Live data from Hacker News

Why Did ArchLinux Embrace Systemd? (2016)

reddit.com

101–110 of 132 posts

Re: Why Did ArchLinux Embrace Systemd? (2016)

#101
post #30

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.

Binary logs seem great on macOS, why is this bad for Linux?

Re: Why Did ArchLinux Embrace Systemd? (2016)

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

Thankfully, changing Linux distributions or switching to a BSD is significantly easier than the significant legal hurdle of immigrating to a country that doesn't have a reputation for being an easy country to immigrate to.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#103
post #33
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.

init.d was nice, using shell scripts. readable, editable, clean, extendable. I liked that

Re: Why Did ArchLinux Embrace Systemd? (2016)

#104

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

Alpine has to use OpenRC rather than systemd because it's designed to run in containers. Using cgroups or lxc requires running your container with elevated privileges. This doesn't only affect systemd, it also makes it impossible for me to run Nix builds in unprivileged containers with isolation enabled, since isolation requires cgroups.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#106
post #38

I don't particularly care for Systemd, just out of principle, but I don't mind using it. Personally, I feel Arch Linux went downhill after Judd left. Maybe I'm naive, but I absolutely loved Arch's 'rc.conf', which was basically an entire system config in one file. That going away, and the adoption of Systemd, really made it feel like a different distro. Not better or worse, mind you, just different.

Take a look at NixOS, the entire OS is declarativily defined and can be stored in git.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#107
post #58

Earlier quoted context omitted.

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.

I am not convinced every sysadmin could ‘easily’ script around init issues on the servers they manage, but I’ll give you that.

The real issue isn’t with servers, it’s with desktop systems and laptops. When users plug in a USB sound card or plug their laptop into a dock, they don’t want to (and likely couldn’t) “easily script around” that; they expect an audio device, network connection, video card to be created without any user intervention, and go away when devices get unplugged.

Making a set of init scripts (and surrounding unload and reload scripts) robust against insertion and removal of any of many different devices isn’t easy even for init script gurus, and would lead to duplicated code for detecting and handling the various load/unload conditions.

That, I think is the primary reason Apple went with launchd. Systemd took that idea. There’s nothing wrong with that.

The main issues with systemd, IMO are a) initially it was buggy, and b) tremendous scope creep.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#108
post #89

Earlier quoted context omitted.

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.

I use Emacs, but at my last few jobs I was just about the only one.

Re: Why Did ArchLinux Embrace Systemd? (2016)

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

What issues do you run into?

My intention is to express my dissatisfaction with systemd, not to get technical support, so I'm not going to list them here. Nothing good can come from doing so. But I will say that in terms of actual pain points, the biggest ones have been around logging.

However, technical headaches aren't my largest objection -- my largest objection is that its getting increasingly obvious that as we move into the future and more applications rely on systemd-specific facilities, it's going to get more and more difficult to operate a Linux system without it.

Re: Why Did ArchLinux Embrace Systemd? (2016)

#110
post #58

Earlier quoted context omitted.

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.

I am not convinced every sysadmin could ‘easily’ script around init issues on the servers they manage, but I’ll give you that. The real issue isn’t with servers, it’s with desktop systems and laptops. When users plug in a USB sound card or plug their laptop into a dock, they don’t want to (and likely couldn’t) “easily script around” that; they expect an audio device, network connection, video card to be created witho…

>The real issue isn’t with servers, it’s with desktop systems and laptops. When users plug in a USB sound card or plug their laptop into a dock, they don’t want to (and likely couldn’t) “easily script around” that; they expect an audio device, network connection, video card to be created without any user intervention, and go away when devices get unplugged.

Bingo !

Folks who know, and I mean really understand how to run servers know how to script init.

Folks who use Linux on the laptop / Admin Ubuntu do not and systemd makes them able to do stuff "most of the time"

There is no reason to force systemd as the default for servers. You dont plug things into servers and in fact you dont want some service monitoring servers so someone can stick something in a server and start rooting around it.

Post reply on HN