follow me on Twitter

    Blog has moved to, see June, 2004 on new site

    Blog entries for June, 2004

    This post moved to

    On Donald Norman's recommendation I'm trying the Harmony remote. Pretty nice. However, I've now seen the phrase "Rebooting your remote..." and that scares me a bit.

    Hint, if you get one of these the Harmony web site has some refurbished ones at a discount.

    This post moved to

    Bought a used copy of an insanely hard video game. Each screen amounts to a puzzle in the Rubik's Cube sense, and once you figure it out you need mad arcade reflexes to implement the solution.

    This post moved to

    Eugenia was recently reminding me about the "dependency hell" problem when trying to install random Linux software found on the Internet.

    Joel's latest article points out once again that the cause of dependency hell is dependencies. Mike Hearn points this out too (though I'm still not convinced a new package format helps).

    Here's how you get rid of dependencies: you have one or a small number of big monolithic chunks - the LSB defines a core one - and apps can depend on that, and nothing else. Everything else has to be shipped with the app itself, or be optional and detected at runtime. An app can require "Linux," not a huge list of files and libraries.

    An implication: packaging of distribution components (things that go with the distribution itself) and packaging of third-party apps is fundamentally different.

    A corollary is that it's kind of nice to have as much as possible in the distribution itself, or packaged specifically with one distribution release in mind.

    I don't think people are facing up to the fact that there's an unavoidable tradeoff here. Extra copies of the same code means bloat, difficulty of doing security and bugfix updates, lack of consistency, and so forth. Dependencies mean dependency hell. For each package, pick which one you want; there's no magic technical solution.

    Some open source projects design themselves to be part of distributions and some design themselves as third-party ISV products. GNOME for example is clearly designed to be part of the OS, not installed by random end users, and I consider this correct for a desktop platform. Discussions of how to move forward in GNOME 2.8 show this trend continuing - to make the desktop work right we have to get increasingly entangled in distribution details such as HAL and CUPS and so forth. The big previously-proprietary apps such as and Mozilla have a very different attitude and tend to assume end users will install the app themselves. Which is both true and untrue on Linux; some will try the app themselves, and some will get it with their distribution.

    If you buy what Joel is saying, then adding new stuff to the big monolithic core (call it LSB, or just "Linux") and getting third parties to use it takes ages. This rings true for me. Very few ISVs use libraries beyond the C library and the occasional GTK+ or Qt. I'm pretty sure most Red Hat customers are still using Red Hat Enterprise Linux 2.1 - which was released over two years ago, with GNOME 1.x, based on Red Hat Linux 7.x-era technology. (This may have changed since we've been selling a lot of subscriptions lately.)

    Things are tough for third-party apps; they have a lot of dynamic adaptation to the current environment, and tend to dlopen() things rather than include a hard dependency. This can mean implementing the same functionality multiple times over for different Linux versions.

    Apps that are part of the OS on the other hand can use new OS features and have dependencies left and right, as soon as those dependencies are available. These apps have a real technical advantage, but have the disadvantage that people only get new versions when they upgrade the OS.

    You might expect from this that OS components advance more quickly but become widespread more slowly than third-party apps. I wonder if that's empirically true.

    This post moved to

    Jono Bacon advances one theory on why people might switch to Linux.

    This post moved to

    Reminder to sign up for the first annual Desktop Developer's Conference, July 19-20 before OLS. A fair number of developers will be there. We hope to have attendance from Mozilla,, GNOME, KDE,,, and every other desktop-related project you can think of. Distributions trying to address desktop user needs are definitely included. Bystanders with an interest in the open source desktop are welcome as well.

    From the Red Hat desktop team we'll have myself, Owen Taylor, Chris Aillon, Chris Blizzard, Mike Harris, Kevin Martin, and Daniel Veillard. Wanted to have even more but GUADEC ate our budget. ;-)

    This post moved to

    Colin posted about the printing hacking he and Matthias have been doing. These guys are badasses.

    This post moved to

    If you compare Linux to Windows, what are the similarities and differences? I mean this broadly, for example:

    • User interface
    • System architecture
    • Pricing and business model
    • Licensing
    • Range of software components ("enterprise stack")
    • Branding and perception

    I'll use "Windows" to mean the whole universe of our primary competition: Windows, Active Directory, Exchange, .NET, and Microsoft itself.

    This comparison matters because we need to give people a reason to switch to Linux. If someone asks how Linux is different, we should have some good answers. If someone asks how Linux is the same, we should have some good answers also.

    Different means risk: the potential to be better (or worse). Different may also create interoperability, training, and marketing issues. Similar means safety: you ask people to decide between Linux and Windows on other grounds.

    Each project and company in the Linux world has its own answers, implicit or explicit.

    In the area of user interface for example, GNOME attempts to be different. It does try to stay familiar in many ways (and tends to be configurable in a more-like-Windows direction, something many vendors take advantage of). But I think it's clear the project has "do the right thing on its own terms" as a goal, and feels there's genuine value to having the capability to understand what the right thing is and get it implemented, something one only learns through experience.

    Companies such as Lindows, on the other hand, have Windows interface cloning as a core premise (note the name "Lindows"). Add technologies such as WINE and the basic retail-box-with-proprietary-license business model, and the cloning goes well beyond interface.

    Since I work at Red Hat, I can tell you the "why is Linux different from Windows on the desktop?" answer we've articulated so far:

    Which isn't to say we won't have more to say later. But this is what we've said so far.

    There are a lot of possible answers, some of them include:

    Price: "Linux is just like Windows, but has lower licensing costs."

    Not Microsoft: "Linux is just like Windows, but isn't sold by Microsoft." If Linux is essentially the same as Windows, but offered by another vendor, customers have more leverage.

    Revolutionary Technology: "Linux has exciting innovations not found in Windows."

    Open Standards: "Open source projects better adhere to open standards."

    Most likely this list is as long as the list of open source desktop projects and companies. My talk at went through some more ideas.

    I obviously have some opinions about the right answer to these questions. I don't think we need to be better than Windows in all respects. We need to be better than Windows in the respects that matter.

    One interesting thing about Linux is that it supports multiple projects and companies pursuing multiple approaches, and thus as a whole community we can try a lot of different answers to this question and see which one sticks. While at the same time, individual groups can tightly focus on a single approach and give it a wholehearted effort.

    A reason this is useful: the comparison between Linux and Windows probably has to change over time. For example, while many advocate cloning Windows today (on the level of architecture, protocols, interface, and more), this argument is generally based on migration path - and thus if we're successful, the rationale for cloning may go away. (Unless of course you subscribe to "not Microsoft" or "having two vendor alternatives" as the fundamental differentiation from Microsoft - in which case keeping Windows and Linux fully substitutable may make sense indefinitely.)

    Plainly a very complex issue, and I doubt anyone will be 100% successful in predicting whether, how, and why Linux will succeed in gaining desktop marketshare from Windows. But perhaps we could benefit from thinking about it more explicitly from time to time.

    This post moved to

    And I forgot Chris Lee who started in the QA group and is already breaking everything. ;-)

    This post moved to

    I forgot to mention on Wednesday, Bryan Clark and Ray Strode have arrived in the office. Fortunately, they don't seem to have run away yet.

    This post moved to

    Someone wrote another TweakUI type thing instead of whining about gconf-editor. Let's see how hard this was:

    [hp@localhost src]$ grep ';' *.[hc] | wc -l
    Shorter than your average flame mail. Kudos to the author of gTweakUI for doing the work. Also check out Configurator for GNOME.

    While googling for historical discussions of TweakUI I found this nostalgia, I haven't bothered to get involved in this argument for a while.

    On a related note, Seth's proposed list of user preferences, an attempt to top-down design user prefs (there's been a lot of organic change since the last conscious redesign). This tries to factor in things that traditionally require root, something we haven't done in the past. The next step is to map out how the list of prefs maps to user interface elements (some may be in Nautilus for example, some in control center, or whatever).

    This post moved to

    Gotta love waking up to find some clueless pundit trashing you personally. I was reading that article thinking "well, the guy is kind of naive on what the issues and solutions are but sure I agree with the goal" but ended up kind of bitter when I got to the end. ;-) Especially the part where he blames me for gnome-terminal code I didn't even write.

    A hint on Metacity performance:

    [hp@localhost hp]$ metacity-theme-viewer Bluecurve
    Loaded theme "Bluecurve" in 0.03 seconds
    Drew 100 frames in 0.55 client-side seconds (5.5 milliseconds per frame) and 1.78428 seconds wall clock time including X server resources (17.8428 milliseconds per frame)
    [hp@localhost hp]$ metacity-theme-viewer Simple
    Loaded theme "Simple" in 0.01 seconds
    Drew 100 frames in 0.15 client-side seconds (1.5 milliseconds per
    frame) and 0.831834 seconds wall clock time including X server
    resources (8.31834 milliseconds per frame)
    [hp@localhost hp]$ metacity-theme-viewer Atlanta
    Loaded theme "Atlanta" in 0.01 seconds
    Drew 100 frames in 0.1 client-side seconds (1 milliseconds per frame) and 0.338352 seconds wall clock time including X server resources (3.38352 milliseconds per frame)

    I added this profiling feature to metacity-theme-viewer long ago, specifically so theme authors could get an idea how bad/good their theme was on this dimension.

    Ironically, just yesterday I was posting about some performance issues. Volunteers wanted. I'm sure we'll get a patch from this OS News guy who knows exactly where the bottlenecks are and how to provide equivalent features in 1/10 the memory, due to his extensive profiling of GNOME, detailed architecture review, and overall coding skills.

    This post moved to

    Been offline for a couple days, which is always nice. On Friday night drove a couple hours into New Hampshire to see a Dylan concert - pretty good, some new material and he did a few new arrangements on the old standards since I saw him last. Meadowbrook is a nice venue, very good sound for an outdoor amphitheater.

    Saturday morning on a TV cooking show someone made the following recipe:

    • Chop up two dozen Krispy Kreme donuts
    • Pour over them one can sweetened condensed milk and one can fruit cocktail
    • Stir and bake
    • Make a sauce of one stick of butter, gobs of powdered sugar, and rum; pour over the top

    My previous example of "most absurdly unhealthy dish ever seen on a cooking show" was a sort of bacon-wrapped-in-bacon-with-bacon-on-top nonsense from "Two Fat Ladies." This Krispy Kreme pudding thing is pretty competitive though. I guess if you use fruit cocktail in light syrup instead of regular fruit cocktail it might be OK.

    Saturday afternoon visited the Shaker village near Concord, and had some nice dry barbecue ribs with watermelon and all that. Saw Harry Potter in the afternoon, and tried a Mexican restaurant in Concord. Relative to New England (this is a huge caveat), the restaurant was a pretty good Mexican restaurant. At least they had heard of cilantro and jalapenos. And the new Harry Potter movie was far better than the first two.

    Had brunch this morning at Common Man restaurant which is sort of a high-end Cracker Barrel (a mix of Irregardless in Raleigh and Cracker Barrel, for those who know Raleigh). Pretty decent place.

    Excited about the new PJ Harvey album on Tuesday, and have been enjoying the new Magnetic Fields over the last week.

    Anyway, a kind of mini-vacation. Back to the grindstone. ;-)