We have a problem with our tools in Debian, and it's this: Above the core tools in dpkg-dev, and the nearly core tools in debhelper and devscripts, and the many different -- but all slowly converging -- revision control systems, there is the potential for infinite cruft to pollute the source package. Note that one developer's cruft is another developer's use of an excellent tool. If you don't believe that, you haven't read a lot of crufy upstream build systems, because Debian isn't the only project with this problem. The source of this cruft is a near-constant stream of new tools that are each developed in good faith by someone who needs that tool, and then adopted and used in packages of a generally small percentage of developers, who think that tool might be a good fit for their problems. The tool isn't yet suitable for everyone to use, and most of these tools never become suitable for everyone, because

1. making the leap from a special-purpose, poorly-designed hack to a general-purpose tool is hard
2. getting the project to standardise on a tool is hard
3. a tool often doesn't become general purpose until enough people use it, no matter how well designed it is to start out with

So after a while, a better, or at least different, solution to some of the same problems will come along, and some generally small percentage of developers will choose to use it in their source packages. Meanwhile, the developers who chose the old thing will be set in their ways and not want to use the new thing, and generally cannot be budged to stop using the old thing by any amount of argument. Which in a sense is normal, and fine, until you have to collaborate with them. I don't care if someone I'm collaborating with uses emacs to my vim, but I do care if they use cdbs to my debhelper. I care because their tool-choice encrufts the source that I'm supposed to be working on. Once a significant percentage of all the source packages in Debian are encrufted for a wide array of different tools, it will become harder and harder to work with Debian's source packages. We're already seeing this happen. Another way of looking at it is that we've invented dozens of source package formats that all work differently, aside from a small shared core, and we expect our developers to be able to use all of them. At this point I see this as a huge, potentially killer problem, that is making Debian development become worse with every passing year. But I have no real solution. Obviously pointing out that tools are obsoleted or bad doesn't work; we still have dozens of packages using yada, which everyone agrees is horrible. That doesn't bode well, does it? One partial solution is to design a category killer, and get it embedded in acknowledged core tools. That's what I have tried, and so far, failed, to do with an evolutionary change to the Debian source package format, which I'd hope would give people a reason to stop using dpatch, dbs, and their ilk. As noted, this approach is Hard.

---

For now, I have no interest in being on a team that requires I use any of the following things:

• dpatch
• dbs
• quilt
• Any similar system that is used to move all patches to under the debian/ directory.
• Any system that nests the actual original upstream .tar.gz inside an .orig.tar.gz.
• yada
• cdbs
• Any similar system that obfuscates debian/rules.
• Any special script that is required to be used to build a package as a wrapper around dpkg-buildpackage.

This means that I can't be on the security or release teams, and even teams like the perl team are getting sticky to be on.

---

PS, this doesn't mean I dislike quilt. I dislike quilt encrufting Debian source packages, which is entirely different. PPS, In case you're wondering why debhelper gets a pass, it's because it's gone through the three numbered steps above to become a standard, general purpose tool, and has no serious competators. (Though it does have parasites, like cdbs.)

Chris Lamb has suggested storing a GPG key on a RAID-5 device [1]. The idea is that it can be stored on several physical block devices such that losing just one will not give the key to an attacker. A default GPG secret key will be about 1.2K in size (3 sectors of a hard drive). A minimal key (with 1024 bit DSA keypair) will be 0.9K (2 sectors). I expect that very few people have secret keys greater than 4K in size. To create a software RAID-5 device under Linux the tool mdadm is used. The default chunk size is 64K, so a 1.2K file will probably be on a single device. If you use the -c option of mdadm to specify a smaller chunk size then the smallest that is accepted is 4K which still permits a default GPG secret key to be on a single device. The Ext2 and Ext3 filesystems will always align such file data to a 4K boundary unless the device is smaller than a certain size (or a special mkfs option is used) to give a 1K block size for the filesystem. If an Ext2 or Ext3 filesystem is used with 1K blocks then you might get a 1.2K file split across multiple 4K RAID chunks. So storing a GPG key on RAID-5 won’t prevent an attacker who steals one part from getting all the most valuable data. It will make it more inconvenient for them (if you are lucky it will prevent them getting all the data) and it will also make it difficult for the owner of the GPG key to determine which of the devices actually contains the secret data (probably all of them will end up having copies if you edit the secret key). Now if RAID-5 did allow chunk sizes that were smaller than the secret key or if you have Ext2/3 with 1K blocks and get lucky with file fragmentation then the problem still isn’t solved. The reason is that you don’t require N-1 of the N disks to get some useful data out of a RAID-5 array (run strings on one element of a RAID-5 array to verify this). A single disk on it’s own will have some data that can be used, as file(1) can recognise GPG secret keys so you could just copy 1K chunks of data into separate files and use file to determine which (if any) has the data in question. The really exciting question is, what do you get if you have the first 1K of a 1.2K GPG secret key? If it could be proved that the first 1K does not give an attacker any advantage then this might provide some benefit. But I think that this is a very dubious assumption, when dealing with such things it’s best to assume the worst. Assume that an attacker who has 1K out of 1.2K of secret data has the ability to reconstruct the rest. In that case the Linux kernel RAID-5 provides no benefit for storing a GPG secret key. Just try not to get your devices that contain secret data stolen. Maybe a watch with a built-in USB device is a good idea. Thieves seem to be targetting mobile phones instead of watches nowadays and something that’s strapped to your wrist is difficult to lose.

• [1] http://chris-lamb.co.uk/2008/01/23/xorly-losing-your-gpg-private-key-safely/

Share This

