I have reported on my impressions and experiences of both systemd and upstart in my previous messagges.
I'd like to run through the remaining points I want to make. I'll then summarise and set out my primary conclusion. Firstly, unlike the systemd maintainers, I think portability to non-Linux systems is important. It may be that our existing non-Linux ports are not very widely used, undermained, and/or not of production quality. However, I think it is important for us to keep those options open. Of course that provides a space for people to work on them and use them, directly, but more importantly it keeps Debian's options open for the future. And the competition helps keep Linux honest, which is important because Linux is effectively unforkable, has a poor history of responsiveness to concerns of some of its downstream userbases, and has a nearly-unuseable governance setup. This by itself means that systemd would have to have very strong other advantages for me to want to choose it. And I recognise that this point of view is not necessarily widely shared. However, happily, I find that no conflict arises for me between my desire for portability and the other relevant criteria. It is important for a component like an init system to be flexible: it needs to act as glue between disparate software projects, and to accomodate their quirks. My experiences with systemd's Debian maintainers (and, indirectly, systemd's upstream) have been far from satisfactory in this regard. Instead of taking a flexible approach, and being willing to provide a range of glue facilities and approaches for different daemon upstreams, the systemd community seems doctrinaire. Daemon authors are expected to do as they are told by systemd upstream, rather than systemd upstream making things comfortable for daemon developers. This is IMO the opposite of the proper attitude. The same appears to be the case for systemd's interactions with Debian as a downstream. Pressure has had to be applied on issues such as separate /usr (and much documentation still contains claims that this is "broken"); I asked for systemd to be able to execute programs from PATH rather than requiring unit files to specify the absolute path and was rebuffed (#...) This is exacerbated by the fact that systemd's Debian maintainers are (IMO) much too deferential to upstream. Finally, the systemd community seems to havve a programme of replacing many other facilities throughout the system (including ones which other software already does better - see eg binfmt-support, #716812, and Colin's comments, which I agree with). This is to be discouraged IMO. In short, the systemd community feels, to me, arrogant and controlling. I am far from the first to say something like this, but I've now experienced things for myself and I concur with the criticism. upstart's minimalism is very appealing to me. It does, however, have a number of missing features. Those I have in mind are: - ability to log daemon output to syslog - multiple socket activation (systemd socket activation protocol) - socket activation for IPv6 (and datagram sockets) Of these Russ rightly points out that lack of IPv6 support is rather poor; it is arguably not suitable for release in jessie without this. However, crucially, these are all simple matters of programming, without difficult design decisions. They IMO don't reveal structural problems with upstart's approach to things. Furthermore, in my view the responses of Debian's upstart maintainers to my bug reports about upstart have been exemplary. There has been, for example, no resistance (from them or AFAICT from upstream) to supporting the systemd socket activation protocol. I am confident, therefore, that if we choose upstart in jessie, these lacunae (and any others we will discover) will be fixed. These problems are certainly not blockers for selecting upstart as the default in jessie. So, to recap this and my previous mails and summarise: * upstart is simpler than systemd (which leads to fewer bugs, etc.) * upstart integration fits better into a daemon source code * upstart is easier to package for than systemd * upstart's community is much better to work with * systemd's non-portability is (for me) a near-blocker * upstart's remaining disadvantages are readily fixable SMOP * upstart is therefore ready for adoption in jessie * sysvinit has many longstanding bugs and deficiences * openrc is not ready (I couldn't evaluate it due to lack of a manual) I therefore conclude that the default init system for jessie should be upstart. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
