You are here

February 2007

Buildd.Net: version 0.96 of released

I've been using Debian for about 10 years now. Debian was my first Linux distribution. For about 7 years I've been running a Debian m68k buildd now. For some time now I've been worrying about Debian and its future.
IMHO, there are several reasons to worry about its future.
a) Release cycles.
Funny enough Martin Michlmayr wrote today about Gnome release cycles. Apparently Gnome suffered from similar problems in Gnome 1.x times as Debian still does today. The big difference between Gnome and Debian is: Gnome has actually learned from its mistakes and changed its release model to something better. Really. I don't use "better" very often in conjunction with "Gnome", but in this regard, the Gnome project did really something good.
Debian, on the other hand, suffers more and more from its "release everything for all when it's ready" syndrome. Releases are always delayed, it's a big chunk of work for everyone involved, Debian is losing users because of the delays and so on...
b) Debian as a base for other distributions.
Lately, several distributions announced, that they will use Ubuntu as a base for their own distribution and not Debian any longer.
c) Internal problems.
Debian has many internal problems. Many of them have to do with communication problems. Others with "you can't force anyone to do anything in Debian" ideology. Some with unresponsive persons in key positions. Some problems are a mixture of all the above. Altogether, these problems are causing that many developers are losing their fun in the long run.
d) Flame wars.
Well, actually this could be listed in b) Internel problems as well, but it's a massive problem of itself, so I think it deserves its own section. Flame wars are really time consuming and destructive. I know what I say. Been there, done that.
e) Getting new people in.
It is often said, that there are >1000 Debian Developers. The truth is that many of them are inactive or MIA. There was a proposal lately to find those inactive DDs and handle them accordingly. Given this fact of many, many inactive DDs means, that there is more work for those left. To solve this problem of overworked DDs (it's another truth, that some DDs are very active and have far too many jobs within Debian), Debian needs to attract more people and encourage people to contribute. Currently, it's not that easy for people to contribute, because of bureaucratic formalisms like sponsored uploads and such. Additionally, not everyone willing to help wants to do packaging or other tasks. There is a lot of other work to do like making graphics, organizing booths or other events, etc. Currently those tasks are mostly done by DDs that could better spent their time on developing Debian itself (packaging, porting, ...).

Ok, enough for now. But how can those problems be solved?
ad a)
Martin mentioned in his post about the Gnome Release management, that they changed from "release when it's ready" to time based releases and gained credibility because of this.
I think, Debian would benefit as well from this type of release management. Additionally, every Developer can react to this new method and make his packages fit for the release because he knows "Hey! Just 4 weeks until the release! Let's get my packages ready for it!"
Another problem, IMHO, is the "release all packages for all archs at one time" problem. This lead to the drop of m68k for etch (via some obscure circumstances like a very broken gcc 4.0 version and some strange release criteria, sometimes referenced as Vancouver Massacre).
Someone of the contestants for the new DPL job mentioned in his world domination plan to have a stable release of some basic components every year and having sub-releases for desktop environments (KDE, Gnome, XFCE...) every 6 months. Basically I believe that this is the way to go. You can discuss the time frames, of course. Release a stable base every year or every 2 years? But really, I think this would be the best way to deal with many problems Debian has.
If every 1-2 years a new stable base would be released, everyone could be happy: the admins with long release cycles for their servers, the users with faster releases for their desktops and (maybe) the porters who can (maybe) omit a subrelease of the desktop apps and concentrate on porting the base system if needed. Really. 15000 packages for (let's say) 15 archs is way too much work for everyone.

ad b)
With the above mentioned changes, Debian could re-gain some more market share and users from other distributions like Ubuntu - and be a base for distributions again. The reputation of Debian would rise again, because the releases wouldn't be delayed again.
I think it would be ok for smaller ports (like m68k) to release differently than the main archs (i386, amd64, ppc, arm): if every year a new stable base release would be done, it could be ok for them to skip a release, if necessary. Of course, details must be elaborated more in detail.

ad c)
There are many internal problems. The most urgent one is "bad communication". Needless to say that it's very important to communicate with your work mates to get your work done. If someone fails basic communication skills (answering questions about the stuff s/he is responsible for) in a reasonable time frame, s/he's simply the wrong person in that position and should be replaced. Of course this interfere with the current understanding of "not being able to be forced to do things" in Debian. People should change their mind about that.
Basically, it's similar to NMUs: if a package maintainer fails to fulfill his responsibilities (fixing bugs), he can either be enforced to fix the problem in that package by a bugreport or he can somewhat be replaced by doing a NMU when he's not fulfilling his duties. If he fails often to get his package into a good shape, he can be replaced permanently by hijacking the package.
Or to give a real world example: If you are holding a honorary post, let's say, you're doing the financial paper work for your soccer club, you can't say "Oh no... I don't have the time to do the tax declaration now or the next month...". That just doesn't work. Either you do your duties on time or you need to step down from that post. Otherwise you would do damage to your club. This is valid for other volunteer organisations as well, like Debian. Do your duties on time or step down from your post.

