I've been extremely busy with labwork lately, trying to get a second paper ready for submission in the coming months. It's taken an obvious toll on my free software work, but that's life I guess. The upside is that the other night I realized why a year and half's worth of experiments kept turning up with negative results that seemed to contradict our other results. It turns out that this experiment was conceptually flawed, and even though I wasted a year and a half on this I did learn something even from those negative results that should go in to the final paper. I'm actually relieved, because even though I don't have all the data yet I can really see how the paper will end up, so I can start writing soon. Oftentimes knowing why something is wrong so you can fix it is even more important than being right.

I set up an ikiwiki to help organize my lab data a few weeks ago, and it's been a huge win. Joey really did a fantastic job on the program and I can't imagine using a wiki that doesn't share a very similar design for any of my personal stuff. I showed my boss some of my data using it and now he wants me to set up a wiki for the lab. He actually wants me to show off my wiki to give my lab members a feel for the idea. Since ikiwiki doesn't seem to be appropriate for my lab members, I'm going to have to look in to the giant list of wikis to figure out the exact right one for my lab's requirements. This is something I never expected to be doing in grad school.

Because there's no way my brain can go without doing a little bit of programming, I finally sat down and wrote myself a small shell script that lets me grep through pdf's, which is something I couldn't find googling around. If you have a lot of pdf's like I do and don't something like beagle or tracker churning away in the background constantly just so you can search them, this is very helpful. It's obviously very crude, but it gets the job done nicely. It relies on the pdftotext program; hopefully it'll be of use to someone.

I've been digging in to my copy of UNIX Power Tools lately, trying to pick up new UNIX and vi arcana, which is something I haven't made a real serious effort to do in a long time. It's been surprisingly fun to try and replace old habits with things that I know are better but don't use. A good example is that I usually will fire off a new subshell in vim when I should really just suspend vim and use my original shell to save time. Re-examining the basics of how I use the system has been a lot of fun, and has made me a lot more comfortable with the simple day to day tasks.

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

(This was one of those pesky “oh, it’ll only take an hour” ideas.) AptFs is a FUSE-based filesystem that provides a view to unpacked and patched Debian source packages as regular folders on a filesystem. Binary packages are modelled as symbolic links pointing to their respective source package. This arrangement allows one to:

• Use standard UNIX utilities to perform queries across the entire Debian source tree
• Save keystrokes and time when downloading (and subsequently deleting) source packages
• Do really awesome things easily, like perform static analysis on the archive, count swear words, etc.

The program maintains a sliding window of unpacked packages to perform automatic cleanup of unpacked packages — it would not be very helpful if commands such as

% find /path/to/aptfs

…unpacked the entire archive into your temporary directory. Source (GPLv3) is available in Git:

% git-clone git://git.chris-lamb.co.uk/aptfs  # or
% git-clone http://git.chris-lamb.co.uk/repo/aptfs.git

Patches always welcome, and shout if you like it; I’ll file an ITP and try and upload it.

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

As I mentioned in an earlier article, one of the goals for the Android port of Hecl is to make it as easy as it is to create Java ME applications:

1. Write the script.
2. Wrap it up and send it to the phone.

No "compiling" (well, none that's obvious or explicitly asked of the user, at least, as we'll see) or fiddling with build files or writing new Java classes or any of that. We're still not there yet 100%, but I did managed to hack together a system that, from an original Hecl.apk, creates a new application that can be installed on the emulator. This is tricky, because Android looks at the uniqueness of the package and class utilized for the application, meaning you can't just rename Hecl.apk to Foo.apk and install it as a separate app. The emulator will overwrite your old copy of Hecl. Here's what we go through to make this work. Be forewarned - big, ugly hacks that are not for the faint of heart follow. The command line isn't exactly beautiful either, but it beats all the individual steps that it replaces, as we'll see.

