Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Plumbing the depths of poor interface design

I hit a particularly precise example of Rusty's API quality spectrum today in some WBEM code.

What's wrong with this code?

member_kb.append(CIMKeyBinding("CreationClassName", "HP_Processor"));

Not much, on first glance. Looks pretty reasonable. But it turns out for some reason that CreationClassName is getting recorded as True, because the second argument gets coerced to a boolean (being non-null). The fix is

member_kb.append(CIMKeyBinding("CreationClassName", String("HP_Processor")));

Yes, this code has its own C++ String class, which is perhaps forgiveable in old code. What is less forgiveable is that C-style char* will almost, but not quite always get coerced into a String object; sometimes into something else. I could even cope if it gave an error and made me go back and check it ("compiler won't let you get it wrong"), but this is just bizarre.

This achieves a pretty high score's on Rusty's scale: The obvious use is wrong.

[This is not a reflection on OpenPegasus as a whole, which is actually pretty clean aside from being non-STL. That's just where I happened to find the example.]

posted Mon 20 Dec 2004 in /software/aesthetics | link

Stablity is a chimera

LWN has yet another thread on kernel stability. Some people would like to be able to install new drivers on old kernels. This is the mirror image of something also often requested: being able to use old (typically binary) drivers on new kernels.

Satisfying both at once requires not just backward- but also forward compatibility: the interfaces between interchangeable parts of the kernel must not change *at all* within a stability window. This is very constraining to development, and since people would like to use years-old binaries the window is very large. So in fact this is possible, if we define the stability window to be exactly one kernel release: anything that works against 2.4.20 will continue to work against 2.4.20 forever.

More generally: everyone would like a stable series that lets them get the bug fixes they care about, but without any unnecessary changes. The problem is that different people have different requirements for what is allowed into the stable kernel series. Some people really need support for some new hardware, but to everyone else that's unnecessary churn. Some people want nothing but security fixes; some people want security and bug fixes; some people want new drivers but no core kernel changes; some people need scheduler changes to run their workload effectively.

It is fundamentally impossible to reconcile all of these changes; therefore the optimal approach is to develop the mainstream in the most efficient way possible, and let people fork stable branches as they want. If you want to build a branch which has only bug and security fixes and nothing more then you can.

posted Fri 17 Dec 2004 in /software/linux-kernel | link

Pasting wrapped URLs in Mozilla/Firefox

Discovering this really made my day: if you go to about:config and set editor.singleLine.pasteNewlines to 3 then Firefox will just Do the Right Thing when given a URL split over several lines. I wish this behaviour were the default. (#23485).

posted Fri 17 Dec 2004 in /software/mozilla | link

Thought for today

There are probably nine other people on the planet who are thinking about the same idea right now. The only question is which one of you is actually going to make it happen. — Eric Sink

posted Thu 16 Dec 2004 in /random | link

Metacity "reduced resources" mode

% gconftool-2 -t bool -s /apps/metacity/general/reduced_resources true
% metacity-message restart

This turns off opaque resize/move, animations and so on. My 3-year-old work machine has an expensive-but-useless graphics card that is only fast when used with proprietary drivers. Since I only display Firefox, rxvt and emacs it's not worth the hassle to install them. This gives a nice speedup.

posted Thu 16 Dec 2004 in /software/gnome | link

py.test

Ian Bicking writes of py.test, a Python testing framework.

It is, to be sure, a big improvement on the standard unittest module, which has far strong of a Java flavor to be comfortable in Python. It is similar to my comfychair in some ways, and probably superior at the moment (though there are some comfychair features I am quite fond of.)

I think the problem with unittest (and to a much lesser extent the current version of comfychair) can be seen by considering a definition of a class: a class is a set of objects with different data sharing common behavior.

That implies one should create a class when there is particular behavior, and when that behavior is common to more than one object.

It is a mismatch if one needs to create a class to hold behaviour that isn't coupled into any particular object. Classes with only a single method are a bad smell but are common in unittest suites. It's also somewhat conceptually unclear what the object created by such a test fixture is meant to represent.

[more later?]

posted Wed 15 Dec 2004 in /software/testing | link

Brad informs me that Konqueror already does this.

posted Mon 13 Dec 2004 in /software/mozilla | link

Manpage URLs in Mozilla

I wish I could type man:ls in Mozilla and have it render the manual page from my local system. I wonder if someone could do this (or has done it?) as a plugin? I know there are manpage gateways on the web and available for local use but I'd rather it was more integrated.

It turns out to work quite well to register, say http://seth.positivism.org/man.cgi?q=%s as a quick search called "man", though that's not quite current for my machine.

posted Fri 3 Dec 2004 in /software/mozilla | link

An amalgam of distributed version control

I've been hanging out with some of the GNU Arch hackers. I had started out trying to describe what GNU Arch ought to take from other systems — primarily simplicity in both model and interface. There are some good ideas in Arch, but also a lot of what is technically known as "crack". [*This somewhat offensive term seems to have acquired the meaning in GNOME of "unnecessary user-hostile complexity".] I have ended up thinking that Arch is not the right foundation for this.

A huge amount of good thinking has gone into various distributed systems over the last few years. I don't personally find any of them totally satisfying, but I think trying to pick the best ideas from each into a new codebase may work well.

There may be some code in a while.

The high points:

• Simple things should be simple (remember this single file locally); complex things should be possible. At the low end I would like to be as simple as RCS; at the high end as powerful (or nearly as powerful) as the existing systems.
• Version control systems have several purposes: collaboration, branching, undo of mistakes, backup, tracking down bugs by looking at history, distribution, etc. Experimental systems (e.g. Darcs) may choose to ignore some, but I think a "serious" system cannot.
• The history by which a patch arrives at its eventual destination is interesting; this history includes who merged the patch, what they did, and what trees it passed through. Only Arch, as far as I know, keeps track of this.
• The Arch interface is too complex. This complexity is not merely in the user interface but rather saturates the model. It is not desirable to use wrappers to hide underlying complexity. It must be removed by radical surgery; fortunately I think no one will miss it.
• Allowing anonymous read-only access by just putting files on a web site is very nice for both usability and security.
• Cryptographically signing revisions/changesets is also good, and falls fairly naturally out of deciding that history should be append-only. Signing should be done by GPG (unlike Monotone) — open source developers have already built up signed keys and we should use them.
• Unless there is a good reason to do otherwise, the interface should be familiar to users of CVS and Subversion: add, diff, commit, ignore, etc should work as expected.
• There are two basic complex merge problems: cherry-picking changes, and history-sensitive merging within an arbitrary graph. I don't think any single existing system (open or closed) can do both correctly, but I think it is possible.
• History should be strictly and reliably recorded. I want confidence the system can reproduce my tree's state at any point in the past. At the same time people want exemptions when for example accidentally committing confidential information.

More later. I have a lot more documentation and the start of some code. I have shown a mockup to both Arch developers and Arch haters and both sets liked it.

Havoc has posted a list of desired features. I think my design can address most or all of them, some in quite entertaining ways. Some of the more workflow-related requirements I think I would keep out of the core tool.

Other comments from Tom and Colin.

posted Thu 2 Dec 2004 in /software/vc/bzr | link

An amalgam of distributed version control

I've been hanging out with some of the GNU Arch hackers. I had started out trying to describe what GNU Arch ought to take from other systems — primarily simplicity in both model and interface. There are some good ideas in Arch, but also a lot of what is technically known as "crack". [*This somewhat offensive term seems to have acquired the meaning in GNOME of "unnecessary user-hostile complexity".] I have ended up thinking that Arch is not the right foundation for this.

A huge amount of good thinking has gone into various distributed systems over the last few years. I don't personally find any of them totally satisfying, but I think trying to pick the best ideas from each into a new codebase may work well.

There may be some code in a while.

The high points:

• Simple things should be simple (remember this single file locally); complex things should be possible. At the low end I would like to be as simple as RCS; at the high end as powerful (or nearly as powerful) as the existing systems.
• Version control systems have several purposes: collaboration, branching, undo of mistakes, backup, tracking down bugs by looking at history, distribution, etc. Experimental systems (e.g. Darcs) may choose to ignore some, but I think a "serious" system cannot.
• The history by which a patch arrives at its eventual destination is interesting; this history includes who merged the patch, what they did, and what trees it passed through. Only Arch, as far as I know, keeps track of this.
• The Arch interface is too complex. This complexity is not merely in the user interface but rather saturates the model. It is not desirable to use wrappers to hide underlying complexity. It must be removed by radical surgery; fortunately I think no one will miss it.
• Allowing anonymous read-only access by just putting files on a web site is very nice for both usability and security.
• Cryptographically signing revisions/changesets is also good, and falls fairly naturally out of deciding that history should be append-only. Signing should be done by GPG (unlike Monotone) — open source developers have already built up signed keys and we should use them.
• Unless there is a good reason to do otherwise, the interface should be familiar to users of CVS and Subversion: add, diff, commit, ignore, etc should work as expected.
• There are two basic complex merge problems: cherry-picking changes, and history-sensitive merging within an arbitrary graph. I don't think any single existing system (open or closed) can do both correctly, but I think it is possible.
• History should be strictly and reliably recorded. I want confidence the system can reproduce my tree's state at any point in the past. At the same time people want exemptions when for example accidentally committing confidential information.

More later. I have a lot more documentation and the start of some code. I have shown a mockup to both Arch developers and Arch haters and both sets liked it.

Havoc has posted a list of desired features. I think my design can address most or all of them, some in quite entertaining ways. Some of the more workflow-related requirements I think I would keep out of the core tool.

Other comments from Tom and Colin.

posted Thu 2 Dec 2004 in /software/vc | link

Copyright (C) 1999-2007 Martin Pool.