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.
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.
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.
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 ;-)
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.
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. ;-)
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.)
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.
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:
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 gnome.org." Given the recent freedesktop.org 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.
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.
We bought a really strange game.
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 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).
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.
