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

Why Did ArchLinux Embrace Systemd? (2016)

reddit.com

Post reply on HN
Print view View original

51–60 of 132 posts

Re: Why Did ArchLinux Embrace Systemd? (2016)

#51

Post by kevin_thibedeau »

NotATroll wrote: post #24
darkwater wrote: post #5

Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only…

> just like PulseAudio does. I think part of it actually stems from people that had problems early on with PulseAudio, and have developed a vendetta against Poettering. Whether that vendetta is justified or not, I don't know. Personally systemd hasn't been a pain point. It's been far less of a headache than everyone at the office thought it would be.

Poettering used alloca() as a poor man's garbage collector. Proper manual memory management is just "too hard". Other lingering code quality issues surely remain when the primary author is taking these sort of shortcuts and not considering how to write robust C.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#52

Post by nerdponx »

dijit wrote: post #35

Ah, I'm going to lose karma here because I'm a sysadmin and not a programmer and programmers seem to really like systemd, and this forum is represented strongly by programmers. Regardless, every time these types of threads come about I feel like I _have_ to speak because there's a lot of bitterly divided people regarding this issue. (or, rather the people who are bitterly opposed and the people who don't care, think…

Well-said. Hopefully this gets upvoted further.

I'm a sysadmin and not a programmer

SystemD is amazing on my laptop, I am really happy with it. But for my servers I am very unhappy with it

I think this is what it comes down to. The end-user experience is pretty good, just like the end-user experience for MacOS and even Windows nowadays is pretty good. But that also means you could replace Systemd with a similar system built on similar concepts, and the end-user experience would still be pretty good.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#53

Post by Varriount »

JohnFen wrote: post #44
darkwater wrote: post #5

Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only…

> it Just Works™ for the vast majority of use cases, just like PulseAudio does. I am not in the vast majority of use cases, then, because systemd is a serious pain in my butt. But then, so is PulseAudio (which is why I make sure it's never installed). My issues with systemd (both technical and as an andicator of the direction Linux is going) are severe enough that I'm actively preparing to move all of my machines ove…

What issues do you run into?

Re: Why Did ArchLinux Embrace Systemd? (2016)

#54

Post by megous »

ChristianBundy wrote: post #42
megous wrote: post #31

Earlier quoted context omitted.

Until it doesn't. Until very recently having wrong permission on one of the networkd config files would result in networkd ignoring the rest of the perfectly readable network configuration files too, cutting off all network connectivity. (Systemd also requested the permission change iself.) Currently there's a bug where if you have a bridge and all interfaces are disconnected from the bridge (I use hot-pluggable USB…

To be fair, this seems like an illustration of GP's point: > complex corner-cases that only a a very tech-savvy user could generate in the first place I agree that an init system should work on complex corner-cases, but systemd remains popular because it works for most people most of the time. Tangent: have you found an init system that you like the most? I've only used four or five init systems and don't have any su…

Having a bridge or wireguard interface and following suggestions in system logs is not really a complex corner case. At least I don't think so.

I like systemd and use it everywhere (I use Arch Linux / Arch Linux ARM mostly). I just don't think it needs to be painted all pink as "Just Works[tm]" software.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#55

Post by agumonkey »

thayne wrote: post #7
darkwater wrote: post #5

Looking back, I still don't get all the hatred that SystemD got (and sometimes is still getting). A part from some nice-to-have missing niche features (I'm looking at you, retries management with one-shots), it Just Works™ for the vast majority of use cases, just like PulseAudio does. The fact is that the minority which indeed have problems is very vocal because those problems come from complex corner-cases that only…

I think ultimately a lot of the systemd hate is just fear of change and not wanting to give up an init system they are famiiliar with.

Something bothers me when they talk about fear of change. Some changes are consensual, some are mostly agreed upon organically and then you have cases like systemd who fueled lengthy debates. I don't like to ignore this as "fear of change".

Re: Why Did ArchLinux Embrace Systemd? (2016)

#56

Post by dijit »

kbumsik wrote: post #41
djsumdog wrote: post #27

After listening to the BSD Canada talk on systemd and BSD, I agree Linux does benefit from a system layer. But I still hate the implementation, and you can't easily swap out stuff. I really like logrotate and syslog and not needing journalctl for stdout/err logs from services. It's one of the things that makes working with Docker containers so much nicer too, because you have sane commands to get logs for services; w…

> After listening to the BSD Canada talk on systemd and BSD For someone who don't know, here is the video "The tragedy of systemd". This is a really good talk. https://youtu.be/6AeWu1fZ7bY

All respect to the author of that talk.. but "just get over it" and "embrace change" is not compelling to those who have very searing issues with systemd.

I do not consider this to be a good talk because it paints dissenters as "not embracing change" because.. they are stupid?

It also makes the argument that the only thing that exists outside of systemd is sysvinit.

He also seeks to make Lennart a martyr because of death threats. (which, btw, seriously it shouldn't even be said that that is unacceptable, some people are fucked up).

Oh, and systemd definitely didn't invent cgroups, an engineer at google did and they don't even use systemd to run GCP compute hypervisors.

Benno so thoroughly misrepresents those that have issues with systemd that I can't help but feel it was intentional.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#57

Post by bitwize »

megous wrote: post #33
megous wrote: post #31

Earlier quoted context omitted.

Until it doesn't. Until very recently having wrong permission on one of the networkd config files would result in networkd ignoring the rest of the perfectly readable network configuration files too, cutting off all network connectivity. (Systemd also requested the permission change iself.) Currently there's a bug where if you have a bridge and all interfaces are disconnected from the bridge (I use hot-pluggable USB…

I'd like something like systemd, but with all high-level internals written in a embedded scripting language.

Might want to look into GNU Shepherd. The whole thing is written in Scheme.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#58

Post by geggam »

ultraism wrote: post #34
yarrel wrote: post #8

Earlier quoted context omitted.

If we're not afraid of change, Let's change away from systemd.

There was a switch away from SysV init for particular reasons, not change for the sake of change.

You know, everyone says this but every server I worked on (several thousands) which used sysvinit I cant remember any issues with startups that couldn't easily be scripted around.

I still dont understand what issues are fixed with systemd and I am aware of many it has created.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#59

Post by znpy »

valeg wrote: post #48

I prefer this approach: > Systemd is included by default but not enabled. You can scan your MX system and discover files bearing "systemd" names, but those simply provide a compatibility hook/entrypoint when needed. > MX Linux uses systemd-shim, which emulates the systemd functions that are required to run the helpers without actually using the init service. This means that SvsVinit remains the default init yet MX Li…

> MX Linux is a cooperative venture between the antiX and former MEPIS communities

Ah! SimplyMEPIS (a live version of MEPIS) was the first gnu/linux system I booted on my (dad's) P3 desktop computer in circa 2003-2004!

Re: Why Did ArchLinux Embrace Systemd? (2016)

#60

Post by djsumdog »

dijit wrote: post #56
kbumsik wrote: post #41

Earlier quoted context omitted.

> After listening to the BSD Canada talk on systemd and BSD For someone who don't know, here is the video "The tragedy of systemd". This is a really good talk. https://youtu.be/6AeWu1fZ7bY

All respect to the author of that talk.. but "just get over it" and "embrace change" is not compelling to those who have very searing issues with systemd. I do not consider this to be a good talk because it paints dissenters as "not embracing change" because.. they are stupid? It also makes the argument that the only thing that exists outside of systemd is sysvinit. He also seeks to make Lennart a martyr because of d…

I didn't get that from his talk. I think it was more of a, "BSD should have a system layer. How can we make one that's way better?" .. that doesn't do all the things people hate systemd for doing.
Post reply on HN