This weekend I went to the Ballarat install-fest, mini-conf, and inaugural meeting of the Ballarat Linux Users' Group (BLUG).

This was the second install-fest, the first one was quite successful so it was decided that there was demand for a second. I suggested that what we should do is get some of the more experience members of LUV to attend and give talks about their areas of expertise and make a mini-conference. I also suggested that we
hire a large vehicle to take a number of people to the meeting. Both my suggestions were accepted.

So on Friday evening I was in a Kia XXX with five other people from LUV on our way to Ballarat.

On Saturday we had the install-fest. We started at about 10AM, there were about a dozen people getting help installing Linux and many more attending the mini-conf and just hanging out. For lunch we had a BBQ. In the afternoon I gave a talk on SE Linux and then a brief impromptu talk on Poly-Instantiated Directories while the next speaker was setting up their laptop.

At the end there was the inaugural meeting of BLUG. The president was appointed, and there were some brief discussions about when to schedule meetings. I suggested that BLUG meetings should be either the day before or the day after LUV meetings to increase the incidence of speakers from other regions attending both meetings, my suggestion was being seriously considered at the time the meeting adjourned - LUV is a larger group and has better ability to get speakers from other regions. It was also agreed that a
weekend combined LUV and BLUG meeting would be arranged twice a year.

