the debian user

Debian developer Kenshi Muto backported the latest 2.6.30 kernel plus firmware for Lenny. So if you have to deal with newer hardware and need the latest kernel, read his blog about it. You can also download the installer images from a French mirror, which could be faster because of better bandwidth. Thanks, Kenshi!

Heise Open Source and the H Open have news about a new benchmark for Linux desktops. You can read them in German or in English. I will have a look at them, and at the Phoronix Test Suite. We should make those a standard when comparing hard- and software IMHO. Thanks guys!

First off: this is no ad, nor a bying recommendation. In fact, I couldn’t really recommend this card. Not for Unix/Linux, and even more so not for Windows.

Why? Or, rather, why not?

Well, to make it short: the card actually does run under Linux. It has a Broadcom 4318 chip set, so with the usual “aptitude install b43-fwcutter” you can download the latest (proprietary) firmware, cut out the relevant parts, and store this in /lib/firmware; all more or less automagically, like we are used to it.

And then the card will start. And give you headaches.

First, (re-) authentication with an access point is flaky, to say the least. Sometimes these cards won’t associate at all, even when less than 2-3 feet away from your AP (tested with a Fritz!Box 7170 and a Linksys WRT-54g with OpenWrt).

Second, with a ping check to your AP, it will give you something between 5% and 25% of dropped packets, some also reported duplicates.

But there’s help.

Read  Linux Wireless about the b43 and b43legacy. And read the bcm43xx-dev mailing list archive. Browse April 2008, or go directly to Stefaniks entry, who explains the SPROM chip, and how Asus managed to get this one wrong.

You’ll need git, and at least build-essential, and then you can improve the performance of these cards. Mine (on 64 bit Asus/Nvidia hardware) went from 25% dropped packets to something like <5%; Mitchie’s (on 32 bit Intel) from something like 6% to 3% or so. Still not perfect, but lots better, especially the authentication issues.

Thanks, kernel & driver hackers - you guys are awesome.

And what are these cards good for? Well, if you don’t like hardware hacking and tweaking, then there’s still the fact that these come with both a normal and a low profile bracket, and they also do a great job listening, e.g. with kismet and the like.

Not yet done with those, but getting closer…

I’m a hardware vendor, shipping systems with free software only. Plus I’m a Debian user, supporter, and small-scale contributor since long. I’ve read Martin’s “The Debian System” book, as well as the three “bibles” on how to contribute, made some packages, I’m following some newsgroups and Planet Debian, and in general I think that I more or less know how the system - and the community - works.

However, with following the latest discussions in/on the Planet about the Lenny release, combined with some personal experiences and thoughts, I think I need to get into the discussion somehow.

Why?

Take into consideration: Centrino2, for example. Lenny has a kernel version 2.6.26, which doesn’t support most of that newest hardware out of the box. Which is fine with me, since I know how minor and trivial it is to include newer kernels into Debian. But also consider end-users, and you’ll get a completely different picture.

What I want to say, and what I’m really afraid of, somehow - is: Lenny is and will be obsolete and outdated, before it’s even released.

Now, don’t get me wrong here: as I said: I think I know the Debian rules, guidelines, procedures, and whatever not, and I’m a great supporter of all that. But I’m afraid we will lose the end-user, if we continue like this. This is in no way the start of a topic like: we need a “benevolent dictatorship”, or something like that - I would immediately turn my back on the distro, if it wasn’t as democratic as it is right now.

And how about Etch-n-half?

Why don’t we do something like a partial freeze, still considering newer kernels during the bug-squashing period? And fixing the kernel (and glibc and whatever depends on it) at the very last possible moment?

Just my 2 cents. I don’t want a situation where I could only recommend Debian to server administrators and geeks.

This blog is aggregated on the Debian community blog, and that is good, because I think the topic I mention here will also affect real big installations like - for example - the city of Munich, and so forth. So the second thought I had was:

How to contribute more, and better, as a non-developer? How would I get feedback on this one? Through my blog? Through my email, which some of you know (and most of you don’t)? As a “user”, who also has other things to do to earn a living, and to support his family, I’m afraid that I really can’t subscribe to all possible newsgroups and mailing lists…

Just take the time to consider my situation: I’m offering hardware, pre-installed with Linux (Ubuntu or Debian, which is the customer’s choice). Centrino is declared EOL (end of life) by most manufacturers by now, while Centrino2 is all the hype (whether it deserves it or not, is a completely different question). That means that my distributors won’t get any Centrino hardware from the manufacturers anymore before long, or even by now. And Centrino2 isn’t supported with Lenny, which isn’t even released yet. Just wanted to make that point clear.

Thanks to you all - without people like you, people like us would have no income at all.

Best,
Wolfgang

Congratulations, and happy birthday. From us and our small company, from Sander of LXer, from Ubuntu (saved as screenshot, see below), or from Steve or Ganneff.

If you follow these last links, you could even see our DPL dance. Or Wouter.

Update 08/08/19: Dr. Oliver Diedrich, known for his good and profound articles about GNU/Linux and other free software, also congratulated the Debian Project (Link to his German article in Heise Open). He also linked again to older news about Etch-n-half, both in German and English.

As mentioned this morning, Lenny is frozen now. And Holger was the first to mention it. Thanks, mate - and enjoy your stay in wonderful Madrid!

