It's a bit unsettling that people in the open source community need to work on this particular thing, but it's unfair to blame them for that. There are plenty of init systems other than systemd, and plenty of desktop projects other than Gnome, but most of them don't require so much downstream work. The amount of time that has to be spent by downstream projects to make systemd useful for as many people as possible, and to make Gnome available to as many users as possible, says a lot about how these projects are developed, too.

What you've described also applies to Fedora. Fedora is community run and non-commercial. The results of the latest FESCO vote shows that. It is very much a volunteer-run distribution.

Yes, many Red Hatters have a personal interest in Fedora, and many others have professional interests. But nobody (from the Fedora community leadership) is going around selling it... :-)

> It's a bit unsettling that people in the open source community need to work on this particular thing, but it's unfair to blame them for that.

I think OP's point, coming from Fedora, is that the package maintainer (of say, apache-httpd) would need to ship unit files for all init systems and support them. The latter is a large task when you never use said alternative init system, especially if a drive-by contributor gave you the initial script. (And yes, you're free to ask for help, post on mailing lists, &c. but fundamentally it'd still come down to you, as the maintainer, to fix it).

At any rate, that's likely how Fedora would behave.

Source: Red Hatter and Fedora contributor.

True, but if you insist on persuing something that the consensus is uninterested in, you can end up maintaining your own personal fork.

Whether by consesus or fiat, every project of the size and complexity of Debian needs to make choices and live with them. Here, it appears to have chosen Systemd, while, in time-honored fashion, offerering the vague prospect of an alternative to blunt the opposition.

Adding code to one codebase isn't an "additional feature" if it means you can delete that code from half a dozen other codebases.

Horses for courses.

Is that really true, or is it just that some people have a grudge against systemd and sysvinit is the only other practical option?

On the other hand, systemd is too big, takes on too much responsibility (really I need a system to retrieve logs in it? or a way to run local dns?).

Since last update on my ubuntu desktop I can't get dns to work from DHCP, I need to overwrite /etc/resolv.conf with correct nameservers after each restart (BTW. Why would anyone think that running local DNS is a good default option - I see `nameserver 127.0.0.1` in the overwritten file).

And the second one on Debian on my laptop, when I run VPN (openconnect) name resolution fails, and I need again - ovewrite resolv.conf.

I didn't have such problems with sysvinit.

systemd is so controversial that I'm astonished why it is used in any distro.

It generally is, really. Resolving DNS servers are, for some reason, apparently much more difficult to run properly than authoritative ones. It's been a trend in many consulting gigs, where there are periodic outages due to reliance on some resolving DNS server somewhere that is overloaded, having a gray failure, or just generally down. It's also been a trend in basically every consumer ISP I've used over the past several decades - running my own resolving DNS servers has cut out on the outages I have experienced quite a lot.

I could probably achieve the same affect by just pointing everything at 4.2.2.1 or 8.8.8.8 or whatever, but I keep more control over my browsing habits by caching most results locally, have lower latency on lookups, etc. In large environments the gains can be even larger.

I prefer running more centralized resolving nameservers on the LAN for clients, but if you don't have that, then you're still gaining quite a bit running it on the local machine.

(and by no means am I a fan of systemd - I just think that this is a fairly sane default)

How do you encode service dependencies? If a service dies, what happens to services relying on it on your system?

Also, maybe I'm just lucky (or using popular hardware, or something), but services on my machine don't just randomly die for no reason. NetworkManager, sshd, etc all seem pretty well-written and stable.

It depends on the service in use and how is it defined. I have an embedded system in production, which have quite a complex graph of dependencies, some of which should be restarted on sudden death of others, some of which should persist anyways.

Needless to say that systemd provides an incredible, robust and easy way of solving that, I had to write just a few 10-line long unit files for in-house software and use standard units provided by standard daemons.

>imagine if systemd suddenly killed and restarted your browser

Because your browsed doesn't rely on them. But my web interface definitely depends on NetworkManager, because it speaks to it via d-bus.

Which is a good thing! Even though my browser uses/"depends on" audio, I still don't want systemd to restart it without warning if PulseAudio dies.

