Nothing that worked on vax quit working because someone was trying to cram a new system paradigm down their throats on their own OS.

You mean like replacing DECNet with Unix style TCP/IP networking for example nothing like that happened? :) Or replacing VWS/UIS with X-Windows?

If systemd's proponents are so sure their way is right, they should create a nice systemd fork of something and play with it all they want.

That's what they did. Distributions are willing adopting it. People are switching over to their side.

I still have RedHat's printed "Linux Man : The Essential Man Pages for Linux" manpages on my bookshelf. Way way out of date, but it is nice to browse. I miss printed manuals but I have to admit pdf and the web are better.

What if the process has dependencies?

So assume
A and B depend on C, D and E.
D depends on E.
D and F are currently communicating but no dependency.

E crashes.

xinetd does that for internet ports. It doesn't do it for generic sockets. Something like an xinitd+ could do it for sockets. The idea is clearly there, a key hard part done. There might be some work to getting it to work smoothly for partial loading but I'm not sure how useful that is in practice.

Windows and iOS.

iOS uses launchctl which is systemd's father.

$DEITY forbid that you want to remount your NFS shares because you're cutting over to a snapmirror of your Netapp to perform maintenance (or have the vendor perform it). Pardon my language, but systemd absolutely shits the bed when that happens.

I would think AutoFS would take care of that and systemd would be out of the picture. Or if you want to do it manually it would be just like what you would do with init except instead of directly unmounting you disable the service associated with the NFS mount. I don't think I'm following the objection here.

to be fair, but they're edge cases that affect many common enterprise-grade setup

Well absolutely being able to handle filesystem failures is mandatory. I'm still not quite understanding what you are saying doesn't work here.

reliable logging, minimizing attack surface, and avoiding SPOFs

systemd's logging is more reliable not less.
As far as SPOFs the move to PaaS makes systems far more redundant not less. Each node is unimportant.
As for minimizing attack surface containerization and virtualization are how that's accomplished. Fundamentally that idea is being rejected in favor of dedicated security systems.

That's why I'm so anxiously waiting for the result of Ian's GR

It doesn't really matter. Ian doesn't have a solution for the problem.

Application programmer B creates a systemd dependency in application C.
Debian package maintainer D considers this a bug in the package.
B tells D to go pound sand.

Now what? Obviously if there is interest in init.d package maintainers can create scripts and add them to the package if it is no big deal, that is if the developer isn't using systemd features. Maintainers can't force upstream to do stuff they don't want to do. The example that changed people's mind was brasero. Once brasero decided to use a chain of dependencies to detect when someone inserted a CD (i.e. no user interaction) what is Debian going to do about it?

If large numbers of people from upstream are committed to systemd (and increasingly they are) Debian can't do anything about it. The opposition from systemd (in so far as it actually exists) is coming from old school admins not developers. Distributions are about wrapping software as it exists or making minor changes.

Of course Linux came out of the hobbyist / Minix community. But that was before any of the distributions you mentioned more during the days of LSI. Most certainly people by 94 were using it for real work, that's when the entire cheap webserver movement was started. 1994 people were running NCSA HTTPd (what would become Apache) on Linux in production. 1994 people who used Linux most certainly did use it for productive work. Heck I was using it as a cheap replacement for a pizza box starting in '95.

As for Linux being disruptive to Unix, it most certainly was. The big Unixes are dead. But that's not what I said. What I said was Unixes, especially Linux and Windows server disrupted the early mini computing platforms.

There was a Unix culture in the 1980s from which Linux came. As for the PC world that was similarly disruptive but Linux as a replacement for Windows was an ideology that came a few years after Linux as a cheap alternative to workstations.

I'm not sure in a 5 9s environment you would care about boot issues. Every machine is already redundant so the only time a new machine would be coming up is

a) When it is entering as another node
b) When it is introducing a new / replacement service

An individual system should never be running in a degraded state.

Certainly systemd itself will create a situation like the kernel where if it were to have a critical bug that prevented it from running the system might not in any useful / meaningful sense boot but it isn't going to get through even early testing in that situation. I just don't see how there is any impact on production from possible systemd bugs that are that catastrophic.
 

Nope: https://uglyman.kremlin.cc/git...

So, why not leave systemd in "user centric" distros like standard ubuntu ; but keep init as default in server-distros

Because process management is really important for servers as well. The idea that it is only useful for desktop is a myth. The direction of the Linux server ecosystem is towards PaaS and containerization. The idea is to divorce hardware from specific workloads entirely where individual boxes just becomes a node with compute and storage resources as part of a larger superserver. Essentially a shift back towards a mainframe like paradigm. Init doesn't work well there either.

There are some obvious niche cases where init is superior but they are niche and few. This isn't about ease of use. It is about the fact that Linux in the server space is now becoming something other than a cheap Unix for use in niche cases for stuff that isn't running on industrial Unixes or mainframes. Instead Linux is finally really genuinely replacing those systems and now needs to offer the functional depth they provided.

I think systemd is excellent for servers, I think the wide adoption by PaaS vendors proves this. I also happen to think process management is good for most embedded systems. Because they often have less support, both human and other infrastructure being able to do internal process management is a plus. So I disagree strongly that systemd is about desktop, that's a myth.

That being said though I agree that systemd is a bad choice for low memory embedded systems. But frankly I think Debian is mostly a bad choice for low memory embedded systems. Those really do need specialized distributions and those specialized distributions exist. Certainly Debian can feed those as a parent distribution and there is no reason that for those packages which are appropriate for embedded I'd expect people to supply patches to make the package work with cheaper (in terms of memory / CPU) init systems.

Your history is a bit off here. Linux's earliest intent was as a workstation OS. An operating system that Unix users could administrate and on their x86 box. A $2k alternative to buying a $7k Solaris workstation. RedHat itself came from this desktop mold, before the LAMP stack made the real action cheap server alternatives. Mandrake, Caldera Desktop, Corel Desktop were all doing easy desktop before Ubuntu. What was unique about Ubuntu was: it was free and gave away the CDs. Everyone else was trying to make money selling the operating system.

What you are right about is that Ubuntu created a generation of Linux users with no experience with other Unixes or often other Linuxes. In so far as Linux was ever successful on the desktop Ubuntu was the form of that success. Your paranoia about "disruption" and "the establishment"... is simply that. Exactly what do you think in the 1980-90s you were doing to the mini computer culture of the generation before you when you made client server cheap and ubiquitous?

For example, RedHat in 1994-6 was selling a commercial X-Server as an option because XFree86 was too hard and too crappy. That wouldn't have been the case if no one cared about ease of use or just doing bug reports.
____

As for the "no plan" that was part of Linux culture from the beginning. It was one of the things that distinguished the GNU community from the 386BSD guys (and the children that spun off to be the today's BSDs).

systemd is able to have server sockets and listen to them creating the underlying process on an as needed basis. One of the reasons the Unix shell was so successful was because there were all these little utility programs around that could be easily patched together via. scripting. This made simple applications really really easy in Unix. What systemd does is allows the creation of something like this for application services. You could have hundreds of thousands of socket services being offered by a collection of applications always available but not consuming resources until needed. Which allows applications to mainly consist of just pasting together services from other applications in unique ways.

To do this though the system has to be doing more than just simple initiating services during boot it needs to talk on other roles. This is one of the reasons that systemd is designed for process initiation all the time.