3 ms·

>systemd was promoted as a init system, but in reality, it is more than that, it is a suite of software; we have journald, firewalld, udevd, logind, networkd, r

>systemd was promoted as a init system, but in reality, it is more than that, it is a suite of software; we have journald, firewalld, udevd, logind, networkd, resolved and many more. Several of the things you mentioned are completely optional. You can use some of the systemd programs but not others. Many distros don't used networkd or resolved for example. GNU was promoted as an editor. Just because an organization or project expands into multiple different projects doesn't mean that is a bad thing. Does it matter to you that GNU makes 100 different things? >People forgot how systemd was forced to everybody when Gnome made systemd-logind a hard dependency This is not an issue with systemd, but Gnome and whoever else. You should complain to them, not the systemd folks. It doesn't make systemd bad or not a useful piece of software. Gnome only has a limited amount of resources (both developers and money). You can't really expect them to support an alternative. I'm sure if you talked with them they would support an alternative to logind if you were willing to provide enough money. If gnome won't support it then you could pay Gentoo developers and I'm sure they would create additional alternatives like you mentioned with eudev. Ultimately I think unification of Linux distros is good. It is unfortunate for BSD and whoever else, but when it comes to Linux this is a good thing. I am currently helping a coworker migrate to Linux and trying to explain apt vs yum/dnf vs pacman vs whatver, rpms vs debs vs snaps vs flatpak vs appimage, etc is just tiresome. When they look up how to do something on Linux and it just doesn't work it is a bad experience. Maybe systemd isn't the correct choice, but unifying on one init, network manager, firewall just makes a better experience, especially for new people.

mid-kid 4y ago
> GNU was promoted as an editor. Just because an organization or project expands into multiple different projects doesn't mean that is a bad thing. Does it matter to you that GNU makes 100 different things? You're comparing an organization consisting of projects headed by different people with very few strict inter-dependencies and whose primary goal was being compatible with as many Unix systems as possible at the time, to be able to slowly start replacing their utilities, to a single umbrella project headed by the same people and parent company, whose utilities are deeply interwoven (can't run a systemd tool, say, resolved, without systemd) and are expressly incompatible with the ecosystem they're trying to replace.
- growse 4y ago
  > ..., whose utilities are deeply interwoven (can't run a systemd tool, say, resolved, without systemd) The systemd components all depend on libsystemd (a systemd project), and the GNU apps all depend on glibc (a GNU project). A common dependency doesn't make them all "deeply interwoven" in any meaningful way.
  - mid-kid 4y ago
    GNU projects generally don't depend on glibc, this is why gnulib (a compatibility layer) exists. With systemd it's often not just libsystemd that's the dependency, but PID 1 and the rest of the stack.
- _-david-_ 4y ago
  >You're comparing an organization consisting of projects headed by different people Originally gnu wasn't what you are describing. It grew into it. Just like what is happening to systemd now. >with very few strict inter-dependencies Systemd has very few interdependencies as well. >whose primary goal was being compatible with as many Unix systems as possible at the time As far as I know glibc is strictly for Linux. Maybe Gnu had an intention of creating software that was compatible with multiple systems but not all their stuff is. >whose utilities are deeply interwoven (can't run a systemd tool, say, resolved, without systemd) and are expressly incompatible with the ecosystem they're trying to replace. The same thing happens with Gnu stuff. Large chunks of gnu software requires GCC.
  - mid-kid 4y ago
    > As far as I know glibc is strictly for Linux. glibc is one of the few exceptions to the rule, and even that supports Hurd and has historically had patchsets to run on the BSDs. > Large chunks of gnu software requires GCC. This is simply not true. Autoconf, the build generation utility, is so insanely complex and archaic because it had to support wildly different compilers and Unix environments. These days it's just GCC and Clang, both of which are very well supported beyond just the GNU ecosystem, to the point Gentoo now has a clang-only variant.

mid-kid 4y ago

> GNU was promoted as an editor. Just because an organization or project expands into multiple different projects doesn't mean that is a bad thing. Does it matter to you that GNU makes 100 different things? You're comparing an organization consisting of projects headed by different people with very few strict inter-dependencies and whose primary goal was being compatible with as many Unix systems as possible at the time, to be able to slowly start replacing their utilities, to a single umbrella project headed by the same people and parent company, whose utilities are deeply interwoven (can't run a systemd tool, say, resolved, without systemd) and are expressly incompatible with the ecosystem they're trying to replace.

growse 4y ago
> ..., whose utilities are deeply interwoven (can't run a systemd tool, say, resolved, without systemd) The systemd components all depend on libsystemd (a systemd project), and the GNU apps all depend on glibc (a GNU project). A common dependency doesn't make them all "deeply interwoven" in any meaningful way.
- mid-kid 4y ago
  GNU projects generally don't depend on glibc, this is why gnulib (a compatibility layer) exists. With systemd it's often not just libsystemd that's the dependency, but PID 1 and the rest of the stack.
_-david-_ 4y ago
>You're comparing an organization consisting of projects headed by different people Originally gnu wasn't what you are describing. It grew into it. Just like what is happening to systemd now. >with very few strict inter-dependencies Systemd has very few interdependencies as well. >whose primary goal was being compatible with as many Unix systems as possible at the time As far as I know glibc is strictly for Linux. Maybe Gnu had an intention of creating software that was compatible with multiple systems but not all their stuff is. >whose utilities are deeply interwoven (can't run a systemd tool, say, resolved, without systemd) and are expressly incompatible with the ecosystem they're trying to replace. The same thing happens with Gnu stuff. Large chunks of gnu software requires GCC.
- mid-kid 4y ago
  > As far as I know glibc is strictly for Linux. glibc is one of the few exceptions to the rule, and even that supports Hurd and has historically had patchsets to run on the BSDs. > Large chunks of gnu software requires GCC. This is simply not true. Autoconf, the build generation utility, is so insanely complex and archaic because it had to support wildly different compilers and Unix environments. These days it's just GCC and Clang, both of which are very well supported beyond just the GNU ecosystem, to the point Gentoo now has a clang-only variant.