It seems to me that the Asus EeePC (a $AU499 ultra-light laptop with only flash storage) would make a decent router. Often full desktop PCs are used as routers because they run the most common software and have standard interfaces. There have been dedicated router devices with flash for a long time, but without the ability to connect a standard monitor and keyboard they were always more difficult to manage than general purpose PCs. Also dedicated routers have limited RAM and storage which often does not permit running a standard OS. According to the best review I could find [1] EeePC has a minimum of 256M of RAM, a Celeron-M CPU (32bit Intel), and a minimum of 2G of flash storage. This hardware is more than adequate to run most server software that you might want to run (my current router/firewall/server has 192M of RAM). It could run a web server, a mail server, or any other general server stuff. It comes pre-loaded with a modified version of Debian so you get all the Debian software (which incidentally means more pre-packaged software than is available for any other distribution). Bigger versions are common, I believe that the $AU499 version has 512M of RAM and 4G of flash - I’m not sure that I could even obtain a lesser EeePC in Australia. The up-side of flash is that it doesn’t take much power as having a low power device in whatever confined space ends up housing your router is a good thing (the EeePC is listed as using less than 20W no matter what the load and idling at as little as 14W) and that it doesn’t tend to break when dropped or have any moving parts to wear out. The down-side of flash is that a sufficient number of writes will destroy it. Obviously swap is not a suitable use for a flash storage device. But a small mail server (suitable for the needs of a home or a small office) should be fine with it. Squid is commonly run on router devices, to run it on an EeePC I would be inclined to buy 1G USB flash device for the cache, then if Squid’s use destroyed the flash storage it would be easy to spend $20 and buy another. The EeePC has three USB ports and a built-in Ethernet port. I believe that the minimum number of Ethernet ports for a firewall is three, this means either one for the uplink, one for the DMZ, and one for your LAN, or two for uplinks (with a redundant uplink) and one for the LAN. The three USB ports allow using two USB Ethernet devices to provide the minimum three Ethernet ports and one for USB flash storage. One notable advantage of using a laptop as a server is the built-in UPS (the laptop battery). Many people have put old laptops into service as servers for this reason, but usually an old battery gives no more than about 30 minutes of power, while a new EeePC should be able to last for more than 3 hours without mains power. Using a second-hand laptop as a server is usually not viable in a corporate environment as laptops are all different. Repairing an old desktop PC is easy, repairing an old laptop is unreasonably difficult and often more expensive than replacing it. The low price of the EeePC makes it easily affordable (cheaper than some of the desktop machines that might be used for such a purpose) and the fact that it is purchased new at such a price means that you get warranty support etc. It seems to me that a significant disadvantage of using an EeePC (or anything other than a real server) for a server task is that it lacks ECC RAM [2], but as I’m not aware of any device sold for the purpose of running as a low-end router or sold at a price-point such that it could be used as a low-end router which has ECC RAM I guess that’s not a big disadvantage for that purpose. But the lack of ECC RAM and the lack of useful support for RAID does make it a little less suitable for use as a mail server. Finally if you are going to run a VPN then it would be handy to be able to secure the hardware against malicious activity when the office is closed. An EeePC will fit nicely in most safes… Please let me know what you think about this idea. I’ll probably start installing some such machines for clients in the near future if ASUS can keep up with the demand.

• [1] http://www.hothardware.com/articles/Asus_Eee_PC_Full_Retail_Review_Showcase/?page=1


• [2] http://etbe.coker.com.au/2007/07/15/desktop-machines-and-ecc-ram/

Share This

pam-hooks - PAM module to execute login/logout actions Yesterday I've finally published a PAM module I wrote a while ago to implement an apparently trivial need which I haven't found implemented elsewhere. What I wanted to do was simply to be able to execute hook scripts upon an user is entering or leaving a PAM session. Actually, my use case is to clean the home directory of a user upon its GDM logout (and to be sure also just after he logs in) as such a user is a "dummy" one, reused by several people in a stripped down kiosk-like environment. When I did my googling about this I was able to find only Enrique Oca a's PAM preprofile which can force script execution at authentication time, but nothing for the logout. So I wrote my own toy module, generalizing a bit the API so that invoked scripts are informed about whether a login or logout is in process. The result is pam-hooks. It is not in Debian since I do not know how many people can be interested in such a thing; in case you are just let me know. Dear lazyweb, comments, code auditing, and pointers to similar stuff I've overlooked are really welcome.

