Erich Schubert's two posts about embedding spamtraps in web pages got me wondering about trying to track the web crawlers that harvest such addresses. If the pages that had the embedded spamtraps could be dynamically generated, it'd be interesting to generate email addresses that encoded the time of the crawl (well the page load I guess) and the IP address of the remote host. I expect that most of the harvesting is done by botnets, so it possibly wouldn't tell you a lot, but it'd be kind of cool to maintain a central blacklist of known harvesting IP addresses, that sites like mailing list archives could use to try and block the harvesters with.

I've spent the evening poking at the panel display that seemed to ship on some of the Philips Freevent desktops (some sort of abortive rebadging exercise). It's a TriGem part with a USB vendor ID of 0x0aa8 and product ID of 0xa001. It has four 7-segment numbers, a volume display and miscellaneous legend indicators. There's also some bizarre spinning circle thing that seems to be under programmatic control, but I haven't figured that bit out yet. It takes bulk writes of 16 bytes to endpoint 1, and the following format seems to be enough to drive the informational display.

The lack of any real free-form text support means it doesn't really fit into the LCDProc model, so I'm not really sure what to do with this. I'm sure I'll come up with something at some point. All the Windows driver does is cycle between showing hard drive space, memory and cpu frequency, though the hardware's obviously designed for showing the time as well (oddly, there's a separate clock at the top of it that works without a driver - I really don't think I want to know how that works). If anyone's got a similar device with a larger array of functionality, I'd be interested to hear if the remaining bytes do anything.

Bytes 0-7	Don't seem to do anything - perhaps on systems with more lights?
Byte 8	Bits 0-4: Volume lights 3-7
Byte 9	Bit 0: GHz light Bit 1: CPU light Bit 2: HDD light Bit 3: Mem light Bit 4: Mute light Bit 5: "Vol" light Bit 6-7: Volume lights 1-2
Bytes 10-13	Bit 0: Lower horizontal bar Bit 1: Left lower vertical bar Bit 2: Right lower vertical bar Bit 3: Middle horizontal bar Bit 4: Left upper vertical bar Bit 5: Right upper vertical bar Bit 6: Upper horizontal bar Bit 7: GB light (byte 10), colon light (byte 11), decimal point (byte 12), MB light (byte 13)
Byte 14	Doesn't seem to do anything
Byte 15	Must be 0x01

Sometimes I don’t particulary want to follow a bug intimately and just want to be notified of the interesting changes; when it’s closed, when someone attaches a fix, etc. Take, for example, #454935. I didn’t subscribe to the bug at the time I noticed it, as it would have taken a couple of minutes to email 454935-subscribe (and send the confirmation back, wait on the fscking greylisting, delete the ACKs, etc.) and I could have always been overrun with annoying “severity wars”, merges with various duplicates, etc. In the event, this didn’t happen, but the perceived cost of subscribing to the bug was much greater than the benefit. Anyway, as I’m fairly certain I’m not alone in encountering bugs like this, my solution was to put together a GNOME panel applet for monitoring specific Debian bugs. It’s pretty fully-featured already:

• At-a-glance view of subscribed bugs, showing relevant information concisely
• “Fuzzy” bug number entry box - parses bug URLs, emails addresses and subject lines, etc.
• libnotify messages when bug changes state
• Quick access to reportbug or reportbug-ng via right-click on applet icon
• Polls BTS with exponential back-off to avoid BTS denial-of-service
• Quick access to the BTS page via right-click on bug entry
• Graceful offline mode - downloaded data is still available without network

Perhaps something like this can lure some Debian users into following development a little closer and put them on the path to becoming a regular contributor, who knows.. Source (GPLv3) is available in Git:

% git-clone git://git.chris-lamb.co.uk/debian-bts-applet  # or
% git-clone http://git.chris-lamb.co.uk/repo/debian-bts-applet.git

It comes with a debian/ directory, which is highly recommended over configuring Bonobo manually. What would be really useful right now is testing. If you want to contribute, please run your eyes over the TODO and HACKING files as well as the (OMGWTFBBQ) unit tests. If no major issues are found in the next few days, I’ll file an ITP and make a call for translations.

