Havoc's Blog

A while back I posted
some thoughts about version control, I feel like these
posts
get at the same point.

People are artificially restricting the design by accepting the same
“boundaries” as CVS, leaving bugzilla, email, an IDE, mailing lists,
etc. all out of scope and with a fixed relationship to the version
control system.

Recent funny-because-its-true bad joke from Red Hat exec David Burney:

Q: How many designers does it take to replace a light bulb?
A: Does it have to be a light bulb?

“Does it have to be a light bulb?” is the right question here. The
design space is best taken as something like “a system for maintaining
an open source project,” not “a version control system.”

If someone submits a patch, I should be able to just click “apply to
HEAD” and it’s done. It shouldn’t be about getting a clean checkout,
downloading patch from bugzilla to local drive, applying patch
(figuring out which patch options the person used), creating the
commit message, etc. Should be just one click.

Looking at all the open source version control systems out there, I
don’t really see why they improve my life significantly over CVS. But
if one of them addressed the overall workflow like this I would
absolutely be interested.

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

A
nice article in the New York Times on software patents. I hadn’t
seen the comparison to pharmaceutical companies before: software
companies are getting one patent per $500,000 in R&D costs, while
pharmaceutical companies are getting one patent per several hundred
million in R&D costs. Seems like a good illustration of the problem
that would make sense even to a nontechnical audience.

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

I did some dbus
optimization a while back, but it got lost when we rewrote all the
marshaling code to support fully recursive types. Unfortunately, the
code now has a distributed bloat
problem where the performance issue comes from too many “layers” — to
speed this up I think we need someone to come in with an ugly stick
and do more hard-coding and special-casing and general
de-genericization/de-abstraction.

Usually this kind of speed-over-sanity is one big Bad Idea in desktop
programming (though the kernel and libc are full of it) but maybe dbus
is an exception if we want it to stack up well vs. other
binary-protocol IPC systems. Then again, if we look at the desktop as
a whole dbus is unlikely to be a bottleneck so “who cares” could be
the right answer. We just have to ignore whining from anyone running
dbus vs. other-IPC-thingy benchmarks.

On the plus side, the dbus TODO for 1.0 is
looking awfully short.

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

Charlie and the Chocolate Factory: enjoyed much more than expected,
keeps the spirit of Dahl books. Christopher Lee scenes were awesome.

The Island: not recommended. Good cast, potentially the original
script was good, but the whole thing got the Michael Bay treatment.
Not sure how they got most of the cast to do it (Scarlett claims to have
signed up before learning of the Michael Bay aspect).

Harry Potter 6: very harsh cliffhanger. You might want to wait for 7
to come out, then read the last two together.

Tour de France: not as exciting as some years, but always good.

I predict that Stealth
will be the worst blockbuster of the summer, based on the trailers.
Looks on par with The Core.

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

Thought I’d pile on and help announce an experimental new project… even though I’ve had nothing to do with designing or building it. ☠ has been in GNOME CVS for a while now, but few have seen it in action.

Besides testing the Unicode support of every program that tries to display its name, the ☠ project is an experiment in combining chat with building a persistent document, plus random cool features such as a web-based shared whiteboard.
FAQ links to
Manifesto.
(Those with broken Unicode or a need to use verbal communication can call the project Yarrr, btw.)

For the nerds in the audience, ☠ combines Java, PHP/MediaWiki, and AJAX in order to offend as many developers as possible in a single go.

Red Hat people involved in building this include Jonathan Blandford, Bryan Clark, Diana Fong, Marco Gritti, Alex Larsson, David Malcolm, Seth Nickell, and Colin Walters. (Hopefully I didn’t miss someone.)

Polish, usability engineering, bug-freeness, and all that good stuff are still to come; as I understand it the current version is intended to discover any interesting interaction properties that improve on existing stuff such as chat, wiki, or email. No point dotting the i’s until we know which aspects are worthwhile.

The shiny new ☠ server is a special MediaWiki instance that supports a <yarrr></yarrr> tag. This tag inserts a ☠ discussion into the page. We seem to have a wiki-free edition as well, if you only want to see the discussion aspect or marvel at the wrongness of the JavaScript hacks. Also, an example meeting conducted by the marketing team.

Part of the idea here is that it could eventually be a desktop feature or application; but as the FAQ says, priority one was to iteratively figure out what the software should be like. An in-flux desktop application would require everyone to keep downloading and installing the same latest version. So we started with the web.

If you think this looks exciting, join the mailing list, or grab the code.

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

My plan was to stay just a couple of nights in Ottawa for desktopcon, skipping the
kernel stuff later in the week. But my flight was just canceled and
they didn’t have anything until tomorrow, which would mean missing
almost the whole thing, since I was already leaving a bit early. So I
just asked for a refund.

At the moment I’m stuck in Manchester airport until I can get a ride
home.

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

Federico,
the gconf issues there are fairly well-known; I posted a mail a while
back with some analysis but Google isn’t finding it again.

The big win is not complicated optimizations, it’s just to avoid
loading and parsing a ton of documentation translations that will
never be used. If you do that then gconfd can continue to be horribly
inefficient but still be far faster since there’s far less
data. Cutting down the amount of data is the order-of-magnitude win.

One approach is an mmap cache like the icon cache.

In the long term, a better approach is to just avoid having the
schemas installed and loaded in the way they are now, as
described
here and also here.

Anyway, it just lacks someone doing the work.

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

I was expecting a summer blockbuster action movie, but War of the
Worlds was pretty much a horror film in the tradition of Alien.

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

Software has a state where bugfixing is just as likely to make it
worse as it is to make it better. Metacity is kind of in this stage;
most (but not all) of the open bugs really are not very important,
relative to other aspects of the desktop that people could work
on. And a more interesting observation, it’s not clear that fixing the
last 1% ever gets you to 100%. Why is this?

• Some minor bugs require large code changes to fix and thus fixing them will
  probably introduce another set of unintended bugs worse than the
  original one.
• Even if the code changes are small, there’s a nonzero chance your
  bugfix is broken or inadvertently creates a new bug, and if the bug
  you’re fixing is lame enough, this chance outweighs the value of the
  fix.
• Some “bugs” are really just arbitrary decisions that were made, and
  “fixing” them leads to toggling the arbitrary decision back and forth
  every couple years, which is worse than just picking something and
  leaving it alone.
• A UI design is always about tradeoffs (if only because human tolerance
  for complexity is finite), so there are a bunch of deliberately
  traded-off downsides to a design, and these are “bugs”
• After some amount of time, bugs become features because people are
  used to them and already worked around them; and you’re likely to
  break a lot of working code or human work habits by fixing the bug.

In short, there are some serious diminishing returns on bugfixing
after a certain point.

I think one of the important things software developers only learn
through experience (you can’t learn it from books) is how to tell the
difference between a bug that should be fixed and a bug that should be
left alone.

Most open source developers just leave these “would be nice to fix
someday, I guess” bugs open in the bugtracker forever rather than
argue with the bug reporter, even though an experienced maintainer
knows they aren’t going to get fixed and aren’t worth fixing.

I’m not trying to trivialize the worthwhile bugs, and there certainly
are a few left in metacity (which we would love help with).

Also, I think major changes to something like metacity remain
interesting, for example adding a compositing manager. Or a full
rewrite of some kind, if it had some good goals. Directed major
changes remain valuable even when random bugfix churn is a negative.

The “it will never be finished, ever” aspect of software can be very
depressing. Sometimes I think the videogames industry would be cool
for this reason, especially writing console games. Because you ship
the game, it’s burned to the CD, and that’s it. The code is set in
stone. Much more like other creative endeavors such as painting or
carpentry. None of this “updates” and “next version” nonsense.

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

Aha! yum-utils to
the rescue, now I can do all sorts of silly things. Thanks Seth.

Of course, gtk2 downgrade didn’t fix Evolution. Which random thing to
try downgrading next… maybe I should just debug the thing 😉

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