I traveled back to Melbourne by train which was cheap at $9 and comfortable. There was even a power point in the carriage (which I didn't use as my laptop was charged and the location was not convenient). For the next such event I'll try and arrange a group to travel on the train together.

The next thing to do is to find other regional centers in Victoria where we can do the same thing. Bendigo might be a possibility.

Also if you are a member of a LUG in a city please consider the possibilities for helping form a LUG in a regional center that's nearby. I would be happy to provide whatever advice I can to help people replicate this success in areas surrounging other cities, so please email me if you have any questions.

Debian is participating in the Google Summer of Code again. Russell Coker offers to mentor SELinux projects, and so do I. I'm available for mentoring SELinux and Debtags related projects in particular. This years idea pool in the Debian Wiki. Make sure to also check last years idea pool (some of which will no longer be open, though). And of course your idea doesn't need to be on these pages already; we're of course interested in anything that goes beyond that. One thing with SELinux I'm particularly interested in is install scripts. That is quite some work to do, and you might want to automate it somewhat. Debian install scripts can be quite complex. Some things are obvious such as restarting services on upgrade. But some scripts do much more. SELinux uses a deny by default approach (which is the only sane security approach, btw.); in particular this means that many Debian install scripts will be failing. Right now, package postinst scripts are being run with the full permissions of the apt-get domain. It would be good to reduce that to a "postinst" domain. It would be a possible GSoC project to analyze which permissions package postinst scripts need, and if we can e.g. add a "postinst extended" domain for just a few postinst scripts that really need extended permissions. An example for extended postinst tasks in Debian (I don't think Redhat, Fedora or Gentoo does that yet): precompiling all python modules for all installed python versions (and to avoid having programs try to precompile them on demand, which will result in audit errors and such). I wrote a module for that called python-support. It adds a restricted domain which can exactly do this task of precompiling Python. But there is other such stuff, such as updating the menus, managing alternatives etc. But feel free to suggest your own ideas.

After finally getting wireless connectivity whilst on hols, the only thing left was email. I'd already configured fetchmail by copying the fetchmailrc from my email server before I left but I'd forgotten to do procmail maildrop. Some reason, can't seem to get maildrop to work with maildir (which is what sylpheed uses for 'local' email accounts) so I'm filtering messages manually for now. Adding a custom action to sylpheed to run 'fetchmail -s' is nice but it would be even better is sylpheed could call that action when checking for email. (I feel a wishlist bug coming on.)

SMTP was initially more of a problem - SMTP AUTH was available via the excellent ukfsn so creating a new Roaming account in sylpheed allows the configuration of SMTP AUTH just for that account. Problems with forwarded email addresses (like codehelp at d.o) and mailing list subscriptions meant that I'm now using a private server but ukfsn were perfectly usable for non-mailing list usage of 'normal' email accounts. It's only my own, overly complicated, forwarding and greylisting systems that made mailing list submissions into a problem.

The remaining problem is power consumption - the wireless connection on this iBook (Airport Extreme internal) seems very power hungry. All the testing and configuring that was needed for the above cut my battery life in half. I can normally get 4hrs plus of 'average workload'. This will have implications for using wireless at DebConf etc. Even if sylpheed could call a custom Action (like fetchmail) automatically, it wouldn't be wise to keep the original 10minute checks without AC power.

Here is an odd technological image (to make you smile I hope) and here is the not-so-odd Technolgy Quarterly published by the Economist.

[UPDATE: I'm closing comments on this post, because the spammers have discovered it -- dnb]

Lars says:

The uncomfortability of Synaptic may be partly due to the fact that it is
a different model from Windows: you get all your programs from one place,
instead of anywhere on the Internet, partly due to just not using Synaptic
much at all, and partly due to Synaptic not being perhaps as easy to
understand as possible. I personally find Synaptic to be very nice, and
use it regularly, but I am biased by having used Debian package managers
for over a decade.

Now, synaptic is a lot nicer for users than scary console frontends like aptitude. But it's really a tool for "power users". Here's a quick list just of what I see when I start it (bearing in mind that my UI design skills suck):

• The "quick introduction" screen that pops up is way too long. The fact that it needs to be so long is already bad.
  
• There's a huge, and I mean HUGE list of sections down the left. What are these? Which one do I look in? For that matter, what is "gnome", and are "shells" programs for the seashore?
  If I want to find software for processing video, do I look in "graphics" or "multimedia"? (and what are these funny "(contrib)" markers?) Which of the huge number of packages in each section do I want? From the point of view of a new user (especially), this categorization is useless, not to mention often wrong or misleading.
  
• The four buttons in the lower-left, which change the display, are a good idea, but they don't say what they do. A label saying something like "Group By" would go a long way here.
  
• I think the version numbers in the main display probably provide too much information for a novice user. They won't really know what to make of them, and if they need the information it can be provided on demand; as it is, it's just one more distraction to sort through while looking for what they really want. The extra space could, e.g., be used to provide more room for the status column (currently labeled "S").
  

So much for superficial observations. There are a few more things that I see that are worth more discussion.

Mechanics of selecting packages

To change the state of a package, you click on the unlabeled little box to its left, then select the correct option from a list containing "Unmark", "Mark for Installation", "Mark for Upgrade", "Mark for Reinstall"...you get the idea. Even if only one option is valid, the menu still appears with all but one option grayed out, and you have to select the one you want.

This is complicated, cumbersome, and surprising. It also introduces terminological confusion, since "Unmark" isn't really what you think of when you go to cancel an installation or whatever.

The best option I can think of here is a pulldown menu (which I believe the GTK+ list widget (god, I almost wrote "control") supports). The menu should default to the current state, e.g., "not installed", and should have options that describe what will be done with the package, e.g., "install", and so on. Only valid actions should appear on the menu. The Package menu should probably adapt in the same way as you select packages. I don't recall offhand how GTK+ menus work, but if possible commonly used commands like "remove" should be closer to the mouse when the menu appears than uncommon commands like "reinstall".

Another choice I can see, if you want to avoid menus, would be something like this: have two checkboxes, one for "install" and one for "upgrade". "install" would be checked for installed packages and not checked for not-installed packages. Checking or clearing it would mark packages for installation or deletion. "upgrade" would mark or unmark packages that were installed for upgrade. Of course, this introduces a redundant column for not-installed packages, which I don't like. It also seems to me that it would be less obvious what's going on for new users. But it would be more efficient for power users (who should all be using aptitude anyway ;-) ).

Progress bar madness

I haven't extensively used synaptic, but several core misfeatures of apt and our archive pretty much guarantee that if it displays progress bars for key operations like loading the cache or updating the package lists, the progress bars either run multiple times (i.e., don't actually tell you how close to finishing you are) or actually go BACKWARDS -- yes, BACKWARDS.

The great package hunt

Maybe the biggest problem is that unless you know what package you're looking for, basically all our package interfaces are useless. There are lots of fancy searching features you could add, but actually a quick test in synaptic suggests to me that this would be going in the wrong direction. Unlike aptitude, synaptic includes descriptions, and searches for stuff users might actually want (like, say, "burn CD") seem to turn up relevant results (i.e., software that burns CDs).

I'm sure the search algorithm could be improved (with inexact matching, better indexing (a package description suffix tree?), etc), but the big problem I see is that you tend to get back several dozen results, many of which are libraries, development packages, command-line software or software that doesn't work; some of the other software is software that can burn CDs but whose purpose is not to burn CDs (e.g., backup software).

How can we solve this? The first thing that springs to mind for me is to use popularity-contest data to weight the list. I know it's not terribly accurate, and it has some skewing problems (stuff in the default install will be favored), but I suspect it would greatly bias the results in terms of software that's useful to many people (using the "recently used" tallies might especially help here).

I don't have many other good ideas on the searching problem; I've seen vague suggestions of counting reverse dependencies, but this doesn't seem like a good metric of useful software to me; trying to extract more information from the short and sometimes inaccurate package descriptions seems like a really hard problem to me. (Google can do cool statistical analysis partly because it has so much data to work with AIUI; even a single Web page typically has orders of magnitude more information than a package description)

Another issue is the problem of finding related software once you've installed one piece. We have "suggests" and "enhances", but they aren't exactly displayed in a prominent or easy-to-understand way by any frontend. I think it might be good to display a clickable list of suggested packages somewhere visible (e.g., at the top of the description box) when the user has selected a package for installation. We could even display a little bar, like on (eg) Amazon: "Debian suggests installing these packages..." ;-)

