I was pleased to learn through Christer Edwards of the existence of a sister project in Ubuntu to our Debian Eee PC project. I followed up on his invitation to drop in on their irc channel and introduce myself. I’ve been looking over the bugs listed on their TODO to see if any are applicable to Debian. Already I have filed #479217 based on the corresponding bug in Ubuntu, and have encouraged them to check out ours as well. I look forward to sharing more with them in the future so we can benefit from each other’s work.

People rarely ask me about my amazing ability to remove fruitfly ovaries in under 10 seconds. "This skill makes me strangely attracted to you" they then inevitably fail to add, thus giving the lie to claims that a PhD in biology is a great way to impress women. In order to avoid future social embarrassment I have therefore decided to provide a step-by-step guide to removing ovaries from any fruitflies you may have to hand.

• Feed your fruitflies. Fruitflies like yeast, so give them a pile to munch on. A well-fed fruitfly is a happy fruitfly.
• A happy fruitfly is a fertile fruitfly, and has bigger ovaries. Since fruitflies are small, this makes your job easier.
• Knock your fruitflies out with carbon dioxide. When doing this, ensure that you don't knock yourself out with carbon dioxide.
• Separate your fruitflies into male and female flies. Female flies have larger abdomens and striped posteriors - male ones are thinner and have solid black markings.
• Dispose of the males. They don't have ovaries. Local laws may make it awkward for you to release animals from laboratory environments, so dump them into a bottle of ethanol. They'll probably die happy, to the extent that fruitflies can really be happy.
• Etherise the female flies. When identifying ether, try not to do so by smelling it.
• Once the female flies are thoroughly dead, transfer one to a small watchglass containing a quantity of phosphate buffered saline with a small quantity of detergent in it. Place this under a low magnification microscope.
• Grip the neck of the fly with a set of needle-nosed tweezers. Grip the very rear of the fly with another set of needle-nosed tweezers.
• Slowly move the tweezers apart. If you are lucky, the abdomen will split and you'll start pulling out internal organs. If you're unlucky, the head will come off. In this case you should move the first set of tweezers further down the body and try again.
• Continue pulling out internal organs until you find two objects that look like bunches of bananas. These are the ovaries, with each "banana" being an egg chamber containing an egg and associated support cells.
• (If your fruitfly contains no ovaries, it's not a female. Try again)
• Carefully separate the ovaries from the other chunks of tissue that are stuck to them, and transfer the ovaries to a tube containing phosphate buffered saline.
• Repeat until you run out of flies. Note that towards the end, it will become tempting to just tear the flies into small pieces rather than removing their ovaries. Bear in mind that the aim is to obtain fruitfly ovaries, not to kill flies. There are much easier ways of doing the latter.
• Dispose of the remaining bits of flies in accordance with any relevant legislation. Do not throw remaining bits of flies at coworkers.
• Fix the ovaries in formaldehyde and suspend in methanol. Freeze at -20 C.

See? It's all very easy.

(Note: This protocol involves chemicals known by the state of California to cause cancer, birth defects and general fucked-upness. Do not ingest methanol unless you want to demonstrate competitive inhibition in the form of a bottle of vodka. Value of fruitfly ovaries may go up as well as down. Do not taunt fruitfly ovaries)

I made an emergency release of the chronicle blog compiler yesterday, after noticing that it was truncating titles containing periods. That was a bit of a mea-culpea moment, but I guess mistakes happen. The new release is in perfect shape for Lenny, and now includes two new scripts installed into the examples/ directory:

• The RSS-feed importer I mentioned prviously.
• A quick hack to detect duplicate post/entry titles.

The latter was applied to my own blog, and I discovered several duplicates. I guess my film quotes having only a limited source collection to work from could also include duplicates - so I've updated my Makefile to only build and rysnc my blog if there are none detected. (In many ways that films site is the precursor to this blog; it uses a collection of text files, one per film, and generates a cross-linked HTML output of film entries. Sadly it is out of date, because entering titles is a real pain..) Chronicle Comments

I'm pleased with the comment process now though, the CGI comment submission script simply archives each submitted comment into a "comments/" directory on the webserver. There a cron-job passes each one through a bayasian filter and moves the file(s) to either "comments/good/", "comments/bad/" or "comments/unsure/". When I come to rebuild the blog I rsync the "comments/good" directory to my local machine, rebuild and then rsync the output back to my remote webserver. (On a single machine this would be much simpler process!) I've imported my blog source into a mercurial repository, so the client-side is consistent. I have a bad habit of making new postings from wherever I happen to be and having a central repository will make that less prone to diaster. Just running "make steve" against the Makefile is sufficient to rebuild everything and sync it to my live system.

ObQuote: Kalifornia

Lets go on your nerves again with a ftpmaster post about work I’ve done in the recent past.

• The already mentioned move of britney. And it seems that this did help, so something that should have been done way earlier already… Oh well.
• Enabled a few triggers for the qa user on merkel. While I already mentioned them in my first post, there is a third one now. The qa user now gets notified at the beginning of the dinstall run, so the pages can show why packages might not be visible in the archive and in incoming right now.
• Split up the insanely huge mbox files we had as the ftpmaster mail archive. They got that big because the monthly cronjob rotating them got disabled when the ftp-master archive went away from raff, and noone bothered to reenable that job. Done now, so we are back to a manageable size. (Even if 90% of the content is spam, no matter how much greylisting and blacklists are activated :( ).
• Just committed a largish change thats nothing more than a cleanup. Someone in the past did love to not care about tab versus spaces for the indentation, so dak code ended up with a mess of tab/space mix for indentation. Which is not nice, one style is way better. Fixed that with the help of reindent.py, which one can find in Pythons examples.
• Got the code on security.debian.org to use the latest dak revision from ftpmaster. It was a few commits behind, but worse - it did have one dak tool changed in a way that it only worked on security, no longer on ftpmaster. Also some files that clearly have been copied by scp -r or rsync, but not using the VCS that should be used for it. Args. Brrrr. The “fix” was a simple check if that value the code wants to use from the config file actually exists, instead of blindly assuming it will always be there.
• Generally looked around on security.debian.org, to get more familiar with the setup there, so I can work on a request I got from some members of the security teams: Run a queue daemon that manages the upload of the packages from the security archive to the normal archive (so they end up in proposed-updates). Currently it is done with some lftp calls within the script that does the security install, and that seems to break every now and then. Which means security uploads to proposed-updates randomly go MIA. Using a queue daemon and then only locally copy files into its dir should make that way more reliable.
• Used a tool from Dato and enabled bzr commit mails for the ftpmaster dak tree, they are now going to the dak list.
• Modified the cronjobs that are expected to have output to log that into files in a new logdir. Also modified the cron.daily AKA dinstall cronjob to be more verbose about the actions done. The directory is synced to merkel too (log/cron in the ftp.debian.org tree), so every DD who wants to can look at them now.
• I also merged a small patch from Thomas, fixing/unifying some wording in reject messages.

Comments: 3

Just up on arxiv.org this week appeared Warming the early Earth - CO2 considered, by von Paris et al. Just a preprint, and i'm working through its 53 pages now, put its likely to put the cat among the pidgeons:

Abstract: Despite a fainter Sun, the surface of the early Earth was mostly ice-free. Proposed solutions to this so-called "faint young Sun problem" have usually involved higher amounts of greenhouse gases than present in the modern-day atmosphere. However, geological evidence seemed to indicate that the atmospheric CO2 concentrations during the Archaean and Proterozoic were far too low to keep the surface from freezing. With a radiative-convective model including new, updated thermal absorption coefficients, we found that the amount of CO2 necessary to obtain 273 K at the surface is reduced up to an order of magnitude compared to previous studies. For the late Archaean and early Proterozoic period of the Earth, we calculate that CO2 partial pressures of only about 2.9 mb are required to keep its surface from freezing which is compatible with the amount inferred from sediment studies. This conclusion was not significantly changed when we varied model parameters such as relative humidity or surface albedo, obtaining CO2 partial pressures for the late Archaean between 1.5 and 5.5 mb. Thus, the contradiction between sediment data and model results disappears.

The suspected composition of the eary Earth (the Archean, when life is believed to have started, 3.8 to 2.5 billion years ago), has alternated between CO2 and other reducing gases, such as methane. Originally CO2 was thought to be the main greenhouse gas, making life possible. However the high CO2 levels required were a problem; high CO2 levels would have created siderite (FeCO3) in the top layers of soil as iron interacted with CO2 in the oxygen-free air. Since then methane has top billing as the greenhouse gas responsible, with significant hydrogen levels a possibility. Over time, methane has come out on top. And thats what I wrote when I did my literature review for my PhD. Now I'm tidying it up a bit, and that section may be in for a rewrite. But what does it mean for our Climate change models of today? Tags climate, co2, thesis

Recently I had to deal with POST requests on mod_perl 2 on a custom XML-RPC webservice server we have been developing and maintaining over the last year (we are actually moving it to REST some time in the middle future). It was time to move some of our base modules from a couple of CGIs to the power and muscle of mod_perl. So, while dealing with POST requests (like XML-RPC is actually specified) I faced the issue that I wasn t being able to get the POST data on the PerlResponseHandler phase. I was probably not reading it correctly, I got deeply into it and even read some libapreq source code. All I was getting was some nifty message like not supported . After reading some documentation (and, to my own shame, the Apache2::Request front page pod) I found out that the usual:

    use Apache2::Request;
    $req = Apache2::Request->new($r);
    @foo = $req->param("foo");
    $bar = $req->args("bar");

will not work on your POST if the content type is different than application/x-www-form-urlencoded or multipart/form-data. For example, say, XML-RPC! So, in case you actually need to read POST data on your mod_perl 2 handler where it s not a form or a file upload, you can read the data manually (I didn t find a simpler way to read the data, actually):

sub handler  
my $r = shift;

return Apache2::Const::HTTP_BAD_REQUEST unless
		$r->method eq "POST" and
		$r->headers_in-> 'Content-Type'  eq 'text/xml' and
		$r->headers_in-> 'Content-Length' ;

my $length = $r->headers_in-> 'Content-Length' ;

my $xml;

while ($length)  
		$r->read($xml, ($length [less than symbol] 2048) ? $length : 2048);
		$length -= length($xml);
 

	...

And you are ready for booze.

John writes about PDFs and the problem of embedded fonts that are missing due to restrictive licencing. Font designers usually distinguish between "embedding" and "using" a font, prohibiting the former in their licence agreement. The difference is that when a font is "used", all information about the text is lost, and only rendering instructions remain (usually a set of Bezier curves). PDF allows you to annotate a rendered page in various ways, among other things, it allows you to specify that a certain region should be interpreted as a specific text. For example, OCR tools working with PDF files start with a file containing just the image data, and add the textual information, so you end up with a file that looks like the scan, but has selectable text. While that is certainly not legal advice, so far it has been considered acceptable to ship a PDF file with pre-rendered text and an annotation that facilitates copy&paste (which you also need with embedded fonts to allow selections to see ligatures like " " as two distinct characters). These files may be slightly larger than they would be with an embedded font, but have the advantage of looking exactly the same everywhere and at the same time, being trivial to render as the rasterizer does not need to understand anything about text layout. tl;dr: if you have a document that people should be able to see exactly the way you intended it, please include the text curves if you may not embed the font directly, and provide selection hints.

On sid dist-upgrading requires some handholding currently: (SID)root@argenau:/# DEBIAN_FRONTEND=noninteractive apt-get --purge dist-upgrade
[...]
Calculating upgrade... Failed
The following packages have unmet dependencies:
e2fsprogs: PreDepends: libuuid1 (>= 1.34-1) but it is not going to be installed
mount: PreDepends: libuuid1 but it is not going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. The reason is the recently started upgrade to perl 5.10. This makes many packages temporarily uninstallable, (including lintian) but perhaps you need to upgrade to perl-5.10 now nevertheless. apt seems to stumble over debconf-i18n,
apt-get --purge install debconf-english
lets dist-upgrade succeed.

A little while back, I wrote a blog post called DjVu: Almost Awesome, where I pointed out the strengths of the three DjVu family of formats, but lamented the fact that there was no Free Software to create DjVu files in the most interesting format, DjVu Document.

Well, now there is: pdf2djvu is out and works, and it's been ITP'd to Debian, too.

As a very quick recap, DjVu is a family of raster image codecs that often creates files much smaller than PDFs, PNGs, TIFFs, etc. It has a ton of advanced features for things like partial downloads from websites. It's pretty amazing that a raster format can create smaller files than PDFs, even at 300 or 600dpi resolutions in the output. Of course, for some ultra-high-end press work, PDF would still be needed, but DjVu is quite compelling for quite a few uses. Since it is a raster format, it is simpler to decode and is not subject to local system variations, such as installed fonts, like PDF is.

Which brings me to the scourge of PDF. Recently we got a trouble ticket at work from someone saying there was a bug with our Linux environment because Linux users didn't see the correct results when they opened his PDF file. A quick inspection with some of the xpdf utilities (pdffonts, to be specific) revealed that the correct fonts were not embedded in the file. The user didn't believe me, and still wanted to blame Linux, saying that it worked fine on his PC with Acrobat. So I tried opening the file on a Windows 2003 terminal server, and it looked worse there than it did with any Free Linux viewer -- really quite terribly corrupted. He still wasn't entirely convinced, until he happened to try printing the file in question, and even Acrobat couldn't print it right.

PDF was supposed to be a "read anywhere" format that produces exact results. But it hasn't really lived up to that. Font embedding is one reason; the spec lists a handful of fonts that are allowed to not be embedded, but it is routine for some reason to violate that and fail to embed quite a few more. Then you have to deal with font substitution on the receiving end, which is inexact at best. Then you have all sorts of complex differences between versions, and it becomes quite the mess. (And don't even get me started on broken PDF editors, such as the ones Adobe sells...) Somehow, quite a few people seem to have this idea built up in their heads that PDF is both an exact format, and an editable format, when really it is neither. (Last week, I was asked to convert a PDF file to a Word document. Argh.)

DjVu keeps looking more and more pleasant to my eyes.

Audit your debian uploads My bank is sending me an e-mail every time I log into the home banking system, so that I can spot malicious logins. My credit card is sending me a SMS message every time it gets charged, so that I can spot mailicious charges. Can I get a notification of every Debian upload done with my key, so that I can spot if my key has been stolen? Let's work on that. As a start, thanks to Ganneff, here is how to do a one-off audit:

# go to merkel to access projectb, which is the postgresql database
# with all dak information
$ ssh merkel
merkel$ psql projectb
# look up the database id of my fingerprint
projectb=> select id, fingerprint from fingerprint where fingerprint like '%797EBFAB';
 id                  fingerprint                
    -----+------------------------------------------
     394   66B4DFB68CB24EBBD8650BC4F4B4B0CC797EBFAB
    (1 row)
# get a list of all uploads done with my key, sorted by date
projectb=> select * from source where sig_fpr=394 order by install_date desc;

First you get to do it (done); then you document it (done); then you automate it. It's quite trivial at this point, so enjoy the new Debian upload monitor. It's got search as you type to find your full fingerprint, then you get an HTML page with the log of your uploads in the last 2 months, and the page has an RSS feed that you can use to track your own uploads. Also, generating all this static content is acceptably fast:

merkel$ time ./deb-key-audit 
real    0m7.145s
user    0m4.244s
sys 0m0.384s

If you want to see the code, you can git clone http://merkel.debian.org/~enrico/keylog.git Currently it wrongly encodes UTF-8 characters: I suppose the strings come out of the database as ASCII instead of UTF-8. A patch would be welcome to fix that. I will now contact QA to see what we can do with it; if it ends up fitting in some bigger picture then it may be that the RSS links will change, but I'll post about it in that case.

nion argued about the new Dilbert.com website now using flash instead of GIFs and I responded that it’s not as bad since Dilbert.com now also officially offers RSS feeds — without Flash. It looks as if Scott Adams got more responses from nion type people since he divides the feedback to the new Dilbert.com site into three groups: Those who are angry about flash and bloat (mostly techies and linuxers), those who are fine with the design and features, but angry about the slowness due to overload and those who are fine with the design and features and ignore the speed. I’m in none of these groups. But Scott Adams valued the feedback and responded especially to the first two groups of critics with something for which he couldn’t have found a better URL:

http://dilbert.com/fast With this pure Dilbert, nion should now be happy again. I still prefer the RSS feeds though.

I really don't think I have anything to add to Joel Spolsky's latest essay, on the horror of architecture astronauts. My favourite quote:

It sort of bothers me, intellectually, that there are these people running around acting like they're building the next great thing who keep serving us the same exact TV dinner that I didn't want on Sunday night, and I didn't want it when you tried to serve it again Monday night, and you crunched it up and mixed in some cheese and I didn't eat that Tuesday night, and here it is Wednesday and you've rebuilt the whole goddamn TV dinner industry from the ground up and you're giving me 1955 salisbury steak that I just DON'T WANT. What is it going to take for you to get the message that customers don't want the things that architecture astronauts just love to build.

In the recent interview with InformIT, Donald Knuth said:

I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you re totally convinced that reusable code is wonderful, I probably won t be able to sway you anyway, but you ll never convince me that reusable code isn t mostly a menace.

I have tried in vain to locate any place where he talks about this topic at greater length. Does anyone have a link?

These last two weeks most of my time has been sucked into getting Python 2.5 as default into testing. That’s done now. I made use of the block uploads thingie ftpmaster implemented for the release team to use. Basically, if your package could disrupt an “almost there” transition, the upload will be rejected. The blocks were in place for 5 days, which I think it’s acceptable. As long as we don’t end blocking stuff for very long, I think we should be fine. See the end of this post for more about this. Though it was quite a bit of work, I’m very glad I took care it myself, since now I really feel I’m 100% back to Debian, after the time I spent off for health reasons. Update: Oh, and I forgot to say: having control over britney has really really helped. Thanks a lot Joerg for that.

---

Dudesconf Tomorrow I’m leaving to Coru a for Dudesconf, which is a kind of Debconf-ES. I’m giving an introductory talk to Git, a semi-lighting talk about grep-dctrl (30 min.), and (gasp) a talk about Debian packaging with a VCS. We may have a Debian Quiz as well. I’m so looking forward to it, since many people who’ll attend are amongst my most loved ones, and I already missed last year’s since I wasn’t fully recovered yet. See you there!

---

Minirok and Sevilla One of the reasons I wasn’t fully back to release management during the past 5 months or so is because I spent as much time as I had doing development for Minirok. I don’t think I mentioned here before, but I was participating in a Free Software Contest for college students organized by the University of Sevilla, Spain. Such effort finally paid off, since Minirok was elected as one of the finalists. This means next week I’ll go to Sevilla, to make a presentation of the project, and who knows what more. ;-) I’m very excited.

