Well, I am sure all of you have already read the announcement: Lenny (aka Debian 5.0) is out! I have been using Debian on all my machines since at least mid 2003, when Woody was stable. Sarge was then released in 2005, then Etch the year after. I have updated my personal repository of unofficial packages for this new stable release. I have let etch packages available (under oldstable), but will remove them in a while. This repository is mainly mainly composed of backported or patched packages for my own use, but can be used by anyone (but I do not guarantee anything ;-)).

If you are following this blog, you probably remember per-process namespaces. Today, I m going to tell you how I did use them in the process of preparing this server to be upgraded to Lenny. I must say I was not using the most recent stuff on this server, and this is why I needed such preparation. First, this server is still running with php4. And well, the following line in the apt-get dist-upgrade output got my full attention (emphasis mine):

The following packages will be REMOVED:
cacti libapache2-mod-php4 libarchive-tar-perl libcurl3-openssl-dev
libgssapi2 libpci2 librpm4 libssp0 linux-kernel-headers modutils php4-mysql


While this server is not important enough not to be broken for a couple hours, I do like to test procedures that could help on servers that are. The first thing I needed to do on this server was obviously to upgrade php. But we all know how php applications are not fully compatible with all versions of php, so I also needed to test the upgrade was not breaking anything. On a server you don t care much about, you can just upgrade, test if all is okay, and be done with it. Obviously, if all is not okay, your visitors will see it, and you may also have a bad time downgrading. Another way to perform the upgrade is to have a similarly installed server on the side, test and validate the upgrade there, and replicate the upgrade on the production server if everything is fine. However, that does require additional resources, and possibly to setup them if they don t already exist. A cheaper way to do the above is to do it on the production server, both in-place and on the side (you ll see what I mean), using unionfs and per-process namespaces. Full containers could be used instead of per-process namespaces (such as openvz, vserver or lxc), but they still require much more setup, especially when you don t use them in the first place. Chroots could work just as well as per-process namespaces, but one of the ideas here is to expose the per-process namespaces feature, and allow for improvement of this procedure with pid and network namespaces, which are not available in Etch (where I m starting from), but are in Lenny. Unionfs allows to merge several directories into a single one, accessing some read-only, and others read-write. Installing unionfs is as easy as running the following command:

apt-get install unionfs-modules- uname -r

I won t describe all the kinds of setups that are possible with unionfs, but only one typical use case, which is what we will be using here:

# mkdir /tmp/root-cow
# mount -t unionfs -o dirs=/tmp/root-cow:/=ro none /mnt


The first thing we do here is to create an empty directory. Next, we merge it with the root filesystem (/), that we will keep read-only (meaning unionfs won t allow itself to write there), and mount the merged filesystem under /mnt. none could just be anything, as there is no device to be mounted. The result, in /mnt, is just something that looks like the root filesystem:

# ls /
bin boot dev etc home initrd lib media mnt opt proc root sbin srv sys tmp usr var
# ls /mnt
bin boot dev etc home initrd lib media mnt opt proc root sbin srv sys tmp usr var


But creating or modifying a file will do so in /tmp/root-cow:

# echo a > /mnt/a
# cat /a
cat: /a: No such file or directory
# cat /tmp/root-cow/a
a
# echo foo.com > /mnt/etc/mailname
# cat /etc/mailname
glandium.org
# cat /tmp/root-cow/etc/mailname
foo.com
# find /tmp/root-cow
/tmp/root-cow
/tmp/root-cow/etc
/tmp/root-cow/etc/mailname
/tmp/root-cow/a


Keep in mind that it doesn t include submounts, though:

# ls /var
backups cache lib local lock log mail opt run spool tmp www
# ls /mnt/var


This means we ll have to also mount /var, /proc, /dev, and /sys. That s enough testing for now, and we ll first do some cleanup before going after the real job:

# umount /mnt
# rm -rf /tmp/root-cow


Using the newns utility from my first post on per-process namespaces, let s create a new namespace to keep our testing private, and populate it with the necessary mount points:

# newns
# umount /tmp
# mount -t tmpfs tmpfs /tmp
# mkdir /tmp/root-cow /tmp/var-cow
# mount -t unionfs -o dirs=/tmp/root-cow:/=ro none /mnt
# mount -t unionfs -o dirs=/tmp/var-cow:/var=ro none /mnt/var
# cd /mnt
# pivot_root . mnt
# mount --move /mnt/proc /proc
# mount --move /mnt/sys /sys
# mount --move /mnt/lib/init/rw /lib/init/rw
# mount --move /mnt/tmp /tmp
# mount --move /mnt/dev /dev


The second and third statements are useful to avoid sharing /tmp with the main namespace, which means the directories we create in the fourth statement won t be visible in /tmp outside this namespace. The fifth and sixth statements put the union filesystems in place. As my system only has a separate /var filesystem (no /usr, and I don t care about /home here), I only need to setup these two. Feel free to add more union filesystems as necessary. The pivot_root call allows to switch to the unionfs ed root: everything under /mnt (/mnt and /mnt/var in our case) will be remounted under /, while what was under / is remounter under /mnt under the new root.
This means, in our case, that we have / and /var as union filesystems, while the old / and /var are respectively in /mnt and /mnt/var. It also means /dev, /proc, /sys and other filesystems are remounted as /mnt/dev, /mnt/proc, /mnt/sys, etc., which is why we next mount --move all of them to a better place in our namespace. Once all this setup is done, we are ready to do our php upgrade test. As Etch doesn t have support for neither PID namespaces nor network namespaces, we ll still have some conflicts with the main namespace for TCP port binding and process handling, so we need to be a little careful:

# rm /var/run/apache2.pid
# echo Listen 8080 > /etc/apache2/ports.conf


With these changes, we can now safely start apache2 in this namespace, at the same time the main apache2 runs in the main namespace:

# /etc/init.d/apache2 start


Now, there are actually 2 problems showing up in apache in this setup. The first one is that displaying static files doesn t work. At all. It appears unionfs doesn t support sendfile(). Which is fine. But apache doesn t check for sendfile() s error cases and doesn t fallback to a working solution when sendfile() doesn t work. So we have to manually disable it:

# echo EnableSendfile off > /etc/apache2/conf.d/sendfile.conf


The second one is that access to the mysql socket doesn t work properly under the unionfs. I didn t want to investigate further, so I only worked around the issue by forcing to use the socket outside the unionfs:

# mount --bind /mnt/var/run/mysqld /var/run/mysqld


Finally, we can test and validate our php upgrade:

# apt-get install php5-mysql php5-cli php5-snmp libapache2-mod-php5
# /etc/init.d/apache2 restart
# apt-get remove --purge php4-common


Note that installing libapache2-mod-php5 will remove libapache2-mod-php4, and apache2 gets restarted, taking into account this change. But the php modules (php5-mysql and php5-snmp) install is only going to happen after that, and no apache2 restart is triggered then, which leaves a half working php setup
Also note that the cacti setup in etch supposes php4 is installed, using a IfModule statement against mod_php4.c and none for mod_php5.c, which means a part of its setup doesn t work out of the box (most notably, the DirectoryIndex). Once all is validated, all we need to do is to stop apache2 and exit from the namespace. The union filesystems and temporary filesystems are then automagically cleaned-up and the namespace disappears as well as all modifications we just did, since all processes using the namespace ended. We are now free to upgrade on the production server, as we know all the side effects. I ll now be able to upgrade to Lenny without php getting removed.

This weekend I have mostly been investigating Common Lisp. If you're new to the environment then you may get started via a simple:

apt-get install clisp

Once you've done that the following resources will help you decide whether you're wasting your time or not:

• Practical Common Lisp
• The Common Lisp Cookbook

It has been a long time since I've had so much fun - even though the first thing I did was experiment with implementing a spam filter - although in my defense I was only classifying based upon the links contained in the mails. So for example:

• http://gmail.com/ - Good.
• http://www.facebook.com/ - Good. (ha!)
• http://tallbear.com - Spam
• http://pamperflow.com - Spam

(NSFW links) ObFilm: Batman

After my entry yesterday about MySQL truncating data, several people have pointed out that MySQL 4.1 or later gives you a warning. Yes, this is true. You can even see it in the example I gave:

Query OK, 1 row affected, 1 warning (0.00 sec)

I ignored mentioning this, but perhaps should have said something about it. I reason I didn't mention it was because I didn't feel that a warning really helped anyone. Developers have enough problems remembering to check for errors, let along remembering to check in case there was a warning as well. Plus, they'd then have to work out if the warning was something serious or something they could ignore. There's also the question of how well the language bindings present this information. Take for example, PHP. The mysqli extension gained support for checking for warnings in PHP5 and gives the following code as an example of getting warnings:

mysqli_query($link, $query);
if (mysqli_warning_count($link))  
   if ($result = mysqli_query($link, "SHOW WARNINGS"))  
      $row = mysqli_fetch_row($result);
      printf("%s (%d): %s\n", $row[0], $row[1], $row[2]);
      mysqli_free_result($result);
    
 

Hardly concise code. As of 5.1.0, there is also mysqli_get_warnings(), but is undocumented beyond noting its existence. The MySQL extension does not support getting warning information. The PDO wrapper doesn't provide any way to get this information. In perl, DBD::mysql has a mysql_warning_count() function, but presumably would have to call "SHOW WARNINGS" like in the PHP example. Seems Python's MYSQLdb module will raise an exception on warnings in certain cases. Mostly using the Cursor object. In java, you can set the jdbcCompliantTruncation connection parameter to make the driver throw java.sql.DataTruncation exceptions, as per the JDBC spec, which makes you wonder why this isn't set by default. Unfortunately this setting is usually outside the programmer's control. There is also the java.sql.Statement.getWarnings(), but once again, you need to check this after every statement. Not sure if ORM tools like Hibernate check this or not. So, yes MySQL does give you a warning, but in practice is useless.

Congrats and thanks to all people involved into releasing Lenny! Keep on the good work!

Now everyone can concentrate on the next release of Debian called Squeeze. My wishlist for the new, upcoming release:

1. no political, show-stopping discussions or GRs anymore.


2. more members in core teams such as ftpmaster, DAM, debian-admin, ... - don't wait until someone will eventually join, but look actively for new members and train them, so that the workload for everyone involved will be less at the end.


3. please forget your personal dislike when working with other people. You don't need to be friends, but you should be able to work together like professionals and concentrate on the topics.


4. please introduce sub-releases for desktop, multimedia, kernel stuff while having a base of core packages for a longer term for servers. Release desktop related stuff more often than the base core packages.


5. acknowledge the work of contributors and find a way to let them some part of Debian without following the long and often unnecessary, unwanted and boring path of NM.


6. and finally: have fun! :-)

So, now it's up to upgrade my machines to Lenny in the next days... I hope everything will be as smooth as everyone is expecting it. :-)

/me++ Or in a bit longer words, today is my birthday and I got a nice present from Debian - a release sent from Samoa. For all the KDE/Debian users, this is also the beginning of something special: Pushing KDE4 slowly to unstable and testing/squeeze.
If you are in the group of KDE-users-against-change, then please stay with the just released version of Debian, Debian Lenny, as this is where KDE3 desktop will be. From Debian unstable, it will dissapear soon.

MySQL in its standard configuration has this wonderful "feature" of truncating your data if it can't fit in the field.

mysql> create table foo (bar varchar(4));
Query OK, 0 rows affected (0.00 sec)
mysql> insert into foo (bar) values ("12345");
Query OK, 1 row affected, 1 warning (0.00 sec)

In comparison, PostgeSQL does:

psql=> create table foo (bar varchar(4));
CREATE TABLE
psql=> insert into foo (bar) values ('12345');
ERROR:  value too long for type character varying(4)

You can make MySQL do the right thing by setting the SQL Mode option to include STRICT_TRANS_TABLES or STRICT_ALL_TABLES. The difference is that the former will only enable it for transactional data storage engines. As much as I'm loathed to say it, I don't recommend using STRICT_ALL_TABLES, as an error during updating a non-transational table will result in a partial update, which is probably worse than a truncated field. Setting the mode to TRADITIONAL includes both these and a couple of related issues (NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO) You can set the mode using:

• On the command line:

  --sql-mode="TRADITIONAL"

• In /etc/mysql/my.cnf:

  sql-mode="TRADITIONAL"

• At runtime:

  SET GLOBAL sql_mode="TRADITIONAL"
  SET SESSION sql_mode="TRADITIONAL"

Just say no to databases that happily throw away your data

When upgrading from older crm114 releases and trying to retain your existing configuration it is important to check that all the configuration options that the new version expects to be set have been set. While some will cause errors if they re omitted others will appear to work but will cause unwanted behaviour at runtime. For example, omitting good_threshold and spam_threshold will cause everything to be flagged as spam in X-CRM114-Status even though the classifier is working well. In practice there are relatively few configuration options that users are expected to configure so it may be easier to redo the configuration based on the example provided. For safety it s best to delete your existing CSS files too in case they ve been invalidated by a configuration or format change. It s all a bit manual but it s worth it for what it does for my inbox.

I just finished most of my jobs for the Lenny release. I started, together with Mark Hymers, at 10:23 UTC. This was ahead schedule, which said 12:00 UTC, but better early than late. After disabling all our ftpmaster cronjobs, setting up our work environment and whatever else we needed and at 10:43 UTC we got the Release Teams GO. All of what we did got logged from screen, as we intend to write a dak tool doing such releases. Anyway, I won t bore you with a detailed set of actions we had to took, way too much for now, just some few moments (All times in UTC):

• [10:23] turned off all cronjobs
• [10:43] Release Team GO
• [12:00] etch is now oldstable
• [13:07] lenny is now stable
• [13:28] squeeze is born (and lot of the work for it was parallel with the lenny work)
• [14:18] the cd-builder host gets an exclusive push so people can start building cd images.
• [15:34] squeeze is now grown up enough to be ready for the world. Most of the other work that had to be on the ftp-master machine before we are done is also done. ftp-master is ready for regular work again (but won t do any yet).
• [15:40] Lets start the work for the security archive
• [16:54] The security archive is ready.

While writing this entry people are still doing work for the release. For example the cd building will take time, after all there are well over 500 images (and 36 live cds). Current plan seems to be that we ftpmaster push the archive mirrors around 23:00 UTC, so it has time to sync everywhere. Some while later the cd mirror will get a push, and then the official announcement will happen. Thanks go out to everyone involved in preparing this release, be it in the past by fixing bugs, uploading packages, doing whatever was needed, as well as doing the work today.

Now that the final Mesa 7.3 is available in experimental (and built on most architectures), it is actually easy to get DRI2 in Debian if you have an Intel board. First, make sure you have a recent kernel, otherwise it may fail miserably. I am running 2.6.29-rc here, and I am not even sure 2.6.28 would be enough. Hopefully, one day the driver/server will properly detect and report problems when it runs on a old kernel :) Enable the new UXA acceleration architecture with Option "AccelMethod" "UXA" in the device section of your xorg.conf. Restart X. You should see DRI2 enabled in the log. Now start Compiz and it works. You can see a wobbly glxgears! Well, on my i945, Compiz was very slow by default. I add to disable Sync to-VBlank in the display settings in Compiz' general options. If you don't want Compiz, you may also try running xcompmgr -a and then play with transset to put transparency on 3D applications. Update: Added kernel requirements, added how to make Compiz not slow.

Apart from interesting features such as DRI2, KMS or input-hotplug, there are some minor changes in X in experimental that actually appear to disturb many users. The first one is that Ctrl-Alt-Backspace does not kill X anymore. There is no easy consensus here, but many people were annoyed of killing X by mistake, so it's disabled by default now. To reenable it, add to the ServerFlags section of your xorg.conf:

        Option "DontZap" "off"

Another one is the background during X startup. Say goodbye to the old well-known grey background. Now you get a black background by default. To revert to the old behavior, pass -retro on the server command line (for instance in /etc/X11/xinit/xserverrc). Note that this option also reenables Ctrl-Alt-Backspace killing the server. Finally, you might also see glxgears reporting very low frame rates (60) on some hardware. Well, please remember that it is not a benchmark, the output basically means nothing. This is why some distros even removed the fps output by default. The thing is that recent DRM stacks will just synchronize frame rendering on vertical blanks (can anybody here see 1000fps with human eye?). So if you have a 60Hz refresh rate, glxgears will report 60fps, that's it. But it has nothing to do with DRI or 3D being slow. Please try some relevant 3D programs or benchmarks before complaining :)