Check your VPN config, it should update systemd settings automatically when connecting/disconnecting.

> Is that really true

Yes

Why?

What is the appeal of writing immensely long, fragile shell scripts?

Having to wrap them in various monitoring and logging daemons

Having to have different ones for every distro you want to support with your software

Is this something that is truly a productive use of your time? Putting aside the question of if systemd is "good" or not. Is the current sysvinit system truly "good enough" and not in need of change?

Something having been used for decades certainly doesn't mean that it's optimal and shouldn't be changed, but it does strongly suggest that it's good enough.

For me it's relative and a case of "the devil I know". I actually prefer BSD-style init to sysvinit, but I've used the latter for ~20 years. I'm aware that traditional init systems may not meet the requirements of certain users (eg. those who run very large server installations), but for my simple use case (small servers and workstations) they do the job.

I'm not against change per se; I'm running Void (with runit) on one of my systems, and the desktop I'm using to post this runs OpenBSD.

Well, considering quite a few distros had already replaced sysvinit with upstart prior to systemd, obviously we have multiple options besides sysvinit. There's also options such as openrc, which will let you make use of whatever you want for pid 1, and manage services elsewhere.

In general, whether or not replacing systemd with something besides sysvinit/upstart is a practical option depends on how reliant you are on packages provided by an upstream distro or 3rd party. It isn't particularly hard to just swap init systems on several distros - debian included - but there are varying levels of tie-in with provided packages.

If you're building all of your required packages with a CI/CD pipeline and deploying with containers based on a minimal linux distro, you could relatively easily use a myriad of systemd and sysvinit alternatives. If you're just deploying on RHEL or Ubuntu VMs and doing yum/apt install to get your software, it's relatively more difficult.

Personally, I think sysvinit needs to be relegated to the annals of history. But I also have been bitten in production many times by systemd bugs, which due to the more... integrated... nature of systemd and it's components have been more trying to troubleshoot and have resulted in longer periods of problematic behavior, increased system level outages, and other headaches. Back when I worked with Solaris, I loved SMF - not so much the XML portion of it, but it worked well, was leaps and bounds ahead of sysvinit in usability in features, and didn't manage to induce nearly as many problems in my production environments as systemd has. And this isn't the first project I've wasted hundreds of hours of my life troubleshooting from the key systemd maintainers. My general experience with their projects has left the impression that they are not nearly as concerned at making their software bug-free as they are chasing features and use cases that interest them. Which is fine - they're welcome to write whatever software they want and prioritize things however they want.

My hope is that some other init system which recognizes the fact that it's no longer the 80s receives traction. Init scripts are awful, and no one should be writing them in this day and age, but I would prefer a system that only has a subset of systemd features but is instead focused on maintaining airtight code quality for those features. I don't need the vast majority of the features and services offered in today's systemd suite, and I don't want to suffer from the cost that all of those diversions extract on the core functionality. Crib the good parts, keep a high quality bar, and make sure a feature is likely to produce high positive impact before investigating resources in delivering it. Which is, I know, quite a lot to ask.

Yes, "horses for courses" as stated in the post you're replying to. I don't require systemd, but I have no problem with it existing for those who do need it. I do have a problem with the idea that something that works better for me should be removed merely because it's "old".

What do other init systems do that systemd doesn’t?

It might have had a controversial history, but it’s here to stay. Just deal with it.

Skip an opaque spaghetti-code declarative-to-imperative compilation step that I have to debug at 3am.

If they're script based, they allow lower level troubleshooting and modification without having to recompile.

systemd is written in a language that is easier than shell to get right, and it's capable of things very few script-based init systems are capable of, so in practice it's very rare that the code of the init system itself needs to be debugged. It's basically rock solid compared to sysv-rc.

