I ve been using Manoj s new kernel-package for some weeks now, and used it to compile two kernels (a reconfigured 2.6.29.1 and the new 2.6.29.2). Both times I ve had trouble with initrd. As the documentation says, kernel-package kernel packages no longer do their own initramfs generation. One must copy the example scripts at /usr/share/doc/kernel-package/examples/etc.kernel/postinst.d/initramfs and /usr/share/doc/kernel-package/examples/etc.kernel/postrm.d/initramfs to the appropriate subdirectories of /etc/kernel/. However, this is not enough. My /etc/kernel-img.conf file had the usual posthook and prehook lines calling update-grub. Unfortunately, those hooks are called before the postinst.d hooks, and so update-grub never saw my initramfs images. Fix? I removed those lines from /etc/kernel-img.conf and created a very simple postinst.d and postrm.d script:

#!/bin/sh
update-grub

I call the script zzz-grub-local, to ensure that it runs last.

That's just something I hear from time to time, and I love it so much. Fluxbox: 65010 SLOC Metacity: 62923 SLOC Openbox: 36336 SLOC awesome: 19207 SLOC

Call for papers: JITP-2010
The Politics of Open Source
May 6-7, 2010 - Amherst, Massachusetts Full Paper Submission Due Date: January 10, 2010 Approach
Free/Libre and Open Source Software (FOSS) has made significant advances, both technically and organizationally, since its emergence in the mid-1980s. Over the last decade, it has moved from a software development approach involving mostly volunteers to a more complex ecology where firms, nonprofit organizations, government agencies and volunteers may be involved. Moreover, the production paradigm continues to expand to other areas of digital content (e.g., Creative Commons, Wikipedia, Connexions, etc.). In this conference we use the phrase open source to capture this broader phenomenon. The Program Committee encourages disciplinary and interdisciplinary approaches to the study of open source, broadly defined. Politics in the conference title, can have many interpretations. Political issues closely tied to the free and open source software movement(s) include: national government policies related to the adoption of open source technologies or questions related to interoperability and open standards, software patents, vendor lock-in, and copyright. These are central themes we expect may be discussed in this forum. In this context, we welcome international submissions since differences in the political perspective appear in international contexts. However, topics related to how the concept of openness has led to various interpretations, adaptations, and applications of open source in other domains, and political issues that surround these broader innovations, are also welcome. Specific topics might include, but are not limited to: General topics related to the politics of open source:
+ How open source software or its principles are changing politics
+ Emerging transparencies in software, systems and society
+ Open source in the developing world and other international contexts
+ The political economy of open source
+ Digital divides and open source Open source and the public sector:
+ Open source software and transparency in government
+ Government policies toward open source and open standards
+ Regulation and open source Open source and democracy:
+ Open source and democratic engagement
+ Open source voting systems
+ Activism, political mobilization and open source The expansion of open source into other domains:
+ Understanding how open source collaboration works and how it can be extended into other areas of collective action
+ Policy areas, such as the effects of free textbooks on education policy or the politics of One Laptop Per Child
+ The political implications of open source in other cultural domains Keynote Speakers
We are pleased to confirm Eric von Hippel (MIT) and Clay Johnson (Sunlight Labs) as the daily keynote speakers for JITP-2010. Paper Submissions
Authors are invited to prepare and submit to JITP a manuscript following one of the six submission formats by January 10, 2010. These formats include research papers, policy viewpoints, workbench notes, review essays, book reviews, and papers on teaching innovation. The goal is to produce a special issue, or double issue, of JITP with a wide variety of approaches to the broad theme of The Politics of Open Source.

How to Submit
Everything you need to know about how to prepare and submit a strong JITP paper is documented at http://www.jitp.net/. Papers will be put through an expedited blind peer review process by the Program Committee, and authors will be notified about a decision by March 10, 2010. A small number of papers will be accepted for presentation at the conference. Other paper authors will be invited to present a poster during the Friday evening reception. All posters must include a YouTube version of their research findings. Best Paper and Poster Cash Prizes
The author (or authors) of the best research paper will receive a single $1,000 prize. The creator (or creators) of the best poster/research presentation will also receive a single prize of $1,000. Program Committee
M.V. Lee Badgett, University of Massachusetts Amherst
Paul M.A. Baker, Georgia Institute of Technology
Deborah Bryant, Oregon State University Open Source Lab
Andrea Calderaro, European University Institute
Mark Cassell, Kent State University
Edward Cherlin, Earth Treasury
Gabriella Coleman, New York University
Doug Downham, University of Massachusetts Amherst
Robert English, Daystar Computing & University of Massachusetts Amherst
Joseph Feller, University College Cork
Jelena Karanovic, Rutgers University
Dave Karpf, University of Pennsylvania/Miller Center for Public Affairs
Jeremy Hunsinger, Virginia Tech
Andrea Kavanaugh, Virginia Tech
Jose Marichal, California Lutheran University
Jens Hardings Perl, Pontificia Universidad Cat lica de Chile
Charlie Schweik, University of Massachusetts Amherst, co-chair
Stuart Shulman, University of Massachusetts Amherst, co-chair
Megan Squire, Elon University
Krishna Ravi Srinivas, Research Information System For Developing Nations
Louis Suarez-Potts, Sun Microsystems, Inc. & OpenOffice.org
Anas Tawileh, Cardiff University & Meedan.net