I have just uploaded javatools 0.5 to unstable and it is currently waiting in NEW. Anyone wishing to try it out earlier can find source and packages (it's arch: all) at http://www.srcf.ucam.org/~mjj29/javatools/ . Javatools replaces the existing jarwrapper package and also contains programs to help packagers in creating packages for Java programs and libraries. Packaging tools The javahelper package consists of several small programs which make packaging Java programs and libraries easier. They are generally designed to work in the same fashion as the debhelper programs, but start with the jh_ prefix. All of the programs have their command line arguments documented in manpages. jh_build Many Java programs and libraries are distributed without sane build systems. jh_build provides a simple interface for building Java source code into Jars, including setting the appropriate entries in the manifest. In almost all cases all that needs to be done to call jh_build is to set JAVA_HOME and CLASSPATH and then call jh_build with the name of the jar and the directory containing the source.

JAVA_HOME=/usr/lib/jvm/java-gcj
CLASSPATH=/usr/share/java/esd.jar:/usr/share/java/jsch.jar
jh_build weirdx.jar src
   

This command will compile all the Java files under src , set the classpath in the manifest and build it all into weirdx.jar. A couple of other options are worth mentioning. If this jar contains an application rather than a library then the -m or --main option can be used to set the Main-Class attribute in the manifest which will allow the resulting jar file to be be executed jh_build also provides a --clean parameter which should be called in the clean target of debian/rules . jh_libs For library packages Debian Java policy currently requires that the libraries be installed to /usr/share/java in a versioned format and with an unversioned symlink. jh_libs will take a jar and correctly install it. As with debhelper programs, this can either take a jar as a parameter, or read a list of jars from a file in the Debian directory. It also follows the -p , -i and -s semantics of debhelper for selecting which packages to install the jar to. When operating on a package, jh_libs will read the list of library jars from debian/package.jlibs or debian/jlibs . The jlibs file is a list of jars to install, one per line, and works exactly the same as listing them on the command line. Each jar is installed to debian/package/usr/share/java/ in the appropriate versioned and unversioned forms. jh_depends jh_depends works like dpkg-shlibdeps, but for jar files. For each jar in the package it takes the jars on which it depends and finds the packages to which they belong. These are included in the debhelper substvars as $ java:Depends . The control file can then just list that variable which is filled in automatically. This is done by reading the Class-Path attribute from the manifest of each jar. Jar files should include this attribute to prevent applications which use them from needing a full recursive classpath in their startup scripts and to prevent unneccessary transitions when the library changes its dependencies. If the package is not built with jh_build and the upstream build system doesn't set it correctly then jh_manifest can be used to fix this. If the application uses executable jars (see Runtime support below) then jh_depends will also add the appropriate depends on jarwrapper and the correct Java runtime. jh_manifest Many upstream build systems do not set the Class-Path attribute in the jars they create. This leads to several unwanted problems, such as expanding the classpath which applications have to use and introducing unneccessary transitions. They also may not set the Main-Class attribute. Both of these are required for running jars with the -jar parameter. jh_manifest can fix the manifest files of jars. It can either read from a manifest file in the Debian directory or run in a mode which updates all the jars with the CLASSPATH environment variable. The manifest files can either be debian/package.manifest or debian/manifest . The format of this file is a list of jars and indented below each one a list of manifest elements to set:

usr/share/weirdx/weirdx.jar:
 Main-Class: com.jcraft.weirdx.WeirdX
 Debian-Java-Home: /usr/lib/jvm/java-gcj
   

jh_exec The Runtime support section below describes running executable jars directly. jh_exec will scan package directories for jars in the paths, or symlinks to jar from the paths, and ensure that they have been set executable if necessary. jh_makepkg jh_makepkg will create template Debian packages for Java programs and libraries similar to dh-make . It should be run in the source directory and it will create the orig.tar.gz and most of the files in the Debian directory, which need only small changes neccessary to build the package. java-propose-classpath Some upstreams have complicated classpaths which may not be obvious to the packager when using jh_manifest to set the Class-Path attribute. java-propose-classpath will unpack a jar and look at the symbols imported to the class files, then scan all the jars in /usr/share/java . This shouldn't be run in the build since it is slow, and there may be ambiguities that the packager must resolve. It is still very useful for the packager as most of the time it will get it right automatically. Runtime support Javatools also provides some runtime support. Unlike compiled programs, or purely interpreted programs with hash-bang lines, Java programs cannot be directly executed. Many upstreams expect them to be run using java -jar jarname or java classname . This is not generally acceptible in systems which expect to just be able to run the command or launch it from a menu. As a result, many packagers are writing wrapper scripts which just call java with the correct classpath, jar and main class. jarwrapper There is an alternative to wrapper scripts, however. The binfmt_misc kernel module allows the kernel to call out to a program in userspace to execute specific types of file. jarwrapper registers itself as a handler for executable jars. This is done by reading values from the manifest file. In order for executable jars to work the following attributes must or may be defined in the manifest. These attributes can be set using jh_build and jh_manifest .

• Main-Class: The name of the class to be run when the application starts. (REQUIRED)
• Class-Path: The path to all the jar files on which this jar depends. (REQUIRED unless empty)
• Debian-Java-Home: A Debian-specific property if this application depends on a specific runtime. Specify the path to the runtime which should be used. (OPTIONAL)
• Debian-Java-Parameters: A Debian-specific property if this application needs extra options to the JVM. (OPTIONAL)

Putting it together This section shows the debian packaging generated by jh_makepkg for an application and a library using jh_build . Sample Library Packaging debian/control

Source: jsch
Section: libs
Priority: optional
Maintainer: Matthew Johnson 
Build-Depends: debhelper (>= 5), javahelper, java-gcj-compat-dev, libzlib-java
Standards-Version: 3.7.3
Homepage: http://www.jcraft.com/jsch/
Package: libjsch-java
Architecture: all
Depends: $ java:Depends , $ misc:Depends 
Description: Java secure channel
 JSch is a pure Java implementation of SSH2. JSch allows you to
 connect to an sshd server and use port forwarding, X11 forwarding,
 file transfer, etc., and you can integrate its functionality
 into your own Java programs. JSch is licensed under a BSD style
 license.
   

debian/rules

#!/usr/bin/make -f
export JAVA_HOME=/usr/lib/jvm/java-gcj
export CLASSPATH=/usr/share/java/zlib.jar
build: build-stamp
build-stamp:
	dh_testdir
	jh_build jsch.jar src
	touch $@
clean:
	dh_testdir
	dh_testroot
	jh_build --clean
	dh_clean
	rm -f build-stamp jsch.jar
install: build
	dh_testdir
	dh_testroot
	dh_clean -k
	dh_installdirs
binary-arch: build install
	# Java packages are arch: all, nothing to do here
binary-indep: build install
	# Create the package here
	dh_testdir
	dh_testroot
	dh_clean -k
	dh_install -i
	dh_installdocs -i
	dh_installchangelogs -i
	dh_javadoc -i --sourcedir=src 
	jh_libs -i
	jh_depends -i
	dh_compress -i
	dh_fixperms -i
	dh_installdeb -i
	dh_gencontrol -i
	dh_md5sums -i
	dh_builddeb -i
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install
   

debian/libjsch-java.jlibs

jsch.jar
   

Sample Application Packaging debian/control

Source: salliere
Section: misc
Priority: optional
Maintainer: Matthew Johnson 
Build-Depends: debhelper (>= 5), java-gcj-compat-dev, fastjar, 
               libmatthew-debug-java, libcsv-java,
               libitext-java, javahelper
Standards-Version: 3.7.3
Package: salliere
Architecture: all
Depends: $ java:Depends , $ misc:Depends 
Description: Short Description
 Long Description
   

debian/rules

#!/usr/bin/make -f
export JAVA_HOME=/usr/lib/jvm/java-gcj
export CLASSPATH=/usr/share/java/csv.jar:/usr/share/java/debug-disable.jar:/usr/share/java/itext.jar
build: build-stamp
build-stamp:
   dh_testdir
   # Build the package
   jh_build salliere.jar src
   touch $@
clean:
   dh_testdir
   dh_testroot
   jh_build --clean
   dh_clean
   rm -f build-stamp salliere.jar
install: build
   dh_testdir
   dh_testroot
   dh_clean -k
   dh_installdirs
binary-arch: build install
   # Java packages are arch: all, nothing to do here
binary-indep: build install
   # Create the package here
   dh_testdir
   dh_testroot
   dh_clean -k
   dh_install -i
   dh_installdocs -i
   dh_installchangelogs -i
   jh_manifest -i
   dh_link -i
   jh_exec -i
   jh_depends -i
   dh_compress -i
   dh_fixperms -i
   dh_installdeb -i
   dh_gencontrol -i
   dh_md5sums -i
   dh_builddeb -i
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install
   

debian/salliere.install

salliere.jar usr/share/salliere
   

debian/salliere.links

usr/share/salliere/salliere.jar usr/bin
   

In just over a month (1 month and 1 day, to be precise), it's FOSDEM again. The Debian Developers Room schedule is almost complete, and some interesting things are being published around it. Such as the pre-FOSDEM beer event. In previous years, this always happened at the "Le Roi d'Espagne", a bar at Grand Place in Brussels. This was a nice place for many years, because it's easily found, and they have this backroom where quite a lot of people would fit in. Unfortunately, "quite a lot" does not equal "a huge number", with the amount of people going to the pre-FOSDEM beer event more and more approaching the latter than the former as the years go by. Last year, it finally became too crowded, and it was decided that the pre-FOSDEM beer event would change bars this year. Which has now happened. This year, the pre-FOSDEM beer event will be at the Delirium Caf , which is not at the Grand Place anymore, but just 100m away from it; the FOSDEM website has more information. A nice feature of the Delirium Caf , besides the fact that they are much larger, is the huge amount of different beers they have. Over 2000 of them, which you can query online!. And that's not even considering the soft drinks or waters or whatever, which they also have on their menu. Another novelty this year is the streaming; the main tracks that will be held in Janson will be streamed out of the event, and the Debian video team is also planning to do some streaming. Meaning, even if you can't make it to FOSDEM, you'll still be able to follow some of it. You won't be able to follow everything, especially not the hallway track which at FOSDEM is a very important one; but at least you'll be able to sample some bits, which is nice. Other than that, not much will change. There'll be a key signing party, organized by yours truly. There'll be Lightning talks, there'll be the Main track, and there'll be a number of Developer rooms, including the Debian one—which, occasionally, is also organized by yours truly. This conference has always been my favourite (even though I haven't been to many conferences besides FOSDEM); I've never missed even one edition ever since the very first one back in 2001 (when it was still called OSDEM). And since a few years, I've also been offering crashing space at our office, for international geeks who don't mind roughing it a bit (it's an office, there no shower, there's only floor space). This year, perhaps I haven't been spamming enough for that, but for now I only have two people who're interested in sleeping over (and they're not even sure); if you're going to FOSDEM and still need a place to sleep, you're (probably ;-) welcome. Send me an email. On the Debian front, things are going well, for the most part. The list of speakers for the Devroom is nearing completion, leaving me with little more to do than to start assigning times. We've been assigned a booth as well, but there I still need to figure out how to organize it, and what to do with it. There will of course be the regular UK T-shirts, and probably some other merchandizing, but I also want something involving some computer device. We've had this d-i "babelbox" installation running a few times now, which was nice; but I do think we need some variation, too. The only problem with that approach is that I don't really know what that variation could be. Suggestions are welcome! And so time goes on, and FOSDEM draws nearer. At some point it'll eventually happen, and then it will be over before one can say "blueberry pie". Sometimes I wonder whether all these months of preparation are actually worth it. But when FOSDEM is actually here, I'm sure I'll find that it is, indeed, worth it...

Julien Goodwin asks whether an insecure platform can perform secure computation [1]. My immediate reaction was to recall Charles Babbage’s quote On two occasions I have been asked, ”Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” […] I am not able rightly to comprehend the kind of confusion of ideas that could provoke such a question [2]. However on careful reading of Julien’s post it seems that he is most interested in the integrity of the computations rather than the secrecy. He suggests the possibility of performing the computation twice and comparing the results. Of course the issue to consider is whether both computations could be subverted. It seems most likely that if you are using someone else’s computation cluster for the calculations then performing the same calculation on two nodes of that cluster will give the same result both times (whether it’s right or wrong). If there was a computation that would get a result that can be verified with little computation then it would be an easy problem to solve. For example if I wanted to brute-force a passphrase for a GPG key then I could try all combinations that were known to be possible, if one was flagged as correct then in a millisecond I could verify it. If none of the possibilities were listed as correct then I could assume that the process was broken in some way. The problem with this is that such a passphrase can have arbitrary length (I know someone who uses more than 50 characters). So if I used a brute-force attack on passwords of up to 9 characters that doesn’t exclude a 10 character password. Probably the best potential use for insecure systems is for analysing large data sets. There have been several projects to harness unused computation resources to perform various large calculations (protein folding and SETI are two examples). Most such projects use closed-source programs because the people who run the contests are afraid of cheats who modify their programs to merely say “no” repeatedly and quickly. Of course this wouldn’t be a problem if they didn’t have a high-score table, and disassembling the program to hack the protocol can’t be that difficult (consider the work invested in reverse engineering protocols such as SMB which are much more complex). It would probably be reasonably to randomly send batches of work to two machines in different regions for such large-scale public computation projects. Finally if you want to perform calculations on secret data on someone else’s hardware then you may have lost before you even start.

• [1] http://laptop006.livejournal.com/39799.html


• [2] http://en.wikipedia.org/wiki/Garbage_In,_Garbage_Out

Share This

This is not about any particular project, but more a generic thought. When should be something considered to be stable enough to be released as 1.0? Over ages I started several projects which are in different quality right now and this is maybe not completely related to version they use. Let's take one of older ones - Wammu. It was started long time ago, it really does not get any major code changes for several years and I still don't want to make 1.0 release there. The reason is that I think that many things could be done better there. However there are quite lot of users which use it and they probably consider it stable enough :-). But they will have to live with 0.x versions as I do not plan 1.0 at all for now even if it maybe deserves it :-). Different case is Ukolovnik. It does not have tons of features, but it's enough for me and it will be 1.0 soon. I have features to add, but I don't thing that RPC interface has to be in 1.0, it can be just thing added later.

