3 ms·

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

> 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.
akagusu 4y ago
Bingo!

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.

akagusu 4y ago

Bingo!