Bootchart: testing boot performance

Bootchart is an application which analysis the boot time performance of your system. It can be useful to track down problems or bugs during boot time. Also, it is a very helpful tool to compare the init boot system with its alternatives.

Recently M. Tim Jones of IBM fame released a comparison of two famous init replacements: initng and upstart. While the comparison gives a good view into both systems and is also clear about the difference in both attempts, it also mentioned a tool to test a the boot performance: bootchart.

Bootchart starts at the beginning of the system and tracks down the system performance and the processes currently running. Afterwards it presents you with a graph of the entire boot process. In my case, it looked like this:

This graph first tells me that my system is *really* slow: 90 seconds is much to much time for a boot process. Now you see why I was so excited when I realized that Suspend to Ram works flawlessly on my system. Also, you might now realize why I’m waiting for a init replacement in Fedora – although its not said that this would actually solve my problems.

Anyway, bootchart is really easy to set up:
Although it is currently not part of any Fedora repository and although there is no rpm provided, there is a src.rpm at the download page which can easily be rebuild (rpmbuild --rebuild bootchart*src.rpm). All dependencies are part of Fedora Core or Extras, so no problem there.
After installing the rpms you will find a new entry in your grub/lilo boot menu. If you switch the the link the system starts first bootchart and afterwards the init system. Just wait until your computer is up as usual, and you will find the bootchart information at /var/log/bootchart.tgz. You can upload them to the web renderer given at the bottom of the download page, it will produce a png or a (for me broken) svg, depends on what you prefer.

If I find the time I will test an init alternative and upload a new bootchart graph. But in any case I will upload a new graph when I’m switching to Fedora 7. I’m curious about the result.

Compiz-Beryl: re-merge possible?

There are talks between Beryl and Compiz about a possible re-merge of both projects. Although nothing is written in stone yet it is at least a chance that it could become true.

David Reveman, the creator and main programmer of Compiz, summed up his experiences from the X developer conference some days ago. While mainly focussing on the future of X he also wrote some lines about the “Beryl situation”:

I had the chance to talk to Quinn Storm from the beryl project during xdevconf. I would have hoped that the current situation with beryl could be improved but it seems like Quinn at least isn’t interested in that. However, after talking to Quinn it’s very clear to me that the fork was partially motivated by assumptions that were wrong.

It now looks like that some people saw this as an opportunity and talked to David:

Robert (racarr) contacted David Reveman a few days ago in respons to his post about “The beryl situation”, and started a dialog about a possible merge. He did this on his own initative, it was not in any way an attempt to force a merge, but rather to investigate the possibility.

In his first reaction Quinn didn’t like the idea, however he listened to reasons and arguments: he thinks that a re-merge might be possible under certain conditions:

Well, I’ve read all the arguments, and I think I may have been being overly cautious. It is indeed a concern that we might lose our freedom in a ‘merge’, but I have been convinced that it isn’t a major concern (and of course we reserve the right to re-fork).

Interesting.

However, as I said at the beginning nothing is written in stone yet. Also, it looks like that David and Quinn are indeed two totally different characters and it will be difficult for both of them to stay in the same team in some kind of equal position. Keep in mind that David is very code focused while Quinn was very user focused from the beginning.

Anyway, the main thing I would like to see is that Beryl/Compiz/re-merge tries to catch up with Metisse. Sure, the Beryl/Compiz stuff looks cool, but Metisse was made with usability and usefulness in mind. Especially the last one is a problem of Beryl and Compiz because there is large space for improvements.
Also, if Beryl and Compiz re-merge than it becomes interesting what the other window managers do: Red Hat currently still supports Metacity, and Kwm is also one of the biggest window managers around. At the moment Kwm gets some 3D love and is improved to the level of a real composite/window manager.

So together with Metisse there are still four players in the game even if Beryl/Compiz merge. I wonder how good the cooperation/competition think will work out between them.