Life sometimes goes in a funny direction, like a full circle d j vu: 20 years ago, I was studying Technology of Computerized Systems (a combination of electronics and programming). Now, 20 years later, I'm starting a dream job as the Business Development Manager of Artec Group and their core business is you guessed it exactly that. The really cool thing about Artec, from a Free Software advocate's point of view, is that they contribute firmware and drivers for their products to LinuxBIOS and the Linux kernel. At this point, my initial tasks will focus on marketing and selling Artec's flagship OEM product, the ThinCan. What is the ThinCan? Actually, you're already familiar with one iteration of the product: the Linutop is a branded ThinCan, delivered with a custom hardware configuration, plus custom casing artwork designed by Fr d ric Baille of Linutop SARL and loaded with Fred's favorite Xubuntu configuration. In the Linutop's case, their business model is to fill the market niche for a simple Internet surfing platform that fits 80% of average people's daily computing needs, so the hardware configuration they ordered reflects that. Still, as several readers of this blog noticed, the "Linutop" could make a fantastic thin client and, sure enough, that was the main purpose behind the ThinCan's original design; it sells well in the Fortune-500 market as an RDP client running under Windows CE. However, until recently, there simply wasn't much demand for a contemporary X11 terminal solution based on the ThinCan. That is, until LTSP took off, thanks to the contributions of Edubuntu and similar educational Linux distributions. Sure enough, someone spotted the opportunity and contacted Artec to order a branded ThinCan iteration with Etherboot and PXE support, which they call the Linuterm. By the way, for those who need a really cheap OEM thin client, I've got a great spring clearance offer for you:

Artec has about 500 pieces left of their older DBE60 ThinCan model, based on the AMD Geode SC2200, and we're selling them at 100 euro / piece, plus VAT and shipping.

The DBE60 is configured with three USB 1.1 ports, one parallel printer port, one 100baseT Ethernet port, one VGA port (up to 1024x768 @ 16bpp 60-85Hz or 1280x1024 @ 8bpp 60-75Hz) and one 1/8" stereo audio output jack. Its BIOS provides Etherboot support and its motherboard is populated with 64MB of RAM and 32MB of Stratoflash. It comes delivered with a European AC adapter. The Geode SC2200 is fully supported by the Linux kernel with the sole exception of a missing ALSA snd-scx200, but this could easily be ported from AMD's deprecated OSS driver and X.org support is provided by the "nsc" driver.

Minimum order size is 10 pieces. Contact me via my full name (unaccented, with one hyphen and one dot) at artecgroup.com quoting this special offer.

PS: someone was asking if that DBE60 special is also available in the aforementioned Fortune-500 configuration. It indeed is: add 16 euro / piece for the Windows CE 4.1 license with an RDP client.

