Compiled over the last few weeks, here's a random list of some subjects I'd love to see covered in XTech 2006. There's now only three weeks left of the call for participation -- so it's definitely time get that proposal in! Mail me if you have any questions.

• OpenDocument vs. Microsoft Office Open XML (am I the only one annoyed by how this format is abbreviated as "Open XML"?)
• Ruby on Rails 1.0
• Firefox 1.5, including its many new features for developers. I loved the idea from Tristan Nitot that extensions are a way to keep Firefox successful. There's a lot of potential here. Anybody want to attend a tutorial on making Firefox extensions?
• W3C Rich Web Clients Activity
• XSLT 2.0 adoption and implementation--anyone but Saxon?
• The Web Desktop. I was incredibly interested in this post of Miguel de Icaza's. For a long time I've felt RDF could hold the desktop together, data-wise, but he also proposes that HTTP and web services could do a similar thing. I suspect these are two strands of development that go hand in hand.
• Design, usability and patterns for AJAX web applications.
• Open Content Alliance
• RSS and Atom: despite the release of Atom, RSS continues to grow down its own path. I reckon it's about time to sort out where each are going, and what they're best for.
• XSL-FO: I use this technology regularly for preparing PDFs with RenderX, and the specification itself is mature. It seems time to take stock of XSL-FO and where it might go in future.

Submit your proposal here: XTech 2006 Call for Participation. XTech will be held 16-19 May 2006, Amsterdam, Netherlands.

I never thought anyone would still seriously advocate CVS over anything else these days, but I was wrong. Bernhard:

