There is again some ongoing debate about Ruy gems and how to integrate them cleanly into the operating system. Let s put aside the fact such tools are useful on Windows and MacOS which don t have decent packaging systems. This is not a reason to dictate stupid requirements for other operating systems. Still, even without that, gems, eggs and the like are great tools for development; tools that developers can t work without today. They allow to easily setup a development environment with everything needed, at the latest versions. However they were not meant for integration and production environments, and will never be suitable for them. We re living in another world indeed: a world where servers must be up 24/7, where security issues flood your inbox every day, where you need dozens of servers running the very same software. This world is the Earth. Python eggs and Ruby gems were designed for the same target audience and with similar requirements; as such, they share the same deficiencies when it comes to other audiences:

1. They replace the operating system s packaging tool. This is very nice to not wait for the packagers when you want the latest development version, but you lose track of what is actually installed. In production, you need to know exactly what s installed and at what version. You also need to know what you will need to update in case of a security issue.
2. They install packages automatically on the system. This is really the biggest WTF; there are some reasons to do that to begin with, but they are all wrong.
3. They use a specific file format. This requirement comes mostly from the Windows world, and it really makes no sense on Unix. It makes it much harder to integrate complex applications using components in different languages.
4. They ship all files at the same place, happily violating the FHS and making it even harder to integrate with other things.

Python tools (setuptools and easy_install) have shifted their philosophy and brought a few small improvements which allow us to easily work around issues 1-3. These tools now include all you need to build a development environment in any directory that will not have an impact on the system packaging, making a clear distinction between the two targets. Furthermore, the metadata is shipped separately and can safely be included in a distribution package. Similarly, modules will not be installed automatically on your system. I have yet to see such a move from Ruby developers. However, what we are still missing is something along the lines of dh_make_perl: starting from a CPAN module, it will generate a clean and working Debian package in a few minutes. There have been some similar attempts for Python, but nothing as efficient. And I am certainly guilty of not having done something in this area, as one of the most knowledgeable of issues we encounter while packaging Python modules. As a note, I should add the underlying issue behind all of this is still the same: the NIH syndrome. Developers are reinventing the wheel, engine and transmission. Which is not that bad per se, but by not looking at existing solutions for the problem of making a car move, they are inventing a square wheel, a steam-powered engine and a superconductor-powered magnetic transmission. For example, while trying to fix the 4th of items listed earlier and they are really willing to fix it and several more general issues, setuptools developers forgot to look at the existing solutions:

• API versioning in /usr/include/package-X.Y
• ABI versioning of libraries
• Build/install-time requirements gathering using an extensible format with pkg-config
• Automated generation of config.h containing all system-specific macros (including paths), with autoconf
• The Mono Global assembly cache which solves some of the specific issues of interpreted languages

Certainly, the existing tools are everything but perfect, and not necessarily suitable for Ruby and Python, but some of the design ideas behind them are clearly the good solutions to some of the issues of software development and integration. Adapting these ideas to radically different languages is going to take more time than just throwing other layers of symlink farms.

You remember the bug sprint, don't you? I've already argued how nice the idea was, being a stereotypical example of how in Debian efficiency and fun can (and often must) go together. Well, Joss' cookies have been delivered to my office last Wednesday, unfortunately I wasn't there!!!, due to my participation first in the Debian QA Meeting in Extremadura, and then another academic workshop in Amsterdam. Sadly, I had to "delegate" the task of cookie tasting to other fellow Debian-ers which happen to work with me. Today I've finally got back to my office, and to much of my surprise, 5 cookies were still there waiting for me. In spite of the bad previsions about their health status after a week, they were delicious: simple biscuits, not too sweet, with walnut in pieces, and dark chocolate. So long Joss, and thanks for all the fish cookies.

