For those who've been hiding under a rock for the last few months: dunc-tank is the (controversion) project that was founded by the current DPL, Anthony 'aj' Towns. Controversial, because a lot of people feel that this goes against the spirit of Debian; and that by paying some Debian people and not paying others, we're creating a two-class system that we'd best avoid. And probably a bunch of other arguments, too, but that's not what this blog post is about. Me, I've been staying rather quiet in the whole debate. It's not that I don't have an opinion; rather, I haven't been voicing it, mostly because my thoughts on the matter are rather convoluted, and I'm not sure I can put them in words pretty well. But since the debate seems to be going in circles, and since I think that I might be able to help it out, I'll try anyway. If that doesn't bring the debate any further, well—can't blame me for trying. Do I think that paying people to do work on Debian is necessarily a bad idea? No, not at all. Quite to the contrary; by paying people to work full-time on Debian for a while, we will increase the amount of work that's being put into Debian, which can only be a good thing; and I can only applaud aj for trying to get this done, since it should be obvious to anyone involved that by proposing this, he only had Debian's best interests (i.e., improve our distribution) in mind. The obvious question, however, is who we'll be paying. After all, while I don't think it's necessarily bad to pay people, I do think that with money, you introduce the possibility for corruption; so at the very least, it should be strictly checked what exactly happens with the money that's being spent. Accordingly, the way in which you pay people—your whole set-up and procedures—should have a number of safeguards. Which brings me to my next point. Do I think that dunc-tank, as a project, is a good idea? No, not at all. Quite to the contrary; and I have a number of reasons for that. First, I don't think that deciding by committee who can get paid and who can't is the way to go forward. A committee will always be biased, no matter how diverse its membership. Even if you could find a committee that would not be biased—an impossibility by definition—then there will still be people who will not agree with the committee's decision. Are they right not to agree? Not necessarily. Is it bad to create such controversy if it could be avoided? Sure as hell. Moreover, by creating a project which populated by Debian people and which has the sole purpose of paying Debian people, it's fairly possible to create the impression as if all other ways to get paid to do Debian work would be unsound; that if a developer accepts money for Debian work without going through the committee, he's somehow doing something morally wrong. This would be very bad indeed; I know for a fact that there are cases of people paying Debian Developers to work a few days on a certain package so that a certain bug which impedes their business is fixed, or so that a certain version of a random package which this company is using, is uploaded into the archive. I've done this myself in the past (although I can't disclose more, since the person who paid me requested to remain anonymous); I know of at least two other Debian Developers who've done so as well. So what's the alternative? Not paying people is one, but it would not necessarily be the best. One alternative, which the FreeBSD people have been doing, is just "no organization at all". People who want to get paid just put up a web page with the amount of money they would like to have, and it's up to the community to decide whether their request is valuable enough for it to actually be paid. To some extent, this is also what the Dunc-Tank committee is doing, except that as FreeBSD does it, there is no committee in between. The problem with this approach, however, is that if we all go ahead and ask for money at the same time, it'll not only make us look like a bunch of beggars; it's also very likely that nobody will actually be getting any money, because there's so many "good causes" to choose from that there might not be enough donations to fund them all. Another proposal was one made by Manoj Srivastava, before word got out that dunc-tank would be started (or about at that time). As it was made on the debian-private mailinglist, I can't say much about that; suffice to say that I feel his proposal was overly bureaucratic, and had problems that were similar in nature to the problems I feel exist with dunc-tank. So do I have any answers which might get us a way out of the current status quo? Nope, afraid not. But allow me to make this final observation: In early 2005, a bunch of people decided that Vancouver was a nice place, and travelled there. As it happened, they were all Debian people. What a coincidence. Since they were all there anyway, they decided to talk a bit about Debian, and as a result, came up with some plan for its future. This plan, too, was rather controversial. When I initially read the first few paragraphs, I suddenly fell upon this paragraph which seemed to say that "we suspect we won't be releasing with anything but i386, amd64, and powerpc for etch". Things suddenly turned kinda red from then on. And it wasn't the wine that I hadn't been drinking. I could imagine that what I felt back then is somewhat similar to what some other people felt when they first heard about the suggestion to pay people for Debian work; and this realization is the reason why I haven't been dismissing their arguments or thoughts, much like I've seen other people do. However, I cannot say that I feel the current crisis to have many parallels with the Vancouver one; this is mostly because in the current case, people on both side of the argument seem to be building up walls around themselves, to help them ignore whatever the other side was saying. In contrast, when someone suggested something which had the potential effect of throwing most of the hard work I'd been putting in for Debian during the last five years now down the drain, I went to talk with them—after the heat had cooled down, anyway. Unfortunately for me, the result is exactly the same; for all my effort, I haven't been able to prevent m68k to be kicked out of the release; and to say I'm not happy about this would be an understatement. But at least this way the port has been given a fair chance; if I hadn't been talking to the people on the other side of the argument, I would still be talking about Steve Langasek as if he were the devil himself, and m68k would probably have been kicked out of Debian—along with a bunch of other architectures. At least I got that bit fixed. I guess what I'm saying is that people, rather than farting in eachother's general direction, should be working together in finding a compromise. Sure, that means making concessions, and agreeing to something you'd rather not agree to. But at least this way, the thing you have to agree to isn't as bad as what it could be. And trust me, people will do the stuff you don't want them to do, with or without your agreement. Hell, they've already started. Whoa, long post. I'll stop preaching now.

Given the recent articles or blog posts that may lead some people to think that dunc bank made people work against Debian, maybe some explanations are needed. Dunc-bank is a single web page that some humourless people may find unfunny, YMMV, but that is nothing else than satirical. There was no conspiracy, undermining work, or power games. People claiming the contrary are just making complete fools of themselves. Really. The people that contributed to dunc-bank, meaning that did report most of the RC bugs in the last month are for some, even disgruntled when it comes to dunc-bank (I'm thinking e.g. of Lucas Nussbaum that did a full archive rebuild and reported many bugs). No, dunc-bank is not the evil masonery club that some depict. The sole thing I think really happened, is that people are nowadays really concerned about QA, and that there is a whole lot of issues that can be tracked automatically, at home (a good ADSL line and a GHz grade CPU is largely enough to do an archive rebuild in a week nowadays). What is really a shame in fact, is that those checks are not performed by Debian for any package, and on a regular basis. The other factor is that I think many people had concerns with etch quality, as many discussions in the past month may have let think that its quality could suffer from the announced release date. Now that this bad joke is now officially a dead-line, I think this is less and less a concern. That said, Yes, I do think some people that usually did good work in debian diminished their work considerably, and that it hurt the release. We lost some developpers (our locales + X-keyboard expert and that's a huge loss), some orphaned a lot of packages, and recent events do show that you can't improvise beeing the libpng maintainer a month before the release, and so on. Yes it's true that recent events and surroundings in Debian^[1] have led people to feel they are strangers to what Debian is becoming. And blaming them for not beeing supportive is very distateful and shocking. When you do pursue actions, that will lead to big changes in the community, then blaming the community members for those changes is a shame. So no, you can't blame the people behaviours (that have been reduced to dunc-bank supporters because that's so easy) for etch beeing late, because you can't blame the direct consequences of an action for beeing the cause of its failure.

