Live data from Hacker News

Replacing Systemd with OpenRC in Debian

danielcordova.me

121–130 of 168 posts

Re: Replacing Systemd with OpenRC in Debian

#121
post #54

Earlier quoted context omitted.

It doesn't suck, people are just emotional beings and have some "football team" level takes on technical stuff as well. The very same people that hate systemd for "being a monolith" and limiting choice are usually also love X and hate Wayland where they can manage to explain how being a monolith is suddenly good. Especially that systemd is pretty modular - at least the actual systemd program running as PID 1. It also…

Both systemd and wayland were quite broken when they were first being pushed onto everyone... they're mostly fine now.

You forgot pulseaudio to the list!

Wayland's big problem right now is that libinput developers gatekeep improvements so if your device isn't on the golden list it will work badly and there is no escape. Which is why I'm not using wayland.

Re: Replacing Systemd with OpenRC in Debian

#123
post #106

Earlier quoted context omitted.

The expressed intention behind adding the DoB field is to comply with age verification laws. Intent matters a whole lot here.

> comply with age verification laws Do you want the developers to ignore the law and in the case of companies like Red Hat etc be vulnerable to law suits?

Yes. Stand up and be a test case like Bernstein. Show some guts.

In the case of a company there’s even less at risk, and a lot of good will to be farmed.

Re: Replacing Systemd with OpenRC in Debian

#124

Earlier quoted context omitted.

> comply with age verification laws Do you want the developers to ignore the law and in the case of companies like Red Hat etc be vulnerable to law suits?

Yes. Stand up and be a test case like Bernstein. Show some guts. In the case of a company there’s even less at risk, and a lot of good will to be farmed.

Are you offering to pay for their lawyers?

Re: Replacing Systemd with OpenRC in Debian

#125
post #119

Earlier quoted context omitted.

IIRC laws in some US states will require OS's to collect the age of the user so services can age restrict, it does not mandate any kind of ID verification. It doesn't matter it's an open source project, ultimately it ends up in commercial products which do require following the rules.

The commercial products can patch it then if they so wish.

The field does nothing when left untouched, which it is by default.

If having the ability to set a piece of metadata worries you, don't set it.

Re: Replacing Systemd with OpenRC in Debian

#126
post #2

systemd desperately needs competition. it isnt just that it became a dependency for every low level service and a potential vector for privacy invasion, it's also janky to use.

I do agree that systemd could use some competition, but until someone builds one, we're going to be dealing with some systemd defaults. Canonical's attempts seem to have been most complete, but outrage at change and different ideas have shut down most of Canonical's attempts to improve the situation.

It's far from janky, at least compared to what else is out there for Linux. If you're not writing systemd service files, you're almost surely back to writing unpredictable 80s style scripting jank.

Re: Replacing Systemd with OpenRC in Debian

#127

Earlier quoted context omitted.

Partition autodiscovery is pretty neat. I did my archlinux install with it using this guide[0]. I have never touched /etc/fstab and I have had zero to worry about corrupting a boot with wrong fstab entries. [0] https://walian.co.uk/arch-install-with-secure-boot-btrfs-tpm...

My searches for "systemd partition autodiscovery" lead me to [0]. In the table labeled "Table 1. Partition Type GUIDs", we find this in the Explanation section for 'SD_GPT_HOME' The first partition with this type UUID on the same disk as the root partition is mounted to /home/. ...you can't spread your /home and / partitions on separate disks and use this? In fact, it looks like you can't use this autodetection unles…

> you can't spread your /home and / partitions on separate disks and use this

No, you'll need to add a line to your fstab manually if you want something autodiscovery cannot do, like multi-disk setups, LVM, and FDE with unsupported configurations. It's great if it works for you and a very minor change if it doesn't.

I don't recall ever installing a system with / and /home on separate partitions, though.

Re: Replacing Systemd with OpenRC in Debian

#128
post #25

Earlier quoted context omitted.

They're separate programs and system services which all more or less just do their own thing, just developed under the systemd umbrella. So it can't be "toggled", you can just not use the parts of systemd you don't want. But it's meant to work as a cohesive system when everything in systemd is used together. FWIW, I think it's great that someone is trying to make a coherent set of system services for Linux. Things te…

It's great that the same someone has formed a company called Amutable which has the sole purpose of converting Linux to a locked-down immutable OS where the users doesn't have the key. Also it's interesting that a set of simple interfaces have worked for so long. Maybe they did something wrong that it didn't break? See: https://www.amutable.com

> converting Linux to a locked-down immutable OS

That approach is part of why Valve has been able to ship Linux to general consumers.

I don't know exactly why you'd go for amutable specifically, but not handing users the key is a huge benefit to any company-owned hardware out there.

Re: Replacing Systemd with OpenRC in Debian

#129
post #43

I have a curious question. My local setup has worked for me for ages ever since arch decided to switch to systemd. Same on the servers I deal with, after Debian's switch. At the same time, I can say I'm not involved with inner workings of a Linux system enough, to be affected by init system change and the pain it might bring. In other means consider me an average Joe of the Linux world. Hence this question: If it suc…

systemd replaces the duct-tape-and-tie-wrap systems that many Linux distros used to run with a unified set of tools, which can be interchanged, but often aren't. You don't have to enable container support, DNS servers, or disk mounts in systemd, but support is there in case you need it. Some distros stopped shipping bespoke DNS servers, others still do, it depends on the distro; it's not like distros are forced to enable the whole set. I don't know any distro that actually does, actually.

If you're the kind of person that wants to deliberately choose what software handles your DNS and what software configures your TTY and which cron daemon you use, then systemd limits your options somewhat. If you want to go in and re-write the init scripts for a system daemon because you have specific requirements, you still can but it adds a level of indirection to the whole thing.

systemd works great for the 95% who can do with a reasonable set of defaults. The remaining 5% will run into annoyances about defaults and obscure configuration, and a small (but extremely loud) subset of those people hate the idea of one set of software taking over so many tasks.

In reality, the option not to use systemd has always been there, but many distros find it much easier to use and most software doesn't bother with the ancient init scripts anymore. You can install openrc, but you're going to need to write most of your service management configuration (often shell scripts) yourself

Re: Replacing Systemd with OpenRC in Debian

#130
post #25

Earlier quoted context omitted.

They're separate programs and system services which all more or less just do their own thing, just developed under the systemd umbrella. So it can't be "toggled", you can just not use the parts of systemd you don't want. But it's meant to work as a cohesive system when everything in systemd is used together. FWIW, I think it's great that someone is trying to make a coherent set of system services for Linux. Things te…

It's great that the same someone has formed a company called Amutable which has the sole purpose of converting Linux to a locked-down immutable OS where the users doesn't have the key. Also it's interesting that a set of simple interfaces have worked for so long. Maybe they did something wrong that it didn't break? See: https://www.amutable.com

Lennart Poettering will not rest until all software is completely unusable.
Post reply on HN