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

Systemd, 10 years later (2020)

blog.darknedgy.net

Post reply on HN
Print view View original

171–180 of 332 posts

Re: Systemd, 10 years later (2020)

#171

Post by tremon »

throwaway2331 wrote: post #133
jasonjayr wrote: post #107

Earlier quoted context omitted.

Networking on linux is wildly powerful. Most desktop/SOHO installations would just be Wifi + DHCP. Maybe some VPN in the mix. But on the other side of the scale, there are routers with complex netfiltering, vlans, crazy GRE Tunnels, Tun/Tap, Wireguard, macvlans split between namespaces, bridges, etc, you name it. Defining a straightforward configuration structure for that complexity is going to be insane. NetworkMana…

My main gripe hasn't been that I want something done an exact way. It's that I want to achieve some semblance of what I'm trying to do in a reasonable amount of time. NetworkManager is god awful in this regard. Even for simple desktop uses, if I want something more advanced than simply connecting to the Wi-Fi (even this requires finagling), then I'm fucked. For example, I've been trying to find what it is that keeps…

I've been trying to find what it is that keeps overwriting /etc/resolv.conf

  chattr +i /etc/resolv.conf
and watch the logs for errors/crashing services. It's sad, I know, but sometimes you do need a landmine to identify the trespassers.

Re: Systemd, 10 years later (2020)

#172

Post by awrmc »

Blikkentrekker wrote: post #165
dijit wrote: post #141

Earlier quoted context omitted.

And this means we can’t do things like force disconnect an eGPU or whatever on acpi events. I think I figured out my issue with systemd. It does not apply Chesterton Fence when redeveloping things… and how could it, when it redevelops so much. Maybe it’s fine if it’s all you’ve ever know (or you never hacked on your system) but those that did have lost something.

The situation is that such hackers and tweakers rarely use systemd, for these reasons. They are simply annoyed by A) it being pushed on them; B) people often acting that they are irrational for not liking it while it does not what they expect and need; and C) discussions with Freedesktop developers that, frankness be, reveal they live inside of a very strange bubble and have no idea of the use cases outside of it. Th…

I'm an open source hacker and I like systemd. Once I took the time to learn its APIs I found it does everything I expect.

Your issues with XFCE and libinput don't seem to be related to systemd. I can't see how airing grievances against other unrelated projects would be a constructive place to take this discussion. Complaining about open source projects only supporting some use cases is also confusing to me. A lot of these projects are very open about the fact that they exist only to "scratch their own itch".

Re: Systemd, 10 years later (2020)

#173

Post by erik_seaberg »

throwaway984393 wrote: post #93
akagusu wrote: post #26

I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.

Part of it was political, but it was also just practical. Poettering's designs are some of the worst for usability I've ever seen. They technically work, but you need a million StackOverflow Q&As to figure out how to get anything done or solve the many common problems. It's like somebody decided that the problem with Linux was it wasn't complicated enough. And then everbody just went with it.

I keep coming back to the https://news.ycombinator.com/item?id=19023885 issue. There’s a default setting somewhere that makes systemd knowingly kill normal user processes it did not start. Why does that exist? It was never init’s job, and init is not something end users should have to be aware of to run stuff with POSIX nohup.

Re: Systemd, 10 years later (2020)

#174

Post by bjourne »

lifeisstillgood wrote: post #79
Spooky23 wrote: post #67

Earlier quoted context omitted.

Exactly. “Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.

Idempotent is surely a valuable piece of software jargon. I know exactly what the user intends, and have good ideas of how hard it is and what likely trade offs they will be making behind the scenes surely it is the very opposite of bullshit.

But the phrase in the paragraph is non-idempotent which is completely redundant. Every piece of software in the world is non-idempotent.

Re: Systemd, 10 years later (2020)

#175

Post by tomxor »

imoverclocked wrote: post #69
akagusu wrote: post #26

I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.

Network configuration (on say, Debian) is still a pain and has a lot of different ways of accomplishing similar tasks. Anything beyond the plain vanilla singular network device that is either dhcp/static is often painful. Systemd has some sauce, there is legacy /etc/network* stuff, there are daemons which can be configured graphically… it’s still a mess. In this arena, I think systemd has failed for the last decade.…

> Network configuration (on say, Debian) is still a pain

What specifically is a pain? Have you used it recently?

Maybe my end-user desktop network requirements aren't complex enough but it's been pretty damn smooth in my experience for the last few years. I used to avoid network-manager with wicd, but now it seems pretty stable. I use the network-manager and network-manager-gnome packages to get the toolbar thingy in i3wm, it's very simple to use. I also combine it with wiregaurd using the wg commands.

Are you doing something more sophisticated like routing traffic? or something else in a server context? I literally can't recall having a single networking issue that was Debian's fault over the last few years, throughout using lots of different APs.

Re: Systemd, 10 years later (2020)

#176

Post by imwillofficial »

dharmab wrote: post #58
MuffinFlavored wrote: post #49

Earlier quoted context omitted.

Like what if you don't mind me asking, and what did people used to use as an alternative?

For the init system, the most common predecessor was a combination of sysvnit and "initscripts" (a shell script for each daemon on your system). Writing the init scripts was simple for the most basic cases but quite complex for complete, bug free case coverage. A big appeal of systemd for packagers and sysadmins was the relative simplicity of unit files. Now we just have to fill out a simple boilerplate INI style fil…

“ It was not.” Yes it was Upstart was super short lived, and OpenRC hardly used.

The vast, and I mean vast majority of distros used SysV before transitioning to SystemD

Re: Systemd, 10 years later (2020)

#177

Post by awrmc »

Blikkentrekker wrote: post #162
johnny22 wrote: post #139

Earlier quoted context omitted.

is that 2006 number correct re: gentoo? Although i wouldn't start by comparing against openrc, but rather the previous uhmm "baselayout" init system. (sorry, i haven't used gentoo in a long time). The previous gentoo init system was already better than sysvinit and initscripts. I still prefer and use systemd though.

No, it is actually incorrect, all numbers are incorrect by one year it seems. Gentoo switched in 2007, and Ubuntu and Fedora used Upstart since 2006. And why wouldn't you compare it with the systems it actually competes against and replaces rather than against something that was barely used any more before systemd even stated development? The comparison with sysvinit, suggesting that those that do not use systemd adv…

>And why wouldn't you compare it with the systems it actually competes against and replaces rather than against something that was barely used any more before systemd even stated development?

I would say that's a meaningless comparison and those other systems were never considered as real replacements. At that time I don't remember OpenRC getting any traction outside of Gentoo, and the distros using Upstart were already unhappy with it. Adding to that, systemd explicitly was targeting distros that used a lot of sysvinit scripts and was intended to be used as an upgrade for them. It's largely succeeded at that.

Re: Systemd, 10 years later (2020)

#178

Post by marcan_42 »

Blikkentrekker wrote: post #162
johnny22 wrote: post #139

Earlier quoted context omitted.

is that 2006 number correct re: gentoo? Although i wouldn't start by comparing against openrc, but rather the previous uhmm "baselayout" init system. (sorry, i haven't used gentoo in a long time). The previous gentoo init system was already better than sysvinit and initscripts. I still prefer and use systemd though.

No, it is actually incorrect, all numbers are incorrect by one year it seems. Gentoo switched in 2007, and Ubuntu and Fedora used Upstart since 2006. And why wouldn't you compare it with the systems it actually competes against and replaces rather than against something that was barely used any more before systemd even stated development? The comparison with sysvinit, suggesting that those that do not use systemd adv…

OpenRC was a C rewrite of what was previously a bunch of bash scripts, but they still implemented the same rich dependency and function-based init logic; it was miles ahead of Debian's init.d scripts before it became OpenRC. OpenRC largely made it faster, and over the years the configuration became (optionally) more declarative and gained features. The actual OpenRC transition was largely seamless for users, because the init script syntax didn't change.

So the year you're looking for isn't when OpenRC was introduced, but rather when Gentoo started using the OpenRC style of init script, which happened much earlier - it's definitely been like that since I started using Gentoo, at least since 2003 or so.

It's actually a misconception that sysvinit is the whole init system; sysvinit is PID 1. Gentoo still uses sysvinit for PID 1 by default. What matters is what your service manager is - that's OpenRC here.

Re: Systemd, 10 years later (2020)

#179

Post by wmanley »

zozbot234 wrote: post #44
an_d_rew wrote: post #23

This was an amazing review, and love systemd or hate it, this article gives a fantastic history and exposition of what systemd actually is . My favorite quote (and when taken in context is much less tongue-in-cheek thank you might think): systemd is an event-driven object manager with dependency-like side effects which ‘boxes’ primitive kernel resources and userspace subsystems into a generic object type called Unit.…

...so, how does a systemd unit definition differ from a Makefile (other than using a different syntax, obviously)? What features would you need to add to UNIX make (and PID 1, for that matter) in order to be able to separate out this whole dependency management business from the other stuff PID 1 has to deal with already?

To pick just a small piece of the pie:

Dependencies in make are equivalent to systemd's Requires= and After= combined. Systemd is far more general in this regard, both in that Requires= and After= are separate concepts, but also in that there is Wants=, BindsTo=, etc. and their inverses (RequiredBy=, Before=, etc.). Sometimes when I'm writing Makefiles I wish Make were capable of expressing some of these concepts.

Re: Systemd, 10 years later (2020)

#180

Post by api »

rnd0 wrote: post #72
api wrote: post #61

Earlier quoted context omitted.

It’s a functional improvement over old init, but the thing I hate about it is how unnecessarily arcane it is. It seems “designed for job security” or more likely designed for consulting revenue. There is absolutely no need for its command names and everything else about it to be so counterintuitive.

>It seems “designed for job security” or more likely designed for consulting revenue. Exactly this, yes; and that's why it was pushed the way it was. I dread the day when systemd or an init system just like it consumes the BSD world.

I feel the same way about Postgres. It's powerful but it's insanely arcane and full of land mines and footguns. It's great for forcing you to hire consultants, DBAs, or pay cloud providers a lot to run it for you.
Post reply on HN