First off, Dan Zukowski has some very informative articles about Amtrak. It's particularly funny listening to Mineta say that the Bush administration wants to support Amtrak. After they proposed $0 for it in their most recent budget proposal, saying that bankrupting Amtrak would be a good thing. Hmm. Doublespeek seems to be in vogue these days. I've watched about half of this week's 4-hour hearing about Amtrak governance. One very interesting thing about it is that the Amtrak board, which fired David Gunn, may not have had a quorom for months, or even years, including the meeting where they fired Gunn. Secretary of Transportation Mineta, who holds a seat on the Amtrak Board, appears to have never actually attended an Amtrak Board meeting. I wonder what will come out next about all this...

Erich, Are you using bind9-host? If so, which version? If you're using the sarge version of bind9-host, with the sarge version of libssl0.9.7, and running all this on an i686-class system, then you're looking at bug #321721. The issue is that, if a binary includes hand-written assembly, gcc will assume by default that the code requires an executable stack unless you set a .note.GNU-stack section in the assembly file which says otherwise. And the i686 version of libcrypto includes (surprise!) hand-written assembly. This bug is already fixed for etch, both in libcrypto.so.0.9.7 and libcrypto.so.0.9.8.

Dear Lazyweb,
,
Nothing is perfect, but on Linux you can at least improve it and tune it. I just ran into memory problems on my development box - I had tons of applications open, and since this is a laptop I prefer to have swap disabled. I then started to build bind9 for a sarge backport, which meant that a long sequence of C compiler processes were launched, each allocating some memory, working with it, terminating, next. Being really at the limit of the available memory, the system became unresponsive - and that behavious is really bad... I thought that sooner or later it will really run out of memory, and decided to watch some TV in the meantime. One hour later when I returned, it was still torturing my HD and still unresponsive. Apparently the compile process has been all the time just below the memory limit, causing the kernel to remove pages from memory and load them back from the disk later, which slowed everything down just horribly. So now I'm searching for a way to prevent such situations. The traditional ulimit approach won't help - no single process was responsible for using all the memory, but each one had its reasonable share. So dear lazyweb, is there a way to tell the kernel to reserve a share of the memory (lets say, 64 MB) for buffers and caches only? I can live with out-of-memory errors a bit early (and the just enable swap), but a massive slowdown as described above (where the kernel is apparently reading some data from the HD, then forgetting it again and replacing it with the next) must not happen that easily... Right now I fear that you could bring down any Linux system easily with a "slow" forkbomb where each forked process allocates 100 MB and starts writing some random data to its memory, forking a new child every 50 MB or so. Neither the OOM killer, ulimit nor traditional forkbomb detectors will be able to counter that, since already a couple of processes will cause the system to become completely IO-bound. Oh, and I have no idea how Windows would react on that either. So don't assume any OS is better, just because I say Linux isn't doing perfectly well here. If you have any tips for me, send me an email.

I saw Ruby the Rival via an article on Lambda the Ultimate, and of course it tickled my interest in the diffusion, rise, and decline of programming languages. The guys they picked to interview have pretty good commentary - I found it thoughtful and insightful. Robert Cooper's comments to the effect that you should do the easy things first and make the complex stuff available are spot on. Simple stuff has got to be simple in order for the language and its libraries and applications to scale down, and without scaling down, you leave yourself vulnerable to someone who is willing and able to get people started with something easier than what you're offering. Bill Venners points out that the Rails folks have done a very good job of marketing what they've done. Agreed. It's been hard to see the opposite effect in the Tcl community, which has some really good technology that has been sold very poorly. Speaking of which, James Duncan Davidson says Ruby doesn't have a "compelling" gui toolkit. It has Tk though, and if they do their homework, will soon have Tile. And that's not bad... maybe it's not the glitziest thing out there, so I could see why it might not appeal to a Mac guy, but on the other hand, there are countless very compelling desktop apps waiting to be written that are interesting to people for what they do, not just because they are slick looking. And frankly, it's not like Java is that hot in the gui space in any case... Mini-Language Only tangentially related to the above, I found this while looking at ofbiz, which looks to be a pretty good system for what it does. However, the "scripting language" doesn't really make sense to my way of doing things. Look at the example towards the end: http://www.ofbiz.org/docs/minilang.html That seems like an awful lot of verbosity for something that doesn't absolutely need to be edited by a computer.