Wouter and Russel: Wouter is right that 0.0.0.0 (or 0 in short) is not an alias to 127.0.0.1 (aka localhost). There are interesting things about specifying IP addresses though. As Matt said in a comment to Russel’s entry, 0.0.0.0 can be shortened to just 0. That’s right and also, 127.0.0.1 can be shortened to 127.1 with any software which implements parsing of IP addresses correctly. Actually, 2130706433 (127*256 +0*256 +0*256+1) would be an alternate alias to 127.0.0.1. A different example would be http://1426782553/ or http://85.719193/, which should take you to my blog at http://blog.incase.de/ (at IP:85.10.249.89) - Except that my Apache doesn’t seem to be able to handle the request with that hostname.
Update: a working example is http://1208933736/ or http://72.974184/ which takes you to google.

Russell, 0.0.0.0 is not the same thing as 127.0.0.1. You may get the same behaviour in some cases due to some implementation details, but that does not mean that both are the same! 127.0.0.1 means "The host this software is running on". In contrast, 0.0.0.0 means "Any host"; it can be used in software as the C constant "INADDR_ANY". While it is true that connecting to 0.0.0.0 from software such as ping will yield the same result as connecting to 127.0.0.1, it is absolutely not true that listening to 0.0.0.0 (in a bind(2) kind of way) yields the same result as listening to 127.0.0.1. After all, in the latter case you will only accept connections that originate from localhost; in the former case, you will accept any connection, whether from localhost, the local network, or the big and evil Internet. I presume you will have at least some firewall in between, but still. That being said, however, 127.0.0.2 is an alias for 127.0.0.1. So is 127.0.1.0. And 127.255.0.1. And, really, anything in the 127/8 network range. Now that has no utility—there can be use in having a /24 reserved for loopback, but a /8? Who would ever need 16M ip addresses for the local host? Is there even an operating system that can keep track of that many IP addresses? Oh well. not as if I care. And, after all, IPv6 has fixed that little issue. Although it might be fair to say that they overcompensated there a little bit.

