2011-12-13 01:48:00

The destructive desktop — Linux in trouble?

Linux on the desktop has come a long way. The Gnome and KDE communities have built themselves a big, very powerful set of tools to build on. And using these tools, they created an enormous amount of software for a large number of different purposes.

Then they discovered that there is a lack of formality in the RPC mechanisms available under UNIX like operating systems. The Shared Memory IPC provides just shared memory and a little flow control, which is tedious. The sysvmsg API is still very inconvenient when communicating between various different processes, especially if they're arbitrary. Sockets work much better in that respect and have a well-defined API, but it is still relatively hard to exchange data over them.

UNIX offered the SUN RPC API which was used to implement NFS, among other things. However, it was ”just“ an RPC implementation and not a real service based middleware. Especially among Universities, a rather complex method of doing RPC had become fashionable: CORBA.

At this time, the only available Open Soure CORBA ORB was Mico. However, Mico still lacked some of the desired features and didn't support a lot of programming languages so the Gnome developers decided to implement their own ORB called ORBit.

The KDE people faced a very similar issue. However, instead of implementing all of CORBA, they developed a much smaller, more lightweight protocol called DCOP. DCOP was more tailored to be used for communicating between the different applications.

So the Gnome developers wanted to reduce the complexity of their protocol as well and started working on a protocol which was supposed to join the advantages of DCOP and CORBA. The result was called the Desktop Bus (dbus) protocol. Instead of complete remote objects it just offers remote interfaces with functions that can be called.

esd and PulseAudio

The sound system underwent a similar development. Initially, the operating system provided an API called the Open Sound System. It is based on a read-write device in /dev and a number of IOCTLs. It was the same API which is found in the BSD and Solaris operating system.

However, the Linux incarnation of OSS was a particularly simplicistic one which only supported one sound channel at the same time and only very rudimentary mixing. As a workaround, the community came up with a daemon which accepted sound samples and mixed them in software: the Enlightened Sound Daemon (esound). This daemon even acquired network capabilities so people could stream whatever they wanted over the network to other computers and play it there without having to resort to systems like the Networked Audio System (NAS). The KDE developers went even further and implemented an audio system on top of DCOP called MCOP.

Over time, the Linux kernel developers came up with a new API to control the various details of the sound card, have many different volume settings and to be able to mix in hardware. It was called the Advanced Linux Sound Architecture (ALSA).

Then, Gnome and KDE developed APIs to abstract the uses of OSS, esound and ALSA: gstreamer for Gnome and Phonon for KDE. Since gstreamer depended heavily on the Gnome libs and phonon on the KDE libraries, the rest of the community had to either adopt or try to keep up with the ever changing sound backends. Esound was deprecated and replaced with Pulseaudio, which triggered yet another shift of APIs.

Over time, more and more subsystems started getting DBus based frontends. hald was added to detect hardware properties. It turned into an official dependency for X.Org and was subsequently replaced with DeviceKit. PackageKit was added as a generic API to instruct the system to find and install packages through a DBus interface. ConsoleKit replaced the regular session and pseudoterminal management environment. PolicyKit imposed additional restrictions on system calls and allowed other people to do privileged operations without changing to the superuser explicitly. sssd is now in the process of replacing PAM as an authentication framework which is also contacted through DBus, without the need to use the system authentication and session management API (PAM and NSS, mostly).

NetworkManager added a new abstract way to configure network devices, such as network cards, wireless LAN or 3G. Like everything else, it provides a DBus interface for executing various operations, such as discovering wireless LANs, connecting to a network and awareness if the computer is currently connected to a network. Various GUI programs such as Firefox, Pidgin, Gajim and similar tools use NetworkManager to clean up their caches and reconnect after the network connection was terminated. They also go to some sort of offline mode if NetworkManager tells them to, in which they don't attempt to connect to the network and try to do whatever you want locally (e.g. queuing messages to be sent, displaying web pages from cache, etc.)

Another addition was systemd, which now replaces System V init and all other types of init derivates on various distributions. It is an init daemon which reads services from a database, somewhat like Solaris' svcadm. However, for starting and stopping services and telling the system to shut down or do something else, systemd has a DBus interface. The old /dev/initctl interface is no longer supported.

And most recently, there was a new addition to the pool: Journal is a service which replaces syslog and which exposes a DBus API for logging messages into a binary log (instead of a plain text log like syslog did). The adoption rate among desktop and other programs is great because now finally everybody can use their favorite API to log, grant log permissions, search logs etc. The world is becoming more awesome every single day.

Or did it? RedHat Enterprise Linux (RHEL) is a Linux distribution tailored for long-term support environments — which includes corporate desktops — and servers. Ubuntu LTS is following the same goal: to provide a modern distribution with long-term support for use in corporate workstations and servers.


