Here it is. Debian had seven hundred thousand bugs reported in its history. Yet another French winner, indeed two, this time:

• Cedric Boutillier is the winner in the "race of bug #700000" by reporting "override: libzoom-ruby:oldlibs/extra libzoom-ruby1.8:oldlibs/extra" against ftp.debian.org, as part of a quite massive bunch of wishlist bug reports to deal cleanly with old transitional Ruby packages. I somehow suspect C dric retained his bug reports to catch the right moment..:-)
• I won the bet about the day this bug report would happen by missing it only by 7 days: I did bet for February 14th 2013, two years after the release of squeeze and I was secretely expecting we would also release wheezy around that time.

The French gang already got #200000 (by Michel Grentzinger) and #400000 (by /me), and #600000 by Cyril "KiBi" Brulebois. We're good at stupid games, as it seems. Of course, I will soon open the wiki page for the bug #800000 bet, which will again include a place where you can also bet for bug #1000000. Be patient, the week-end is coming..:-)

Here it is. Debian had seven hundred thousand bugs reported in its history. Yet another French winner, indeed two, this time:

• Cedric Boutillier is the winner in the "race of bug #700000" by reporting "override: libzoom-ruby:oldlibs/extra libzoom-ruby1.8:oldlibs/extra" against ftp.debian.org, as part of a quite massive bunch of wishlist bug reports to deal cleanly with old transitional Ruby packages. I somehow suspect C dric retained his bug reports to catch the right moment..:-)
• I won the bet about the day this bug report would happen by missing it only by 7 days: I did bet for February 14th 2013, two years after the release of wheezy and I was secretely expecting we would also release wheezy around that time.

The French gang already got #200000 (by Michel Grentzinger) and #400000 (by /me), and #600000 by Cyril "KiBi" Brulebois. We're good at stupid games, as it seems. Of course, I will soon open the wiki page for the bug #800000 bet, which will again include a place where you can also bet for bug #1000000. Be patient, the week-end is coming..:-)

The War on Time Whoosh! I ve been incredibly quiet on my blog for the last 2-3 months. It s been a crazy time but I ll catch up and explain everything over the next few entries. Firstly, I d like to get out a few details about the last Ubuntu Developer Summit that took place in Copenhagen, Denmark in October. I m usually really good at getting my blog post out by the end of UDS or a day or two after, but this time it just flew by so incredibly fast for me that I couldn t keep up. It was a bit shorter than usual at 4 days, as apposed to the usual 5. The reason I heard for that was that people commented in previous post-UDS surveys that 5 days were too long, which is especially understandable for Canonical staff who are often in sprints (away from home) for the week before the UDS as well. I think the shorter period works well, it might need a bit more fine-tuning, I think the summary session at the end wasn t that useful because, like me, there wasn t enough time for people to process the vast amount of data generated during UDS and give nice summaries on it. Overall, it was a great get-together of people who care about Ubuntu and also many areas of interest outside of Ubuntu. Copenhagen, Denmark I didn t take many photos this UDS, my camera is broken and only takes blurry pics (not my fault I swear!). So I just ended up taking a few pictures with my phone. Go tag yourself on Google+ if you were there. One of the first interesting things I saw when arriving in Copenhagen was the hotel we stayed in. The origami-like design reminded me of the design of the Quantal Quetzel logo that is used for the current stable Ubuntu release. The Road ahead for Edubuntu to 14.04 and beyond St phane previously posted about the vision we share for Edubuntu 14.04 and beyond, this was what was mostly discussed during UDS and how we ll approach those goals for the 13.04 release. This release will mostly focus on the Edubuntu Server aspect. If everything works out, you will be able to use the standard Edubuntu DVD to also install an Edubuntu Server system that will act as a Linux container host as well as an Active Directory compatible directory server using Samba 4. The catch with Samba 4 is that it doesn t have many administration tools for Linux yet. St phane has started work on a web interface for Edubuntu server that looks quite nice already. I m supposed to do some CSS work on it, but I have to say it looks really nice already, it s based on the MAAS service theme and St phane did some colour changes and fixes on it already. From the Edubuntu installer, you ll be able to choose whether this machine should act as a domain server, or whether you would like to join an existing domain. Since Edubuntu Server is highly compatible with Microsoft Active Directory, the installer will connect to it regardless of whether it s a Windows Domain or Edubuntu Domain. This should make it really easy for administrators in schools with mixed environments and where complete infrastructure migrations are planned. You will be able to connect to the same domain whether you re using Edubuntu on thin clients, desktops or tablets and everything is controllable using the Epoptes administration tool. Many people are asking whether this is planned for Ubuntu / Ubuntu Server as well, since this could be incredibly useful in other organisations who have a domain infrastructure. It s currently meant to be easily rebrandable and the aim is to have it available as a general solution for Ubuntu once all the pieces work together. Empowering Ubuntu Flavours This cycle, Ubuntu is making some changes to the release schedule. One of the biggest changes made this cycle is that the alpha and beta releases are being dropped for the main Ubunut product. This session was about establishing how much divergence and changes the Ubuntu Flavours (Ubuntu Studio, Mythbuntu, Kubuntu, Lubuntu and Edubuntu) could have from the main release cycle. Edubuntu and Kubuntu decided to be a bit more conservative and maintain the snapshot releases. For Edubuntu it has certainly helped so far in identifying and finding some early bugs and I m already glad that we did that. Mythbuntu is also a notable exception since it will now only do LTS releases. We re tempted to change Edubuntu s official policy that the LTS releases are the main releases and treat the releases in between more like technology previews for the next LTS. It s already not such a far stretch from the truth, but we ll need to properly review and communicate that at some point. Valve at UDS and Steam for Linux One of the first plenaries was from Valve where Drew Bliss talked about Steam on Linux. Steam is one of the most popular publishing and distribution systems for games and up until recently it has only been available on Windows and Mac. Valve (the company behind Steam and many popular games such as Half Life and Portal) are actively working on porting games to run natively on Linux as well. Some people have asked me what I think about it, since the system is essentially using a free software platform to promote a lot of non-free software. My views on this is pretty simple, I think it s an overwhelmingly good thing for Linux desktop adoption and it s been proven to be a good thing for people who don t even play games. Since the announcement from Valve, Nvidia has already doubled perfomance in many cases for its Linux drivers. AMD, who have been slacking on Linux support the last few years have beefed up their support drastically with the announcement of new drivers that were released earlier this month. This new collection of AMD drivers also adds support for a range of cards where the drivers were completely discontinued, giving new life to many older laptops and machines which would be destined for the dumpster otherwise. This benefits not only gamers, but everyone from an average office worker who wants snappy office suite performance and fast web browsing to designers who work with graphics, videos and computer aided design. Also, it means that many home users who prefer Linux-based systems would no longer need to dual-boot to Windows or OS X for their games. While Steam will actively be promoting non-free software, it more than makes up for that by the enablement it does for the free software eco-system. I think anyone who disagrees with that is somewhat of a purist and should be more willing to make compromises in order to make progress. Ubuntu Release Changes Last week, there was a lot of media noise stating that Ubuntu will no longer do releases and will become a rolling release except for the LTS releases. This is certainly not the case, at least not any time soon. One meme that I ve noticed increasingly over the last UDSs was that there s an increasing desire to improve the LTS releases and using the usual Ubuntu releases more and more for experimentation purposes. I think there s more and more consensus that the current 6 month cycle isn t really optimal and that there must be a better way to get Ubuntu to the masses, it s just the details of what the better way is that leaves a lot to be figured out. There s a desire between developers to provide better support (better SRUs and backports) for the LTS releases to make it easier for people to stick with it and still have access to new features and hardware support. Having less versions between LTS releases will certainly make that easier. In my opinion it will probably take at least another 2 cycles worth of looking at all the factors from different angles and getting feedback from all the stakeholders before a good plan will have formed for the future of Ubuntu releases. I m glad to see that there is so much enthusiastic discussion around this and I m eager to see how Ubuntu s releases will continue to evolve. Lightning Talks Lightning talks are a lot like punk-rock songs. When it s good, it s really, really amazingly good and fun. When it s bad, at least it will be over soon :) Unfortunately, since it s been a few months since the UDS, I can t remember all the details of the lightning talks, but one thing that I find worth mentioning is that they re not just awesome for the topic they aim to produce (for example, the one lightning talks session I attended was on the topic of Tests in your software ), but since they are more demo-like than presentation-like, you get to learn a lot of neat tricks and cool things that you didn t know before. Every few minutes someone would do something and I d hear someone say something like Awesome! I didn t know you could do that with apt-daemon! . It s fun and educational and I hope lightning talks will continue to be a tradition at future UDSs. Social Stefano Rivera (fellow MOTU, Debianista, Capetonian, Clugger) wins the prize for person I ve seen in the most countries in one year. In 2012, I saw him in Cape Town for Scaleconf, Managua during Debconf, Oakland for a previous UDS and Copenhagen for this UDS. Sometimes when I look at silly little statistics like that I realise what a great adventure the year was! Between the meet n greet, an evening of lightning talks and the closing party (which was viking themed and pretty awesome) there was just one free evening left. I used it to gather with the Debian folk who were at UDS. It was great to see how many Debian people were attending, I think we had around a dozen or so people at the dinner and there were even more who couldn t make it since they work for Canonical or Linaro and had to attend team dinners the same evening. It was as usual, great to put some more faces to names and get to know some people better. It was also great to have a UDS with many strong technical community folk present who is willing to engage in discussion. There were still a few people who felt missing but it was less than at some previous UDSs. I also discovered my face on a few puzzles! They were a *great* idea, I saw a few people come and go to work on them during the week, they seem to have acted as good menial activities for people to fix their brains when they got fried during sessions :) Overall, this was a good and punchy UDS. I ll probably not make the next one in Oakland due to many changes in my life currently taking place (although I will remotely participate), but will probably make the one later this year, especially if it s in Europe. I ll also make a point of live-blogging a bit more, it s just so hard remembering all the details a few months after the fact. Thanks to everyone who contributed their piece in making it a great week!

