Why Did ArchLinux Embrace Systemd? (2016) • Hacker News Board

Re: Why Did ArchLinux Embrace Systemd? (2016)

#71

Post by megous » Mon, Oct 21, 2019, 5:39 PM UTC

bitwize wrote: post #57

megous wrote: post #33

Earlier quoted context omitted.

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.

It seems to have a very limited scope of just managing services. I sort of like that systemd is more tightly integrated with Linux and for example listens on netlink for network changes, or device hotplug events, or on input events for (power) button events, and allows to reconfigure the system based on changes dynamically, etc.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#72

Post by tracker1 » Mon, Oct 21, 2019, 5:40 PM UTC

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…

I'm mixed on this... as a developer I just want something that works, has decent interfaces and abstracts away so I can care a lot less about it. SystemD does most of this for me.

Also, echoed in another comment, I'd just assume use Docker and/or K8s and/or dokku for most of the services I write anyway. Frankly, I care about writing the applications and services that solve problems for me, I don't want to spend as much time on system administration or CI/CD infrastructure as I already to.

In the end, it does a better job at most of the problem space in most ways compared to the alternatives. I have to google for it any time I actually interact with it anyway, which is what I did with older initd systems, so I'm not really that enthusiastic one way or the other.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#73

Post by agumonkey » Mon, Oct 21, 2019, 5:47 PM UTC

silon42 wrote: post #30

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.

I like systemd, but agree that binary logs are a horrible idea.

the initial goals was laudable though, is there a way to have text logs and verifiability

Re: Why Did ArchLinux Embrace Systemd? (2016)

#74

Post by bitwize » Mon, Oct 21, 2019, 5:48 PM UTC

Ah, systemd. It's one of those things where I'm glad it exists, but I hate it. I'm glad it exists because more open source is good, and diversity of implementations is good. I hate it because it complicates my machine's startup process, and my life, unnecessarily, and puts a lot of shit in pid 1 that shouldn't be there. I don't want it to become a hard dependency of my entire software stack. (Same with PulseAudio, hence why I am not currently a Firefox user.)

I left Arch after the systemd transition and didn't look back, but I wish Arch devs and users well.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#75

Post by notyourday » Mon, Oct 21, 2019, 5:49 PM UTC

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.

So does any init system or process supervisor system that has more than trivially tiny installation base.

The entire point of developing a new one is to reduce the number of the minority cases when it does not "Just Works(tm)"

Look at monit. It "Just works(tm)" for 99.9% of the use cases but boy its single threaded, everything is sequentially controlled with multi-second granularity is infuriatingly bad if you are one of the unlucky souls that wants monit-like functionality where every group runs independently from the other groups.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#76

Post by bitwize » Mon, Oct 21, 2019, 5:50 PM UTC

kevin_thibedeau wrote: post #65

bitwize wrote: post #61

Earlier quoted context omitted.

Nobody can write robust C. The correct answer is Poettering should've switched to Rust. With few exceptions, any code base that has not yet done so should be considered brittle and bug-prone.

The problem is the Java generaton that never learned how to do it.

Somehow members of the JavaScript and Ruby generations pick up Rust rather easily, while those who pride themselves on having learned to write robust C (or C++) are flummoxed by it.

Hypothesis: C is so pathologically bad that it breaks brains.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#77

Post by dijit » Mon, Oct 21, 2019, 5:54 PM UTC

djsumdog wrote: post #60

dijit wrote: post #56

Earlier quoted context omitted.

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.

oooooo, the grandparents video is very different in tone than the version I watched, which is the same talk: https://www.youtube.com/watch?v=o_AIw9bGogo

I'm sorry, I had assumed I had seen the exact video, but I had just seen the talk from another venue.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#78

Post by LinuxBender » Mon, Oct 21, 2019, 5:54 PM UTC

barbecue_sauce wrote: post #19

LinuxBender wrote: post #10

Earlier quoted context omitted.

For me it was the scope creep. Systemd is turning "init" into a framework of all the vulnerable and bad ideas that Microsoft moved away from after Win95/XP. binfmt mount, intercepting and changing the behavior of DNS, polkit implementation, changing user authentication, so much more than I could put here. There are many desktop concepts being shimmed into servers that are simply not appropriate for a lean mean web ma…

Is it correct to even say that systemd "brought" cgroups and lxc? They seem like fairly independent projects.

I agree with you and edited my wording.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#79

Post by castis » Mon, Oct 21, 2019, 5:55 PM UTC

bugbug99 wrote: post #64

lykr0n wrote: post #12

Earlier quoted context omitted.

To what?

s9

What should someone google in order to find out more about this? (i tried, i got lots of information about the samsung phone, even with -samsung and various incantations of 'init', 'processes', 'linux', etc)

Re: Why Did ArchLinux Embrace Systemd? (2016)

#80

Post by slrz » Mon, Oct 21, 2019, 5:58 PM UTC

kevin_thibedeau wrote: post #51

NotATroll wrote: post #24

Earlier quoted context omitted.

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

As long as the allocation size is bounded (due to alloca/VLAs lacking any mechanism to signal allocation failure), what's the problem with that?