The latest versions of both Ubuntu LTS and RHEL ship with NetworkManager for managing their network connectivity. If you don't use NetworkManager, a number of programs will refuse to connect to the Internet or behave in various weird ways. More so, a lot of system services now depend on NetworkManager and won't start unless it is running. And if you run NetworkManager, it starts periodically messing up any local system configuration. So you're basically bound to use NetworkManager.

So you install a server in headless mode (Wait, the installer won't typically let you do that anymore. But let's assume you do it nonetheless because your server doesn't have a graphics card anyway, it's attached to a Cyclades SSH serial port adapter like any other one of your UNIX servers.) Then you try to figure out how to configure NetworkManager from the command line. There's no tool in the entire distribution which lets you do that.

So from some time in the past you remember that you used to use a program called cnetworkmanager to operate NetworkManager from the command line. You install it and — the DBus API changed since the program was written, so the DBus call fails with a not-very-helpful error message.

So the only way to actually use NetworkManager is to use nm-applet, an X11 system tray application. You install your i3, you install your stalonetray and you start nm-applet — hey, it works! Now you can finally connect to the network. And if you wonder how you were supposed to install these packages without network access: by periodically calling ifconfig and ip route add until you finally managed to fetch all the data before NetworkManager would mess it up again.

So you have a bit of a more complex network configuration and need to add routes or, even better, use OSPF to find routes to some targets which don't go straight via some default gateway. (Why? Perhaps because you wanted to run Linux on your default gateway.) Fire up Quagga and you will see how Quagga struggles to add routes while NetworkManager struggles to remove them again. Part of your packets make it to their destination. Also keep in mind that you're now running X11 and a network management GUI on your router!

Now to your road warrior laptop. For simplicity sake and because you already exchanged SSH keys anyway, you decide to connect to your company via SSH-based VPNs. If you do that from the command line, NetworkManager gets very angry with you and does stupid things to ensure you can't put your default route over the new VPN device, or even use it at all.

So you have to use NetworkManager, which only supports vpnc and OpenVPN. However, Open Source vpnc servers are pretty much nonexistent and OpenVPN requires you to either set up a complete PKI or live with ridiculous preshared key algorithms. tinc supports simple public/private key algorithms, but it is not supported by NetworkManager. So the only way to make VPN work is to migrate to OpenVPN and to maintain your own PKI.


There are many more such effects with the new interfaces but these examples should suffice for now.

The effect of all those changes are numerous. For one, it is no longer possible to run the system without a graphical user interface unless you plan to invest a huge amount of work and to throw out most of your system support. If you want to get vendor support, this is not the way you will want to go.

You also can't implement complex network or authentication setups anymore. The number of possible combinations in the configuration has been significantly reduced by removing options which are not typically used for desktop systems. Also, since the APIs have a tendency to change very frequently, typically, only genuine supported Gnome or Ubuntu/Fedora software tends to work on the long run. If you try to use an alternative which has an user interface you prefer or has a feature you want, you will find very frequently that it is trying to call some DBus interface which is no longer implemented or has a different set of parameters.

Even worse is if you try to use any window manager that is not KDE or Gnome. Both KDE and Gnome launch a very large amount of daemons which are required by a number of applications — pulseaudio, an user dbus session (in addition to the system dbus instance), gnome-settings-daemon, etc. pp. Many programs also require support from applications which exist as tray icons, so you need to find an application to emulate the Gnome tray — and not all of them do it correctly.

Also, many of the advanced features like suspending the laptop when closing the lid or other ACPI events are no longer implemented as shell scripts in /etc, but have moved to be DBus APIs implemented by Gnome and KDE. The reason is that it becomes much easier to display things on the screen, but it also means that the /etc scripting API is rotting away and will not work on the long run. So if you want your laptop to suspend when you close the lid, your window manager must implement it.

Even worse, some of the applications don't react very well under window managers which are not KDE and Gnome because they don't implement the original X11 protocol directly and rely on so-called window manager hints.

Debugging DBus based systems

Which brings us to debugging. Even if your API uses DBus, it is not necessarily bug free. So under DBus based systems, you will sometimes see very weird interactions which seem to come out of nowhere, and it is absolutely not clear to you what happened.

You can use dbus-monitor to get an idea of what is going on on the DBus, but if you have some weird interaction you typically have no clue what the name of the DBus call you're looking for may be, so you start dbus-monitor without any filters only to discover that there is a huge amount of traffic, some of which is log messages.

So you try to read it from the logs but they are binary in some format Journal is writing…

This makes the system appear very opaque to everybody who's trying to take a serious look at it and fix problems. The result is that even people like me start going for solutions like ”Restart the application“ or ”Delete the configs“, because debugging a problem becomes extremely time consuming and the interactions between the different applications are no longer well-defined and obvious. This was one of the very basic design principles of UNIX.

Effects on other operating systems