Rumour has it that some types of spammer target the secondary MX servers. The concept is that some people have less control over the secondary MX server and less ability to implement anti-spam measures. Therefore if they accept all mail from the secoondary then a spammer will have more success if they attack the secondary server. True secondary servers are becoming increasingly uncommon, the lower priority servers listed in MX records tend to have the same configuration as the primary, so the benefit for the spammer in attacking the secondary server is probably minimal. But it would be good to know whether they do this. I decided to analyse the logs from a mail server that I run to see if I can find evidence of this. I chose a server that I run for a lient which has thousands of accounts and tens of thousands of messages delivered per day, my own server doesn t get enugh traffic to give good results. I analysed the logs for a week for the primary and secondary MX servers to see if the ratio of spam to ham differed. Now this does have some inherent inaccuracy, some spam will slip past the filters and occasionally a legitimate email will be rejected. But I believe that the accuracy required in a spam filter to avoid making the users scream is vastly greater than that which is required to give a noteworthy result. I produced totals of the number of messages delivered, the number rejected by SpamAssassin (which has a number of proprietary additions), the number of message delivery attempts that were prevented due to rate limiting (most of which will be due to spammers), and the number of attempts to deliver to unknown accounts (some of which will be due to spammers having bad addresses in their lists). For each of these rejection criteria I produced a ratio of the number of rejections to the number of delivered messages for each of the servers. The rate limit count didn t seem useful. While the primary server had a ratio of 0.75 messages rejected due to rate limiting to every message accepted the secondary had a ratio of 0.08. It seems that the secondary just didn t get enough traffic to trigger the limits very often. This is an indication that the more aggressive bots might not be targetting the secondary. The ratio of messages rejected by SpamAssassin to legitimate mail was 0.76:1 on the primary server and on the secondary server it was 1.24:1. The ratio of messages addressed to unknown users to successful deliveries was 3.05:1 on the primary and 7.00:1 on the secondary! This seems like strong evidence to show that some spammers are deliberately targetting the secondary server. In this case both the primary and secondary servers are in server rooms hosted by the same major ISP in the same region. The traceroute between the two mail servers is only 7 hops, and there is only one hop between the two server rooms. So it seems unlikely that there would be some connectivity issue that prevents spammers from connecting to the primary. One other factor that may be relevant is that the secondary server has been in service for some years while the primary is only a few months old. Spammers who store the server IP address with the email address (which happens - change the DNS records to send your mail to a different server and you will see some spam go to the old server) will be sending mail to what is now the secondary server. The difference in the rejected mail volume on the secondary server and the amount that would be rejected if it had the same ratio as the primary amounts to 7% of all mail rejected by SpamAssassin and 14% of all mail addressed to unknown users. I think it s unlikely that any significant fraction of that would be due to spammers caching the server IP address for months after the DNS records were changed. So therefore it seems most likely that something between 7% and 14% of spam is specifically targetted at the secondary server. While the ratio of spam to ham seems significantly worse on the secondary it is still a relatively small portion of the overall spam sent to the service. I had been considering setting up secondary mail servers with extra-strict anti-spam measures but the small portion of the overall spam that is targetted in such a way indicates to me that it is not going to be worth the effort. Another thing that has occurred to me (which I have not yet had time to investigate) is the possibility that some spammers will send the same messages to all MX servers. If that happens then the ratio of spam to ham would increase every time the number of MX servers is increased. In that case it would make sense to minimise the number of MX servers to reduce the amount of CPU power devoted to runing SpamAssassin. Note that I have intentionally not given any numbers for the amount of mail received by the service as it is a commercial secret. Update: One thing I realised after publishing this post is that the secondary MX server is also the main server for mail sent between local users. While the number of users who send mail to other users on the service is probably a small portion of the overall traffic (it s not a really big ISP) it will make a difference to the ratios. Therefore the ratio of spam to ham would be even worse on the secondary MX (assuming for the sake of discussion that local users aren t spamming each other).

