Only if the attack's for the benefit of the sysadmin or their employer, as far as I can tell. All-party Parliamentary Internet Group had links to legislation/regulation:

• the Computer Misuse Act 1990 doesn't make this explicit;
• Cybercrime Convention says a person can be held liable for crimes committed for their benefit made possible by lack of supervision (Article 12) and also lets you be slapped for withholding evidence;
• the EU Framework Decision on "Attacks Against Information Systems" echoes this (Article 9).

The British and Irish Legal Information Institute didn't let me find any cases with computer misuse AND supervision. Using "lack of supervision" alone finds common sense use only. So it seems to hinge on supervision. I hope that you have to do something pretty obviously daft to fall foul of a court on that. I guess that you shouldn't let a server managed by you run totally unattended, but if you take normal precautions (firewall, logcheck, intrusion detection and so on and actually review them), the admin should be OK whatever. If someone's just using your computer as a jumping-off point for random attacks, I don't see how that's for your benefit either. I think that wording might be to discourage evil businesses having teams trying to deface competitor sites and so on. There's probably a bigger danger from copyright and trademark infringement accusations IMO. I am not a lawyer. Check the above yourself or consult a lawyer about it. If you do and have updates, can you let me know, please?

grep-dctrl has proven, at least for me, an utterly useful tool; I suspect this will probably be the case for many others as well. (As I side comment, I believe it’d be nice for AMs to make sure their applicants do at least know about the existance of grep-dctrl, and ideally have basic knowledge about how to use it.) Many times, though, using its grep-available form is not fine-grained enough, and one needs full control over the distribution to make the search in. A valid workaround for this is to run grep-dctrl over /var/lib/apt/lists/whatever; I’ve been using this for some time now, with shell aliases like grep-sid or grep-s-etch (for sources), but sometimes I wanted a grep over two dists, or several components (e.g., main and contrib), or a set of arches. For this, I decided to write a grep-dctrl wrapper that, relying on the structure of a normal mirror, allows to run a search over any combination of dist/component/arch. At home, where I do not have a local mirror, I have populated /org/ftp.root/debian/dists with a pool of symlinks towards /var/lib/apt/lists, and whenever I need more than i386/source, I can run it on any debian.org machine with a local mirror, e.g. merkel. For example, to know which packages in sid but also present in testing are still kdelibs4c2a-untransitioned, but ignoring hppa and m68k, I’d run on merkel the following:

  % grepd sid:main,contrib:alpha,arm,i386,ia64,mips,mipsel,powerpc,s390,sparc \
          -Fdepends -e 'kdelibs4(c2)?(  , $)' -ns source,package  
    unique-sources   xargs madison -s testing   awk ' print $1 '

In case somebody finds it of interest, the script is available here, together with the dirty hack that is unique-sources, needed since not all binary packages have a Source header (sigh). NP: Jacques Brel, Au suivant

This time tomorrow I'll be on a plane heading to Israel in a circuitous route for a much needed vacation in Israel. It appears that the weather in Israel had turned from sunny and hot into a real winter so that we won't feel too bad comparing the weather of Israel and Ireland. The Haaretz forecast says there will actually be rain, of which I had enough here. We will escape the empty Maynooth of Christmas for the split personality (Rehovot/Carmiel) of Hanukka with the families, for some much needed stuffing with home-made Sufganiyot and other not-necessarily-related-to-Hanukka foods. A union with a newly purchased Canon 350D is also much expected :-)
This will replace a Canon Elan7 film camera of which pictures that the local development shop manages to screw the image scanning and creates washed-out colours.

I can definitely see that, when Wesnoth 1.1 is out, it will cause a new decrease in productivity in Debian. PS: Not really. Fhew! PPS: Other suggestions were: Frozen Wesnoth, Frozen Budoku, or worse: Wesnoth Budoku.

I've still been extremely busy. Unlike my last fairly incoherent brain dump, this time I've been keeping notes on the things I wanted to write about, so hopefully I won't forget things. Here we go...

Squirrels

Squirrels are absolutely everywhere. They're very fast and very cute. They're kind of like possums, except diurnal. They run up trees with ease, and leap from tree to tree. It's quite cool to watch them. The damn things don't stand still long enough to be photographed (properly), and they don't let you get too close without scampering up a tree or running off. I'm told they're the number one carrier of rabies, so I shouldn't be trying to get too close anyway.