I managed to do a minor release of Monsterz that fixes compatibility issues with recent versions of Pygame and NumPy. Unfortunately, despite my recent ITP, Monsterz cannot yet enter Debian due to license issues. I really tried my best to create and use completely free content, releasing the game and the graphics under the WTFPL and using a public domain module for the background music, but I still have problems with the sound samples. Two samples are under the CC-by 2.0 (which according to us is non-free, although very close to being free, which gives me good expectations for the next versions) and 8 other samples are free and royalty free for commercial and non-commercial use , which sadly does not explicitly allow modification. I already asked for clarification last year when I started gathering media for Monsterz, but got no answer. And I did not just google for free mp3s , I really spent whole evenings hunting for the most freely licensed samples I could use. This shows exactly how difficult it is to find DFSG-free music and sound effects (as well as 2D and 3D graphics, but to a lesser extent from my personal experience). Though one possible reason may be that it is extremely easy to embed precise licensing terms within a program file, it makes me feel like coders are years ahead in terms of sharing their digital work for everyone to use and improve. Of course, not being a professional sound engineer or creator, I am most certainly missing huge parts of the whole business equation, and I may underestimate the artistic bond they share with their work (and thus their reluctancy to give it away for minor to no retribution). But I do not believe that sound samples of a grunting alien or a bouncing ball may have a high artistic or pecuniary value. And though many people outside Debian will consider our license analyses mere nitpicking, a game designer would probably never use a sound sample that cannot be modified. But instead of just ranting and waiting for new versions of licences that never come in time (GFDL anyone?), I will just try to create my own replacement sound samples and give them away for free when done.

Wow. Over 2 months and not a single blog post. Not intentional, but sometimes you have to do what you have to do. (Which in my case has been 10,000 lines of C++ and a workshop paper.) So, what’s new? Lots really, and I will write more as I wait for my 10,000 lines of C++ to run over the next few weeks, but for now, I’ll just mention the following: yesterday, Nick released Book and Volume, his latest piece of interactive fiction. I played it over a period of several months in my official role as “beta tester” and have the honour of being one of only four people to have (at this point in time) completed the game. It’s great. It’s immensely satisfying and very funny, offering a unique take on the life of a stressed system administrator and the corporate nature of American culture. You can read more about the piece on Grand Text Auto and on Nick’s site, which also contains instructions for installing an appropriate interpreter (apt-get install frotz, for the Debian kids) and a link to the the game itself. For now, however, I shall leave you with the opening paragraphs:

Your pager tickles you awake. Upstairs in the house of your childhood, in your room, and it must be time for school because—no, it’s the weekend, you remember, but your alarm is going off anyway. You should have been awake already. You’re going to miss the bus. Your mother climbs in the window. You’re dreaming. You’re a grown-up: It opens to you again, a sluggish window summoned by a mouse click. Waking up now in your own apartment, your new apartment. Your pager is buzzing and vibrating both, serious. It is in fact the weekend, but you’re not in elementary school. No one is crawling in through the window. You’re a system administrator for nWare. Waking up urgently, here in nTopia.

