Among the quirks: (and note these are current as of 2.6.32)

Buggy IOMMU. If you enable virtualization in the BIOS, the kernel spews out boatloads of iommu warnings/errors due to some kind of glitch. It's presumably a kernel bug, but until it's fixed, you gotta add 'intel_iommu=off' to the kernel command line.

Keyboard lagging This was particularly annoying, but adding 'i8042.noloop i8042.nopnp' to the kernel command line made quite a difference. It ain't perfect, but it's at least no longer infuriating. It's worth noting that the laggy keyboard also afflicts operation under Vista too -- only I can't do anything about that!

ExpressCard slot not working post-suspend. Due to a kernel bug, the PCIExpress hotplug driver wasn't working unless the ' pciehp.pciehp_force=1' option is added to the kernel command line. Now I can hotplug ExpressCards left and right, yay.

Post-suspend, the ethernet interface not coming up with GigE speeds. Apparently the network chipset somehow decides to stop advertising 1000Mbps support to the switch, so it's not autonegotiated properly. The workaround is pretty simple: As root, run:

'ethtool -s eth0 speed 1000M'

Headphone jack not working. When something's plugged into the headphone jack, the speakers are muted -- and so is the headphone jack. if you sorta plug it in loosely, you hear both the speakers and the headphone simultaneously. Something's screwy with the HDA Codec routings! This was a particularly annoying fix to solve, and has been broken since the 2.6.28 kernel. There's been a patch rotting in ALSA's bugtracker for more than a year now.

Tonight I got sick of the headphone jack screwiness, and started poking around and discovered the 'hda analyzer' tool; and when poking around with the various routing lines referenced by the patch, I suddenly start hearing output from the headphones. Plugging and unplugging them JustWorks(tm). Apparently the default routing for the headphone jack is incorrect. A bit more digging led me to the hda-verb tool, which can then be invoked with:

hda-verb /dev/snd/hwC0D0 0x21 SET_CONNECT_SEL 0x0d

I added a rule to the pm-utils scripts that kicks both ethtool and hda-verb to fix things up after a suspend, and I'm as happy as a clam now.

When combined with the 'asusg50oled' app that does something useful with the little OLED display above the keyboard, this laptop is actually more functional in Linux than it is under Vista -- It won't come out of a suspend properly there -- and I can even directly control the LEDs around the touchpad. oooo.

Other joy I encountered included a slightly buggy ExpressCard CompactFlash adapter. Modern CF cards, basically being full PATA implementations, can operate at UDMA speeds -- current high-end cards can sustain 90MB/s throughput, well in excess of the ~25-ish that the best USB-based readers can accomplish. I picked up a 'SIIG ExpressCard/54 R/W' adapter, which promises to let me run all-out. So, once I got the hotplug problem fixed up, I slapped in my UDMA-capable CF card.. and.. barely managed 20MB/s, actually worsethan my USB reader.

Further investigation showed that the kernel PATA later was saying that the '80-wire detection' was failing, forcing the card to revert to at most UDMA-33 speeds. Apparently the CF adapter wasn't reporting the proper cable status -- CF cards by definition are 40-pin, but the cables are nonexistent so they can operate at full UDMA/133 speeds if they support it. Unfortutaely, SIIG used the same PCI subvendor/model ID as the reference design for the PATA chipset... so there was no way to hack in a kernel quirk to work around this buggy hardware. But not all was lost!

There was a way to force this to be overridden, but only on a per-adapter basis -- and since the ExpressCard is removable, each time a hotplug event happens it's assigned a new adapterid. I was able to work around this by forcing the kernel to default to a "short 40-pin cable" mode, and explicitly setting the hard drive and DVD drive to full sata operation -- adding 'libata.force=short40c,1:sata,2:sata' to my kerel command line. And my "300X" CF cards sustain 40MB/s. Whee!

So what's my cmdline after all of this?

"ro root=/dev/sda7 rhgb pciehp.pciehp_force=1 intel_iommu=off SYSFONT=ter-u16b LANG=en_US.UTF-8 KEYTABLE=us libata.force=short40c,1:sata,2:sata i8042.noloop i8042.nopnp"

Features like replacing the internal permission model with a finer-grained group-based model. Moving to a real templating engine. Better "social" features. Adding an external RPC API. Adding some sort of caching of search results or other complex queries that involve permission tests. And so on.

One deceptively simple feature request is to integrate PostGIS support. While PO currently extracts GPS data out of images and stores it in the database, it doesn't really do anything useful with that data. Integrating PostGIS support would instantly give PO access to a very powerful geospatial backend that can tie in to all sorts of other spatially-aware systems. There is a near-endless list of upsides, even if PO never uses anything more advanced than spatially-aware searching.

The downsides, however, are doozeys -- From an administration perspective rather than from a code perspecitve. First, due to the level of effort it would take to make PostGIS support optional, we'd have to require it across the board. PostGIS is not part of the standard PostgreSQL distribution, and would consequently make setting up a PO installation more difficult. It would greatly complicate upgrading an existing PO installation to a newer version of PostgreSQL and/or PostGIS, and upgrading to newer PO releases could also get more complex.

So all of that said, PostGIS support would be interesting and cool, but is it necessarily the right direction to take? I know PO is already used by at least one municipality to hold photos relating to their tax rolls, but without a better idea of real-world workflows, I don't know what PO can do to better tie in to the rest of their (or anyone else's) systems.

Meanwhile, regardless of PO's support for PostGIS, more user-visible features like "pull up a google map with locations of this set of photos marked" can be implemented, and now that I have a GPS widget for my camera, I'm actually interested in such things. :)

I get nearly no feedback from PO users; indeed aside from the freshmeat subscriber stats I really have no idea how many folks actually use PO. My best efforts with Google show a few dozen public PO installations, including at least two which the admins have independently translated into Russian. Come on folks, send me patches so all users can benefit from this work!

So, peanut gallery, any thoughts?

There are many more user-visible changes than usual this time around, ihcluding a nice dark theme, pretty URLs, and per-folder/album thumbnails. Oh, and a 40x speed improvement on a hot-path sql query. Yikes.

Each release has made PO's internals less obnoxious and easier to change, but I've hit another brick wall and the next set of internal improvements will be pretty invasive, with no real user-visible benefit.

Unfortunately, development has slowed down considerably lately, in part due to RealLife(tm).. but as always, it's nice to get feedback.

I also just switched PO over to using git. Due to differences in the usage model (from svn), there was no easy way to migrate the old history in the same repo and still continue using git's best pracices. C'est la vie.

A lot of work went into making client/event management more, well, manageable. Multi-day events and the ability to directly tie clients to events tie into date-based searching to make it easy to find out just what you took for any given point in time.

Also new is pluggable authentication, two-step registration, sortable folder/album listings, much (much) faster exporting, plus a large pile of under-the-hood changes to facilitate future features. Oh, and an Italian translation.

v2.35a will probably be released this week with a small pile of bugfixes. Most of these bugs were found while testing out changes made to the development trunk.

On that note, there are a lot of cool things in the pipeline for v2.36; the most visible of which is a new theme! Rickard Olsson got the ball rolling and contributed a dark theme, which I then mangled a bit and committed. When combined with pretty URLs and per-folder thumbnails, things look pretty slick. It's funny how sometimes just how effective superficial changes can be.

es_print_assist.c is now updated to properly poll the printer status, so it can now take the raw dump from gutenprint and shove it out to the printer with minimal delay.

The third step will be to rework it so that it can deal with an arbitrary file on stdin, properly parsing the dumpfile to determine length and paper type.. and for step four, adapting it into a proper CUPS backend. Yay.

The real fun, however, is the need to write a custom CUPS backend to properly spool data to the printer. I have a little helper app (es_print_assist.c) that batches the writes properly, but it dumbly waits instead of properly polling the printer for its status. CUPS is a lot more complicated to figure out than gutenprint, so further progress will be much slower.

Meanwhile, Photo Organizer 2.35 is coming along nicely; I'm at the point where I have to decide whether to go into -rc stabilization now, and save the next round of invasive changes for 2.36, or go ahead and make one or more of those changes now.

In particular, I want to be able to have PO auto-generate full-resolution JPEGs from the source RAW images. On the surface this is straightforward, but I want to implement this properly, by genericizing the "generate a down-scaled image and apply this set of transforms to it" code. This way additional sizes would be trivially easy to add, as would some of the changes I have in mind to make watermarking much more useful. Progress has been slow, but I'm almost done getting the low-level bits in place.

Anyway. Tons of stuff to do, never enough time..

It's a sweet little printer, using the old technique of dye-sublimation to create true continuious tone prints, rather than glorified halftoning that even the best inkjet printers use. Not only do the prints come out looking indistinguishable from what a photo lab would produce -- they're water- and smudge-proof.

I did my homework; apparently the majority of Canon's dyesub printers were supprted under Linux via the gutenprint drivers, but not the ES1 specifically. No big deal, it should just work. Even in the absence of direct Linux printing, I could print from the camera directly or shove a memory card into the printer. All in all, things should Just Work.

They didn't.

My first test involved taking a few converted-from-RAW JPEG images out of my archives, copying them to a CF card, and trying to print that. I got a rather crass Incompatible JPEG Format error message out of the printer. Interestingly my camera also errored out on those images, complaining that The image could not be displayed.. After some heavy digging it turns out the printer makes heavy use of the EXIF data, and if it's not present (or in many cases, simply modified!) the printer gives up. WTF? Why can't Canon document what it needs in a JPEG rather than just displaying a useless error message?

As I shoot RAW images, not being able to convert, crop, tweak, then print a random image via a CF card seriously sucked. So, I'll try Plan B: Print the images from the camera via the universal PictBridge interface.

No good.

Apparently my Nikon D200 camera can't print RAW images. WTF? Even if the camera could only print JPEGs, the NEFs have a full-res embedded JPEG image in the file that would print just fine. Sigh. Onto Plan C: Print directly from my laptop.

No good.

Apparently the SELPHY ES1 is incompatible with Canon's older dyesubs. To some extent I expected this, as it uses a different ribbon/dye pack, but that's mostly because the printer's physical engine is oriented differently -- and it's also why I bought this model over the others. Thanks to this incompatibility, I can't print from Linux either. Onto Plan D: Print from Windows. Surely that will work, right?

Sort of.

The printer worked just fine from Windows... but the prints were all quite dark. Too dark. After some digging, I found the driver's options panel and knocked the brightness up a few notches.. and while not perfect (yellow-ish color balance, mostly) the images were finally acceptable. But this would mean I'd need to boot into Windows to print, which really sucks as the rest of my RAW workflow is Linux-based.

Fortunately, the printer is USB-based, which means that thanks to a wonderful tool called Snoopy2, it's trivial to get a full dump of the entire communications chain between the printer and its driver. Armed with this dump, I could figure out the protocol and hack support into gutenprint.

After an initial learning curve, I succeeded. I was able to generate a binary dump indistinguishable from what Windows generated (except, of course, for the image data). So, cackling with glee, I proceeded to dump this out to the printer.

No good.

The device write() apparently blocked on the very first chunk of data. After much experimentation, I discovered that the logical chunks of data needed to be broken apart and written separately. The initialization sequence and the Yellow, Magenta, and Cyan image data all needed to have pauses between them (the printer sends a status message when it's ready) or the printer's USB interface locks up altogether. Sigh. So I split apart my dump file into its logical chunks, and dump them separately to the printer.

Success!

Not only did it print, but the brightness and color balance looked great. Yes, the images look much better than what their Windows driver manages to put out.

Ah, I love Free Software. When it doesn't JustWork(tm), you can fix it so it does.

All that remains is getting my patch integrated into upstream gutenprint, and figuring out a way to intellently spool the printer data in a CUPS-compatible manner.

Oh, this was the first image I printed:

I took it last weekend at Paradise Beach. I have no idea who this guy is, but he was out kite-surfing on a windy but otherwise beautiful day.

Oh, as a footnote -- about a month before I ordered my ES1, Canon announced its successor models, the ES2 and ES20. Same basic specs, but when untethered the printers had fancier (and faster) feature sets. I needed a printer for next weekend (November 16-18) and nobody had a useful ETA on when they'd show up, so I bought the ES1 at a discount. On the 9th, four days after I received my ES1, everyone suddently got them in stock. Sigh.

The long-awaited version 2.34 of Photo Organizer is finally here. Nearly every facet of Photo Organizer has been enhanced in some way. The most visible improvement is the refactored UI that makes extensive use of CSS and supports multiple languages. Working with larger sets of images and especially clients is also considerably simpler, with the ability to tie folders and clients to datebook events. There are also many behind-the-scenes changes to improve reliability, facilitate future scalibility and of course, a massive pile of little features and tweaks.

You can find it at: po.shaftnet.org

The project remains completely obselete, having been nearly completely eclipsed by the drivers in the linux kernel, but it continues to have a few differentiating features, the most significant of which is support for Prism 2/2.5/3 USB widgets.

It's funny; The very split-MAC architechure that linux-wlan-ng was derided for is the future of Linux wireless -- And the same problems are coming up in almost the same order, as are the same mistakes, and with them the inevitable conclusion that some of these problems are hard.

Sometimes I really dislike that I spend most of my time hacking on proprietary code -- linux-wlan and linux-wlan-ng were my employer's experiment with open-source code, and it almost put us out of business. If we can't get paid for support, and we can't get paid to write software, how exactly are we supposed to pay the bills?

Is the entire F/OSS "business model" subsidized by proprietary components?

The single biggest feature of the "unstable" tree is the use of CSS for layout and other formatting, plus other changes necessary to support better theming and internationalization. The work is well advanced, but I'm running into a few walls.

First, I can't seem to figure out how to have truly marginless <button>s. I'm using graphical buttons for things like next/prev links, but try as I may, I end up with a small (~few pixels) margin around the embedded image. This doesn't matter for most of the buttons, but there is a subset used for navigation and this results in the navbar being unacceptaby wide.

The navigation buttons are being used as implicit <a href> tags, which raises the question "why not just use the tag then?" -- basically, I want everything using the same mechanism, if at all possible. As most of these buttons/links appear within multiple forms (and occasionally standalone) I can't use <input type="image"> tags because of their implicit submit on click. On the plus side their borders/margins can be disabled!

Second, I can't seem to figure out how to have a proper 'onmouseover' event when hovering over a button. The button normally pops up a little tooltip (via the title attritubte), but I want to pop up a thumbnail of the next/prev image when the mouse hovers over the button as well as the tooltip. I could probably hack something together via a hidden <div>, but I'm almost over my head as it is.

The goal of these buttons is to enable a pure-text interface, making it trivial to translate it into different languages -- and the crucial bit is that the rest of the code can't care what the UI looks like.

Hacking HTML/Javascript/CSS/DOM is a far cry from the kernel-land hackery I spend most of my time in. To say nothing of my continuing distaste of PHP!

..PHP still makes me ill every other time I see it. I keep getting the idea of rewriting Photo Organizer using mod_perl, which will surely make a lot of other people feel quite ill. :)