[RV Heraclitus SE Asia voyage: blog photos] The past few weeks, we changed our route to visit an uninhabited island (aka Ko Pulau Island) said to be "National Geographic, man" by some Americans we met in Kupang. On the way to Ko Pulau Island we saw a large school of pilot whales and dolphins, a humpback or other whale close to shore, a blue starfish and hot water vents nearby on the same mostly dead reef, a flock of birds feasting on a dense school of fish, a manta ray, a bonfire on the beach shared with the kids of Rote (who we swapped roast banannas and coconuts with), a clean hull and renewed sea-sickness. At Ko Pulau Island, we saw a long white beach made of small bead things instead of sand, with surf at either end and reef in between, a green lagoon with islands being eaten away at the base, a monkey-head rock, pink coral, reef fish, sea urchins, various pieces of flotsam washed up on the beach (flip-flops, a light-bulb, bottles, wood, burnie-beans, nautilus shells, a seabird egg, a dead seabird and other crap), sunset over the ocean with golden cirrus in the sky, turtle nests, tracks and hatchlings scurrying off into the water, Indonesian fishermen in need of water and turtle eggs, tidal pools with the occasional crab, ghost crabs darting towards the water, a pandanus stand, a small cave surrounded by discarded turtle eggshells, spinifex, hermit crabs, scrambling lizards, sunburn and other things. Later in our voyage, we saw a big lone flying fish, land looming mountainous on starboard, TNI, gratis reef fish, water buffalo and threatening rain clouds. The next major stop was a bay on the south side of Sumba, black cliffs to port and an eroded hillside to starboard. There, we enjoyed the excellent snorkeling against the cliffs and off the beach, birds calling from the forest, wasps - shiny blue and otherwise, meeting roaming cows in the forest, forest fungi and other sights. We met some fishermen and drove through the forested slopes toward a nearby city. On the way, we visited an Indonesian village and saw their traditional animist temple, ample baby pigs & dogs, tons of kids trying to get in photos, satellite dishes and graves in front of houses. Unfortunately, I crashed once we reached the hotel, missing eating and night life, but I did enjoy the sights from the windows of the cramped 4WD we were in. We headed for the 9.8 knot passage of Selat Sape, complete with eddies, currents, a barracuda and the steep slopes of a silent volcano. Since there, we saw an increasing number of interesting and curious Indonesian vessels, fish traps, the grey shapes of dolphins swimming in the aqua water under the bow, a floating sandal, a school of mahi-mahi jumping out of the water, a misty night, numerous schools of feeding fish, entangled luminescent trails left by dolphins swimming in the phosphorescent water beneath the bow, flashes of lightning in the distance, our first rain since Cairns, the associated storm, Jack the fisherman (a mast hallucination) and other things. Our next stop was Kalimunjava (north of Java, Indonesia), more than half way to Phuket. We spent a week there, watched lightning, collected rain, visited the local school, dived and snorkelled on the magnificant reef with some really nice university students (hi Lely, Dudu, Jaos and others) from Java who were doing a study on the corals and hiked up the steep slopes of the island. From there we ambled past Borneo, towards Bintan, near Singapore, experiencing the first non-calm seas in ages, dolphins in the storm, floating lines of debris, big barges, container ships and megatankers, a fancy, shiny yacht, fishing vessels with 50,000 lights, Rain Drop and it's egg (child of Rain the gecko), amazing cloudscapes at sunrise, throughout the day and at sunset on the way. Amazingly, we met the 8 (Infinity, the new PCRF vessel) one find day in the South China Sea on their way to Bali. Eddie saw them from 5 miles away and knew almost straight away it was them. Michelle came on board and a lone daytime cumi (squid) swam between us as we parted. Before we arrived at Pulau Bintan (near Singapore), we saw seasnakes and a palm tree floating and lots of wind and rain. We will probably arrive in Thailand by January and I'm thinking of passing thru Sydney on the way home, so let so please mail me if you want to meet up.