I've been a bit behind with the ISC DHCP v3 package of late. I've had a package of 3.1.0 for a few months, but I'm becoming more and more reluctant to make uploads of this package without giving it some rudimentary testing. Real life has been demanding of late, so I haven't had a chance to do that testing. Nothing's gone wrong with the package to date, I just feel negligent not giving it some basic testing before throwing it out there. So I chucked a spare QFE card in my workstation brutus, put unstable on the second hard drive, installed Debian unstable on the spare 10G partition of Sarah's old PowerBook, and lashed the two together with a bit of CAT-5, and voila, instant DHCP client/server testbed. So now that I'd verified that version 3.1.0 wasn't blatantly broken, I could have a fiddle with the new support for option 119 (domain-search) that has people at work very excited. I spent a bit of time off on a wild goose chase trying to figure out how to configure the DHCP server for this new option before I realised it was as simple as option domain-search "foo bar baz"; and then made the necessary tweaks to dhclient-script. I'm figuring that since one of the blokes who wrote the RFC works at Apple, and since Leopard supports option 119, the way they're doing it in Leopard must be approximately correct, so I've altered the behaviour of the DHCP client accordingly. All of this assumes you're not using resolvconf. Prior to 3.1.0, if you had the domain-name option set, the /etc/resolv.conf created by dhclient-script would set the search directive to the domain name. With 3.1.0, I've decided to make this set the domain option instead. The resolver behaviour remains the same, as best as I can determine. With 3.1.0, if the domain-search option is set, then the search directive is set to this. If the domain-name option is set, this is prepended to the list of domains in the domain-search option. This is consistent with what MacOS X 10.5 (Leopard) does. I'm not sure what Windows does (nor what version started honouring the domain-search DHCP option)), and since it doesn't have an /etc/resolv.conf equivalent, it's a bit hard to test. I'm going to hazard a guess and hope that since the other bloke who wrote the RFC works for Microsoft, that maybe, just maybe, Windows and MacOS X at least behave the same way. Currently, if resolvconf is in use, you get the old behaviour whereby the search directive is populated with the contents of the domain-name option, and the domain-search option is ignored completely. I've filed #460609 with a patch to fix this. Interestingly, resolvconf itself internally collapses the domain and search directives into the search directive of the /etc/resolv.conf it generates, so I can't quite get the same /etc/resolv.conf generated as would be generated without resolvconf being used. No big deal, the behaviour should be the same. The domain directive is largely unnecessary as I understand it. I have unearthed what I consider to be a bug with the domain-search option handling code in the client. It seems to be largely benign, apart from causing the client to emit some errors when it's obtaining a lease that contains the domain-search option, and possibly not splitting the domains in the domain-search option correctly. There's also another (I think unrelated) warning that gets emitted as well. I'm waiting to hear back from upstream about both. I'm not going to package the recently released 4.0 DHCP until I've figured out a transition plan to go from the old DHCP v2 packages to the v3 ones.

I'll be in Zurich doing some consulting work this coming week. If things go well I ought to be able to do drinks and/or dinner on Wednesday. Drop me an email if you'd like to join us!

For the last four years, I have left my life and home to return to my mother’s far more precarious and fragile life in Puerto Rico. I do so to visit. But I also do so to give her caretaker, Milagro, a much needed break. I returned on December 18th and found my mother nearly in the same state as she was in October. Far worse than a year ago, but she still struck me as my mother, if nothing else because she knew I was her daughter. Over the course of a week, all of that changed. After a series of howling fits, by the end of my first week there, she no longer knew she was my mother. While I knew this would eventually happen, I was still caught off guard. You see, prior to my arrival, and since my last visit in late October, she asked me on the phone, and my sister and Milagro in PR, *nearly everyday,* when I was coming back. So even though she asked when her daughter, who she knew lived and worked in the city of New York, was coming back over and over again for 8 weeks, this seemingly hard-wired thought quickly vaporized thanks to what is a disease of the brain, but what strikes experientially as a cruel disease of the soul and personality. So while 2007 was overall a pretty good year, it is also the year when in certain respects my mother died, at least for me in so far she has morphed into someone remarkably different from the person I once knew. Now she only remembers small scraps of her life. She knows she is from Russia, she knows that she lives in the Casa de Vera (which she thinks is her bed), she knows she loves the dog, she knows that she had parents (and she would like to return to them but does not know where they are), she knows she has a good friend who is a painter (I think she had a massive crush on him if she still remembers him and not me but otherwise, everything is so twisted, so jumbled or so gone, it is beyond stunning. She certainly knew I was around and helping for she got upset when she knew I was leaving, often bursting in tears, asking me to take her to New York. But she just knew me as Gabriella from Nueva York who brought her novio bueno to PR and not as anyone else. It is certainly not easy to see this, to experience it day in and out but it is what it is and there is no running from it. Logistically it is also beyond hard to take care of my mom. To get her to eat, to calm down after one of her morning fits (she always, always, always had a raging fit in the morning, the afternoon and evenings being far more calm periods), to convince her to wear her dentures (which is the only remedy to stop her from spitting all over the place), to dress her, to deal with her in the middle of the night, often twice, are all extraordinarily challenging. Very quickly, your waking hours fill up with seemingly endless tasks and this I guess is, in some respects, a hidden blessing; there is just a lot less time to ruminate over how all of this, frankly, sucks. It is only later, late at night, early in the morning, or on the plane ride home where the darkness of her life would set deeply into my own. It may be obvious why this state and experience is tough but there are two parts that I find particularly rough. If my mother’s state is one of near total chaos and entropy, there is one thing that is utterly clear. She knows she is suffering and she wants out. On particularly bad days, she would mutter or sometimes yell loudly that she wants to die and would ask for the medicine that would accomplish this. She would even sometimes call me mala for not giving her this medicine. It is certainly not the case that everyone with Alzheimers goes through what my mother does. Apparently, some experience the illness quietly and peacefully. This is so not the case for my mother, who lived a particularly hard yet vibrant life. Donning a difficult personality, she lived lived as fully as she could and it is clear that as life leaves her, she would rather not be around to experience what is a cruel exorcism of self. Thankfully, she is not constantly or not even mostly in a suicidal state. I think she at times forgets how lousy she feels and rather enjoys the rather limited life she has. And at this point, I just hope that she continues to have calm or even happy moments. The second surprise concerns my own memories. My mother has had this rare form of Alzheimers, Posterior Cortical Atrophy, for at least 6, possible 7 years now, though we only received the official diagnosis 2003, which is the year when when I first started to write the occasional post about my experiences with her. In 2003 and 2004, she was pretty functionally in tact and it has only been the last 2.5 years when the persistent decline has set in, whittling her capacities and memories to what seems to be a bare minimum. But because her presence and reality is nothing short of totally enveloping and drowning, I am starting to lose my own memory of my mother prior to her illness. If Alzheimers robs people of their memories, I have come to realize, that if you are not careful, it is a thief that can also rob your own memories. I think it is for this reason that I have become so attached to my mother’s stuff her furniture, her paintings some of which I have taken back with me. They are material vehicles that transport me back to the past when my mother was in a different state and place. Now it is clear that if the challenge is to deal with the emotional toll this illness causes, it as much summoning the will and performing the labor to retain and recall my older memories of her.

I switched today my blog from a svn backend to a git backend, since the svn post-commit hook doesn't work for web commits on svn. (I doesn't get a email for changes via the web interface). We'll see how ikiwiki behaves with a git backend

mutt-patched: sidebar keybindings mutt-patched it's really cool, thanks Myon for advertising it. Actually I've tried it only in the hope that it could solve bug #459739 (don't bother trying: it doesn't), but I'm now liking it, especially the sidebar patch. Unfortunately it lacks default keybindings for moving the sidebar cursor (why the heck: since the sidebar is enabled by default, am I supposed only to look at it?). Here are mine, in case someone wants a "plug and play" configuration for her .muttrc:

zack@aquarium:~$ cat .muttrc  tail -n 6
# mutt sidebar settings
bind index,pager \CP sidebar-prev
bind index,pager \CN sidebar-next
bind index,pager \CO sidebar-open
macro index,pager B '<enter-command>toggle sidebar_visible<enter>'
color sidebar_new yellow default

They are basically a subset of those proposed on the homepage, but I did not like changing the default semantics of b. See also bug #459725.

Something awry on Gmail this evening... I've been having status messages — you know, the yellow/orangish overlay on top of the page that usually shows when an action has finished — telling me that "the system encountered a problem" for a few hours now while reading my email, intermittently.
Now all of a sudden, I'm dropped in the "old version" of the Gmail interface and there's no longer a choice at the top for the current UI, you know, the one with the funky coloured labels and such; which disappearance leads me to believe that it's not just a client side issue. I'm simply curious now how long it'll take them to fix things.

*Update* As I finished this post and went back to navigating through Gmail, the new UI is back. That didn't take them long...
*Second update* ... but the service also wasn't fixed, I almost immediately started getting error status messages again. And now I'm back into the "old" UI. As I'll be off for bed soon, I probably won't find out how long it'll take. Not that I'm that interested.

Been a week since I posted. I've not done much, though I did complete most of the migration of my planet-searching code to gluck.debian.org. This is now logging to a local SQLite database, and available online. I've updated the blog software so that I can restrict comments to posts made within the past N days - which has helped with spam. My other comment-spam system is the use of the crm114 mail filter. I have a separate database now for comments (distinct from that I use for email), and after a training on previous comments all is good. Other than being a little busy over the past week life is good. Especially when I got to tell a recruitment agent that I didn't consider London to be within "Edinburgh & Surrounding Region". Muppets. The biggest downside of the week was "discovering" a security problem in Java, which had been reported in 2003 and is still unfixed. Grr. (CVE-2003-1156 for those playing along at home). Heres the code:

#!/bin/sh
#
#  Grep for potentially unsafe /tmp usage in shared libraries
#
find /lib -name '*.so' -type f -print > /tmp/$$
find /usr/lib -name '*.so' -type f -print >> /tmp/$$
for i in $(cat /tmp/$$ ); do
    out=$(strings $i   grep '/tmp')    
    if [ ! -z "$out" ]; then
        echo "$i"
        echo "$out"
    fi
done
rm /tmp/$$

Bits from the Debian i18n meeting (Extremadura 2007)

From December 12th to December 15th, Junta de Extremadura hosted another one of the Debian Meetings; five i18n guys shared ideas, food, buses and fun with the Debian KDE maintainers. We would like to thank Extremadura for hosting us during the Hispalinux Meeting 2007, the event was held at Universad de Derecho (Law University) in Caceres, Spain.

These are the minutes, results and notes from our work, it is a brief description but hopefully complete of what we have done and what is still missing/pending.

Thanks to Cesar (cek) we had the chance to work on churro (i18n.debian.net) locally; the server is still running a 2.4 kernel because of some "tick" problems with 2.6 series, the last one tried was 2.6.21 and we should try newer ones, in order to support upgrades and not get stuck with 2.4, we hope Cesar will find time to test new Debian kernels.

First, let me introduce everybody to the services, robots and resources being hosted by i18n.d.n:

• MoinMoin wiki for local and simple reference documentation, it contains all the links to the below resources. (http://i18n.debian.net/wiki/)
• Pootle experimental server
• dl10n scripts, aka dl10n robots (codename Lion), these scripts are responsible for the status of pseudo URLs used by some translation teams, by the Project Smith and by the NMU Priority List for i18n NMU Campaign
• Synchronization of the i18n material used by the Debian website to generate translation statistics about PO and PO-debconf
• Generation of Compendium PO files per-language
• Different types of statistics
• Other non user-visible services like a full source mirror for stable, testing, unstable and experimental, used by the scripts and robots.
• DDTP, Debian Descriptions Translation Project
• DDTSS, The Debian Distributed Translation Server Satellite, a web front-end for DDTP, now integrated to DDTP to use the Database back-end instead of the e-mail interface.

And, at some point, we found important to state clear the acronyms and names used in related DDTP projects/tools:

• DDTS, Debian Description Translation Server, this is the main "back-end" used in DDTP, it tends to be the interface between translator tools (present and future ones) and the database;
• ddt.cgi is a CGI interface that is able to provide info for specific packages or translations, including diffs, related packages and active/inactive descriptions.
• DDTC which is the old (and still functional) command line client for DDTP.

We took the chance to organize a few things on churro, old accounts were cleaned out and removed, we moved from /org to /srv and got more GBs of space to the "playground". Old files were also removed and some are schedule to deletion on early 2008. With the reallocation of /org we also find some more space to /home and /var, we reorganize some of the links on the web space (specially to remove services from people's accounts), and we changed the mirror script to also synchronize the Packages and Contents files.

Grisu and Martijn worked mainly on DDTP and DDTSS integration. DDTSS now provides statistics for stable, testing and unstable, we are also working with Debian Med to provide support and infrastructure to a specific audience, like packages related to Medicine. The conversion to talk directly with DDTP/DDTS database also provided:

• Fetching new translations is almost instantaneous and marks translation as requested (avoiding duplicated works via the e-mail interface).
• After sufficient reviews occurred, the upload is instant
• Committed DDTS / DDTSS / DDTP website generation into SVN
  • Added READMEs for the above directories

DDTSS now announces the user using authentication because of its integration with the Database backend used by DDTP. Quick trivia: DDTP is now a compound of 25 languages occupying 18 GBytes.

A few days before the meeting we had the offer to use "AUTOBYHAND" to upload a package with the Translation-* files. The package is now called 'ddtp-translations' and we worked during the meeting to create scripts to build the package and to test it on the archive side. This approach allow Debian i18n Team to upload new translations and remove old ones (or inactive ones) without bother FTP Master Team. Special thanks to Anthony Town, he has been working with us to prove tips, fixes and info on how to produce the package and the scripts. The code is available in the debian-l10n SVN under pkg-ddtp-translations:
http://svn.debian.org/viewsvn/debian-l10n/pkg-ddtp-translations

In our case, "BYHAND" processing consists of a simple tarball of the main,contrib,non-free /i18n/Translation-*, we decide to work on a set of scripts to make it easier to create new packages (ddtp-translations) in a consistent way and keeping debian/changelog up-to-date. We also made some suggestions to the script what will run on the archive side to check the tarball structure, base on the examples of debian-maintainers and debtags (tags-override).

One of our initial targets for the meeting with regards to Pootle and Debian was to try big PO files per language, fortunately, Nicolas and Friedel were able to increase Pootle performance enough to get a few languages from DDTP loaded in Pootle. Using the upstream Pootle-diet branch, which uses a database back-end for the generation of statistics, the time to browse the DDTP POs of a language (~20.000 files) went down to a dozen of seconds.

Speaking about Pootle, Friedel gave us a good picture of what is coming next in terms of Pootle's development. There are improvements planned in the areas of permissions and rights delegation, as well as file management (for projects and templates). Improved management of terminology projects is also planned.

Improvements in the QA capabilities of the translate toolkit and Pootle are planned to help with the "false positives" of the pofilter checks. Better reuse of existing translations will become possible by using better translation memory techniques. There is also work planned on formats and converters involving, for example, XLIFF, TMX, TRADOS and WordFast.

Another pending task for quite a while was the CVS migration to SVN, it is now done, with a new layout. Commits to the CVS were disabled and every single script or resource depending on CVS should be changed to use SVN. For now, we are publishing (via HTTP) the status files generated by the pseudo-urls robots until we can fix the scripts to re-enable the commit of the files. You can find them here: http://i18n.debian.net/debian-l10n/status/

We are pretty happy with the changes and results of the work during those days, but we still have some items pending on our TODO list:

• More advertisement and usage information about PO Compendiums
  There are two use cases are identified:
  
  • Filling new PO files.
  • QA work to find inconsistent translations.
  Maybe Eddy would love to do that? :-)
• Extend the duration of the statistics history. (Nekral)
• Debian packages of the services running on churro
  • DDTP (Grisu)
  • DDTSS (Martijn)
  • dl10n (Nekral)
• DDTP: add some scripts to handle packages with version in the description (e.g. kernel and kernel modules) (Martijn)
• DDTP: Standard generation of the translation tarballs (faw)
• DDTP: document the bracketed stats on the main page (faw)
• DDTC: should be updated to match the current features. Documentation to ease integration with procmail. (Nekral - low priority)
• Implement mail service for translation teams with their own robots (e.g. Dutch) (faw)
• Collect data from http://www.debian.org/devel/website/stats/ (Nekral)
• http://www.debian.org/intl/l10n/po/,
  http://www.debian.org/intl/l10n/po-debconf/
  are built based on the churro material. It would make more sense to build these statistics on churro (Nekral)
  • We could "fork" the page and add some fancy new features on these pages (Nekral)
  • Add information from the coordination page to indicate that a translation is ongoing. (Nekral)
• Pootle: missing review indication. Hard with PO back-end. (Friedel)

There are a couple more reports to be sent but they are more focused on i18n specific questions, tools and plans for 2008. So, probably those will be sent only to debian-i18n mail list. If you are interested, please, stay tuned. :-)

Posted on d-d-a: http://lists.debian.org/debian-devel-announce/2008/01/msg00002.html
And a big thanks to Nicolas François (aka nekral), he helped me a lot making notes, preparing the text and reviewing it; and was patient enough to wait for the report while I was solving some personal problems.

(Disclaimer: I work for MIT Information Services & Technology blah blah blah I am a student blah blah these are only my words and do not represent the opinion(s) of my employer.) Way back in the day in 1983, MIT started something it called Project Athena, which had the goal of investigating how computers could be used to enhance education at MIT. This project became the origin of such pieces of software as the X Window System and Kerberos, as well as a campus-wide network of workstations all running similar software. In 1991, Project Athena ended, but the Athena system continued on, taken over by MIT Information Systems. It’s 2008, and Athena still exists at MIT—walk into a computing cluster, and chances are all the machines will be running Athena software. (Unless that particular cluster has been taken over be Athena’s evil sibling, often referenced as “WinAthena”, which often seems to be maintained by no one, and whose existence is sometimes denied by those who maintain and support Real Athena. Not many machines have suffered this agonizing fate, luckily.) Unfortunately, as the years have progressed recently, fewer and fewer resources have been put into the development of Athena. In many ways it is no longer on the cutting edge of things as it has been in the past, though it is certainly still useful. Some students these days, however, even think of Athena as only “their MIT email” or maybe use it occasionally to print something in a cluster on the way to class. I’ve seen people grow frustrated and storm out of a cluster due to things like instructions for using a flash drive that involve more steps than just plugging it in. While on the one hand it’s easy to laugh at people for a lack of patience or being open to a computing system that is not either Windows or Mac and perhaps a bit more complicated on the surface, on the other hand, some of these things really should just work by now, and on other UNIX-based systems they do—but Athena has lagged behind. When you log into an Athena workstation for the first time, you are confronted with what looks like this: That’s GNOME 2.8, and it looks kind of like the GNOME 2.8 default but uglier. When you look under the hood, there are pieces of the system that obviously originated in a time where nothing better existed and so something new had to be created—the “xlogin” login system doesn’t support PAM, and the login path involves a hairy maze of scripts that perform various tasks. Under the hood, the base OS is currently RHEL 4 or Solaris 10. I still can’t remember what the right options are to feed RPM whenever I need some information that I think I should be able to get from it. These things were once necessary but today just look crufty. Some people have tossed around the idea that everyone has a laptop these days and thus clusters are uselessly expensive, but it’s been met with a lot of resistance. I’m all for progress, but I use clusters all the time! They’re one thing that makes it an easy choice for me to have a really portable laptop, because when I really need computing power or screen space on campus away from my room, there is always a cluster nearby. They’re also nice isolated places that can be associated with “work mode”, which is good for productivity. Beyond all this, Athena provides a common platform that all technical classes can depend on, from providing standard and specialized academic software to standing as a baseline of “make sure your code works on this before handing it in because that is how it will be graded”. At any rate, things are finally happening on this front. Athena can’t stay RHEL 4 forever—while AFS allows non-system software to be easily updated for all machines without requiring any OS release, hardware moves on and compatibility is lost, and the rest of the world is coming up with new awesome things that Athena machines are missing out on. A student group that I am vaguely involved with, SIPB, took the early initiative with this and created DebAthena, which takes stock Debian and Ubuntu and allows it to closely resemble an Athena environment. We even run a campus Linux dialup using the packages. (I won’t claim to have done much work on DebAthena myself because, well, I didn’t.) Amazingly, the Athena release team has decided to work with the SIPB on the next release of Athena. So, what I really just wasted over 600 words prepping for is to say that Athena 10 will be based on Ubuntu. This is only relatively new news, but I am lame about finishing blog posts. There are a variety of reasons why Ubuntu was chosen over Debian. Some of them are lame and some of them are not. Even so, I am excited about this prospect—and it should be possible to peripherally support Debian in such a way that was not possible with Athena 9.4. I really like Athena. Even coming to MIT with a background in Linux there has been a steep learning curve, though, and I think that things could be better. Lots of people here have their first encounter with a ‘nix system in the form of Athena, and we should strive to make that experience as good as possible. I’m kind of skeptical on the expected release date of this upcoming summer, but as long as it happens soon it will be a big step forward. In some ways it’s kind of sad that I’m excited about a big part of a research institution catching up with others—but inertia is a strong force, and dealing with thousands of workstations is no trivial task. I kind of long for the exciting days of creating new big pieces of free software like X. I bet I imagine those days as being better than they actually were.

