I was recently forced to face once more the limitations and quirks of rpm. This is more painful, when looking at a more capable system like .deb.

When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .

Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.

Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time

So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.

Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.

Fatality two - why fatality one was met

All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.

This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).

Fatality three - why rpm based system fail to have upgrade support today

Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:

• new-preinst 2
• new-postinst 2
• old-prerm 1
• old-postrm 1

The numbers 1 and 2 are literally what is passed to the scripts and mean "the number of the installed versions of the same package that will exist after the current operation finishes". No versions of any kind, no other parameters, no rollback, no nothing, just 1 or 2.

And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).

More bad ideas from the rpm land (glad not to be there)

In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.

They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.

I just read an interesting blog post about Montenegro [1]. Apparently a key to the process of becoming a country was acting like it was inevitable. It seems that this method can be applied to many areas, one of which is the contest between Linux and some proprietary OSs. For many years monopolists have convinced people that it was inevitable that they would monopolise all areas of software development. Why use any other software (even if it is more reliable, faster, has more features, and is cheaper) if a monopolist is about to dominate the market? The monopolist changes sometimes, the monopolist from ~1990 to now is different from the monopolist of the 1970’s, but the tactics of a computer monopolist remain the same. The way to beat this is largely to just ignore them. There is an ongoing debate in some circles about when Linux will be “ready for the desktop“. I’ve been running Linux as my primary desktop environment since about July 1998, it’s almost 10 years of having Linux as my primary desktop environment. It seems inevitable that the Linux will take over the desktop - it’s far better for desktop use than it was 10 years ago when I switched. Some people claim that Linux lacks driver support. Every piece of hardware that I’ve wanted to use over the last 10 years has had adequate support. Often second-hand hardware works best with Linux, hardware vendors have no reason to continue to support their old products on newer operating systems (they make more money if you buy new hardware to run the new OS). Not only is hardware support for Linux adequate, but long-term support is far superior (and I often get to use cheap second-hand hardware). Now that an increasing number of hardware vendors are supporting Linux for their new hardware (Intel, AMD, and most laptop vendors are doing some good work in this regard). It seems that everyone who has tried both says that writing drivers for Linux is easier than writing drivers for proprietary OSs, so it seems inevitable that Linux will end up with better driver support by all metrics. Linux is designed for users. DRM (Digital Restrictions Management) is not something that interests Linux developers. Run Linux and your computer will obey you and give full quality audio and video. It seems inevitable that Linux will dominate the AV section of the market (it already dominates the computer work involved with creating movies). Free software (of which Linux is merely the most famous and popular example) is based on the principles of open design and open standards. When you use a free software program to save a file then you can be reasonably sure that you will be able to read it back again in a few decades. Most free software uses file formats that are well documented and standardised. Sometimes there are bugs in programs and new versions will use files in a different way, this is sometimes a case when you rely on a bug in an old version. Using the older version of the software is sometimes required to properly access old data. Fortunately when you have the source to the older programs they can be compiled on new systems (so different types of CPU won’t matter). Also the lack of DRM means that an OS image can be virtualised. One thing that is on my todo list is to create a set of virtual machine images of some of the most commonly used distributions of Linux so I can easily compare distributions of 10 years ago with modern distributions - it’s not technically challenging and there is no particular technical or legal obstacle to doing this. This would also mean that if someone gave me a file in some strange format from 10 years ago I would have a better chance of reading it. It seems inevitable that as the value of data increases the desire to avoid OSs that prevent people from accessing their own data will also increase, and that will eventually squeeze out most closed software from the market. This doesn’t mean the end of proprietary software, merely the end of software that holds user’s data hostage. The majority of the world’s population does not use computers. The computers that they end up using will be cheap because they can’t afford to waste so much money on new hardware. To make cheap machines means that there will be limited resources in terms of RAM, mass storage, and CPU power which require more efficient software. Also to properly take advantage of machines with small screens and other limitations changes to the design of the software will be required. It seems inevitable that the most open software will be adapted to such environments more readily than proprietary software. Now this doesn’t mean that we can take a break from development. In the free software community there are usually many different programs to perform a particular task with competition between the developers of the various projects. The fact that a monopolist is inevitably going to lose it’s position is of little relevance to the competition between the various free alternatives.

• [1] http://www.airs.com/blog/archives/115

Share This

I spent a while yesterday playing with an OpenGear serial console device. It presents an interface to a number of devices via TCP. Unfortunately it is a little flawed for our purposes. We'd like to be able to telnet directly to a serial console of a connected device, like so:

telnet $ip 2000+N

That would give us the serial console of the device in port N. However rather than dropping us straight into the serial console it instead presents a login: + password: prompt. We'd like that removed. The solution according to the manual is to enable the use of RFC 2217 - but that will be a pain. Apparently downloading the CDK will allow a new firmware to be built, and I could fix this problem. Unfortunately the firmware produced by this built fails to flash - failing with an error "Error: Firmware is for a different product". Sigh. Still I have got a partial solution. / is mounted read-only. But /etc/config is writable and /etc/config/rc.local is executed at boot-time. My file contains this:

#!/bin/sh
if [ ! -d /tmp/bin ]; then
  mkdir /tmp/bin
fi
# fake login which won't prompt for username / password
echo '#!/bin/sh' > /tmp/bin/login
echo 'pmshell -l $4' >> /tmp/bin/login
chmod 755 /tmp/bin/login
# fake inetd which exists with the modified PATH so our
# fake login will be invoked.
echo '#!/bin/sh' > /tmp/bin/inetd
echo 'PATH=/tmp/bin:$PATH /bin/inetd $*' >> /tmp/bin/inetd
chmod 755 /tmp/bin/inetd
# use our inetd
kill -9  $(ps -f   grep [i]net  awk ' print $1 ')
/tmp/bin/inetd &

Suprisingly this solution works, but it is nasty. If anybody has any success rebuilding firmware for a CM4148 (running stock 2.3.1u3 firmware currently) I'd appreciate pointers. Unfortunately the source contained upon the opengearweb.org website also fail to flash, when rebuilt. ObQuote: Shooting Fish

• Security futurists shun perimeter, anti-virus systems
• Battlestar Galactica Last Supper
  (warning, image contains spoilers)
• An hour and a half with Barack Obama
  He'd get my vote.

Dear lazyweb, this sunday afternoon, I opened BackupManager’s Bugzilla and started squashing bugs. There was 54 bugs opened that requested a review. 15 of them are now tagged “pending” (meaning they’re closed in SVN and will be shiped with the next release). All of the patches submited - that made sense - were applied, thanks to all the reporters for their help, by the way. So, fear a new release soon…

I am a huge political junkie and I have been closely following Europe and US politics for more than 5 years. After this time and several disappointments, I have to admit that Obama is the first truly inspirational politician I have seen (listen to the Yes We Can song based on his New Hampshire speech). Some of his detractors dismiss his speeches as lousy, empty or vague, but you just have to listen to a couple of them to see that he is genuinely smart (such as the one about faith and atheism or the interview at Google). He doesn’t only take the right stance on most issues that I care about (Iraq, foreign policy, ethics, net neutrality, …), but he does it in a sincere way. Obama just gets it. I have got this impression from watching several of his speeches and interviews, but Marc Andreessen had the chance to spend an hour and a half with him a year ago and got the very same feeling. The main argument against Barack Obama nowadays is his alleged lack of experience. “Watch how I run my campaign”, Barack said to Marc when inquired about that. It’s obvious that running a primary campaign isn’t the same as being POTUS, but being the president’s wife isn’t exactly the same either. So if we compare the Obama and Hillary campaigns we can easily see Hillary’s experience as an “old school” politician. She overstates, lies, accepts loads of money from lobbies (because “they represent people too”, haha), resorts to fear-mongering (”Obama is not a muslim, …, as far as I know”, 3 a.m. ad), sides with McCain if needed to get some extra votes, surrounds herself with nitwits, … . To summarize, she uses every dirty trick she has learned in these years in Washington, and that’s exactly what I am so sick of right now. On the other hand, Obama’s campaign hasn’t just been one of the best organized and executed campaigns I have ever seen, but also the cleanest one. He has managed to overcome double-digit Hillary leads in most states without having to resort to any of these experienced politician’s dirty tricks. If I have to trust one of both to run a country, the decision is obvious. If I didn’t manage to convince you, I hope Lawrence Lessig and xkcd’s Randall Munroe do. Obama is leading and almost there, he just needs the final push. Please, do the right thing.

I see that github have recently announced their pricing plans. Looks like they’ll not be having many kernel developers using their “open source” plan - my current working Linux .git is 261Mb but you start having to pay at 100Mb. git may be very space efficient but the kernel is an enormous project. Mind you, the whole web service based approach of github is fairly alien to kernel development - a large part of what it’s doing is replacing the combination of mailing lists together with git send-email and git am (or their equivalents) that the kernel relies on for code exchange and review. Interestingly it appears not to have done anything that provides the discussion and review side of things - that seems like a surprising omission for a web 2.0ish thing.

Wednesday:


Today:


Hurrah for the open source development model!

(One of these taken by someone who can take pictures, and one taken by me)

Because of some modifications at my Real Life Orkplace, I decided to reduce other duties to get a better chance to deal with my new duties. So i requested help for my four packages in the Distribution

RFH: jove

My first package. A small, but powerful Emacs-relative, with all those uneeded things stripped which makes emacs fat. Maybe these days especially useful for small memory devices, as it gives you emacs-likeness for the price of nvi or ae. I have no idea how well it works in a real utf-8-environment.

RFH: milter-greylist

A greylist-milter which makes running a mailserver somehow possible for me. it keeps away about 2/3 of spam, which leaves me with only 400spams/day. I already have two contacts who want to help with that.

RFH: nn

No news is good news, but nn is better. This is a USENET reader, for those people who grow up with Webforums and Blogs: This could be still the most effective way to celebrate flamefests, gather information or communicate with people sharing same interests. And nn has in my opinion the best UI for it, and makes it easy and fast to find interesting articles and skip others. Well, Upstream Development has ceased to exist around 1994. I think if no one takes over, this package will become finally useless when IPv6 gets widely used (right after the release of 'Duke Nukem Forever') and it also doesn't deal well with non iso-8859-1-charsets. So best for this package would be to rewrite it from scratch (my dream: message/mime-handling/threading from mutt, scoring from slrn, and UI from nn) because the User Interface is much better than those of all still alive Newsreaders i tried.

RFA: synergy

This is my most popular package, which makes it possible to share one mouse and keyboard over many computers and displays. (It is available for UNIX/Linux, Windows and MacOS) This is a very very useful software, and i use it permanently. Sadly the Upstream Development mostly ceased to exist, and so i put this to RFA (instead of RFH) because many Debian-Users use it according to popcon. This software should be taken over by someone who is able to help Upstream. There is a RC-Bug, which caused the package be pulled from testing.

Interesting is that while filing those RFH/RFA all the same day, i only got responses for the packages which scores lowest in popcon, (24 for milter-greylist, 1196 for synergy).

So my flight from SFO to AKL was nice and uneventful. I even managed to sleep for about 6 hours. The flight landed about 30 minutes early in Auckland, but alas, the connecting flight had some sort of "engineering" problems, and was delayed from a 6:30am departure, past 7:30am, and then the next thing I knew they were handing out bits of paper saying the flight wouldn't be departing until 10pm and we were all getting shuttled off to a hotel for the day. So I don't really know what happened to the flight, but the same flight number is now departing this evening. Fortunately I didn't have a huge amount to do today in Brisbane (but I have no idea what Nick had intended to do today). I currently estimate I'll get into Brisbane at around 11:30pm tonight. I've got plenty of reading I was planning on doing on the flight, which I didn't do any of, so I can keep myself occupied. I'm also going to try and catch up with Rowan and Kelly. Oh, and it was good to be able to have a shower. It sure beats sitting around in Auckland International all day. I think this is the first time I've had a delay like this. The moral of the story? Direct flights, hang the expense!

Before my hard disk adventure, I used to use whereami to manage my laptop network setup. Whereami is pretty good. It allows me to detect whether a cable is connected to my NIC, and not even bother wasting several minutes in trying to get a DHCP lease. It can run tests on several interfaces, and decide that I am "home" if it finds a known network on either the wireless or the wired interface. Most importantly, it allows me to build a script based on where I actually am, so that I can have my laptop modify several configuration settings that depend on the actual network I'm on -- say, whether or not to use a proxy, or whether or not to use an SMTP smarthost. I was having issues with whereami lately, however, and thought to look for something else. After all, it's true what they say; whereami does not properly integrate with ifupdown. If you use whereami, modifying the network configuration involves "/etc/init.d/whereami start" or some such; just "ifup eth0" will break things horribly. Additionally, I was having issues with my WPA setup; there is a testwpa, but it does not seem to work for me for some reason—and I can't seem to figure out what's going on in order to file a bug. Apart from the two issues above, I was having some minor annoyances with my setup; enough so that after reinstalling my system, I thought to try something else. The guessnet package is designed to properly integrate with ifupdown, so I thought I'd give it a try. I don't think it is what I'm looking for, though.

#  route_data = $ lookup 
#			$ readfile /etc/whereami/topmost_location 
#		 lsearch /etc/exim4/smarthosts 
  route_data = $ lookup 
  			$ extract eth0 
				$ readfile /etc/network/run/ifsftate 
			 
		 lsearch /etc/exim4/smarthosts 
		$ lookup 
			$ extract wlan0 
				$ readfile /etc/network/run/ifstate 
			 
		 lsearch /etc/exim4/smarthosts 

The upper version is what I used with whereami (but not active, see the comment marks :). My script would write something to /etc/whereami/topmost_location, and several other things (including my exim configuration, as shown above) would use that to automagically modify their configuration. Which is pretty cool. The lower version is the equivalent of the upper version with guessnet. How ugly. And then I didn't even see a way to avoid ifup from trying to 'up' eth0 if the MII tells me there is no cable in the NIC. Oh my.

Last week I did again some work on nagios-plugins. After the announcement of Dann Frazier to upload NMU to fix a trivial bug, I thought it’s time again to give some extra care to the package. So I prepared 1.4.11-2 fixing the important bugs and uploaded it. I also commited some minor fixes to the svn, so these issues will get fixed by the next upload. Since the development of policyd-weigh stalled and unfortunately maybe get stuck, I was looking for an alternative, which maybe found with postfwd. It’s quite flexible but it also will take more time (and care!) to get a reliable configuration, which maybe effective as policyd-weight (still) is right now. While checking the dependencies for postfwd I noticed that Net::DNS::Async isn’t available in Debian (yet). So I decided to create a package starting with dh-make-perl, join the Debian Perl Group and let it review. Damyan Ivanov was so kind to review and upload it, Gregor Herrmann did also give some much useful hints. Thanks to both! And yes, I also found time to step forward with NM, since I was overloaded the last weeks with usual work and life. Thank to my AM to be so appreciative.

In case you didn’t know, I’ve decided to resign as atheme project lead. This is for a few reasons:

• Firstly, I have felt overall ineffective in this role since late 2007. This is probably due to the fact that disagreements between me and several other people have resulted in people leaving the organization to work on other projects, and the fact that atheme has not grown in any significant way since last year’s Summer of Code event.
• Secondly, I am busy with a lot of other things and do not have time to give the proper attention this role needs. This role is basically defining the direction that atheme grows in, and capitalizing our strengths to expand the project and promote it. I see the lack of growth and proper promotion as a personal failure.
• Thirdly, at the moment I am under a lot of stress due to dealing with various issues at the moment, which is leaving me irritable and generally quick to anger. This is not a quality we want in our project leadership. In short: I’m fucking up, and it needs to stop. So right now, I am resigning as project lead. If people want me back when I am under less pressure in general, then that’s great.
• Fourthly, we need to see new leadership in atheme anyway, to keep things interesting. Without a regular change in leadership, people will start to see us as someone’s personal project, and that’s not the case with atheme.

However, just because I’m resigning as project lead doesn’t mean that I will stop working on projects I care about inside atheme, like audacious, mowgli, and mcs. These projects are critical components of the modern FOSS desktop, and I intend to continue working on them. This is purely an administrative change, so that any mistakes or stupidity I do have no effect on atheme.org’s overall health. I hope to see many other Atheme members step up and try to become project lead. Under the right leadership, atheme’s projects could become a much more notable platform in FOSS development within a short amount of time. Update: Due to popular demand, I have changed my mind. I’m no longer resigning as project lead of atheme.

dpkg-cross updates
uploaded to Debian unstable

   * General support for querying endianness of an architecture.

   * Update standards version (no changes)

   * Add Cvs-CVS field to debian/control

   * Reinstate detect_arch for improved build test checks in emdebian-

     tools

   * get_endianness: new function for Emdebian TDeb support

This provides support for architecture-dependent TDebs in Emdebian as well as adding detection of armel.

emdebian-tools 0.8.3
Uploaded to Emdebian

   * Interim Emdebian release.

   * emsecondstage: ensure cdebconf environment is setup before

     configuring packages

   * emdebian.gpe: Add extra packages needed to allow the gpe package set

     to boot.

   * Emdebian::Tools, (create_patches) : skip generated files.

     [*.debhelper, *.substvars, files]

   * em_installtdeb: support special modes via debian/xcontrol

   * Support unpack method in basic emsandbox rootfs

   * embootstrap: continue after some errors

   * Support unpack method in gtk emsandbox rootfs

   * Simplify basic empdebuild chroot and copy in hostname files

   * empbuilderlib: add support for creating skeleton versions of

     /etc/group and /etc/passwd.

   * empbuilderlib: add an approximate time set func for use when no

     network is available.

   * emsecondstage: configure cdebconf before others so that the database

     is ready

   * embootstrap: use the new support in empbuilderlib for group, passwd

     and date

   * Add --arch support to em_installtdeb

   * Depend on new support in libdebian-dpkgcross-perl

   * empdebuild: force the -S argument to apt-cross to prevent

     intermittent failures

   * empbuilderlib: parse the .list contents from dpkg

   * embootstrap: ensure buildplace is clean before starting a fresh

     debootstrap

   * emdebuild: use dpkg-cross support for detect arch to distinguish

     between arm and armel binaries

   * Emdebian::Tools. add parse_xcontrol function for easy queries of

     debian/xcontrol

   * pbuilder/emdebian.crossd gpe gtk : Tidy up the scripts with routine

     calls to the empbuilderlib library

   * pbuilder/empbuilderlib: Add some common routines to help make the

     rootfs bootable

   * pbuilder/emsecondstage: bring into line with other changes in the

   * empbuilderlib.3 : Add a manpage for the expanded set of common

     functions in empbuilderlib

   * Suggest file-roller for inspection of rootfs tarballs

   * emdebhelper.mk: sync with recent changes in CDBS for debhelper

     support

Reasoning
OK, so why upload emdebian-tools to Emdebian when it depends on the update to dpkg-cross in Debian?
Well, emdebian-tools is becoming a bit of a behemoth. I mean a package that has only existed for 12months and has had over 30 releases, increasing in size from 30kb to over 500kb (without counting dependencies) and which encompasses a gammut of scripts with different roles is just begging for a functional package split.
Package splits take time - not just the time in NEW but all the testing to ensure that each split can be installed separately without falling over "Unable to find foo in @INC" etc.
At the same time, emdebian-tools is both rapidly developing and becoming remarkably stable (which gives some indication of just how diverse it has become).
So I'm heading for a 1.0.0 release before Lenny and to achieve that, I want to split it:

1. emdebian-tools - umbrella package consisting of the core build scripts (perl) - these are becoming quite stable - that depends on all the others.


2. emdebian-archive-keyring - tiny package that just implements SecureApt for the Emdebian repository.


3. emdebian-rootfs - the rapidly developing (shell and perl based) root filesystem management scripts, based on debootstrap and pbuilder.


4. libemdebian-tools-perl - a standard perl module of common functions for the other packages.

This allows people to use the toolchains with the smallest package, prepare root filesystems from prebuilt binary packages with just three of the four and only those who build packages will need all four.
So the plan, overall, is to keep updating emdebian-tools in Emdebian unstable during the time that emdebian-tools 0.9.0 goes through NEW in Debian. Then, when 0.9.x is in testing and any issues from the split are resolved, 1.0.0 can be uploaded to Debian.

