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

71–80 of 357 posts

Re: Avoiding Complexity with Systemd

#71

Post by idoubtit »

midasuni wrote: post #13
Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

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…

I doubt answering rants is useful, but I'll try to give factual counter-arguments.

> there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years of typing cat /etc/resolv.conf

systemd-resolved is not enabled by default in Debian and many distributions, and it is not needed in any way by systemd. If you don't like it, don't use it!

Your rant does not sound very serious. Did you really have "ntp" or "syslog" in your muscle memory? That's strange, because most syslog daemon did not have a `syslog` command.

Anyway, systemd-resolved was created because it has uses. And for systems that used a dns cache (dnsmasq, etc), rejoice, because the config is now simpler than it was.

> For decades it was /etc/init.d/myserice restart

> Now is it systemctl restart myservice or systemctl myservice restart? I have no idea as I’m not at a computer.

Before systemd, at least on Debian, for a few years the recommended way was NOT calling `/etc/init.d/something`, but instead `service apache restart`. Since sysv was unsuitable for many uses, several alternatives emerged, like "runit", or "upstart" for Ubuntu. So, before systemd, the recommended way changed with the distribution.

Thanks to systemd, most linux installs now use `systemctl restart service1 service2`. Note that you can now act on multiple services at the same time. You can use this feature as a mnemonic.

> Or the restart fails it doesn’t tell you why, ... Init.d scripts didn’t do that.

In many cases, init.d scripts told you nothing when they failed. Each service has its own procedure. Nowdays you can always see what happened with the command systemctl prints on failure.

And `systemctl cat s1` display starting instructions that are rarely longer than a dozen of lines. I remember init.d scripts that were hundreds of lines long, and awfully hard to understand.

Re: Avoiding Complexity with Systemd

#72

Post by darthrupert »

midasuni wrote: post #13
Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

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…

I used Linux about a decade before systemd came along, and I welcome it. I think it made almost everything better, and not by a small margin.

Re: Avoiding Complexity with Systemd

#73

Post by bonzini »

_jal wrote: post #33
zozbot234 wrote: post #11

Earlier quoted context omitted.

There's a lot of poorly-understood incidental complexity in the systemd codebase, and this can bite users even when doing basic service and runlevel management. The systemd approach is to try and make it 100% declarative based on simple .ini files, but the semantics of this seemingly "declarative" configuration was never properly specified. Even many systemd fans seem to be quite aware of this, and there seems to be…

> 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.

Re: Avoiding Complexity with Systemd

#74

Post by drran »

jbverschoor wrote: post #23
dagw wrote: post #22

Earlier quoted context omitted.

Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. They might not have been better or more robust, but they where easier to understand and reason about. You could explain the entire thing to the most junior of sysadmins in a few minuets, tell them to read the boot scripts, and they would basically understand how everything worked.

Really? Have you ever written init scripts for a hand full of services for your typical saas application? It’s always been a mess, and I’m very happy systemd was copied from / inspired by Apple’s launchd.

This mess is easy to solve with a library of functions to call, e.g. /etc/rc.d/init.d/functions, which can be imported and used. Unfortunately, there is no standard API for this.

Re: Avoiding Complexity with Systemd

#75

Post by drran »

baybal2 wrote: post #65

I want to mention connman. Does everything you expect of single programmlet to manage your NTP, resolve.conf, DNS caching, mDNS, network devices, and etc. Importantly, it weights only 1/100 of SystemD

How to kick out SystemD first, to try connman?

Re: Avoiding Complexity with Systemd

#76

Post by drran »

siraben wrote: post #7
atoav wrote: post #4

Earlier quoted context omitted.

I use mostly Ubuntu and Debian and defining systemd units just means you have to spit the right text into a .service file placed at the right spot. How does NixOS make that easier?

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.

Re: Avoiding Complexity with Systemd

#77

Post by WesolyKubeczek »

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.

I just write an easy-to-debug program which I can launch from command line and see it run, and when I'm satisfied, a systemd unit from a cookie-cutter template is going to make it run. Service dependencies are now a breeze, too.

If I need to limit resources, I can just declare the limits in the unit. If I want a custom networking/mount namespace, it's taken care of.

Re: Avoiding Complexity with Systemd

#78

Post by throw-8462682 »

mjw1007 wrote: post #67
throw-8462682 wrote: post #54

Earlier quoted context omitted.

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?

It certainly does sometimes happen that difficult software projects end up being implemented by people who (at least at the start) don't understand the problems involved, for reasons related to the "winner's curse" [1]. That is, people who underestimate the difficulty of a project are more likely to attempt it, and people who don't understand the area well are more likely to underestimate its difficulty. [1] https://…

It happens but it’s not clear what you intend to say with that, so maybe just say it? I don’t think the systemd team could have imagined the success and scope of the project from day 1. Another explanation for their success is that the team was onto something, and by using proper engineering practices (work incrementally on pieces that are individually useful) became successful. Think T S Kuhn’s progressive research program.

Re: Avoiding Complexity with Systemd

#79

Post by Tom4hawk »

zeeZ wrote: post #49
kbumsik wrote: post #32

Earlier quoted context omitted.

I sometimes feel a bit weird when I see complaints like this. Because I have never experienced broken by systemd. For logging, can't you write a systemd service in bash with -x flag?

Recently a systemd update that came with a flatcar linux update added/enabled a systemd-resolved stub that hogged port 53, preventing the actual DNS server on the machine from starting up. Does that count as broken by systemd?

No. Sounds like broken distribution.

Re: Avoiding Complexity with Systemd

#80

Post by throw-8462682 »

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

Earlier quoted context omitted.

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?

For SystemD, I see none. Though, I see unfulfilled urge to give Linux "serious enterprise grade" twist, and bog everything in "serious enterprise frameworks of doom"

If you think that systemd is an ‘enterprise framework of doom’ then you must not have worked in Java enterprise software development.
Post reply on HN