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.

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 linux landscape is very diverse and complicated… but a simplified description would be:

A linux distro consists of:

1. a kernel. the famous core project led by Torvalds and contributed to by thousands of others. This provides the low level functionality necessary for any computer to run. Contains basic stuff like file system, process management etc.

2. a userland. This is all the stuff on top of a kernel like a desktop environment, applications(text editors, web browser, etc.), various utilities, a shell(often Bash) to alllow the user to communicate with the underlying operating system, a package manager to install new software, an init system (such as the famous systemd) etc.

[Aside. The term “Gnu plus Linux” refers to a linux kernel complimented by the Gnu userland]

When someone refers to a linux distro’s base they would usually be referring to the composition of the userland that is included (though sometimes they might be referring to a modified kernel as well). So people who are familiar with the intricacies of the apt package manager (associated with Debian and others) might not like that Centos uses yum (though replacing the word apt with yum works on many commands [ e.g. sudo apt install myprogram].

The desktop enivironment will use a particular file manager by default so that can be a point of friction for someone who swaps distro; menu design might be slightly different, icons in different places.

If someone is used to systemd to start and stop services then relearning a new init system could be enough to stop them switching distro.

A different terminal emulator can be used by different distros but to be honest with you I’ve never spotted any difference.

Some distros choose different C libraries (musl, glibc) but if you are not a programmer this might never become apparent to you.

Switching from one way of doing things on linux is usually not too difficult if you do it in small chunks but if you change a lot of things at the same time it can definitely be overwhelming.

Also some distros are targetted at niche users. If you accidentally overwrite your os with a new distro and only then find out that there is no gui and networking isn’t on by default and you have to edit your own network config to get internet working then you might avoid that distro in the future (Thankfully big distros like Debian, Ubuntu, Centos don’t throw users in the deep end like this).

Probably the single biggest hurdle holding back linux adoption is the vast amount of choice which can be very confusing for new users.

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

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.

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.

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

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.

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

One thing no one seems to have touched on yet: distros have philosophies—guiding principles that affect what packages they have and how they’re presented.

For instance, Debian is strongly open-source-centric. Closed-source software is not normally found in their main repository (even when it would be useful to put it there, like some drivers).

Gentoo, on the other hand, is all about user choice. You’re expected to choose for yourself whether you want to use systemd or OpenRC, X or Wayland, which DE (if any) you want to use, and which features you do or don’t want compiled into your software. However, Gentoo is quite happy to include closed-source software in the main package repository, because using it is also a choice that some people prefer to make.

Red Hat, Arch, and Slackware (to name the remaining major foundational distros) also have their own philosophies. Some descendant distros retain their parents’ principles, while others discard them and develop a philosophy of their own (Ubuntu doesn’t have Debian’s Open Source Uber Alles tendencies, for instance).

So, hey, can someone explain to me about Linux Mint, like since it is derivative of Ubuntu does that mean that the new system of having to pay for Ubuntu updates is inherited by Mint?

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”).