It might also be interesting (if this is considered acceptable; since the data is anonymous I don't see a problem) to analyze the popcon data to find out what packages are being installed in tandem. I don't know if we have enough information to do it, but it could turn out to be really useful to be able to click on a package and see other packages that are popular with users who installed that package. Going back to online stores again, those "other people who bought 'Types and Programming Languages' also bought 'Introduction to Category Theory'" links are amazingly useful, and something similar would probably be a big help in Debian.

For all of you that were clamoring to have 1.2 packaged, I’ve finally managed to tie up most loose ends. 1.2.7-1 is now available in experimental. The only problem that seems to remain is that it doesn’t build in kFreeBSD, because it is using network manager, which seems to be available only for Linux. I’ll correct that in a future upload. (Update: It’s been brought to my attention that packages.debian.org does not yet list the upload. If you encounter this problem, please just wait a few hours for the pages to be regenerated. The packages are already in the pool and they should hit your friendly neighborhood mirror in the next update, at the most.)

... write an email to "area-muc", the list for the Debian Munich user group and propose to do a link exchange for "Toronto Restaurants". May I point out that Munich and Toronto are separated by a larger ocean? And the Debian Munich user group doesn't have a real homepage they could do a link exchange on? (menupalace.com and their chris dickey was that stupid spammer. If I had a myspace account, I'd probably try to write him some comments...) Note: most likely this self-called webmonkey searched for toronto and blindly grabbed all email addresses he could find.

Today is the second day in which I find that my laptop does not resume properly from sleep and I start to wonder why. None of he old problems, blank screen, no reponse...

This time it just looses the GNOME session. I saw two segfaults on the console, on resume: one from iceweasel and one from another app. Then gdm comes up.

I think is xorg's fault or gnome-core. Why? Well, it didn't happened 4
days ago and I have these in the dpkg.log (grepped for upgrades only):