(doh, I nearly had it. I just got #690019, #690020 and #690022 for l10n stuff) Bartek Krawczyk reported Debian bug #690000 on Monday October 8th, against guake. And my friend Sylvestre Ledru, the package maintainer, now has to fix it instead of trying to promote the use of Scilab over proprietary alternatives in the French aerospace research organizations..:-) Bug #680000 was reported as of July 2nd: 3 months and 8 days for 10,000 bugs. This is a VERY significant drop in the bug reporting rate in Debian. Last time, I wrote: "How will the wheezy freeze affect this? We'll see in two months!". We have the answer: the wheezy freeze triggerred an important drop in bug reporting rate in Debian. My general feeling is somehow different: for whatever reason, I feel like the *overall* activity in the project has dropped significantly. I seem to have less mails to read, less bugs reported against my packages, even less heated discussions here and there, as well as several very quiet channels on IRC. Am I pessimistic when feeling that the overall momentum is sliding out of Debian? Maybe I am, so, folks, please make me optimistic and move you fingers out of the place where they are and help releasing that damn penguin. Apart from that, our next milestone (apart from the wheezy release!) will be bug #700000. Remember the bet?. It looks like the probability of Kartik Mistry winning it is now away (he bet for Now 8th 2012) and the best position is hel by David Pr vot (he bet for December 12th). On the other hand, my own chances are increasing if the bug rate drop is confirmed and if bug #700000 is reported in more than 3 months (I bet for February 14th 2013, guess why?). We'll see that in a few weeks!

The Maker Faire is one of those awesome Bay Area things that always fills me with excitement and gets my imagination going. Zoe and I went again this year to check it out, as best we could within the time constraints we had to work within (opening time and her nap time, minus travel time). She definitely enjoyed herself. We took the Caltrain, because historically driving and parking has been a bit of a nightmare. The optimal train to get to get there before it opened (at 10am) was the 9:19 train from Mountain View, which was scheduled to get in at Hayward Park a little before 10am. It just so happened that there was a Giants game on in San Francisco today as well, and the train was absolutely packed. We only got a seat because one kind gentleman was getting off and explicitly gave his seat to us. One lesson learned: don't try and take the BOB stroller on the train. Even when collapsed, it's way too bulky. For future Caltrain outings, I'll take our City Mini stroller instead, as it folds much flatter. I also took our macpac Possum child carrier backpack, and Zoe was pretty happy to just sit in it for the bulk of the time. I think it had novelty value for her, as we haven't used it for a while. I probably could have gotten away without taking a stroller at all. I was very glad I took the backpack, as it gave her a much better vantage point for everything that was going on than she would have gotten from sitting in the stroller. There was supposed to be a free shuttle from the Hayward Park station to the Maker Faire, but there was a huge crowd waiting for it, so I decided to just walk. It didn't take too long. For the return trip, I think I exited from the wrong side of the fairgrounds, and couldn't figure out the shuttles, so I just walked to Hillsdale station. At least the return train wasn't crowded. Overall, using Caltrain to get in and out was successful. Zoe was very well behaved for the ~30 minute train ride each way. The Faire was quite a bit bigger this year, and has spilled out into the parking lot on one side. I'd heard stories that O'Reilly had quadrupled booth prices as well. Trying to abide by the program was too difficult, so we mostly just wandered through the main Expo hall and looked at various booths. I just did a full read through the website of all the exhibitors to see what I missed out on. Here's some of the stuff I saw in person, or discovered via the website:

• there was a really excellent looking Dalek running around (way better than the photo on the page linked to here). I also learned that there's a whole Dalek-making website. Awesome.
• RAFT (Resource Area For Teaching) had lots of really simple, low cost projects for demonstrating various concepts in physics and science.
• Linux for makers was represented
• This Arduino-controlled automatic fish feeder looked cool. I didn't get to see it in person, I discovered it while I was trawling through the list of exhibitors.
• Shop-in-a-box. I'd have liked to have checked this out.
• Build a bug habitat. I'd have liked to check this out out as well.
• Solar bike trailer. My Dad would have liked this, as he has an electric bike. I imagine this wouldn't be all that hard to make. The trailer looked pretty long from the photo though, but hey, no pedaling.
• The water causeway. Now this looks interesting. I would have loved to have seen this one in person. I love clean tech. There's a whole bunch of videos linked off the page for this.
• Wave energy capture model. Another clean tech thing I'd have liked to have checked out.
• Roominate looks really cool. Something for Zoe when she's a bit bigger.
• There was a table extolling the virtues of growing your own algae for consumption (as spirulina) and bio-fuel. I'm interested in finding out more about the latter.
• I saw some HEXBUG-related stuff near the Geekdad table. This looked like a dressed up version of the "take a toothbrush head and glue an electric toothbrush motor on the back" type project. I'm curious to see how expensive the kits are, as they looked like a lot of fun.
• Ratduino sounds intriguing, but I can't find out much about it.
• Urban scale wind turbines. One that I needed to have seen in person. Unfortunately I missed it.
• GlueMotor looks cool.
• Low-cost push-button clicker. I'd have liked to have found out more about this. If it's what I imagine it is, this could be quite revolutionary in the classroom.
• Hardware Startup Showcase. I have ideas. I'd like to see them get out of my head and into existence. Turns out there's even a MeetUp group.
• Kits by Kids. I'll have to check this out to see what sort of stuff I can do with Zoe when she's a bit older.

Kickstarter is really becoming huge in the maker community. There were heaps of exhibitors there with (mostly robotics) projects that were past the initial prototyping phase and were seeking funding on Kickstarter to go into mass production. Some of the talks I'd have liked to have seen:

• Every Child a Maker
• "Kickstarters," Equity and the New Maker Pro
• Making Professional Makers - Career Tech Ed Instructors Talk Shop
• Manufacturing Open Source Hardware - Get Your Stuff Made!

Zoe was really well behaved for the entire expedition. I don't think she really gave me any grief at all. There was a brief period where she wanted me to carry her, but I managed to negotiate her back into the stroller after not long. I think her favourite was ArcBotics, which had a robot insect that would dance and wave at her. She kept asking for it to do more dancing.

Julien Cristau reported Debian bug #670000 on Sunday April 22th, against libgtkada. This bug is indeed part of a MBF for packages that are "marked as Multi-Arch: same, but contain files in arch-independent paths with arch-specific contents" (doh, these multi-arch things are sometimes giving me headaches!) Bug #660000 was reported as of February 15th: 2 months and 7 days for 10,000 bugs. As expected, QA work and release preparation do trigger an increase in bug report rate and we're now again quite close from the "10,000 bugs in two months mark". I forgot to report that bug #666666 has been reported in the meantime. This time by one of the top bug reporters in Debian, namely Lucas Nussbaum, during one of his archive-wide package rebuilds, against psimedia. Next step will be bug #680000, targeted in June 2012. With this rate, bug #700000 should be reported around mid-November 2012 and Kartik Mistry would win the Bug #700000 prediction contest". In the meantime, Launchpad will have reached bug #1000000 (the highest bug number is currently #986849....which will be no longer true by the time you read this). The rate in LP is currently about 20,000 bugs per month. I wonder how many of these are closed as I feel like this is humanly impossible to process that many bug reports.

Ben Hutchings is a rather unassuming guy but hiding behind his hat, there s a real kernel hacker who backports new drivers for the kernel in Debian stable so that our flagship release supports very recent hardware. Read on to learn more about Ben and the kernel team s projects for Debian Wheezy! Raphael: Who are you? Ben: I m a professional programmer, living in Cambridge, England with my long-suffering wife Nattie. In Debian, I mostly work on the Linux kernel and related packages. Raphael: How did you start contributing to Debian? Ben: I started using Debian in 1998 and at some point I subscribed to Debian Weekly News. So in 2003 I heard about the planned Debian 10th birthday party in Cambridge, and thought I would like to go to that. Somehow I persuaded Nattie that we should go, even though it was on the day of our wedding anniversary! We both enjoyed it; we made new friends and met some old ones (small world). From then on we have
both been socially involved in Debian UK. In 2004 there was a bug-squashing party in Cambridge, and we attended that as well. That s where I really started contributing fixing bugs and learning about Debian packaging. Then in 2005 I made my first package (sgt-puzzles), attended DebConf, and was persuaded to enter the New Maintainer process. NM involved a lot of waiting, but by the time I was given questions and tasks to do I had learned enough to get through quite quickly. In April 2006 I was approved as a Debian Developer. Meanwhile, I looked at the videos from DebConf 5 and thought that it would be useful to distribute them on a DVD. That led me to start writing video software and to get involved in the video team for the next year s DebConf. Raphael: You have been one the main driver behind the removal of non-free firmwares from the kernel. Explain us what you did and what s the status nowadays? Ben: That s giving me a bit more credit than I deserve. For a long time the easy way for drivers to load firmware programs was to include them as a blob in their static data, but more recently the kernel has included a simple method for drivers to request a named blob at run-time. These requests are normally handled by udev by reading from files on disk, although there is a build-time option to include blobs in the kernel. Several upstream and distribution developers worked to convert the older drivers to use this method. I converted the last few of these drivers that Debian included in its binary packages. In the upstream Linux source, those blobs have not actually been removed; they have been moved to a firmware subdirectory. The long-term plan is to remove this while still allowing the inclusion of blobs at build-time from the separate linux-firmware repository. For now, the Debian source package excludes this subdirectory from the upstream tarball, so it is all free software. There are still a few drivers that have not been converted, and in Debian we just exclude the firmware from them (so they cannot be built). And from time to time a driver will be added to the staging section of Linux that includes firmware in the old way. But it s understood in the kernel community that it s one of the bugs that will have to be fixed before the driver can move out of staging . Raphael: Do you believe that Debian has done enough to make it easy for users to install the non-free firmwares that they need? Ben: The installer, the Linux binary packages and initramfs-tools will warn about specific files that may be needed but are missing. Users who have enabled the non-free section should then be able to find the necessary package with apt-cache search, because each of the
binaries built from the firmware-nonfree source package includes driver and file names within its description. For the installer, there is a single tarball that provides everything. We could make this easier, but I think we have gone about as far as we can while following the Debian Social Contract and Debian policy. Raphael: At some point in the past, the Debian kernel team was not working very well. Did the situation improve? Ben: Back in 2008 when I started working on the Linux kernel package to sort out the firmware issues, I think there were some problems of communication and coordination, and quite possibly some members were burned-out. Since then, many of the most active kernel team members have been able to meet face-to-face to discuss future plans at LPC 2009 in Portland and the 2010 mini-DebConf in Paris. We generally seem to have productive discussions on the debian-kernel mailing list and elsewhere, and I think the team is working quite well. Several new contributors have joined after me. I would say our biggest problem today is that we just don t have enough time to do all we want to. Certainly, almost all my Debian time is now taken up with integrating upstream kernel releases and handling some fraction of the incoming bug reports. Occasionally I can take the time to work on actual features or the other packages I m neglecting!

Our biggest problem today is that we just don t have enough time to do all we want to.

Raphael: It is widely known that Linux is maintained in a git repository. But the Debian kernel team is using Subversion. I believe a switch is planned. Why was not git used from the start? Ben: The linux-2.6 source package dates from the time when Linus made his first release using git. I wasn t part of the team back then so I don t know for sure why it was imported to Subversion. However, at that time hardly anyone knew how to use git, no-one had experience hosting public git repositories, and Alioth certainly didn t offer that option. Today there are no real blockers: everyone on the kernel team is familiar with using git; Alioth is ready to host it; we don t have per-architecture patches that would require large numbers of branches. But it still takes time to plan such a conversion for what is a relatively complex source package (actually a small set of related source packages). Raphael: What are your plans for Debian Wheezy? Ben: Something I ve already done, in conjunction with the installer team, is to start generating udebs from the linux-2.6 source package. The kernel and modules have to be repacked into lots of little udebs to avoid using too much memory during installation. The configuration for this used to be in a bunch of separate source packages; these could get out of step with the kernel build configuration and this would only be noticed some time later. Now we can update them both at the same time, they are effectively cross-checked on every upload, and the installer can always be built from the latest kernel version in testing or unstable. I think that we should be encouraging PC users to install the 64-bit build (amd64), but many users will still use 32-bit (i386) for backward compatibility or out of habit. On i386, we ve slightly reduced the variety of kernel flavours by getting rid of 686 and making 686-pae the default (previously this was called 686-bigmem ). This means that the NX security feature will be used on all systems that support it. It should also mean that the first i386 CD can have suitable kernel packages for all systems. I have been trying to work on providing a full choice of Linux Security Modules (LSMs). Despite their name, they cannot be built as kernel modules, so every enabled LSM is a waste of memory on the systems that don t use it. This is a significant concern for smaller Debian systems. My intent is to allow all unused LSMs to be freed at boot time so that we can happily enable all of them. I recently proposed to drop support for older x86 systems, starting with 486-class processors in wheezy. In general, this would allow the use of more compiler optimisations throughout userland and the kernel. However it seems that there isn t that much to be gained unless we also drop 586-class processors, and there are still quite a few of those in use. So I think this will have to wait. Uwe Kleine-K nig has been working to include real-time support (also known as PREEMPT_RT). This can provide low and very predictable I/O latency, which is useful for live audio synthesis, for example. It still requires a number of patches and a build configuration change, resulting in a separate binary package. We re currently only building that for 64-bit PCs. (You may notice this is missing for Linux 3.1, because the real-time developers skipped this release.) Raphael: What s the biggest problem of Debian? Ben: I think we try too hard to accommodate every possible option, without regard for the cost to developers and users in general. As an example, we now have sysvinit, file-rc, upstart and systemd all in testing. Daemon maintainers can t rely on any advanced features of upstart or systemd because we refuse to choose between them. And the decision to support the FreeBSD kernel means that we cannot choose upstart or systemd as the only option. So all daemon maintainers will have to maintain those baroque init scripts for the indefinite future. We really should be able to decide as a distribution that when one option is technically good and popular then it can be made the only option. But no-one really has the authority to do that, so we muddle along with the pretence that all the options are equally valid and functional, while none of them is supported as well as they should be.

We try too hard to accommodate every possible option, without regard for the cost to developers and users in general.

We also try to build every package on every architecture, in general. I m quite sure there are many (package, architecture) combinations that have no users, ever. But if at some point that combination FTBFS, developers will waste time investigating and fixing that time that could have been spent working on bugs and features that users actually care about. Yes, sure, portability is good but you can t prove portability just by making a package compile on every architecture. This also applies to the selection of drivers for the kernel, by the way. Raphael: Is there someone in Debian that you admire for their contributions? Well, there are many people, but I will pick out just a few: Steve McIntyre, for his work as DPL to improve communication with the various Debian derivatives and to bring fresh blood into various core teams. Also for being a generous host for countless Debian social and bug-squashing events. Stefano Zacchiroli, for improving further on communications with both downstream and upstream projects, and for regularly exercising his power to lead discussions to the benefit of the project. Julien Cristau, for maintaining good humour while not only fighting against the tide of graphics driver regressions in X and the Linux kernel but also working on release management. Jonathan Nieder, for taking on the unglamorous and frustrating task of kernel bug triage as a non-maintainer and developing it to a fine art.

---

Thank you to Ben for the time spent answering my questions. I hope you enjoyed reading his answers as I did.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook .

4 comments Liked this article? Click here. My blog is Flattr-enabled.

Sam Morris reported the Debian bug #650000 on Friday November 25th, against system-tools-backends. Bug #640000 was reported as of September 1st. We're now approching the 3 months mark for 10,000 bugs. It either means that Debian development rate is slowing down...or that we're in the way to stabilize our development version. To be honest, I think that both reasons can be invoked. So, we're indeed halfway in the road from bug #600000 to bug #700000. Remenber the bug #700000 prediction contest? Bug #600000 was reported as of October 12th 2010, So, it took 1 year, 1 month and 13 days to reach #650000. It means that, with the same rate, we should reach bug #700000 at the very very beginning of 2013.And thus, the closest bets as of now are those by David Pr vot and, sorry, myself. There's of course plenty of time (and a release) to change this.

mythbustering a Debian release This is no news anymore, but in case you don't know yet: Debian 6.0 "Squeeze" has been released the past week-end. If you haven't yet downloaded Squeeze, stop reading this blog post right here and jump to: to choose your ISO; or check the release notes for upgrade instructions from Debian 5.0 "Lenny". Done?
Cool!
I hope you are now enjoying Squeeze as much as I've enjoyed being part of its development cycle which:

• has lasted 24 months from the Lenny release
• has been worked on by a volunteer Project of about 900 members and thousands of other volunteer contributors
• has closed 150'000 bugs
• has increased user freedom by delivering a Free Linux kernel
• has added 2 non-Linux ports (kfreefbsd 32/64 bits) to the already large family of Debian ports
• will continue the tradition of archive-wide long term security support (lasting about 3-3.5 years given current Debian release cadence)
• maintains, stubbornly, the tradition of a rock-solid Debian-quality system, made of packages which have been "tortured" by testing utils like piuparts, edos-debcheck, and frequent archive rebuilds (after all, what is Free Software for if you cannot recompile your programs?)
• has added 10'000 new (binary) packages
• has provided official backport service
• ... etc, you got the idea

I'm still shaked by the events, given the release happened in a sort of split context: the teams working on the final phases of the release (release team, ftp-masters, webmasters, cd, DSA, etc.) were "at home" hacking frantically on it, while many EU-based Debian people (including yours truly) were at FOSDEM representing Debian to the community with booth, talks, and answering the recurrent question so, have you released yet? . At FOSDEM, I've been personally submerged by congratulation messages that are not really for me, but rather for the Debian community at large. So: congratulations folks! People out there be them Debian users, users of some derivative, or Free Software enthusiasts in general seem to really love what we have achieved with Squeeze! The people that need to be thanked for this result are way too many, so I won't try to name names. Nonetheless, I've a few personal kudos to deliver to:

• The release team for the fantastic coordination and communication job over the past few months. They have also contributed to mythbustering #1: Debian cannot fix a release date (a bit) in advance.
• All the people who have worked on fixing RC bugs by sending patches, reviewing and testing them, preparing NMUs, etc. I'll never give up my belief that releasing is a shared responsibility and that we cannot scale without realizing that and changing our culture accordingly. All this people have contributed to move towards mythbustering #2: NMUs are bad.
• The publicity team which with release live blogging via @debian, blog posts, and press releases have contributed to mythbustering #3: Debian isn't able to communicate about the "cool" stuff they are doing.
• The webmaster team which has done an incredible job at mythbustering #4: Debian web presence sucks.

I'm overwhelmed by happiness about all that and I'll cherish it forever as a souvenir of what a community of volunteers, driven by common ideals, can achieve. Now let's party and then roll up our sleeves for Wheezy, which is already open for development.

---

PS I've talked again at FOSDEM about the relevance of Debian in the Free Software ecosystem. I've the impression the message is getting through: check out the very nice article Why Debian matters more than ever by Zonker.

When I was walking past Southbank when I saw some Parkour being practiced. I watched for a while and spoke to the instructor after the informal lesson was finished. He s a professional instructor with the Melbourne branch of the Australian Parkour Association [1] and he sometimes gives free advice to newbies that he meets on the street (in this case a group of 6 teenage boys). From the web site it seems that the standard lesson fee is $15 for an indoor lesson or $10 for an outdoor lesson with a $5 discount for members of the Australian Parkour Association [2], which is really cheap for a 2 hour lesson! APA membership costs $10 to join plus a $50 annual membership fee. It s worth reading the ParkourPedia information about the spirit/philosophy that is Parkour [3]. It s interesting to note that there can be no official Parkour shows because if you do it for anyone else then it s not Parkour so much for all the Parkour videos on Youtube. Also another issue with the Youtube videos is that Parkour isn t about doing the most dangerous things you can possibly survive in an urban environment, it can be practiced in country areas and isn t supposed to be unreasonably dangerous. The outdoor Parkour lessons start near the Arts center in the middle of Melbourne and presumably some of them go past Southbank as it has some interesting things to jump over. So it s worth watching out for people jumping over various obstacles instead of walking around them. They may not be doing a Parkour show, but it s in public and anyone can watch.

• [1] http://www.melbourneparkour.com.au/
• [2] http://www.parkour.asn.au/
• [3] http://parkourpedia.com/about/what-is-parkour

#600000

[Update: and to Rene Mayorga, for winning the 600000thBugContest!]

We will not make it and have Debian bug #600000 reported on 10/10/10. Debian is really not able to do anything on time..:-) (are others?) Whatever the moment this bug is reported (in 2-3 days, I would say), Ren Mayorga is the winner of the Debian bug #600000 contest. Of course, I'll send a nice blog post so that it makes it into Debian News. And then, we'll open the bets for Debian bug #700000!

Lucas has written two long, insightful posts on the frustration about the social aspects of integrating Ruby stuff Debian The first one, on September 12 and the second one, on September 29. I cannot really blame (thoroughly) the Ruby guys for their position. After all, they have a vibrant community, and they are advancing great pieces of work. And they know who that code is meant for Fellow programmers. And yes, although it is a pain to follow their API changes (and several of the Gems I regularly use do often get refactorings and functionality enhancements which break compatibility but introduce very nice new features), they say that's solved with one of Gems' main features being the simultaneous installability of different versions. The key difference in Debian's worldview with Ruby's is they cater to Fellow programmers. Even leaving aside heaps of different positions and worldview/mindset, we have a fundamental difference: Debian cares about its users, whatever that means. So, our users should not even care what language a given application is implemented in They should only care that it works. We, as packagers, should take care of all the infrastructural stuff. And yes, that's where we find the conflicting spot: We don't want to ship many versions of a system library (that in this case would be a Gem). Specially if later versions fix known bugs in earlier versions and backports are not available or supported. Specially if upstream authors' only response to a bug in an older release will be "upgrade and rewrite whatever breaks in your application". As an example of this, I am not currently updating the gems I maintain, as Debian is on a freeze to get out the next stable release. Or if at all, I am targetting those uploads to our Experimental branch, in order not to create a huge backlog for me when the freeze is over (just a series of rebuilds targetted at unstable). And yes, I will have to be responsible for any bugs that will most likely not be supported by most of my upstreams during the next ~2 years. That's the role of a Linux distribution. And yes, as Lucas writes in the comments he got as responses to the first post This dissonance comes in no small part because the Ruby developer community is mostly made from non-linuxers. People coming from a background where (mostly propietary) applications bundle up everything they need, where static linking is more popular than dynamic libraries, where there is no coordination between parts of the system are much less likely to understand our work. And yes, the Perl community is a joy to work with in this regard. And that's the same I understand from the Python one. Because of their origins and where their main strength was grown and remains. PS - And yes, I will join the flock of people saying that... The specific person that attacked your work is a great programmer, but well known as intolerant and obnoxious. Fortunately, even if our respective cultures fail to mix so much, most of our interactions just end with a "sigh" of lack of understanding, and not with the flames you got targetted with :-/

In my Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ, I wrote The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable). Zed A. Shaw just provided a very good example of that. Quoting the most juicy parts:

It s simply a tactic to make sure that you are stuck on Debian.

If we look at this problem from an open source perspective, Debian is at a minimum being a horrible citizen.

What is happening is control is not aligned with responsibility. Debian has taken control of the software package and recrafted it for their very narrow set of system administrator users. However, they refuse to take responsibility for the defect and quality problems they create. Instead I end up being responsible for their mistakes, which is wrong.

If Debian is in control, then Debian should be made responsible. That s the only way to get them to change it. If they don t want to be responsible, then they should let me be in control.

I m imagining a mass petition, maybe some funny ad campaigns, in-person confrontations meant to embarrass package maintainers, SEO tricks to get people off Debian, promotion of any alternative to Debian, anything to make them pay, apologize, and listen.

If you write software and you re sick of Debian screwing up your gear, then shoot me ideas for how we can make this happen. I think that if enough of us band together to make Debian responsible for its actions we can actually get them to start asking us before they package our software to find out how we think it should be packaged.

On the technical part of the post: The problem that Zed is experiencing is unknown to me, and also to the Debian and Ubuntu bug trackers. To my knowledge, rubygems doesn t not require openssl or net/scp to work, and a simple grep through the sources kind-of confirms that. But of course, that blog post was written as a rant, not as a proper bug report. My best guess is that the gem that Zed is installing requires openssl and net/scp. But of course, rubygems can t just depend on all the libraries that applications or libraries installed via rubygems could possibly require. Regarding openssl, we had a problem in Ruby because of the licensing situation of Ruby (dual licensed GPLv2+ and Ruby license, linked with openssl, which might raise some eyebrows), so it was split off the main standard library package until recently (and, apparently, in the version Zed is using). For net/scp, it is not part of the standard library, and not a dependency of rubygems, so I don t see why Zed expects it to be installed. On the rest of the post: Following my last post, several people volunteered to help with Ruby on Debian (and Ubuntu). In particular, Laurent Arnoud has been doing some fantastic work fixing the pkg-ruby-extras team s RC bugs. Also, all the messages of support both in the comments of my last post were very much appreciated. But I m really wondering why the Ruby community generates so many poisonous people. All my work on Debian is done on a volunteer basis, and it s really hard to get so much shit from it.

