Havoc's Blog

Evolution guys bringing up complex data structures again, here’s an
old mail on the subject. Check my “list of things I was planning
to get around to” in that mail, ah the follies of youth…

Storing “structs” (or dicts/hashes) as little XML strings could be a
totally sane underengineered solution, but surely needs some
convenience API around it, or perhaps standardize the XML format and
add a GCONF_TYPE_DICT_STRING rather than using GCONF_TYPE_STRING
ambiguously.

Increasingly clear that gconf needs a lot of work, notes here
for example. But I’m not sure how to get this done, I’m afraid that a
total
rewrite would just make different mistakes instead of
creating the Right Thing. Not that I’ve ever rewritten anything…

For the average admin, the primary mistakes in gconf (other than
multiple-login design bugs) seem to be things
that are confusing. Here are some of those and possible solutions.

1. The XML file format is confusing; the format itself is ugly,
the fact that it uses a filesystem hierarchy instead of a single file,
the starting filenames with “%” to avoid clash with key names, and the
historical lack of whitespace in the files… either a DB database or
a single huge XML file would have been less strange, though neither
would be as robust as the current setup, it would be more obvious how
things worked.

2. The fact that “schema objects” (GCONF_TYPE_SCHEMA) are “installed”
into the config database itself confuses the hell out of people; it
means there are two things called “schema” (.schemas files and
GCONF_TYPE_SCHEMA) and two things called “defaults” (the default in
the schema and the default in /etc/gconf/gconf.xml.defaults). Making
this worse, RPM spec files change one default and admins are supposed
to change the other default. Piling on to the confusion, schemas
aren’t exactly the same thing they are in LDAP terminology.

The solution I’d propose here is to yank schemas out of gconfd and the
config database entirely. Make them just XML files; apps load the ones
they care about at runtime and read the defaults themselves;
gconf-editor just loads them all. So have only .schemas files, not
.schemas in the database.

That does still leave people trying to edit the .schemas files to
change defaults, instead of changing gconf.xml.defaults. Not sure what
to do about that. Maybe it’s just not a problem.

3. Apps that have “profiles” add another layer of complexity that’s
sort of a pain in the ass. See gnome-terminal (or the panel which
has the complexity but not the user-visible profiles feature).

4. The panel has its own ad hoc complexity, as described here
and here.
I believe the panel could avoid this, by just copying the current
setup to new screens, or by creating a config source with ~/.gconf
removed and copying that. Or by using
gconf_engine_get_default_from_schema() or similar. Unfortunately
the panel is the number one thing any admin wants to configure, so
its extra complexity is most people’s impression of gconf itself.

5. gconf-editor doesn’t expose the right way of thinking about the
system, because it simply edits the current user’s
configuration. Ideally, we’d have a much more admin-task-based UI that
could do things such as “dump the current panel configuration to a
file”, “create a kickstart script to load said file”, or at least
“edit the systemwide default or mandatory settings.”

Anyhow… aside from all these gripes, the basic idea of gconf I
believe has been proven useful in practice. A process transparent
model-view approach to settings is the right architecture with genuine
advantages. But after a couple years remaining more or less unchanged,
some iteration and evolution towards a better implementation seems
long overdue.

One thing that has been fixed up recently is that the panel and
other apps in principle handle locked-down keys. Maybe it’s almost
reasonable these days to log in with ~/.gconf removed from one’s gconf
path, and start filing bugs about stuff that breaks…

Though that raises another topic, should frequently-changing transient
state such as current window positions be in gconf 😉 Consider an
LDAP backend, where LDAP is totally unscalable for writes and
reasonably scalable for reads. And of course this transient state
should get saved even on a fully locked-down desktop. So should
removing ~/.gconf even be counted as reasonable? The fuzzy split
between data, preferences, and transient state comes back to haunt us.

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

I might add, simply using files for user data — documents, address
book, calendar — is totally plausible to me. Make these files
non-dotfiles in the home directory. Maybe make them a single file with
a MIME type, so you can just drag and drop your calendar or address
book between systems.

Or use dotfiles. e.g. metacity uses dotfiles to save sessions.

Files lack change notification and make it harder to write
configuration UI such as a generic management tool or the control
center. They make it hard to do lockdown in a generalized way and
support a central data store for an entire network. But this stuff
doesn’t really matter if the file is genuinely data, rather than
preferences. The home directory is where user data lives.

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

Satellite TV guy came today and said we had to put the dish on a big
pole in the middle of the yard, or chainsaw a bunch of trees; time to
fall back to Comcast…

IBM laptop support is impressive: laptop hard disk died, I called late
morning, they had me a new one the next morning. Didn’t have to send
the old one back, didn’t have to argue. I’m now using the 2.6 kernel
on my new drive.

Christian: presumably up2date/yum is slow on Fedora because the
default mirror is swamped. Look here,
edit /etc/yum.conf.

Seth, Jonathan, and Federico are really rescuing the file selector
situation at the last minute. Those guys rock.

