Hi,
On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote:
> Hello,
>
> In the past, we have had multiple heated discussions involving
> systemd. We (the pkg-systemd-maintainers team) would like to better
> understand why some people dislike systemd.
>
> Therefore, we have created a survey, which you can find at
> http://survey.zekjur.net/index.php/391182
>
> Please only submit your feedback to the survey and not this thread, we
> are not particularly interested in yet another systemd discussion at
> this point.
I think that one reason why we risk having another init systems
discussion is that there hasn't been (TTBOMK) a good effort to summarize
the various point raised and your answers (as systemd maintainers) to
them. Such a "systemd demystification" effort would have been a nice way
forward.
I went through the various init systems threads again during the last
few days. My understanding of the consensus so far is the following:
- Both systemd and upstart bring many useful features, and are a
clear improvement over sysvinit. It is not clear which one of systemd
or upstart is the best on the technical level. Many of the differences
have grounds in differences of philosophy, which can easily be seen as
pros or cons.
- It is also hard to say which one is best on the development/support
community level. Upstart is strongly supported by Canonical, which is
an organization with which we are quite used to work with. However,
contributions to Upstart are subject to the Canonical contributor
agreement. Systemd has already been adopted by most of the other
major distributions.
- Neither systemd nor upstart are likely to be ported to kfreebsd soon,
as they both rely on many Linux-specific features and interfaces.
As Debian, we have two different problems:
1. We need to decide which init systems we want to support, and how.
2. We need to decide which init system should be the default.
1. Deciding which init systems we want to support, and how
----------------------------------------------------------
I'm not talking about shipping them inside Debian (we already do that),
but about providing the necessary service config files (upstart job
files / systemd service files) so that users actually benefit from
switching to systemd or upstart.
We don't need to select a single init system at this point, and it would
make sense to try to support all of sysvinit, upstart and systemd, at
least for some time. (And, since sysvinit is the only alternative on
kfreebsd, we could aim to end up supporting (upstart OR systemd) AND
sysvinit, provided this proves feasible thanks to e.g. helpers to
generate init.d scripts.)
The policy has already been updated for upstart, and currently states:
(9.11.1) Packages may integrate with the upstart event-based boot
system by installing job files in the /etc/init directory.
(http://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit)
One clear task for systemd supporters is to similarly update the policy
for systemd.
Then, something I failed to find in the discussion was a discussion of
how sysvinit / systemd / upstart could co-exist (not on a single system,
but in the archive). I understand that systemd replaces some parts of
initscripts, could also replace syslog, etc. How do systemd supporters
see that working in practice? What kind of feature duplication between
init sytems should be expected? How much does it increase the
maintenance effort?
Something else I failed to find in the discussions was an evaluation of
the transition effort. We currently have 1190 initscripts, shipped by
1094 packages. How do systemd supporters see the transition to service
files? How can we make it easier?
There was a GSoC project in 2012 about generating sysvinit scripts from
systemd .service files. Was there some communication about its outcome?
Is it realistic to dream about a generator that would automate the
generation of sysvinit scripts, systemd .service files, and upstart job
files for a majority of our packages (the "easy" ones)?
Some infrastructure to track those transitions would be useful (status
page, graph).
As well, as, maybe, a tool to list locally-installed packages that lack
upstart of systemd support (think of {rc,wnpp}-alert).
According to some quick grepping in Contents-*, currently, we have 76
upstart job files shipped in Debian. Ubuntu has 301. And we have 204
systemd job files in /etc or /lib.
2. Deciding which init system should be the default
---------------------------------------------------
That decision is likely to be hard to make, but in any case, a survey
at this point is unlikely to be extremely helpful.
We don't need to wait until one of the alternatives is fully supported
by all packages to chose that alternative, but how the transition
happens for each alternative is likely to provide valuable input, and
more insight into the features of each alternative.
Lucas
Attachment:
signature.asc
Description: Digital signature