Live data from Hacker News

Why Did ArchLinux Embrace Systemd? (2016)

reddit.com

81–90 of 132 posts

Re: Why Did ArchLinux Embrace Systemd? (2016)

#81

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'm still convinced a part of it was trolling. Just straight-up "I don't know about this in any detail and I don't care about it, I just want to start shit" trolling, which took whatever legitimate criticisms there are and wrapped them in a thick shell of bad attitude and loudmouthed idiocy for the pure sake of it. Trolling doesn't mean someone's lying, after all; it just means someone's loud and obnoxious; look up Frankfort's definition of "bullshit" for more.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#82

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've been using Linux on the desktop since 2003. Linux audio support started out as a shit show that you could deal with tolerably well by buying supported sound cards. Pulseaudio seemed to simplify things until it didn't actually work. Until it inexplicably stopped working at intervals until load was such that it ended up out of sync by just a little bit etc. It simultaneously had a degree of complexity and configurability that suggested that maybe just maybe if you fiddled with a knob it would actually work until it didn't again.

If it just solidly didn't work at all it would have been annoying but this sort of kind of but never really consistently almost working is what makes you want to physically throw your computer through the nearest window.

Now it seems to work acceptably well save for the fact that guis still regularly have garbage interfaces and one weird stupid configuration.

Pulse by default remembers which device a particular app was outputting sound so you can switch the default device to headphones while say your browser isn't actually outputting sound via any tab and then you will open a sound producing tab and it "remembers" it was using the speakers and blares at full volume at 2AM. Thanks pulse.

This is configurable but who is going to figure that out?

I believe the relevant line is thus where the relevant part is restore_device=false

    load-module module-stream-restore restore_device=false
in /etc/pulse/default.pa

Regarding sound configuration virtually nobody wants different programs to output to different sound producing devices. This might be an important use case for some users but if you have 5 sound producing apps the process of switching from speakers to headphones should not be to move each one with 3 clicks per move. I almost exclusively perform 3 operations I turn the sound up or down and switch to and from headphones whereupon I expect everything including newly created streams to end up on the new device. The first 2 have dedicated buttons the third does not so I had to make it so.

Absent a dedicated button fewer steps would be nice last I looked a few years ago it was complicated in all environments I tried. Having the right answer to get a pleasant environment be write a shell script and fiddle with config files is probably not optimal.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#83
post #71
post #57

Earlier quoted context omitted.

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.

Maybe someone should extend shepherd.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#84
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 mu…

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

Re: Why Did ArchLinux Embrace Systemd? (2016)

#85
I would like to know what Arch Linux and the other distros thought of alternatives like runit, openrc, and BSD-style init.

I can at least sympathize with the arguments for systemd if the only other choice was SysV init scripts. As Richard Gooch once said, "These boot scripts, in the tradition of SysV, can do anything. They are flexible. They are scalable. They can run industrial-strength systems. Unfortunately, they're bloated and ugly. OK, maybe they're not ugly to everyone (not that I've ever heard anyone admit they're elegant, only 'it works'), but they sure are bloated. They are complex and hard to navigate." (http://www.safe-mbox.com/~rgooch/linux/boot-scripts/)

But the choice was never just between SysV init or systemd. Couldn't Linux have done something like FreeBSD's rc? Or I read about the daemontools family of init systems, like runit, which is what Void Linux uses. These systems sound like they solved SysV's problems without adding systemd's. That is, they are more declarative, easier to maintain, can handle complex dependencies, and can run things in parallel. But they remained unixy: they are small, file-oriented, and don't swallow up adjacent software.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#86
post #76

Earlier quoted context omitted.

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.

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 either but it makes for interesting comparisons

Re: Why Did ArchLinux Embrace Systemd? (2016)

#87
post #84

Earlier quoted context omitted.

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 mu…

> 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 :)

Re: Why Did ArchLinux Embrace Systemd? (2016)

#88
post #44

Earlier quoted context omitted.

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

> I'm actively preparing to move all of my machines over to BSD You remind me of all those people who are going to move to Canada "any day now" because of Trump.

[flagged]

Re: Why Did ArchLinux Embrace Systemd? (2016)

#89
post #86
post #76

Earlier quoted context omitted.

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.

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.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#90
I think very few people criticise systemd for its init system, which is pretty decent as far as init systems go. The main complaint is everything else systemd does. It's trying to swallow the universe and there seems to be no limits to where its "scope" will end.
Post reply on HN