Encouraging signs on open source Java in the news this week; this
would be fantastic for GNOME and free software overall, uniting all
the not-Microsoft platforms into a single juggernaut. I mailed
everyone I could think of with a quick .02 that we need not only open
source but also GPL-compatible, so we can really use Java throughout
the OS.

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

I think we finally have the whole lineup for which candidates fit in
which positions for Hiring Phase 1, and thus will be able get back to
everyone who’s applied pretty soon. Crossing my fingers, I don’t like
leaving people hanging, but it just takes a lot of time to do
responsibly. More positions should open, but finishing up soon for the
spots with immediate start dates.

Went to EuroTrip with Blizzard, Shona, Jeremy, Seth last night; it was
a pretty good movie if you like the “American Pie” sort of genre. I
laughed hard. Before that we ate at Blue Ribbon which was deemed an
acceptable barbecue restaurant — although those of us recently
arriving from North Carolina were unsure of authenticity and
questioned the lack of hush puppies.

On the technical side, I made a metacity release (yay!), but have some
patches I really need to look at. There’s an interesting one on the
D‑BUS list to add
SELinux support.

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

Had a pretty nice vacation weekend in New York, I’m still here but
shifted from vacation to Red Hat business trip. We had a lot of fun
the first couple days. Some part of walking around in the cold,
eating dubious food in Chinatown, and drinking a bit too much
made us really sick on Sunday, so mostly sat around and watched TV and
read email.

Apparently not a virus though, so all good today. Taking the Acela
home, took the LimoLiner here. We’ll see how they stack up.

The last couple weeks I’ve been waking up in the 7–8am timeframe every
day; tomorrow I have to do the same. It almost feels normal… I
haven’t really done this since high school.

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

Still no Internet at home. DSL is apparently unavailable so it looks like
we’ll get cable instead.

At work, I’m beginning to see the light at the end of the tunnel and
may get back time to maintain metacity properly yet. In the meantime,
please mail me with any emergencies. I hear rumors of crashes but
don’t know if these apply to HEAD or are the already-fixed ones. Need
to make a new tarball and build in Fedora Core 2. I’m hoping to keep
up with metacity maintenance while unloading my other modules as the
right people appear to own them.

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

The hard bits of moving and housing now done! All that remains is to
catch a plane back to Raleigh, hop in the car, and drive the car up to
our house. Well, modulo some details.

Some new developers start at Red Hat this week, which we’re excited
about. We’re giving some open source desktop contributors more time to
contribute, but we’re also looking to add some new developers who
perhaps haven’t focused on the desktop in the past. As always I have
to link to
my job postings. On Friday HR gave me a giant pile of resumes that
they’ve received, I’m steeling my resolve to start reading them all.

But does
Murray have a resting heart rate well below 30 beats per minute?

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

Packed my cube yesterday, only a couple hours of going through the
pile of paper on my desk. I was amazed at the age of the paper on the
bottom. GNOME nostalgia packed includes the squeaky rubber GNOME (see
item
7), an original Ximian monkey, and the big GNOME foot used for
conference booths back in the day. I also packed the N64 used for
daily RHAD Labs bomberman games over the 1999–2002 period or so.
A tradition worth restarting.

Tomorrow the packers come to put our apartment in boxes and we’ll be
camping on floors for a week and a half while it’s all in transit.

Fedora People
is very nice to have, given the horrible signal-to-noise of
fedora-devel. Our new leader Christian declared priority 1: setting up
CVS and build infrastructure, a prioritization I agree with
strongly. Once we get that all else will follow. It’s really an
enormous technical challenge on some level, but the right thing to do
is “screw it, do something broken and fast for now, evolve it later.”

I thought it would be fun to give Seth the redhat-menus package
(contains the menu files for Fedora and RHEL). Read the bugs on this
package and you’ll understand the pain. Seth we love you. My other
packages mostly remain unowned at the moment; Alex and Jonathan are
picking up the critical issues. However, some new faces are arriving
soon.

Imendio is rocking with some D‑BUS enhancements. Nice to see that
moving forward.

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

Well, it isn’t quite over yet. Still going back for closing comments
in a couple hours. Very nice conference overall.

Gave a keynote talk this morning, which just destroyed my throat
somehow, though it was only an hour of talking. I suggested deciding
who to buy your Linux desktop from by comparing
this
photo with this
one. Mostly though I had a lot of text and serious stuff about how
we’re going to succeed on the desktop.

Will be back in the US on Sunday night, then swinging by LinuxWorld
for a bit, then back home to pack up the apartment, up for the house
closing, down to get the car, and finally landing in Boston in a
couple of weeks; at that point I hope to avoid traveling for a good
long while.

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

Successfully arrived at linux.conf.au. So far the awesomest conference
ever; Michael kindly picked us up at the airport, hotel room is sweet,
free Internet in the hotel and around the city, nice bag/hat/shirt,
the works. Adelaide is a beautiful city from what I’ve seen, very
similar to California.

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