David, after the demise of the little joystick of my previous phone (Sony Ericsson T610), I opted for the D900 (at CHF 21.-- plus 2 years, quite a good offer IMHO.) The hardware is very slick, though the display is disappointingly dark if you use the phone outside in bright light (Look at Casio's Exilim cameras for a good example of how a display can be readable even in direct sunlight.) Since I'm using the device as a phone only (and write less than 5 messages per month, usually), I still think it's a nice thing, but...

• The camera is not usable because of a huge delay after release, mostly the autofocus, I guess. Quality is good otherwise, you don't want to photograph anything capable of movement.
• Haven't figured out how to import a contact that's sent to me by SMS (MMS?) into the address book.
• The Sony-Ericsson had the option of dialing any number that is contained in a short message, I really miss that.
• Battery lifetime is good as long as you're not using it as an MP3 player. But then the limited memory is a problem anyway. Haven't bought an SD card, so YMMV.
• No infrared. So no pushing contacts from or to my old Palm Vx which is still my primary repository for addresses.
• No timeout on Bluetooth activation. So I need to manually switch it off after use, which takes about 4 clicks. Switching it on and using it is quicker and works just fine.
• No way to sync addresses with my computer that I have figured out. (I guess I don't need to mention that I'm only speaking of Linux here. A Windows software CD is included, naturally.)
• No T9 in the WAP browser (T9 == autocompletion thingy, in case you didn't know that.).
• How do I edit the included dictionary of the T9? This actually made me switch off that thing entirely, while on the old phone I was quite good with that, most of my relatives names etc. being in the dictionary.
• Samsung to 3.5mm adaptors (for headphones) are hard to come by. If you know somebody who sells them in Switzerland, please tell me.

Would I buy that phone again? I don't know. The price was good, and, again, it's still a very slick looking phone. But the firmware designers should be locked up for a few years and forced to write their code with the built in editor or someting like that. But if you expect anything other than to be able to call people over this device: don't go near it. I haven't relly looked at any other phones when I bought it, so I can't compare.

The Children’s Online Protection Act, or COPA, requires website operators who provide commercial material that could be “harmful to minors” to verify their users’ age, for example, with a credit card. The statute was immediately challenged as unconstitutional under the First Amendment. A preliminary injunction against enforcement of the law was upheld by the Supreme Court, which remanded the matter for factual development as to whether filters could accomplish the same purpose while interfering less with free speech. (Ironically, the ACLU found itself in the unusual position of arguing for Internet filters in this case.) It was just about one year ago that the Government sought to enforce a subpoena against Google for records of user queries and URLs stored in Google’s database. The court granted the motion with respect to stored URLs but not queries in Gonzales v. Google. It was never quite clear what the Government would really do with the data or why they pushed so hard to get it after receiving what they needed from other search providers. (The U.S. apparently argued Google’s search results would “add luster” to its analysis). In any case, the statute has now finally been held unconstitutional. As Ed Felten insightfully points out, unlike in previous instances where courts have struck down Internet speech regulation, in his opinion, Judge Reed did not provide a roadmap for Congress to try yet again to enact a law that would pass First Amendmend muster. Maybe Congress will leave the issue alone for a while:

Two things make the judge s ruling relatively roadmap-free. First, it is based heavily on factual findings that Congress cannot change things like the relative effectiveness of filtering and the amount of HTM material that originates overseas beyond the effective reach of U.S. law. (Filtering operates on all material, while COPA s requirements could have been ignored by many overseas sites.) Second, the alternative it offers requires only voluntary private action, not legislation. Congress has already passed laws requiring schools and libraries to use content filters, as a condition of getting Federal funding and with certain safeguards that are supposed to protect adult access. The courts have upheld such laws. It s not clear what more Congress can do. Judge Reed s filtering alternative is less restrictive because it is voluntary, so that computers that aren t used by kids, or on which parents have other ways of protecting kids against HTM material, can get unfiltered access. An adult who wants to get HTM material will be able to get it. Doubtless Congress will make noise about this issue in the upcoming election year. Protecting kids from the nasty Internet is too attractive politically to pass up. Expect hearings to be held and bills to be introduced; but the odds that we ll get a new law that makes much difference seem pretty low.

In June I plan to attend the DebConf 7 in Edinburgh. I like train riding and after all it s good for the climat, so I ruled out flying.If you want to go to UK by train, you have to take the EuroStar through the tunnel. The Deutsche Bahn offers a nice package including a sleeper train for 86, so I got that part covered. But that only gets me to London, and I need to go to Edinburgh.So today, I orderd a one way ticket from London to Edinburgh for 28.50 from GNER, one of the private british rail companies, and payed by credit card. Right after I sucessfully booked the ticket, I noticed some problems with the shipping address: An Umlaut in the street name has turned into weird characters and it did not display the counry (Germany) that I m sure I selected. So I immediatelly sent this mail to GNER:

Hello, I just booked this ticket online. It seems there are problems with the German address, though. The correct address is: Joachim Breitner
Ehb hl 33
71083 Herrenberg
Germany (you can replace by ue if necessary) My Booking Reference: xxxxxxxx Thank you,
Joachim Breitner

And got this response:

Dear Joachim

Thank you for your recent e-mail regarding delivery address of tickets.

I can confirm that we do not deliver tickets overseas. However, since our system is automatic, as soon as you click on the 'Buy tickets' button, the tickets are printed and sent in post.

Please remember that once the booking is confirmed, the delivery address/method cannot be changed.

In this case, if we receive the tickets back from the General Post Office, they can be reissued to a UK address and if we do not receive the tickets back, you will have to buy new tickets as your tickets are non refundable.

Please reply to this e-mail with a UK address, where you would like the tickets to be delivered so that I can update it on the notes, and the tickets will be posted, once received back. If we do not receive the tickets back, you will have to buy new tickets.

If you have any further queries, please do not hesitate in contacting us.

Kind regards

Saurabh

Now I really wonder:

• If they don t send tickets abroad, why do they allow me to enter a German address?
• Should I ask my credit card company to deny the payment (if that is possible)?
• How do I get my ticket now?
• And do we really want to privatize the Deutsche Bahn?

Update: I gave them an address in the UK now, I hope it works out (thanks Ben). And the Deutsche Bahn is already privatized, just not publicy traded yet and is 50% owned by the state, I was confusing that.

Well, obviously this one needs a shorter name. The problem I'm trying to solve here is that SONAMEs, or rather the way they are used today, only handle the issue of a single, fully contained library changing ABI as one of its header files changes. However, libraries do not exist in a vacuum; as a bare minimum, they use definitions for types and alignment requirements built into the compiler, and if any of these changes, so does the library ABI. Hence, the idea of using a single number to denote the ABI is not really sufficient. The correct solution would be to embed all ABI information into the soname (libapt-pkg, for example, uses "libapt-pkg-libc6.3-6.so.3.11" on amd64, which is better but still not perfect). Obviously, this would require massive changes to the build scripts in all libraries and educating all library authors, so it is not going to happen (soon). So, what other options are there? As the kernel ABI (the syscall interface) is supposed to be really stable, we probably do not have to worry about that. So, we only have a problem if there are libraries with different assumptions about each others' ABI in the same userspace program. This can happen in two ways: The compiler changed (as in the case with the recent C++ transitions), or a library that is an indirect dependency of something that also has another dependency (direct or indirect) changes ABI. I've talked (briefly) about the former in an earlier post already. To illustrate the latter, a small example: There is a library, libuseful.so.0 that provides a number of functions, among these: struct complex_number

  float real;
  float imaginary;

 
void complex_multiply(
  struct complex_number *result,
  struct complex_number const *lhs,
  struct complex_number const *rhs); Now another library, libresourceful.so.0, comes along and implements complex_divide on top of complex_multiply. Since the definition for complex numbers from libuseful makes a lot of sense, the include file for libresourceful reads #include "libuseful.h"
 
void complex_divide(
  struct complex_number *result,
  struct complex_number const *lhs,
  struct complex_number const *rhs); Now one of the more serious people in Debian decides to write pointless 1.0, which takes two complex numbers and calculates (a*b)/a, using both complex_multiply and complex_divide, and links against libresourceful.so.0 and libuseful.so.0. Some time passes, and shortly before Debian freezes, libuseful's author decides that she needs more precision, so she changes the floats to doubles, bumps the SONAME and releases the new version. Shortly thereafter, someone notices that libresourceful is now using an outdated version of libuseful, and recompiles libresourceful. Since the header of libresourceful did not change, noone thinks of changing the SONAME, after all, changing it would render us incompatible with other distributions. Now, pointless 1.0 depends on libuseful.so.0 and libresourceful.so.0, which in turn uses libuseful.so.1. It still believes complex numbers are made from floats, however libresourceful now disagrees. The (a*b) expression is calculated correctly, using floats, however the result is then passed to the complex_divide function which expects a pair of doubles. Not good. Obviously, there is a number of things people have done wrong in this example. First of all, if you inherit type definitions or anything else from another library, your ABI becomes bound to theirs. As you cannot know statically what version your library will be linked against, you need a script that computes your ABI version at build time. If you do not want that, you need to repeat the type definitions in your header and (deep-)copy the data from one of your structures into one provided by the library you are using (I can already hear the screams of the performance fetishists). The assumption that, just because a dependency changed, there is not necessarily a need to bump the soname is not fundamentally incorrect; if no interfaces are being propagated, it is certainly correct, and most libraries do not really do this (for example, a HTTP library uses the resolver, but never passes the hostent structures upwards). Detecting this is difficult to do, although Sun has a few tools to help here. So where does that leave us? In my opinion, the most sensible thing a distribution can do is to make sure such a constellation never gets installed to an user's system. If there is any doubt, we need to err on the side of caution (aka use a bigger hammer). This is a "wacky ideas" post, so I also need to propose a totally untested thing that might work (or not), but at least has passed the stage of me sleeping a night over it. Ideally, dpkg would enforce that. In order to do that, it needs appropriate metadata that tells it that a certain constellation is probably wrong. The thing we want to avoid is an application using multiple versions of the same library at the same time, where "use" is denoted by a dependency relationship. So what we need is a way for a library package to declare that it is wrong to (indirectly) depend on this package and a package out of a certain group at the same time. I can see two ways of doing that, each with its own advantages and disadvantages: The "explicit" way is to add a new dependency relationship (that is where the subject "Conflicts-If-in-Same-Dependency-Tree" comes from), where you would conflict in this way with a virtual package that is named after your library without the SONAME version, and at the same time provide that virtual package (which is a technique that should not be unfamiliar to Debian people). The hypothetical libuseful above would then state Package: libuseful0
Provides: libuseful
Conflicts-If-in-Same-Dependency-Tree: libuseful So installing pointless_1.0 would pull in libuseful0 and libuseful1, dpkg would see the conflict and refuse. For upgrades, it would refuse the libresourceful0 upgrade, as that would create an inconsistent situation. The only way out of there is to recompile pointless. The advantage is that the modifications to dpkg would be manageable (at least compared with the other option, which I will introduce shortly), the obvious disadvantage is the massive number of virtual packages introduced. The "implicit" way of doing that is moving the SONAME into its own field in the control file, and teaching dpkg that two packages with the same name and different SONAME fields can be installed at the same time, although not depended on by the same package. This is a really nasty change to dpkg and also requires a syntax for dependencies that includes the desired SONAME version, but it gives us a lot of other advantages. The one immediately visible is that it does not bloat the Packages file too much, and does not introduce lots of virtual packages, although the net effect inside apt and dpkg is probably going to be the same. A really cool side effect though would be that the soname is no longer part of the Package: field, and thus it becomes possible to insert it using substvars. This, of course, is a cool thing when library authors come to their senses and include ABI information for dependent libraries into their SONAMEs. Since this has gotten lengthy, thanks for reading this far. Of course, questions and comments are requested, and if you are interested in pursuing this, please get in touch, either via email or if you can wait that long, at the "Wacky Ideas" BoF at DebConf. The last thing for me to do here is to welcome Joachim to the "post your ideas" "meme".

Tomorrow at 9 in the morning some officers from the Valencian regional Government will drive up to the mountains of the Bartolo, Serra Perentxissa, Montd ver and Carrasqueta to power off the set of antennas which have broadcasted the signal of TV3, the Catalan public television, during the last 20 years for the entire Valencian territory. These news have been responded with protests from most of the Valencian cultural collectives. You can sign a petition, or send an e-mail, which will be swiftly ignored by the people in charge. Behind the official reasoning for this attack to our freedom of choice -the broadcast is illegal- there is a set of good reasons for the usual suspects, the Valencian Partido Popular to do this. The biggest one is that two months before the local and regional elections, the right-wing are doing their math and it may not be working out too well for them. They need to scrape as many votes as they can, and an easy granary is attracting the extreme right-wing, which is a bit active but fragmented in the region, and mostly in the city of Val ncia. This social group is greatly virulent against anything which sounds like Catalan , especially the people known as blaveros , who claim our culture and language has no common root and has nothing to do with the culture and language from the North. Fortunately, the ISO 639 standard and the entire scientific community agree that they are nuts. But back to my rant. So, how can the PP try to get a handful of votes from the right-wing? Easy, start an anti-TV3 show on the media and start scalating it until the final act -tomorrow-, where milions of citizens are deprived of one of the best channels available in our TV sets. This will surely be sold as a major victory against the Catalan invasion or as the end of an "alegal situation", although there are like 30 other channels in the same situation in the city of Val ncia, and the PP-controlled Canal 9 channel is broadcasted in the Balear Islands (also controled by PP) in the same legal situation. In a time when watching Middle-East or American channels is trivial using a satellite set, some people think the best thing they can do is to end a service paid and provided for free by Acci Cultural del Pa s Valenci , an important cultural entity, during the last 20 years, ending the right to choose one of the only channels with all the programs in our language for milions of Valencians. Their right to do it is also challenged in court, but there is no doubt that tomorrow they'll go ahead and shut it off. We could have a reasonable government who would maybe want to accept the Catalan TV and radio channels in our territory, if the Catalan government would also accept our (crappy) channels in theirs, but they refuse this as well, because they now feel insulted . All in all, I had enough of PP long ago, and am hoping I am not the only one. In less than a month, Valencians will celebrate the 300^th anniversary of the Batalla d'Almansa on the 25th of April of 1707, although we seem to be fighting a new battle now in 2007. The Batalla d'Almansa meant the end of the War of the Spanish Succession in Spain, but also the start of tough times for our culture, language, and people, when Felipe V abolished the Valencian furs. But this story can make a blog post of its own next month. Quan el mal ve d'Almansa, a tots alcan a...

I just uploaded newsbeuter 0.3 to unstable (get it from incoming until it hits the archive).

The release is mainly a bugfix release but there are also some cool new features and improvements.
- The html rendering especially encoding issues are fixed now.
- Everything is stored as UTF-8 internally and gets converted on-the-fly.
- libidn is not needed anymore
- gettext support (at the moment just german translation, translators wanted)

And last but not least podcast support.
For this there is a new tool included in newsbeuter named podbeuter. When updating feeds newsbeuter searches for podcast files and
adds them to a download queue. podbeuter then is the download manager to do automatic or manual downloads of the podcasts.



Have fun and test it.
Oh and YVFI we hang around in #newsbeuter on freenode now

Debian as a Linux distrubtion is all about integration and ease of management, which includes init-scripts. I d like to propose a feature that might be helpful to quite a few system administrators while being non-disruptive to all others.For a lot of daemons there are use-cases that require more than one instance of the daemon to be running. With instance I mean a separate process with it s own configuration files, but on the same system, which rules out virtualisation or changeroots. Examples are copies of the main server running on a different port, to test new settings, different servers on different IPs, a HTTP-Server-Split into a slick static-and-proxying server and a heavy backend server, a mail server split with a virus scanner in between etc.So as an administrator I currently not only have to write the configuration for the additional instances, but also write my own init scripts and modify them, never being sure if I did it good or whether it will cause problems on package upgrade or similar things. I d rather see the functionality built-in to the package s init script directly.There is a package in Debian that already provides this: The OpenVPN package maintained by Alberto Gonzalez Iniesta allows the user to define new instances of OpenVPN simply by adding a new file to /etc/openvpn/. The file /etc/default/openvpn defines which of these instances are to be started when I or the system start runs /etc/init.d/openvpn start. /etc/init.d/openvpn stop stops all running instances and /etc/init.d/openvpn restart also restarts just the currently running servers. I can easily control a specific instance by adding it s name (which is the configuration file s basename) after the command to the init script.I think these semantics are clear, sensible and non-disruptive and should be available with every Debian package where the administrator might want to run several instances at once: web server, mail server, ftp servers, name servers etc.In those cases where the daemon is not configured by a single file alone, one directory with the configuration for one instance is needed. Otherwise, I don t see why this should be a problem. For backwards compatibility, the normal configuration file locaction could be an implicit instance called default and all additional instances go to their own directory (e.g /etc/ntpd.conf is instance default , and /etc/ntpd/public.conf is instance public ).Comments welcome.

Ted Ts'o had an interesting post about git recently. He has a lot of good thoughts on the subject. He comments that he wound up using git because it's so Unixy (with its small commands to do things), that he sees the git community developing innovations faster than Mercurial, and that they are working to improve the documentation and user interface problems.

The being so Unixy is a double-edged sword. On the one hand, it can make it easy to write shell scripts to extend Git. That itself can be a double-edged sword (think filename quoting and the like). But one doesn't have to use the shell. The other downside is that being Unixy makes it hard to run on platforms that aren't, such as Windows. So if one is working on Unix-only software (X, the kernel, e2fsprogs, etc.), there's no need to care about it. But if you're a person like me, who has Windows users using my software, or a large organization like Mozilla, it's maybe a showstopper. Of course, workarounds exist (cygwin, git-cvsserver), but none of them are particularly nice.

I think that both Git and Mercurial are working to address their shortcomings. I've chosen hg for now because it does what I need now. And because there are very nice tools to convert hg to git, and vice-versa. So if Ted's right, and a year from now git is easier to use, better documented, more featureful, and runs well on Windows, it won't be that hard to switch over and preserve history. Ted's the sort of person that usually is right, so maybe I should starting looking at hg2git right now

So following up on my bzr post, here are the things that Mercurial is great at right now:

1. Performance. Approximately even with git, occasionally faster. Nobody else can compete with these two right now.
2. Simplicity. It's almost as easy to get started as with darcs, and with recent patches, will be even closer in the future.
3. Lots of ways to interact. You can send hg bundles, which preserve all metadata (parents, hash, authors, etc), or you can send git-format email patches, or you can push and pull between repos. The email tools will shortly be able to automatically detect what patches to send. Your choice. git doesn't seem to support lossless emailing of bundles like this, and bzr doesn't make emailing of anything easy by default.
4. Merging. hg seems to be able to automatically resolve more merge conflicts than anything else, and when it can't automatically resolve them, has a nicely configurable system to let you use your choice of tool to manually resolve them.
5. Community. The Mercurial community is open and inviting, and open to new/different ideas. It seems similar to Darcs in that respect, and somewhat dissimilar to git.
6. Rebase does not trash history like it does (barring undocumented manual intervention) in git.

I've written before about Darcs, so I won't duplicate that here.

In response to Joey’s IPv6 autoconfiguration troubles: Over the years I’ve gotten IPv6 autoconfiguration working just as you described: load the module and bring the interface down and back up. Though, I suspect you may have been running Debian’s linux-image-2.6.18-3- arch kernel which seemed to drop/neglect/whatever (I haven’t checked the specifics) IPv6 multicast (link-local) traffic over which the autoconfiguration is done. When 2.6.18-4 arrived in Sid, all worked fine for me after a reboot too.

Yesterday I went to bed too late because I was captivated by the last episode of The Trap: What Happened to Our Dream of Freedom, a series by Adam Curtis. Even since I saw Pandora's Box I've been an avid viewer of his work. The Trap talks about what freedom is, and this morning I realised that many things he talked about can be seen in the OSS world, and more specifically in Debian. I'm certain Biella can write something much better (and shorter) and I'm still thinking about it, but I wanted to write some stuff down.
One of the main ideas is the modern western culture has been formed to appeal for people thinking like a model in the 'prisoners dilemma': they only case to further themselves. This lead to the idea that life (not only the economy) should be like a free market, and that people should be 'free' to choose what they liked. Of course in practice the rich are 'free' to send their kids to better schools then the poor who are 'free' but constrained to send their kids to worse schools. The program called this negative freedom: there is constrained freedom. Think of it as Microsoft's vision of freedom, their 'freedom to innovate' (which they don't), your freedom to select which of the N licences of vista is good enough for you. This limited freedom is more stable then the positive freedom that is actual seeking true freedom, without constraints. This positive freedom was then developed by Satre, Fanon and Shariati into the idea that true freedom could only be gained by armed struggle, to gain freedom but also an identity that transcends the simple individual.
The whole idea of the two freedoms was described by Isaiah Berlin and he also had the idea that freedom can only be gained by limiting the power of the state over the individual, otherwise both concepts of freedom would become tyrannical because the powers that be would decide what freedom is, and then suppress anybody that does not agree with that idea. Examples are the communists in the USSR, but also how the Americans turned to torture, imprisonment without tribunal to 'liberate the Iraqi people'. Or older still the Reign of Terror during the French revolution.
All of this has some relevance to OSS and Debian in particular. Don't we search freedom from constraints (licences, absence of source)? Don't we want a revolution in the use of computers? Are we not using disruptive means to get it? The introduction of a samba file-server in a pure MS environment by a disgruntled admin who just wants stuff to work could be seen as being almost a terrorist method of working. Not that we want to terrorise the population, but make them aware that an alternative exists. And this to chance the system. Sometimes the whole mindset does seem to be a little too much confrontational, almost towards having a real conflict. Just think about the many references that some disaster should wipe out the Seattle area. Are we not at risk of becoming tyrannical in many ways? Ignoring any Debian discussions, there is the whole FreeBSD/OpenBSD split, people complaining that wikipedia is removing contents the consider valuable, projects refusing to create howto's and introductions to keep the newbies away etc. OOS does seem to have a tendency to become tyrannical in some aspects. Not that this is always bad, see the benevolent dictators handling the Linux kernel or python.
If I understand the idea's correctly it means that even if we want freedom, from the moment we start using the powers of the project to limit somebody we start the slide towards being oppressive and tyrannical. Somehow I fear that all this will lead to a lot of reading and thinking...

For the first time, I have working ipv6 to both my main servers as well as my home network using 6to4. That's nice, what's driving me insane is that while I seem to have radvd set up properly on my OpenWRT system here at home, none of the boxes on the network are autoconfiguring their ipv6 addresses. And linux doesn't offer any way to debug this that I know of, besides logging the rather useless "wlan0: no IPv6 routers present". radvdump shows the clients can see the advertisements, which look ok. All the kernel parameters look ok. If I manually set up an address on the clients it works. So why is linux ignoring radvd? No idea, no way to tell.. Update: Getting ipv6 client autoconfiguration to work on linux seems like a bit of a black art. You're think you could just load ipv6, take an interface down and back up (or even just wait for radvd to broadcast) and have autoconfiguration just work. This does not seem to be the case, after beating my head against this for several hours with no success I finally rebooted my laptop and it's now doing autoconfiguration. No such luck with my desktop and nslu2, despite reboots and poking. And something strange is going on, since twice I've seen dhclient clear autoconfigured ipv6 settings from an interface.

I just upgraded samba.grep.be, my web/mail/subversion/whatever server, from sarge to etch. No, etch isn't released yet, but it's almost there, anyway, and I had some time off. That is, some time off—I got distracted halfway through, and then obviously dpkg asked me about conffile changes. As far as I can see, it's all up and running again, now, though I might have missed some stuff in between. Occasionally, that might mean that Planet Grep had some issues for you today; but those (should) have been dealt with by now. And I didn't even have any issues with packaged software. Isn't that great?

John Goerzen recently posted about Git, Mercurial and Bzr that I found interesting, especially since I used to be in the hg camp, but have been gradually using git more and more, even to the point making minor improvements to the git documentation and writing the git mergetool, since being able to automatically fire up a graphical merge tool was one of the features which I missed from hg. So while I haven't yet converted the primary SCM repository for e2fsprogs to use git (yet), I've reached an opposite concolusion from John, and yet, I can't really argue with his observations.

The main reason why I've come out in favor of git is that I see its potential as being greater than hg, and so while it definitely has some ease-of-use and documentation shortcomings, in the long run I think it has "more legs" than hg, and with the release of git 1.5.0, it became clear that the git community was willing to work on these particular shortcomings, which is why I started working on it and making plans to migrate e2fsprogs to use git. The main reasons why I think git is more powerful is that not just that it supports lightweight branches inside a single repository (although I really do like that a lot since it makes it a lot easier to run multiple experiments in parallel and switch back and forth between them), but also because git is much more Unix-like; there are lots of tools that enable scripting for either new git extensions or for ad-hoc shell pipelines that you can't really easily do in hg without breaking into Python.

But git definitely does have shortcomings, and John is on the mark with most of them. Git's documentation is very poor. Part of the problem stems for tutorials that were written to work with older versions of git (don't try using anything older than git 1.5 if you are a git newbie; git 1.4.x is far more user-hostile) or were written for use with systems built on top of git 1.4.x, such as Cogito. (I don't recommend Cogito, since git 1.5 is significantly more usable, and I've always found Cogito to be more confusing that just using stack git.) The tutorials that are distributed with git 1.5 are much better, but they clear do need more work.