Sales tax

Definitely one of the more annoying aspects of consumer life is the fact that prices quoted are not inclusive of sales tax. This means you always need to part with more cash than you expect. Furthermore, there are some places (some fast-food outlets) that do quote the prices inclusive of tax, so it's really hard to know what you're in for.

Speed limits

I find speed limit signs to be either infrequent or harder to notice, or a combination of both. They're just a black text on white background sign. I'm used to them having the red circle. That said, no one seems to drive at the speed limit anyway.

Ethnicity

Canberra's a very white town compared to say Sydney, but I reckon at least the San Jose area of California blows the socks off what I've seen of Sydney for multiculturalism. You really notice it over here. I've been at the mall in Milpitas, and you can play "spot the white European" (a variation of "spot the Caucasian").

Different responses to thankyou

I think the fairly standard response to saying thanks that I'm used to is "You're welcome". Over here, you get "mm hmm" a lot, which is just strange.

Fractions vs decimal

They love their fractions. Petrol gets quoted at 221⁹/₁₀, which took me a while to realise was 221.9 cents per gallon

Alcoholic beverage labelling

Australia has the concept of a "standard drink". I remember as a kid the advertising campaign "rethink your third drink" (or for women, "rethink your second drink"). The idea being that men could drink two standard drinks in the first hour, and then one standard drink every hour after that, and be at 0.05% blood alcohol, which is the legal limit for Australia. And every bottled alcoholic drink is labelled with how many standard drinks it is. An average beer is about 1.2 standard drinks for example. No such labelling over here. You get the percentage of alcohol per volume, and that is it, which makes self-regulating very difficult. The limit is apparently 0.08%, but I don't think I want to be driving around on the wrong side of the road at that level (or any level really).

Christmas vs "Holidays"

Everyone and every piece of advertising goes on about the "Holidays". Retail people are always wishing us "Happy Holidays" instead of "Merry Christmas". I think this is because there's a large chunk of people who don't necessarily celebrate Christmas.

Tipping

I haven't really come across tipping in everyday life as much as I'd expected, but when I think about it a bit, I'm at work most of the time, so that's probably why. The general rule seems to be to tip "double the tax", so for a bill at a restaurant, or where you get personal service, such as a haircut, you tip. But you don't tip at McDonald's, nor Subway (where I would have expected you would).

