3 ms·

Care to elaborate in a sentence or two? I mean, I have a decent idea who you are, so I think you have some authority on things Linux - but I'm curious regarding

Care to elaborate in a sentence or two? I mean, I have a decent idea who you are, so I think you have some authority on things Linux - but I'm curious regarding your reasoning :) I think especially the metrics for "simple" are very use(r) dependent. Simple for you or me means something entirely different than e.g. my Grandma (who has no computer). Personally I run four Linux machines, so they're customized anyway and "simple" for me means "I understand everything that's installed, because I installed and configured it". Someone running 4000 machines would probably have a slightly different opinion on what's "simple". Small, well, it's not an embedded Linux with a small libc and -Os for sure. But I never felt Arch bloated.

ddevault 4y ago
The simplest system uses the fewest moving parts to accomplish the goal. Some of Arch's ideas, like PKGBUILDs, are pretty simple. But ultimately Arch is just another typical mainstream Linux distribution with glibc, GNU coreutils, systemd, PAM, etc. These tools are all severely bloated and over-complex, and many simpler alternatives exist which solve the same problems with much less. As for "small", well, it varies, but Arch systems tend to bloat more with time as the system does not provide much for auditing and cleaning up your system, so the older an arch install gets, the more garbage it accumulates. Arch also tends to turn on as many options as possible for each of the things it packages, so many packages have a lot of optional dependencies made mandatory. This is not a unique problem to Arch; only Gentoo (and maybe Nix and friends) solve this one, and they have many other problems to contend with. All of this is not to say that Arch is necessarily a poor choice. It's just not simple, nor small.
- archi42 4y ago
  I see. Yes, many of these tools aim to be rather universal, which is detrimental to "leanness". OTOH all these bloaty tools are relatively well understood. E.g. being able to write unit files that heavily up the security of random daemons is really something I learned to value the last years. But I only used init.d as an alternative, so my horizon is a bit limited in that regard. Not using glibc, well, I was under the impression this causes a lot of pain for a general purpose Linux. Regarding the "growing" OS, hm... I've manually checked what's installed on my Debians using aptitude, and removed old stuff. Similarly, I could let pacman produce a list of installed packages to audit and check which are not required anymore. Either case needs manual action, because the automatic tool will not know if I still need that random python lib I manually installed, or if it can be removed (truth be told: neither do I!). Now for unused dependencies this is different. Pulling in lots of stuff is a problem, yes. I think this could be solved by building those packages with a modified PKGBUILD locally (making it more like Gentoo), but for my "Linux on a big machine" I never saw the need to try that. Anyway, I didn't read it like you were claiming Arch to be a poor choice :) Thanks for the reply, I really appreciate the perspective. I don't want to drag you into a discussion over details, especially since I don't feel like "you're wrong". So feel free to just let it stand like this. OTOH, what are your favorite glibc/coreutils/systemd/PAM replacements?

ddevault 4y ago

The simplest system uses the fewest moving parts to accomplish the goal. Some of Arch's ideas, like PKGBUILDs, are pretty simple. But ultimately Arch is just another typical mainstream Linux distribution with glibc, GNU coreutils, systemd, PAM, etc. These tools are all severely bloated and over-complex, and many simpler alternatives exist which solve the same problems with much less. As for "small", well, it varies, but Arch systems tend to bloat more with time as the system does not provide much for auditing and cleaning up your system, so the older an arch install gets, the more garbage it accumulates. Arch also tends to turn on as many options as possible for each of the things it packages, so many packages have a lot of optional dependencies made mandatory. This is not a unique problem to Arch; only Gentoo (and maybe Nix and friends) solve this one, and they have many other problems to contend with. All of this is not to say that Arch is necessarily a poor choice. It's just not simple, nor small.

archi42 4y ago
I see. Yes, many of these tools aim to be rather universal, which is detrimental to "leanness". OTOH all these bloaty tools are relatively well understood. E.g. being able to write unit files that heavily up the security of random daemons is really something I learned to value the last years. But I only used init.d as an alternative, so my horizon is a bit limited in that regard. Not using glibc, well, I was under the impression this causes a lot of pain for a general purpose Linux. Regarding the "growing" OS, hm... I've manually checked what's installed on my Debians using aptitude, and removed old stuff. Similarly, I could let pacman produce a list of installed packages to audit and check which are not required anymore. Either case needs manual action, because the automatic tool will not know if I still need that random python lib I manually installed, or if it can be removed (truth be told: neither do I!). Now for unused dependencies this is different. Pulling in lots of stuff is a problem, yes. I think this could be solved by building those packages with a modified PKGBUILD locally (making it more like Gentoo), but for my "Linux on a big machine" I never saw the need to try that. Anyway, I didn't read it like you were claiming Arch to be a poor choice :) Thanks for the reply, I really appreciate the perspective. I don't want to drag you into a discussion over details, especially since I don't feel like "you're wrong". So feel free to just let it stand like this. OTOH, what are your favorite glibc/coreutils/systemd/PAM replacements?