Continuing on from the SCC stuff, which I should probably get in the habit of calling the mirror split, then… At the same time as I’ve been trying to work out ways to fit the mirror split stuff into the AJ market concept, I’ve been pondering on and off what can be done to improve the security situation. My thinking’s probably still biassed by my long time wish for official security updates to testing, but I’m somewhat inclined to think that if we can figure out a way of integrating the testing security team and the official security team we might end up closer to a solution – at the very least that’d provide us with a decent number of people who can actively help out with security updates that aren’t secet and get a few more people familiar with the technical aspects of how security updates are released, who’ll then have less of a learning curve if they end up being added to the security team proper. And heck, even if that doesn’t work, it at least gives people running testing an easier url to remember for security updates. Of course, integrating the teams isn’t that easy, or it would’ve already been done. So after thinking about it, I had a chat with Joey (aka Martin Schulze, aka the guy who’s issued 317 of the 340 security advisories in the past 12 months) about the problems:

<aj> so, the other thing i wonder is what you think of the testing-security-support split?
<Joey> need more input
<aj> as in separate host, funny domain name, not available on security.debian.org/, extra effort to mirror, etc
<aj> i think it sucks :)
<Joey> there are a lot of sucking things…
<aj> it’s true
<aj> so, i figure the reasons for the split are (a) you don’t want to add a bunch of people to team@ and hence vendor-sec, and (b) there’s no way to make it so they can use dak-security without being full team/vendor-sec members; and maybe (c) you don’t want them officially associated with debian security coz they’re newbies
<Joey> a) and b) are true
<Joey> However, with security.debian.org being a push mirror, it would be possible to let it be pushed from a second source into a different directory, such as /testing-security/
<aj> hrm
<Joey> However, that would require all architectures to be supported and not just some.
<Joey> all as in “all that are in testing”
<aj> ah, that’s (c) then – they don’t do enough for the official debian stamp
<Joey> ah ok

Assuming those really are the key factors (which might or might not turn out true, but they seem likely) then that’s something that can be worked on. The first point is completely out of my domain – I’ve never been on vendor-sec, and it’s not likely something that ought to be tweaked much anyway; vendor-sec’s a very closed list by design, and for most security work it’s probably a distraction (testing security as is currently operates without concerning itself with vendor-sec, AIUI); the second points purely technical; and the third point is a combination of technical issues and an issue of training, both of which will be hopefully helped a lot by integrating testing-security and security.debian.org. So the easiest point of attack is obviously the second one, since it’s “just” a matter of expanding dak’s featureset. The problem here is embargoed fixes – the security team needs to be able to prepare fixes for vulnerabilities revealed on vendor-sec, but then keep them secret from everyone not on vendor-sec until the publication date. Which is fine, except that dak takes an all or nothing approach to that sort of secrecy: secuirty uploads go into accepted, get built, and then the security team run “amber” to publish the update. But what that means is the accepted directory and its contents can only be visible to people with vendor-sec access, which means only people with vendor-sec access can do security updates. But we do actually have a different queuing mechanism that allows us to keep some things secret, while not hiding everything: thanks to the crypto-in-main transition, the NEW queue acts like that, more or less, only allowing ftpmaster to see the contents of NEW packages until they’ve passed license inspections and the appropriate export notifications have taken place. And actually, we’d already considered extending that sort of behaviour to add an “unapproved” queue that would prevent uploads from entering proposed-updates without the stable release manager’s prior approval. The idea then, would be to have a couple of queues for the security team: an embargoed queue, accessible only to those with vendor-sec access that would store embargoed fixed ‘til they’re ready to be released, and an unembargoed queue for preparation accessible by a wider group, for preparation of fixes that don’t need to be secret. Both queues would need to be autobuilt (and the build logs for embargoed uploads would need to stay restricted, while the build logs for unembargoed uploads would not), which is an added difficulty, since only accepted can be autobuilt presently. But otherwise, it seems basically plausible, both to myself and Joey. Conveniently, Andrew Pollock’s been interested in throwing some money through the AJ Market to see what happens, and since the initial idea we were tossing around fell through due to his move to the US, he’s put up the dosh to make the above happen. Well, strictly the dosh to make me make the above happen, or something. Anyway, I’m already running behind both in implementation and blogging about it, so back to the grindstone… (Okay, perhaps it’s not quite the feature Mark Twain would most like added to dak, but it’s still nifty.)