---

Finally, more on blocking uploads This Python 2.5 transition was the first time the block uploads feature was used, and there were a couple bumps along the way. In particular, a couple packages were blocked, when they shouldn’t have been (libqt4-ruby and evolution-sharp), and one needed package was not blocked, though Rene Engelhard thankfully spotted it very quickly (mono). The problem is it’s not completely straightforward to generate a list of all the stuff that could possibly affect the transition. What I did was to make a run of britney on an arch that had all the needed bits in place, and block all the packages that migrated together as a result of the hint. This fails in two ways:

• it can include stuff that is not needed for the transition, namely unrelated packages that happen to become candidates for testing by one of the their dependencies having migrated as part of the hint. This is what happened with libqt4-ruby and evolution-sharp.
• it can miss stuff that is needed, like packages that can migrate by themselves, so the main run prior to the hint migrates them, and hence do not show up as part of the hint, but that some package of the transition depend on. This is what happened with mono.

The second problem, though, can be fixed by parsing the excuses list and blocking stuff that some bits of the transition depends on. Easy enough. Yet, there are more cases when things can go wrong, for example a shlibs-bumping upload of a package (say, sqlite3) linked against by some package still needing a couple of builds (say, qt4-x11). For that, blocking uploads is not an option, since that’d be an insane amounts of packages that, furthermore, can be uploaded if they don’t bump shlibs, so I guess we’ll have to ask in the next release update that shlibs-bumping uploads are coordinated in -release too, at least when close to finishing a transition.

A few weeks ago, NYU hosted an interesting event about the future of the Internet, appropriately tittled The Futures of the Internet, the video of which is now available here. One of the panelists was Jonathan Zittrain (who recently wrote an important new book bearing the same name as the event) and during the talk he provided a few ideas about how geeks and developers can help secure the Future of the Internet. While I agree with a lot in fact most of his assessments about the state and fate of the Internet as he lays out in his book and his talks, his characterization of geek/hacker/developer politics is not one of them. Basically, one of Zittrain’s claims is that developers are not doing enough to save the Future of the Internet and it is their rampant, Atlas-like libertarianism, which is, in part, to blame (first made 37:20 minutes into the video for those who want to listen to the actual comments). They have little-to-no political consciousness, are too cool to care about the fine print and they don’t care about the broader politics of the the Internet because they assume that they can just hack around any sort of barrier and impediment. While we can, without a doubt, identify a strain of libertarianism among hackers, it is by no means representative of all of geekdom and in fact, is becoming more and more a worn out 1990s stereotype/clich as time passes than an accurate representation of what is a far more variegated set of ethics and practices among hackers (and I will soon publish an article on this topic). It also completely fails to capture the ethical spirit as well as sociological, and political workings of one of the most important strains of hacking free and open source software which not only powers most of our (open) Internet but which in fact has provided a pretty hefty ethical backbone by which to conceptualize one of the ways we should think about the fight for the future of the Internet. Ok, time for a rant now Geeks not only designed the Internet, an indisputably revolutionary medium, but also implemented, and continue to maintain it, and then in their copious spare time, also engage in fighting back the political, legal and corporate encroachment which threatens to limit the very revolutionary nature of the Internet (as Chris Kelty’s new book on Free Software argues). If these acts by geeks are not enough political action, then maybe the development of not just one, but multiple entirely open and free alternatives to the only two proprietary operating systems that exist today might be a political act that would satisfy? Many would agree that even simply using a free operating system is a political act. It would be better to claim that individuals, lawyers and other political actors are not doing enough to save the Future of the Internet, rather than imploring the already overtaxed geeks to set aside everything that they are already doing to do something even more. (end rant) It also seems that when it comes to political questions related to the Internet, net neutrality being the hot topic now, or fighting restrictive and problematic laws like the DMCA, one of the only groups of people (outside of lawyers and librarians) to actually understand and dissect the fine print (and geeks actually are pretty attuned to and like to dissect the fine legal print), to protest these unsavory laws, and to support the organizations who are doing something about it (like the EFF), are geeks and hackers. While many geeks are not necessarily keen on conceptualizing their labor in traditional political terms, or aligning their technical projects with a political affiliation, and yes would rather just be writing good code, they do fight for their productive freedom and this productive freedom just happens to relate to most questions and concerns related to an open, accessible, and tweakable Internet, built by the geeks, lest we forget What was perhaps most surprising was that he also seemed to think that geeks and developers have not turned to “apprenticeship,” nor policies and procedure to coordinate their development projects, unlike Wikipedia, which he considers a shining example that geeks should look towards as a beacon of policy that geeks should consider emulating in their projects (comments made answering my question). He clearly has not been hanging out with any Debian developers in the last 10 years nor has he gone through their New Maintainer Process In other words, he seems to think they are allergic to regulation due to their accentuated libertarianism, or are against structure because of their anarchism, neither which is remotely true. I think I found this characterization most ironic and problematic for before Wikipedia was even an entry on a Wiki, projects like Debian (and most other F/OSS projects) were transforming and changing to integrate normative procedures and policies that allowed a group of people to work together, scale, grow and deal with crises’. No, they don’t have the Wikipedia badge system, but that system is emblematic of Wikipedia’s own transformation into integrating its own normative procedures and policies for working together, not an example of an idealized policy system that other projects are too primitive to have evolved into yet. About one hour into the talk when questions opened up, I objected to his characterization, but given his answer back to me, I did not make much of a dent in his thinking. Another lawyer Tim Wu (who also wrote a wonderful book on the Internet) chimed in to give me some props and also made a good point that even if geeks are the only groups of people who would storm AT&T and know intimately about the importance of net neutrality, there is a lot of room for thinking about how to strengthen and improve the tactics and politics among geeks and developers so that we can ensure the type of open and generative Internet and set of technologies we value. As part of thinking and rethinking new strategies, it is as key to acknowledge and honor the past. In this regard, free software development has been pivotal both in terms of providing software (and making it is an important political act as is choosing to use free software over propriety software) and a set of important set of ideas that a lot of lawyers like Yochai Benkler and Lawrence Lessig have run with to make some important political claims of their own. So despite my rant above, which was a rant and thus exaggerates things to some degree, I do think there is much more that geeks and non-geeks can do, such as help translate these uber-geeky issues into less geeky terms (and actually this is already being done by some geeks as the work of Jelena Karanovic has shown, or translate the technical issues into new domains as the uber-geek Karl Fogel is doing with question copyright but first lets give credit where credit it due and recognize that labor is political

With Hans Reiser convicted for murder, some seem to feel that reiserfs is more or less dead. Jason Perlow writes a very strange article on ZDNet to which I'm replying to it mainly because he alludes that Debian so far has failed to react. First, default installations of Debian create ext3 and not reiserfs filesystems (Please correct me if I'm wrong. I've just recently installed a fresh etch, but I didn't specifically look at the fs.) And even if it were reiserfs (v3), I don't see why a reaction would be called for now. The stability of reiserfs has come up every once, before the whole murderer story begun, and that the interaction between the reiserfs developers (including, of course, Hans Reiser) and the kernel team were always difficult has also been known for a long time. This is the kind of reason where I think it's appropriate for Debian to take steps (i.e. switching to a different filesystem), not a single event, where it is not even clear yet how the reiserfs (v3 and v4) efforts will move on. On to the technical stuff: Perlow tries, but doesn't really arrive at understanding the issues he's writing about. Reiser 4 is discounted without a single remark on its technical merits (I can't comment either as I have not looked at it so far.) Why he discounts ext4 is not clear to me (because it is not ripe for production use yet — but that's even more true of ZFS and this Linux-NTFS thingy he rambles about further down...) He discounts JFS2 because it hasn't got a new release for several years (is that bad in a filesystem?) but then touts ZFS as a great idea with minor licensing problems, without speaking of patents which is where the real problems lie (not to mention the fact that the Linux ZFS port probably is much less tested than ext4 or JFS.) And in a final jump into fantasy-land he mentions that NTFS might just be ideal for Linux, and Microsoft is said to have started cooperating nicely with the Free Software world, so all licensing and patent issues are certainly going away Real Soon Now™. At least for Novell, these issues shouldn't be a problem, I guess. Not mentioned by Jason are btrfs (which has a quite tightly coupled network filesystem brother, crfs and is in a very early state of development), and hammer, which comes from the BSD world and currently lacks a Linux port. Both efforts are probably more likely to replace ext3 or reiser on Linux than both ZFS and NTFS: no patent issues, no license issues, and the development is actually done by a community and not a single company. Update: Julien Blanche ha a much more succinct response to Jason Perlow. More intersting to read than mine, too.

Here's a nice toy I added to mpdtoys this evening. vipl allows editing mpd's playlist in a standard text editor. Reorder or delete songs, etc. Enter ">" in front of the song you want to play. Type in partial song, album, or artist names and it will expand them to any matches. :wq to start the music playing.

After three years, a new version of ocaml-gettext is out. I know that the delay is quite long... Been too busy to do anything regarding this. This new version is mainly a bug fix release:

• UTF-8 is better handled when merging PO/POT
• multi-lines, special and continuation comments of PO file are supported
• camomile implementation is now safer (less chance to fail if something goes wrong)
• improve overall build system

However, the major event of this release is the fact that it is now compatible with OCaml 3.10.0. This is a big news, because string extraction heavily rely on camlp4, which has changed a lot. I have also uploaded a debian package of ocaml-gettext. Plans for next release:

• website has not been updated because generating it is too much complicated, i should switch to something more simple layout and generation scheme
• my home-made build system is not good at all (fail to detect changes and do incremental rebuild...), next release should move to ocamlbuild
• PDF generation has been disabled, because it makes fop produce a lot of errorrs, it should be re-enable
• finish the patch to xgettext to allow OCaml string been extracted

Homepage Download

In the last week, Nicholas Negroponte gave this unfortunate interview decrying "open source fundamentalism" and hinting the possibility of a warmer relationship with Microsoft. Predictably, this has elicited an ongoing response by OLPC News and on the OLPC development mailing lists. Just a few days before Negroponte's statements hit the press, I gave a talk at Penguicon called Laptop Liberation where I talked about why I thought that OLPC's use of a free software operating system and embrace of free software principles was essential for the initiative's success and its own goals of education reform and empowerment. I've been saying similar things for some time. My main point boiled down to something that, appropriately enough, Nicholas Negroponte was fond of saying back when the project was still called the $100 laptop: an extremely cheap laptop is not a matter of if, but of when and how. This technology will define the terms on which students communicate, collaborate, create, and learn. These terms are dictated by those with the ability to change the software -- by those with access to computers, the source necessary to make changes, and the freedom to share and collaborate. Constructionism -- OLPC's educational philosophy -- is about putting powerful tools and control over those tools into the hands of learners. It is about learning through exploration and creation -- about shaping one's own educational environment. Constructionist principles bear no small similarity to free software principles. Indeed, OLPC's stated commitment to free software did not happen by accident. OLPC convincingly argued that a free system was essential for creating a learning environment that could be used, tweaked, reinvented, and reapplied by its young users. Through these processes, the XO becomes a force for learning about computation and an environment through which children and their communities can use technology on their terms and in ways that are appropriate and self-directed. We know that laptop recipients will benefit from being able to fix, improve, and translate the software on their laptops into their own languages and contexts. Much more importantly, however, are all of the uses for the laptops that OLPC has not -- and can not -- think up. OLPC is a powerful tool for learning, but ultimate power is only in the hands of those that can freely use, change, and collaborate in defining the terms of their learning environments. In its commitment to software freedom, OLPC chose not to be arrogant by assuming that it knows how its users will use their laptops. Flexible environments designed for constructionist learning and a free software platform protect against this arrogance. Constructionism and free software, implemented and taught in a classroom, offer a profound potential for exploration, creation, and learning. If you don't like something, change it. If something doesn't work right, fix it. Free software and constructionism put learners in charge of their educational environment in the most explicit and important way possible. They create a culture of empowerment. Creation, collaboration, and critical engagement becomes the norm. OLPC does not get to choose if educational technology happens. If we work hard at it though we might get to influence the "how" and the "who." Proprietary software vendors like Microsoft want the "who" to be them. With free software, users can be in power. What's at stake is nothing less than autonomy. We can help foster a world where technology is under the control of its users, and where learning is under the terms of its students -- a world where every laptop owner has freedom through control over the technology they use to communicate, collaborate, create, and learn. This, to me, is the promise of OLPC and its mission. It is the reason I've been involved and in support of the project since nearly day one. It is the reason I left Canonical and Ubuntu to come back to school at MIT to be closer to the then nascent unincorporated project. It is the reason that OLPC's embrace of constructionist philosophy is so deeply important to its mission and the reason that its mission needs to continue to be executed with free and open source software. It is why OLPC needs to be uncompromising about software freedom. As an adviser and sometimes contractor to OLPC, OLPC does not need to listen to me. But I hope, for all our sake, that they do.

Update: Richard Stallman and the FSF have published another essay on the same topic focused more on pure free software (i.e., less education specific) objections.

The recent announcements by McCain and Clinton of their support for a temporary repeal of the Federal gas tax make me sick. More on why later, but first, I want to put forth my idea. I think both Republicans and Democrats would like it -- as it's based on market principles and achieves a reduction in costs to the average household, while simultaneously helping the environment and reducing our dependency on foreign oil. But of course, it's courageous, and we don't have many politicians of that type anymore.

What we need is a large, revenue-neutral, gas tax increase. Now, before people go nuts, let's explore what this means.

Revenue-neutral means that it doesn't result in a net increase of monies going to the government. The increase in the gas tax rate is offset by a decrease in the income tax, tied to the cost of direct and indirect taxable gasoline each family or business consumes. So on day 1, if you cost of filling up at the tank goes up by $10 in a week, if you are an average family, your total paychecks also go up by $10. Your cost for receiving a package might go up by $1, and your paycheck goes up by the same amount. So you're no worse off than before -- if you're average.

Let's look at the pros and cons of this sort of plan:

• The economic incentive to be efficient consumers of gas is magnified. This will eventually lead to Americans having more money in their pockets, increasing market incentives for fuel efficiency, and a decreasing (or increasing slower) price of oil as demand slows.


