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

61–70 of 357 posts

Re: Avoiding Complexity with Systemd

#61

Post by morelisp »

bonzini wrote: post #19
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 Actually long before that it was service restart myservice, which still works.

Unfortunately, it was `service myservice restart`, which is the wrong order if you want to be able to do multiple things at once (or even just align with any other `cmd subcmd args` program).

Re: Avoiding Complexity with Systemd

#62

Post by birdyrooster »

smitty1e wrote: post #30
turminal wrote: post #14

The title is an oxymoron. Putting a huge complex piece of software between yourself and "complexity" doesn't make the system less complex.

Systemd seems to do a good job of moving the complexity of managing the privileged/unprivileged divide into a standardized service. I sympathize with the "transition sucks" sentiments elsewhere on this post. Having a bunch of working scripts turned into instant technical debt cannot be pleasant. But, as with python3, systemd seems to be the way things are headed.

Why are we talking like this? We’ve been using systemd for over 5 years. It’s weird. Time loops.

Re: Avoiding Complexity with Systemd

#63

Post by throw0101a »

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…

> Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts.

Things would have been fine for a lot of people if they had stopped at SysV script replacing, and general start up.

At this point, with all the additional functionality continuously being added, I'm waiting for systemd to fulfil Zawinski's Law:

> Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

* http://www.catb.org/jargon/html/Z/Zawinskis-Law.html

* https://en.wikipedia.org/wiki/Jamie_Zawinski

Re: Avoiding Complexity with Systemd

#64

Post by mercora »

danny_sf45 wrote: post #50
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…

As a developer I prefer using systemd instead of containers to deploy Golang applications. Without (Docker) containers it is: - build Go binary and install it in production server - write and enable the systemd unit file With (Docker) containers it is: - write Dockerfile - install Docker in production server - build Docker image and deploy container in production server I get the appealing of containers when one prod…

i feel the same way, systemd also has some comprehensive sandboxing capabilities built-in.... i have my gripe with systemd too though. mostly with journald because it is slow, likely due to its on disk format, really could have used sqlite for this...

Re: Avoiding Complexity with Systemd

#66

Post by nmg »

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…

> 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

Re: Avoiding Complexity with Systemd

#67

Post by mjw1007 »

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?

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://en.wikipedia.org/wiki/Winner%27s_curse

Re: Avoiding Complexity with Systemd

#70

Post by christophilus »

danny_sf45 wrote: post #50
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…

As a developer I prefer using systemd instead of containers to deploy Golang applications. Without (Docker) containers it is: - build Go binary and install it in production server - write and enable the systemd unit file With (Docker) containers it is: - write Dockerfile - install Docker in production server - build Docker image and deploy container in production server I get the appealing of containers when one prod…

Same. I deployed a fleet of transcoding servers with the worker logic being a simple Go program. It was super simple with systemd.
Post reply on HN