You might regard C as easier than shell to get right (that's debateable), but systemd has many many more lines of source code than sysvinit. Good luck debugging it at source code level on a remote system if that "very rare" event occurs.

Going binary is like going back to Windows. If systemd was how Ubuntu worked 15 years ago, it's likely I wouldn't have seen the advantage and wouldn't have bothered switching.

[0] https://www.theregister.co.uk/2018/10/26/systemd_dhcpv6_rce/

> Founded August 1997; 22 years ago

It's not about dropping, it's about how much effort the invididual maintainer must put into a package to support sysvinit, with the answer now being "none". The burden of work is shifted to from the maintainer those wishing to support sysvinit (or any other alternative).

The non-systemd crowd wrote elogind in response to this. But of course, now elogind is in a situation like WordPerfect was with Microsoft Word back in the 90's -- trying to remain compatible with a moving target.

So the point of this vote is to answer the question: How does a package manager of a package like the "Gnome desktop" interact with the non-systemd crowd, when they want to depend on a new feature that's in logind but not in elogind?

Option F is basically, "The package manager says, 'systemd is our primary init system; we depend on systemd's logind period.'"

Option B is, "The package manager says, 'I'm making this dependency change. Hope you can manage to get elogind up to scratch before the release; otherwise your package will be broken, but that's not my problem.'"

Options D and H were variants on, "The non-systemd people have 6 months to get elogind up to parity with logind. Before 6 months, a breaking change would have to be reverted before release; after 6 months, a breaking change is allowed in a release."

Personally I think H was the best option; the fact is they're all actually quite close. 425 people voted, and the deltas between them are 22, 31, and 34. The community is really quite divided still.

Despite its editorialized name of "support portability without blocking progress", it had a mandatory 6-12 month waiting period before using any piece of new functionality, and the anti-systemd crowd has demonstrated repeatedly that they'll use any weapon to slow down systemd usage, which means in practice every single new mechanism or upgrade would likely have incurred a 12-month delay.

I think the winning option was optimal: it firmly says "if you want a non-systemd init to work you have to do all the work or convince (not force) others to help you". It means that if people materialize to do the work for a new init (whether a better-than-sysvinit alternative, or some future better-than-systemd alternative), they can do that work, and encourage (but not force) others to do the same.

So, if something comes along that people are excited about because it's actually better, or meaningfully different and not worse, nothing stops developers from rallying behind it and adding support for it.

The same sort of thing is exhibited by the pro-systemd crowd. Here's an example where a maintainer completely refused to engage with someone trying to fix a component required to work with non-systemd systems:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930869

And the issue I have with 'B' is that it doesn't actually do anything concrete to address this kind of behavior.

> Despite its editorialized name of "support portability without blocking progress", it had a mandatory 6-12 month waiting period before using any piece of new functionality

Debian only does a release every 2 years. If that number were set to '6 months', in practice what that would mean is that if you want to introduce a breaking dependency, you have to introduce it in the first 18 months of a release development, so that the other people in your community have some chance of getting things working before the release. That seems like a basic level of consideration and cooperation.

[Minor edits for clarity.]

I wasn't commenting on that here one way or another. I was observing that this would hand one crowd a new weapon, in the form of a mandatory 6-12 month delay.

(In general, I think the vast majority of the pro-systemd crowd is not interested in actively killing alternatives; they're just interested in actually using features that other alternatives don't have. Problems and disputes certainly happen, as well as people getting frustrated or burnt out trying to deal with the constant battles, as well as people just trying to get things done.)

(I also think many of the anti-systemd crowd is just interested in trying to maintain what they care about, but that in practice it's become evident that "keep up" would require than the available development resources, while the far more acrimonious "slow others down" requires less. I suspect it's a survival/threat response, but that still doesn't make it the right one.)

> Debian only does a release every 2 years.

Many people run the testing or unstable distributions. And in any case, that's not the issue here:

> If that number were set to '6 months', in practice what that would mean is that if you want to introduce a breaking dependency, you have to introduce it in the first 18 months of a release development,

That's not what that proposal said. What it said was that if you want to use any new feature, you'd have to ask first, document it in Policy first (which is not the norm, usually Policy follows experimentation and documents what has become existing practice), make sure it's something that could theoretically work not just on non-systemd but also on non-Linux, then wait "at least 6 months, preferably at least 12 months" to see if someone bothers to make an alternative implementation, before you can actually use it. And any further enhancement to such a mechanism needs another 6-12 months.

That might have sounded reasonable to the developers of software like sysvinit that doesn't actually change anymore, and is mostly in permanent maintenance mode with its current set of features. It doesn't sound at all reasonable regarding actively developed software.

Right, but the problem is, as you say, there's the "unreasonable" 5-10% on both sides that are using "tactics" to block the other agenda and push their own. Option 'B' basically gives all the power to the pro-systemd crowd, because there's no real mechanism to force a stubborn maintainer to even review a patch tweaking things to work without systemd, much less accept it.

Option 'H', it appears to me to be trying to balance things, such that neither side can actually block things for long. I think that's a much better goal to aim for.

(The text of proposal H is at [1] for those following along.)

> That might have sounded reasonable to the developers of software like sysvinit that doesn't actually change anymore, and is mostly in permanent maintenance mode with its current set of features. It doesn't sound at all reasonable regarding actively developed software.

I'm involved in "actively developing" software, and often come across interfaces that I'd like to just throw away and start over; but instead, we have to make a plan to deprecate the old interface over the course of line 10 years.

That's because systems software is all about compatibility. If you wanted to be able to throw everything away every 6 months you should be writing Javascript.

In any case, look at the votes. Of the 425 people who voted, 116 people favored "Support for multiple init systems is Required" over "Focus on systemd"; and most people voted in favor of some option that allows for init system diversity. Diversity of init systems is clearly important to the community as a whole. It seems to me then that guidelines need to be put in place to prevent extremists on either side from imposing their will on the whole community.

> Many people run the testing or unstable distributions.

Indeed, and many of those people want to be able to not run systemd, for a variety of reasons; and most of the community want to accommodate them, at least at some level.

> That's not what that proposal said. What it said was that if you want to use any new feature, you'd have to ask first, document it in Policy first...

That procedure is in a section which specifically says it's about:

> For example, creating system users or temporary directories. Current Debian approaches are often based on debhelper scripts.

That looks to me like it's not about a dependency on random shiny new features; it's about replacing some core Debian functionality with systemd functionality, in a way which affects all users of the system. Given that system diversity, at least at a basic level, is the goal for most Debian maintainers, doesn't it make sense that such a change should be taken carefully?

So you seem to acknowledge that there are people on both sides unreasonably using procedural quirks to impose their view on the majority.

'H' seems to me very balanced in that regards. You seem to think it's skewed too far towards the non-systemd people. How would you tweak it to make it more balanced?

[1] https://lists.debian.org/debian-vote/2019/11/msg00163.html

> So you seem to acknowledge that there are people on both sides unreasonably using procedural quirks to impose their view on the majority.

No, I just didn't want to derail the discussion in that direction; my original post was, in isolation, a statement of a problem with proposal H that made it unacceptable to me. That statement is not invalidated with "but the other side ..." arguments.

But since the topic has come up: There are definitely people who favor systemd and say things like "could we just kill sysvinit already", but words aside, I don't see substantial actions that gratuitously hurt sysvinit, rather than just side effects of using things that sysvinit doesn't support. Instead, I see many people just getting their work done by making other software better, and thus as a side effect causing alternatives to fall further behind.

Nobody set out to say "let's make GNOME work exclusively on systemd". They built atop features that systemd had and sysvinit didn't.

When you're trying to stay in permanent maintenance mode, someone doing active development looks like a threat. And when you have a much smaller and community, sometimes most of the people you have left are the extremists.

An interesting alternative to systemd doesn't look like sysvinit, it looks like a better and different solution to people's problems. The proposal that won leaves room for that to happen someday, while not slowing down active development. There'd be some very different conversations going on if, for instance, people were proposing runit as an alternative rather than raw sysvinit, or proposing an inittab.d directory and some helper programs that make inittab.d support inetd-style daemons, or otherwise asking people to include four lines of code to support an alternative rather than hundreds of lines.

> I'm involved in "actively developing" software, and often come across interfaces that I'd like to just throw away and start over; but instead, we have to make a plan to deprecate the old interface over the course of line 10 years.

Nobody's talking about throwing away interfaces and breaking compatibility. On the contrary, systemd still supports init scripts. What we're talking about is not continuing to use the old interface forever because people want to run software that will never support the new interface.

To use an analogy to SONAMEs: a new version of a library can introduce new interfaces without breaking the old ones, that new version will have the same SONAME, and code using the old interfaces will run on the new library, but code using that library's new interfaces won't run on the old library. And that's perfectly acceptable; that allows both sides of an interface to evolve together.

> That's because systems software is all about compatibility. If you wanted to be able to throw everything away every 6 months you should be writing Javascript.

1) See above.

2) There's no need for gratuitous insults or contempt culture here. Discussions on this topic already descend into flamewars very easily, let's not push them in that direction.