Joey, just don't delay your releases waiting for incoming translations. Gettext is anyway smart enough to not use translations when they're non-existing (aha) of fuzzy. So, an incomplete translation for a program will just end up in a partially translated program. That's actually the case for *many* localized software, including the big ones. I suggest that you apply such a schedule:

• Plan a release
• Send call for translations (hint: podebconf-report-po is your friend even for non debconf translations...see its man page) and give translators a deadline. The deadline has to be reasonable and leave some room for translation proofreading. Most often, when few strings are impacted (say not more than 20 but, again, that's hard to judge)
• When the deadline is reached, upload release with what you have
• A few days weeks later, eventually release a new version with late translations

But, as you suspected, releasing without synchronised translations is the better choice....as long as you care abou tsending call for updates when needed. BTW, if you need some help to coordinate incoming translations for apt-key, maybe ask on debian-i18n and someone will eventually pop up (hopefully, not /me).

Holger reported in his blog that he uploaded a backport of the AMD Geode GX/LX X.org module to Debian. He also points out that what he has backported is from a non-Debian source. In case it wasn't obvious to him, there are good reasons why the official Debian module is not from the OLPC branch: the OLPC branch includes OLPC-only code that breaks operation for non-OLPC hardware. This means that the backport package is completely useless for the vast majority of GX/LX hardware on the market. Well done, Holger!

Things have been rather hectic lately, so I haven't found much time to blog. Here's why: DBE62 The Gigabit Ethernet version of our thin client took more time to produce than I expected, for a number of reasons mostly related to a few improvements we decided to squeeze into the design at the last minute. However, today, we finally reached a point where LinuxBIOS runs as well as it did on our previous DBE61 model and where we no longer need any DOS tool to flash the MAC address into the VIA velocity Gigabit chip we selected. Hurray! Production will only commence in one month, but I'm already excited by the new model's potential, both as a thin client and as an embedded platform. Another good thing is that, thanks to Ubuntu developer Scott Balneaves, we managed to get all the necessary tools to support thin clients based on LinuxBIOS into LTSP, so our Etherboot model works out of the box on Ubuntu, since Gutsy. Hurray! There is one remaining issue related to recent changes in X.org core functionalities that make the AMD driver we need unstable but, again, various AMD, Debian and Ubuntu developers are looking into fixing this, so we should soon have spotless Geode support into Debian and Ubuntu again. T rkiye I visited Turkey twice over the last few months, because I'm putting together a pilot project to better promote the Estonian high-tech sector abroad, in collaboration with the Estonian government. I have to say that the more I visit Turkey, the more I like the place and the more understand why these people see themselves as Europeans because, you know what? They are: practically every significant civilization and religion that is at the core of European culture had major events taking place in in Anatolia or Thrace and, also, a devastatingly huge percentage of the consumer goods sold in Europe are designed and manufactured in Turkey. Learning the rudiments of Turkish has also proven to be a lot of fun. While I'm nowhere near as fluent in Turkish as in Finnish or even in Estonian, the learning curve isn't as steep as I initially expected: Altaic and Ugric languages share a surprising amount of grammatical concepts, while Turkish itself borrowed a lot of vocabulary from French, because the founder of modern Turkey, Atat rk, was very fond of the language. I'll venture that proximity with nearby Middle-Eastern countries that were formerly under French influence has something to do with it too. Identity crisis To me, the most challenging part of these business missions abroad is to represent a whole economic sector from a country of which I'm not a citizen or even a resident. Case in point: Being invited to dinner by a Turkish investor, I noticed the waiter asking my host where his foreign guest might be from. A few minutes later, as the waiter put down a gigantic pita bread with the word "Estonia" spelled in roasted sesame seeds, my host asked, reading my business card:

• Actually, your name doesn't sound Estonian. France?
• Qu bec.
• And your mobile number ... 358 ... is that Finland?
• Yup. I've been living there for the past 10 years.
• Ah! So you don't live in Tallinn?
• Nope. Helsinki.

Looking at the waiter and pointing at the gigantic pita, he continues:

• Actually, make that Canada ... no, Finland ... Ah, sorry, never mind. Just keep it as Estonia.

Honestly, trying to keep a straight face while saying "We" about a country of which I'm not a citizen and where I don't even reside becomes unbearable. At some point, some European bureaucrats will have to admit that I need a new citizenship, to reduce the confusion and to let me find myself a proper national identity again; the sooner, the better. Besides, the absurdity of the situation keeps on jumping at everyone's face: during the second mission to Turkey, I kept on bumping into Finnish diplomats who took personal offense at me for living in their country and yet representing the interests of a competing, neighboring country. If you ask me, I cannot entirely blame them for it. However, as far as I'm concerned, I've done my homeworks: I've been here 10 years, I speak the language and I don't have a criminal record. Given this, you'd think that acquiring citizenship would be a mere formality, but the Ulkomaalaisvirasto doesn't see it that way. If you ask me, this country's very first Minister of Immigration, Mrs.Astrid Thors, ought to unilaterally grant citizenship to anyone who's lived here for at least 5 years, just for the asking, regardless of what circumstances brought them here or of what absurd decisions the Ulkomaalaisvirasto might have previously made on their residence permit status. Doing this would go a long way towards undoing the mess of her predecessors at the Ministry of Interior and it would speak volumes about how much Finnish society has evolved from the days when any foreigner was a commie they had to push over the Eastern border.

Update: Why don't I learn my lesson and stop working too late? Making a fool of myself in public isn't something to be proud of.

Ignore this post if you're seeing it for the first time.

---

Martin, David, this script is broken. When trying to set kernel parameters, there should be a new line, it shouldn't be explicitly removed. I know it looks weird, but this seems to be proven by this output:

kinder:/etc/init.d# ./params4flash start
kinder:/etc/init.d# cat params4flash
#! /bin/sh

exit 0

PATH=/sbin:/bin

# Max time to wait for writeout
MAX_AGE=120
CENT_AGE=$((100 * $MAX_AGE))
# Max percent of mem to use for dirty pages
DRATIO=10
# Once we write, do so until this many percent of mem is still in use
DBRATIO=1

case "$1" in
start)
   echo -n 0         >> /proc/sys/vm/swappiness
   echo -n $MAX_AGE  >> /proc/sys/vm/laptop_mode
   echo -n $CENT_AGE >> /proc/sys/vm/dirty_writeback_centisecs
   echo -n $CENT_AGE >> /proc/sys/vm/dirty_expire_centisecs
   echo -n $DRATIO   >> /proc/sys/vm/dirty_ratio
   echo -n $DBRATIO  >> /proc/sys/vm/dirty_background_ratio
   ;;
