Was that an exercise in truth inversion?
The Linux ecosystem is exactly what made systemd "win". And the rise of systemd occurred in a bottom-up manner actually.
systemd actually didn't win anything, it just allowed the streamlining of using the Linux kernel specific features that nobody used because of catering to the lowest denominator. I was not surprised at all at how fast true admins got rid of sysvinit or even Upstart.
On the machines I control, I've done this more than 15 years ago, going with simpleinit-msb for most of this time, before having to switch to an alternative because maintaining it was leaving me sometimes with security vulnerabilities to fix alone.

Exactly! When you have several layers on top of your block devices, like RAID and LVM, it's even worse.
It was such a pain before, despite the LVM or multipath daemons, I was never sure the servers would reboot correctly, or the config freeze or corrupts itself.
Such a nightmare before systemd tackled the problems and sometimes the bugs in kernel or daemons, now it just works.

I won't do your work for you, and you must be a pretty bad one to talk about things you don't even know about.
If reading skills and understanding skills are so challenging to you, you won't understand a thing, which is probably what happened already, given the copious amount of documentation available on systemd. There never were any for sysvinit and its scripts, and a very bad one for Upstart.
Besides, you need experience with sysvinit or Upstart to understand the biggest advantages of systemd.
Given my experience, I just don't take people that say sysvinit (or Upstart) had no problem seriously, less of my time lost this way.

Stop making fool of these veteran good unix sysadmins please. I will not associate with some fool like you. You people that know nothing love to give yourself a false authority by saying this nonsense everytime. But a good sysadmin will see through you without any problem.
You trolls are so nonsensical that you say Upstart WORKED WELL and was available in the 80. Linux is not Unix BTW, if you were a seasoned Unix sysadmin, you would loathe Linux more than systemd, systemd is only possible because of Linux.
You are wrong on all counts, so blinded by your hatred for something you don't even understand, it's pathetic.
I've encountered very few admins that even understand how a Unix-like boots anyway, lots of seasoned admins just have no ideas.
I've encountered far more Linux sysadmins that had this knowledge than anything else.
At best you're one of them.

You're wrong, plain and simple!
Upstart was trying to solve lots of problems of sysvinit that a seasoned Unix admin should know about, it even used dbus.
And the decision to use systemd by default in Ubuntu was the distro maintainers choice.
No good reason to make better than sysvinit? I've seen reasons 16 years ago, that's why since then I never installed sysvinit init anymore on my own made Linux OS. And yet, in my work environment, I'm still to this day the most knowledgeable around about how all this sysvinit crap works, be it SYSV or BSD style.

If that's the only reason you know about, it just confirms you know nothing about systemd. This is not even one of the main advantage of systemd since years.
The dynamic nature of the Linux kernel and its devices is one main reason.

No, once you said "I am not looking back", and then you come to a thread of the thing you weren't supposed to be looking at, I call you on your BS.
Besides, this serves no purpose at all, this doesn't help people in the thread, and doesn't help him either.
I see a poor person looking for validation because of his/her insecurity of having changed OS, which doesn't help his/her cause actually.

You didn't use systemd either : it has step by step execution, debug option which is very verbose, emergency shell, debug shell (on vt9), all of this off the top of my head.
Besides, systemd is not based on Unix, it's heavily tied to the Linux kernel, the same Linux kernel that already doesn't grok UNIX if you want to go that way.
Actually, systemd uses a lot of Linux features not present on Unix. If you wanted to complain, you'd have complained about Linux primarily.
systemd would not even be possible on any Unix, that's why portability of systemd to other Unix was thrown away.

So you found vulnerabilities but don't even know how to exploit them ?
People talking about things they don't even understand...

It's obvious you're not a fan of systemd, you can't even manage a Linux OS properly, restarting because of a PA crap (which would normally show a audio Linux module bug) that you're unable to handle correctly and then talking about debugging the init of your system which is far harder to do.
Actually, debugging systemd startup is easier (or I should say faster) than debugging Upstart, especially the dependencies, there are tools included in systemd that do nearly everything for you.
Besides, a sound server has nothing in common with an init system, so making comparisons between the two shows no technical knowledge at all.
The end user experience of Ubuntu is not about the self-contradictory "debuggability, hackability and simplicity", it's about simplicity which contradicts your "hackability" statement.
I don't see how the end-user experience is inferior, this makes no sense. When you change your timezone in the graphical UI and it is now synchronized automatically with the underlying OS, and the change is visible in the command line, when it was not the case before with Upstart (or sysvinit), that's an improvement in my book.

No it doesn't remains to be seen, it's pristine clear that it's better for everyone else, as the "them" you're talking about are the only people affected by this change.
Which is exactly the reason why everyone else don't understand what the change is about, they were never aware of this part of the system, except when they were affected by a bug in it (and there are tons of bugs still present today in upstart, bandaids and the like).
It's striking to see that when Debian had sysvinit, Ubuntu made Upstart because sysvinit was such a pain. But the switch of Debian to systemd was enough of a step forward compared to managing Upstart alone, that Ubuntu decided to switch to systemd.

