Havoc's Blog

One of my D‑Bus
wishes is already squared away in the form of a
viewer
that comes with Qt, hopefully distributions will be shipping with
this soon.

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

I went to a fantastic Dylan concert on Sunday night at Boston
University. I’ve been to quite a few of his concerts over the last 15
years or so, and this was one of the best. If you haven’t heard his
new album, it’s well worth it, even a lot of non-Dylan-fans have been
appreciating it. There are a couple more shows left in this tour, one
at Amherst and one in New York I think.

The audience was a lot more age-diverse than usual — maybe in part due
to the Raconteurs opening and the BU location. There were a lot of
parents with their kids, and plenty of college-age people. But the
whole crowd stayed for Dylan and seemed into it, even the stuff off
the new album. All the Raconteurs stayed too, watching from the side
of the stage.

I wasn’t looking forward to an arena show, but it turned out our
tickets were on the third row (which wasn’t apparent from the seating
chart) and that Agganis Arena is not very big and has good sound.

A block of songs at the start of the set were nothing but harsh:
Señor
(Tales of Yankee Power), Honest
With Me, Positively
4th Street, and Masters of
War. Amy says Jack White was getting all into Masters of War and
singing along. (Entire set
list.)

I’m kind of sad I missed the previous night, in the same arena;
the songs were
mostly different and included several of my favorites. But this
was a great performance.

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

Roozbeh,
I have no objective way to know if you or Red Hat’s lawyers have the correct
interpretation of US law and Fedora’s EULA language.

However, I’m tempted to take into account that 1) they are lawyers 2)
they wrote the EULA in the first place 3) they talk to the FSF and OSI
all the time 4) they are pretty much open source licensing experts due
to working here and 5) there’s no indication of bad faith; there
aren’t any payments (let alone $348 million in payments) or even any
apparent benefits to Red Hat.

In short, why would Red Hat’s lawyers be interested in making up a
bogus answer for you? They are probably telling you (or Rahul and
Jesse) their honest opinion about the law.

You and I might not like the law, but that’s a separate issue.

As James
posted long ago, the EULA specifically states that the GPL license
of each individual component “wins,” so I don’t see how a GPL
violation is possible. The EULA flat-out says that it’s superceded by
the GPL’s requirements, as I read it. (I am not a lawyer.)

Finally, there is no change to the level playing field here,
because there aren’t any deals or payments or patent rents
involved. Anyone has the same choice Red Hat does (or probably
doesn’t) have to offer a distribution with or without this clause. So
if there is any benefit to Red Hat, anyone can copy the benefit, and if
there’s any detriment, anyone can remedy it and compete on that
basis. And anyone can copy or remedy this feature of Fedora without
paying anyone or asking anyone, and they can do it today. Maybe Ubuntu
or someone already does, in fact, I have no idea.

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

I’m a moron for posting on this topic, but does
this make any sense? Payments are being made but nobody admits
there’s any reason to make them? (Other than these
348 million reasons.)

Of course, Novell doesn’t have to say there are patents. They just let
Microsoft offer the customer “protection” “in case your house
burns down” and then Novell steps in and says “check it out! We
already paid your protection money for you!”

Or I guess their sales message could be: “Customers, for your benefit
we have paid money to remove a nonexistent threat. That’s $N less
we’ll be spending to provide value to you.” Somehow I doubt it. For
this deal to help Novell’s sales, they have to (at minimum) leave
Microsoft’s bogus claims uncontested.

Let’s see how one tries to weasel out of the spirit of the GPL:

Q1. How is this agreement compatible with Novell’s obligations under
Section 7 of the GPL?
Our agreement with Microsoft is focused on our customers, and does not
include a patent license or covenant not to sue from Microsoft to
Novell (or, for that matter, from Novell to Microsoft). Novell’s
customers receive a covenant not to sue directly from Microsoft. We
have not agreed with Microsoft to any condition that would contradict
the conditions of the GPL and we are in full compliance.

Novell’s end user customers receive a covenant not to sue directly
from Microsoft for their use of Novell products and services, but
these activities are outside the scope of the GPL.

Even if the above is true (I am not a lawyer), it’s a technicality and
an unintended loophole. GPLv3 seems to have new improved
text that might help, and I sure hope the FSF will be making it
crystal-clear in the GPLv3 final draft.

