I've just glanced over to see how much it costs to get there.I don't seem to be able to get the exact fares yet, but it's looking like it will be around 140000 yen (approx 1000 euros).I won't have a direct flight there, I'll be flighing through Heathrow.Humph.

I have been asked for advice about long-term storage of documents. I decided to blog about it because my thoughts may be useful to others, and because if I get something wrong then surely people will correct me. ;)

Many organizations are looking at using computers for storing all documents. This gives savings on the costs of storing paper - the promise of the paperless office is being fulfilled. There are some potential issues about whether a signature in a PDF file that's scanned from paper is valid - but I guess it's the same as a signature on a FAX and everyone seems to accept FAXed contracts.

The technical problem is how to reliably store data long-term. The problem is that all modern methods of storing data will degrade over time. Anything less than engraving a message in stone, gold, or platinum and burying it will have some data loss eventually.

If the documents that need to be archived have no special requirements and if you have a good backup system in place (testing backup media, off-site storage in case of disaster, multiple sets of hardware that can read the backup media in case of hardware failure, etc) then you might be able to just store the documents on a server and include them in the backup plan. The regular backups should cater for replacing media over the long term. If however there is a significant amount of data or the data has confidentiality requirements that preclude having it all online all the time then you need a separate infrastructure for such storage.

Regular backup systems have to deal with files being deleted from storage and files that have their contents changed. For a document archiving system no file will ever be changed once it has been created and no file will be deleted. This allows some simplifications to the backup strategy. For example if you have multiple terabytes of documents backed up by tape and stored off-site you could use CD-ROMs or other media for storing recent changes. It would be very easy for an employee to grab a couple of CDs before rushing out of a burning building, but grabbing a set of tapes (or the correct tape from a large set) may not be possible.

It would be possible to use a tape library system as the primary storage for documents. If a large organization was going to implement this a few years ago that might be a good option. Nowadays storage is getting increasingly large and cheap. Terabytes are available in desktop PCs and hundreds of terabytes are available for server storage. So having the primary document store on a server with a decent amount of space and then making tape backups for storage in secure locations seems viable.

One thing to note about such document storage is that having everything on a server allows a much larger amount of data to be accessed and copied more easily than on paper. Sorting through a billion paper documents and copying the thousand most useful ones would be a difficult task for someone who was involved in industrial espionage. Finding the most useful files when they are indexed on a server should be quite easy and copying a few thousand is also easy (one thousand scanned documents of medium size should fit on a USB memory stick - much smaller than a few reams of copied documents).

Finally documents have to be archived in publicly documented file formats that can be easily read in the future. The PDF specification is well known and there are multiple programs that can display data in such files, another good option for scanned documents is JPEG. Proprietary formats such as MS-Word should never be used, you never know whether you will be able to read them in four years, let alone the seven years for which many documents must be retained or the 20-30 years that some documents must be retained.

Marc Brockschmidt wrote the BTS is too crowded and Joey Hess objected that a too clean BTS can also be a bad sign.

I think both is true or to say better none of the ways makes sense without the other:

Bug reports are in my eyes one of the most valueable resources we have. Noone can test everything even in almost trivial packages. To archive quality we need the users input and a badly worded bug report is still better than no bug report at all. Our BTS is a very successfull tool in that as it lowers the barrier to report issues. No hassles to create (and wait for completion of) an account, no regrets by getting funny unparseable mails about some developer changing their e-mail addresses (did I already say I hate bugzilla?).

As those reports are valueable information, one should keep them as long as they can be usefull. Looking at the description of the wontfix tag shows that even a request that cannot be or should not be fixed in the current context is considered valueable. Most programs and designs change, and having a place to document workarounds and keep in memory what open problems exist.

On the other hand a crowded bug list is like a fridge you only put food into. Over time it will start to degrade into the most displeasing form of a compost heap. The same holds for bug reports:

Most bugs are easier when they are young: You most propably have the same version as the submitter somewhere, know what changed recently and when you can reproduce it you get some hints on what is happening and get add it. If you cannot reproduce it, the submitter might still be reachable for more information.

When the report is old, things get harder. Is the bug still present? Was it fixed in between by some upstream release? Is the submitter still reachable and does still remember what happened?

When I care enough of a problem to write a bug report and trying to supply a patch for it, I try to always take a look at the bug list and look for some other low hanging fruits to pick and submit some other patch, too. (After all, most of the time is spend trying to understand the package and the strange build system upstream choose instead of plain old autotools and not when fix the problem). But when it is hard to see the trees because of all the dead wood around it, and there is nothing to find with some way to reproduce it and one knows far too well that the most efficient steps would be a tedious search for old versions to see if that was a bug solved upstream many years ago, good intentions tend to melt like ice thrown in lava.

So, when I wrote both is true I meant that keeping real-world issues documented and aware is a good thing. But having bugs rot (and often they do), will pervert all the advantages. In the worst case, people will even stop submitting new reports as it takes to long to look at all the old ones to look for a dublicate.

Ocamlnet 2.2: test it by yourself from experimental A couple of days ago I finally managed to complete the packaging work of Ocamlnet 2.2. This upstream version is a (r)evolutionary release in which it aggregate in a single source package libraries who used to be distributed separately, namely: equeue, ocaml-rpc, netclient, and ocamlnet itself. I've been quite surprised to discover that upstream is explicitly nice with us packages and provides guidelines on how to split the various libraries in binary packages addressing both dependency and licensing problems (e.g. for nethttpd which is GPL and can't be shamelessly linked with other components which are MIT/X11-licensed). The packages are in experimental but need NEW-processing, as well as cryptgps (a pure-OCaml implementation of some symmetric crypto algorithms, which is a new build-dep of Ocamlnet). Hence to ease testing I set up an apt-gettable repo here:

deb http://people.debian.org/~zack unstable ocaml