Actually, what you say just says a lot about your knowledge of these sysadmin issues : you know nothing at all and you are spewing nonsense, which perhaps will fool people that aren't interested in these issues, or will be brushed off as ignorance by people affected by these issues.
The outcome will be the same in both cases : what you say won't have any credence and is completely useless.
I don't know in which world you live where "so far the jury is still out on that", you must have missed the last 6 months at least : it's over.
And your vision of systemd is wrong by the way : educate yourself please.

You haven't looked back, and yet here you are looking back at a linux distro that uses systemd.
Basically, you make no sense : lying to yourself is not a solution.
It's obvious you crave for what is happening in the Linux systemd world, which is the contrary to "not looking back".
Or perhaps you're right, which would mean you think that you have gone back by going openbsd, and you are now looking forward to Linux distro using systemd.

Isn't that supposed to be funny? People on Slashdot actually believe this load of bullshit?
UUID for disks folded into systemd? systemd crowd (developers?) are windows devs? sysadmins don't reboot servers?
If that's the "knowledge" of the new wave of Linux users, I guess old Linux sysadmins won't have to fear for their jobs.

That's the only truth in this post till now.

Another lie. The main problem of systemd is that there's so much to do given the state of Linux init systems, that it's still a fast moving target, too fast for distros. It will stabilise when most of the features are implemented.

This shows a lot of ignorance on even how a Unix like system works. Init is launched by the kernel, so of course it runs as super user, and no, it's not network connected, not PID 1 at least. The rest is drivel or nonsense, like it obsoletes 20-30 years of best practices and knowledge, this makes no sense, I can operate my servers with best practices that I couldn't use with sysvinit, and I still use the linux (you mean GNU?) tools the same with systemd.
Executables configuration scripts (init scripts) are not at all best practice, even less when they use configuration files of their own, scattered in several different files, and whose behaviour can be modified by the environment, making for a huge attack surface that can go undetected. That's what you call best practices? And calling people names doesn't make your argument any better.

You would not understand as you've shown below and above that you're not the audience to even start to understand what it's all about.
The minority you're talking about is the exact same that was maintaining the init scripts before, you can be assured they know what it is about. And I can perfectly understand why these people would ditch sysvinit and init scripts as soon as possible.
systemd is a good thing for a lot of reasons that you will be unable to understand, given what you write below.

Now you're spewing nonsense. This is not your experience with systemd, this is your experience with some specific version of Fedora.
Linux crashes, /home not being mounted and other problems are not fixed by searching Google blindly or reading manuals or reading bash scripts, this makes no sense at all. Reading init scripts wouldn't help you understand what is going on.
There is one thing to do in this case : searching for logs that will give you a hint at your problem (the error at bootup is not enough), to have a start of an understanding of what's going on. That's the basic and you don't even have that. Fortunately you have the sense of not being vocal about systemd when you don't have the basics of system administration. Other vocal people don't even have that common sense unfortunately.

What you are saying doesn't compute. If the init scripts were working well in the last 20 years, why do you need distro maintainers to maintain them? Why is there the fear of these init scripts rotting away if not tend for?
Real sysadmins who have worked with these damned init scripts and are not lying to themselves know perfectly why.
Init scripts are flawed by design on a dynamic kernel like the Linux kernel, and this problem was there before 2000 already.
That's actually one of the main huge benefit of systemd, with gettiong rid of executable configuration files (init scripts), which are a huge surface attack on any sysvinit system. I have seen countless security issues related to bad things done in init scripts, like for example creating temporary files or directories, which is handled securely by systemd.

Yes, these scripts are workaround for the deficient sysvinit, like trying to guard against environment tampering, managing user options without modifying the init script itself (often scattered over several locations), ...
systemd removes these nonsense scripts and replaces them with a simple configuration file (a unit) without any drawback. You can even modify the systemd units, with your modifications usually still valid after an upgrade (it won't work if your unit is renamed to something else than apache2).
This just shows how horrible init scripts were. It's even worse when you know you can manage isolation like chroot, or security features very useful for a web server like hiding filesystems or directories from the daemon.

This is correct, except for the bunch of people unfamiliar with modern OS operation. Their goal was to reduce this number, which doesn't solve any use case I know for big servers, except reduce attack surface at boot perhaps, this I can agree with.
For smaller servers and limited resources systems, like embedded systems, the efficiency is very welcome. My security frontends say thanks to systemd.

Actually, systemd works far better with my use cases. It works far better with LVM2 for instance, than my shell scripts ever could.
Actually, it works every time now with systemd. mysql and apache works far better now, especially mysql which was a pain to start and especially to stop with the initscripts. Now with systemd it's far better.
I agree there's some tuning to do at first, but not the kind of bad hacks we had to use with init scripts.
The attack surface of init scripts was also huge, without any hope to discover it without constant monitoring. Some init scripts had 4 (yes four) different ways to configure them, each one could be exploited.