• Ever heard of atomic commits? You modify three files, commit. Turns out that in the time between you starting to edit stuff and you committing, someone else changed some stuff, and your commit doesn't apply somehow. The first file is committed, the second breaks, and the third isn't committed. Congratulations, you just broke the build, and you'll have to manually fix it. When editing three files, that's manageable; when your commit is (say) about 15 files or so, it's not really as manageable anymore. CVS doesn't have atomic commits.
• About it being rock solid, I only say Hah. I've seen way too many cvs pserver bugs out there—and that's still the only possible way to go if you want anonymous CVS access.
• How about the fact that upstream CVS development is rather extremely dead, after most of their developers started to develop subversion because the CVS code is so extremely horrible to maintain?
• Moving files around isn't just a nice thing to have; it's an extremely important feature. Far too often have I seen people afraid to reorganize their code because that would lose history on the files. If you can't move files, you can hardly ever reorganize code, which means that you let your version control system dictate how you should work—which is bad, very bad.
• And finally, being able to tell someone that this is fixed in r132 rather than having to say this is fixed in r1.74 of foo/bar, r1.34 of foo/baz, and r1.82 of foo/quux is very helpful. Your suggestion about dates (there's normally at least a quarter of an hour between commits) only suggests that you haven't seen many large projects in the heat of code changes. And even if that weren't true, the fact that it normally isn't a problem makes it even more of a problem on the occasions that it, in fact, does take less than a few seconds between my commit and yours

Really. Have you tried comparing CVS to anything else, on a serious project? There should really be a way for all those version control systems to talk to eachother. After all, they all have one thing in common: they're all ways to exchange patches. Surely there must be some way to device a protocol or something so that those patches can be easily sent from one version control system to the other and back again?

Or: Why you should move away from Microsoft. Now. Visual Studio 2005, the new version of Microsoft's development tools, is coming out. Among its new features are Branching, Bug Tracking, and Atomic Checkins. Yes, that's right: Anno 2004, Microsoft still did not sell a version control system that had something as basic and important as branching. Kinda reminds me of the time when Microsoft implemented a telnet service for Windows right around the time when the UNIX world finally decided that telnet and RSH are insecure by design and that you should use SSH instead. If Microsoft keeps lagging behind on such fundamental issues, you shouldn't be using them.

Given that the perennial, uh, “discussion” about GNOME’s features is on us again, I thought I’d share the method I use to remove options from Quod Libet. I break them, and see how long it takes people to notice. Well, no, not really, but the amount of brokenness in an option is a good metric for whether or not people change it. One of the first options in QL was a checkbox for “Show album cover”. Sometime around 0.7 or it became impossible to turn this off, and I didn’t notice until I was redoing the preferences dialog for 0.11. Rather than fixing it, I just removed a few dozen lines of code and made it always on. No one has ever asked for it back (though someone probably will now). This has happened a couple of times. On a related note, three months ago Bram Cohen made an interesting post about configuration in software, which has been rolling around in my head picking up smaller objects since. There’s a lot of “configuration” that we don’t think of as configuration — for example, the volume in an audio player is stored in basically the same place (same file, GConf tree, whatever) as, say, where the program looks for files. But we only think of the later as part of our “configuration.” That’s because we control the volume “nearby,” in the same place we view it, but the location to look for files in a very different spatial place (an entirely separate window). No one would be crazy enough to put a volume control in a Preferences dialog. So “configuration” becomes synonymous with “hard to find”. The answer to configuration creep, then, is to provide as much direct manipulation as possible. At least from the UI perspective. You’re still screwed from the combinatorial explosion on the implementation side. Beyond that, one thing I’d really like is for context menus to be more common. That is, users should be able to expect to right-click on a widget, and change changable aspects of that widget. This also means making right-click involve no surprises — it shouldn’t activate buttons, shouldn’t delete things, etc. Otherwise people will be too afraid to right-click to try configuring. This feels like a good substitute for when direct manipulation isn’t really possible, because the most direct form of manipulation is already taken up by the widget’s primary purpose. Anyway, Quod Libet is going to be moving in this direction in the future. We already have plugins configurable in the same dialog where you turn them on and off. In 0.16 the tray icon has become an interface almost unto itself, and so it has a separate Preferences dialog now, launchable only from the icon. (It also only has one thing to configure, but that might change. Most importantly, it can grow, without getting in the way of people who don’t care about the tray icon.) For 0.17 I’m probably going to fulfill the common “display remaining time” feature request by putting a radio context menu on the time display. And so on. Fixing Real Bugs
But enough about UI wankery. Does anyone know of a nice C parser for Python? Inspired by a bug he found in mmapmodule, Michael’s written a tool to find type signature issues in CPython functions, but its usefulness is lessened by the fact it returns a ton of false positives and probably also misses many things as well. You Are All Self-Absorbed
My project for a class this semester involved trying to extract useful categories from the link structure of weblogs. Unfortunately it turns out weblogs are all about navel-gazing, and the link structure isn’t at all useful. The majority of shared links on Planet Perl,Debian,GNOME,Python pointed to perl,debian,gnome,python .org, and the majority on MSDN Blogs pointed to microsoft.com. Only about 10% of links pointed to a post on another weblog. Given that additionally weblogs tend to not have comments (and even if they do, people reply in another weblog post anyway), that’s kind of sickening. Can you imagine how much email would suck if only one out of every 10 mails got a reply? I wouldn’t be able to spend all day reading about how Debian’s FTP masters are doing their job properly.

It's been an interesting 24 hours. Monday
8:00 PM
I get home after working a regular day and having supper with a friend. 8:15 PM
One of our friend from church -- who happens to live a few blocks from my workplace -- calls. "Did you know your workplace is on fire?" "Uhh, no...." "Yeah, big fire, flames, dozens of emergency vehicles..." "Hmm..." So then I call my manager... "Did you know the company is on fire?" "Uhh... no...." "Yeah, sounds bad, I'm going to head in and see what's going on." 8:30 PM
I arrive at work. Cops have blocked all the entrances. I identify myself as an I.S. manager and am directed to the "manager area". (Others are kept across the street.) An eerie orange glow -- and lots of smoke -- is visible above the rooftop. This looks bad. We learn that something in the compressor room caught fire or exploded. Fire spread upward quickly. Most importantly, everyone got out without any injuries. 8:35 PM
Our T1 provider calls my cellphone. These are really, really good folks. I answer, as I'm standing next to a noisy fire truck. ISP: Hi. Just calling to let you know that your T1 is down and we're looking into it. Me: Hmm. That might be because it's on fire. ISP: Uhm, did you just say it's on fire? Me: Could be. There's a fire in the building and we're not allowed in just yet. Plus the electric company is trying to cut the power. ISP: OK then, I think we're going to assume the problem is at your end for now. This sounds bad. I know the I.S. dept. still has UPS power, since the phone system attendant is answering. But if the T1 is down, it seems that it must have burned up (its run goes very close to the affected area), and taken some phone lines with it. 9 PM
It's below freezing already, and I didn't bundle up very well. Several waiting -- but unused -- ambulances are nearby and the paramedics invite those of us waiting inside the heated vehicles. 9:30 PM
The CEO and CFO are permitted to tour the building with a firefighter. Word is that sprinklers have come on and there's water in the I.S. dept. This is potentially really bad news. The I.S. dept is in the basement and water has been a problem before, so we're prepared, but water and computers are never a good combination... After a little while, we are allowed inside as well. There is 1 to 2 inches of water on the floor in the basement, but fortunately nothing has reached the raised floor yet. The fire department supplies an AC generator to power the sump pump, plus 6 squeeges. We supply 6 people. We keep on the squeege duty until about midnight. Meanwhile, it turns out that a water pipe broke out in the shop near the fire. Water gets shut off. But the floor up there appears to unfortunately slope towards the staircase that leads to the basement. Water is coming down fast. We find what we can to block the path, and that seemed to just make the collection deeper. I periodically try to find someone that can bring a pump and a generator -- or something -- to help this get cleared up. Midnight
I head home. The water situation is improving, but not resolved yet. Others remain. Once home, I post a notice on our public website saying that our power, Internet, phone, and FAX lines are down. You just might have a problem reaching us. I also e-mail some consultants, saying that the reason the VPN doesn't work is that we had a fire. I also e-mail the new I.S. person who has an hour commute and advise him of the situation. Our fire was top story on one of the local newscasts. We watch the video of it, sigh at the annoying "on the scene" reporter (motto: "things were interesting an hour ago"), and turn in. 1AM
Time to sleep. Tuesday
6AM
Get up, in to work by 6:45. Everything is dead. No power, no water, no phones, no heat, no gas. Also, fortunately, no more water coming down. I call the other I.S. developer and tell him not to bother coming in right now, but maybe we'll call later. 8:30 AM
An impromptu meeting happens. The CEO sets communications as the #1 priority: phone and basic Internet access. Plants 2 and 4 have working power, so if we can bring up some servers and network gear on a generator, computers over there will work. No water in plant 1, where my office is. So nearest restrooms are a 5-10 minute walk through dark and damp areas. Bottled water, coffee, and donuts appear at the halfway mark to the restrooms ;-) 9:00 AM
Generators start appearing near the I.S. dept. After getting them powered up, proper extension cords found, etc., we start plugging in the phone system. Power strip 1 works. I flick the switch on power strip 2, and it all goes dead. This generator's circuit breaker keeps doing that every time we try to turn on the phone system. So we try generator #2. Phone system finally powers up. But all incoming lines are ringing at phones in sales. Volunteers go up to answer those phones. Meanwhile, phone tech shows up, and orders his own, larger generator. I call our person that's an hour away and tell him to go ahead and head in. 10:00 AM
Now we turn to the computers. We're going to have to be careful what we bring up so we don't overload the generator (and thus have an unclean shutdown on anything that's already up.) I recable power to some switches, our T1 router (ISP calls: the T1 just came up! yay!), and our firewall. Flick the switch on firewall. Generator stays up. Firewall emits a high-pitched whine. Eeep. Flick the switch again! After checking things out, we adjust the voltage a bit and determine that things are generally OK. I run the firewall on one of its two power supplies. At least if it burns one out, we can still run it off the other later. Turn it back on -- whines again, but it goes away after a few minutes. Phew. Next step: our main Linux file server. Flick the switch, and there's a satisfying "whoosh" from the fans. Excellent. Our developer shows up and observes later: "John, this was odd. When I got here, there were 7 guys standing around watching you boot up machines." 11:00 AM
Decision time. Our main ERP server is an AIX box. 8U. About a dozen disks. Certain to be a large draw. Can the generator handle it? Yes, it should. Should we power it up, given that it takes 45 minutes to come up and 20 to go down? We opt to try. I cable it up and press the power button. Nothing happens. But that is normal for AIX. After a few minutes, we start seeing hex codes on the LCD. A few minutes later, disks start coming up. All looks good... 11:15 AM
Orange alert lamp comes on for the AIX box. Uhoh. Turns out one of the drives in the RAID is bad. Time to call IBM, but at least it's mirrored to the box is up. IBM service calls are always "fun" for this. I spent a total of about an hour on the phone with them, 90% of which was spent with them analyzing error logs trying to find out what exact part number to give is, and 10% spent trying to look up our account information. Plus, the phone guy is now switching the phone system to his genset. He tries to hook it up through a home-type UPS, which is giving him fits. I get disconnected from IBM at least twice. Noon
My supervisor goes to Subway and brings in lunch for all four of us in I.S. since we don't really feel like we can leave. Word arrives that the generator that's powering the servers is leaking oil. Eeep. But it should be good until evening. On the plus side, the generator will automatically shut itself off when it runs out of oil. Won't damage itself. 1PM
IBM calls, trying again to get information about what exact part they need to bring out. Only 29 minutes on the phone this time. Word arrives that a 60kW generator has arrived that they will attempt to hook into the mains supply for the building. The main power distribution center has been burnt. Plus we aren't allowed to touch large parts of it since fire inspectors and insurance adjustors aren't done yet. But no ETA on the big generator. We make a preliminary decision to cut power to computers & the network at 5PM, and maintain the single phone system generator overnight. 2PM
Local IBM rep calls. He'll be out between 3:30 and 4. I say that'll be fine, but warn him that if he's any later, the power may be down. 3:45PM
IBM rep shows up, replaces the dead disk. It works. Whee. 4:15PM
I start powering down the AIX box. We then learn that ETA on the big generator is 5PM. So we start shutting down other servers as planned. 5PM
Big generator comes up. It works. We slowly bring up our systems. Everything is good. BUT -- we are basically maxing out the capacity on the generator. People will not be able to just come in and work like usual tomorrow. We'll be meeting in the morning to figure it all out. 6PM
We post signs at entrances warning people to not turn *anything* on. Finally head home at 6:30.

Yay. Ruby on Rails 1.0 has been released 39 minutes ago. I will probably check it out for real now (although I usually use Drupal for web development work, of course). They sure have some funny quotes on their website ;-)

Ruby on Rails is astounding. Using it is like watching a kung-fu movie,
where a dozen bad-ass frameworks prepare to beat up the little newcomer
only to be handed their asses in a variety of imaginative ways.
--Nathan Torkington, O'Reilly Program Chair for OSCON

(via mir.aculo.us)

Steven Vaughan-Nichols: “Over in the land of LAMP (Linux, Apache, MySQL and the scripting language of your choice that begins with P), they’re discovering that backward compatibility is a bear. Welcome to the world of serious software development.”

Josselin Mouette has thrown down the gauntlet -- Subversion is the One True Revision Control System and we should all just Stop Worrying and Learn To Love The Handcuffs. In particular:

[...] just use subversion, and if you feel it's missing features, please contribute them. By standardizing on subversion, we lower the barrier for people wanting to contribute, instead of increasing it by asking them to install and understand new tools.

Quick thought experiment, Josselin: replace "subversion" with "Java". Or "Perl", or "C", or even "Python" or "Ruby". Or any other language. It doesn't matter which one. Even if the language you substitute is a good one, and one you happen to like, it's still a fairly obviously braindead idea -- that there can possibly be One True Programming Language for all problems, and that there can never be any improvement that can't be bolted into the existing OTPL. Revision control isn't so much different from programming languages. Different systems will provide different advantages and disadvantages. There's also incremental and revolutionary improvement that will take place over time -- machine code to symbolic to procedural to object oriented -- that can never take place within the established framework. I happen to really like the distributed model -- it reduces (though, naturally, cannot eliminate) the division between the Blessed and the Peons in a project (those with direct commit access vs. the rest of us). You can get disconnected operation for (almost) free. Also, despite the assertions contained in your article, the "barrier to entry", ironically, is actually lower with a good distributed RCS than with Subversion. The barrier isn't what you think, though -- sure, using an unfamiliar RCS is troublesome, but it's a lot less hassle than learning a new language, and people do that on occasion to hack on a particularly interesting problem. The real barrier to entry is forcing anyone who isn't blessed with direct access to The One And Only Repository to use inferior development support tools. "An example!" I hear you cry. Gladly. This morning (literally) I got enough of a handle on the internals of Ruby on Rails to actually track down a bug that was irritating the crap out of me. Being a good developer, I wanted to use revision control to track my changes. In the All Subversion, All The Time "utopia", that would involve getting an anonymous checkout, making a copy, hacking on the copy, then (when all was done) running diff -urN between the original and the copy, and sending it all upstream with a manually-created log message (assuming I could remember everything I'd done). You also need to manually remember (or encode it in your directory or something) the source of your tree, so upstream can merge it reliably (and compare it against other equivalent work that may have been done in the meantime). Doing it better, I could do an anonymous checkout, and then import it all into a new Subversion repository (or directory) of my very own, and hack on it in there. Benefit: revision control of my changes. But it's non-trivial to create a new repo and import everything into it, and there's still no automatic record made of the upstream source of my new repo. Wanting to make a second change is even worse -- I either have to make a whole new copy of my source tree (disk is cheap, but this is getting silly) or just keep forging ahead with changing my existing tree -- so this second set of changes can end up being dependent on the first (which is Not So Great if upstream don't merge your first patch). In the "new repo" scenario, you can branch from the root of your new repo and continue hacking on your newly created branch, which is a good start, but it's still icky. And good luck having the system track new commits from upstream while you're working, too. If the project was using a DRCS, in contrast, the problem would reduce to making a branch into your local archive, hacking (committing at will), updating with new upstream commits as you go along, and then publishing your changes to a public place for reintegration (or, in some cases, sending your changeset via e-mail). Oh, and before anyone starts screaming "if anyone can branch, it will encourage forking!", consider which is more likely to result in a permanent fork (rather than a temporary independent line of development): a local set of changes in a tarball or local subversion repo, both of which are hard for anyone else to collaborate on without major pain; or a branch in a simple-to-publish (or push) designed-to-be-shared DRCS archive, which automatically keeps all of your interesting metadata intact and coherent across archives, merges, time, and space (and possibly even dimensions). This utopia doesn't really exist, and is hampered by everybody having their own Pet DRCS, but the problem, I'm fairly sure, is transient, and my main point isn't even so much against the choice of Final Ultimate Solution, or even the problem space, but more about the attitude that everyone should get behind Any One System and stay there. I can't imagine the world of pain we'd be in if Josselin had posted his message a few years ago (but with s/subversion/CVS/i, naturally) and everyone had followed his advice -- can you imagine per-file changesets with no effective merge capability for the rest of eternity? <shudder />

SableVM SDK 1.13 released! The most important change in this version is the update of the class library to the GNU Classpath 0.19 release. The difference in usability is huge, because SableVM SDK 1.12 used GNU Classpath 0.16 and since its release there's been plenty of improvements to GNU Classpath (Swing being probably still the most visible to a user). Way to go guys! SableVM SDK is meant as a relatively complete replacement of a Java Software Development Kit. An important goal is also the ease of installation. To achieve it all the separate software pieces have been integrated into one source archive that (once its build-time dependencies are fulfilled) can be simply installed all at once. Just a short reminder about what's inside:

• SableVM and SableVM Classpath (based on GNU Classpath 0.19)
• CP-Tools (javap, javah, serialver, ...)
• Fastjar
• GJDOC (javadoc drop-in replacement)
• Jikes
• LibFFI and LibPOPT (now part of SableVM)

Have fun with it! And don't forget to let us know of your experiences!

Christian, you're so right. If you want to contribute to 3 projects, you now need 3 revision control tools. I pledge developers to use centralized tools like subversion. Even more: just use subversion, and if you feel it's missing features, please contribute them. By standardizing on subversion, we lower the barrier for people wanting to contribute, instead of increasing it by asking them to install and understand new tools. Development with so-called distributed revision control systems is just like these RCS themselves : a complete mess.

Just reading the comments associated with a post from the reddit.com people about a rewrite of their entire site from Common Lisp to Python. The Lispers are screaming "noooooo!", the Pythonistas are grinning smugly, and the Rubyolas are asking "why not us?". In the middle of it all, comes this gem (unfortunately, posted by "Anonymous", so no attribution):

Real men would design a custom ASIC and write a new FORTH system optimized for Reddit, complete with custom developent environment, web server, etc. It would multiply the development time-to-1.0 by about 2-4x, but the entire system would be smaller than the ethernet plug, would handle a saturated gigabit pipe with sub centisecond latency, never crash, and use less power than your toaster. Everyone would be too busy saying "WTF is FORTH?" to bitch about you not using Ruby on Rails. Then you'd lose to the guy who did it in PHP (*turn* *puke*), because it's not about the technology, stupid.

Never one to miss out on a good fad, I've recently been getting interested in Ruby on Rails. (OK, maybe it's not fair to call Rails a fad -- it looks really good -- but it is the Tech Of The Moment). What's the first thing you do when you hook onto a fad? You find the relevant blogs. Handily, RoR (as the in-crowd calls it) has a Planet-style aggregator, Planet Ruby on Rails. Less handily, the site is running a *very* half-arsed aggregator script that doesn't escape any of the HTML in the entries, so Liferea summarily spits the dummy at them all and I see nothing but titles in my viewing window. I sent a polite (yes, really!) e-mail to the site admin, asking if it might be possible to get an escaped version. I haven't had a response in a few days, and a lot of the entries look really interesting. So, I've installed my own local Planet RoR aggregator -- running The Real Planet. Planet is astonishly easy to install -- 3/4 of the work was writing the shell script to take the OPML from the original Planet RoR and massaging it into Planet config.ini format. So now I have Real Articles to read again. Life is good.

