(Despite what I said, I'm still going to feed this to Planet Debian as I've actually had one person ask me not to stop)

feature wall

accent wall

ensuite

confused look from apartment leasing salesman (Australian for the bathroom attached to the master bedroom)

Rar. Beware. I've now got the M&S USB missile launcher working under Linux. I hate libusb, it's very badly documented and seems to assume you know the USB spec inside out. Anyway, usblauncher-0.0.1.tar.gz does the appropriate magic (if crudely) and includes a basic GTK2 Perl program to control it. Ian Jeffrey has also produced some code that works in much the same way, but it's only a command line example and I couldn't see a license that allowed redistribution attached to it. It looks like he went about things in much the same way as I did though.

Yesterday I needed to get a simple task done: scan a piece of paper so that I could email it to someone. Simple enough, as there is a scanner available for use in the grad lab. When I arrived, the lights were turned off and the lab vacant. Walking up to the machine with the scanner attached, I was surprised to see that the screen was locked. This annoys me to no end, and got me thinking about the thought processes of people when they choose open resources. Economics tells us that scarce resources are more valuable. The problem with this is the hoarding of resources - obviously the person who locked the computer was not using the unique resource attached to it, but if economics guided his decision would this be the correct answer? I would like to think not - it is far more valuable to use identical resources which were available (other M$ computers) while leaving that resource available for use by others. This seems to reverse the normal economic idea - you should use the resource which is the most abundant which suits your needs, allowing the scarce resources available to be used by others. Sidenote As it turns out, the user of this locked computer had left the computer locked for a considerable length of time. I left at 9, returned at 11, and returned again at 1 and there was no sign that it had even been used. I got tired of waiting and rebooted the computer, which I justified by the fact that you're not supposed to lock computers for long times in the grad lab. This particular student I do know, and he has taken some of the exaggerations about grad school a little too far - I'm pretty sure he sleeps in the building most nights, which just shouldn't be done IMHO.

OK, I will make this short because a gazillion of other people will probably blog about the 22C3 for several days or weeks to come... Today (last day) I only attended one talk — Bluetooth Hacking - The State of The Art. Funny stuff you can do with Bluetooth... All in all it was a great conference. Get the proceedings or browse the list of talks (most of them have PDFs attached) for more details. Videos of all talks should be available anytime soon (I hope!). Oh, and the 22C3 is probably the only event where you will see such signs (attached to walls by the congress staff!)...

A big word up to X11R7 being released. The benefits of modularisation are pretty well-documented: distributors can do security updates much more easily, as well as keep better track of upstream sources, users can build drivers easily if need be (and the drivers can get released promptly upon releases of new cards), etc, etc. But for me, the biggest win is that it's finally over: I've been working on it since Jan 2004, and the xlibs and xserver projects basically began in October 2003. I'm really glad that the release didn't, as suggested, get dragged into 2006.

People who deserve a great deal of thanks for this release include, but are absolutely not limited to, Kevin E. Martin, Adam Jackson and Alan Coopersmith as the release cabal, S ren Sandmann Pedersen as a modular partner in crime, Keith Packard and Jim Gettys who basically got modularisation moving, LinuxFund for funding Xizzle and Debrix (the genesis of the modularised X server), Jakub Stachowski and Kristian H gsberg for work on Debrix when I got busy with other commitments (and krh for ongoing modularisation work). I'm sure there are others who I've forgotten here; if you feel you should be on this list, then sorry. The code contributions are too many to mention: Eric Anholt, Ben Herrenschmidt, Billy Biggs, Alan Hourihane, Zack Rusin, Dave Airlie, Aaron Platner, and a cast of thousands.

I've heard the other release parties are rocking along nicely; I plan to make Melbourne's pretty damn good. Cheers!

I bought brand new Siemens C75 phone few days ago. This is how it looks like:

It's really great and of course I wanted to put Debian logo on screen. I had some old serial cable from my previous phone, so that was first I tried. Unfortunately trying to connect to phone causes its power down. Probably some firmware problems.
So I bought USB cable today. This time at least it doesn't want to switch off my phone, but I still can't get it work. Tried siefs, scmxx and both seem to have problems handling this phone.
I forced usbserial module to use explicit vendor and product id. Only then dmesg shows:

usbserial.c: USB Serial support registered for Generic
usbserial.c: Generic converter detected
usbserial.c: Generic converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
usbserial.c: USB Serial Driver core v1.4

This seems to be ok at least according to many howtos I found on net. So why does it still not work?

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)

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.

