Hacker News Reader

Comment by ddevault | Hacker News Reader

Small? No. Simple? No. Great documentation? Yes.

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.

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.

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?

Core of the distribution is the package manager/building tools. Compared to the babylon of eg. Debian packaging tools, where you'll have trouble figuring out basics like automatically installing build dependencies if you don't already have the target package built (lol, wtf? :)), Arch Linux's makepkg/PKGBUILD ecosystem is uniform, fully featured, and fairly simple.

There may be simpler packaging solutions, like Slackware's or whatever postmarketOS uses, but those are limited, and you'll have trouble figuring out how to do things like selecting files you don't want the package manager to ever overwrite, or preventing installation/updates of specific packages, or other things you might need that go slightly beyond basic installation/updates.

Small is relative. Small compared to most Linux distros, macOS and Windows. You also have to remember most installers have a lot of packages that may never be used in the user installs. If you're installing KDE then don't expect it to be tiny but using Sway you'll get a pretty minimal but fully functional WM without the bloat unless you pull in a package that has a large dependency graph.

>Great documentation? Yes.

Compared to BSD's, mediocre and subject to dramatic changes by nature.

I disagree, actually. (For clarity, I wrote this article, 9 months ago.)

This year I have done short reviews of FreeBSD, OpenBSD and NetBSD. IMHO the docs for Arch are more helpful than any of theirs.

How short?

     help #in the terminal.

     man afterboot

Also, the OpenBSD FAQ.

Subjective, but I also find Arch documentation to be "better" because it more frequently answers my question in less time.

You could say *BSD documentation is more "comprehensive" but I usually find myself wading through an ocean to find what I'm looking for. On top of that, every time you try to look elsewhere, you just see RTFM. I can respect the sentiment, but having different variations of the same documentation can help understanding imo

Well, great documentation with the caveat that good upstream documentation is always preferable to the Arch wiki.

Main virtue of Arch. They don’t patch. Upstream documentation will apply as is.

I think Arch generally got its philosophy right. It’s pretty much the minimal set of tools to get an easy to update binary distribution. They don’t touch what they don’t have to.

Reply on news.ycombinator.com