Call for papers: JITP-2010
The Politics of Open Source
May 6-7, 2010 - Amherst, Massachusetts Full Paper Submission Due Date: January 10, 2010 Approach
Free/Libre and Open Source Software (FOSS) has made significant advances, both technically and organizationally, since its emergence in the mid-1980s. Over the last decade, it has moved from a software development approach involving mostly volunteers to a more complex ecology where firms, nonprofit organizations, government agencies and volunteers may be involved. Moreover, the production paradigm continues to expand to other areas of digital content (e.g., Creative Commons, Wikipedia, Connexions, etc.). In this conference we use the phrase open source to capture this broader phenomenon. The Program Committee encourages disciplinary and interdisciplinary approaches to the study of open source, broadly defined. Politics in the conference title, can have many interpretations. Political issues closely tied to the free and open source software movement(s) include: national government policies related to the adoption of open source technologies or questions related to interoperability and open standards, software patents, vendor lock-in, and copyright. These are central themes we expect may be discussed in this forum. In this context, we welcome international submissions since differences in the political perspective appear in international contexts. However, topics related to how the concept of openness has led to various interpretations, adaptations, and applications of open source in other domains, and political issues that surround these broader innovations, are also welcome. Specific topics might include, but are not limited to: General topics related to the politics of open source:
+ How open source software or its principles are changing politics
+ Emerging transparencies in software, systems and society
+ Open source in the developing world and other international contexts
+ The political economy of open source
+ Digital divides and open source Open source and the public sector:
+ Open source software and transparency in government
+ Government policies toward open source and open standards
+ Regulation and open source Open source and democracy:
+ Open source and democratic engagement
+ Open source voting systems
+ Activism, political mobilization and open source The expansion of open source into other domains:
+ Understanding how open source collaboration works and how it can be extended into other areas of collective action
+ Policy areas, such as the effects of free textbooks on education policy or the politics of One Laptop Per Child
+ The political implications of open source in other cultural domains Keynote Speakers
We are pleased to confirm Eric von Hippel (MIT) and Clay Johnson (Sunlight Labs) as the daily keynote speakers for JITP-2010. Paper Submissions
Authors are invited to prepare and submit to JITP a manuscript following one of the six submission formats by January 10, 2010. These formats include research papers, policy viewpoints, workbench notes, review essays, book reviews, and papers on teaching innovation. The goal is to produce a special issue, or double issue, of JITP with a wide variety of approaches to the broad theme of The Politics of Open Source.

How to Submit
Everything you need to know about how to prepare and submit a strong JITP paper is documented at http://www.jitp.net/. Papers will be put through an expedited blind peer review process by the Program Committee, and authors will be notified about a decision by March 10, 2010. A small number of papers will be accepted for presentation at the conference. Other paper authors will be invited to present a poster during the Friday evening reception. All posters must include a YouTube version of their research findings. Best Paper and Poster Cash Prizes
The author (or authors) of the best research paper will receive a single $1,000 prize. The creator (or creators) of the best poster/research presentation will also receive a single prize of $1,000. Program Committee
M.V. Lee Badgett, University of Massachusetts Amherst
Paul M.A. Baker, Georgia Institute of Technology
Deborah Bryant, Oregon State University Open Source Lab
Andrea Calderaro, European University Institute
Mark Cassell, Kent State University
Edward Cherlin, Earth Treasury
Gabriella Coleman, New York University
Doug Downham, University of Massachusetts Amherst
Robert English, Daystar Computing & University of Massachusetts Amherst
Joseph Feller, University College Cork
Jelena Karanovic, Rutgers University
Dave Karpf, University of Pennsylvania/Miller Center for Public Affairs
Jeremy Hunsinger, Virginia Tech
Andrea Kavanaugh, Virginia Tech
Jose Marichal, California Lutheran University
Jens Hardings Perl, Pontificia Universidad Cat lica de Chile
Charlie Schweik, University of Massachusetts Amherst, co-chair
Stuart Shulman, University of Massachusetts Amherst, co-chair
Megan Squire, Elon University
Krishna Ravi Srinivas, Research Information System For Developing Nations
Louis Suarez-Potts, Sun Microsystems, Inc. & OpenOffice.org
Anas Tawileh, Cardiff University & Meedan.net