restart reload force-reload)
   echo "Error: argument '$1' not supported" >&2
   exit 3
   ;;
stop)
   # No-op
   ;;
*)
   echo "Usage: $0 start stop" >&2
   exit 3
   ;;
esac
exit 0
kinder:/etc/init.d# cat /proc/sys/vm/swappiness
60

The bad thing with fixing build failures with dash is that there are still a lot of open bugs. (Remember, the 0-day NMU policy applies to those, so it’s a good opportunity to improve your NMU karma. And I will sponsor your NMUs if you can’t upload!). The good thing is that you sometimes run into funny code, like:
clean:
    dh_testdir
    dh_testroot
    pushd docs ; $(MAKE) distclean true ; popd Since pushd/popd is a bashism, the Ubuntu patch changed this to:
clean:
    dh_testdir
    dh_testroot
    cd docs ; $(MAKE) distclean true ; cd $(CURDIR) Which works, but is … interesting? :-)

I have decided to run a contest for security related blog posts that appear on Planet Linux Conf Au [1]. That Planet is for people who are attending Linux Conf Au [2], and the prize (or prizes) will be given out at the conference. The aim will be posts on the topic of computer security from people who are not experts. Anyone who has been employed as a security consultant or developer of security software or who has spoken at a conference such as LCA on a topic related to security can enter but will only be eligible for an honourable mention. Any such expert who enters for an honourable mention MUST note on their entry that they are not eligible for a prize to avoid any possible confusion. Only blog posts of a positive nature will be well regarded by the judges. Negative reviews are only acceptable if they have positive suggestions for improvement and/or bug reports linked from them. You may submit a series of posts on a theme, and multiple posts on different security issues will help an entry - we will judge the contributions of the person not a single post. The prize pool is currently $50, which I hope to expand - but such expansion depends in part on the quality and quantity of early entries, so if some good entries are submitted soon then there will be more and bigger prizes. Currently the prize pool comes from the pockets of me and Casey, commercial sponsorship will be accepted and may increase the prize pool significantly. The duration of the contest is from this moment until at least lunch-time on Friday the 1st of February. We may extend the contest until Friday night and announce the winner(s) on Saturday - but at this time you should not count on such an extension and plan to have your entry or entries in by mid-day on Friday the 1st of Feb (Australian eastern daylight savings time). So far of the people I have invited to join the judging panel only Casey Schaufler has accepted. Casey and I will consider offers to assist in judging from people who have a combination of security and blogging experience that is significant, but note that as of this time all prize money comes from the judges… When you write a post that you wish to submit for the contest please comment on this post with the URL to make sure that the judges don’t miss it. Entries submitted on the last day may need some other form of notification, I will write a future post which clarifies this issue. Some issues related to selecting the winners have yet to be determined, I will write future posts with more information. But please don’t hesitate to enter now, well written posts that have a positive tone are what you need. Also entering quickly will help increase the prize pool, more prizes means a greater chance that you will win one! One thing I am considering is how to manage commercial sponsorship if it is offered. One possibility I am considering is allowing a sponsor to declare that half of the money they pay will be used as prizes for entries that relate to their product. That would give an extra incentive for people to blog about topics related to the sponsor but still give extra prize money for other topics. In that situation the relation between the sponsor’s product and the prize winning entry or entries would be liberal, so a post about standard Unix security features would be eligible for prize money from any commercial Linux distribution. Finally you must have your own individual blog to enter the contest. Guest-posts on other people’s blogs or group efforts are not eligible for anything other than an honourable mention.

