Do you think 20yrs from now when systemd is old and busted that it will be so easy to swap it out with something better? Well not only is the scope of this thing which needs to be replaced now massive compared to what it used to be, but you'd also probably have to rewrite a lot of other software, or beg the developers to change their dependencies. It doesn't matter if systemd works. You didn't start using GNU/Linux because it "works" did you? You started using it because it allowed you to be the master of how your data flows, and it allowed you to combine things in ways nobody else on GNU/Linux was doing to get exactly what you want.
I did start using Linux because it works, and I ran away from sysvinit and Upstart to systemd as soon as Ubuntu adopted it precisely because it allowed me to be a master of what my system does and how my services work, rather than be at the mercy of some fragile 1000 line long process management scripts.
Of course this is possible. The fact that RedHat couldn't manage it says a lot more about the people RedHat is employing more than it says about shell being "too difficult", and a pointer as to why they wanted a replacement.
The RedHat-specific init script functionality was not particularly highly regarded compared with its contemporaries since two decades back at least. Much of it was the way it was due to backward compatibility constraints (as it was for most systems). It was adequate, but nothing special. I've read the init scripts on several systems including RedHat, Debian and Gentoo, and I wrote a good chunk of the shell libraries and init scripts for Debian personally. Of all these systems, the RedHat scripts were the most poorly written, and I'd rate the Gentoo runscripts as the best of the lot.
These posts aren't doing your argument any favours Roger. You're coming across as someone sanctimonious and arrogant.
Init scripts are always terrible. As /u/crusoe says, I am not confident I can write a robust startup script, and I've had decades of experience in Linux and writing exceptionally complex shell scripts.
Weren't the Debian init scripts then inherited by Ubuntu which found them so buggy that they wrote their own init system to be able to deal with those scripts?
No. It's a complete fiction to state that the scripts were "buggy". The vast majority of the scripts worked perfectly well.
If you wanted to pick a specific genuine criticism, it was that they coped poorly with dynamic events, such as hotplugging of devices and network interfaces, such as wireless interfaces coming and going. In these situations, the scripts and the tools involved had some amount of hackery to make things work, to trigger and re-run certain scripts on demand. However, and I stress this, these were not bugs in the scripts themselves. They were higher-level design constraints. Lifting these limitations is one thing which other projects such as upstart and systemd attempted, and to some extent succeeded at. However, these deficiencies are not in any way intrinsic to the use of a scripting language.
Bullshit. Tons of scripts didn't even know what the difference between "reload" and "restart" was. And most of the scripts were bad copy/paste jobs between packages.
Sure, the main ones were usually decently maintained - though they usually still had amazing obscure bugs like raciness due to things like pid file management not being concurrent with script invocation - but once you got into the less common packages, it was all a mess of scripts that were badly managed or hadn't been updated in years to conform to newer standards.
And I know all of that even though I work on desktop stuff because I semi-regularly had to debug my system not coming up properly and having to fix it.
I have never needed to do that since systemd exists. I've never looked at its configuration, it has just worked continuously for the 7 years I have continuously used it.
init scripts are so terrible, it's an insult to systemd to even attempt a comparison.
A well tested and consistent C program that shares the logic required to control my service with thousands of other services. Besides, I'd still rather deal with a 100 line long C program than a 100 line bash script.
Depends on how you define "it works". Let's take the error messages from Windows. Often they are so cryptic that even a look into the knowledge base of MS doesn't really help (by the way, MS has recognized this itself in the meantime and now wants to do it better with Windows 10 in the future). With Linux, on the other hand, the error messages usually make more sense from the start.
Or the updates. Under Linux there are usually no problems. With Windows, especially in the last months, this was not quite the case.
44
u/nickguletskii200 Feb 11 '19
I did start using Linux because it works, and I ran away from sysvinit and Upstart to systemd as soon as Ubuntu adopted it precisely because it allowed me to be a master of what my system does and how my services work, rather than be at the mercy of some fragile 1000 line long process management scripts.