While a few developers have the chance to be paid for their job on Debian, most of us are doing it on our spare time, for fun. Yes, we are making the best operating system out there, for fun. Yet a large number of developers are taking this project way too seriously. To say it in other words, they have a carrot up the ass. I happen to prefer the French expression though, since it conveys better the rigidity of their attitude: they have a broomstick up the ass. Recently, when I launched the idea of the Bug Sprint, someone wrote to me to propose, instead of rewarding people with cookies, to send them money. This is the best example of broomstick behavior: taking the fun out of people by bringing back rampantly the very idea that almost split the project in two the last time it was introduced. The very same person, when faced with a sarcastic email sent to an announcement mailing list, immediately rushed in to send a ban request to list masters (a totally useless one, since I don t have the habit to make the same joke twice). That person happens to be the project leader. So it seems the only thing the DPL has to do, at a time when we d rather need people to fix RC bugs, is to protect the project from seditious members who don t share their love for broomsticks. When someone makes a bad-taste joke, you are not forced to laugh. But you are not forced to impose your rigid and moralist views either. And on top of that, throwing random accusations of sexism without any kind of justification does not improve the mood. This is even very close to defamation, but since I don t have a broomstick in the ass myself, I prefer to just laugh at them with the help of some fellow developers. I will go on shocking these people. And they won t like it more than in the past. Every time one of them climbs on her high horse to take a pathetic and patronizing stance while totally missing the point, it will bring a bit of fun. Bonus #1: as for the promised statistics, we are, at the time of writing, at 493 599 unique IPs who clicked on the trap. Quite a good investment for someone who d want to make money from smelly geeks. Bonus #2: here is a sexist picture.

There have been 470 mails during the last month in the DFSG violations threads on -vote@, but only 10 posters have contributed more than 10 mails so far:

85 Robert Millan
51 Manoj Srivastava
18 Pierre Habouzit
18 Josselin Mouette
16 Thomas Bushnell BSG
14 Stephen Gran
13 Frans Pop
13 Ean Schuessler
13 Adeodato Simo
12 Russ Allbery

Is someone working on a summary of the discussions? I would really hate it if we were asked to vote on this, with a “for details, see the -vote@ archives” footnote. (Robert Millan sounds like a perfect candidate for this task :-) )

---

A couple of minutes ago I received an email notification about #479427 being closed:

#479427: epiphany-gecko: please reduce the number of dependencies by avoiding linking to some libs
...
* Pass --as-needed to LDFLAGS. Closes: #479427.
+ Introduce 99_ltmain_as-needed.patch.

Being very interested on the subject I went to incoming.d.o and downloaded the -gecko and -webkit versions of epiphany, which were both listed in my packages with most dependencies top 20.

$ countPkgsDeps.pl epiphany-*_2.24.1-1_amd64/control
epiphany-webkit:27
epiphany-gecko:32

So yes, the number of dependencies dropped from 55 and 58 to 27 and 32, accordingly :)

Should dropping the number of useless dependencies be a RG for squeeze? we'll see.

Note: I'll update the post as soon as the i386 packages are built, because the number of package dependencies of my previous blog post were calculated from i386's Packages, not amd64's.

Oh, and of course many thanks to Josselin Mouette for working on the issue.

Hey Romain, you d be impressed by the number of upstreams whose knowledge of security measures is similarly close to the absolute zero. Since bad guys are always digging through commits for suspicious things, hiding the relevant commits is the best thing you can do to help them. Given things like this exist, It s likely that they have even automated tools to do this search for them. This way, distributors and security engineers have to do the same job, hoping to never miss a change that was actually a security fix. Unfortunately, two small scale projects that we happen to use have exactly the policy Romain described regarding security updates. I m amazed by the fantastic job the distributions security teams manage to achieve in these conditions.

The Debian Lenny release has still quite a big list of Release Critical bugs, and as Debian developer I feel that I should do my share, and at least look at the list of bugs and see if there's any I could do something for.