• [1] http://planet.linux.org.au/lca2008.html


• [2] http://linux.conf.au/

Share This

Although I lot of people have been lauding the Kindle, I recently decided to go with the Sony PRS-505 instead. Yes, the Kindle has built-in EVDO access, and the ability to buy books without a computer, or even browse the web; and yes, the Sony has once again demonstrated it can’t create a compelling 21st century computer application to save its life. However, it had a few things that at least for me, made a better choice for me than the Kindle:

1. The Sony is thinner — I want to be able to slip it into my laptop case and have it take the absolute minimum amount of space.
2. The Sony simply looks much more elegant than the Kindle; steel with a leather cover simply looks a lot better than white, cheasy plastic.
3. I’m not interested in buying a lot of DRM’ed ebooks; ergo, I won’t be buying may books from either Sony or Amazon’s web sites. It is highly likely that within 2 years I will be buying a more advanced eBook reader, possibly one with color, and I don’t want to be locked into a single format where I have to go and repurchase all of my books just because some the latest and greatest eBook reader uses an incompatible DRM technology from whatever Sony or Amazon has used.
4. The Sony is $100 cheaper. Given that something better will be available within 2-3 years at the very most, and possibly sooner, I’m just not interested in spending $400 on a first generation prototype.
5. Perhaps the most important, the Sony has the really, really good open source support. Kovid Goyal’s libprs500 project supports the Sony PRS-500 and PRS-505, and has very good version tools, allowing people to convert eBooks previously stored in HTML, PDF, TXT, Microsoft Reader (.lit), IDPF/Open eBook (.epub) into Sony’s format. And with a little bit of work, it does a very, very good job with the conversion. Better yet, its ability to convert multiple HTML pages into a single eBook, with credible table of contents, means that libprs500 can pull down the New York Times, the Economist, etc., automatically format it into a single eBook which you can save onto your Sony Reader, and then read it while you are on the airplane. No muss, no fuss. I can also take various books that are available on the web as HTML and also convert them into an eBook which can be used by the Sony Reader very easily.