2007-03-12 00:19:04 upgrade xorg 1:7.1.0-13 1:7.1.0-15
2007-03-12 00:19:04 upgrade xvnc4viewer 4.1.1+X4.3.0-20 4.1.1+X4.3.0-21
2007-03-13 03:10:34 upgrade libeel2-data 2.14.3-3 2.14.3-4
2007-03-13 03:10:35 upgrade libnautilus-burn3 2.14.3-8 2.14.3-8+b1
2007-03-13 03:10:35 upgrade libnautilus-extension1 2.14.3-9 2.14.3-11+b1
2007-03-13 03:10:36 upgrade nautilus 2.14.3-9 2.14.3-11+b1
2007-03-13 03:10:37 upgrade nautilus-data 2.14.3-9 2.14.3-11
2007-03-13 03:10:51 upgrade nautilus-cd-burner 2.14.3-8 2.14.3-8+b1
2007-03-13 03:11:00 upgrade gnome-mount 0.5-2 0.5-3
2007-03-13 03:11:24 upgrade libxine1 1.1.2+dfsg-2 1.1.2+dfsg-3
2007-03-13 03:11:25 upgrade lintian 1.23.27 1.23.28
2007-03-13 03:11:26 upgrade unionfs-tools 1.4+debian-3 1.4+debian-4
2007-03-14 09:46:32 upgrade foomatic-filters 3.0.2-20061031-1.1 3.0.2-20061031-1.2
2007-03-14 09:46:32 upgrade libntfs-3g0 1:0.0.0+20061031-6 1:0.0.0+20061031-6+b1
2007-03-14 09:46:33 upgrade ntfs-3g 1:0.0.0+20061031-6 1:0.0.0+20061031-6+b1
2007-03-14 09:46:33 upgrade ekiga 2.0.3-4 2.0.3-5
2007-03-14 09:46:48 upgrade gnome-desktop-environment 1:2.14.3.5 1:2.14.3.6
2007-03-14 09:46:48 upgrade gnome-core 1:2.14.3.5 1:2.14.3.6
2007-03-14 09:46:48 upgrade gnomemeeting 2.0.3-4 2.0.3-5
2007-03-14 09:46:48 upgrade libgraphicsmagick1 1.1.7-12 1.1.7-13
2007-03-14 09:46:49 upgrade graphicsmagick 1.1.7-12 1.1.7-13
2007-03-14 09:46:50 upgrade obexfs 0.10-3 0.10-3+b1
2007-03-14 09:46:51 upgrade graphicsmagick-imagemagick-compat 1.1.7-12 1.1.7-13


I'll turn back time with snapshot.debian.net and see if I get back my resume ...


Notes:

• I use Etch, almost no packages from Sid or Experimental...
• no, I didn't submit a bug yet; although this is not RC from Debian's PoV, it sure feels like this kind of regression shouldn't happen...
  

Via Universal Hub, retail employee fired for blogging. This is not uncommon, but notable in that the blog had no work-related content nor, apparently, was it done on work time:

Drew started his own personal blog. On it he did not mention Mercenary, did not link to Mercenary, did not sell or offer any products or services that might be construed as competing with Mercenary. It just wasn’t about Mercenary. He didn’t even use his own name. His boss learned about the blog when coworkers passed around the posting with the adorable photo of his newborn son. His boss then fired Drew by leaving him a voicemail that Drew picked up when he got home from the hospital.

Although my employment law is rusty, I doubt the employee has a colorable claim against his previous employer. (Private employment is generally not subject to any First Amendment protections.) Any change here is going to need to be more cultural than legal. Ten (maybe even five) years from now, I suspect people will wonder what all the fuss was about. (Some have suggested that the blogger was actually fired for having a baby. If that is true, it likely would be actionable.) Technorati Tags: Blogging, Employment, Free Speech

I've been playing around some with the Google Maps API, via ym4r. I discovered, however, that its geocoding API doesn't do anything with the "accuracy" information that Google gives you, which tells you if the address you fed it actually means much. The XML looks something like this:

<Placemark>
  <address>Italy</address>
  <AddressDetails Accuracy="1" xmlns="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0">

I opened up geocoding.rb, and had a look, figuring it had to be pretty simple, and indeed, with REXml's XPath stuff, you can easily grab the elements you want. For example:

data_country = data['//CountryNameCode']

So... data['//AddressDetails'].attributes['Accuracy'] ought to give me what I want, right? Nope. The namespace in the sub element confuses everything. After some googling, I finally found the recipe:

data_accuracy = data['//*[local-name()="AddressDetails"]'].attributes['Accuracy']

Kind of a mess, but it works, I have my accuracy attribute, and I submitted a patch to the ym4r guy.

Just received that, in reply to a mail I sent:

This email is from X. My email address (X@Y.com) is protected against spam and viruses by MailInBlack. Please click on the following link in order to identify yourself to me and to allow your message to reach me.
http://192.168.0.252/v/?C8BEF10E72C&tmstp=20070316084314&tk=message_confirm&tkid=7951&lang=2 This needs to be done only once, for this email and all future email correspondence. Thank you for your understanding. X

