Linux compatible systems. Linux compatibility: is there a problem? Executing DOS Application Programs
26.02.2007 Alexey Grinevich, Denis Markovtsev, Vladimir Rubanov
If you go back to the late 90s and plunge into the world of operating systems of that time, then hardly anyone will doubt the undivided reign of Unix-compatible systems. Everything is on the Unix side - the family of these operating systems is studied at universities, hundreds of thousands of applications have been created for it, it is successfully used in various sectors of the economy, a sea of books and documentation has been written about it. True, you can't buy Unix, but you can buy IBM AIX, BSD, HP-UX, Sun Solaris, etc. This requires additional effort to get a program written for, say, AIX to work on Solaris. The various Unix clones have proven to be poorly compatible. Similar problems exist for Linux today.
To solve the infrastructure problem of poor compatibility between different versions of Unix in 1985, the IEEE began work on a standard that provides portability software... In 1990, the IEEE 1003 standard was released, also called POSIX, which regulated software interfaces(API) and a list of Unix clone commands. However, for the Unix market players, unification has created complex political problems: any decision, any choice between alternatives to reach agreement leads to the fact that the decision of one manufacturer is recognized as "more standard" than that of another. As a result, the standard is replete with ambiguous statements like “in this case, one of two things is possible. alternative options behavior "and white spots like" the standard does not regulate the behavior of the function in this case. " Finally, fragmentation became one of the main reasons for the defeat of the Unix world. The players in this market competed not only with other types of operating systems, but also with each other, introducing private extensions and closed interfaces, limiting the circle possible applications any one clone.
Launched in the early 90s, the Linux operating system, incorporating code from the GNU movement and absorbing the core ideas of Unix, has become a universal compromise through openness and independence. Its code was implemented from scratch, not relying on any implementation, but only on the text of the POSIX standard. As a result, the system turned out to be initially POSIX-compatible, and independence allowed to unite the efforts of various players in the Unix market in the struggle to "return" the lost segment of operating systems for PCs. However, the problem of fragmentation remains relevant for Linux: the presence of competing distributions raises concerns about the likely repetition of the fate of Unix.
At first glance, the very danger of fragmentation looks rather illusory - in fact, there is a common code, most distributions work on the basis of the same kernel, the same libraries, which largely determines compatibility. It would seem that applications should remain functional and compatible between different versions of Linux. But this is not confirmed in practice. Along with the fragmentation of the Linux distribution market in terms of approaches and additional functionality, there are significant imbalances in support by various clones of even widespread and standard applications- different distributions use different versions of the kernel and system libraries (primarily glibc). This leads to the fact that the composition and behavior of the system interfaces provided by the system to applications change from distribution to distribution. In order not to repeat the sad experience of Unix clones, in 1998, within the framework of the specially created organization Free Standards Group (now the Linux Foundation), work began on the LSB standard (Linux Standard Base - "basic family of Linux standards"). Thanks to efforts from the X / Open, IEEE and ISO organizations, which opened the POSIX standard and some of the tests for free access, the foundation was laid for the Linux standardization business.
But what exactly and why should you standardize? Isn't uniform open source in itself a uniform and open standard?
Application compatibility issues
How do the differences between Linux distributions appear in practice, and how serious is the problem? Let's give an example. Five product lines form the basis of IBM's commercial offerings software products: DB2, Websphere, Rational, Tivoli and Lotus. Practice shows that supporting all five lines for one Linux distribution costs millions of dollars annually, which goes to developers and testers responsible for supporting applications for a specific Linux distribution. Consequently, those distributions are supported for which the profit from the sale of products exceeds these millions; in fact, these are only SuSE and Red Hat distributions. This is how a situation of inconsistency arises - what works on some distributions does not run on others.
The situation is quite different for Sun Solaris. First of all, Sun Microsystems guarantees that a program compiled for Solaris 2.6 will run without recompilation and under version 10. The Sun developers go to great lengths to do this; with each code change, a set of more than 2,400 applications of various purposes and composition is run. Moreover, if someone discovers that an application has stopped working because of an incompatibility between Solaris versions, Sun takes the responsibility and expense to correct the inconsistency. In the case of Linux OS, this work was not carried out for a long time, applications and distributions lived their own separate life. The saddest thing is the lack of a universal way to write a program in such a way as to ensure portability. The efforts of the Linux Foundation consortium, representing the interests of the main players in the Linux market, are aimed at solving this problem.
Linux structure
Oftentimes, Linux is just the kernel, but there are many things that the kernel shouldn't do. Working with documents, sending mail, processing XML, rendering windows - there are special libraries for all this, which are included in almost all distributions. These libraries, one way or another, lead to a call to the kernel, but problems and errors can occur not only in the kernel, but also in the libraries themselves.
There is an opinion that if a program stopped working when the Linux distribution (or its version) was changed, then, having the source codes, it is very easy to correct it, and therefore there is no problem with compatibility. Before discussing whether this is so or not, let's first take a look at the structure of the Linux operating system.
A “generalized” model of a Linux-based system is presented in
Fig. 1. System model based on Linux OS
Each specific Linux-system is created for the operation of one or several applications, but the code of the application itself is not enough to extract the service that users need from the hardware - most applications use calls to library functions in their work. The LSB Core 3.1 standard defines the following system libraries: libc, libcrypt, libdl, libm, libpthread, librt, libutil, libpam, libz, libncurses. On modern Linux systems, the interfaces to these system libraries are implemented by the glibc, Linux-PAM, zlib, and ncurses libraries, which actually implement more interfaces than the LSB Core defines.
By the degree of interaction with the Linux kernel, the functions of the system libraries can be classified as follows:
- the function implementation is completely contained in the library, and the kernel is not used (for example, strcpy, tsearch);
- the library implements a trivial wrapper to invoke the appropriate kernel interface (eg read, write);
- the implementation of the function contains both calls to the system interfaces of the kernel (and possibly several different ones), and part of the code in the library itself (for example, pthread_create, pthread_cancel).
Itself Linux kernel contains many exported entry points, but the vast majority of them are internal interfaces for use by modules and subsystems of the kernel itself. Front end contains about 250 functions (version 2.6). Of these, for example, the glibc 2.3.5 library uses 137 in its implementation.
Configurations
Under configuration The system part of the distribution is understood as a combination of the kernel version (including individual patches), versions of system libraries, their build parameters and the architecture on which it all works. On the is an example of a build configuration for two hypothetical distributions that are a combination of component and patch versions. New functionality is added between component versions, and outdated interfaces and functions are removed. So, in this diagram, it is easy to see that since distributions 1 and 2 use different versions of GCC, source compatibility between them is somewhat lost - not everything that was built with gcc 3.4 can be built with gcc 4.0 without modification.
Fig. 2. An example of a build configuration for distributions
Distributions
By the address lwn.net/Distributions/ you can find a list of well-known Linux distributions (at the time of this writing there were 542 of them) open to the general public. It does not include versions made for internal use by individual enthusiasts, as well as by various companies, departments, etc. Under the GNU license, you can take an arbitrary distribution, modify it (at least the components covered by GNU), and redistribute it further.
Distributions can be classified according to a number of characteristics.
- By base manufacturers. For example, Red Hat, Slackware, SuSE, Debian, Asianux, Mandriva, Gentoo are the main branches of the Linux industry. These distributions are not descendants of the others (although there are some historical dependencies between them). They can be considered strategic directions of development in Linux in general. Most of the rest of the distributions clearly belong to one of the aforementioned branches - mainly inheriting from source code and applications and adding specific functionality.
- By localization. In many countries there is a local Linux manufacturer (for example, in Russia, everyone knows the ASP Linux and ALT Linux distributions).
- By application. Distributions for embedded use in mobile devices; unsupported distributions file system; lightweight versions for use in a PDA; portable versions to run from limited media (Linux on floppy, Linux on CD, etc.).
- By specialization. Distributions to support a specific hardware architecture (AlphaLinux with support for Alpha processor architecture, ARM Linux with ARM support, etc.).
Linux build procedure
It may seem that to achieve robustness and compatibility at the level of behavior of the system library interfaces, it is enough that testing is done by the developers of the kernel and libraries, but this is not the case. Already at the level of system library interfaces, there are many dimensions that make almost every Linux system unique in terms of quality. The behavior of interfaces to applications is determined by a combination of libraries, kernel, and hardware. In turn, the kernel and libraries are determined by their version (including official or unofficial patches and modifications) and, very importantly, by the build configuration.
The variety of different components that come with Linux and the many dependencies between them can illustrate how to build a kernel. The Linux From Scratch project contains the sequence of steps required to build a Linux distribution from scratch. Simplified build sequence for LFS distribution Linux version 6.0 looks like this:
1. Binutils-2.15.94.0.2.2 - Pass 1
2. GCC-3.4.3 - Pass 1
3. Linux-Libc-Headers-2.6.11.2
4. Glibc-2.3.4
…
87. util-linux-2.12q
88. Boot Configuration
89. Linux-2.6.11.12 - Kernel
The kernel is built at the very the last step using the previously assembled binary utilities. It is important to consider the versions of the component listed in each item in the list. Replacing one version of a component with another is not always trivial - the assembly of the system may be impossible due to the absence or change of some function, or it may be complicated. Building many components requires additional steps, for example, the instructions for building flex for a given distribution contain a note :
Flex contains several known bugs. These can be fixed with the following patch:
patch -Np1 -i ../flex-2.5.31-debian_fixes-3.patch
The build process includes the assembly of compilation tools, which also undergo significant changes over time. Even basic Linux components are often outdated. Thus, the version of the gcc 4.0.0 compiler is not suitable for building the 2.6.11 kernel (although they are contemporaries) and requires the use of a special patch to eliminate this incompatibility.
Captured by addictions
Fragmentation at the library level is the biggest problem modern world Linux. Frequent release of new versions of Linux libraries is usually considered a good thing and, indeed, this is the only way to quickly apply and test new ideas and make the latest advances in "engineering" available: sometimes dozens of versions of the same library are in widespread use. At the same time, the integral hallmark development of individual components of the Linux OS is its decentralized nature. Often, almost simultaneously released new versions of various components are deliberately incompatible, which means that it is absolutely impossible to provide adequate testing of various combinations of libraries for compatibility and to guarantee stable operation of the system in all possible combinations. As a result, the brunt of the problem falls on the user who decides to install a program or library for which the ability to work in the environment existing on his machine is clearly not guaranteed, and this situation occurs quite often.
The category of problems associated with incompatibility of library versions is called dependency hell ("dependency hell", en.wikipedia.org/wiki/Dependency_hell). What problems can a user encounter when installing a new library in his version of Linux OS? In this case, applications that were running with the previous version may not function correctly because those applications might rely, either explicitly or implicitly, on certain bugs and side effects that were present in the older version. The opposite situation is also quite real, when a new version just contains a new error. But the real problem arises when several different applications must be running on a system that rely heavily on different versions of the same library; it may turn out that joint work these applications are simply not possible. Sometimes it is possible to have multiple versions of the same library on the system, and this is a perfectly safe solution, but this is not recommended at all in the case of the glibc library.
The main evolutionary path to achieving compatibility across Linux distributions is standardization... A mature and well-supported standard will reduce the cost of providing portability for Linux solutions, which will help increase the number of applications for this platform, and hence the popularity of Linux in general. Today, the Linux Standard Base acts as such a "saving" standard.
LSB is the main standard that defines the compatibility requirements for Linux systems. Basic information on this standard has already been published, for example, in a work in which, however, highlighted old version the standard and the role of kernel interfaces was somewhat exaggerated. In reality, the LSB standard does not specify the kernel interfaces, but rather defines higher-level APIs implemented by various libraries. LSB is not trying to be a replacement for existing standards, but rather builds on all the major standards that have already taken root in Linux. It captures versions and subsets of constituent standards to ensure consistency, and complements descriptions for those interfaces that are de facto present in most Linux distributions, but are not included in any existing standards. The main part of the LSB standard is the requirements for system interfaces, which must be supported by all Linux distributions (a kind of "common denominator" of all Linux systems). In this part, the LSB refers heavily to the POSIX standard.
The main difference with LSB is that application developers can target one platform, say LSB 3.1, and this is enough to work on all LSB 3.1 compliant distributions. The same applies for distribution providers: once compliance with LSB 3.1 is achieved, the distribution automatically supports all applications compatible with it. For example, IBM, as part of the Chiphopper initiative, provides hardware solutions running only LSB-compliant distributions. Largely due to the activity of large players, the main distribution vendors have already passed LSB certification or announced their intentions to be certified ( www.linux-foundation.org/en/LSB_Distribution_Status).
Right now, the main weakness of the LSB standard is the lack of tests. There are cases when the interface described in the standard works differently, and nevertheless the system successfully passes certification. This is because the test for this interface simply not, or it is too weak to fully test the functionality of the interface. It is very pertinent to quote Ian Murdoch, the creator of Debian and now the chief technology officer of the Linux Foundation: "An interface standard is known to be as good as a test coverage that verifies compliance with that standard."
The Open Group has opened some of its tests for the POSIX standard for inclusion in the LSB certification test suite. The LSB suite includes free tests of the GNU C ++ Runtime Library Test Suite, tests for libgtk and libxml are adapted. The Linux Foundation is considering a buyout to open and list various paid test suites on the LSB.
They are also engaged in solving this problem in our country. So on the basis of the Institute for System Programming of the Russian Academy of Sciences, the Linux OS Verification Center was created, where an open test suite OLVER is being developed, which is planned to be included in the official LSB tests. The Center and the Linux Foundation signed a cooperation agreement, within the framework of which work continues to improve the test coverage of LSB and a new infrastructure is being developed for the development of this standard.
Conclusion
In order to prevent the fragmentation that has already taken place on the Unix operating system, measures to ensure compatibility of distributions are necessary - at least within some subset of the functionality. Portability of applications within this subset will allow to unite Linux as a single platform and significantly reduce the cost of developing and maintaining applications, which should positively affect their number and the popularity of Linux solutions in general.
Today, the main initiative to ensure portability is the open standard LSB, adopted by the leading manufacturers of distributions (Red Hat, SuSe, Mandriva) and applications (MySQL, RealPlayer, SAP MaxDB). Behind this standard is the powerful Linux Foundation consortium and its active members such as IBM, Intel, HP and Oracle, which allows us to hope for its successful development and widespread implementation in real life. Thus, the LSB standard has laid a solid foundation for a unified, non-fragmented Linux platform that provides portability of applications based on source code, and in binary form.
However, even very good standards remain only good wishes, as long as there are no convenient and reliable ways to check compliance with them. That is why improving the quality of LSB test coverage is one of the most important priorities for the collaboration between the Linux OS Verification Center and the Linux Foundation.
The test suite is based on automatic generation of tests from formal specifications of requirements and corresponding test scenarios using UniTESK technology.
By the end of 2006, the main phase of the project was completed; all project results are published on the Center's website. Now the project is in the stage of supporting and expanding the range of target platforms (combinations of hardware architecture with a specific distribution).
* Flex contains several known bugs. They can be fixed with the following patch ... - eng.
Linux compatibility issues
( 2007-08-15 )
To make a decision as to whether a certain computer can work great under Linux or not, you need to check all its components - video card, sound card, printer, scanner, digital camera and other devices for compatibility with Linux.
Of course, over the past decade, support for various hardware in Linux has noticeably improved and now you have a fairly large chance of buying a computer to run almost any distribution kit on it without any problems. However, there is still some hardware that is not currently supported.
Today, almost all equipment is working well, but you should be wary of equipment that is controlled by programs rather than buttons. Because the programs are most likely written for Windows and sometimes Mac OS X.
Even when the manufacturer declares support for Linux, be very careful. Most likely, you will have to go to the manufacturer's website, where, most likely, you will find not entirely fresh information. A search on the Internet will also not be very useful, because as a result, you will find many pages with outdated or not entirely correct information in your case.
Below is a list of some Internet resources, the information on which is regularly updated and is quite complete and detailed.
Video cards
If you want to check if your video card is supported, start with the X.Org website, there is a list of supported video cards. You can also check the manufacturer's website. This is true, for example, for video cards from NVIDIA and ATI. In addition, there is the Nouveau project, which develops open drivers for NVIDIA cards, and its counterpart, the Avivo project, which develops open drivers for ATI cards. However, none of these projects have released an official release yet.
If you are unsure of which one is better to choose - open source or proprietary - there are several ways to make this choice. First, you can make a choice based on your philosophy, but most likely the choice will be made based on their functionality. The main problem with open source drivers is limited or completely absent support for 3D capabilities, while proprietary drivers are slow and (especially ATI) unstable.
Another option is the policy of the distribution you are using. Commercial distributions like Xandros and Linspire usually have proprietary drivers already included, while Ubuntu uses open source ones. However, Ubuntu also has Restricted Device Manager, which makes it easy to install proprietary drivers on the system. Fedora 7 is one of the first distributions to use Nouveau drivers whenever possible instead of proprietary NVIDIA drivers.
Sound cards
Unfortunately, there is no single site with detailed information, but you can check the list of Linux-compatible cards on the Linux-Sound site. You can also get information from the Linux Audio Developers mailing lists.
Another good source is the Soundcard Matrix on the ALSA project website. If your card is in this matrix and the Notes column is empty, your card is guaranteed to be supported.
Printers
You are guaranteed to work with any printer that supports the Universal PostScript language. However, if you want to get more detailed information start with the Printer Compatibility Database, which is part of the OpenPrinting Project (Formerly LinuxPrinting.org).
The Printer Compatibility Database is an almost ideal source of information on printers. It contains almost all known printers. It sets its own support level for each printer: Good, Mainly, Partially and Paperweight :). The base also describes with which driver what printer how it works, and a detailed description of the settings for full use of the printer. Alternatively, you can choose a printer for your tasks, using part of the same database. All information is based on user reports.
Scanners
If you are using a multifunction printer as your scanner, the printer database can help you (see the previous chapter). However, the main source of scanner compatibility information is the SANE Project Information Retrieval Service, which will help you find suitability information. specific model for use on Linux. If you have any problems, it is best to ask questions on the SANE project forum.
Digital cameras
Modern digital cameras have abandoned the proprietary protocols of the past in favor of the open one - USB, for which Linux support is very high. However, if you still need to make sure that your camera will be supported, refer to the gPhoto project, which has a database of more than nine hundred items. Another source is the Hubert Figuiere database, which contains detailed information not only on camera support, but also on configuring the system to use them.
Wireless adapters
A few years ago, the main gap in device support was modems. These days these are wireless adapters. In addition, the constant release of new models further complicates support. So, for example, two related models can have fundamentally different firmware and accordingly require different drivers.
The only site with information on wireless adapters that is up to date, maintained by Jean Tourrilhes and sponsored by Hewlett-Packard. The information on the site is posted quite chaotically, but if you wish, you can understand it.
If your adapter is not supported, you may be able to start it with, or, for Broadcom adapters,. Both of these projects are actually a wrapper for drivers from Windows or Mac OS X.
The disadvantage of both programs is that you need to use lspci to get the Bus ID of your adapter. Therefore, before you buy something, see how many adapters similar to yours are supported by ndiswrapper.
Laptops and other mobile devices
New hardware is bought from time to time, and of course you want it to work on Linux. It's not that the free community doesn't know how or doesn't want to support devices - experience shows that it can and can. The point is greedy and stupid manufacturers who do not want not only to write drivers for their hardware, but even to open specifications for their devices. Usually, if the hardware does not work in Linux, then such a manufacturer, as a rule, does not deserve attention at all.
This post talks about Linux and Linux hardware installation. Installing hardware on Linux is easy, and below are resources to help you with this.
Where can I find information on Linux device and peripheral compatibility?
http://linux-wless.passys.nl/ - an extended database of WiFi cards for Linux. This is the most complete resource for supporting wireless network cards in Linux, you can look by manufacturers - and if supported, then the name of the driver is immediately given.
http://www.sane-project.org/sane-mfgs.html - a list of Linux scanners that are supported by the SANE subsystem. A list of scanner models that work in Linux, depending on the manufacturer. Compatibility gradations: full support, partial, basic, no support. It also indicates which backend is required for the device to work.
http://openprinting.org/printer_list.cgi - A database of running Linux printers supported by the CUPS printing subsystem, which provides Linux printer drivers for Linux distributions. Easily search by printer model and manufacturer. Compatibility gradations: works, works almost, works limited, ballast.
Databases by device category
http://www.linuxcompatible.org/compatibility.html - A database of all Linux compatible devices from sound cards and ending with printers and scanners. There are gradations of compatibility: it works perfectly, works for the most part, some functions work, ballast. The base is very extensive, from time to time it is updated by the site creators. An excellent resource, anyway.
http://kmuto.jp/debian/hcl/ - base of devices supported by kernels 2.6.15 and higher. We simply copy the output of lspci -n from the console and get information about the support for the hardware located on the motherboard.
http://www.linux-laptop.net/ - the most complete resource about running Linux on laptops. The page contains a classification by manufacturer, further - links by model to specific user pages, telling what and how they did to get the functionality of their laptops. Most of the information is in English, but other languages are also present.
http://start.at/modem - a great resource for supporting such flawed devices as winmodem. It turns out that you can also extract something from this ballast: an impressive list of supported devices is given.
http://www.phoronix.com/lch/ - Custom database of supported devices. It starts to fill up, you can take part in it too. There are RSS feeds for a specific type of piece of iron, and for all at once.
Is a great resource on Linux devices with links to HOWTOs and how to setup. On the page - classification by device type, then - links to how to configure and what problems may arise. There are also links to general information on these devices. Very informative. There is a news feed on the site (new documentation).
http://cdb.suse.de/?LANG=en_UK - list of SuSE Linux compatible devices. Updated database of compatible devices with SuSe Linux. As a rule, these devices work in other distributions too.
http://www.linuxtested.com/ - compatibility and operation of devices by distribution. The site has information on testing devices in the following distributions: SuSE, Redhat / Fedora, TurboLinux, Debian, Mandrake.
http://www.linux.org/hardware/ - Hardware that runs on Linux. The list is incomplete, but it might be useful - there is information about exotic hardware that Linux supports.
http://www.linux-drivers.org/ - Links to many Linux compatibility resources. A large number of links to resources and hardware support in Linux.
http://hardware4linux.info/ - linux-compatible directory hardware, division into categories: "works right out of the box", "works with a modification", "unknown", "works partially" and "does not work". A fairly large and constantly updated database of devices.
http://www.linmodems.org/ - Database of support for perverse devices such as wine modems. In them, all the main activity is shifted to a driver written for you-you-know-which-system. As a result, there are almost no “brains” on the device, just as the manufacturers of such devices do not have them. Through the efforts of free programmers, many of these devices can be made to work on Linux.
The splitting of Linux into multiple distributions is undoubtedly taking place. But let's see if the devil is so terrible, first by answering the question, what is Linux. First of all, it is, of course, the core. And this kernel is being developed within the framework of a single project, gradually accumulating branches and patches of many developers, and no tendency to fragmentation of the system at the kernel level has yet been traced. Further - the complex of the system environment: means of loading and initializing the system; utilities to support kernel functionality; means of supporting user interaction with the system; system-wide libraries; support means graphical interface; package management tools.The system environment, in addition to the bootloader itself, whose functions are exhausted at the start of the system and do not affect further work in any way, also includes a set of system initialization scripts and their configuration files. These sets are specific for each distribution, but any of them provides loading of all the starting services necessary for further work - nothing more is required from them.
Kernel functionality support utilities, user interaction support tools and system-wide libraries - all this is a long-established set of programs (it can be called Base Linux), originating mainly from the GNU project and related to it, almost identical in all common distributions and synchronously updated in them ... So there is no particular fragmentation here either.
The GUI support tools are the X Window System, window managers, and frameworks along with the libraries they are based on. The first is now practically in all Linux distributions(and in most Unix-like systems in general) is represented by a single implementation, Xorg. Of course, there are version differences here, but they only affect the support of additional decorative functions.
The package management tools remain, and here, of course, the specificity of the distributions manifests itself more than in the set of initiation tools. Actually, the very specificity of distributions is determined by the principles of their bundling.
From the “base vendor” perspective, there are only three historically completely original systems: Slackware, Debian, and Red Hat. All the rest are either genetically related to them, or evolved under the influence of one of them (however, you cannot discount the influence of BSD systems). On the other hand, the departure of "clones" from the ancestral distribution is just a matter of time and intensity of development. Who would ever think that Suse comes from Slackware and Mandriva (originally Mandrake) has historically been just Red Hat with KDE as the desktop? On the third side, due to the open development model, all distributions are in a state of constant mutual influence, and it is often impossible to determine the degree of kinship of a descendant with its progenitors, which is directly related to the problem of compatibility.
Separation of OS by application - yes, there is a reason in the selection of distributions general purpose and systems focused on special areas of use. But first, almost any general purpose distribution can be installed and configured for special use. Secondly, this is how all special systems are created. Third, distributions that are initially built for special purposes are often overgrown with attributes such as installers and package management tools, becoming "shared" systems.
In fact, there are only two significant classifying features of differences between distributions: the form of distribution and the means of managing its components. The first of them can be divided into two groups: portable, or portable, and batch. The portable distributions are usually called the Source Based System, which does not seem entirely correct, because they are usually not distributed in the form of source codes. Their main component is a system for obtaining the source code of authoring packages from the Net, building them and incorporating them into the file system of the target machine (a typical example of this is Gentoo with its portage system). In FreeBSD, from where this concept was borrowed, such a system is called ports, which it is advisable to keep as the generic name of all such controls for distribution components. Accordingly, the gcc compiler and accompanying build tools are an integral component of portable distributions. Package distributions are distributed in the form of precompiled binary packages, which can either coincide with the author's packages or be more fractional.
There is no sharp line between portable and packaged distributions. The former in any case contain a precompiled base system, without which it would be impossible for the port system to function. In addition, no one forbids distributing them as binary packages generated by the ports system (this is the main way FreeBSD is distributed). Package distributions often contain either standalone "port-like" systems (Archlinux, CRUX), or their package management tools allow you to completely rebuild the distribution from source (Debian and its clones). Nevertheless, package distributions can be distributed without a compiler and accompanying tools, but they have some kind of package management system as an integral component. Which one depends a lot on the format of the packages: tar-archives compressed with gzip or bzip2; rpm packages and deb packages. Accordingly, package distributions can be divided into three groups, each of which has its own set of low-level utilities for installing them, so using packages of one format in a distribution designed for another usually causes problems. However, there is no insurmountable border, as there are means to convert packages from one format to another, and in addition, many high-level package management systems, originally designed for deb-format packages, successfully adapt to other formats.
Of course, it is not necessary that an arbitrary package converted to a deb-format package will be successfully installed in any deb-oriented distribution - apart from a possible violation of dependencies, this can also be hampered by differences in the file system hierarchy, but this practice is very rarely necessary. In fact, replenishing the distribution with packages, resolving their dependencies, adapting to functioning in the environment of this system, updating versions is the task of the distribution kit builders, with which they quite successfully cope.
Long gone are the days when programs were written with a focus on a particular distribution. Today they are almost always created with the expectation of use in abstract Linux, and even in a Unix-like system in general. In any case, adaptation of applications for a specific distribution kit and for a system is the concern of its builders. Of course, it would be rash to expect the builders of free distributions (as well as from the developers of any free software) to guarantee compatibility, although in practice such a guarantee is the reputation. But distributors of corporate editions of commercial distributions Red Hat, Novell, Mandriva provide such guarantees.
Nevertheless, the problem of compatibility between distributions and application programs exists, but it does not concern open and free software, but proprietary, not available in the source code and therefore cannot be adapted for a specific system by modifying them. The producers of such programs themselves test their products for compatibility only with some distributions and do not guarantee their performance in any other systems. So, until recently, only Red Hat and Suse were certified to work with the Oracle DBMS (now they have added their own Oracle distribution). Major IBM products such as DB2 target Red Hat. However, everything is not so scary here either. First, the absence of a manufacturer's warranty is not at all equivalent to the guaranteed inoperability of its products in other distributions. Secondly, for example, the purpose of creating such clones of Red Hat as Scientific Linux is precisely to achieve full functionality of the parent system, including in terms of compatibility with third party applications... And thirdly, the launch of proprietary programs on systems that seem to be not intended for this is often achievable with the help of special techniques.
Leave your comment!
New hardware is bought from time to time, and of course you want it to work on Linux. It's not that the free community doesn't know how or doesn't want to support devices - experience shows that it can and can. The point is greedy and stupid manufacturers who do not want not only to write drivers for their hardware, but even to open specifications for their devices. Usually, if the hardware does not work in Linux, then such a manufacturer, as a rule, does not deserve attention at all.
This post talks about Linux and Linux hardware installation. Installing hardware on Linux is easy, and below are resources to help you with this.
Where can I find information on Linux device and peripheral compatibility?
http://linux-wless.passys.nl/ - extended base of WiFi cards for Linux.This is the most complete resource for supporting wireless network cards in Linux, you can look at the manufacturers - and if supported, then the name of the driver is immediately given.
http://www.sane-project.org/sane-mfgs.html - a list of Linux scanners that are supported by the SANE subsystem.A list of scanner models that work in Linux, depending on the manufacturer. Compatibility gradations: full support, partial, basic, no support. It also indicates which backend is required for the device to work.
http://openprinting.org/printer_list.cgi - a database of running Linux printers supported by the CUPS printing subsystem, which provides Linux printer drivers inLinux distributions.Easily search by printer model and manufacturer. Compatibility gradations: works, works almost, works limited, ballast.
Databases by device category
http://www.linuxcompatible.org/compatibility.html - a database of all Linux-compatible devices, from sound cards to printers and scanners. There are gradations of compatibility: it works perfectly, works for the most part, some functions work, ballast. The base is very extensive, from time to time it is updated by the site creators. An excellent resource, anyway.
http://kmuto.jp/debian/hcl/ - base of devices supported by kernels 2.6.15 and higher... Just copy the output of lspci -n from the console and get information about the support for the hardware located on the motherboard.
http://www.linux-laptop.net/ - the most complete resource on running Linux on laptops. The page contains a classification by manufacturer, then - links by model to specific user pages, telling what and how they did to get the functionality of their laptops. Most of the information is in English, but other languages are also present.
http://start.at/modem - a great resource for supporting such flawed devices as winmodems... It turns out that you can also extract something from this ballast: an impressive list of supported devices is given.
http://www.phoronix.com/lch/ - custom database of supported devices. It starts to fill up, you can take part in it too. There are RSS feeds for a specific type of piece of iron, and for all at once.
- great resource on Linux devices with links to HOWTOs and "how to set up". On the page - classification by device type, then - links to how to configure and what problems may arise. There are also links to general information on these devices. Very informative. There is a news feed on the site (new documentation).
http://cdb.suse.de/?LANG=en_UK - list of devices compatible with SuSE Linux. Updated database of compatible devices with SuSe Linux. As a rule, these devices work in other distributions too.
http://www.linuxtested.com/ - compatibility and operation of devices for distributions. The site has information on testing devices in the following distributions: SuSE, Redhat / Fedora, TurboLinux, Debian, Mandrake.
http://www.linux.org/hardware/ - hardware running Linux. The list is not complete, but it can be useful - there is information about exotic hardware for which there is support in Linux.
http://www.linux-drivers.org/ - Links to many Linux compatibility resources. A large number of links to resources and hardware support in Linux.
http://hardware4linux.info/ - linux-compatible hardware directory, division into categories: "works right out of the box", "works with a modification", "unknown", "works partially" and "does not work". A fairly large and constantly updated database of devices.
http://www.linmodems.org/ - a database of support for perverse devices such as wine modems. In them, all the main activity is shifted to a driver written for you-you-know-which-system. As a result, there are almost no "brains" on the device, just as the manufacturers of such devices do not have them. Through the efforts of free programmers, many of these devices can be made to work on Linux.