ad d)
Well, I'm not innocent when speaking about flame wars. Anyway, people can learn and change their mind. Flame wars are really bad in Debian, but it seems to be something like a sport to me sometimes. And usually it needs two parties for a flame war. That's the reason why I believe that expelling a fellow DD because they were involved in some major flame wars in the past is simply wrong. Either expel all parties or none.
A party is not only involved when answering to mails on mailing lists, but also when doing stuff that forces the other party to react - for example by starting a flame war on a mailing list. There's always action and always reaction. Therefore you can't disjoin both and just judge upon one party.
When a mediation is tempted, both parties are required to obey the mediators decision. Of course there should be a fair decision that honors both sides. Both sides have to give in for a successful mediation attempt. If that's not the case, the mediator failed. Not obeying to the mediators decision, because "no-one can be forced to do anything in Debian" (see above), is plainly wrong.
Anyway, most people should know of what I'm speaking here. I think it's plainly wrong to expel developers that have done really great work in the past due to some flame wars. Debian as a community has failed when it chooses this ultima ratio. Debian just proves that it is unable to establish a community where people can work together, when developers are going to get expelled because they thing that a mischief was done to him.
How would you feel and react when someone would play bad games on you? Wouldn't you yell loudly as well?
So, how can something like this be avoided? Maybe a Code of Conduct could help, maybe that CoC wouldn't be necessary when everyone would be nice to anyone and remember that there's a human being each mail with feelings and emotions?
Anyway, Debian needs to abandon flame wars in general.

ad e)
Well, I've already written a little bit about this problem above. There are many tasks in Debian that doesn't need technical excellence of packaging details - instead it needs excellence in social skills. Something that many technically focussed people are missing. Debian needs to become more attractive to those kind of people that are good at this non-technical issues and encourage them to join the project - and not to frighten them away by a very technical and bureaucratic procedure like the current NM process. Those kind of people won't wait some years to be actually being able to do work. They will just go on and find a place where their skills are better welcomed.

Ok, that's for now, I think... it's been a long post and therefore I've used folding for it.

Well, not a nice one. Debian needs big changes in its structure and the candidates for the upcoming DPL elections identified some of them and put them on their agenda for their DPL period (if they win, of course). But the history showed that none of the past DPLs had really the power or the will to push big changes and made hard decisions. So, after all everything will stay as it is now. Nothing will change for the better, I fear. Users will leave Debian because of its stale release cycles, more and more Debian-based distributions will change their base to Ubuntu and Debian will become more and more irrelevant over time instead of being a strong participant in the free software world.


Eisregen in Rostock

Although the changes have been done in September, I finally uploaded the new version today.

# - fixed a bug in recognition of running buildd processes
# - fixed a bug in N-D-P detection

You can find the updated version at


Wireless Bridge Linksys WET54G

Heute morgen gab es Eisregen in Rostock. Auto freikratzen war nicht möglich, da die Eisschicht einfach zu dick war. Also was bleibt einem anderes übrig, als das zu tun, was man eigentlich nicht tun sollte: Motor laufen lassen und abwarten. Nach 10 Minuten war der Wagen dann ausreichend warm, daß man mit dem Eiskratzer nachhelfen konnte.

Auch die Fahrt zur Arbeit (das nächste Mal, wenn der 23.02. auf einen Wochentag fällt, nehme ich mir jedenfalls einen Tag Urlaub) war dann etwas geruhsamer als an anderen Tagen: statt mit 80 über die Stadtautobahn zu fahren, waren eher so 60-70 drin. Das eigentliche Problem waren aber die Nebenstraßen in der Stadt.

Da sind mir zugeschneite Straßen ehrlich gesagt viel lieber... :-)


Blog migration finished

Ok, for some time now, I've been using my old Samsung Vm8100KXDT Laptop to connect my wired network to my Linksys WRT54GS router, which resides on another floor.

Well, if you read my old Drupal blog, you may have noticed, that I complained several times about my Netgear WG311T PCI card, being not able to be run in my PowerPCs. That's the reason why my Laptop was acting as a wired/wireless bridge (or more exactly a router between both worlds).

Today I bought a Linksys WET54G wireless bridge to replace my Laptop for that purpose. My Laptop was just too noisy and too power consuming and - even worse - the harddisk began to die. It was giving loud *klackklack* noises from time to time, resulting in a loss of DMA and therefore needed a power cycle afterwards.

Anyway, the WET54G is a nice small box with one antenna and one ethernet port. It is advertised as being a operating system independent device - which is clearly not true. You'll need a Windows PC to configure the device and it's quite awful to configure.

Instead of accessing the WET54G bei http, the CD-Rom contains a small program that scans the ethernet for that device. Next problem will arise when you want to configure your WLAN/WiFi settings. It is pre-configured to use channel 6 and infrastructure mode. Unfortunately, you'll need to first configure infrastructure or ad-hoc mode before you proceed to configure your ESSID, channel and b/g/mixed mode settings. Even worse because you can't change the channel or the mode when you have chosen infrastructure mode.

So in order to change your channel, you'll need to configure it in ad-hoc mode first, then change your channel and mode first, safe your settings, let the device reboot and continue with configuring infrastructure mode again.
Really badly tested piece of software, Linksys!

But beside of this huge annoyance the WET54G works quite nice once setup properly. Alas, I can't recommend it to buy for the above reasons.

After configuring it the first time, there actually is a webinterface, where you can configure the device with your favorite free OS. However, it was not accessible the first time to me, although I configured a Laptop to use the described default network in the manual. The above mentioned problems of not being able to configure the channel in infrastructure mode still exists in the webinterface.


Buildd.Net: new arm subarch added - armel

On this weekend, I finalized my blog migration from Drupal to Serendipity.

I was somewhat surprised that my latest blog entry in Drupal gathered that much attention. It was the most read article on my (old) blog, mainly because it was featured by someone on the Drupal talk site.

Anyway, my old blog is now available at whereas the new blog is at Thanks to Alexander Wirt for updating my links on planet.d.o!


First new entry

Aurelien Jarno asked me to add another arm port to Buildd.Net, namely armel - a new ABI version for newer little endian based arm boxes. Read more about that new arch in the Debian Wiki.

Anyway, here it is: armel page on Buildd.Net - have fun!


Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer