So I usually don’t announce my publications on my blog and for various reasons. The main one is that I am more than a little embarrassed that some of them are behind walled gardens (but being I am a junior prof, I am not in a position to negotiate otherwise). Otherwise, some of my pieces are semi-jargony (in the academic sense) and may not be of interest to readers who I think are more geek than academic. Finally, the process of publishing is so slow, so long, and so painful, I try not to think about it, much less write about it, if I can help it. But I decided to announce this
piece , which is on hackers (surprise surprise) as it might be of interest to some readers and because people can download it for free here for the rest of the month (but registration is required ) Co-written with Alex Rex Golub, I am pretty happy to see in print although it is far more academic in its tone, argument, and language than most of everything else I have written. This is in part because the article is more theoretical than ethnographic (hence the journal, Anthropological Theory) and tackles the question of liberalism alongside hacking. It seeks to demonstrate that these can be talked about 1) together and in cultural terms 2) that we we can identify some cohesive elements to hacking and liberalism, in part by placing them in conversation with each other 3) and yet we can also locate plurality and diversity within liberalism and hacking as well. This is a lot to tackle and cover in one piece under 35 pages and I am sure it could have been pulled off better but I think it is is a decent start to thinking about these questions. If you are interested but are allergic to academicalese, sticking to the Introduction, the Hacker Ethical Practice: Three Examples section, and Conclusion, will give you a taste of the arguments while avoiding most of the jargon. The irony of this article is that even if it hits at some pretty theoretical issues, it was provoked by a mundane conversation and disagreement I had with one hacker, Karl Fogel, over another hacker, Kevin Mitnick. After returning from the hacker conference, HOPE, I had dinner with Karl and told him about Kevin Mitnick’s keynote speech, which I found particularity enjoyable and entertaining. After calling Mitnick a hacker, Karl responded with the following: Kevin is not hacker. He is a cracker. Though I think I convinced him that cracker may not be the best word for him (and he convinced me there are differences between hacking, noting perceptively that his primary motivation seemed to be getting access to something he wasn’t allowed to have access to that is, it was more about breaking the rules and the thrill of crossing a social line, than about learning a technical system. ), I decided that I wanted to write a piece that squarely addressed tensions and differences among hackers instead of whitewashing them away as most authors, journalist, and even some hackers do.
Although most of the time, it seems like it is the Karl-type hackers who accuse the Mitnick-type hackers of not being true and authentic, recently I have been in a few situations where the tables were turned. For example, last year I was having coffee with a 2600-type who insisted that hacking on Linux was not hacking at all (not innovative enough, according to his world view). Another example I came across was in a recent Phrack issue where the prophiled hacker, the Unix Terrorist, takes a swipe at (well honestly at everyone and everythin) but when he is talking trash about who is and who is not a hacker, he singles out F/OSS developers:

Linus Torvalds isn’t a hacker! Richard Stallman isn’t a hacker! Niels Provos
isn’t a hacker! Fat/ugly, maybe! Hackers, no! And what is up with
the use of the term “cracker”? As far as I’m concerned, that term
applies to people that bypass copyright protection mechanisms.
Vladimir Levin? HACKER. phiber optik? HACKER. Kevin Mitnick? OK,
maybe a gay/bad one, but still WAS a “hacker.” Hope that’s clear.

Of course, one can play the game of defining the authentic hacking (and it makes sense for many to do this!) but my interest as an anthropologist has never been to draw a bright and clear boundary between good hackers and bad hackers. or “real and fake hackers,” but instead to describe and grapple with the tension points and internal ambiguities among hackers (my whole course is designed around this theme, in fact). This is not to say that anything goes in the world of hacking (that is, I don’t consider any computer break in a hack; I often just call it a crime) but if there is a group of people calling themselves hackers and thinking to some degree of the ethical implications of their actions, as an anthropologist, this is enough “social evidence” to start asking some questions about the political and cultural significance of their actions.

I finally got around to getting myself a new mobile phone, as it looks like the Android phones may take a while to arrive here in Europe, unlocked, and my old phone was fading. I ended up selecting a Nokia 6120 in order to get something that runs Symbian, which has a decent amount of apps above and beyond the Java ME stuff. So far, I'm fairly happy with the phone. Here are some notes:

• It's small and light. Nice!
• It runs Java ME (J2ME) applications surprisingly slowly. I'm non-plussed by this. And no, it's not just Hecl, even ShopList, which is quite simple and small (~ 6K), takes several seconds to start up. This is not appreciably faster than on my cheap phone from several years ago.
• My old, cruddy phone was able to recharge (slowly) via USB. This one doesn't, as far as I can tell.
• I bought it from Amazon.de, and the bozos who were the 'real' sellers sold me a phone intended for the polish market, meaning the dictionary languages installed are all eastern European - no Italian, which I need. Not the phone's fault though, and I guess it's probably possible to replace that stuff.
• The camera has some weird issues where it leaves streaks. I realize that it's only a phone camera, but it ought to be able to do better. Here's an image from my recent trip to Oslo, by way of example:

• Creating videos wors pretty well though.
• Playing video is just a bit jerky - it mostly keeps up, but not 100% of the time, when you lose a few frames.
• Nokia ought to do a better job making sure that it's integrated with Linux (Ubuntu in my case). That said, things work quite well, by and large, and I was able to get things done with relatively little fiddling.
• The amount of progress over a few years is very impressive. This phone completely blows my old phone out of the water. Sure, it's a bit pricier, but it's way more capable.

All in all, I'm happy with it, but I think that my next phone will be some kind of Android-based device, as that system is way more hackable than Java ME, and the people developing it seem to 'get it' a bit more. That said, I'm glad I got it - I needed something modern to play with Hecl on, and hopefully I will be able to work on using some of the fancier bits of the phone from Hecl. Oh, and by the way, I'm always on the lookout for phones to try Hecl with - even if they're old and worn out, the only thing that matters is that they are able to run Java ME applications. Contact me for shipping information:-)

I've just started a new job, so I decided to take a few days holiday in between and work on something that's been on my todo list for way too long now -- making the debian-installer work on the D-Link DNS-323. After a couple of days of work, I've just finished off the install of Debian on my DNS-323, which I initiated by loading a firmware image into the web interface of the stock firmware, and then SSHing into the machine at the appropriate moment. What this means is that anyone with a DNS-323 can install Debian on it. I think that's worthy of a small, quiet "woo hoo!"... Looking back now, it seems to have been a fairly simple and straightforward operation, but I can remember that it didn't look so simple when I started a week ago. So, in the interests of perhaps short-cutting someone else's adventure into the world of d-i hacking, I'm writing everything up while it's fresh in my mind (the benefits of being on holidays -- plenty of time to write long blog posts). Alternately, if anyone has a random device they'd like to see d-i on but doesn't have the inclination to do it themselves, feel free to send me one and I'll do it for you. Before I begin, I've got a few "shout outs" (I think that's what the cool kids are calling it these days) to people who've helped me along the way. First off, Martin Michlmayr has answered innumerable dumb questions from me, and I think wrote most of the parts of d-i that I've extended -- it's fair to say that I'd have had no hope of doing this without him. Thanks also to the people in #debian-boot and #debian-arm for answering questions and putting up with my frequent bouts of self-congratulation whenever I passed the most miniscule milestone. Finally, everyone who has put work into d-i has my thanks, too -- it's not perfect, but it's a damn sight better (both to use and also to hack on) than any other installer I've ever met. So, without further ado, off we go... Work out how to get a console Unless you are a guru of unbelievable skill, you will undoubtedly not do everything quite perfectly the first time, and you'll want to see the kernel/init boot messages, and maybe in some cases try some investigation and diagnostic work. For that, you're going to have to have some sort of console access. If the device doesn't have a full screen/keyboard thing going on, the chances are you'll almost certainly end up with a serial console. A few devices have a network management thingo that will give you a console, usually over VNC or some sort of horrid Java applet, but I've only ever encountered that in rackmount servers, which have a keyboard/video interface anyway... In theory, I suppose, the kernel could provide a network console, but I've never heard of such a thing being attempted, and Google is not helping me out. I might add that to the todo list as a future hacking project... On the DNS-323, it was a serial console that was needed. Like a lot of the embedded devices I've seen, it didn't quite talk RS-232, so I needed an adapter (I got a TTL-232R-3V3 USB-to-3.3v-serial adapter from a local electronics supply place, which worked perfectly with Linux as soon as I plugged it in). I needed to solder a few wires to a connecter inside, and connect that up to the USB doohickey, but it all came good in the end. The chances are someone's done a similar job for your device of choice, so a search for things like "devicename serial console" will almost certainly pay off. Work out how to load and boot a kernel/initrd Your development work will involve booting weird kernels and initial ramdisks to make everything work; you need some way of stuffing those into the device and booting from them. Everything has a boot loader of one sort or another; working out what you've got and how to make it sing and dance is the ultimate quest here. How this is done will vary greatly from device to device; the WRT-54GL, for example, waits for a tftp connection for a couple of seconds on startup, which you can use to send a new firmware; many other devices have a boot loader that you have to explicitly control (via the console), but it will make a tftp connection out to another machine if you ask it to. Some devices you just need to load the data in via serial cable (at 115200bps it's bearable; at the 9600bps I've heard some devices work at, it would be tres painful). The DNS-323 runs uBoot as the boot loader, which will do a tftp request by default. However, D-link, or Marvell, or someone in the decision-making chain for this thing decided to knobble it and removed most of the useful commands, so sending the thing via serial port is the only option. Since writing to flash takes a pile of extra time, I found (eventually) that you can just load the data into RAM somewhere and boot from there, without needing to write it to flash (also handy to avoid wasting precious write cycles), since you can tell uBoot to boot a kernel located anywhere in the address space. Obviously you need to reload the kernel/initrd on every boot if you don't write it to flash, so if you've got a "stable" kernel or initrd that you think you'll be using for a while (when you're testing the other item) you should flash it then. One note on uBoot, that took me far too long to work out -- you can't just stuff a kernel fresh off the Makefile in and assume it'll work -- uBoot needs a special header prepended that tells it all about what you're loading (architecture, file type, compression method, etc). You "wrap" a file in this uBoot header with the "mkimage" command (in the uboot-mkimage package in Debian). Incidentally, if you need to remove the uBoot bits from a file, just strip the first 64 bytes off -- that's all the uBoot header is, so something like this will do nicely:

 dd if=file.uboot of=file bs=64 skip=1

A final uBoot warning: it's fairly important to specify a "load address" for the files; if you get them wrong, your kernel and initrd may or may not boot (I never quite got the hang of why some wrong values worked and some didn't). If your device uses uBoot, and you have the ability to extract the uBoot-enabled kernel and initrd from a vendor-provided firmware image, you can use mkimage -l to inspect what all the values need to be for your own kernels and initrds. Just stick with them. Does Debian support your hardware? Obviously, if you want to run Debian on something, Debian has to support that hardware. The easiest way to test this out is to try an install. For this, you'll need to retrieve an appropriate kernel and initrd pair for the installer. Some arches, like i386 and amd64, only have one kernel and initrd for the installer, so you just have to choose if you're going to netboot, or do a full CD install, or whatever. Other arches, though, like arm, have subtly different images for different machines. There are two reasons they vary: firstly, they often need to split into subarches, where they all share a general CPU architecture but there are enough differences in the hardware that they're not all supportable by the same kernel. At a more fine-grained level some different machines of the same sub-architecture need differently formatted firmware images to boot. On ARM, in particular, it's pretty common to need to prepend a "device ID" to the kernel image so that the kernel knows what sort of machine it's booting on, which means that every machine typically needs it's own kernel image, regardless of any other issues with firmware formats. Choosing the sub-architecture should be relatively straightforward, if you know much about the machine you're targetting. Picking a machine type can be a bit harder, but again, if you know what your boot loader needs, it shouldn't be too hard to find a kernel/initrd from the existing machines in your subarch that you can mangle to fit. Load up your kernel/initrd into the device, boot it, and see how far it gets. You might get lucky, and the kernel inits, your hard drives are detected, your NIC is initialised, and you're off and running without further ado. Or you might not be so lucky. The worst case is that the kernel doesn't even get as far as loading the initrd -- it might not print anything at all, or the kernel might hang part way through the boot. This is likely to require a fair amount of debugging fun, as initial boot failures get a bit tricky. A better situation is where the kernel boots OK, and d-i starts, but something in the install process falls over. This can either be a kernel/driver problem, or a d-i problem. Either way, since d-i has started, you're likely to be able to get a shell and do some debugging. In order to make d-i work, you need to have somewhere to install to (disks, usually) and a source of packages to install from (CD/DVD if you're on a suitably large device, or the network otherwise). These are the two key ingredients you need; most everything else is stuff that ranges between "nice to have" and "critical" for operational purposes, but which has absolutely zero impact on your ability to do the install, so we'll ignore it for now. For the DNS-323, I had a few kernel problems (which I'd been warned about by Martin before I started) -- the NIC wasn't initialised with it's MAC address, which meant it was running around my Ethernet screaming "I am 00:00:00:00:00:00! Ph33r m3!", and the SATA controller just didn't seem to exist at all. These were kinda critical to doing an install, so it was time to get hacking to make those work. There were also a couple of parts of d-i that needed tweaking -- the preseeding code didn't support the device, and I needed to package a tool to build a "complete" uploadable firmware image and teach d-i how to use it. Apart from that, though, things were looking pretty good. Make the Debian kernel support your hardware Once you've worked out what hardware you need to make work, you need to dig into the kernel and fix it. Sometimes, if you're really lucky, a kernel version newer than the one currently in Debian has better support for something, and you can backport the fix / feature improvement. Other times, there's something similar already in the kernel for a different device and you can crib off that (I did this extensively for my little fixes). Then there's the "ask an expert" school, where you find someone who knows what they're on about and pick their brain (I did a bit of that, too). Finally, there's plain old "research and development", for which there are piles of documentation already out there. My changes for the DNS-323 came to 121 added lines and 16 deleted lines, most of which was cribbed-and-tweaked from other parts of the kernel. I might have written 10-20 lines of code "from scratch". It's not always scary-hard. Cross-compiling your own kernel One thing that I think needs mentioning in the kernel hacking department is cross-compiling a modified kernel for testing purposes. Chances are your main workstation has a lot more grunt (and build tools) than whatever you're trying to get Debian onto, so cross-compilation is the way to go. You need to first grab a copy of the source you want to build (from apt-get source linux-image-blahdiblah, or a release tarball, or Linus' git repo, it doesn't really matter) and a cross-compilation toolchain. For my cross-compilation toolchain, I just added this to my sources.list:

 deb http://www.emdebian.org/debian/ unstable main

then I ran apt-get update, and installed these packages:

	binutils-arm-linux-gnueabi gcc-4.1-arm-linux-gnueabi
	gcc-4.3-arm-linux-gnueabi-base libc6-dev-armel-cross

Kudos to the emdebian team for making that such an utterly painless exercise, by the way -- the days of needing to faff round with gcc sources to get a cross-compilation toolchain are apparently over. Once you've got a source tree and a cross-compiler available, you can run any of the usual kernel make commands (like make zImage or make oldconfig), as long as you've got a couple of make variables defined. In my case, I used:

 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-

ARCH tells the kernel what architecture to build for (useful in all make commands because not all arches have the same config options in make menuconfig, for example) and CROSS_COMPILE tells the build system what to prefix the calls to gcc, ld and such with (if you installed the same cross-compiler packages as I did, you'll find it installs files like /usr/bin/arm-linux-gnueabi-gcc, so you can ls /usr/bin/*gcc to find out what you'll need for the CROSS_COMPILE setting). Hack d-i to make things work In addition to tweaking the kernel, it's quite possible that the internals of d-i might need some tuning. It's possible that d-i might need to be "taught" to recognise the hardware in your device, or you'll need to extend some aspect of the installation process to complete the installation. In order to hack d-i, you need to know a bit about how it works and how it is structured, so let's run through that first. The entireity of d-i is based around udebs, which are packages of the same format as "real" debs, but which have been built differently (against a small libc, for instance) and have had everything that isn't absolutely necessary (docs, non-essential scripts, extra functionality, etc) stripped out of them to create the smallest possible packages. There are a variety of different udebs -- most are derived from otherwise normal, law-abiding citizens of the archive, like busybox (basic unix utilities like cp and ls), the shell that's used in the installer, parted, various libraries, and so on. Others are "special", and have no big brother in the archive. These are mostly "task" udebs, that define what actually happens in the installer. When they're "installed", they have special fields in the package metadata that define where in the install sequence they go, and they end up on the menu you see if your installation goes a bit pear-shaped. The tricky thing about udebs is that, as small as they are, there's too many of them to be able to have them all available when the system first boots, so even the "setup" of the installation gets done in several stages. First, the kernel and initrd boot. The initrd contains just enough stuff to get access to the rest of the udebs, and nothing else. Even this early stage is built from udebs -- there's lists of what goes into the initrd for various architectures and flavours of installer under installer/build/pkg-list in the d-i SVN. If you need an extra udeb in your initrd, that's the place to specify it. Once the initrd has gotten access to a source of packages (off a CD, over the network, telepathy, whatever) it can drag the rest of the packages it needs from there. Space is still an issue at this point, though -- there's no diskspace yet to put anything onto, so everything needs to fit into a ramdisk. Don't go loading anything you don't need. The packages loaded at this stage are what defines most of the steps that will be done for the rest of the install, so once all those extra udebs are loaded, the remainder of the install kicks off and does it's thing. Different architectures and install methods have different requirements, too, which complicates matters. For example, when you're installing on a regular PC with screen/keyboard, you can guide the install using that. However, if you've got no screen, how can you control the install? There's serial consoles, but requiring everyone to void the warranty (more) on their little embedded doodad by installing a serial console cable to install Debian isn't so hot. So, lacking a terminal, how do you control the install? Well, on install flavours for devices that might be in this situation, you can SSH into the installer and complete it that way. That feature is, like everything else, provided in a udeb -- called network-console, as it happens. But what IP address do you connect to, and what network settings does the device use? Again, without a console you can't configure your network, and not everyone has a DHCP server (and even fewer people have a DHCP server that will hand out an address that they'll know in advance, or be able to find out). So, there's a udeb (called oldsys-preseed) that does it's best to configure your network based on the settings already in the nvram for your device. In short, there's a lot of tricky, well-thought-out shit going on inside d-i, and you might have to deal with a little bit of it. The nice thing is that by now I expect most of the really hard problems have been solved, so with a bit of luck you'll only ever have to do minor tweaking. In general, all of the packages that are "d-i specific" live in packages in the d-i SVN. If you need to modify a udeb, you need to rebuild it and put it in installer/build/localudebs/ (creating it first if need be) and every time you change it, you need to delete installer/build/apt.udeb/cache/. To give a concrete example (from the ever-present DNS-323), I had to modify oldsys-preseed so that it would get the details from the nvram that the stock firmware uses to configure itself. This, in turn, required that the minix-modules udeb be included in the initrd, because the DNS-323's nvram is actually a small minix partition stored in flash. Painfully, this required some more hacking, because the armel d-i kernel wasn't configured to generate minix-modules. That might need some explanation... Since building the kernel is a fairly massive undertaking, CPU-wise, instead of building all the udebs from scratch there's a package called kernel-wedge to split a real linux-image package into lots of little udebs. There's a separate source package for each architecture, linux-kernel-di-$ARCH-2.6, that contains the configuration data for kernel-wedge to specify what udebs need to be built, and what goes into each of them. A small tweak to the armel package and voila! I had a minix-modules udeb to include in the initrd. With the config stuff I'd done in the d-i build itself and my changes to oldsys-preseed, we were done with d-i. Tell d-i how to build your bootable artifacts If your device needs a "different" install image from other similar devices, you need to write some makefile rules to build those files. Look under the installer/build/config/$ARCH/ directory to see the various rules files available. I had to package a new tool to create uploadable firmware images for the DNS-323, along with adding a rule to use that tool to build images. None of it was particularly difficult. Polish the diamond Getting d-i working is only part of the battle; it's quite likely that there will be other hardware in the machine that needs to be supported. This could involve kernel-level stuff to interface to the hardware, or userland tools to manage the hardware. There's several bits in the DNS-323 that still need work; I can't control the LEDs on the front panel, nor the fan, and I can't use the on-board temperature sensors yet. But, I do have Debian running on the thing, which is what I was shooting for. Examples If you're interested in exactly what I did, there are a number of bugs in the BTS that contain the patches I made:

• #502821: oldsys-preseed changes to take existing network config from NVRAM;
• #502936: build a minix modules package for the armel d-i kernel;
• #503040: d-i core changes to build firmware images for the DNS-323;
• #503172: kernel patches to support the SATA controller and NIC better.

Lenny is the codename for the next release of debian, which will be debian 5.0 formally. For the first time that I can remember, debian will fit on one disk. OK, so it’s a blu-ray disk (BD), but I’m sure it will be a selling point to some people. The announcement goes into some more detail about the implications for data transfer and mirror sizes, as well as noting that it stresses genisoimage beyond breaking point. Before the release, there’s the small matter of about 200 bugs which we need to fix. If you can help, please do. One prickly problem in some of the bugs is that a second debian release in a row is looking like it will allow violations of the Debian Free Software Guidelines into the release. (I don’t think all of the listed example bugs are violations, but some are). My main question about the firmware ones remains the same as two years ago:-

“I think the idea that refusing to ship non-free firmware in main will strengthen demand for free firmware is worthy of consideration. Debian helps users to take control of their operating system. Increasing the demand for free firmware might also help users to take control of their hardware, or at least highlight that there’s this crap which their operating system uses to support their hardware but doesn’t have its normal freedoms.” “However, I’m undecided whether it’s a good idea to exclude them from the distribution CDs and so on. How big is the problem of vital hardware which won’t work without firmware being copied to it? Should we split non-free into non-free-hardware and non-free, allowing non-free-hardware packages onto the CDs?”

Ben’s technical blog: For those who care about firmware is tracking some of the hardware, but I don’t own any of the untested ones. That’s not surprising: I’ve been trying to avoid closed firmware for a few years now. Debian bug #502959 discusses how one of the key debian project machines is affected. There’s a nice suggestion of using some of the project’s $64,000 to buy some hardware that’s fully supported by free software, but the bug has been closed by Peter Palfrader with the message “go screw yourselves and do something useful, like find a bridge”. Yikes. Is there less vital hardware now than two years ago? Can the patches provided really not be included?