That would force Novell to fork gcc, glibc, and so forth. Something
they would deserve.

As an open source developer, on an emotional level, I feel
Novell (the company) should now be treated like a company
distributing GPL software without source, or for that matter a company
distributing proprietary software without a license. Both are illegal
and against the wishes of the software’s creators.

I’ve written countless lines of GPL software and I am
against it being distributed under Novell’s “protection racket”
terms. If the GPLv3 solves this problem I’d love to switch to it, “tivo clause” or not.

Just to be clear on one thing. I’m not against proprietary software on
moral grounds. I use a fair bit of it for various reasons, though I’m
also a huge open source fan and think open source’s practical and
social benefits are unquestionable.

If any company wants to write and sell proprietary software, then
great for them — open source can compete on the merits. I would also
work on proprietary software and be OK with it, though in
practice I’ve never had a job doing so.

This is not a religious argument about open source, it’s a matter of
respect for a community that works together, and the wishes of
creators. If I write something and put it under the GPL, then
I want it under the GPL where all of us working on it can use
it. I don’t want it to be made proprietary, for someone else’s
benefit, due to some shady deal and legal technicality.
Commercial yes (and encouraged), proprietary no.

In Novell’s world, if I write something and GPL it, Novell will try to
convince customers to buy support from Novell instead of from me (the
original author) because of some nebulous, unspecified,
almost-certainly-bullshit “IP issues” hinted at by Microsoft and
legitimized by Novell for the price of $348 million.

In proper open source, Novell (or anyone) is welcome to take my code
and convince customers to buy support from them because they are a big
company and I’m just some guy on the Internet. But Novell (or anyone)
is not welcome to proprietarize my code. If I wanted them to
take my code proprietary I’d choose a BSD license and not the GPL.
I want them to compete with me on a level playing field by offering a
better value.

I suppose we can’t blame Novell’s executives. I imagine they needed
the money, so asked Microsoft “what would it take for you to give us a
few hundred million?” — and then did what Microsoft asked.

The rest of us should be asking why Microsoft asked for
what they got. Here’s my speculation: Microsoft is much more threatened by
open source as a model than they are by the Linux kernel or Novell
specifically, and they’re very happy to throw a technical bone -
especially one that involves Linux running virtualized on Windows
— if in their mind it could help “proprietarize” open source software
and spread doubt about it.

I’m sure many people will dismiss the above because I work at Red
Hat. Fine. But I have to say, this post would be a lot more
strongly-worded if I didn’t work at Red Hat and didn’t have
to worry about that perception.

If it isn’t obvious, this is a personal opinion and no more. I’m
neither a lawyer nor do I have special knowledge.

I’m pretty sure none of the open source developers working at Novell
were involved in this decision, and I don’t envy them having to live
with it. Hopefully there’s some way the community can make the Novell
execs regret their actions without harming the innocent bystanders.

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

I spent half the weekend rearranging
Mugshot server code to make it easy to add new kinds of “block”
(online happenings the site and client app will keep track of).

I’m becoming a huge fan of Java and Eclipse server-side development. I
think it gets a bad rap because of certain suckages (EJB 2, JSF,
old-style JSPs with inline code, old-style Java without generics or
enums). But modern Java is EJB3/Hibernate, JSP expression language and
tag files, Java 5, and so forth. At its best it’s a very nice
setup (though obviously I can come up with some gripes if pressed).

When we started out on Mugshot we made stupid mistakes since we were
not Java programmers or even server-side programmers, and if there’s
one problem with all this Java stuff it’s a lack of guidance on
overall application structure and which technologies to use.

The more we’ve figured out what’s going on the nicer the codebase
gets. Now the problem is going back and fixing all the clueless code
we wrote while learning. 😉

Later this week I want to add a new block type (perhaps one whenever
someone posts a new Flickr photoset), and write up a wiki page
describing how to do it. This could be a short intro to hacking on the
Mugshot server and also of course a guide to adding new block types.

BTW, Google Desktop
was just updated to store more of its data and settings online (shared
between your computers) instead of on a local disk. Obviously the way
of the future and has been for a while now, and open source should be
in a unique position to modify all the important apps to take
advantage when a server side is available. Tom Tromey is thinking about
it, and I’m also encouraged by AbiWord Collaboration.

In part I think there’s a largish up-front effort to get some colocated servers
and build some of the basics like a user account system. In fact I
know there is because for Mugshot we spent a lot of time on this stuff. If it
helps, anyone is welcome to modify Mugshot’s code and use our
colocated machines to work on providing services to the free desktop.
If it doesn’t help, that’s cool too, but still I hope more people will
think about hacking in this area.

My simple file sharing
hack needs finishing up too (a quick fix is to add a block type
for “new file shared,” so people know when you post something).

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

John
is threatening to roll the D‑Bus low-level
API 1.0
tarball in a couple of days. I just looked back in the ChangeLog:

2002-11-21  Havoc Pennington  <hp@redhat.com>
	* Initial module creation

Coming right up on year 4. Now that’s what I call a conservative
release schedule! The last big API change I believe was:

2005-01-15  Havoc Pennington  <hp@redhat.com>
	* Land the new message args API and type system.
	This patch is huge, but the public API change is not 
	really large. The set of D-BUS types has changed somewhat, 
	and the arg "getters" are more geared toward language bindings;
	they don't make a copy, etc.
	There are also some known issues. See these emails for details
	on this huge patch:
	http://lists.freedesktop.org/archives/dbus/2004-December/001836.html
        http://lists.freedesktop.org/archives/dbus/2005-January/001922.html

Software sure does take forever, in this case double-forever. D‑Bus
has rarely been anyone’s full-time job, and there were several
stretches with essentially no work happening.

What’s the significance of the D‑Bus release? Well, the original D‑Bus
goal was a “system message bus”, to support things like HAL. A secondary
but hoped-for goal was to replace CORBA and DCOP with a
simple desktop-independent IPC system. Both seem to be working out pretty
well these days.

A lot of work remains though. Here are some of the major items:

Bindings, bindings, bindings. The low-level
libdbus does not
need to be growing many new features or much new code at all over the
next couple years, but there’s still all kinds of room to improve on
the high-level bindings as most of them remain pretty immature.

The GLib bindings could be a lot easier to use. The original
intent was to have no “IDL” xml file to mess with, but nobody has
implemented the C parser (could be based on gtk-doc) or GLib
introspection to avoid it. There’s AFAIK no roadmap for what should be
involved in getting these bindings to 1.0, and I’m sure the bindings
could be improved many small ways.

Bindings are essential. The low-level API is both easy to misuse and
kind of a pain in the ass.

Performance. I’ve noticed that people are profiling
GTK-on-Cairo well after its release, and so far D‑Bus is on the same
track, despite some
strong hints. Unlike the UI toolkit, I doubt D‑Bus speed is very
user-perceptible, though I do know D‑Bus isn’t especially peppy.
Nontheless, I’m sure someone is going to benchmark it vs. other IPC
systems and post shocking graphs, and to them I say, find the hotspots
and send patches already.

Windows port. There’s some work on the Windows port, and I’m
not sure of the status in detail, but I think it could be done in a
week or two of effort. Would like to see someone hammer this out for 1.2.

System activation.
David
Zeuthen’s work to enable the systemwide bus to start daemons will
likely land in a “1.2” sort of release, ideally within a few months.

Tutorial documentation.
The low-level libdbus has almost excruciatingly thorough API
documentation if I do say so myself, but nobody should really be using
that API anyway and API docs are bad for getting started. “Getting
started” documentation is needed for each high-level binding, with examples.

D‑Bus Viewer. KDE had a neat tool for DCOP that let you browse
all the running apps and introspect their methods. This is really
useful, and a D‑Bus equivalent is needed. There was a start on one in CVS at
one point, but it hadn’t gotten very far.

Integration into the GTK+/GNOME API. Lots of things in GNOME
can be cleaned up and made simpler with D‑Bus available. For example,
the bat**** insane lifecycle-management/activation code in
libgconf/gconfd‑2 can be nuked. (please save
us — it’s so simple
and things are so
broken.)

For applications that want to be single instance and can just rely on
D‑Bus, there’s no need to wait for a fancy “unique application”
library — just try to own your app’s D‑Bus name on startup, and exit
anytime you lose the name or fail to become its owner. Presto,
single-instance. (This is what bus names were designed for, btw.)

