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

Avoiding Complexity with Systemd

mgdm.net

Post reply on HN
Print view View original

251–260 of 357 posts

Re: Avoiding Complexity with Systemd

#251

Post by mgdm »

imiric wrote: post #165
viraptor wrote: post #108

Earlier quoted context omitted.

> So like chroot and namespaces? Why do I have to depend on systemd when these are native features provided by Linux? Not like namespaces - using namespaces. And for the same reason we use other high level abstractions and high level languages rather than handcrafted assembly. You don't have to depend on it either - you can still use chroot instead of you want, but it's more work that way. > Great, but so do Docker a…

> You don't have to depend on it either - you can still use chroot instead of you want, but it's more work that way. How so? If I need filesystem isolation, I'll use the simplest tool that provides it. In this case probably a container runtime. Note that none of your criticism about Docker applies to Podman. Why would I ever want to use containers with a tool that forces (OK, strongly suggests...) me to use it as an…

It's not really a binding. It doesn't link to anything in systemd, it's just aware of the convention used by systemd to pass the file descriptors into the process. The actual code being executed from that repository is around 60 lines, I guess:

https://github.com/coreos/go-systemd/blob/main/activation/li...

I just used that rather than writing it myself because it felt like it didn't add much to the story. Also the code was actually written on macOS, it still runs fine without systemd.

Edit: I'd be quite interested to see if passing file descriptors in this way would be a goal in, for example, the proposed Alpine service manager. A quick scan of the proposal didn't show me anything obvious, but I'll go and read it in more detail.

Re: Avoiding Complexity with Systemd

#252

Post by WesolyKubeczek »

zh3 wrote: post #246
WesolyKubeczek wrote: post #77

For me, systemd is the best thing since sliced bread. As a programmer, I now don't need to care about dropping privileges, managing logging, daemonization (the moment I need to do the double-fork dance again, chairs will be flying, I swear), dropping into a chroot, and do half-arsed guesses "is it up and running yet?" from a convoluted mess of shell code that looks like a bunch of hair stuck down a drain for a month.…

Wait until it automagically fails. It may be great for less-skilled people, but for anyone running anything where it's too critical to outsource support it's then necessary to have a systemd expert inhouse (and such a person has proven extremely hard to find).

Waiting for the last 8 years, and?

Re: Avoiding Complexity with Systemd

#253

Post by gmmeyer »

zh3 wrote: post #246
WesolyKubeczek wrote: post #77

For me, systemd is the best thing since sliced bread. As a programmer, I now don't need to care about dropping privileges, managing logging, daemonization (the moment I need to do the double-fork dance again, chairs will be flying, I swear), dropping into a chroot, and do half-arsed guesses "is it up and running yet?" from a convoluted mess of shell code that looks like a bunch of hair stuck down a drain for a month.…

Wait until it automagically fails. It may be great for less-skilled people, but for anyone running anything where it's too critical to outsource support it's then necessary to have a systemd expert inhouse (and such a person has proven extremely hard to find).

I have never encountered the need for this and I honestly doubt you have either. Systemd fails mysteriously far less often than poorly written init files I have seen and it is honestly not that hard to debug almost every failure I've ever encountered. And I have worked on some very large scale systems with systemd. A systemd file I helped write has run many millions of times over without issue. I honestly find this comment impossible to believe

Re: Avoiding Complexity with Systemd

#254

Post by boublepop »

a1369209993 wrote: post #243
boublepop wrote: post #94

Earlier quoted context omitted.

It took 10 years before the “python2 will never die”-crowd finally accepted they where not going to win at that python3 was here to stay. People spend a couple of years getting used to a stack in their early carrier and then spend decades arguing that it should never change.

> the "[python] will never die"-crowd finally accepted they where not going to win Why are you talking in the past tense? We have done no such thing. Death to python 3; long live python.

Obviously I don’t mean you don’t exist any more, but the surveys show enough converted that your views on pythons future are no longer relevant in the bigger picture.

Re: Avoiding Complexity with Systemd

#255

Post by imiric »

cpach wrote: post #170
aerique wrote: post #136

Earlier quoted context omitted.

Void Linux, "the BSD of Linux", uses runit and it has been fine since forever. If there were any issues they would be worked on.

I’m glad to hear runit works fine for them. I’m not so sure there isn’t any room for improvement though. In the related s6 project there is lot of discussions about adding new features that are beneficial for supporting a modern Linux distro.

As a datapoint of one, I've been using Void Linux for near a decade.

I haven't once been in a situation where I thought systemd would help. Granted, I don't run many custom services, but for what it does, runit does a great job. Something a bit more user friendly like s6 would be nice, but otherwise it stays out of my way and I don't think about it.

NixOS/Guix would be worthwhile switching to, but Void is comfortably simple.

Re: Avoiding Complexity with Systemd

#256

Post by bkor »

josephcsible wrote: post #235
bkor wrote: post #221

Earlier quoted context omitted.

> we should scrap and replace the whole program instead of just fixing its default configuration? Loads of distributions assisted that upstream works out of the box with systemd. That way the work is shared across distributions. Not sure why you make such a strange suggestion. Loads of work has been saved thanks to systemd. So much more is shared across distributions it's kind of crazy to look back.

I was talking about rsyslog there, not systemd.

