SoylentNews is people
SoylentNews
Earlier this month we covered a story where we quoted the following:
Due to Debian developers having differing opinions on handling non-systemd bugs in 2019 and the interest/commitment to supporting systemd alternatives in the scope of Debian packaging and various related friction points, they've taken to a new general resolution over weighing init system diversity.
The results of the ballot to discover how the Debian devs feel about their earlier decision with the benefit of hindsight is now in:
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.
(Score: 5, Interesting) by digitalaudiorock on Monday December 30 2019, @06:47PM (10 children)
I'd argue that even that parallel boot nonsense is BS that's mostly been debunked. I have an archaic x86 system running Gentoo with openrc that can boot to a working desktop in about 40 seconds including everything needed to to LAMP development. What's to fix there, and how fast would that be on any remotely modern hardware?
I'd argue that there simply was never any design plan for systemd to begin with...just a "how tough could it be?" attitude. That is, no real plan as to how it was even supposed to work. I've posted links to this before, and it's quite an eye opener. It's a very non-political assessment of systemd architecture:
https://blog.darknedgy.net/technology/2015/10/11/0/ [darknedgy.net]
Speaking of parallel startup, just as I was saying about having no real design...read the section there titled "Imbalance between promoting laziness or eagerness".
(Score: 2) by janrinok on Monday December 30 2019, @07:56PM (8 children)
That is exactly it - it is essential for spinning up multiple copies in the cloud on demand. It isn't designed for the home user , although it works as well as any other init system in my opinion, but for use in the cloud it is very useful indeed.
(Score: 0) by Anonymous Coward on Monday December 30 2019, @09:32PM (3 children)
Cause it's vitally important that I can spin up multiple copies in the cloud on demand every minute and ... how does SystemD even help here?
(Score: 3, Informative) by janrinok on Tuesday December 31 2019, @08:08AM (2 children)
Systemd helps in many different ways for cloud software.
Firstly, it 'knows' which services each program relies upon. If a service fails temporarily - e.g. networking - it can automatically restart all the programs that crashed when the failure occurred without any intervention from a human. It also knows which services depend upon others so it can start them in an effective manner, either in parallel if they have no interdependencies, or sequentially in the correct order. In the cloud it also means that an instance can be stopped, moved elsewhere, and restarted if hardware fails on one server.
You might only want one a single instance of software starting on a server, but many cloud systems (AWS etc) are starting and stopping instances counted in their thousands or more all the time. They have to do this efficiently, meet a changing customer demand, and ensure that costs are kept to a minimum. The customer does not want to pay for time that he cannot use.
None of these issues are of vital importance to the home or small business user. But, for Debian to survive (and for many other distros too) it was important that they remained viable for cloud computing. Very few distros can afford to just appeal to a niche user group if they want to be a major player with sufficient funds to pay for the support that such a distro needs.
However, systemd does work on home computers. I've been using it on some of the machines that I support, although I also use some non-systemd distros too. For example, I have remote systems based on RaspPi that use an SDR to monitor specific frequencies used by aircraft. They do, occasionally, suffer from a network problem that is caused that is caused by an unidentified short-term (5-10 minutes) burst of local RF interference. systemd notices when this happens, waits for the problem to cease, and then restarts the relevant software (and any other services that have been affected) to continue to do the job it is intended to do. I currently have several such systems situated within a few kilometers from where I live. It would be cumbersome to say the least if I had to visit each one every time the problem occurred.
Finally - and this is no different from other init systems - systemd provides a logical standard way of setting up new services. The documentation is full of new terminology but, once you grep what it actually means, it all seems (to me at least) quite logical and straightforward. I have read of all the potential problems that systemd presents but, after 5 years of use, I have not experienced a single one of them. I'm sure others have, but the same could be said of almost any piece of software that is in regular use. Find me one that doesn't have a bug and I will find you one that probably hasn't been fully tested either.
There is nothing to prevent anyone from using a different distro if they do not want to bother to learn systemd. But there are hundreds of thousands of home users who rely upon it everyday without many of them being aware that it is even installed on their computer. It just works. If you want to use your computer to do things rather than learn what is going on under the hood, you can quite happily forget about systemd and carry on doing whatever it is that you want to do.
(Score: 0) by Anonymous Coward on Tuesday December 31 2019, @03:19PM (1 child)
I find that claim to be utterly hilarious, especially given your choice of example. The single issue I've seen the most with systemd is networking startup issues, where it fucks up starting the network and gives up entirely, freezing the boot until I manually intervene. I have literally never seen it recover gracefully from a network issue greater than a link flap.
(Score: 1, Flamebait) by janrinok on Tuesday December 31 2019, @03:58PM
Dear AC - you seem to have missed the point that I have not experienced any of these problems. I didn't say that nobody had.
So you think that the many millions of Ubuntu, Debian, Mint or whatever other systemd distros are using them because they don't work? Perhaps you have a special use case that causes such problems - the vast majority of users do not have the same experience as you it seems.
So the single issue that you have seen the most is happening on the machines that you manage, and you have to manually intervene? I can see a common link here..., and it is not systemd.
(Score: 0) by Anonymous Coward on Tuesday December 31 2019, @03:04AM (3 children)
Even systemd recommends against using systemd for single-purpose VMs or containers. They use a specially designed stub init for that. Not to mention most orchestration software requires special configuration options for systemd if you were going to use it anyway.
(Score: 0) by Anonymous Coward on Tuesday December 31 2019, @08:04AM (2 children)
then why in all heck is it on Ubuntu? A desktop OS??
(Score: 2, Informative) by r_a_trip on Tuesday December 31 2019, @03:56PM
Ubuntu is big in cloud computing. Desktop has long since become a byproduct.
(Score: 0) by Anonymous Coward on Wednesday January 01 2020, @01:05AM
Maybe because a desktop operating system is designed for a desktop, which definitely isn't a single application VM or in a container. Not to mention, the most common desktop environment has multiple dependencies on the systemd ecosystem.
(Score: 2) by Runaway1956 on Thursday January 02 2020, @09:43AM
I've waded into that link. It gets deep. I'm running out of time, so skipped to the conclusion. That summation pretty clearly states what I've often heard, and in some cases experienced. My long holiday is ending, but I hope to find time to follow links and citations, to understand it better!
To sum it up even more succinctly, it's something of a kludge. When SystemD doesn't do what is expected, someone shims it somehow, with little regard to "standards", then generally fails to document it.