Last week, Binary 2.0 Conference (Japanese) was held. "Binary 2.0" is a new buzzword inspired from "Web 2.0", so the definition is not clear. But many peapole enjoyed the conference. In that time, there are two new presentation methods. The first one is SPS - SDL Presentation System (Japanese). It seems realy cool. The presentation had some beautiful effects, like wave of water on the mouse cursor. The second one is GDB presentation method (Japanese) . He made a MIPS compatible CPU on a FPGA board, and control it via GDB remote debug protocol. It is also cool. On the other hand, I tried to make my presentation by Macromedia flash. It is my challanging since 2003, however I can't beat the above methods. However my method has an advantage, portability. The SPS make an executable file, it is dangerous to execute, and not portable. My presentation file can play under many flash player, like rich mobile phone's browser.

Without the vast number of voluntary supporters past LinuxTag events wouldn't have been possible at all. On the financial side LinuxTag has always made only little profit after the event. Without these nearly 100 volunteers who have supported us directly during the event and during its preparation the show wouldn't have been possible. Without the help of so many supporters during the event, the entire show isn't possible. Hence, it is important to either generate more income and be able to pay for hostesses and callboys or manage a proper environment in which many supporters want to help. For this, accepting the importance of the supporters, acknowledging their work and supporting them with food, fluids, fun and other advantages is very important. To my regret, I have to admit that this has not always been the case inside the core team. I have argued in favour of the supporters several times, so hopefully not much of it has been noticed by them. Supporters have worked in several different areas. I'll try to list them below but I'm sure I already forgot half of them even though I have coached most supporters directly or indirectly. We have maintained the parking ground so we were able to ensure that the Festplatz in the middle of LinuxTag is not abused as a parking place during the event. This required us to maintain a gate with at least one gatekeeper from 6 a.m. to 10 p.m. This was a lot of work, and it wasn't that interesting, but good for people who want to read or hack in the gatekeeper pavilion. We have manually built the projects network in the exhibition halls. In the conference building it was built by the KaLUG. All information signs and plans had to be drawn, printed, magnified and fixed at their respective locations. There are a lot of additional signs that we have maintained to help visitors find their way. I'm sure still a lot of signs were missing. I have used the opportunity to prepare most of them after the last event, so that we have less work for the new one. Our own office had to be set up, since we've used naked rooms with only some cupboards, tables and chairs inside. More furniture had to be arranged, the network had to be built up, the server had to be installed or configured, the printer had to be attached, the network configuration needed testing, the desks had to be set up. For some years now one to three volunteers have helped us in the office in order to support the core team and so that we are able to present visitors, exhibitors, the press etc. We've had an an additional human firewall who worked for two or three days usually and was able to support most people already without clogging the office room. The firewall (Arne) himself had the idea to become a firewall several years ago and I have to agree that it was a very good idea. However, with the exhibitor support maintained at a special booth at the entrance less work had to be done for the firewall this year. Several large and self-standing signs had to be prepared or repaired after the had been broken at the last event or their content has been obsoleted. Signs for the gate from above had to be printed and fixed at proper locations so that exhibitors find their way. We have built up the entire audio and video equipment on our own with a service provider from Bremen. Since this affected up to six rooms a lot of equipment and cables had to be moved, installed and dismantled after the show. For this we've helped J rg and Sven with several volunteers. The business congress had to be prepared as well. Stuff for the attendees had to be created and taken to the conference building. The entrance counter for it had to be maintained and staffed. Doors had to be secured. Deliveries had to be maintained in a storage area, since before LinuxTag a lot of stuff is delivered to LinuxTag without the target booth built up already. During setting up the booth, the booth builders also had to be supported and problems detected, discussed and corrected. During the entire time of our siege of the fairground we've had to maintain our own storage of fluids and food. Due to the high temperatures having around enough fluids was very important. In addition to this demands for several goods also required us to send somebody out for shopping each day. In order not to die of starvation during the event we have also organised a delicious lunch for all supporters and core team members. Kudos to Thomas we were able to order large pots of salad and cooked food for two years so that we didn't have to eat unhealthy food (such as fat pizza for six days) and everybody could decide on their own how much they want to eat. In the years before we've had rented a cook and even ordered Pizza. The food had to be fetched from the restaurant, arranged, together with table clothes, cutlery and stuff, and finally taken back at the evening. Cutlery had to be cleaned regularly as well. For the social event the location had to be cleaned and prepared. This year we've had the great opportunity to use the Nancy Caf which was unused for about 10 years, and hence required a lot of cleaning. As it turned out just before the show began, it required a lot more cleaning than expected. However, thanks to the competent and highly motivated supporters the location was cleaned in time. Kudos to Claudia, this year's social event was also one of the most successful. For the legendary KaLUG party the location had to be prepared as well and the food cooked. Looking at the pictures, the pavilions had to be built, tables and chairs arranged, cutlery and fluids organised. In the evening all the stuff had to be cleaned as well. This year KaLUG had organised a so called "Sp lmobil" that helped with doing the washing-up, but somebody had to work in it as well. The KaLUG has maintained the Internet caf in the conference building and has set up the network for the exhibiting projects in the conference building. For this they have acquired a lot of computers and network equipment that had to be built up and dismantled after the show. They have also acquired a number of movable walls for separating booths and providing poster space. During the show we have distributed fluids for the conference rooms and exchanged information posters and flyers with the daily schedules. When you're giving a talk, your throat often gets quite dry, hence, a cup of fresh water is a good cure, but requires the organisator to maintain water and cups. Since the conference program changed daily posters and handouts had to be exchanged during the evening. Project exhibitors were supported directly by us while company exhibitors were supported by a service provider. Additionally all speakers had to be supported as well. The conference rooms were also maintained by a moderator who supported the speaker, announced the talks and speakers, ran (!) around with a microphone, helped in case of technical problems and maintained the schedule. Even though it may look strange for an outsider there are a lot of costs that emerge when such an event is organised at a commercial fairground. LinuxTag has always had the problem of only little yield after all bills have been paid after the show but had to start preparing the event for the upcoming year. In the past years it was always a struggle to continue with only little financial substance trying to get the next event set up properly. LinuxTag has been unique in its configuration, looking at its history, its organisation structure, its size and its components. There are basically only three ways of creating income: commercial exhibition, business congress and sponsoring. All three have obviously been on the descending path for several years now, reducing a lot of flexibility for the organisation. This income has had to be used for all expenses. On the other side there are a lot of areas that just cost money, such as the conference building, exhibition hall, hotel, travel reimbursements, projects booths, advertising. In addition to that we've had two service providers that have taken over some tasks and needed to be paid as well. A very rough overview is in my Howto LinuxTag talk from this summer.

I use Gmail to filter my mail. This has been the case since June 2005. I usually have about 1000 SPAMs in the SPAM mailbox. Recently I’m up to almost 1500. Sigh. I noticed alioth was spammed pretty bad. That’s one reason. I get quite a quite a few SPAM in my inbox which I need to manually send to the SPAM folder. That’s getting worse. Thankfully no HAM is found (knock wood) nowadays in Gmail’s SPAM folder. There was a monster thread over at Linux Users Victoria about Microsoft Exchange. For some odd reason the LUG doesn’t want the mailing list archived. Anyway I made a bit a of a tangent on the thread when I recommended people and companies outsource their mail to external hosts. The savings can be incredible. Though if employees send a lot of attachments, it can be quite painful.
Especially as Australia is using “Pay as you Go” style Internet. Setting up mail servers nowadays is too hard. In my (contracting) experience most offices are incapable of running their own mailservers. Currently I have a painful problem with my Debian (unstable) T30 laptop with Debian’s default exim4. Mail seems to get frozen if I don’t find a net connection within a couple of days when writing email offline. Finally here is a cheerful link of computing pictures to ease the pain.

So, what’s with all the broken laptop hard disks?! I have two laptops running almost all day (one as a cheap simple server with built-in UPS) and one as workstation. But in the last, say, 2 years I had to replace the 2.5” (laptop) hard disk drives 4 times! Since laptop HDDs cost a lot more per megabyte than normal 3.5” drives, this was becoming an expensive issue for me. So, I geared up S.M.A.R.T on both machines and did some investigating. The major issue seems to be the load/unload system that is integrated into more and more of these drives nowadays. The heads will automatically be retracted (parked) after some idle time to decrease the risk of shock damage and reduce power consumption. However, this seems to be a bad combination with Linux. I have not done any research into the specific implementation of the journaled file systems that I use (ext3, XFS), but it can something to do with it. It seems the heads of almost all laptop disks I encounter are continuously unloaded and loaded instead of around 5 times per hour. It seems a hard disk drive is made to allow for 300.000 load/unload cycles, after that the mechanism wears of so that inaccurate moving can occur and the platters can be damaged because of a small miss. Now, my drives had 650.000, 1.2000.000 and 900.000 before bad sectors and completely erratic behaviour start to occur, but this was within a year. My most recent broken drive had about 3 load cycles per minute, this means 180 per hour. With things going bad at 600.000, the disk thus had a lifetime of 3333 hours (138 days). This is ridiculously short. So I’ve turned APM of all my drives off (hdparm -B254). Better a small risk of bad sectors when dropping my laptop than having to replace my disk within the year. Also note that my brand new Western Digital disk has spent 14.000 of its load cycles within the first 15 hours that I was busy with installing Debian and recovering backups! If someone has more information about this, please let me know.