3) Javascript is still an environment where people have to care deeply about compatibility, both in the provision of interfaces (making sure old Javascript still runs) and in the use of them (making sure multiple browsers work).

4) I work entirely on systems software, and one of the things that happens regularly is introducing and using new interfaces, while carefully preserving compatibility with old interfaces.

> Option 'B' basically gives all the power to the pro-systemd crowd, because there's no real mechanism to force a stubborn maintainer to even review a patch tweaking things to work without systemd, much less accept it.

First of all, there are already such mechanisms, including the technical committee if it comes to that. But I personally don't think it needs to come to that.

If you're approaching this from a mindset of "force a stubborn maintainer", perhaps rethink your mindset. The whole point of option B is that we're not going to force maintainers to work on things they don't have any interest in. So, perhaps show that you can provide compatibility in a minimally invasive way. Perhaps convince a maintainer that you'd be happy to co-maintain the package to handle those bits. And perhaps don't cultivate the kind of personality that makes people want to ignore an entire email thread when they see your name (https://joeyh.name/blog/entry/thread_patterns/), so that people actually want to work with you.

Architectures have a similar tension. Debian supports many different target architectures, and that sometimes requires patching software to help it run on other architectures. People who care about the architecture help write those patches, people who maintain packages include those patches, and Debian occasionally has to decide which architectures are viable for release. There are occasional packages that only run on certain architectures. But for the most part, packages tend to run on every architecture, and architectures don't generate flamewars nearly as often.

