271–280 of 416 posts
>The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd Do people who really uses LFS even want GNOME or KDE on their system ?
Earlier quoted context omitted.
I have been saying for years that Microsoft would eventually deprecate WinNT and switch Windows over to a Linux foundation. Things seem to be slowly but continually moving in that direction.
Makes no sense to dump a superior kernel and executive for Linux. The Win32 layer is the issue, not the underbelly.
At this point in time, having programmed deep in the internals of both Linux and Windows, I think it is probably incorrect to call either kernel an inferior or superior one.
I mean, it was true for both of them at some point (Overlapped IO was great on Windows and missing on Linux, for example) but today, in 2026, the only differentiating factor is the userland experience.
For me, Windows loses this hands down.
This is a mindblower. To quote Bruce Dubbs: ''As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. Yes, systemd provides a lot of capabilities, but we will be losing some things I consider impor…
I don't mind the inevitable death of System V. It's an archaic relic of the Linux era. Going systemd-only is not necessarily a good choice (though I do understand it from a practical point of view). There are other, better alternatives for System V that are smaller and more modular so you still get the Unix "feel" without the absurd complexity of interlinked shell scripts that System V relies on. I'd like to see Open…
The reason it is being removed is precisely because now we are in the Linux era, no longer in the Unix era.
Have another vote in favour of OpenRC, and even Upstart, if it somehow revives.
Earlier quoted context omitted.
Not as much as people in Linux community think, especially those that never used commercial UNIX offerings. GPL is on its way out, a good example is that all Linux competitors in the embedded space, including Linux Foundation's Zephyr, none of them has adopted GPL. GPL based software is now a minority, almost everything uses licenses that businesses rather reach for.
I will be honest mentioning Zephyr in a situation when talking about how outdated the Unix design philosophy is, is a bit funny to me since Zephyr (like ecos kinda did once) tries to be Posix-like in its APIs (but ends up not really improving things over the other embedded OSes TBH).
Earlier quoted context omitted.
OpenRC on Gentoo works great. I have a full bleeding edge Wayland KDE Plasma with Pipewire setup that I game on. OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things. There are growing pains. https://bugs.gentoo.org/936123 Especially when upstream hard requires systemd. More annoying when there's no real…
To pile on, a minimal OpenRC service file is just as complicated as a minimal SystemD service file; that is, they're both almost-exclusively composed of key-value pairs. For instance, this is the service file for the 'rsyncd' service [0]: #!/sbin/openrc-run command="/usr/bin/rsync" command_args="--daemon ${RSYNC_OPTS}" pidfile="/var/run/${SVCNAME}.pid" depend() { use net } Like SystemD, OpenRC provides pre/post start…
Depending on what you want to do, a generator might be appropriate:
> Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins
Earlier quoted context omitted.
There is a book on that, gets posted every now and then on HN. In case you never read it, https://web.mit.edu/~simsong/www/ugh.pdf Hardly the piece of OS beauty that gets praised about FOSS circles.
I love that book but isn’t it nearly 30 years old?
Earlier quoted context omitted.
What practical problems do you run into with systemd? All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic". But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems. People complain in website comment se…
Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound. But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup. To give you concrete examples: 1. Systemd has mount…
I hate mounts in systemd.
Lots of pearl clutching in here about it, tho
The proof in the end that SystemD is a cancer in the Linux ecosystem. Officially it is just a stack and you can decide to use another one if you don't like it. Unofficially RedHat money ensured that other critical stacks will depend heavily on it so that you can't easily swap without replacing the whole ecosystem.
The whole GNU / Red Hat platform is this way. Try switching out Glibc. You get the same "you have to use all our stuff" dependencies.