Havoc's Blog

On the ninth day of traveling. Getting a little sick of it. We went on
a really cool sailboat ride around San Francisco bay tonight though.
Back home far too early on Friday morning.

Red Hat joins the blog aggregator
movement, check it out. The master aggregator merges
sub-aggregators for executives, other employees, and the Fedora Project.

Following those links I just saw Tom
hacking on GDirect.

Please test the new Metacity magic to try and automatically figure out
whether to focus newly-opened windows and report bugs… this really
needs to work well for 2.8.

(This post was originally found at http://log.ometer.com/2004–08.html#5)

Currently at OSCON. My
presentations are both somewhat updated versions of talks I’ve given
before, but the slides are Creating a Desktop
OS and D‑BUS.

(This post was originally found at http://log.ometer.com/2004–07.html#28.2)

Filesystems
are not the answer, what we need is a document
store. None of the open source desktop projects will ever
depend on ReiserFS or similar features. Because these projects have to
be able to work with NFS, GFS, AFS, and across multiple UNIX flavors.

The document store approach is to create the equivalent of an IMAP
server, or WebDAV server, but with a richer set of functionality and
the ability to run locally. Document stores are not filesystems; they
store structured data not byte streams, and while they may have a
hierarchical-namespace “view” the hierarchical namespace isn’t their
core organizing principle.

A key thing to realize: you don’t have to use the same solution for
user data (“home directories”) and system implementation details (the
OS itself, random junk in /tmp). The traditional filesystem is just
fine for the latter. User data can and should be special-cased. You
don’t want user-invisible implementation details showing up in search
results and the like, anyhow.

Another key point is that apps can move to a document store piecemeal,
just as IMAP is useful even though it’s email-only. There’s not a boil
the ocean “get everyone to switch” problem.

Examples of the document store approach include WinFS, GNOME Storage,
Chandler Repository, and the IBM Workplace data store.

(This post was originally found at http://log.ometer.com/2004–07.html#28)

Had dinner and a beer with Jon Trowbridge tonight, fun to go in to
Cambridge. As ex-UofC we should really spend more time making fun of
Harvard, don’t get around to that often enough. GNOME has a long U of
Chicago tradition including Owen, Dan Mueth, and Sam TH of GNOME
Office fame.

My bike has the interesting property that it looks like I ride it a
hell of a lot. That’s because there was a time when I did. So it’s
beaten and worn, has “serious biker” components (e.g. seat that hurts
like hell), and you have to bend in half to reach the handlebars.
Not good if you haven’t done it in a while.

On the topic of GNOME forks, a fundamental free software
maintainer responsibility: if you reject a patch, don’t complain
about forks that add the patch. If someone wants to make “GNOME for
geeks” then great. Not that I think this particular project will
succeed, but anyone is welcome to try.

I think the free software world is sometimes too hostile to forks;
having people with substantially different goals trying to work on the
same project doesn’t work out that well most of the time. You sort of
have to agree on the project parameters to get anywhere. That said,
it’s important to be sure the goals are genuinely different.

Nice to see Bryan spelling out the rules on application
naming, I think what confused all the hackers is that we have a
different guideline for things that come with GNOME, and things that
don’t. Sort of ties in to my talk where I
defined a platform as a unit that’s designed (interaction/UI-wise) as
a whole. Modularity is good engineering and bad interaction design
most of the time, the ideal is to make the implementation modular
and the user experience integrated. Which can be tricky.

So we have a problem that the menu spec was written without
understanding the desired UI. We need to fix the spec somehow.
Unless OnlyShowIn=GNOME fixes it, which I suppose is possible in many
cases.

I don’t think anyone would seriously argue that “Calculator” or
“Dictionary” should be named things like “Frobfoodle” or
“BlatherMaster” or other obscurity, so I think the disagreement here
is on where generic names end and specific names begin, not on whether
each should exist.

(This post was originally found at http://log.ometer.com/2004–07.html#25)

Took my bike to the shop for a tune up, new tubes, new bar tape. Then
got back on and rode around for the first time since smashing my wrist
into little bits two years ago, just before GUADEC Copenhagen.

Exercising again after long periods of sitting on one’s ass is
painful. I always get air whistling through my ears somehow, burning
lungs, and a strong urge to vomit. My memory is that this goes away
after a few days of regular exercise, but I haven’t tested that in
several years, given that the wrist smashing episode also came at the
end of a long sedentary period.

I’m off on a nine-day trip (OSCON, LinuxWorld) in a couple days, so I
can’t really get started on the regular exercise until I get
back. We’ll see how that goes.

(This post was originally found at http://log.ometer.com/2004–07.html#25.2)

Blizzard
took notes on Tom Fitzsimmons’s talk, also I thought
this link
from the slides was a good overview.

(This post was originally found at http://log.ometer.com/2004–07.html#20)

My slides,
also blizzard
took some notes.

(This post was originally found at http://log.ometer.com/2004–07.html#19)

Nice
to read this article because it rings so true. Usability advocates
such as Alan Cooper point out
that feature-matrix-driven development results in bad design and bad outcome
for users.

However, that I remember Cooper doesn’t point out the cause of
feature-matrix development. I hate to do it but I’d place a big part
of the blame where this Microsoft Money guy does: reviewers.

There’s nothing more frustrating than to spend many months figuring
out what your users want, then read a review where the reviewer has no
idea who the target audience is or what they could really benefit from.

What makes this especially bad is that it’s the overwhelming rule, not
the exception. Reviewers have no idea what would really make a
product good or bad, they just do a feature matrix or review the
product as if the target audience were magazine reviewers.

Do we need a Consumer Reports for software, based on real research
and knowledge?

Why don’t developers just ignore reviews? Because reviews have real
impact on what people think and do. Not just for commercial software;
volunteers writing free-of-cost software are sensitive to this as well.

Getting a clue for more reviewers and pundits would probably do more
for usability than evangelizing every programmer in the world. The
developers will come over naturally if the incentives are in place.

(This post was originally found at http://log.ometer.com/2004–07.html#3)

I consolidated my
current thinking on where we should go with a config system in the
future, it was sort of spread around between piecemeal emails and web
documents.

(This post was originally found at http://log.ometer.com/2004–07.html#3.2)

On Donald
Norman’s recommendation I’m trying the Harmony remote. Pretty nice.
However, I’ve now seen the phrase “Rebooting your
remote…” and that scares me a bit.

Hint, if you get one of these the Harmony web site has some
refurbished ones at a discount.

(This post was originally found at http://log.ometer.com/2004–06.html#19)