But if an architecture came along that, say, didn't support something fundamental like mmap (such targets do exist), and the maintainers of that architecture wanted every package in Debian to do the work to support systems without mmap, that doesn't seem especially likely. In terms of invasiveness, I think that seems more analogous to the work required to support sysvinit.

> In any case, look at the votes.

I did. Per https://vote.debian.org/~secretary/gr_initsystems/ , "Support for multiple init systems is Required" resoundingly lost (below even "Further Discussion"), "Support for multiple init systems is Important" lost to everything else, and all the options submitted by anti-systemd folks lost to all the systemd options. The option that won is the one that allows for something better to come along in the future, which I think is exactly the right balance.

> clearly important to the community as a whole.

The vote demonstrates what is important to the community as a whole. It's a vote for "no, we won't slow down or stand still, but other alternatives are welcome to keep up".

> It seems to me then that guidelines need to be put in place to prevent extremists on either side from imposing their will on the whole community.

Such guidelines were put in place. Nobody on either side is in a position to impose their will on the whole community. The problem is that one side did want the ability to impose their will on the whole community.

> That procedure is in a section which specifically says it's about:

> > For example, creating system users or temporary directories. Current Debian approaches are often based on debhelper scripts.

> That looks to me like it's not about a dependency on random shiny new features; it's about replacing some core Debian functionality with systemd functionality, in a way which affects all users of the system.

Remember that the proposal you're quoting was written by sysvinit folks. It only mentions a couple of minor features of systemd that the sysvinit folks are pretty sure they can implement.

I wrote a mail last month with a long list of systemd features people may want to use, along with many of the same points from this discussion: https://lists.debian.org/debian-devel/2019/10/msg00346.html . Please see that whole mail.