MailInBlack seems to be a french company. No wonder why they guarantee that 100% of spams are stopped. (To be fair, I am not sure yet of who fucked up, it might be the admin)

My Thinkpad has started to run hot recently. If I do anything CPU intensive then it will heat up to >80C and then turn itself off. When idling it seems to stay at about 60C when the ambient temperature is about 24C.

It used to not be like this, a couple of years ago I cracked a GPG pass-phrase by using my Thinkpad (as well as a few other machines) to run a brute-force attack lasting a few months. So a couple of years ago I could run at 100% CPU time for months on end and now I can only do that for a few minutes.

It seems that my Thinkpad may have accumulated dust in it's fan from years of running 24*7. I run my Thinkpads 24*7 so that they can download email and large files while I'm asleep, because Linux suspend options have been lacking until recently, and because I use my laptop for a large portion of the day.

The problem I am having is similar to what I had with a previous Thinkpad. Are Thinkpads unable to handle 24*7 operation?

The Linux kernel project has seen major changes to its development and release strategy in the last few years, in particular since the first stable release of the 2.6 series in December 2003. This series was opened almost three years after the 2.4 series in January 2001, which many felt was too long. A problem that resulted from the long interval between major releases was that vendors had to back- and forward-port a lot of patches. Nowadays, major development happens on the 2.6 series and new releases are published every three to four months. This new development model has faced much controversy. While some people, in particular developers of the kernel, claim that the new model is working very well, some users are worried about the number of significant changes and lack of stability in the kernel. Andrew Morton, a lead developer, has expressed several times that he believes the kernel is getting buggier.

Version	Date	Months
1.0	1994-03-14
1.2	1995-03-07	12
2.0	1996-06-09	15
2.2	1999-01-25	31
2.4	2001-01-04	23
2.6	2003-12-17	35

Past problems

• Because of the long release cycle, many changes accumulated. It was hard to get the development stable and there were few testers.
• Features got out very slowly because of the long release cycle.
• Hardware support and crucial features had to be backported to the latest stable kernel.
• Vendors backported many features to their own releases. The code base from different vendors diverged a lot from each other and from the official development version.

Solutions

• New versions are now released every two or three months. There is a two week merge window after each release during which new features are accepted; subsequently, the focus is on stabilization.
• There is now a steady flow of code into production and many people get to test the new code.
• Features get out more quickly.
• Vendors can directly work with current releases and get their changes into official versions easily.

Outstanding problems

• There is no long-term stable version based on the 2.6 kernel. This is being addressed with Adrian Bunk's 2.6.16 long-term maintenance tree but whether it will have a big impact remains to be seen.
• Regressions between versions are introduced more frequently. Better control and tracking of regressions are needed.
• The Bugzilla bug tracker needs to be integrated better into the development process and it would be helpful to have a QA person. In January 2007, Google announced that they're looking for a kernel QA person who'd work together with Andrew Morton.

I was away in Philadelphia over the past week for the annual Drosophila meeting. My boss presented our work, and I shared a poster about it with the postdoc in the lab. I was constantly running from talk to talk and from poster to poster, trying to soak up as much as I could. I also got to meet a fair number of famous people, which was pretty awesome. It's not every day you get to meet a Nobel laureate, but that's why you go to these things. We got a lot of good feedback on our work, and we've basically gone in to overdrive to try and get the paper (which will be my first one) submitted.

Since I've been back, I haven't had any significant time to do Debian work, mainly because I've been in the lab or just taking care of life stuff almost non-stop. I managed to sneak in some time to tweak the XSF wiki pages, but the rest of the team has been handling things in my absence. I wish I could report on what they've been up to, but I haven't looked at any non-personal email for the past week.

Finally having a chance to check planet Debian today, I'm excited to see Martin's various posts about the release management for different free software projects. Obviously that's been the major thorn in our side for a while now, and while we're improving we can obviously do better. I'm looking forward to a post-mortem report and discussion from the release team about what the next steps we need to take are. I have my own ideas of course, but the release team has a much wider field of view than I've been able to achieve.

Off to see the Shins tonight, hopefully they're as good live as I've heard.