This last point is I believe one of the best reasons why the Sony Reader will be able to compete very successfully with the Kindle. The libprs500 software is written as a python application, and it will work on Windows, Linux, and MacOS — and its GUI user interface is far better than the truly pathetic Sony Connect software. Score one for Open Source! In my opinion, Sony should send a very nice gift certificate to Kovid as a thank you; his open source project has added an immeasurable amount of value to their product. The only thing that you can’t do using the libprs500 software is buy DRM’ed books which are locked to the Sony Reader — but that isn’t something that many people will be particularly interested in, I suspect. OK, I did buy Pillars of the Earth, which was available on the Sony site for $6 dollars — hmm, cheaper than Amazon’s $9.99 — but that was an investment I was willing to flush down the toilet when the PRS-505 becomes obsolete, mainly so I could test what buying a DRM’ed book would be like from the Sony web site. But I probably won’t be buying many books with DRM that way. On the other hand, I am quite willing to spend quite a bit more money on non-DRM’ed books from publishes such as Baen Books. Here’s to the hope to the publishing industry figures things out faster than RIAA’s member companies. In the meantime, I will be mostly pretending that the both the Sony and Amazon eBook stores with their proprietary DRM’ed books don’t exist…

One might think that it is too early to declare the existence of a “classic” work on the Internet given how the Internet as a widely accessible communications networks is barely out of its pre-teen years, But if there is one book that I would say is a classic, it’s Julian Dibbell’s My Tiny Life. There were plans underway to release it under a libre license but after I ran into Julian at the AAAs in November, I got the scoop that things had come to a screeching halt. So a few days ago I was surprised to find in my inbox, this nicely crafted announcement that My Tiny Life is more or less (more more than less) free as a free bird. This is good news and his story about the trials and tribulations of getting My Tiny Life out of the noose of copyright, is an interesting one, involving among other things, outsourced Indian Labor. Who knew. And while I am on the topic, I meant to write about who, among the many authors I assigned this last fall, took the cake among students as their favorite book/article. Somewhat, unsurprisingly, Dibbell’s more recent Play Money was the champion. Most of the comments were relayed in class but here is one of the more amusing comments indicating the love:

Reading Julian Dibbell s Real Money, Or How I quit My Day Job and Made Millions Trading Virtual Loot was exceedingly more interesting than I expected.

And then just yesterday, another student wrote me an email telling me he read and re-read the book over his holiday break and wants to get Dibbell inivited to NYU to speak (which would be great, though I admittedly have no idea how to make that happen given my recent arrival here). But clearly, there is another classic in the making. Thankfully students liked many other readings and I think there were two other clear winners: Carl Elliot’s Better than Well , Michael Warner’s The Trouble with Normal. and Michael Sandel’s The Case against Perfection. This is of course no surprise to me as I picked these books because I knew they would teach themselves.

We are getting many bugs about wrong DPI configuration and DisplaySize not working. In most of the cases, it is actually caused by a confusion between Monitor sections in xorg.conf and RandR 1.2 outputs. With a default config, RandR 1.2 drivers will basically associate the unique Monitor section with their first output, even if not enabled. Bug #461501 is a good example of this issue. RandR 1.2 drivers (intel, ati, nv for G80, mga in experimental, radeonhd so far) require that you specify which output is attached to which monitor. If you have a Monitor section with identifier "Foo" connected on output "BAR", then you want the following in your Device section:

    Option "Monitor-BAR" "Foo"

Or (easier), just rename identifier "Foo" into "BAR". You need to add such a section for each output that you want to tweak (DisplaySize, ModeLine, PreferredMode). Then your tweaks will be applied to the right monitor/output. See the HowToRandR12 sections III.1 and III.3 for details.

