Fedora: an example of community involvement
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:
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.
Posted Nov 18, 2004 5:36 UTC (Thu)
by hp (guest, #5220)
[Link] (2 responses)
Posted Nov 18, 2004 7:53 UTC (Thu)
by skvidal (guest, #3094)
[Link] (1 responses)
However, as I have been one of the most vocal critics of fedora's fitful growth into a community project I think I'm in a good position to say that things are getting much better. They're not great but I think it's on a much better track than it was. I'm looking forward to more development time on FC4 and a number of side projects related to FC4.
-sv
Posted Nov 18, 2004 19:12 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
Posted Nov 18, 2004 10:23 UTC (Thu)
by NRArnot (subscriber, #3033)
[Link] (1 responses)
In the case of a linux distribution, that problem isn't a serious one. If Redhat is able to continue to provide benevolent dictatorship of this project, it will continue to flourish. If not, there are plenty of other distributions to defect to, and the sources as well.
Posted Nov 18, 2004 13:45 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Exactly. To be frank once I've tries Fedora Core 1 I've been so disappointed I've switched to Gentoo and never recommended Fecora Core to anyone. Recently I've tried Fedora Core 3 and I actualy liked it! I myself will stick with Gentoo but if user does not like to recompile everything every day the Fedora looks like good choice now.
Posted Nov 18, 2004 16:23 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (2 responses)
Posted Nov 18, 2004 20:13 UTC (Thu)
by stuart2048 (guest, #6241)
[Link] (1 responses)
Posted Nov 19, 2004 13:58 UTC (Fri)
by dcoutts (guest, #5387)
[Link]
Conclusion FIFO's are wierd and best avoided in favour of unix domain sockets.
Posted Nov 18, 2004 19:54 UTC (Thu)
by tpo (subscriber, #25713)
[Link] (1 responses)
Posted Nov 19, 2004 12:55 UTC (Fri)
by jvoss2 (guest, #7065)
[Link]
I did :-) The result is not as beautiful as Ziga's, but it might be useful nevertheless. You can find it at my Boot Process of a Debian System web page.
I hope this helps,
Posted Nov 24, 2004 23:44 UTC (Wed)
by zeega (guest, #26094)
[Link]
I'd like to include boot charts from various GNU/Linux distributions on the web site (Gentoo, Ubuntu, Debian, etc.). Each may require minor modifications of the init script though, so let me know if you have any questions.
--
Posted Nov 25, 2004 9:35 UTC (Thu)
by forthy (guest, #1525)
[Link] (1 responses)
Posted Nov 26, 2004 20:29 UTC (Fri)
by niner (subscriber, #26151)
[Link]
Are there distros out there that do not already behave this way?
Posted Nov 25, 2004 10:53 UTC (Thu)
by gowen (guest, #23914)
[Link] (1 responses)
Posted Nov 25, 2004 10:54 UTC (Thu)
by gowen (guest, #23914)
[Link]
Posted Nov 25, 2004 15:05 UTC (Thu)
by paulpach (guest, #20903)
[Link]
I am currently porting Ziga's scripts for gentoo.
Posted Nov 26, 2004 18:50 UTC (Fri)
by renox (guest, #23785)
[Link]
To have the equivalent under Linux, you would have to measure: kernel boot + KDE or Gnome startup with auto-login.
The public source repo is basically in beta test now with a number of external people involved in that.Fedora: an example of community involvement
In addition fedora extras cvs repo is in use by at least 5-6 non-red hat employed contributors. There is much progress being made, especially with CVS. When the official public announcement will be is in anyone's guess.Fedora: an example of community involvement
Thanks for saying this seth. I am having to make a decision soon for my own enviroment, and hearing things from people who have taken RH to task is clarifying if I should stick with RH.Fedora: an example of community involvement
It's been observed that the best form of government is a benevolent dictatorship, but that no means has ever been found to keep the dictator benevolent.Fedora: an example of community involvement
Fedora: an example of community involvement
This is a pleasing and immediately understandable chart. Tufte would be proud. If I had some sort of Linux award to offer, Ziga Mahkovec would receive it for showing ineguity and motivation in an area that has languished for years. And Owen Taylor would get an honorable mention.Fedora: an example of community involvement
Hmm, what sort of award should we propose for the chap who stuck a busy loop in rhgb in the first place?Fedora: an example of community involvement
It was not obviously a busy loop. It's a problem with properly understanding the wierd semantics of FIFO's. Apparently if a FIFO has no writers and a reader is poll()ing/select()ing on it, the semantics is that instead of blocking until a writer connects to the FIFO and writes something, the kernel sends the reader process sig HUP every time it poll()s. So the reader ends up spinning bussily.Fedora: an example of community involvement
Anybody tried this (logging the boot) with Debian? Fedora: an example of community involvement
*t
Fedora: an example of community involvement
Jochen
The bootchart script and source code are now available on SourceForge, so if people want to give it a try, visit:Fedora: an example of community involvement
http://www.klika.si/ziga/bootchart/
Ziga
One culprit of long boot time is init, which starts processes Fedora: an example of community involvement
sequentially. On the last LinuxTag, a guy next to me in the bar BQ queue
told me that he had changed init to run all the setup scripts of one
run-level in parallel, and reported a very significant speed-up in boot
time. It's probably not an universal solution, since run levels are not
necessary dependency graphs, but creating such a dependency graph and
executing it as parallel as possible should help (or at least start all
S<n> scripts with equal n in parallel).
I'm a little bit surprised. I know that at least on SuSE exactly this is done. Init scripts have priorities inidcated by the number between S and the scriptname in the runlevel link. These numbers are calculated through dependencies given by special comments in the init scripts themselves and all scripts with the same priority are started in parallel. So this is already implemented and even standardized in the Linux Standards Base: http://refspecs.freestandards.org/LSB_2.0.1/LSB-Core/LSB-...Fedora: an example of community involvement
I find the contents of the opening paragraph peculiar. Would anyone at LWN ever consider writing :
Fedora: an example of community involvement
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 at Linus Torvalds' house.
D'oh! That should, of course, read:Fedora: an example of community involvement
The Linux Kernel, after more than ten years, 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 at Linus Torvalds' house.
I have made a few patches for gentoo that decrease boot time. The most important
ones are Avoiding unneded
work, Making parallel
startup trully parallel, and Starting X as soon as posible
For gentoo users
With BeOS, from the moment the BIOS initialisation finish to a usable graphical desktop, it took under 20s (more like 14s if memory serves) on a Celeron333 with 128MB of RAM.46s is still far too slow
If I'm not mistaken 46s only take into account the kernel boot time on a 1.5GHz PentiumM!
This may be be partly caused by a slow disk (the PentiumM makes me think that it is a portable which have usually slow disks), but still this is very slow..