It is true that the many of the man pages in git are lacking, and John's criticism of the fact that many man pages do not list all of the options that they take, but rather refer to other man pages is on point and accurate. It has gotten better (take a look at the git-diff man page from the git 1.4.x days, and laugh or cry, depending on your point of view) but there is still much work to be done. In practice, the better way to use the git man pages is to skip past the options section, and take a look at the Examples section. This shows a number of ways that a particular command might be used, just as a Unix master might say, "Grasshoper, see how you can use awk to do all of these amazing things."

I do take issue with John's assertion that git's philosophy has been to make life easy for the central maintainer, and not to pay much attention to the needs of individual contributors. That may have been Linus's development priorities but with Junio having taking over maintenance, there have been a lot of improvements in git 1.5.0 to make life easier for people who are tracking remote repositories and making changes, in particular the git remote command.

The most interesting observation which John made was the non-intuitive semantics of git-format-patches, and I did find it interesting that one commenter posted a solution which made perfect sense given other git commands, and yet didn't work. Obviously the person who posted the comment didn't bother to try it first, probably because in most other places git is actually pretty consistent; but git-format-patch is one of the places where most painfully is not. I view this as a bug that should be fixed, and fortunately I think it can be fixed without breaking the git-format-patches is currently being used. (The problem is that it doesn't use the standard notation so it is more convenient in the common case of how it is normally used, where the end point is not specified and is always the the tip of the current branch. I believe we can avoid the UI surprise by making git-format-patch use the standard revision range parsing if parameter contains the ".." or "..." operators. I'll have to try to prepare a patch which does this and see whether it gets accepted.)

