Fedora: an example of community involvement [LWN.net]

The Fedora Project, after more than one year, has not become a "community" project by any means. It is centrally controlled, and many crucial decisions seem to come from some sort of smoke-filled room in Raleigh. The long-promised publicly-available source code repository ("intended to be available by the release of Fedora Core 2") is nowhere to be seen, the governing councils have not been created, and the project's technical leader is rarely seen on the mailing lists. In many ways, Fedora looks more like an open beta testing program run by Red Hat than a true community project.

That said, a couple of things are worth pointing out. One is that the Fedora Project has clearly succeeded in creating, evolving, and supporting a top-quality distribution with bleeding-edge software and predictable release cycles. The other is that, in some ways at least, Fedora's interaction with its user community is yielding clear benefits. Simple testing and filing of bugs is probably the biggest part of it. Beyond that, however, the project does seem to listen to its users and be influenced by what they say, even if Red Hat does have the final word on important decisions. And, at times, members of the community can truly help to make the distribution better.

As an example, consider this challenge recently posted by Owen Taylor. He noted that a Linux system still takes a couple of minutes to boot, which is too much:

Ideally, system boot would involve a 3-4 second sequential read of around 100 megabytes of data from the hard disk, CPU utilization would be parallelized with that, and all queries on external systems would be asynchronous ... startup continues and once the external system responds, the system state is updated. Plausibly the user could start work under 10 seconds on this ideal system.

Owen asked for help from the community in figuring out what was slowing down the boot process. That help was all of two days in coming, when Ziga Mahkovec posted some results. He had modified the kernel boot process to instrument what was going on, and produced a pretty chart showing where the time was being spent. One immediate culprit stands out from the chart: the rhgb process. That is the "Red Hat Graphical Boot" utility, which does no actual work; it simply watches over the initialization process and shows its progress on the console. It's not something which should be occupying a large part of the time required to boot. But it was responsible for over 1/3 of the time required to boot a Fedora system.

As it turns out, rhgb gets into a loop where it simply spins in the CPU, slowing down everything else. A bugzilla entry was created, the bug was fixed, and life improved. Ziga made a new chart showing an improved situation - and a boot time of 46 seconds.

Fedora users may have even more to cheer soon. Ziga made yet another chart which follows the process through a GNOME graphical login. One of the big culprits there is the obnoxious, throbbing Red Hat Network update applet. It turns out that Red Hat developers detest that applet too and tend to kill it on their systems. Now that it has been shown to be a major factor in making users wait to be able to do anything with their systems, it may just get some needed attention.

Meanwhile, the bottom line is this: Fedora may not be a community project like, for example, Debian. But neither is it a sealed product from a corporate cathedral. Fedora is clearly a better distribution as a result of its interactions with its users. Hopefully, someday, Red Hat will follow through on its promises (source code management server, community governing council) and bring the community further into the process. Fedora is blessed with a community of users who want to help; it shouldn't let the desire for corporate control keep them from being part of the project.

(Log in to post comments)