> I was talking about rsyslog there, not systemd.

It's not at all clear what you're talking about, honestly. First you talk about distributions, then a vague "we", then some weird "scrap and replace" nonsense. No idea who you mean with a sentence such as "we scrap and replace rsyslog". It really makes no sense, if there's a developer that works on rsyslog the work will continue. Distributions might change a default, but it didn't seem to be about distributions.

To make things a bit clearer I talked about all the benefits of having systemd across distributions, plus how the work is shared. This because you seemed to not understand the benefits that systemd has for distributions, in response to the "since distros don't optimally configure a program out of the box". Again, with systemd work it often allowed things to be done upstream. Configuring things in a distribution is a waste of time, previously distributions often wrote their own init scripts.

One person specifically mentions that it's nice when stuff is good by default. Complaining that it's some fault of the distribution completely misses the point: systemd allows stuff to be shared across distributions! No need to complain that either the default wasn't ok, the init script had a bug, etc. It's shared by default. Similarly, once a mistake is found, the bugfix can be made in one place.

That's the nice bit. Your weird comment isn't clear at all, plus completely misses what's nice about systemd for distributions.

Re: Avoiding Complexity with Systemd

#258

Post by zxzax »

stefanha wrote: post #48

Recently I have been wondering if systemd solves problems that are becoming less and less relevant to developers. New services are often deployed as containers. While systemd has a bunch of container-related functionality, it does not integrate well into the Kubernetes or even Docker workflow. It's used very little in those environments. If you are building CoreOS or NixOS system images, or traditional Linux system s…

You can just use podman to run Docker containers. That workflow is honestly what I wanted years ago when I first used docker, where containerization is put in the core system, and you can progressively add containerization to your core services while also running a full container on top of the same runtime.

Re: Avoiding Complexity with Systemd

#259

Post by bkor »

josephcsible wrote: post #236
bkor wrote: post #214

Earlier quoted context omitted.

> Systemd was forced down our throats by Red Hat adding hard dependencies on it to other software under their control, e.g., GNOME. Other distros then adopted systemd under duress What utter drivel. I've participated in the discussions around systemd in various distributions. There was a huge amount of discussion, then one by one distributions switched. Some quickly, some took various years. Again, some distributions…

> That you can only say things such as "forced down our throats" and "duress" says enough. Not capable to actually hold a discussion, let's be emotional and without any actual facts. Does this sound any better? Red Hat used their influence over GNOME (and other programs) to add a hard dependency on systemd to it. This forced other distros to either switch to systemd or drop support for GNOME. I suspect that had Red H…

Nope, it's still entirely incorrect. Again, the release team misjudged things. I was part of the GNOME release team at that time. We were actually warned about it, then misjudged it ("it'll be fine").

Further, it wasn't even a hard dependency. You're really not understanding components and APIs.

> This forced other distros to either switch to systemd or drop support for GNOME.

No, again entirely incorrect. GNOME runs without systemd. A few distributions worked on ensuring GNOME runs without it. It took a while to make that happen, so for a bit some distributions needed to keep some components back. But still: you're talking about systemd while it was an interaction of a few components. Systemd consists of loads of bits.

GNOME _runs_ on distributions without systemd! It took work to make that happen, we coordinated to ensure the problems would be solved.

> I suspect that had Red Hat employees not added hard dependencies on systemd to any other software, that no distributions other than Fedora and RHEL and its clones would require it.

Again, you're so incorrect it's not funny. Arch was really quick to switch to systemd. I help out with Mageia, they really wanted to switch as well, but it took (volunteer) time to make it happen. Opensuse took a while, but still, they would've switched.

The only unique ones were Ubuntu (political crap) and Debian (partly due to political influence by Ubuntu).

Systemd was selected on merit by loads of distributions, not this conspiracy thing you're pretending it to be.

Re: Avoiding Complexity with Systemd

#260

Post by bkor »

josephcsible wrote: post #234
bkor wrote: post #219

Earlier quoted context omitted.

> Thankfully, sanity eventually did prevail in GNOME (just related to this matter, not in general) You've rewritten history to pretend you're right. Then you follow up with more drivel? Sorry, aside from trolling, what is your point?

> You've rewritten history This seems pretty clear that GNOME used to depend on systemd. How am I rewriting anything? https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd#Pa...

GNOME relies on some API that has been implemented by elogind. Nothing in this bit changed. Gentoo (I think with the help of some others) ensured it was implemented (forked) so the API could still be used without systemd.

I thought you were the same as the other person. You're continuing the same argument, so it really doesn't matter if you're the same or not: "quickly made systemd a hard requirement" is bullshit. Further, it could easily be worked around.

If you notice e.g. the history of Ubuntu it happens regularly that you hold back a component if there's a problem integrating it. This happens across multiple distributions. It isn't something unique, nor special.

GNOME nor Red Hat did NOT "quickly made systemd a hard requirement". Gentoo was great to ensure that the API that was depended upon was implemented separately. Aside from that, a distribution could also hold back the logind change that caused this change. Skipping over all of these details is great to make this into some big conspiracy story. However, it is rewriting history. It wasn't something unique. Yeah, GNOME release team misjudged one thing. But it actually took a few years before it became an issue. Not this drivel with "OMG they added a hard dependency". It wasn't like that.

Post reply on HN