And yet that's exactly what I'm doing today on my systems, which I build from scratch. And I grok the entire operating system, systemd was a god send tool for me.
I run in a setup where multiple graphical sessions run on one computer, which only Linux allow me to do very easily.

There is one exception though : polkit. It is the only tool on my systems that I never tried to completely understand. Now I don't even need to anymore with udev + systemd. And I bet that's where the op is having problems, as it was fixed by installing systemd.

And the outcome is pretty good as Linux runs on every computer available to this day, be it embedded or phones or HPC. So I don't understand what you mean by poor management, are they able to do that in poor management companies?

You're just new to this: Free Software is like that since it started, what you say is laughable to people used to FOSS. You talk like you just discovered FOSS.

Should you use Windows or OSX? Windows Vista, Windows 7, Windows 8, Windows Server 2008?
When you get Ubuntu, you know what you get just as much as when you get OSX, you even can test it without installing anything.
You're juste spewing fallacies here.

You must be young as what you say is patently false, especially in Windows. Nearly everything I learned in Windows 98 was made useless when Windows XP came, including most of my work environment. I can say the same with Windows NT to Windows Server 2003. While nearly everything I learned in school on Unix 20 years ago is still usable today on Linux which is not even Unix.

This is what distro do, it's nothing new, it's just you discovering it now, but everything you're saying has already been done and evolved since then.

It's funny you say that, as systemd is about putting back text (systemd units) instead of lots of binary stuff everywhere (init scripts).

Not on my Linux, and I use systemd. I mean it's integrated and I do not have one single process which does everything.

So you will need systemd on your servers, especially if you want focus on security. The Linux kernel provides dynamic interfaces since a long time, and no one in userspace provided the tools to cope with it until systemd. Devices was done with udev and its predecessor devfs, but init was unable to cope with it before systemd, despite higher level tools trying to cope with the linux kernel dynamic nature.

No, anecdotes never lead to facts even if you have millions of them. You can't even say facts of what. Only analysis of anecdotes can lead to facts.
This is becoming ridiculous, pushing dogmatic thoughts like that is dangerous.

This is pure lie that can be debunked by just looking at the devel ML.
Why systemd haters always have to rely on lies?

No, the reason is that the unstable distro these people are using is really unstable, but they are too young to have experienced previous big breaks in GNU/Linux distro, like udev predecessor, kernel 2.2 to 2.4, 2.4 to 2.6, 2.6 to 3.0, 3.3 to 3.4, Gnome to Gnome 2, Gnome 2 to Gnome 3, ...
systemd is far from being the biggest change and challenge in Linux since I've worked with it starting in 1999, it's actually a breeze that no decent admin that know several Unix + Linux should trip on.

When I read this I could be made to believe I'm a genius. This is wrong on so many levels, the first one being that things didn't work before, things were duct taped constantly by distro providers or by admins. Which is why the first thing systemd haters talk about is being able to tweak their initscripts, because the secret to unknowing people is that the basic distros just don't work with their setup, which has to be tweaked with ugly hacks for every specific environment.
It becomes a hell to maintain and every distro upgrade is at risk of failing very badly or erasing their change.
Usually what happens is that you forget about it, then when it blows up, blame the distro, and then quickly flee in shame when you realise it was all your fault to begin with. Now these admins blame systemd for their faults, the good ones come regularly to the ML to see their problem fixed.
Fortunately systemd is part of the fix for this mess.

In the OP, it's the opposite: the computer is more useful today than it was before thanks to systemd getting installed, so the problem is solely with something else.
Which makes sense since a distro upgrade is not just systemd being upgraded, contrary to belief of non proficient people.

perhaps he shuts them down because he specifically said that installing systemd solved his problem but he doesn't know why.
Yet people with logic problems claim systemd is the problem, despite the fact that it wasn't installed on the systems experiencing the problem.

As it has been adopted by most distro, you're obviously wrong with your rhetoric. It has been one of the most cohesive force actually.

systemd doesn't have the power to force anyone to do anything, people that went to BSD did this on their own will.
Debian community has not been torn by systemd but by trolls actually, systemd was the point used by the trolls.
And usually, victims are unwilling to be victims, or so I heard.

I won't take your word for it on this, only time will tell but I'm pretty sure what you say is just plain hyperbole.
Competent sysadmins actually have no problem with systemd, on the contrary.

I've run my own Linux From Scratch like system since 2001, and I can say your advice is a very bad one.
The problem is that the kernel provides dynamic interfaces since a long time. If you do what you say here, you will have a very limited setup that must not be a moving target, or take the risk of seeing your OS not boot very often, or even lose data (I had several of these problems before systemd). Your setup also has to be a very basic one.
Even your network interfaces or your disks can appear too late for your script on a very basic setup.
systemd is an answer to all this actually: it finally puts the dynamic parts in userspace needed to correctly handle the dynamic kernel.

The problems the OP is seeing, I've crashed into several years ago, and it's basically a documentation problem.
Some of the plumbing tools used for DE (like polkit or accountsservice) are badly documented, sometimes badly designed, sometimes with incomplete options (fixed in the latest versions of accountsservice) and the worst is that there is no howto that I could find explaining the big picture of how it all works together: everything is buried in various development ML. I had to basically reverse engineer nearly everything to understand how it works, mostly because as I compile everything from upstream, the DE like Gnome and KDE would just not start without everything in the right place and well configured.
Gnome 3 and KDE 4 were the worst upgrades for me, I delayed them a lot.
So what the OP discovered is actually nothing new, and I agree but only for security related plumbing needed for DE and user sessions.