Recent discussions within Debian that make a noticeable detachment from the FSF point of view toward freeness, mainly about the GNU Free Documentation License and other documentation licenses, have induced me to wonder whether this is a symptom of a deeper difference of opinion between Debian and FSF. FSF is supposed to be developing the next generation GPL. One of the rumours about potential changes involve a requirement to post sources of GPL'd software that is used to power a website. If GPLv3 really included such a requirement, then I believe it would fail the DFSG (no restrictions on usage). It is also possible that the same difference of opinion between Debian and FSF that is now manifesting itself in the GFDL debate would end up causing us to reject GPLv3, even if it didn't include that particular restriction. It is likely that many free software authors, certainly all FSF projects, would eventually start licensing their software under GPLv3 (or, at your option, any later version). Then we would be in real deep shit. Update 2004-05-18: I seem to have been a little sloppy writing the above. I do not claim that a GPLv3 of the kind I indicate above necessarily fails the DFSG (such a claim would be nonsensical before an actual draft of GPLv3 is published). I intended to say that I expect to see such arguments if and when such a GPL is released, and I would not be surprised if such an attitude were to win the eventual argument. The point of this post is to show where that would lead us. I'll reprint here a comment I posted to this entry earlier:

I have no particular wish to see Debian and FSF disagree about the freeness of GPL, for the reasons I gave in the post.