About books:

• The book I think I’ve liked most, ever, is Los dominios del lobo, by Javier Mar as. I don’t think I’ve read any other novel twice.

• Between 1998 and 2003, I read a lot, but then I severely slowed down.

• 84, Charing Cross Road, by Helene Hanff, is a little wonder that everybody should read.

• Most of what I read is fiction, but none of it sci-fi.

• I find it amusing that I loved Co os, by Juan Manuel de Prada.

• On perspective, what it seemed like a lot of books, are truly very few.

• Steve Langasek may or may not dislike Carlota Fainberg, by Antonio Mu oz Molina.

• After the current Planet Debian meme/whatever (one abd zero, btw), I’ve resolved to take on reading again, but will most likely fail.

• I wish I would have been able to finish Las ideas puras, by Pablo d’Ors, and Un mundo exasperado, by J.A. Gonz lez Sainz.

• Strangely (?), I have a very strong preference for Spanish literature. The way e.g. Juan Manuel de Prada (El silencio del patinador, La tempestad) and Francisco Umbral (Las ninfas) make use of my mother tongue is obscenely close to perfection.

• Let’s mention one non-Spanish writer: Thomas Mann.

• Like with films, but unlike with music, I don’t like to make my list of read books publicly available.

I am working on my own private arch repo in Beagle 0.1.2 package. It is mostly done, but I need Mono 1.1.10 packages to test it running. As far as I know, those packages are not ready, nor available in any private repository. Anyway, if you are running Beagle 0.1.1 I strongly recommend you to upgrade your kernel to 2.6.14 version, which comes with inotify enabled. It will solve part of the problems of memory leaks, though not all of them.

I have read 13 of the books on the list that Clint mentioned. I had begun to write about all the ones which I expected to be there but weren't and then realized I might as well make my own list. So here it is in alphabetical order not in any particular rank. Some entries are actually series.

• 2001: A Space Odyssey, Arthur C. Clarke (But the sequels get progressively worse.)

• Alice In Wonderland/Alice Through The Looking Glass, Lewis Carroll

• Baroque Cycle: Neal Stephenson

• Behold The Man: Michael Moorcock

• Breakfast of Champions, Kurt Vonnegut

• Dictionary Of The Khazars, Milorad Pavic

• Earthsea Trilogy: Ursula Le Guin

• Gloriana or The Unfullfill'd Queen, Michael Moorcock

• Gormenghast Trilogy, Mervyn Peake

• Gravity's Rainbow, Thomas Pynchon

• Jonathan Strange and Mr. Norrell, Susanna Clarke

• Lord Of The Rings, J.R.R. Tolkien

• Naked Lunch, William S. Burroughs

• Ringworld, Larry Niven

• The Computer Connection, Alfred Bester

• The Dune Encyclopedia, Willis E. McNelly (The real backstory to Dune. Brian Herbert should be fed to Shai-Hulud.)

• The Futurological Congress, Stanislaw Lem

• The Island Of The Day Before: Umberto Eco

• The Moon Is A Harsh Mistress, Robert Heinlein

• Ulysses, James Joyce

All pretty damn geeky I think if not stereotypically so.

HP: Upon notification of the screen not behaving properly after the lid is shut and reopened, HP release a BIOS update that fixes it.

Dell: Upon notification of the screen not behaving properly after the lid is shut and reopened, Dell repeatedly fail to return phone calls when expected to, ask for the OS to be reinstalled multiple times, tell me that the motherboard needs replacing and then refer the issue to some internal department with no indication as to how long it will take before anything will be sorted. Total elapsed time so far: over a month.

Thanks, Dell. Thell.

Claire Giordano: “[N]o matter what the result, this project [OpenSolaris] will be written up as business school case study. I don’t know whether it will be a positive case study, or a negative one… But it WILL be a case study!”