Alternative transports and X forwarding.
DBUS_SESSION_BUS_ADDRESS should be ssh-forwarded and tunneled, just
like DISPLAY. Until this is done, remote applications won’t really
work right. And the sooner this is done, the sooner a new-enough
version of ssh will get rolled out to distributions.

A somewhat hackier approach would be to implement a libdbus
transport
that worked over an X connection, probably using X properties to
transfer messages.

Please, report API bugs. Especially in the bindings, but it’s
still possible to evolve libdbus via deprecation or extension as
well. Several bad bugs were almost in libdbus 1.0 because people just
assumed they were by design (diabolical design?) and worked around them
instead of saying something or patching the library.

A final fun fact about libdbus 1.0:

$ nm -D dbus/.libs/libdbus-1.so | grep ' T ' | wc -l
200

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

Since John is about ready to release D‑Bus 1.0 I thought I’d finally
fix up all the warnings from Doxygen. The API reference docs were
mostly complete already, but I found a surprising number of
inaccuracies (some things were wildly wrong or misleading, since the
library has evolved so much since they were written). I also added a
lot of recommendations, extra detail, and reworded stuff for
consistency and clarity. Hopefully future API users will be much
better off.

Check
out the results, and please send improvements.

I noticed that Doxygen is generating man pages for the whole
D‑Bus API, though nobody is installing them in packages right
now. Sometimes “man dbus_connection_open” can be nicer than searching
the web.

Jeroen Vermeulen wrote a nice intro to
D‑Bus worth checking out also.

My sincere hope is that libdbus is basically done, and that most
feature requests will be rejected after 1.0. The higher-level
bindings, on the other hand, can still use a lot of work. The tutorial
(as opposed to reference) docs and the spec need help. And the test
suite can always be stronger, it’s suffered since gcov kept changing
its format and my “make coverage-report” feature bit-rotted.

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

Andrew
Cowie blogs about dynamically building Java-GNOME by messing with
bytecode. These bytecode-munging libraries are
fascinating in a “wow, that’s pretty cool” way.
(valgrind does the same thing, but with machine code instead of
bytecode — valgrind is also fun to play with.)

When I looked at some of these
libs, I thought ASM
looked good — small, fast, and easy to use. It has a feature where
you can write your Java class, then convert it to an ASM code
generator, then modify that generator. (Or write your “before” and
“after” Java class, convert both to ASM, and compare.)

I’m not sure there’s a lot java-gnome could do with bytecode that it
couldn’t do with full GLib introspection and proxies,
though.

btw, someone please hack on full
introspection
for GLib… that would nicely shrink a lot of language and IPC bindings.

My wishlist for GLib introspection is that a single, simple, smart
command generate the typelib, the glib-mkenums stuff, and the
glib-genmarshal stuff. glib-mkenums and glib-genmarshal require you to
write all kinds of gunge in your Makefile that would be more nicely
done in a real programming language instead of inline shell
cut-and-pasted into every Makefile. And I wouldn’t look forward to
adding a third block of Makefile gunge to get the typelib. How about
just generating a public/installed header file, a private header file,
and a .c file from a single smart command and single input file — that
would be sweet.

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

People keep acting like it’s nuts to use Subversion instead of git (or
one of the other long list of distributed alternatives), and I feel
like I’m just missing something or getting too old to understand the
kids today.

I found an old series of blog posts about how the different models
support different community dynamics,
Greg Hudson,
Ian Bicking,

Bryan O’Sullivan.

I think what I don’t get yet is why you’d want to maintain a
bunch of local changesets for very long. The Linux-kernel-style
fork-fest seems just nuts for anything I’m working on. Usually there
are less than 10 people, often less than 5, that are really doing much
work, and any other contributors are sending a one-liner every few
months. There’s just no problem that I see here that
distributed version control would solve.

Maybe it’s a personal style issue. On all my projects I almost
compulsively commit to the central repo every day — too afraid of
losing work when a hard drive goes south or something. I know other
people who delay committing for months at a time which I would find
nerve-wracking. I also press save every 3 minutes whenever I’m editing
a document.