Package split issues in general
Something that bugs me with package splits is this stable vs development issue within the same source. I think it would be sensible to only upload emdebian-tools (the stable bit) if it changes but to upload emdebian-rootfs as often as necessary whilst still building from the same source.
This issue will also bite when Emdebian deploys other functional package splits and seeks to improve apt itself to handle many, many more binary packages.
It's also a similar idea to allowing translators to upload TDebs separately from normal package updates.
Why should I have to split the source in $RCS in order to upload package splits separately? Other upstream teams won't do that so Debian needs a solution.
Why should users have to download emdebian-tools 1.0.1 which is absolutely identical to 1.0.0 just because emdebian-rootfs needed lots of updates in 1.0.1. (Remember, emdebian-tools will depend on emdebian-rootfs so when emdebian-rootfs is updated, all users of emdebian-rootfs and all users of emdebian-tools will get the update. Yet I don't see why emdebian-tools itself needs to be touched.)
It is plain daft.
I've seen similar issues in other environments where, for various very good reasons, users need to limit the bandwidth and duration of apt downloads. For Emdebian, we also need to limit the total amount of data downloaded by apt-get upgrade simply because free space on the device can be severely restricted - my target device will have about 7Mb free space and that is regarded as "under-utilised". Downloading an entire package just to update /usr/share/foo/changelog.gz in such circumstances is just plain stupid. I know we can do better than that.
Apt needs to become much more intelligent and have a way of only downloading the changes in packages instead of the entire .deb - something along the lines of an rsync method. To get that working, the actual package names need to be munged so that rsync can compare foo_1.2.3-1_all.deb against foo_1.2.3-2_all.deb by having both symlinked as foo_current_all.deb. (dpkg-name can restore the original name if needed.)
Such a method must be possible and would have enormous benefits for packages like OOo where each upload can't be changing 100% of the code each time, yet we all have to download Mb after Mb of content that is identical to what dpkg is about to replace.
Am I just ranting or does this strike a chord on the lazyweb in general?
The slowest part of many desktop experiences of Debian could well be the time taken to download updates - not everyone has multi Mb broadband.

OK, this is just one of those things that just shouldn't happen but always seem to happen anyway.
In testing an installation method for Emdebian, creating certain system config files for the target device ended up with a test script putting the Emdebian config file onto the main system. Yes, permissions would have stopped this but the other part of the test routine is udev and ensuring the device has a working console, hence the script needs to run under sudo to unpack the device nodes.
Just goes to show, developing scripts that work under sudo is a minefield of bugs. The law of unintended consequences means strange things can happen on the development box.
What did I do?
Oh, just replaced /etc/group with a installer copy.
Not much broke - except that 'ls' listed the group as 1000 instead of 'neil' and I stopped getting email.
I didn't twig initially - but then I realised that exim could not find the exim group because the Emdebian rootfs doesn't have exim or any MTA. All my email had arrived but it was frozen in the exim queue because exim couldn't work out how to proceed without an exim group.
Ah well. Good to know that I had a backup of /etc/group.

Suddenly, sudo runq dropped several hundred emails onto dovecot. Hey ho.
If only I could get USB to serial working on this HP laptop, I could play with these things on a box that is less important to my overall day to day work.
Still, nice to know exim did the right thing. Thanks, exim.

For people who have interest in the development of gender equity in FLOSS development, here's a short news item. Yesterday, the Samba Team announced the "pre2" version of samba 3.2.0, scheduled to be released during the SambaXP conference next month in G ttingen (to German friends around: of course, I'll be there: Apr 14-18). That release was announced by Karolin Seeger, whoc is now replacing Jerry Carter as Samba's release manager. As far as I know, Karolin is indeed the first female memer of the Samba Team (which includes about 20-30 people). Guess what: that release seems to be a pretty good one. I'm already working on the Debian package. The release is indeed the first one to include many patches we bringed from Debian, for instance those aimed at following the FHS. Steve Langasek is the one to be rewarded for this as he bringed very valuable input in the discussion I had with Jerry Carter to convince him to include these patches..:-)

As many of you might not know I love steam. Steam power, specifically. Steam engines represent one of the most interesting engineering developments in history as far as I'm concerned, (closely followed by the accurate mechanical clock). Why? When I was a kid I had a computer. Each part of it was labeled and described in a manual. I knew what it was. I understood how it worked. I could build one myself if I had the time and re$ources. Nowadays? Hell no. Sure I can assemble the different components, but I can no longer visualize the whole entity, and I couldn't build one from scratch. I'm amazed at youngsters (~18 yrs old) who can understand a modern PC. Me? I do, but only barely, and that is primarily because I've watched the transition: Hercules Graphics -> CGA -> VGA -> SVGA -> & etc. Coming in cold? Right now? I'd be lost. I'm impressed (saddened? That this stuff isn't more accessible?) that people can pick up technology and understand it, without having watched the developments along the way. "Southbridge"? "Northbridge"? "APIC"? It's the same with everything. Fixing a car engine? These days? With electronics? Hell no. My (non-existant) car breaks, I'd be fucked. I can strip a simple engine. I could repair it if I had to. I could build a steam engine. I could, given a suitable template and collection of eye-glasses, build a mechanical clock. But computers? Modern Cars? Aeroplanes? More complex than a simple person like me can understand. And somehow I think that's a bad idea. It almost reminds me of the old Asimov stories where only computers could design new machines. People just didn't undestand them anymore.   So, in conclusion. I have new steam car. It works, as you can see in this adhoc video. (Randomly captured by my partner whilst I was too busy squee'ing. Excuse the quality and lack of editting. Notice too that I've removed the seats for the test drive, just to give me a safe place to pick it up without burning my fingers!) Lets hope the rise of the machines is soon, otherwise mankind will have collectively lost all knowledge of things less advanced than hot & cold electricity and the microprocessor. (As you can tell it is late and I've just had many beers and a beautiful curry. All is well! Thanks for reading!)