Almost always though, I find that I won't touch the remaining bugs in the list.because of one or more of these reasons:

1. a package I really don't care about
2. hugely complex package or might also use something obscure like cddb
3. it seems like people are already looking into it
4. it requires a political solution, not a technical one
   

As part of the effort to get Lenny released, Joss Mouette started the Debian Bug Sprint.
This is really a cool concept, and it is a shame not more people participated.

The reason for me it is cool is that it forced me to break the rules I mentioned above, because I got a bug which fitted 1 and 4 of my list above!

Turned out this bug is really a border case in interpretation of Debian policy.

The package is perfectly usable without any extern dependencies, hence it is currently in the main section of Debian. However it doesn't end there. The package also has a download script that can fetch firmware images for certain printers. It appears for people with these printers the package is NOT usable without external files.

Aparantly though, the current, as one person involved in the bug calls it, "spirit" of Debian is to tolerate this, as it is good enough that it is usable without external dependencies for SOME persons.

However the bug submitter doesn't agree, and thinks this is a case that needs addressing withing the Debian project.

I suggested splitting up the package and moving the download script to contrib, but this was mostly dismissed as idea.

The end result is that the maintainer decided to escalate the problem to the Debian CTTE.
This means it probable won't be solved by today, soo I will have to bake cookies for someone :)

Cookies, bugs, and releases Christian knows how to be very inspiring and provocative with his blog posts, the APT case is a very good example of how useful that can be. I believe today's post is yet another example of that, many thanks Bubulle! Still, I stopped believing in the incompatibilities among having discussions (possibly heavy, possibly flamish) and releasing. Fact is:

• I've been participating in the -project discussion about Debian membership. The reason why I did that is that I firmly believe we need to open up Debian to non-technical (or at least non-packager) contributors. We have been wishing that for years, no matter if/how flawed was the initial proposal, keeping the ball rolling on that aspect is very important for our project, possibly more than releasing ...
• ... nevertheless, this did not inhibit me from taking part in the wonderful idea of the BugSprint game. In fact, I also think that I deserve some cookies, but I'm waiting to see how Joss will determine the first 5 winners
• (and no, I did not gave up my job either :), I've been following the discussion on -project like 1 hour per night for a couple of random nights last week, and playing the BugSprint some hours during the past week-end)

The BugSprint has been anticipated well before the inflamatory membership reform proposal, and repeatedly advertised by Joss in various ways (kudos). Still the participation has been way too low. That has nothing to do with other "distractions".

...of my friends, workmates and colleagues, when I will have to try to explain them that, no, I have no bloody idea of when Debian will release. Mostly because:

• we have a ready installer and we don't release it
• a dozen of people cutting hairs about freeness are blocking the project's energy and demotivating most of our developers (Bug #449497 is a very good example of this)
• while this happens, another part of our energy is wasted in other hair-cutting discussions after an inappropriate announcement that was made in d-d-a about a topic that could have waited after the release

The project is currently heavily frozen. Our bug report rate during last month was 3000bugs, to be compared to the 5000 bugs/month ratio of the normal development process. So, yes, I'm already hearing the laughs about the trust that can be put in Debian. At some point, we should remember that even our technical excellence will not prevent us from people looking elsewhere for something serious to work with. Again, prove me wrong. Release the damn installer. Stop this nonsense about the so-called freeness of whatever bit in Debian. Postpone the discusion about contributors/maintainers/developers. Release the thing. By the way, thanks to Joss for the cookies contest. From what I've seen during the week-end, it was very successful. And, un surprisingly, those working on it were those not wasting their time in silly games. Ah, and I fixed an RC bug this week-end, too...

The Debian bug sprint has started! 27 players registered in the hope to win cookies. The list of players and their assignments can be viewed at the usual place. Good luck to everyone. NB: for those who wonder, the assigned bugs were chosen as the 27 oldest RC bugs without a patch and randomized with shuf.

