Talk:Arch compared to other distributions

From ArchWiki

Add Alpine, Void

Void and Alpine are reasonably popular by now. One of their features is a focus on "minimal size", so a subsection could be added to the article accordingly. There's some ambiguity with the Arch compared to other distributions#General section - both distributions are general purpose, and Debian/Ubuntu also focuses on "minimal size" to some extent (package splitting). Therefore one could either propose a different section name, or alternatively include Void/Alpine in Arch compared to other distributions#General.

Either way we should think of a write-up and probably include these distributions in the article. -- Alad (talk) 14:22, 3 September 2021 (UTC)

I'll start working on this now. Will likely include Puppy Linux and Tiny Core Linux as well, due to their fit to this category and mix of prominence and endurance. See here. Einr (talk) 03:57, 5 September 2021 (UTC)

Why was this moved to draft state? I was basically done with it. Feel free to add to it, but it's in a comparable state now to the other lists. Einr (talk) 07:40, 5 September 2021 (UTC)

We are not done reviewing it. — Lahwaacz (talk) 07:42, 5 September 2021 (UTC)
Can we nuke all this stuff? It screams of content that requires a lot of upkeep (package count, etc), general advertising and a tremendous amount of fluff. Arch ethos is to keep it simple. None of this is remotely simple.
Grawlinson (talk) 01:42, 8 September 2021 (UTC)
I included info about package coverage, in rough approximations, because there was some open consideration of what overlap these have with more general-purpose distributions. It's not essential, but has already been researched and is of relevance to defining the class. Simply removing the content if it proves out of date without a maintainer would be understandable. These are also just comparisons to Arch. LFS is arguably "simpler" than Arch and distributions which are considerably smaller than Arch are also, by necessity, simpler than Arch... Arch isn't all about simplicity. Even the decision to break away from CRUX was over the concern of added complexity created by the envisioned metadata-included creation of pacman. Einr (talk) 03:28, 8 September 2021 (UTC)
Also, I agree and appreciate that simplicity is in the ethos of Arch. Not trying to contest that at all. Just pointing out that it does necessitate some definition. For instance, I suggested "lightweight" as an alternative name for what is now proposed as "minimal-size". This was criticized as, "meaningless." Arch is trademarked as "A simple, lightweight distribution." Certainly, we don't want to face the same criticism from the outside. Einr (talk) 04:29, 8 September 2021 (UTC)
That, "defining what Arch means by simple and lightweight," is part of where I see the value in this page. It's a concrete comparison of the tradeoffs Arch makes vs other projects so that the casual outside observer can clearly see how Archers prioritize simplicity and lightness vs other goals. So minimal-size is a category that specifically helps to define how Arch compares to other projects which more highly priotize "minimalism" or "lightweightness" or whatever you want to call it (currently the idea is that "Minimal-size" is the most apt short description). Einr (talk) 04:38, 8 September 2021 (UTC)
As a specific example of defining what Archers mean by simple: An Archer might argue that the convenience and stability gained by having a package manager which is better at keeping track of all the moving components in the system and how they interrelate ultimately provides for a simpler overall experience which more than offsets the engineering complexity of it. Einr (talk) 04:46, 8 September 2021 (UTC)
And a specific example of how that definition can help in shaping the future of the distro: I'm currently advocating for an automated install process which covers, at least, the most common use-cases outlined in the Installation_guide. The argument being around how the added complexity of having an automated process which better keeps track of all the moving components in the system and how they interrelate ultimately provides for a simpler overall experience which more than offsets the engineering complexity of it. Einr (talk) 05:10, 8 September 2021 (UTC)
I would like to see more actual comparisons to Arch, rather than merely listing features of other distributions. For example, Void Linux uses pull requests to accept packages into their repositories, while Arch has the AUR with user-submitted packages, which are then cherry-picked to the repositories. Alpine uses APKBUILD, which is very similar to PKGBUILD but is strictly limited to POSIX shell features, e.g. no arrays. And so on.
Those are great details to include! Please do. My draft only serves as a foundation. I'd like to see more detailed comparison too. Einr (talk) 22:55, 8 September 2021 (UTC)
Personally I would also skip Tiny Core Linux and Puppy Linux. You even admit to their limited relevance in the distro landscape. -- Alad (talk) 18:34, 8 September 2021 (UTC)
Yeah, I've noticed you feel strongly that distros included here should have broad relevance as basically being very general purpose or being generally ubiquitous to those familiar with Linux. I feel like there's some opportunity to cherry-pick a few less ubiquitous distros specifically for the purpose of highlighting implementations which stretch the boundaries of what people might typically do with Linux. For Arch, aiming to be incredibly versatile and fostering of regular tinkering and expansion of the idea of what you can achieve with your system, I feel like it's a worthwhile thing to point these out! For instance, Tiny Core I think gives a wow moment to a lot of people when they realize a whole functional graphical desktop can fit in 11MB, and that adding Wi-Fi and non-US keyboards adds a whole order of magnitude in size and complexity. Einr (talk) 23:02, 8 September 2021 (UTC)
It's also a very poignant contrast! Arch is A simple, lightweight distribution, but within the confines of being totally general-purpose. Tiny Core, by comparison, is maximally simple and lightweight as an absolute first priority. Einr (talk) 23:46, 8 September 2021 (UTC)

Draft: Minimal-size