I have had an unverified report form myself that the following will allow file to correctly detect Ulead Photo Explorer5 (.pe5) files.

cat >> $HOME/.magic << EOF
# Ulead Photo Explorer5
# Source: http://www.jisyo.com/cgibin/view.cgi?EXT=pe5 (Japanese)
0	string		IIO2H		Ulead Photo Explorer5
EOF

Its Debian Bug #339397 for now.

This essay 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 main hearing is the only part of the trial which directly affects the court's decision. It is immediate and oral and usually lasts no longer than a couple of hours. The current system is fairly young. There were several fairly substantial reforms of Finnish court procedure in the 1990's. I will discuss this history in a later essay. See more ...

So it seems I cannot uphold my word - Well, yes, it was because of the trouble it would represent to the fine Moquegua guys - But anyway, I ended up accepting the invitation practically at the last minute, and went to Moquegua, Per , probably for my life's most tiresome journey.
Saturday, after lunch, we headed for the airport. I left Mexico at 17:30, and arrived five hours later in the Lima airport. Thanks to Antonio, Jos and Laura, who picked me up at 23:30 and arranged me a room in a hotel. I met the DebianPeru crowd, a very nice group, Sunday morning - We had breakfast, chatted for a while, and went for Lima's famous ceviche (assorted seafood cooked in cold in lemon. VERY good). At 3:45PM, I took the bus to Moquegua... For 17 long hours.
Got to Moquegua at ~8AM, went to the Jos Carlos Mari tegui University. I met the other guest speakers for breakfast, went with them to meet the Univerity Rector, hooked up some minutes to the net, went to a typical Moqueguan restaurant, gave my talk... Then hurried up to get the bus back to Lima. We got there five minutes before it left. I don't know why or how, but the bus back took 14 instead of 17 hours - I will not complain ;-)
Back in Lima, Carlos met me at the bus station, we went for breakfast, and hurried to the airport. I crossed the gate at 12PM, hurried by the airline personnel (and didn't manage to see Rudy/Stone_Head, who was on his way there)... Just to find the plane was delayed, although by little. Sat down for a while, hacked for a bit, and took the plane back home.
Summing it all up, I traveled roughly 40 hours, out of the 72 hours I was out of Mexico. Of course, you could add 1hr travelling to the airport and 1:30 back home... Anyway, 40/72 is quite close to 42/74 :)
I am tired. Plain tired. I am just waiting for Nadezhda to get home, as I want her to find me alive, and I'll crash down in bed.

Who can resist a good rhyme? Or a bad one? So this round of dak hacking turned out to make the AJ Market scheme another notch more confusing – hence the delay in blogging, and the teaser in my last post. The issue leading to the confusion is that the major item on the list to start hacking on was SCC, which unlike the projects I’ve undertaken so far, is more than a day’s hacking. In fact, due to the need to give mirrors a chance to adapt to the new system between it being implemented and actually used, it’s actually more of a multi-week task. And doing it as a one-day-a-week project would extend that into a multi-month task afaics. I guess that’s still better than never, but obviously it’s worth looking into alternatives. Naturally, then, the first phase of a longer project like this is threefold. We’ll call it “the three P’s”. Planning My theory at this point was to come up with a plan for what to do, try figuring out how much work it’d take, and then see what sort of financial arrangements might be plausible – not involving me cutting a few weeks out of my life for spare change, but without making the whole thing an unleapable chasm from what the AJ Market’s currently managing either. I figured writing it up as a semi-formal proposal makes most sense:

Summary Implementation of the outstanding mirror split proposal for the Debian archive to allow new architectures, particularly amd64, to be included in the archive. Benefit In spite (or perhaps because) of its simplicity, this project has been languishing for over two years, and is not currently being worked on; so at present it’s not even possible to estimate when it would otherwise be completed. It is most notably preventing amd64 from being integrated into the normal Debian development environment, causing derived distributions to maintain amd64 specific patches themselves. In the longer term, reducing the constraints imposed on the archive size may allow the introduction of additional suites, such as backports or volatile, as well as additional architectures; though significant further discussion on this would be needed. Background Since at least mid-2003 the Debian archive has been closed to new architectures due to the already large amount of space and bandwidth required to become a Debian mirror. At present, the archive uses some 158GiB of disk, and about 1GiB per day; additional architectures are expected to require approximately an additional 10GiB each, and there are likely around half a dozen architectures that will be considered for addition once the moratorium on new architectures is rescinded (incl amd64, armeb, sh variants, kfreebsd and possibly partial architectures for arch variants such as s390x and ppc64). The primary work needed to fix this involves:

• ensuring the mirror network operates correctly when a majority of mirrors are partial; this reduces the impact on bandwidth and storage capacity
• optimising portions of the archive maintenance software, particularly apt-ftparchive; this reduces the load on the archive server
• providing appropriate guidelines on the qualification criteria new architectures need to meet in order to be added to the archive; this provides a limit on future increases, allowing growth to be appropriately controlled

Actual work I expect there will be six phases to the project:

1. cleanup of the archive as it stands, and establishing a clear categorisation of its contents to define what a partial mirror by architecture or suite should officially contain
2. providing appropriate scripts to ensure mirror sites can easily comply with the previously defined expectations for partial mirroring
3. devise an appropriate structure for the new mirror network, that can easily incorporate existing mirrors, and coexist with the existing structure
4. provide information on the new structure to both mirror admins and users; assist with the transition, and resolve any problems found
5. ensure the archive management software is appropriately optimised, and that archive inclusion criteria have been debated and established
6. add new ports that have passed the qualification requirements to the archive

In theory, a couple of days for each of those sound plausible, so making that twelve days actual work (with a couple of week’s delay in between for mirrors to have some time to adapt to the new network). On the downside, twelve days at a day a week is over three months of real time, not counting the possibility of doing other things with the one day a week, or Christmas, or the aforementioned delay for mirrors. Yick. So much for planning. Preparation So the next “p” is preparation. In this case that’s finally getting around to fix dak CVS, which has been slightly broken since May. The extent of the actual breakage was just the loss of the ChangeLog history, aiui (or at least, that was the unrecovered breakage), but the result of that was months of uncommitted changes on both ftp-master and security (and reportedly from Ubuntu’s dak installation too). The changelog for the first set of commits (not counting buildd changes from ftp-master, security changes or Ubuntu changes that haven’t made it to ftp-master) looks like:

        * tiffani: new script to do patches to Packages, Sources and Contents
        files for quicker downloads.
        * ziyi: update to authenticate tiffani generated files
        * dak: new script to provide a single binary with less arbitrary names
        for access to dak functionality.
        * cindy: script implemented
        * saffron: cope with suites that don't have a Priority specified
        * heidi: use get_suite_id()
        * denise: don't hardcode stable and unstable, or limit udebs to unstable
        * denise: remove override munging for testing (now done by cindy)
        * helena: expanded help, added new, sort and age options, and fancy headers
        * jennifer: require description, add a reject for missing dsc file
        * jennifer: change lock file
        * kelly: propogation support
        * lisa: honour accepted lock, use mtime not ctime, add override type_id
        * madison: don't say "dep-retry"
        * melanie: bug fix in output (missing %)
        * natalie: cope with maintainer_override == None; add type_id for overrides
        * nina: use mtime, not ctime
        * katie.py: propogation bug fixes
        * logging.py: add debugging support, use   as the logfile separator
        * katie.conf: updated signing key (4F368D5D)
        * katie.conf: changed lockfile to dinstall.lock
        * katie.conf: added Lisa::AcceptedLockFile, Dir::Lock
        * katie.conf: added tiffani, cindy support
        * katie.conf: updated to match 3.0r6 release
        * katie.conf: updated to match sarge's release
        * apt.conf: update for sarge's release
        * apt.conf.stable: update for sarge's release
        * apt.conf: bump daily max Contents change to 25MB from 12MB
        * cron.daily: add accepted lock and invoke cindy  
        * cron.daily: add daily.lock
        * cron.daily: invoke tiffani
        * cron.daily: rebuild accepted buildd stuff
        * cron.daily: save rene-daily output on the web site
        * cron.daily: disable billie
        * cron.daily: add stats pr0n
        * cron.hourly: invoke helena
        * pseudo-packages.maintainers,.descriptions: miscellaneous updates
        * vars: add lockdir, add etch to copyoverrides
        * Makefile: add -Ipostgresql/server to CXXFLAGS
        * docs/: added README.quotes
        * docs/: added manpages for alicia, catherine, charisma, cindy, heidi,
        julia, katie, kelly, lisa, madison, melanie, natalie, rhona.
        * TODO: correct spelling of "conflicts"

