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

201–210 of 254 posts

Re: Why I dislike systemd

#201

Post by weland »

groks wrote: post #160
pjc50 wrote: post #58

Earlier quoted context omitted.

Polkit is a nightmare . And I agree with you on the churn. There was a time when Linux administration changed less frequently than Windows, round about the 95-XP-Vista era.

http://smcv.pseudorandom.co.uk/2015/why_polkit/

Polkit is a great idea, don't get me wrong. However:

* Like pretty much anything from freedesktop.org, the documentation is a joke.

* The security system implemented through it is next to impossible to debug. It's very easy to add "allow to happen", but I can't do things like "ok, tell me who can mount filesystems" or "give me a list of all things that users in the wheel group are allowed to do". Normally this would be trivial to implement by parsing the rule files, except that the rules are written in JS (I have no idea why) and parsed in a particular, cumbersome order.

* Probably also as an artifact of having to execute JS code to add rules, many errors are silent, incomprehensible, or occur only when a particular action happens.

* polkit doesn't have a textual interface, it only works through D-Bus. This makes it useless for scripting.

Re: Why I dislike systemd

#202

Post by weland »

bad_user wrote: post #155
weland wrote: post #84

Earlier quoted context omitted.

> For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e.g. if you think connecting to a Wifi network is problematic, try connecting to a L2TP over IPSec VPN). That's because there is equally no uniform and simple way to connect to use those, either. The problem is that the "simplification" that NetworkManager prov…

Thanks for your detailed response. So what laptop do you use for OpenBSD? I'm running Ubuntu on my main laptop and I tend to search for hardware that's known to work with it.

It's an HP 4720s. I didn't buy it on purpose -- it used to be my girlfriend's. When it broke, I gave her my (much tinier) ThinkPad and after I fixed it, we never swapped them back.

I think the only thing that doesn't work out of the box is the weird WiFi adapter that has problems even on Windows. I just use a tiny USB adapter.

I also have OpenBSD installed on my even older laptop, which is an iBook G3. Power management and wifi don't work there but it is 15 year-old hardware, I don't really care.

Re: Why I dislike systemd

#203

Post by chousuke »

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…

Honestly, I don't think that argument holds much water.

Init systems are not "just shell". If you go and try to write a sysv init script with only shell skills, chances are your init script will be broken in some obscure way. Perhaps because you didn't specify LSB headers correctly, or your PID file handling is subtly broken, or you're missing a check somewhere and the script is racey. I can't really say how much reading it would take to catch all the corner cases with sysv init scripts, but for simple cases, you will be able to write a correct unit file after about 15 minutes of reading the manuals.

Knowing shell helps, but you'll still need the tool-specific knowledge.

Re: Why I dislike systemd

#204

Post by pjc50 »

groks wrote: post #160
pjc50 wrote: post #58

Earlier quoted context omitted.

Polkit is a nightmare . And I agree with you on the churn. There was a time when Linux administration changed less frequently than Windows, round about the 95-XP-Vista era.

http://smcv.pseudorandom.co.uk/2015/why_polkit/

From the bullet points:

Fine-grained access control needs domain-specific understanding

This also applies to the user trying to configure it. For all the reasons listed in "weland"'s sibling comment, this is hard to learn. If something doesn't work in polkit, and you're not completely familiar with it, it's very hard to make it work.

Re: Why I dislike systemd

#205

Post by JdeBP »

digi_owl wrote: post #191
JdeBP wrote: post #183

Earlier quoted context omitted.

knowing the systemd unit options is not a reusable skill That is, to an extent, not true. There is at least one system that can import systemd unit files, subject to some fairly obvious limits on Linux idiosyncrasies. http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

Heh, i was wondering how long it would take before we would get something like this.

It was around before the Debian Technical Committee made its decision. It wasn't one of the options to choose from, but it was an existence proof, for those making the decisions, that systemd unit files will not lock them in and that there's a route for Debian packages that have systemd units on Debian kFreeBSD and Debian Hurd.

Re: Why I dislike systemd

#206

Post by JdeBP »

the_why_of_y wrote: post #161
peatmoss wrote: post #112

Earlier quoted context omitted.

This has long been my experience with BSD (back before jumping to OSX for some years, and now back to OpenBSD). There is a willingness to update core pieces of functionality where needed to reduce inessential redundancy. Another example: console / keyboard config. In OpenBSD, I set this up through wscons. If set here, my keyboard settings get propagated in a robust, non duplicative way to X11. Contrast this with Linu…

This is indeed annoying; fortunately David Herrmann is working on a new user-space terminal emulator for Linux called KMSCON which uses the same keyboard input code as XOrg (libxkbcommon) so there is hope for improvement. https://dvdhrm.wordpress.com/2012/12/10/kmscon-introduction/

"is", "new", and "KMSCON" are all erroneous there. (-:

Re: Why I dislike systemd

#207

Post by rockdoe »

yellowapple wrote: post #177
rockdoe wrote: post #91

Earlier quoted context omitted.

Given that it's the default and sometimes only working option for many of the most popular Linux distros: yes.

Given also that systemd is Linux-only due to its reliance on cgroups: yes.

That doesn't stop you from having a Linux system without systemd, though.

Re: Why I dislike systemd

#208

Post by digi_owl »

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…

Here is the thing. The problem is not systemd as init, it is systemd as, well, systemd.

The constant addition of daemons and functionality to the overall systemd codebase by either subsuming or replacing existing, INDEPENDENT, projects.

As such, who cares what init is used. The thing is that until systemd the other daemons/services started by init didn't particularly care what init it was.

Previously you could piecemeal your changes. Didn't like syslog? Grab something else that talk the lingo and slot it into place. Sorry, but journald demands that the init is systemd.

Want something to handle seats/sessions? Sorry, but logind only works with systemd as init.

Etc etc etc!

Going on and on and on about inits is a smokescreen.

Re: Why I dislike systemd

#209

Post by digi_owl »

pjc50 wrote: post #204
groks wrote: post #160

Earlier quoted context omitted.

http://smcv.pseudorandom.co.uk/2015/why_polkit/

From the bullet points: Fine-grained access control needs domain-specific understanding This also applies to the user trying to configure it. For all the reasons listed in "weland"'s sibling comment, this is hard to learn. If something doesn't work in polkit, and you're not completely familiar with it, it's very hard to make it work.

On that note:

https://www.techdirt.com/articles/20150615/11565531344/repor...

Re: Why I dislike systemd

#210

Post by XorNot »

digi_owl wrote: post #194
XorNot wrote: post #48

Earlier quoted context omitted.

Because systemd is event-driven, you can't actually be sure the service file won't be re-used in the running configuration - or that it won't trigger other service reloads/starts/stops due to its dependency specifications. Ergo systemd requires an explicit reload to commit the state of the unit files once you're satisfied they are as intended. This is very important when you consider that unit files can kill other un…

And in the end i will gladly trade a few seconds longer boot for a system i can actually reason about rather than treat as some kind of black box voodoo. The latter is why i moved away from Windows in the first place.

It's definitely more then a few seconds (systemd boots fast), but more importantly reasoning about unit files is a lot easier then reasoning about the init-script ordering.

With a unit file I can just declare the conditions under which it should run or stop. If the system doesn't achieve those conditions, then I can solve that problem - rather then having my unit run before the system is ready to do so.

You're not really reasoning about your system because you can say "this runs after this" if you don't also express all the dependencies and failure conditions.

Post reply on HN