Only one day left for registration ! Register now and win cookies !

Sometimes, I m becoming really pestered by the number of issues, especially hardware issues, that remain prominent in the Linux system after so many years. And I m convinced that one of the root causes is the kernel development model. While far to be the only one, you understand a lot when you have a look at it. The stable API nonsense To explain the development model, the kernel documentation contains a document written by Greg Kroah-Hartman called stable_api_nonsense.txt. I think this document gets one thing very right: advertising it is complete nonsense. Many things in this document can get you a good laugh if you are used to software development, unfortunately they are not funny given how much they affect us as users and developers. Let s start with the executive summary:

You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.

What it should say instead is:

You know you want a stable kernel interface, but you don't have it, and we will never provide it. You want stable interfaces to focus on fixing bugs in your driver instead of updating it for interface changes, and to make integration of your driver in the main kernel tree easy. You would get a lot of good benefits if your driver was in the main kernel tree, but it won't make it unless you adapt to our bizarre processes, all of which have made the Linux kernel into a constantly moving target which is the reason many hardware vendors don't want to support it in the first place.

Our compiler does not have the same ABI as yours This is what happens when the only thing that interests people in charge is to code. Writing this means that these developers have no interest in making the system usable. This becomes more unbearable when such technically sharp people make up false technical arguments:

Depending on the version of the C compiler you use, different kernel data structures will contain different alignment of structures, and possibly include different functions in different ways (putting functions inline or not.)

Really, I wonder how the Microsoft developers, the GNOME guys, the glibc guys, and basically all library developers who know what they are talking about, manage to have stable ABIs despite the compiler changing all the time. One of the incredibly complicated techniques they use is to only rely on guaranteed functionality of the C specification, instead of doing many clever and funky hacks. For things more related to development itself, there are also incredibly complicated techniques like opaque structures, which save a lot of ABI breakage. Actually the only thing you need, if you design your ABI properly, is to be rigorous.

Depending on what kernel build options you select, a wide range of different things can be assumed by the kernel

This statement of a problem also contains the solution: stop making available build options no one cares about (remember, people install binary packages from their distributions) to guarantee stability instead. Instead of implementing the solution, kernel developers deliberately choose to deal with this insanity in the worst possible way: by encouraging it. Only lame developers need stable APIs But the nonsense doesn't stop to the ABI, which after all is merely a problem for distributors. To be more annoying to developers themselves, let s make up reasons to break the API all the time:

Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things.

Explained this way, it looks like a good thing. If you've done serious development or integration, you know that actually it is a problem. If you never slow down to look at what you've done, you're only going to add new bugs while you're trying to fix the others.

When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly.

Everything is said. In the Linux kernel, changes are not done in a continuous way. Every non-minor change is going to have an impact on hundreds of different modules. The amount of work needed to accomplish these changes is absolutely insane. When a project like GNOME decides to phase-out an API, it takes several years before being actually replaced. In the kernel, it can simply happen between two minor releases, together with a rewrite of the whole ATA stack. The lolution Of course, Greg KH has a simple solution for you, in the What to do section.

So, if you have a Linux kernel driver that is not in the main kernel tree, what are you, a developer, supposed to do? Releasing a binary driver for every different kernel version for every distribution is a nightmare, and trying to keep up with an ever changing kernel interface is also a rough job.

No shit !

Simple, get your kernel driver into the main kernel tree.