Ugh. Still, that’s enough to start work. And the final “P”? Come on, be honest with yourself, you know what it’s going to be. Procrastination Okay, that’s not entirely fair; the irrelevant bit of work was actually on to TODO list before SCC (mostly because it was something that I could get done reasonably quickly) and in fact was this line of the above changelog:

        * dak: new script to provide a single binary with less arbitrary names
        for access to dak functionality.

All the various model/actress names have been getting more than a little confusing recently, with almost forty in the dak suite, and another two dozen or so in use elsewhere – and then there’s the fact that the whole hot babes thing is both a bit offensive, and getting a bit old. OTOH, you need something to rename them to. We ended up deciding on the “version control solution” and introducing a “dak” command that’d launch all the different little bits of functionality depending on arguments, in the same way cvs, svn, tla, bzr, darcs etc do. The implementation’s kinda neat: we have a list of commands (like “ls”) and their description (“Show which suites packages are in”), along with the python module and function they’re in (“madison”, “main()”). That let’s us not actually have to change any of the other scripts immediately, and lets “dak ls foo” work the same as “madison foo”. It also means that down the track we don’t need to have separate modules for each subcommand, and that we can rename modules and functions without affecting the user interface. Of course it also means that all the internal scripts haven’t changed to use the new names yet, leaving the new interface a bit underused, but hey, “dak ls” at least manages to be one character shorter than “madison”, so that’s a win! To be continued…