I assume that I was sung songs when I was little, but I don't really remember them. I do remember my mom singing "You are my sunshine" to me (but only the chorus, as she thought the first verse was too sad. I'm glad that she never heard the remaining creepy stalker verses from the O Brother soundtrack). Angie will sing lullabies that she remembers, but she's the oldest of three kids, whereas I'm the youngest of two by five years.

So all this to explain why at 4am I was singing Leif to sleep with songs from The Dances of Universal Peace. Walking in circles singing them reminded me that I haven't been to the dances in a while. They're on the second Tuesday of the month here in Montr al.

FSFE launched a raffle to encourage more people to join. I don't find it particularly attractive, which is probably partly because of my statistics education. I'll join FSFE when they stop promoting non-free-software like the notorious FDL. As it turns out, my reaction was pretty mild compared to some existing fellows. There was a discussion on the main FSFE international list flaming them for including the "likeable mask"-wearing Nokia N800 and an ex-Qt-locked Greenphone among the prizes. GNU Project Chief Webmaster Matt Lee wrote:

"I don't think this is appropriate, or wise. Further, it makes me want to not support FSF Europe."

Pretty early on, FSFE's Jonas Oberg wrote:

"Actually, this is news to all of us. [...] if there's no way to liberate the hardware before sending it out, we might well have to withdraw those prizes from the raffle to avoid sending non-free software to anyone."

but the flamefest continues unabated. As is sadly common on free software-related lists, the moderators have not stepped in with the fire blankets yet. (Some also found it worth reposting old lies about debian, which drew me onto the list to rebut them. sigh Way to go FSF fans.) Aside: Savannah has suffered a hardware failure in case you were wondering where cvs.savannah.* went.

Yes, that’s it, I’m finally Debian developer. I would like to use this post to say thanks to everyone who helped me to achieve this goal since I applied in 2005-10-05, here we go! Thanks to…

• Ricardo C rdenes, the man who linked me to Debian development world and, of course, my advocate.
• Moray Allan, my responsible AM.
• The NM Staff (Myon, HE, Ganneff, Elmo…)
• My usual sponsors: Ricardo, Ana, Amaya, Mones, Gunnar….

I hope to write an small report about the NM process with my impressions and opinions soon, so stay tuned. By the way, if you are planning to join Debian and you’re able to meet me, I’m offering GPG key signing since today :) Finally, thanks to all my #dudes!

The aim of Debian is to integrate software produced by other projects to create a complete operating system based on free software. In recent years, the project has faced increasingly delayed and unpredictable releases. Most notably, the release process of Debian 3.1 was characterized by major delays. Initially announced for December 1, 2003, the software was finally released in June 2005: a delay of one and a half years. Since then, the project has made a number of improvements to its release process.

Version	Date	Months
1.1	1996-06-17
1.2	1996-12-12	6
1.3	1997-06-02	6
2.0	1998-07-24	14
2.1	1999-03-09	7
2.2	2000-08-14	17
3.0	2002-07-19	23
3.1	2005-06-06	35

Past Problems

• Release management was not very organized and release updates were posted only infrequently. Because of this and the lack of a roadmap, freezes were often announced out of the blue.
• Due to the unorganized nature of the release, several new and unexpected blockers were found during the release process, leading to delays.
• The unexpected delays meant that software was frozen for a long time, in the case of Debian 3.1 for over a year. When this release was finally published, many components were already out of date and would often not meet user demands.
• The fact that Debian has experienced significant delays with several of its recent releases has led to problems with the image of the project. There is a perception that Debian is slow and cannot meet deadlines. This is also associated with frustration in the developer and user community.

Solutions

• The project has implemented better release management structures. In particular, Debian moved from a single release manager to a team during the 3.1 release cycle. The release is now handled by two release managers with the help of several release assistants.
• A release date for the next release was set well in advance and there is more planning.
• Release announcements are sent more frequently and various information sources have been implemented through which developers can stay informed about the release status.
• Release targets have been defined better and there is a distinction between blockers and goals. Only blockers hold up the release whereas goals can be postponed for a future release. For example, the XFree86 to X.org transition and the integration of AMD64 support were blockers, while LSB 3.1 compatibility and SE Linux support were only goals for Debian 4.0.
• The release team has shifted the responsibility of achieving targets to specific developers and teams. There are also better criteria now defining these responsibilities. For example, criteria have been published that architectures need to fulfil for inclusion in Debian 4.0 and there is a page indicating the status of each architecture.
• The release team is increasingly giving encouragement to developers to help out with software packages and bugs which normally do not fall into their domain.
• A staged freeze has been implemented according to which software is frozen in stages according to its importance. The toolchain and base system are frozen earlier than the majority of package. The majority of software is now frozen when most blockers have been resolved.
• The use of the experimental repository has been promoted to make sure that the main development repository is in a good shape most of the time.