No, Debian folks, not our former DPL...:-) My, by far, favourite skipper in the greatest race around the world (alone on a 60-feet boat without assistance), the Vend e Globe, arrived last night. I mean Samantha Davies, 34 y.o. female british skipper, who finished 3rd (or 4th, depending on Marc Guillemot's arrival time), who illuminated these weeks with her videos and messages always full of positive attitude and happiness....which is certainly harder to do when surfing in the southern latitudes over 20 knots and thousands of miles away from any land. I recommend those of you who never went on the VG web site to just navigate around the videos and spot those sent by Sam, to understand. She made it with a 9-year old boat (that completes its third VG), keeping up with performance while preserving the boat (probably the one in the best condition after arrival). and all Vend e Globe fans will always remember her constant smile. All this explains why I have even more admiration for Sam's performance than I have for Michel Desjoyaux (the winner) or Armel Le Cl ac'h (2nd), both among the world's top skippers (along with Lo ck Peyron, imho). The race is not over, far from this. Eight skippers still have to arrive. Three of them (Marc Guillemot, Brian Thompson and Dee Caffari) will arrive on Monday or so, while Arnaud Boissi res and Steve White wtill need one or two weeks and Rich Wilson, Rapha l Dinelli and Norbert Sedlacek still are in the southern Atlantic ocean. And kudos also have to go to the 21 skippers who couldn't complete the race, certainly the most difficult Vend e Globe ever. I wish I would live close to Sables d'Olonne to have a chance to see a VG arrival some day. Great race, great adventure. Sad that it happes only every 4 years..:-)

Suspense..... Will we release Lenny today? :-) Whatever happens, I like the way these last two weeks were handled. The clear communication from the release team made it clear to everybody what the deadlines were. That helped a lot in cooking up good Release Notes and the great Release Annoucencement, as well as their translations. Of course, one can regret that all had to happen in the very last weeks (the RN could have been prepared earlier but nobody was in that mood except certainly Martin Borgert who is trying to shake up the tree for months...). Again, great work, everybody and I wish the best to the folks who will burn their week-end up to polish the last bits of that release.

I just finished packing up the signature collection for dedication-5.0.txt. Hopefully I didn't miss any signatures, saving about 400 attachments is tedious. Fortunately most people got the filenames right. On the down side, there were about 80 signatures that I couldn't verify because the corresponding key could not be found on the key servers. I've mailed the owners, and about 20 have uploaded their key until now. There are 355 valid signatures. Thanks to all for such a huge participation, that's about twice the number (185) we got for dedicating Potato to Espy in 2000. (These were DD-only, though.) Comparing to the various Debian keyrings, 207 active DDs participated, 3 former DDs, 12 Debian maintainers, and 133 other contributors. Let's hope Lenny will be as great as Thiemo would have liked it.

From tomorrow, if you start seeing bugs or getting email about your packages where the version string ends in em[0-9], or where dependencies mentioned by reportbug include such a version suffix, the user is running one of the two Emdebian distributions to be released alongside lenny (and based on lenny packages). You might also see Emdebian in the output of 'apt-cache policy' if your bug reports request or supply such data.

If there is any doubt that the bug is present in Debian, please immediately re-assign the bug to the buildd.emdebian.org pseudo-package in the BTS.

I'll be posting to d-d-a with more information on the releases and the em1 version suffix - just as soon as Lenny itself is released.

A patch for reportbug is being tested and I'll file the bug probably tomorrow. A large proportion of the development work to actually get Emdebian to the point of two releases only happened after the lenny freeze began. (Not the recent deep freeze, the initial toolchain freeze before DebConf8). (reportbug itself is not currently part of Emdebian for a variety of reasons.)

Emdebian only uses a small subset of Debian packages, so this principally involves the core packages in Debian, GTK+2.0 and dependencies, XFCE and GPE as well as a small number of applications like iceweasel, sylpheed, xchat-gnome and grisbi.

The two Emdebian distributions will be:

Emdebian Grip 1.0 (lenny)

A small Debian-compatible Emdebian installation

Full release title:

    Emdebian GNU/Linux Grip 1.0 (based on Debian GNU/Linux 5.0 "lenny"). 

Short release name: 

    Emdebian Grip 1.0 (lenny)

Common release names:

    Emdebian Grip or Grip (lenny)

Architectures: i386, amd64, powerpc, arm, armel, mips and mipsel

Emdebian Grip explicitly supports mixing Debian and Emdebian and that is how a Debian package could end up depending on a package from Emdebian Grip - this is not expected to be a problem because Grip packages are binary-compatible with the Debian version, just with some files removed from the package. (i.e. Grip is post-processed, not recompiled.) Grip typically comes in at ~600Mb for a full XFCE desktop and uses the Lenny debian-installer images. (Grip base system ~250Mb.) I'm currently running Emdebian Grip on my Acer Aspire1.

More information: http://www.emdebian.org/grip/

Emdebian Crush 1.0 (lenny)

The smallest Emdebian installation - cross-built from Debian sources.

Full release title:

    Emdebian GNU/Linux Crush 1.0 (based on Debian GNU/Linux 5.0 "lenny"). 

Short release name:

    Emdebian Crush 1.0 (lenny)

Common release names:

    Emdebian Crush or Crush (lenny) 

Architectures: arm only 

More information: http://www.emdebian.org/crush/

Crush is the cross-built distribution from Emdebian - significant functional changes exist compared to the Debian package, libraries have been recompiled with options turned off and functionality removed etc. and Crush has dropped support for python or perl, and uses a modified, more recent version of busybox instead of coreutils. Crush is the hardest distribution to install, maintain and update and requires extensive customisation for particular machines with the benefit that it is an ultimately flexible Debian where the base system (equivalent to a debootstrap in Debian) can fit into 24Mb installed and a GPE GUI in 75Mb. uClibc support is expected in Crush 2.0 (squeeze), allowing sizes to shrink by another 10Mb or so. I'm currently running Emdebian Crush on my balloon3.

Some stuff I want to reminder for next year s FOSDEM:

• Carry a power bar with at least 3 outlets. Power plugs are a limited resource. With a power bar at FOSDEM you always will be able to get power for your laptop/gadgets and make new friends. All at the same time!
• Make a backup schedule, in case the talk you wanted to attend run out of space.
• H agen-Dazs next to LUIZA/LOUISE metro station is good for breakfast and dessert. And there is wifi!

I already wrote two days ago about it, but the problem then was to find a way of unique identifiers for files. Using md5sum and openssl sha1 seemed to deliver multiple files for each hash, which confused me.
A closer look later revealed that there were in fact multiple times the same file, so the same hash is of course correct.

Anywa, I'm now using the following two scripts to create an index file about the content of my filesystems and to be able to restore files from lost+found.





It's actually working for me, but use them at your own risk - as always! ;)

Anyway, there are some drawbacks with these versions:

1. it is dog slow. Grepping through 75M of ls-md5sum-files.txt for each file found in lost+found is CPU-intensive and slow.


2. files with spaces in their names are not handled well. In fact they are not handled properly at all. You'll get "file not found" errors for each filename with spaces.


3. currently grep -m 1 stops grepping when the first match was found.

If anyone has an idea how to speed up the script or improve it otherwise, please let me know! I already though by myself to remove found files from ls-md5sum-files.txt to reduce the workload on grepping every time all of the 75M and to work around the last point from above. But rewriting the file everytime a fiel was found and moved will put extra workload on disk I/O, which - of course - will get better over time because the file gets smaller. Another idea was to store the file within an array in memory, but then I would prefer to use a Python script for this purpose.

So, when you have some ideas, tips or improvemts, please comment!

I was at this event back in November and they ve just emailed me this week to point out the speeches and some recordings are now available online. The appointed Regional Development Agency is getting more powerful as our indirectly-elected South West Regional Assembly is phased out, so if you re based in SW England, you may find their current views affect a lot of your daily life over the next few years. After the meeting, I passed on a few comments about how Business Link is failing to support cooperatives and I was asked for numbers, but I don t think I have them yet. I m still following this up and will post about it again later.