The Linux operating system traces its history back to 1991, when the 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 - dozens and hundreds of enthusiasts joined the development, each of whom brought something new. Subsequently, large companies joined the development - Intel, IBM and others. The exact reasons that prompted the industry leaders to support a free operating system are not known to me, but "evil tongues" say that many companies decided to move Microsoft, which at that time had an absolute monopoly in operating systems for desktop computers.
Linux kernel evolution expressed in number of lines
Could Linux, without the support of the industry masters, have become what it is now? Far from a fact - old-timers remember the patent wars between the Santa Cruz Operation and the companies supporting Linux. SCO lost this war and no longer exists.
The number of commits to the core by company
Thus, during its life, the Linux operating system has come a long way of evolution and has now become a popular operating system capable of replacing Windows for solving many of the urgent tasks of users.
Before we start comparing modern Linux distributions, we must define two important aspects - the first aspect is what the operating system consists of, and the second is from what point of view we will compare. By a distribution kit we mean a complete solution consisting of an OS kernel, a graphical server (X-server), an environment (a set of supplied programs), an installation utility and an initial configuration. It is possible to compare distributions from the point of view of the end user, system administrator, and application programmer.
Linux from a system administrator's point of view
At the dawn of its development, Linux was the lot of technologists and tech-priests with specific knowledge of programming and administration. The forerunner of Linux was the Unix operating system, and a specialist with experience in Unix administration could easily set up and configure the system. This was inaccessible to the average average user, and the administration process for him was something akin to magic. Modern Linux has become user-friendly - the installation process boils down to answering a few questions, and often it is enough just to agree with the configuration option offered by the installer, simply by answering all questions positively - the installer will analyze the hardware configuration and select the necessary drivers and configuration parameters. Usually the distribution kit contains ready-to-use software packages,supplied in the form of 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 is supplied as a source when all programs and build rules, and the operating system itself is literally built on the user's computer for his processor configuration. The question of the effectiveness of such a method is controversial, we will not delve into it, I will only note that this is only one of the degrees of freedom declared by the community - the user is free to choose "whether it is worth the candle". In general, the RPM and DEB package formats are similar, and when choosing a distribution kit, you can ignore this point. With rare exceptions - sometimes it happensthat the author of the program for some reason did not provide for the second version of the installer and it exists only in RPM (RedHat Linux and its derivatives) or DEB (Debian Linux and its derivatives) format. In this case, you may need an effort to install such a program - even manually unpacking the installation package, you may stumble upon unsatisfied dependencies. Installing such a program will require a lot of effort, and in case of an error, trying to replace the required libraries, you can lead to a system crash. Fortunately, this situation is extremely rare and 99.9% of Linux users will never face this problem. Moreover, all well-known manufacturers of distributions 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 packet format. However, from the point of view of the system administrator, there is one more difference - the format of the startup scripts. From the Unix family of operating systems, Linux has two competing formats - System V style and BSD style. To understand what this is about, let's see how it works. The boot loader 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-tasking console system with no network and no graphical interface and with a read-only root filesystem. Moreover, some of the hardware in this case may not work if the drivers for it are not present in the kernel, but are loaded as modules.In the classic mode of operation, 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 - the execution modes that describe the operating modes of the system - starting, single-user, multi-user with a network subsystem, multi-user with a graphical interface. Depending on the conditions of use, the administrator can set a standard runlevel, which the system will switch to after booting,it is usually multi-user mode with network and graphical interface for the desktop and multi-user mode with network for servers. It is in these scripts that the difference between SystemV and BSD styles lies. However, having knowledge of the inittab format, you can look at the contents of the scripts and understand how the start, stop, and transition between system runlevels work.
In 2010, engineers at RedHat developed a replacement for init, the systemd service. This service has brought new features to the system:
- socket-activated services (
replacescomplements inetd); - launching services on a schedule (
replacescomplements cron); - work with a 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 service startup (includes loading speed (both of the system and of individual services), rendering of the start of services, etc.);
- systemd-boot - UEFI bootloader (replacement for 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 the new subsystem.
Thus, the transition to systemd, as it were, erases one of the differences between Linux - the system of startup 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, while other volumes can be mounted using systemd tools.
In the past, sysadmins used to argue which system was better than SystemV or BSD, but now the debate has subsided. An experienced sysadmin will be able to configure any system, but for newbies on the Web, there is enough information that reveals any aspect of Linux configuration.
Linux from a user perspective
From the point of view of the end user, Linux differs slightly more. Let's look deeper into the question. The graphical subsystem was originally optional on Unix. Unix often ran on powerful computers, and users connected to it via 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. Graphical terminals were expensive and rare devices, so personal computers became popular as terminals. By the way, here is an interesting point that often causes confusion - the X-server is executed on the terminal, not on the host. The program itself is running on the host, which uses the xlib library,providing a basic low-level interface for working with a graphics server. This interface is quite low-level, it introduces the concept of a window, i.e. rectangular area of the screen, can display vector text in various fonts, and also provides drawing of various graphic primitives - points, lines, rectangles, circles and pictures.
Since the basic graphical primitives are quite simple, this has led to the emergence of widget libraries - these libraries provide a higher level of abstraction and greatly simplify writing programs with a graphical interface. For example, the X Athena Widgets library became 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 this is where the differences begin for users. The appearance of what the user sees on the screen depends on several subsystems - it is the Desktop Environment that provides a space called the desktop, it 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, it 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 running in different window managers can have different window decorations - different titles, window border sizes, different minimization, full-screen and close buttons. The window manager defines all this. However, within a single window manager, different programs can have different types of interface elements, depending on the library used. For the sake of fairness, it should be noted that you could observe such a variety in Windows, but much less often, since the vast majority of Windows programs use standard GDI + or wrapped around it.
What will the Linux user face on the desktop? First of all, it is GNOME or KDE, most of the 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 libraries of interface elements, two libraries are in the lead here - GTK and Qt. Both libraries are cross-platform, and if any program exists under both Linux and Windows, then it is most likely written using GTK or Qt. However, there are exceptions, for example, Xamarin has 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 come from.
Linux from the point of view 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 do not need to use conditional compilation directives - modern Linux is fairly well standardized and fully POSIX compliant. Moreover, using autoconf allows you to write programs not only for Linux, but also for any POSIX compatible system, from BSD to all sorts of exotic.
You probably won't have to choose a package format - use both DEB and RPM and you will cover almost all use cases. For service programs, you will probably have to pay attention to the format of the startup scripts so that the installer correctly registers the autostart of your service. In my case, I had to pay attention to the location of the fonts, since different vendors use different paths for storing fonts, however, a recursive search starting with / usr / share / fonts will help you here - all fonts, except for custom ones, will be located along this path. As for the custom fonts that are installed in / home / user, there is some confusion and wobbling, and different vendors offer at least two hierarchies - ~ / .fonts and ~ / .local / share / fonts.
For graphics programs, the complexity is somewhat greater. In view of the zoo's different desktop environments, you need to consider their particularities. For example, so-called desktop notifications will be supported by most desktop environments, but may not work with some exotic window manager.
Finally, a few more important points that make significant differences between distributions. Despite the similarity of all modern Linuxes, you may encounter problems on distributions with increased protection, i.e. those where the mandatory access system is used. For example, some resource is available by default in all classic distributions, but will cause an access error in the protected version of Linux. It is impossible to predict in advance where and how the program will fail in this case, so the only solution is to test on protected distributions. Or a quick fix of the problem after the user has contacted technical support.
The second point is the popularity of the distribution. If you use some not very common library or framework as part of the product, then it is possible that such a distribution will contain an old or incomplete version of this library. In my practice, this situation happened in one of the distributions with support for code page 1251 in the System.Text.Encoding library for C #. There is only one way to deal with such problems - since the problem is not observed in other Linux distributions, you should write to the technical support for the developer of this distribution, describing 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 a distribution from the same vendor are more significant than the differences between modern distributions. From the point of view of users, the main difference is in the choice and configuration of the desktop environment and the software supplied with the distribution.