Technical Basics


(For very basics, see Basics section of "Moving to Linux" page.)


Layers

+/-
[Mostly from lowest to highest:]
  • Boot medium: hard disk (HDD), solid-state drive (SSD), flash drive (USB), read-only (CD, DVD), or network.

  • Disk partition table: part of Master Boot Record (MBR) sector,
    or GUID Partition Table (GPT) which is 34 logical blocks.

  • Computer/boot firmware:
    Legacy BIOS (MBR sector has partition table and first-stage bootloader),
    or UEFI (load a file from FAT32 boot partition)
    or coreboot or U-Boot.

  • Boot manager / boot menu / bootloader: usually GRUB, but there are others (Syslinux, LILO, rEFInd, gummiboot, efistub, coreboot, OpenCore (Mac), Clover (Mac), BOOTMGR (Windows), systemd-boot, U-Boot (embedded systems), more). [Also there is a "fallback" bootloader in boot/efi/EFI/BOOT ?] Gives a menu of available kernels/systems, user chooses, it loads that image and jumps to it. At various points in here, there may be decryption of the full disk or a partition.

  • Bootsplash: Plymouth, Splashy, RHGB, XSplash, more.

  • Kernel type: mainly a matter of config parameters ? Real-time, low-latency, clustering, stripped-down, more ? Could change the process scheduling algorithm or other things. There are various named configurations (AKA "spins"): Zen, Liquorix, GNU Linux-libre, XanMod.

  • Kernel: handles processes, memory, more. Uses drivers to connect to hardware devices, and modules to implement filesystems and network protocols and security mechanisms and encryption and more.
    Linux kernel map
    Interactive map of Linux kernel
    Do "lsmod" to see installed modules, drivers and filesystem types.
    Do "lspci -nn -k" to see which module/driver each device is using.
    Do "ls /sys/module/MODULENAME/parameters" to see parameters defined for a module.
    Do "sudo cat /sys/module/MODULENAME/parameters/PARAMNAME" to see a parameter value.

    • Modules and Drivers:
      "ls /lib/modules/$(uname -r)/kernel/drivers/*/*.ko"
      to see all available modules and drivers.
      "Kernel Modules" section
      Some drivers may contain/install maybe-proprietary binary "blobs" of code which run on CPU or GPU etc: article.
      There also could be a "blob" of CPU microcode which is installed inside the CPU to modify the instruction set.

    • Filesystems:
      "ls /lib/modules/$(uname -r)/kernel/fs/*/*.ko"
      to see all available filesystem types.

    Also kernel parameters: "less /boot/config-$(uname -r)"
    "Kernel Parameters" section
    Each distro can configure the kernel as it wishes.

  • libc API: glibc, musl, others.

  • GNU packages/utilities: shell, compiler, libraries, CLI utilities (coreutils: cat, ls, grep, others), more.

  • util-linux utilities: dmesg, fsck, kill, su, others.

  • Init system.

  • Windowing/display server protocol: X11, Wayland, Mir, OpenGL ?
    "X" section, "Wayland" section
    "echo $XDG_SESSION_TYPE", "loginctl show-session 2 -p Type", "glxinfo | less"

  • Display server: X.Org Server, XFree86, Wayland compositor (Weston, mutter) ?
    diagram of X and Wayland in same system

  • Window manager: X11 manager (tiling: i3, dwm, bspwm, awesomewm, xmonad; stacking: Fluxbox, Openbox, mutter, muffin, Compiz, Metacity, kwin, xfwm, Gala, Window Maker, JWM), Wayland manager/compositor/more (Weston, sway, Way Cooler, mutter, Enlightenment, Moksha, Wayfire, Hyprland, more) ?
    For more info, see my Linux GUI page.

  • GUI framework/library/toolkit ?: GTK+, Qt, libwayland-client, libX, OpenGL ? Non-GUI: D-Bus, udev ?

  • App framework/library ?: KDE, GNOME, Unity, more ?

  • Desktop manager (taskbar/systray, application launcher, icons): KDE/Plasma, GNOME, Cinnamon, Xfce, LXDE, more.

A bundle of choices of the last 4-5 items and some apps usually is called a "Desktop Environment" (DE). See Desktop Environments section.