The obvious reply is that most people don’t have commit access. But if
someone’s doing any kind of significant work, I think they should. And
for my projects I’ve essentially always given out access as soon as
someone did any kind of largish patch or frequency of patches. Again,
a typical number of people doing work would be 3, 5, maybe 10 — 10
is a pretty large project by most open source project
standards.

Aside from community dynamic / “what is the point of
decentralization” two other things bug me:

• There are so many choices (cvs, svn, git, mercurial, darcs, bazaar,
  arch, monotone, etc.). It used to be that if you understood CVS you could quickly
  work on any project. These days, if you want to work on a project you
  might have a few days of ramping up on the quirks of their SCM before
  you can do anything. And they are all quirky. And I just don’t care
  about SCM that much and don’t want to think about learning new ones.
• The distributed systems seem pretty wild from a user experience
  standpoint. In the sense of “jeez, I can tell a (kernel, Haskell,
  shell) programmer wrote this.” Subversion may be less flexible but
  it’s also less confusing. Call me stupid.

Also, I used to walk to school both ways uphill in the snow, fyi.

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

For the version of Mugshot we’re going to release shortly, we redid the UI (it looks something like this [link went away over the years, sorry…]). Amazingly, there’s no good cross-platform way to implement a custom UI along these lines. The old version of Mugshot uses an embedded IE control on Windows and a custom GTK+ widget on Linux.

The solution we’re trying is a quickly-hacked-up custom canvas. (See gtk-devel post, current subversion location.)

It turns out that One Laptop Per Child has similar requirements, see for example these mockups (there are also newer mockups but I can’t find a link to them). We broke HippoCanvas out of the Mugshot sources so the Sugar project could try using it and see if it works for them also.

A couple years ago, throwing a canvas together in a few days like this would have been way too much work; the reason it’s plausible today is that Cairo and Pango handle so many of the hard parts.

HippoCanvas has some nice improvements over GtkWidget. The best one: modernizing the layout system. It’s not too often one notices GTK’s breakage here, but sometimes it’s very visible. The two big changes in HippoCanvas layout are to add height-for-width and to distinguish between “minimum size” and “natural size.” (GTK’s “size request” defines a minimum size for a widget).

The natural size feature makes ellipsized text work properly, something that’s essentially impossible in GTK+ (without writing a custom canvas widget anyway). Here’s a real-world example problem we had before implementing natural size — implementing this with three GtkLabel widgets would have this same bug:

In the first shot, one of the text items is ellipsized while the other
gets extra space. In the second, both get extra space even though in a
real app you’d probably want all the extra space to be on the right
side of the window (left-aligning the text).

The problem is that GTK+ only supports a minimum size. To allow text
to ellipsize, you have to set the minimum size to zero (or something
small). However, this means you have to pack the text item in a box
such that it expands when there’s extra space… and that means GTK+
will add bogus whitespace as in the above screenshots. If you don’t
pack the item such that it expands, it will just always be the minimum
size (i.e. zero).

HippoCanvas allows items to have a minimum size and a natural size.
The algorithm is that if the layout box gets more than the minimum
size, first it brings all items up to their natural size (whether they
are “expandable” or not), and then it distributes whitespace among
expandable items.

So for example, here’s a test layout at its natural size:

And its minimum size:

And two points in between:

The algorithm brings smaller items up to natural size first, so the
yellow item on the right is fully visible while the two longer items
are still ellipsized. If you think about an example like the “Blah
blah blah blah — Havoc” images earlier, the idea is to display all of
“Havoc” first, and then as much of “Blah blah blah blah” as possible.

Expandable items only matter once everything has its natural size,
like this:

One way to understand the problem with GTK is that it doesn’t support
the “expand=0 ellipsize=1” behavior illustrated in these screenshots.

A downside of a more-complex layout system like this is that layout
containers are tougher to implement. However, this is the wrong thing
to optimize for, because virtually nobody implements layout
containers. GTK+ doesn’t have very many but still has too many of
them; we consolidated GtkFixed, GtkHBox, GtkVBox, and
GtkAlignment/GtkMisc into a single box
item, and made all canvas items have xalign/yalign
properties. This already covers 98% of layout needs.

In the end, this kind of corner case probably doesn’t matter very
much; after all, HTML, Flash, Windows, GTK+, etc. are all very
successful despite missing/flawed solutions for layout. But it’s
nice to get things right in this new code.

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