I finally found some time to devote to hacking on the DG834G. Given that it seems the bootloader checksums almost the entire flash on each boot a writeable flash file system doesn't seem to be an easy option. This rules out vanilla OpenWRT unfortunately, which is a shame given the AR7Port. However as I'm familiar with OpenEmbedded (which seems to be non working at present, but is behind OpenZaurus which I run on my C3000) I decided to have a look at getting that going. So now I have an image that boots, creates a ramfs for /, pivotroots the flash round to /media/realroot, creates a bunch of symlinks and should give me a basic filesystem to play with. Except it's not very happy, producing INIT: PANIC: segmentation violation! sleeping for 30 seconds. messages. Booting to just /bin/sh works fine, but various things won't run. I'm currently blaming this on the fact I haven't changed the default Netgear kernel from 2.4.17, so the next course of action is probably to use an OpenWRT based kernel and see how that goes.

Ok, so my brain is right now thinking on how to make Comas (my Conference Management System, which is quite nice, but somewhat unflexible. Sorry for the butt-ugly and incomplete webpage...) more flexible - And I have come accross some quite nice things. First of all, I want the fields for each person (the person table) to be easily modifiable, allowing me to add/remove attributes at will between different instances of Comas. Ok, this is the muscle behind my new idea. Yes, PostgreSQL-specific, as basically everything in Comas:

CREATE OR REPLACE VIEW table_attributes AS
SELECT c.relname AS tablename, a.attname AS attrname, t.typname AS type,
a.attnotnull AS required, d.description AS description FROM pg_class c
JOIN pg_attribute a ON a.attrelid=c.oid JOIN pg_type t ON a.atttypid=t.oid
LEFT OUTER JOIN pg_description d ON d.objoid=c.oid AND d.objsubid=a.attnum
WHERE a.attnum>0 AND a.attisdropped = 'f' AND c.relkind='r' AND c.relname
NOT LIKE 'pg_%' AND c.relname NOT LIKE 'sql_%'
ORDER BY tablename, a.attnum;

Nice, but still not enough - As with any other RDBMS, fields can not only hold data, but -of course- they can be foreign keys, referring to data in other tables. Ok, in order to check those relations and be able to build a map of the relations in my DB, I came up with this:

CREATE OR REPLACE VIEW related_tables AS
SELECT c1.relname AS referrer, c2.relname AS refered, a.attname AS ref_key
FROM pg_constraint con JOIN pg_class c1 ON con.conrelid=c1.oid JOIN pg_class c2
ON con.confrelid=c2.oid JOIN pg_attribute a ON c1.oid=a.attrelid AND
a.attnum=ANY(con.conkey) WHERE contype='f' ORDER BY c1.relname, c2.relname;

In the first query, note that I am excluding from what I report all the tables starting with pg_ or sql_ - While that's a usual convention in Postgres, there surely is a better way to do it, some attribute signalling it's a system catalog... But, at least for now, this covers my needs.
Anyway, this might come useful for your projects. PostgreSQL introspection is fun! (Yes, those two queries are the result of many lonely hours going through the documentation and a couple of spontaneous questions to several friends - But it's worth it!)

According to an announcement of the Galeon developers on their website and the Galeon announcement mailing list, Galeon is more or less dead. It has been superseeded by the more actively developed Epiphany and most of the Galeon (1.3 to be correctly) features which are not already in Epiphany (can’t be that many *harhar*) will be either implemented as Epiphany plugin or — if impossible as plugin, like e.g. middle click in menus or similar things — shall be ported to Epiphany. The Galeon developer team will focus their work on the Epiphany plugins, but still plans to once release Galeon 2.0. (Somehow I always thought, Galeon 1.3 is what meant to be Galeon 2.0.) Having read this, I’m even more convinced that Kazehakase will fill the gap Galeon 1.2 has left behind. Oh, and btw Erich: plugins or extensions are the only thing I sometimes missed in Galeon, as well in 1.2 as in 1.3. :-) But having no turing-complete extension language is the drawback you have, if you want a fast and stable browser…

