By Jake Edge
July 27, 2011
Wherever systemd goes, arguments about it seem to follow. The latest
episode involves Debian "discussing" the pros and cons of the init
replacement, with many of the same arguments we have seen elsewhere on both
sides. But there is a difference for Debian because, unlike most
distributions, it supports both Linux and FreeBSD kernels and may
start supporting Hurd in 7.0 ("Wheezy"). That makes switching to
systemd more difficult for Debian—if it is even desirable—but it also
brings up an interesting question for the distribution: should the needs of
the smaller sub-distributions (GNU/kFreeBSD, GNU/Hurd) hold back progress
on Debian GNU/Linux?
Perhaps unaware of the firestorm he was about to set off, Juliusz Chroboczek
posted some observations about systemd to the
debian-devel mailing list. In it, he offered his opinion on the good and
the bad with respect to systemd and tried to make it clear that he wasn't
trying to push the decision in any particular direction, just recording his
observations. Overall, it is a fairly even-handed look at systemd that
notes multiple advantages and disadvantages.
Of course, systemd advocates will argue that some of the
disadvantages cited are wrong as Debian systemd maintainer Tollef Fog Heen did, but overall there weren't many big complaints
about the posting itself—except from systemd developer Lennart
Poettering. His response was forwarded to
the list by Chroboczek and was characteristically combative, which to some
completely justified one of the original posting's complaints:
"Systemd's author is annoying".
Undoubtedly Poettering is tired of defending systemd against what he sees
as "amazingly badly informed" criticisms. Given that the
overall tone of Chroboczek's post was fairly positive, though, it's a little
surprising to see the animosity with which Poettering responds. One of the
main problems that some in the Debian community (including Chroboczek) have identified with
systemd is its "Linux-only" attitude. Poettering
addresses that, like he has many times before, but includes a long list of
non-POSIX features that systemd uses, concluding:
"There's a reason why systemd is more powerful than other init systems:
we don't limit ourselves to POSIX, we actually want to give the
user/administrator the power that Linux can offer you."
But that power also limits the environments where systemd can run, of
course. In addition, the systemd developers have made it clear that they
are not interested in taking patches to make it portable to non-Linux
systems. In fact, Poettering calls it "practically impossible. about
every line of it is non-portable code" in an IRC conversation summary posted to the thread by Matthias
Klumpp. All of that makes it difficult for the Debian FreeBSD port, as well
as the Hurd effort (and would presumably hinder a humorously suggested
Plan 9 version of Debian too).
The Linux versions of Debian (including the various architectures and
embedded Linux versions) are by far the most popular, so there is a
question of how much minority Debians should be able to hold back
progress. As Uoti Urpala puts it:
I think the important question is whether portability to other kernels is or
should be a "project's goal", and how much else you're willing to lose for the
sake of that goal. I know I would personally be a lot happier with a Debian that
supports systemd functionality than with a Debian that can run on a BSD
kernel.
Wouter Verhelst, on the other hand, is adamant that GNU/kFreeBSD is going to continue
as part of Debian, and that systemd is not welcome if it will make it
harder for that variation to operate:
Whatever its features, if we have to jump through a large heap of hoops
to get it to work at all, or to make life for maintainers of daemon
packages not a complete nightmare, it's not likely to become the default
in Debian any time soon.
As might be guessed, Urpala was not convinced that supporting FreeBSD was
enough of a reason to stop the eventual adoption of systemd:
But the attitude that it's OK for kFreeBSD to set limits on
Linux development (or that developers working on Linux must handle the BSD
porting/compatibility to be "permitted" to adopt a new technology) smells of
trying to hold the project hostage, and I doubt it can have positive effects for
the project overall.
In addition, he and others believe that moving
away from the traditional System V shell-script-based init would
be a net benefit for package maintainers: "I think the life of many maintainers of daemon packages is a 'complete
nightmare' now with sysvinit, compared to what it would be with
systemd."
Because systemd can use existing init scripts, there is no need
for a mass translation of packages to support systemd. However, an
eventual switch to use systemd by default would undoubtedly cause various
Debian packages to drop their init scripts in favor of systemd unit files
that are far simpler, but wouldn't be usable directly by the System V init
system that is currently the default. All is not lost however, as Russell
Coker describes:
If a daemon supports socket activation then there would need to be separate
work done to write a systemd unit and a sysvinit script.
If a daemon doesn't support socket activation then IMHO the ideal situation
would be to have a program that takes a systemd unit file as input and creates
a sysvinit script. That would reduce the amount of effort and reduce the
amount of low quality sysvinit scripts that are out there (and I've written my
share of such bad scripts).
Another possibility would be for Debian to directly support both System V
and another init (i.e. systemd or Upstart) but many think that
idea is a non-starter. Maintainers would have to support both styles of
initialization (or ignore the benefits of the newer systems) as Russ
Allberry noted:
Unless you're willing to write init scripts and
cripple systemd by making it use init scripts, it's a huge pain, since you
have to maintain two parallel init setups for every package requiring
something to run at boot, one of which will probably never be tested by
the maintainer.
The same issue applies with upstart, of course. Both systems support
old-style init scripts, but one of the huge motivations for switching init
systems is to *stop using* old-style init scripts, since they support a
tiny fraction of the capabilities of systemd or upstart and are massively
annoying and tricky to maintain in a bug-free fashion.
There is a potential support problem for upstream projects, however, as
Gergely Nagy points out: "[...] even if systemd can
be made portable enough for Debian's
needs, or Debian can find a way to work around systemds unportability,
upstreams who need to support other systems will still have yet another
extra burden to carry." Of course, whether Debian switches to
systemd, Upstart, or stays put, the problem for upstreams doesn't really
change. None of the init systems is likely to disappear anytime soon, so
either upstreams or distributions will have to support all of them in one
way or another. As is often the case, Debian project leader Stefano Zacchiroli
finds some middle ground:
But what I find surprising in this discussion (with notable exception,
luckily) is the feeling that portability is boolean: it is not. It is
rather a trade-off among the work that needs to be done / code that
needs to be maintained and the distro-wide technical choices that we
make. In that respect, the fact that systemd upstream might decide not
to integrate upstream our [changes] is sad, but it's not the end of the
world: it won't be the first nor the last upstream not willing to
integrate some of our changes.
Zacchiroli's post—worth reading in full—manages to express
support for most of the positions taken in the thread, while also pointing
out
a clear path forward for any change to the init system for
Debian. While there hasn't been a large contingent pushing Upstart in the
thread, it is clearly on the radar as a possibility. Any change is likely
to be a ways off in any case, so a long thread arguing the merits of
systemd is premature. Whenever such a
decision is made, though, the general sense from those participating in the
thread is that the decision will be made on technical grounds separate from
the issue of how to support non-Linux versions of Debian. That
problem will be solved too, but there is no reason to hold back progress on
Linux for
other kernels (or vice versa).
Comments (86 posted)
Brief items
As you can clearly see, you can see nothing. Yes, nothing! As of 18:55:52
UTC+2 the NEW queue, which
at some times was well over 500, sometimes even 600 packages is now empty. Completely empty.
To the best of my (and Ganneff's knowledge) the last time the NEW queue was empty was at least five years ago.
Interesting enough, that triggered an yet undiscovered bug in dak, which refused to scan an empty directory...
--
Alexander Reichle-Schmehl
Comments (none posted)
The CentOS 6.0 live DVD is available. "
The CentOS-6.0 LiveCD is
meant to be a Linux environment suited to be run directly from either CD
media or USB storage devices. It does not need any persistent storage on a
machine, which also makes it a suitable recovery environment."
Full Story (comments: 1)
The Fedora IBM System z (s390x) Secondary Arch team has announced the
Fedora 15 for IBM System z 64bit official release.
Full Story (comments: none)
IPFire is a server distribution intended for use as a firewall. IPFire 2.9 Core Update 50 has been released.
"
Since 44 months and 50 core updates, IPFire is working better than
on the first day. The developers keep working on little updates that
improve the base system and addons, but also bring major updates on the
way. That is why the system runs very great on recent hardware and keeps
up with new technology. A very special attention is paid to
safety-critical problems. Many security issues of third party packages
have been patched, tested and delivered only within a couple of hours."
Full Story (comments: none)
The second release candidate for Mandriva 2011 has been
released. "
In this release candidate we fixed more than 300 bugs and added or changed about 700 packages."
Comments (none posted)
The openSUSE project has
released
the third milestone for openSUSE 12.1. "
Just a few days ago the third of six milestones on the road to openSUSE 12.1 has been made available for testing before it goes to final release November 11th, 2011. (Yes, 11-11-11!)"
Comments (none posted)
Red Hat has
announced
the release of Red Hat Enterprise Linux 5.7. "
Today's update adds
features that enhance the flexibility, security, and stability of Red Hat
Enterprise Linux 5 environments, and includes a number of features
incorporated from Red Hat Enterprise Linux 6. Application interface
consistency is maintained between Red Hat Enterprise Linux 5.7 and prior
updates, allowing systems to be updated easily without application
re-certification." More information can be found in the
release
notes and the
technical
notes.
Comments (none posted)
The Ubuntu team has announced the release of Ubuntu 10.04.3 LTS.
"
This release includes updated server, desktop, alternate
installation CDs and DVDs for the i386 and amd64 architectures."
Kubuntu 10.04.3 is also available.
Full Story (comments: none)
Distribution News
Debian GNU/Linux
The introduction of "multiarch support" is now a release goal for the
coming Debian release 7 "Wheezy" (targeted for a 2013 release).
"
Multiarch is a radical rethinking of the filesystem hierarchy with
respect to library and header paths, to make programs and libraries of
different hardware architectures easily installable in parallel on the very
same system."
Full Story (comments: 18)
openSUSE
The openSUSE conference team has announced the travel sponsorship program
to financially support community members to attend the conference
(September 11-14 in Nuremberg, Germany). The application deadline is
August 5.
Full Story (comments: none)
Newsletters and articles of interest
Comments (none posted)
The H
takes
a look at some of the features planned for Fedora 16. "
The feature list contains 40 items, including GNOME 3.2 and KDE Plasma Workspaces 4.7. The developers are planning to switch to using Grub2 for the boot loader. Having switched to systemd, as an alternative to sysvinit and upstart, in Fedora 15, the project plans to replace further sysv init scripts with systemd units in version 16. Furthermore, Fedora is to offer everything that's required for Xen virtualisation, as version 3.0 of the Linux kernel, which is now expected to be released on Friday, will include all the necessary components."
Comments (none posted)
Jack Wallen
presents
his top 10 reasons to use Slackware. "
1. Stability
Even for an operating system known for its stability, you'll be hard-pressed to find a more reliable Linux distribution than Slackware. It's been around for 20 years and has long enjoyed a reputation for being solid. In my time using it - and I have installed the most recent version as well as having used versions throughout my time with Linux - I can honestly say its reputation is entirely justified. Whether on a server or a desktop, it is remarkably stable."
Comments (4 posted)
Page editor: Rebecca Sobol
Next page: Development>>