July 12, 2009 at 18:12GNU or Linux?
- Transfer
Looking through articles for translation on translated.by I came across a proposal to translate a GNU or Linux article ? authored by David Chisnall . The author suggests understanding what is more in the OS - GNU or Linux? Actually the translation of this article is brought to your attention.
No other system has experienced such controversy around its name. A huge number of flame wars began after the FSF announced that distributions such as Ubuntu and Fedora should be called GNU / Linux, instead of Linux. Did they just try to make money from someone else's work, or their arguments are not unfounded?
To understand this issue, let's take a look at what happens when you start the GNU / Linux system - how much GNU code is used and how much Linux code is used. The developer uses a huge amount of GNU code, for example GCC and GNU Make, but how true is this for the end user?
Before starting to figure out where are the GNU bits and where is Linux, it is important to understand what the kernel does. The kernel performs two main tasks:
* It frees developers from the need to study low-level architecture. This requires the presence of a large number of drivers for devices and common interfaces to these drivers. A good example is the socket interface. When you write network code, you simply open the socket and write data to it. You do not need to worry about the type of user network equipment and underlying protocols.
* Isolates running programs from each other.Isolating processes with a platform-independent method is simple: Allow processes to use only unprivileged processor instructions. Unfortunately, this approach will make impossible any I / O operations for programs, which makes all programs pointless. To remove this restriction, there is a system call - a mechanism that allows a running process to request the kernel to perform a privileged operation on behalf of the requesting process. Common examples are writing to a file (virtual disk), allocating memory, or accessing a screen or keyboard.
The mechanism used by the system call is platform dependent. An exception method was a common method on the x86 platform, although the new processors from AMD and Intel provide instructions to make this even faster. In this case, control passes to the kernel, which decides how to interpret the values in the registers and on the stack, as well as what actions to take.
An important standard when programming for * NIX or * NIX is the single UNIX specification - the POSIX superset, which includes everything that should be on a UNIX system. Code written according to this standard is portable among a number of UNIX-like systems.
The standard does not describe system calls. On the contrary, it describes C functions that serve as a wrapper for system calls. When a programmer wants to call the open () function, he does not need to know that he will put the pointer in EBX and the value 2 in EAX, and then will cause an 80h interrupt; C standard library implements all these functions. Any non-trivial program on Linux will use the C library (libc, for short). There are several options for implementing the standard C library. Each member of the BSD family has its own implementation, however, like any commercial UNIX system. Which version of the C standard library is used on Linux depends on the usage; There are several versions for embedded systems, but most Linux desktop distributions use GNU libc.
By the amount of code, the kernel and libc are almost equal. For two, they provide a developer interface to the system. Since the standard defines only C-interfaces and not system calls, most of the code is written using the standard C library. This rule holds true for other languages; if you, for example, run some java or python code, then it will gain access to the kernel through the C library. Some languages have their own standard library from the GNU Project. For example, any C ++ code will use GNU libstc ++ on GNU / Linux platforms. Some distributions also include GNU implementations for Java libraries, although this practice is not so popular anymore, given that the Sun versions have become open source. Even if you use Sun Java libraries,
C ++ is even more nuanced than with other languages. When you link two modules (for example, an executable file and a library), then several standards at once describe the interaction model of these two modules. When calling a function from another module, it is necessary to explicitly determine the order of the arguments on the stack and in the registers, who will clear the memory afterwards, and so on. In C ++, a lot of things must be explicitly defined for using classes in various modules. This set of standards is called the Application Binary Interface (ABI). On Linux, C ++ ABI is defined in GCC, which is a GNU package, as mentioned earlier. Compiled C ++ code, regardless of which compiler was used, must obey GNU standards, otherwise such code cannot be reused by other C ++ code.
Modern GNU / Linux distributions begin the boot process with GRUB (GRand Unified Bootloader), which is also part of the GNU project. (Although, technically, the download starts in the BIOS or other firmware, and this applies to all systems that run on the hardware platform.) GRUB was not created specifically for Linux. It can run other operating systems, and is the standard for running some x86 systems, including OpenSolaris and the Xen hypervisor.
GRUB then transfers control to the kernel, which continues to initialize the system and configure the drivers. The kernel in turn transfers control to the init process. This process is responsible for creating other processes.
On Linux systems, init is a very small program that does more than just run a script. In some distributions, init is replaced by Upstart, a program that is neither part of Linux nor part of GNU, and has a more complex event-driven model. Scripts launched by init or Upstart are just a set of commands interpreted by a shell.
The POSIX specification describes the minimum functionality of the shell. If you want to write portable shell scripts, you can stay within this limited functionality, and, in the end, get scripts that will run on all UNIX-like systems.
However, most init scripts are not portable. They use the extended shell functionality found in most Linux distributions - Bash, the GNU shell.
The UNIX Unified Specification contains much more than just a set of C functions. In particular, the standard defines a set of user utilities that must be present on UNIX-like systems. Many programs use these utilities through shell scripts or other calls. Most of them are contained in the GNU root utility package. Again, comparing the number of lines of code, the size of the root utilities is comparable to the size of the kernel.
It can be assumed that these utilities are not so important part of the system, but this is not so. Without utilities, most init scripts simply won’t start (even with Bash), and the system will be unusable. Most installers will not start either, which means that you cannot install any programs. Even basic functionality such as copying files uses root utilities.
The Unified UNIX Specification provides a list of 175 programs that must be present on every UNIX system. Most of which (with a few exceptions, such as vi) are created by GNU and are present on most Linux distributions. Some of them are never used by ordinary users; for example, the standard requires c99 and fort77 utilities to compile programs written in C and Fortran (both utilities are provided by GNU).
I said earlier that the kernel has two roles. The main role in providing user programs with access to hardware. Therefore, most Linux code (and the code of most other kernels) consists of device drivers. But, it is worth mentioning the schedule separately.
The old XFree86 driver model depended weakly on the kernel. The X server started as a privileged process and received direct access to the hardware. I myself saw a live example of this when trying to use the Matrox binary Linux driver under FreeBSD. Although the driver was written for Linux, it got a great fit on FreeBSD, as it interacted directly with the X server and hardware, and not at all with the FreeBSD kernel.
New drivers use the Direct Rendering Infrastructure (DRI). This system consists of two components called DRI and DRM. DRI is a user environment driver that provides commands to the hardware and provides the API to other user programs. DRM, in turn, is a small kernel module that checks commands and passes them to the hardware.
Often when holivars on the topic "is Linux ready for the desktop" people ask, how well does 3D work in Linux? In fact, 3D processing is not a Linux task on most systems. Linux just provides a direct interface to the hardware, and X.Org already writes drivers. The same drivers can be run on FreeBSD, OpenBSD and a number of other systems. In the GNU / Linux world of Linux systems, Linux is not developing drivers for one of the hardest parts of the hardware component of a modern desktop / laptop.
With the invention of FUSE, which also runs on FreeBSD, NetBSD, and Mac OS X, the kernel often ceases to provide all drivers for file systems, further diminishing the role of Linux in the system.
Perhaps the most truthful test of the importance of a component of a system is how easy it is to manage without a given component in the system. Some Linux platforms use not many GNU programs; for example, using busybox for command line utilities and uclibc for the standard library. Some GNU platforms such as Nexenta or Debian GNU / kFreeBSD do not use the Linux kernel.
To appreciate the importance of Linux, let's take a look at the Linux compatible environment in FreeBSD. When running Linux programs on FreeBSD, a modified system call handler is installed that calls the FreeBSD kernel functions in response to Linux system calls. This approach allows you to run programs written under Linux, without changing them.
In order for this method to work, a stripped-down version of Linux is often installed in a separate environment. Programs written for Linux will eventually be able to find all the necessary libraries and utilities, including GNU utilities, GNU grep, Bash, and other packages.
What is this talking about? This suggests that if you want to run GNU / Linux program on a different system, then it is easy to do without Linux, but without GNU is not so simple.
Of course, most programs will run successfully without any compatibility mode if you recompile them. In this case, they will not use GNU libc, GNU utilities, or bash. Some programs require a GNU compiler or GNU Make to compile successfully, however, after compilation these programs will no longer require any GNU utilities except:
So uninstalling GNU from GNU / Linux seems a lot more complicated than uninstalling Linux. PC-BSD or Nexenta is a good desktop OS without a drop of Linux code inside, but with lots of GNU code. Those Linux systems that are not so heavily dependent on GNU code are completely integrated systems whose names are not familiar to users of desktop and server versions of Linux.
So what is it worth saying, Linux, GNU or GNU / Linux? I call GNU because, as a programmer and user, I mostly use the tools developed by GNU. When I port the code from FreeBSD, the problems arise only in the root utilities or in the standard C library. If I wanted to run the same code on HURD or any other GNU system, then I would use the same interfaces.
In general, I prefer to highlight distributions like Fedora or Ubuntu, and not mention GNU or Linux. The system includes a huge amount of code from various sources. The GNU Project and X.org are among the largest code providers, but Ubuntu GNOME / X.Org / GNU / Linux sounds a bit long. And including in the system name such a small and easily removable part as Linux, they act unfairly against many developers whose code is also present in the system.
- translated.by/you/gnu-or-linux/into-ru/trans
Original (English): GNU or Linux? (http://www.informit.com/articles/article.aspx? p = 1339466)
GNU or Linux?
No other system has experienced such controversy around its name. A huge number of flame wars began after the FSF announced that distributions such as Ubuntu and Fedora should be called GNU / Linux, instead of Linux. Did they just try to make money from someone else's work, or their arguments are not unfounded?
To understand this issue, let's take a look at what happens when you start the GNU / Linux system - how much GNU code is used and how much Linux code is used. The developer uses a huge amount of GNU code, for example GCC and GNU Make, but how true is this for the end user?
What does the kernel do?
Before starting to figure out where are the GNU bits and where is Linux, it is important to understand what the kernel does. The kernel performs two main tasks:
* It frees developers from the need to study low-level architecture. This requires the presence of a large number of drivers for devices and common interfaces to these drivers. A good example is the socket interface. When you write network code, you simply open the socket and write data to it. You do not need to worry about the type of user network equipment and underlying protocols.
* Isolates running programs from each other.Isolating processes with a platform-independent method is simple: Allow processes to use only unprivileged processor instructions. Unfortunately, this approach will make impossible any I / O operations for programs, which makes all programs pointless. To remove this restriction, there is a system call - a mechanism that allows a running process to request the kernel to perform a privileged operation on behalf of the requesting process. Common examples are writing to a file (virtual disk), allocating memory, or accessing a screen or keyboard.
The mechanism used by the system call is platform dependent. An exception method was a common method on the x86 platform, although the new processors from AMD and Intel provide instructions to make this even faster. In this case, control passes to the kernel, which decides how to interpret the values in the registers and on the stack, as well as what actions to take.
View from the developer.
An important standard when programming for * NIX or * NIX is the single UNIX specification - the POSIX superset, which includes everything that should be on a UNIX system. Code written according to this standard is portable among a number of UNIX-like systems.
The standard does not describe system calls. On the contrary, it describes C functions that serve as a wrapper for system calls. When a programmer wants to call the open () function, he does not need to know that he will put the pointer in EBX and the value 2 in EAX, and then will cause an 80h interrupt; C standard library implements all these functions. Any non-trivial program on Linux will use the C library (libc, for short). There are several options for implementing the standard C library. Each member of the BSD family has its own implementation, however, like any commercial UNIX system. Which version of the C standard library is used on Linux depends on the usage; There are several versions for embedded systems, but most Linux desktop distributions use GNU libc.
By the amount of code, the kernel and libc are almost equal. For two, they provide a developer interface to the system. Since the standard defines only C-interfaces and not system calls, most of the code is written using the standard C library. This rule holds true for other languages; if you, for example, run some java or python code, then it will gain access to the kernel through the C library. Some languages have their own standard library from the GNU Project. For example, any C ++ code will use GNU libstc ++ on GNU / Linux platforms. Some distributions also include GNU implementations for Java libraries, although this practice is not so popular anymore, given that the Sun versions have become open source. Even if you use Sun Java libraries,
C ++ is even more nuanced than with other languages. When you link two modules (for example, an executable file and a library), then several standards at once describe the interaction model of these two modules. When calling a function from another module, it is necessary to explicitly determine the order of the arguments on the stack and in the registers, who will clear the memory afterwards, and so on. In C ++, a lot of things must be explicitly defined for using classes in various modules. This set of standards is called the Application Binary Interface (ABI). On Linux, C ++ ABI is defined in GCC, which is a GNU package, as mentioned earlier. Compiled C ++ code, regardless of which compiler was used, must obey GNU standards, otherwise such code cannot be reused by other C ++ code.
Boot system.
Modern GNU / Linux distributions begin the boot process with GRUB (GRand Unified Bootloader), which is also part of the GNU project. (Although, technically, the download starts in the BIOS or other firmware, and this applies to all systems that run on the hardware platform.) GRUB was not created specifically for Linux. It can run other operating systems, and is the standard for running some x86 systems, including OpenSolaris and the Xen hypervisor.
GRUB then transfers control to the kernel, which continues to initialize the system and configure the drivers. The kernel in turn transfers control to the init process. This process is responsible for creating other processes.
On Linux systems, init is a very small program that does more than just run a script. In some distributions, init is replaced by Upstart, a program that is neither part of Linux nor part of GNU, and has a more complex event-driven model. Scripts launched by init or Upstart are just a set of commands interpreted by a shell.
The POSIX specification describes the minimum functionality of the shell. If you want to write portable shell scripts, you can stay within this limited functionality, and, in the end, get scripts that will run on all UNIX-like systems.
However, most init scripts are not portable. They use the extended shell functionality found in most Linux distributions - Bash, the GNU shell.
What is the standard?
The UNIX Unified Specification contains much more than just a set of C functions. In particular, the standard defines a set of user utilities that must be present on UNIX-like systems. Many programs use these utilities through shell scripts or other calls. Most of them are contained in the GNU root utility package. Again, comparing the number of lines of code, the size of the root utilities is comparable to the size of the kernel.
It can be assumed that these utilities are not so important part of the system, but this is not so. Without utilities, most init scripts simply won’t start (even with Bash), and the system will be unusable. Most installers will not start either, which means that you cannot install any programs. Even basic functionality such as copying files uses root utilities.
The Unified UNIX Specification provides a list of 175 programs that must be present on every UNIX system. Most of which (with a few exceptions, such as vi) are created by GNU and are present on most Linux distributions. Some of them are never used by ordinary users; for example, the standard requires c99 and fort77 utilities to compile programs written in C and Fortran (both utilities are provided by GNU).
What else should you pay attention to?
I said earlier that the kernel has two roles. The main role in providing user programs with access to hardware. Therefore, most Linux code (and the code of most other kernels) consists of device drivers. But, it is worth mentioning the schedule separately.
The old XFree86 driver model depended weakly on the kernel. The X server started as a privileged process and received direct access to the hardware. I myself saw a live example of this when trying to use the Matrox binary Linux driver under FreeBSD. Although the driver was written for Linux, it got a great fit on FreeBSD, as it interacted directly with the X server and hardware, and not at all with the FreeBSD kernel.
New drivers use the Direct Rendering Infrastructure (DRI). This system consists of two components called DRI and DRM. DRI is a user environment driver that provides commands to the hardware and provides the API to other user programs. DRM, in turn, is a small kernel module that checks commands and passes them to the hardware.
Often when holivars on the topic "is Linux ready for the desktop" people ask, how well does 3D work in Linux? In fact, 3D processing is not a Linux task on most systems. Linux just provides a direct interface to the hardware, and X.Org already writes drivers. The same drivers can be run on FreeBSD, OpenBSD and a number of other systems. In the GNU / Linux world of Linux systems, Linux is not developing drivers for one of the hardest parts of the hardware component of a modern desktop / laptop.
With the invention of FUSE, which also runs on FreeBSD, NetBSD, and Mac OS X, the kernel often ceases to provide all drivers for file systems, further diminishing the role of Linux in the system.
Uninstall GNU or Linux.
Perhaps the most truthful test of the importance of a component of a system is how easy it is to manage without a given component in the system. Some Linux platforms use not many GNU programs; for example, using busybox for command line utilities and uclibc for the standard library. Some GNU platforms such as Nexenta or Debian GNU / kFreeBSD do not use the Linux kernel.
To appreciate the importance of Linux, let's take a look at the Linux compatible environment in FreeBSD. When running Linux programs on FreeBSD, a modified system call handler is installed that calls the FreeBSD kernel functions in response to Linux system calls. This approach allows you to run programs written under Linux, without changing them.
In order for this method to work, a stripped-down version of Linux is often installed in a separate environment. Programs written for Linux will eventually be able to find all the necessary libraries and utilities, including GNU utilities, GNU grep, Bash, and other packages.
What is this talking about? This suggests that if you want to run GNU / Linux program on a different system, then it is easy to do without Linux, but without GNU is not so simple.
Of course, most programs will run successfully without any compatibility mode if you recompile them. In this case, they will not use GNU libc, GNU utilities, or bash. Some programs require a GNU compiler or GNU Make to compile successfully, however, after compilation these programs will no longer require any GNU utilities except:
- C ++ programs that are likely to use GNU libstdc ++.
- programs explicitly using one of many GNU libraries.
So uninstalling GNU from GNU / Linux seems a lot more complicated than uninstalling Linux. PC-BSD or Nexenta is a good desktop OS without a drop of Linux code inside, but with lots of GNU code. Those Linux systems that are not so heavily dependent on GNU code are completely integrated systems whose names are not familiar to users of desktop and server versions of Linux.
So what is it worth saying, Linux, GNU or GNU / Linux? I call GNU because, as a programmer and user, I mostly use the tools developed by GNU. When I port the code from FreeBSD, the problems arise only in the root utilities or in the standard C library. If I wanted to run the same code on HURD or any other GNU system, then I would use the same interfaces.
In general, I prefer to highlight distributions like Fedora or Ubuntu, and not mention GNU or Linux. The system includes a huge amount of code from various sources. The GNU Project and X.org are among the largest code providers, but Ubuntu GNOME / X.Org / GNU / Linux sounds a bit long. And including in the system name such a small and easily removable part as Linux, they act unfairly against many developers whose code is also present in the system.
- translated.by/you/gnu-or-linux/into-ru/trans
Original (English): GNU or Linux? (http://www.informit.com/articles/article.aspx? p = 1339466)