These distributions range in capability from being focused on embedded systems deployment or niche purposes, to having overlap with the more typical general purpose distros listed above. The defining factor of this category is that one of the primary reasons for these distributions to exist is that they are made to have as small of a footprint, in terms of size and resource usage, as is possible for their intended purpose. This generally implies compromises which would not be seen with other, more general-purpose, distributions.

These distributions can be as small as ~12 MiB on disk, and more typically the minimal install is between 100 MiB and 700 MiB. By contrast, Arch aims to be lightweight, but to serve as a more general purpose system has a base install closer to ~2 GiB, and needing ~512 MiB RAM.

Alpine Linux

  • Is a security focused distribution first. Is developed with the expectation it will be deployed to embedded and network edge devices such as routers. The mix of embedded use and a desire to reduce the "attack surface" (which comes from extraneous or overly-complex software) for high-value devices motivates making installations of Alpine very small.
  • A minimal install is ~130MiB on disk.
  • Userland binaries compiled with position-independent executables, to limit available exploits.
  • Achieves very small size in part by foregoing the usual choice of glibc, and instead uses musl libc.
  • BusyBox based, also to reduce size and complexity.
  • Still strives to be a general purpose distribution, and covers a wide variety of potential uses. Lack of glibc can introduce compatibility issues for some applications.
    • Package coverage: Over 5000 core projects, and over 7500 in edge.
    • Wide platform support: i686, x86_64, ARM (hf, v7, AArch64), ppc64le, s390x
  • OpenRC for init
  • Started in 2005, with steadily growing adoption, particularly since about 2015. Is now the most prominent minimal-size distribution.

Void Linux

  • Is a general-purpose distribution with a focus on being fast and as small as possible.
  • Minimal installs: 96MiB RAM, 600MiB disk (700 with glibc)
  • i686 and x86_64 support
  • Built around both musl and glibc.
  • Runit for init system (Arch uses systemd by default)
  • Using xbps package manager.

Puppy Linux

  • Is an end-user, desktop-focused, portable-first distribution.
    • Boots into a ramdisk, primary intent to boot quickly off a USB stick.
  • Small size to enable quick portable boot off USB
    • ~130MiB minimum on disk (Typical: i686 - 300MB, x86_64 - 600MB)
  • Maintains two main variants: One Ubuntu derived, the other Slackware (also Raspbian for RasPi/ARM)
  • One of the oldest and most enduring of the minimalist distributions. Peak interest in 2008, has faded in prominence since.

Tiny Core Linux

  • Is an extremely small graphical Linux desktop
    • ~12 MiB on disk (with Wi-Fi and non-US keyboard support: ~106 MiB)
  • Achieves small size by cherry-picking some of the smallest tools available for each purpose:
  • Can be used as a portable OS, in similar manner to Puppy Linux
  • Is limited in scope. Monolithic package updated twice a year since 2009.
    • Repo browser not online. State of package repositories unclear.
  • Ports for: i686, x86_64, ARM, RasPi

Add NixOS Somewhere

I think currently Arch and NixOS are the most interesting comparison out of everything. Arch has been known as, "Linux, with a nice package manager" NixOS is might be more, "A nice package manager, oh and Linux too; purely functional, btw." Einr (talk) 14:07, 5 September 2021 (UTC)

Arch compared to other distributions#General? -- Alad (talk) 14:48, 5 September 2021 (UTC)
Yep, sure. I'll start working up a draft. Einr (talk) 01:19, 6 September 2021 (UTC)
This draft could still use some more direct comparisons to Arch.Einr (talk) 22:38, 8 September 2021 (UTC)
"NixOS is unique in that it is a package manager first and only secondarily a Linux distribution." <-- this doesn't seem all that correct to me, NixOS is the distribution, Nix is the package manager. -- Malcontent (talk) 10:26, 29 August 2023 (UTC)
Agreed, the current NixOS description looks more like an ad in favor of NixOS, more comparison with Arch is needed. -- Malcontent (talk) 11:12, 29 August 2023 (UTC)


  • While most distributions include a package manager, NixOS is unique in that it is a package manager first and only secondarily a Linux distribution. Nix, the package management system, aims to be a subsystem which can be installed on practically any Linux distribution. The aim being to be a universally applicable dependency management system for developers.
    • Allows use as a continuous-integration environment.
    • Allows replacement of language-specific package managers.
    • Allows use of a single tool for all project build, machine configuration, and cloud deployment management.
    • Is a developer-centric OS.
  • Uses a purely functional package language, to avoid side-effects. The ultimate goal from this is to enable Reproducible Builds.
    • Making progress in this.
    • This is a major security consideration for any software available in binary form.
    • Allows truly atomic changes, which are easily rolled back, for most system management operations. The aim is both for stability and to encourage tinkering, similar to Archer mentality.
      • Arch, comparatively, is not designed around this notion. However, it is versatile and with the right selection of filesystem and supporting software can approach a similar level of reversibility. The snapshotting functionality of btrfs, along with judicious configuration of software like TimeShift can allow most of this benefit.
  • Has one of the largest, most up to date, package ecosystems in the Linux world; comparable to Arch, if AUR is included.
    • A core strategic project focus is on increasing and improving the package coverage, functional status, and up-to-date-ness. Semi-annual releases have a release manager who actively tracks this and doles out praise and recognition for contributing.