A very common reaction when people hear that the Linux distributors are doing something crazy is to say, ”Who cares, I'll just use my NetBSD/FreeBSD so this won't affect me“. This, however, is only partially true.

The problem is that even users of FreeBSD and NetBSD want to use some of the software which was implemented for one of the desktop environments will have to find ways to make the DBus services work and react in the correct way. Jared McNeill attempted this with the NetBSD port of DeviceKit, but most operating systems aren't designed to support the kind of APIs involved. As a result, it becomes extremely difficult to support such software, and makes all operating systems more like Linux if they want to be able to run this type of software.

This is the exact opposite of the design principles of standards like POSIX and the Single UNIX specification. These specifications set a common high-level ground for all operating system interfaces, but leave the implementation details up to the systems. In order to honor the thought put into these design principles, the system shouldn't depend on anything other than a C API either so the implementation details are entirely up to the implementor.

More than that, this again affects choice and diversity. One of the biggest arguments the Linux community has brought up for migration from Linux was diversity, but right now, Linux implementors are competely ignoring this plea of their own. Instead, they come up with, well, ”proprietary“ Open Source software which locks people to use Linux and Gnome/KDE.

And this change in design principles is something which should be changed very soon. The current tendency towards DBus interfaces is actively harming the more proficient users in the various ways they made for themselves. Linux and UNIX have always been about the ease of customization. Gnome and KDE are both based on the idea that this only confuses the first-time users and should not be offered, which is fine. However, these window managers are now forcing themselves onto the users, and limiting the user's choice of operating system to just one. This is harmful and obliterates most of the advantages UNIX and Linux systems have given us.

So if you believe in the principles behind UNIX and Open Source, please don't write software which requires any of the Gnome/KDE and DBus API. Writing X11 programs with xcb and proper RPC APIs like SUNRPC or Thrift should be more than good enough. So, please support choice and freedom by implementing programs the right way instead of the Linux/Gnome/DBus way.

Flattr this

2011-08-15 01:23:47

Frustration with the Thecus N5200

After a recommendation from a friend, I recently bought myself a Thecus N5200 NAS for home use, to replace the sluggishly slow Netgear ReadyNAS. Along with it, I bought 5 2TB hard disks, which should be enough to give me 6TB or more of storage on my home directories.

So I installed the hard disks and booted it up. I created a big RAID 6 volume over all disks and then realized that it wasn't helping a lot because, while there was a menu option to enable NFS support in the first place, there was none whatsoever to export my new file system via NFS. Also, showmount confirmed that it wasn't exported.

Follow the manual

As I couldn't find anything in the online help or the user manual about exporting file systems to NFS, I found Thecus N5200 Debian on the Chaoswiki and tried to follow the procedure outlined there. However, it turned out that my NAS was running a much more recent version of the Thecus supplied Linux distribution and couldn't install any of the mentioned packages. Also, Thecus itself doesn't seem to offer any SSH server.

Do It Yourself, maybe?

So since the whole thing is just an i386 which runs Linux I decided to try and go in to fix things up myself. I installed Debian onto an SD card and tried in kvm whether it boots up fine and configures the system. Then I got myself an adapter from PC Engines to mount the SD card into the Thecus NAS and tried to boot it up.

Well, so much for the theory. The system did something but there was no output on any of the two serial consoles, ever. Not even the firmware of the box write anything anywhere. The system is really hard to interact with. And while, in qemu, I get a serial console, it didn't work at all in the Thecus.

And while the network card was configured and the firmware installed, nothing moved on that front either. According to Running Debian on Thecus n5200 on wpkg, the only way to tell what the NAS is doing seems to be to solder a VGA adapter onto the mainboard and attach a monitor.

Picking up the pieces

So to summarize, so far I wasted more than CHF 1'000.- and 10 TB of space. All I got in return is a brick which sits on the ground and can only share files with Windows boxes. Yes, I know, most systems can mount SMB shares, but that's really not an option.

So I really wonder where this is going. What I'd love is a tiny box with space for 5 hard disks which can at least do 1 Gbit/s and can be integrated easily with my LDAP and Kerberos setup. In my world, this shouldn't be too much to ask.

However, instead of this, vendors seem to throw very expensive closed systems at us which attempt to prevent us to customize them or to really interact with them in any way which the vendor wasn't planning for. I don't see the reason though.

What's the loss for Thecus if I can easily install my own operating system, like I can with my ALIX? They aren't losing any money form this or anything. What's the cost of making everything output to the existing serial port? It's not like this is expensive to implement or anything. And the operating system used in the box suppports it just as well.

So far I'm getting the feeling that I just found a new brick I can use as a door stopper. But I guess I'll try to do some more stuff with it before I loot the hard disks. Perhaps I should buy a regular Mini-ITX PC and use that.

