I'd just like to start by saying that I don't want this to devolve into a flame war. I understand how strongly people feel on this issue. I am not a big fan of systemd myself, but I have used it. Because of the controversy surrounding the issue, I have been researching it, and the one thing that pretty much every source is short on is non-biasd information. The best factual information regarding the operation of systemd comes from Poettering's own blog, which is obviously biased. My main question is; why have so many distros adopted systemd? I understand all of the Redhat distros, Redhat did develop it. I've heard(no source, but it makes sense), that Redhat has employees on Debian's board. That in turn caused Ubuntu to switch as well. What about Arch, Mageia, SUSE, Sabayon? Likely as a result of Sabayon, Gentoo even has full support of it(though not by default). If systemd is as bad an idea as many claim(http://boycottsystemd.org), why is almost everyone using it? I personally understand both why a new init system was needed and why it seems like the design of systemd is terrible, but I am not a developer. I'm an admin. I've used systemd, sysvinit, and openrc. They all work. Why systemd?

would linus torvalds count as non-biased?
i saw a video yesterday, and basically he said 3 things:

- systemd is not better or worse than, e.g., sysvinit
- it's sad that it's compatibility is rather narrow
- the faster boot times undeniably speak for themselves

i am using arch linux and systemd - i think the usage is pretty starightforward, but i should say that for archlinux as a whole, i haven't used systemd elsewhere, and there's something cluttered about debian (based) systems.
i am not informed enough to have a real opinion on the topic.

2 members found this post helpful.

