I’ve been using linux desktop for a year or so now. One noteable thing i keep seeing is that one person will say I dont like XYZ distrobution because of its base. But I am still a little unsure what is meant by it. I am assuming the main difference between each base is the choice of package management(?). But what other factors/aspects that are important for the average user to know about each ‘base’? This is probably quite a broad question to a rather technical answer, but appriciate any answers, and i’ll try my best to understand and read up :)
You can divide distros into two categories:
- Independent distros; these are not forks of other projects (at least not in their current iterations). We may also refer to these as upstream-projects.
- Derivative distros; these are forks from the earlier mentioned projects. We may also refer to these as downstream-projects.
E.g. Zorin OS is a derivative of Ubuntu, which itself is a derivative of Debian. After the gargantuan effort it takes to make Debian possible, Ubuntu’s maintainers ‘grab’ Debian, apply a set of changes and ship it as Ubuntu. After which, Zorin OS’ maintainers grab Ubuntu, also apply a set of changes and ship it as Zorin OS.
Of course, not all derivatives are created equal; sometimes a single change is applied that by itself constitutes the fork. And other times, the changes are so massive that they blur the lines between independent and derivative; Ubuntu’s changes to Debian is a good example of this.
Derivative distros can’t simply change everything as they see fit; some things are simply essential parts. In most cases, these include:
- the release cycle of the base; rolling-release vs point-release, but also LTS vs bleeding edge and everything in between
- the (base) packages of the base
But what other factors/aspects that are important for the average user to know about each ‘base’?
I was about to write a long ass dissertation, but it became very unwieldy. Consider asking for specific bases and perhaps I will respond for those.
On a final note, it’s worth mentioning that differences between different distros have never been as blurry as they’re today. With e.g. Distrobox, one can install whatever package from whichever distro they want. Thus, we aren’t as tied to the packages provided by the base distro as we were used to. Furthermore, most distros have different ‘variants’ that allow access to different channels or release cycles. E.g. for those who want Debian packages but bleeding-edge; there’s Debian Sid etc.
Sure, a lot more can be said; like how corporate interest plays into all of this. But what has been mentioned above should suffice for now.
When they say base, they’re talking about the distro it’s built off of(Debian, arch, slack, fedora, Ubuntu, etc.). As an example, Mint is built on the Ubuntu base, Bunsen is built on Debian, etc. These are often called flavors as they’re not considered distros but rather something built on top of a distro.
The major visible differences in distros are the package managers and tools provided for it but they also have different goals. Debian aims for rock solid stability, fedora puts FOSS first, Arch is designed to take up your free time by making you build everything from scratch and pointing you to a wiki when you’re stuck (I kid).
The flavors then customize the experience, usually muddying the distro goals in the process. For instance, someone might take a fedora base then pack it full of proprietary software and release it.
I wouldn’t say what you use is irrelevant but you can truly make every base look and perform the same if you do some work. People that don’t like a particular base usually don’t want to do that work, they want to use it. I’m one of those people. Where I used to love tinkering in Linux, now I just want to get it up and running so I can do my stuff on it.
Great comment, but something I’d disagree on:
As an example, Mint is built on the Ubuntu base, Bunsen is built on Debian, etc. These are often called flavors as they’re not considered distros but rather something built on top of a distro.
From my understanding, those would generally still be referred to as distros in their own right. I’ve always understood a flavour to be a variant of a specific distro. For example, kubuntu is the KDE flavour of Ubuntu.
Correct, they are derivative distributions.
Arch is designed to take up your free time by making you build everything from scratch
That’s a weird take, arch provides repositories ootb and is meant to be used with pacman, you’re maybe confusing with gentoo?
I think they meant build as in configure your environment, not build as in from source. If that’s the case, they’re not exactly wrong. But once you get the bulk of it to your liking, it’s mostly fun little tweaks and accidents. It’s just a lot at first.
(I kid)
No, you don’t
There are a few “grandfather”-distros out there, for example Debian and Arch. They’ve been around for a few decades now.
Then, they got kinds, because some people said “I don’t like xy, I will do it better”, but granddaddy disagreed, so they split apart.
That’s what Ubuntu is to Debian for example, that’s why Ubuntu is Debian-based. They are related to each other (e.g. the same package manager), but differ in some things (e.g. update cycle).This cycle of forking continues, that’s how Mint got there for example. Mint is based on Ubuntu, and Ubuntu is based on Debian.
But nowadays, the gap between distros gets smaller, with things like Distrobox, Nix, Flatpaks, and more. I wouldn’t mind working with a PC that has Mint on it instead of Fedora. Sure, there are reasons why I prefer one over the other, but in the end, they’re all the same.
One example I can think of where the base matters, and not the package manager, is when adding an user to the sudo group. RedHat distros need another promt than Debian for example.
But other than that, the thing that defines a distro are the packages, they make a distro unique.
The base tarball between Debian and Arch (locked to the same glibc) differ only very slightly in software composition stratified mostly by filesystem organization. One could actually make the case then, that the package manager is what differentiates the OS – in which case, Arch’s source code could be conflated to being pacman’s source code
A distribution is basically just what packages come pre-installed. This can have a big impact of course since it can change what package manager is used, the C libraries, and a lot of default system configuration. But the underlying Linux kernel and GNU userland are going to be basically the same across all GNU/Linux distros
A distribution distributes packages. Each base has its own set of packages, compilation flags or “package configuration”, optimizations, release schedule, and overall goals.
Besides technical reasons, people may not like some “bases” for political reasons too.
Something that often gets missed is the difference between packaging conventions between distros.
For example, Debian has Apache httpd packaged as “apache2” and has wrapper scripts for enabling sites. Fedora/RHEL has “httpd” and includes conf.d from the main conf. Arch also has “httpd” but doesn’t have a conf.d out of the box. Of course you can pretty much configue Apache to your heart’s content and have an identical setup between all three distros.
From what I’ve read, Debian tends to patch and change software to fit more into their overall system whereas Fedora and Arch tend to be more upstream.
RPM and Arch both have group packages and metapackages. Debian just has metapackages AFAIK. Debian also has “recommended” and “suggested” levels of soft dependencies, the former which is enabled by default. RPM has the capability for weak dependencies but AFAIK most RPM distros don’t use it. Arch doesn’t have soft/weak dependencies AFAIK.
When you install a new system daemon on Debian, it’s generally enabled and started by default, whereas RPM-based and Arch don’t do that.
When I think of the base of the system I tend to think of some of those more subtle idiosyncrasies that tend to spread around the ecosystems, like Ubuntu and Debian behave quite similarly for instance.
I know others will expand on this, but in the past there were two main “bases”: Debian and Enterprise Linux (EL). The main differences were their package managers and how the handled things in init.d and configuration like networking. This was due to how they made their modules iirc.
So a lot of distros forked off of these two bases rather than reinvent the wheel. Ubuntu is based off of Debian and CentOS based off of RHEL.
There’s probably more nuances but that should give you an idea.
I’d say the main differences are at least
- package availability
- update frequency
- backporting
- packaging philosophy (e.g. plain upstream vs customizations, include all funtionality in single packege vs split out optional features)
- default confguration for packages
Also there’s reliability. If a base dies, everything based on it dies too or at least needs a colossal amount of work to fix. The point about philosophy is very close as well. The base can go closed source, prohibit usage of itself etc
init system could be different, systemd, shepherd, sysvinit…etc
“base packages” that comes with different distro is way different
Guix is a notable mention for having the minimal bootstrap source. On top of that, it is functional package management, implying you can rollback safely (at the cost of disk space).
That’s really hard to answer definitively without context. Obvs there’s the kernel, but that’s similar enough across distros that it’s not really a point of contention that I know of. At a guess it might mean the distro it’s “based” on, but that in itself could mean a few different things. There’s stuff like package management, which you mentioned, and init style. That’s where things get complicated.
Like, Mint is based on Ubuntu, which itself is based on Debian. They share DEB / APT for package management and use systemd for init. OTOH, there’s stuff like OpenSuse, which is originally based on SlackWare, but uses RPM (like redhat) for package management. OpenSuse uses systemd, but I think RedHat uses upstart and SlackWare uses a BSD-style init. It’s been a while since I checked in on those last two.
Of course they could also mean something like choice of desktop environment (as in “A Gnome-based distribution”), default package selection (what the installer refers to as a “base” install). They could mean the general philosophy or release schedule (rolling vs. point release). Or they could even be referring to the userbase (as in; “I use Arch, btw”).