This Gnomedesktop posting outlines the future of galeon. All it's users (and maybe former users, too) should read it... Basically: the main (current) galeon authors don't have enough time to work on galeon (e.g. on the bookmarks editor, which has some issues). Epiphany, which was forked off Galeon, has a much more active developer community, a more up-to-date codebase, including an extension system. So the galeon authors decided to try to work galeon into epiphany extensions as far as possible (btw, epiphany is to get hierarchical bookmarks independently, so one of the big issues many people have with it is gone then) and maybe make a new Galeon based upon Epiphany to add these features which are not possible with Epiphanys' extension system. Neither Galeon nor Epiphany currently have an easy standing. For example Ubuntu prefers Firefox to Epiphany (albeit Epiphany is way better intergrated in the desktop). This is a pity, since IMHO firefox suffers from featurits. Also I'm not a fan of extension systems like in epiphany and firefox. Especially with firefox, the code quality of extensions varies a lot. And even extensions that are really useful (e.g. the webdeveloper toolbar, albeit it offers little more than I do in Galeon with Bookmarklets) still suffer from some old bugs (e.g. the "show divs" menu item will still be checked after you changed the page) that are maybe just not fixeable in the extension. At the same time, using extensions basically means that the application will be (and behave) different on the machines you work on, unless you spend a lot of time in installing the same extensions everywhere (and then in turn syncing their configurations as well etc.). Neither will the UI be consistent, themes won't support the extensions etc.

The DCC Alliance (not to be confused with the DCC Alliance, which is entirely unaffiliated with the former. But it's a recursive acronym, so there's NO TRADEMARK ISSUE) aim to produce a distribution which is entirely binary compatible with Sarge. A laudable aim. Sadly, there's a bit of a problem.

OpenOffice.org 2.0 was released this week. In common with previous versions, it's a horrid mixture of C++, Java and assembler. It's the Java that's the problem, of course. To compile it, you either need Sun's ridiculously non-free Java, or you can use gcj. That's gcj 4.0, of course. Which can be installed in parallel with gcc 3.3, so that's not a problem. Except. gcj 4.0 wants the libgcc from gcc 4.0 (unsurprisingly), which has the same SONAME as the libgcc from 3.3 (correct behaviour - code built against libgcc from 3.3 will run fine with libgcc from 4.0). However, libgcc from 4.0 adds some extra symbols - as a result, code built against libgcc from 4.0 will not necessarily run on systems with libgcc from 3.3.

Or, in other words, shipping libgcc from gcc 4.0 will result in a system that will build binaries that can't be installed on machines running plain Sarge.

So, there's a bit of a dilemma. Either

• Fail to support OpenOffice.org 2.0


• Only support OpenOffice.org 2.0 if non-free Java is used


• Break binary compatibility with Sarge


• Do something really quite nasty

The DCC Alliance want to build a distribution base that's binary compatible with Sarge. It's an entirely laudable aim, and (regardless of any impression I may have given in the past) I hope it's successful. But. That level of binary compatibility inherently compromises your ability to use new software. To begin with, you can work around that - backport code to older versions of libraries, include local copies, do static linking, that sort of thing. Over time, it gets harder.

Optimistically, Etch will be released in December 2006. If we assume that DCC releases occur at roughly the same rate as Debian ones, we're looking at 18 months until we get a DCC based on etch.

In 18 months time, is it really going to be possible to build a useful modern desktop system that's binary compatible with Sarge without it being an utterly unmaintainable pile of ugly hacks? Even after 5, we're seeing pain.

There's a reason that derivative distributions tend to diverge from the original project. It's because it's really quite remarkably difficult to maintain sanity, technical correctness and not change any of the underlying structure. I'd like to see DCCA succeed in doing so, and I do admire them for not just giving up in exasperation already.

XOrg 6.9 RC1 was released some days ago, and yesterday David Nusinow uploaded it to Debian experimental. XOrg 6.9 RC1 features EXA, a new 2d acceleration architecture for X11, developed by Trolltech KDE hacker Zack Rusin, that should improve Composite performance a lot. I tried again xcompmgr, kompmgr and transset and they behaved a bit better than they did the last time I tried, but it’s still not acceptable for permanent desktop usage. I’m really looking forward to the next XOrg releases

Recently, I bought a copy of Wil Wheaton's book Just A Geek. I've read one chapter so far. And I have to say: great book. This has to be one of the most insightful, brutally honest books I've ever seen. It's also funny. Here's a little snippet, recalling his first-ever book signing:

... a guy walked over to me, and extended his hand. "Hi, Wil," he said, "I'm Tim O'Reilly." HOLY MO-- WIL! IT'S TIM O'REILLY!! HE CAME OUT TO SEE YOU! Before I could scream out, "I KNOW! I KNOW! I KNOW! GREAT GOOGLY MOOGLY!" my brain said, "Stay cool, Wil. Don't geek out." I heeded my brain's advice . . . "It's really nice to meet you," I said. . . Check me out. I totally behaved myself. "Nicely done," said my brain. "Have some serotonin."

Wil talks a lot about his two inner voices: his totally-honest self, and the voice he calls Prove To Everyone Quitting Star Trek Wasn't A Bad Idea, or just Prove To Everyone for short. I think we all have some of Prove To Everyone in us. Especially Americans, and free software hackers, where competition and, well, proving onesself are expected. It's time to loosen up a bit. I'm going to enjoy the rest of this book.