This posting is part of my Finnish criminal court series. See the introductory essay for more information and an overview of the Finnish criminal court system. The following is a fictional account of a criminal case, one of the most frequent ones, written in the form of a play script. A PDF is also available. There is also an OpenOffice-generated XHTML renderition, which may be more pleasant to read than the version below (but lacks most of its logical markup). DRIVING WHILE INTOXICATED
A glimpse of Finnish criminal justice
Part One Dramatis personae
Presiding judge
Prosecutor
Defendant Extras
Three lay judges
Court reporter Sets
Courtroom
Courthouse lobby DISCLAIMER This is a work of fiction. Although this play is based in general terms on real life, all the specific characters and events portrayed or described in this play are fictitious, and any resemblance to real people or events is purely coincidental. The verdict presented is fictitious, and while it is based on the author's understanding of the law, it may be erroneus. No legal advice should be inferred from this work of fiction. Scene One: And so it begins The courtroom is about the size of a large school classroom, and shaped as a rectangle in terms of floor layout. The judges' bench, a long wooden table, lays near one of the short walls; the space between the bench and the wall is enough to give the judges and the court clerks comfortable room to sit and to move behind the sitting judges. At the center of the bench is the seat of the presiding judge, who has easy access to a telephone, a public address system and a panel for controlling the LED display visible in the lobby above the courtroom door. To his or her right is the court reporter's seat in front of a PC and in control of recording equipment. To the reporter's right there is room for one additional individual. To the presiding judge's left, there are three chairs for the lay judges. If one were to stand directly opposite the presiding judge, on the other side of the bench, one would find an open Bible. In front of the bench, disregarding the Bible, there is some room, approximately two meters or so. Along each long wall there is a small table, and those two tables face each other, and are therefore turned sideways from the bench's point of view. By the desk on the bench's right is the seat of the prosecutor, and the other, facing desk is reserved for the witness being examined. Facing the bench, separated from it by that empty space, are two rows of tables with chairs. Beyond them there are two rows of seats for the audience without tables; the farther row is right at the other short wall. The long wall to the judges' right contains one double door leading to the court building lobby, and the other long wall contains two sets of double doors at each end of the wall, leading to a part of the building not accessible to the public. We'll call the door closer to the bench the judges' door. The PRESIDING JUDGE is a 50-something man dressed formally in black and blue. The three LAY JUDGES are more casually but still essentially formally clothed. LAY JUDGE ONE is a sixty-something male, LAY JUDGE TWO is a female in her fourties and LAY JUDGE THREE is a female just under thirty. The COURT REPORTER is a female in her fifties, also dressed formally. It is 9:00. The four JUDGES and the COURT REPORTER are sitting on the bench. Each JUDGE has papers in front of him or her, the PRESIDING JUDGE's stack being by far the thickest. The PROSECUTOR, fourty-something man, enters through the judges' door, carrying law books and a large stack of paper. He sits down at his desk. PRESIDING JUDGE (Nodding to the prosecutor.) Okay. Let's start. (Enters codes on the LED machine. Then picks up the public address microphone.) The criminal case 'prosecutor against Matti Meik l inen' begins in room three. Parties to room three. Scene Two: Main hearing The DEFENDANT enters through the double door from the lobby. He feels a little lost. PRESIDING JUDGE (To the defendant:) Matti Vihtori Meik l inen? (DEFENDANT nods.) Please, take a seat in the front row. (He waits for the defendant to comply.) This case will be tried as follows. First, the prosecutor will read the charge. You will then respond by telling us if the charge is correct or not, that is, if you in fact did commit the acts specified in the charges, and if you did not, or the charge is only partially correct, you should state briefly why the charge is in error. The prosecutor will then present the case, he will describe us his understanding of the events in question. When he is finished, you will again have opportunity to state if the prosecutor is correct or not, and if not, in what way is he wrong. If there is disagreement between you and the prosecutor, we will hear the evidence. After that, the prosecutor will state his or her concluding opinion of the case as presented here. Again, you will have the opportunity to respond. We will conclude with discussion of what punishment, if any, would be appropriate. The court will then discuss the case alone, and will finally announce the verdict. Is this understood? (DEFENDANT nods.) Okay. Prosecutor? PROSECUTOR (Reads the charge from a paper everyone has in front of his or her.) I demand punishment to Matti Vihtori Meik l inen for driving while intoxicated. Matti Vihtori Meik l inen had on the first of May this year operated his car while his exhaled air contained 0,597 milligrams of alcohol per liter. Matti Vihtori Meik l inen's driving license must be suspended. PRESIDING JUDGE (To the defendant.) Is the charge correct? DEFENDANT Yes, it is. PRESIDING JUDGE Okay. The prosecutor will now tell us the circumstances and events in detail. PROSECUTOR Thank you. It was to my understanding late evening on May day, and the defendant had come from a bar and was apparently trying to move his car to a cost-free parking space. A police patrol happened to observe this and the defendant had apparently been a little shaky in his walking, so the officers gave him a breathalyzer test, which showed significant alcohol content. The defendant was brought in the station where a precision test was performed. The first reading was 0,597 and the second reading was 0,617; the mean of these two is 0,607, and after performing the confidence subtraction, the reading 0,597 milligrams per liter was obtained. PRESIDING JUDGE (To DEFENDANT) Well then, is what the prosecutor just said true? DEFENDANT (Speaking in a colloquial manner and very somberly. He is ashamed and wishes this would be over soon.) Yeah, it is. PRESIDING JUDGE All right. It seems to me that there are no points of disagreement, so we don't need to hear witnesses. (The PROSECUTOR nods.) Okay, it's time for the concluding statements. I think we will hear consequence opinions at the same time. Prosecutor? PROSECUTOR Thank you. I don't think there is much to say. The case has been shown beyond reasonable doubt, in my opinion. We have the precision test readings and the defendant's admission. As to the penalty... the amount of alcohol we are talking about is just below the limit for serious intoxication, so this is no small deal. On the other hand, the circumstances were not very dangerous. I think suspended imprisonment could well be considered, though a stiff fine would probably be more appropriate. The driving ban must be fairly long, obviously. PRESIDING JUDGE All right. (To the defendant.) Do you have anything to say before we adjourn to consider the case? DEFENDANT Well, I suppose it's clear that something is going to be given to me. I prefer a fine, naturally. PRESIDING JUDGE Naturally. The court will consider all options. Do you have any special requests concerning a driving ban? DEFENDANT As short as possible, of course. PRESIDING JUDGE Do you have a particular need for a car, do you need it for work, for example? DEFENDANT No. PRESIDING JUDGE Okay. Now, your income. We have here the last completed tax report for you, it says you earned 500 euros a month and had no children. Has this changed? DEFENDANT No change. PRESIDING JUDGE Okay, thank you. If you will then go outside to wait while we consider this case, thank you. The DEFENDANT exits to the lobby, the PROSECUTOR exits through the judges' door. Scene Three: Deliberation We are now in the lobby outside the courtroom. There are many doors that lead to many courtrooms. Above each door, attached to the wall, is a display showing the current case number; there is also a light saying do not enter, which is lit for most of the rooms, including Three. Also there is a numeric display which is out at the moment for most of the rooms. For some rooms, they indicate when the session will resume. Each courtroom door also has a paper pasted to the door frame listing the cases for the day. The door leading outside is separated from the lobby by a routine security check area, and one of the courthouse police guards stands there waiting for people to enter. Some other guards and janitors sit in their glass booth. There are many people sitting on the chairs, waiting for their turn to enter one of the courtrooms. DEFENDANT enters from the Courtroom Three door and sits down, waiting. It takes about fifteen minutes. During this time, announcements from other courtrooms could be occasionally heard, and people would enter or exit other courtrooms. Then... PRESIDING JUDGE (Over the PA) Verdict in the case 'prosecutor against Matti Meik l inen' in Courtroom 3. DEFENDANT exits through the Courtroom Three door. Scene Four: The Verdict The DEFENDANT enters from the lobby and sits down. After a minute, the PROSECUTOR rushes through the judges' door. PRESIDING JUDGE (Announcing to all people present.) The District Court has examined this case and has decided that Matti Vihtori Meik l inen did in fact commit the crime he was accused of in the way specified in the charge. The justification is the combination of the measured alcohol content in Meik l inen's breath and his own admission of guilt. Matti Vihtori Meik l inen is therefore sentenced to pay sixty-five day-fines, that is three hundred and ninety euros. Penal code, Chapter 23, Section 3. His driving license is suspended until the first of November this year. Road Traffic Act Section 75 Paragraph 1. One who is dissatisfied with this verdict can appeal it to the Vaasa Apellate Court within thirty days. Dissatisfaction must be declared, however, either right now to me or within a week to the Office of this District Court. (To DEFENDANT) Come and take the fine ticket and written appeal instructions (DEFENDANT takes those from the COURT REPORTER.) This hearing is concluded. The DEFENDANT leaves, as the court and the prosecutor prepare for the next case. TO BE CONTINUED
(with the next case)