Please also see the note in that mail: I'm not trying to say "we should wholeheartedly adopt every one of these technologies"; [...] The issue is that we don't even have the option of considering most of these technologies in the current environment. Even if Policy changed tomorrow to have a full "unless you're using capabilities that alternate init systems don't have" clause, people would still be afraid of using those capabilities or merging patches that do so, lest their work become the subject of a giant flamewar. We should get to a state where people building something interesting using these capabilities and technologies can expect useful feedback, and potentially excitement and collaboration, rather than flames.

I think we need to move past the framing of "people don't want to write init scripts"; this is also about being unable to use a decade of additional capabilities that go far beyond sysvinit.

The net result of the decision years ago was, effectively, "we can use systemd as 'a better sysvinit', but we can't use any capabilities that go substantially beyond sysvinit".

The net result of the decision today is that people can finally start considering the use of capabilities that systemd has, without worrying about the next flamewar.

> doesn't it make sense that such a change should be taken carefully?

Are you under the impression that such a change won't be taken carefully? Such a change just won't be vetoed on the basis of "but sysvinit doesn't have that feature". That doesn't mean that every single feature will be adopted without due consideration.

Debian is typically very careful about compatibility and stability, and holds those as primary virtues, and I have confidence in Debian's continued ability to do so.

> 'H' seems to me very balanced in that regards. You seem to think it's skewed too far towards the non-systemd people. How would you tweak it to make it more balanced?

I have no interest in relitigating this vote. The option that won is the one I consider the correct balance. Rather than handing one group power over the other, it simply says that everyone is free to work on what they want to work on, and to convince others to join them, without giving any special treatment or veto power to sysvinit.

Considering the small minority of Linux installations on desktops and laptops (compared to servers and other network infrastructure), and the fact that only some of those will be using Gnome, I think this has been overemphasised. It's unfortunate that a minority has dictated policy for everyone else.

Having said that, I think Debian has made a rational decision. It would be unreasonable to expect package maintainers to provide multiple sets of init scripts due to the extra work. (FWIW I've used Debian for ~20 years and still use sysvinit).

Good programming practice is to make it easy to change components like that, and doing it also helps testing. In theory it should just be a matter of replacing a few components to get gnome running without systemd, depending on how hard coupled those are.

Thus has been showcased that it is possible and there's no reason why this shouldn't be a separate library in first place according to all those great UNIX and programming philosophical motto out there.

I would say categorizing systemd as "general bloat" is not entirely fair - I would say it is far more stable and easier to debug and fix (with the proverbial rusty hairclip) than debian's sysv init mess was last I looked at it and I would say systemd is actually quite lean both in absolute size, resource consumption and complexity.

I find it easier to debug and edit shell scripts than wade through large amounts of C code (and possibly recompile) in the event of a problem that can't be fixed by a simple reconfiguration. I guess it depends on what you're used to.

Specifically a problem that couldn't be fixed by changing systemd unit files?

(I don't mean for this to sound in bad faith; I'm genuinely curious as a user of systemd)

General statement.

It doesn’t work with Juniper routers that many large ISP providers use.

So I resort to ISC DHCP and its flexible DHCP OPTIONS.

1. It's not relating to the service manager part of systemd. It sounds like a problem with systemd-networkd which is a component that is entirely optional and easily replaced even on a systemd-based system (as you admit yourself).

2. The original question was about bugs in systemd that require inspecting C code where the equivalent bug on a non-systemd system could be diagnosed by inspecting shell scripts. ISC DHCP is not written in shell script.

> A,B,F (#3,2,1)

> Maintainers do not have to write them and do not need to accept them.

* https://diziet.dreamwidth.org/3999.html

Maintainers were failing to fix bugs in their init scripts, or even ship init scripts for critical services. The resolution was about trying to force them to include a very small shell script to do the job, and they balked.

There are a frightening number of maintainers who couldn't write a bash script to save their job, and even more maintainers who don't actually use or understand the package they are responsible for.

I suspect the long term damage here is going to be embedded and all the little projects that base off Debian.