Without Systemd

I don't know why this is getting downvoted.

I used to install systemd from backports on wheezy only because I don't have to write sysv-init scripts that way.

I think it would still have to be some kind of structured format (one json object per "line", for instance), so that it could keep all of the metadata. On the other hand, you can use journalctl --output=json to get exactly that, so...

I have a grief with plain text logs. They are really nice if you want to read them manually with vim or less, but are super painful if you want to parse them automatically.

It doesn't help much that a fair number of logging libraries have buggy formatting to an extend that you can't safely parse plain text log files sometimes.

For example this bug (mostly fixed by now) https://github.com/sirupsen/logrus/issues/531

Then quite simply you haven't been listening or paying attention. I'm a gnu/gpl proponent, so I come into the systemd debate leaning towards the side that is simply requesting (why should they even have to? They don't!) init diversity. I've heard plenty of reasoned debate between both sides though, and things like "why people continually try to remove" have been layed out time and time again.

So after showing you aren't even aware of the current debates which are still ongoing, you try to criticize their points as being "too hung up on sticking to the UNIX philosophy"? That's not a good description of the antisystemd sides arguments, because the positions I have seen taken are more varied than that. Essentially that was just a strawman you took out of your hat because its one that sounds good.

Oh and if it's worth anything, as a sysadmin who has to support all the distro's, systemd has not been a panacea as touted by any stretch of the imagination. For example, logging. Why is that now a systemd thing? Just cause systemd is the creepy uncle that likes to touch everything it can? So I'm just gonna pipe that crap into syslog anyway... and don't get me started on LP's shenanigans.

I fully support devuan and all others in their pursuit of init freedom, because the user deserves to have choice. I hope fully gplv3'd init wins (systemd being agplv2 I think).

I had just recently tried to install this, but then I encountered a very strange bug with Firefox where any tab crashed immediately upon opening with some sort of IPC error, and I tried searching around but couldn't find any mention of it anywhere. I ended up just giving up on fighting systemd and install Xubuntu.

I love runit. It's simple and elegant, is in tune with the Unix Philosophy, and doesn't try to absorb a ton of unrelated, independent services into itself like systemd does.

If something like runit was chosen by RedHat and the distros that followed it, this holy war wouldn't exist.

Upstart was on the good path, but had its own issues as well. Detecting which process it should track was rather tricky in some cases. For example any server optionally spawning an extra command before forking is not possible to configure in a generic way. Shutting things down properly without cgroups can be bad too. (It's server's fault, but good init can help here)

I imagine it would get better if upstart got a serious v2 or higher, but it seems it won't get serious changes anymore.

Isn't being somewhat monolithic Linux-like in itself? I've always been under the impression that Linux is a monolith kernel approach to Unix. Unless we're all switching to Hurd, caring about a monolith init system while running the Linux kernel seems philosophically inconsistent.

> And its adoption was largely driven by decisions by large distributions, rather than organic growth.

Yes, that's not stated enough. According to systemd proponents, systemd was demanded. Truth is I've never witnessed or heard about a rush towards RedHat distributions because they had systemd first. Never. That's what should have happened if systemd was so attractive, shouldn't it? Nor have I ever heard a user demanding systemd in order to solve his problems.

It was pushed by distribution maintainers, not users. I remember when Arch decided to switch to systemd. The maintainers made false claims (which were repeated by other distributions later) and false promises.

They claimed that systemd would relieve them from the terrible burden of maintaining init scripts. Many times have I asked to give example of this burden, I was never given an answer. Of course, the software packages are mostly all already present, there are very few new ones coming who require an init script, and the existing ones have had their script running for years and years, there is very little fixing or evolution in those. It's difficult to give proofs of a burden that did not exist, but that claim persisted, despite never being backed by anything.

Arch maintainers, in order to get allowed to switch to systemd, promised that the previous init system would stay beside systemd and be maintained. That was a swindle: once they got the agreement to proceed with systemd on that condition, it was a matter of only a couple of months for them to ditch that promise. And 6 months after, the maintainer who made this promise in order to butter the opposition up and pass the deal for systemd as Arch init, was hired by RedHat...

3: Users are not given an easy way to avoid using libc or the kernel calls or ASCII text either, so that a non-issue unless you already decided that it's important not to use those things.

I'm sorry. But the "Unix" way is to do one thing well. Why is it that every single app needs to support a "daemon" mode? It is the biggest pain in the but.

I love systemd. Finally a sane solution on linux.

> One of the main problems was the speed with which systemd was rolled out on all the major Linux distros, despite it being relatively immature and very controversial at that.

When Debian/Ubuntu defaulted to systemd, systemd already had 5 years of existence. In Mageia, 2 years, while Arch Linux, took 2.5 years. Fedora was the only distro that ready adopted systemd by default very soon, in a year and half [1].

Compare this to upstart, that had an initial release in August 24, 2006 and adopted in the same year in Ubuntu 6.10 (and by default, since I don't know any distro that maintained a compatibility shim for those who didn't want to use upstart, like happens in systemd nowadays).

> The second major issue is it growing way out of the bounds of being just an init replacement, thereby violating the so-called Unix Philosophy of doing one-thing well. For a user app to do that is one thing, but for a core OS component to do that just smells way too much like forcing Linux to be more like Windows, which a lot of hard-core Linux users are ideologically opposed to.

However, systemd is not a single binary. Each additional funcionality is shipped in different binaries, so the init part only cares about init, journal part only cares about journal, etc.

This also happens in other projects. GNU Coreutils (ls, date, cut, du, df, echo, mkdir, etc.) for example, is a collection of binaries that do each its own part. It does as much sense of calling systemd violating Unix Philosophy because it has multiple funcionality implemented in the same source code as calling GNU Coreutils violating Unix Philosophy by the same reason.

> The third major issue is that on most major Linux distros, users are not given an easy way to avoid using systemd, no matter how much they hate it or oppose it.

This only became a problem after systemd it seems. Ubuntu/Fedora only offered upstart, Arch only offered BSD-style init, Debian only offered SysVinit, etc...

After systemd was adopted by default people started to whine to maintainers support multiple init systems, increasing the burden of maintance without obvious benefits (who are gonna fixes the bugs if the majority of developers are running something else?).

> The fourth issue is the apparent arrogance of the people responsible for systemd, and their off-hand dismissal of mature and widely respected unix conventions.

Well, the community is as bad or even worse than the maintainers, IMO.

> The fifth problem is that when systemd breaks, troubleshooting and fixing it can be a lot harder than doing the same with an init script.

Sure, however writing scripts was much worse since even the simpler things are incredible difficult to get right with scripts (want to get the PID of a daemonized process? PID files, except that now you can have racing conditions and possible problems with locking).

I recently migrated a script init-style startup file (used by a thin systemd service) to a native systemd service in my current work. Nobody understood the script file very well, while the .service native systemd file is much simpler and obvious about what is doing.

> All of this adds up to a storm of controversy that the systemd people mostly brought upon themselves. Had they just been more humble about their creation and waited until it was mature and well-tested and did all the wonderful things they claim it could and should do instead of stuffing what was widely seen as a broken-by-design piece of garbage down everybody's throat, maybe much of the Linux community wouldn't have been nearly so outraged by it.

Using words like "broken-by-design" without given reasonable arguments will only make your argument less convincing, you know?

[1]: https://en.wikipedia.org/wiki/Systemd

[2]: https://en.wikipedia.org/wiki/Upstart

As someone who is a heavy Windows user, this whole thing confuses me. Someone comes along, similar to Stallman who embraces Linux in the truest form: they build something for you. It has faults. It may not be great, but it does some things well. And somehow, it creeps over & takes over. On more than one comment here, people complained about how fast systemd (not systemD) took over -- and yet, is that the author (Pottering or whatever?) fault? I think not -- this is your fault. Your friends. Mine. My friends. The random dev in the corner who found it useful & uses it & realizes the potential.

I'd be curious to see what the Amazons, WalMarts & other large ''small service Linux-y thingy'' do to get so big & scale so fast: are they not essentially using CoreOS, many containers & making use of systemd to the fullest extent possible?

I just don't get it. Linux is all about choice (and yet nobody realizes too much choice is bad - just look at all the distros you have). Someone fixes it all for you & you get upset. Someone takes power away from Sysadmins & shifts it just a little more to Devs because they can't get work done. You get upset (I am admittedly in that camp) but, from the people that I hear good things about systemd, I hear great* things that convince me it's wonderful. The bad camp can't say the same thing on the same scale: it's just blame & resentment & frustration because they can't articulate what they don't like about it other than "It isn't the Linux way!!11Oneoneon1on1!! M$"