Last week's sunday (that is, 2006-12-10), we had a concert with the choir. Rather than just singing four songs as we did during our "toonmoment", this time we had about an hour of music, spanning about everything (really) from the Renaissance up to modern music. Pretty fun, that. It went pretty well, too—except for one little note which we totally missed in the low end. But that's because it was really in the low end, and we had gone down a bit. For those who care about that stuff, there's a (low quality) fragment of the video they made of the concert up on youtube, with us singing "Tourdion", a French Renaissance drinking song, which we opened the concert with—although this version is the one we did at the end, because people asked for another song. I stand at the far right, the last bass singer; at my left (your right), there are only altos. Occasionally, the first alto to my left happens to be Leen Verhelst, my sister, who's been in choirs mostly all her life.

Jono Bacon wrote a long blog entry on Planet Ubuntu about his vision of freedom, and how it applies to the proprietary drivers. This is a good opportunity to write sthing I wanted to write for a long time. Ubuntu’s bug #1 is “Microsoft has a majority market share“. Well, I think that this should be of severity minor or wishlist, not critical. A better bug #1 would be “our priority is our users” (does it ring a bell ?). I find it far more important to improve the satisfaction of people already using a Linux distribution, than to try to convince others to use it. Most users of Windows have very good reasons for using Windows, like proprietary applications that have no equivalent in the Free Software world. I don’t think that “Linux doesn’t have a 3D desktop” is the major blocker for people not using Linux. Windows doesn’t have a 3D desktop. Many Mac OS X users don’t use the 3D features. I haven’t felt the slightest need to try a 3D desktop, and I’m using GNOME/metacity, so the jump wouldn’t so hard to make to compiz. I’m not saying that a 3D desktop is not a good idea. Of course, it would be nice to have LiveCDs that just work and start a 3D desktop, so we could show off at conferences. But I haven’t even bothered to google for such LiveCDs. Sometimes, proprietary drivers are more needed on Linux, for example for people who bought a Wifi card without checking first if it was supported. But I don’t think that 3D graphic drivers are that important. I still hope that Ubuntu will not ship proprietary software by default, and that Ubuntu will try to help the free drivers instead. Update: I forgot to close the comments when publishing this entry. They are closed now, but trackbacks are open if you want to write your own blog about this (I don’t think it’s necessary, all arguments have been reharsed many times already. Ah, and for the records, the free ati driver works perfectly fine and fast (using MergedFB) in my dual-screen setup (2560*1024), with xv on both monitors.

For me to accept someone's claim that they are perfect, they have to back it up first. I discovered that I, too, am perfect—for the time being. I also discovered that currently, there are only 44 known perfect numbers. The 44th is, uh, slightly large.

wouter@country:~$ LC_ALL=C wget
http://amicable.adsl.dk/aliquot/c1/perfx44.txt
--10:54:31--  http://amicable.adsl.dk/aliquot/c1/perfx44.txt
           =>  perfx44.txt'
Resolving localhost... 127.0.0.1, ::1
Connecting to localhost 127.0.0.1 :3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 20,107,132 (19M) [text/plain]