Not much new on the home front -- I'm now taking care of Crystal's Iguana full time, as he's too large to hide in her dorm any longer. We really need to build him a larger habitat -- he's getting larger, and the makeshift cage he's in is just too small now. He's also slowly warming over to me.. which means he's a little less cranky than he used to be.

Over the past weekend, I've managed to successfully install a new ceiling fan in the master bedroom, complete with a remote control. It's nice to have a working (== quiet) fan again, and thanks to the remote, we can control the light independently from the fan. I've also been inhaling solder fumes -- I built a couple of regulated power supplies so I can charge up my Jukebox in the car. That went rather well, actually. My soldering skills are improving.

Meanwhile, I managed to get my hands on a like-new Nikon 70-210mm AF lens -- which is now my new favorite. It's the perfect complement to the 18-70mm lens I've been using. I've given it two workouts so far; A stint at the Miami Zoo and another at a bit of a party last night. I don't have any photos of those online yet, but I hope to soon. I haven't posted anything new in a while now, because I'm in the process of moving everything over to a new backend.

I abandoned photomolo, as it wasn't flexible enough for my needs, and still had the problem of taking way too long to update an album tree. It simply didn't scale to 10,000+ photos. I'm still using its excellent exifiron tool though. Photo Organizer (PO) has most of what I want -- especially the separation of the public view from the backend image repositories. It's also completely database driven (by a real database!), which helps it scale considerably. It has a few warts though, and I've already sent in a few patches, with more on their way.

I'm finished importing everything up to July 2004. We're talking about over 10,000 photos and 20 gigs in total, so it's a slow process, in part due to PO's relatively lousy bulk import features. Once they're all imported, then I get to go through them all and decide which ones to make public. I'm looking forward to that, as I'm discovering all sorts of great shots that I forgot I had.

While the public URL is http://www.peachyphotos.com/po, apparently hanging off shaftnet, it's actually being served from one of my internal servers. Apache has this cool transparent proxy feature that I'm heavily abusing for this project. Another cool thing is that PO is a multiuser system, so allowing other people to set up accounts and their photos is fairly straightforward. One feature I'm glad is missing is the ability to post comments and whatnot on photos. It's a photo album, people.

Being sick, I've been reading more than usual lately. I've now finished up Ringworld, Ringworld Engineers, Hegemony or Survival, The Cartoon History of the Universe (Volume I), Neverwhere, The Giver, In Cold Blood, and a few others I can't quite recall at the moment. On the movie front, Shawn of the Dead rocks. You will go see it. Also on the movie front were Ringu (the Japanese movie that The Ring was based on), Gothika, Employee of the Month (which was mediocre -- until the last quarter of the movie, where it got exceptionally good), The One, Robots, and finally, Terminal.

The Giver was a particularly good book. It goes to show you that the best childrens books have particularly deep meanings beneath their surface stories, including life and death. The Cartoon History of the Universe is also excellent, and I now have volumes II and III to read through once I finish A People's History of the United States.

Oh, and before I forget -- Every now and then I get someone asking me why I don't have a livejournal, use gmail/hotmail, bebo, flickr, or whatever. There are many reasons for this, but fundamentally it's a matter of principle. This same principle is why I run my own DNS/Webserver/Mail[-list] server (ie shaftnet), run Linux in general on my systems, why I'm rolling my own photo album organizer. I want to remain in control of my data; I will not trust my data -- my life's work -- to a corporation, which only acts in its own interests; and where "we can change the terms of this agreement at any time" means you actually have no rights at all.

Plus it's a lot more fun this way, I learn a lot, and I don't have to jump through anyone's hoops but my own. Other people have accounts on my systems, and some of them even contribute to their upkeep. In a way, their trusting their data to me runs counter to the aforementioned principle, but on the other hand, they know me, know where I live, and I tell them flat out that if they don't trust me to be responsible then don't ask for an account. Place your trust in individuals, not organizations.