Simple, isn't it? Unfortunately this is not going to happen while you are too busy adapting it for the constantly moving interfaces. This is quite feasible if you are writing a driver for an Ethernet network adapter, but for a video card this is another story, and for a virtualization layer? Well, the Xen developers have been struggling for years to integrate their technology in the kernel, and it is still far from done. No wonder why you get good drivers only for ethernet cards and not for 3D cards or even wifi chips. This doesn t go without other, worse consequences for users and distributors. Not everyone can afford to run Ubuntu, Debian unstable or Fedora, especially if they have simple requirements like not changing the whole system every 6 months. Corporate users using Debian stable, RHEL, SLES or Ubuntu LTS need a stable kernel that doesn t move, and that doesn t break everything when upgraded. The introduction of projects like DKMS to distribute drivers in a sourceful way while keeping them easily installable is a step in the good direction, despite being a workaround for a broken situation underneath. However these efforts are ruined by the constantly changing APIs that will go on requiring changes to the sources as well as the binaries. Why it can still work In fact, with such processes, you can wonder how it is possible that the system is actually usable. The answer is simple: while being smaller than many other projects, the Linux kernel has much, much more developers. A rough estimation shows that Linux has 2000 developers, many of which are paid full-time to work on it, to work on a 15 Mloc codebase. You can compare it with X.org, which has a few dozens of developers for 3 Mloc. Or with GNOME, 400 developers for 20 Mloc. With OOo, 150 developers for 10 Mloc. Yes, you need 10 times as many people to maintain the kernel code than for another comparable project. That's of course what happens when you keep them busy with a permanent refactoring of the code. This development method, while certainly having the advantage of bringing lots of innovation and fast integration of new features, is also driving away a very large portion of the open source community to work on rewriting Firewire stacks every 6 months. And as long as they are busy with this, they are not writing correct X drivers nor fixing bugs in the applications.

I would like to add some clarifications to the debate on linux sound APIs that happened last friday on planet. First, despite being portrayed as such, I am nothing like an OSS zealot. I was just recently surprised that OSS developpement still exists and that no one cares. Hence, my initial motivation for my post was to correct false informations, not to advocate for any solution. Now, since the debat has been opened to the issue of linux sound APIs, I feel like adding my two bits. In particular, unlike Josselin, I don't believe that the debate is irrelevant. I, too, would like that we consider two levels for sound APIs:

• Low level, decidated to some specialized applications
• High level, used for simple sound applications, in particular in a desktop environement.

However, there are few points that are missing in Josselin's claim:

• This distinction was not an initial design for ALSA. ALSA was aimed at being both low level and high level, in particular with the pcm virtual devices. However, the lack of documentation and the absence of any high level programming interface for the high level pcm virtual devices just made this goal totally fail.
• Desktop environements didn't agree on a common standard. Even though there seems to be some solutions that are emerging now, like pulseaudio, this is not at all a standard yet. For instance, all graphical mixers I know about only support ALSA.

So, yes, I believe there is still a debate which should not be closed be throwing away idealistic solutions, but by discussing the real issues and trying to settle real solutions. Lennart also commented on previous message that he had adressed most of the remarks concerning the initial guide. In particular, he notices that OSS4 does a lot of audio processing in-kernel, objecting that this means that OSS4 will never be part of the official kernel. This is true, but it doesn't mean there are no life outside of the stock kernel. Here, again, it is a matter of liberty of choice. If some audio applications are better suited for OSS4, then I don't see why we shouldn't provide this alternative.

Lennart Pottering’s post about the sound APIs available for Linux appears to have caused some consternation from people working with the modern out of tree OSS drivers who feel that the current, out of tree, OSS drivers are being unfairly maligned. This rather misses the point of his post. The fact that there are improved versions of the OSS code doesn’t really help developers who are trying to target current Linux distributions which only ship the old OSS drivers. From this point of view the new OSS drivers are probably best looked at as a completely different product. Joss is right, though - most applications should be working with a higher level user space API than either ALSA or OSS. One of the most obvious examples of this is in the embedded space where there are often vast numbers of controls that need to be exported in order to support the complex audio routing that devices like phones can have. Most of these should only be touched very occasionally when changing use case and should therefore be hidden from normal applications where they’re at best irrelevant and at worst confuse end users. They do, however, need to be exposed by the kernel in order to allow user space the flexibility to manage the audio configuration of the system at run time.

