Live data from Hacker News

Avoiding Complexity with Systemd

mgdm.net

51–60 of 357 posts

Re: Avoiding Complexity with Systemd

#51
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…

I think it's also because those people that didn't want systemd have just moved on. I moved my servers to alpine and my desktop to FreeBSD. It's just not a thing in my thoughts anymore. I wouldn't write about it. So it seems the Linux community is more aligned now.

However alpine is working on a similar thing based on s6 but with modularity and lightweightness as design goals. This sounds great to me. I'm not against the idea of a service manager, but I think systemd is overreaching.

Re: Avoiding Complexity with Systemd

#52
post #27
post #20

You incur complexity with systemd. You avoid complexity with runit.

IMO runit is abandonware at this point. No release since 2014. Have you looked at s6? It’s a compelling alternative.

Runit is finished at this point. It does what it says, and I haven't run into bugs.

Churn isn't a virtue.

Re: Avoiding Complexity with Systemd

#53
My problem with systemd is that it's just so poorly written.

The ideas are not inherently bad. But they're not thought through, and the implementation is pure garbage.

Like taking the most stable software in the world[1], and going "nah, I'll just replace it with proof-of-concept code, leaving a TODO for error handling. It'll be fine.".

And then the "awesomeness" of placing configuration files whereever the fuck you want. Like /lib. Yes, "lib" sounds like "this is where you place settings file in Unix. At least there's no other central place to put settings".

[1] Yes, slight hyperbole. But I've not had Linux init crash since the mid-90s, pre-systemd

Re: Avoiding Complexity with Systemd

#54
post #17
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…

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

Re: Avoiding Complexity with Systemd

#55
Whenever these discussions of systemd come up, I am reminded of this talk[0].

It will be interesting to see if one day a replacement for systemd comes along and people who once championed systemd will begin to use the arguments the people who do not prefer systemd use to defend their choices for not wanting to use the next init system manager.

[0]: https://youtu.be/o_AIw9bGogo

Re: Avoiding Complexity with Systemd

#57
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?

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"

Re: Avoiding Complexity with Systemd

#58
post #52
post #27

Earlier quoted context omitted.

IMO runit is abandonware at this point. No release since 2014. Have you looked at s6? It’s a compelling alternative.

Runit is finished at this point. It does what it says, and I haven't run into bugs. Churn isn't a virtue.

Exactly this. Runit was designed to be simple and in simple software, at some point, there is just not much to improve.

Re: Avoiding Complexity with Systemd

#59
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…

I think it's also because those people that didn't want systemd have just moved on. I moved my servers to alpine and my desktop to FreeBSD. It's just not a thing in my thoughts anymore. I wouldn't write about it. So it seems the Linux community is more aligned now. However alpine is working on a similar thing based on s6 but with modularity and lightweightness as design goals. This sounds great to me. I'm not against…

If anyone's interested here are the details: https://skarnet.com/projects/service-manager.html

Re: Avoiding Complexity with Systemd

#60
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…

I’ve since moved away from systemd for all my Linux boxes, work and home.

We still cannot block systemd from making a network socket connection so security model is shot right there by the virtue of systemd running as a root process.

In the old days of systemd, no network sockets were made.

Systemd has become a veritable octopus.

Now, I use openrc and am evaluating S6.

Post reply on HN