Understanding Linux Distros

by Steven J. Owens (unless otherwise attributed)

The following was originally written in 2009. I edited this version in May 2020 and gave it another read just now in mid 2023. I don't see anything obvious that needs to be updated. Things may have changed a bit since the last review of this, but not all that much, and mostly for the better (at least when it comes to Linux).

Linux is a derivative (in a loose sense) of Unix, which is an OS that was first developed in 1969. A particular flavor of Linux is called a "distro", short for "distribution".

I generally use the Ubuntu linux distro for my laptop/desktop. Historically I preferred the Debian distro for servers.

I ran a personal colo box for about fifteen years, on Debian. I tried to install Debian on my laptop in 1999 but it proved impossible due to OEM* laptop hardware driver issues.

(* OEM means Original Equipment Manufacturer; the general context is that OEM hardware is the opposite of very standardized, off the shelf hardware, and sometimes has odd compatibility or driver issues.)

In 2006 Ubuntu was starting to make a splash. In particular it had a reputation for a) being a Debian-derived Linux distro but not pissing off the Debian people the way every other Debian-drived Linux distro had, and b) having better hardware driver support. So I tried Ubuntu on my new Thinkpad and it worked out great, been running Ubuntu ever since.

But I've worked with a gazillion different flavors of Unix.

My first job was writing database manuals for a database that was ported to literally 28 different varieties of Unix, and we had running servers of all of them in the office, and I would login to whichever was available.

Redhat and Redhat-derived distros were/are popular for servers in various specialized fields (graphics farms, the corporate world) so I've worked with various of those (fedoracore, whitebox linux, etc).

Linux Distro Differentiators

What distinguishes one linux distro from another is pretty much four things:

  • installation process
  • application package management (i.e. installing, upgrading and uninstalling apps)
  • default choices for desktop, GUI, suite of apps installed by default, etc
  • ideology and drivers.

    In this day and age, installation process is pretty well solved, but in earlier times it was a major part of the puzzle and some distros solved it better than others. A lot of this was about the variety of computer hardware it supported (which also gets tangled up in drivers, i.e. the low-level chunks of code that the OS uses to talk to the different pieces of hardware).

    And application package management is extremely well solved, I'm constantly boggled that anybody uses anything but Debian's apt system...

    ...and now, 14 years after first writing what I just said, the Debian approach won. That approach means using app servers (often called repositories, repos for short) and installation tools that automatically sort out dependencies. Other distros have mostly adopted either the same approach. In some cases literally using the same software tools (apt, etc), in other cases basically a clone of that approach.

    Ubuntu uses Debian's apt system, by the way, with their own set of repositories.

    default choice for desktop, GUI, etc is tricky, since it's a matter of personal taste... Gnome versus KDE being the two biggies.

    Ubuntu defaulted to gnome, but then switched to a new thing they came up with, called Unity. After several years they switched back to Gnome.

    However, it's generally very easy to switch out the desktop. In Ubuntu it's generally as easy as just installing the package for the desired desktop and then rebooting and, at the login screen, selecting which desktop you want.

    Kubuntu is Ubuntu with the KDE window manager as the default.

    The terminology gets tricky here, there are several layers, except "layer" implies a far neater, cleaner hierarchical relationship than the reality. But you have:

  • display servers
  • display manager
  • window manager
  • desktop, desktop environment, or desktop manager

    The display server is the lowest level part, it's responsible for putting pixels on your monitor. Xorg, XFree76 and X11 are examples of display servers.

    The display manager, aka the login manager, is the program that displays the GUI login screen and then starts up the other stuff.

    The window manager is relatively low-level, and is the tool that the desktop manager uses to put windows on your monitor, which it does by talking to the display server. But be aware, people seem to use "window manager" interchangably with "desktop" aka "desktop manager".

    The desktop manager (Gnome, KDE, XFCE) is a higher logical level on top of the window manager, and also often comes with a suite of apps that are installed by default.

    Gnome and KDE are desktop managers/GUIs.

    I'll get more into ideology and drivers, further below.

    Distros

    Debian, and Ubuntu are distros. RedHat is another major distro, mainly because they specifically courted the corporate market, and several major corporations adopted redhat (IBM being a biggie, and hence a lot of IBM's customerS).

    There are a bunch of other distros out there, Slackware, Arch, Suse, not to mention Unix-derived alternatives other than Linux, like the BSD lineage (BSD, FreeBSD, NetBSD, etc), but I don't know that much about them and I don't think they're a good starting point for a beginner. Some of them might be a very good starting point for a very technical beginner, who wants to get down in the guts and get their hands dirty, but this essay is not for that sort of beginner.

    Debian and Ubuntu are closely related.

    Debian is one of the oldest, and one of the ideologically most pure Linux distros.

    There have been several attempts to make Debian-derived spinoffs, but Ubuntu is the only one (that I know of) that did it without burning bridges with the Debian project.

    Debian is the one of the most stable Linux distros, and also has, hands down, the best package management system, but the ideological purity also led to circumstances that made it politically difficult to use Debian in corporatins.

    Also, Debian, being fairly geek-driven, combined with an ideological unwillingness to take certain ideological shortcuts in the media/hardware driver area, lagged in some areas such as:

  • installer user experience; because geeks aren't scared of technical installation experiences, so they don't prioritized spiffing this up.
  • driver support, particularly for proprietary hardware.

    By "ideologically pure", I mean that the Debian project were and are committed to open source, and that they would rather build their own components and drivers, or do without, than live with the restrictions that some companies want to demand in return for allowing you to use their proprietary components and drivers.

    This was a much bigger issue 20-30 years ago. In a large part, it's a smaller issue now because of things like the open source movement and the Debian project.

    People said "but that's the way we've always done it, why are you special?"

    And the open source movement said "That's bullshit, we're doing it our way, why are you special?"

    People like the Debian project changed how things are done by being "unreasonable" (cue George Bernard Shaw quote: “The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”).

    So the Ubuntu project was sort of intended to overcome those two weak areas for Debian, the installer and hardware drivers. And they did. And they also contributed back to Debian quite a bit, so that made the Debian crowd happy with them. Most important was that the Ubuntu people (mostly a company called Canonical) managed to strike a good compromise balance about ideology, in a way that was acceptable to the Debian crowd.

    Package Management

    Package management is, as I mentioned above, about managing the installation (and upgrade, and uninstallation) of software, applications, on your computer. Generally ALL software, including apps, but also drivers, and window managers and desktops.

    Package management basically means how you install and manage your applications. But also, more importantly, dependency management.

    Google "DLL hell" sometime to learn the microsoft version of the problem. Or "Dependency whack-a-mole"

    That is, you want application A, which needs library B, but library B needs tool C, but tool C needs library D, etc. This is a problem in both Windows and Linux.

    Windows uses (or used, Idaknow) DLLs, "Dynamic Linked Libraries", binary files that were used by multiple programs.

    In the old days, you needed to manually sort this all out And on top of that, you needed to go out, find the package, find a site on the internet that had the code, get the code, check the docs to see what other projectsthe code depended on, find THAT site, get the code, etc.

    Some distros, like redhat, used "RPMs", (Redhat Package Management files,I think) which wrapped up all the install files in a single bundle file, and also included a specific listing of dependencies in the file.

    So at least the process was a little more explicit, and automated installing each package, but you still had to do the leg work of hunting down and downloading the dependency RPMs.

    Oh, and you had to figure out where to install the stuff, where the files should go, then you had to customize each new dependency so it knew where the previous dependency'sfiles were, etc.

    "DLL hell" is the whackamole process, combined with contradictory dependency requirements, so you get stuck.

    So RPMs and the like streamlined a lot of that, but still you had to do the whole three stooges routine of sorting out the dependencies. And the RPM crowd started building these big RPM warehousing sites, etc.

    Meanwhile, the Debian crowd was happily using Debian's apt system, which would automatically figure out the dependencies, fetch the dependency packages from central servers (called repositories or repos in the apt world) and install them.

    Package management is all about how you deal with getting working applications, and it's major part of what makes people favor one distro over another.

    Support is a bit of an issue in distro preferences, but not nearly as much, thanks to open source. If you're dealing with non-open applications, then it is an issue, and Redhat is, again, much stronger in that area, because they chose to focus on that, buying the help they ened from companies with proprietary drivers, then selling commercial support to large corporations.

    Oh, I should note that the redhat crowd now claim to have solved the package management problem, mostly by adopting apt and etc. I've heard conflicting reports, but hey.

    Re: non-open applications, for me that's mostly things like high end application servers, for more normal use it's stuff like media formats, or hardware drivers. Proprietary formats (flash, video and audio formats, etc) and some hardware folks (nvidia graphics cards comes to mind) are still insanely paranoid about IP, etc, and refuse to provide the necessary info for the open source world to implement open source drivers.

    The 3D/CGI tools market is strongly Redhat. Linux is actually fairly strong in the 3D tool market, but almost all of them only support Redhat.

    Ideology is about two things. Primarily how much they're willing to compromise on closed/open source, what license they have, what licensing and restriction they're willing to tolerate. But also how that general outlook informs the rest of their operation, what their priorities are, etc.

    For example, two long-standing pain-in-the-ass factors for Debian are proprietary media/hardware drivers, and Debian's release schedule.

    Proprietary media formats and proprietary hardware (for example NVidia) are NOT open source, they're closed source and very secretive about their internal stuff.

    Redhat dealt with this simply by cutting a deal with the media format and hardware people, and including proprietary drivers.

    Debian wouldn't give in on it.

    Ubuntu took a sort of middle ground, supporting separate sets of repositories, so they have "free" as the bsae repository set, and you can enable additional sets of repositories based on your own tolerance for proprietariness.

    On the release schedule thing, debian took a very pragmatic approach; new versions are released when they're ready.

    Unfortunately, large parts of the world - the corporate world, for example - can't live with that, they need to know how long the current version will be supported, and when the new version will be out.

    So Ubuntu adopted a clockwork yearly release schedule, and also provided a "Long Term Support" release, which is on a slower, multi-year schedule (i.e. each LTS release is supported for 4 years).

    In 2009 Debian made a huge change, deciding to switch to an every-two-years release schedule.

    Releases are basically about making changes that require sweeping rearrangement at the strategic level. As opposed to patch updates, security updates, etc.

    Open Source, Closed Source, and Ideology

    To touch on the bigger picture with open source and ideology:

    Open source just means "not closed source". "Closed source", also sometimes called "proprietary", is fairly specific and obvious - they want to sell you a car with the hood welded shut.

    They want special privileges. They want to treat knowledge as property.

    I can rant about that for several hours, but in a nutshell, various entities and groups have been struggling for literally many decades to redefine the law in order to deprive you of your constitutionally protected rights, solely for the purpose of (they think, despite all evidence to the contrary) making themselves more money.

    For example, despite advertisements at the start of your DVD, copyright infringement is not theft. Period. There are rock solid, iron-clad, clear-as-a-fucking-bell Supreme Court cases that state this. See, for example, Dowling v. United States, https://en.wikipedia.org/wiki/Dowlingv.UnitedStates(1985) ).

    Here endeth the lesson.


    See original (unformatted) article

    Feedback

    Verification Image:
    Subject:
    Your Email Address:
    Confirm Address:
    Please Post:
    Copyright: By checking the "Please Post" checkbox you agree to having your feedback posted on notablog if the administrator decides it is appropriate content, and grant compilation copyright rights to the administrator.
    Message Content: