Hello World. As you can see, my blog is now on planet.d.o as well. /me waves :)

I'm writing this during the final minutes of debconf-es-2, which I enjoyed quite a lot. Thanks to everyone who made this another fun Debian event! Quite unsurprinsingly, I couldn't get as much done as I thought previously. What I did manage to do, is to add more stuff to my todo list: I will be taking home a bunch of DV tapes with the recordings of the talks given. I'll send a note, when they're available online.

When I connected my IM client today aftera couple of days of being offline for different reasons, I saw that two people had written to me because of Jingle being released as offcial JEP (Jabber Extension Protocol). Those are JEP-0166 and JEP-0167, the former for "low-level" signalling and the latter for specific audio and video calls. I strongly belive that this will expand usage of VoIP, as people will find quite natural being able to call a person that is currently available, which is managed by presence status. Oh! And for those of you who don't know yet... Jingle is what Google Talk is using right now.

Nice. Very nice. The Xbox-Linux / Free60 team around Michael Steil has published a paper / wiki page called 17 Mistakes Microsoft Made in the Xbox Security System. I'm currently reading the paper, but I'm not quite through yet (the PDF is 13 pages long). It contains a very detailed analysis of the 17 types of mistakes Microsoft made (they made most of them multiple times)... The paper and the findings will be presented at the 22C3 in Berlin — this is one of the lectures I will definately be attending, that's for sure! Quoting from the article:

"[Conclusion: ]The security system of the Xbox has been a complete failure.".

Also nice: the earlier (now obsolete) version of the paper was called The Hidden Boot Code of the Xbox — or "How to fit three bugs in 512 bytes of security code" ;-) (via Golem)

Or was it generated by a computer picking random buzzwords? Take a guess.

The semantic mark-up languages would be used to specify the convergence of business and IT models, and more importantly, their metamodels. The ontological representation of the metamodel of a constituent model enables reasoning about the instance model, which enables a dependency analysis to deduce unknown or implied relationships among entities within the instance model. The analysis would be extended across multiple layers of models. The semantic model-based dependency analysis would reveal which entity has an impact on which entities (for example, business components and processes, performance indicators, IT systems, software classes and objects, among others) of the model. This semantic model-based analysis would be applied to a model that provides an introspective view of the business within an enterprise. Also, it would be applied to a value network that yields an extrospective view of businesses in an ecosystem.

As many people have expressed in their blogs after Bubulle's initial rant, I am also joining the game :)
Some weeks ago I decided to finally move my personal documents repository from CVS to SVN - Why SVN? Because I don't need a distributed system, I am the only person with write (or read) access to it... Besides, I'm too lazy - The one feature that made me start using SVN and not any other system is that you can use it just as if it were CVS, but without the ridiculous constraint placed by just integrating many individual files instead of managing the whole beast as a repository.
I had a problem, though, that made me lose good part of an evening - I think it might be related to #333105, but I'm not sure: I converted my repository using cvs2svn, which saved all my five years worth of commit history (whee!), grouping commits that seemed to belong together in single SVN transactions (whee!!)... But binary files were all corrupted. To make things worse, I didn't notice this until I had to present a talk in Peru - and my laptop's working copy was severely FUBAR.
Well... I managed to give my talk - And yesterday I finally decided to restore sanity to my life, reviving my doc_gwolf SVN tree. The stupid steps?

• cvs2svn --encoding=ISO-8859-1 -s /home/cvs/doc_gwolf /home/svn/doc_gwolf
• cd /tmp; svn co file:///home/svn/doc_gwolf
• Locate all files which differ between the two checkouts
• As I had done some work without committing, check against the list what was text, what was binary
• For each of the binary files, svn remove $file;cp /tmp/cvs/doc_gwolf/$file $file; svn add $file
• Add/replace all the files which were locally modified
• Everything seems to work? Ok, svn ci, and be merry.

Phew :-/

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?

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?

Heise (and many other sources) report that the EU parliament has voted for the abysmal data retention directive, simply ignoring objections from the industry and the civil society. The EU has turned into a police state where more than 450 million citizens are treated as criminals by default now! 1984 is a joke compared to this. We're all fucked! Bigtime! Please, someone go out and sue the shit out of the fucking idiots who are responsible for this kindly remind the responsible politicians that this directive is a really bad idea! Update 2005-12-15: OK, so I might have overreacted. My first answer to the accusations would probably be (abusing an unrelated quote from Jonathan McDowell): "I exaggerate for effect". But honestly, while it's not as bad as 1984, I really do think that this law will bring us all a big step nearer to a 1984-type horror scenario. (via netzpolitik.org)

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.

It amuses me that people are arguing with others about whether Debian “delivers” what it promises its users. Sarge was released on June 6, 2005. Since then, there have been exactly 0 kernel security updates for it. Meanwhile, Ubuntu has managed to release 7 kernel security updates in that timeframe (USN-137-1, USN-143-1, USN-169-1, USN-178-1, USN-187-1, USN-199-1, and USN-219-1). Each one of those fixes at least two or more real vulnerabilities (some fixing as many as ten!). So here we are, 6 months after the release of Sarge, and we’re not fulfilling our promise of a distribution that lacks known security holes. Furthermore, talks with our Security Team (which is, as far as anyone can tell, one active person) have gotten us nowhere; the DPL himself has attempted to do so, and was told that a kernel update is “in progress”. The sad part of this is the fact that the Security Team thinks there is no problem; once a kernel update is complete, everything will be OK. The lack of a kernel updates is merely a symptom of larger problems within Debian; key people do not scale, work in a closed manner, and are not willing to delegate responsibility. Meanwhile, the Testing-Security Team has managed to provide a wonderful example of how a security team could work, in many instances beating the stable Security Team to release fixes. I could go into how much fun it was for me to wait 10 months to get DAM approval in the NM queue, how I’m being forced to run Ubuntu on a server because Debian still hasn’t gotten its act together with respect to AMD64, and other such things, but it all comes down to the same core problem.

