follow me on Twitter

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

    Blog entries for November, 2004

    This post moved to

    In case you had any doubts about how much David Zeuthen rocks, check this out, standing on the shoulders of Owen and Ziga Mahkovec. As I think Owen intended, this shows how important profiling before optimizing really is. Now we understand the issues and a 40-second boot (including GNOME login) is a simple matter of programming. I'm looking forward to FC4.

    In the boot chart, it looks like David has gnome-session launching at about 22 seconds, so I have my hopes up that we can run gdm at that point when using gdm instead of autologin, and have a username/password prompt in under 30 seconds.

    It does look like getting below the times David is posting will involve simply loading less junk off the disk. It'd be interesting to start analyzing what said junk includes and whether there's any low-hanging fruit.

    A useful lesson also demonstrated by my D-BUS hacking: a wall-clock sampling profiler is essential to figure out the high level areas to optimize. Something like callgrind can be useful once you're optimizing a specific CPU-bound function or loop, but callgrind is the wrong place to start.

    This post moved to

    Amusing myself with profilers the last few days, with moderate success. This was probably a waste of time; I don't think IPC is likely to be a bottleneck or performance issue for the desktop as a whole. (Despite the occasional Slashdot kid speculating that stuff is slow "because of CORBA" or "because of X" as if anything that opens a UNIX domain socket is automatically to blame for all performance issues...) But, it was a good way to procrastinate the more useful stuff I should be doing. And I found a few real bugs while I was fooling with the code.

    This post moved to

    I should have mentioned in my last post, Planet Classpath is well worth checking out; for example right now it has Tom on Monotone, IKVM status update, Swing on GTK+ screenshots.

    This post moved to

    Gotta reply to the questions I guess ;-) Or at least some of them.

    Why Red Hat is not making any Java-GNOME application?

    We've been reluctant to start competing with Novell to see who can write the most code in their favorite language, eventually leading to two different desktop codebases. Instead there are quiet efforts to find other solutions.

    Coincidentally, Graydon (who has implemented much of Swing on top of the GTK+-based AWT in Classpath) posted this analysis comparing Java-GNOME and GTK#. Basically he ports a GNOME applet from C# to Java and lines up the code side-by-side to demonstrate how similar it is. A nice bit of perspective.

    Why all of us are not using Eclipse instead of Emacs or vi for developing GNOME?

    Last I tried it (some time ago) the C/C++ support wasn't good enough. One of the Eclipse developers tells me that I should try again when 2.1 comes out and that it's much better. If I can do this (and also use a gcj-compiled 100% open source Eclipse) then I would definitely like to switch to Eclipse.

    OK, I'll let someone else answer the other questions ;-)

    This post moved to

    Nat's X-rays look extremely similar to mine. I don't even want to think about how badly that hurt at the time. Everyone be nice to Nat.

    This post moved to

    Ross, my favorite feature request for SJ is a better way to handle my CDs that come up "unknown" - it might be nice if SJ supported submitting the info to MusicBrainz? (Doesn't it use MusicBrainz? I don't even know.) Also, e.g. MusicBrainz lists two different Daydream Nation but my Daydream Nation comes up as unrecognized, so perhaps some sort of feature where you enter the title and artist and it pulls down the track names, and then sends a new CD signature to MusicBrainz.

    That said I really love the simple just-does-what-I-want-without-a-lot-of-nonsense aspect of Sound Juicer so feel free to ignore my features to preserve that. ;-)

    This post moved to

    I got a ton of suggestions for the home music system, it will take me a while to process, try some things, and post results. (Since I know everyone is in suspense to know how the very last hacker on earth to get around to a home music system will set it up.)

    This post moved to

    Luis, if you read Hyperion be sure you have the sequel handy, since the first book pretty much just ends in the middle of the story. The second book seems to have a good stopping point. I haven't read the other ones.

    This post moved to

    I've been reading version control system manuals lately for some reason, joining the Colin club. Also talked to Graydon a little bit about monotone since he's in town for the Java summit.

    Here's how I'd like to go about comparing these systems. (I didn't do it yet, I may be too lazy for now.) We should be able to look at how our software development process works and make a list of the tasks involved; and see how well the various source control systems support those tasks. I admit, this ignores the potential for an earth-shattering revolution in the software development process by presupposing what the high-level tasks are. But it sounds useful to see which of these systems most nicely supports our current process and social organization. Or perhaps we'll see that they are all essentially the same.

    Here are some example tasks:

    • Starting work on a new patch with a defined goal ("I want to fix bug #123456")
    • Submitting a patch to the mainline project ("Dear maintainer, here is my fix for #123456, please apply")
    • Reviewing pending patches for one's own mainline project
    • Accept/reject patches, with comments
    • Make a new development release
    • Make a new bugfixes-only stable release
    • Backport a fix from the development version to the stable version
    • Restore a recent (perhaps never-submitted-to-mainline) version of a file you're working on, since you just accidentally deleted it
    • See what changed recently that may have broken the build
    • Get the latest version of the software
    • Adapt a patch to work with a different version than the one you wrote it for (aka resolve conflicts)

    For each of these tasks, we should be able to completely describe the stuff you have to type and/or click on to perform them using each system. Right now many of them involve bugzilla, mailing lists, etc. in addition to a source control system. Which points to the potential usefulness of a comprehensive UI for programmer collaboration, designed for the open source process... someone write that. ;-)

    In addition to the steps to do each task, we might want to note any interesting properties of each task using each system. For example, whether the task can be done offline; whether it's slow or fast; security concerns; etc.

    Part of the reason I'm thinking along these lines is that in looking at monotone, I get the feeling I could do a lot of really neat things with it but that right now it's a little too "policy-free" and these neat things might require too much thinking on my part.

    A fun thing about monotone is that it's peer-to-peer based on public key crypto; you can make assertions about changes to the source tree, and you can collect other people's assertions. To define the "mainline" of a project you would say something like "use all changes to branch foo signed by person a, b, or c" - while with CVS you say something like "all changes to HEAD that are on the server" Given the recent hacking incident, I can see the merit of the monotone approach. There's no way to tamper with a source tree without stealing a private key and passphrase.

    Graydon said today that he's looking at including in the repository itself the list of "committers" at each point in the revision history. So say I start a project and work on it for a while; at first the project mainline is defined as all revisions I have signed with my key. At some point I could change the default committers for the branch to include Colin; and then anyone checking out the branch who doesn't specify otherwise would get stuff either one of us had signed. Patches Colin submitted before he became a committer, however, would not suddenly be added. And if I later kicked Colin out of the project, his post-kickout changes would not be used either.

    With monotone today, as I understand it you have to specify on your own local system all keys you trust to make changes, and then all changes signed by those people are in the source code you check out. For something like GNOME you can imagine the mess as our trusted-persons lists got out of sync, and we each had a somewhat different version of the code.

    I know Graydon could explain all this more accurately than I can.

    Here are a couple more feature ideas I have.

    • The version control system keeps track of how to submit patches (mailing list, bugzilla, etc.) and has a "submit patch" command. (Prereq: the system has a concept of a patch you're working on for submission)
    • The version control system tracks submitted patches for the maintainer and supports easy review and acceptance/rejection of them.
    • Easy way to have a conversation about any patch (as we do now in bugzilla typically)
    • Allow the maintainer to easily hack on the patch, merge their changes with it, and then bounce the patch back to the submitter for more work - I often want to just fix the nitpicks instead of writing them down, then give someone the patch back to fix the big stuff.
    • Often you want to commit a number of times before you submit a patch officially (sometimes people will make a CVS branch for this). A nice feature would be to avoid the need to do this manually; just have the developer tools automatically "commit" every time you save from the editor, or even make the whole undo buffer persistent. Much more plausible with monotone than with CVS.

    Anyhow, there's unquestionably a lot of room for improvement in our developer tools. One of the questions in my mind is how far you can get if you define the problem as only version control; at some point the really useful stuff would involve the editor, the bug tracker, and so forth as well.

    This post moved to

    We bought a really strange game.

    This post moved to

    I shouldn't say Tivo sucks; I admit I'm doing something obscure and geeky with the file share of music. But, while I'm complaining about home electronics, I do have a basic Tivo complaint: they need to be the cable box.

    In Raleigh, we had a PVR that was built in to the cable box. Compared to Tivo, it was buggy and the UI was atrocious. However, it had several vital advantages over our current cable-box-plus-Tivo setup:

    • No lag due to Tivo-acts-as-remote-control-for-cable-box
    • The program guide was more accurate, so shows didn't get clipped at the end
    • It had multiple tuners, so you could watch a show while recording another
    • It would avoid problems such as changing the channel while recording, or leaving the cable box on mute
    • One less remote control
    • You can't use "On Demand", Pay Per View, and other cable features from Tivo

    No question that the cable companies are deliberately squeezing out Tivo, and it's pretty sad that Tivo created this category of device and probably isn't going to benefit from it in the long term. I don't know how Tivo can get around the situation though: a combined cable box plus PVR is a dramatically better user experience, even if the cable box PVR is pretty lame compared to Tivo's.

    I guess you can get Tivo integrated with a satellite box, one reason I wanted satellite instead of cable. Sadly we have too many trees.

    This is incidentally another reason I haven't tried MythTV; I'm hoping to get a PVR from the cable company. I'm even feeling a bit friendly toward Comcast, since they just wholesale rewrote the UI on the cable box and the new one seems optimized for, say, watching TV (rather than whatever the old one was supposed to be for).

    This post moved to

    About 5 years behind the curve, I decided that it would be nice to rip all our CDs, box them up, put them in the basement, and play the full music collection on shuffle.

    To start, I got an external hard drive and the nifty Linksys NSLU2. The NSLU2 is a $79 Linux server with two USB ports. You give it a blank USB hard drive, and it formats it with ext3; one small partition has some admin files for the OS, and the other partition holds your data. The NSLU2 runs Samba and acts as a file server.

    So my plan was as follows: let NSLU2 format the drive, then attach the drive directly to my laptop and rip CDs onto it. Move the drive back to the NSLU2 and voila, a file server with all my music. This part worked great. Even better: since I was using Sound Juicer and HAL/gnome-volume-manager in Fedora Core 3, I believe it could have been done without a command line. (Though I cheated and got rsync involved.) Now we can access all our music from any of the 3 PCs.

    The reason I got the NSLU2 was that our PCs are off most of the time, since they're loud and obnoxious. I figured I'd just put the NSLU2 and hard drive next to my wireless router and stuff the whole mess in the closet. That way no particular PC would have to stay on all the time, and ideally they could all be turned off while we listened to music on the stereo.

    And that's where the problem arises: how to get from a file share full of music to our stereo system?

    Plan A was to use the Tivo. It turns out that this has two showstoppers. First, it requires a server running on a PC; Not compatible with my "keep the PCs turned off" goal or my "Windows is only for games" goal. Second, even if we could live with that, the Tivo server software simply refuses to load any files found on a network file share. Lame!

    Switching to Plan B, I found a bunch of products to connect 802.11 to your stereo but virtually all of them require a daemon that runs on a Windows PC. The only "digital media player" I can find that will read files straight from a file server is the Roku HD1000, but it's huge overkill, and costs too much (especially since wireless requires an external adapter). From reading reviews, I also get the impression that nearly all of these "digital media players" are total crap, and that the required PC software is even worse. The nicest- and simplest-looking of the wireless-to-stereo-system converters is of course the AirPort Express, but it too requires a PC-hosted iTunes server.

    So after searching for the last few hours, I'm giving up on finding a prebuilt appliance that will work. My Plan C thought was to buy a small fanless Linux machine, an embedded board or something, and install Rhythmbox on it. But that sounds like a serious pain in the ass, and I avoided something like MythTV in the first place because I didn't want to fool around with custom hardware and software setups.

    I had one last thought just now: "wait, the NSLU2 is a small fanless Linux machine." And then Google turned up running an iTunes server on the NSLU2. Which would mean I could use the AirPort Express. So tomorrow's plan is to read that article and see if it looks possible. Still a pain in the ass, but at least no hardware hacking is involved.

    If it works, my total solution will be 1 external hard drive ($179), 1 NSLU2 ($79), 1 AirPort Express ($129) coming in under $400, which is not that bad. I am making it worse by adding a second external hard drive for backing up both music and data from the PCs, but that's optional.

    If Tivo didn't suck, then I could just go into the Tivo UI on my TV, enter the file share name, and have the music available; since the Tivo already uses a wireless adapter. If that had worked I could have solved the whole problem for $260 and without using the command line once.

    It's interesting that probably the majority of gadgets I've used and researched in the course of sorting this out are Linux-based. Including the Tivo, the NSLU2, and many of the digital media players.