There are corners of the Internest where foolish people congregate, and invent stories. These foolish stories are then read as gospel by trusting people, and reposted, until the original made-up source is concealed from view. As an attempt to stem this flow of disinformation, here are some commonly held but incorrect beliefs about the Mono framework, and an explanation of the reality of the situation, as far as I understand it. The next Mono version is co-developed with Microsoft There is a grain of truth behind this one, but it s a gross mischaracterisation. Mono 2.8, when it ships, will bundle, for convenience, a number of Free Software libraries, which are released by Microsoft under a license considered Free Software by the Free Software Foundation, the Ms-PL. These are:

• System.Web.Mvc and System.Web.Mvc2: ASP.NET MVC, a library for writing ASP.NET web pages with a model-view-controller design, similar to Rails for Ruby. This is not news System.Web.Mvc has been bundled in Mono since Mono 2.4.2 (June 25th 2009). System.Web.Mvc2 has been bundled in Mono since Mono 2.6.7 (July 14th 2010).
• System.Numerics: Mono re-uses Microsoft s implementation of BigInteger.cs from the Dynamic Language Runtime (see below). This is indeed new to Mono 2.8, as it is part of .NET 4.0 (Mono 2.8 targets .NET 4.0 compatibility by default).
• System.Data.Services.Client: The OData SDK client library. This is indeed new to Mono 2.8.
• System.ComponentModel.Composition: The Managed Extensibility Framework, a library for writing and using plugins. This is similar in scope to the existing Mono.Addins project. This is indeed new to Mono 2.8, although it was added to Mono Trunk in 2009.
• System.Web.Extensions: Microsoft Ajax, a library for using Ajax inside ASP.NET projects. This is not news MicrosoftAjaxLibrary has been bundled in Mono since Mono 1.2.6 (11th December 2007).
• Microsoft.Scripting.Core and Microsoft.Dynamic: The Dynamic Language Runtime is a framework permitting implementation of dynamic languages (such as Python or Ruby) on top of the core .NET runtime. It is used for IronPython and IronRuby, amongst others. The DLR has very recently changed license from Ms-PL to Apache 2.0, but the version bundled in Mono is still under the older license. This is not news the DLR has been bundled in Mono since Mono 2.6 (14th December 2009).

