== 1. A Quick and Dirty Introduction ==
I’m not going to cover the history of GNU, Linux and the free software community in any detail. This has already been done many times by people far more experienced than I am, and in far greater breadth. I do recommend Eric S. Raymond’s The Art of Unix Programming for an engaging history of the Unix way from its beginnings in 1968 up to 2003.
So, if you’re a weak Windows user, there are a few caveats you should be aware of. First of all, Linux is not an operating system by itself. It is a kernel. When coupled with other utilities, like a shell, a compiler, a toolchain, display server, display manager (or “login manager” for you plebeians), window manager, hardware and networking daemons, etc., then it becomes a fully-fledged operating system, or a Linux distribution.
Typically you will have compilers and core utilities (such as rm, cp, ls and so on) by the GNU Project bundled in, the Linux kernel (no shit), the X.Org display server and related utilities, udev to listen to kernel events and initialize hardware devices, an audio layer like ALSA to manage sound cards and a desktop environment like GNOME or KDE with all of its assorted libraries like widget toolkits and inter-process communication/messaging frameworks (though, not necessarily, often a basic window manager like Openbox may be used, instead).
Now, you may be wondering to yourself: GNOME? ALSA? Openbox? udev? What the fuck is all this shit?
This is the beauty of freedom and variety. You see, when using Windows, you’re bound to whatever Microsoft gives you. You have to use their desktop environment, their standard utilities, their display manager, their package format, their everything. Now, I’m aware people have tried to do things like third-party window managers and all that, but let’s face it: they’re all clumsy hacks. Windows’ proprietary nature leaves you at the mercy of your masters at Microsoft.
With Linux, the only required mutual component for all distros is the Linux kernel itself. Absolutely everything can be customized right down to the bone, if you so choose. You can swap system libraries at whim, recompile them with different optimizations and so forth. With Windows, you have to stick to whatever defaults the packages have been compiled with for you.
Oh, and obviously, you can tweak the kernel endlessly, as well. Yeah, this can make huge differences on your system’s performance. But the fact of the matter is, even a standard huge kernel compiled with all modules, coupled with a lightweight desktop environment, will still let you achieve speeds that you had never even imagined were possible before.
Another thing that separates Linux from Windows, very important… package management.
So, how do you install software on Windows?
You go to the vendor’s website, download the binary installer program and run it. Same old, same old. Quite tedious.
Linux distributions, on the other hand, have centralized package management systems. The most common ones are dpkg + APT (used by Debian, Ubuntu and all their variants), pacman (used by Arch and all its variants) and RPM (used by Fedora, Red Hat Enterprise Linux and all variants with various frontends, most commonly yum).
What this means is that there is a standard way to handle all software packages on your system, as well as a common format for them. The way software is installed on Linux usually happens through the use of a package manager frontend, which connects to a distribution’s software repositories via a mirror (constantly updated 24/7), downloads a standard software package and then processes it using system tools.
In practice, this usually means that instead of doing this:
Open browser -> Type URL -> Navigate page -> Download installer -> Run installer -> Skip through, making sure to toggle off malware -> Run software
You do this, instead (for instance, in Arch):
Open terminal emulator -> Type ‘pacman -S software’ -> Run software
Yeah. Package formats come in all sorts of forms. The simplest one usually involves an archive with metadata and a shell script that describes the software build process, but in practice most are significantly more complex.
Linux distributions are more than operating systems. They’re a mentality, a community, a way of life, even. The overwhelming majority of software bundled in them is free software, which is software that respects the user’s freedom. This means you can view and modify the source code, redistribute your own vanilla or modified copies. You’ll usually find thriving communities for each distro on message boards, mailing lists, IRC channels and so on. Be sure to participate, and do not hesitate to report bugs!
Actually a more apt descriptor would be to refer to Linux distributions as entire multitudes of communities, as they are bundles of wide varieties of free software, each with their own community. Compare and contrast to the hulking monolith that is Windows, where everything is bundled by Microsoft… whether you like it or not.
Finally, you will likely be captivated and perhaps even initially frustrated by the sheer difference in the workflow with the Unix way. Unless you’re using a distro for dummies, you’ll be using the command line a lot (don’t be scared, it becomes second nature pretty quickly) to handle all sorts of system administration, and have all sorts of programs and utilities that are simply absent in the DOS prompt. What’s more, there is no registry. Everything is flat configuration files. Granted, some DEs like GNOME do offer their own graphical configuration management tools, such as dconf, but the registry model is still totally absent. It’s much more basic.
Drop any preconceived notions. The more you learn how to use a Linux system, the more you will realize that you have been lied to your entire life. You will look back into your Windows days with disgust and anger at not being introduced to what a proper operating system is meant to be like. Buckle up.
== 2. The Folly of Distro Hopping ==
Usually the number one sin that Linux newbies commit is uncontrolled distro hopping. They’ll switch between Linux Lite, Linux Mint, Linux Sapphire, Linux Pointy Hat Edition, Linux This-Is-The-98327th-Ubuntu-Remix and so on.
The fact of the matter is, most distros are formulaic and forked from others. They don’t have much to serve on the table. Usually they’re just remixes. They’ve preinstalled a few packages for you, gave it a nice wallpaper, a fancy name, registered a domain, released an ISO and now it’s a distro.
Don’t fall prey to that.
Here’s a real-world example: CrunchBang.
CrunchBang is a very popular Linux distribution that’s known for being minimalistic, lightweight and fast.
But just what is it, really?
It’s Debian with Openbox and a Conky instance installed for you beforehand.
That’s it. Remember when I said you can tweak Linux down to the bone? Yeah, you can pretty much get CrunchBang just by installing Debian and fiddling with it for 30 minutes. It’s dead simple, but newbies and lazy people suck it up.
I’m not trying to slander CrunchBang, specifically. I’m just using them as an illustration to show that most distros are merely remixes and not worth spending your time over. There only a relative few “big” distros that have enough to offer by themselves to make them stand out. However, if you’re trying to convert a friend to Linux, or want to quickly install a ready-to-go ISO to a new PC, then sure… go for a remix. But not while you’re learning.
== 3. The Rundown ==
So we begin.
I’ll be covering each distro individually, but I’ll attention primarily to the homebrew and independent ones. That and forks, but only those that have significantly shifted from their upstream origins. Basically, I’ll be covering the ones that matter. You can use these summaries to figure out what’s suited for you. I recommend that you try out one of “The Five Horsemen” (as I have reverently dubbed them) listed below (perhaps barring Sorcerer), although if you’re not that brave, then I don’t blame you.
== 4. The Plebeian Tribunal (Well, Mostly) ==
These are the ones that are the most accessible.
Pretty much the grand-daddy of every notable Linux distribution. Not quite the oldest that is still maintained, it only missed that honor by a month to one of the “five horsemen”: Slackware.
Debian has pretty much become synonymous with Linux. Even if you’re not using it directly, a ton of major and minor distributions use its packaging infrastructure, or even directly descend from Debian. Indeed, the first package manager people usually think of is APT, and more specifically the “apt-get” frontend tool. More specifically, Debian’s package format is the “.deb” archive, which is handled through the dpkg tool (and alternately its graphical counterpart GDebi). Installation of packages from repositories is handled through the APT toolset (apt-get and apt-cache), although more recently an abstraction over the APT toolset called aptitude has been out and increasingly more recommended. apt-get remains the primarily used utility.
It has a relatively conservative installation process, yet one that is graphical and very easy to follow, but not overtly dumbed down like Ubuntu’s, or other desktop distributions. You are also given the option of a text-based installer.
Debian isn’t just a Linux distribution, it’s a broader operating system and free software advocacy project. Debian also offers operating systems based on the FreeBSD and GNU Hurd kernels, but we will not be covering those here.
Debian is well known for its free software guidelines. These consist of a ten-point list that determine whether the software can be included in the official Debian package repositories. Some of those packages that fail are either pushed to the non-free or contrib repositories, which are configured manually. Third-party repositories exist to fill in the gap for proprietary, non-free or otherwise disputably licensed software not in the contrib or non-free repos. The Debian project also has an ardent security policy and is always quick to backport and patch in bug fixes after CVEs are brought to light.
Debian uses sysvinit as its init system, however, following a publicized and intense debate, the foundation has taken the decision to adopt systemd in its next releases (starting from 8 as stable).
Debian’s primary bootloader is GRUB, having dropped default support for LILO as of version 7 (wheezy). GRUB is more heavyweight, but also more supported and widely adopted.
Ultimately, Debian is very much the vanilla Linux experience. At least, the vanilla contemporary Linux experience. It can be adapted into virtually anything and with its strict guidelines and ideological purity, you can be sure that your freedom is being preserved.
If you want something minimal, but don’t want to dig too deep into internals, then Debian is a worthy choice.
Don’t even bother. Ubuntu, especially after the adoption of the Unity desktop environment, has been so bloated with Canonical’s crapware (including Amazon.com spyware) and distanced from the Unix philosophy that it’s not worth it. It’s useful as an operating system to install on your grandparents’ or your technically incompetent friend’s computer, but you won’t learn much from it. It’s very much a corporate effort.
Its dedicated, superfluous tools and packaging repositories tend to break compatibility with Debian and plenty of other related distros.
Kali Linux is just Debian with GNOME 3 Classic and preinstalled tools… oh, and its own repository.
Don’t bother, unless you need a quick bootable pentesting kit on the run. What I’d recommend doing is compiling and installing the security tools that you need yourself on your own personal distro. If it’s a Debian-based one, you can include Kali’s repositories in your /etc/apt/sources.list.d/.
Plenty of pentesting repositories exist for other distros, including BlackArch for Arch Linux.
4) Linux Mint
Same shit as Ubuntu. Not quite as bad, but still very much simplified. Some of its own dedicated tools are also under-engineered and break down if you try to diverge from the path that the Mint developers have given you.
The main reason I included this one is to warn of Linux Mint Debian Edition. Tempting as it may be, it’s a mistake. First of all, it hardwires Mint’s own repositories and has a very peculiar updating mechanism. Rather than fetching from repositories, it distributes sporadic update packs from a graphical update manager. If it sounds like Windows, that’s because it very much is. If you try to include Debian’s own repositories, you’ll likely end up breaking your system pretty quickly, as Mint doesn’t play nicely with them at all.
Still useful for converting inexperienced users, on family computers or for use on a casual machine for browsing and email.
What’s special about NixOS, indeed its defining component, is its package manager, also named Nix.
Nix is arguably the most sophisticated and advanced package manager in existence. It is also distribution-agnostic. However, it does come with a few caveats.
Nix and consequently NixOS does not store its packages in the typical /usr, /bin and other directories that are part of the Filesystem Hierarchy Standard (FHS). In fact, NixOS does not even have an FHS. Instead, it stores all packages in a directory called /nix/store.
Packages are written in a functional configuration language called Nix expressions. Due to Nix’s use of cryptographic hash signing in its package directories, it enables having multiple non-conflicting software versions installed trivially. This is the default behavior; it does not overwrite existing packages.
Nix also enables a multi-user environment by giving non-privileged users on a system the ability to install packages in their own custom profile, without reinstalling existing system packages, or injecting malware into them.
The hash signing and multiple versions also mean that atomic updates are supported. Packages can be upgraded without time lapses in between old and new files, and one can very easily roll back to old versions without a hitch.
Removal by default does not delete the package immediately, it only unlinks it. This is to ensure that rollbacks can safely be done, or that other users on the system do not immediately have their software crash. A garbage collector must be run separately for total deletion.
There are also other features. Ultimately, Nix has not seen any wide deployment, and the rest of the OS is like any other. It uses systemd as its init system.
I would recommend NixOS for experimentation and research purposes, but probably not to begin with right away, due to the violation of the FHS, first and foremost.
Fedora started off in 2003 and still remains primarily a community project, though heavily sponsored by Red Hat. It uses the RPM packaging infrastructure with the yum frontend (although a new one called dnf was introduced in Fedora 18).
It follows a six-month release cycle, which is to say a new version is released every six months.
Fedora very much focuses on being up-to-date and integrating bleeding edge technology. Indeed, it was one of the first distros to include systemd as the default init, although it’s understandable, seeing as Red Hat employees were responsible for its creation in the first place.
It comes with SELinux configured by default. SELinux (Security-Enhanced Linux) is a tool for implementing access control lists. It is free GPL software, but it’s worth noting that the NSA were its original developers. Keep caution.
Overall, it is analogous in many ways to Debian as a relatively vanilla contemporary Linux experience. I would personally recommend Debian as closer to the metal, but both are more-or-less interchangeable. The Fedora Project is not as strict on freedom as Debian is.
Essentially Arch Linux for people too scared to use Arch Linux.
It comes with its own graphical frontend to Pacman (Pamac), a text-based distro installer (compared to the command-line installation process of vanilla Arch), a settings manager utility (msm), a dedicated command-line kernel management tool (mhwd-kernel) and its own hardware detection facilities, particularly for video drivers (mhwd).
Actually a good desktop distribution for users with some technical experience, but probably a bit too spoiled for beginners looking to learn.
== 4.1. The Five Horsemen of the True Bearded Sysadmins ==
Going strong since July 1993, it is the oldest actively maintained distribution in existence. The great thing about Slackware is that it is by far the most UNIX-like of all and exposes the internals of your system without any bullshit. Whereas most distros use a System V init system, Slack uses BSD-style initscripts stored in /etc/rc.d. These manage runlevels, system startup, networking, various daemons and so on. Concise and simple.
Slackware’s package management system is by far the most minimalistic, and it’s binary-based. Slackware packages are basically just tarballs (usually with the .tar.xz extension) with some Slack-specific metadata files and a doinst.sh for post-install config and symlink setup. They are handled locally with a set of basic utilities (installpkg, removepkg, upgradepkg, explodepkg, makepkg), although the first three are most important. There’s also an ncurses-based frontend called pkgtool where the functionality of installpkg and removepkg are given a nice TUI. Remember: this is for local packages only.
Slackware has long been criticized for not having automatic dependency resolution or bleeding edge software, but that’s missing the point. Slack has always had a conservative development philosophy, with focus on security, stability and having a large amount of software bundled with the installation medium itself. In fact, most things you’d need are in the DVD for you.
There is a network-based package manager called slackpkg which downloads and installs packages from various official FTP mirrors, acting as a frontend to the base package utilities, but with support for download over a network and searching.
Finally, for software that you cannot find through other means, there’s something called SlackBuilds. These are special build scripts designed to set up a Slackware package which you can then install to your system using installpkg. There is a website that collects these, with each one being officially approved by Slack devs before they’re uploaded, called SlackBuilds.org (or SBo). They also have a tool called sbopkg which automatically interfaces with their site, downloads SlackBuilds, runs them and even gives you the option of directly installing them.
Dependencies have to be resolved manually, but it’s rarely an issue, since each package has an info file which notes these. You can make what’s known as a queue file, which is a list of packages to install at once, and pipe them in. sbopkg lets you do this natively from its UI.
There’s also third-party managers like slapt-get and Swaret that some Slack-based distros used, but their packages aren’t necessarily stable, so I don’t recommend their usage.
Slackware’s installation is easy yet powerful. The only step that needs to be done from a raw command line is the disk partitioning, after which you run the dedicated setup program (an ncurses-based, menu-driven shell script) and do everything from there. You’re given a lot of options and ways to manage the control flow, so you’re not restricted in any way. What’s really nifty is that as the system installs, you have the slack-desc (title+description file) of every package going by. Haven’t seen this in any other distro.
Slackware is also the most secure by default. To do package management, you must be root. No exceptions. Sudo doesn’t cut it. Some operations like dmesg, which can be done by regular users in other distros, need sudo in Slack.
It’s also highly stable and uses LILO. You can set up GRUB later manually post-install, but I prefer LILO. It’s so much simpler than the gargantuan monstrosity that is GRUB. Security updates are also constantly given.
In short: If you want rigid stability, vanilla packages, security, to be as close to UNIX as possible and want a bundle of software (base system-only is an option too), go for Slack. It’s been tested throughout time and it’s a favorite by admins and power users alike. If you’re a maniac about constantly having bleeding edge software, then you’ll be disappointed. But if you learn Slackware, you learn Linux.
2). Arch Linux
Arch is much more recent, but it’s quite popular for two reasons: bleeding edge software and system simplicity. Arch strives to provide the newest versions every single time, regardless of whether they’re stable or not. Arch can potentially break a lot, and to be an Arch user you need a love of troubleshooting and tinkering.
Arch is also a rolling-release distro. Install once, pacman -Syu to have the latest system every time. Whereas Slack has a standard release model.
Arch is pretty famous for its pacman package manager. Once again, it handles binaries, but it has dependency resolution too. Arch packages are also tarballs (a PKGBUILD and some metadata). Package management is pretty similar overall, but Slack’s tools are rawer and use the shell, whereas pacman is written in C.
Arch also has the AUR (Arch User Repository), consisting of a large amount of user-submitted software. Stability is not tested, but you should be fine most of the time, and it is pretty huge. There’s several frontend programs for it, most commonly used is yaourt. Slack has no definitive user repository, although you can download packages from individual users at your own risk.
Finally, there’s the Arch Build System (ABS), where you can download PKGBUILDs that can then be packaged with makepkg and installed with pacman. This is similar to the concept of *BSD ports trees, where everything is handled through source. However this is somewhat different, as you don’t compile directly, but rather assemble packages from raw files with what’s known as a fakeroot procedure. Slack has the exact same thing (SlackBuilds), except they’re verified for stability (less emphasis on the ones in the -current tree, of course).
Arch also has a very lush wiki full of great documentation that is valuable for every Linux user. This is naturally owing to its much larger (and arguably zealous) community.
Arch’s installation is much rawer. You’re booted into a chroot environment and you set everything up from the command line. Nonetheless, a few menial tasks are still automated through the Arch Install Scripts.
Arch doesn’t use initscripts like Slack, rather it uses systemd. This is a fairly new replacement for the System V init system and it is more abstracted than Slack’s approach. It can generally be controlled through the userspace program systemctl.
In short: If you want the most bleeding edge and newest version of everything and are ready for things breaking, go for Arch. But be wary of systemd.
Then we have Gentoo.
Gentoo is source-based, as opposed to Slack and Arch, which are binary distros. This means every package is compiled from source and can have its own particular flags (USE, CFLAGS, CXXFLAGS, etc.) set for it. This means greater control over hardware optimization and exactly how you want it to be compiled, but the trade-off is for speed. However, updates may take less bandwidth.
Gentoo’s package management system is named Portage, and is controlled by its frontend named emerge, which handles the actual process of compilation (ebuilds). Gentoo’s system is thus the closest to *BSD ports. Worth noting is that the flexibility of Portage makes it OS-independent and it has been ported to other *nixes, even Mac OS X.
Gentoo uses the typical System V init system, but the runlevels are named rather than numbered. It uses its own system built on top of the standard sysvinit, called OpenRC. As opposed to Arch with systemd and Slack with BSD-style scripts.
However, as of recent, Gentoo has also adopted systemd. They still give you a choice between OpenRC and systemd, but it is unknown for how long.
Gentoo is also rolling-release like Arch, but it is not quite as focused on bleeding edge as Arch is, though you can get the latest through overlays and unstable repos.
Gentoo’s installation process is also very minimal, but with a few quirks of its own. It requires that you compile your own kernel (though this is made easier with the built-in genkernel tool) and unload the base system and package manager (the stage3 tarball). Nonetheless, Gentoo has great documentation, so following it should be straightforward.
In short: If you want complete control over your individual package flags and to compile from source while having a reasonably stable, rolling release system, go for Gentoo. Note that there are also binaries for huge shit like Firefox and LibreOffice. Be sure to use OpenRC.
Concerning the Sorcerer family, they’re not very popular, but here’s what you need to know: they’re source-based, use a very peculiar yet powerful package manager called sorcery, which works on a wizard-themed allegory of handling packages (you don’t install and remove packages from a repository, you cast and dispel spells from a grimoire and so on), plus they have a traditional release cycle.
The family of distros is as follows: Sorcerer, Lunar Linux and Source Mage. They typically offer even further control of the intricacies of individual packages than Gentoo, but are developed by small teams and consequently they aren’t constantly updated due to low usage and community. Funny thing is Sorcerer came at around the same time as Gentoo and could have overtaken, but oh well.
The Sorcerer family package managers download the source code directly from the developer’s website (much like SlackBuilds do), so as long as the URLs are up to date, so will the packages. Essentially rolling release but with no master repository.
However, individual package managers differ. The one I referred to above is Source Mage’s, but the three distros while having common descent from one another, are mutually exclusive in their ways, with their grimoires being incompatible.
Their installation is also straightforward. Source Mage’s in particular is very well made in that it’s entirely command line-based, but is inside a guided environment (there are detailed instructions displayed on what exactly to do, you can switch between steps at will by typing next or prev, and see what you need to do by typing todo). Overall, it’s just a slight layer on top of a Linux from Scratch system.
In short: If you want to get in the deep underground, try these one day, but I don’t recommend these as a beginner due to sparse documentation and the community involvement that will likely be required from you.
CRUX is 64-bit only, source-based, uses a ports system of package management, has BSD-style initscripts and its packages are tarballs that follow a structure very close to BSD (Makefile, patches, md5sum, etc.) This is all handled through the pkgutils that CRUX uses, in particular the prt-get frontend (or pkgadd if you want more control). It’s also devoted to having new software, but not to the point that Arch seeks to.
CRUX has no /usr/doc and avoids filesystem clutter.
Installation is quite straightforward and not all that difficult, but you are expected to compile your own kernel without the aid of any tools like Gentoo’s genkernel.
In short: If you want a source-based Slackware and you have a 64-bit system, go for CRUX. But I still recommend you try one of the big three (Slackware, Arch, Gentoo) first to get your hands dirty and so you’ll have fewer gotchas down the road.
== 5. Conclusion ==
I hope you’ve found this resource to have at least a modicum of use to your endeavors in getting into Linux. There’s much more to inform yourself on, but nonetheless I’d be glad if this quick resource gave you some pointers.