WARNING: nothing in this post has been implemented or tested, except maybe at a minimal proof-of-concept level ("it compiles!"). It's just some musings on how you can make the computer do your work for you.

I was reading a defense of Hungarian notation when I started to get a familiar notion tickling the back of my brain. The author was explaining that the original idea behind Hungarian was not to replicate type information in variable names, but rather to include some sort of usage information: one example would be giving a string value holding a value that is untrusted the name utName. While it's more reasonable than lpschwzMyVariable, this suggesion made me suspicious that the author was really hacking around suckiness in the C language.

Tagging values with usWhatever and then verifying that you never mix usBlah with Blah isn't just tedious and error-prone, it smells a lot like doing work by hand that the computer ought to do for you. It seemed to me that it ought to be possible to "tag" unsafe values at the type level and let the language's type-checker sort things out. The simple approach is of course to define something like this:

newtype Unsafe t = Unsafe t

NB: I'm using Haskell because it was the first language that sprang to mind when I thought "type system hack".

This newtype declaration lets you attach an Unsafe tag to any type. Presumably the type signatures of routines that return untrusted data (such as a hypothetical getHTMLFormValue or a routine to retrieve previously entered form values from a database, if they aren't sanitized first) should be modified; for instance, if the signature of getHTMLFormValue was

getHTMLFormValue :: HTMLForm -> String -> String

it should instead read

getHTMLFormValue :: HTMLForm -> String -> Unsafe String

To create a new Unsafe value you simply apply the Unsafe constructor to the value:

getHTMLFormValue = Unsafe (oldGetHTMLFormValue)

To unwrap Unsafes you use pattern-matching:

let (Unsafe unwrapped) = wrapped in ...

So, this sort of works, but it's unsatisfying on several levels:

• It allows the creation of types such as Unsafe Unsafe Integer and even Unsafe [Unsafe Integer]. If a value is already unsafe, how can it be "more unsafe"? And what in the world is an unsafe list, or an unsafe list of unsafe values?
  
  Unfortunately, this is probably a limitation that any scheme that relies on type-tagging will have. You can get around it by either explicitly defining each new unsafe type:
  
  

  newtype UnsafeString = Unsafe String

  
  
  This is arguably a good idea anyway, since virtually all unsafe values (in the sense the previously linked article mentiones) are likely to be strings, and as I note later, it's not clear how to "sanitize" a non-string. OTOH, placing unnecessary type restrictions feels un-Haskellish to me, and it seems likely that you can trust the programmer not to pile up Unsafes.
  
  
• This scheme makes it very tempting to strip off the unsafeness of a value and lose the fact that you did so.
  
  Since the only way to strip off unsafeness is via pattern-matching, it seems to me that it would be tempting to pattern-match away the unsafeness in function declarations:
  
  

  foo (Unsafe x) = ...

  
  
  This may be just fine, but my preference would be to forbid pattern-matching altogether (by not exporting the constructor directly to other modules; just export a normal function that constructs an Unsafe value) and instead providing two routines to remove unsafety:
  
  

  escapeData :: Unsafe t -> t
  unsafeExtractRawData :: Unsafe t -> t

  
  
  The first routine encodes the data into a "safe" form, while the second simply fetches the wrapped value:
  
  

  unsafeExtractRawData (Unsafe x) = x
  
  foo x = doSomeStuffWith (unsafeExtractRawData x)

  
  
  The rationale here is twofold: first, by giving the dangerous extraction routine a scary and hard-to-type name, you remind yourself to think twice before invoking it (cf unsafePerformIO); second, you can easily audit all the locations where the unsafety is "stripped away" with a textual search.
  
  There are some issues involving the safe encoding -- you probably ought to make a typeclass of things that can be safely encoded from an Unsafe value; not too hard and this entry is already too long.
  
  
• The final issue involves manipulation of Unsafe values. So far you can pack and unpack Unsafes; however, this seems like it would get a bit annoying if you had to do any significant operations on them. For instance, searching in an unsafe string for a substring seems like it would be a pain and a bit error-prone (since you'd have to remember to wrap the string back up in an Unsafe). You might think that ideally, all normal String operations should work directly on an Unsafe String or pairs of Unsafe Strings -- you just shouldn't be able to convert between the two.
  
  Unfortunately, I can't see any way of doing everything that you'd want to here. For some types you can. For instance, the following definitions let you compare values wrapped in Unsafe in the usual way:
  
  

  instance (Eq t) => Eq (Unsafe t) where
      (==) (Unsafe v1) (Unsafe v2)   = v1 == v2
      (/=) (Unsafe v1) (Unsafe v2)   = v1 /= v2

  
  
  This admits (Unsafe t) to the Eq class, and looks reasonable enough (assuming that it's safe to compare unsafe values, of course). However, for probably the most important Unsafe values -- Unsafe Strings -- I can't see how to do this. The problem is that String is not a typeclass, it's a synonym for [Char], a list of characters. The important string operations are either defined directly on the String type, or generically on [t]; i.e., "a list of anything". Because there is no typeclass, you simply can't overload these operations to apply to unsafe strings as well as regular strings.
  
  One way around this is to provide an "unwrapping combinator":
  
  

  liftUnsafe :: (t -> t) -> Unsafe t -> Unsafe t
  liftUnsafe f (Unsafe v) = Unsafe (f v)

  
  
  This would automatically convert string operations to unsafe-string operations; not ideal, but reasonable enough. Operators are still a little annoying, but you can mangle their names:
  
  

  (++u) :: Unsafe [t] -> Unsafe [t] -> Unsafe [t]
  (++u) = liftUnsafe (++)

  
  
  So you have to use ++u instead of ++ to concatenate unsafe lists; not too bad.
  

While it may not be perfect -- it only makes sure that you don't accidentally violate safety, and doesn't stop you from deliberately doing something dumb -- this approach feels a lot safer to me than ad-hoc mangling of variable names. I used Haskell because you can do type hacks fairly easily in it, but I don't see why you couldn't play a similar game (albeit much less conveniently) in C++, or even in a dynamic language like Python. Of course, Python would give you runtime errors about safety violations instead of static ones, but that still beats getting runtime security holes.

I would add as a hypothesis that it should be possible to express just about any variable-name-mangling technique whose goal is to "make wrong code look wrong" in the type system, provided your type system doesn't suck; and that doing so is preferable to doing it manually, since it means that a lot of repetitive error-checking can be handled by the computer. And since the computer is better than you are at verifying formal invariants, forcing it to handle them whenever possible is always a good idea.

(Despite what I said, I'm still going to feed this to Planet Debian as I've actually had one person ask me not to stop)

feature wall

accent wall

ensuite

confused look from apartment leasing salesman (Australian for the bathroom attached to the master bedroom)

On Thursday, I went up to my father's house to pick up my desktop, now that I finally have Internet access at home so I can have permanent access to it from a more convenient place. While I was there, I decided it'd be a good idea to do an upgrade on my dad's box. While I was doing this, the nfs share of the Debian mirror in the home server that serves this blog stopped working, and I couldn't ssh in, although the console and ICMP appeared to work. Having no monitor attached to that box, I decided to reboot it and resolve the problem in a lame way. Had I known my primary hard drive had decided enough is enough, I would have looked for a monitor instead. After reboot, the server started doing a very loud and scary noise, which was not new to me. When the BIOS tried to probe the disk, it would not start up and would instead whine like that. When this happened in the past, switching the box for a few minutes and trying again was enough. Not this time, though, it looked like it was the end. Horrified by the fact that I had no really useful backup of /etc and /home, I tried over and over to get it working. I plugged the HD into another old AT box (which once served as my GNU Hurd playground), but I still got those scary noises. At least I knew it had nothing to do with the mother board. As it was getting late, I decided to take the HD with me, and another Maxtor of the same size (but not exact model) with me, to have a look in office the next day. I thought I'd have to restort to try to transplant the logic board from the good one to the faulty disk, but before that, I realised I could try mounting it in a USB cage. For some reason or another, this worked, and I quickly saved thetwo partitions it contained with no read errors. After this, I realised I had not done the copy as root, so I had lost all my ownerships. I plugged the disk again, and re-rsynced. It still worked. Alleviated, I went back home, copied the data to another old disk, and I don't remember why, I tried mounting the faulty disk again. I got scary noises even using the USB case, and no other tries have been successful, so I think it's completely dead now, just before my final mount which saved the data. The box is now back online, using a Seagate disk I had stored in a drawer and with no notes on it about it having any kind of problem. I suspect I will need to do real backups now, because the drive isn't as safe as it looked...

hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58   DriveReady SeekComplete DataRequest  
hda: drive not ready for command
hda: status timeout: status=0xd0   Busy  
hda: drive not ready for command
ide0: reset: success

My little P150 needs a 6GB drive. I'll have to find one somewhere.

David Berlind: “[P]icture a world where, instead of carrying a notebook computer with you everywhere you go, and instead of having power-drinking desktops in every corner of your house, all you have is a USB key that you take from one dirt cheap thin client to another. On that key is not just all of your personal data (that is stored in the cloud but replicated to your USB key for offline usage), but perhaps a small Web server and some applications, both of which are thin-client friendly.” I’m in complete agreement that the thin client/web application computing model is the wave of the future, and that the days of the fat client as the primary mechanism for monetizing software are numbered. However, I don’t buy into the notion that software-as-a-service displaces the traditional fat client entirely, for one very simple reason: It’s going to be a while yet before we have truly ubiquitous network connectivity. Sure, perhaps if you live in the San Francisco Bay area or in a similarly technology centric place, it’s easy to buy into the notion that it won’t be long before we’ll all be connected all the time. However, we can’t lose sight of the fact that a vast majority of the population doesn’t live in a world where technology billboards dominate the morning commute. Heck, my cell phone doesn’t even work when I visit my grandfather in rural Indiana—the notion of an omnipresent wifi fabric built from community hotspots is a long way off there, to put it mildly. And even when we do get to the day when we have ubiquitous connectivity, we’ll still want caching for optimization and replication to eliminate the single point of failure problem, not to mention the ability to retain control over our own digital lives. So, I view the thin vs. fat client juxtaposition as being not so much about user experience—AJAX has shown us that remarkably good user interfaces can be built on the web. It’ll be more about caching and data replication, two very important considerations in any distributed system. I think most people are missing that. David, as usual, appears to get it. My prediction: Applications will increasingly move to the web, so you’ll be able to get to your data anytime, anywhere, and from any connected device. No surprise there. But the majority of the time, when you’re using “your” client device (whether it’s a PC in your home or office or a handheld device or something that lives on a USB key and securely attaches to the network via some device that’s outside of your administrative control), you’ll still primarily interact with the web through a fat client of some sort. To be sure, the fat clients of the future will look a lot different from the fat clients of today. Hint: “Fat client” doesn’t have to mean “self-administered”. Perhaps the fat clients of the future are delivered on demand or via independently developed components that integrate into some larger framework. Perhaps it’s as simple as running a web server locally. But the fat client in whatever form will still be the primary interface the vast majority of the time. That’s why I don’t buy for a minute that Web 2.0 is yet another death knell for Microsoft. They’ve obviously got a great fat client story, and in case you haven’t noticed, they’ve just woken up to what’s going on around them. By the way, this is the area where I think Linux on the desktop could have the biggest impact—it won’t be about who has the better desktop or who can replicate the popular fat client applications of today in open source. It’ll be about who can mold Linux into the fat client framework of the future, seamlessly integrated with applications and services delivered via the web but open. If I were Microsoft’s competitors in this space, namely Google and Yahoo, I’d be spending a lot of time thinking about this. In today’s fat client world, Microsoft is between them and their customers more often than not, and if the past is any indication, they’ll be able to use this position to tremendous advantage.