It’s quite convenient to have your GPG private key on your desktop, laptop and USB stick.. but if one of these is stolen or lost, you are pretty much obliged to issue a revocation.
Now, RAID-5 has this wonderful property whereby it is impossible to recover data from an array of size n if you have (at most) n-2 elements. So, one idea would be to create a small loopback device -based array that you can spread around your nice stealable items - you then use your key by combining >= n-1 of them.
..Or Eve must steal n-1 items before she can reconstruct your secret key. You can recover the “missing data” from single lost device, obviously.
There are almost certainly cooler algorithms for this, but none that are in the Linux kernel. Some scriptage that seems to work for me:
#!/bin/sh
set -eu
NUMITEMS=3
SIZE=30
create()
for NUM in $(seq $NUMITEMS);
do
dd if=/dev/zero of=$NUM.img bs=1M count=$(echo "$SIZE/($NUMITEMS-1)" bc)
losetup /dev/loop$NUM $NUM.img
done
sudo mdadm --create -l5 -n$NUMITEMS /dev/md0 $(seq -f "/dev/loop%g" $NUMITEMS)
sudo mkfs.ext3 /dev/md0
stop()
sudo mdadm --stop /dev/md0
for NUM in $(seq 1 $NUMITEMS);
do
sudo losetup -d /dev/loop$NUM true
done
start()
# Collect array elements from argv
NUM=0
for ELEM in $ELEMENTS;
do
NUM=$(( $NUM + 1 ))
sudo losetup /dev/loop$NUM "$ELEM"
done
sudo mdadm --assemble --run /dev/md0 $(seq -f "/dev/loop%g" $NUM)
recreate()
# Assume already running
dd if=/dev/zero of=$NUMITEMS.img bs=1M count=$(echo "$SIZE/($NUMITEMS-1)" bc)
losetup /dev/loop$NUMITEMS $NUMITEMS.img
sudo mdadm --add /dev/md0 $NEW
sudo mdadm --misc --wait /dev/md0
JAVA_HOME=/usr/lib/jvm/java-gcj CLASSPATH=/usr/share/java/esd.jar:/usr/share/java/jsch.jar jh_build weirdx.jar srcThis 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-gcjjh_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 .
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 installdebian/libjsch-java.jlibs
jsch.jarSample 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 installdebian/salliere.install
salliere.jar usr/share/sallieredebian/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...
Hit Alt+F2, type notepad, hit enter. An editor window pops up. Something
is very strange, though ... until I realize that KDE has caught my Alt+F2, so
that the “Run Command” box I was typing notepad into was not that
of the Windows session on the terminal connection but the one of my local KDE.
And since I've installed Wine some time ago, there actually is a text editor
called notepad on my local computer which closely resembles the one from
windows.
And the whole thing because apparently Copy and Paste doesn't work from my
local desktop to a (Citrix based) terminal session. (Hmm. Is Alt+F2 even the
correct key combination for Windozes? Update: Several people have
pointed out that it's Start+R in Windows. Thanks, will have to try if that's
put through to the terminal session correctly, then.)
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.
A phone call in December made me very proud: A colleague I met thanks to the Espora collective told me she was involved in the Mexican activities for this year's World Social Forum (FSM Mexico 2008 site). The Mexican activities? Yes. This year, the World Social Forum will not be held at one -or several- distinct places, but it will happen globally. There will be activities in tens of countries. The activity program for Mexico (full PDF version) is quite loaded - And I was invited to give one of the talks, this Friday (Jan 25) at 12:00, about Free Software for a Free Society, in the Foro Derecho a la Comunicaci n track.
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:
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:


Sadly, I can't seem to get things right re: Fosdem. I got the dates wrong for Fosdem and had to pay extra to change the bookings. Last year I got the flight wrong and had to pay extra to fly from Gatwick instead of Heathrow (and when I got to Brussels there was some bomb alert that had closed the airport, just to make things worse).
Here's a handy incantation I use with the Intel X.org graphics driver on my laptop.
Put this script somewhere convenient:
#!/bin/sh
if xrandr grep '^VGA connected' >/dev/null
then
#echo "VGA connected"
xrandr --output VGA --above LVDS --auto
xrandr --output LVDS --auto
else
#echo "VGA not connected"
xrandr --auto
fi 2>&1 logger -t xrandr-hotkey
and bind it to your "switch video mode" key, e.g. Fn+F7 on my Thinkpad X60s. For instance, I run xbindkeys, so I saved it as autoxrandr and put this in ~/xbindkeysrc:
"exec /home/smcv/bin/autoxrandr"
XF86Display
Now if you press the "switch video mode" key with a monitor plugged in, you'll get the external monitor appearing above the laptop panel (my preferred configuration - I've balanced my monitor on an N800 box to get the bottom of the screen level with the top of my laptop's screen). If you press that key again after unplugging the VGA cable, the laptop will turn off the VGA output and pull all the windows onto the built-in screen.
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? :-)
Next.