So basically git does have short-comings, yes, but people will come out in different places about which tools is best for them, and that's OK. Actually, I think the ultimate solution for this problem is to build a bidrectoinal hg/git gateway. There are tools that will export from hg to git, and vice versa, and they are actually pretty sophisticated. I don't think it should be that painful to create a tool that does incremental exports in both directions, maintaining state so that the right thing happens when a commit gets made on the git side, and gets exported into hg, or vice versa. Ultimately I think that's the best solution, since that way people can use whatever tool they want, and still contribute and development as first class citizens. This is the main reason why I've held off on converting e2fsprogs to git (although I have made some private test repositories which I'll use to take advantage of git's superior annotation and query/log utilities); I don't want to make a git repository of e2fsprogs public until I'm sure that a bidrectional gateway tool won't require me to make any changes that affect the commit-id's, since that would invalidate any work that people have done that was based on a clone of the coverted git repository.

I have a rough design for how to do the bidirectional gateway, but the issue is finding time to implement it. Anyone with free time looking for a project? If so, contact me. I probably should have written this up as a potential Google Summer of Code project, but it's too late for this year. Oh, well.

The search functionality of YouTube always sucked. Ever since Google acquired them, I was looking forward for them to add a better search. Well, this apparently has happened now; searching at youtube now allows queries like "paris -hilton". At the same time, searching at Google Video now returns results at YouTube. In this particular case however, I'd prefer it to not return YouTube results, because videos at Google are usually of a better quality...