So, to summarise, there are five Free Software libraries written by Microsoft under the Ms-PL included in Mono 2.8 but only two of those five are new, and none of them were co-developed in any meaningful sense. Mono development is dead There have been reports that Mono development has ended, on the basis that no commits have been made to Novell s Subversion server for a few weeks. However, these reports miss one minor detail Mono has moved to Github.com. There were 35 commits from 9 different people to the main mono.git repository (of dozens of repositories under the main Mono project) in the last 2 days, at time of writing far from dead. Mono lacks features found in Microsoft.NET Mono lacks libraries found in Microsoft.NET, such as the Windows Presentation Framework GUI toolkit. In terms of features, i.e. things implemented at a compiler or runtime level, Mono is typically more advanced. This is helped in no small part by Mono s Free Software development model, allowing experimentation and what if changes to the core runtime which a sluggish corporate behemoth like Microsoft cannot accommodate. To give three real-world examples, Mono allows embedding of its compiler as a service, and provides a REPL shell this is a planned feature for .NET 5.0, but has been available for years in Mono; Mono.Simd provides a number of data structures which will run on any version of Mono or Microsoft.NET, but will use optimized CPU extensions like SSE when run on a sufficiently new version of Mono, on an appropriate architecture as far as I m aware, there is nothing like this available or planned for Microsoft.NET. Mono is able to produce fully compiled, static executables which do not need to JIT anything at runtime this is used for iPhone compilation, for example, where JITters are not permitted. There is no comparable feature in Microsoft.NET. Clearly, Microsoft.NET can only be thought of as more featureful if one defines features in terms of does it have lots of libraries? in terms of functionality, Mono is ahead. Mono can sneak onto your system without your knowledge If you don t have the mono-runtime package installed, you can t run Mono apps. It is possible to install some Mono apps alongside the awful-yet-popular mononono equivs package, since the popular equivs script fails to place Conflicts on the correct packages (F-Spot will be blocked, Tomboy will not). No package in Debian or Ubuntu embeds its own copy of the Mono runtime, and we have no plans to make any changes to packaging which would allow execution of any C# application without mono-runtime installed. If one is using a different OS, then things may be different e.g. The Sims 3 for Mac & PC uses embedded Mono, which you wouldn t know about without looking. Canonical are pursuing a pro-Mono agenda, and are responsible for it being pushed in Debian Mono development has been happening in Debian for longer than Canonical has existed the first upload was made in April 2002. Ubuntu is made primarily from software already available in Debian deemed of sufficient quality, and when F-Spot and Tomboy became parts of the default Ubuntu desktop system in 2006, both pieces of software were already available in Debian and deemed of sufficient quality. Nobody working on Mono in Debian is paid by Canonical actually, that s not entirely true, three packages related to accessibility are officially maintained by someone who was hired by Canonical after doing the initial packaging work when he worked for Novell. But the Mono runtime itself, Canonical have no influence over its direction in Debian. As for a pro-Mono agenda , they ve always taken an extremely pragmatic approach to language choice, never showing any real preference for one language or another when it comes to app selection. They don t exhibit any overt anti-Mono policies, which is not the same thing. The names of people contributing to Mono in Debian are not secret check the pkg-mono team page on Alioth. The System.Windows.Forms namespace is protected by Microsoft patents The truth is, nobody knows for sure if SWF, or any other part of Mono, or any other framework such as Vala or Python, is covered by Microsoft patents. The way the US patent system is contrived, it is actively dangerous to check whether something contains any patents when you write it, as you are liable for triple damages should it later emerge that there WAS a patent, even if your searching missed the fact. You cannot patent an API or namespace only a specific implementation of a software concept, in those countries where software patents are permitted. There has never been any evidence shown that Mono s implementation of SWF, or indeed any part of Mono, infringes any Microsoft-held patents, because if that were the case, then the code would be rewritten to avoid the issue much like the approach taken by Linux kernel developers when a patent becomes apparent. The belief within the Mono community is that the core parts of Mono as defined in ECMA334/335 are safe (they are covered by the Microsoft Community Promise patent grant); any of the Ms-PL libraries mentioned above is definitely safe (Ms-PL includes an explicit patent grant); and the rest of the package is likely safe too (on the basis that it is a named component of the Open Innovation Network s list of protected software and on the basis that there s unlikely to be anything patentable in one of many implementations of basic ideas like database connectors). Nobody knows for sure, because that s how the system works. But, again, nobody knows for sure that Microsoft patents don t apply to other frameworks such as Python there is simply a belief and an assumption that they do not. MonoDevelop contributors removed GPL code from MonoDevelop, in an attack on the GPL This is somewhat disingenuous, given MonoDevelop is LGPL. The MonoDevelop team excised the remaining GPL code (and there wasn t much of it) in order to grant greater Freedom to developers. Previously, the entire MonoDevelop IDE was a GPL combination, meaning any add-ins for the IDE also needed to be GPL, regardless of developer choice. Now, any developer can write an add-in for MonoDevelop, using the license of their choice, whether another Free license like the Mozilla Public License, or a proprietary closed-source add-in. They are still welcome to produce GPL add-ins, if they want to, as well. Mono won t run random Microsoft.NET apps anyway, so isn t really cross-platform Actually, this one is often true. When developers write apps for Windows primarily, they rarely take the time to think is this the correct way to do it? and will often plough on with an assumption about the Windows way of doing things. It might be simple things like filesystem assumptions (assuming a case-insensitive filesystem, or assuming a backslash is used to separate directories, not a forward slash). It might be more involved, such as using P/Invokes into Windows-specific C libraries, when a more cross-platform alternative is possible. So, often, random applications for Microsoft.NET won t run on Mono. The reverse is also true F-Spot or GNOME Do are fairly heavily tied to Linux (or to UNIX-like OSes with X11, at any rate), through the libraries they invoke being fairly platform-specific. You can write platform-specific Java, with one quick piece of JNI, too. It should be noted, however, that Mono makes the chance of .NET applications being ported to Linux (and/or Mac) much more likely, since even in the worst case scenario, a company only needs to fix a portion of their source to make it cross-platform. The Mono team have a tool called MoMA, which will scan an application and its libraries, and give you detailed reports on the app s portability. This info is used at both ends by app vendors who want to become more portable, and by the Mono team who want to fill in the most frequently encountered blanks. And, it should be stressed, writing cross-platform apps is entirely possible if one desires it e.g. the IRC client Smuxi is pure cross-platform C#, and the executables compiled on Mono on Linux will run fine on Microsoft.NET on Windows. Portability in this direction is important too consider how many people have been introduced to Free Software thanks to availability of Free apps on Windows like OpenOffice.org, Firefox, Pidgin or GIMP. You can download Tomboy for Windows, and work is ongoing on fixing Banshee portability issues (which are mostly caused by gStreamer). Mono on Android is a terrible idea which will be super slow There are two efforts to enable developers to write Android applications with Mono a paid proprietary product from Novell called MonoDroid, and an untitled porting effort by big-name Android hacker Koushik Dutta. I have no insight into MonoDroid since it hasn t been released yet, but Koush did some benchmarks of his work which exhibited some remarkable figures compared to Dalvik (and even compared to Sun Java for ARM). Those numbers haven t been updated to reflect the Froyo Dalvik JITter, but Mono on Android is still very exciting from a performance perspective. Mono isn t really Free Software The source code is all available under Free Software licenses. So, um, yes it is. We don t need Mono because we have $LANG By the same logic, we don t need $LANG because we have Mono. By all means, use the language of your choice other developers will use the language of their choice too. If you want to use Vala or Python or Java, then by all means, go ahead. It doesn t mean there s no room for more languages, better suited to other usage patterns. Haskell is great for some types of development, so is Fortran, and so is C#. You might not need Mono because of $LANG, but there are others in the world with different needs. Mono apps are all slow, and crash your computer, and stuff No userland app can crash your Linux system, unless there s a bug in the kernel, or you have some severe problems with your hardware. If you ve ever observed a crash as a result of running a Mono app, then it s really coincidence that Mono is tickling whichever part of your system is busted. As for slow startup time may well be slower than for apps written in C or Vala. There s a delay due to the JITter needing to compile all the libraries used by the application (we may AOT the most common libraries in a future Mono package version, at upstream s recommendation). Once an app is running, it should be fast compared to a Python app, and memory-light compared to a Java app. The new garbage collector in Mono 2.8 should also offer significant improvements to performance, especially under heavy workloads. Ubuntu s default GTK+ themes require Mono This is my favourite recent nonsense to emerge from the Internest. There are reports mostly restricted to IRC and blog comments, that (paraphrasing here) removing Mono removes the Ubuntu themes . Here s the reality: in Ubuntu 10.04, a new visual style was implemented throughout the distro. As part of this, small icons (e.g. notification area icons) were set to be black-and-white by default, and colourised when attention is needed (e.g. the power-off icon turns red when a reboot is needed, the messaging indicator turns green when there s a new message). All of these new monochrome icons are in a package named ubuntu-mono . Removing the ubuntu-mono icon package will also remove the new Ubuntu GTK+ themes, in the light-themes package. So there s your explanation: the themes have a dependence on some monochrome icons, not on the Mono framework.

A lot is being said on how Ruby is packaged in Debian and Ubuntu. In this post, I m trying to go through the most common myths and give my position as a Debian Ruby maintainer. Note that those are my views, not necessarily those of the other Debian Ruby maintainers. Myth: Ruby is completely outdated in Debian and Ubuntu There s a culture in the Ruby community of always using the latest bleeding-edge version. There s also a culture (though this one has recessed a bit, I think) that it s perfectly fine to change APIs in incompatible ways if it makes the software slightly better. In Debian (and Ubuntu) stable releases, we try to provide a rock-solid version of Ruby that won t be allowed to change API during the support lifetime of a release. Bugfixes for important bugs can be applied, but that s basically all. So it s not surprising that Ruby in released versions of Debian and Ubuntu is behind the latest upstream version. In development branches, we are following the latest upstream versions quite closely. Debian 6.0 squeeze , to be released by the end of the year, includes Ruby 1.8.7-p302, and will include 1.9.2-p0 (the currently of Ruby 1.9.2 in squeeze is currenty a SVN snapshot from beginning of august). There are people interested in installing a packaged Ruby that just works, and other people interested in installing their own version of Ruby (through RVM and such). People in the Ruby community tend to forget about the first category, and consider that, because they install Ruby from source or with RVM, that should be the solution for everybody. We need the Ruby community to respect that different people have different ways of using Ruby, and to stop recommending that everyone using Debian and Ubuntu should install Ruby from source. We also need to leverage the backports services for both Debian and Ubuntu to provide a way to install the latest upstream version on stable releases. The only reason why we are not doing it yet is lack of time. Myth: Ruby is split into a myriad of packages in Debian In the past (pre-2005), a decision was made to split some libraries from the standard library into separate packages. This was motivated by:

