The most merciful thing in the world is the inability of the human mind to correlate all its contents.
H. P. Lovecraft
Ubuntu Hardy Heron

Today I installed Ubuntu Hardy Heron on a desktop computer. I am pretty distro/desktop agnostic (see my ten year anniversary post), but since Debian Etch is a bit old for a desktop and Hardy Heron has Long Term Support (I do not want to update/fix a computer every half year!!) Ubuntu was my choice.

There are unlimited gnome improvements which I don't care about, but some things stand out for me in this release.

screenshot,background Leiden (by Jochem)

So thanks again for all free software developers!

-- Filed under:

Posted by jochem on 20th April 2008, last update on 22nd April 2008
Helping the environment

A lot of work is done in making linux suspend work better. For me it works perfect (from linux kernel 2.6.20 or so). Therefore I wanted to go a step further and let my class A, heavy power-using receiver switch off when my desktop computer suspends (to ram). And switch back on when my computer wakes up. The motivation is that I only listen music via my computer.

To achieve this I bought the Gembird Silver Shield, a USB-switchable power adapter. I was prepared to do some nice USB snooping and C programming to get this device working in linux, but (un)fortunately there was already a working utility for this device.

Configuration for suspend/hibernate is not so easy and documentation is sparse for the user mode utilities. Since it took me more than the usual googling I will summarize my conclusions here for later use. First the gnome-screensaver measures the idle time. After this timeout is expired the gnome-power-manager starts to measure his own timeout (so before suspend the two times will stack). When the gnome-power-manager times out it will look at the Inhibit flag. If there is no inhibiting (for example my rhythmbox pushes Inhibiting, because I do not want to suspend when music is playing) your computer will suspend.

Since a custom script should be added to switch the power-switch off via usb with sispmctl the suspend-backend is important. Gnome power manager can use multiple backends to go to suspend mode. This works via hal (the hardware abstraction layer). Configuration for this is in /usr/share/hal/information. HAL is responsible for calling the suspend-backend. The default suspend-backend on my machine is pm-utils. (which can be tested with pm-(suspend/hibernate/power-save etc.). I also have a package called hibernate (which can also suspend, confusing isnt' it?). A third one is suspend2 (which can also hibernate....). These backends have different ways of adding custom hooks.

To add a hook to hibernate I added a file called local in /etc/hibernate/scriptlets.d/. The API is as follows (ugly in my book): 

# -*- sh -*-

UsbPowerSocketDown() {
      /usr/bin/sispmctl -f1
}
UsbPowerSocketUp() {
      /usr/bin/sispmctl -o1
}

AddUsbOptions() {
      AddSuspendHook 10 UsbPowerSocketDown
      AddResumeHook 10 UsbPowerSocketUp
      return 0
}

AddUsbOptions

Pm-utils has a much nicer API. To add a custom hook add a file to /etc/pm/sleep.d . This uses init style ordering. So look in /usr/lib/pm-utils/sleep.d/ for a proper number. I needed to talk to the usb-bus AFTER the modules were loaded, so a number lower than 50. So I added /etc/pm/sleep.d/10usbpoweroptions with content like this: 

#!/bin/bash
case $1 in
    suspend)
        /usr/bin/sispmctl -f1 
    ;;
    resume)
        sleep 1
        /usr/bin/sispmctl -o1 
    ;;
esac

After all this fiddling it works like a charm! Now hopefully one standard will emerge; because how to achieve the same result with KDE I don't know. I had to manually patch rhythmbox to change calling (via dbus) the Inhibit method from org.gnome.powermanager to org.freedesktop.powermanagement (because i used a wrong combination of versions..), so this suggests a move in the right direction.

-- Filed under:

Posted by jochem on 2nd February 2008, last update on 3rd February 2008
Qemu/kvm and xorg screen resolution

Fast virtualization is cheap nowadays on linux. Just apt-get install kvm on a recent kernel and VT-enabled processor and you are ready to run all kind of different os-es on your host. No more recompiling the vmware kernel modules *again* or fiddling with xen-modified kernels and difficult networking setups. Yeah!

One problem I encountered was getting a decent resolution (f.g. 1280x1024 or higher) in the guest xserver (xorg). Google was not really helpful this time so therefore I post this note for future reference. Qemu emulates two kind of video cards, standard is a cirrus, -std-vga provides you with a vesa one. Vesa was not able to help me (garbled screen), so using the (default) cirrus emulator is the way to go for a linux guest.

The trick was in changing the monitor sync and refresh rates, autodetection did not work properly (in my centos 4.0 guest). So here is my working snippet of /etc/X11/xorg.conf: 

Section "Device"
  Identifier  "Generic Video Card"
  Driver      "cirrus"
EndSection

Section "Monitor"
  Identifier  "Generic Monitor"
  Option    "DPMS"
  HorizSync 28-64
  VertRefresh 43-60
EndSection

-- Filed under:

Posted by jochem on 1st October 2007, last update on 1st October 2007
10 years GNU/Linux

I am using GNU/Linux for 10 years! As a celebration I made a white chocolate cake (recept) with tux on it. Thanks to all the volunteers for this great combination of free software. In the past I have used all major distributions, nowadays I am stuck with Debian. In fact I am rather distro-agnostic, if it runs xterm, screen, vim, mplayer, gcc and mutt I am happy. Pro is the nice Debian philosophy, con the fact that is has not incorporated SElinux yet. So perhaps I will switch in the next 10 years again?

Sidenote for R. Stallman: when i am using gnu/linux 25 years I promise to make a gnu cake :-D.

-- Filed under:

Posted by jochem on 16th September 2007, last update on 16th September 2007
Alsa versus OSS

Last week I read a thread on the mplayer-dev mailinglist. It was about setting the default sound output from Alsa to OSS. It is now OSS for a default compile of the tarball. However OSS is deprecated in linux AND in almost all distributions that ship mplayer (my favorite media player) set the default output to Alsa.

Most in charge mplayer developers are pro OSS and do not want to switch. One of the arguments is that OSS is now GPL and is used other unices as well . There are also arguments about library vs. unix semantics. Alsa has an OSS compatibility mode (actually two, one in-kernel and one in-library). However using this blocks soft-mixing. This means that another program playing sounds can not do this while using default mplayer compile.

Both sides have some good arguments (i truly understand the points for OSS!, it is just not realistic), but discussing them in this context is useless and the way it is done on this mailing-list is very childish and out of reality. Mplayer should set Alsa as default output for linux, because 1) all major distributions do this and do this with good reason: 2) OSS in linux is deprecated. Reading this thread made me feel tired of (the immaturity of) the open source scene.

But today I am a happy guy again. Some troll suggested removing Alsa from the linux kernel and I was afraid of another useless thread. However I found a message from Takashi (one of Alsa's most productive driver and patchwriters:

Honestly, I'm not fully against changing the current code base (or crap, whatever, any childish name). There are indeed many misdesigns. But, replacing with the above is no option, IMO. The OSS have also many misdesigns, so the same argument would start again. One should learn something from history...

Anyway, if it's going to be more constructive, I'm willing to join in.

Takashi

Hannu (the main OSS developer) then said this:

We have no intention to push OSS back to the kernel or to replace ALSA. That alternative is not realistic any more. In addition OSS is a cross-platform product and staying more or less outside various kernel trees should provide better flexibility.

What we would like to push is that the old "deprecated" OSS/Free are removed from the kernel. OSS/Free is based on about years old OSS API version which was too limited for many applications. Having OSS/Free in the kernel doesn't serve any purpose.

Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are rather different. Both of them have some good points and bad points. For ordinary users it doesn't matter which API is used by the applications as long as they work. Just the application developers can see the real difference. Some of them prefer OSS while some other prefer ALSA and this should be their "freedom of choice".

I think the ideal solution would be that both ALSA and OSS APIs can co-exist by sharing the same low level drivers (which has already been demonstrated). The low level driver interfaces in both systems are practically identical. This means that ALSA's core can work with OSS' drivers and vice versa.

Today both OSS and ALSA teams have to spend significant amounts of time in emulating the "alien" APIs. Making OSS and ALSA to co-exist will require some work in both sides but that should be nothing when compared to the effort required for emulation.

Just my 2 cents.

Best regards, Hannu

Fortunately there are still a lot of sane people in the community. Thanks!

-- Filed under:

Posted by jochem on 28th June 2007, last update on 28th June 2007

<- older entries