That's about all my current observations on living over here. Tomorrow we get our townhouse in Central Park. Our air-freight was finally delivered today. (What was supposed to take about 8 days took 4 weeks). Not sure when we can expect our sea freight at this stage. We bought a couple of mountain bikes last weekend, and if the weather is okay tomorrow, we'll pick them up and ride them home. We've found a really nice off road (as in not shared with cars) bike path, which runs close to home all the way to work. I'm really keen to roller blade to work if it's feasible, and also to cycle in. I'm a bit disappointed to discover after we've been accepted for the place that we're right on top of a toxic waste dump (or something like that). If I grow a second head, you'll know why. The other piece of exciting news is that the bank sent me a debit card, when they'd previously told me they wouldn't until I had a Social Security number (still no sign if that yet). This thing (the debit card) is freaking weird. It's Mastercard branded, and in some places you use it like you'd use a debit card for EFTPOS back home. You swipe, enter your PIN and that's it. In other cases, you swipe and sign a bit of paper like a credit card transaction. In either case, money is sucked out of our checking account. The scary thing is that no one seems to check signatures in this country, and a lot of places will accept credit card payments electronically (like petrol stations where you just swipe the card at the bowser and enter the ZIP code of your billing address and that's it). Oh, and I can use this thing like a credit card for Internet purchases. What bothers me is that the level of authentication is so low, but it's sucking actual money out of our checking account, so with all the credit card fraud around, it's relatively trivial to draw actual money out of a bank account, as opposed to using someone's credit. That said, I just got the card today, and since then, it's made shopping so much easier. It's amazing how many places won't accept a foreign credit card, and I was a big user of EFTPOS back home, and this ability to use a debit card like a credit card means I can essentially continue in that habit. I wasn't looking forward to carrying lots of cash or having to use cheques.

The latest buzzword acronym, AJAX, is getting on my nerves. Javascript is not cool. It's an annoying, slow language. If you have ever written code in Python or Ruby or Lua, you'll agree that the syntax and library sucks. Usually I'm annoyed by the long loading times of Ajax, so please use it only where it's absoultely necessary. I agree that google maps is cool, because the alternatives would have been an even slower pure html version, an annoying flash which doesn't work properly (say hello to 'new' yahoo maps) or a very slowly starting java applet. I watched the Ruby on Rails and TurboGears intro screencasts today, because I wanted to find out how these frameworks are like to work with. The part I liked least was then in the turbogears screencast they did that pointless ajax thingy, writing javascript code and such... I liked the template engine of turbogears, python "kid". Thats a really nice XMLish template language. Read: proper XML, XHTML. Ruby on Rails templates had this ancient eperl feeling to me. Also kind of PHP like, but not as worse. In contrast to PHP you can actually parse it. Still, you can't properly validate your XHTML template files. So I'll probably try out TurboGear sometime soon, and if I'm not happy with it maybe Ruby on Rails next. I'm very happy to see these new frameworks for free languages. I heard a lot about Java Frameworks recently, but they all seemed so overengineered, and then there is this Java annoyance... A python or ruby solution is much nicer there.

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?

Ah, Novell have released an initial report comparing the DBus and CORBA ports of EDS. As the author of the DBus port, I should make some observations. The incorrect reporting of large numbers of contacts in a book view is very odd, and I've not seen that before. I'll try and replicate that locally, I did change some message limits so maybe they are being hit. Occassional dbus_g_proxy_cancel_call assertions are known to happen. I've a potential fix locally, but it requires a patch to DBus, which hasn't been committed yet. Now to the benchmarks. The primary optimisation target for my work has been in the book views, as these are the primary bottleneck in a real-world application. This is visible in Test 1, where the DBus port takes 17 seconds compared to 72 seconds for CORBA. A number of the optimisations I've made can be applied directly to the CORBA code too, and are currently sitting in Bugzilla. Test 2, calling e_book_get_contacts() is interesting. It may be that verbose mode is enabled in DBus, which has a serious performance impact on large messages (and this is a very large message). Alternatively this difference may simply be due the message bus, which adds a layer of IPC (and thus string copies) which CORBA doesn't have. As very few real-world applications (I'd say none) use this function (it blocks the interface unlike book views which are asynchronous), this isn't a very meaningful benchmark in the scheme of things. For the calendar, there has been no performance turning done at all. It's known that the calendar port to DBus isn't quite complete, and needs cleaning up and performance work.

The GNOME team has been sitting on top of ready-to-go GNOME 2.12 for way too many weeks now, but unfortunately a series of planned and unplanned transitions affecting unstable prevented us from moving them from experimental to unstable. Today's good news is that these transitions are either going well (C++) or not at all (freetype upstream), so the release team gave us green light to start a fun GNOME 2.10 2.12 transition. There are a few aspects in this cycle that makes it a bit special and a bit more complex. GNOME 2.12 in experimental uses dbus 0.50, which is API/bus incompatible with the previous version in testing/unstable, so when we upload GNOME 2.12, the new dbus will go in too. As KDE is also using dbus in a few places, KDE and GNOME uploads will need to happen at the same time. To make it even better, dbus 0.50 has been obsoleted by 0.60, which is again API and bus incompatible with the previous version. The GNOME and KDE teams have agreed on the following plan:

1. The Project Utopia people have uploaded dbus 0.60 to experimental, and is currently waiting in NEW.
2. The mighty seb128 will upload GTK+ 2.8 and Pango 1.10 to unstable RSN, so our first version of GTK using Cairo starts to get broadly tested in architectures other than i386 and powerpc.
3. Once dbus 0.60 is accepted in the archive, the GNOME team will rush to recompile GNOME 2.12.2 against this new dbus, and test that everything is ok with the new version.
   At the same time, the KDE camp will upload their shiny KDE 3.5 debs, compiled too against dbus 0.60, to experimental, for the first time.
4. When everything has transitioned to dbus 0.60 in experimental, GNOME and KDE will be uploaded to unstable.
5. Vorlon will take a deep breath and will try to figure out how to get the two monsters in testing at the same time. Vorlon, we love you. :)

This looks like it'll take months to do, but I really don't think it'll be the case. We hope to be ready for a full GNOME 2.12 upload to unstable, at long last, pretty soon. As always, the brave can still use GNOME 2.12 in experimental with the usual aptitude -t experimental install gnome-desktop-environment. More updates as stuff happens!

h01ger thought that maybe I should clarify a few points in my blog. Well sure, I can do that. First of all, I think Joey does great security work. I am not attacking him for this. Second, I think Joey does a great job with Debian in general. However, I think he’s seriously harming Debian by not opening up and organizing the security infrastructure, and this is where my problem lies. I hope I’m getting this point across. There have been a number of attempts to revise the infrastructure and organization; a meeting in Oldenburg, where the testing-security crew attempted to get Joey to use their work; proposal(s?) by the DPL; AJ is now working on security queue stuff. I really do hope that Joey decides to work w/ AJ (or any of the other people who’ve suggested different ways to handle Debian security), for the sake of Debian. Joey keeps looking for additional manpower, and gets frustrated when people don’t contribute. Well, as someone who has attempted to contribute, and has seen others attempt to contribute, we get frustrated when our contributions are ignored (in the case of the kernel security update, the i386 and source packages apparently sat around for 4 months). Maybe if all this happened in the open, instead of amongst private emails (that often times go unanswered because Joey is busy), people might not get discouraged, and will continue contributing. I personally don’t think anything has been solved, and unless Joey is actively working w/ Branden or AJ in private, I don’t see any progress towards solving a problem that will require openness, organization, and trust. Manpower can follow after that.

It seems everyone is talking SCMs these days, usually touting their favourite option while deriding everyone else's. (I exaggerate for effect.) Years ago we mostly used CVS and were happy. Some people are still happy with it. I still have a bunch of code in it, though migrating it to something else is on my list. Why? Niceties like being able to rename a file. Or atomic changesets. Things that all the new breeds of options can do. For the tress I manage myself distributed working isn't a big issue, so they'll probably just get migrated to Subversion as the easiest option. However I'm not really tied to any SCM. I've used at least Arch (tla), BitKeeper, ClearCase, CVS, Monotone, PVCS and Subversion for both checking out and committing files, and handful more to check out files from things I wanted to look at. The only one that is unusable is PVCS. The rest have all been fine for whatever I've used them for. So, if I don't care about which SCM, why blog about them at all? Because I care about how they get used. I'm a big fan of small granular commits with descriptive commit messages. Not huge big dumps of code with "check in new code" as the comment. Gah. Take, for example, the Linux kernel. Commit messages are fairly descriptive there and if you have enough time you can read through the changelog since the last release and really know what's gone on. This is great. Also the changes are granular enough that if you hit a problem it's likely that you can narrow it down to a single commit that doesn't do a lot other than break things for you. Not all projects I have been part of manage either of these. People often seem to view the SCM as a punishment, using it only under sufferance and as infrequently as possible, leading to large commits of many items at once. Which then means they don't see the advantages of it and are more likely to hit merge problems as the tree has changed under them. Meaning they end up hating it more and avoiding it as much as possible, making it all worse. Not good. Or, you get people who'll commit alright, but without any sanity testing at all. Like, even a compile. What's the point? I know you can roll it back, but if you're not sure it works and haven't even compiled it, what the hell makes you think it's suitable for committing? Bah. I can't see that my desired usage is that unreasonable. Am I missing something?

Reading about California’s execution of Tookie Williams Monday night, it occurs to me that there are two categories of death penalty supporters:

1. People who don’t understand the legal system. If you’ve never sat through a criminal trial (or several), you can’t possibly understand the uncertainties in every case, including those cases that the press paints as “open and shut” (e.g, the O.J. Simpson Trial). Human fallibility permeates the process: the prosecutor, the defense attorney, the witnesses, the jury, and the judge. Sometimes it reduces to a question of whom to believe, and the legal process is not necessarily the most effective way to answer that question if your goal is to get to the truth. Sometimes “what happened” is actually pretty clear, but it still seems like fitting square pegs in round holes to match the facts of the particular case to the abstract categories set up by the law. The other thing that should be abundantly clear to anyone who has participated in or witnessed a criminal trial is that degrees of potential punishment have only a minimal impact on an individual considering a crime. For the most part, those individuals just don’t expect to get caught (or they aren’t thinking about it at all). I would be shocked if anyone could prove a crime was deterred because the death penalty was a potential punishment for the act in question, rather than, e.g., life in prison. It should be obvious that people who commit murder are generally not rational beings, weighing their options and the potential consequences. Certainly, there is no statistical correlation between increased application (or availability) of the death penalty and decreased violent crime.
2. People who use the death penalty for political advantage. These people, mostly politicians, may or may not appreciate the fundamental problems of the death penalty, but realize that most people do not understand the criminal justice system, and that taking a pro-death penalty position will communicate a message that they are doing their utmost to reduce crime and make people safer (regardless of whether or not that is actually true).

Are there any death penalty supporters who don’t fit into those two categories? Perhaps certain victims and their families, who view the death penalty as necessary to reestablish some sort of karmic balance in the world and “put the whole thing behind them”?

As it seems people are arguing about the revision systems hype, I just wanted to point that CVS rulez. Sure, it does not $some_obscure_witty_feature but, hey, is this feature really useful? I've been using CVS for ten years, coded around 500k source line of code and honestly, it suits all my needs. To tell the truth, I don't even use all of its capabilities. So, CVS can't keep history of a file when you move it. Big deal? After all, renaming a file is just like creating a brand new one. Leave a commit message stating previous name of foo is bar if you really need history and that is it. So far, I never stumbled upon a case where this "feature" limited me or made me loose more than 15 seconds. Same for distributed RCS. Sure, on the paper they look good. Call me a moron but I never managed to use one properly. Even a large but well managed project does not need such monstruosity. Matthew is right on one point: RCS are like languages, geeks advocate languages because of a specific subset of features. But they don't realize 90% of functionality of a language is present in all other languages and the 10 other percents can be achieved with method if you really need them. I personally find very discouraging to learn a brand new RCS for every project I contribute to if upstream has decided this one is cool. If you want users to contribute, use a standard RCS as well as a standard mailing-list system, common language, etc.

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.

With regards to The previous post of Wouter, DebConf6 has been scheduled in May as the local MX team are concerned about the potential instability of the political situation and potential demonstrations during the run up. The elections are coming up on July 2nd, so a good month beforehand should be adequate clearance.

It's a shame you can't make it, and I hope to see you, and everyone else who can't make it, at the next one :)

With this rcs debate currently on planet.debian.org I feeled the need to add some toughts.

My point is mainly: Why not simply stick to plain old CVS?

The pros are easily collected: it's installed everywhere, almost everyone know at least the basic commands, and it is rock solid technology without all those little nasty bugs the newer ones have all the time.

Most of the contra arguments are not applicaple to me, so how can they to anybody else? ;-)

Like changelog messages: I write a Changelog after a patch, because I look at the patch for doing so. After all, that is what the Changelog is supposed to document, not what I though I did. (And looking at this is always a good way to catch some obvious mistakes one did).

Making multiple patched off other people's projects: Two versions of the directories you are working on is all that is needed. Change the one, make diffs compared to the other. Revert the diff (patch -R or just answer often enough), change the diff to what it should be, reapply it to make sure it still works, test it, revert it again. To make another patch for the same original software, continue from the begining, otherwise apply the patch to both copies. Just works. Easier than any darcs or co, even if that would not core dump, go into endless loops or play dead dog.

Even the non-exotic new systems still have plenty of features I never needed:

Something has to be really big moving files around is needed at all. And if it is needed, just delete it here and add it there. That looses a bit of history, but that is still found in the older place's history. Moving whole files is there only a special case of moving routines between files while refactorisation, one sometimes just has to look somewhere else.

Even for svn's global revision numbers I have not yet found a use. Being used to cvsish tagging removes the need if thinking before, and between commits there is normaly at least a quarter of an hour, so date based indexing always works.

So, what are we talking about?

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 />