Havoc's Blog

Slashdot
comments are even dumber than usual when discussing coordinated
security updates. I guess I’d expect that if they know nothing else,
at least many Slashdot posters work in IT and understand security
patches!

For those who don’t know: in most cases, a not-yet-public security
flaw has a public announcement date coordinated among all the major
Linux distributions, BSDs, and the upstream project in
question. That’s because most users can’t use tarballs or
project-built binaries, they need packages from their vendor. By
coordinating the announcement date, everyone can patch their systems
at the same moment that the script kiddies can start to use the
exploit. For an already-public flaw, of course, there’s no value in a
coordinated release date and everyone scrambles to ship the fix
ASAP.

The lag between announce and patch can be large if the announce date
isn’t coordinated, because so many versions of so many operating
systems need to be patched. Often the patch has to be backported to
multiple versions of a package, which can be complicated. Then the fix
has to be built (for something like Mozilla or OpenOffice.org, this is
not fast), tested, documented, and pushed out for download.

If you’re an open source project maintainer, you need to understand
what to do when you learn of a security flaw. The simplest thing is to
quietly notify any of the major Linux or BSD distributions and let
them take it from there. For example here is how to
report to Red Hat, here
is how to report to Debian, here is FreeBSD.

Once you notify someone, wait to hear back. The upstream maintainer
would normally announce the vulnerability and commit patches to CVS at
the same coordinated time that vendors post packages. If you patch in
CVS before anyone is ready with packages, your users are vulnerable
during the gap (and generally unhappy about it). Worse, by committing
a patch to CVS you’re doing something that a black hat could notice,
but most sysadmins will not notice.

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

Alex
Graveley links to subtext, I
think this thing looks awesome. A perfect place to experiment with it
would be something like GNOME panel applets, Apple Dashboard, or Second Life objects. All these are
limited programming domains where making programming easy would be
high-value. I guess any sort of plugin/extension system might be a
good place to experiment, but graphical ones seem more exciting.
Seth points out that it’s similar or at least complementary to
some Smalltalk ideas.

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

Better judgment > /dev/null

Sorry to see this come up again, but I guess it will be a hot topic
at GUADEC, so I may as well lay out the current status as I see it.
(Summary: not much has changed…)

It won’t show on Planet GNOME, so here is Mark
Wielaard following up on Christian’s
post. Also earlier he posted a
chart of Classpath development progress. More people should read
Planet Classpath as I’ve
hinted a couple times in the past.

Responding to Christian, he says “Java’s mindshare in the wider GNOME
community is close to non-existant today and there aren’t really
anything on the horizon that could plausibly alter that.” This is
potentially true. I said as much in my talk at the open source Java
summit, where I was trying to clue in Sun (among other goals). At the
same time, I think GNOME has it wrong (or at least is leaving those of
us at Red Hat unable to contribute to GNOME), so I find the situation
depressing.

Let’s talk about technology first.

Graydon’s
analysis pretty much shows what a non-technical-issue this Java
vs. C# thing is. And as Jeffrey
Morgan says it would be nice to preserve choice for app
developers.

The velocity of open source Java development, and sheer quantity of
open source libraries and tools for Java seem to be discounted.

Just one thing I’ve been very impressed with is the Eclipse
plugin system: this is in no way tied to Eclipse or SWT, and it is
just a better way to think about extensibility than our historical
fixation on “component systems.” There’s a very similar open standard called OSGi that I think is
pretty neat, with at least two open source implementations (Oscar and Knopflerfish). I should do a
separate blog post on why these are interesting sometime.

Screw its plugin system: when I used Eclipse itself to write Java for
a few days, I was impressed with the increase in productivity. Most of
the wins were because of the IDE, not because of the
language. Like Emacs, Eclipse has awful usability engineering, but it
has great features and functionality that save time once you discover
them. If you’ve never used a serious IDE with a language like Java or
C#, you should try it. The most important language features are the
ones that enable a great IDE.

Another place to look at the size of the open source Java community
is JPackage; the package list is
down the side. And those are just the packages someone cared enough
about to maintain in RPM format.

Or let’s look at Apache’s Java
community, where Lucene was
born — and then ported to C# to become the Beagle engine.

Obviously C# has lots of software out there as well, and it has more
GTK+ software due to the focused effort to create same. I’m not trying
to exhaustively belabor the Java vs. C# technical comparison but I am
trying to point out that Java has a hell of a lot going for it
including open source developer tools and libraries and huge momentum
(largely open source) on the server side. Java 5 has some cute
language features, too, and Tromey has
shown how to make native code bindings easy.