Debian 4.0r4, codenamed “Etch-and-a-half”, is finally released. The usual updates are enough if you have working Etch installations, like always. And Debian developer Philipp Kern has put up a nice list of those who contributed to the making of it. From his list:

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• Jérémy Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matthäi
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

Thanks to all of you, really.

The upgrade adds support for newer hardware due to the use of a newer kernel - a first time for a Debian point release. It also corrects several bugs and defects.

And Lenny is about to be frozen as well. Good times.

You may have heard of it: I’m speaking about DSA-1571-1. Read more about it on the pages “Key Rollover“, or “SSLkeys“.

And no, I don’t put it off lightly, like tuxchick did lately, nor do I blame any Debian people or anyone else - we’re only human, after all. But think about the consequences, like Erich did.

For me, that meant for instance that with fixing my setups on my local and remote Etch systems, I had to take care not to lock myself out of my older (and not vulnerable) Sarge servers with just generating new keys. The same applies if you made keys and used them for instance in your OpenWrt (or other) routers. Or for (SSL-) certificates. Or Tor. The possibilities are endless.

It’s even an issue if you set up a new Ubuntu Hardy system with the shiny new CDs which come fresh out of Canonical’s shop - the host keys are generated before you’ll get any updates over the network!

Maybe that is why Steinar explains us the maths, why Daniel calls it the “Worst Debian day ever“, or why Steve thinks that “Fixing this will take years, probably“. And it affects half of the world, tho most end users probably won’t be thinking about the large number of servers which run their services (I bet most people still don’t know that each and every email or chat or whatever runs through Debian servers somewhere out there).

But, like Michal said, “Everything bad is good for something” - so let’s roll up our sleeves and get to work. I’m halfway through already, I hope. Let’s see if I forgot something…

So - for all the sysadmins out there: think twice, and then again. And for the end users who rely on someone else (like an ISP or some “managed hosting”) to run their stuff: ask them if they heard about DSA-1571-1.

This mornings upgrade of Cacti on Etch wasn’t a very good one - it only displays

Invalid PHP_SELF Path

Get back the old one with:

sudo aptitude install cacti=0.8.6i-3.2

Then things should be back to normal. See also: Bug #479618 with the severity grave.

Update (only one(!) day later…):

As usual, Debian developers are super-fast. Now Cacti 0.8.6i-3.4 is available, and it just works. Thanks, Sean (or whoever uploaded this)! You rock.

Seems like ATI/AMD did the absolute right thing with opening up their drivers and/or hardware specs, following the good example of Intel. The good news of the day are:

If you have an IGP (integrated graphics chip set) like the RS480, or the RS690, then with the patch to a bug in MESA, the open source driver named “xf86-video-ati” now provides 3D, and you can expect that for example Compiz will finally run on your hardware. Non-proprietary.

Read David Airlie’s Blog for more info. Found on Phoronix.

The short version: packages for Fedora 8 and 9 are underway; I’ve read nothing so far within the Debian pages I’m following, but once that patch arrives in Sid, we all know it will take some 10 days or so to make it into Lenny as well.

This is great news indeed. Finally, we can start thinking about actually buying ATI graphics. And choice is what it’s all about, right?

Since I put my workstation, which is at the same time the MythTV server / backend streamer for the family into a new case and added another TV card, I had some issues.

No matter in which PCI slots I used these cards (two analog ones, a V-Stream Terminator with SAA7133 and a Hauppauge Win-TV with BT878 chip sets), they changed device numbers during boot time. So sometimes card 1 was /dev/video0, sometimes card 2 had that device number. Additionally, the BT878 card changed its /dev/dsp number. Not good if after each reboot (and they happen sometimes, because I wanted to dual boot into something newer than Etch for instance), you had to stop the mythtv-backend, change TV-Card settings accordingly, and then to restart the backend again.

This shouldn’t normally happen with PCI cards, but well, different timings, the moon phases, some weird things you could never analyze without real expensive equipment, … after all, a PC is only human as well, right? Hm.

I had read about udev already, but never actually cared much for it, not even to make rules for hot-pluggable stuff like USB sticks and so on. However, now I had to read, so this is what I did. Interesting, really. But for my special case here, a short intro on the MythTV Wiki should also give enough information for those whose /dev/video0 and /dev/video1 are swapping.

For the impatient: find out more than you want to know with just using

udevinfo -a -p $(udevinfo -q path -n /dev/video0)

(or video1 for your second card), then use part of those informations for writing a rule for udev. This is what I ended up with:

# this file was generated by wjl on Sat Apr 19, 2008
# to give persistent names for video and dsp devices to MythTV
#
# Add these symbolic device names to the mythbackend setup,
# and they should not change anymore (be persistent).
#
# let’s start with video:
KERNEL==”video[0-9]*”, ATTR{name}==”saa7133*”, SYMLINK+=”video-saa7133″
KERNEL==”video[0-9]*”, ATTR{name}==”BT878*”, SYMLINK+=”video-bt878″
#
# and then create a symlink for the bt878 DSP:
KERNEL==”dsp[0-9]*”, SUBSYSTEM==”sound”, DRIVERS==”Bt87x”, SYMLINK+=”dsp-bt878″

After that, as already commented in the rule file itself, use these symbolic names in the TV Card Setup of your MythTV backend. And that’s it. After the next boot, you (and MythTV) should be using these symbolic names instead of /dev/video0 or /dev/dsp1.

See “Writing udev rules” on reactivated.net or a pdf from linuxformat.co.uk for further and much more thorough advice.