Posted by Tonnerre Lombard | Permanent link | File under: broken, hardware

2010-09-01 02:33:57

The Debian Installation of Doom

For tonight I set myself a rather trivial task: install Debian on a remote server which I can only netboot grml on, and where I have no console access. I figured it wouldn't be too difficult. However, Debian figured that it would be best to throw any possible obstacle my way.

I booted into grml, set up the partitions and file systems (/dev/md0 as /boot, /dev/md1 with lvm and the root file system). Then I mounted them in place and ran debootstrap. However, debootstrap said the configuration phase of the packages failed. So I chrooted into the system and ran dpkg --configure -a.

Then, I figured that Debian prefers to leave the most important programs uninstalled, so I ran apt-get install less bzip2 pax openssh-server sysklogd grub-pc linux-image-2.6.32-5-amd64. However, grub-pc decided it doesn't want to install itself successfully. A manual run of grub-install fixed this glitch as well. Then I set up a root password, enabled root logins for now in the ssh configuration and configured /etc/fstab and /etc/network/interfaces. I added a netconsole to the grub configuration, just in case.

Then I figured it was time to test the system, so I rebooted. However, I never saw the system come up. Also, the netconsole didn't log a thing. So I booted back into grml, installed kvm and tried to boot the system, only to find grub saying:

error while parsing number

So I fixed the device paths and re-ran update-grub2. Then the system booted but still didn't respond to ping, and had nothing on the netconsole. So I booted grml and saw that there was finally at least a dmesg.0 file. This file contained a number of hints:

netconsole: eth0 doesn't exist, aborting.
e100: eth0: e100_request_firmware: Failed to load firmware "e100/dm101m_ucode.bin"

So I figured that apparently the Debianists no longer ship firmwares anymore. I found a package called linux-firmware in the non-free repository and installed it. Then I rebooted and received ping replies from the system, but ssh never came up, the connection remained refused. So I booted into grml and found all logs in the chroot to be empty:

grml# ls -l  
-rw-r----- 1 root adm 0 Aug 31 23:20 /mnt/vms-planck--root/var/log/messages
-rw-r----- 1 root adm 0 Aug 31 23:20 /mnt/vms-planck--root/var/log/syslog
-rw-r----- 1 root adm 0 Aug 31 23:20 /mnt/vms-planck--root/var/log/daemon.log

So I installed Dropbear and configured it to listen to port 2222, then rebooted. The system pinged, but ports 22 and 2222 remained refused. When running the system in kvm again, I discovered strange messsages though and found the root cause to be a popular debootstrap bug:

grml# cat /sbin/start-stop-daemon
echo "Warning: Fake start-stop-daemon called, doing nothing"

So I moved /sbin/start-stop-daemon.REAL back to /sbin/start-stop-daemon, but instead of typing reboot I accidentally typed poweroff, and now I have to wait for the hoster to flip the power switch of the server again before I can continue, so things will remain interesting.

I guess being bitten by debootstrap, defaults, grub, netconsole, firmware and start-stop-daemon on the same day was a bit too much. Time to watch V for Vendetta and go to bed.

Update: Note to those who didn't realize: no, I didn't watch the film, I just found it fitting.

Posted by Tonnerre Lombard | Permanent link | File under: broken, free_software

2010-07-18 16:27:43

Quotes from the people who brought you PHP

Thorsten Glaser from Tarent added a number of nice quotes from PHP developer Rasmus Lerdorf to the PHP source code of Evolvisforge, the gforge clone of his company:

I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.


I was really, really bad at writing parsers. I still am really bad at writing parsers.


I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I'll just restart apache every 10 requests.


We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all.


I think people like Rasmus explain a lot about the poor design and the many implementation flaws of the PHP programming language.

Thanks as well to Benny Siegert who provided the quotes.

Posted by Tonnerre Lombard | Permanent link | File under: programming, broken

2010-06-12 07:44:11

Cassandra in pkgsrc

During this second quarter of 2010, I added a number of Cassandra related packages to the pkgsrc package collection. They will appear in the next quarterly branches. The following packages have been added:

  • databases/apache-cassandra: Highly scalable, distributed structured key-value store
  • databases/libcassandra: C++ interface to Cassandra
  • databases/p5-Net-Cassandra: Perl5 module for accessing the Cassandra database
  • databases/py-cassa: Python client library for Cassandra
  • databases/ruby-activerecord-cassandra: ActiveRecord Cassandra adapter
  • databases/ruby-cassandra: Ruby extension for Cassandra

Apache Cassandra is a next generation, No-SQL, non-relational distributed database. Unlike SQL databases, it behaves more like a key-value store and can store nested data structures. Cassandra is already in use by a number of large web sites, and has clients for a number of programming languages, like the ones mentioned above.

Posted by Tonnerre Lombard | Permanent link | File under: programming, free_software