Distributions (distros)

+/-
A distro is a set of choices of layers/parts/policies, all packaged together under one label.

Some major distros: Debian, Ubuntu, Kubuntu, Linux Mint, Red Hat, Fedora, Arch, openSUSE.

Debian Family Tree (!)
Which is just part of a bigger GNU/Linux Distributions Timeline (!!)

My "Linux Distros" page



Other pieces that usually vary by DE

+/-
  • Display manager / login screen manager: sddm, gdm3, lightdm, KDM, MDM, SLiM, more.
    See Display Managers

  • Themes.

  • System Languages.

  • Fonts.

  • Desktop widgets/launchers/icons/shortcuts. Launchers: dmenu, Synapse, Albert, Ulauncher, more.

  • Taskbar/systray applets.

  • GUI-shell extensions.

  • GUI workspaces (AKA virtual desktops or multiple desktops; article).

  • KDE's GUI activities (desktops with different icons and widgets on each, and then you can have multiple workspaces inside each activity).




Other pieces that often vary by distro or distro-family

+/-
  • Installer (Calamares, Ubiquity, Subiquity, curtin, Anaconda, Debian-Installer, YaST, Cnchi, Refracta, os-installer, more).

  • System GUI apps:
    • Updater.
    • Software manager/store (snap software-boutique, GNOME Software, KDE Discover, Muon, pamac, AppCenter, MintInstall, more; article1, article2).
    • File manager/explorer (Nautilus, Nemo, Caja, Thunar, Dolphin, Krusader, Pantheon Files, Ranger, ROX, LF, others) and add-ons.
      ("xdg-mime query default inode/directory" to show file manager in use.)
    • Task manager.
    • Crash-reporter (whoopsie, apport, Dr. Konqi, others).
    • Settings manager.
    • Network manager.
    • Disk partitioning/formatting.
    • Screen-saver/locker: XScreenSaver, Light-Locker, GNOME Screensaver, XSecureLock, XLockmore, alock, xtrlock, more.
    • more ...

  • Default user GUI apps:
    • Terminal.
    • Text-editor.
    • Video player.
    • Browser.
    • Image viewer.
    • Image editor.
    • more ...

  • Repositories / App Store: apps and packages that are available for use in this distro.

    You'd hope that being in a repo means "has been tested/approved and is supported", but it may just mean "installs and runs without crashing". And various repos for a distro may be provided by various parties; e.g. Ubuntu has 4 repos (the universe and multiverse repositories are "community-maintained").

  • CLI apps.

  • Codecs.

  • Printer drivers: "lpstat -s" to see defined printers; "ls /etc/cups/ppd/*.ppd" to see the installed printer drivers; /usr/lib/cups/driver contains databases of PPD's.

  • Documentation.

Things that vary less often, or vary only from one distro-family to another:
  • Source or binary packages: most are binary; source-based distros include: Gentoo, LFS.

  • Packaging

  • Init/daemon/services system: sysvinit, runit, systemd, BSD-style startup scripts (Slackware), Upstart, Finit, OpenRC (Gentoo), more (also see No systemd).

  • Fairly standard daemons/services: Network management (DNS, DHCP, VPN, more), printing (CUPS), network services (FTP, SSH, more).

  • Fairly standard facilities: Authentication (PAM, certificates, more), access control, IPC (D-Bus, sockets, more).




Some other variations or modifications, some of them user choices

+/-
  • Do you use the command-line much, or mostly stay in the GUI.

  • Does the distribution do "rolling releases" (constantly updating), or do periodic "stable releases" (AKA "point release" or "fixed release"). Rolling release: Arch, Solus, openSUSE, more. Stable release: Ubuntu, Mint, Fedora, Elementary OS. Some distros have both kinds available.
    FOSS Linux's "Linux Rolling Release vs Point Release, and which is better?"

  • There may be different stable, testing, experimental versions of the same distribution.

  • Emphasis / target of distro: desktop GUI, server, VM / container / cloud, micro-VM / unikernel / cloud, IoT, micro-computer (e.g. Raspberry Pi).

  • CPU architecture: x86, ARM, more.

  • 32-bit and 64-bit versions, as on Windows.

  • UEFI Secure Boot ("Secure Boot" section), or not.

  • Kernel / system emphasis: normal, high-availability (clustering), hardened, low-latency (e.g. Ubuntu Studio, Liquorix), real-time, run-as-root (e.g. old Kali), containers/cloud image (e.g. Flatcar), immutable (e.g. Fedora Silverblue/Kinoite, openSUSE MicroOS, SteamOS, Vanilla OS).

  • Disk encryption: full-disk, full-extended-Linux-partition, individual partition encryption, encrypted home directories, or no encryption.

  • Various command-line shells: bash, zsh, fish, dash, tcsh, ash, more.

  • Various GUI docks: Latte, Cairo, Docky, more.

  • Do you compile things yourself from source (Gentoo, LFS, BLFS, more), or use binaries created by other people/companies.




Dedoimedo's "The ultimate guide to Linux for Windows users"



Roles in the Linux world

+/-
  • Policy / standards / licensing bodies and corporations.

  • Developers.

  • Packagers. I Love Lucy assembly line
  • System administrators.

  • Users.




More-complicated things you can do

+/-
  • Partition a disk into Windows and Linux partitions, so you can dual-boot (boot into either OS). A little dangerous; sometimes a Windows update will wipe out the Linux bootloader (only if using MBR ?).

  • Boot Linux, and then sometimes run a Windows emulator (such as WINE) to run some Windows applications.

  • Boot Linux, and then sometimes run a virtual machine (such as VirtualBox) to run a copy of some other OS (Windows, or a different Linux) inside the VM.

  • Boot Windows, and then sometimes run a Linux command-line environment (such as BASH) to do various operations.

  • Boot Windows, and then sometimes run a Linux emulator (such as WSL 1) to run some Linux applications.

  • Boot Windows, and then sometimes run a virtual machine (such as VirtualBox, or WSL 2) to run a copy of some other OS (Linux, or a different Windows) inside the VM.




See my "Moving to Linux" page




Linux Myths

Linux just
From 4/2000 interview of Rob Young, founder of Red Hat:
There are two big myths about the business, and the first is there is a single Linux operating system. Linux is a 16-megabyte kernel of the 600-megabyte operating systems that companies like Corel and Red Hat make. Linux might be the engine of your car, but if you plunk an engine in your driveway, you're not going to drive your kids to school.

Our job is making people understand this revolution is about open-source software and it is not about Linux at all. Linux is simply the poster boy for this movement. The other myth is that Linux is being written by 18-year-olds in their basements when actually most of it is being written by professional engineering teams.
Jonathan Corbet's "Statistics from the 5.10 kernel development cycle" (12/2020)
Dawn Foster's "Who Contributes to the Linux Kernel?" (1/2017)

Another myth is that "free" software and "open-source" software are identical concepts.
Mark Drake's "The Difference Between Free and Open-Source Software"

In 2021, there are lots of articles about how shameful it is that so many people use FOSS without paying for it. Major internet incidents have been caused by one lone badly-supported package-developer stopping their work or making a mistake. But I think people pushing the "shameful" narrative are being naive. Many corps and people use FOSS exactly because it is free. They don't WANT to pay for it. They're not using it to take some principled stance about freedom.

Desktop user should realize: Enterprise Linux is where the money is, and it drives and enables many of the advances delivered to desktop Linux. PipeWire comes from automotive Linux; systemd comes from needs of enterprise admins; probably ZFS and Btrfs and containers and security modules and firewalls etc.





Linux Truths / Benefits







Miscellaneous



Standards / projects / groups

+/- Plenty of huge companies (Intel, Microsoft, Google, Samsung, more) and smaller companies/foundations (Mozilla, Apache, more) contribute code and/or money to Linux and FOSS.
Statistics & Data's "Top Companies Contributing to Open Source - 2011/2021"

Some subsystems have come from various corporations: CUPS (Apple sort of), ZFS (Oracle).

Unix Family Tree 1
Unix Family Tree 2

From Alan Pope's "Pitchforks set to Stun":
The 'community' of Linux users has a bit of a problem. It's not really a community at all. The Linux 'community' is a bunch of individuals who have an affinity for running the OS. ...

... there's no real wider unified 'Free Software' community either. There's the "Popular People's Front of FSF" and the "People's Popular Front of Open Source" who believe fundamentally different things and target different users. It's a giant sliding scale, ...
Difference between Free Software and Open Source, by South Park Goth kids (video)



Software / business models

+/-
  • Open-Source: original software source code is published for anyone to see and use. It's considered good behavior to take any changes you make, open-source them, and offer them to the upstream project to help improve the base software.

  • Free: any changes to software source code must be published for anyone to see and use.

  • Open-Core: [definition is contested ?] uses open-source software at the core and then adds proprietary software around that.

Note that these really are talking about software (not services, or trademarks). Examples: Linux kernel is open-source but the name "Linux" is trademarked. Red Hat's software is open-source but the company sells support services and owns various trademarks. Canonical (Ubuntu) is open-source but sells certification services, support services, management services, and owns various trademarks.

Each project or company may have secret information (encryption keys, operating procedures, customer data, financial, etc) even though the software is free or open-source.



The CLI (terminal-and-shell; Command-Line Interface)

+/-
Where there is a shell, there is a way.
From procabiak comment on Guide: Migrating to Linux in 2019:
+/-
Stop recommending the command line to beginners. Disclaimer/TL;DR: I like the command line, use it every day, but it's not the user-friendly tool you make it out to be. It's a tool for veterans, power users, tech-savvy folk. It's dangerous in the wrong hands.

This is a Linux/nix culture we need to move away from if Linux is to be successful mainstream. There's a reason many distros have a GUI for package management. If everything was indeed easier on a command line for every user demographic, why waste time implementing the GUI package manager, just tell everyone to use the terminal, right? Wrong! (IMO)

There're people who don't speak English or have difficulty with spelling even the simplest words, people with typing disabilities, older aged people, children ... Just to name a few, but all who just want to enjoy a game without needing to learn the complexities of Linux or us vets pushing that need onto them.

With a GUI package manager, you don't need to know anything beyond the ability to explore, click around to find stuff you need, etc. Often times you'll find other software you didn't think about wanting. The guide already states package managers are akin to app stores. These days everyone knows what an app store is (well, I make the assumption - there are people who have never owned smartphones before), so it's not as difficult a concept as it used to be, so we can use fewer words to explain it. The instructions are pretty simple: "open the package manager (app store) from the menu, search for steam and click install, enter your password and click OK". It's not faster than a command line, but it's simpler for many people. The instruction is nearly universal for all distros, even if the GUI looks or behaves slightly differently.

Contrast with apt, yum or pacman. You'd also need to learn to use grep to get anything remotely useful out of their list-package outputs. You can't explore - you just execute a command like sheep and hope you really just installed steam from Valve and not some other kind of steam. And when it comes to instructions, you need more words to explain the command line (that many people are omitting): "open the Terminal, type sudo apt install steam, type in your password (it shows up blank but your password is really there, keep typing), press enter, then type Y and press enter" ... Not only that, that command only works for Debian-based distros using apt. It will confuse Fedora and Manjaro novices using yum or pacman (they might even try to install apt, just to be able to run your command!).

You can also very easily mislead a novice to run dangerous "sudo rm -rf /"-like commands. I assume it's backwards to suggest to the user to understand the command before executing it when they are learning the command in the first place, so we can't assume the novice user will know what every command does. Therefore I can maliciously explain that line means "sudo = as a superuser, rm = remind me, -rf = to read from, / = root", for example. If I am their only reading material, I've just tricked a user to wipe their OS, imagine what else you can do to that novice by exploiting shortly-named commands?

The reality is command lines are simpler for the person offering help, but not necessarily for the person on the other end.

From grady_vuckovic comment on Guide: Migrating to Linux in 2019:
+/-
I have experience in converting people to Linux and that terminal is absolutely poison. When I show a typical Windows user an OS like Linux Mint, they are interested until they see the terminal, then groan and lose interest immediately.

Even if GUIs change, it is still waaaay easier for a new user to figure out a GUI with obviously labelled buttons, text boxes and tabs, than figure out how to use a terminal.

Try to put yourself in the mindset of a person who has only ever used a computer for homework, Facebook, job-hunting, Amazon, and who mainly uses a smartphone for all their computer needs. A terminal itself is a foreign concept and not a pleasant one.