This /etc/network/interfaces which is distro specific that you talk about, is exactly one of the configuration for which a replacement is proposed by the systemd you talk about below:

Yes, in systemd it exists, nowhere else for now.

No it's not, you don't understand what you're talking about. The kernel doesn't configure your network interface for you, it just manages the device.

It sure enough removes complexity from the OS if you use every control systemd allows.

Who is "us"?
I sure enough am not part of the people you're talking about, and most of the Linux community, those that develop software and manage most distributions, have switched to systemd. If you care about the linux community, then you should come join us in the real world and quit your fantasy land.
Linux never had this principal of doing one thing well, that's a laughable statement.Linux actually does lots of things well and even better, as is systemd.
If Debian unstable is above your proficiency level, then wait for the stable releases.
It's not even about Debian here, it's about upstream systemd, that you won't see before long unless you run your own OS and compile everything from upstream like I do, or use a distro like Gentoo which is very up to date.

At first reading, I was mislead by thinking you were talking about RAID and similar high availability features in general, which work far better with systemd and LVM than with sysvinit where it was a nightmare prone to break on any boot.
Then I understood you were talking about these features inside btrfs.
And that's where you're yet again one of these people spreading FUD on systemd by being ignorant, be it on purpose or not.
How is software RAID and other features like it (like snapshots) handled on Linux? Yes, by one of several daemon, in the LVM package, that manage the state of the virtual devices. That's because, like was explained by the systemd developers, despite these features being implemented inside btrfs, the kernel still doesn't have enough states to give to userspace : the disk is either plugged or not.
And this is not at all driven by systemd but by udev, which yes, is in the systemd repository.
The issue here is that btrfs lacks the daemon to manage the virtual devices in userspace, and the kernel, if your btrfs RAID is degraded, say the disk is dead, thus why udev doesn't show the btrfs RAID as plugged, and thus why systemd doesn't mount it.
All of this was explained, but you chose to spread FUD by blaming systemd as being shit and breaking userspace.
It works with sysvinit because your script doesn't care for which disks are up or not, and will just break your setup any time some disk doesn't show up.

This is a lie, btrfs didn't work well for a decade to begin with, btrfs is not even a decade old.
This just shows up to what ends systemd haters are willing to go to spread FUD.
And don't tell me RAID and SAN worked well with sysvinit, this would be another blatant lie.

I described the real situation up there, and everything can be found in ML archives, so everyone can see that eveything you wrote there are blatant lies. It's scary at this point.
Even the situation you described is wrong. You actually asked "Did my broken system boot?" and the objective answer is no. A good btrfs RAID would have booted, then even if a disk failed, it would stay functional. But it wouldn't boot in degraded state, just as most hardware RAID by default in fact.

Now I'm starting to believe in a conspiracy against Free Software.
I find it odd to see such nonsense written here, being modded up.
Because what is described here (making the product closed source) is just not possible to do for Free Software like systemd, but is entirely possible (and has been done before and up to this day) with BSD.
Yet, this explanation of why a free software liecensed init system (systemd) is like a closed source operating system (Windows) appears here, is based on nothing solid, but people seem to believe this nonsense nonetheless.
And there have been a big amount of articles about moving from Linux to BSD since six months ago, and I'm now starting to believe this is astroturfing.
Even the move to BSD because of an init system makes no sense to me.

What I'm sure about, is that to this day I'm unable to make my own Windows OS, but I'm still able to do my own Linux systems (all my Linux systems at home are custom made from upstream sources) even today despite having moved to systemd years ago.
Though it's not a bad thing to go learn other OS out there for an admin, I more or less know most of the Unix and Windows systems, but not Mac OS.

Users of systemd include distribution builders, daemon makers and administrators. It's clearly wrong and unfair to say systemd has been forced on these people, unless they're incompetent. Actually, most of these people are happy with the change. Not all administrators obviously as it requires some work and learning to switch your init daemon and its accompanying system startup, shutdown and live management process.

This is plain wrong, I've seen popularity and interests among daemon makers and administrators too : the only people that had to deal with sysvinit and suffered decades from its insanity, especially for low level stuff like network and storage management.

Again a lie. Gnome has a hard dependancy on systemd-logind API, this is like that because Gnome asked for a replacement of consolekit for months, and there was two sides : those that did the work (only systemd) and those that said "You just have to do this" without any work done.
The same applies with the console on userspace and the linux kernel.

To me, what's odd is the time it took (15 years since I've seen the problem) for a solution to the problem to appear, and also the 5 years it took since I discovered systemd for it to be adopted.
Things didn't work successfully before, the people believing that are those that never had to fight their way through init scripts for all these years. The massive adoption is not at all surprising to me, this was needed for years.
An evidence is the fact that even those against systemd are afraid, among other things, of the cost of maintenance of init scripts, because they don't work successully to this day, are full of hacks, and so require lots of maintenance that "you just have to do" talk won't do.

What flies in the face of open source is actually people like you that waste time whining about people that actually code open source.
Complaining is all you're able to do, just go help the Devuan project instead.
Since Devuan appeared, there's still lots of people complaining and others dedicating efforts to go to BSD, and these people love to advertise that they're moving to BSD. But we don't care ! Just move to BSD already and leave the people on Linux alone.

What's this hyperbolic nonsense ? Nothing has been locked down here. Actually with systemd, nothing is locked down at all, I even have more power over my Linux now than ever. These doom and gloom stories for Linux because of systemd are just ignorant rants. People that actually use and understand systemd don't care because these rants make no sense.