Outstanding problems

• Developers still need to be convinced that targets can be met, that deadlines are real and that Debian can release on time.

I was the maintainer of minit for some time, and spent some time adding some runit-like functionality to minit I then called "enitdir". It worked similar to runit (IIRC, maybe it was a different init). Basically you had a directory for each runlevel, which contained symlinks to all services supposed to be running. There is a symlink called "current" or something pointing to the current runlevel. enitdir monitored this symlink and the directories contents via dnotify, so it supposedly was both very fast and efficient at noticing changes there. Switching runlevels was as easy as "ln -snf current foobar"; starting and stopping services worked by removing the symlinks in the current runlevel or manually calling minit (for non-persistent changes, restarts, etc.) (I think I never uploaded a package with any of this, the minit packages remained really close to upstream. I intended to do a fork/rewrite named enit, but never got around to it. Many of my ideas are addressed by upstart.) However this didn't solve some integration issues. First of all, not all packages back then were using invoke-rc.d; this should be a lot better nowadays. But the major issues lie within handling multiple inits on one system. There is a hook that applications could use to prevent init scripts from running (which might be the answer to Wouters iniscripts post). It's called "policy-rc.d". However there are some things wrong with this approach: it doesn't really support the installation of multiple inits or handles the problems of switching between inits in any way. Basically, the moment we need to switch inits (and thus service startup/stopping behaviour!) is during reboot. While the old init is still running, any start/stop operations MUST still use the method appropriate for the current init system. Otherwise, major bugs can occur, especially with smarter init systems that respawn services. E.g. the user runs "apt-get install sysvinit mysql-server". Lets assume sysvinit has a debconf prompt 'make me the default init' and the user says yes. Next mysql-server is upgraded, during which it calls the sysvinit way of stopping the service (i.e. /etc/init.d/mysql-sever stop), then does some dangerous things to the database, then restarts the server. However, a smart init such as minit (when equipped with appropriate service files) will notice the mysql-server process dying and immediately restart it (notified by kernel, efficient and fast) while the upgrade script is still messing with the database files. Boom, there goes your database. I guess you got the point. So we probably need a smarter invoke-rc.d script. It should support

• init detection - figure out which init is running, e.g. by comparing the inode of /proc/1/exe to the inode of /sbin/init.* (current init doesn't need to be named /sbin/init, but note that this magic might break on upgrades. Fallback to readlink(/proc/1/exe) maybe?)
• different init behaviours. The current policy-rc.d hook is pretty much a yes/no hook. Instead it should call the appropriate init-specific invoke tool.

Such an invoke tool could then for example look like this:

if [ -e "/etc/enit/service/$1" ]; then
    enitctl start $1
else
    /etc/init.d/$1 start
fi

You get the idea, having the policy script figure handle compability for services that don't have an appropriate service description for this init system yet. (Yes, s/start/$2/ or something, above is pretty dumb, but helps bringing my idea over).

As I'm nearing the completion of my PhD, I'm starting to write about the findings from my research. The aim of my PhD is to investigate quality improvement in free software projects. After some exploratory studies about quality in free software, I decided to focus on release management as one problematic area in which improvement is possible. My approach is to study the development process of projects and to investigate ways how these processes can be improved. The hope is that such improvements will lead to increased levels of quality in the software produced by free software projects. With regard to release management, I'm focusing especially on large and complex projects, in which hundreds of volunteers need to be coordinated during release preparations. I've been looking particularly at time based release management since my exploratory studies have shown that there is significant interest in this release management strategy. The main question of my research is how and why time based release management works for large free software projects. In my first series of postings, I will introduce the seven free software projects I have studied in depth during my research. For each project, I will briefly summarize what problems the project faced in the past, what changes they have implemented to address these problems, and what outstanding problems they still have.