java -jar /home/davidw/workshop/hecl/jars/AndroidBuilder.jar -android \
    /opt/android-sdk_m5-rc15_linux-x86/ -class Example -label "Hecl Example" \
    -package my.example -permissions ACCESS_LOCATION,ACCESS_GPS

1. The first thing that needs to be done is to replace the AndroidManifest.xml that is contained within our "template" application, that resides in Hecl.apk, a copy of which is contained within the AndroidBuilder jar file. Since the compiled version of the xml file is a binary format that hasn't been reverse engineered or documented yet, the best way to do this was to simply:
2. Write out a new AndroidManifest.xml in our temporary work directory that uses our provided package name, label and class.
3. Using the aapt command in the SDK, create a new, empty apk file, specifying the newly created xml file as the manifest file to use.
4. Now we can extract the compiled version of the xml file, for later use.
5. At this point, we extract a version of Hecl.jar contained within AndroidBuilder.jar to the temp directory.
6. Now we need to generate some Java classes that correspond to the new package and class names that we've passed to AndroidBuilder. Ideally, I would have done this with some tools to write the byte code out directly, since the classes are so simple: all they do is subclass the Hecl and SubHecl classes so that methods fall through to those.
7. But instead, I just write out the .java code and compile it.
8. The two new classes get stashed inside the copy of Hecl.jar that we're working with.
9. We now use the dx command to compile the entire jar into the classes.dex file that Android uses.
10. Since Hecl.apk is just a zip file, we can replace the AndroidManifest.xml file and classes.dex file with the new files we have created.
11. At this point, we rename the whole works, and move it out of the temporary working directory to the current directory.

Phew! That's a lot of ugly work. It's obvious that a lot of this should and could be handled in a less "brute force" way, but for now it gets the job done. The only thing left to do is replace the Hecl script, which is very easy:

zip -r Example.apk res/raw/script.hcl

This makes it possible to whip out new Android Hecl scripts without carrying around a lot of project infrastructure - all you really need is AndroidBuilder.jar and your script. Naturally, all of this is very much a work in progress, so it may not work as advertised, and, given the mess that we go through, bugs are likely as well. Do report them if you find any, and have fun! In the future, it will be necessary to make it so that it's possible to add resources to the apk file with zip, and have them be available to Hecl applications, which was actually the focus of the previous article.

I finished reading the electronic advance reader’s copy last night. Overall, I’m glad I read it, though it was quite infuriating. The book is set about a decade in the future. In the book’s world, anthropogenic climate change and global warming turned out to be a hoax; instead, a global cooling (caused by solar variation) was beginning. At the same time, the bird flu (H5N1) became a major pandemic. The United States was governed by the democrats and “the bitch” (a thinly disguised demonisation of a certain democrat presidential candidate), who handled everything wrong. The book is a fictional autobiography (or a series of blog posts) by a US army officer who became famous during those turbulent times, first commanding a company finding its own way back home after being abandoned in the Middle East (the later stuff I won’t describe to avoid spoiling the book). The Last Centurions is a television propaganda show featuring his unit in action, intended to counterspin anti-military news reports. Several chapters early in the book are pure political ranting by the narrator: how anthropogenic climate change is false, how socialized medicine is bad (and causes lots of unnecessary deaths during a pandemic), how republicans are good and democrats are evil et cetera et cetera et cetera. (Then again, it’s a Ringo book, political ranting is a given.) Given my political persuasion, it was not easy to read: I kept yelling, “where are your footnotes!” I actually tried to verify some of the claims the narrator makes, and found nothing persuasive. Still… in the end, it all turned out to be justified. It explains the character, and it explains the world. Perhaps it should be a bit trimmed during editing (remember, I read the author’s submission draft which has not been through the usual editing and copyediting cycles), but a lot of it is necessary for the story. The premise that anthropogenic global warming is a false theory made it very hard for me to suspend disbelief. However, given that premise (and the premise of a totally incompetent government in the USA), the story is compelling and interesting. There’s a quite a bit of military action as we have become to expect from Ringo. The beginning grabbed me, – apart from the couple of chapters of exposition – held my attention tightly to the end, and left me shell-shocked. I especially liked the wife’s edits. I’m sorry that we didn’t get to see their courtship. I don’t know if I’ll ever want to re-read the book, but I’m still rating it at 5/5. The book is now available as an e-ARC, and will be released as a regular book in August. There is a companion site at www.thelastcenturion.com.