This is the new hype of last years. No development can take place with these so cool tools. Crap, I just maintain the bloody localization for apt and dpkg and, as the developers of these packages use distributed revision control systems, I'm forced to use them as well. I have never lost so much time in fixing broken stuff in my archives. OK, I'm a moron certainly but I use RCS things for several years right now (the old CVS/SVN and the like with a centralized repository) and I HAVE NEVER LOST SO MUCH TIME since I use tla, than bazaar. More fun: it seems that baz is getting obsoleted by bzr right now as obviously geeks cannot live more than one year with the same tool. So I will have to convert my archives if I want to continue helping in apt/dpkg localization. Of course, I know that people will help morons like me to do it, but, hey, this will AGAIN be lost time. Thanksfully, the D-I developers are wise people and we don't use distributed RCS but a good old solid SVN for 3 years now. Frans, Joey, don't ever think about changing this, please.... So now, I'm left with a change that I can't commit in my local archive for a French man page of dpkg, as suddenly for no reason, the bloody baz complains:

A/  arch /dpkg/dpkg--devel/dpkg--devel--1.13/philippe.batailler@free.fr--2005
A/
 arch /dpkg/dpkg--devel/dpkg--devel--1.13/philippe.batailler@free.fr--2005/patch-log
A
 arch /dpkg/dpkg--devel/dpkg--devel--1.13/philippe.batailler@free.fr--2005/patch-log/patch-1