It s generally accepted that certain things need redundancy. RAID is generally regarded as essential for every server except for the corner case of compute clusters where a few nodes can go offline without affecting the results (EG the Google servers). Having redundant network cables with some sort of failover system between big switches is regarded as a good idea, and multiple links to the Internet is regarded as essential for every serious data-center and is gaining increasing acceptance in major corporate offices. Determining whether you need redundancy for a particular part of the infrastructure is done on the basis of the cost of the redundant device (in terms of hardware and staff costs related to installing it), the cost of not having it available, and the extent to which the expected down-time will be reduced by having some redundancy. It s also regarded as a good idea to have more than one person with the knowledge of how to run the servers, jokes are often made about what might happen if a critical person fell under a bus , but more mundane things such as the desire to take an occasional holiday or a broken mobile phone can require a backup person. One thing that doesn t seem to get any attention is redundancy in the machine used for system administration. I ve been using an EeePC [1] for supporting my clients, and it s been working really well for me. Unfortunately I have misplaced the power supply. So I need to replace the machine (if only for the time taken to find the PSU). I have some old Toshiba Satellite laptops, they are quite light by laptop standards (but still heavier than the EeePC) and they only have 64M of RAM. But as a mobile SSH client they will do well. So my next task is to set up a Satellite as a backup machine for my network support work. It seems that this problem is fairly widespread. I ve worked in a few companies with reasonably large sysadmin teams. The best managed one had a support laptop that was assigned to the person who was on-call outside business hours. That laptop was not backed up (to the best of my knowledge, it was never connected to the corporate LAN so it seems that no-one had an opportunity to do so) and there was no second machine. One thing I have been wondering is what happens to laptops with broken screens when the repair price exceeds the replacement cost. I wouldn t mind buying an EeePC with a broken screen if it comes with a functional PSU, I could use it as a portable server.

• [1] http://etbe.coker.com.au/2008/07/21/review-of-the-eeepc-701/

This is primarily a bug-fix release, cleaning up a bunch of accumulated minor stuff. The largest single fix saves all the error output from tar in the various places that Lintian runs it and analyzes it to turn it into Lintian tags, which suppresses the occasional annoying record size messages from tar and should provide better handling of other tar problems. There are also fixes, several from Raphael Geissert, for various packages that failed in the lintian.d.o log. My tentative plan is for the next verison to be 2.3.0, incorporating more infrastructure work by Raphael Geissert to work towards getting rid of the separation between unpack and collection and make the data collection more fully dependency-driven. I'd also like to take another pass through the wishlist bugs and try to knock off a few more of them. I'm going to try to get 2.3.0 started and get up-to-date on merging major patches over the next couple of days, and then will probably take another break from Lintian work for a while to work on Policy (and on finishing the USEPRO RFC).

A few weeks ago I wrote up a short review of Bernhard Pfaff's nice (but somewhat dry) Analysis of Integrated and Cointegrated Time Series with R (2nd ed) on unit root and cointegration modeling with R. This is now online at the Journal of Statistical Software.

We have had a quite strange couple of days... Everything was smooth as usual on Thursday. As I posted here, I cycled to Iztacala to give a talk and back, and basically had a good time. We had heard news some days earlier on the radio that the usual seasonal flu was still present by mid-April, while usually it disappeared by early March... But nothing more. But Friday morning, as I listened to my usual news program, Aristegui repeated over and over that the Health ministry had ordered (in a press conference at 23:00 the previous day) schools of all levels not to hold activities... Quite unusual, but WTF... Got to work as usual, around 9 AM. The first thing I see in the Institute, our Academic Secretary telling us all to finish our most urgent business and head back home, do not pass go, do not collect $200. And... During the morning it started sinking in. This is a very weird and somehow scary situation. We are facing -as you all must know by now- a previously unknown strain of flu virus (influenza porcina H1N1B, AFAICT). During the past couple of days, we have seen the scenes we wondered about during the past decade, mainly in South East Asia (with SARS and with bird flu): Everybody is scared, nobody really understands what they are scared of, people do stay at home. The streets are eerily quiet, and many people are seen with masks covering nose and mouth. I must recognize our federal and local governments are acting very well coordinated (for the first time in probably over a decade, since they were from different parties for the first time). This has been clearly labeled as an epidemic (over 1600 sick people reported at hospitals, and over 100 deceased) and has spread to many of our country's states (as well as to other many countries, although it still seems to be controlled there - But we have got reports from the USA, Canada, France, Spain, Israel and New Zealand so far). I will most probably spend the next full week at home, as my University (as well as all schools and universities in this city and at least the Mexico, Nuevo Le n and San Luis Potos states) will be closed until May 6th. Of course, sports and cultural activities are all suspended as well. Many (most?) bars and restaurants remain closed. Today, my parents came from neighbouring Cuernavaca (where no alerts have yet been emitted, but will surely follow), and we went out for lunch (to a nice Yucatan food place, chosen partly as it had very little concurrence and because we could sit outdoors. Yes, I must specially thank them for being as imprudent as coming over here, given the generalized scare... I know there was nothing I could do to prevent them from doing so :-) And... In this strange climate, I can only thank I am not a party-organizer or anything like that, as I'd have had my plans frustrated. Here I sit next to my laptop, in my halfway-re-windowed house, with a still shrink-wrapped book that looks beautiful (La bicicleta: Rito, t cnica y pasi n), eager to open it (Thanks, Nadezhda! :-* ). Happy birthday to me. Take off the mask, blow 33 candles, put mask back on. Thankfully there is no cake to eat, as it could be messy with the mask on.

