[Someone]

I am not convinced every sysadmin could ‘easily’ script around init issues on the servers they manage, but I’ll give you that.

The real issue isn’t with servers, it’s with desktop systems and laptops. When users plug in a USB sound card or plug their laptop into a dock, they don’t want to (and likely couldn’t) “easily script around” that; they expect an audio device, network connection, video card to be created without any user intervention, and go away when devices get unplugged.

Making a set of init scripts (and surrounding unload and reload scripts) robust against insertion and removal of any of many different devices isn’t easy even for init script gurus, and would lead to duplicated code for detecting and handling the various load/unload conditions.

That, I think is the primary reason Apple went with launchd. Systemd took that idea. There’s nothing wrong with that.

The main issues with systemd, IMO are a) initially it was buggy, and b) tremendous scope creep.

[geggam]

>The real issue isn’t with servers, it’s with desktop systems and laptops. When users plug in a USB sound card or plug their laptop into a dock, they don’t want to (and likely couldn’t) “easily script around” that; they expect an audio device, network connection, video card to be created without any user intervention, and go away when devices get unplugged.

Bingo !

Folks who know, and I mean really understand how to run servers know how to script init.

Folks who use Linux on the laptop / Admin Ubuntu do not and systemd makes them able to do stuff "most of the time"

There is no reason to force systemd as the default for servers. You dont plug things into servers and in fact you dont want some service monitoring servers so someone can stick something in a server and start rooting around it.

[michaelmrose]

Unfortunately linux often STILL doesn't handle plugging and unplugging devices very well and it kind of seems like this has gotten worse not better with systemd.

Also you seem to be conflating dealing with devices with initialization of the system. Dealing with such devices has insofar as I'm aware always been handled by c code in and out of the kernel whereas at one time initialization of services and orchestration of components was handled by a scripting language.

This is to say that a bash script may have brought up different components and services but that c code that makes up the component is in charge of actually managing said device.

Its obviously feasible for both c (or any other language) code and orchestration of start up and shut down of services to be buggy but its not equally easy for end users to fix their own problems in all cases.

Ideally bugs get reported to those who are most capable and the underlying code is corrected however if said labor isn't paid to work on their project hours to do so may be in short supply and it may frequently fall on users to lend a hand.

This is a numbers game. If you have 10000 users and 10 of them are qualified to solve such problems you may be lucky to get the help of 1 to submit patches or post a solution to a problem on a forums for others to use before the upstream problem is fixed.

If 100 are qualified you are 10x as likely to find help to solve a problem. I have on many occasions come across a solution months or years before an official upstream solution came into being. You are suggesting that most sysadmins might find it challenging to solve their own problems. They don't always have to. Merely having comprehensible user friendly systems make it more likely that one of their fellows can help them do so and more likely that such solutions travel both laterally between users and hopefully upstream solving the problem for all.

[umanwizard]

Desktops and laptops are a tiny and insignificant minority of Linux installations, and almost completely related to why Linux is popular and important.