This is going to be a long read so let me give a quick overview of what you can expect. Lets start with a definition:
Program Space: A lightweight virtual environment for programs designed to restrict the programs running inside the Program Space to their own data and configuration, and to restrict configuration options and runtime behavior to values/behavior that the user finds acceptable.
The definition above is all about what a Program Space should be. It says nothing about how to create and use a Program Space. Thats what this article is about. In this article I will introduce you to a program of mine called psc (Program Space Control), and I will show you how to use this program to create and manage the virtual environment mentioned in the definition.
As you will learn, working with Program Spaces is easy. In order to create a Program Space named “test” you can simply type:
psc test --create
You can run a program inside this Program Space by typing:
psc test --run [program]
psc test --run bash
psc test --run ifconfig
psc test --run top
Psc lets you create and control a virtual environment but does not configure this environment. Configuration is done with scripts that contain a combination of psc commands and ordinary commands like mount, ip, iptables etc. Its the configuration that restricts the programs running inside the Program Space. So if you would type:
psc test --create
psc test --run pstree
You would see no difference with typing the pstree command directly (you would see a tree containing dozens of programs). If however you would run a script to setup a rootfs like:
psc test --create
psc test --run pstree
Then the output would be:
Apart from the pstree program only two other programs seem to be running, all the other programs running on the system are invisible to the pstree program.
The script ps_rootfs mentioned above is part of the Program Space Construction Set (PSCS) which also contains the source code of the psc program. The PSCS contains a number of sample configuration scripts that will show you how a Program Space can be configured. Besides the rootfs script it contains a network script and scrips to run a LAMP stack (Wordpress Blog) inside Program Space.
I hope this short introduction is enough to make you want to read the long explanation :-). Further on in this article I will explain the technology behind Program Spaces: how the psc program works and what commands it has. To demonstrate how the psc program can be used to create and configure a Program Space I wrote a number of scripts which will be explained in the PSCS section.
At this point I have to say something about the status of my Program Space project: Its experimental. The psc program and scripts have been tested on my Debian Wheezy systems alone and are not intended to be used by inexperienced users or in a production environment.
If you are an experienced developer or sysadmin I would love to hear from you. Bug reports, ideas for improvements, or contributions to the PSCS are welcome!
Inside the Linux kernel all the important resources are capable of having multiple independent configurations. This technology is called kernel namespaces. Programs running in User Space use one of the possible configurations of a resource and are referred to as “running inside a namespace”.
Named after the resource there are several different namespaces (configurations) that can be created:
PID namespace: A PID namespace encapsulates a process tree. Starting a new PID namespace creates a new process tree which only contains processes that are started inside the newly created namespace. The first process running inside a PID namespace has a PID of 1, and acts as the “init-process” of the namespace.
NET namespace: A network namespace represents a completely independent network stack. This includes interfaces, IP addresses, routing and iptables rules. A newly created network namespace is spic and span - not even the lo interface is configured...
MNT namespace: A mount namespace consists of a set of mount points. A new mount namespace starts with a copy of all the mount points at the moment of creation. This copy is independent - mount actions inside the namespace do not affect mounts outside the namespace.
IPC namespace: The IPC namespace isolates the System V interprocess mechanisms like message queues, semaphore sets and shared memory.
UTS namespace: The UTS namespace encapsulates the settings for host name and domain name.
In order to create a Program Space the psc program creates a small daemon named psd. This daemon starts with its own PID and UTS namespaces, and can later on have private MNT, NET and IPC namespaces. Programs running as children of this daemon inherit the namespaces of the daemon and are restricted by the configuration of the inherited namespaces.
Running programs inside Program Space involves running them as children of the psd daemon. How does that work?
First the daemon is created:
psc test --create
Then send a command to the daemon:
psc test --run pstree
The daemon process (psd) acts much like the ssh daemon, but without the encryption and login part. When the daemon receives the command to run a program it creates a terminal program (pst) which takes care of running the program. To illustrate the connections:
User Space Program Space
--> STDIN STDIN -->
terminal <-- STDOUT psc <-- socket connection --> pst STDOUT <-- pstree
<-- STDERR STDERR <--
Hope this gives you some idea about how things work.
Psc is a small C program which must be compiled first:
gcc -Wall -o psc psc.c
In order to control a Program Space the psc program has a very small set of commands with the following format:
psc [program space name] [psc command] [psc command parameters]
The first parameter is the name of the Program Space. This name must not exceed 60 characters and may not contain spaces. The following commands can be used:
psc [name] --create [logfilename]
This command creates a new Program Space daemon and writes the PID of the daemon to STDOUT, a PID of 0 (zero) indicates an error. A newly created daemon starts with private PID and UTS namespaces. In order to see the effect of the private PID namespace the /proc directory must be re-mounted, this is typically done at a later time with the --chrootfs command. The UTS namespace is used to change the host name of the Program Space to ps_[name]. The logfilename parameter is optional, specify a full path if you want a logfile to be created. Creating a new Program Space requires root permissions.
psc [name] --kill
Kills the Program Space by sending SIGTERM to its daemon. This command requires root permissions.
psc [name] --net
Creates a new network namespace. The namespace starts with no network devices (not even lo), you have to create and configure all network interfaces. This command can only be given one time per Program Space and only by the root user.
psc [name] --ipc
Creates a new IPC namespace. This command can only be given one time per Program Space and only by the root user.
psc [name] --chrootfs [path]
Creates a new MOUNT namespace and changes the rootfs of the Program Space daemon. After this command the working directory of the daemon is set to /. The directory specified by [path] must be a mount point (use mount --bind to create one). The command can only be given one time per Program Space and only by the root user.
psc [name] --cwd [path]
Changes the working directory of the Program Space daemon to the specified path. All new programs running in Program Space start with this working directory.
psc [name] --pid
Writes the PID of the Program Space daemon to STDOUT, a PID of zero indicates an error.
psc [name] --run [program path] [program params]
Runs the specified program inside the Program Space. The user account used for running the program is equal to the account that invoked the psc command. The exit code of the psc command is 1 if psc encountered an internal error, or the exit code of the specified program.
Program Spaces are configured by using a mix of psc commands and ordinary system commands.
To illustrate this I have created a number of example scripts. Together with the pcs program these scrips form the PSCS which you can download at the downloads page.
The PSCS contains the following files:
psc.c – the sourcecode of the psc program
ps_rootfs – this script uses AUFS (a union filesystem) to make directories from the host rootfs read-only, all write actions on the host rootfs end up in a directory that is private to the Program Space.
ps_backup – a script to make a backup of the Program Space.
ps_network – a script to configure the network inside the Program Space
ps_lamp_create – this script creates a Program Space containing a ready-to-run WordPress instance.
ps_lamp – a script to start/stop the WordPress Program Space.
ps_httpd_firewall – this script configures a simple firewall for web-servers running inside a Program Space
Installation of the PSCS files can best be done in a directory that is in the PATH environment variable. A good place would be /usr/local/bin
Before discussing the details of each script its important to pay some attention to the things they have in common.
First, all scripts contain two types of variables: variables that refer to a Program Space, and variables that do not. Without proper naming things can become very confusing. I use the term User Space for everything that does not refer to a Program Space. Variables referring User Space always have a us_ prefix. For Program Space variables I use the ps_ prefix.
Second, its important to execute a script in the proper environment. A script that is designed to be run from User Space must not be able to run inside a Program Space. All scripts start with code to test the environment of the script.
The purpose of a rootfs script is to restrict the programs running inside a Program Space. Ideally these programs should only have access to their own data, and only have access to the shared libraries that are necessary to run the programs. Every change a program running inside a Program Space makes to its rootfs should not affect the User Space rootfs. For example, if a program running inside a Program Space installs a specific version of a shared library then that version should not be available to programs running in User Space.
The ps_rootfs script that comes with the PSCS is designed for a wide range of programs. This means that you can always come up with a better rootfs for a specific group of programs. It creates a rootfs with the following properties:
Directories from the User Space rootfs are mounted read-only inside the Program Space rootfs. It is not possible for a program running inside a Program Space to change the User Space rootfs.
A program running inside a Program Space can make modifications (create/delete files, chown etc) to the mounted directories coming from User Space, these modifications end up in a data-directory which is private to the Program Space.
To perform this magic the script makes use of AUFS, a union file system. The best way to illustrate how this works is by an example - In order to mount the /var directory from User Space the script executes the following mount command:
mount -t aufs -o br=/programspace/test/data/var=rw:/var=ro none /programspace/test/rootfs/var
/var is mounted read-only
/programspace/test/data/var contains changes made in Program Space (not visible)
/programspace/test/rootfs/var the directory a program in Program Space sees (read-write)
In this example “test” is the name of the Program Space.
As you can see its pretty simple. The script mounts a number of User Space directories the same way. Then it creates special directories like /dev inside the Program Space rootfs and creates some necessary device nodes. Once the rootfs is fully configured it changes the rootfs of the Program space by executing:
psc test --chrootfs /programspace/test/rootfs
One of the interesting properties of the generated rootfs is that all filesystem actions end up in either the data or the rootfs directory of the Program Space. Creating a full backup of a Program Space is therefore easy: just tar the directory that contains the data and rootfs directories of the Program Space (note: the ps_backup script from the PSCS does this).
If you use the ps_rootfs script to create a rootfs for a Program Space then all data and configuration files of that Program Space are stored in a directory named /programspace/[name]. The ps_backup script makes a nice tar archive of this directory. Restoring the backup is as easy as tar xf. (must be done as root)
In most cases the data inside the backup does not depend on the computer that created the backup. So if you have another system with the same software installed you can simply move or copy the Program Space to that system by unpacking the backup. (I had no problems moving the LAMP Program Space data from a 32bit system to a 64bit system)
The ps_network script uses DHCP to automatically configure the network of a Program Space. In order to do this, your system must have a bridged network available (the script expect a bridged network with the name br0).
If you do not have a bridged network, then you can create one by the following steps (Debian Wheezy):
apt-get install bridge-utils
modify /etc/interfaces so that it contains:
iface lo inet loopback
iface br0 inet dhcp
restart the network:
Before you run the ps_network script you must change the rootfs by running ps_rootfs. This is because the dhclient program that runs inside the Program Space needs some space under /var to store information about its current leases. Without the rootfs this info would end up in the User Space rootfs and could cause problems there.
This script creates a ready-to-run WordPress Program Space. The purpose of the script is to demonstrate how the pcs program and the scripts mentioned earlier can be used together, it is probably not the best example of how to configure a LAMP stack ;-)
Unfortunately it is not possible to create a script that is independent of the Linux distribution, this demo is written for Debian Wheezy only.
The second part of the LAMP demo is a small script to start and stop the WordPress Program Space. Once the configuration is done, starting and stopping a Program Space is very easy. In order to start the lamp_demo Program Space the script runs the following commands:
(note: checks and error handling removed, click sourcecode link for actual code)
psc lamp_demo --create
psc lamp_demo --run /etc/init.d/mysql start
psc lamp_demo --run /etc/init.d/apache2 start
As you can see, its simple!
If you issue a pstree command inside the Program Space the result is:
This has been a long article, and it is nice you are still reading :-) I hope you like this Program Space idea and will give it a try. Please feel free to contact me if you have questions or ideas for improvements.
The Raspberry Pi seems nice hardware for a small home server like the FreedomBox. It is both low power and low cost. The only questions for me were: is it powerful enough - how does it compare to other computers?
On the Raspberry Pi website I read that it's performance is roughly equal to a 300 MHz Pentium 2 which is not very helpful. I once owned a 300 MHz Pentium 2 system, but that was 15 years ago. I really have no idea how any modern system compares to it.
In my previous article I measured the performance of the MK802 stick computer. This computer turned out to perform roughly equal to a single core Intel Atom. Last week I finally got my own Raspberry Pi so I decided to run the same tests for the Pi.
I bought version 2.0 of the Raspberry Pi model B. This version has the following hardware:
SoC: Broadcom BMC2835
CPU: 700 MHz ARM 11
GPU: Broadcom VideoCore IV
Memory: 512 Mb (shared with GPU)
USB: 2 * USB 2
Video: Composite out, HDMI 1.4
Audio out: 3.5 mm jack + HDMI
Network: 10/100 Mbit RJ45
Storage: 32 GB Samsung class 10 SD card
As OS I use Raspbian. This is a Debian derivative that has been optimized for the Raspberry Pi.
To measure the performance I used an experimental python-powered version of my blog. This version does not use a database, but stores the individual postings in a simple directory structure. For each request 10 postings are read from disk and served as one HTML page that looks (almost) exactly like my normal blog. The size of this page is 64.9 Kb.
On a fast system Apache bench was used to measure the performance in pages/sec. I requested 1000 pages with a concurrency of 10.
The measurements were done for the following systems:
The Raspberry Pi model B version 2.0, running at 700MHz
My current FreedomBox. This is an 1.2 GHz Marvell Kirkwood 6281 system. The same SoC is used for the DreamPlug.
The MK802, which uses an 1 GHz Allwinner A10.
An Intel Atom 330 system running at 1.6 GHz.
My Desktop system with a dual core G620 Pentium processor running at 2.6 GHz.
Except for the MK802, all systems have a wired 1Gb Ethernet connection. For the MK802 i did two measurements: one with WiFi Ethernet and one with a wired 100Mb USB-Ethernet adaptor.
Raspberry Pi Marvell MK802 MK802 Atom Desktop
ARM 11 6281 WiFi Wired 330(*) G620 (**)
Pages/sec. 17 25 12 39 174 805
MB/sec. 1.1 1.64 0.77 2.5 11.2 52
Power (W) 3 (#) ~13 3-4 (#) 4 (#) 35 45
Pages/sec/W 5 2 3 10 5 18
(#) A fair comparisson would include 5W for the missing HD
(~) estimation, could not measure without ruining my uptime :-)
(*) 4 threads were used.
(**) 2 cores (= 2 threads) were used.
As you can see, the Raspberry Pi is not very fast. Still I found its performance much better than expected. It roughly performs at 70% of my current FreedomBox and roughly at 40% of a single core Intel Atom clocked at 1.6 GHz. This may not look great but remember that the important question is not how fast it is, but: is it fast enough?
Having expected much worse results for the Raspberry Pi I wondered if the test reflected real-world performance. What if I run some real-world server software like Apache on it? To test this I installed Apache with Wordpress on the Raspberry Pi and copied my blog to the Raspberry Pi.
Requesting the main page of my blog took 3.4 seconds on the Raspberry and 2.6 seconds on my Marvell system. A difference of 25 percent. Not bad! I find the performance of my FreedomBox quite acceptable and I do not think anyone would notice it it was 30 percent slower. So in my opinion the Raspberry Pi would be fine hardware for a FreedomBox.
Recently a whole range of cheap Android devices have become available, all powered by the Allwinner A10 SoC. Thanks to the way A10 devices boot they are very easy to hack. All that is needed is a bootable SD card. How to make such a card is no big secret, and there are now multiple SD card images available. You can boot for example Lubuntu or Debian instead of Android. One A10 device, the MK802 stick computer, is almost ideal for a small home server. I bought one to examine its potential for the FreedomBox.
What makes A10 devices special?
Before i share my experiences with the MK802 i have to write something about its hart, the Allwinner A10 SOC. This remarkable 400 pin (!) chip only costs about $7 and houses the following:
A one core Cortex A8 ARM processor, typically running at 1GHz.
A MALI400MP OpenGL 2.0 GPU.
DDR3 800 MHz controller.
Hardware accelerated video playback.
Video outputs for: HDMI, VGA, Analog video, and LCD.
A 10/100 MHz Ethernet controller.
A NAND Flash controller.
USB Host controller + USB OTG controller.
A SATA-II controller.
Etc, Etc, Etc....
Apart from all the hardware features its boot process is also interesting. Booting goes as follows:
Check if the reset pin is pressed. If so, load new firmware from the USB port.
Check if there is a SD card present. If it contains a bootable image, boot from the SD card.
Boot from the internal NAND storage (boot Android).
Step 1 can recover a "bricked" device. Step 2 makes loading an alternative OS possible. Very hacking friendly!
What A10 devices are available?
The A10 is used in a whole range of products, from tablets to TV multi media boxes to stick computers. The most popular devices are:
The $70 Mele A1000. This is a complete computer. Some specs: 512 Mb RAM, SD slot, support for SATA Hard-disks, connectors for multiple types of monitor (VGA/HDMI/Analog video), 10/100 Ethernet connector, WIFI, Audio out and two USB host ports.
The $65 MK802. This is a stick sized computer (0.47 x 3.46 x 1.38 inch) that has (of course) less connectors than the Mele A1000. The specs are: 1024 MB RAM (older versions 512 MB), microSD slot, HDMI video out, WIFI, one USB host port and one USB-OTG port.
You will probably agree with me that the $70 Mele is a better deal - the MK802 is overpriced. It would not surprise me if the MK802 drops in price to about $40 in the near future.
Booting an alternative OS.
A10 devices have become very popular the last few months and a lot of development is going on. Most development targets Lubuntu (Ubuntu + LXDE) and the Mele A1000.
The best way of running an alternative OS is download a ready made SD image for your device and write this to a cheap SD card (8GB class 4 is fine). On my MK802 i successfully tried the following images:
A Lubuntu 12.04 desktop version, downloaded from miniand.com. This version has a fixed 720p HDMI output with no hardware acceleration. While i'm not very interested in desktop use, i found the desktop performance quite acceptable. This Lubuntu version seems stable too.
The Linaro-alip armhf version. This image is made by Toby Corkindale and has an 1080p HDMI output, again with no hardware acceleration. Desktop performance is acceptable, stability is OK.
How does the MK802 perform?
A small internet-connected server like the FreedomBox should meet the following performance requirements:
It should be fast enough for simple tasks like serving web-pages.
Ethernet/WIFI must be fast enough.
Because the device runs 24/7 energy consumption must be low.
All of these can be measured easily. Measurements are more interesting if you can compare them for different systems, so i decided to do the same measurements for the following systems:
My current FreedomBox. This is an 1.2 GHz Marvell Kirkwood 6281 system. The same SOC is used on the DreamPlug.
The MK802, which uses an 1 GHz Allwinner A10.
An Intel Atom 330 system running at 1.6 GHz
My Desktop system with a dual core G620 Pentium processor.
Except for the MK802, all systems have a wired 1Gb Ethernet connection. For the MK802 i did two measurements: one with WiFi Ethernet and one with a wired 100Mb USB-Ethernet dongle.
To measure the performance i used an experimental python-powered version of my blog. This version does not use a database, but stores the individual postings in a simple directory structure. For each request 10 postings are read from disk and served as one HTML page that looks (almost) exactly like my normal blog. The size of this page is 64.9 Kb.
Apache bench was used to measure the performance in pages/sec. I requested 1000 pages with a concurrency of 10. The results are:
Marvel MK802 MK802 Atom Desktop
6281 WiFi Wired 330(*) G620 (**)
Pages/sec. 25 12 39 174 805
MB/sec. 1.64 0.77 2.5 11.2 52
Power (W) ~13 3-4 4 35 45
Pages/sec/W 2 3 10 5 18
(~) estimation, could not measure without ruining my uptime :-)
(*) 4 threads were used.
(**) 2 cores (= 2 threads) were used.
From the results the following conclusions can be drawn:
The WiFi of the MK802 performs poorly. However, a bandwidth of 770 KB/sec is still well above the upstream speed of most households so it may be considered acceptable.
The 1 GHz A10 processor is much more powerful than the 1.2 GHz Kirkwood processor of my FreedomBox. Personally, i find the performance of my FreedomBox (which runs several virtual machines with Wordpress blogs) quite acceptable. A10 devices will do well as FreedomBoxes.
The A10 performs roughly equal to a 1.6 GHz single core Intel Atom (with no hyper-threading).
Using an Intel Atom or even a desktop computer seems overkill. An A10 powered device should be powerful enough.
Pages/sec/W is a measurement of the energy efficiency. To be honest, these values are not fair because the MK802 is the only device without a hard-disk. A hard-disk consumes about 5 W so it has a big impact. The energy efficiency of the MK802 is excellent.
My overall conclusion is that the MK802 should do well as a FreedomBox. It's a pity that it has no wired Ethernet connection. It has however an USB-OTG port which could be programmed to behave like an Ethernet dongle (just like those WIFI sticks - you plug one in and it is detected as a new network interface)
Here are some links to start with if you are interested in A10 devices:
Much pioneering work on the A10 was done by Luke Kenneth Casson Leighton. Luke is the one behind Rhombus Tech. A Community Interest Company, which is developing an open hardware Computer-on-Module that uses the A10. Lots of info can be found at:
In this article i answer the following question: When does the energy cost of running the FreedomBox software on a desktop computer justify buying specialized low power hardware? The answer to this question may surprise you.
Not long ago a reader of my blog asked me why he could not use his desktop computer to run the FreedomBox software. I answered that he could, but it would not be very economical. I gave him the following example: My desktop computer at the time consumed 93 Watt when idle. Keeping this machine running for a year would cost me 186 EUR. The energy costs of my 11 Watt NAS "FreedomBox edition" is just 22 EUR a year. In this example it is clear that it pays to buy special hardware for the FreedomBox. For my new energy efficient desktop computer (23 Watt idle) the situation is different.
In a previous article Free hardware for the FreedomBox software i argued that the cheapest hardware for the FreedomBox is hardware that you need anyway. If you can run the FreedomBox software on this hardware without changing it's function, then the hardware for the FreedomBox costs you nothing. This is true for always-on devices like wireless routers and NAS servers. With these devices the only cost of running the FreedomBox software is the cost of the extra energy which is probably very low. For desktop computers the situation is different. Desktop computers consume more energy than specialized always-on devices and are only used part of a day (normally).
How much does it cost to use a desktop computer to run the FreedomBox software?
Calculating the costs is very easy. Because you need the desktop computer anyway, the price does not enter the equation. Only the extra energy costs are important. This leads to the following equation:
Cd = Pdi * Td * Ckwh/1000
Cd : Cost of running FB software on a desktop computer
Pdi : Power consumption in Watt of the desktop computer when idle
Td : Time in hours the desktop computer is running FB software exclusively
Ckwh : Kilowatt-hour price.
Because the FreedomBox software is mostly sleeping, i only take the idle power consumption into account.
How much does running a dedicated FreedomBox device cost?
With a dedicated device you have to enter the price of the device into the equation:
Cf = Cfd + Pfi * Tf * Ckwh/1000
Cf : Cost of running FB software on a dedicated FB device
Cfd : Price of the FB device
Pfi : Power consumption in Watt of the dedicated FB device when idle
Tf : Time in hours the FB device is running
Some quick calculations.
Let's compare the cost of my (very) energy efficient desktop computer with a DreamPlug. I use the following parameters:
Pdi = 23 W
Td - do not correct the time for non FB use of the desktop computer.
Cfd = 163 EUR DreamPlug + 50 EUR USB hard-disk = 213 EUR
- assume a 3 year life of the DreamPlug
Pfi = 5 W DreamPlug + 5 W USB hard-disk
Ckwh = 0.25 EUR
In this example using a DreamPlug as a dedicated FreedomBox device is not economical. Even with no correction for the time the desktop computer is used for it's normal tasks, the DreamPlug solution is almost 2 times as expensive.
Using the DreamPlug results for a 3 year period you can calculate the idle power consumption of a desktop computer that is just as expensive as a dedicated DreamPlug. This turns out to be 42 Watt.
Let's calculate the costs of running a Raspberry Pi model B for three years.
Cfd = 39 EUR (32.70 GBP * 1.2 EUR/GBP) + 50 EUR USB HD = 89 EUR
Pfi = 1 W Raspberry Pi + 5 W USB HD = 6 W
Cf = 89 + 6W * 3*365*24 * 0.25/1000 = 128 EUR
The very low power Raspberry Pi is the winner. It would save me 33 EUR over a period of three years. For me, this is not a good reason to buy a Raspberry Pi. (Still think i buy one, just for fun!)
(Note: in these calculations i have not corrected for the time i use my desktop computer for it's normal tasks. If i correct for the 8 hours a day i use my system for desktop-tasks, the desktop costs for running the FreedomBox software would be 100 EUR.)
If you have desktop computer with low idle power consumption, then there is no (economical) need to buy special low-power hardware for running the FreedomBox software.
Maximum measured power is 53 Watt. This is without stressing the graphics core which will probably add an extra 7 Watt if its used to its full capacity.
When I selected the system components I had the following main requirements:
It must be able to use the system to develop software for GNU/Linux.
I wanted to use the system as an internet connected server that runs 24/7.
To isolate my development work from the server-tasks, I want the server-tasks to run inside a virtual machine. The server-tasks are simple (personal web-server, email server, etc.) and do not need a very fast CPU (I am currently using ARM hardware for these tasks)
Because the machine is always on, its important that the system uses as little energy as possible. A one Watt device that runs for a year costs about 2 EUR in the Netherlands. Normal PC's like my old system easily consume 90 Watt or more when idle, which make them very expensive servers.
Both main usages of the system only occasionally stress the system so low energy consumption for the idle state is a main concern.
Here are some remarks on the components I selected.
I selected an Intel G620 processor because its performance is more than enough for my simple tasks. I t has an nice integrated graphics core and low power consumption. With a price of only 54 EUR it's cheap too.
The specs mention a TDP of 65 Watt. My whole system never uses more than 60 Watt so this is a bit pessimistic. I think a TDP of 35 Watt like the special energy efficient G620T version is more realistic. When compared with the G620T the G620 only uses one or two Watt more.
Finding the right mainboard was a bit tricky. Power consumption varies quit a bit between different products. Even when idle the difference in power consumption can be over 10 Watt! A very nice comparison of 21 mainboards can be found here. From this comparison you can see that the Intel DZ68DB mainboard I selected does very well.
Here I had two requirements. High efficiency and low noise. These qualities are both present in the selected Be quiet! Straight Power E9 400W. This power supply has an 80Plus gold certification, which guaranties an efficiency of 90% or more. For cooling an 135mm SilentWings fan is used resulting in an extremely low noise level of under 15 dB(A) at full load. With a price of about 70 EUR this power supply is twice the price of a standard power supply. When I look at the specs and build quality I find this very good value for money.
Not much to say. I bought 8GB just to be able to compile very large programs and run the VM's
I bought an energy efficient Western Digital Caviar Green WD5000AZDX, 500GB. This HD is fast and almost silent.
The integrated graphics core of the G620 processor is more than capable for any graphics task other than gaming. Video decoding is pretty good. I even managed to play the “killa sampla” with only a small distortion in the first two seconds of the clip.
At the moment i'm running the testing version (Wheezy) of Debian GNU/Linux on the system. Quite a nice experience, everything worked out of the box and no proprietary drivers needed to be installed.
I only needed to make some small adjustments to the kernel settings in order to lower the power consumption. It turns out that the 3.x kernels have support for the power saving features of the integrated graphics core of the G620 processor, but these features are disabled by default. To turn the features on you have to edit the grub boot configuration as follows: