Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I dislike systemd

steven-mcdonald.id.au

Post reply on HN
Print view View original

141–150 of 254 posts

Re: Why I dislike systemd

#141

Post by EmanueleAina »

keypusher wrote: post #6

I agree with most of this, especially the fact that complexity has simply been shifted to other places. It's much easier for me to read a systemd unit file than it was for me to read a complex set of init scripts. The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files. Having to specify After=…

> The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files

How that's different from sysvinit?

> The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary.

`journalctl` prints plain text on its stdout, so you can think of it as a glorified `cat` if you don't want to use its extra features. On the contrary, if one needs its extra features on plain text log files one usually resolves to using fragile parsing hacks.

> The venerable "hostname" command is now "hostnamectl" because it must go through systemd

They do different things, `hostname` only reads the current hostname. `hostnamectl` is able to set the hostname, standardizing what used to be a per-distribution custom mechanism. Despite being shipped with systemd (to make sure everyone can rely on it) it doesn't actually depend on systemd and in no way goes through it.

> They have also replaced chroot with systemd-nspawn, and made it so you cannot even use systemd while in a normal chroot.

`chroot`'s purpose has never been the ability to run an init system inside it, no matter if it is sysvinit or systemd. On the other hand `systemd-nspawn` creates isolated containers, I'd be surprised you can't run sysvinit inside it.

Again, you're comparing apples to whole orange trees as the systemd utilities do much more than the traditional ones you mentioned.

Re: Why I dislike systemd

#142

Post by exelius »

vezzy-fnord wrote: post #135
exelius wrote: post #125

Earlier quoted context omitted.

Once upon a time, we were obsessed with efficiency and speed of code. We created powerful, but simple systems like sysvinit, and we designed to optimize speed in 80% of use cases. The Linux you grew up with used to mostly run on x86 machines, except the majority of Linux devices now run on ARM with different power requirements, hardware, drivers, etc. than x86 ever had to deal with. The increasing complexity in the u…

Your implication is that sysvinit was designed for speed. I can't seem to find much evidence for that. In fact, sysvinit's purely synchronous nature and its reliance on the patterns of symlink farms to represent system states in the form of "runlevels", along with the tendency to write bloated shell scripts for it because no one ever bothered to write a proper rc/service runtime framework until much later (in contras…

I think it was originally designed for speed (or at least for simplicity) because it only dealt with a handful of use cases that worked well. Granted, they were the more general use cases, but writing a dependency solver into the init system in 1980 would have negatively impacted speed to an unacceptable degree. Applications back then weren't modular enough for it to make a ton of sense anyway. So they traded flexibility for deterministic execution that was "fast enough". That's not a tradeoff you have to make anymore; CPUs are fast enough now that you can do all the thread syncing you need without worrying about the overhead too much.

But flexibility and modularity is more important now than maintaining compatibility with decades old init scripts. Some of those modules may need low level system access for a variety of good reasons. The kneejerk reaction is to apply network server use cases to every Linux feature, but Linux is a whole lot more than a network server these days.

Re: Why I dislike systemd

#143

Post by EmanueleAina »

weland wrote: post #117
madez wrote: post #107

Earlier quoted context omitted.

In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. Where is the evidence?

All over their bugtracker, but the most famous one is here: https://bugs.freedesktop.org/show_bug.cgi?id=76935

Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple applications still do for other purposes).

Arguably, the tone of the discussion resembles more the usual LKML tone rather than the one observable on the systemd mailing list.

Re: Why I dislike systemd

#144

Post by EmanueleAina »

pnathan wrote: post #105
stephen_g wrote: post #9

Earlier quoted context omitted.

I'm not a professional sysadmin, but as a developer with a bunch of virtual servers systemd has only made things far easier. Writing init scripts used to be a real pain, now I can set up a unit file in two minutes and it works... Maybe there's something to be said for "sysadmins who want to be able to model the entire boot process and run-state in their head" but with correct information about dependencies and so on,…

> Writing init scripts used to be a real pain, now I can set up a unit file in two minutes and it works... I've always found init scripts straightforward to read and write, even though I don't develop them often. I don't care for the upstart/systemd/OSX approaches. I don't want to digest another manual to do what I can do in bash easily.

If your needs are simple, the resulting unit file is trivial and you can basically copy and paste from any example without looking at any documentation.

If your needs are complex, you have better chance by mixing different options in the completely declarative syntax of systemd than mixing shell snippets from different scripts using different styles.

In any case systemd happily launches LSB-compatible init scripts, you literally don't lose anything.

Re: Why I dislike systemd

#145

Post by EmanueleAina »

thaumaturgy wrote: post #32
anko wrote: post #17

Earlier quoted context omitted.

> Writing init scripts used to be a real pain, now I can set up a unit file in two minutes and it works... This. I'm not saying systemd is the best answer, but I really think sysadmins could learn a thing or two from developers. Nearly every custom init script I've ever seen has bugs, and isn't portable between systems. Where are the unit tests? Code reuse? Focus on maintainability/readability? Shell scripting used t…

Sysadmins would say that developers could learn a lot from them. Like, documentation, maintaining backwards compatibility, sane upgrade processes ... Don't throw stones in glass houses and all that. We all could stand to learn things from other people. Sure, sysadmins could stand to be better programmers, but software developers tend to forget that software is just a tool, and sysadmins use it like a tool. They just…

> but software developers tend to forget that software is just a tool, and sysadmins use it like a tool. They just want to get in, get out, and move on to the next problem

Which is exactly why developers don't get to write any documentation other than the bare minimum: software for the client is just a tool, once it is running they want developers to move on to the next problem, not wasting time on any additional documentation (which, arguably, is not strictly a developer task, more a QA one).

Re: Why I dislike systemd

#146

Post by BFay »

stefantalpalaru wrote: post #67

Why would you punish yourself with various *BSDs when you can have OpenRC and more advanced ports on Gentoo? Do people really associate systemd, Gnome and other nuisances with Linux?

Don't you have to build every package from source with Gentoo? I can see where that would be useful, but isn't it really time-consuming (or punishing, if you prefer that word)?

Re: Why I dislike systemd

#147

Post by EmanueleAina »

hedwall wrote: post #39
anko wrote: post #17

Earlier quoted context omitted.

> Writing init scripts used to be a real pain, now I can set up a unit file in two minutes and it works... This. I'm not saying systemd is the best answer, but I really think sysadmins could learn a thing or two from developers. Nearly every custom init script I've ever seen has bugs, and isn't portable between systems. Where are the unit tests? Code reuse? Focus on maintainability/readability? Shell scripting used t…

>I'm not saying systemd is the best answer, but I really think >sysadmins could learn a thing or two from developers. >Nearly every custom init script I've ever seen has bugs, and >isn't portable between systems. Nearly every custom init script is written by a developer for the product you desperately have to run because development wanted it, not bothering to give us sys admins time to look into the: packaging, conf…

> My deadline for almost all work I do is "yesterday".

Having more or less worn both hats, it's exactly the same for developers. :)

Re: Why I dislike systemd

#148

Post by EmanueleAina »

empressplay wrote: post #11
ghshephard wrote: post #7

There is something epically beautiful about OpenBSD's consistency over the last 10 years. I swear that a 2004 OpenBSD sysadmin would be close to 100% efficient with a circa 2015 OpenBSD system, despite the absolutely massive number of improvements and changes that have been made with the operating system. Once systemd starts to get traction, it's cognitive overhead is going to become a real problem for sysadmins who…

Except that there's no reason for systemd's model to "get traction" outside of desktop-focussed Linux distributions, since a "better user experience" is it's current raison d'etre. So no, I shouldn't need to have to "learn to trust the operating system / systemd" on my servers -- it has no reason to be there!

Many systemd features are explicitly tailored for server workload (eg. resource management), and a particular effort is being put over container-based deployments.

CoreOS has been quite successful in basing their own infrastructure on systemd and with rkt they are moving to use systemd even more.

Re: Why I dislike systemd

#149

Post by EmanueleAina »

justincormack wrote: post #64
empressplay wrote: post #11

Earlier quoted context omitted.

Except that there's no reason for systemd's model to "get traction" outside of desktop-focussed Linux distributions, since a "better user experience" is it's current raison d'etre. So no, I shouldn't need to have to "learn to trust the operating system / systemd" on my servers -- it has no reason to be there!

The model where services do not daemonize and write a pid to a file is actually hugely better for servers. Most of the rest of it is not useful.

The per-unit cgroup and the ability to kill it is rather nice too, without delving in the container-related features where the systemd server-side support really shines.

Re: Why I dislike systemd

#150

Post by EmanueleAina »

jfindley wrote: post #73
xroche wrote: post #62

> nearly everyone (or at least the most vocal crowd) seems to either love it or hate it "At least the most vocal crowd". Which means that most people DO NOT CARE, and the systemd war is beyond ridiculous. As Linus said, > "I don't actually have any particularly strong opinions on systemd itself."

The systemd war is probably the best thing that could have happened to ensure widespread adoption of systemd. It allowed the supporters to lump anyone with any concerns or objections in with the frothing-at-the-mouth haters, and completely ignore them. I don't hate systemd. I like what it's trying to do, and I don't hate the big-picture implementation either. But I, and many others, have a bunch of concerns around so…

Why is resolved feature-creep? It's rather nice to have working name resolution out of the box when coupling it with networkd and firing up a container.

I mean, it's not my standard usecase in this moment of my life, but I see how it can be useful.

(Also, your last link reports that "This bug is for livecd-tools which has been fixed", I don't know what's the point you're trying to make.)

Post reply on HN