I'm now getting Green Energy via Lichtblick

Since a few days I'm a happy customer of Lichtblick, the biggest electric utility (Stromanbieter) in Germany which provides 100% green energy (or Ökostrom as it's called in Germany).

Why?

I was getting tired of all those hypocrites and liars (a.k.a. politicians) who keep on talking about global warming and renewable energy, but fail to produce any real results since many, many years now.

So I decided to do my (small) part to help reduce CO2 emissions, the greenhouse effect, and global warming. After measuring the energy consumption of all my power-sucking devices and replacing or turning off some of them, and after replacing all lightbulbs with highly efficient energy saving lightbulbs, changing the electric utility was the next logical step.

First try (failed)

As probably almost everyone in Munich, I was a customer of the Stadtwerke München (SWM). According to the last electricity bill I got from them, their sources of energy are: 17% renewable energy, 83% fossil energy sources, 0% nuclear power. Well, at least they don't use nuclear power, that's a big plus IMO, but 83% polluting, fossil crap? Thanks, but no thanks.

So I opted to use their Ökostrom M-Natur tariff, which (they claim) provides 100% renewable energy. They use the so-called Aufpreismodell (sorry, German only), i.e. you pay a few cents extra per kWh, and this extra money is invested in renewable energy sources (mostly small hydropower plants around Munich).