M  man/fr/dpkg.1
M  debian/changelog
M  ChangeLog
arch_commit: unable to acquire revision lock (could not rename file.)
tree: /home/bubulle/src/debian/dpkg/dpkg-1.13
revision: bubulle@debian.org--2005/dpkg--devel--1.13--patch-88
url: /home/bubulle/arch/bubulle@debian.org--2005

So nice: I'll again waste precious time asking on IRC for help and hearing people telling me to switch to <insert your favorite RCS system here>. This will be a so wonderful Sunday....

The premiere is over. It's a great piece, and I'd have loved to see more of it rather than attempt to fix broken light equipment during the show.

08:02am: Decklin Foster mentions dropping FreeDB in favour of MusicBrainz, and abcde in favour of jack. 09:48am: I wonder if adding MusicBrainz support on abcde would be a bad idea. 05:20pm: Decklin Foster points me to a python script which provides the needed interface. 2 years later: I add MusicBrainz to abcde. No. Just joking. I will work on it during the next few days. Or in debconf-es2. Cheers!

Last days have been quite productive for Backup Manager and I’m glad to see that all the development phase seems to be finished in the SVN repository. As you can see, we’ll be able to release the first stable version of Backup Manager (0.6) as soon as the user guide is written. From the code tree point of view, all the known bugs are closed by now and requested new features implemented. I put all my energy in the user guide now, and hope I could fine some english native speakers soon… I don’t plan to release a new debian package for the last 0.5.9x versions, the next debian package will be 0.6-1, and it will be backported to sarge if needed.