This is about two things that are not robust. zomg, as of version 0.5.7, can play libre.fm radio streams without modification. It does not do this particularly well. As of today a second type of libre.fm radio stream is available, so I will give two illustrative examples:

• To play free music tagged 'Blues' (note that almost none of this is actually blues), zomg -r librefm://globaltags/Blues
• To play free music performed only by Abscondo (note that the "similarartists" is there to mislead you): zomg -r librefm://artist/Abscondo/similarartists

These stations lack the intelligence to avoid annoying duplication or much of anything but randomization. However, both zomg and libre.fm are free software, and anyone can chip in and improve this if desired. In other news, the state of client support has moved a bit, though not as much as one might have hoped. You can get a picture of that here.

previously i threw together a small hook to make it a bit easier to avoid duplicate work while maintaining packages, as well as easily keep the BTS up to date with relevant information. now i've commonized the code just a bit and have a second hook which can be used to maintain certian (what i believe to be) good practices for keeping packages in git. admittedly, it's a bit more "stick" than "carrot" with respect to streamlining workflows, but i feel the justifications and the resulting benefits are worth it. so the hook does basically two things, either of which can be customized and/or disabled. prevent "non-debian" changes on a "debian" branch assuming that there are seperate branches for "debian" packaging and for "upstream" development, this hook prevents upstream-style changes on the debian branches. that is to say changes to files outside ./debian are not permitted on a "debian" branch, unless of course you're merging from an upstream branch. instead, changes to the source in a debian branch should be managed by quilt-style "feature patches", or a more advanced branch topology using some kind of feature branches (topgit or similar). prevent changelog modifications from being mixed in with other commits this one might be a bit more controversial for some. basically, the idea is that:

• stuff is fixed in a commit
• there is a log message for this commit, which contains a description of the fix
• the changelog update is redundant information to this log
• it's impossible to merge/cherry-pick/revert the fix later if the changelog gets tangled into the commit.
• there are nice tools (git dch) for managing debian/changelog updates anyway.

therefore, this hook "declines" commits which modify debian/changelog, unless it is the only file being changed. using this new hook note this is the same repo as the other hook, so if you already have that set up you can skip the clone and instead just pull in the changes. to set it up:

REPO_PATH=/path/to/your/repo.git
HOOK_REPO_PATH=/somewhere/you/want/to/put/it
git clone git://git.debian.org/users/seanius/vcs-hooks/git-hooks.git $HOOK_REPO_PATH
ln -sf $HOOK_REPO_PATH/debian/git-hooks/pre-receive-fileset-fascism.py $REPO_PATH/hooks/pre-receive

the config options for controlling this hook (these are git config options just like the other hook):

# hooks.debianbranches (default: 'debian-.*')
#    a regular expression which indicates which branches are "debian" branches.
#    in the context of this hook such branches are not allowed to have changes
#    in files outside of the ./debian directory.
# hooks.sacredchangelog (default: True)
#    if set to True, debian/changelog can not be changed in a commit that
#    also modifies other files.  this helps ensure changes that are easily
#    merged/cherry-picked/reverted.

examples of the hook in action rejecting a commit that has an entangled changelog:

rangda[~/debian/php] git push                                  :)
Counting objects: 9, done.
Delta compression using 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 442 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
fileset-fascism rejecting commit 2fab3269b3d9daedd7013a576483a11ccb4cb86a
    debian/changelog must be changed seperately from other files.
    changed files in this commit:
        debian/changelog
        debian/control