On most decent software managers for Linux distros, the GUI is mostly pretty self-explanatory, with a simple search box for finding new software. That's pretty easy for a new user to figure out how to use.

But it is almost impossible for them to figure out what 'sudo apt steam' means at a glance, (and no, taking the time to explain it doesn't help, it will likely result in a 'wait wait I just want to install an app, why do I need to know all this rubbish?') or figure out where they need to go to type it, because if your user doesn't know where the software manager is, they certainly don't know where the terminal is or how to use it, so for all you know they could end up typing those commands into a search box somewhere. Not to mention it's difficult for them to even remember something like that.

And when I say "how to use it" regarding the terminal, I mean that literally. I've seen new users half type in commands, causing the terminal to enter a mode of waiting for the rest of the input of the command, then they can't figure out why it isn't working as they type in more and more commands, and other frustrations. It is truly a TERRIBLE user experience and one that should only be reserved for veteran Linux users.

Also keep in mind, users like to install and uninstall software, how on Earth is a user meant to figure out how to uninstall software which they installed with 'sudo apt'? There's no list of installed software they can look at, no buttons to click, no GUI to navigate, all they can do is hopelessly start Googling for help on how to use apt commands (that's an appallingly bad user experience for someone new to Linux) or (more likely) just get frustrated and decide "Linux is rubbish!" and switch back to whatever they were using before.

On top of that, it looks pathetically antiquated in 2019 to use a terminal to do such a simple basic OS operation as installing software or installing some drivers.

It may be easier for you to give instructions in terminal commands, and the terminal may be easier for you to use than a GUI, but it is scaring away possible Linux converts. For Ubuntu at least you should include instructions on how to navigate to the Software Manager.

I personally wouldn't offer any advice at all for Linux newbies that includes terminal commands unless you're trying to scare them away from Linux.

