Boycott systemd

by martinp • 12 years ago

258 232 12 years ago

mateuszf3• 12 years ago

Em .. no, thank you. I think that systemd is a good step in the direction of unifying different distributions. Also, many argument presented on that page have been debunked or are actually good things.

tmikaeld2• 12 years ago

I agree, i find it very hard to believe that so many distos would make the wrong choice here.

Fuxy• 12 years ago

It's the best option at the moment arguably not perfect but better then anything else out there.

I wish the owner of that website would would make a better alternative instead of complaining.

makomk6• 12 years ago

They made the only choice. Because various applications are now dependent on systemd APIs in order to function correctly, and those APIs in turn can only be implemented by an init system that is structured the same way as systemd, it's essentially impossible to use anything else. Someone could come up with an alternative to systemd that was superior in every other way and it'd be impossible to move to it. (Hell, it'd have been impossible to move to systemd in the first place if the existing init system was so closely entwined with everything else.)

clarry2• 12 years ago

I think diversity is one of Linux's strengths. And the flexibility is what allows people to experiment and try create new things, wildly different and original things. Things like new init systems, say systemd. I don't mind what init system you use, but it would be nice if one didn't become the dependency that is so hard to replace or work around that no sane person will. That's a way to kill innovation and ensure that big changes only come from the influential elite.

mateuszf3• 12 years ago

I think that diversity is good in user software. Base system (OS) - kernel + process management should just work good and be portable.

blueskin_3• 12 years ago

I'd rather see init's problems fixed (i.e. start services in parallel), but systemd is far better than upstart (edit: got it to load at last, I see it's not by upstart fans, so ignore that last part).

That said, a lot of systemd seems like a really stupid idea to me, e.g. binary logs, the massively increased SPOF size, and the "do everything" mentality. Unfortunately, I don't know of any distros that aren't using it now (edit: I didn't even realise Slackware was still a thing...), and upstart is even more of a joke than systemd.

crashandburn4• 12 years ago

I've got to agree with a lot of your points here, to paraphrase churchill, systemd is the worst system management daemon system that we have, except for all those other ones that have been tried from time to time. (this sounds a little harsh to the other ones, but I find systemd intuitive from a user-facing perspective even if it does have a lot of inelegance under the hood) [0] http://wais.stanford.edu/Democracy/democracy_DemocracyAndChu...

quasque2• 12 years ago

What's wrong with binary logs? Seems like an improvement, given how they can be cryptographically 'sealed' to help tamper detection, and have indexes built in [1].

[1] http://www.freedesktop.org/wiki/Software/systemd/journal-fil...

icebraining• 12 years ago

Sealing sounds interesting, but that page doesn't explain why can't plain-text logs be sealed.

mrweasel3• 12 years ago

Binary logs are pretty annoying because your standard tools for searching through them no longer works.

tail, less, grep, wc and similar tools are rendered useless. Newer tools like logstash or Splunk are also going to have issues reading your binary logs. It's not really a wise thing to break the tools that most people use every day, it's just going to make them hate you.

andrelaszlo• 12 years ago

Tom Gundersen discussed the move to systemd on the Arch Linux forums a couple of years ago.

https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Summary:

    0) it is hotplug capable
    1) we can know the state of the system
    2) it is modular
    3) it allows dbus/udev to go back to doing the task they are meant to do
    4) we can reduce the number of explicit ordering dependencies between daemons
    5) we get a lot of security/sandboxing features for free
    6) systemd service files can be written and distributed upstream
    7) systemd is a cross-distro project
    8) logind will finally deliver on what consolekit was supposed to do
    9) systemd is fast

antocv3• 12 years ago

DMD has all those advantages as well.

Dmd is the gnu daemon managing daemons.

davexunit3• 12 years ago

I'm very excited about dmd. It's being developed in conjunction with the Guix project for an official GNU distribution. I hope to soon steer clear of this systemd mess by using a Guix system running dmd.

viraptor4• 12 years ago

While systemd has some good parts...

0: udev did that. They merged udev in. Now systemd does it. I'd rather see them play nice by communicating with other projects than controlling everything on their own.

1: Apart from internal watchdog, the features he listed are also available in upstart. (others are not, but his list is actually common)

3: This is a strange claim when talking about an init system that effectively starts managing devices.

6: Not sure why it's on the good things list - it already happened before for rc/init/upstart. It's inevitable rather than new awesome - we'll all have to rewrite the configs once again.

8: Why is that part of systemd? Ubuntu was happily running with it being a separate daemon. If it doesn't depend on systemd why is it included (same for udev really). Convenience for developers is not a great answer here.

There seems to be a lot of exaggerated claims going both ways - at least that shows not everyone is happy about the change. Hopefully the next project that replaces init will be what many claim systemd is right now...

RVuRnvbM2e2• 12 years ago

0: Kay wrote udev. He is now a lead contributor to systemd... 1: Upstart was hobbled by the Canonical CLA. Several systemd contributors cite this as the reason for starting systemd in the first place. 3: See 0 6: See 1 8: logind is developed as part of the systemd suite, but is entirely modular and in fact is used with non-systemd inits via systemd-shim.

lawl• 12 years ago

  0) That's not the init systems job.
  1) That's not the init systems job. Use something like http://cr.yp.to/daemontools.html
  2) Less modular than any init system out there. Having *everything* (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it.
  3) See 1.
  4) Never bothered me, but fair enough.
  5) That's not the init systems job.
  6) Not if the path's differ. E.g. are debianized.
  7) So was sysvinit.
  8) That's not the init systems job.
  9) It actually is.

Edit: And if you downvote me, at least add an explanation please. Thanks. I'd like to know if I'm factually wrong or you just disagree.

skrause• 12 years ago

You failed to mention why it's not the init system's job. An init system which is aware of what's going on can have a lot of advantages.

In the end djb's daemontools are nothing more than an init system on top of an init system. So why not include it in the main init system?

cnvogel5• 12 years ago

2) Less modular than any init system out there. Having everything (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it.

I can understand the issue that people have with systemd swallowing more and more functionality, but this fact is just false.

dhcp is in /usr/lib/systemd/systemd-networkd, which is not the systemd binary running as PID 1 (/usr/lib/systemd/systemd/systemd).

    chris@raspberrypi /usr/lib/systemd $ ls -la systemd systemd-networkd
    -rwxr-xr-x 1 root root 907340 Apr 14 23:10 systemd
    -rwxr-xr-x 1 root root 329604 Apr 14 23:09 systemd-networkd
    chris@raspberrypi /usr/lib/systemd $ ./systemd --version

systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR

RVuRnvbM2e2• 12 years ago

You clearly don't understand systemd.

It is a suite of tools for managing the system state. Going from runlevel 0 to runlevel 3 is just one such transition.

systemd is referred to as monolithic because it is developed in a single repository, but it is in fact extremely modular. "PID 1" is only one of the ~70 binaries which make up the systemd suite.

Saying "That's not the init systems job" seems dogmatic and short sighted when there's currently no other approach which offers the hotplug, service management, security and performance features that systemd brings to the table.

zokier5• 12 years ago

I think you are missing the forest for the trees. Systemd is not just PID1, it is an umbrella project for various core system bits and pieces. Most stuff in systemd project do not run in systemd PID1.

dkhenry• 12 years ago

If over half your critique is that systemd does _more_ then its predessor and all of those are valid services, that it can do well, then I don't see the real complaint here. I mean are you upset because its different.

Tuna-Fish3• 12 years ago

> 0) it is hotplug capable
0) That's not the init systems job.

For modern Linux, there is nothing but hotplug. And I mean that very literally. Oldest Unices only worked on systems where all the hardware was brought up on boot, before the rest of the system. Then hotplug was added on top of this. Init systems didn't evolve to accommodate this, instead different systems were developed to handle it. However, the Linux kernel has constantly evolved towards eliminating old-style static boot, with right now, on normal bootup, almost all devices are hotplugged. This is why sysvinit doesn't work properly anymore. Being hotplug capable is definately the init system's job.

VMG2• 12 years ago

Edit: And if you downvote me, at least add an explanation please.

See other replies.

binaryapparatus3• 12 years ago

For me, systemd broke beautiful Arch setup into some monstrosity. That's not what Arch was or at least what it was for me.

I do (rarely) install Linux on some new PC but I think I stopped installing Arch after this changes. I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf? What is that killer feature that Arch offers, apart from being rolling release?

pavanky5• 12 years ago

I keep hearing bullshit about how systemd broke archlinux. But for the vast majority of us it did not. I had atleast 3 machines running ArchLinux at that point and had very little trouble porting all of them.

Anecdotal evidence can be dismissed by anecdotal evidence -- A variation of Hitches' razor

zokier5• 12 years ago

What is that killer feature that Arch offers, apart from being rolling release?

Like being good solid rolling release distro is not good enough? Frankly I prefer my distros to be free of any "killer features".

nvarsj• 12 years ago

For me, systemd on Arch reduced my boot time from 45s or so to pretty-much-instant-on. Which is pretty damn nice for a distro where one tends to reboot a lot.

I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf?

rc.conf removal had nothing to do with systemd, I think. And was removed prior.

What is that killer feature that Arch offers, apart from being rolling release?

Vanilla upstream packages.

havaze• 12 years ago

What is that killer feature that Arch offers, apart from being rolling release? Apart from that its pacman, just sick of the apt-get madness. And generally having far less default crap on you system.

ealexhudson• 12 years ago

'systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of binaries'

So, a collection of lots of single-purpose binaries that work together flies in the face of "do one thing and do it well". I kinda stopped reading at this point, which was sadly quite high up the page.

TTPrograms• 12 years ago

I think the point is you can't replace each of those binaries with alternatives. The monolithic nature of systemd is not just a function of the raw number of binaries involved.

zokier5• 12 years ago

I think the point is you can't replace each of those binaries with alternatives

Is there any reason why you couldn't do so?

Found this chart: http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... Note the columns "Reimplementable Independently" and "Known Other Implementations"

toggle• 12 years ago

True, but I think you could say the same thing about git. It's a big bundle of binaries, and there aren't alternatives available that you can swap in and out. And yet, git is seen as the perfect example of the Unix philosophy.

People whip out the Unix philosophy the same way they do every other philosophy: whenever it supports what they already want. I don't think it's a valid argument anymore.

nifoc• 12 years ago

Consider migrating to BSD, Plan 9 or something similar, if things get really out of hand.

I can understand suggesting to migrate to BSD, but Plan 9? Seriously?

And what's the purpose of the "Open Source Tea Party" picture? This surely is not the only picture of Lennart in existence.

foxylad• 12 years ago

Given that both systemd and upstart exist, it would seem that it is time for a next generation init. And given that Ubuntu has now accepted systemd, it has critical mass and should be the new standard.

"Doing one thing and doing it well" is a fine guide for system tools, but does not apply to everything - look at the kernel, or Gnome for instance.

Grue3• 12 years ago

I'm getting code 500 error, but I'm guessing a Republican has been discovered to be somehow related to systemd.

klaasvakie2• 12 years ago

Does anyone know if this quote is true?:

"Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions."

I was pretty meh about the whole systemd thing, but having to change userspace when swopping out kernels is a spectacular disadvantage. Imagine having to downgrade your distro whenever you need to test against older kernels --- madness.

This is especially bad with ARM/embedded stuff where one often runs a modern userspace with an older kernel.

cnvogel5• 12 years ago

In my experiece, upgrading the kernel to a newer one is not a problem. What can happen, though, is that an upgrade of userspace will suddenly require a kernel-feature not present, if you run an ancient board-support-package with a 3.0-kernel or so in 2014! (happened to me with a BSP for a Freescale i.MX6).

So, if you have archlinux tracking the latest and greatest systemd, uptrading userland can make your machine no longer bring up everything (completely). But in my case the kernel is from 2011...

klaasvakie2• 12 years ago

I have an i.MX5 BSP with a 2.6.xx era kernel :(

Can you give an example of the "no longer bring up everything (completely)"?

zokier5• 12 years ago

systemd README claims compatibility with 3.0 kernel:

http://cgit.freedesktop.org/systemd/systemd/tree/README#n39

makomk6• 12 years ago

Upgrading the kernel to a newer one isn't generally a problem, but the changes to cgroups that the systemd and kernel devs are planning to make in the future are not going to be backwards compatible with old userland code.

vidarh5• 12 years ago

They'd get much further if they actually came up with a better alternative.

Even if all of there points were objectively true, it doesn't matter when sticking with the old init is so much worse in many ways.

People aren't picking systemd because it's perfect, but because both the mess of init scripts it is replacing, and alternatives like upstart,is seen as worse/too lacking.

EDIT: Btw. this just got me to install systemd on one of our dev/test Debian boxes at work, to start testing it.

theanirudh• 12 years ago

The author of systemd, Lennart Poettering busts some systemd myths in his blog post http://0pointer.de/blog/projects/the-biggest-myths.html

barkingcat• 12 years ago

it sounds like a lot of the complaints were of the "this makes things easier and smells like it's not the lovechild borne of any arcane hacker and I refuse to read documentation" variety.

espadrine• 12 years ago

There's one thing that the boycott post gets right, that Mr Poettering doesn't address, which is:

2. systemd's journal files (handled by journald) are stored in a complicated binary format.

Mr Poettering tackles the myth that configuration files are binary (they are very obviously not).

That said, I am not sure how to get the journaling data in an Upstart system, nor in a sysvinit one.

cakeface• 12 years ago

Also, I highly recommend reading Lennart Poettering's initial description of systemd on his blog [1]. It lays out the paradigms behind systemd design really well. I think that it is important to understand the problems that systemd is trying to solve in order to evaluate whether it is doing it's job well.

[1] http://0pointer.de/blog/projects/systemd.html

lmedinas2• 12 years ago

Systemd got a huge boost due the involved from Red Hat. But then most of the distros are adopting it, even Debian and Ubuntu. I don't see a reason but still if you want to stay out of systemd better use Gentoo or other "non" major distro.

mateuszf3• 12 years ago

The reason is that it's awesome.

lvillani• 12 years ago

Cached: http://webcache.googleusercontent.com/search?q=cache:zylqvGo...

(the site is unreachable at the moment).

nemasu• 12 years ago

Okay, well, while I agree with most of the points they make, there just isn't a viable alternative. I maintain noop Linux (nooplinux.org), it started using OpenRC, but when udev was merged into systemd, things got very complicated, eventually the switch was made. Systemd is very fast, the 'init.d' scripts are way better, udev work very well...I don't mind thinking about moving back away from systemd (because I really do have a love-hate relationship with it), but what am I supposed to go back to? OpenRC/SysV-whatever? Heck no. Upstart? Nope. ...is there even an alternative that makes sense? Because moving back to SysV would be a step back.

stefantalpalaru• 12 years ago

it started using OpenRC, but when udev was merged into systemd, things got very complicated

I got past that by using eudev with OpenRC on Gentoo.

jbergstroem2• 12 years ago

For uncomplicated systems (such as virtual machines, servers and whatnot) there's mdev in busybox.

SEMW• 12 years ago

"Unix philosophy" seems to be one of those phrases that everyone likes agreeing with because you can use it to either justify or condemn anything you like.

E.g. you could perfectly plausibly make the argument that systemd's return to inetd-style service starting (on-demand and in-parallel through socket activation) is a lot more unix-philosophy-like than the SysVinit way.

cturner• 12 years ago

Agree, but SysV-init isn't notably unixy. In general, SysV distros raced to embrace and extend away from the mainstream. That created lots of un-unixy subsystems that live on in linux. Quick wave in the direction of three - NFS, wacky IPC systems, SysVinit.

SysVinit is complicated - it wants to be a DSL but is still a shell hack-together. It's inflexible - it's a dependency tracking system, but you can't easily adapt it for userspace launch control, or as a build tool. It doesn't do one thing well. (e.g. doesn't reliably contain a process tree, there are still situations where you want to use pid files or complicated ps greps).

Init is a hard problem. From what I can see all the unix derivatives have made a mess of it. I've had fleeting attempts at writing my own, and I definitely made mess.

In the absence of the good, I reckon the simple becomes the standard. In modern BSDs there's a script called init, it gets called at startup and does nothing for you. I reckon we should judge challengers to init against that.

burke• 12 years ago

It's like a modern-day "no true scotsman": http://en.wikipedia.org/wiki/No_true_Scotsman

lucian1900• 12 years ago

This is why we can't have nice things.

moreentropy3• 12 years ago

I can't access that site because it returns 500 right now, but: Can we please get over it?

Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done, and managing processes using init scripts and daemonization is pain. Edit: I'v read the cached version now, and this assumption turned out wrong. The authors see a need to replace sysvinit.

The amount of bad and inconsistent init scripts, messy PID file handling, makeshift service wrappers, defective daemonization and logging workarounds is so much worse than having one place that will handle those ever repeated tasks.

I love that in recent years Linux (as in distributions) got an attitude and actively push things forward, without losing compatiblity to older software. Apple introduced launchd and nobody complained. We start to rely docker and all sorts of new approaches to manage our services and nobody complains. But init is somehow regarded as the holy cow noone is supposed to touch although everybody agrees it sucks.

Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products, and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.

I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result. How could this get even worse?

txutxu• 12 years ago

If you can't access the site, your toughs about it's current content, look like a you're respectfully trying everybody to disrespect this.

I'm happy about this movement.

In 15 years of sysadmin, I can say that writing init scripts never was a big issue. Maybe for "junior sysadmis" or those that are in the office by their last name.

I respect your opinion, but I'm very afraid of the course that linux is taking regarding system design (dbus, systemd, etc) and I resonate with that page content.

tmikaeld2• 12 years ago

I read your answer like this:

No newbie sysadmin should touch init scripts because they can't handle it.

Isn't it about damn time we go from overly complex to what makes sense?

“The only way to control chaos and complexity is to give up some of that control”

vidarh5• 12 years ago

In 20 years of managing Linux systems, I can probably count on one hand the time I saw an init script that was written properly unless it was provided by the distro maintainers (and often not then either). That is, it included all the expected options for the service, it correctly handled pid files for daemons that for whatever reason doesn't do it themselves, it handled reload's gracefully, and so on.

Good riddance to init files.

If these people want to keep people from using systemd, they need to come up with a better alternative.

jbergstroem2• 12 years ago

I don't see init scripts as an argument for writing journal (no more plaintext logfiles), integrating udev, replacing cron, writing their own login manager or handling power management (among other things).

The argument of "do one thing well" might be 20 years old, but no one is holding progress back -- rather raising voices against doing so by aggressively removing choice from the agenda with it's current implementation.

moreentropy3• 12 years ago

This is all stuff that needs to be taken care of, on every system. So I'm happy that systemd handles the basics in a sensible way. Why do I as a sysadmin need the choice here? Everything I need is covered by systemd, and in a less painful and more consistent way.

For example, I really do like how systemd-journald takes care of logging, although I don't know why it's not using plaintext log files internally. journald gives me the choice to not log to disk at all, which is nice on embedded systems and my notebook SSD. If i wanted to have logs the old way, i'd just attach a syslogd on journald's socket. With systemd and journald I can have my services log to stderr and everything just works.

I don't have to: * Log to stderr if my service can't start for some reason * THEN daemonize (which is a pain to do in node.js and python, and not possible in golang) * Then switch logging to syslog or my own logfile(s) * Think about logfile rotation * use supervisor or monit to make sure my services stay up

matthewmacleod• 12 years ago

I know you didn't get the chance to read this, but it specifically says:

Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it.

And I don't think that's an invalid point. I totally agree that a better init system is desirable, but I've also personally really struggled to understand why systemd is a good approach – it does seem, from someone who's not that close to the issue, that it's an extremely complex and monolithic approach to the problem.

rjzzleep• 12 years ago

I don't see a boycott happening. Not unless someone steps in to write an alternative init system, which solves some of the issues openrc and systemd solve, but without systemd's baggage.

taking the discussion out of the opinion level to a more factual level(eg. i like the boot speed of my archlinux machine but the whole consolekit(why did we get that to begin with ?)/logind/ridiculousness, logging and service files vs. startx and grep /var/log is annoying to say the least, but as i said subjective)

on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design. let me bring a few examples:

https://bugs.freedesktop.org/show_bug.cgi?id=76935

That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.

or this one, systemd segfaulting with cgroups off:

https://bugs.freedesktop.org/show_bug.cgi?id=74589

Lennart:

To make this work we'd need a patch, as nobody of us tests this.

There were a few other recent ones. When your new init system consistently takes down your operating syste, because of stupid bugs, and the lead developers say we don't care, and even block efforts to fix these issues, you should indeed worry.

https://plus.google.com/111049168280159033135/posts/Kd57G8s1...

In fact Greg KH jumped in to play daddy, and wrote a patch where tom gunderson commented that that patch would not be merged as it's not clear what problem it solves.

edit: some say openrc is the one. here's a comparison:

https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

welterde• 12 years ago

solves some of the issues openrc and systemd solve, but without systemd's baggage.

I thought OpenRC was that init system? Or what systemd baggage comes with it?

midas00710• 12 years ago

runit (from daemontools) might not start things up in parallel, but it's a whole lot simpler and reliable. Phusion uses it instead of upstart in their base docker VM.

Also a lot of enterprise shops use daemontools and runit, because they just fucking scale.

darkarmani• 12 years ago

on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design.

Agreed. This is a big worry. When the lead developers of something this important sound this callous, I start getting concerned.

danielweber2• 12 years ago

How could this get even worse?

Linux distros have gotten worse and worse and worse over the years. (So has Windows.) Every 3 years the old way of handling configurations is thrown out and a new one put in place.

That said, I don't know enough to say whether systemd is fixing this problem or if it is contributing to this problem (which it could do even while claiming to fix the problem).

lmm2• 12 years ago

Making init better is a good thing. Breaking working systems is a bad thing. Making gnome not work on *BSD is a terrible thing, not just on a theoretical level but also on a practical one.

Linux itself would have been impossible if the systemd attitude had prevailed among older unix. Linux-only software is the open source community shooting itself in the foot. Systemd will break the community, which will be worse for everyone, linux users included.

tedks3• 12 years ago

Does anyone really care, though?

This is the free market deciding that non-Linux unixes aren't worth anyone's time. If you believe in the free market, you should either stop complaining and get on the winning team, or hole up in BSD-land rewriting Linux software until you have a plurality market share.

Demanding that open-source developers donate their time to support your particular OS is just leech behavior. Mandating "support equality" is a step in the wrong direction. Open source became great by being free; let's not take that away.

meapix2• 12 years ago

good point.

felixgallo6• 12 years ago

"Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done..."

The Unix philosophy (loose coupling of specialized pieces) is what permits you to get things done. It is the foundational theory behind the most successful architecture on the planet.

systemd is doing things the Windows way -- monolithic, tightly coupled systems wherein, using Occam's Razor, the explanation for some of the coupling has to go into the realm of the nontechnical.

Those of us who have to manage and create large complex systems sort of scratch our heads at the idea that desktop systems booting faster is an important goal deserving of all this mess. Linux on the desktop has always been terrible and will always be terrible, and getting to it a few seconds faster is not helping you.

bitwize3• 12 years ago

Windows has historically sported better system integration than Unix, with system components of greater granularity and flexibility than Unix has historically provided thanks to the power of COM interfaces. If the tightly coupled Windows way provides a better solution, then maybe we should build things the Windows way.

gkya3• 12 years ago

Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products [sic], and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.

This statement is so utter in faultiness, I don't even know where to begin. In the first statement, you say “Regardless of the truth of it; this axiom X is true.”, and introduce a logical paradox, similar to the sentence “This sentence is not true.”[1]. Consequently, you call Mac OS X, FreeBSD and alike niche. The former is the second most popular commercial desktop OS, and the latter is incorporated into the former and also is the OS that powers PlayStation 4[2][3].

You say that “init systems need not be compatible”, and I say yes. Also, OS interfaces need not be compatible. Implementations of C library need not be compatible either, nor implementations of C themselves. Why did the size of a byte were standardised anyway[4]?

I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result.

You wouldn't have to if there were a standard initialisation interface, would you?

Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done, and managing processes using init scripts and daemonization is pain.

You want to get things done today; I'd guess you'd also like to keep thing happening 10 years later, when Linux is no longer as popular (Software come and go, no-one can guarantee that, say, illumos[5] will not become more popular than Linux in 10 years). Would you rather run around porting your init scripts to the new OS a cloud provider fancies, which your boss fancies, or write new bugs (which some refer to as features)? Would you rather wait for the mainstream repos of your favourite projects to catch up, or just deploy the program and enhance the experience? Would you rather read pages of documentation for your new incompatible init system, or skim the frontpage of HN?

We start to rely docker and all sorts of new approaches to manage our services and nobody complains.

Well, Docker is a containment and distribution solution and programs need not be modified nor need to have around Docker to run. It is reminiscent of a FreeBSD jail or a plain old VM.

Apple introduced launchd and nobody complained.

Just compare the source trees, you'll be enlightened[6][7].

[1] http://plato.stanford.edu/entries/self-reference/

[2] http://www.phoronix.com/scan.php?page=news_item&px=MTM5NDI

[3] http://www.vgleaks.com/some-details-about-playstation-4-os-d...

[4] https://en.wikipedia.org/wiki/IEC_80000-13

[5] http://wiki.illumos.org/display/illumos/illumos+Home

[6] http://cgit.freedesktop.org/systemd/systemd/tree/

[7] http://www.opensource.apple.com/source/launchd/launchd-842.1...

edit: format references

ciupicri2• 12 years ago

Doesn't illumos use something similar to systemd, called SMF[1]?

[1] http://www.illumos.org/man/5/smf

moreentropy3• 12 years ago

You wouldn't have to if there were a standard initialisation interface, would you?

My point is, even right now with sysvinit (and aix doesn't use it afair), i have to adapt a init script to every single unix/linux distribution i want to use my software on. At least, if i want to comply with that system's best practice.

With systemd and other init replacements, it's likely a few lines of config file i have to rewrite. Its much less effort to ship or adapt to a few of these than have a init script that works everywhere.

About other unixes: calm down, this is some process that supervises other processes, this is in no way comparable to making libc incompatible. I assume we're talking about servers here that run off the shelf distributions. For (virtual) appliances and embedded devices / firmware everyone will roll their own images with whatever init they're happy with. We don't have any influence on what commercial vendors do. If AIX feels like an 80s system (i know it's modern and powerful at the core) that's IBMs decision, but i don't hear any complaints that Linux distributions don't ship ksh in vi mode as /bin/sh anymore.

So, in this particular market and with the problem at hand, i don't see how and why Linux should wait for the sysvinit replacement that is able to make everyone happy and will magically be adopted by everyone.

And if some day illumos will succeed Linux, I'm sure people will manage to port their 10 lines of service config over.

josteink3• 12 years ago

Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products, and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.

I think it's a shame most of the original page comes off as backwards thinking, Unix nostalgia and FUD like claims.

Because this one thing is actually quite important and something we should care about.

You can claim that Linux is now Unix and everything else is just niches. Great. Like Hurd. Clearly a play-thing. No point being portable enough to work there.

However back in the days, Unix was the real thing and Minix/Linux was just a toy itself. But hadn't software initially been portable, Linux could never have risen to what it is today.

When we are making an init-system with Linux kernel-dependencies, and making other core platform services like DEs dependent on this init-system again, we are tightening the bonds beyond what's useful, effectively hindering other platforms from ever gaining mass adaptation, even if they should otherwise deserve it.

SO while I appreciate systemd in general there are aspects of this development I indeed thinks deserves some more and warranted criticism.

mordae• 12 years ago

Contribute to and use distros like Slackware and CRUX that follow traditional Unix paradigms.

Made my day. Emphasis mine.

josteink3• 12 years ago

The good thing about Slackware is that it acts as a timemachine for how Unix/Linux used to be back in the mid-90s.

When the neckbeards comes around complaining about "Unix philosophy" you can always tell them to use Slackware. And then watch them go silent.

_pmf_• 12 years ago

At https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems all of the features that are unique to systemd are immediately something that I'd rather not have integrated.

adimania• 12 years ago

It is Linux. Let systemd live and if you don't like it, switch to upstart. No one is stopping you.

lmedinas2• 12 years ago

Actually it's not like this. On FOSS when there is no manpower distros need to make a choice: supporting the software themselves or pick the maintained solution. So when upstart developed slowed down, by other words Canonical pulled resources from it, it was when they made the decision to switch to systemd.

Also the cost of maintain it and adapt applications who are tied to systemd is much more larger than adopting syetemd.

The only viable solution i'm seeing right now is: Use a mainstream distro with systemd or switch to other one which maintains their own init system like Slackware or Gentoo.

chronid6• 12 years ago

It's (slowly) becoming impossible.

pekk4• 12 years ago

This is the "TempleOS impulse". The feeling of disgust with byzantine complexity, driving an impulse to start clean and chase the money changers out of the temple

mrmondo• 12 years ago

For Linux to keep evolving, part of evolution is mutation, the strong will flourish while the weak will die.

Regardless of what init system is right or wrong, the beauty of the Linux ecosystem is we can afford for different distributions each to make different decisions.

Systemd seems functionally better than both sysvinit and upstart and it certainly doesn't seem to be the root of all evil like this article makes out.

I don't believe that everyone boycotting systemd over what's currently out there will aid linux in any way.

clarry2• 12 years ago

Except that making certain decisions can become prohibitively expensive if it means replacing a behemoth everyone and everything depends on.

chronid6• 12 years ago

When everything will use systemd (because all the "core system" is starting to depend on it, wayland included) how do you evolve out of it? Rewrite the entire lower level of your system AGAIN? That does not help evolving rapidly, in my opinion.

therealunreal• 12 years ago

That's funny. So what you're saying is that we shouldn't rewrite the lower level because it'll be harder to rewrite it later on.

prima-facie• 12 years ago

an abhorrent and violent slap in the face to the Unix philosophy

I'm tired of all this UNIX philosophy crap. I have been using Systemd for more than a year now, on Archlinux, and it has been a delightful experience.

It works out of the box and it gets a lot of things right. Journald is quick & easy to use and a real help in finding problems. No more searching around in log files and grepping. Dependencies between services are handled by the init. Services start with maximum parallelism. Writing .service files is really easy.

It simply has better UX than any other init system, and it's supported by a lot of distros. This means standardization and progress. No more developer time wasted on sysvinit scripts.

The posted link is the same FUD that I have been reading for the last year on various forums. Even if systemd can be a single point of failure, it's still way more stable than anything we have used before.

voidz5• 12 years ago

I'm tired of people who are tired of hearing about UNIX philosophies and call it crap.

Gonzih• 12 years ago

For me it always feels like people who are bashing on systemd never actually used it. I was very concerned about systemd for long time. And nowadays I use it on all my machines/servers. And it just makes my life so much easier. I'm happy. I like it. I can agree with lot of points on this website. But still systemd makes my happy. So sorry, but no.

midas00710• 12 years ago

For 99% of uses, esp desktop, laptop, embedded... it's great.

For that tiny percent of use cases where services can do all kinds of crazy things and there needs to be extra control, other things like supervisor, foreman_god, daemontools/runit come into play. There are use-cases not many people have to deal with or even exposed to, yet are important considering the impact (say downing a major service like Gmail).

mrweasel3• 12 years ago

We just install daemontools on all of our servers for our own stuff and let the system packages use whatevers the default in the distro, they seem to live happily together.

I suspect that one issue with systemd is that it aims to solve very real problem, but they are problems that not many noticed. Most of the stuff that's highlighted as benefits of systemd are things I never experienced, either I don't thing advanced enough or the issue has already been addressed by the distro.

Most of us are just going have some daemon/process that we want to start at boot and for that purpose systemd is going to look like massive overkill and overly complicated. That might be mostly a documentation issue, systemd could benefit for a "So you want to start at process" guide.

blueben• 12 years ago

Seems the authors forgot to give themselves the credit they deserve.

https://forums.darknedgy.net/profile.php?id=589 https://forums.darknedgy.net/profile.php?id=373 http://billyest.es/About_Me

ef47d35620c1• 12 years ago

I don't know much about systemd, so I can't say either way.

So long as I can still get syslog style plain text logs, then I have no objections. Unix and text log parsing is unparalleled. If simple text log parsing and manipulation is removed (all binary with only xml or json), then I'd be very opposed to systemd.

coldpie2• 12 years ago

The short story is systemd's logs are "binary", but they have tools to transform them into whatever plaintext format you like.

fidotron• 12 years ago

Lennart is rapidly becoming the new Drepper.

As long as characters like this persist Linux as a direct end user system is going nowhere, and it will remain a lower level component abstracted away by higher level platforms, as in Android or Chrome OS.

Spittie• 12 years ago

Okay, I like to think as myself as an open minded individual. I'm not a systemd fanboy either, I just research and use what I believe it's better for myself. There is a reason why I can't consider the anti-systemd guys seriously: It all seems FUD to me. Take for example point 8, "you have to reboot to update systemd. Okay, not really, but the update might go wrong!". Really?

Going point by point:

1. As the site says, systemd is both an init system and a collection of programs that make sense to have in a system. One can already strip most of everything from it (I think only journald is mandatory), and there is usually a stable api between every component, so one can simply replace them.

In fact, I believe that half of the complains about systemd would disappear if it all the tools were developed in a different repository and not under a "systemd umbrella" (Isn't one of the major point pro-BSD the fact that the base system is all developed together?)

2. If you want to use systemd but have plain-text logs, journald can pass everything to syslog and similar daemons. What everyone forget is the bonus that journald provides: no more "cat /var/log/*.log | grep <program> | sort -u" and hope that applications log in the same format, I have everything in a single place and can browse them by unit, by user, by time, by urgency...

3. I can agree with that. But it's not that sysinitv or upstart worked on non-linux systems (without ugly hacks)

4. And? I'm not sure what's the problem here. udev and dbus are mandatory by pretty much anything that's not a .sh script nowadays.

5. Okay, fair point. "It assumes that users and admins are dumb" can you really blame them?

6. Fair point again, systemd is bigger than sysinitv. But that's almost saying that we should all use microhttpd instead of nginx/apache because it's smaller.

Also the simple fact that it's included in RHEL 7 mean that it got audicted by RH, which make me feel safe.

7. That's just FUD. Here's Gnome 3.10 running on OpenBSD: http://undeadly.org/cgi?action=article&sid=20140219085851

Gnome will depend on systemd when under wayland, that's instead a fact. Actually, on logind, which has an api that anyone can reimplemnt (https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...)

8. Not true, again. Right now, on my system:

   pgrep -l systemd
      1 systemd
      354 systemd-journal
      386 systemd-udevd
      766 systemd-logind
      1190 systemd
      1754 systemd

Also, I still fail to see why "it's big, it will fail" is a thing. What matters is code quality, not size.

9. Fair point.

10. This might or not be possible, I don't have much experience in writing unit files so I don't really know the limits.

11. Nobody is forcing anyone to adopt systemd. It's getting adopted because distributions and developers think it's better.

And after months/years of complains about systemd, I still haven't seen anyone trying to produce anything that has the same advantages for sysadmins and programmers.

Really, that's how it feels: "I'm going to complain and complain and complain, but I won't lift a finger to change the course of events".

Can anyone make a point in favor of sysinitv (or against systemd) without bringing in abstract concept as "Unix philosophy" and plain wrong facts?

meapix2• 12 years ago

6. is a big deal for me. 9 CVE since 2011? that's crazy in combination of "single point of failure".

exelius4• 12 years ago

Yeah, but keep in mind that:

1. It now has a lot more attention focused on it, so it will get more scrutiny.

2. Unix admins have always been wary of the bleeding edge; distros are adopting systemd today, but those distros themselves are unlikely to see wide production adoption for a year or two.

3. If the systemd team's processes are not up to snuff, a major distro will fork it and run it themselves. If the criticisms have any merit, others will follow. It's why open source is such a great model for critical system software: it's as pure of a meritocratic model as you can get (well, if you accept the fact that merit is based on adoption.)

Basically, any new critical unix process is going to have these types of issues. The fact that systemd has a lot of support basically ensures it will get a lot of attention and bugs/security holes will be fixed.

pjc50• 12 years ago

Over-complexity was a major contributor to the failure of OpenSSL. I think there's a real danger of building an overcomplicated system that sets us up for problems in the future. Especially as it ties into everything, presenting a large attack service from other parts of the system that are supposed to be lower privilege.

I've accepted udev, but I'm still wary of dbus.

exelius4• 12 years ago

I agree with you. The whole "movement" against systemd seems to be "this is very different than the way we used to do things!" Of course it is; computing has changed a lot in the last 30 years since sysvinit was designed. We now care about things like power management, hot-plug devices, etc. and the only way to ensure a consistent method of handling them is to have a single control point. The kernel is also a single point of failure by necessity; so it's well audited and a lot of work goes into making sure it is rock-solid. Because systemd is now the de-facto heir to sysvinit due to its inclusion in almost every major distro, I suspect it will get the same level of care and oversight.

A lot of these complaints boil down to the fact that systemd is a single point of control for a lot of different functions. IMO systemd actually reduces overall system complexity by creating a unified interface for launching any sort of automated executables.

Niten2• 12 years ago

4. And? I'm not sure what's the problem here. udev and dbus are mandatory by pretty much anything that's not a .sh script nowadays.

I don't know that this was the author's original meaning, but I think the much bigger problem is that udev and (k)dbus have become dependent on systemd. This has caused headaches for the Buildroot team with udev, for example:

http://lists.busybox.net/pipermail/buildroot/2013-March/0681...

How do systemd's proponents respond to these problems? GKH will say "just use mdev":

https://plus.google.com/111049168280159033135/posts/R387kQb1... (conversation about halfway down)

And if you need udev's features after all? "If you disagree with the current developers about decisions like this, then fork. And be prepared to handle the fallout." As in, be prepared for endless public derision by Lennart, GKH, Koen Kooi, and everyone else involved with systemd, as was directed toward everyone working on the eudev fork just for daring to make a version of udev that was no longer tied into systemd.

The author of "boycott systemd" complains that it is "heavily desktop-oriented". I actually like systemd, but this is a legitimate concern for a huge number of embedded Linux users, especially as systemd continues to assimilate peripheral projects. The concern is made much more severe by the confrontational and childish attitude adopted by systemd's developers and lead promoters in such matters.

Hello71• 12 years ago

Addenda:

2. So? Like text files can't get corrupted? At least journal has checksums to ensure that data is not unknowingly corrupted.

4. If I recall correctly, systemd can be used with static dev (with limited functionality).

5. That's not what I've gotten (Gentoo). Also, if it's an issue, it can be turned off.

it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical

Isn't it a good thing if stuff is smaller?

8. This isn't an actual argument. systemd has code to catch errors and infinite loop the program. It's not even internally consistent. "have fun rebooting, except my argument isn't even valid because systemd has code to reexec"

9. No, systemd is primarily concerned with glibc. Patches to run on other libcs are accepted if they do not unnecessarily complicate the code.

10. Without actual examples, this is a useless argument at best.

11. This is not a point, just name-calling.

makomk6• 12 years ago

1. As the site says, systemd is both an init system and a collection of programs that make sense to have in a system. One can already strip most of everything from it (I think only journald is mandatory), and there is usually a stable api between every component, so one can simply replace them.

The only stable APIs in systemd are the ones that the whole agglomeration of programs provides to the outside world. Anything else can and will change and break without warning according to the systemd developers.

3. I can agree with that. But it's not that sysinitv or upstart worked on non-linux systems (without ugly hacks)

Didn't matter, they had their own init systems and until systemd came along very little software depended on a particular init system.

Gnome will depend on systemd when under wayland, that's instead a fact. Actually, on logind, which has an api that anyone can reimplemnt (https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...)

According to the chart someone else linked, which I think is by the systemd developers, logind cannot feasibly be reimplemented and the systemd version can't be used by anyone else: http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... In practice, no-one has managed to reimplement anything beyond the most trivial APIs exposed by systemd. Some (like the whole new-style daemons API used by many daemons ported to systemd) literally cannot be implemented by init systems that aren't structured the same way as systemd.

11. Nobody is forcing anyone to adopt systemd. It's getting adopted because distributions and developers think it's better.

In at least some case, it's getting adopted because important software has been rewritten upstream to depend on systemd.

fmoralesc• 12 years ago

logind cannot feasibly be reimplemented

I disagree that is what the chart shows. A bit later in the document they say

If you decide to reimplement one of the APIs for which "Reimplementable independently" is "no", then we won't stop you, but you are on your own.

so I think they mean to say sth different than "the APIs can't be tried to be implemented at all".

I think when they say "reimplementable independently" they mean "to develop a feature-par system", which might be way too strict. For example, the unit format also is marked as "not reimplementable independently", when it is clear it is in some form; plausibly, some attributes one can specify in unit files as implemented by systemd can't be replicated in other systems, but that doesn't mean there can't be similar, partially-compatible implementations. I guess in some (most?) cases, those might be enough.

Also, logind's case might be marked as not reimplementable independently to discourage forks like Ubuntu's, which caused their version to remain stagnant when the API changed upstream. I'm not sure, but logind's API might still be a moving target, so a reimplementation might have to face some issues.

peterwwillis• 12 years ago

tl;dr systemd crashes systems, is incompatible with other distros and OSes, adds admin difficulty, breaks applications, and introduces security holes

---

systemd was created in order to improve the speed of booting up your system. I'm serious. It was created because waiting a minute to boot up your machine once was too long.

In order to accomplish those faster boot times, they ripped out the stock init system model, and created a monolithic, non-portable, non-backwards-compatible, kernel-version-specific, Noah's Ark of API calls and custom tools which use binary formats and incompatible IPC methods to start programs that were never designed to run that way. They made obsolete virtually every aspect of the operating system which used to work with existing applications to start and maintain the running of userland programs. For faster boot times.

Of course, most of you don't care because you don't have to maintain your system, as long as it just works. What does this mean for people who do work with the system?

First off, building tools that work with the system are now more complex. It used to be you could use any i/o or ipc method to do anything you wanted. Now you have to look up and call and API call - and if the API call you want isn't in systemd's tool, or it doesn't expose it in a way you can use in your program, tough. Better become a C programmer fast.

Second, better be careful how you update your system. Every version of systemd, and any software it depends on, could crash your entire machine if a bug is introduced. I weep for the poor sysadmins who push out an update to thousands of machines only to find a strange bug which takes them all down, all because systemd decided having an enormous codebase was worth booting 20 seconds faster.

I hope you've got money for a security audit. systemd has had nine security vulnerabilities in the past four years. For comparison, sysvinit has had one CVE - in 1999. I haven't found any CVEs or security bulletins for upstart, which sounds amazing to me.

When it comes time to porting your application to Linux, you don't get to just write it in a way that would normally work on most Unix-like systems (which would, at this point, be virtually every operating system that isn't Windows or Mac OS, and now Linux). Now you have a new porting target specifically just to get your application to run, and then you get to deal with the normal porting issues.

At the end of the day, systemd is a culmination of two ideas, with one result. One idea is that a "superior design" with "advanced features" is the only benchmark in which we should design and run a system. The other idea is that we don't need to keep compatibility with legacy systems or alternative platforms, because fuck users, admins, developers, security analysts, distro maintainers and portability teams, we want faster boot times , damnit. And it's Advanced! The result? A big fucking mess of complexity that breaks everything that came before, introduces security holes, makes it more difficult to modify or maintain your system, and breaks compatibility with other systems (even Linux ones).

But aside from all that, systemd is great.

silon3• 12 years ago

Does the old "good standard will have 2 or more implementations" apply here?

ausjke• 12 years ago

I hate to be personal, the guy leads systemd is indeed a genius, but genius could be more destructive, his way to do things for linux/unix is too intrusive for whatever he has done so far.

it's always good to try a disruptive way on the side before it matures and gets accepted gradually, however with the direct support from Redhat(where he is an employee) this systemd thing carries much more power than a typical open source project, sigh.

I would rather stay with sysvinit instead of something like this.

I think he should be employed at Microsoft to help them revamp their OS or whatever, make it or break it there, but please stay out of OSS.

evbogue• 12 years ago

If this person had been running systemd, this website would still be up.

binaryapparatus3• 12 years ago

I see this as related and it is less than a month old: http://www.muktware.com/2014/04/linus-torvalds-happy-systemd... https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF

I am not much of a systemd fan so I may be biased but it is interesting read anyway.

SnakeDoc4• 12 years ago

The Canonical fanboys are just upset they lost out on their inferior technology and now are trying to do everything possible to stall it. systemd is unquestionably a big step forward, Upstart is only a step to the side. There is a reason the serious linux distros (no, Ubuntu is not serious, it's a toy for newbies to use on their desktop) have all chosen systemd. There is also a reason some of them tried Upstart and decided it was not good.

pekk4• 12 years ago

No, the Canonical fanboys are following Mark Shuttleworth in accepting systemd as the future for Ubuntu.

This is a different set of people.

caryhartline• 12 years ago

Do you really think "Canonical fanboys" would ever suggest Slackware as a distro choice?

dschiptsov• 12 years ago

There must be already a name for this particular fallacy, when a bunch of people considered themselves "knowing the [only] right direction" and especially "destroying and discarding everything to build it up from scratch as they know will be the best for all". A-la those uneducated, ignorant, but cook-sure and self-confident lower-class revolutionaries in Russia hundred years ago who were unable to grasp that "evolved [social] system" has some subtle "laws , forces and reasons" behind it and that uncomprehensive, even unreadable philosophy or a naive, oversimplified model [of economics] is much worse than no philosophy or model whatsoever. Self-regulated (and especially evolved) complex systems are "smarter" than any bunch of individuals ,)

midas00710• 12 years ago

Until there's a viable alternative, it looks like whining.

SnakeDoc4• 12 years ago

I think the website is missing the legal disclaimer "Paid for by Canonical (because we're bitter)".

pekk4• 12 years ago

Again no, Canonical wants to sell services around Ubuntu, which will soon be based on systemd, by decree of Mark Shuttleworth.

Wanting to do that, it doesn't make sense that they would shill for Slackware at the top of the page.

SnakeDoc4• 12 years ago

Just pointing out it's not that difficult to "roll your own" linux distro. It'll take you an afternoon if you haven't done it before... and you can very well choose to keep using sysvinit if you want (my personal distro will use sysvinit probably until the end of the year when I have time to figure out how to integrate systemd).

lasermike0262• 12 years ago

I hate systemd. I will avoid it when every possible. It is an abomination. I hate upstart even more.

pekk4• 12 years ago

Did you read the page? It doesn't advocate upstart.

lasermike0262• 12 years ago

Yes, I did read it. The reason I threw in upstart is because these inits have similar design philosophies.

legulere• 12 years ago

They single out Lennart Poettering but don't have the guts to write their own names under their arguments. You can't take this serious.

oldmantaiter• 12 years ago

Considering the adoption and improvements, I'm on board with the "standardization" of distros with systemd.

Can't stand upstart and it's "Oh you wanted to restart your daemon, but I won't run the pre-start/post-start/post-stop actions you've configured me to", but that's just me.

bitwize3• 12 years ago

The "debate" about systemd is like the "debate" about global warming: all the people with any knowledge of the issue fall on one side, and the opposition consists largely of the ignorant and butthurt.

Systemd has won by being vastly superior to any alternatives. I suppose it's all right to use something else but the community has embraced systemd as the correct solution, and you lose community support and assume all the risk of breakage if you do not stick with systemd.

Niten2• 12 years ago

Systemd has won by being vastly superior to any alternatives.

Systemd is better than Upstart, but it won in no small part due to politicking and strategically merging other projects that everyone else depends on.

voidz5• 12 years ago

I fell in love with FreeBSD's init style, which is what I switched to when the move Archlinux made broke my systems. Due to virtualisation demands I had to switch back to Linux, and chose Funtoo (a Gentoo fork) with the OpenRC init system.

I've never been happier.

ciupicri2• 12 years ago

Isn't FreeBSD's init system monolithic?

duncan_bayne• 12 years ago

I recently installed and investigated PC-BSD for this very reason; a friend who's a BSD user commented that systemd has been driving BSD adoption very hard recently. I intend switching to PC-BSD for personal and work use within the year.

Boycott systemd

Related Stories