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
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.
Comments (17 posted)
The NSA's Security Enhanced Linux project is controversial. To some, it is
the future of Linux computing; with SELinux, many of our current security
nightmares will cease to trouble us. To others, SELinux is a morass of
complexity which is difficult, if not impossible, to understand well enough
to get any sense of whether it is configured in a secure way or not. This
whole situation is not helped by the current state of SELinux
documentation. There are few resources out there for people wanting to
know how SELinux works, how to manage it, or even whether to try to adopt
There is, however, a new book on the shelves: SELinux: NSA's Open Source
Security Enhanced Linux, by Bill McCarty. At 254 pages, this book is
relatively thin by contemporary technical book standards. It offers a
finicky editor a fair number of things to grumble about, but those grumbles
should not overshadow the important point: this book is an important step
in the process of bringing SELinux to a level where software developers and
system administrators can make some sense of it.
Let's get the grumbles out of the way first. The book shows some signs of
having been written and produced in a hurry; as a result, it has more than
the desirable number of typos and contradictions. It talks alternately
about the runcon and run_con command, for example. It
claims that "domain" and "type" are interchangeable terms for the same
concept, then says "Recall that a general type is one not related to
a specific domain." Readers are directed to the kernel source (said
to be found in the deprecated /usr/src/linux directory) to
associate a device name with a major number when a quick look at
/proc/devices would do the job. We are told "SELinux is
generally stable and free of trouble," which would, by itself,
strain many readers' ability to suspend disbelief, but then the author
suggests avoiding using X on SELinux systems, or, if that is impractical,
learning to love GNOME to avoid problems with KDE. And so on. The reader
finds these things often enough that they become a significant distraction
from the real content of the book.
The book starts with a general overview of SELinux, including the obligatory
set of scary statistics on the frequency of attacks. A number of
approaches to security are looked at, including, of course, mandatory
access control schemes. The second chapter is a quick overview of SELinux,
where the important concepts (roles, types) are introduced. The two
mechanisms which can cause type/domain transitions (file creation and
exec() calls) are introduced. Everything is fairly vague at this
point, but the discussion is enough to let some of the important ideas sink
The author then takes a diversion into how to install SELinux on several
distributions, with special attention paid to Debian, Fedora, and Gentoo.
This information will certainly be useful to some readers, but (especially
in the future) most readers are likely to find SELinux on their systems
already. If you are trying to figure out how to make your Fedora system
work, Chapter 3 will just be a distraction. (Incidentally, the book
covers Fedora Core 2).
Chapter 4 gets into high-level SELinux administration: turning enforcement
on and off, installing new policies, dealing with file labels, etc. There
is useful stuff here, but the presentation leaves a little to be desired.
For example, loading policies requires the use of the newrole
command (which will remind old-time Unix users of the obnoxious
newgrp command made necessary by certain vendors' kernels which could only handle
membership in one group at a time). Policy loading is covered
before newrole, however, leading to a fair number of
forward references in the text. Reordering the discussion would have made
things easier to follow. That said, this chapter provides a reasonable
start for administrators trying to find their way around their SELinux
The next three chapters form the technical core of the book, with detailed
descriptions of the language used to define role-based access control and
type enforcement rules. There's lots of cute railroad diagrams for those
who want pictures, and a detailed examination of how the policy for the
ping utility is put together. If you are trying to make sense of
the policy files that come with your SELinux distribution, these chapters
provide the information that you will need. The book then winds down with
a chapter on ancillary policy statements and one giving some pointers on
how to carry out simple policy changes.
A topic which is missing entirely is how one might design a security policy
from the beginning. The implicit assumption is that few, if any, readers
will have such ambitious goals; they will, instead, be trying to make
things work with the policy shipped by their distributor. That is probably
a good assumption; designing an SELinux security policy from the beginning
is not for the faint of heart. Still, as we'll explore in a companion
article, there may be reasons for wanting to take on such a project.
Meanwhile, if SELinux takes off the way many people clearly expect it to,
there will be a strong need for developers and administrators who truly
understand how it works. For that reason, your editor predicts that this
book will become required reading for a lot of people. For all of our
quibbles, we must say that Mr. McCarty has succeeded in shedding some
much-needed light into a dark and difficult corner of Linux systems
Comments (4 posted)
As the release date for Solaris 10 nears, Sun Microsystems has been
powering up the hype machine accordingly, and trying to convince
the world that Solaris 10 is the best OS ever.
According to Sun, Solaris 10 will offer more than 600 new, "breakthrough"
features. That's a few too many for this article, but we'll take a look at
some of the most notable features that are slated for inclusion in Solaris
One interesting feature is Solaris Dynamic Tracing (DTrace). DTrace is a
system for troubleshooting problems in real time, by allowing admins and
developers to observe and tune system behavior.
Another feature that Sun is touting is Solaris
Containers. Containers are essentially virtual machines, which allow an
admin to create "private execution environments" on a machine,
to isolate applications from one another and essentially create multiple
hosts on a single server. This is, of course, nothing new to Linux users
who have already discovered User-Mode Linux or any
of the other virtualization solutions available for Linux.
Solaris 10 also comes with a new file system, ZFS. This is
a 128-bit file system that offers far greater capacity than the current
UFS, and 64-bit checksums for data stored on the filesystem. ZFS works with
"virtual storage pools," and is supposed to greatly reduce the difficulty
of administering file systems. According to Sun's website:
For example, with Solaris ZFS, to add mirrored file systems for three users
and then add more disks, the number of tasks is reduced from 28 to 5. And
the time taken to perform this function has been reduced from 40 minutes to
10 seconds, so administrators can spend more time solving business
problems, rather than managing storage.
The TCP/IP stack gets special attention in Solaris 10. Sun has rewritten
its networking stack, and claims that delivers a 50-percent or better speed
boost for "many networked applications." Solaris 10 also
includes built-in kernel support for the Stream Control Transmission
Protocol (SCTP) and Session Initiation Protocol (SIP) in an effort to make
Solaris 10 attractive for VoIP deployments.
Despite the slew of new features, Sun has fallen into an unenviable
position with Solaris: Having to go to customers with a emulation
technology to run their existing programs. When Linux was the underdog,
much was made of the ability to run Solaris and other *nix binaries on
Linux, as a way to allow companies to move their existing applications to
Linux. With Solaris 10, Sun is promising a Linux
Application Environment (LAE) to run Linux binaries on Solaris 10 on
Pricing for Solaris 10 has changed as well. Sun is, literally, giving it
away. Sun is giving a "right-to-use" (RTU) license and security updates for
Solaris 10 at no charge. Customers who want to utilize support or have
access to all Solaris 10 updates and fixes start at $120 per year for a 1-4
The company is also making much of binary compatibility with Solaris 10 --
promising customers that older Solaris applications will be able to run
unchanged on Solaris 10.
Perhaps the most interesting feature for Solaris 10 is the licensing, if we
ever find out what it is. According to Sun's executives, Solaris 10 will be
open source. However, the company has not yet announced a license, whether
the license will be OSI-compliant or
exactly how much of Solaris 10 will be under this open source
license. Further, assuming that the license is open enough to encourage
contribution, Sun hasn't set out any information about accepting
contributions from the community.
A more ominous possibility exists: Sun could release its code under a
license which is not only non-free, but which creates problems for any free
software developers who look at that code. If Sun's fortunes continue to
decline, there is a definite possibility that the company could look to
litigation for its salvation. This possibility should be kept in mind by
anybody who contemplates going anywhere near the Solaris code.
Obviously, Sun is trying to regain some of the ground that it has lost with
Linux. It seems unlikely, at least to this writer, that Sun will make much
headway in regaining lost customers with Solaris 10. While Solaris 10
offers some undeniably useful and interesting features, it's fairly obvious
that most organizations do not choose operating systems on features alone.
Sun lacks the momentum that Linux has gained over the past few
years. Companies that have already invested time and money into migrating
to Linux are less likely to spend additional time and money evaluating
Solaris 10 if Linux is meeting their needs. Companies that are already
utilizing Linux are unlikely to even bother evaluating Solaris 10 unless
Linux does not meet their needs.
Also, Sun's LAE won't be available in the first release of Solaris 10,
meaning that organizations that are willing to consider migrating from
Linux to Solaris will have to hold off until Sun releases LAE in an update
to Solaris 10. This puts Sun even farther in the hole with regards to
losing customers to Linux.
If the Solaris 10 license is GPL-compatible, many of Solaris 10's
interesting features will no doubt find their way into Linux. It seems
unlikely that Sun would choose that path. On the other hand, if Sun chooses
a less friendly open source license, it will have a tough time creating a
community that will drive Solaris development or adoption in the same way
that the GPL has driven Linux. Either way, Sun seems set to lose with its
open source ploy.
Solaris 10 looks to be a fine operating system, but it may very well be too
little and too late to help Sun regain its market share.
Comments (36 posted)
A press release
has gone out stating that
the Polish government has
officially decided that it is unable to support software patents in
Consequently, the EU Council is unable to formally adopt that
legislative proposal as its common position. Without the support of Poland,
those countries that supported the proposal in May now fall short of a
qualified majority by 16 votes.
Needless to say, this is an
important development. Software patents will probably not be defeated
quite this easily, but this is an important step in that direction.
Comments (none posted)
Next week's LWN Weekly Edition will be published on November 24 - one
day earlier than usual - so that the LWN staff can prepare themselves for
the annual Thanksgiving feast. We'll return to the usual schedule on
Comments (none posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Civilizing SELinux; New vulnerabilities in bogofilter, ez-ipupdate, OpenSSL, SquirrelMail, sudo, ...
- Kernel: Not getting burned by kunmap_atomic(); Trustees Linux; Avoiding unwanted OOM killer experiences.
- Distributions: SUSE Linux Enterprise Server 9; Gentoo Linux 2004.3; Novell Desktop reviewed
- Development: Wired: a music production and creation system,
new versions of ALSA, GLib, DSPAM, spamprobe, Analog, abcde,
Ecasound, Grace, SQL-Ledger, PythonCAD, JGraphpad, JUNG, GARNOME,
Xfce, Passepartout, Grisbi, Gaim, Epiphany, Coaster, SableVM,
MLton, Pyro, Ali, Wing IDE.
- Press: A patent marketplace, Firefox adoption, Open Solaris, Norway saves
money with Linux, Senate Copyright Bill, MS and Indemnification,
- Announcements: The Linux Core Consortium, VC firm joins OSDL, lots of new books,
VA survey on open-source resistance, GNOME love day, JavaPolis,
PHP Quebec, Mozparty2.
- Letters: How to improve IE