Live data from Hacker News

Why Did ArchLinux Embrace Systemd? (2016)

reddit.com

91–100 of 132 posts

Re: Why Did ArchLinux Embrace Systemd? (2016)

#91
post #87
post #84

Earlier quoted context omitted.

> as a developer I just want something that works, has decent interfaces and abstracts away so I can care a lot less about it. As a sysadmin, I want something to be debuggable because I'm the one who gets paged when the failure rates increase.

On to microservices with you and give the developer the pager! Embrace the change :)

I mean.. I'm still on the hook for Kubernetes nodes being available..

Re: Why Did ArchLinux Embrace Systemd? (2016)

#92

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…

Before using SystemD for the first time, I also wondered if there is any grain of truth in what its opponents said about SystemD. However, after trying SystemD for one week, I became convinced that the designers of SystemD are incompetent, so they cannot be trusted with a component of such importance for a computer. I am normally a Gentoo user, but a few years ago I wanted to install Linux in a hurry on a small compu…

Do you count signals as inter-process communication? I'd argue they are, and the init system definitely needs to cleanly shut down the system (using signals, at least). What degree of inter-process communication is acceptable, then?

Re: Why Did ArchLinux Embrace Systemd? (2016)

#93
post #79

Earlier quoted context omitted.

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)

I think the OP meant s6 and not s9.

runit, s6 and also nosh are all daemontool-style init systems, which have a somewhat different idea how to do things than systemd all, but all are inspired by the original daemontools package.

s6 and nosh have decent overviews:

https://skarnet.org/software/s6/ https://jdebp.eu/Softwares/nosh/guide/introduction.html

The original daemontools: https://cr.yp.to/daemontools/faq/create.html#why

I'll let others decide whether these are better or worse than systemd. I go with whatever my distro would give me, since picking a different init system is too much work...

Re: Why Did ArchLinux Embrace Systemd? (2016)

#94
post #68

Earlier quoted context omitted.

Before using SystemD for the first time, I also wondered if there is any grain of truth in what its opponents said about SystemD. However, after trying SystemD for one week, I became convinced that the designers of SystemD are incompetent, so they cannot be trusted with a component of such importance for a computer. I am normally a Gentoo user, but a few years ago I wanted to install Linux in a hurry on a small compu…

The more you have to deal with systemd, the more you hate it. I wrote maybe two dozens of unit files at this point and can't take seriously any praise of systemd anymore, I immediately assume such people don't actually do anything with it beyond starting and stopping services.

I don't mind systemd and I've administered a lot of stuff with it at this point, well beyond just start/stopping services -- I've written plenty of unit files, written drop-in unit file overrides, written timer units, written auto-mount units, looked at startup timing profiles, debugged issues using journalctl, etc.

If I had to guess, it's probably because I've never ran into any of the weird systemd problems that I see people report sometimes. For me, it's always pretty much just worked, and more often than not it natively has the functionality that I want.

My largest complaint is that I have to bounce across several manpages to write a comprehensive unit file.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#95
post #92

Earlier quoted context omitted.

Before using SystemD for the first time, I also wondered if there is any grain of truth in what its opponents said about SystemD. However, after trying SystemD for one week, I became convinced that the designers of SystemD are incompetent, so they cannot be trusted with a component of such importance for a computer. I am normally a Gentoo user, but a few years ago I wanted to install Linux in a hurry on a small compu…

Do you count signals as inter-process communication? I'd argue they are, and the init system definitely needs to cleanly shut down the system (using signals, at least). What degree of inter-process communication is acceptable, then?

Not OP, but I would consider SIGTERM as IPC, but SIGKILL as not really IPC (since the target can't respond to it).

Traditional RC does a SIGTERM to everything, and then waits a bit and then does a SIGKILL to everything. This means that if the SIGTERM failed to be handled properly, progress is still made.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#96

Earlier quoted context omitted.

systemd did bring them mainstream, but yea cgroups were around for years before systemd was a thing. But they were mostly independently managed by some small daemons that did things based off rules and other things like that mostly. Systemd changed how they got used, primarily because multiple management systems working with them tends to cause issues, but using them for low impact isolation and tracking of daemons a…

I think Docker had a bigger influence on cgroup use than systemd.

I disagree because everybody who uses Ubuntu is using systemd, but only a fraction of them use docker.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#97
post #96

Earlier quoted context omitted.

I think Docker had a bigger influence on cgroup use than systemd.

I disagree because everybody who uses Ubuntu is using systemd, but only a fraction of them use docker.

Ubuntu uses snaps heavily bringing cgroups to play.

Re: Why Did ArchLinux Embrace Systemd? (2016)

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

Java or any other garbage collected language is memory safe by design.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#99
post #89
post #86

Earlier quoted context omitted.

I think C requires more of people. Granted I am no C expert but having worked in the industry a couple decades I have made conclusions based on observations. As a sysadmin I wrote a small kernel module to trigger a panic on a certain condition hoping to capture some info in a dump several years ago. Today I cant find sysadmins who can use a CLI properly. The goalposts have moved inwards IMO Not sure its bad thing eit…

It's kind of like back in the day Emacs was considered a programmer's tool. Yet secretaries not only used it, they learned how to configure it to their liking in Lisp! (If you tell a normie they are "customizing" the editor rather than "programming" it, they won't even realize it's hard!) These days, people calling themselves professional developers with years of experience won't even touch Emacs.

Plenty of people still use Emacs.

I picked it up several months ago after using Jetbrains IDE's for quite a long time, and honestly haven't felt the need for any of what Jetbrains brought to the table.

Mostly thanks to LSP.

If you're not a Java developer, Emacs is perfectly fine as a configurable extensible editor. With the additional caveat that its lack of multithreading can get in the way sometimes.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#100
post #22

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…

> Systemd is turning "init" into a framework of ... This is conflating the systemd project and they systemd init system. Most of the things you mention are seperate systems (systemd-resolved,logind, polkit, etc.) that are part of the systemd project and interoperate with the systemd init system, but are not part of the init system itself.

Agreed and the conflation is somewhat intentional. When you install a system, you get all of that. Custom kickstart files can strip away some of it. For the longest time, you would get polkit regardless. The rpm spec file was changed about a year or two ago so that it can be removed if someone did not exclude it specifically. To be fair, each OS maintainer is including or excluding bits of systemd in the default configurations, so that is not entirely systemd's responsibility. Every year systemd appears to be subsuming more and more system functionality.
Post reply on HN