I agree that it definitely works and the boot times are fast(though I would argue that that doesn't matter all that much). **Tinfoil hat time** I would debate how non-biased he is at this point. It's well known that he uses only Redhat distros(mostly Fedora), and that he likely holds stock in the company.

Being a new Systemd user I haven't got the boot time corrected, but I can say that the shutdown time is really fast.

1 members found this post helpful.

Your wish is unrealistic. The only kind of discussion that has even a remote chance of not becoming an argument is a technical discussion about the actual working of the monster. A discussion about the factors behind systemd's development and adoption will involve politics, ideals and economics. It will only take a few posts before the thread becomes exactly what you do not want it to be.

And the best way to understand the situation is to critically read the information and mis-information available, including many threads on this board, and come to your own unbiased conclusion.

Not that I know of. In fact, there are Canonical employees on Debian's technical committee. The decision process for Upstart or systemd was a close decision (4 voters for systemd, 4 voters for Upstart), so that the committee leader had to make the decision. He decided to go for systemd.

At first, I wouldn't think that really many claim that systemd is bad, it is more a very vocal minority. But anyways, the answer to "Why systemd?" is rather simple: Because the distro developers have decided that the advantages of systemd outweigh the disadvantages.

3 members found this post helpful.

I had a quick look at boycottsystemd.org and read "violent slap in the face to the Unix philosophy", "open disregard for non-Linux software", and "vehemently postmodern", at which point I tended to switch off. Look at the statistics on web-servers and supercomputers (specialised, but the only statistics we have): Linux is by far and away the POSIX system. BSD and Plan 9, recommended at that site, are as relevant to the 21st century as OS/2.

The technicalities are a bit beyond me, but in matters technical I trust the experts. I assume the heating engineer knows how to service my boiler, that the builder who said my roof needs repair but not replacement understands his job, and that Linux developers know what's best for a distro.

4 members found this post helpful.

Bottom line, for the things they have in common, both work. In the differences, systemd is faster and does more.

So what if the commands are ugly, most people never have to USE them. The ones that do CREATE ugly commands (or at least 'I' do) and can learn new ones rapidly. The technical advantages are worth a bit of ugly, where you need them.

Beyond that it is mostly religion, and arguing does no one any good in that field.

Religion or maybe just habits, I mean I don't hate scripting. I often tweaked init scripts to better suit my tastes.
Last time I edited an init script was by necessity though, I installed a system on SSD drive and the boot was too fast, I mean NTP started even before /dev/rtc0 was created. The easy fix was adding a 3sec delay in rc.S

Now with systemd I don't see myself repair things as easily as with plain text scripts. But it's me and my habits

well that's one good thing, i guess.

You could dig up a dozen reasons why systemd was adopted, but mostly it was for boot time, GNOME, and service supervision, something we've had for a while now.

To be honest, the concept was originally sound:

- parallel service loading
- service supervision
- centralization and simplification of service scripts

...but systemd grew beyond simply being an init system to become something else. It included at least a dozen or more co-services, dragged in D-Bus and udev, creates a binary log which if corrupted is useless, and created a dependency hole within the system. Many services were deprecated all for systemd, some projects even went as far as to only support through systemd. Plus, it was egotistically created only for Linux and newer versions have lock outs on certain kernel versions.

To me, I point at the massive single point of failure this has created. Even though all the different parts of systemd are different parts, they all must still execute within PID1, and should a child process crash the parent process, the system is crashed.

I can't bring myself to support systemd because of all the lessons of UNIX and sensibility of using a bazaar style collective of daemons in a system to a cathedral design of one daemon with many child processes. This design is completely reflective of Oracle's SMF, Apple's launchd, and Microsoft's svchost... all of which are notorious for feature creep and bloated system requirements.

As far as systemd doing more, yes it does, but how much should systemd actually be doing? There were other alternatives that could have been utilized by Debian and Canonical, which honestly I don't need to name, but really, the choices were poor at best, there were little alternatives.

I just wish we could see exactly where systemd is headed. How many features and daemons is it going to include and/or offer as well as deprecate? Is it going to eventually become it's own OS? I know Lennart has said Linux needs to be competitive, but at what price?

6 members found this post helpful.

a newbish question:
is it possible to undo the bad, while keeping the good, original idea?
as in commercial?
if a linux developer has that in mind, it will affect projects badly, i'd say.

If we take out all the stuff that was added to systemd except the init system, we basically have yet another OpenRC, Runit, s6, etc. alternative init system that would work. However, if that's the case, why do we even need it all then?

I've said it several times that in reality systemd does nothing but reinvent a wheel trying to claim it's more rounder. Even if you add back all the rest, all you do is just add things that have been covered by separate projects.

I have always carefully considered one thing about Linux's competitiveness... GNU/Linux speaks for itself and doesn't need to be competitive in any arena. By forcing systems to upgrade kernel and systemd in lock-step you start to remove a long standing security feature of GNU/Linux, asynchronous systems running variety of kernels and software. GNU/Linux is harder to target because no two systems are the same, meaning it's difficult to insert malware effectively, because say you target Fedora, you try to target Gentoo and end up still only targeting Fedora because the two systems run two separate kernels and software. Now that we're going to have locked step kernels, malware authors could find it easier to target GNU/Linux, and by pushing GNU/Linux mainstream, it becomes a target. If we all are running the same CoreOS regardless if it's Debian, ArchLinux, Fedora, or SuSE with equal software, now we have four systems and distributions able to be targeted.

I'm skeptical about that malware argument. The protection against malware is good design, pure and simple. A serious computer criminal will be targeting the internet, where the financial transactions take place. Since most of the companies who would be targeted run Debian or CentOS, cracking one would be a good-enough achievement
.

Malware usually is written around a primary design in a system to attack a known flaw.

Look at Windows as a great example. All Windows operating systems at some point all run the same kernel and core. They all have the same security updates, patches, and hotfixes which makes them easier targets to exploit a flaw. If several thousand systems have the same flaw, the attack is more widespread, more devastating, and more difficult to combat.

Look at the IE6 attack that happened with Windows XP a few years back. Many British workstations, including those in government, were all using IE6 due to the fact Microsoft can't push IE in England and Europe. Even if they used the last version of IE6, the vulnerability was still there.

Think about a flaw in a Linux kernel. If say tomorrow a hypothetical kernel had a flaw, everyone used it, and it was a bad security flaw, if a malware author targeted that flaw, the damage could be extensive. Imagine a malware author having not only root, but kernel level access in a critical server or system. Basically they have the proverbial "keys to the kingdom".

I'm not saying it would happen, but giving hackers a chance, reason, and means is not wise on any level. Creating an aspect where kernel upgrades are forced upon the user creates a security flaw. This means a minimal kernel has to be there, the flaws of that kernel become a regularity, and for each upgrade, you limit down the number of kernels that are varied among users.