One month with Emacs and counting - Part 1 Straight to the point: since mid September I've been using Emacs, trying to evaluate whether I was willing to switch from Vim to it. Yup, that's true, me (user of Vim since the day I've started using GNU/Linux 10 years ago, (not so) active maintainer in Debian of vim and related packages, author of some popular Vim extensions and of vim-addon-manager) it's considering switching to Emacs. What is worse is that I've de facto already switched. May jamessan forgive me. OK, that was the hardest part to write, now ... This choice will have an impact on me: partly because I'm quite sure several fellow DDs will start making fun of this story , and partly because as many geeks I've always had strong opinions on the editor war. Switching side ain't easy. Hence, I've decided to write a small (2-3) series of blog posts on the issue, to future memory. The post you are reading is about why, since a few months ago, I wasn't willing to give Emacs a try, and how I've changed my mind. Why I wasn't willing to give Emacs a try, but then changed my mind I love knowing tools which can improve my workflow, no matter the task. Editors happen to be at the intersection of many tasks, hence knowing well his own editor and feeling satisfied about it is quite important. This is even more so for free software hackers which, for a reason or another, happen to use the very same editor for a lot of different tasks; in my case: programming, conf file hacking (i.e., playing the sysadm role), mail writing, and everything in between. I've started using vi on Solaris around 1998, then switched to Vim starting from version 4.0, and then followed all its releases up to 7.0. I consider my "Vim karma" to be quite hight and I've delivered several talks about using Vim for LUGs and other free software-related events. Still, I've always been hit bit several minor nuisances and glitches of Vim which couldn't be fixed by simple configuration tuning or add-on implementations (more on this in a future post). In the quest for the perfect workflow, those glitches have made me try several times other editors hoping for more satisfying work environments. Of course Emacs was one of them, which I've tried repeatedly during the years; the last time was circa 2006. For one reason or another, after a few days of experiments, I've always decided to give up with it. Why? Various reasons, listed below, together with an explanation of what (I think) has changed since then.

1. Poor Unicode/multibyte support. Support for whatever Unicode encoding was close to null. It was not available in the legacy editor, and you had to use something called MULE, to be specifically enabled. That was so 60's, and rather hard to use. Now (apparently starting from Emacs 22.1, June 2007) finally you have built-in Unicode support and the needed two variables for setting the input encoding and the file encoding, which is basically all you need. Looks easy once you have it ...
2. Lack of "modern" UI toolkit support. Yes, I do live in a console and invoke my editor from it, but nevertheless for long coding sessions I do also love having a nice GTK+ window containing my editor using settings which smoothly integrated with the graphical settings of my desktop environment. Maybe I'm getting old, maybe GNOME has changed my perceptions, but why the heck I had to tolerate different monospace fonts in my gnome-terminal wrt my GUI editor I never understood. Firing up Emacs was like getting back in time of 15 years, and if a geek having a maximized terminal on most of its workspaces had this feeling, then something was really wrong. This has changed: starting again from Emacs 22.1, the editor has frown support for that "bleeding edge" technology called GTK+. Finally you can use Pango font faces and avoid the time travel feeling when switching from a terminal to your GUI.
3. "Dead upstream" syndrome. As we all know by experience, choosing a free software product is not only a matter of evaluating bugs and features, there are other environmental factors. A notable example is how active upstream is. A few of us will use a product affected by the "dead upstream" syndrome. That's exactly what I was feeling about Emacs. The first argument I can offer to back that feeling is again the Emacs release history (noted that "small" hole between 2001 and 2007? Rest In Peace release early, release often ...). The second argument is the bug tracking system: there was none, bug discussions happened only on the development mailing list and the bug tracker was a text file on CVS! (Yes, Vim doesn't have a proper BTS either, but I was looking for reasons to switch from it and hence looking for something better in several respects.) That has changed completely, as I discovered only at this year DebConf thanks to gismo. 2007 has enjoyed 1 Emacs release and 2008 already two. They do have a BTS now and guess what? is dear old debbugs. According to my first experiences as Emacs bug reported the maintainers are very reactive and also friendly in dealing with bug reporters. Finally, also keeping up with snapshot releases in Debian is entirely trivial, thanks to Romain's repository.
4. Poor performances & memory consumption. This goes in the direction of probably the most popular joke used by Vim zealots in the editor war: Emacs is a nice operating system, but lacks a good editor, or something such. In the past I had the impression that starting Emacs was really slow and that generally the memory footprint was too high to be acceptable. You know what: starting a full-blown gvim with a good deals of add-ons (and I used quite a lot of them, that's why vim-addon-manager was born) is not that faster. And on the contrary, firing up an emacsclient is way faster than starting up a new gvim instance. Regarding memory consumption Emacs is still "gaining" the battle. Still, one has to keep in mind the different workflow: with Vim you are encouraged to enter and exit the editor (not without drawbacks, as I'll discuss in a future post), while with Emacs you always use the same one. It turns out that via emacsclient the resulting feeling is the same as having multiple editors (as you can fire them up as separate windows or in separate consoles), still sharing all user memory. A final comment on memory consumption while looking at my top sorted by decreasing RSS memory: the top process is xulrunner (from the browser) with 356Mb, then Xorg (159M), pidgin (128Mb !!!!), trackerd, gnome-terminal, gnome-panel, ..., Emacs shows up with 51 Mb at the 7th position. Yes, it is not the thinnest editor in the world, but on average machine it doesn't really matter at all.

In the next post: how to switch from Vim to Emacs, without loosing your mental sanity. (Whether I did succeed wrt sanity is up to the reader to judge.)

I’m not sure which is the second-largest of the projects supported by Software in the Public Interest, but I thought that OpenOffice.org was up there with them. It’s been a bit of a surprise to me that SPI hasn’t done more for them since they joined back in March: only about $1,000 has been donated that way, none spent and I’ve not noticed their liaison being very active yet. Following the release of OpenOffice.org 3.0, I took a bit of a closer look. Stuff Michael Meeks is doing: Measuring the true success of OpenOffice.org suggests that the project is much smaller than I thought:

“In a healthy project we would expect to see a large number of volunteer developers involved, in addition - we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite we appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux’s recent low of 160+. Even spun in the most positive way, OO.o is at best stagnating from a development perspective. “

OpenOffice.org is a project that produces something I don’t use much, but I recognise the significance of it. I’ve looked at contributing a couple of times in the past (nothing major, just bug reports and offers of help), but got utterly lost in the maze of websites and copious verbose descriptions written in management buzzspeak. (I spotted a “Report a Bug” link taking me to a page titled “Submit an Issue” for example.) Looking again now, OOo doesn’t seem much easier to navigate. I did find that SPI doesn’t appear to be listed on their donation page yet, which probably explains the low donation amount. Another confusing thing: they don’t use bugzilla, but a less accessible fork called Issue Tracker. Even simple contributions seemed to want multiple registrations to websites, mailing lists and whatnot - that seemed to contradict a claim that “Joining OpenOffice.org is purely optional” - and a confused email question to an address listed on the website got a rejection/error in reply. I’m sorry to say that I got confused, discouraged and moved onto other, easier things that I’d use more. Anyone else looked at contributing? How did it go for you? Anyone understand how this associated project works?