Enough on technology. On the crux of the issue, what I wish GNOME
would understand: Red Hat not shipping Mono is currently a
can’t rather than a won’t. Making it worse, we are not
able to spell out all the facts on why we can’t. In fact, none of the
Red Hat engineers (including myself) knows all the facts (and
we couldn’t share them in public if we did). We continue to try to
get this issue resolved and there are serious efforts in progress,
but, well, they have been in progress for quite a while. At some
points it felt close to resolution, at the moment it doesn’t really,
at least not to me.

Please don’t ask for more details here. I can’t give them. You can
take this as evidence that I’m lying, and that’s fine, but I can’t do
anything about it.

I believe we have legitimate and non-evil reasons why we can’t
ship Mono. And I think open source Java looks plausible and a lot
nicer than C; Java and Classpath will even run on Mono, and if C#
becomes more viable later, experiments such as Graydon’s or the Lucene
port show that it isn’t hard to do a Java to C# conversion. And guess
what, we need open source Java in the desktop anyhow for
OpenOffice.org and the browser plugin at minimum.

I don’t know what people expect Red Hat GNOME developers to do. We
can’t roll over and say “OK, we’ll start hacking in C#, even though we
don’t see a path to shipping any of the stuff we’re hacking on” — does
anyone seriously expect that?

If people don’t believe us, then the right action is for GNOME to just
require Mono and let Red Hat sort it out. Let’s not blame a faceless
company here for the sorting out. At the moment Red Hat’s desktop
strategy is largely set by me and other community members you know. I
can tell you what I would advocate faced with Mono as a GNOME
requirement: initially try to reimplement or live without the Mono
bits, maybe using language-translation hacks to port stuff to Java;
while finding a non-GNOME or forked-GNOME path to get out of this
losing approach in the long term. It’s ugly but true. We would
probably stall as long as possible, hoping to find a way to ship Mono
or that GNOME would change its mind, but that’s all we could do. I
can’t think of a way we could justify hacking on software we can’t
ship.

If anyone has a better suggestion then let me know what it is.

Here’s what I ask. Give the Java and Eclipse talks at GUADEC a
chance. Try out some of the Java technologies I mentioned earlier in
this post. Try Java 5. See if this is really such a clear-cut
technical issue.

Eventually though GNOME should just decide what to do and proceed. If
people think we are lying, or that something will happen to let us
ship Mono, or simply think that Mono is more valuable than Red Hat’s
contributions, then so be it. These are decisions that have to be
made. GNOME got stuck on the “Bonobo war” for a while, and the “Mono
war” today, both at their heart ridiculous distractions from the real
point, which is implementing a desktop environment.

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

Mikael,
I would have said exactly the opposite. You can build all the platform
you want and nobody is going to care. What they care about is
apps. Good apps will drag along the worst platform imaginable. In
fact, the major apps mostly have lame custom cross-platform toolkits
as their platform, and nobody cares. GTK+ blows many of these toolkits
out of the water but it does not matter.

My suggestion for giving GNOME a jolt would be to win with the
apps. Make Evolution really fantastic, instead of
limping-along-in-danger-of-being-Thunderbirded. Support great apps
like Epiphany and Evince. Get GNOME Office in the game so it has a
chance in hell. Invent great new kinds of app. Use a distinctive
aspect of the GNOME platform (it’s willing to diverge from Windows) to
do interesting things in the apps and shared among
apps. Undiplomatically: the last thing I’d do is start the
my-platform-is-so-cool technowanking. It’s all about what you can do
for end users.

GNOME is a perfectly good desktop environment and I think is going
along fine as such. But desktop environments aren’t that
exciting. Apps are exciting. Heck, read the metacity README. It’s
all about the virtues of boring.

Note, by “apps” I really mean “useful end-user functionality” and the
desktop environment could include that functionality (effectively
becoming a single integrated app). But our current structure tends to
put everything useful in standalone apps.

I’m not crying “the sky is falling” here since I think good apps exist
for Linux, they just aren’t being built within GNOME. What I’m saying
is that if we want GNOME to be where the excitement is, then
it’s about apps.

If you don’t build the apps you can’t really change anything
interesting about the platform. You can only write a platform that can
be a backend for XUL, VCL, SWT, WINE, etc. since the apps use those
APIs.

The value of centering the excitement around GNOME would be to create
a more integrated, exciting, innovative/nimble app suite. The downside
of course is that it’s so much more work than just using the
cross-platform apps.

