Given the popularity of systemd as a discussion topic on HN, I'm surprised there isn't much about OpenRC[0].
Does anyone know if Devuan have given it any consideration?
Linux greybeards release beta of systemd-free Debian fork
101–110 of 189 posts
Re: Linux greybeards release beta of systemd-free Debian fork
#102Earlier quoted context omitted.
Aside from the binary logs, which are really not a great idea, systemd adds orders of magnitude more complexity to a system that really didn't need it. The init system could have been addressed without something like systemd. I'm old enough to remember and use Unix. Like a lot of IT guys my age, we all tend to think that adding complexity is wrong. This notion of one ring to rule them all mentality is really starting…
I'm afraid you still haven't answered my question. Aside from binary logs, what binary blobs are you referring to in systemd?
I guess he means systemd being a compiled binary so how exactly a service file is processed is less clear as say with a sysvinit script
Re: Linux greybeards release beta of systemd-free Debian fork
#103I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look a…
I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look at BSD-style init scripts some time. They're beautiful in their simplicity and readability. They source a common set of functions, have well-defined variables to control execution, and end up with a length about that of systemd units, without sacrificing the po…
The Design and Implementation of the NetBSD rc.d system - http://www.mewburn.net/luke/talks/auug-2003/
Re: Linux greybeards release beta of systemd-free Debian fork
#104I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look a…
I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look at BSD-style init scripts some time. They're beautiful in their simplicity and readability. They source a common set of functions, have well-defined variables to control execution, and end up with a length about that of systemd units, without sacrificing the po…
Why in the world would you need to "start tracing through magic symlinks" with Systemd?
If you mean to figure out what was actually executed for a unit "systemctl cat [service name]" will tell you the full path of each file systemd processed for that service and what content was pulled from it.
Re: Linux greybeards release beta of systemd-free Debian fork
#105Earlier quoted context omitted.
I'm afraid you still haven't answered my question. Aside from binary logs, what binary blobs are you referring to in systemd?
I guess he means systemd being a compiled binary so how exactly a service file is processed is less clear as say with a sysvinit script
I can't see how that is the case. Why is this any less clear? I don't think following the Fedora debug guide is any less difficult than troubleshooting a SysV-init script.
https://fedoraproject.org/wiki/How_to_debug_Systemd_problems
It's curious that he says "Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device drivers under Linux are now almost all binary blobs."
That's not exactly true now, is it? He seems to be implying that there are closed source binaries in the Linux kernel...
Re: Linux greybeards release beta of systemd-free Debian fork
#106I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look a…
> sysvinit-script OpenRC fixes a lot of that, without adding the giant pile of dependencies that systemd imposes. As someone who is already comfortable with bash, OpenRC scripts should be easy. > I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. There are more options than sticking with Debian's ancient scripts. The larger problem is that init is only a tiny part of systemd. Systemd's ma…
> The larger problem is that init is only a tiny part of systemd.
That's because you can't reasonably fix the many problems with sysvinit (or OpenRC) without also providing a proper process manager, and dependency system that does far more than just trigger scripts in the right order.
The biggest problem with init is that it's just init.
> Do you enjoy depending on a moving target that changes at the whim of the systemd cabal and their reputation for WONTFIXing anything that they don't understand or haven't considered as a use case?
I don't enjoy that, but the alternative of relying on sysvinit or OpenRC is so many times worse.
Give me a better alternative, and I'll throw Systemd out of the window immediately. But to be better it will need to at a minimum:
- Be able to sanely handle service restarts, including configurable behaviour on failure.
- Be able to ensure service output is sanely logged.
- Be able to reliably keep track of processes belonging to a service even if they double fork or the prent process dies.
- Have a dependency system that allows starting and stopping services automatically depending on the status of other services, the availability of a directory or file.
- Be able to schedule execution (like cron) but still subject them to the process management and dependency rules.
.. to mention some.
Re: Linux greybeards release beta of systemd-free Debian fork
#107Earlier quoted context omitted.
What binary blobs are you referring to? Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities, the only other thing that is binary that I'm aware of is the binary log file, which can be reconfigured to revert to text if you so desire.
systemd is itself a series of something like 70-odd binaries. Why? Why not keep it text-based? It works for others.
Does it really work for others? Because I've yet to see any init system that provides even a small proportion of the functionality of systemd that I actively rely on.
Re: Linux greybeards release beta of systemd-free Debian fork
#108Earlier quoted context omitted.
> Um, yes - you can. Systemd's own documentation[1] disagrees. Several important interfaces - which are used by other parts of systemd- are marked as not being independently reimplementable. Another way to say that is that systemd considers those to be tightly coupled. > There is only really one component that can't be easily replaced, and that's journald. You're contradicting yourself. If I remove all of systemd, ex…
> Systemd's own documentation[1] disagrees. Interestingly, most of it is reimplementable independently elsewhere. But I think it's instructive to quote why they say what they say: "A number of systemd's APIs expose Linux or systemd-specific features that cannot sensibly be implemented elsewhere. Please consult the table below for information about which ones these are. Note that not all of these interfaces are our in…
Right, so the issues that he seems to have - I see the main issue is that some software links directly against systemd libraries. That is indeed not very good.
However, his issues about the difficulties of swapping over packages - well, he has his own distro and he's actually worked out after a bit how to replace it with System V. Linking libraries is not very good, but that's surely more of an issue with developers making bad dependency choices? or perhaps they find it convenient. And he worked out how to get around it with a shim anyway, which obviously increases his workload, but then again he's the one who wants to diverge from what all the other distros are doing!
Of course, there is the other point in that it could be argued that the SystemV system doesn't have features that are provided by systemd... which would tend to indicate that perhaps it's lacking in a few areas.
He also belabours the point of parallelisation. I cannot understand why he just doesn't change the before or after directives in the unit config files. That's really not much different to the pain of reordering services in the existing System V-based systems!
So I'm really not convinced :-) Anyway, that was rather a fun talk, I liked how he was troubleshooting the issue, more power to him that he got his system in the way he likes it.
Re: Linux greybeards release beta of systemd-free Debian fork
#109Earlier quoted context omitted.
"Systemd" isn't really a single program, it's a collection of 69 binaries, that together handle a number of functions that were traditionally handled by separately-developed pieces of software. It handles init, user logins, the console, system event logging, network interface configuration, time+date settings, and device management (udev was merged into Systemd in 2012, apparently). A lot of those components have int…
I was genuinely not aware that the components are that intertwined that they rely on each other. Which components are problematic? In terms of Gnome - well, Gnome is Gnome. I'm not going to start defending their decisions, I disagree with quite a few of them myself.
Udev (AFAIK a program that recognises and mounts plug-in devices, but I'm not sure) is developped by systemd guys and they recently told that they won't care about the case where it is used w/o systemd. It is an important part of GNU/Linux distros. Tho I used Arch for about two-three years I guess (since just before it switched to systemd as default til two monts ago), and I never had to fiddle with it, so I don't know how it affects people. Gentoo forked it to maintain a version that did not depend on systemd.
Re: Linux greybeards release beta of systemd-free Debian fork
#110Earlier quoted context omitted.
I was genuinely not aware that the components are that intertwined that they rely on each other. Which components are problematic? In terms of Gnome - well, Gnome is Gnome. I'm not going to start defending their decisions, I disagree with quite a few of them myself.
Udev (AFAIK a program that recognises and mounts plug-in devices, but I'm not sure) is developped by systemd guys and they recently told that they won't care about the case where it is used w/o systemd. It is an important part of GNU/Linux distros. Tho I used Arch for about two-three years I guess (since just before it switched to systemd as default til two monts ago), and I never had to fiddle with it, so I don't kn…
Yeah, that's precisely what it does - it's a daemon that interacts with the kernel for hotplug devices, etc.
Is udevd used by anything other than the kernel though? If not, then I don't think it's a huge issue if those who want to use a different init system maintain their own version!