Many Linux fans know that Debian Stable usually already lost the “b” when it’s being released. ;-) What seems not so well known (especially not by some DesktopBSD Marketing guy at last year’s LinuxDay.at :-) is that there is really a lot of people who really like this “stale” software collection — because it’s rock solid — especially compared to the ports in FreeBSD or DesktopBSD *evilgrin* which unnecessarily follow every new feature upstream introduces. This is really annoying in a server environment where you want as less changes as possible when updates are necessary due to security issues. My personal favourites here are Samba and CUPS. *grmpf* Although I belong to those people who run Debian Stable even on brand-new hardware, I sometimes have to use the newest beta or alpha versions of some software to get it even only running. And doing so is fun but feels strange somehow, though. Currently I follow the pre-releases of three software makers quite close, due to a new laptop: At the beginning of last semester I bought a brand-new Lenovo ThinkPad T61 (2,2 GHz Intel Core2 Duo T7500, 4 GB RAM, 160 GB HD, 1440x900 14” Widescreen) without preinstalled operating system (possible thanks to the ETHZ Neptun Project) and installed — of course — 64-bit Debian Stable on it. While the Debian Installer from Etch worked fine even on such new hardware, not all features worked out of the box because some components were just too new. So the first thing I did was installing 2.6.22 from Backports.org, quickly moving farther to vanilla 2.6.23. Nearly everything I needed worked except the wireless network card. It needs the iwlwifi driver which is officially in the Linux kernel starting at the upcoming 2.6.24 (said to be released during the next few days). So I run 2.6.24 pre-releases on the laptop since the first release candidate, always eagerly waiting for either the next RC or the final release. (And 2.6.24 looks impressively stable to me — even since the early release candidates. :-) I even got the fingerprint reader working for login and sudo (but not xscreensaver) using libthinkfinger backported to Etch from Debian Experimental. I’m just not sure if this is a good idea since the back of the screen already has enough of my fingerprints on it. ;-) The next software of which I’m currently running an alpha version is 64-bit Opera 9.50 (aka Kestrel, available at snapshot.opera.com) because no earlier Opera version is available for 64-bit Linuxes. Here I had different experiences: The builds from October and November were already quite stable, but since December it crashes usually several times a day. At work I also run the 64-bit Opera on my workstation, but stalled updating it when I noticed that it became so unstable. So my Opera at work has currently an uptime of nearly four weeks — and would have probably more if I hadn’t rebooted my workstation in Mid-December. Somehow this hunting for new versions and eagerly waiting for every new (pre-)release makes me really fidgety sometimes. And my understanding for people doing this for there whole userland or even operating system has grown, but I still prefer to have stale but stable software on all my productive machines, even on my laptop — just with some few and handpicked excpetions. The third but less thrilling thing I’m following are nVidia drivers for X. Since the free nv driver of X.org doesn’t support (and not only just doesn’t know) my graphics card yet and nouveau isn’t ready yet, I run the binary only and closed source driver from nVidia, waiting for that one release which supports Xen since I really would like to run a Xen guest with Debian Unstable for testing purposes and package building on my laptop. Until then I have to content myself with the much more unwieldy QEMU respectively KVM. Anyway, I’m very happy with the T61 and Debian Stable and can easily connive at the few not (yet) perfect issues like missing Xen support by nVidia, broken ad-hoc mode in the wireless card, no internal card-reader (as announced in the Neptun specifications) and no native serial port. Some useful links regarding the subject of this post:

• Linux Weather Forecast
• Opera Desktop Team
• Nouveau: Open Source 3D acceleration for nVidia cards
• ThinkWiki

Now playing: Jean Michel Jarre — Rendez-vous à Paris

One year ago, I took over Gammu maintenance. I think it time to summarize a bit what happened during that year. There were definitely good and bad releases in that time (especially strictness introduced to SMS parser in 1.13.0 took quite a lot of releases to fix various bugs), but generally I things Gammu is moving in a good way. What I would definitely call positive:

• Added build time testing. This helps a lot to catch regressions. However more tests could be done.
• I cleaned up lot of code parts so that Gammu is now more resistant to bad data and should not crash in these cases.
• Added lot of API documentation, most API functions are now fully documented.
• More often testing releases - I try to release every week. Sometimes changes are huge, sometimes just few bugfixes. This makes Gammu occur among most vital projects on freshmeat.net.
• Quite complete IrMC implementation together with AT/OBEX switching gives support for quite a big range of phones today.
• SMSD got PostgreSQL support.
• AT+CMGL support for reading messages gives us support for many phones which were not supported in the past.
• I started to use OpenSuse Build Service and Ubuntu PPA to provide up to date binaries for many distributions.

There are also some bad things:

• Nobody cares about build under MSVC. It is broken sometimes and I try to fix issues, but no constant testing of this causes problems.
• Almost no new features for Nokia phones. I simply lack time to do anything more than bug fixing here.
• Still bad support for Symbian phones. Some developer interested in this area is definitely needed. But probably OpenSync with SyncML is enough for most people.
• The changes I made to the SMS parser broke too much things, I should have payed more attention to this change. But now things seem to be worked out.

Some statistics of last year (based on Ohloh):

Value	Dec 2006	Dec 2007	Difference
Code Lines	90,540	101,687	+12%
Comment Lines	9,204	15,336	+67%
Comment Ratio	9.2%	13.0%	+30%

All these changes were made in approximate 1200 commits. I hope next year will not be worse :-).

As one of the females in #d-o might I add that this is not at all a sexist channel. Sure, like all friggen channels on IRC, and not to speak of the internet in general, there will be jokes, about men, women, monkeys, MacGyver and politicians. If you walk into a channel as a stranger and immediately draw conclusions because one
of the known peers of the channel utters a joke, and ramble about it, publically slandering that this person or channel is sexist, you really have no friggen business on the internet. Sorry, but you don’t.
Everyone is made fun of on irc, in #debian-offtopic it’s definitely “friendly insults” at that, and women are no exception to this. If you are too sensitive to handle this, again, you really have no business on irc. Please stop slandering and causing excessive drama because you cannot handle a fucking joke, for the love of god. I’ll say it again, #debian-offtopic or ANY debian channel I have ever been to (which according to my whois is a whole fuckload) has never ever hit me as sexist, and if you hang around enough to see some of the cool people around in them, maybe, just MAYBE you’ll see that these simple insults are JOKES and meant to be FUNNY and SARCASTIC. If you are unable to handle JOKES and SARCASM, get your ass off the internet and leave the rest of us “sexist” and ”blasphemist” freaks alone, PLEASE.