I am currently working on implementing a cryptographic file system using FUSE. It is different from EncFS and similar in that it just mirrors a normal directory tree, but encrypts the contents of the files as they are read or decrypted as they are written. My use case is backups. I have some machines where I and only I have access, machines which may contain proprietary information, personal emails and so on. Of course, I want backups of those, so when the hard drives stop working, I don't lose any data. The machine(s) I am backing up to, however are not always machines where I trust all the people with physical access to not make a copy of my data. In addition, I don't want broken hard drives returned under warranty to contain unencrypted data. This use case is the reason for why I'm encrypting on read rather than on write. I have chosen to use CTR (counter) mode together with AES which should give acceptable security. One of the requirements CTR needs to work well is a nonce, typically 64 bits (for 128 bit AES) which must not ever be used twice. If you use it twice, you leak information about your plaintext, which is, for obvious reasons, bad. My current design headache is how to choose a good nonce. Ideally, I believe it should be persistent for each version of the file and unique per file. Using the inode number takes up 64 bits (on AMD64 at any take, or when using -D_FILE_OFFSET_BITS=64 on 32 bit platforms). So while this gives me the latter, it doesn't give me the former at all. I am wondering if I should use the inode number modulo 2^32 (effectively choosing the lower 32 bits of the inode number) and then something which is fairly sure to never be the same, such as mtime (or at least the lower 32 bits of it, when time_t becomes 64 bit). The reason for not just choosing a completely random value is I don't want a command like diff file1 file1 to claim there are differences in the file. My hope was I'd get a great idea on how to solve the problem as part of writing it down. Alas, that hasn't happened, so if you happen to come across a great solution (or a reason to avoid a particular choice), feel free to email me

Yesterday I got my laptop back. It was in service since the 6th of December.

They replaced the battery, and although it looked like the built-in charge indicator was defect, actually the button on this battery is buried deeper than it was on the previous one and I have to press really hard on it to trigger it.

According to the tests made yesterday night, this battery holds for about 2.5-3 hours when playing music. Also it has 96% of its designed capacity. I guess is OK enough since I don't want to be spared from my laptop anymore.

Next on the agenda:

• restore data sanity (I did clean up most of the data from the HDD before handing down the laptop for the case when I was forced to hand it over; lucky for me, I managed to keep the HDD)
• install armel Debian on my new[1] NSLU2, Kinder (more news on that later ;-) )
• fix my local network chaos triggered by the problems that hit Ritter (my older NSLU2)
  
• finish the wiki theme
• work a little more on svn-buildpackage and kill more of its bugs
• walk through my (game) packages' bugs and try to fix them, answer, etc.
• try to make bluetooth transfers to work from and to my laptop

BTW, I still hold to my opinion that Dell and Emag suck, although I might buy desktops from Dell, laptops are a no-no until they fix their broken batteries and their broken "1-year warranty for batteries" policy.

[1] I bought a new NSLU2 after I left my laptop in service and it has been waiting since then to run the Debian Arm EABI (armel) port

emacs git modes. Apparently, they are already available in Debian package git-core, /usr/share/doc/git-core/contrib/emacs/. In Fedora Core they are in an independent package emacs-git, and in Fink they are in the package git-mode. I just added the following lines in .emacs to try it out, and they seem to be working somehow. Great.

After some romantic films these past days to match my mood, and to celebrate I got back on track today, I watched Glengarry Glen Ross this evening. I was expecting a lot, and a lot I got, albeit not equally divided across the duration of the film. In the first part, it outstands the brief but intense appearence of Alec Baldwin (youtube link). It is funny because I normally peek at movies several times days before watching them, and normally at intervals of 10 minutes, which is what mplayer gives you for PgUp and PgDown. And at minute 10, I always got the memorable “You can’t close the leads you’re given, you can’t close shit, you are shit! Hit the bricks, pal, and beat it, ‘cause you are going out.” quote by Alec. (Minute 2:16 in the above Youtube link, or here.) After that it’s was just okayish for me, until minute 48 arrived, and then I could not take my eyes off the screen, not even once to check irc (and, well, that’s just unusual on me), until minute 89 (out of a 96 minute movie). For those who’ve seen it, that’d be the whole while in which the policeman is in the office. Anyway, give it a go if you’d like, and be sure to check this trailer after you have. On other news, and all the romantic stuff above which I really enjoyed notwithstanding, I loved El d a de la bestia. Pure awesome, but watch at your own risk!