Holy sweet smoking mother of Jezus. (note, though, that the 20M characters include newlines every 80 (or so) characters. The 44th perfect number, which occasionally was discovered this year, has 19616714 digits. That's 19 million 616 thousand 714 digits)

At the main train station in Munich, at the subway level there is a big screen showing ads and miscellaneous information to capture the attention of the waiting passengers. These screens are pretty nice, they show some comics, random facts, some headlines, weather forecast and similar things. In their "bits & more" computer tips section they today showed the URI for some linux application finder. (That is not at all specific to germany, so I doubt they paid for being mentioned) I was really surprised to see a Linux software page mentioned on such a high visibility place; stuff there is usually targeted at the total computer newbies. Now if this isn't a sign that Linux is becoming mainstream...

That would solve so many problems. LaTeX is still unbeaten in terms of print quality. It's really powerful. Since I've been using it, if started to really despise Writer and Impress. latex-beamer slides look just so much better than any PowerPoint presentation I've ever seen. However, it's far from easy to use. The syntax is a pain, and I don't think it's a feature that you can actuall program in this language. Similar things hold for BibTeX - there are so many things to do wrong there that will go a long way unnoticed. I've recently helped a friend to fix some BibTeX files. It was a pain, there was so much wrong in there... for example URLs. People noticed that they can't just always copy URLs in there, because some characters are special to LaTeX. But instead of using the \url macro, which would also have solved linewrap problem, they started doing the most obscure things (and of course they did not read the FAQ we wrote for them or asked how to do it right), for example adding whitespace to enforce line wraps, replace _ and & with whitespace etc., wrap uppercase chars in - an awful mess. The same thing with the author values. They just wrote "First author, second author" without considering that this might be interpreted according to the common "Last Name, First Name" scheme: e.g. "van Damme, Jean-Claude". (The correct syntax is "First Author and Second Author and Author, Third" - use "and" for separating even when you have more than two authors.) XML is better here. It's rules of escaping are generic and application-independant, and thus you'll have much more tools that know how to do it right, and you only have to learn it once, not for each application. The structuring also comes in handy:

  <authors>
    <author firstname="Foo" lastname="Bar" />
    <author firstname="Gnarf" lastname="Quux" />
  </authors>

is a bit more to write, but it avoids parsing errors. And with good utilies it's not particularly hard to write. Now don't point me to XML-FO. I know about formatting objects, the paper I submitted to the eXtreme Markup Languages conferences was done with FO. It's just that they don't come anywhere close to LaTeX in terms of print quality, the only OpenSource implementation I'm aware of didn't make much progress (but they seem to have released a rewrite in the meantime) and was lacking important features, and MathML has a horrible syntax mess (apart from Apache FOP not having MathML support). XSLT also has an annoying syntax. Too verbose and totally unreadable once you do things that are a bit more complex than the simplest examples. I wish we had something that gives a similar print quality to LaTeX, that uses some XML format (or something similar structured and easy to parse, like Xcerpt data terms, but thats basically equivalent to XML, just a bit more compact; Lisp S-expressions and OEM are other examples) that allows the easy creation of third party utilities and does away with all the black magic involved... Yeah, IMHO it's really time for a rewrite of LaTeX with a modern language design. And a large, unified standard library; plain LaTeX sucks, you can barely use it without extras such as url, hyperref, latex-beamer. [Update: yes, I'm aware of bibtexML, but it's just as bad, you still need hacks such as "the C language" or using "and" to separate multiple authors. I'm also aware of docbook and docbook to latex converters; that definitely is a workaround, but doesn't solve the real problems] (Comments in my blog are intentionally disabled. So if you want to voice your general dislike of anything with XML, abuse your own blog!)

I am really upset by the way the ARM build daemons are managed. The packages are not uploaded regularly, with sometimes three days between two uploads. Well it should not be a problem, if packages that have failed to build due to some packages not uploaded fast enough (see for example python-gnome, or rkward) were requeued, but that’s actually not the case. Also last week, the build daemon named “cats” stopped to upload packages, despite it continued to build them. 11 days later, nothing has changed even after a mail to arm@buildd.debian.org. And I do not speak about build daemons building nothing. All of that resulted in ARM being the slowest architecture to build packages. It looks like the ARM build daemon maintainer does not know the excellent page made by Jeroen. As arm@buildd.debian.org is everything but responsive (well if you can assign a level of responsiveness to /dev/null), I have decided to act. I have installed QEMU on an 8-way Opteron machine, and created 8 emulated ARM machines, which 256MB of RAM and 10GB of disk for each, all running buildd + sbuild. Altogether those 8 emulated ARM machines should be faster than all the Debian ARM build daemons. I have setup a wanna-build database on my server. During the day it has built around 100 packages. Yes I agree that real machines would be better, but I don’t have a stack of fast ARM machines at home. Anyway when you see random segfaults on the build daemons, or strange failures (that happen for weeks) on the build daemon named “netwinder“, you may think to that again. Unfortunately the machine I use for that is only available for a few months, and I will have to stop the emulated machine then. I just hope that the situation with respect to the build daemons will improve, so that I can stop them even before.

I’ve spent the last few days in Badajoz for the Debian QA meeting in Extremadura. It was my first Debian event, and it was really nice to finally meet all those developers I only knew over the Internet until then. The organisation was very good in general, and C sar G mez really deserves kudos and some rest now In addition to the usual mail processing, I worked on a few things:

• I processed some logs from a rebuilt of all packages in etch and filed about 20 RC bugs about FTBFS. I also did several libpng-related rebuilds, checking that etch packages that b-dep on it still build with the proposed new version. And I investigated a few bugs.
• I also worked on a dirty script to generate the List of packages with problems wrt release (packages in etch with RC bugs, or packages in unstable but not in testing). See the list sorted by maintainer, and the list sorted by popcon score. Despite the unavoidable high number of false positives, I think that some maintainers were actually unaware of the status of their packages, so the list was probably useful.
• I gave a talk about Collaborative QA. The idea is try to move from the current non-organisation (QA one by a bored developer, on his own, because the release is approaching) to a more organized structure (team ?), allowing to share the load and share information (blacklists, false positives lists, processes, etc). I’m not sure yet if this will work, because many people consider that the current way of working on QA is OK, but I’ve created the collab-qa alioth project, and will try to use it to store information about my archive rebuilds. More to come about this later.

In general, I was pleasantly surprised by the fact that all DDs there were very friendly, welcoming, etc. Quite different from the picture of the Debian project one can easily get by looking at the mailing list. It was really nice to have so many interesting discussions with interesting people.

On several occasions in discussions about life etc friends have mentioned the theory that quantum mechanics dictates the way our cells work. In the past I have not been convinced. However this site http://www.surrey.ac.uk/qe/Outline.htm has a very well written description of the theory which is very compelling.

As anyone who follows my blog knows, I’m fond of linking to other sites with brief little quotes that either get me thinking or reinforce points I’m trying to make elsewhere. (Credit where credit is due: Dave Winer and Doc Searls both do this very effectively, and I’m just shamelessly copying them, down to the quoting style they typically use.) One of the quotes I’ve had queued up for a long time is this one from Jon Udell:

I have a confession to make. Sometimes, when I m trying out an unfamiliar open source component, I cheat. Even if the software I m working on will deploy to Linux, I ll sometimes develop it on Windows first. Why? Because on Windows, an open source component is likely to come with an installer that just works.

He’s right. Unless an application is included with your Linux distribution of choice, installing that application on Linux is a nightmare compared to Windows. Here’s an example. To install Sun’s Java Studio Creator on Windows, I just click on the .exe on Sun’s web site, which downloads the file and places it on my desktop. I double click the .exe (after, of course, checking it for viruses) and am up and running in a few minutes. In contrast, on Linux, I click on the .bin, which downloads the file and.. up pops a text editor showing me a /bin/sh script. Nice. Fortunately, I know what that is, so I save the script to a file on my desktop. I double click the file, and.. up pops a dialog box telling me the file isn’t executable. Nice. Fortunately, I know what that means, so I drop into a shell and run chmod +x ./creator-2_1-linux-ml.bin. I double click the file again, and there’s a nice graphical installer now. Finally, it looks like everything is going my way. Halfway through, though, the installation fails, telling me I need to install the RPMs for compat-libstdc++ and compat-libstdc++-dev. Nice. Assuming I even know what an “RPM” is, I then realize: I’m running Debian, and Debian doesn’t use RPM. Maybe I know about alien, but even if I do, where do I go about getting the compat-libstdc++ and compat-libstdc++-dev RPMs? At this point, I’ll probably hit Google—that is, if I haven’t already thrown up my hands in disgust and gone back to Windows. After a bit of Googling, I find this page, which tells me on Debian what I really need is libstdc++2.10-glibc2.2 and libstdc++2.10-dev. Of course! I should have known that. (Note: I’m being sarcastic.) After installing those two packages, I restart the installer (which, thankfully, knows how to deal with the fact that it’s already half installed, but that won’t always be true). The installation finishes this time, and the installer kindly offers to start the program for me. However, after poking around a bit and exiting back to the desktop, I don’t see a menu entry or a desktop icon, so I’m not sure how I’m going to find it again (and I hope I don’t have to explain why cd’ing to ~/sun/Creator2_1/bin is not an answer). Anyone who has ever installed software on Linux is familiar with this song and dance. If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms. (And, no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture.) Oh, well. At least I didn’t have to check for viruses! Fortunately, some of the problems I experienced are bugs. The above was done on a pre-release Debian etch system over the summer, so it’s likely the problems have been fixed. I repeated the experiment on an Ubuntu edgy system, and it didn’t open the text editor, nor did it complain about an incompatible C++ environment. However, there were still no menu entries or desktop icons, and there was an additional problem too in that when I double clicked the file, it opened it in CrossOver Office, which I also have installed. Regardless, even if it works better on some distros than others, there’s still no usable solution until ISVs and end users alike can depend on things consistently working regardless of the distro being used. Again, fortunately, we have solutions to parts of the problem already. The LSB abstracts away the differences between the runtime environments of the various distros, so the Java Studio Creator installer could have simply said “you must install the LSB environment” rather than trying to deal with the hundreds of little variations in both the environments and the package namespaces that provide them (e.g., compat-libstdc++ vs. libstdc++2.10-glibc2.2). Better yet, on distros that provide the LSB environment in their default configuration, the installer doesn’t have to do anything. And Project Portland promises to give us a consistent interface for creating menu entries, desktop icons and such things. However, far too few applications take advantage of the LSB today (though that’s changing), and Project Portland isn’t in any of the distros yet (though we’re looking at bundling its primary deliverable, xdg-utils, with the LSB 3.2 SDK to work around that). Finally, even though the LSB provides ISVs with a consistent way to create an LSB compliant executable, there’s no consistent way to deliver an LSB compliant application that’s easy to install and that integrates well with the distribution’s package system. Yes, the LSB includes RPM today, but for a variety of reasons, ISVs don’t want to use RPM, and as already mentioned, not all distributions support RPM natively. Fortunately, once again, this isn’t just a rant. The LSB tackled these very issues at the LSB face to face and Packaging Summit last week in Berlin, Germany, and we think we have a way forward that’s acceptable to all involved: Linux distribution vendors who already have well established package systems and systems management tools built around them; ISVs who need to support multiple platforms and so don’t want to support the Linux specific RPM format or who otherwise want more control over the installation experience; and end users who want to use the software management facilities their distributions provide, whether that’s RPM or something higher level like APT and yum. More in part 2…

I just lent two 80G IDE drives to a friend, and he re-paid me with 160G drives. Generally I don't mind people repaying hardware loans with better gear (much better than repaying with the same gear after a long delay and depreciation), but this concerns me.

My friend gave me the 160G drives because he can't purchase new 80G drives any more, his supplier has nothing smaller than 160G. I have some very reliable machines that I don't want to discard which won't support 160G drives - I'm not even sure that they would boot with them! Now I'm going to have to stock-pile 40G disks.

The machines I am most concerned about are my Cobalt machines. They are nice little servers that are quiet and use only 20W of electricity!

It's a pity that there aren't any cheap flash storage devices that connect to an IDE bus. If I could get my Cobalt machines running with flash storage they would be even more quiet and energy efficient while not being at risk of mechanical damage, and I doubt that flash storage will exceed 40G of capacity for a while.

Update: I've set a new personal record for rapid comments on a blog entry, all telling me that it is possible to get CF to IDE adapters. Thanks for the information, I appreciate it and will consider it for some machines. The problem however is that the price of a CF to IDE adapter plus the cost of a CF card of suitable size is moderately high (more than the cheaper hard drives), while CF capacity generally is only just usable for a mainstream Linux distribution.

These factors combine to make CF-IDE devices an option for only certain corner cases, not really an option to replace all the hard drives in machines that matter to me. I will probably use it for at least one of my Cobalt machines though.

Update2: Julien just informed me of the new Samsung flash-based laptop drives that will have capacities up to 16G (or 32G according to other web sites). I'm now trying to discover where to buy them.

Elizabeth Montalbano and Andy Updegrove write about IBM’s donation of iAccessible2 to the Free Standards Group, which is being formally announced today (see the IBM and FSG press releases). In addition to IBM, the project is backed by Sun, Oracle, SAP and other major vendors. This is a big deal in and of itself, of course, because it will make applications based on ODF, AJAX, and other emerging open standards more accessible to visually impaired users. But it’s also an important milestone for the FSG, so I thought I should say a few words about that here from my own little pulpit. The first clue is that iAccessible2 is an accessibility API for Windows. Windows? Yes, the FSG is primarily a Linux organization (our main project is, of course, the Linux Standard Base), so why on earth are we now involved in building APIs for Windows? First of all, we’ll be moving this project forward as an extension to our existing accessibility projects—which, given the way the FSG is structured, flow into the LSB as they are adopted by the Linux distributions (who, as I’ve already mentioned here, are active participants in the LSB project, so we’re not just hoping the distros adopt our work, we’re proactively trying to drive consensus on these key issues). So, this definitely impacts our Linux work by bringing accessibility features to Linux that not only equal those of Windows but exceed them (iAccessible2 itself came about because Microsoft Active Accessibility has notable shortcomings). But it’s more than that. Another way to look at this is that the LSB APIs will be taking on a distinctly more cross platform flavor, particularly in the “around the edges” cases such as this. Again, that begs the question: Why is cross platform support important for a Linux organization? That one’s simple. APIs are for application developers. Application developers target multiple platforms. The less Linux specific work an application developer has to do to support Linux, the more cost effective a Linux version will be, the more likely it is to get done. It’s all about more Linux apps. There’s another dimension to it as well. There are a certain class of features that the vast majority of developers don’t think much about because that vast majority doesn’t need them. There’s no itch to scratch, as it were. Accessibility is a great example of such a feature: I have no idea what it’s like to be blind, nor do most people. If we can provide a set of open, cross platform APIs that allow application developers to easily add such features to their products, more standards based products will support them. As Massachusetts and ODF brings into sharp focus, these “around the edges” cases developers don’t think much about can turn out to be very important indeed.

My workmate Javier Uruen has just pointed me to Banned for George Bush T-shirt, a story about a guy that was banned from an airplane because he was wearing a “George W. Bush is world’s #1 terrorist” t-shirt. He argued it was his right to express his opinion, while the airline said the t-shirt was offensive and he wouldn’t be able to flight unless he took it off. I can’t see how that shirt can be offensive for anyone besides George W. Bush and I guess nobody would have prevented a person from flying because of an “I love George W. Bush” t-shirt, and that is offensive. Freedom of speech seems to be in danger. In brighter news, I’ve discovered that UC Berkeley freely offers video and audio for some lectures. I’ve been listening to some lectures from the Undergraduate Colloquium on Political Science and they rock. Allan Ross, the lecturer is awesome, I wish I would have had somebody like him in my university.

In case anyone is in doubt about the degradation of educational standards over time, I present to you the 8th grade "final" exam for Saline County, Kansas, for April 1895.