In Debian, we work on developing a unix-style operating system, and when the project was getting started, the obvious way to deal with delegating powers to various people was naturaly to use standard unix permmissions on our master server. So the list administrators were the only people who could write to the list configs and archives, the BTS admins were the only ones who could write to the BTS, the archive admins were the only ones who could manipulate the archive, the build daemon admins were the only ones who could modify various bits of that stuff, etc. As time went on, these services were split off to seprate machines and in some cases access to the machine running a service was limited to the maintainers of that service, again in a way that would be familiar to unix admins everywhere. But as time went on and things like revision control systems became available, Debian also began to make some choices that didn't involve unix permission or host based security. The best example of this is the Debian bug tracking system, which allows anyone to manipulate any bug status in any way without any authentication at all. It works because the BTS keeps a record of all changes, and informs interested parties about changes, so vandalism or accidents can be reverted. Aside from spam, vandalism in the BTS is such a rare problem that I cannot think of an example. Thus the Debin BTS partakes somewhat of the WikiNature, although it predates the wiki by a long time. The archive itself only uses unix permissions at its core, while the upper layers do not partake of them: Any maintainer can upload any package and superscede data in the archive automatically, although actual unix write permissions are very limited. The archive administrators use archives of old versions of packages, automated checks, and forced manual review of certian classes of packages (such as NEW) to limit this so that Developers don't make messes. Social norms are used to avoid other problems. The Debian website is in an interesting period in its history. It's been maintained in a way that mostly avoids unix permissions for a long time, by keeping it in CVS and building it automatically. However, for reasons that I suspect have never been adequately explored, not all Debian developers can commit, you have to be in the webwml group. Though gaining access to the webwml groupo is trivial for any Debian developer. But the most interesting thing is that Debian now also has an official wiki, which is open to editing by all, and that increasingly it is used for at least the more fluid and development-based website stuff. For example, the debian-installer home page is a thin stub giving the essential information and links, and mostly linking to the wiki for the rest. The debian-installer project itself occupys another point on the scale between locked down unix permissions and free modification by all. People have to get an alioth account and demonstrate basic competance to get debian-installer write access, but don't need to be Debian developers or spend more than an hour or so to get access. Once you have access, you can change anything in svn (and everything is in svn) we don't limit write access to parts of the project. We avoid malicious commits through patch review. I could give many more examples of subsystems in Debian that exist at different point in the spectrum between locked down unix permissions and a wiki. There seems to be a definite pull toward moving away from unix permissions, once ways can be found to do so that are secure or that allow bad changes to be reverted (and blame properly assigned). Cases of moving in the other direction are rare (one case of this is the further locking down of the Debian archive server and BTS server after the server compromise last year). Anyway, the point of this is that, if you survey the parts of dealing with the project where Debian developers feel most helpless and unempowered, the parts that are over and over again the subject of heated discussions and complaints, you will find that those are the parts of the project where unix permissions still hold sway. This can range from simple cases such as a cron job that only one person can look at and modify[1], to various data files that could perhaps be kept in svn, but aren't, all the way through to stuff like the Debian keyring. I would love to see a full list developed, although many of the things that remain are obscure little corners like certian blacklists in the BTS, bits of the buildd infrastructure that only a half dozen people know about, etc. The challenge, then is to find ways to open things up to everyone, without throwing security out the window. It has to be done a piece at time, and some of the pieces that are left are the ones most resistant to this change. I hope that people can keep this progression away from unix permissions in mind while working on Debian infrastructure. (If I ever ran for Debian Project Leader (which I won't), this would be one of the areas that I would be sure to investigate basing my platform on. Speaking of which, it's nearly election season again, isn't it?)

---

[1] The best solution I have found to this common problem so far is simply to keep the cron job in svn with everything else, and if someone modifies it, review it and update it via semi-automated means (some simple command). There are probably better ways to do it.

In 1999 I went to LinuxTag as a Debian representative after the project has received an offer to staff a booth there. I took over the maintenance and organised the first Debian meeting in Germany. I also gave two talks during this event, one of them was even repeated on the second day. We've had a lot of fun and since this was the first meeting of Debian affiliated people in Germany, it was very interesting to connect faces to mail addresses and to learn more about the people behind a name. This LinuxTag was the last such event that took place at the University Kaiserslautern. Free projects such as KDE and Debian have been offered a booth in one building from which one could reach the lecture rooms, while company booths were located in the Mensa building with their own professional booths. It was a warm weekend and the Jolt people have supported us with cool and caffeined drinks. We had the opportunity to use a lecture room for sleeping with other project members. Klaus Knopper was supporting the network and supervised the security team, and hence, had the unfortunate job to move away all project members from their booths, out of the building or into the lecture room. I've heard, that he had a hard time, and still believes that Debian people don't need sleep. I guess we should have moved him into the lecture room for a sleep instead. This '99 LinuxTag was quite a real success. It took place at the rise of the dot com era and all people were happy about the event. There were about 7,000 visitors in total on both days. The city of Kaiserslautern has called the university several times since there were no free hotel rooms anymore. Former events happened more or less unnoticed by locals, but not anymore in 1999. After the show was over, we dismantled the booth, moved away our own equipment and left the place. However, I made the "mistake" to notice that the LinuxTag people, who have provided us such a great opportunity, still had work to do since they had to dismantle the booth system and clean the ground floor. My biggest "mistake" was that I didn't run away and have a nice evening but decided to help and ask other booth members who were still around to do the same. Having cleaned up the location quite fast was not the only result. Oliver Zendel, who was in charge of talking to the community and who offered Debian the booth, spoke to me afterwards and wondered whether I would be interested to join the team. Well, I knew how to organise stuff, can talk to people, know quite some people in the community, the LinuxTag people were a cool team, so why not. So for the event in 2000 I was in charge of the projects exhibition. In 2000 we also had to move out of the university of Kaiserslautern since 7,000 visitors were already too much for that small university and city. That's why we eventually moved to the Stuttgart fair. That was an interesting experience. It was also interesting to see how such an event can be organised by a team of friends and how the acceptance in the business world was. In Stuttgart we were able to use a small office (max. 15m ) for the entire team as working space. Two computers were installed which we were allowed to touch but not to install a real system on. Hence, Klaus brought Knoppix CDs. This was the first time that I learned about the Knoppix Live CD. Together with my notebook we've had three desks and could work. However, today I really wonder how this could have worked with so many people, but apparently it really did. Due to the need and my experience in both talking to the press and being the press I joined the LinuxTag press team and even held the final press conference, while my colleague held the opening press conference. So after all projects were happy, the show went fine and most of the office jobs were done, I prepared a press release together with others and maintained the final conference. This was also the first time LinuxTag has organised a business congress as a special extra program for business representatives. It was also the time I experienced the need for several supporters for various tasks. In that year, a dozen supporters were paid as "security" who also drove the shopping for us. Hence, I already acquired some people who supported us as volunteers. That was also the time when Benny joined the team. In 2000 the exhibition boomed and there were a lot of large dot com company booths, which was very nice because LinuxTag arose from a students association and became more and more professional, a platform for both companies and projects. It was organised just like a Free Software project and worked non-commercially. Despite several flame wars and disputes, which seem to be normal, it was organised by friends who believed of a higher goal. It was very nice and gave me a warm feeling when looking at what we have achieved. However, I had nothing to do with commercial interests, income, acquisition, invoices etc., so I may have missed a lot. This year, LinuxTag was planned to take place in one exhibition hall, but there were so many companies interested in running a booth that a second exhibition hall was later rented as well. That's why there were two adjacent halls instead of one large location. In 2001 we were using a different exhibition hall, a larger one due to the strong demand in 2000, but still at the Stuttgart fair. This time I was also in charge of the supporters and already dispatched jobs during the event. From time to time I also maintained the shuttle service to the airport to pick up speakers or take back speakers, which I've also done in 2000. This time we've had a larger office in which all of use fit and which was a nice working atmosphere. We were also able to provide more booth space to Free Software projects. In that year I've automatically taken over the office and communication with the outside world, collecting and distribution information. I don't think this was planned, but it just happened since I was able to do the job besides my other obligations. I also gave a talk about Debian, even though others in the team considered me insane for doing that as well. With a lot of help by the local user group, we were able to offer project members a cheap sleeping opportunity. The LUG acquired a gym hall during the night an cooked in the student's office "Hellblaues Nilpferd". After I've picked up Hans Reiser I went there for a snack with him before dumping him at the hotel. It was a nice atmosphere. One of the lead people for this effort, Hubert Kai er, was suddenly overtaken by death two weeks ago. In 2002 LinuxTag moved to Karlsruhe and thus to a new fair where everything had to start again from zero. We had to get acquainted with the local company and their representatives and learn how the new fairground works. The fairground was more interesting since there was a large open area between the conference site and the exhibition hall. Looking at past years, it was used by visitors. Thanks a lot to Jochen Topf from GUUG and members of the local user group KaLUG a lot of community events happened during LinuxTag. They maintained an Internet caf in the conference building and organised the legendary KaLUG party which has become a regular LinuxTag event. In addition to that I've also worked more and more and took over more areas where I noticed help was needed and that I could manage it. So it happened that I took over more work at and before LinuxTag which finally resulted in two months of work were I don't remember a day on which I've worked less than 8 hours for LinuxTag in 2005. In 2002 I worked on the coding marathon and delegated the tasks and support during LinuxTag to two other people, so it will run independent of me. Since I was the first of the team to arrive in Karlsruhe, I also built up the office and the storage. Due to the large distance I had to leave Oldenburg the day before I want to arrive in Karlsruhe, so that I was at the fairground at last at 10 o'clock on Sunday morning. Before the event a lot of issues had to be negotiated with various parties, which required quite a lot of work. Until 2004 the entire team was working in their spare time without getting paid for their LinuxTag work. The higher goal was the impulse and all of us had neglected one issue or another that wasn't important for LinuxTag. We've had some external service providers at least since 2002. The acquisition became a difficult task for students who liked to work until the morning and get up at lunch time, since many companies expect a partner that is available for them from 9 to 5. That's why Charter was eventually hired and this year ergomedia. For press work newthinking was hired. This year the social event was also organised by them. However, having two people from the board of directors being paid by the association for their LinuxTag work from April, and external service providers that were also paid, was something I considered problematic if not unfair, looking at how other people commit to LinuxTag and don't get a monetary compensation. Several people still worked a lot on LinuxTag in their spare time and had to live from something as well. It caused resentment in the team.