I have many more thoughts here, I guess, but it gets hard for me to
talk without getting Slashdotted and causing
confusion/misunderstanding among the vast majority of readers who lack
context. I’m reluctant to post even this much… I’m sure I already
have some choice quotable that everyone will misunderstand.

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

Which is worse: Disgraced
Navy SEAL Shane Wolf (Vin Diesel) is handed a new assignment: Protect
the five Plummer kids from enemies of their recently deceased
father or Tommy Lee
Jones stars as a Texas Ranger who must protect a group of 5
cheerleaders who have witnessed a murder? I think The
Pacifier is victorious on the grounds of worst title.

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

I think some people were confused about what I meant by “structural”
changes. I’m talking about things on the scale of whether apps involve
windows, dialogs, and menus (and thus whether there’s a window
manager, and which widgets are found in the GUI toolkit). Another
example might be removing files from the user model (including the
file manager and having open/save in applications). These are just
examples, they aren’t intended to be good ideas. Some of the stuff here
I would count as GNOME 3 material, but a lot of it is feasible in
GNOME 2 (and some of it isn’t even that interesting, it’s just code
cleanup).

Which structural changes are potentially interesting enough to justify
GNOME 3? I don’t know. Maybe there aren’t any. This is something
people would have to experiment
with (google
cache, the site was down when I wrote this).

My point is as much to discourage a flawed GNOME 3 as it is to
encourage an interesting one. I think some people are wanting total
freedom from backward compatibility, dogfooding, ABI stability,
freezes, etc. without adequate cause for said freedom. About anything
you can imagine as a tweak or evolution of the current desktop is
going to be feasible in GNOME 2.x. GNOME 3 should have strong cause in
real user-centered innovation, it should not be “we haven’t broken ABI
in a while, let’s go for it! woohoo!” because that approach is driven
by technical wanking, not by the goal of making a better desktop.

Unless someone starts some experiments and scopes out some interesting
new directions, I think we’ll be in the 2.x series forever.

BTW, if we did do a GNOME 3 in the sense that I’ve described it, I bet
the 2.x branch would continue indefinitely alongside; 2.x would be
much more suitable for technical workstation kinds of applications,
for example.

Keep in mind, there are some pretty interesting things to do on 2.x,
especially if you think about writing apps rather than modifying the
core platform.

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

Ah geez, again I foolishly fail to remember that phrasing things a
certain way results in Slashdot
articles which inevitably have misleading headlines and summaries.
For the record, my point is not that we should do a GNOME 3
(especially right now), and it definitely isn’t that I
personally intend to do a GNOME 3. It’s that if someone did
a GNOME 3, the right way to do it is to create a fairly long-lived
branch (aka fork) of the project while continuing the GNOME 2.x series
on a 6‑month cycle in the meantime. I’m responding to other people’s
blogs here, rather than proposing something.

And for the record I don’t think conservatism in GNOME 2 is bad, it’s
just different. The important point is to recognize that you can’t do
two things in one branch. Doing it all in one place results in both
breaking the crap out of current users, and failing to innovate
or do interesting things. So you split them apart. This is also
lower-risk; if the innovation fails, then you just drop the branch.

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

Adding to my previous post a bit, regarding the
6‑month cycle: I don’t think going 6 to 9 months is at all useful
for enabling GNOME 3. GNOME 3 is a bigger effort than that. We should
pick the release cycle to benefit GNOME 2, not GNOME 3. And I think
GNOME 2 is running pretty smoothly (well, there are some issues but I
would not blame the release dates). Larger changes can be done in 12
months rather than 6 by just skipping a cycle for a particular
component. We’ve done this in a number of cases. 9 months is long
enough to start causing the problems we were trying to avoid when we
created the time-based release approach. Even if we don’t think enough
cool stuff happens in 6 months, I’d argue that changing to 7 is better
than changing to 9.

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

My take on the GNOME
3 discussion is that we have multiple goals at the moment which
are truly in conflict. On the one hand, we have the fairly traditional
desktop of today, with some growing userbase, and it’s important not
to break it. Most of the employed-to-work-on-GNOME developers are
focused on this. On the other hand, innovation is necessary to move
forward, and there’s a lot we could do. But we don’t want to drag
today’s users through broken intermediate states and make them wait 3
years for bugfixes to come out.

Look at how much screaming we get for relatively tiny changes
to today’s desktop such as the file selector, focus stealing
prevention, or whatever. Even with these small things, until the
details are ironed out (adding typeahead to the file selector, adding
flashing taskbar buttons to the focus stealing prevention) it’s pretty
disruptive.