A brief case study in a flamewar diverted. The release managers are currently preparing a followup to the architecture requalification, following the efforts made over the past couple of months. Four ports are currently looking shaky, namely m68k, arm, s390 and sparc. An early draft begins going into the details by saying the following:

ARM has been borderline on a lot of the criteria, which we were willing to consider waiving; but there are two points in particular which we aren’t willing to waive. First is that the porting machine for arm, debussy.debian.org, has been off-line now for a number of months, and a replacement machine has not yet been activated by DSA. […]

Even without the already existing tensions on debian-devel and elsewhere, I’d expect the RM posting the above to the developers announcement list to immediately result in hue and cry about DSA trying to kill arm and how unfair and inappropriate that was. And I can’t even say that’d be unreasonable. OTOH, I can say it would’ve been unjustified, enough so that the above won’t actually make it out to -devel-announce. Why? Read on past the fold. Read the rest ...

I've been so busy, I haven't had time to blog. Rather than putting it off any longer, I'll just dump what I can remember. Last Wednesday, Sarah arrived after her holiday in Singapore, and from all accounts, had a great time. Photos as well. Sticking with the whirlwind theme, the next day, we had a "building warming" party at work for the new building we'd moved into the week before Michael and I started. The next night we had the work Christmas party, which blew the socks off any work Christmas party I'd ever been to before, and then on Saturday night we went to a party in San Francisco that we'd been invited to. On a life in general front, I'm still waiting for a Social Security number. The lack of one makes life a bit difficult for a lot of things. It also turns out that Sarah's work permit will take about 90 days to approve, so she's going to be a lady of leisure for the next few months. I've finally been issued with a work mobile phone (or "cell phone" as they call them), and so can stop roaming and paying through the nose for the privilege. We've found somewhere to live. We take possession of a 2 bedroom townhouse (split-level) in a complex in Mountain View that is 3 miles from work on the 18th. The rent is $1725 a month, which is a bit better than we were expecting. The complex we're renting in does have shared laundries, which we'd not too keen on before getting over here, but they're quite modern and secure, and there's a laundry block close to our townhouse, so hopefully it won't be too bad. The whole place had been renovated about 5 years ago, so it's all in good condition. We could have rented a 3 bedroom apartment (single level) in the same complex for about $125 a month more, but we're trying to actually make some money while we're over here... Driving on the other side of the road becomes fairly "normal" after about a week of doing it regularly. Sarah's adapted fine. Lane placement is the hardest thing, because your body's used to being in a certain spot on the road, and it's all different sitting on the other side of the car. We've managed to open a rudimentary bank account, even with my lack of Social Security number. Unfortunately I can't get paid until I have an SSN. Upside of that is that if it doesn't happen until next year, I presumably won't have to worry about income tax for this US financial year. Downside is kind of obvious... By far one of the stranger things of everyday life here is the lighting situation in the average residence. Lamps are all the rage, to the point that light switches don't exist in some rooms (notably bedrooms). Take where we're currently living for example. There's a light switch at the bottom of the stairs, there's one at the top. There's a bank of four in the living room, two of which control lights in the kitchen, and one the hallway. The last one controls a lamp in the corner of the living room, which is connected to a power socket (or power point as we'd call it). The bedroom with the attached bathroom (en suite) has two bedside lamps, and that is the sole source of light. The bathroom attached has light switches, and the walk-in robe has a light switch. It's so weird. So walking into a darkened bedroom involves walking all the way in, and fumbling around with a lamp. It's often easier to turn on the light in the wardrobe so you can see what you're doing first. I can't think of any reason for it, except tradition. It's not like they're avoiding wiring the walls or the ceiling, because it's done partially already. The bedroom has a ceiling fan, but where in Australia, there'd be a knob on the wall near the light switch to control it, it has a little chain you yank on. To add to the strangeness, there are two switches on the wall, one of which seems to allow you to turn off the ceiling fan if it's already been switched on by pulling the chain. The townhouse we're renting has a similar lamp dependency, so we're going to be making a trip to Ikea for some lamps it would seem. That's about everything I can recollect right now... Oh, I should point out that I'm really loving it over here.

 Anyway, I think Portugal is not, at all, a small team, and I think, on group D, is the one that we have to pay more attention. Iran qualified as the 3rd out of 4 on the Asian seats, and we cannot minimize them, neither. And Angola qualified as the first of their group on the African zone; they made 21 points, just behind Côte d'Ivoire. Group D is a hard group, yes it is. In case Mexico qualifies to the second stage, the 1st and 2nd place of group D would go against 2nd and 1st places (respectively) of group C, where I, personally, fear Argentina :) Go Mexico! :)