While computers mostly handle the Daylight Savings Time changeover automatically, sometimes work is required. In our case at ICHEC, arranging for some jobs to run at set times, means changing the scheduler at the changeover. We use PBS and Maui to schedule what jobs run when on our cluster. Mostly jobs get run according to priorities: the scheduler (software) decides which what the priority jobs are and when; it collects free nodes until it has sufficient free CPUs to run the jobs at hand. It can do backfilling: when it's e.g. trying to run a large 128 node job but has only 10 nodes free, it will reserve nodes as they become free until it has all the resources needed to run the job. If by looking at the remaining time left on running jobs it realises that it won't get nodes free for the large job for say 2 hours, it can run small jobs with runtimes of less than two hours on the nodes it had reserved. Clever. The fun issue comes when you need to set reservations: say you need to run a job at 2am every day on 32 nodes, as we do: the scheduler needs to plan accordingly. The scheduler needs to really have 32 nodes free at that time. Thats 2am local time, of course: but next Sunday, at 2am, the clock changes... So, working out the consequences, and preparing for the change, I sympathise with our American friends who've moved three weeks early to save energy. Thus causing lots of midnight oil to be burned around the world by sysadmins and programmers updating software. Hmmm. Note to Self: When Posting a blog entry asking for help on getting blog comments to work with openid, try leaving the comments setup on the blog working, so people can leave replies. Fixed now.