After Lennart posted his summary of Linux sound APIs, the debate heated up again between ALSA and OSS zealots. Both ALSA and OSS developers think their API is the definitive interface for sound support in Unix and like to bash each other, and tell how the other API sucks and how the others are spreading FUD. This is not only a sterile debate, but it is completely irrelevant. Do you know why? Because neither of them is a suitable sound API. Technical constraints, functional requirements and history make the ideal sound stack on Linux look like the following:

• a sound driver, consisting of a kernel module and if necessary a low-level library
• if configured so, a sound daemon which brings software mixing and network support PulseAudio finally kicking out all crappy alternatives
• a high-level programming API for use by developers.

Only the last bit should be of interest to application developers. Everything else is plumbing. When you develop a multimedia application or a mixer controller, why would you care of the insanely complex ALSA library or to make ioctls somewhere in /dev when GStreamer and Phonon provide you with high-level functions that can do it in a snap? When you want to insert sounds in your game or application, why would you care of those bits when, with SDL_Mixer or libcanberra, a single line of code is enough to decode and play the sound? If we want to see sound working properly under Linux, we need to keep the stack simple and to clearly separate the roles. In the end, this boils down to very simple things:

• Application developers must stop using ALSA and OSS. Both of them are completely unsuitable for the task, and it only serves the purpose of letting ALSA and OSS developers troll. Whichever application you are writing, there is one of the high-level frameworks SDL, GStreamer, Phonon, libcanberra, KNotify, JACK that is better.
• OSS and ALSA should stop trying to be application-level APIs. Instead of trolling about which API is better, they need to write drivers so that sound fucking works instead of asking users to use Windows to see their brand new computer output some sound.
• The plumbing layers (backends for the high-level APIs and PulseAudio) need excellent support for both ALSA and OSS. In the end, what matters is to have a driver for your sound card and to have it usable by all applications. Keeping the driver layer independent from the sound API is the only reliable way to keep things working over time. If someone else starts writing yet another driver framework, we will be able to make applications use it, instead of adding yet another ton of compatibility stacks.
• In the end, compatibility layers that cross layers in the stack must disappear. ALSA emulation for PulseAudio? OSS emulation with a LD_PRELOAD hack? Seriously, WTF? Applications should not have used them as a sound API, and we need to trash this crap eventually.

Please, guys, hold off a minute. You are developing drivers and you must be praised for that. Keep doing that well, and stop trying to invade applications. There are people who may not know how to develop a driver, but who obviously know better what a sound API should look like.

Computer security is generally defined as the following:

1. The data should remain available to those who need it.
2. The data should not be available to those who don t have the right to.

The critical software component to the first item is your well-known nightmare: the backup software. Backups are easy! In many corporate environments, here is how you ensure you have backups:

• you install the backup agent,
• you call/mail the backup guy, telling him the IP of the machine and what to backup,
• you wait for his call/mail telling you it s ok.