I am all for models and examples, and well, Nerd Girls, is such a web portal meant to celebrate “smart-girl individuality that???s revolutionizing our future.” And they “want to encourage other girls to change their world through Science, Technology, Engineering and Math, while embracing their feminine power.” That message is all good and fine but the profile page is just a little too homogeneous and “made up” and actually just looks fake as fake can be (and what is UP with those dumb glasses they are all wearing?!). Sorry to say this, but all those “chics” look like they are fake nerds and are really models for Seventeen magazine or soft-porn movies. Is Nerd Girls a joke? Or is it real and just not for Ugly (or regularly looking) Nerd Girls? update
[h0mee] lol
[h0mee] actually what it really reminds me of
[h0mee] are those inspirational posters you see in high school meant to inspire students to study harder
[biella] like this one update again (sorry, the comments on my irc channel are just too good to ignore: [Atala] lol one of my friends just said the site seems like a thought experiment on what would happen if MTV bought Bitch magazine.
[rex] EXACTLY

I am all for models and examples, and well, Nerd Girls, is such a web portal meant to celebrate “smart-girl individuality that s revolutionizing our future.” And they “want to encourage other girls to change their world through Science, Technology, Engineering and Math, while embracing their feminine power.” That message is all good and fine but the profile page is just a little too homogeneous and “made up” and actually just looks fake as fake can be (and what is UP with those dumb glasses they are all wearing?!). Sorry to say this, but all those “chics” look like they are fake nerds and are really models for Seventeen magazine or soft-porn movies. Is Nerd Girls a joke? Or is it real and just not for Ugly (or regularly looking) Nerd Girls? update
[h0mee] lol
[h0mee] actually what it really reminds me of
[h0mee] are those inspirational posters you see in high school meant to inspire students to study harder
[biella] like this one update again (sorry, the comments on my irc channel are just too good to ignore: [Atala] lol one of my friends just said the site seems like a thought experiment on what would happen if MTV bought Bitch magazine.
[rex] EXACTLY

So we are about 1/2 way done with my hacker class and I have to say it has been a pretty fun ride, especially since many students thought hacking was all about pimply kids engaging in malicious acts of computer violence and many had no knowledge of basic technological concepts like UNIX or source code. We had to first sweep away the cobwebs of misrepresentation and replace with a more solid foundation of facts (however messy the world of hacking still is!) But after building a foundation, you still wonder whether students are learning. Traditionally we gauge progress with exams or essays, which can be effective but let’s face it, at times a little tedious. But today a student sent me the following very short email, which made me realize I had another barometer at my disposal to gauge their progress xkcd:

http://xkcd.com/344/ I wouldn’t have gotten the joke if it wasn’t for you. Thanks.

The email not only made me smile (for it is always nice to know your students are leaning something) but it gave me the idea that in the future I might include a comic based exams composed of 5-10 comic strips (many from xkcd) and ask for an exegesis of them. Why not? Seems like fun to me. And it would be great to include the following as one of my course objectives: “By the end of this class you will be able to read xkcd and actually understand (most) of it.” If they could do that, well, they must have learned at least something update: One of my readers, Florian, sent this nice bit, which I have not read before: “I read your blog via Planet Debian and immediately felt reminded of Jane
Goodall’s Foreword to Gary Larson’s The Far Side Gallery 5 which I’d
like to share with you:”

Recently I was talking with one of the best researcher know, Tim
O’Halloran. He has been able to inspire generations of middle and high
school students to care for the natural world. Tim told me that Gary
Larson has had a major impact on his teaching. Tim uses Far Side
cartoons to introduce topics, to illustrate points, and to “reinforce
the notion that the more we investigate the universe, the richer is our
experience.” When designing exam papers Tim finds the cartoons “ease the
tension and spark the memory.” It all began when, in the fall of 1985,
he was given the task of teaching science to 162 Tulsa ninth-graders who
were convinced that it was absolutely irrelevant to their futures. Tim
put one hundred Far Side cartoons on a large bulleting board, and told
the students to study them. The consensus was that they didn’t
understand the humor - The Far Side was “too weird”. However, Tim wrote
me, “Each time we completed a unit and the students approached the
bulletin board with newly acquired wisdom, I smiled quietly and thanked
the cosmos for Gary’s perspectives as the kids roared with the confident
laughter of the enlightened.” Having taught myself for a while, I can fully and happily relate.

Later in the semester, and for my hacker course, we will be reading Understanding Comics, which will give us a bit of a meta perspective on why comics are so good at conveying a certain type of message. I can’t wait to read it as I have heard it is fantastic.

So we are about 1/2 way done with my hacker class and I have to say it has been a pretty fun ride, especially since many students thought hacking was all about pimply kids engaging in malicious acts of computer violence and many had no knowledge of basic technological concepts like UNIX or source code. We had to first sweep away the cobwebs of misrepresentation and replace with a more solid foundation of facts (however messy the world of hacking still is!) But after building a foundation, you still wonder whether students are learning. Traditionally we gauge progress with exams or essays, which can be effective but let’s face it, at times a little tedious. But today a student sent me the following very short email, which made me realize I had another barometer at my disposal to gauge their progress xkcd:

http://xkcd.com/344/ I wouldn’t have gotten the joke if it wasn’t for you. Thanks.

The email not only made me smile (for it is always nice to know your students are leaning something) but it gave me the idea that in the future I might include a comic based exams composed of 5-10 comic strips (many from xkcd) and ask for an exegesis of them. Why not? Seems like fun to me. And it would be great to include the following as one of my course objectives: “By the end of this class you will be able to read xkcd and actually understand (most) of it.” If they could do that, well, they must have learned at least something update: One of my readers, Florian, sent this nice bit, which I have not read before: “I read your blog via Planet Debian and immediately felt reminded of Jane
Goodall’s Foreword to Gary Larson’s The Far Side Gallery 5 which I’d
like to share with you:”

Recently I was talking with one of the best researcher know, Tim
O’Halloran. He has been able to inspire generations of middle and high
school students to care for the natural world. Tim told me that Gary
Larson has had a major impact on his teaching. Tim uses Far Side
cartoons to introduce topics, to illustrate points, and to “reinforce
the notion that the more we investigate the universe, the richer is our
experience.” When designing exam papers Tim finds the cartoons “ease the
tension and spark the memory.” It all began when, in the fall of 1985,
he was given the task of teaching science to 162 Tulsa ninth-graders who
were convinced that it was absolutely irrelevant to their futures. Tim
put one hundred Far Side cartoons on a large bulleting board, and told
the students to study them. The consensus was that they didn’t
understand the humor - The Far Side was “too weird”. However, Tim wrote
me, “Each time we completed a unit and the students approached the
bulletin board with newly acquired wisdom, I smiled quietly and thanked
the cosmos for Gary’s perspectives as the kids roared with the confident
laughter of the enlightened.” Having taught myself for a while, I can fully and happily relate.

Later in the semester, and for my hacker course, we will be reading Understanding Comics, which will give us a bit of a meta perspective on why comics are so good at conveying a certain type of message. I can’t wait to read it as I have heard it is fantastic.

Just received this comment from Jimmy Kaplowitz over in the US: “yuck, your country continues to turn into Big Brother: BBC News: Giant database plan ‘Orwellian’” Hell, yeah. That’s a reason why my support for the party is so weak at the moment. I’ve been working and writing against this since ST@ND and the Regulation of Investigatory Powers Act, which we were told was essential for crime-fighting, but actually helps gov.uk spy on parents making school place applications. Currently, I’m telling people Gov.UK Consults on Forced ISP Snooping: Please Say NO. If anyone has any doubt that the database state will be abused, look at some examples of Labour’s “terrorists” (at least, they had supposedly anti-terror measures used against them) since 2001:-

1. Wolfie, an 82-year-old peace-campaigning heckler at a Labour conference
2. Indymedia
3. a Frenchman in Suffolk who downloaded the Anarchists’ Cookbook
4. an Algerian pilot
5. the country of Iceland

and that’s ignoring gov.uk’s frequent data leaks. Noodles replied: “There’s a quote somewhere that goes along the lines of “If the Tory policy is looking sane compared to what you’re doing, you’re doing it wrong” that’s been applied to the Labour fascist state stuff.” Our terrorism measures are a joke, with loopholes that gov.uk can drive a truck through. They should be repealed and clearly-limited ones enacted, shouldn’t they?

Christian worries about how to grow the desktop share in the free desktop. Some recent events (Chromium, Geode) have led me to believe that … We've won … already. For example let's look at the reactions to Chromium (which I believe was released way too early):

• Linux and Mac versions have not been launched
• Google announce ... Linux version ... delayed. Why do they do this by not considering ... Linux
• Chromium for Linux & Mac OS X

I've just picked three links but the trend is clear. The digirati want to use Linux and Mac OS X to evaluate new technologies NOT Windows. Sure, some of them still have those boxes around for “client work”. But that is not what they use day-to-day. Now let's take a look at Mozillas' Geode. Here is the Introduction to Geode. Look at the comments:

• Why is it not compatible with Linux (first one)
• Ele é compativel com linux? (seventh one)
• 15th and 16th comments

In fact the outcry was enough for lack of Linux support that is merited a follow-up Common Geode Q&As:

Geode is meant as a temporary solution to allow websites to experiment with geolocation today. … Skyhook is built in. A side effect is that Linux isn't supported for the simple reason that Skyhook hasn't implemented Linux drivers. Although not ideal. …

A year ago this would not have happened. This amount of push-back from the digirati that the new technology they are supposed to look at and evaluate is not available on their platform would have been accepted as a matter of course. Now, though, they all expect it on their platform of choice. We've won, already. Whilst the largest user-base remains the Windows market, if you want the digirati to look at and evaluate what you have to offer it needs to work on Linux & Mac OS X. Another example, while I remember, is Adobe releasing Flash 10 for Linux on the same day as other platforms. Unheard of. So what does mean for Christian's question?

1. Within 12 months it will be inconcievable for software to NOT be released on Windows + Linux (and maybe Mac OS X)
2. Within 24 months we will have power users asking for Free Software (probably not Linux but more likely OpenOffice 3.x & Firefox) routinely
3. Within 36 months Linux will be 10% of the desktop market. Bigger than Mac OS X. That is a lot of people you can not afford to ignore if you are a company, it will mean that ‘web-based’ will be more and more common — integration between desktop and the web will be key.

One of html's deficiencies is that it doesn't have a tag to mark up a date. If html had such a tag, then browsers could display dates using your time zone, and in whatever format you like. Rather than in some random time zone, that is often not even shown, and some random format. My fav way to see a date is as relative date, such as "two days ago". With a mouseover so I can see the exact, absolute date in the rare case I need it. It's possible to combine some javascript with html, so that, if javascript is available, a nicely formatted relative date is displayed. And with no javascript, an plain old absolute date is shown. Perhaps the cleanest way to do it is using html like this, combined with javascript that fires on page load, parses the date and replaces it with something nicer:

<span class="date">Fri Oct 17 16:17:02 2008 (EDT)</span>

But you might want to avoid using the ugly machine-parseable date, since it will still display in any situation where javascript isn't available. To do that, I added an attribute containing the machine-parseable date. I chose to use the "title" attribute, so as a bonus you can hover over it to get a popup with the raw date.

<span class="date" title="Fri Oct 17 16:17:02 2008 (EDT)">Friday afternoon, October 17th</span>

So, relatively clean html out of the way, now we just need some javascript to munge in the relative dates. There are various examples out there. The best one, requires the prototype framework. I try to stay away from javascript frameworks, since I'm not a javascript programmer, and since I dislike page loads pulling in thousands of lines of irrelevant code. So I came up with my own more bare metal implementation, which handles both types of html above. You can see it in action on my website, or by enabling the relativedate plugin on your own ikiwiki. (This code is in the public domain, but do note that I'm not a javascript programmer, really.)

---

var dateElements;
window.onload = getDates;
function getDates()  
    dateElements = getElementsByClass('date');
    for (var i = 0; i < dateElements.length; i++)  
        var elt = dateElements[i];
        var title = elt.attributes.title;
        var d = new Date(title ? title.value : elt.innerHTML);
        if (! isNaN(d))  
            dateElements[i].date=d;
            elt.title=elt.innerHTML;
         
     
    showDates();
 
function showDates()  
    for (var i = 0; i < dateElements.length; i++)  
        var elt = dateElements[i];
        var d = elt.date;
        if (! isNaN(d))  
            elt.innerHTML=relativeDate(d);
         
     
    setTimeout(showDates,30000); // keep updating every 30s
 
function getElementsByClass(cls, node, tag)  
        if (document.getElementsByClass)
                return document.getElementsByClass(cls, node, tag);
        if (! node) node = document;
        if (! tag) tag = '*';
        var ret = new Array();
        var pattern = new RegExp("(^ \\s)"+cls+"(\\s $)");
        var els = node.getElementsByTagName(tag);
        for (i = 0; i < els.length; i++)  
                if ( pattern.test(els[i].className) )  
                        ret.push(els[i]);
                 
         
        return ret;
 
var timeUnits = new Array;
timeUnits['minute'] = 60;
timeUnits['hour'] = timeUnits['minute'] * 60;
timeUnits['day'] = timeUnits['hour'] * 24;
timeUnits['month'] = timeUnits['day'] * 30;
timeUnits['year'] = timeUnits['day'] * 364;
var timeUnitOrder = ['year', 'month', 'day', 'hour', 'minute'];
function relativeDate(date)  
    var now = new Date();
    var offset = date.getTime() - now.getTime();
    var seconds = Math.round(Math.abs(offset) / 1000);
    var ret = "";
    var shown = 0;
    for (i = 0; i < timeUnitOrder.length; i++)  
        var unit = timeUnitOrder[i];
        if (seconds >= timeUnits[unit])  
            var num = Math.floor(seconds / timeUnits[unit]);
            seconds -= num * timeUnits[unit];
            if (ret)
                ret += "and ";
            ret += num + " " + unit + (num > 1 ? "s" : "") + " ";
            if (++shown == 2)
                break;
         
        else if (shown)
            break;
     
    if (! ret)
        ret = "less than a minute "
    return ret + (offset < 0 ? "ago" : "from now");
 

I mostly stayed under a rock during the last weeks: exams season, some assingments plus one week of much needed [VAC]; ironically in the DebConf 8 secondary hotel. I'm in a very interesting course on operating systems' programming, it's a new optative course, and has generated a lot of expectatives: most of the systems-oriented undergrads in the computer science career are attending. The downside is that it's *intensive*: we're expected to build from scratch a minimal operating system, starting from the bootloader. So far my group has already done a bootloader that understands FAT, and the entry point for the OS, in which the basic stuff is setup: gate A20, interruptions, protected mode, GDT, etc. Also, each group is required to do a presentation of some systems research topic, and we choose Plan 9 from Bell Labs, that mostly unknown OS that was meant to be a better UNIX, but never gained popularity. So I spent many days playing with it, trying to grok quickly what it was about, and creating a small network of virtual hosts (in Qemu) that could show how it all fit togheter. Plan 9 has all the credentials: created in the same lab as UNIX, designed by the same people, which already learned from past mistakes. It was started in the late eighties, and it really feels like what the future was meant to be. Sadly, we're just starting to see a few of it's revolutionary ideas being applied to other systems: UTF-8, /proc, unionfs, fuse, clone(2), separate namespaces; all of these follow concepts first created in Plan 9, UTF-8 was designed by Ken Thompson "in front of my eyes, on a placemat in a New Jersey diner one night in September or so 1992", in Rob Pike's words. Not happy enough with reworking all the core concepts, they also recreated the visual environment. I have to admit, the user-facing ideas are so foreign that I still don't feel very comfortable using it. Surprisingly, the desktop is very mice-centric, it cannot be used at all without the mouse, and it's bothersome with less than three buttons. Anyway, the underlying workings are so attractive, that I cannot stop from wondering if a hybrid system could be built (Debian/kPlan9 anyone?). To illustrate, I'll reproduce here the same example that I showed yesterday and left some jaws hanging. I had booted a CPU server and a diskless terminal, called cpu-0 and term-0 respectively. This is a screenshot taken in the terminal, which is basically a telnet to my Debian box:
Nothing spectacular here, except for the weird syntax, it was seen like this in the Debian box:

martin@abraxas:~$ netstat -nt   grep :22
tcp        0      0 10.0.2.1:22             10.0.2.30:39879         ESTABLISHED

But here comes the fun, I ran an import command, which is more or less a remote filesystem mount, with which I mount the remote machine's /net in the local namespace. It has to be noted that the /net path is by convention the entry point to anything network related, including all the networking API.
And the wornderful thing is that this works as it should (note the remote address):

martin@abraxas:~$ netstat -nt   grep :22
tcp        0      0 10.0.2.1:22             10.0.2.10:38158         ESTABLISHED

So, what happened? telnet wanted to create a TCP connection, and that is accomplished opening /net/tcp/clone, but then it found the imported filesystem. The open(2) request was then transferred to the remote machine, and there the networking code did the actual TCP/IP dance. Things like this make you realise that maybe the BSD sockets API is not that nice an abstraction; in Plan 9 there are no BSD sockets, it's only implemented in the POSIX compatibility libraries, which aren't used by any of the core tools. Neither there exists any threads support, you just call rfork(2) setting the appropiate flags, exactly what glibc does under the covers nowadays. They also decided to live without select(2) or poll(2), there are no non-blocking calls. If you want non-blocking, you rfork(). The only syncronisation primitive is rendezvous(2), and everything else is built on that. At this point, it should not surprise you that to kill a process you can type echo kill > /proc/$pid/ctl; and that there's no need for an equivalent to Xnest, as rio (the graphical interface) provides a modified /dev, you just type rio inside a window and there you go. Yes, I'm hooked. If you're interested, I compiled many links here (some Spanish there, but all the content is in English), as one of the weakest points in Plan 9 is the unorganised and missing documentation. Tags: Plan9, Planet Lugfi, Planet Debian, Facu

When I first got a digital SLR camera a few years ago, I spent some time evaluating photo printing options. I sent a set of test prints to several different companies, and wound up deciding to use Shutterfly for my photo printing.

It's been some time since then, so I figured it was about time to re-evaluate options.

There are three main things to consider when obtaining prints of photos: cost of prints, quality of prints at delivery, and longevity of prints. Many people look only at cost, and those that look past cost rarely look past quality at longevity. Longevity (or permanence) is, in my opinion, the most important factor to consider. But let's look at all of them.

Longevity

All color photo print technologies fade or otherwise degrade over time. There are several main things that can cause this: exposure to light, exposure to gases (especially ozone), and exposure to humidity. The impact of these different items varies by print technology, paper, and process.

Longevity: Traditional Photo Paper

Most services such as Shutterfly, Snapfish, Ofoto, as well as retailers such as Walmart, Target, and Walgreens print on traditional photo paper.

Historically, traditional photo paper has had terrible fading characteristics. Typically, old photos exposed to light -- for instance, hanging on a wall underneath a light bulb or in the sun -- will exhibit severe fade towards yellow or magenta. Modern papers are much better, but you will still not want to leave them directly in the sun or under lights.

Over at TPR, you can find several papers analyzing this. Perhaps the most interesting are test of digital prints and image permanence: comparing the technologies.

To attempt to summarize, what you see is that of the two common consumer-grade photo papers, Kodak Royal and Fuji Crystal Archive, the Fuji paper has better permanence. However, the pro-quality Kodak Professional Supra Endura is better than either of them by a significant margin. The photo papers didn't really have a problem with humidity, and not much of a problem with ozone.

Longevity: Inkjet

So what about inkjets and laser processes? The main thing I learned from my research is that there is a tremendous amount of variance here. When looking solely at top-quality inkjet papers and inks, they ranged everywhere from having little bits of them flake off after a few months to doing better than any of the photo papers. This variance occurred even with similar papers from the same manufacturer.

As far as light exposure is concerned, every inkjet paper tested by TPR did better than Kodak Royal. Some fared about the same as Fuji Crystal Archive. And some even beat out Kodak Supra Endura.

But look at the ozone exposure test and you see a far different picture. All of the photo papers did really well, though suprisingly Supra Endura was the worst of them (though the scale is so small here that the difference is pretty minimal).

Not one of the inkjet papers came even close to that, and some faded so fast that they couldn't even make it halfway through the test.

As far as humidity is concerned, it barely impacted the photo paper prints at all. Inkjet impacts were still mostly small, but also were mostly more impacted than the photo paper.

Longevity: Laser

And finally, how about laser prints. There was huge variety here. An HP printer they tested faded so fast it couldn't complete the light exposure test, while a Konica-Minolta fared better than Kodak Supra Endura in one test. In another light exposure test, they performed about the same as the photo papers. Ozone had little effect on the laser papers, except for the Dell test, which faded so fast they had to abort the test early. Humidity also had little effect on the laser prints.

Longevity: Other Examples

Brett Wilson did some interesting experiments with photos hung in front of a window as well. Wilhelm Imaging also has done some research in this area, though they are done using fluorescent lights only, which is prejudicial in favor of inkjet papers and against photo papers.

For the ultimate in longevity, true black and white photo paper is well-regarded.

TPR also has a report covering different lacquer and other finishes often applied to prints to improve their longevity.

Longevity: Conclusions

With the exact right combination of inkjet paper and ink, you can get a print that will last exceptionally long. Some inkjet paper and ink combinations have really poor longevity characteristics, however, as do the laser papers.

Photo papers, especially Kodak Supra Endura, but even Fuji Crystal Archive, will last quite awhile as well, and are probably the best storage if kept in dark conditions such as an album.

Print Quality

When looking at print quality, I'm concerned with correct color balance, saturation, cropping, consistency, sharpness, contract, and detail in both dark and light areas -- the typical things you'd look for.

Printing inkjet prints at home leaves all this up to your printer, inks, papers, and you, so we can't really compare meaningfully.

Back when I looked at it, Shutterfly and Ofoto did the best. Walmart, Walgreens, dotPhoto, and many of the other online sites were really too poor to even bother with. Ofoto had a bit of a yellow tint to it, while Shutterfly did pretty well.

Most of the reviews of the major sites I've seen lately rank Shutterfly or Snapfish at the top in terms of quality. Many also rank Ofoto/Kodak near the top.

Walmart and Walgreens produce consistently bad results, and I only use them if all that matters is speed. If you ever read a review where somebody says that they get good results from one of those places, find a review where somebody has a better idea what they're talking about.

Besides your mass-market sites like Shutterfly and Ofoto, there are also some slightly more expensive sites. The two best-known are mpix.com and adorama.com. Mpix is a division of Miller's Professional Imaging, a pro lab. Mpix is basically a website where you can submit photos in the way you would to one of these other sites, and they can do their thing. Their standard rate includes human color correction on every print, but they offer a cheaper rate if you don't need that. Their standard paper is Kodak Pro Supra Endura (the one that ranked highest in longevity tests), and the options go up from there. They also offer printing on true black and white paper, as well as wrap-around canvas and other such options.

I've sent some work their way and have been exceptionally happy with the result. Everything from the color of the prints down to the packaging shows extreme care and attention to detail. Among the reviews that cover mpix -- many don't -- it almost always comes out at the top of the pack, easily beating out Shutterfly and Snapfish. It can be more pricy (though sometimes actually cheaper, since shipping is flat-rate with them), though not significantly.

Adorama is also sometimes mentioned. Most people seem to prefer mpix over adorama, but some prefer adorama. It's a bit cheaper when you don't need color correction for some prints, but sometimes -- right now, for instance -- closes for weeks at a time to observe Jewish holidays. It didn't seem to be enough for me to bother.

Cost

Perhaps the easiest to figure out is cost, since websites typically list it right there for you.

High-quality inkjet prints are by far the most expensive option. I looked at 4x6 prints. Using the high-quality paper/ink combinations that did well in the TPR tests, and when buying supplies in bulk to get the best possible discount, it's still 25 cents or more for a single 4x6 print. That's with doing all the color work yourself, and not even figuring in the cost of the inevitable experimenting with getting the software set up right and the wasted prints when ink gets low. It also doesn't figure in the cost of the printer.

At mpix, if you do your own color correction, it's 19 cents per print, plus shipping. Prints are on Kodak Professional Supra Endura Shipping is a flat rate of $3 for 50 or fewer 4x6 or smaller prints, or a flat rate of $5.95 for USPS Priority Mail for anything else. They offer FedEx at an additional cost, which maxes out at a flat rate of $12.75 for overnight shipping. Some items such as framed canvas prints are more expensive.

Other options at an additional cost include color correction by a human, metallic paper, Ilford B&W paper, etc. There are also some more typical pro-lab options: red-eye removal by a human, custom retouching, etc.

At Shutterfly, a 4x6 print goes for 15 cents. You can get them as low as 10 cents if you buy a pre-paid plan of 600 prints for $60. Shipping varies based on the number of prints, starting at $1.79 for up to 10 prints, ranging up to $21 for 500 prints, with 3 cents per print after that. Priority and express mail is available at an additional charge. Shutterfly's standard paper is Fuji Crystal Archive.

At Snapfish, a 4x6 print goes for 9 cents. You can get them as low as 8 cents if you buy a pre-paid plan of 250 prints. Shipping at Snapfish follows a complicated formula, but is generally approximately the same as Shutterfly. Though if you print more than 595 prints, watch out for the 10 cents per print overage fee. They don't state what paper they use. Recent reports seem to suggest that it's Fuji Crystal Archive, but some reports claim it's Kodak Royal.

My Conclusions

I'm planning to switch most of my prints to mpix -- their higher quality and cheaper shipping offset their higher per-print cost for me. Also, I plan to try out Snapfish and see what sort of quality I get from them for things where quality isn't really that critical.

The design of levels for computer games is a form of programming, particularly for games with deterministic NPCs. It seems to me that for a large portion of the modern computer user-base the design of games levels will be their first experience of programming computers, the people who don’t start programming by creating games levels would be writing spread-sheets. Probably a few people start programming by writing “batch files” and shell scripts, but I expect that they form a minute portion of the user-base. I believe that learning some type of programming is becoming increasingly important, not just for it’s own sake (most people can get through their life quite well without doing any form of programming) but because of the sense of empowerment it gives. A computer is not a mysterious magic box that sometimes does things you want and sometimes doesn’t! It’s a complex machine that you can control. Knowing that you can control it gives you more options even if you don’t want to program it yourself, little things like knowing that you have an option of using a different choice of software or paying someone to write new software open significant possibilities to computer use in business environments. Games which involve strategic or tactical thought seem to have some educational benefit (which may or may not outweigh the negative aspects of games). To empower children and take full advantage of the educational possibilities I think that there are some features that are needed in games. Firstly levels that are created by the user need to be first class objects in the game. Having a game menu provide the option of playing predefined levels or user-defined levels clearly shows to the user that their work is somehow less important than that of the game designer. While the game designer’s work will tend to be of a higher quality (by objective measures), by the subjective opinion of the user their own work is usually the most important thing. So when starting a game the user should be given a choice of levels (and/or campaigns) to play with their levels being listed beside the levels of the game creator. Having the users levels displayed at the top of the list (before the levels from the game designer) is also a good thing. Games that support campaigns should allow the user to create their own campaigns. The KDE game kgoldrunner [1] is the best example I’ve seen of this being implemented correctly (there may be better examples but I don’t recall seeing them). In kgoldrunner when you start a game the game(s) that you created are at the bottom of the list. While I believe that it would be better to have my own games at the top of the list, having them in the same list is adequate. When a user is playing the game they should be able to jump immediately from playing a level to editing it. For example in kgoldrunner you can use the Edit Any Level menu option at any time while playing and it will default to allowing you to edit the level you are playing (and give you a hint that you have to save it to your own level). This is a tremendous encouragement for editing levels, any time you play a level and find it too hard, too easy, or not aesthetically pleasing you can change it with a single menu selection! When editing a level every option should have a description. There should be no guessing as to what an item does - it should not be assumed that the user has played the game enough to fully understand how each primary object works. Kgoldrunner provides hover text to describe the building blocks. Operations that seem likely to be performed reasonably often should have menu options. While it is possible to move a level by loading it and saving it, having a Move Level menu option (as kgoldrunner does) is a really good feature. Kgoldrunner’s Edit Next Level menu option is also a good feature. Finally a game should support sharing levels with friends. While kgoldrunner is great it falls down badly in this area. While it’s OK for a game to use multiple files for a campaign underneath the directory it uses for all it’s configuration, but it should be able to export a campaign to a single file for sharing. Being able to hook in to a MUA to enable sending a campaign as a file attached to an email as a single operation would also be a good feature. I have filed Debian bug #502372 [2] requesting this feature.

• [1] http://games.kde.org/game.php?game=kgoldrunner


• [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502372

Share This

Today, I tried to switch one of my personal repositories for debian-related scripts from bzr to git, just like I've done for pmount. The trick was that this time, I wanted to only move a part of the repository, not the full repository. I had only been working before with CVS and SVN who have the idea of modules, which is not the case for bzr or git. So I made the mistake of using a single bzr for several projects, which I realize now is not a very good idea... In any case, I managed to drop some parts and here is how I did it; the trick was precisely to use SVN as an intermediate storage medium, using the following configurations files. First, bzr2svn.conf

[DEFAULT]
verbose = True
patch-name-format = ""
[project]
source = bzr:source
target = svn:target
start-revision = INITIAL
state-file = tailor.state
[bzr:source]
repository = /home/vincent/debian-devel/bzr/scripts
[svn:target]
repository = file:///tmp/testtai
module = biniou

and svn2git.conf:

[DEFAULT]
verbose = True
patch-name-format = ""
[project]
source = svn:source
target = git:target
start-revision = INITIAL
root-directory = /home/vincent/tmp/debian-mr-copyright-mode
state-file = tailor.state
[svn:source]
repository = file:///tmp/testtai
module = biniou/debian-mr-copyright-mode
[git:target]
git-command=/usr/bin/git

Then, all that is left to do is to run tailor on the resulting configuration files:

~ tailor -D -c bzr2svn.conf
~ tailor -D -c svn2git.conf

In my previous post I drafted a rough idea how to add a feature to Debian that would bridge the gap between Debian as a Binary Distribution and any Source Distribution. The feature in question is giving users the chance to build customized Debian packages for specific feature sets. The possible use cases are simple:

Lets say Anthony User needs super-duper-tool with postgresql support. However this is a not so common use case and so the archive only has postgresql support. If he now wants to build a custom package, the process is "as simple" as:

apt-get source super-duper-tool
cd super-duper-tool-*
apt-get build-dep super-duper-tool OR sudo mk-build-deps -r -i
(possibly try out which ./configure options are supported by super-duper-tool)
vi debian/rules
edit debian/rules
dpkg-buildpackage -us -uc
sudo debi

That is, to be honest lot of work. And the biggest problem about it is that you need to know all this, which is not really user knowledge.

The basic idea is that Anthony can do something like
export DEB_BUILD_OPTIONS=nomysql,postgresql
deb-build-tool build super-duper-tool

and is done.
So the question is how could this be achieved?

1. Define a set of common options (options should be consistent through all source packages, otherwise it makes not that much sense) that every package should support, if it is a supported feature by the package in question. This includes flags like mysql, postgresql, ldap and its no-equivalents (nomysql, nopostgresql) to negate it.
2. Enable use of this common options in the package build process and that is really the hardest part. Defining a lot of ifneq..findstring constructs for 2-10 options per source package in any available source package is.... not.... a good approach. Luckily a lot of packages uses autoconf where enabling and disabling features is as easy as adding a --with-foo or --enable-foo option to the ./configure parameters. So we could write a wrapper that would handle these options. The debhelper scripts already have dh_auto_configure: Maybe this could get enhanced.
3. If it does not exist: Write a tool to auto-build packages with DEB_BUILD_OPTIONS set by the user. Should automatically get the source, (optional: setup/update a pbuilder environment) and build it and optional install/upload it (to a user repository for example) .
   

Still, the idea is only a rough draft. There are still a lot of open questions/issues, for example:

• How to handle these feature flags in packages that don't use autoconf
• How to enable these feature flags for packages that don't use debhelpers
• Shall a central place for setting DEB_BUILD_OPTIONS exist (like it does for Gentoo, FreeBSD etc.) and if so: Where?
• How should packages define new build options, if those defined Debian-wide, aren't enough?
• What about support? Do we support such custom builds of packages or will this be a support-on-good-will thing

Is anybody interested in pushing this idea forward? I'm happily interested in it and I know people who like the idea, too. But I can't push this forward on my own all alone. Certainly the work won't affect Lenny anymore, but considerable the time frame that is planned for Lenny+1 by the release team, this could be a feature for Lenny+1.