I've seen this discussion come by many times, and every time I had to get my eyebrows back from the back of my head when reading the responses.
I get what the technical differences are between systemd and alternative solutions. That is not the problem. What I don't get is how the init system of anything can evoke such emotions. It all goes way beyond expressing preference. The flamewars and vitriol that have been spread are disgraceful, and people are seriously considering switching to different operating systems because of whatever package runs their daemons and their startup scripts. It's embarrassing.
As a frequent user of Linux, it completely mystifies me how changes in this can cause such emotions. I mean, I'm the kind of guy who did not prefer Fedora for such details as font rendering and certain package policies, so I'm not insensitive to distro differences in general. But I guess I'm ignorant about why so many people seem to cherish such very strong opinions about an init system.
What is it about init systems that causes this outrage? I really want to know!
> What is it about init systems that causes this outrage?
I like systemd. It has shaven quite a few seconds off my boot time. I get that its modularity simplifies things for the developer. However, I understand some of that outrage. Linux systems have typically been mix-and-match. However, when systemd started gaining popularity, some packages have been written to depend on it, and it seems to be becoming difficult for people to choose not to have systemd. Given that systemd is built to make good use of Linux-specific features, it's also annoying for *BSD developers to get many software packages to build and run on their systems.
"I don't understand why many of these packages need systemd."
Exactly the issue I think.
I'm wondering (not trolling) how many desktop people actually reboot the kernel (fresh boot or resume from hibernate) as opposed to using suspend to ram? Given the outrage the Gnome devs caused by hiding the power down function on early versions of Gnome 3 quite a few. I generally just suspend, but I've recently started using hibernate on one laptop with whole disk encryption just in case of petty theft/leaving it on a bus.
Do any sysadmins use automatic spinning up of instances of a small Linux to cope with traffic spikes? Is that something that is actually done? Boot time could matter then.
In general, this is not about the merits of systemd as a program.
GNU/Linux represents choice and freedom. The abundance of distros is proof of that. You can choose your preferred init system, system logger, cron daemon, desktop environment, browser, etc.
Now, systemd is being forcefully pushed to all distros. For instance, by merging udev (a part of the Linux kernel) with systemd. We can't even build a distro anymore without downloading systemd. User choice is under threat.
In this situation, some people align with the forceful approach of systemd. Some prefer to choose what goes into their computers. This is similar to the inclusion of DRM in Firefox, there's no middle ground.
So the debate is really about competitition vs a walled garden provided by systemd.
For me, it is about the merits too, or lack thereof.
The internals of systemd consists of reams of repetitive string processing that should not even have been written in C, and lots of indirection which obscures control flow paths through the program.
The behavior of systemd is only completely specified only by its obtuse implementation, which was developed by some people who have no clue how to design that kind of thing (or to specify and document it).
Why I even know this is because I had to switch to source level debugging to figure out why systemd is or isn't doing something, and how to change it.
Background: I worked on substantial improvements of Linux's ability to support serial consoles on a USB-serial device. This required interaction with systemd. Part of the functionality is that you can plug a console in before booting or after, and get a prompt. Moreover, you can unplug a device with one kind of USB-serial chip, and plug in a different kind that uses a different driver, yet completely recover your existing session, which could be in the middle of a vi edit or whatever).
To get the behavior completely polished, I had to wrestle with systemd, which was killing the sessions in an obscurely mysterious way that made the USB-serial/TTY/console code in the kernel look like a walk in the park. I think it took me several days to figure out, after poring over the systemd source code. First I discovered it was systemd doing the killing by putting some printk's in the kernel. Reading systemd documentation was useless, so I had to crack open the source code and start instrumenting that. I think it took the better part of a week to finally get the behaviors ironed out.
I feel your pain. I expect the badly-documented bug-and-vulnerability-ridden unmantainable mess aka systemd to collapse as abandonware in the future. That's what happened with similar projects before.
I used systemd last year to see if it was any good, and it's terrible. Specially journald, well it uses a binary format, I see this file, about 250KB, I wanted to decompress it as a text file to use my tools. OK, I had a brand-new very powerful computer. After 1 HOUR, I see a 5GB file, the decompression still running!
Another bug, I needed to power off with (unix sysadmins will laugh at this):
sync; sync; shutdown -h now
otherwise systemd (systemctl poweroff) would randomly delete files in my home dir!
So yes systemd is also technically bad. That's why *BSD, GNU Guix and other alternatives are gaining momentum.
How is it not the point? You said "we can't even build a distro anymore without downloading systemd," due to the implication that udev was embedded in the kernel, but that's not true. You can build a distro - just don't use udev.
udev is a necessary component of Linux. You could say just use a fork like eudev. Fine (for the time being). But the thing is, you can't remove udev from the Linux kernel if you want to keep it calling Linux, as it'd be a fork.
Why do you say that? That's what I don't understand. As far as I know, that's not true. You can run a Linux system without the udev daemon, or with one written by you.
But the thing is, you can't remove udev from the Linux kernel if you want to keep it calling Linux, as it'd be a fork.
But udev isn't in the Linux kernel! How can I remove it from there?!
If you remove udev from Linux, I see at least two problems. One of them is technical: programmers expect Linux to have udev, because that's what the Linux authors advertise. The other is legal: Linux is a trademark, and if you replace something and introduce some incompatibility, it's a bad idea to keep calling it Linux.
> But udev isn't in the Linux kernel! How can I remove it from there?!
I think here lies the misunderstanding, udev was previously in the kernel repository, now it isn't. Fair enough. But consider that GNU is also separated in a different repository, but it still comprises the GNU/Linux system as a whole.
Imagine we could only download GCC (necessary to compile Linux) as part of Adobe Flash, don't you think I could say the same? That "we can't even build a distro anymore without downloading Adobe Flash"?
Would it really work? I think you'd have to rewrite some parts of the kernel, but I may be wrong now, in the past or the future.
Anyways, we're arguing semantics here, it'd be better for all to separate udev from systemd. It's like Windows installers usually bundling the program with some crap, and I know most people don't appreciate that.
> What is it about init systems that causes this outrage? I really want to know!
There are some technical concerns, but a disproportionate amount of criticism is because the lead developer[0] of systemd also developed PulseAudio, which was adopted by distros too early and therefore caused a lot of problems for people.
People remember PulseAudio without much fondness, so they are bitter and take it out on systemd.
It doesn't help that he has a somewhat direct manner of communicating, which some people find off-putting.
So, to answer your question, a lot of it is personal, not technical. That's why you see much more vitriol than you'd otherwise expect for a somewhat technically controversial, low-level piece of software.
Another part of the problem is that people feel that systemd is being forced on them (more so than the usual "my distro switched to X, so I'm stuck using X"). The major issue right now is systemd-logind, a replacement for the unmaintained ConsoleKit daemon which is used to manage login sessions. logind provides functionality that is necessary for modern desktop environments, but it's designed to work only with the systemd init daemon. GNOME in particular has been talking about adding a hard dependency on logind, and once that happens the only choice of init system for people running GNOME will be systemd.
Not as much as you'd think, actually. A large part of concerns are technical, sometimes abstract though still quite valid (Rob Landley's take on it was good).
That said, Poettering's character is so distinctive that it's nearly impossible not to do a little jab against him.
Just so you know, what you are saying doesn't contradict what I am saying.
You're saying that there are technical concerns, and that those are a large number of the concerns expressed.
I'm saying that his personality and previous history with PulseAudio are a reason that those technical concerns are expressed far more often (and with more vitriol) than they otherwise would be.
If systemd was just an init system, there wouldn't any problem. It's the fact is now includes about 30 other very non-init features that's the problem. Things like an NTP client, a network config tool, a boot firmware management tool, a login system, and a lot more.
That's a terrible response to corruption of a key system utility. "Oh, corruption happens, deal with it." System logs are much too important of a subsystem to have such a blaise attitude when things break.
> What I don't get is how the init system of anything can evoke such emotions. It all goes way beyond expressing preference. The flamewars and vitriol that have been spread are disgraceful, and people are seriously considering switching to different operating systems because of whatever package runs their daemons and their startup scripts. It's embarrassing.
It's partly a hang-over from toxic communities and people ignoring all the evanglist advice. Linux had a lot of early discussion on Usenet. One feature of Usenet was robust discussion (often under people's real names) which could devolve into hateful flame wars. This was not limited to Linux discussion, but includes Vi vs Emacs, the pronunciation of gif, BSD vs GPL licences, microkernals, etc etc etc.
There are also people involved in this current argument who are difficult to talk to. These people have help create a totally toxic environment.
It's not limited to linux. There are several megabytes (doesn't sound much but don't forget it's just text) of arguing on Wikipedia over m-dash, n-dash, hypens and etc. and that place has rules to supposedly encourage collaborative behaviour.
Not just init systems. Try version numbers[1] or choice of default desktop for a release [2]. The default mark you, not removing any of the many alternatives.
It starts off with confirming that systemd is indeed the very baddest bad thing there is. And then later on mentions that "but, yeah, I don't actually have any troubles with it" at the very end.
I'm sure there are people who have their reasons for avoiding systemd, and for them a list like this is probably great.
But for those still on the fence, this reeks of scare-tactics.
Let's make on thing clear: Systemd does provide a sufficient amount benefits and I can say that without any particular source of my own.
Why? Because pretty much all the distros out there are moving towards systemd and you would be out of your mind to think they are putting in this effort to migrate to systemd if they hadn't done a technical consideration and decided it was a worthwhile thing doing.
"Pretty much all the distros out there" except for: (from TFA)
"The PCLinuxOS distribution has not adopted systemd and, so far as I know, has no plans to migrate to the new init software. Slackware Linux, CRUX and Gentoo Linux are all Linux distributions which are unlikely to adopt systemd as their default init system for philosophical reasons."
The philosophical reasons being the centralisation of control over a key aspect of Linux to a group of developers that aren't universally trusted?
> The philosophical reasons being the centralisation of control over a key aspect of Linux to a group of developers that aren't universally trusted?
In the case of Gentoo, they already support systemd[1] as an alternative.
What I don't entirely understand is, systemd is an umbrella project with many sub-components[2] that are depended upon in many non-init packages now. As far as I can tell, none of the systemd devs care for anything other than Linux support [3], so any packages depending strictly on systemd components are unable to run/build on other systems, or have to now support two+ subsystems.
Gentoo provides support for alternative platforms such as OSX and BSD via the Prefix[4] project, so for them to switch to systemd (and its sub-components) as a default would be to make the Prefix project harder to accomplish.
Again, I don't know enough about the various components that comprise 'systemd', or how modular they are outside of Linux. If someone can clarify any misconceptions I have, I'd be grateful.
In the case of Slackware, I'm going to guess that it's more to do with Patrick's idea of "if it ain't broke, don't replace it". This is why Slackware still comes with Lilo by default: it works, so they never switched to Grub (though Grub can be used and is actually also an available package on the installation DVD: the choice is always yours).
I've used debian for 15 years and I'm looking for a replacement because systemd.
The turning point was systemd breaking a fully functional system and forcing it into recovery mode which was simply broken and going in an infinite loop of displaying it was about to offer a recovery terminal which never came.
Not having log as text and useless info from systemctl and journalctl instead of the useful info I had in traditional logs played a significant part and the attitude and position of the systemd guys too.
This debian forums post sums it all:
From my (relatively short) experience with systemd as init I find that systemd (at least as packed in debian) is really far from being ready. Even the slightest unexpected (to systemd) configuration will make it break from all sides, and even the so-called emergency shell is painfully broken. Together with both the upstream and downstream (debian maintainer) attitude ("this is not a bug, fix your configuration so that it matches our expectations, which by the way change every day and we don't tell you about it" -- i.e. the exact opposite of Linus/kernel's attitude "we don't break userspace").
Arch users made the switch a long time back. When switching to systemd it isn't just install and go.
Systemd is mature and reliable and is running on so many servers it isn't even funny. I personally like it and it is much better for me to admin my services on servers.
I replaced sidux by arch on my personal laptop 5 years ago and I'm looking for a replacement distro for this usage too.
my experience with systemd on my arch laptop isn't one I would say is mature and reliable.
When a service that used to work now fails to start and the only information systemd gives is that it failed to start, I find the only reliable things is that it fails to provide relevant information to allow me to get out of the situation the way I could with logs before systemd.
> When switching to systemd it isn't just install and go.
This I can definitely agree with. Has debian said anything about replacing sysvinit on existing installs or will they just be using systemd as the default on new ones?
The latter would from my point of view be a reasonable compromise and shouldn't alienate anyone.
Yes. The systemd people are in control of the decision making process in debian now. They have decided that an upgrade to jessie will silently replace sysV with systemd. They have rejected all other arguments.
Honestly, these truly are authoritarian scumbags. Linux is finished. And it happened quickly too.
Well, the Linux community does have a long history of technical decisions that later ended up biting them in the ass. HALd was retired just as it was enthusiastically adopted, as it was widely deemed an "unmaintainable mess", despite its code size being only a fraction of systemd's. There was controversy around devfsd before udev replaced it. Debian's decision to adopt libav might have made sense initially, what with it speeding up development, but it later became a detriment very quickly. The ffmpeg deprecation disclaimer was also a very ignorant move.
Finally, at the end of the day, most OEMs ship Windows. I think you're overestimating the distros a fair bit. Wide consensus doesn't always mean quality.
Yes, but avoiding risk is a valid argument for avoiding anything new. Avoidance of risk is why many people like Debian, so hearing that some users and developers of Debian are not in favor of systemd, even if only due to the fact that it's something very new and very different, seems quite reasonable.
Systemd does provide a sufficient amount benefitsyou would be out of your mind to think they are putting in this effort to migrate to systemd if they hadn't done a technical consideration and decided it was a worthwhile thing doing
To some people and some workloads, very much yes, systemd is a very good thing. To other people and workloads and system configurations, systemd doesn't help and sometimes even hurts. Really, to each their own.
But this really is the whole point of FOSS, there are other init systems besides systemd and other OS than Linux where the use of systemd has not been deemed to be worthwhile. If you feel similarly, use one of those distributions/OS and contribute to it so that it doesn't go away.
I'm not a fan of systemd. I run Debian stable. I'm not sure what I will do once Jessie becomes the stable release.
The solution is to fork Wheezy off as an alternative to Debian.
Debian is now in the enemy camp. The decision making process has been taken over by the systemd people. New authoritarians.
Wheezy is the last of the unix like era of the Linux "software stack". All that is needed is to patch security fixes sometimes, and/or run a grsecurity patched kernel. The software in Wheezy does everything desired.
It is the ideal.
The ideal is being lost. Make sure you keep your source code DVDs.
I wouldn't describe the article as great, because it strayed so horribly off topic and the answer is wrong.
By analogy it would be like asking a question along the lines of "please inform me generally about the marketplace for 3rd party iphone cases" and then instead of getting a survey of the iphone case marketplace, the response is a half dozen paragraphs about the relative superiority or inferiority of windows phone, and the philosophical implications of blind love of change vs blind avoidance of change, and the politics of blah blah and then at the end finally an answer like "Otterbox cases have a good reputation, and VLM on hacker news claims regardless of device mfgr, if he can put a device in an Otterbox case he puts it in an otterbox case, and (insert list of inferior competitors to Otterbox)"
The other aspect I don't like is the answer in small detail is wrong, there is no uncertainty, Ubuntu is just reskinned and 3rd party support of Debian, so obviously "some time" after Debian goes 100% systemd then Ubuntu will go systemd. Its only a matter of time, Debian being Ubuntu's upstream. I guess theoretically the only way for Ubuntu to avoid it would be Ubuntu switching to Gentoo as upstream (guess it could theoretically happen, however unlikely) or avoid the question entirely by going out of business (again afaik not likely).
>obviously "some time" after Debian goes 100% systemd then Ubuntu will go systemd. Its only a matter of time, Debian being Ubuntu's upstream.
Ubuntu has been using their own init daemon, "upstart", since 2006. After Debian announced their plans to switch to systemd, Ubuntu announced that they would follow suit instead of continuing to use upstart.
Let's suppose that you don't want to use systemd, but you do want to use Debian.
No, let's back up a step. Let's say you don't want to use GNOME3, but you do want to use Debian as a desktop system.
In that case, you would simply install KDE or XFCE or LXDE, or just have a display manager of your choice start the window manager of your choice. There are lots of choices and Debian considers them all first-class citizens. Nobody gets upset when you say "I don't like running KDE, what are the alternatives?" If you say "It looks like xterm has a new dependency on gtklib, what's up with that?" your bug report will be addressed.
But if you say "I don't want to run systemd, it seems to have been installed by mistake" what you get is:
systemd is the future, you should run it.
why are you so rude? systemd is the default init. Get used to it.
it's not that there are lots of people who object to systemd, it's all the same people being loud and repetitive.
and
it's all settled now, so any attempt to object is a flame.
And that's why systemd is causing such a ruckus in the Debian community: they don't play well with others.
Regardless of what ends up happening with the most popular distributions, there will always be another distro that will stick with something different or more antiquated for you to choose. You can even do it all yourself with something like Linux From Scratch. If some software doesn't support systemd, you have the choice to either avoid that particular piece of software or submit a patch to support your preferred stack. There's still plenty of choice to be had.
As someone who is responsible for a fleet of various machines, I like that going forward I'm probably only ever going to have to hassle with one init system (at least until the next big init system enters the fray). I don't even really care which one "wins", but it's nice only having to write one style of init scripts/units. I especially don't care which package contains my dhcp client or ntp server. This is stuff that, for the most part, I don't need to touch after writing an Ansible playbook for tweaking.
On the desktop side, the various organizational and technical differences between distros (in spite of efforts like the LSB) make life harder for those writing distro-agnostic software. A good example is Steam. This is one of those potential "killer apps" for the Linux desktop, yet they're only able to officially support Ubuntu during the early goings because of the variations between distros. This may change as Steam for Linux matures, but it's telling that they picked a single distro to focus on initially.
systemd being adopted by the more popular distros is a win-win. The major, popular distributions get closer together for greater interop, while the fringe distros can cater to the vocal minority who actually cares about this. You'll always have the choice to choose other distributions and other software.
"If some software doesn't support systemd, you have the choice to either avoid that particular piece of software or submit a patch to support your preferred stack."
Qualified agreement.
In Debian Testing/Jessie, a simple wm on top of Xorg can be made init diagnostic
Something a little richer that is still init agnostic requires some management. Using --no-install-recommends when installing xfce4 for instance results in a functional desktop with nice fonts and compositing, but dbus insinuates itself but can't function, and there is no automounting of drives (I use pmount) and one is left to fall back on wpa_supplicant and roaming.conf.
Depends on what you need in a desktop
PS: my 'production' laptop will run a rich desktop but my carry-round laptop for wasting time in cafes will be some kind of debian-sysvinit frankenbox just for the lutz.
That would be asking for a new feature, not asking for the preservation of existing functionality.
Even so, the answer is that yum and apt have already been packaged for Debian, so can install those, install alien, and then convert deb packages to rpm packages, build a repo, and work from that. Ask around, maybe other people are interested in doing that too.
Init systems and process managers are meant to be generic, even systemd has that as a goal. The biggest problem is always converting your scripts to a new scheme, unless a compatibility layer exists.
On the other hand, package managers are far more opinionated. Each distro has their own particular package format, guidelines and development practices that are made to form a coherent as possible experience. File system layout is important here, among many other things.
However, you certainly can. apt-get install yum is a thing. I'm not sure how reliable it is, though.
I don't know what they say, but I do now they have a systemd-shim package that you can use to emulate systemd functionality when you don't use it as the init system. And the sysvinit package hasn't been removed.
You should note the date on that article (April 3rd). Kay Sievers rights have been reinstated by Linus.
It's also important to note that the issue was with Sievers specifically and not with systemd. As Linus said "[...] you don't fix problems in the code you write [...]".
eg, "[...] But I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project."
I can't talk about systemd, but I had to deal with pulseaudio issues as developer of a third party project and it wasn't a pleasant experience. Kay is not involved with PA in any way, but I remember PA developers blaming Ubuntu because of their PA integration.
Yes, it is probably me seeing things here as result of my own frustrations, but I wouldn't like to experience a similar situation with systemd.
Of course systemd works, and works well, it is in RHEL7 and the clones (the 'EL' world), it has to work! And be maintained for 10 years. That 10 year support horizon rolls forwards each release.
At the philosophical level, does anyone not have mild concerns about the binding together of large parts of the underlying systems and the general loss of modularity?
At the coal face do any sysadmins really value the new logging and monitoring tools?
One metric might be the speed adoption of EL7 by those currently using EL6 and EL5. A high speed of adoption means general happiness (or just need for newer packages). A low speed of adoption means unhappiness (or just no pressing need to upgrade).
The logging and monitoring tools are /worse/ than in a BSD or SysV init situation. Journald, as opposed to rsyslog and syslog-ng, can't talk to other systems in anywhere near a sane manner, can't connect to databases, has no ability to filter and direct messages, etc. On top of that, it makes core dumps require root privileges to analyze them, making user level development and debugging more difficult. Systemd has a heavy, heavy stink of someone from the desktop realm coming in with no knowledge of what tools sysadmins already use, and screwing everything up in the process.
>The logging and monitoring tools are /worse/ than in a BSD or SysV init situation. Journald, as opposed to rsyslog and syslog-ng
I have to agree. I am one of the main people to support Fluentd (an open source log collector https://www.fluentd.org), and a lot of people do forward rsyslog/syslog-ng to Fluentd for further processing/analytics. We've been trying to figure out a way to do the same with journald, and while it does seem possible, it will require a ton more work.
Redhat employ the core systemd developers, and RHEL is mainly a server product. Senior Redhat people must understand the issues and have decided to go with this system for a reason. I'm just wondering what the reason was!
One of them has just jumped ship to Google mind you!
Adoption by large enterprise customers follows different patterns than you seem to expect. Right now (7.0) an "early adopter" will be planning certification with a probable production rollout for 7.2. I expect there will be another rise in usage with 7.4.
Systemd adds complexity and functionality. The question is, does the price of complexity outweigh the gain in functionality. I got really annoyed at systemd initially but that was because I knew a bit about upstart and init. My systemd knowledge was zero - it is still pretty low. Now that I've seen it in action, it doesn't seem as offending. In time, there will likely be docs on the Internet. I do hope this isn't a harbinger of bad things in Linux. I think the original commenter in the article alluded to the same philosophical point.
One thing to think about is that my adding complexity in the beginning, you can avoid complexity in long run. Imagine a Unix shell without pipes. That would certainly be simpler in a sense, but the ability for programmers to write simple programs that work together would be severely curtailed. Systemd itself might be more complex than initv, but it provides a lot of tools and guarantees to application developers which makes life simpler for them in the long run.
The only time I interact with systemd is when I'm running
it on a server, something the majority of people don't do.
And there's the crux of the issue, from my perspective. I'm sure this year will be The Year of the Linux Desktop™ (are we still saying that?) but the fact is that there are way more Linux machines in a server role than in a desktop role and the people who run those machines are doing so because they are in the critical financial path of a company. This is a change that doesn't directly cater to the people who are running servers (despite the message that systemd has features that are valuable on servers). Relatively few people are running Linux at home compared to the number of server installations. So while more individual people may be impacted by systemd, it's designed and targeted for the desktop which has a lot fewer actual installs.
I've had to interact with systemd on my desktop system rarely (but enough that it's frustrating for things that should be easy and obvious and just work) so what's on the desktop doesn't impact me that much. But I run way more server installations where things like boot-time and NetworkManager and multi-seat (I question how many people actually need this on the desktop anyway) and name-systemd-feature-of-week doesn't offer much advantage over the old system which seemed to be working fine, was mature, and everyone was sufficiently familiar with it (not to say it doesn't have warts, as everything does).
To add some balance, I found this article "The Biggest Myths" (http://0pointer.de/blog/projects/the-biggest-myths.html) to be really helpful in sorting out what is going on with systemd. I was a bit sad that Upstart did not win on the Ubuntu side because I had already invested in learning the technology and I quite like it versus SysV init scripts.
> I quite like [Upstart] versus SysV init scripts.
Have you tried systemd service files yet? They're quite nice to work with. I haven't written Upstart's equivalent, so I only know what those are like second-hand, but I imagine if ease of creating a service is a major factor you'll be pleasantly surprised by systemd.
Not yet. I am waiting till I actually need to use it. Right now I administer Ubuntu servers at work so I am still on upstart and at home I am on a combination of (Free|Open)BSD and Ubuntu.
I use VirtualBox on Windows with a shared folder, and when the virtualbox package breaks for whatever reason, the OS decides that's a good enough reason to fail startup and go into emergency debug mode.
I also notice it with the systemctl command line tool, which is actually really pleasant to use.
I'm not sure what would happen if this happened with other init packages.
We have this thing you may be interested... its called BSD ... in fact we have several of them, any one of which may be exactly to your tastes. If your not sure, check out PCBSD.
I like using FreeBSD and Solaris, and all sorts of other OSes. SystemD makes it harder to do. For every system service, now were maintaining a systemd and a non systemd version of its init files.
I get what the technical differences are between systemd and alternative solutions. That is not the problem. What I don't get is how the init system of anything can evoke such emotions. It all goes way beyond expressing preference. The flamewars and vitriol that have been spread are disgraceful, and people are seriously considering switching to different operating systems because of whatever package runs their daemons and their startup scripts. It's embarrassing.
As a frequent user of Linux, it completely mystifies me how changes in this can cause such emotions. I mean, I'm the kind of guy who did not prefer Fedora for such details as font rendering and certain package policies, so I'm not insensitive to distro differences in general. But I guess I'm ignorant about why so many people seem to cherish such very strong opinions about an init system.
What is it about init systems that causes this outrage? I really want to know!