Isn t that cool? So little work to have all your data completely safe! Wait if you look more closely, there is something wrong here. Nowhere in this process did you specify credentials to the backup guy, nor did you add anything to identify the backup server. Or to say it otherwise, once you have installed the backup agent, the backup server has full access to your data. But you didn t even specify anywhere the IP of the backup server. So this means that anyone on the network has full access to your data. Which, while trying to make your data secure, actually brings a gaping security issue on your system. Security by nullity When you install a well-designed backup agent, like Bacula, you have to specify a password for each client and make this password known to the backup server. A simple authentication protocol ensures that only the backup server is able to backup your data. However, when you install, for example, the HP Data protector agent, it starts listening on a TCP socket and (no kidding!) binds it to a restricted shell which has access to a small list of commands. The backup server only needs to connect to this TCP socket and issue commands. While this has the great advantage of simplifying the development process of the backup server, such a software has a name: a rootkit. Several other proprietary backup software have different implementations, like RPC-based or proprietary protocols, but the basis remains the same: you connect to the TCP port, and you have a way to read absolutely any file on the system. Of course, there are so-called security options, that you can buy besides the disk agent or the nifty web interface. Yes, when you buy software that is critical for your security, the very lowest level of security that you d expect from any software not turning your box into a self-service is a paying option. In the end, what prevents your data from being available to anyone on the intarweb is the ultimate solution to everything(tm): the firewall. As people are not stupid enough to use the same backup system in the DMZ, you can t simply bounce from it after having used a hole in the lousy PHP code that is never updated. (Well, that will still work in many cases since people actually are stupid enough.) No, what makes it very fun is the backup network. The hackup network A tape library is expensive hardware, therefore you only want to buy one. However, when you have several departments or, in outsourced environments, several clients, you can t simply access to the backup agents on all these servers, because of all these evil routers and firewalls that are blocking you. The solution is trivial: use the second network card on all servers to connect to a backup network. The backup network is entirely managed by backup people who have no idea of network security, and is routed all the way down to the backup server. If you are lucky, some ACLs set up by the network guy who plugged the switch will prevent some parts of the network to access some others. In all cases, it s very likely that many people in the company (or from other companies!) have full IP access to all your private servers where sensitive data is stored. That includes access to your databases setup without a password, and of course to your highly secure backup agent. That generally also includes full IP access to the lousy maintained backup server, on which security updates are never installed. But don t worry. Your data is safe. Note: no, this is not a worst-case scenario. Such badly-designed software is widespread. Such practice is widespread in several companies I know.

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• 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

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

Russel, GUI front-ends to GnuPG, at least the default one in the GNOME installation, can of course store passphrases and other sensitive information in a secure manner. Or, to be more precise, they could if the trivial fix to #472629 was applied by the PAM maintainers.

Josselin thinks it’s the most stupid world record, my take is that it is only a useless one. World records are interesting when they are challenged, not when they are set. And the fact is Firefox will become the world most downloaded software in a day in the world because nobody else tried to set this record before. Most Guinness records are such records, by the way: they’re set, not challenged. Speaking of stupid records, and how they are set (… or not), I quite like the following story, which happened live on french television. Some years ago, a guy wanted to set the record for spitting a greenpea as far as he could (*that* is a stupid record). The Guinness records guy was there, obviously, so that the record could be homologated. I don’t remember the numbers, but it’s not very important after all. Anyways, the guy sets his record, he is happy, and for fun, the TV show host tries. First try, first win, he broke the record that had been set a few seconds before ; without even trying to beat it. Coming back to the Firefox record, it’s useless to set a record you already know is not an absolute record. Microsoft service packs and affiliated are downloaded massively the day they are released, Microsoft just never considered submitting it to the Guinness book. And if they’d have tried, they would have set it at least an order of magnitude higher than Firefox will set it. Then Firefox would have needed to come up with a catch phrase like “the most downloaded free (as in free speech, because a MS service pack is free as in free beer) software” to get its moment of fame. So, how long before Microsoft tries to break it, with, say, IE8 ? And what will be the new marketing trick for Firefox 4.0 (after a full page in NYT for 1.0, “get your name in Firefox” for 2.0 and a Guinness record for 3.0) ?

Instead of trying to set a world record in the most stupid world record ever category, finally bringing software development to the same level as sausages, you can do something useful for your computer: download the latest epiphany package in unstable. Thanks to glandium s work, it fixes two notable regressions introduced by gecko 1.9, including the removal of the incredibly unusable certificate error page, also known as I want to be as cryptic as IE. As a side note, after spending a whole sunday trying to fix #393837, without anything remotely looking like success, I m very happy that the Epiphany developers decided to abandon Gecko. Maybe we will finally have a browser that is usable without needing a herd of maniac cultists to fix a bug. Something they won t do anyway they re too busy downloading the longest sausage in the world.