LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsFedora, systemd, and changesSignificant changes in distributions brought by new releases often make some segment of the users unhappy—sometimes very vocally so. One need only look at the GNOME 3 arguments that have raged here and elsewhere to see one example. But another change that came along with Fedora 15 is getting a similar reaction: systemd. This replacement for the init process has many technical advantages, along with bugs to still be worked out of course, but its inclusion into Fedora 15 has been met with some rather loud complaints. There is merit to some of them certainly, but many seem to fall into the category of "how dare you touch my init". init is the first user-space process that gets started on a Linux system and is the only user-space process that is started by the kernel—the others are descendants of init. It is responsible for setting up the system for use by other processes: mounting filesystems, starting services, and so on. Traditionally, much of the work has been done using shell scripts, either with the venerable sysvinit or the more recent Upstart, but systemd is on a path to change much of that. Instead of invoking the shell multiple times as part of the boot process, systemd allows much of that work to be done from within the systemd executable itself, which saves a lot of overhead in terms of starting the shell and executing the same basic shell script code multiple times. But systemd can still use the existing sysv/Upstart-style init scripts, and Fedora 15 makes use of plenty of them. Over time, the plan is to phase those out in favor of configuring those services directly using systemd's configuration files. While systemd seems to be working well for many users, it isn't surprising that a low-level component might not suit everyone's needs. Several recent threads in the fedora-devel mailing list highlight some of those problems, but more than that, they also highlight just how unhappy some people can get with changes of this sort. Denys Vlasenko made a reasonable point—amongst some flames—when he asked about the memory usage of systemd: "Granted, systemd does a bit more that "typical" init, but I think using *eleven plus megabytes* of malloced space is a bit much." He went on to list multiple things that systemd does which, in his mind, should not be part of the init process. Eleven megabytes of malloced space did seem somewhat excessive, so Adam Jackson dug in to try to learn more. His numbers showed 21M of malloced space, 11M of which was all in 2064-byte allocations. Since malloc uses 16 bytes for its own bookkeeping, it meant that something was doing more than 5000 allocations of 2048-byte chunks. As Michal Schmidt was quick to point out, those come from a known problem with SELinux. Jackson also noted that Vlasenko wasn't really helping his case by not investigating the problem further:
I'd have more empathy for your position if you'd made even a cursory
investigation into what that memory was being used for.
To be clear, this is an observation about how you're presenting your argument. The original post reads mostly as "this looks like it's doing too much, because of these things that I don't understand but I just _know_ they're not necessary, so obviously this is all crap and everyone who's working on it should be ashamed". Even if you were right, that's not a tone of voice that makes people want to listen to you. Contrary to Vlasenko's prediction that his memory complaints would be ignored by systemd developer Lennart Poettering, it would seem that work started more-or-less immediately on finding ways to improve libselinux. Dan Walsh released an updated version that sped up the loading of the file context information by a factor of four. Discussion also started on ways to reduce the memory usage of libselinux. But there is an overarching issue here: it is long past time to complain about systemd's architecture or its inclusion into Fedora 15. As Simo Sorce put it:
[...] I
don't think [complaining] generically about systemd architecture here is [at all]
productive. We discussed systemd for quite a while here and it certainly
[is] far from perfect, for some things probably not even "good" yet. But its
time to file bugs for real problems, not time for bike shedding on
architectural decision that have been taken quite a while ago, unless
you want to argue for getting rid of it completely and reverting back to
the previous init mechanism.
New features for Fedora are proposed and discussed before a decision is made to include them. Fedora nearly shipped systemd in Fedora 14 before deciding against it in the final stages of the release process. That process was done in the open and the decision was made by the Fedora engineering steering committee (FESCo) in accordance with how Fedora is governed. Perhaps it was the wrong choice for the distribution and its users, but it's a little late to make that argument now. Fedora users who are upset by the change have multiple choices, of course. Some other distributions are also adopting systemd, but Ubuntu seems unlikely to drop Upstart anytime soon. In addition, Debian will still maintain Upstart and shell init scripts, even as it starts supporting systemd, because it wants to support non-Linux environments and systemd is very Linux-specific. Other distributions may also stick with Upstart (or still be using sysvinit). Another option would be to maintain Upstart and the init scripts as an option in Fedora going forward. While I have heard multiple complaints (on two continents) about systemd over the last few months, I haven't heard much in the way of strong technical arguments against it. The same is true of GNOME 3, actually. Those arguments may well exist—and even be compelling—but most of what I have heard has been an overall resistance to change. There is certainly nothing wrong with that, and change for change's sake is generally a bad thing, but the systemd and GNOME developers believe that they are making truly useful changes. There are enough other options in the free software universe that it probably makes sense for those who are unhappy to either engage with the development communities to move them in a different direction or to switch to one of the myriad other choices that exist.
Brief items Distribution quotes of the week
Will you be working on the yum bacon command per chance?
-- Mathieu Bouffard
Mathieu,
-- Seth Vidal
I'm sure you are joking but lest anyone get any clever ideas: there will not be any meat-eating related jokes in yum
No, I could not mention my own achievements, because Debian is a team
sport. I might have catalyzed some achievements, but I'm far from being
entitled to claim them as achievements of mine. That said, there have been
several Debian happenings during the past year that I'm particularly happy
and proud of. One is undoubtedly the Squeeze release and some of its
novelties, such as the removal of non-free firmware blobs and the kFreeBSD
ports. Another one, at a more social level, is the recognition of full
Debian project membership status (AKA "Debian Developer" status) to
contributors with abilities other than packaging.
-- Stefano
Zacchiroli (via an interview on Muktware)
dyne:bolic 3.0 beta1A beta version of dyne:III, the third series of dyne:bolic development, is available for testing. "this version of our OS is based on the last stable version of pure:dyne "carrot and coriander" ( see http://puredyne.org ) closely reviewed following the 100% free guidelines set by the linux-libre project." Pure:dyne is a community effort maintained by media artists for media artists, using free software.
Fedora 16 to use Btrfs as its default filesystemAt the June 8 meeting of the Fedora engineering steering committee (FESCo), the group decided that Fedora 16 will ship with Btrfs as its default filesystem. Btrfs is a relatively new copy-on-write filesystem with many interesting features such as read-only and writeable snapshots, multiple device support for RAID, online filesystem defragmentation, and more, though it is still marked as experimental in the kernel. "AGREED: Feature is approved. Will add some base critera to the page to be met by feature freeze. This is just a swap of ext4 to btrfs for default, not change of lvm or other parts of default."
openSUSE Medical release and new leadershipThe openSUSE Medical project is aimed at packaging and publishing software for medical purposes. "openSUSE Medical is now part of the Linux Medical Taskforce and has exciting plans for the future included importing diabetes care and diabetics applications, some educational applications for students and of course the usual updates, bugfixes and translations." The first beta of openSUSE Medical 11.4 is available for testing. Feedback from medical professionals, medical students, physicians and patients is welcome.
Tin Hat 20110613 released.Tin Hat is a desktop system based on Hardened Gentoo which runs purely in RAM. "[Tin Hat 20110613] is a major release with upgrades to every aspect of the system. The toolchain was updated to Gentoo's hardened gcc-4.4.5, glibc 2.12.2 and binutils-2.20.1. The kernel was bumped to vanilla 2.6.38 plus GRSEC/PaX patches. System init was updated to openrc. In all, about 400 packages were upgraded, including Gnome 2.32.1 and Namoroka (aka Firefox) 3.6.17"
Distribution News Fedora Election Results for FESCo and Fedora Board seatsKevin Fenzi (nirik), Bill Nottingham (notting), Tomáš Mráz (t8m), Peter Jones (pjones), and Stephen Gallagher (sgallagh) have been elected to serve on the Fedora Engineering Steering Committee (FESCo). Rex Dieter (rdieter), Jon Stanley (jds2001), and Peter Robinson (pbrobinson) have been elected to serve on the Fedora Board.
Fedora 13 end of life on 2011-06-24Fedora 13 will reach end of life on June 24, 2011. There will be no updates after that time. "Please see http://fedoraproject.org/wiki/DistributionUpgrades for more information on upgrading from Fedora 13 to a newer release."
openSUSE The road to systemd for openSUSE 12.1The openSUSE project aims to have systemd as the default in its next release. "As you might guess, switching boot manager is not a trivial task and issues will be found. So, we want to have as much feedback and testing as possible, to try to tackle as much (if not all) issues in time for 12.1."
Newsletters and articles of interest Distribution newsletters
Zimmerman: DEX finishes first batch of derivative patches for DebianOn his blog, Matt Zimmerman posts a report on DEX, which is a project to get Debian and its derivatives working more closely together. Debian project leader Stefano Zacchiroli had a hand in both the project and the report. It looks like the first project, "ancient-patches", was a success: "This has left only two patches out of the original list of 277. Both of them are filed in the BTS and have been discussed with the relevant maintainer team. One of them is expected to be obsoleted when a new upstream version is packaged, which implements similar functionality. The other is being discussed with the upstream developers, but there is no conclusion yet about whether it can be merged upstream or in Debian."
Ubuntu 11.04 (Natty Narwhal), Reviewed In Depth (Tom's Hardware Guide)Tom's Hardware Guide has a lengthy review of Ubuntu 11.04 and the Unity interface. "Unity incorporates some great design concepts, but they are counterbalanced by other concepts that aren't so great. The new Panel is streamlined, and an explanation of the indicator colors is a welcome addition. However, the global menu is of questionable merit and the lack of GNOME applets is disappointing. The concept of Dash is much-needed on desktops, notebooks, and tablets. But the non-customizable layout and reliance on typed searches can slow down even the most basic tasks. The design of the new Launcher is definitely a high point, while its rigid auto-hide behavior is unquestionably a bummer."
Page editor: Rebecca Sobol |
|||||||||||||