As I found out a few hours later (d'oh!) this "Aufpreismodell" is not really ideal (you still pay a conventional electric utility instead of one with 100% renewable energy, for instance). In addition, I stubled over a petition for the city of Munich to stop investing in a new fossil fuel power plant (bituminous coal, to be more precise). Which I promptly signed (and which went to several local parties including the greens, the mayer of Munich, and others).
Now, this is what I call hypocritical behaviour — on the one side they claim/pretend to be environmentally friendly by promoting their "M-Natur" tariff, and at the same time they invest even more money in fossil fuels? WTF? Anyway, it seems the petition did have at least some impact, the aren't allowed to invest more money into that fossil fuel powerplant than they already did.

For me that was more than enough reason to immediately revoke my M-Natur tariff, and what's more, I switched to a completely different company now, Lichtblick (see also the respective Wikipedia page). I'm not willing to support such energy policies/politics with my money anymore.

Lichblick

Lichtblick is an Ökostromanbieter in Germany, supposedly the biggest one.
Their "energy mix" is 100% renewable energy (which is correct, unlike with SWM, as they do not own any additional fossil fuel plants). 76% of that is hydropower, FWIW.

Their prices may be a bit higher than those of conventional electric utilities, but not all that much; you might even pay less, depending on where you live and which tariff you have now. You can use their price calculator to find out.

Btw, some other good choices in Germany are Greenpeace energy, Elektrizitätswerke Schönau, and Naturstrom AG.

How the switch went

Easy. Grab the respective PDF, print it, fill in the required info, and send it to them. Alternatively, they also offer online registration. It'll take a few weeks until the switch is performed; they have to contact your current electric utility etc. In my case it took ca. 4 weeks.

There are no additional costs for switching. There is no "downtime" whatsoever (not even a few seconds), German law requires that you always reliably get your electricity 24/7 (and it indeed worked just fine for me).

So, that's that. From now on I'm happily using green energy all day (and night) long. I'm doing my part in Saving The Planet (tm) and I sleep a bit better at night...

P.S. No, I'm not getting paid by Lichtblick (or anybody else) to write this.

Linux on the Fujitsu Siemens Lifebook S-4572 Subnotebook

Fujitsu Siemens Lifebook S-4572

TuxMobil - Linux on Laptops, Notebooks, PDAs and Mobile Phones Linux On Laptops

I recently bought a Fujitsu-Siemens LIFEBOOK S-4572 (sub)notebook on eBay for less than 150 Euros, a really great little machine.

It's a Pentium III, 750 MHz, 256 MB RAM (the chipset cannot handle more than that unfortunately), 12.1" screen, ethernet, 2x USB 1.1, CD-ROM/DVD reader + CD-ROM writer, PCMCIA, IrDA, modem, and a 15 GB hard drive. No floppy, no serial ports, no parallel port. There's no wireless builtin, but I use a cheapo PCMCIA adapter.

The greatest feature compared to all other laptops I previously owned is that the battery life is really great, it lasts almost 3 hours (compare that to 45 minutes on my current "main" laptop).

I'm running Debian unstable on the box (of course). Here's the Linux support status as far as I have tested things:

Networking

Works out of the box using the e100 driver.

Sound

Works out of the box using the snd_intel8x0 driver.

X11

Works out of the box, using either the vesa or the ati driver (at a max. resolution of 1024x768).

Touchpad

Works out of the box. Using the Option "SHMConfig" "on" line in /etc/X11/xorg.conf's InputDevice section (using the synaptics driver) also works fine and allows you to scroll using the touchpad, e.g. in a browser. More info in the SynapticsTouchpad page on the Debian wiki.

CDROM, DVD

Reading CD-ROMs and DVDs as well as burning CD-ROMs works fine. I don't think the drive is capable of writing DVDs.

External VGA

Displaying the screen contents on an external VGA monitor (or beamer) works just fine, switching is done using Fn+F10.

PCMCIA

Works fine, tested using the Sitecom WL-112 wireless card. The driver installation for that is straight-forward, too:

$ apt-get install rt2500-source
$ m-a a-i rt2500-source
$ dpkg -i /usr/src/rt2500*deb

Special keys

All the Fn-keys work fine (brightness, volume, etc.). There are five other special keys (for starting a browser or something) which I haven't tested, but I don't really care...

USB

Works fine, but it's only USB 1.1, so some higher-speed devices will not work (DVB-T USB devices for example; PCMCIA DVB-T adapters might work).

IrDA, Modem

Untested, I don't care.

Powersaving, Suspend to RAM

It seems this CPU (Pentium III, Coppermine) doesn't support frequency scaling, so cpufreq-set doesn't work. I'm using laptop-mode-tools to improve battery life a bit more, though. Also, Suspend-to-RAM works fine out of the box:

$ apt-get install hibernate
$ hibernate-ram

Suspend-to-Disk works fine, too, even though I'm using a dm-crypt'ed disk (+ LVM), as with all my boxes:

$ hibernate-disk

lspci

00:00.0 Host bridge [0600]: Intel Corporation 82440MX Host Bridge [8086:7194] (rev 01)
00:00.1 Multimedia audio controller [0401]: Intel Corporation 82440MX AC'97 Audio Controller [8086:7195]
00:00.2 Modem [0703]: Intel Corporation 82440MX AC'97 Modem Controller [8086:7196]
00:07.0 Bridge [0680]: Intel Corporation 82440MX ISA Bridge [8086:7198] (rev 01)
00:07.1 IDE interface [0101]: Intel Corporation 82440MX EIDE Controller [8086:7199]
00:07.2 USB Controller [0c03]: Intel Corporation 82440MX USB Universal Host Controller [8086:719a]
00:07.3 Bridge [0680]: Intel Corporation 82440MX Power Management Controller [8086:719b]
00:12.0 Ethernet controller [0200]: Intel Corporation 82557/8/9 [Ethernet Pro 100] [8086:1229] (rev 09)
00:13.0 CardBus bridge [0607]: O2 Micro, Inc. OZ6933/711E1 CardBus/SmartCardBus Controller [1217:6933] (rev 02)
00:13.1 CardBus bridge [0607]: O2 Micro, Inc. OZ6933/711E1 CardBus/SmartCardBus Controller [1217:6933] (rev 02)
00:14.0 VGA compatible controller [0300]: ATI Technologies Inc Rage Mobility P/M [1002:4c52] (rev 64)
01:00.0 Network controller [0280]: RaLink RT2500 802.11g Cardbus/mini-PCI [1814:0201] (rev 01)

Other resources

I'm really considering making this my "main" box even though it's a bit older/slower, as my current laptop with 45 minutes battery life is a major pain when travelling...

Rebuilding the whole Debian archive using the Open64 compiler

I got bored recently, so I rebuilt the whole Debian archive on one of my machines. To make this not a completely useless excercise, I used the Open64 compiler instead of gcc and created build logs for your perusal.

So what is Open64?

From the Wikipedia page:

Open64 is an open source, state-of-art, optimizing compiler for the Intel IA-64 (Itanium), AMD Opteron and Intel IA-32e architecture. It derives from the SGI compilers for the MIPS R10000 processor. It was released under the GPL in 2000, and now mostly serves as a research platform for compiler and computer architecture research groups. Open64 is licensed under the GPL. Open64 supports Fortran 77/95 and C/C++, as well as the shared memory programming model OpenMP. It can conduct high-quality interprocedural analysis, data flow analysis, data dependence analysis and array region analysis.

Open64 installation

The installation is pretty easy fortunately:

$ wget http://ovh.dl.sourceforge.net/sourceforge/open64/open64-4.0-src.tar.bz2
$ tar xfvj open64-4.0-src.tar.bz2
$ cd open64-4.0
$ export TOOLROOT=/opt/open64
$ make
$ make install (as root)

I think you need gcc-3.4 (gcc 4.x is not yet supported), and for some odd reason you also need csh as one of the install scripts seems to use it.

It would be nice if someone could package Open64 for Debian, I definately don't have the time to maintain such a huge package (a whole maintainer team would probably be good here).

Rebuilding the Debian archive

There are several possible ways (and tools) to rebuild the Debian archive; I've used pbuilder/cowbuilder with the rebuild scripts from Bastian Venthur, which are now included in pbuilder.

First we need to install the required packages, setup a cowbuilder base chroot, and get the list of packages:

$ apt-get install cowdancer grep-dctrl wget devscripts sudo
$ cowbuilder --create --distribution lenny --basepath /var/cache/pbuilder/testing-base.cow
$ cp -r /usr/share/doc/pbuilder/examples/rebuild .
$ cd rebuild
$ ./getlist lenny

Now we add Open64 into the cowbuilder chroot and fix up the chroot by pointing the gcc/g++ symlinks to Open64:

$ cp -a /opt/open64 /var/cache/pbuilder/testing-base.cow/opt
$ chroot /var/cache/pbuilder/testing-base.cow
$ cd /usr/bin
$ mv gcc gcc.orig
$ ln -s /opt/open64/bin/opencc gcc
$ mv g++ g++.orig
$ ln -s /opt/open64/bin/openCC g++
$ exit

In addition, we set the CC and CXX environment variables to Open64, which will make 90% of all (autoconf-using) packages automatically use Open64. We need a small script for that:

$ cat c.cfg:
export CC="/opt/open64/bin/opencc -m32"
export CXX="/opt/open64/bin/openCC -m32"

Now edit the buildall script. Change the Debian mirror used there (optional) and make it use our c.cfg script by adding the --configfile /path/to/rebuild/c.cfg option in the "pdebuild" line.

We can now finally start building the archive:

./buildall list.lenny.i386 lenny

You can also run multiple buildall instances at once to speed up the archive rebuild on SMP/multicore machines, and you can even abort the command and simply restart it later. The script will continue where it left off.

Results

The whole rebuild (with 2 instances of buildall running at the same time) took ca. 9 days on an AMD64 Athlon64 X2 (dual core, 1.8 GHz each) machine with 1 GB of RAM.

I really should have used something like apt-proxy to speed up the rebuild and save some bandwidth, but I read about apt-proxy too late...

All log files from my rebuild are available for detailed analysis if anybody is interested (you can browse the logfiles online or download all of them as tarball). I didn't perform any detailed analysis, just some rough numbers here:

  • Succeeded package builds: 8425
  • Failed package builds: 2509
  • Total number of packages rebuilt: 10934

If anybody does some more elaborate analysis, please let me know.

RAID5 + dm-crypt + LVM + ext3 Debian install and benchmarks

OK, so I've setup a RAID5 at home because I'm getting tired of failed disk drives and data losses.

Some notes:

  • The system consists of 3 x 300 GB IDE drives in software RAID5 (standard Linux kernel and mdadm), thus ca. 600 GB usable storage space.
  • I've used the stock Debian installer to set up all of this, no custom hacks or anything needed.
  • Each drive is on an extra IDE bus/controller (1x onboard/internal, 2x on an PCI IDE controller card), as broken IDE disks (lacking hot-swap capabilities) often take down the whole IDE bus with them; it's not a good idea to put two disks on one IDE bus.
  • The software stack is: RAID5 at the botton, dm-crypt on top of that to encrypt the whole RAID, LVM on top of that to partition the system into /, /usr, /var, /tmp, /home, and swap.
  • /boot is on an extra 1 GB partition (replicated on each drive) as GRUB doesn't work on RAIDed disks and I want to use GRUB, not LILO. GRUB is also installed on the MBR of each drive, so if one of them fails, the other two can still come up.
  • I installed and configured smartmontools to check the status of the drives, and hddtemp to check their temperature.
  • Stability tests so far: While the system is running, pull out one of the IDE drives (yes, they're not hot-swappable and that may not be such a good idea, usually). The system survived without data loss. Time for rebuilding the array: ca. 1 hour. Second test: while the system is running, pull the plug. The system survived that, too.

Some stats from bonnie++ if anybody cares:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
bonsai           2G 26727  72 39426  19 16690   7 28725  65 34164   7 215.3   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
bonsai,2G,26727,72,39426,19,16690,7,28725,65,34164,7,215.3,0,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

(Now, if I only knew what all those figures mean ;-)

No, neither the software RAID5, nor the dm-crypt layer nor LVM cause any measurable performance degradation whatsoever (from my subjective feeling). I don't care enough to measure anything. The CPU is idling all the time.

Power consumption is rather high (partly due to the mainboard and CPU, but also because of the disks + fans) and the system is pretty loud, which both sucks on the long run. I plan an ultra-silent, ultra-low-power RAID5 with 2.5" disks attached via USB to a (silent, low-power) NSLU2 for later.

Testing stuff with QEMU - Part 3: Debian GNU/kFreeBSD

Debian GNU/kFreeBSD screenshot 1

Note: This article is part of my Testing stuff with QEMU series.

From the Debian GNU/kFreeBSD port page:

Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel, coupled with the regular Debian package set.

Q: Why would anybody want to do that?
A: Why not? [1]

So, after we have talked about that, let's start:

  1. Install QEMU:
    apt-get install qemu
  2. Download the latest Debian GNU/kFreeBSD installer ISO image (either for i386 or amd64):
    wget http://glibc-bsd.alioth.debian.org/install-cd/kfreebsd-i386/20070313/debian-20070313-kfreebsd-i386-install.iso
  3. Create a QEMU image which will hold the Debian GNU/kFreeBSD (i386) installation:
    qemu-img create -f qcow2 qemu_kfreebsd_i386.img 5G
  4. Boot directly from the ISO image and install Debian into the QEMU image:
    qemu -boot d -cdrom debian-20070313-kfreebsd-i386-install.iso -hda qemu_kfreebsd_i386.img
  5. The FreeBSD installer will now start. For more detailed instructions see the Installing Debian GNU/kFreeBSD manual.
    First you can choose between an "Express" or "Custom" install (I used "Express").
  6. Next you end up in the partitioning tool. Type "a" to use the entire (QEMU) disk for the installation (the disk is called "ad0", not "hda" as on Linux). Type "q" to quit the partitioning tool.
  7. You are now asked which boot manager to use. For QEMU you should use "BootMgr", the default FreeBSD boot manager. If you install on real hardware you can also use GRUB; in that case choose "None" here (see the manual for more information), but note that the installer does not install or configure GRUB for you! You should do that beforehand!
  8. Next up: The disklabel editor. Here you'll create a partition ("slice" in FreeBSD-speak) for the root filesystem and a swap partition.
    Press "c" to create a new slice (will be called "ad0s1"), enter "4GB", choose "FS" (filesystem), and enter "/" for the root filesystem. Per default the UFS2 file system will be used. To create the swap partition, press "c" again, enter "1023MB", and select "swap". The new slice is called "ad0s1b". Press "q" to quit.
  9. Choose "minimal" when asked which distribution to install.
  10. Installation media dialog: select "CD/DVD" and "acd0" (for QEMU's ATAPI/IDE CD-ROM drive).
  11. The installation will now begin, and after a while you're asked to switch to console 3 using ALT-F3. Do it.
  12. You'll have to answer a bunch of questions: geographic area + city you're in (for timezone), whether you want to participate in the Debian popularity contest, whether module-init-tools should load additional drivers (no, so press ENTER three times). The installation will soon be finished.

At the end you must select "No" as you're told to do, then reboot via "Exit Install". You can then shutdown QEMU.

  1. Restart QEMU with the newly installed Debian GNU/kFreeBSD:
    qemu -hda qemu_kfreebsd_i386.img
    Debian GNU/kFreeBSD screenshot 2
  2. Press enter at the FreeBSD boot manager prompt, then login as root (there's no password).
  3. First things first: Set up a root password:
    passwd
  4. Now let's fix networking, update the system and install a bunch of packages:
    nano /etc/network/interfaces
    Yes, there's no vi, not even a symlink to nano! Uncomment the two "ed0" lines ("ed0" is the equivalent to "eth0" on Linux, I guess).
    /etc/init.d/networking restart
    apt-get update && apt-get dist-upgrade
    apt-get install vim xorg icewm xterm
  5. You can fix your console keymap using the kbdcontrol package (just select your keymap from the menu):
    apt-get install kbdcontrol
  6. Finally, let's fix X11 and start it. But first we create a new user, as we don't want to run X11 as root:
    adduser uwe
    vi /etc/X11/xorg.conf
    The mouse device is "/dev/psm0", the protocol "PS/2", and the graphics driver should be "vesa":

      Section "InputDevice"
          Option "Device" "/dev/psm0"
          Option "Protocol" "PS/2"
      [...]
      Section "Device"
          Driver "vesa"
        
  7. That's about it. Login as "uwe" (or whatever your username is) and start X11:
    startx

Wasn't all that hard, eh? Now, if you've got some spare time, head over to the Debian GNU/kFreeBSD wiki page and help improving this port ;-) You should probably start with reading the PORTING guide.

Both kfrebsd-i386 and kfreebsd-amd64 seem to be reasonably stable already (and more than 70% of the whole Debian archive builds fine on these architectures, see kfreebsd-i386_stats and kfreebsd-amd64_stats). I'll quite likely install kfreebsd-amd64 on one of my boxes soonish and start using it, maybe I'll even find some time to fix/patch/port some packages...

[1] More elaborate answer(s) and reasons are available in the Debian wiki.

Syndicate content