My thoughts:
+/-
  • Recognition (seeing something in GUI and recognizing it's what they want) is easier than recall (knowing what they want to do, and then recalling what command does it) for most people.

  • CLI is the right tool for certain things, such as piping commands together to do text-manipulation.

  • CLI is great for documenting procedures, can be copy-pasted, can be used through SSH, even can be spoken to someone.

  • CLI can be faster for experienced users.

  • CLI is more standard (across distros) than GUIs.

  • CLI is always same language, while GUIs can be in any human language.

  • Windows and Mac also have CLI's, so this is not an advantage or selling-point for trying to move people to Linux. Heck, DOS had ONLY a CLI. And the Unix CLI commands have been available for DOS and for Windows CLI for a long time; you can use grep and sed etc on any of those CLI's, with the right stuff installed.



'Terminal' is not same as 'shell'

+/-
Types:
  • Terminal is the GUI process (window controls, tab stops, copy/paste, drag/drop, font, background image/color, line-buffer, scrolling, multiple panes, char color, more).

  • Shell is the text-command process (variables, statements, pipes/redirection, launch commands, path, history, tab-completion, more).

  • CLI is Command-Line Interface, basically "commands you can run in the shell".

  • (Virtual) Console (accessible via ctrl+alt+F1 etc) is a text-window process (line-buffer). Device name /dev/tty*.

  • Pseudo-Terminal (PTY) Device names /dev/ptm* and /dev/pts*.

Examples:
  • Terminal: gnome-terminal, xfce4-terminal, konsole, guake, rxvt-unicode, aterm, xterm, kitty, alacritty, tilix, terminator, tmux, PuTTY, termite, sakura, urxvt, st, foot, cool-retro-term, tabby, more.

  • Shell: sh, csh, bash, fish, zsh, ksh, ash, dash, more. "cat /etc/shells".

  • CLI: can run "echo hello >>file1".

  • (Virtual) Console: done through getty, agetty, more.

  • Pseudo-Terminal (PTY) terminal running in user space.

Aram Drevekenin's "Anatomy of a Terminal Emulator"
Seth Kenlon's "Terminals, shells, consoles, and command lines"
Unix Sheikh's "The terminal, the console and the shell - what are they?"
Andreas Fuhrich's "What is the difference: terminal / console / shell?"
Hiks Gerganov's "What do PTY and TTY Mean?"
The Valuable Dev's "A Guide to the Terminal, Console, and Shell"
Viacheslav Biriukov's "Terminals and pseudoterminals"
Linus Akesson's "The TTY demystified"
Chris Siebenmann's "A surprise: you can only have one Linux kernel serial console"


GUI Terminal:
A pseudo-terminal (pty) is a pair of char-device files which serves as a bidirectional pipe between terminal and shell.
See current pty and shell: "ps -p $$"
See terminal process: "ps -ax | grep terminal | grep -v grep"
Type of terminal to emulate ? "echo $TERM"


Similar happens in a (Virtual) Console:
A tty a char-device file connects console (text window) and shell.
See current tty and shell: "ps -p $$"



A multiplexer has one terminal controlling multiple sessions. Tmux uses a client/server architecture that lets one terminal control multiple sessions on a remote host. Terminator is a terminal that can control multiple sessions on the local host.


"Console" versus "Virtual TTY"

+/-
From /u/aioeu on reddit:
There are at least three different things to consider here:
  1. The kernel knows how to drive a video adapter. It can run the hardware in a text mode (e.g. a VGA text mode) or in a graphical mode (the framebuffer).

  2. The kernel's virtual TTY subsystem associates a video adapter with a keyboard device and provides the kernel's built-in VT102 emulator. This is probably the thing you think of when running Linux in a text-only mode. It's the thing that provides the multiple screen buffers you switch between using Ctrl+Alt+Fn.

  3. Quite separately, the kernel always has a "console device" of some kind. The purpose of this console is to be somewhere for the kernel to log messages.

It should be emphasized that these three things are fairly independent. For instance, it is possible to run a system without the virtual TTY. You might use a userspace TTY implementation instead, or you might not care about having an interactive terminal at all.

Regarding point 3, although most people just use a video adapter as the kernel console, you can choose to use something else instead. For instance, you can boot the kernel and have it use a serial port as its console. You can have it shipped over the network to another machine. You can even use multiple output devices as "the" console: you can have the kernel output log messages to both a video adapter and a serial port, for example.

...

To a large extent, this is a big problem with naming. It's an utter mess. The virtual TTY, for instance, is often also called a "virtual terminal", and indeed the kernel config option for it (CONFIG_VT) is named with that in mind. But then this kernel subsystem goes and creates /dev/vcs* devices, and the documentation for that calls it a "virtual console". So who knows?

To make this more concrete, consider these two statements:
  • I entered my username and password at the console.

  • The kernel logged a message to the console.

Both reasonable sentences ... until you realise that the word "console" is being used to denote two completely different things. They only look like the same thing because they happen to be going through the same hardware device.

I guess my point is that you really do need to read between the lines when interpreting articles ... My earlier comment was my description at how these components fit together. I deliberately did not use the names "virtual console" and "Linux console", because different people interpret them different ways.


Expression of Change's "CLIs are reified UIs"

John Hammond's "How to move FAST in the Linux Terminal" (video)

Cool feature: in KDE's Dolphin file manager, press F4 to open a Terminal that will change dirs as you change dirs in Dolphin.

How to change default terminal,
from someone on reddit:
"[GNOME] Unfortunately, there is no 'default terminal' setting. GLib has a hardcoded list that is used for launching .desktop files marked Terminal=true. [You have to uninstall unwanted terminals.]"
[Maybe you could just replace /usr/bin/gnome-terminal with a link to your desired terminal ?]

Change console settings during pre-kernel part of boot:
See if bootloader config file supports "vga=" parameter.

Change console settings during kernel part of boot:
Try kernel command line "vga=nomodeset" parameter.

Change terminal and console settings:
"man setupcon"
"man console-setup"
Edit /etc/defaults/console-setup or $HOME/.console-setup and then run "setupcon"
Or see /etc/console-setup/*
Or: "setfont" or "setconsolefont", edit /etc/rc.d/rc.font, see /usr/share/kbd/consolefonts
Or: look in /etc/fonts/conf.d

Change terminal settings (not console):
Edit Exec line in Terminal's file in /usr/share/applications, or make overriding file in $HOME/.local/share/applications