Actually, it's a strong indication of inexperience and incompetence on the side of the "sysadmin" who experience this issue.
I have several servers and desktops with NFS mounts and systemd, and they all start and stop extremely fast.
Some desktops have the home mounted as NFS, and they shutdown in less than 2 seconds, which always amazes me.
Perhaps the difference is that all my NFS mounts are defined as systemd units, and they are all using the "on demand" feature of systemd, which equals automount. Automount was how I was handling my NFS mounts before systemd, so as not to break my systems in case of network issues, which would mean a reboot.

You should not go everywhere talking about your understanding problems. We understand you can't read correctly or understand anything about computer science.
For the record, the log is NOT lost, it is still there (unless the filesystem removed it), and only the corrupted part in it are not displayed by the systemd standard tools.
And no, systemd does not corrupt the log during unexpected shutdown, there is no code to do such a mischievous thing in systemd.
Actually, computer programs are not sentient entities, they're not magic, they're not self aware. It's just that an unexpected shutdown in itself prevents the OS from doing its normal cleanup, and the corruption can happen at any level. Filesystems and (log) files got corrupted by unexpected shutdown before systemd was even created.

I can't believe one moment that a company gives system design to people like you who have astounding comprehension issues.
You don't have any idea of how a log or any file is written to disk, you are still wondering why an unexpected shutdown can corrupt a file, I dare not tell you that can corrupt an entire filesystem, gasp!
It's pathetic to read such behaviour, because logs got corrupted before with your syslog daemon, but you weren't aware of it. For you, as you weren't aware of it, your log weren't corrupted: a fallacy you can't manage to grasp. Sorry, that's not how it works in the real world. Now, journald can verify its log integrity, and all of a sudden, lots of ignorant people come complaining about a problem that always was there, because journald actually provides this information. Instead of being thankful, ignorant people calling themselves sysadmins want others to do the work only themselves can do, which is securing their log files and their filesystems.

This is your opinion, you're entitled to it, my opinion is the contrary of what you're saying.
systemd replaces many of the kludges that were inconsistently added to sysvinit (like daemontools or inetd) to have a system that was a little bit manageable.
Even process management was pathetic with sysvinit, nobody used it because of that, except to launch getty and a bunch of scripts, which is very sad.

That much is true, that's the true problem between systemd and stable distributions. The other benefits must be huge for the distributions to accept to maintain old systemd releases (like 209 which is full of various bugs which can be annoying).

Fallacy, and again your opinion, mine is different. I find the development leads very competent, I'm noone to judge on their ego and I don't care, it's irrelevant to code an init system, like communication skills which are not needed at all to code. To troll on Slashdot, perhaps communication skills are useful, but not to code an init system. Which must be why systemd is so much more advanced than the other init systems on Linux.

So file bug reports, that's how it's done in the community. Anti-Linux shills however, they only troll and never do anything.
You can even go to the dev ML and explain the problems. I don't see any design decision which is bad for security and stability myself, but several minds are better to locate these.

The rest of your post is nonsense: systemd has only been evaluated on its technical merits, that's how it won nearly every Linux distro.

systemd actually DOES provide faster boot times, but that's in a native systemd environment, not in a kludge one where systemd has to launch shell scripts.
Actually, systemd is so fast that it showed lots of race conditions in many projects startup, like gdm or mysql.
It's true that fast boot times was only one point at the start of the systemd project, it never was its ultimate goal.

Your examples are useless as long as we don't know if systemd was running in native mode (with only systemd units) or in compatibility mode (by having to translate init scripts to units and still launch them as shell scripts). In compatibility mode, systemd has more work to do than in native mode. The compatibility mode is basically useless for systemd, it's only useful for the admin as a temporary workaround, when you're translating init scripts to systemd units.
Only then can you really enjoy the power of systemd.

There's no difference between kernel and systemd for old subsystems, you're just plain wrong with understanding problems or ignorant on purpose.
What was yanked is the readahead part, and it is because there was no maintainer for it. The devs didn't have SSD so they couldn't maintain it.
It's pretty basic stuff that are very easy to understand, the same happens in the Linux kernel.
Now, when I read your conclusion from these facts, I'm sure I won't ever ask you any advice or logical thinking.

You use words and talk about things you don't even understand, you make gross generalizations and I'm sure you think that makes an argument.
First, a customer is everything but stupid, surely you meant a consumer.
You make fallacious sentences like "many systemd proponents will lie shamelessly about its characteristics". This sentence is a subject of study in itself, given that its meaning changes depending on who reads it. It contains no evidence, is based on nothing but your perception of reality.
Then comes the scare tactic with this gem : "That also means that the NSA has its fingers deep in there, possibly without Poettering realizing".
It seems to me you don't have even the start of a clue of computer science and how it works. It also seems to me that you keep the NSA as the utmost authority in security.
Did you know that (you won't understand one thing of what I'm going to say but whatever) the NSA was beaten by their own weak cryptographic algorithm policy (low key length) that they imposed on foreign countries?
The NSA is not the supra smart entity you think it is.

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...