My Fujitsu-Siemens laptop’s power adapter became unreliable. I contacted support, described the symptoms. A week later, I had a new adapter. Thank you, Fujitsu-Siemens. You rock.

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

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

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

I spent part of my Sunday on samba yesterday. After all, that ankle tendinite I have for nearly two weeks now has some benefits for Debian: I don't waste hours running on week-ends. Samba 3.0.28a was announced by upstream and I worked to package it. Not really difficult and the package is already ready. It again minimizes the numer of Debian patches: we're slowly converge back towards upstream. Meanwhile, Steve uploaded a new release of 3.0.28, introducing the use of ucf to manage smb.conf changes. He slightly messed up in the update and, therefore got 3 RC bugs in a row for the same problem (#470138, #470139, #470140...and even #470142 to complete the picture). Good score, Steve. One beer for me next Debconf...:-)...The breakage was fixed a few hours later. So, conclusion: we apparently have active users who are committed to reports errors. Good...:-) As soon as 3.0.28-4 makes its way to unstable *and* the automated Ubuntu merge-o-matic, I'll probably upload 3.0.28a, not really waiting for 3.0.28-4 to enter testing (we already have 3.0.28 in testing). Another work in the pipe is the preparation of samba 3.2.0. Upstream released RC2 last week and I did early work to package it (for experimental as of now). However, that release incorporates most parts of our "FHS" patch, for better compliance to the FHS, as well as several other patches we pushed to them. And, as these weren't applied as is, some checks have to be done. Moreover, some other changes seem to be needed to get the package to compile. And, finally, we need to merge back recent changes from the trunk branch (such as the ucf support). All this is a way too high barrier for me and I'll need Steve to take that load, which he promised to do (and so *will* do, I know him enough....). When all this will be settled down, it will be time to jump in the BTS and fight with some old bugs of the package.

There are plenty of reasons why a company might provide a web form as the only means for customers to get in touch with their customer support department: for instance, the web form compels the customer to send along important information with the first request, therefore saving time (and money) for the customer service department. Even though I hate web forms, I sometimes do fill them in and usually get an answer back; it works. Every once in a while, however, I ll encounter a form designed by people without any form of understanding of the role of a customer for any business (it s the most important asset ). Such is the case when the form limits the message to a certain number of characters. Obviously, no customer service agent wants to read novel-length prose when fielding incoming requests, but a few hundred characters may also not be enough to get the point across. Star Alliance, for instance, expects you to get your point across in 300 characters. I find it hard to imagine that people write lengthy texts into web forms, unless they have more information to get across. I also see no technical reason for limiting the length of the text which can be submitted. The only logical explanation I have is that those companies give a flying food about customers and would much rather not have them contact the support department. NP: The Flower Kings: Back in the World of Adventures

dpkg-cross updates
uploaded to Debian unstable

   * General support for querying endianness of an architecture.

   * Update standards version (no changes)

   * Add Cvs-CVS field to debian/control

   * Reinstate detect_arch for improved build test checks in emdebian-

     tools

   * get_endianness: new function for Emdebian TDeb support

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

emdebian-tools 0.8.3
Uploaded to Emdebian

   * Interim Emdebian release.

   * emsecondstage: ensure cdebconf environment is setup before

     configuring packages

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

     to boot.

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

     [*.debhelper, *.substvars, files]

   * em_installtdeb: support special modes via debian/xcontrol

   * Support unpack method in basic emsandbox rootfs

   * embootstrap: continue after some errors

   * Support unpack method in gtk emsandbox rootfs

   * Simplify basic empdebuild chroot and copy in hostname files

   * empbuilderlib: add support for creating skeleton versions of

     /etc/group and /etc/passwd.

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

     network is available.

   * emsecondstage: configure cdebconf before others so that the database

     is ready

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

     and date

   * Add --arch support to em_installtdeb

   * Depend on new support in libdebian-dpkgcross-perl

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

     intermittent failures

   * empbuilderlib: parse the .list contents from dpkg

   * embootstrap: ensure buildplace is clean before starting a fresh

     debootstrap

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

     between arm and armel binaries

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

     debian/xcontrol

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

     calls to the empbuilderlib library

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

     rootfs bootable

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

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

     functions in empbuilderlib

   * Suggest file-roller for inspection of rootfs tarballs

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

     support

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

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


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


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


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

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

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

Fields used by an LDAP Unix user database Some notes about LDAP for Unix user management: Meaning of fields for objectClass posixAccount:

• uid contains the username
• uidNumber contains the numeric UID
• gidNumber should have the numeric GID
• cn should contain the user's full name (optional)
• homeDirectory and loginShell contain what you think they contain
• gecos contains the gecos from passwd (optional)
• userPassword contains crypt followed by the encrypted password from /etc/shadow (md5 password hashes are ok as well) ( SASL is an interesting alternative)
• sn is the surname (optional)
• givenName is the given name (optional)

Meaning of fields for objectClass posixGroup:

• gidNumber is the group id
• cn is the group name
• memberUID attributes contain posixAccount.uid values

For objectClass inetOrgPerson: what you put there can be used as if it were a vCard by mail programs and contact lists. Now, the name of people could potentially be split in cn,givenName,sn,gecos and displayName (possibly more): how would normal user tools deal with the redundancy? To show a gecos field, pam_ldap will search for a gecos field first, then automatically fallback on building a gecos field out of the other suitable info it finds. To show a name, sane programs try displayName first and if it's not present they guess using the rest. Then there is the issue of how to chose the dn to identify users, groups and so on. Users usually go in uid=$USERNAME,ou=People,$SUFFIX, while groups would usually go in cn=$GROUPNAME,ou=Groups,$SUFFIX. Should you need to create the People and Groups organizational units, this could be the proper bit of LDIF:

dn: ou=$NAME,$SUFFIX
ou: $NAME
objectClass: organizationalUnit

To add fields that are not already part of a schema, one needs to create their own schema. To do that, one needs to first obtain (free of charge) a Private Enterprise Number that is used in various places in the schema definition. Making up your own one means risking conflicts if you eventually grow larger. But it is rarely needed, because for most things there are already schemas available. Many thanks to Wouter and noshadow for allowing me to crudely extract all this content from their brains.

When you join an academic department, you are just one body and mind among many others doing what you do: teach, write, go to conferences, answer a lot of student emails, advise, etc. However, what you don’t get to do is really see your colleagues very often. While we come together far too frequently for faculty meetings, once you are done, you just want to scuttle out of the room (and as quickly as possible) to continue what seems to be an endless stream of work. But over the course of months and years, there are times and moments when you do come across your colleagues and their work: you may assign some of their work in your class class, go see them speak at an event, or learn about their work over coffee. This weekend during a PhD prospective weekend, I finally got to learn about what is probably one of the coolest projects to come out of my department, The Dead Media Archive run by Ben Kafka and Alex Galloway for their Dead Media Archeology Class. Loosely inspired by a mailing list by the same name started years ago by Bruce Sterling (which eventually suffered its own death), they are collecting information and analyzing the significance of all sorts of Dead Media, some of which were quite present and important for our economy and communication systems, others which flickered much more briefly as a bright idea but never really caught on. As part of their class assignments, students have to write in-depth descriptions, histories, and analysis’ of these objects and they are fantastic; so if you are into dead media, do check out the archive.

Android relies heavily on something called "resources" to access portions of the system that aren't directly in the Java code. For instance, if you had an ogg file that you wanted to use to play a sound with, you would add it as res/raw/foo.ogg. Then, during compilation, the aapt tool transforms all your resources into a Java file called R.java, which is basically a series of integers that can be used to reference the actual resources. For instance, to set up our hypothetical ogg file, we would do:

MediaPlayer mp = MediaPlayer.create(context, R.raw.foo);

That's all well and good as far as it goes, and if you don't have any reason not to use it, you should. However, with Hecl, one of my goals is to make it very easy to create applications. This means:

• No complex directory layout structure.
• No big long build files that require tools like ant.
• No complex compilation steps.

I'm not there yet, on the Android platform, which is a bit more complex than Java ME (where it is indeed so easy to create new Hecl .jars that it's possible to do it on the fly via this web site: http://builder.hecl.org), but I am making progress. One thing that a user might want to do is add their own files to the .apk file that actually gets installed on the phone. Since it's just a zip file, that's pretty easy:

zip -r Hecl.apk res/raw/foo.ogg

However, without a resource, there is no way to access that file, so the question is: how can we get ahold of it somehow? The first piece of the puzzle is Java's ZipFile class, which lets us open up a zip compressed file, such as the .apk file that contains the ogg file we're interested in in this case. The critical passage is getting ahold of the actual filename on the Android filesystem of the code that's currently running. It turns out to not be too difficult, if a bit obscure:

String filename = this.getPackageManager().getApplicationInfo(packagename, 0).sourceDir;

With that information in hand, we can feed it to ZipFile, and then access the contents at run time. It's not a perfect nor complete solution, yet. So many of the Android API's require a resource ID, so it takes some extra coding to do things from the InputStream that we can get out of the zip file, but there may be ways to make this easier. For instance, we could simply dump the contents of raw/ into an application specific data directory the first time an application runs, in order to at least be able to access the files as files, rather than InputStreams connected to ZipEntries. In any case, at least it's possible to access files added to the .apk without requiring the compilation step. I'm not sure how many other use cases there might be for direct access to the .apk file, but if other people need to do this, hopefully this information will be helpful.

Do you know the situation where you just aren’t sure whether you are spelling a word the right way? If you know how to type the word pretty well, then a dictionary might work just fine. If you aren’t sure at all you might consider using Google’s ‘Did you mean’-feature. Check out a simple demonstration for the word Wondows, which could mean ‘Windows’. If you happen to use that google-feature just too many times you might be interested in my small hack:

wget -O google_correct.py http://grml.org/scripts/google_correct.txt
chmod +x google_correct.py

This small python script uses xsel (so it currently works only on systems providing xsel ;-)) to retrieve the currently selected word from your X selection, executes a google search and parses the output for the keyword inside the ‘Did you mean’ section. Finally it sets the corrected keyword as your current X selection. If you provide the keyword directly as an option, then the script just outputs the corrected keyword without touching your X selection so you can integrate it directly inside your $EDITOR as well as an option. This gives you the flexibility to use this feature globally(!) inside your preferred window manager. Select a word, press the keybinding for executing google_correct.py and now you’ve the corrected word available for further actions… Finally don’t forget to put the affected word (after double-checking it using a real dictionary of course) into your $EDITOR’s dictionary to keep such “help m0m, I can’t sp3ll w0rds anymore” situations at a minimum. I’m using a personal dictionary file and ‘iab wondows windows’ inside Vim to fix spelling errors for words I’m unsure how to spell or which I always get worng. A whishlist of further ideas/features for the script can be found in the header of the script itself. Further input welcome.

I'm looking for some time for a good user self management. "Good" means: User can add their own accounts, gets approved (or not), can recover the password, ... Of course, there are plenty implementations of that available in the market - most wikis have that, as well as lots of other applications. But all of them are embedded-only, i.e. one has to use that web application and gets "vendor-locked". Isn't there anything open source and standalone available, following the basic unix principles of "do one thing and do it well"?