[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 firmware: Legacy BIOS (loads MBR sector, which contains partition table and first-stage bootloader),
or UEFI (partition marked "boot"
is a FAT32 filesystem; select and load a bootloader file from it).
- Boot manager / bootloader: usually GRUB,
but there are others (Syslinux, LILO, rEFInd, gummiboot, efistub, coreboot, systemd-boot, more).
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.
- Kernel type: SELinux or not,
Hypervisor or not ?
- Kernel: handles processes, memory, etc. Uses drivers to connect to hardware devices, and modules
to implement filesystems and network protocols and security mechanisms and encryption etc.
Linux kernel map
Do "lsmod" to see installed modules, drivers and filesystem types.
Each distro can configure the kernel as it wishes.
- Modules and Drivers: "ls /lib/modules/$(uname -r)/kernel/drivers/*/*.ko"
to see all available modules and drivers.
- Filesystems: "ls /lib/modules/$(uname -r)/kernel/fs/*/*.ko"
to see all available filesystem types.
- libc API: glibc, musl, others.
packages/utilities: shell, compiler, libraries, CLI utilities (coreutils: cat, ls, grep, others), etc.
utilities: dmesg, fsck, kill, su, others.
- Windowing/display server protocol: X11, Wayland, Mir, OpenGL ?
article "echo $XDG_SESSION_TYPE" "glxinfo"
- Display server: X.Org Server, XFree86, Wayland compositor (mutter) ?
- Window manager: X11 manager (i3, dwm, bspwm, Fluxbox, Openbox, mutter, Compiz, Metacity, KWin, muffin),
Wayland manager/compositor/etc (Weston, sway, Way Cooler, mutter, Enlightenment, Wayfire, etc) ?
do "wmctrl -m" to see what you're using.
From StackExchange answers:
"Your display manager creates a nice graphical display where you can use a login manager to
login to your X session which will start a window manager and may start a desktop manager."
From someone on reddit:
"The window manager puts the window decoration around the contents including the buttons to minimize or close.
It allows resizing and moving the windows around, decides which window is on top."
- GUI framework/library/toolkit ?: GTK+, Qt, libwayland-client, libX, OpenGL ? Non-GUI: D-Bus, udev ?
- App framework/library ?: KDE, GNOME, Unity, etc ?
- Desktop manager (taskbar/systray, application launcher, icons): KDE/Plasma, GNOME, Cinnamon, Xfce, LXDE, etc.
A bundle of choices of the last 4-5 items and some apps usually is called a "Desktop Environment" (DE)
GNOME, GNOME Flashback, KDE Plasma, Xfce, LXDE, LXQt, Cinnamon, MATE,
Enlightenment/E, Pantheon, Trinity, Budgie, Unity, Deepin/DDE, Razor-qt,
Sugar, UKUI, PIXEL, Equinox/EDE, etc.
From someone on reddit:
"A DE gives you an overall user experience. It has the panels, the system menus, the starters,
the status applets. It has a window manager. It might offer a default file explorer and viewer.
To streamline, it might even contain default editor, terminal program, or even e-mailer,
all made to look alike and work together."
Other pieces that usually vary by DE
A distro is a set of choices of layers/parts/policies, all packaged together
under one label.
Some major distros: Debian, Fedora, Red Hat, Ubuntu, Xubuntu, Linux Mint, openSUSE, etc.
Debian Family Tree
Which is just part of a bigger
GNU/Linux Distributions Timeline
Other pieces that often vary by distro or distro-family
- Display manager / login screen manager: KDM, GDM, LightDM, MDM, SLiM, etc.
Ivana Isadora Devcic's "How to Choose & Switch Linux Display Managers"
- System Languages.
- Desktop widgets/launchers/icons/shortcuts.
- Taskbar/systray applets.
- GUI-shell extensions.
- GUI workspaces (AKA virtual desktops or multiple desktops;
- KDE's GUI
(desktops with different icons and widgets on each, and then you can have
multiple workspaces inside each activity).
Some other variations or modifications
- Installer (Calamares,
- System GUI apps: updater,
software manager/store (article),
file manager/explorer (Nautilus, Nemo, Caja, Thunar, Dolphin, Krusader, others) and add-ons, task manager,
crash-reporter (whoopsie, apport, Dr. Konqi, others), etc.
("xdg-mime query default inode/directory" to show file manager in use.)
- User GUI apps: terminal, text-editor, video player, browser, etc.
- 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.
- 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.
Things that vary less often, or vary only from one distro-family to another:
- Package formats and managers
- Init/daemon/services system:
BSD-style startup scripts (Slackware),
- Fairly standard daemons/services:
Network management (DNS, DHCP, VPN, etc), printing (CUPS), network services (FTP, SSH, etc).
- Fairly standard facilities:
Authentication (PAM, certificates, more), access control,
IPC (D-Bus, sockets, more).
, 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, etc.
- 32-bit and 64-bit versions, as on Windows.
- UEFI Secure Boot (Ubuntu's "SecureBoot"), or not.
- Kernel / system emphasis: normal, high-availability (clustering), hardened,
low-latency (e.g. Ubuntu Studio), real-time, run-as-root (e.g. old Kali), run containers, cloud.
- 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, etc.
- Various GUI docks: Latte, Cairo, Docky, etc.
- Do you compile things yourself from source
or use binaries created by other people/companies.
From someone on reddit:
Just FYI ... as someone who has gone through Linux from Scratch ...
Certainly you will learn some things about Linux by doing this. But honestly ... LFS is essentially
a lot of very repetitive compiling -- you go through the compilation of all the basic tools for
setting up a Linux system. But there's very little explanation about how things work, how all
the pieces fit together, etc., and the final product is a bare-bones, minimal Linux install.
Obviously, you can add more to it if you wish (and there is some guidance on the web site for that),
but in general I think the best thing that LFS teaches is just sort of ... how programs are
compiled from source code.
I learned a lot more about how the pieces of Linux fit together (the init system, networking,
package management, desktop environments, etc.) by installing Arch Linux. (Gentoo would work as
well, but is a longer process given the compile time.) You're not "building it from scratch",
but most of the interaction people have with a working Linux system is on the level of those
building blocks, rather than "how do I ensure that this program in /bin is properly linked
with the correct gcc compile tool". I found it much more useful to find out things like,
"how does networking work in Linux? what's the difference between ALSA and PulseAudio?"
And if you're really interested in how software is compiled, of course, you are certainly
free to compile things within an already-working Linux distro! Installing something manually
from the Arch User Repository could be a useful intro into this concept.
I'm certainly not trying to dissuade you from going through Linux from Scratch. It's well-written,
and there's certainly something cool to building your own Linux system entirely from the ground up.
I'm just trying to offer my perspective, as someone who went through it myself for the purpose of
learning about how Linux worked, and realized I didn't actually learn much at the end of it.
- Policy / standards / licensing bodies and corporations.
- System administrators.
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.
You could pick an app or distro and:
Jason Evangelho's "8 Ways To Contribute To The Desktop Linux Community, Without Knowing A Single Line Of Code"
wikiHow's "How to Contribute to Open Source"
KillYourFM / contribute-foss
Open Source Guides' "How to Contribute to Open Source"
LTP - Linux Test Project
- Donate money to the project.
- If you find bugs during normal use, report them.
- Get onto the beta or insiders or "proposed" track, and report crashes and bugs.
- Help to test it, systematically, using a plan and maybe automated tools.
- Help to improve the docs.
- Help to improve the project or doc web sites.
- If you're artistic, work on artwork or logos.
- Help to port an app or service to more distros or more DEs.
- Help to translate a distro or app to more human languages.
- Help to make a distro or app or site more accessible to the disabled or impaired.
- Do some bug-fixing (start small: a smaller app you know well, in a language you know, small bugs).
- Donate money to fund development or fixing of a particular feature, or do specific
work yourself for money: Bountysource.
See "Reporting Bugs" section of my "Using Linux" page
Shubheksha's "How to find your first open source bug to fix"
Davide Coppola's "How to contribute to an open source project on GitHub"
Elizabeth K. Joseph's "4 ways I contribute to open source as a Linux systems administrator"
Quora discussion "How do I start contributing in Open Source projects?"
Sarah Drasner's "How to Contribute to an Open Source Project"
Command Line Heroes' S2E3 "Ready to Commit" (audio)
Debian's' "How can you help Debian?"
For development, start with an app, DE, or distro you use
First, become a very good user
kamranahmedse's "Getting Familiar with Unfamiliar Codebase"
Development things to realize
- Use the software, explore the features, read the docs and Help.
- Update to the latest version, or the beta version.
- File bug reports, and read the open issues/bugs.
- Join the user forum or group or reddit sub.
Big projects often have extensive guides for developers
- Probably you will be stepping into a project that has a 20-year history, an enormous
base of scripts, code, docs, and issue-tracking, and a big somewhat-changing team of developers.
- It will take time to learn the code and tools and style.
- Flitting from one project to another may be difficult, if they all use different tools and languages etc.
- People-issues and process will be very important; follow the rules, be humble, start very small.
- If a project seems stalled (2 years since last release, bugs open for a long time, pull/merge requests
outstanding for a long time), or going through a huge transition,
or very undocumented, or broken in some way, maybe stay away (at least as a first project to join).
Check the plans/roadmap for the unit you have chosen, to see the priorities, and what other
people may be working on:
linuxmint / Roadmap
Find out the developer communication channels (mailing list, forum, bug-tracker, IRC, whatever)
for the unit you have chosen, and join those channels.
Hcamael's "How to Develop Linux Driver from Scratch"
Corbet, Rubini, and Kroah-Hartman's "Linux Device Drivers, Third Edition"
From someone on reddit:
Please don't create a new distro
> I want to take a stab at creating a couple of GUI Linux apps to improve
> the usability of some parts of the system that are locked to CLI.
Honestly, coding probably isn't going to be the lynchpin issue you'll run into.
Most projects are ruled like fiefdoms, some are more reasonable/practical than others and as a result
allow for more broader contributions, but you still run into issues where maintainers/developers will
not accept or consider certain features because it either violates their vision or ethos for what
they think their creation should be, or they don't want to support features they aren't interested in
(desktop icons disappearing from Gnome3 is a prime example), whatever the case it's not a coding issue,
the biggest problems with OSs are people issues.
Linux is suffering from Fragmentation
Please don't create a new distro. We have far too many already.
GNU/Linux Distributions Timeline
If you want/need something, do it some other way. A configuration script that modifies an existing distro.
A new DE or theme. A new kernel module. Whatever is appropriate for your need/idea.
Of course, if you have some great new world-beating idea that just can't be done in an
existing distro, go for it ! But expect lots of work and little audience. Better if
you could implement your idea in some major distro such as Ubuntu, and get it out
to millions of users.
Make a Linux App
"Fragmentation" section of my "Linux Problems" page
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
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.
"Terminal" is not same as "shell"
- 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 can be faster for experienced users.
- 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.
Expression of Change's "CLIs are reified UIs"
- Terminal is the GUI wrapper (window controls, tabs, copy/paste, drag/drop, font,
background image/color, line-buffer, scrolling, more).
- Shell is the text-command part (variables, statements, pipes/redirection,
launch commands, path, history, more).
- Console (accessible via ctrl+alt+F1 etc) is a
text window which is a text wrapper for the shell, and is run from a much
lower level than a GUI terminal.
Terminals: gnome-terminal, konsole, guake, rxvt-unicode, aterm, xterm, kitty, alacritty, tilix,
terminator, PuTTY, more.
Shells: sh, csh, bash, fish, zsh, ksh, more.
||Red Hat, Fedora, CentOS, SUSE, Mageia
||rpm, yum, dnf, zypper, YaST, urpmi, Drakrpm
||Debian, Ubuntu, Mint
||dpkg, apt, apt-*, aptitude, Synaptic, wajig
||Slackware, VectorLinux, Zenwalk
||pkgtools, slackpkg, slapt-get, Swaret, netpkg
||Arch, Manjaro ?
||pacman, pamac ? AUR helpers: yay, yaourt, apacman, pacaur ?
||emerge/Portage, entropy, equo
||Intel Clear Linux
Some front-end managers that work on top of multiple package formats: smart, PackageKit.
Combination package manager / configuration manager ?
Devopedia's "Package Manager"
DistroWatch's "Package Management Cheatsheet"
Dedoimedo's "Broken apt, missing dependencies, what now?"
From /u/Linux4ever_Leo on reddit:
Honestly, there really isn't anything stopping the Linux world from standardizing on one single package management
system except for egos. Each distro line deems its own package management systems to be the "best".
Red Hat derived distros use RPM packages; Debian derived distros use DEB packages, Slackware uses good ol' tarballs.
Gentoo and Arch prefer sources based packages. Still other distros have developed their own proprietary
ways of managing packages. In short, it's sort of a mess. ... Personally, I don't care what sort of
package manager wins the game so long as SOMETHING is standardized which will help further the widespread
adoption of software on Linux and make things easier for developers to port their software to the Linux platform.
There are a couple of other levels of "management":
- VMs and emulators.
- Containers (snap, flatpak, appimage, docker).
- Language-specific managers (npm, ruby gem, pip).