Please try it and give feedback to debian-ocaml-maint@l.d.o. In all my tests the upgrade from ocamlnet pre-2.2 has been smooth: the (too many) transitional packages I had to create did their dirty job. The only "issue" non-addressed (and I don't know how to actually) is that the nethttpd library used to be distributed in libocamlnet-ocaml-dev and is now distributed in libnethttpd-ocaml-dev. Since the former package is entirely useful without the latter there is no dep among the two and it's possible that upon upgrades an user ends up without a working nethttpd library on the system. I added a Recommends in the hope it's enough, let's see how many complaints I will receive ...

We got back to Montreal yesterday morning just after midnight. Maj got us upgrades on United to business class, which was really a life-saver. There's a direct flight from San Francisco to Montreal, but it's 5 hours one way and 6 hours on another. This time traveling to California, we decided to split up the flight, stopping in Chicago about halfway between. Returning was a good flight. We were comfortable, there was room, Amita had enough space to play on the ground and sleep comfortably on our laps. Maj: "Business class isn't anything fancy; it's just enough space, good service and quality food that you feel like a human rather than like livestock." The only downside was that Chicago O'Hare is a half-ass airport. For one of the most (the most?) visited and transited airports in the world, it's really skimpy on services inside the security area. There aren't any big restaurants or nice bars or stores inside the B and C concourse; just stand-up kiosks. We walked halfway across the airport to find a pub to eat at. Probably the best thing about the airport is the giant brachiosaurus skeleton in B concourse. Amita June couldn't stop looking at it; she ran from foot to foot banging it with her hand. Good for her; it's a pretty neat thing to see in a boring airport. tags: airport travel ohare brachiosaurus amitajune maj

Ebjo Another Maj quote: "It's just a coincidence that we use the term blog as a cutesy contraction for 'Web log'. It could have easily have been a 'Web journal' people were contracting, and then we'd call it an ebjo." tags: ebjo blog maj

Goethe One of the things that I've found as a participant in Open Source software and Open Content is that there are a lot of different people involved. And today, in 2007, Germany and France have become important loci of new developments in Free Culture. I've been working on my French for a while, and I think I'm getting pretty good, but I've never learned any German. At all. But German Wikitravel is one of the largest and most popular versions of the project. And I want to be more of a participant -- or, at least, have some better relationships with our German users. So, today I signed up for German lessons at the Montreal Goethe Institute. The Goethe Institute promotes German language and culture world-wide, including high-quality lessons in German. Montreal's is in a beautiful old building right at the corner of Sherbrooke and St. Denis. It's got a nice office and a friendly warm bookstore, "Das Buch". I'm going to take the intensive beginner's course -- mornings Tuesday and Thursday for 6 weeks. I hope at the end of that time I'll be better able to meet German-speaking Free Software advocates, Open Content participants, and most of all Wikitravellers a little more towards halfway. tags: goethe institute german wikitravel classes montreal

La ka I went to La ka this afternoon again to meet a couple of people. It was my first two-meeting day at La ka, which I think is a bad sign I'm turning into a serious maven. But like they say, it's really where the hipsters are doing business on this le lately. The nice thing was that I got to introduce two Montrealers that I like a lot. Hugh Macguire of, among other things, the Librivox public-domain audiobook project, is really interesting and passionate about communities and free content. Nicolas Ritoux is one of the most clued-in tech journalists I've met. It was nice to introduce them, and it was good that they seemed to get along. Depressing, on the other hand, was walking around the Plateau in January with 12C weather. This has gotten beyond funny into scary -- we just haven't had any serious snow in Montreal this winter. I'm worried that it's going to get worse, too, and I don't know what that will mean for Quebec's culture. Mon pays, c'est l'hiver, goes the song, and I'm not sure I get what a city without winter would mean here. tags: winter laika hugh macguire nicolas ritoux librivox montreal snow

House Maj and I have been watching House on DVD. It's really good, although a little formulaic. Everybody's always running around and bleeding and vomiting, and people get an average of 3.8 different rare diseases per episode. There's also a lot of cheating and sneakiness. It's great. tags: house tv

Mantini One nice thing about New Year's Eve this year was that Baron Earl served a refreshing -- nay, energizing -- spocktail called a mantini. I was especially pleased to find out that the first ingredient was not, in fact, a praying mantis. With the Baron, you never know. tags: mantini spocktail baron earl

Marc, I disagree. Solving every issue and whim that every user files against a popular package, while not letting the package degenerate into a mess, is hard. Taking some time to gather opinions and produce a well-designed fix that strikes to the core of an issue, rather than treating symptoms, is a good thing for many classes of bugs. (Other classes should instead be fixed immediately.) The existence of many open bugs against a package in Debian is not an indication that it's of lower quality than the corresponding package in Ubuntu -- which in fact probably has 99% of the same bugs anyway. As a user, I also regard a BTS as perhaps the best form of documentation there is about real-life problems that I might encounter while using the package, the general quality of the code in the package, etc. It's the first thing I look at when installing some new peice of software. It's also a good way to gauge how well the package is maintained -- not by counting bugs, but by reading how the maintainer responds to bugs. What I look for in a BTS is an indication that the maintainers care about a bug. The fact that bug #725 took ten years to get fixed doesn't mean that X's maintainers suck, it means that for ten years, we were able to document a minor problem to the few users who cared about it, and that we were able to keep track of it until someone finally figured out how to fix it. That's quite an accomplishment. Another example, to keep picking on X, the fact that bug #216933 is marked wontfix is not an indication that the bug is worthless; in fact the bug documents a quite subtle issue in the Crusoe's code morphing software, and has been an invaluable reference to a lot of Crusoe users. I'm much more concerned about all our users who don't know about the BTS and are unwilling to bother to file bugs than I am about the total number of unfixed bugs in the BTS. Getting 100% of our users to file good bugs on every issue they run into would do much more to increase the overall quality of Debian than fixing every > 1 year old bug in the BTS would.

Blogging is hard, isn't it? Finding a topic that's not better placed on specific mailing list or somewhere else is not easy. One of the classical subjects for bloggers is ranting. And that's what I would love to do now :-)

I have had discussions with people who are turning away from Debian in the past few months, mostly to Debian derivatives like Ubuntu. Mostly, the reason for that is some sort of software that is newer/better supported/blabla in some other distribution, which I think is OK. Debian has a policy of a long, painful release cycle, but the stable releases that come out of it tend to be useful for a long time and relatively bug-free. That is good and shouldn't be changed without good reason.

Most of the people I spoke too revealed a far more disturbing thing: The long release cycle isn't the only argument against using Debian. Most of these people had other reasons, and a good number of those are things that Debian as a whole can - and should - address. Mostly, the Debian BTS comes up as a topic. Not because we don't use the Industry Standard [tm] bugzilla (which I personally hate so much I can't even describe), but because the BTS contains a lot of old bugs nobody cares about. Look at most of our packages: Bugs filed 7 years ago, with the last activity from that time, without a hint how (and if) they are ever closed are not uncommon; they are what you actually expect if you look at a bug list.

Naturally, processing, forwarding and closing bugs is the task of the maintainer. This doesn't work out in all cases, we have more than one cases where maintainers are overwhelmed by the sheer number of bugs flowing in against their packages. Also, and that is probably accepted everywhere: Bug processing is uncool. It is so much more fun to rewrite your code, add features, get new packages in the archive and doing new, blingy stuff, that the boring maintenance work of existing packages moves to a place far down on the todo lists. But hey, this maintenance. That's what maintainers are for. Most Debian Developers are Package Maintainers. They should do it, not adding new stuff.

We need to discuss how to work around these issues. We are not the only project which an overfilled bug tracking system. Look at the Gnome and KDE projects, the number of bugs filed against Mozilla products each day. Can we learn something from them? I would be happy to get a bit of feedback about this, so whoever is involved in other projects which have found better days to deal with bugs, please send a mail.

Apart from the fact that I would love to get more input on this, I want to start something new for lenny, the stable release planned after etch. I want to get the bug count down. Not the release critical bug count (which is eagerly watched all the time), but the small issues that bug users every day. For that, I have planned to look at 5 random important and normal bugs each day (starting with software I use) starting the day etch is released. I may begin to do this earlier, but I'm currently really not swimming in free time.

I don't plan on fixing all these issues (well, I may, if I can easily reproduce them), but more on forwarding them to the appropriate place, upstream, and noting so in the BTS. I want to poke maintainers long enough to invest some more time in fixing bugs. This will also help with the MIA efforts of the QA team, I guess...

Oh, what I almost forget: I expect help from all of you!

Hah! Targetted memes have hit again - Arareko decided I should talk about myself. I will do this, but I won't point the finger at five others - Lets see just who bites ;-) Besides, having left this post rot as a draft for over a week already, it got a bit more interesting: The meme bit from two sides. Arareko (as well as Ion) was bitten by Cicloid, from the mx.planetalinux.org-derived side of reality, and then Hanna bit Wouter on Planet Debian. Ok, time to get this message out from the freezer...
So... Five not very well known things about me? Ok, here I go.

1. Many people inquire me routinely about my name, specially when reading it off an official document where it appears with both names and both family names (Gunnar Eyal Wolf Iszaevich). As many Jewish families, mine comes from all over Europe: My mother-side grandparents were both born in Poland (hence the Iszajewicz, morphed into the slightly more writable Iszaevich). My father-side grandmother was born in Vienna, Austria (I still have some family in Graz), and my father-side grandfather was a proud child of the Austro-Hungarian empire - His family probably was originally Austriac (Wolf is a German name), but became Hungarian and Hungarian was their home language. He was born in Felszoviso, Transilvania (the part of Hungary that later became Northern Romania). And, yes, I mentioned my family is Jewish, so having the Hebrew name Eyal (my second given name) is no surprise. Now, about Gunnar? Well, I still don't know :) It's a Scandinavian name. My family has no (upwards) relation to Scandinavia, but both of my parents (although merely by coincidence, and with over 30 years between periods) lived in Western Sweden - My father, 1970-1972, and my mother, 2003-2006. Oh, and people usually expect them to carry strange foreign names as well - No, they are Bernardo and Ofelia.
2. I like to think started my journey into Free Software very early in my life. No, I didn't use Linux until 1994 (and only installed it in 1996), I'm not talking about such a modern piece of free software. I first touched computers around 1983-1984, when my father used to take me on Friday nights to his institute, to play with the computer. This computer was a Foonly F2, administered by La Mancha. What did I use to play on such a beast? Why, of course, I used Emacs to write TeX! Rumors say that this Foonly had the first TeX installation outside of Stanford (I guess this fact derives from Donald Knuth's visit to UNAM in 1977 - But of course I don't remember that!)
3. My family is bitterly split in two camps: Those who love eggplant and those who hate it. At least my parents, my aunt and I are known to love it. At least my wife (Nadezhda), my brother and two of my cousins are known to hate it. The feelings towards this noble plant are really strong, but out of respect for the other party of the family, we practically never cook with it.
4. Now that we mention food-related strangeness, I was a vegetarian for almost my first 20 years of life. My father is still a vegetarian (for over 35 years already). Nadezhda became a vegetarian almost a year ago. I still think I have saved enough karma during those 20 years to endure some more meat eating, but who knows... I might switch back just to be on the safe side ;-)
5. Often, memes can absorb too much energy from me. Even having left this entry not responded for over a week, I've been thinking (and forgetting) on and off what to write in it. So, Mauricio, thanks for making me waste my time this way! ;-) I hope this fact counts as a legal fifth thing.

Kewstoke is connected to the town of Weston-super-Mare by the mile-or-so of Kewstoke Toll Road but since 2005, there has been no toll collector. Unsurprisingly, the number of the least desirable vehicle types (Chelsea tractors/SUVs and light goods) using this coast road has doubled while the toll has been missing. Now the council is looking at putting up the season ticket rates from 5.50 to somewhere between 22.00 and 35.00 if they bring the toll back. A seven-fold increase? The alternative is to abolish to toll: which do you think is more likely? The latest report lists

"Unrestricted access and egress between Kewstoke and Weston-super-Mare"

as a benefit of abolition. Becoming a rat-run between the town centre and M5 is a benefit for who exactly? Certainly no benefit to the residents of Kewstoke or the top end of WsM who get the extra traffic wriggling along small roads with junctions not designed for that flow. Probably no benefit to drivers if they start to rely upon a hazardous road along the cliff-tops, which can be totally closed by just one break-down. It also goes against the Joint Local Transport Plan which says the council will

"direct traffic and particularly freight onto the most appropriate roads. Manage safe travel taking into account the current and desired uses of the network. Improve quality of life for local people."

Are press releases like Toll Road Accidents Reduced trying to convince us that driving along the cliff-tops is safe? More reports can be found among the items of the Strategic Planning and Economic Development Policy and Scrutiny Panel

The issue of core file management has come up for discussion again in the SE Linux list.

I believe that there are two essential security requirements for managing core files, one is that the complete security context of the crashing process is stored (to the greatest possible extent), and the other is that processes with different security contexts be prevented from discovering that a process dumped core (when attacking a daemon it would be helpful to know when you made one of it's processes dump core).

The core file will have the same UID and GID as the process that crashed. It's impossible to maintain the complete security context of the crashing process in this manner as Unix permissions support multiple supplementary groups and Unix filesystems only support one GID. So the supplementary groups are lost.

There is also a sysctl kernel.core_pattern which specifies the name of the core file. This supports a number of modifiers, EG the value "core.%p.%u.%g" would give a file named "core.PID.UID.GID". It would be good to have a modification to the kernel code in question to allow the SE Linux context to be included in this (maybe %z).

To preserve the SE Linux context of the crashing process with current kernel code we need to have a unique type for each process that dumps core, this merely requires that each domain have an automatic transition rule for creating files in the directory chosen for core dumps. In the default configuration we have core files dumped in the current directory of the process. This may be /tmp or some other common location which allows an attacker to discover which process is dumping core (due to the directory being world readable) and in the case of SE Linux there may be multiple domains that are permitted to create files in /tmp with the same context which gets in the way of using such a common directory for core files.

The traditional Unix functionality is to have core files dumped in the current directory. Obviously we can't break this by default. But for systems where security is desired I believe that the correct thing to do is to use a directory such as /var/core for core files, this can be easily achieved by creating the directory as mode 1733 (so that any user can create core files but no-one but the sys-admin can read them) and then setting the core_pattern sysctl to specify that all core files go in that directory. The next improvement is to have a poly-instantiated directory for /var/core such that each login user has their own version. That way the user in question could see the core files created by their own processes while system core files and core files for other users would be in different directories. Poly-instantation is easier to implement for core files than it is for /tmp (and the other directories for which it is desirable) because there is much less access to such a directory. When things operate correctly core files are not generated, and users never need to access each other's core files directly (they are mode 0600 so this isn't possible anyway).

This area will require a moderate amount of coding before it works in the ideal manner. I aim to briefly describe the issues only in this post.

You scored as Neither. You think neither like a man nor like a woman. What you are you may decide for yourself. Most people will consider you strange, alien, weird or funny. You are probably quite interesting.

Neither		75%
Male		43%
Female		43%
Either		36%

Should you be MALE or FEMALE?*
created with QuizFarm.com

I’m trying to learn ruby, but having no inspiration of what to write with it. My girl suggested I post “Will code for films” and see what people would pay to have written .. I expect very little. Still who knows? I’m suffering connectivity issues again, which are making me actual freetime difficult to spend. Grr. To follow the meme: Five random facts:

• I believe that garlic can be used to enhance all food. Even ice-cream.
• My first scar was given to me by my sister, when I was approximately six weeks old. Families, eh?
• I have lived in the same flat for 2.5 years, and in all that time have never opened the bedroom curtains/blinds.
• I have twelve bottles of Single Malt in front of me. Current favourite? A balvenie.
• I rarely dress before noon.

And for bonus points: “My girl” refers either to my sister, or my girlfriend. Context usually makes this obvious if it matters…

There seems to be a bit of a fuss around Vista's Content "protection" mechanism going around the 'Net these days; someone made some review of it in terms of the effects this will have on the hardware industry, which was mentioned by a few people on Planet Debian, and also on Bruce Schneier's blog. The argument, basically, goes like this:

• To view "Premium Content" on Vista, you must have a computer that consists of drivers and hardware that are vetted by Microsoft as being "ok".
• For this hardware and these drivers to be "ok", you need to have created your hardware to implement cpu-to-device encryption, and have done a number of other things that require huge gobs of money to properly develop.
• Hardware manufacturers will do this, but that will require them to ask more money from consumers.
• As a result, everone will pay, even those who don't run Vista (such as Linux and MacOS users)

Personally, I don't buy that argument. "Premium Content" (really, Crippled Content) will only be available to those users who actually have hardware and software which is capable of viewing Crippled Content. While it might be a problem for home users not to be able to view Crippled Content, I can't think of any reason why you would want to be able to view Crippled Content on your enterprise desktops. As a result, Enterprise users will continue to buy the cheapest hardware available that still accomodates their needs, much as they do now (I have yet to see the first enterprise desktop with one of those extreme 3D-capable cards...). And if just one manufacturer decides that the Enterprise market is enough of a market for them not to support Crippled Content with (a subset of) their hardware, then I can't imagine there being a problem in finding affordable hardware anymore. Eventually, people will understand that Crippled Content is much more of a trouble than it is worth—a DVD player is just as cheap, and doesn't require you to have a humming, noisy PC in the living room—and Vista's Crippled Content will go the way of the dinosaur. Where it belongs.

Yesterday I went to see An Inconvenient Truth with Hieke at LHC: the documentary by Al Gore about global warming. Already a classic, and well worth a visit. Gore is an excellent, erudite speakererudite, has convincing arguments and is surprisingly humourous. The film consists mainly of a recording of a speech he's been giving for about twenty years on the topic of global warming. He supports his views with clear arguments. The film is not at all fatalistic: a good point was his emphasis that we need not "go from denial to despair" but that it's actually quite well possible to solve the problem. If there's policical will. The only downside is the distinctly "American" flavour that the film has: intermezzos about his family and some emotional personal events in his life. And every person that Gore quotes is "my friend". But these points are really minor. A must see.

Quoting Shakespeare's Sister:

It remains a radical act to be fat and happy [...], especially if you're a woman (for whom "jolly" fatness isn't an option). If you're fat, you're not only meant to be unhappy, but deeply ashamed of yourself, projecting at all times an apologetic nature, indicative of your everlasting remorse for having wrought your monstrous self upon the world. You are certainly not meant to be bold, or assertive, or confident and should you manage to overcome the constant drumbeat of messages that you are ugly and unsexy and have earned equally society's disdain and your own self-hatred, should you forget your place and walk into the world one day with your head held high, you are to be reminded by the cow-calls and contemptuous looks of perfect strangers that you are not supposed to have self-esteem; you don't deserve it. Rare indeed is the fat chick who manages to find contentment in her own skin, because everything around her is designed so that she will not.

Being publicly fat and happy is hard; being publicly, shamelessly, unshakably fat and happy is an act of both will and bravery.

Love yourself, whatever your size is!

Being Sedintary Is Bad For You, Not Being Fat

Hardware evils

I've had quite the unfortunate week, hardware-wise, here. Nothing on my end is broken, but [lj user=ceilingsarecool]'s computer is screwed but good. It all started near the beginning of this week when I started to look into her machine. It had been loud for a while, and was being unreliable in regards to applications. Running memtest86+ on it via a handy System Rescue CD I always keep around discovered a couple of stuck bits on the memory that otherwise had been perfectly fine. However, I have had sticks die before, so I called Crucial and am having the memory replaced. (thank you Lifetime warranty). While I was taking the Memory out I noticed the couse of the loudness. Apparently there was ailing fan on the south bridge, which explained her issues with USB-connected devices. No problem - I'll just order a replacement motherboard. The old FIC AD11 was getting pretty bad anyway.

The new motherboard (a PCCHIPS M810LMR) arrived yesterday, so I went through the lengthy process of removing the old motherboard and moving the CPU from one to another. Just one problem: the new motherboard didn't start up. After checking that I had everything connected right, I thought the board was DOA. This would be my first DOA ever, but as usual the place I bought from has a DOA replacement policy so I thought I just wasted 2 hours and a bunch of time replacing. Unfortunately, this isn't even the end of this sad tale of brokenness. When I put the CPU back in the old motherboard, it didn't start either. So now I'm left with two motherboards for a processor that doesn't work, I assume. I don't really have another one that I can test it out on, and I can't test the motherboards with another CPU because I don't have one.

Luckily, I have some old towers sitting here that were about to be dragged out to the dumpster. I rescued them. They're ancient, even more than the machine that was in use was. I had to burn a Maxtor MaxBlast4 CD just to get them past the 65GB barrier, and of course I need to do a "repair" install of Windows because all the hardware changed since I installed it.

Lesson of this tale: Almost-broken computers are a delicate ecosystem. Just buy a new computer - you'll have to do that in the longrun anyway. Currently I'm looking at replacing the mainboard and CPU with this combo from newegg. It's got mixed reviews, but is reasonably priced, and if DOA I am sure that newegg will replace it. I'm debating between doing this and just saving up to get a decent new motherboard and CPU (generally around $150-$250, $300 easily with new memory) later in the year. I feel pretty bad because every computer that I've given ceilingsarecool to use has had issues like this. She tells me that she doesn't really care that much, and she does have a laptop which works well when the desktop has issues like this, but it's still like a poison apple.

Windows XP Setup

It doesn't seem to matter what you are installing Windows XP on. It can be 500MHz or 1.2GHz or 3.0GHz, the first time estimate that you get for finishing the install is 39 minutes. When XP was first released, I never ever had a computer that would finish that fast - it consistently took an hour or more from that state, and then I jumped to fast computers that come under the mark most of the time (although not by much). At least the estimate is monotonic, not going up to an hour. I can at least assess the progress a little more. Installing a couple times in the last few weeks has got me wondering about the origin of that estimate, and if it was going to be so inaccurate as to just guess and be constant at the beginning of the install, why include a time estimate at all?

Michael Davies recently blogged that all developers should have big screens. This news has been around for a while, the most publicity for the idea came from Microsoft Research where they did a study showing that for certain tasks a 50% performance increase could be gained from a larger monitor.

If you consider that a good software developer will get paid about $100K and it's widely regarded that in a corporate environment the entire costs for a worker (including management, office space, etc) is double their base salary then you consider each developer to be worth $200K per annum. Therefore larger and more monitors could potentially give a benefit in excess of $100K per annum (we assume that the value provided by the developer is greater than their salary - apart from the dot-com boom that's usually the case).

It's quite obvious that you can get a really great monitor configuration for significantly less than $100K and that it will remain quite current for significantly more than a year (monitor technology advances comparatively slowly so a good monitor should last at least four years).

Some time ago I researched this matter for a client. I convinced all the managers in my area, I convinced a bunch of colleagues to buy bigger monitors for their homes (and bought one myself), but unfortunately senior management saw it as a waste of money. I was trying to convince them that people who were being paid >$100,000 should be each assigned a $400 monitor. Sadly they believed that spending the equivalent of less than a day's wages per employee was not justified.

If I was in a management position I would allocate an amount of money for each developer to spend on hardware or conferences at their own discretion. I would make that amont of money a percentage of the salary of each employee, and I would also allow them to assign some of their share to a colleague if they had a good reason for it (EG if a new hire needed something expensive that would exceed their budget for the first year). I think that people who are good programmers are in the best position to judge what can best be done to improve their own productivity, and that allowing them to make their own choices is good for morale.

On a more technical level I have a problem with getting a big monitor. I do most of my work on a laptop because I travel a lot. I don't travel as much as I did while living in Europe but still do a lot of coding in many strange places. I started writing my Postal benchmark in the hotel restaurant of a Bastion hotel in Utrecht during one of the worst recorded storms in Europe (the restaurant had huge windows and it was inspirational for coding). I wrote the first version of my ZCAV benchmark in Denver airport while waiting for a friend.

What I need is a good way of moving open windows from my laptop to a big external display and then back again. I don't want to logout before moving my machine. With a Macintosh this is quite possible (I'm using a OS/X machine while working for a client and the only thing that has impressed me is the monitor support). With Linux things aren't so easy, it's supposed to be possible but I haven't heard any unqualified success stories yet.