Sarah slept better overnight, but still not great. She was certainly more lively this morning when I got in, than yesterday. She's resigned to the fact that you don't come to a hospital to get rest, which is kind of ironic. She did need to get put back on the oxygen overnight because her O₂ saturation dropped. She was off it again by the time I got in. Today's big achievement was getting the external pacing wires removed. They were put in during the procedure as a precaution, I think because if her heart played up, they didn't want to have to use defibrillator paddles, and because they'd cracked her chest open, manual CPR wasn't an option. The wires could be attached to an external pacemaker if necessary (but it never was). I watched the removal quite closely, as I was pretty curious. Basically the physician's assistant just came in and yanked them out. Judging from the look on Sarah's face, it was an interesting sensation. We were both amazed at how long the wires were. There was probably 30 centimetres of wire under the skin. The last bit was loosely spiralled. I was just really surprised, because the PA's hand started off at Sarah's chest, and ended up at the PA's shoulder. It was just a lot longer than we both expected. All the extra length was because the wires wrap around the heart. The wires came out at about 2:30pm. Sarah had another chest x-ray and a CT scan today. The CT scan looked good. The x-ray showed some fluid in her lungs, and her lung capacity is still sub-par. It seems when she's fully horizontal, her breathing isn't so crash hot, but it's fine when she's sitting up or walking around. All Sarah's got left is one peripheral line now. There was some talk of her possibly going home on Wednesday. She has an echocardiogram tomorrow, and I guess it'll all hinge on how her lungs are going.

After two weeks being back in Czech and mostly offline, I got back to Japan this weekend. The travel went quite okay, the only thing I really don't understand is why Japanese customs always want to check my luggage. There must be something special on it or I probably look like drugs smuggler, but he did not answer my question why they always select me for checking things :-). Anyway I already processed most of email backlog, only about 100 mails remain, I hope to read and reply them during this week.

A few days ago I stayed in an apartment at the Oaks on Market [1] hotel which I booked through www.WotIf.com. The WotIf price was $159 per night - the list price was $376 per night. It was possible to get extra beds for $30 each per night if you wanted to get more people in the room. All rooms are of the Suite / Apartment [2] style. The room was a basic (twin or queen) room, it was quite large and well equipped. The TV in the room was quite large and TFT, it had a range of inputs which seemed to include everything other than VGA and DVI (if I was running a hotel every TV would have VGA or DVI input for laptops). All the basic kitchen facilities were there, including a microwave oven, a stove, and a toaster. There was even dish-washing liquid! The hotel pool (indoor and heated) is 25M long and 1.2M deep, there is a spa and a sauna. The pool isn’t cleaned as well as it might be, there was a band-aid stuck on a wall and sand and other stuff on the floor of the pool (including a hair elastic with a rusty clip - it had apparently been in the pool long enough to rust). The hotel is a short tram ride from the LCA venue, walking to LCA would be possible too (I walked further than that when at Dunedin). I can’t claim that this hotel is better than others, but it would do. Having a pool is a good thing, I recommend that all delegates bring their bathers for pool parties - the weather will probably demand such things.

• [1] http://www.theoaksgroup.com.au/Property.aspx?sid=31


• [2] http://doc.coker.com.au/travel/hotel-vs-apartment/

Share This

So, after my previous entry, here's now a small list of the oldest bugs still opened in Debian BTS:

• #1555, Package: dselect, "dselect per-screen-half focus request". There is indeed no more information left in that bug and I wonder whether it is useful to keep it opened.
• #2297, Package: xterm, "xterm sometimes gets mouse-paste and RETURN keypress in wrong order". Seems reproducible and puzzling a lot of people.
• #2298, Package: trn, "trn bug with shell escaping". trn has been replaced upstream by trn4, apparently, so we're here talking about an old dusty software (installed by 44 ppl, still).
• #3175, Package: xonix, "xonix colors bad for colorblind".
• #3180, Package: linuxdoc-tools, "linuxdoc-sgml semantics and formatting problems". There is not info in this bug report about what the bug could be. To close?
• #3251, Package: acct, "accounting file corruption". Tagget upstream, wontfix. Should this be closed more than 11 years later or is someone still hoping that this is useful?