So, today has been a day of hardware. Some good, some bad. First, the good. Take one Via EPIA-M motherboard, add a helping of LinuxBIOS and Etherboot and let simmer for a few hours on a low heat. Then add a sprinkling of Phil Hands' d-i preseeding for the final garnish. Tweak to suit your tastes and lo and behold. A neat little motherboard that does proper serial console, boots d-i over the network via tftp and does a completely automated Debian install. Of course, it's not quite that easy. LinuxBIOS requires a few out of tree patches that are still under discussion. The latest version of Etherboot (5.4.1) doesn't seem to work (lots of rubbish on the serial console and no boot), but the version that does (5.2.6) requires a backport of the latest via-rhine driver to avoid leaving the network card in a state that Linux isn't happy with. And Phil's documentation could do with some updating (which I should really email him about). Oh, and add to that the fact that numerous things seem to assume that there is a PC BIOS and that it will support standard interrupts. Yeah, like that's going to happen. Still, I seem to have almost got there and it's quite funky to watch it all happen automatically. Kudos to the d-i team for the ease with which you can preseed. Flush with success I moved on to the next challenge; scanning some forms before posting them off. Nice and easy, normally. If it weren't for the fact that the machine with the SCSI card for the scanner just happens to be the one I stole for the above, and that the new case it's in doesn't allow any PCI cards. Bah. So, find a spare machine, get it into a state where I can actually drive the scanner, scan away. Took far too long. I really need to get it hooked up to my main machine, but there isn't enough desk space to have it close enough for the cables I've got. Perhaps I should crack and buy a USB scanner. I don't really need high quality, just something as an alternative to photocopying. After that trial I've moved on to upgrading my PVR box; I got a new 320GB HD today to replace the 40GB that I'd been using - it was getting to annoying to have to either watch or syphon off various series that I'm recording. While I had the box open I decided to upgrade the motherboard to something that might support wake-on-lan, so this turned into a bigger job than it should have been. :( I'm currently waiting for the data to copy across before trying to stick it back together. Bah. Don't suppose anyone has an S370 P-III better than 667MHz and no better than 1GHz they want to part with cheaply? I'm currently running a Celeron 800MHz (which I think is a slight step up from the previous PIII-667), but a little more oompfh would help with streaming over the network. I'd just upgrade to something modern, but I suspect the extra cost of silent cooling would be a killer.

I'm very excited to announce the Call for Participation for XTech 2006. Submissions are due by 9th January. The conference itself is 16th-19th May 2006, in Amsterdam, Netherlands. The theme this year is "Building Web 2.0", focusing on the technologies and issues involved in building the next generation of web applications and services. There are four tracks --

• Applications -- "mashups", frameworks, publishing, open source solutions, aggregation
• Browser Technology -- browsers, AJAX, design and interaction for Web 2.0
• Core Technologies -- the XML and RDF family, RSS/Atom, databases, nuts-and-bolts tech
• Open Data -- information design, identity, tagging, privacy, trust, Creative Commons, DRM, government

I'll write a bit more about each track in the coming weeks, but if any of this turns you on, head over to the full call and submit your abstract. Also, do read the full track descriptions -- they go into more detail than I can here. Tutorials will be held on the 16th, and the presentation tracks from 17th-19th. In 2006 I want to build on the success of last year and broaden XTech's reach into web technologies. On the technology side, I'm particularly interested in getting more in about databases, frameworks like Ruby on Rails, tagging and search. In addition to technology, I'm interested in opening up dialogue between developers, designers and information architects about the kinds of applications being built on the web now, and the issues of their design, organization and implementation. Partly to encourage this, 2006's conference will have more room for panel discussion sessions. Feel free to drop me a note with any questions or suggestions about XTech 2006. (If you want to propose a session, please use the online submission form rather than sending email.)

Strange things are going on in the LinuxTag association. Yesterday, a press release was published announcing that LinuxTag e.V. will celebrate a booth party at the LinuxWorldExpo in Frankfurt today. Needless to say that the core mailing list was informed about the press release nearly one hour after the release and not prior to it. It is very interesting to learn that LinuxTag supports and enhances its only competitor with a party that also claims to be the largest such event with the most companies and visitors ("facts" most visitors can't backup, but nevertheless). The party is attributed to the community, which is quite abundant at this event apparently. Unfortunately, this also demonstrates that even after the big bang as a result of the press release covering the move of LinuxTag to Wiesbaden, nothing has changed within those who lead. They still don't seem to be interested to work together with the others in a "team". In response to the Wiesbaden press release in October two more people have left the association due to this constant skipping of team members and missing information distribution prior to their release in the press. More and more former team members who have committed large amounts of time and energy to the event in the past are leaving the group. To those who have wondered whether I left the boat or not: I have left the association in April already after the CeBIT disaster, together with three others including the founding member Klaus Knopper. However, in order to support the community and projects I decided to continue the work I've already started and supported them during the show. However, things have only gone worse since then. Currently, there's only about a 20% chance left that I'll be part of the next organisation team. Having a functioning team and team work is a precondition to this. Being paid, since others are being paid as well and I need to live from something is also a precondition. Until now, I haven't been paid for my work at LinuxTag, not even my expenses from this year have been reimbursed. It was said that the party was mentioned in a protocol from the 10th already. Also the press release was accidently released before the mail and should be release at the next morning. However, 18h until 10h next day is not that much when the text has to be modified.