Thomas mentions that Etch will release with glibc 2.3 rather than glibc 2.4, and wonders why that is. There are two simple reasons for this:

1. AIUI, glibc 2.4 drops support for non-NPTL kernels (i.e., 2.4 and earlier Linux kernels). Since sarge's default kernel was still a 2.4-based kernel, upgrading to a glibc 2.4 will immediately break everything on your system, since at that point your libc suddenly refuses to cooperate with your kernel. Not providing an upgrade path for users who run a supported kernel of our previous release is not an option.
2. Etch will have official support for 11 architectures: i486 and later intel-compatibles, SPARC, Alpha, PowerPC, ARM, big- and little-endian MIPS, PARISC, ia64, S/390 and AMD64. If we want to migrate to glibc 2.4 or later and still release, then it has to work on all those architectures. Since NPTL requires some architecture-specific support and since that architecture-specific support is not available for some of our current architectures, this is not the case (also see the above). It may be possible that Debian "lenny" will drop some architectures because the most recent version of glibc still does not support them, but ultimately that decision will be up to the release managers.

So, while I'll agree that it kindof sucks that Debian will release with a somewhat outdated version of glibc, it's not as if there isn't a valid reason.

I've talked a lot lately about different VCSs.

I got some interesting comments in reply to my most recent post. One person took issue with my complaint that nobody really understood how to specify a revision to git format-patch, and proceeded to issue an incorrect suggestion. And a couple of people complained about my comments about bzr, which generally came down to the released version of bzr didn't have anything compelling and also didn't support tags.

