A couple of details for those who did not follow the discussion and are not familiar with Debian's voting system:
* Proposal E "Support for multiple init systems is Required" has been firmly rejected. (In the Debian voting system, rating an option worse than "Further discussion" effectively means considering it even unworthy of being in the ballot.)
* The core of Proposal B is «The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work». The full text can be found at https://www.debian.org/vote/2019/vote_002#textb
* In case the message were not clear enough, the runner up option is Proposal E "Focus on systemd". Proposal E is also the most voted option.
> the runner up option is Proposal F "Focus on systemd". Proposal F is also the most voted option.
I'd say that in this voting system a statment like that is not really important
in any way. You'd have to compare it to sum of options that don't focus on
systemd as an example or some other combinations.
No. As anyone who wants to not to focus on systemd would vote each such proposal over "focus on systemd", having Proposal F be above them all means that the sum of people voting them is less than the sum of people voting for Proposal F.
The strength of the Condorcet method is precisely that adding a new option cannot make an existing option beat another existing option. That is, there is no vote splitting.
But Proposal F is very clearly NOT above them all. 207 people preferred B over F, while only 185 people preferred F over B.
If F were above them all, it would be the Condorcet winner and hence would have necessarily won according to the Schulze method, which it didn't.
B actually is the Condorcet winner, as it would beat every single other option in a one-to-one contest. (The fact that B is the winner according to the Schulze method doesn't necessarily imply that it is the Condorcet winner, as there might not be a Condorcet winner.)
F being the "most voted option" is a misleading and mostly vacuous statement. All that can be said is that more people preferred F to "further discussion" (303 vs. 110), than preferred any other option to "further discussion". In particular, only 299 vs. 111 preferred B to "further discussion". However that has no bearing whatsoever on whether people preferred F over B.
(My theory for why B didn't beat "further discussion" by quite such a large margin as F did, is that in the case of B both the only-systemd "extremists" and the anti-systemd "extremists" preferred "further discussion" to B, while in the case of F only the anti-systemd "extremists" preferred "further discussion" to F.)
I don’t think so. Looking at the most voted option tells you what the majority thinks. The voting system is designed to promote a most agreeable resolution not simply the majority’s choice, but knowing what the majority wants is still interesting.
> knowing what the majority wants is still interesting.
Totally agree.
> Looking at the most voted option tells you what the majority thinks.
My point is that the options are designed specifically for this type of voting system.
Here it is possible that anti-systemd votes are spread across many options and pro systemd votes are concentrated in only one or two. So even if you have most votes on "Focus on systemd" it doesn't mean that it is what most people want.
> Here it is possible that anti-systemd votes are spread across many options and pro systemd votes are concentrated in only one or two. So even if you have most votes on "Focus on systemd" it doesn't mean that it is what most people want.
As I said in my above reply which you've ignored, that is not how the voting system works. It is not possible to split votes like that in Condorcet. Everyone who opposes systemd can vote for all of the non-systemd options and not diminish the chances of any of them.
The ballot allows you to place all the options you support, in any order you prefer. Let's say I really oppose systemd and want it to lose. I could have voted:
Option 6
Option 3
Option 5
Option 4
Option 7
Option 8 (FD)
This would show on the majority vote as a vote for all of {63547}, and a vote against {12}. Vote splitting is not possible, even in the majority vote section.
The result of the "majority vote" is done preferentially, which means that there is no situation in which vote splitting will occur. It makes no sense to refer to the "majority vote" in this context, because the whole point of preferential voting systems is that (usually) no option wins outright on first preferences alone. Thus the result of the Condorcet vote is the order which the maximum number of people would've been most happy with.
Yes I should have put “majority” in quotes. I was trying to use it in the way the post I was replying to used it which is more accurately as you describe.
> Looking at the most voted option tells you what the majority thinks.
No it doesn't. (At least not with the definition of "most voted option" that was used by gioele.)
B would beat F in a one-to-one contest, so the majority thinks that "Systemd but we support exploring alternatives" is preferable to "Focus on systemd".
Our reasons for doing this are we run stripped-down systems that go for years (even decades), but which we absolutely must be able to fix ourselves with the proverbial rusty hairclip. The general bloat of linux distros (due to gnome/systemd and others) really doesn't suit our use case (although obviously it suits others, even the majority).
I hope it does involve removing sysvinit. Compared to alternatives like runit or s6, sysvinit increases bloat (because every service needs to include it's own daemonising and logging code) and makes systems brittle and difficult to debug (because the classic daemonisation process is subtle and easy to get wrong). If I had to build a stripped-down, ultra-stable, long-running system, I definitely wouldn't want to build it on sysvinit.
Indeed! Comming from Fedora, I can't really imagine the overhead maintaining two sets of init files would bring. Such a waste of already scarse maintainer resources.
Debian is a volunteer project. It's not a commercial enterprise. Volunteers work on whatever they think is worth their time and whatever they think it benefits them and their users. It's not a "waste" of "maintainer resources". "Resources" don't get bossed around in a community project.
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.
> Debian is a volunteer project. It's not a commercial enterprise. Volunteers work on whatever they think is worth their time and whatever they think it benefits them and their users.
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.
You can be a volunteer project and still strive for having uniformity across packages in your project. The fact that you're volunteering doesn't mean you get to do whatever you want. That's exactly the reason Debian holds such votes.
> "Resources" don't get bossed around in a community project.
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.
As a Fedora user myself as well, this indeed seems like a massive waste; I can see the point of different distros having different init systems (i.e. Devuan for SysV init, Debian for systemd, Alpine for openrc, ...) but multiple init systems per distro are just unnecessary and hinder true innovation IMHO.
Every POSIX service needs to be daemonised, write logs, etc. The question is, do you have one bullet-proof implementation in the service-manager, or do you have N independent and less-tested implementations in the N managed services?
Adding code to one codebase isn't an "additional feature" if it means you can delete that code from half a dozen other codebases.
That's true but what we're hoping for is that Debian doesn't change things so much that sysvinit is unusable. Systemd does have its advantages but some people _like_ sysvinit.
sysvinit is simple, and I didn't have any major issues with it.
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.
>BTW. Why would anyone think that running local DNS is a good default option
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)
At least on my desktop machine, there aren't a whole lot of services that directly depend on other services. Usually, a service will provide some functionality (e.g. sound) used by applications I launch. As far as I know, systemd doesn't help with that, and I don't really want it to--imagine if systemd suddenly killed and restarted your browser!
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.
To clarify, by "systemd doesn't help with that", I meant "systemd does not attempt to manage, track service dependencies of, or restart applications I launch through my desktop's Applications menu or in a Terminal window".
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.
Your browser can encode that it doesn't have to restart if pulse dies. Wants= will try to ensure Pulse is started but if Pulse cannot start or crashes, that's fine. Requires= will ensure pulse is started but doesn't do anything if it crashes. Only BindsTo= will stop the browser if pulse crashes.
Regarding VPN, you probably have your VPN config wrong.
Either you want it to use a DNS server on the remote network (connecting to a LAN at the office for example) or not.
Check your VPN config, it should update systemd settings automatically when connecting/disconnecting.
Forgive me if it sounds like I'm trying to bait into an argument, but
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?
> 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.
> Is the current sysvinit system truly "good enough" and not in need of change?
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.
>Is that really true, or is it just that some people have a grudge against systemd and sysvinit is the only other practical option?
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.
> Systemd can do things that were not relevant 20 years ago.
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".
I think the the controversy is the other way around, systemd does a lot of things the others didn't. People wanted all those responsibilitys modularized.
Because the Linux community is not made up of product managers. It's full of software developers each who thinks their way is the best. Distros, maintainers and users will always be fighting political battles.
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.
> systemd is written in a language that is easier than shell to get right
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.
Even more massively to me, this was a very low barrier for entry for beginners who want to learn how everything works. It was a major point in favor of Ubuntu, coming from Windows, when I started experimenting bit over a decade ago.
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.
Possibly the IPv6 packet one, CVE-2018-15688? [0] A basic buffer overflow in systemd meant oversized network packets could be used for DoS or "potential code execution".
https://nvd.nist.gov/vuln/detail/CVE-2017-15908 says this is a infinite loop DoS in systemd-resolved, so it can't be the (hypothetical) bug described by the GP since it's neither a RCE nor in systemd PID1.
In this case, telecomms hardware (there may be older systems out there that are off support). Uptimes are often into years; we used to have systems that would run in 8Mb of RAM though the oldest I know of now has 32Mb :)
Its quite possible that for systems that old, there are no updates even available. Its also possible the systems have no route to the internet, which while not making them immune from compromise, certainly makes it more difficult.
Security patches don't necessarily affect uptime. For example, patching and replacing e.g. libc on a live system is entirely possible, even though it's not the standard procedure.
> I hope that "exploring alternatives" isn't code for dropping sysvinit.
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).
That's probably for the best. Writing init scripts is easy enough for that small percentage of users (like gp) who really need it. Good choice on Debian's part, imho.
The issue isn't actually so much about writing init scripts, as about all the other bits of functionality that systemd has been aquiring. One example apparently is logind. Important key packages have (as I understand it) started depending on functionality provided by logind; I think something like "Gnome Desktop". Which would mean, if you want to run Debian with Gnome, you have to run systemd.
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 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.
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:
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.
> The same sort of thing is described on the pro-systemd crowd.
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.
> 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.
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?
> 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.
> 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.
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).
I am not sure how much power Debian have if projects start to depend on systemd outside of initialization. Things like socket handoff, service discovery, logging and so on is choices of upstream and can be quite convenient depend on which ever third party library that is most common in use.
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.
Most of elogind code is taken out of systemd and living standalone, even following systemd version.
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.
> The general bloat of linux distros (due to gnome/systemd and others)
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.
> 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
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.
Do you have an example of a situation where a problem in systemd required you to patch the source and recompile, or are you just making a general statement?
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)
> Do you have an example of a situation where a problem in systemd required you to patch the source and recompile, or are you just making a general statement?
You could use that argument and say do you need to look at all the code for the dozen shell programs you're calling in that init file to diagnose problems.
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.
It's basically saying that nothing is changing. 'Exploring alternatives' is a nebulous phrase that says they're sticking with the status quo and keeps the options open but doesn't commit anyone to actually doing anything.
Hum, not exactly : It assesses that those interested in having other init working for a package where that support is not directly provided by upstream nor the maintainer can do the work themselves and they will get the community's help by having their patches reviewed and discussed in a timely manner. Which was not a given.
Only Patch "reviewing" is guaranteed, not patch acceptance.
Reviewing and discussion were not a given before this vote. This proposition at least ensure that. The maintainer will not be forced to accept patches that he deems unfit just for the sake of supporting other init systems though.
"exploring alternatives" absolutely means dropping support for sysvinit in many cases, which is what was already happening.
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.
This is considered one of the most democratic systems, it tries to make sure that the preferences of most voters are met in an optimal way.
However, I would claim that with a list of 8 options it is close to impossible for a human to come up with a stable ordering. If you were to vote 3 times or 5 times without being allowed to look at your previous ballot sheets, how much would the votes change?
Is that stability actually an issue? It would seem to indicate that the voter has no strong preference for the items that they could not remember how to order consistently, and so either outcome would be roughly equally acceptable to them.
It could mean that in a close vote like this, the result was due to random chance and not the will of voters. This does happen in fptp as well but not to this extreme.
Schulze requires only a weak order of your votes: you can say that you like options B and C better than D, E, and F, but not prefer B over C or C over B. This is going to be an easier way to reflect your inner vote preference, because instability of votes is likely to be a result of choosing arbitrary orders for different tranches--and Schulze doesn't require you to pick that order.
You are correct. The voter has the option to lead options unranked or rank several ones equally. So it's easier than having to come up with a complete ordering. Still, I would expect than many voters would come up with slightly different ballot sheets when having to do it several times. Did I give these 3 or 4 options the same low rank? Even if not required most Debian voters seem to give complete orderings https://www.debian.org/vote/2019/vote_001_tally.txt in "normal" elections. In this complicated systemd voting less so https://vote.debian.org/~secretary/gr_initsystems/tally.txt
I disagree with the assertion that "no one can count all those different orderings by hand".
To steelman a bit, let's consider a worst-case brute force manual tabulation of the results (there certainly may be more efficient ways to do it by hand than what I write here):
On a ranked ballot with 8 proposals, there's effectively (8 * 7)=56 binary options (do you prefer A over B, do you prefer B over A, do you prefer A over C, etc.)
In this vote, there were 452 valid ballots. 452 * 56 = 25,312 individual data points to tabulate, into a 8x8 matrix of results. If reading an individual result off a ballot and counting it takes a person 1-10 seconds, the entire tabulation would take 7-70 person-hours.
With that 8x8 matrix of individual results tabulated, determining the Condorcet winner (or the members of the Schulze set, if there's no Condorcet winner), takes less than 1 person-hour, by hand.
Now, that's certainly not an instantaneous result, but it's certainly within the realm of feasibility for a completely non-electronic election or referendum.
As another way of sanity-checking, consider that major elections in the U.S. often involve a combination of local, state, and federal ballots that can have upwards of 30 individual questions in total, and millions of ballots are cast, and results are typically certified within a fairly short timeframe.
It offline's certainly the case that an all-electronic vote is faster, more convenient, and that this lower cost can also allow for more proposals on the ballot, and more frequent and more granular elections, but I'd say it's a far cray from being "absolutely dependent on electronic vote".
That wasn't the point of GP's comment. Of course you only have one round of voting. Their point was, if you have 8 options and you don't really care for most of them (i.e. only the ordering of the first two or three matters to you) than the ordering of the options you don't care for won't carry much significance to the single voters (so they may order them randomly or leave them in the order they are presented), but it can matter in the end results.
(I hope what I mean is clear, if not feel free to push me for clarification)
Intentionally or not you've performed a little bit of sleight of hand. At first our voter doesn't care which of "most of them" gets chosen, they've no preference. Then one of these gets picked and "it can matter".
But it doesn't matter to the voter we're thinking about at all. The people "it can matter" for thought hard about this option because it mattered to them by definition, and so their sincere preference was incorporated into the decision.
By smuggling their preference back in as a concealed preference of other voters who didn't actually care, you inflate their position. If I say I don't care between Pizza and Burgers, and then Burgers win, you don't get to count me as a secret supporter of your "Let's eat these stale Doritos I found" faction just because you feel my support of Burgers ought not to really count.
Choice 2: B: Systemd but we support exploring alternatives
Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus.
The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include.
Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative.
>It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner.
This part directly addresses the current issue; people were just ignoring those that were working to make non-systemd debian possible and were refusing to even talk about the issue. It will be interesting to see what happens now if those people continue to behave in the same way.
So this actually ends up being a victory for the non-systemd faction, at least in a political sense.
- systemd supporters are mainly desktop users, so their opinions are irrelevant because as a desktop user the only thing you might do is restart a service, is important to listen to server admins that know what they are talking about
- GNOME (other Red Hat tech) depends on a systemd component and refuses patches to make it independent, so basically GNOME is forcing systemd adoption and is trying to block alternatives by refusing patches
- systemd projects and fans will ask you to create a better alternative to systemd if you don't like it, but if you try to promote an alternative they will try to block the alternatives by refusing to accept patches to keep projects systemd independent.
Monoclultures are bad, when systemd will o longer be popular and we want to implement a better succesor we will discover that many things are hard coded to depend on some it's many components.
About what is the best init system, I don't know , I am desktop user, and as I said all desktop users opinions are probably "it works for me so you are wrong"
> is important to listen to server admins that know what they are talking about
Huh?
I got on the systemd train when race conditions with pidfiles caused essential services not to restart correctly for the umpteenth time on a small subset of the thousands of bare metal servers I managed.
Not a single sysadmin I worked with liked anything about sysvinit. Nearly every distro-provided init script for the services we cared about had some sort of subtle bug which we had to manually fix with our configuration management.
Or maybe somebody had been diagnosing an issue and manually run “sudo /etc/init.d/someservice start” and now congratulations, the service inherited the cwd of the person who ran the init script.
Or you have to deal with inconsistent log rotation behavior, or the service coming up before the network was ready on boot (better rename the symlink to 99_myservice!)
I don’t know where people get the idea that sysadmins prefer sysvinit. Maybe ones that only run one or two servers? After having managed tens of thousands of them across many datacenters, systemd is a clear and obvious win.
I am not saying that all/most sysadmins hate systemd , I am just annoyed but the random Joe Desktop Linux users throwing his opinion. I like reading sysadmin experience and what issues they have like you but also ones that had issues with systemd bugs and behavior and a random Fedora user will show up and repeat something he has no clue about.
I personally had no issue with systemd or upstart or any other I used so I would wish desktop user like me would read more and comment less about what is better.
Are the uninformed opinions of joe user really influencing decision makers? The internet is mostly filled with people spouting uninformed opinions, it does not seem worth it to spend any energy caring about it.
I don't think the decisions made in Debian were influenced a lot by the average joe user, my complaint is about the discussions, my complaint is that say if I find a thread that compares all the init systems I would prefer to read expert opinions on it, people that had success with systemd but also people that had trouble with systemd , but you get average joe pasting same shit all the time on both sides.
But yeah you are right(this always happens on the internet), I was also guilty of this, I remember back when C# appeared and I was sure is the best thing ever and it will soon replace all the other languages. I think at my past enthusiasm for C# when I see Rust/Go/CoolLang evangelizing why X is better and in 3 years it will dominate.
My problem with systemd is that it is not just a init system. It goes further than that and it exposes apis that third parties use. It is tempting to use systemd functionality as developer, but then you are no longer portable to bsd, darwin or other systems. I think systemd is bad because it will break links between the various unixes.
That being said, as system administrator, I found systemd mostly to be ok, but sometimes you run in non reproducable problems. I have sometimes that servers don't come up, because the network unit didn't get started. Restarting fixes it. I haven't been able to reproduce it and the logs are also not very helpful.
I don't know.. your application can and should be portable.. But if you want to support systemd, sysvinit, launchd, windows-services or whatever, that's up to you. It's this tiny part where you need to commit to some piece of technology.
I don't see the difference between creating a systemd config file, which is super clear and managed properly and to create a bunch of init scripts that depend on pid-files which might be stale and where those directories are abitrary.
If I understand correctly, GP is saying that systemd also provides non-init-related functionality.
If a package you develop relies on only systemd's init capabilities, it'd probably be pretty straightforward for someone to port it to an OS with a different init system (like BSD). If your package relies on other systemd capabilities, though, the task of porting gets much harder.
> If your package relies on other systemd capabilities
Such as? Which other "systemd capability" besides the init system part exposes an API to general user-space applications? The only one I can think of is logind, for which an alternative implementation (elogind) exists.
It depends on a systemd API and there is an independent implementation, elogind. GNOME runs just fine in the BSDs, so its dependency on systemd is a strawman.
I only use linux on servers, and have been doing that since I used redhat and slack in the '90s. After that I moved to FreeBSD and since about 15 years, I'm on Debian.
sysvinit scripts are horrible to create and operate. It's easy to set tup dependencies for network or other services. I haven't used it to run cron-like tasks, or inetd-type servers, but I don't have a need for that.
- login (replacing login managers such as ConsoleKit)
- network configuration
- tmpfiles
- timedated (replacing ntpd)
- udev (userspace /dev manager)
- boot (replacing boot managers like grub)
As you can see, systemd has taken over a great many things that are totally unrelated to its core mission of replacing sysvinit. The fact that it continues to grow and take over all these other facilities and the fact that the systemd team actively fights people trying to develop alternatives is why people hate the project so much.
I see we've reached the point in any systemd-related debate where someone tries to claim systemd is bloated by listing off projects that are not part of the systemd init system and just happen to share a common name and dev team.
The problem isn't the common name, it's the tight coupling between components. This is antithetical to the Linux philosophy, which emphasizes modularity, interchangeability, and configurability.
I assume you mean the UNIX philosophy? Regardless, almost all of said components are optional, systemd doesn't in any way force you to use them. As a matter of fact many of the components you listed have alternatives that are more popular than the systemd tool (NetworkManager over systemd-networkd, GRUB2 over systemd-boot, etc).
Most yes, not all of them.
For example logind. Is there any reason why this should be coupled with systemd?
Apparently not as has been proved by elogind project.
+1. I don't know about the big picture, but as a user, systemd is just damn convenient. I don't want to have to code every single little daemon I need in shell scripts. systemd handles most of that so neatly.
1. the infamous "a start/stop job is running" message.
2. Some services just won't start at boot. E.g. reproducible ntpd on CentOS 7
3. Sometimes my notebook, running Debian with systemd, won't shut down an I had to shut it down hard by ling pressing the power button.
Never had this kinds of problems with any other init systems.
The ballot graph looks a bit strange to me. For one, votes seemed to come in all the way through the voting period, and actually increased just before the deadline. For two, nearly 20% of the ballots -- 100 out of 550 were rejected. I hope that's not evidence of "voting irregularities" -- the top 4 options were all within 50 points of each other.
EDIT: From the bottom of the page: "Most of the bad ballots are due to the presence of a non printing character (usually one that displays as a space) in the ballot that confuses the parser. "
> From the bottom of the page: "Most of the bad ballots are due to the presence of a non printing character (usually one that displays as a space) in the ballot that confuses the parser."
Note that "Bad Ballot" is a specific category, with just seven such ballots counted in this vote, not 100.
The dozens that were rejected much earlier failed GPG signature checks, which means _anybody_ might have sent those because if they had a signature from a Debian Developer it wasn't valid. I could have sent one (I am not a Debian Developer). I could have sent thousands of them!
Most commonly what's going on is that somebody screwed up and either tries again soon after or reaches out to friends to ask er, wait, how do I do this routine voting thing again? I'd not be astonished if at least one person managed to screw up and not vote, but I would be shocked if it's enough people to actually matter. And I'd also question what the point is of being a "Debian Developer" if you can't follow the relatively simple instructions to vote.
In say a General Election we have to cater for the widest possible demographic. For example in England the rules say that any "unambiguous" vote counts. The instructions say to put an X in a box, but if you use a tick, that's fine. If you ignore the boxes and write in block caps "I vote for Steve Smith to be our MP" that's still fine (assuming Steve was a candidate in this election) because everybody can see you wanted Steve. If you cross out two of five candidates, circle two others and draw a smiley face... we can't tell who you wanted, sorry, invalid ballot. But that's because we're trying to capture _every voter_ so it would defeat the purpose of the poll to insist upon technical competence by voters. Debian isn't trying to do that, quite rightly.
> For two, nearly 20% of the ballots -- 100 out of 550 were rejected.
Of 552 ballots receieved, 548 passed "MIME Decoded" and 459 passed "Sig Check", with 452 Votes Tallied and 7 Bad Ballot - so, the vast majority of the failed ballots had invalid GPG signatures.
This data doesn't tell you how many of the valid ballots were re-sends from voters who had previously sent in an invalid ballot.
Note that you get an e-mail either saying that your vote was accepted, or that your vote was rejected and why (bad GPG signature, unrecognized GPG key, mangled ballot, etc.)
So if someone screws up, they know and can resend.
Also, you're allowed to send in a second ballot which supersedes your previous ballot, up until the deadline. So if you change your mind during the voting period, you can update your selection.
> For one, votes seemed to come in all the way through the voting period, and actually increased just before the deadline.
That doesn't seem surprising at all; many people vote (and rally others to vote) just under the wire. The same pattern appears in conference submission graphs; there's always a huge number of submissions on the last day.
Wow. If 20% of the ballots are rejected in our next election due to some invisible garbage, the opposition and Western media will cry "they stopped even pretending to count the actual votes".
Seriously, opinion on systemd and choice of software used to fill the ballot seem likely to be correlated.
I think the question was, why does the tool show the non-truncated value for that one line, considering it put the truncated (%0.03f) version right next to it.
dvt-rslt:367-368 the ratio is interpolated into the string output without any format specification (resulting in the full decimal expansion), whereas in the passing case (line 382) it is not.
The ratio is formatted with %6.3f in both cases (369-372, 384-387).
That's what it does. Doesn't tell us why (though it looks like a simple oversight on the programmer's part).
Just for fun, I had a look. The commit which adds the non-truncated print changed some behaviour with regard to < vs <=, so it might have been added for debugging purposes and simply never removed.
Yeah, I am just end-user and I don't really care what is under the hood as long as it works, but isn't the biggest complaint against `systemd` is that it integrates a lot of other functions/subsystems that are not part of other init systems? And you kinda have to take whole package?
The only non-init part of the systemd that is required is systemd-journald; every other part can be disabled at build time via configure switch, or at runtime by disabling the corresponding unit files. Whether optional parts can be disabled on any particular distro is the distro packagers' responsibility.
It does have a lot of features but my beef with it is how its integration into Debian still leaves all the misleading old cruft laying about. Take the MySQL server package. Suppose you want to change the limit of how much shared memory it can use. Well, the package comes with an init script, let’s put the ulimit statement in there. Restart. No effect. Ok, limits.conf. Restart. No effect. Ok, edit mysqld_safe script. Restart. No effect. Oh I figured it out, systemd ignores all these things and you have to set limits in its service file. But if you set it to ‘unlimited’ it silently ignores the statement. You have to say ‘infinity’ for some reason.
All this crud has just been left here to confuse users and I hate it.
Man, I feel like the Linux world is moving to systemd but this whole process has been like pulling teeth. I'm totally unaffected by this but even I'm feeling worn out on it. Feels like brexit, honestly -- nobody's enthusiastic about either systemd or sysv init, ok, fine, its happening but... ugh.
The real problem I have with systemd isn't the technology itself, as much as the attitude of the people who run it.
Off the top of my head, issues I've seen with systemd:
* At some point there was no way to say, "bring up this service once the network is up". I mean, there was technically a "network" target, but it considered "localhost" as a network. So if, say, you have automounted NFS, the automounter starts running before your main interface has DHCP. This setup been a widely-used configuration for decades; the systemd maintainers didn't care.
* At some point, if you typed "reboot ; exit" in an ssh session, the "reboot" would hard-kill your ssh session and your shell before the "exit" would be run; so your ssh connection would then hang until the machine came up again and refused a TCP resend request.
* The whole thing with systemd reading the kernel's command-line, deciding that "debug" was meant for it, and spamming the logs making it completely unable to boot; and forcing the kernel to introduce a work-around to hide "debug" from systemd.
* The whole interface renaming thing that's happening in Debian now; every time our project has upgraded our test systems from jessie to stretch, and then stretch to buster, we've had to spend dozens of man-hours figuring out why our network configurations aren't working.
The problem here isn't so much that there are these sorts of bugs; the problem is that there seems to be an attitude of, "Well my set-up works; yours doesn't matter." That's not the attitude such a core piece of infrastructure should have.
Compare this to Linus' nearly fanatical insistence that things in userspace should continue to work. If Lennart Pottering had the same attitude towards breaking existing systems that Linus has, systemd would probably be incredibly popular.
Manually breaking the connection is tolerable-but-annoying for interactive sessions. The place where this caused real problems for me is in my testing setup, where I would have scripts do something like:
ssh <host> "shutdown -h now ; exit"
[wait for the machine to stop responding to pings]
[wait for the machine to start responding to pings]
[Do the next thing]
...and if it didn't shut down within a certain amount of time, or come back up within a certain amount of time, treat it as a failure.
With ssh hanging:
* If the shutdown/start again succeeds, then the "wait for it to stop responding to pings" happens after it's rebooted.
* If the boot doesn't succeed, the whole system waits for ssh's timeout (which is quite large) before failing.
EDIT: I should clarify, this issue has been fixed in Debian at least for a while; but I just tripped over it again when I was playing with an Ubuntu VM; maybe 16.04?
Maybe replace "ssh" with "timeout 10 ssh"? I assume 10 seconds is long enough for ssh to do its thing and short enough that the machine couldn't have come back up.
It wasn't. systemd fixed its actual bug, which was a real bug that caused it to generate an excessive amount of debug output. With that fixed, there was no further issue and no need for a workaround.
(The bug wasn't that systemd generates debug output when the kernel command line contains 'debug"; the bug was something else, which caused systemd to generate an absurd amount of debug output.)
well the first point is fixed when using networkd. the problem is/was that many systems used their own network solution, like networkmanager (RedHat) which did not fit well into systemd
But that's a big problem: if the scope of systemd is just to be an init system, its answer to everyone who wants to make their tools work with systemd shouldn't be "just use our loosely associated tools instead".
networkd, NetworkManager, etc. all integrate into the network-online.target in exactly the same way. There is no favouritism for networkd in particular.
And anyway, the network-online.target mechanism always seemed like a hack added to placate the people who insist that it exist rather then fix their software to not couple tightly into the concept of "the" network being "online". ;)
I'm also mostly disconnected from this, which honestly makes me a fan of systemd.
Today (literally) I wanted to launch Xilinx hw_server as a daemon that my peers could restart if it broke itself (it's... prone to doing so). While I could write an init script that knew about PID files, creating a systemd unit was _vastly_ easier.
Yeah, it's not Unix, but UNIX is also sort of terrible for anything that's not a one-shot, no?
They are changing a core component of a piece of infrastructure used by a large a diverse set of people for a (relatively) diverse set of usecases; and said infrastructure has central governing body; while many of the big players have a public decision making process.
Sure, bazaars are nice, but times like this really make me appreciate cathedrals.
daemontools does not support "start service B once service A is up and running", it can only do "start service A before starting service B". For services that take a while after starting before they are ready, such as databases, that can be a problem.
Traditional sh init scripts were able to handle this as most such services could fork and exit once they were ready, but fork and exit is incompatible with daemontools.
Some daemontools clones have ways to handle this, but IIRC daemontools itself does not.
There really aren't any drawbacks. There are a few distros that use it. If you want to play with it, I'd really highly recommend spinning up a Void VM.
Runit doesn't use control groups - I suppose so it can work on non-Linux OSes. systemd being Linux-specific does.
https://en.wikipedia.org/wiki/Cgroups
The problem isn't so much systemd as an init system as systemd as an everything system. I gave an all-in systemd distro a try this year but quickly went back to something more relaxed after realizing just how bad systemd timers are compared to crontab. It takes writing two 15 line config files and then a long system call to get it to reload the config. It'd be fine for just init but as it swallows more system processes it gets unweildly fast.
On the other hand systemd timers are a lot more powerful with stuff like RandomizedDelaySec and WakeSystem. They can also depend on other units, so that a timer only fires if the system has certain services/devices/mounts/whatever.
Debian has certainly more than 10%. Especially in small server space or embedded Linux many just install Debian because its a simple and stable option.
That does not change your point about systemd adoption. Debian has been in practice systemd only for how many years?
For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian. That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.
However, in practice Debian users tend not to replace systemd's PID1 with the sysvinit-core package, as it is installed on a negligible fraction of Debian systems.
I'm not sure you can rely on popcon to make decisions like that.. anyone who doesn't explicitly opt in, and anyone who installs on a system with limited internet access (i.e. probably most enterprise users) won't be counted.
> I'm not sure you can rely on popcon to make decisions like that
I'd go further and say you definitely can't rely on popcon, for two main reasons:
1 - Not many sysadmins are happy to install a program that "phones home" at regular intervals about system usage.
2 - Popcon records file access times, so a server that runs for long periods between restarts or reboots shows init files are accessed infrequently. This skews the result towards desktop and laptop installations (which are most likely to use the default init).
systemd looks like it was forced somehow on distros.
I was happy with sysvinit, no issues with it as a simple user on laptop.
But now I have issues with systemd once a month, I really hate that thing and don't see any benefits.
> systemd looks like it was forced somehow on distros.
Distros adopted systemd because it solves a huge waste of time that distributors have to deal with: maintaining init scripts. systemd unit files are distro-agnostic and can thus be maintained upstream.
(There's also other useless idiosyncrasies that systemd plowed over, so there's even less work for distributors to do. Or rather, more time to do actually interesting work to differentiate their distribution.)
Package maintainers have far, far worse problems to deal with than some shell scripts that are trivial most of the time for alternative init systems like openRC.
Also, hopefully, no maintainer in his (security-wise) right mind use upstream provided system files as-is.
Fine doesn't mean enthusiastic. Most people are just going along with the trend with no strong preference either way. I'm actually quite fond of systemd now that I'm used to it, but I wouldn't have "moved" to systemd if it wasn't for the major distros making the choice for me.
Are not the distros who design the composition of the actual overall system the exact right people to make this call? In an ideal world (and by your comment I assume you are close to it) you do not care or maybe even realize which startup system the system utilizes.
That is only true for a casual user's desktop, maybe. If you're a power user or a server admin, you will likely be setting up services, or diagnosing their failures, at some point - and then the features and the ergonomics of the init system are very relevant.
Well "the world", whoever is part of that set, can move wherever wants to.
The problem is that in the name of a forced unification that supposedly will do a greater good for the great scheme "linux on desktop" many from that "world" are really into scorched-earth tactics.
There is absolutely no technical reason why different worlds cannot coexist, at least in our case.
Doesn't really count if it never made it to any of the mainstream UNIX implementations; your own citation notes that it's a forgotten technology. Linux certainly never had it at any point in the past.
It would be helpful to also have that shared in in a way that makes it easier to see how many top-ranks each choice had, how many bottom-ranks etc.
But note that it seems that equal rankings are allowed, and many common ranked-choice cast vote record formats don't represent equal rankings.
And the classical egcc vs. gcc, but this one is older than Debian.
Anyway, Gnome was eventually downgraded into "an alternative"; Bash is not the default Debian default shell anymore, it's only default for interactive sessions; Pulse is impossible to get ride of nowadays and still impossible to use; the Grub one kept going until Grub2 that was actually better than LILO; vim won, hands down, as it should; everybody gave up on xfree86 once x.org become better.
Except for pulse, as soon as the preferred alternative became better than the one the change-resistant people wanted, resistance simply vanished. Pulse is outed on the above example because well, it never became better than the alternatives, but still there was never any sizeable resistance, just some noise or lack of it.
HAL was widely used in the 2000s, and virtually nobody uses it now, as its functionality could be -- and was -- much more simply implemented inside udevd.
Basically it just means "if somebody proposes something better we won't tell them to go screw themselves by default". Which I think is very important, as the future of operating systems like Linux is where it has been for the past 2 decades: in distributed computing.
For non-desktop computing, what we really need are distributed operating systems. We have been poorly cobbling them together for decades, yet only a few research operating systems actually ship the needed functionality. Currently we use an array of layers of things, like hypervisors, container schedulers, service meshes, etc to sort of fudge together something that can do distributed computing in very specific ways. But they're all very complex, costly, and time-consuming to set up, and usually tailored to specific use cases.
What we need is for Linux itself to natively ship all a distributed OS's features, so that apps can simply take advantage of them without having to be strapped into 20 layers of glue. But at the current pace of kernel development, I imagine it'd take 10 years to get all those patches developed, tested, and merged. So instead you could merge only the most core functionality, and extend the rest into the userland, and you'd get something kinda resembling systemd, but actually oriented toward running apps and services on a distributed network. I believe that would make most Linux-specific "cloud" technology obsolete, and in the process greatly simplify the entire technology stack, reducing TCO, speeding up development, and simplifying operations.
Assuming that gets developed, "exploring alternatives" is a necessity to eventually get it adopted into Debian, so I'm really glad at least the option is there.
Though he insists on claiming to be "neutral" Ian's position explained in the latter link was to rank E (the only thing rejected more firmly than Further Discussion in this vote in the end) near the top. Option E purports to force every Debian contributor to do the heavy lifting for the systemd refuseniks, their desires are "Required" by the project to be implemented.
Actually, with a tiny amount of human insight, what Option E forces is really either: Another vote to kick out the refuseniks because this is intolerable OR most Debian contributors quit and the project gradually stagnates.
The Diziet sobriquet seems appropriate. Diziet Sma is the Special Circumstances agent "running" the win-at-all-costs mercenary Zakalwe in Iain M Banks' novel "Use of Weapons". Win-at-all-costs is a reasonable strategic choice in the last place we see Zakalwe (the War on Hells in "Surface Detail") but it's probably a bad idea in a volunteer project like Debian.
Voting systems basically break down into two main processes: runoffs and Condorcet. In a runoff, you basically throw out failing candidates from the vote until you get a winner, with there being different criteria for who gets thrown out. In a Condorcet voting scheme, you instead consider all possible two-way races simultaneously. If one person wins all those races, they win the vote (Condorcet majority criterion). If such a person doesn't exist, different methods handle this scenario differently.
A good way to think of it is like this. Runoff-style systems have the goal of maximizing happiness: prioritize giving more people their high-rank options. Condorcet-style systems have the goal of minimizing unhappiness: minimize giving people their low-rank options. If you have an electorate between two partisan candidates and a centrist candidate, most people are partisans who prefer their partisan candidate, and the partisans are roughly equivalent in strength, a runoff system is going to eliminate the centrist candidate first and give the election to a partisan, while a Condorcet system will find that more people prefer the centrist to the wrong partisan and give the election to the centrist.
Rather than "considering alternatives", couldn't Debian invest time and money to make a public study of init systems with their pro and cons, then draft a spec of what they would like to have that doesn't already exist ?
No one else had the technical and soft skills required to replace a core part of a distributed project like "Linux user space". Or maybe more importantly didn't have the motivation to do so.
It feels very much like when a new person turns up at work, with the same ideas you had, but could never get implemented or kept to yourself. Somehow they get it done. Either you embrace their success or become bitter.
* Proposal E "Support for multiple init systems is Required" has been firmly rejected. (In the Debian voting system, rating an option worse than "Further discussion" effectively means considering it even unworthy of being in the ballot.)
* The core of Proposal B is «The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work». The full text can be found at https://www.debian.org/vote/2019/vote_002#textb
* In case the message were not clear enough, the runner up option is Proposal E "Focus on systemd". Proposal E is also the most voted option.