How Modern Linux Differ From Each Other
The Linux operating system dates back to 1991, when a Finnish student, Linus Torvalds, began developing a new operating system inspired by the ideas of Unix and Minix. The successful choice of a free license predetermined the success of his undertaking - tens and hundreds of enthusiasts joined in the development, each of which brought something new. Subsequently, large companies joined the development - Intel, IBM and others. I don’t know the exact reasons that led industry leaders to support a free OS, but “evil languages” say that many companies decided to move Microsoft, which at that time was an absolute monopoly in desktop operating systems.
Linux kernel evolution expressed in number of lines
Could Linux be without the support of the industry’s masters to become what it is now? Far from a fact - old-timers remember patent wars between the Santa Cruz Operation and Linux-supporting companies. SCO lost this war and no longer exists.
The number of commits per core by company
Thus, over the course of its life, the Linux operating system has come a long way in evolution and has now become a popular operating system that can replace Windows to solve many of the most urgent tasks for users.
Before we begin comparing modern Linux distributions, we need to identify two important aspects - the first aspect is what the operating system consists of, the second - from what point of view we will compare. By distribution we mean a complete solution consisting of an OS kernel, a graphic server (X server), environment (a set of supplied programs), installation utility, and initial configuration. You can compare distributions from the point of view of the end user, system administrator and application programmer.
Linux from the point of view of the system administrator
At the dawn of its development, Linux was the domain of technologists and tech-priests with specific programming and administration knowledge. The forerunner of Linux was the Unix operating system, and a specialist with experience in administering Unix could easily install and configure the system. It was inaccessible to the average user and the administration process was akin to magic for him. Modern Linux has become user friendly - the installation process comes down to answering a few questions, and often just accepting the configuration option offered by the installer, simply answering all the questions positively - the installer will analyze the hardware configuration and select the necessary drivers and configuration parameters. Typically, a distribution kit contains ready-to-use software packages delivered as DEB or RPM archives containing, in addition to the programs themselves, configuration scripts and information about dependencies on third-party libraries. However, there are exceptions, for example, the Gentoo distribution comes in the form of the source when all the programs and assembly rules are installed, and the operating system itself is literally assembled on the user's computer under its processor configuration. The question of the effectiveness of such a method is controversial, we will not delve into it, I only note that this is only one of the degrees of freedom declared by the community - the user is free to choose "whether the game is worth the candle." In general, the RPM and DEB package formats are similar, and you should not consider this point when choosing a distribution kit.With rare exceptions, sometimes it happens that the author of the program for some reason did not provide the second version of the installer and it exists only in RPM (RedHat Linux and its derived distributions) or DEB (Debian Linux and its derivatives) format. In this case, you may need efforts to install such a program - even manually unpacking the installation package, you can stumble on unsatisfied dependencies. Installing such a program will require a lot of effort, and in case of an error, trying to replace the required libraries can lead to a system crash. Fortunately, this situation is extremely rare and 99.9% of Linux users will never encounter this problem. Moreover, all well-known distribution manufacturers keep their repositories with a rich set of programs, where each program is compiled and tested for a specific version of the distribution.
So, we know that one of the differences between Linux is the package format. However, from the point of view of the system administrator, there is another difference - the format of the start scripts. Two competing formats came from the Unix family of Linux operating systems - System V style and BSD style. To understand what it is about, let's see how it works. The bootloader loads the OS kernel and transfers control to it, the kernel starts and starts the first process - init. Strictly speaking, instead of init, you can slip any process, for example, bash. In this case, we get something like a single-user single-task console system without a network and graphical interface and with a read-only root file system. Moreover, part of the equipment in this case may not work if the drivers for it are not present in the kernel, but are loaded in the form of modules. In the classical operating mode, the init process reads the/etc/inittab file and, in accordance with it, starts the system startup process - mounts partitions, loads drivers, initializes network interfaces, starts service programs (which were previously called daemons), loads the graphics subsystem. Init does this not directly, but using the concept of runlevel and special scripts. Usually there are up to six runlevels - runtime modes that describe the system's operating modes - start-up, single-user, multi-user with a network subsystem, multi-user with a graphical interface. Depending on the conditions of use, the administrator can set the standard runlevel to which the system will go after boot, usually it is a multi-user mode with a network and a graphical interface for the desktop and a multi-user mode with a network for servers. It is in these scripts that the difference between SystemV and BSD styles is made. However, having knowledge of the inittab format, you can look at the contents of the scripts and understand how the start, stop, and transition procedures between runlevels of the system work.
In 2010, RedHat engineers developed the replacement init - the systemd service. This service has brought new features to the system:
- socket activation services (
- scheduled services launch (
- work with hardware watchdog timer (replaces watchdog);
- root change (replaces chroot);
- automount volumes and network resources (
replacescomplements mount and fstab);
- journalctl - logging service;
- systemd-analyze - analysis of the launch of services (includes the speed of loading (both the system and individual services), rendering the start of services, etc.);
- systemd-boot - UEFI bootloader (replacing grub and lilo).
Currently, the vast majority of Linux distributions have switched to systemd, of the once popular distributions, only Slackware resists the transition to a new subsystem.
Thus, the transition to systemd seems to erase one of the differences between Linux - the system of start scripts and leads to unification. At the same time, support for classic startup scripts is preserved - for example, some volumes for mounting can be specified classically via/etc/fstab, and other volumes can be mounted using systemd.
In the past, system administrators liked to argue which system is better than SystemV or BSD, but now the debate has subsided. An experienced system administrator will be able to configure any system, for newcomers to the Web there is enough information that reveals any aspect of Linux configuration.
Linux from the point of view of the user
From an end-user perspective, Linux differs slightly more. Let's look deep into the question. Initially, the Unix graphics subsystem was optional. Often Unix worked on powerful computers, and users connected to it through X-terminals. The interaction took place over the network - the program was executed on the host computer, received information about pressing the keyboard and mouse events, and in response sent commands to the terminal to draw graphic primitives and text. Graphics terminals were expensive and rare devices, so personal computers became popular as terminals. Here, by the way, is an interesting point, which often causes misunderstanding - the X server runs on the terminal, and not on the host. The host runs the program itself, which uses the xlib library, which provides a basic low-level interface for working with a graphic server. This interface is quite low-level, it introduces the concept of a window, i.e. a rectangular area of the screen, it can display vector text in various fonts, and also provides rendering of various graphic primitives - points, lines, rectangles, circles and pictures.
Since the basic graphic primitives are quite simple, this led to the emergence of widget libraries - these libraries provide a higher level of abstraction and greatly simplify the writing of programs with a graphical interface. For example, the X Athena Widgets library has become part of the X Window System graphics system. This library introduces the concept of buttons, radio buttons, menus, input fields and similar primitives. However, by modern standards, it looks pretty “twisted”.
And here actually differences for users begin. The appearance of what the user sees on the screen depends on several subsystems - this is the Desktop Environment providing a space called the desktop, this is a window manager that determines the appearance of program windows (window decorations) and often, but not necessarily, integrated into the desktop environment, and finally, this is a library of interface elements. What and how the user sees on the screen is determined by combinations of the above components.
In practice, this leads to the fact that the same program launched in different window managers can have different window decorations - different headers, window border sizes, different minimization, full-screen and close buttons. All this is determined by the window manager. At the same time, within the same window manager, different programs can have different types of interface elements, depending on the library used. In fairness, it should be noted that you could observe a similar variety on Windows, but much less often, since the vast majority of Windows programs use standard GDI + or the binding around it.
What does a Linux user encounter on the desktop? First of all, it’s GNOME or KDE, most distributions are based on these desktop environments. However, they are not limited to and various Linux vendors offer about a dozen different environments. As for the interface element libraries, two libraries are leading here - GTK and Qt. Both libraries are cross-platform, and if any program exists under Linux or under Windows, then with a high probability it is written using GTK or Qt. However, there are exceptions, for example, Xamarin created a version of the Windows Forms library for Linux and macOS. Also sometimes window manager developers distribute their widget libraries. Thus, it becomes clear where such a variety of graphical user interfaces for Linux comes from.
Linux from the perspective of application programmers
All of the above applies to programming as well. If you are writing a server or a console utility, then in the vast majority of cases you will not have to use conditional compilation directives - modern Linux is fairly well standardized and fully compatible with the POSIX standard. Moreover, the use of autoconf allows you to write programs not only for Linux, but also for any POSIX compatible system, starting from BSD and ending with all kinds of exoticism.
You most likely will not have to choose the package format - use both DEB and RPM, and you will cover almost all cases of use.For service programs, you will probably have to pay attention to the format of startup scripts so that the installer correctly registers the autorun of your service. In my case, I had to pay attention to the location of the fonts, since various vendors use different paths to store the fonts, however, a recursive search starting with/usr/share/fonts will help you here - all fonts, except for custom ones, will be on this path. As for custom fonts that are installed in/home/user, some “confusion and reeling” is noticed here and different vendors offer at least two hierarchies - ~/.fonts and ~/.local/share/fonts.
For graphics programs, there are several more difficulties. In view of the zoo of various desktop environments, it is necessary to take into account their features. For example, the so-called desktop notifications will be supported by most desktop environments, but may not work with some exotic window managers.
Finally, a few more important points that make significant differences between distributions. Despite the similarity of all modern Linux, you may encounter problems on distributions with increased protection, i.e. those using a credential access system. For example, a resource by default is available in all classic distributions, but it will cause an access error in a protected version of Linux. It is impossible to predict in advance where and how the program will fail, therefore testing on protected distributions is the only solution. Or a quick fix after contacting a tech support user.
The second point is the popularity of the distribution. If you use some not very widespread library or framework as part of the product, then it is possible that such a distribution will have an old or incomplete version of this library. In my practice, this situation happened in one of the distributions supporting codepage 1251 in the System.Text.Encoding library for C #. There are only one way to deal with such problems - since there is no problem with other Linux distributions, you should write technical support to the developer of this distribution, describe the problem in detail and say that there is no problem in other distributions.
Output . If you do not consider protected versions of Linux, then from the point of view of system administrators and programmers, modern distributions are very similar. Often the differences between different generations of the distribution for one vendor are more significant than the differences between modern distributions. From the point of view of users, the main difference is in choosing and setting up the desktop environment and the software supplied in the distribution kit.