error: hooks/pre-receive exited with error code 1
To ssh://git.debian.org/git/pkg-php/php.git
 ! [remote rejected] debian-sid -> debian-sid (pre-receive hook declined)
error: failed to push some refs to 'ssh://git.debian.org/git/pkg-php/php.git'

rejecting a commit that has non ./debian changes:

rangda[~/debian/php] git push                                  :)
Counting objects: 5, done.
Delta compression using 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 309 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
fileset-fascism rejecting commit d96669c0780e33b250af81404e263fc181fe0547
    non ./debian changes on a debian branch in this commit.
error: hooks/pre-receive exited with error code 1
To ssh://git.debian.org/git/pkg-php/php.git
 ! [remote rejected] debian-sid -> debian-sid (pre-receive hook declined)
error: failed to push some refs to 'ssh://git.debian.org/git/pkg-php/php.git'

as always, comments/feedback/suggestions/etc welcome

I've released version 0.5.2 of the aptitude package manager (release notes). You can download it from Debian's experimental archive, or from the aptitude package page. WARNING: This is an unfinished piece of software. Do not install it if you want a package manager that does everything you need perfectly all the time. It is buggy and incomplete. This update includes major changes to the resolver backend and a new and improved GUI frontend for the resolver: It also includes an assortment of other fixes and improvements. Click through to the release notes to see a list of what changed in this release, with screen-shots.

After describing my adventures with JNI on Android, I decided to write a proper doc on it, with detailed explanations and examples of native library usage. This doc, created using noweb, is now available online: JNI examples for Android.

I just noticed Matthew Palmer's Insane/Brilliant idea of the day: he proposes to use large sets of USB serial adapters with a sheevaplug as a cheap serial console server. As part of upstream on cereal, i feel obliged to mention that package as a tool for managing serial console farms like this. It's designed to run in a small footprint, stores timestamped logs for the consoles, supports concurrent remote access, and uses standard unix accounts (usually via ssh) to permit read and/or write access to each port. It has saved me exactly the headaches Matt describes many times. However, i've had trouble getting multiple identical USB serial adapters to persist at standard device file locations across reboot. That is, if you have four pl2303 devices from the same manufacturer, it seems to be a crapshoot which one will be /dev/ttyUSB0 after you restart your system. I could find no distinguishing data in the sysfs to get udev to persistently key off of, anyway. if you know a way to do it, i'd be happy to see it! Depending on how many ports you need, another alternative would be to use a sheevaplug with a multiport USB-to-serial adapter. While i haven't tried this specific hardware, it would remove the need for the hub, and potentially would mean you didn't need any extra power. I'm assuming that this device would give you persistent port naming, but i haven't tried it. Pricewise, it seems to be a win, too: $100 for the SheevaPlug and $100 for the 8-port adapter.Tags: cereal, sheevaplug

Duck number 1076783 since 1582.

I have a little job that runs on my web server and tells me what URIs people have tried to fetch over the last 24 hours which were not successful. One of these URIs was for a page that used to contain my first ever Linux device driver. That device driver is now obsolete and so there was little point in tracking down the code and putting it back in place, but I did think there was a story to tell, so today I wrote down what happened with this driver at the URI. Thanks to the magic of ikiwiki's "inline" directive, here it is in the log: This is a story about my first real attempt to contribute to the Linux kernel. The Davicom DM9601 is a cheap USB NIC that I picked up on ebay at some point in late 2006. Suprisingly, at the time, there was no driver for it in the Linux kernel. I'd had some experience hacking on the kernel whilst working for IBM and I've always wanted to get more involved, so I thought this would be a good opportunity. I searched around and managed to find a vendor-written driver for the 2.4.x kernel series, but nothing newer. I felt that the best approach would be to start porting this driver to 2.6, improving it along the way. I got to work, and after several hours I had something that would compile against 2.6 series headers, at least, so I put my progress online and wrote a short log post about it (dm9601). A really invaluable resource whilst doing this was LWN.net's "Porting device drivers to the 2.6 kernel". Once I had the code up there, kernel hacker Arnd Bergmann got in touch with me. He said, quite frankly, that my driver had a long way to go, but that he would be willing to help mentor me and guide me in improving it so that it would make it into mainline. This was fantastic news: this is exactly what people need when trying to get up to speed with the customs of something as complex as the kernel development community. Arnd sent me a long list of things I needed to fix. Whilst I had my code online I had several other people get in touch with me and provide things like device IDs for their NICs that they needed to add in order to get it to work for their hardware. Several weeks later, after implementing a good chunk of Arnd's suggestions, I had a driver that worked, at least a little bit, with 2.6, so I got back in touch with Arnd. Bad news, for me at least: Peter Korsgaard, another kernel hacker, had implemented a dm9601 driver from scratch over a weekend. Apparently he was at a friend's house, his friend had this device, he noticed there wasn't a driver in the kernel already and sat down to write it as a fun project. From scratch. In one weekend. This was a bit of a blow. I couldn't imagine having the skill and knowledge required to be able to pump out a driver like that, but I knew the first step on the road was what I was doing, and that road was now closed. I couldn't really blame Peter, I could only really feel quite jealous at his prowess, so that was the end of that. His driver was much leaner, much tidier, fitted the kernel programming style properly, and was thus accepted. However, for my hardware at least, it didn't actually work, and he didn't have access to the device after that one weekend, so he wasn't in a position to fix it. This situation lasted about 4 months from 2007-02-23, when Peter's driver was accepted, until about 2007-06-27 with this patch. From this whole experience, I did manage to get one small patch into the kernel: one which added the device IDs for my NIC and those of the people who had got in touch with me.

