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
signature.asc
Description: Digital signature
