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

131–140 of 254 posts

Re: Why I dislike systemd

#131

Post by egwynn »

mavhc wrote: post #114
anon3_ wrote: post #33

Earlier quoted context omitted.

> I'm one of the people who jumped ship to OpenBSD in the last year or so. Ha. FreeBSD here. And so long as you get the right hardware, I find BSD to be far simpler than linux distributions out there. Ports? Beautifully elegant and simple. Configurable. Magnitudes easier than configuring rpm/debs. Getting a package approved in debian? Alioth? No offense, the wiki, all these pages on the debian website - they have no…

I used FreeBSD for a while because it had ZFS, and found Ports confusing and fragile. Maybe I was doing it wrong, but the handbook wasn't much use: "here's 4 different ways to do it, we're not saying which is a good idea". Every upgrade took ages, required reading a load of documents, and broke something. There didn't seem to be an equivalent of Debian's Stable, everything was apparently the latest release.

I also was frustrated with how poorly the handbook explained ports/packages. But now that I understand how they work, I feel like it’s an elegant system that works well. I just wish it didn’t take so much trial and error to figure it out.

Re: Why I dislike systemd

#132

Post by weland »

cwyers wrote: post #128
weland wrote: post #87

Earlier quoted context omitted.

Unfortunately, the systemd development team is not that easy to work with, which is part of why a lot of people distrust systemd the way they do. In theory, yes, it should be the way you mention it. In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. No one who has used more than one Linux distro would disagree that a unified system to control init services i…

But I think you could find a vocal minority (or several) to oppose ANY particular implementation. One of the reason the anti-systemd crowd has such a hard time gaining traction is because the only thing that unites all of them is opposition to systemd. They don't agree on what should be in its place instead -- some want to hold onto sysvinit, some want Upstart (although that's a dead end now), some want OpenRC, some…

It's very easy to agree that nuclear pulse propulsion is a bad idea for a vehicle, even among people who otherwise have very different preferences on what kind of engine they like on their vehicle.

Unfortunately, yeah, the whole debate there is unproductive. Instead of focusing on real problems, it gets stuck into an endless debate on Unix philosophy, carried among a bunch of people who aren't really sure why it's a problem if something doesn't follow it and another bunch of people who insist that they're following because saying otherwise would be bad PR.

Re: Why I dislike systemd

#133

Post by vezzy-fnord »

RVuRnvbM2e wrote: post #122
INTPenis wrote: post #63

Earlier quoted context omitted.

Couldn't/Shouldn't this be solved with some script that traces the dependencies of units? I'm not familiar enough with systemd to understand how to trace dependencies and create a complete list of all units that will run at next boot but I expect this to be doable by someone with that expertise.

systemd-analyze dot --order | dot -Tsvg > /tmp/system.svg The resulting dependency diagram may look complex, but consider that there is no equivalent functionality for SysV init scripts despite the fact that they have the same level of inter-dependent complexity .

Whether using a dependency system at all for the purpose of ordering and expressing relationships between daemons is the best approach is beyond the scope of this reply, but I just want to say that most modern sysvinit deployments did in fact have service dependencies, through the use of LSB initscript headers that were parsed by insserv(8).

It was kludgy, but there.

Re: Why I dislike systemd

#134

Post by dvogel »

RVuRnvbM2e wrote: post #122
INTPenis wrote: post #63

Earlier quoted context omitted.

Couldn't/Shouldn't this be solved with some script that traces the dependencies of units? I'm not familiar enough with systemd to understand how to trace dependencies and create a complete list of all units that will run at next boot but I expect this to be doable by someone with that expertise.

systemd-analyze dot --order | dot -Tsvg > /tmp/system.svg The resulting dependency diagram may look complex, but consider that there is no equivalent functionality for SysV init scripts despite the fact that they have the same level of inter-dependent complexity .

The complexity of the dependency graph produced by system-analyze is not present in most sysv init systems. That complexity is mostly a reflection of the efforts to make system services boot in parallel. Most sysv init scripts were blocking and executed serially, which is what allowed the simple filename prefixes to be used for ordering.

What to see your entire sysv init, as it will run every single time?

    ls -1 /etc/rc3.d/[SK]* /etc/rc.local | xargs -- cat | less
Obviously, substitute whichever runlevel you're concerned with.

Re: Why I dislike systemd

#135

Post by vezzy-fnord »

exelius wrote: post #125
empressplay wrote: post #5

I don't "hate" systemd either, I just think it's a bad approach. It flies in the face of the "open architecture" concept and stifles innovation. It discourages users from learning about how their operating system works, and it unnecessarily puts too much control of a fundamental component of the OS in the hands of a too-small number of people. None of these reflect the Linux I grew up with. Thus, I am not a fan of sy…

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 contrast to the BSDs), meant it was slow.

IIRC, one of the motivations for some distros to symlink /bin/sh to dash was to reduce boot times. Then we got ugly hacks like startpar for asynchronous script executions, insserv for parsing dependency directives inside scripts, and Debian had all the cruft behind sysv-rc just to make managing the runlevels easier.