I've been talking serial consoles with a couple of the other guys at work: how nice they are to have for machines in the datacenter, how annoying it is that vPro serial-over-LAN doesn't seem to be robust (yet?), and how serial access concentrators are lung-and-kidney expensive (especially when you've got 50-some racks to outfit). This discussion, combined with my ongoing embedded-hardware-fascination lust for a SheevaPlug appears to have spurred my brain into coming up with a Brilliant Idea: tie a SheevaPlug to a pile of USB to serial adapters and use that as your per-rack serial concentrator. Imagine: faffenheimer, a dedicated server you manage for a customer, and located in rack 27 of your DC, has just crashed, and you'd like to know WTF has happened rather than just blindly reboot, but you're in the office 15 minutes away from the DC floor, and the customer's going to want that machine back up and running pretty quickly.

workstation:~/porn$ ssh rack27.serial
rack27:~$ sconsole faffenheimer
[screen session attached]
[minicom running, shows the horror of a kernel crash dump]
[oh look at that, kernel bug]
^A ESC
[pgup pgup]
[enter]
[pgdn pgdn]
[enter]
^A >/tmp/faffenheimer-crash-dump
^A d
rack27:~$ exit
workstation:~/porn$ scp rack27.serial:/tmp/faffenheimer-crash-dump ~
workstation:~/porn$ powercycle rack27 faffenheimer

Shiny! We got a crash dump in a minute or so (rather than having to take phonecam photos of KVM screens in the DC), never had to leave our comfy seat, and the machine's on it's way back up. We're now free to pursue diagnostic activities on that crash dump at our leisure. 10 minutes later, the downtime for faffenheimer that was automatically set when we ran powercycle runs out and Nagios sends us threatening messages. Hmm, something's gone wrong here. Back into the console...

workstation:~/porn$ ssh rack27.serial
rack27:~$ sconsole faffenheimer
[screen session attached]
[Boot is hung waiting for root password after initrd has bombed]
[Type root password]
[Oh look, the root MD appears to have come asunder]
[clickety-click... fixee fixee]
[reboot]

The more I think about this, the more I reckon I'm onto a bona fide winner. The sheevaplug is a powerful ARM-based system with USB/ethernet/SD ports that is packaged literally in it's own power supply wall wart -- it's a plastic box with power plug prongs poking out the side. That's all there is to it. The USB to serial adapter things are likely to be a bit more of a pain, but I've played with enough of them by now to not be too scared. So, you plug the Sheeva into a power socket, plug an Ethernet cable and USB hub into the Sheeva, configure things a bit so that the system knows which serial adapter maps to which machine, and you're away. Oh, and the best bit: the Sheeva apparently draws as little as 2W when idle. A whole datacentre's worth of serial goodness for about a server's worth of power. The cost per rack should be somewhere below AU$250, especially in bulk. Let's see if I can convince work to spring for a Sheeva, a USB hub, and a half dozen or so USB to serial adapters to test this whole thing out. Given that the whole thing looks like it'd cost less than AU$250 (plus my R&D time), I can't imagine it'll be too hard a sell to at least give it a go. Watch this space...

As you might know, as part of the Haskell Hackathon 5 in Utrecht, the second darcs hacking sprint took place. Thanks to generous donations to the Darcs project, I have been able to attend. I took the overnight train from Prague on Thursday evening interestingly, we managed to accumulate about 90 minute delay in Germany, but by skipping some detours (throwing passangers out at more convenient ones) we managed to get to Utrecht on time. (Wow.) After a while of confusion, we managed to get our strippencards and find the right bus and get to the UU campus (at that time, we have already met with Thorkil, whose train was combined with mine in the middle of the night somewhere in Germany). The first thing there was to get our name tags and a round of introductions followed I was fairly surprising by (large) number of darcs hackers among the general Haskell population present at the Hackathon. Overall during the sprint, various topics have been discussed ranging from theory issues to actual implementation bits in current darcs. Some roadmapping has taken place. It was great to see all those darcs people together. More interestingly, it sort of convinced me that actually something is going on with darcs. Although most people seem to be pretty short on time, at least I got the impression that people have actual intent to keep advancing darcs, in one form or other. Also, there s been some preliminary plotting on what is the life expectancy of darcs 2, roughly. My current plan is to use darcs 2 as an implementation vehicle, because people use it in real life, for carrying out the actual work on hashed-storage. That way, we should be able to de-couple low-level repository and file access code from darcs itself, also meaning it should be reasonably easy to plug it into camp later (or maybe it turns out we instead want to remodel darcs so that we can plug camp-core in time should tell). We have done some bits of work on darcsit (gitit) migration of wiki.darcs.net, although it hasn t been so much of a smooth sailing. I have even tried to set up gitit on one of my machines, but cabal-installed happstack went eventually crashing and burning instead of doing anything useful. I m stuck on that front, hoping that Eric and Gwern can get test.darcs.net running within reasonable resource usage. I have thrown a chat with various people about hashed storage and I have explained various problems of the current darcs hashed repositories and how hashed storage addresses those. Also, I have talked with Benedikt about his filecache and we entertained some initial thoughts on how those two play together. We have also spent a while at a whiteboard with Eric discussing what needs to be fixed in sources handling: the file that lives under _darcs/prefs/sources and that keeps track of related branches of a given repository. The catch is, that when inappropriate entries get into that file, bad things can happen: darcs repeatedly waiting for a nonexistent remote machine to answer, or triggering automount a few thousand times by probing just the wrong directory. These need to be remedied and we came up with a reasonable action plan. Hope to have this in 2.3, as it should be moderately hard to fix and it has potential to sweep a fair amount of silly and obscure performance bugs. All in all, it seems to me that the important part of the sprint this time was talking to people and thinking about things. Still, I did manage to get some hashed-storage coding done (but mostly cleaning up and documenting work) during the sprint. I expect the fruit of the sprint discussions to take shape in form of code improvements in following months.

Finding power and internet to post to a blog while hiking for half a year up the Appalachian Trail doesn't seem like a very likely combination, but nowadays some people manage it in various ways. I've read and enjoyed three or four books about AT thru-hikes, but blogs are a more immediate, interactive medium. I've been following with interest a group who came down with food poisoning as they hiked along the Holston Mtn. ridge in my "backyard" and look forward to reading about others as they pass by. So, I'm aggregating all such blogs I can find for the 2009 season on a page I call Planet A.T.. It's a nice way to read these contrasting accounts juxtaposed together in real time. One includes cell phone photos and fairly frequent updates of a hiker who's already reached Damascus; another is frequently updated by Blackberry by a guy I could well have crossed paths with on Roan this week; another has more infrequent, interesting long essays by a hiker who has just reached Tennesee; another is a teacher sending educational videos home to his school. There's even an 86 year old who I understand is the oldest person to hike the whole trail -- and is doing it again. I thought I'd only find a few blogs, but I've now added over a hundred! So maybe one in ten of all thru-hikers this year have a blog. And the number of bloggers will presumably dwindle toward twenty-five before they reach the end in Maine.

This is a continuation from before. I am digressing a little in this post. One of the things I want to get out of this exercise is to learn more about Ontologies and Ontology editors, and on the principle that you can never learn something unless you build something with it (aka bone knowledge), so this is gathering my thoughts to get started on creating an Ontology for package building. Perhaps this has been done before, and better, but I ll probably learn more trying to create my own. Also, I am playing around with code, an odd melange of my package building porcelain, and gitpkg, and other ideas bruited on IRC, and I don t want to blog about something that would be embarrassing in the long run if some of the concepts I have milling around turn out to not meet the challenge of first contact with reality. I want to create a ontology related to packaging software. It should be general enough to cater to the needs any packaging effort in a distribution agnostic and version control agnostic manner. It should enable us to talk about packaging schemes and mechanisms, compare different methods, and perhaps to work towards a common interchange mechanism good enough for people to share the efforts spent in packaging software. The ontology should be able to describe common practices in packaging, concepts of upstream sources, versioning, commits, package versions, and other meta-data related to packages. I am doing this ontology primarily for myself, but I hope this might be useful for other folks involved in packaging software. So, here follow a set of concepts related to packaging software, people who like pretty pictures can click on the thumbnail on the right:

• software is a general term used to describe a collection of computer programs, procedures and documentation that perform some tasks on a computer system.
• software is what we are trying to package
• software has names
• software may exist as
  • source code
  • executable code
  • packaged code
• source code is any collection of statements or declarations written in some human-readable computer programming language.
• source code is usually held in one or more text files (blobs).
• A large collection of source code files may be organized into a directory tree, in which case it may also be known as a source tree.
• The source code may be converted into an executable format by a compiler, or executed on the fly from the human readable form with the aid of an interpreter.
• executable format is the form software must be in in order to be run. Running means to cause a computer to perform indicated tasks according to encoded instructions.
• software source code has one or more lines of development. Some Common specific lines of development for the software to be packaged are:
  • upstream line of development
  • feature branch is a line of development related to a new feature under development. Often the goal is to merge the feature branches into the upstream line of development
  • usually, all feature branches are merged into the integration branch, and the package is created from the integration branch.
  • integration branch is the line of development of software that is to be packaged
• some software lines of development have releases
• releases have release dates
• some releases have release versions
• source code may be stored in a version control repository, and maintain history.
• Trees are a collection of blobs and other trees (directories and sub-directories). A tree object describes the state of a directory hierarchy at a particular given time.
• Blobs are simply chunks of binary data - they are the contents of files.
• a tree can be converted into an archive and back
• In git, directories are represented by tree object. They refer to blobs that have the contents of files (file name, access mode, etc is all stored in the tree), and to other trees for sub-directories.
• Commits (or changesets ) mark points in the history of a line of development, and references to parent commits.
• A commit refers to a tree that represents the state of the files at the time of the commit.
• HEAD is the most recent commit in a line of development or branch.
• A working directory is a directory that corresponds, but might not be identical, to a commit in the version control repository
• Commits from the version control system can be checked out into the working directory
• uncommitted changes are changes in the working directory that make it different from the corresponding commit. Some call the working directory to be in a dirty state.
• uncommited changes be checked in into the version control system, creating a new commit
• The working directory may contain a ignore file
• ignore file contains the names of files in the working directory that should be ignored by the version control system.
• In git, a commit may also contains references to parent commits.
  • If there is more than one parent commit, then the commit is a merge
  • If there are no parent commits, it is an initial commit
• references, or heads, or branches, are movable references to a commit. On a fresh commit, the head or branch reference is moved to the new commit.
• lines of development are usually stored as a branch in the version control repository.
• A new branch may be created by branching from an existing branch
• a patch is a file that contains difference listings between two trees.
• A patch file can be used to transform (patch) one tree into another (tree).
• A quilt series is a method of representing an integration branch as a collection of a series of patches. These patches can be applied in sequence to the upstream branch to produce the integration branch.
• A tag is a named reference to a specific commit, and is not normally moved to point to a different commit.
• A package is an archive format of software created to be installed by a package management system or a self-sufficient installer, derived by transforming a tree associated with an integration branch.
• packages have package names
• package names are related to upstream software names
• packages have package versions
• package versions may have
  • an upstream version component
  • a distribution or packaging specific component
• package versions are related to upstream software versions
• helper packages provide libraries and other support facilities to help compile an integration branch ultimately yielding a package

Umh, is today the quote your neighbour day? No? Thought so... Still, for the second time in a couple of minutes, I'm quoting/translating here. This time, I'm quoting a short text posted by fellow Mexican Debian guy Rodrigo Gallardo: Deceptions (hmm... Not in the let you down sense, but in the deceiving sense. Sometimes it is hard to translate a single word without twisting it around). My translation is far from perfect - Read it in Spanish, you will enjoy it more. Rodrigo says:

Things and actions are what they are, and the consequences of them will be what they will be; why then should we desire to be deceived? Joseph Butler

I was in Colima, sitting on a slide in a city park, that day I understood why somebody might want to be drunk. Several years later, this time in Tlalpan, I understood why somebody would want to believe in a god. And sometimes I am truly sorry not to be able to embrace neither of both longings. The idea of letting go the facts, to believe they have an inner order, although covered in mistery, or they are just far away, blurry. But where others see destiny, I see things falling naturally in their place. Where others see beauty in the mistery, I see a challenge. And even more beauty in an elegant explanation, in understanding. Motivation, not in the promise of future welfare but in the certainty of this limited but tangible present welfare. Freedom in the absence of a purpose, and inmortality in the little pebble I am in the great human building. I suppose that if Revernd Butler knew his phrase inspired this divagation, it would not make him precisely happy. But, things are what they are, and his argument says what it says.