I guess I could try setting up XDMCP between my laptop and a desktop machine with some big displays and logout before moving.

Any suggestions?

Or, if you really want to, be careful that, if /usr/lib/iceape/chrome is a directory (and not a symbolic link), your working directory is /usr/lib/iceape/chrome, or you will end up with the content of your current directory in /usr/share/iceape/chrome, which may be a big issue if you run apt-get from /. If /usr/lib/iceape/chrome is a symbolic link, no worry, just ignore this message. Thank you for your attention, and very sorry :( Update : That’s in such cases that you’d like special crafted tools to rebuild packages without the need to rebuild the whole thing when it comes to just change maintainer scripts (pre/postinst, pre/postrm…). Fortunately, I have pbuilder configured with ccache, but that doesn’t help the buildds with their build job.

I used to live in Norfolk, so Norwich Evening News: Was top cyclist killed by driver asleep at the wheel? (Updates: EDP: Death crash trial hears of "most viable explanation" and EDP: Driver guilty of causing cyclist's death ) and Norwich Evening News: Cyclist hit by bus on A47 are rather worrying. Weston super Mare Weston Mercury: Town centre havoc reports that Wales and West Utilities will be digging up Orchard Street followed by Alexandra Parade, Regent Street, Walliscote Road, High Street and Knightstone Road over 16 weeks from 8 January, and also

"Three months worth of work to remove the central reservation and add a filter lane to Herluin Way is also due to start on the same day [...] Uphill Road South in Uphill is closing on January 9 for six weeks as Wessex Water repairs the highway's sewer. [...] Winters Lane in Redhill is shutting for two months while a new sewer is put in."

Pipe works seldom seem to take up the full width of the road and the Herluin Way cycle track only crosses Herluin Way at a few points. Will these roads be kept open for cycling? They should be. All of these seem to be starting just before next week's Cycle Forum (7pm Wednesday 10 January at Worle Campus, press release ). Interesting new year present.