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

41–50 of 132 posts

Re: Why Did ArchLinux Embrace Systemd? (2016)

#41

Post by kbumsik »

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

Re: Why Did ArchLinux Embrace Systemd? (2016)

#42

Post by ChristianBundy »

megous wrote: post #31
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…

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 super strong opinions -- maybe because I'm not running and SBC farm. :~)

Re: Why Did ArchLinux Embrace Systemd? (2016)

#43

Post by kissgyorgy »

megous wrote: post #31
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…

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…

nobody talked about systemd-networkd, that's a separate project and binary.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#44

Post by JohnFen »

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 over to BSD.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#45

Post by dijit »

Analemma_ wrote: post #15
crankylinuxuser wrote: post #9

Earlier quoted context omitted.

The problem is when "It just works" doesnt, it's an undebuggable, un-understandable, documentationless kluge with binary logs. I had it silently take over my DNS . I even have the 'official' way check-boxed to not override DNS settings in Network Manager. Does so anyway. I even removed the symlink from /etc/resolv.conf and made it root:root . SystemD changed it next reboot.

> The problem is when "It just works" doesnt, it's an undebuggable, un-understandable, documentationless kluge with binary logs. Init scripts were undebuggable, un-understanable, documentationless kluge with text logs, and systemd has a perfectly functional format converter. I'm not seeing the regression here.

2 things;

1) Init scripts varied by implementation very much, I have managed to successfully debug, make, read and otherwise modify/parse init scripts from basically every _major_ distro including OpenBSD and FreeBSD.

I am not particularly intelligent, so if I can do it, you can.

2) There is no reason to assume we go back to bash scripts per-se, there is a huge middle ground between a huge C program which execve()'s programs and watches them live, parses their output, logs it, enables socket activation, keeps an in memory DAG that it determines randomly on boot.... and bash scripts.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#46

Post by kissgyorgy »

skywhopper wrote: post #25
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…

systemd did solve lots of problems, particularly for workstations, but it has done its work by tearing down and replacing plenty of components that didn’t need replacing, reinventing solutions that already existed, and eliminating pragmatic options for troubleshooting often out of some blindly overapplying some principles that don’t make sense in every context. And unfortunately its architecture is such that you can’…

You mentioned no concrete examples, without them, your comment is just your opinion, not really adding to the conversation.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#47

Post by MuffinFlavored »

djsumdog wrote: post #32
KingMachiavelli wrote: post #3

> What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. As a distro and philosophy, Archlinux was bound to adopt systemd eventually. e.g. Maintaining you're own init system/scripts is not KISS. Creating a custom init file to adapt 90% of software from systemd to another init system is not KISS.

Gentoo, Alpine and Void still default to using their own init systems.

It seems Alpine uses Gentoo's OpenRC init system from a quick Google.

https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System

https://wiki.gentoo.org/wiki/OpenRC

Re: Why Did ArchLinux Embrace Systemd? (2016)

#48

Post by valeg »

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 Linux can use Debian packages that have systemd dependencies such as CUPS. This approach also allows the user to retain the ability to choose his/her preferred init.

Source: https://mxlinux.org/about-us/

Re: Why Did ArchLinux Embrace Systemd? (2016)

#49

Post by efiecho »

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.

Sigh, this argument just has to come up in every discussion on Systemd. Anyone who dare to be critical about Systemd is apparently just a Luddite afraid of change. You know what, I have no problems with change at all, only when the change is to something worse.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#50

Post by megous »

I agree with an event driven supervisor daemon architecture, and that shell scripts are inefficient.

But writing everything in C in non-scriptable way may be a bit of over-reaction to the old ways of having everything scripted in the least efficient way possible.

I also write my init systems in C (not for generic Linux distro, mostly for embedded HW/mobile use), but I'm planning to make it so that I have a program in C that offers some primitives and the core logic will be implemented using an embedded JS engine, so that it's scriptable and fixable without re-compilation.

Post reply on HN