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

111–120 of 357 posts

Re: Avoiding Complexity with Systemd

#111

Post by dane-pgp »

bonzini wrote: post #73
_jal wrote: post #33

Earlier quoted context omitted.

> semantics of this seemingly "declarative" configuration was never properly specified Yeah, and it is not only underspecified, but too weak to be useful, which just pushes all the init.d logic somewhere else. What you've accomplished is moving it somewhere nonstandard, great job. Also, the command line ergonomics suck. Systemd is deeply unfriendly to humans. It was a power play in support of a long-term RH strategy,…

It's interesting to see these allegations ("power play in support of a long-term RH strategy") without any proof or for that matter any explanation of what the strategy would be.

I believe that Red Hat employees were some of the main contributors to Gnome, which quickly made systemd a hard requirement, forcing distros which used it as the default desktop to make systemd the default init system.

Re: Avoiding Complexity with Systemd

#112

Post by leotaku »

drran wrote: post #76
siraben wrote: post #7

Earlier quoted context omitted.

In NixOS it's trivial to use and define NixOS modules, which handle restarting/starting/stopping systemd units. See the wiki example[0] on how to define and use a service that greets the user with GNU Hello. Also, since you have access to Nixpkgs, you can make the ExecStart as complicated as you want with whatever dependencies you desire, and trivially share it with others. [0] https://nixos.wiki/wiki/Module#Example

It looks like NixWay of doing NixThings to solve NixProblems. Why I need NixModules in the first place? ELI5, please.

It's basically just a nice way of composing the different parts of your system.

E.g. you could write a NixOS module to manage your web app. You declaratively configure that you want to run Nginx, Postgres, etc. open some ports, connect to your VPN and basically everything else you might want. There are a lot of existing modules, so in most cases you have to write very little code yourself. If you want to scale your system to run on multiple systems or containers, you can do that with relative ease.

You also have a singular source of truth for all of your information, down to your application binaries. Your configuration says you are using Postgres version X.Y.Z with compilation options A, B and C, so that's exactly what is running on your systems.

Re: Avoiding Complexity with Systemd

#113

Post by theranger »

kzrdude wrote: post #41
turminal wrote: post #24

Earlier quoted context omitted.

> * If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd? Because the only two alternatives are 1) running mainstream distros from before 2014 or 2) running obscure distros that still don't use systemd.

yes, people forget that we are a village. Contrary to “popular misconception”, Linux is not a settler's freehold where every holdout makes their own rules. Admins have to work with a diversity of systems. They can choose how to setup new ones, but they have to work with a range of them. What everyone does has an effect on everyone else. If some distro introduces a new way of doing things, it has some chance of ending…

So the admins should really not rant about systemd but complain about the distributions who switched to systemd or about their employers who force them to use such distributions.

Re: Avoiding Complexity with Systemd

#114

Post by Nursie »

einpoklum wrote: post #100
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.…

1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. 2. Some of the systemd logging is binary, so good luck with that if there's a problem. 3. Have you tried non-systemd init systems other than sysvinit? 4. Yes, it is convenient when everything below your development is cenrtalized by a single entity. It can easily provide a consistently useful underpinning. But…

> 1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses.

What other system is there, right now, that can do this so well?

I'm definitely onboard with the issues around tight coupling, I'm really not a fan of binary logs etc. But the unit files are pretty awesome IMHO.

So serious question - what else does those as well or better?

Re: Avoiding Complexity with Systemd

#115

Post by theranger »

nmg wrote: post #66
midasuni wrote: post #13

Earlier quoted context omitted.

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

> Now is it systemctl restart myservice or systemctl myservice restart? I have no idea as I’m not at a computer. I felt so alone in the world until this moment

Well, by the time the systemd gets as old as sysvinit currently is, everybody will have the correct one in their muscle memory.

Re: Avoiding Complexity with Systemd

#116

Post by leotaku »

sgt wrote: post #85

If you are looking to run your containers in a very light weight way and also easily understood, you can use systemd for this and use tips from this article. You will have to do the orchestration yourself so I think it would have to be more suitable for very simple deployments with small teams and / or part time projects.

I've used systemd containers to run badly behaved GUI apps, e.g. Steam and MS Teams on my personal computers. Surprisingly good experience, the systemd manual pages are extremely comprehensive and, in my opinion, much easier to understand than people make them out to be.

Re: Avoiding Complexity with Systemd

#117

Post by iso1210 »

throw-8462682 wrote: post #54
baybal2 wrote: post #17

Earlier quoted context omitted.

> Systemd is 10 years in making Systemd is 10 years in making, and still manages to brick production servers. The problem is not with SystemD or its coding as such, but the ideology it came with, and bad developers who push it. The last attempts to make it saner basically reverted it back to sysvinit. So, not much difference now.

How likely is it that the prolific systemd team and tech decision makers in Linux distributions don’t have a design instinct and came up with this ball of mud full of accidental and unneeded complexity? Have you considered that there may be teams and requirements outside your current sphere of experience?

Maybe there are, but that doesn't help me.

The systemd way seems to be "one tool of complexity 40 to 50 things" rather than "50 tools of complexity 1 each doing one thing".

When you only need 10 things, you only need 10 simple tools of complexity 10, rather than one tool of complexity 40.

Re: Avoiding Complexity with Systemd

#118

Post by iso1210 »

tyingq wrote: post #44

My frustration with systemd is that it creeps out over time into other functionality, and that it's difficult to find the right documentation. Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I…

Ouch, what on earth does "log out" even mean? What a terrible way to run any computer other than maybe a single user laptop.

Re: Avoiding Complexity with Systemd

#119

Post by josephcsible »

viraptor wrote: post #92
loudmax wrote: post #81

Earlier quoted context omitted.

I tend to agree with most of the points you're making but I do want to point out that "If you don't like it, don't use it" isn't helpful advice for system administrators who weren't given a choice in the matter. It's fine if you're designing a system from the ground up, but most of the time, most of us have to work with what we're given. I think most of the resentment against systemd is that it felt like it was force…

If you can't opt out of systemd-resolved due to job policies, that's really not systemd's fault and there's nothing they can do to solve that situation. Why complain about it in that context?

What does this have to do with job policies? 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, since many of the packages that Red Hat made depend on it are important to the Linux ecosystem, and the other distros didn't have the resources to fork them all.

Re: Avoiding Complexity with Systemd

#120

Post by cpach »

Nursie wrote: post #114
einpoklum wrote: post #100

Earlier quoted context omitted.

1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. 2. Some of the systemd logging is binary, so good luck with that if there's a problem. 3. Have you tried non-systemd init systems other than sysvinit? 4. Yes, it is convenient when everything below your development is cenrtalized by a single entity. It can easily provide a consistently useful underpinning. But…

> 1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. What other system is there, right now, that can do this so well? I'm definitely onboard with the issues around tight coupling, I'm really not a fan of binary logs etc. But the unit files are pretty awesome IMHO. So serious question - what else does those as well or better?

s6 does it well

https://skarnet.org/software/s6/

Post reply on HN