The whole thing descended into an unmaintainable mess that performance improvements in systemd and other alternative systems were unsurprising.

Re: Why I dislike systemd

#136

Post by EmanueleAina »

VLM wrote: post #108
chousuke wrote: post #60

Earlier quoted context omitted.

It's perfectly possible to run scripts with systemd unit files, so there's no real "flexibility" lost anywhere. The primary improvement is that systemd handles by default most of what used to be boiler-plate in every script, on top of calculating dependencies automatically. Then you get integrated process supervisor capabilities so that the init system actually knows whether services are running or not. Speed was cer…

The key is the expense vs reward ratio. I don't know how to write sysvinit scripts any more than I know how to write fizzbuzz. What I do know is how to program and specifically how to write and maintain and debug shell scripts. I NEED that for other automation purposes and cannot get rid of that mandatory requirement so it used to dovetail quite well with init scripts. There are corner cases and security issues and t…

I don't think it's really fair to compare writing unit files to being able to program in shell.

True, knowing the systemd unit options is not a reusable skill, but it's not a huge effort either: the syntax is trivial (INI-inspired, the same as .desktop files) and the options themselves are rather well documented.

And for sure, these options are immensely more reusable when writing a new unit file than mixing and matching shell snippets taken from different init script using different styles and conventions.

(Not to mention how subtly tricky programming in shell is even when you're doing trivial things, see http://www.dwheeler.com/essays/filenames-in-shell.html )

Re: Why I dislike systemd

#137

Post by hhw »

joosters wrote: post #89
icebraining wrote: post #76

Earlier quoted context omitted.

$ vim /etc/network/interfaces auto wlan0 iface wlan0 inet dhcp wpa-ssid wpa-psk You can also have multiple virtual interfaces configured in the same file as above, and then just do "ifup wlan0=virtualif" to switch. Much ado about nothing.

Absolutely. It's also more secure this way, since you aren't putting the passphrase in a readable-by-any-user command line argument.

FYI, it's trivial to hide processes from other users on BSD with a sysctl variable.

Re: Why I dislike systemd

#138

Post by EmanueleAina »

thaumaturgy wrote: post #30
jveld wrote: post #19

It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being repeated in systemd. I kinda had the opposite impression. I first encountered systemd when I started messing around with arch for a couple little vps projects. At the time I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely found day-to-…

This is why I suspect that most of the divisions in the sysadmin community regarding systemd are generational. For people (like me!) who have been writing init scripts forever and can do it in their sleep, they'd prefer the flexibility and familiarity of init scripts to a new system that at first glance appears more limited. For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifyi…

You can still use plain shell-based LSB-compliant init scripts just fine, which is what Debian is still doing as they didn't want to have flag days like all the other distributions who switched.

I don't see why you should feel homeless.

Re: Why I dislike systemd

#139

Post by EmanueleAina »

pppp wrote: post #123
thaumaturgy wrote: post #30

Earlier quoted context omitted.

This is why I suspect that most of the divisions in the sysadmin community regarding systemd are generational. For people (like me!) who have been writing init scripts forever and can do it in their sleep, they'd prefer the flexibility and familiarity of init scripts to a new system that at first glance appears more limited. For people who are less experien^H^H^H^H^H^H^H^Hcrusty :-), init scripts look like a horrifyi…

I wouldn't say the init scripts on OpenBSD are complex: # cat smtpd #!/bin/sh # # $OpenBSD: smtpd,v 1.4 2012/10/26 06:51:59 ajacoutot Exp $ daemon="/usr/sbin/smtpd" . /etc/rc.d/rc.subr pexp="smtpd: \[priv\]" rc_reload=NO rc_cmd $1

Indeed. But at that point you have a DSL which is no longer obvious when one only knows about shell scripting (eg. I have no idea what `pexp="smtpd: \[priv\]"` does), so using a completely declarative language with a trivial syntax doesn't seem a huge issue either.

One may think about systemd's unit files as a set of shell variables that gets sourced by the real script.

Re: Why I dislike systemd

#140

Post by falcolas »

EmanueleAina wrote: post #139
pppp wrote: post #123

Earlier quoted context omitted.

I wouldn't say the init scripts on OpenBSD are complex: # cat smtpd #!/bin/sh # # $OpenBSD: smtpd,v 1.4 2012/10/26 06:51:59 ajacoutot Exp $ daemon="/usr/sbin/smtpd" . /etc/rc.d/rc.subr pexp="smtpd: \[priv\]" rc_reload=NO rc_cmd $1

Indeed. But at that point you have a DSL which is no longer obvious when one only knows about shell scripting (eg. I have no idea what `pexp="smtpd: \[priv\]"` does), so using a completely declarative language with a trivial syntax doesn't seem a huge issue either. One may think about systemd's unit files as a set of shell variables that gets sourced by the real script.

That's not a DSL, that's a shell script. As for what `pexp="..."` does - it's just setting the pexp variable. If you'd like to know what that does, you can just look up the bash source of `/etc/rc.d/rc.subr`, another bash script.

No DSL knowledge required, at all. Just shell knowledge, and the willingness to look at sourced shell scripts.

Post reply on HN