So I went into #bzr, asked them what bzr has that git, Mercurial, and darcs don't. And gave bzr the benefit of the doubt that 0.15 will be out soon and will be stable. What I got back were these general items:

1. Renaming of directories (not in hg, git)
2. 2-way sync with Subversion (not in hg, darcs)
3. Checkouts (not in any others by default)
4. No server-side push requirement

Let's look at these in more detail.

1. Renaming of directories

All of them can rename files and (excepting git) completely accurately track back the file's history. But consider this: if person A commits a change to branch A that adds a file, and person B then renames the directory that the file is in on his branch, will a merge cause person A's file to appear in the new directory name? In darcs and bzr, yes. In Mercurial and git, no.

So yes, this is a nice thing. But I have never actually had this situation crop up in practice, and even if it did, could be trivially remedied. I would say that for me, I don't really care.

[Update: Current stable releases of Mercurial can do this too. I'm not quite sure how, but it does work. So git is the only one that can't do that.]

2. 2-way sync with Subversion

This is a really nice feature and is present in both git and bzr. I haven't tested it either place, but if it works as advertised -- and properly supports tracking multiple related svn branches and merges -- would be slick. That was enough to make me consider using git, but in retrospect, I so rarely interact with people using svn that it is not that big a deal to me.

Still, for those that have to work with svn users, this feature in bzr and git could be a big one.

Better yet would be to get all those svn holdouts over to DVCS.

3. Checkouts

A bzr checkout is basically a way to make local commits be pushed to the remote repo immediately, as with svn. This is of no utility to me, though I can see some may have a use for it. But it can be done with hg hooks and probably approximated with scripting in others.

4. No server-side process necessary for pushing repos

bzr has built-in support to push to a server that has sftp only, and doesn't require a copy of itself on the server. While I believe that none of the other three have that, it is possible to rsync (and probably ftp) darcs and Mercurial repos to a server in a safe fashion by moving repo files in a defined order. Probably also possible with git. All four can pull repos using nothing but regular HTTP.

What bzr still doesn't have

Integrated patch emailing. The big thing is that it has no built-in emailing of patches support. darcs is extremely strong in this area, followed by hg, and git is probably third. "darcs send" is all it takes to have darcs look at the remote repo, figure out what you have that they don't, and e-mail a bundle of changesets to them. I posted an extension and later a patchset that does all this for Mercurial except for automatically figuring out what default email address to do (that'll come in a few days, I think). One feature Mercurial has had for awhile that Darcs hasn't is sending multiple textual diffs as a thread, with one message per changeset. bzr doesn't have any support for emailing patches yet, which is disappointing. Because of the strong support for this in darcs and Mercurial, people running those systems feel less of a need to publish their repos.