• the size of some libraries, like REXML
• the fact that some libraries, like OpenSSL, readline, gdbm and tk require other library packages to be installed
• licensing concerns about shipping some code (a .so) linked with OpenSSL, and some other code (another .so) linked with readline, in the same package.

Most of the split was undone a very long time ago, and the readline and openssl splits were undone this year. The current package in Debian squeeze has:

• ruby1.8: binaries (ruby itself, irb, rdoc)
• libruby1.8: the standard library, except ruby-tk
• libtcltk-ruby1.8: ruby-tk (merging it with libruby1.8 would add several megabytes)
• ri1.8: contains both the ri binary and documentation
• ruby1.8-dev: development headers (to build applications or gems linked against the Ruby C API), and statically built version of the library
• ruby1.8-elisp: Ruby emacs mode
• ruby1.8-examples: Examples
• libruby1.8-dbg: debug symbols

It is always possible to merge more packages, but merging any of the other packages would significantly increase the size of what you get by default, and might discourage people to use it in some contexts (disk space is not always cheap. Think embedded systems and smartphones). Myth: Rubygems is crippled in Debian There are two differences in the rubygems Debian packages. First, gems are installed in /var/lib/gems, not /usr/local/lib/gems. That is because rubygems are seen as state for the Rubygems package, not independant software installed separately. A change for this is currently being discussed, and should be done after the squeeze release. (I don t think that it s reasonable to push that change now). A consequence of installing to /var/lib/gems is that gems binary are outside of $PATH. After the change, gems binary would also be installed in /usr/local/bin. Second, gem update --sytem is disabled in the Debian package, because that would replace code from the Rubygems Debian package with code downloaded from the Internet, and can break your system in subtle ways. We have changed this (in SVN, not in any package in the archive yet) to allow gem update --system if a specific environment variable is set, which gives us the opportunity to display a warning message. Myth: Ruby is slow on Debian Ruby is built with the pthread threading code, because not using it breaks many native Ruby libraries (Ruby-gnome2, for example). And other Linux distributions are doing the same. There are some very old benchmark results floating around in some blogs that show that the pthread code has a performance impact of about 20%. There are been patches for that for a long time (applied in Ruby Enterprise Edition), but they were never properly sent back. Actually, all the discussions about this issue were rumors and blog posts, and there wasn t even a bug report about it! After the bug was reported properly, it was fixed in a timely manner. The fix is not yet included in the Ruby 1.8.7, but is being applied as a patch to the Debian package since 1.8.7.299-2. (So the Debian package is actually newer and faster than upstream Ruby in that regard). What makes Ruby so difficult to maintain in Debian? The main problems we have with Ruby are portability issues. The only officially supported platform for Ruby is IA32 (i386 in Debian), and everything else is best effort. It means that it is not even supported officially on x86_64/amd64! Debian supports a dozen of architectures, and the Ruby package has to work on each of them. Ruby 1.8 is mostly OK nowadays thanks to the help of Debian porters, but we still have serious problems with 1.9.2, since the test suite fails on sparc, hppa, ia64 and Debian GNU/kFreeBSD. Why doesn t Ruby use the alternatives system on Debian? The alternatives system provides a way to switch between different software providing the same functionality. Currently, if you want to use Ruby 1.9.2, you need to use the ruby1.9.1 executable (1.9.1 = ruby compatibility version here). The alternatives system would allow to switch ruby to ruby1.9.1 on a system-wide basis. However, the situation of applications and libraries working only with Ruby 1.8 should be clarified: those should use /usr/bin/ruby1.8 instead of /usr/bin/ruby. Another problem is that the way to specify packages dependencies still need to be determined. There s nothing impossible to do about that, it just needs someone to do the work. Where do we go from here? The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable). This atmosphere makes it hard to recruit people, and the Debian Ruby teams are completely understaffed, which is clearly the major blocker to improving the situation further. We are 3 co-maintainers for the interpreter packages, and I m the only Debian Developer that is really active on a regular basis in the pkg-ruby-extras team (that does libraries and applications packaging). We desperately need help, but at the same time I have no time to improve our documentation and make it easier to join the team. While I haven t reached a final decision yet, I am also likely to stop doing Ruby work in Debian after squeeze is released, as I am getting increasingly tired and demotivated.

Joe Hansen reported the Debian bug #590000 on Thursday July 22nd, against the uif package. Guess what? That was a localization bug..:-)... Joe is doing a lot of work for Danish localization in Debian since a few months and I'm happy to see him rewarded byt this little "success". Bug #580000 was reported as of May 2nd. It is now confirmed that the rate for 10,000 bugs is more 2.5 months than 2 months as it was in the past. So, now my next post about this topic will be about Bug #600000 for which a bet was placed two years ago. I already lost the bet as I predicted it to happen on June 30th. Either Ren Mayorga or Josu Abarca are likely to win this bet, more likely Ren , I would say. One should note that all people who did bet where optimistic about the moment where bug #600000 would be reported.

I have announced the Debian Community Poll in my former blog post. I have closed the poll today and I will start publishing its results now.
What is the codename of the current stable release?This is the only compulsory question with the intention to block spammers. The correct codename is Lenny but I have accepted almost any answer that is somehow related to Debian. Version numbers, names from Sarge to Experimental, even well known codenames and version numbers from Ubuntu have been counted as correct. 22 partipants answered wrongly and their submissions got removed from the result set. A whopping number of 3258 submissions have been accepted and get analyzed now. Thanks to all participants!
How long have you been using Debian?

• 33.6% answered 6 - 10 years
• 32.7% answered 2 - 5 years
• 16.6% answered more than 10 years
• 15.5% answered 0 - 2 years
• 1.7% did not answer

On what kind of hardware are you using Debian?
Multiple answers are allowed for this question and that is why the values do not sum up to 100%.

• 80.5% are using Debian on the desktop
• 62.4% on the server
• 56.9% on the notebook
• 21.7% on the netbook
• 11.6% on embedded device(s)
• 3.2% on other device(s)

The following other devices have been mentioned: smartphone, virtual machine, nettop, NAS, HTPC, workstation, pendrive, live cd, cluster, thin client, router, rocket flight computer, ibm mainframe, and automatic bar tender.

Do you contribute to Debian?

• 50.0% choose answer #5: I don't contribute on a regular base.
• 31.2% choose answer #4: I'm regularly helping other Debian users.
• 8.0% choose other (see below) or simply did not answer
• 4.9% choose answer #3: I'm regularly contributing to Debian packages without uploading them by myself.
• 4.5% choose answer #1: I'm a Debian developer.
• 1.4% choose answer #2: I'm a Debian maintainer.

The following other answers have been provided:

• upstream developer or contributor
• translator
• bug reporter
• advocator
• former DD or DM
• prospective DD or DM
• mirror maintainer
• package/installer tester
• documentation writer
• donator or debconf sponsor
• debconf organizer or helper

How do you think about the Debian Free Software Guidelines (DFSG)?

• 46.0% choose answer #2: I like the DFSG but it is not the most important reason for using Debian.
• 36.6% choose answer #1: The DFSG is very important to me. I could live with many changes in Debian but I would be very upset if Debian would allow non-free software into its main component in the future.
• 10.1% choose answer #3: I don't know.
• 4.9% choose answer #4: I don't care.
• 2.4% did not answer.

Are you using Debian derived distributions, too?
Multiple answers are allowed for this question and that is why the values do not sum up to 100%. There were a lot of different answers but the most frequent are:

• 47.1%: Ubuntu (Kubuntu, Lubuntu, Xubuntu)
• 40.8%: no answer; this was the only way to say that someone does not use a derived distribution
• 11.0%: other (see below)
• 7.0%: damn small linux
• 4.8%: Sidux
• 4.3%: grml (juxlala)
• 2.2%: Knoppix
• 1.6%: ELive
• 1.4%: Maemo

The other answer includes the following distributions: 64studio, ALT Linux, arch linux, ArtistX, BackTrack, BRLix, Canaima GNU/Linux, catix, cdlinux.pl, CloneZilla, CrunchBang, Custom, ddwrt, debian arm userspace for zipit z2, DebXO (?), DreamLinux, Easy Peasy, eb4, eeebuntu, EMC2 Ubuntu (linuxcnc.org), Emdebian, Estrella Roja, Fedora, Finnix, Gentoo, gNewSense, Hackable:1, Kanotix, Kuliax, LFS and CLFS, LinEx, Linux Mint, live CDs, live-helper, Mepis antix, Musix, My own LiveCD, Mythbuntu, OpenInkpot, openwrt, paipix gnu, Parsix, Peppermint, personal debian derived, proxmox, Puppy, PureOS, qtopia, SHR, simplyMEPIS, Skolelinux, slackware, SymphonyOS, Toutou, Trisquel, tty GNU/Linux, UHU Linux, Univention Corporate Server, vinux, Voyage, Vyatta, whiite, Xandros, Xarnoppix. Not all of them are derived from Debian.

- to be continued -

That is my second day at the UDS in Brussels. I have attended some sessions about server and cloud yesterday. The Ubuntu people are better organized than the Debian people during Debconf. They are collaboratively preparing the sessions in Launchpad and make notes with the Gobby editor during the session. Gobby allows group editing via Internet. The release date helps to keep the focus on stuff that can be done within the time frame and helps to concentrate on getting results.

It will probably be only 5 months for Maverick because Mark asked for a release on 10.10.10 which is an interesting date after removing the dots and converting it to a decimal number. I am comparing it to Debian: Toy Story 3 will be shown in cinemas soon and the Squeeze character is promoting the film. Will we use such a coincidence for more public attention and will will we release our Squeeze soon? I am afraid that it won't happen.

Our last session yesterday was about Tomcat packaging improvements. Debian and Ubuntu are using and maintaining identical packages of tomcat6 using the alioth infrastructure of the pkg-java team. Some of our plans are:

• fixing postinst to read configuration values from /etc/default/tomcat6
• add debconf support to allow modification of /etc/default/tomcat6
• document alternatives to authbind since authbind does not support IPv6
• document 2 ways to package web applications using tomcat6 or tomcat6-user
• transition from the old libservlet2.[34]-java packages to the current libservlet2.5-java package
  

As you might have read, one of Debians slightly important machines had some hardware trouble. Before I get into more details of this story, let me say thank you to all the people who worked on this issue: - The DSA (Debian System Administrators) team, - the local admins at Brown University Computer Science department. I intentionally leave out the HP support here, I think their work in this issue was pretty suboptimal. While they do follow a certain schema, it took a bit long and the stunt with the technician not finding the replacement board and later on leaving without further notice wasn t all that great. (Update: Just to clarify this: In general we are happy with HP and the hardware and relationship and all that stuff. And usually the support works pretty well, like for all the times we had to replace broken disks.) Now, the story. This all started by us noticing something in ries kernel output telling about some trouble with the ram:

ries kernel: [168074.392016] Northbridge Error, node 0, core: -1
ries kernel: [168074.392186] K8 ECC error.

This was first noticed somewhere at the beginning of January. A DSA member then used the usual HP tools to check whats up, none of it reported an error. There wasn t much of an option left besides waiting what happens in the future. No support would do anything here. Until March we did not have any trouble. But at the 14th of March this changed, as the HP tools now found a serious error, reporting Status: DIMM is degraded for the third DIMM module. A support ticket was opened at this point and a replacement DIMM got sent out. Unfortunately the well known Mr. Murphy did look at this issue and so the wrong thing was sent out to the wrong place. Countdown continued and 10 days later the host decided to randomly lockup. And as HP servers have an Automatic Server Reset function in such cases, the whole machine rebooted. Not only once. Guess how much a filesystem likes such things when the machine is active. And for added fun a second DIMM got reported as broken, we now had DIMM #3 and #4 gone off. A certain ping-pong with HP support later we asked the local admins to take out the broken DIMMs and then also to change the order in which the remaining DIMMs are arranged. Unfortunately this did not help, the errors stayed. At this time we already turned off the services running on the machine and it mostly waited in the HP Insight Diagnostics test from HPs SmartStart CD. (And it always locked itself at 97% here). The support asked us to try another round of work on the machine, which our DSA team and the local admins did. But as it already was the 30th of March and nothing helped, our DSA got a little more direct in asking for a working solution. Like replacing the board and sending a technician to look and fix the machine. This was scheduled for the 1st of April, but turned out to not work as hoped. For some reason the technician was not able to find the board that was sent as replacement (no fault of our local admins!), so nothing happened the 1st of April except us getting a little upset. DSA communicated this to HP support, asking for escalation and finally getting this fixed. Our local admins could at last greet a HP technician on the 2nd of April then and he even had the replacement board with him, so he did his work there. He also confirmed that the two DIMMs mentioned above are faulty. For some reason he did not replace them, but left them outside of the machine. He also left the place without telling the Brown CS staff, so it wasn t the best performance he made. Fortunately the machine was in a working state again, only missing 2 of its DIMMs, 4Gb RAM. This has to be replaced by HP in the next days. When the Brown CS staff found out the technician left without notice they enabled our DSA to access the ilo of the machine again, so they could get the machine back up. Of course the first run was the HP SmartStart stuff again, running a full test. It reported no error, pheeew. There had been a few more steps in getting the settings of the ilo correct again and running a full filesystem check on it, but somewhere in the night the machine was back up and ready for us FTPMasters and Release team to get the services back. As the machine was back up in the middle of the night where I was sleeping, I did start my work somewhere this morning. At 10:25 CEST this started with a md5sum check of all files we have in our pool/ structure, ie. the Debian archive. We had 655k files to check, so it naturally took a while. Luckily we only found 32 broken files. Even better a set of them is already fixed, the rest of them is easily fixable with a set of binnmus the buildd people helpfully schedule, so not too much work involved in fixing this issue. Could have been worse. (Actually, when the first reboots happened, before the long downtime, we also had some broken logfiles, unreadable changes files and such things. But those I already fixed back then). More or less in parallel to the md5sum check we also started the queue daemons again, to let our upload queues from the other hosts forward their files to the central queue on ftp-master, tested the triggers to the new buildd peoples machine and the release team did a britney run. This took the first 5 hours (and a bit) of the process. As a second step, and we are still in this, we started the processing of the incoming queue. Turned out we have to process 10gigabytes of new uploads, in a total of 1285 uploads. This process is still running at the time I write this blog post, having processed about 1100 uploads. A good 9 til 10 hours run, but this was expected. I actually thought it will take even longer. When this is done I will go and have a manual dinstall run. That is, I will run every action a dinstall is usually doing by hand. And verify each step. Usually dinstall takes some 2 hours, manually it can take a bit more. Somewhere during this run a mirror push will also be done, a fairly huge one this time, with all those updates. When this all works I will turn on FTPMaster cronjobs after this dinstall, or at latest tomorrow morning, as usual, and service is back as usual. As far as I know the release team plans to turn on their cronjobs tomorrow morning too, so this will all be nice then. Apropos release: Please note what I wrote in my latest d-d-a mail:

As a sidenote from me: If you have a package that might be involved in
whatever transition to testing, or simply might get involved, it could
really help if you wait a day or two with the next upload, so the
release team can sort through all before you give them new trouble. If
in doubt, try mailing debian-release@lists.debian.org and ask. :)

So, thats it, enough annoyance with all those status bits here and there. I go leave you alone now. :)