There’s also a reality that the GNOME 2 desktop, as shipped by most
everyone, is the GNOME environment plus Firefox plus OpenOffice.org
plus Evolution or Thunderbird; which means that to take a particular
UI direction or add a platform feature, you have to convince all of
those projects to change… and they are incented to keep the platform
as similar to Windows in basic structure as possible. The value of
platform features is to create commonality between apps, so if apps
don’t use the platform, platform features are useless.

So the forces of existing userbase, the easiest-to-reach future
userbase, cross-platform applications, and funded development efforts
are strongly pulling GNOME 2 toward conservatism.

I think GNOME 3 should be a fork for that reason. There’s another
reason it should be a fork; I’ve been using a petrified wood
analogy. The process for forming petrified wood is that an organic
structure is replaced by minerals. The result is a rock, with the same
shape and structure as a piece of wood.

If you think about the transition from GNOME 1 to GNOME 2, as with
petrification we took the structure of GNOME 1 (session manager plus
window manager plus file manager plus control center plus panel) and
recoded it to be a different material, but the same shape. GNOME 2 is
in an important sense “the same thing” as GNOME 1, though it’s
certainly much more robust and polished.

This structural similarity is fractal in nature, so on the
whole-network level we have the structure of thick clients plus
mail/calendar server plus directory server for example, and or inside
the toolkit we have the basic premises shared by GTK+, Qt, and Swing.

Some people seem to think of GNOME 3 as “when we get to break ABI” — I
consider this a dumb goal, and I’m not sure breaking ABI even gets you
anywhere. GNOME 3 may be more about creating different ABIs. My
view is that GNOME 3 is interesting vs. GNOME 2 if and only if we are
changing the structure, i.e. what the desktop really consists
of and how it works on a macro level; GNOME 3 can’t possibly be worth
it if we’re just substituting minerals for lignin and cellulose but
getting the same structure in the end. It’s worth it if we’re building
a different kind of tree.

Something that makes GNOME 3 harder: you can’t change this macro level
in interesting ways without breaking all the apps. (I state this with
confidence because apps are the only interesting purpose of a desktop,
ergo failing to change the apps means you’ve failed to change anything
interesting.) Which doesn’t mean you can’t run the old apps, but it
means that today’s apps would be sort of freakishly out-of-place on a
GNOME 3 desktop that had changed shape. In other words old apps would
run in a “compatibility mode” and would be visibly distinct from new
apps.

I don’t know if we should do GNOME 3 today, or who should do it; but I
would caution that the purpose should be real value. Structural change
rather than rewriting purely to get new construction materials. And I
think this makes a temporary (but probably multi-year) fork almost
mandatory. Trying to do GNOME 3 “in place” will destabilize GNOME 2
while preventing the structural changes that would have value.

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

Aaron,
there is no standards committee or standards body at
freedesktop.org. freedesktop.org right now is the equivalent of
Sourceforge, essentially, except that projects have to be desktop-related.

I fully agree with outreach and that is what the successful projects
have done. e.g. for fontconfig, Keith Packard went and talked to GTK+,
Qt, Mozilla and even provided patches to all three of those
IIRC. Writing the patches taught him what would be workable.

If the D‑Conf developers don’t do outreach then they are taking
the risk that their project won’t be adopted. There’s no risk to us
(us being GNOME and KDE). Waldo and I are going out of our way a bit
to give them feedback whether they ask or not, but they still have to
get things approved by GNOME and KDE as a whole, and if their
ambitions are beyond GNOME and KDE, they have to get Mozilla and
OO.org and Samba and whoever else they care about as well.

Precisely because freedesktop.org is not a standards committee,
though, there’s no freedesktop.org policy to outreach or not
outreach. And nobody to say which config system to use. If someone else
has E‑Conf and F‑Conf and Q‑Conf then they can all post to the
list, and they can all have some CVS space (once they have some actual
code and look plausible), and they can fight it out until one of them
successfully gets adopted by the major projects. Or maybe the major
projects will choose something not hosted on freedesktop.org at
all, or stick with their current stuff, and that’s fine too.

You may ask “what’s this about a freedesktop.org platform”;
here
is my original suggestion on that and I
think this is my latest comment. Let me quote from that last one:

The “stack” concept is useful but NOT for technology pimping.
A goal of the stack should be to show which technology is *well-cooked*
— and part of the definition of “well-cooked” is “widely de facto shown
to be useful.” So it doesn’t make sense to use the stack to “push” or
promote technologies, since “already accepted” should be a gating
principle.

While some people may have other ideas, I will again reiterate that
KDE and GNOME can veto anything by simply not going along with
it. That’s the core reason I don’t understand any paranoia here.

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