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)


  • 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.

Add particularly interesting note about NetBSD

While writing up the content above about minimal distros and researching and filling in their platform support I threw in the note in the section below about NetBSD.

This was just reverted. The justification being: "remove the one detail about one specific BSD variant - not related to Arch, there is no explicit list of BSDs and everything can be found on the linked Wikipedia page"

This justification doesn't stand up for several reasons:

  1. This page is littered with references to platform support.
  2. Arch is notable for only supporting x86_64. People are likely to specifically be looking here for platform support contrasts.
  3. The Wikipedia page does mention the portability-focused design, but does not specifically call out that NetBSD is the portable OS as far as the *NIX world is concerned.

Please only revert content when there's a very clear and widely acceptable reason not to include it. Einr (talk) 07:37, 5 September 2021 (UTC)

The page used to have a detailed list of BSDs. That quickly turned into an ad board. [1] So we have no interest in having anything more than what the page has now. -- Alad (talk) 12:51, 5 September 2021 (UTC)
Perhaps then a quick one-line summary of each, and an ongoing policy that this isn't expanded further. Proposed content below. Einr (talk) 05:06, 6 September 2021 (UTC)
The currently proposed content is missing any comparison with Arch, so it is out of this page's scope. Providing quick summaries of 3 BSDs is pointless, they can be found elsewhere. This page is about giving comparisons (with Arch!), not summaries. — Lahwaacz (talk) 20:32, 7 September 2021 (UTC)
Agreed! I thought the NetBSD note about being most-portable was a poignant self-evident contrast to Arch only supporting one platform, which is why I wanted to include that one specifically. If the choice is between none and all of the well known ones, I'd rather include all though. Here's a quick whack at a comparison. Einr (talk) 22:47, 8 September 2021 (UTC)

Reverted content

[Ed: This was in the BSDs section]
  • NetBSD is notable for it's portability-focused design. It runs on more platforms than possibly any other OS.

Proposed content

  • As in the Linux world, there are many BSD derivatives. The top three are summarized below.
    • FreeBSD - The biggest. Tries to be everything. Focused on SMP server use and implements fine-grained locking to improve scalability. Arch is also focused on being very general-purpose, and the Linux kernel is arguably the best refined kernel for SMP scalability in the open source world currently.
    • OpenBSD - Security-centric. Absolute focus on ongoing code audits. Arch tries to maintain security by keeping the core distribution tightly controlled through highly trusted users and rigorous review, but doesn't centrally focus on security as the main goal of the release.
    • NetBSD - Possibly the most portable OS. Runs on an extensive variety of platforms. Arch instead only supports x86_64, in order to provide focus on the core use-case: contemporary desktop, mobile, and server.

Add corpo distros

What better contrast is there to Arch than the commercial server distros? Basically the ossified antithesis of rolling-release. RHEL, SLES... just a short summary of how they're keeping old kernels on life support. Einr (talk) 06:24, 6 September 2021 (UTC)
Just throwing up a quick draft. Einr (talk) 06:38, 6 September 2021 (UTC)
I don't think we should promote/advertise commercial distributions by mentioning them here. -- nl6720 (talk) 07:02, 6 September 2021 (UTC)
Part of me agrees. Most people seem to agree though that RedHat and SUSE have been fairly responsible and among the best of the corporate actors in the open source world. Both of these distros remain fully open source, and only support contracts are sold. Also, what I've written hardly reads as an endorsement. I'm adding a note now to drive the philosophical contrast, which is what this section is really about. Einr (talk) 23:55, 6 September 2021 (UTC)
As a further note, I'm actively contributing these comparisons to help promote a dialog on what Arch stands for and how it stands out. Einr (talk) 00:04, 7 September 2021 (UTC)
Playing devil's advocate (on ossified old-kernel life support, vs. constantly pushing everything to be up to date): A corporate CTO might argue that, in their current environment, they are dependent upon software which, due to it's niche "vertical" nature cannot be so actively kept up to date or perhaps exists in a lab or high-volume manufacturing environment which they must prioritize being as frozen as possible. They might point to the difficulty they experience currently in even completing a two-year-long migration every decade as they must receive buy-in from many silo'ed global business groups with their own specialty needs across dozens of global datacenters housing tens of thousands of servers. How, possibly, could they expect to migrate to rolling release? A CEO who insists that they investigate the possibility may have a team formed, with options investigated. Requests across the IT department are put out for views from developers and admins and internal customer-group representatives on the prospect. Sysadmins and performance engineers point to the massive improvements to Linux kernel observability which are only just reaching maturity in the latest kernels, begging and hoping and dreaming that they be able to use them across the whole landscape. Manufacturing leads respond bluntly, "Hell will freeze over before you touch our systems. We're still secretly hiding SunOS systems from you (oh did I say that out loud?)."
An optimistic outcome: A compromise is formed. Rolling-release is allowed for a new internal-cloud, and new bare-metal installations must thoroughly justify LTS installs. Actually, you can just roll whatever ISO you want (with some usergroup gating and a bit of IT oversight)! All business groups are expected then to increasingly justify having old-kernel environments, which are further isolated. The CTO remembers to tip-toe around manufacturing (they found a possum in one of those SunOS servers, and no one is sure if it was living there already...). RedHat and SUSE catch wind of and encourage this trend and offer rolling release enterprise-commercial distros, allowing further re-allocation of engineering headcount towards new tech and ongoing security and stability audits; everyone wins. Einr (talk) 00:44, 7 September 2021 (UTC)
I don't know about those corporate details you mention. But Fedora and openSUSE, the underpinnings for RHEL and SLES respectively, are already mentioned on this page. As such, the main distinction points for these distros are already listed. openSUSE Leap is even 100% binary compatible to SLES nowadays. [2] -- Alad (talk) 18:39, 8 September 2021 (UTC)
Yeah, that's why I thought it best to only include a bare-bones summary of the primary detail which provides such a sharp contrast to the rolling release model of Arch here. As you've said, the other more detailed contrasts to Arch are better highlighted in the comparisons to the community versions of these distros. Einr (talk) 22:33, 8 September 2021 (UTC)


These distributions are the commercial arms of the corporate giants in the Linux world: RedHat and SUSE. The companies play a large part in providing to the kernel and core libraries, and these distributions are their support-provided offerings to corporations. Large corporations expect very long term support for in-house datacenter server installations, and that has led to Red Hat Enterprise Linux and SUSE Linux Enterprise Server having decade-long lifecycles where very old kernels and libraries are maintained with security packages and occasional feature backports. This is effectively the antithesis of the rolling-release model, as championed by Arch; Archers tend to believe that the most stable and secure system is achieved by maintaining a laser focus on keeping up to date.

Swap order of CRUX and LFS

I know that CRUX has a special meaning for Arch, however LFS is a special case, as it not really a distribution, but more or less the starting point for who wants to create a distribution. Thus I think LFS should be the first of the list, then CRUX, then the rest. What do you people think? --Grufo [ contribs | talk ] 18:18, 29 October 2021 (UTC)

You could argue for it both ways (personally I prefer CRUX at top). I doubt it matters enough to change the article, though. -- Alad (talk) 13:29, 30 October 2021 (UTC)
Yes, of course, it is a totally unimportant detail. I just noticed while reading the article that it feels strange to have a list with a distribution, a guide to how to create a distribution, a distribution, a distribution, a distribution, etc. But probably this is really subjective. --Grufo [ contribs | talk ] 08:52, 1 November 2021 (UTC)