[Update: There is a plugin for bzr that seems to address some of this. I haven't tested it, and it's not in bzr core (so doesn't quite meet my very friendly for a newbie requirement), but this does exist, though apparently not as advanced as Mercurial]

Performance. Supposedly 0.15 is supposed to be better on this, but even if bzr achieves the claimed doubling of performance, most benchmarks I have seen would rate it as still being significantly behind git and Mercurial, though it may overtake darcs in some tests.

Extensive documentation. I would say that bzr's docs are better in some ways than git's (its tutorials especially), but lack depth. If you want to know some detail about how the repository works on-disk, it's not really documented. Darcs still has David's excellent manual, and Mercurial has the hg book which is still great as well.

Merging not as advanced. darcs is pretty obviously way on top here, but of the others, Mercurial does a pretty good job with its automatic handling of renames and automatic resolving of different branches that commit the same change (even if that same change is a rename, or an add of the same content). bzr can't resolve as much automatically.

Summary

Well, I'll say that bzr still doesn't look compelling enough for my use cases to use, and the lack of an easy-for-a-newbie-to-use automated email submission feature is a pretty big disappointment. Though I did appreciate the time those on #bzr spent with me, and if I needed to sync with svn users frequently, I'd probably choose bzr over git.

For now, I'm happy with sticking with darcs for my code and hg for my Debian work.

But all four communities are aggressively working on their weaknesses, and this landscape may look very different in a year.

I figured this new shiny OpenID thing was cool enough to start using it. There's just this one problem: I didn't want to have to go through the "register on a website and remember yet another password" dance once more; and since I have this marvellous Kerberos realm set up which works for authenticating against my webserver, too, why not use that? So I downloaded the JanRain PHP OpenID library, and went hacking. It's not all that hard, really:

diff -ruN ./lib/actions.php /svr/www/openid.grep.be/data/lib/actions.php
--- ./lib/actions.php	2006-12-08 23:56:22.000000000 +0100
+++ /svr/www/openid.grep.be/data/lib/actions.php	2007-03-08 14:18:32.000000000 +0100
@@ -88,17 +88,24 @@
     if (!isset($input['openid_url']))  
         $errors[] = 'Enter an OpenID URL to continue';
      
-    if (!isset($input['password']))  
-        $errors[] = 'Enter a password to continue';
+    if (!isset($input['password']) && !isset($_SERVER["REMOTE_USER"]))  
+        $errors[] = 'Enter a password to continue, or log in using an ' .
+			'apache logon method';
      
     if (count($errors) == 0)  
         $openid_url = $input['openid_url'];
         $openid_url = Auth_OpenID::normalizeUrl($openid_url);
-        $password = $input['password'];
-        if (!checkLogin($openid_url, $password))  
-            $errors[] = 'The entered password does not match the ' .
-                'entered identity URL.';
-         
+	if(isset($_SERVER["REMOTE_USER"]))  
+	    if(!checkUser($openid_url, $_SERVER["REMOTE_USER"]))  
+	       $errors[] = 'The apache user does not match the openid URL';
+	     
+	  else  
+           $password = $input['password'];
+           if (!checkLogin($openid_url, $password))  
+               $errors[] = 'The entered password does not match the ' .
+                   'entered identity URL.';
+            
+	 
      
     return array($errors, $openid_url);
  
@@ -166,4 +173,4 @@
     return sites_render($sites);
  
 
-?>
\ No newline at end of file
+?>
diff -ruN ./lib/render/login.php /svr/www/openid.grep.be/data/lib/render/login.php
--- ./lib/render/login.php	2006-12-08 23:56:22.000000000 +0100
+++ /svr/www/openid.grep.be/data/lib/render/login.php	2007-03-08 14:53:56.000000000 +0100
@@ -3,6 +3,7 @@
 require_once "lib/session.php";
 require_once "lib/render.php";
 
+if(!isset($_SERVER["REMOTE_USER"]))  
 define('login_form_pat',
        '<div class="form">
   <p>
@@ -31,6 +32,33 @@
   </form>
 </div>
 ');
+  else  
+define('login_form_pat',
+       '<div class="form">
+  <p>
+    Enter your identity URL into this form to log in to this server. This
+    server must be configured to accept your identity URL. Since you already
+    logged on through an Apache method, entering a password is not required
+  </p>
+
+  <form method="post" action="%s">
+    <table>
+      <tr>
+        <th><label for="openid_url">OpenID URL:</label></th>
+        <td><input type="text" name="openid_url"
+                   value="%s" id="openid_url" /></td>
+      </tr>
+      <tr>
+        <td colspan="2">
+          <input type="submit" value="Log in" />
+          <input type="submit" name="cancel" value="Cancel" />
+        </td>
+      </tr>
+    </table>
+  </form>
+</div>
+');
+ 
 
 define('login_needed_pat',
        'You must be logged in as %s to approve this request.');
@@ -62,4 +90,4 @@
      
     return sprintf("<ul class=\"error\">\n%s</ul>\n", $text);
  
-?>
\ No newline at end of file
+?>
diff -ruN ./lib/session.php /svr/www/openid.grep.be/data/lib/session.php
--- ./lib/session.php	2006-12-08 23:56:22.000000000 +0100
+++ /svr/www/openid.grep.be/data/lib/session.php	2007-03-08 14:34:49.000000000 +0100
@@ -129,6 +129,16 @@
  
 
 /**
+ * Check whether the logged-on user matches the specified OpenID URL
+ */ 
+function checkUser($openid_url, $user)
+ 
+    global $openid_user_urls;
+    return isset($openid_user_urls[$openid_url])
+        && $user = $openid_user_urls[$openid_url];
+ 
+
+/**
  * Get the openid_url out of the cookie
  *
  * @return mixed $openid_url The URL that was stored in the cookie or
@@ -202,4 +212,4 @@
 
  
 
-?>
\ No newline at end of file
+?>

It expects an array in config.php like so:

openid_user_urls = array(
	"http://wo.uter.be/" => "wouter@GREP.BE"
);

(in the case of kerberos; if you use a different authentication method, the syntax of that array will most likely be different, too) It's still not perfect; all my changes really do is bypass the password check if it notices that apache has already authenticated the remote user; but I still need to "log on" at the PHP level, which also requires me to enter my OpenID URL. A somewhat cooler implementation would pre-enter the OpenID URL in the form. A really cool implementation would not even show me the logon form, but go straight to the "logged on" state, using the OpenID URL as given by the consumer, and the information apache provides us on the remote user. But it's a start. Adding OpenID capabilities to my blog comment entry script is proving slightly more challenging, however. More on that later.

Call me pessimist, but I can't see how wind power works as a civilisation's main power source without massive backup by either energy storage or alternative energy sources for those times when there's just no wind. There are only few (if any) locations with winds which blow 24*7 at enough strength. So our world needs, even more than wind power, any technology that reduces power consumption (which can mean, in many cases, fall back to some old-fashioned technology. Like a proper on-off switch instead of a standby mode. /me would probably vote in favor of a law mandating on-off switches on all electrical devices.)) (Oh, and to Joey, in case he didn't notice: Winter's back! :-)