Month: November 2006

On a side note, gnome-power-manager 2.16.x was pretty much synchronous with hard-coded sequences of operations and functions depending on events. 2.17.x is much better code IMO, with most of the events happening asynchronously and with separate state machines. This makes the code much easier to understand and modify, and should squash some weird timing bugs. It also makes adding new functionality as easy to add as dropping in a couple of gobjects and hooking up some signals.

Black magic. I'm doing lots of work with development versions of the kernel, PolicyKit, HAL and X and I need a clean environment. Ubuntu has lots of black magic, which is great from a “just works” perspective but bad when you are trying to hack on core bits of the stack.

Don't get me wrong, I still think Edgy is great, and would wholeheartedly recommend it for someone new to Linux. For me, Fedora is just right.

Why split the data from the daemon tarball? Well, policy and probing information is still in the daemon package where it belongs. Hal is released every few months with updated dependencies and lots of snazzy new features. Users love this, stable distributions hate it, and don't update HAL, missing the newest hardware quirk updates. This means that new hardware often won't work out of the box until the next version of the distro is released.

So, for example, stable distro 'x' ships HAL 0.5.9 with no intention of updating it other than for security fixes. Stable distro 'x' does however update from hal-info-20061107 to hal-info-{date} as there are no new features, minimal risk of breaking, and lots of chance that more stuff that didn't work now will.Note: the hal-info version does not match the hal version – by design. Expect more frequent releases of hal-info than hal.

What does this mean:

for an end user: Not much – all the fdi files are installed in the same places as they used to be. hal-info updates might be a little more frequent, and more new hardware might just work.

for a distro packager: hal should depend on hal-info, of any version. Existing patches to the fdi files in fdi/information should be moved to the hal-info product.

for the release architect: updating hal-info shouldn't break anything that already works or add new dependencies.

for the developer: hal-info should be checked out in the same level directory as hal if you intend to use ./run-hald.sh

I've just read Bruce Perens blog about the Novell and Microsoft agreement.

One sentence that made me think is “…Novell will help Microsoft turn back the Open Document Format and substitute something Microsoft controls…” – now this is Bruce's not-so-neutral opinion, but I personally read this as “Novell might be persuaded to stop actively pushing ODF”. Maybe I misunderstand the agreement.

Basically my concern is simply thus: Why is Microsoft partnering with Novell? I'm sure they're not doing it for the fuzzy pink feeling, but rather long term commercial gain.