• Economic incentives to use mass transit, live close to urban centers, or drive fuel-efficient vehicles are magnified. Likewise, the economic incentives to invest in mass transit and efficient automobiles are also magnified.


• As more efficient technologies come on the market, and Americans decide that they'd like to pad their bank accounts by hundreds or thousands of dollars a year, more sustainable and environmentally-friendly development patterns will emerge. Also, the price of oil will be kept low. Of course, people that choose not to change will, on average, be no worse off than before.


• Alternative choices to the automobile will have a greater incentive to develop. Think the return of a fast, speedy national passenger and freight network, greater mass transit options, etc.


• The marketplace will drive Detroit to love making fuel-efficient vehicles, because they will be the new profit centers.


• This sort of thing is known to work well in other countries around the world.

If we think more long-term, we see even more positive effects:

• The return to local agriculture and manufacturing. Due to lower transportation costs, local farmers and manufacturers will be able to undercut Walmart's prices due to the larger relative costs of Walmart's much-vaunted national distribution network. Unless, that is, Walmart starts buying local -- which is a good thing too. This is a good thing for American jobs.


• Keeping all that oil money in the domestic economy is a good thing for American jobs, too.


• Our businesses will have a jump start on being competitive in the increasingly carbon-regulated global marketplace.

As for the cons:

• Eventually this will lead to a net reduction in Federal revenues as efficiencies develop in the marketplace and people save money on gas. Corresponding budget cuts will be required. (A good thing, I figure)


• Implementing this all at once would be a shock to some people living inefficiently now -- those that are far above average. It would have to be implemented gradually to avoid being a shock to the economy.

Now, for the McCain/Clinton plan: it's a farce. Reducing the gas taxes means more efficient gas, which means more consumption of gas, which in turn leads to -- yes -- higher gas prices. Its real effect will be minimal, and is a terrible long-term policy. It charges tens of billions of dollars to the national credit card (which we, and our children, will have to repay) while achieving almost no benefit now. It's a gimmick through and through, and something that says loud and clear that neither candidate is on track for the "Straight Talk Express".

Update 4/29/2008: One potential solution for the problem of declining revenues over time is to periodically re-index the averages to mirror current usage. Assuming this does really lead to the expected drop in consumption, there is no sense in 2020 of paying people for how much gas they would have used in 2008.