Verschillen tussen Linux-besturingssysteem en Windows-besturingssysteem. Compatibiliteit met Linux-hardware: zoals Linux met hardware-ondersteuning

Van tijd tot tijd koop je nieuwe apparatuur, en je wilt natuurlijk dat deze op Linux werkt. Het is niet zo dat de vrije gemeenschap geen apparaten kan of wil ondersteunen; de ervaring leert dat dit wel kan en gebeurt. Het punt is dat hebzuchtige en domme fabrikanten niet alleen stuurprogramma's voor hun hardware willen schrijven, maar zelfs de specificaties voor hun apparaten willen openen. Als de hardware niet op Linux draait, is die fabrikant meestal helemaal niet het overwegen waard.

Dit bericht gaat over Linux en het installeren van hardware in Linux. Het installeren van hardware op Linux is eenvoudig en hieronder vindt u bronnen die u hierbij kunnen helpen.


Waar kan ik informatie vinden over de compatibiliteit van apparaten en randapparatuur met Linux?
http://linux-wless.passys.nl/ - uitgebreide database met WiFi-kaarten voor Linux.Dit is het meeste volledige bron voor draadloze ondersteuning netwerkkaarten in Linux kun je op fabrikant zoeken - en als het wordt ondersteund, wordt de naam van het stuurprogramma onmiddellijk vermeld.

http://www.sane-project.org/sane-mfgs.html - lijst met scanners in Linux die worden ondersteund door het SANE-subsysteem.Lijst met scannermodellen die in Linux werken, afhankelijk van de fabrikant. Compatibiliteitsgradaties: volledige ondersteuning, gedeeltelijk, basis, geen ondersteuning. Het geeft ook aan welke backend nodig is om het apparaat te laten werken.

http://openprinting.org/printer_list.cgi - een database met werkende Linux-printers die worden ondersteund door het CUPS-afdruksubsysteem, dat voorziet in Linux-stuurprogramma's voor printers inLinux-distributies. Handig zoeken per printermodel en fabrikant. Gradaties van compatibiliteit: werkt, werkt bijna, werkt in beperkte mate, ballast.

Databases per apparaatcategorie
http://www.linuxcompatibel.org/compatibiliteit.html - database van alle Linux-compatibele apparaten, variërend van geluidskaarten en eindigend met printers en scanners. Er zijn gradaties van compatibiliteit: het werkt perfect, het werkt voor het grootste deel, sommige functies werken, ballast. De database is zeer uitgebreid en wordt van tijd tot tijd bijgewerkt door de makers van de site. Hoe dan ook: een prachtige bron.

http://kmuto.jp/debian/hcl/ - basis van apparaten ondersteund door kernels 2.6.15 en hoger. We kopiëren eenvoudigweg de uitvoer van lspci -n van de console en krijgen informatie over de ondersteuning van de hardware op het moederbord.

http://www.linux-laptop.net/ - de meest uitgebreide bron over Linux-werk op laptops. De pagina biedt een classificatie per fabrikant, gevolgd door links per model specifieke pagina's gebruikers vertellen wat en hoe ze hebben gedaan om de functionaliteit van hun laptop te krijgen. De meeste informatie is in het Engels, maar ook andere talen zijn aanwezig.

http://start.at/modem - een grote hulpbron voor het ondersteunen van defecte apparaten als winmodems. Uit deze ballast blijkt ook nog iets te halen: er is een indrukwekkende lijst met ondersteunde apparaten.

http://www.phoronix.com/lch/ - gebruikersbestand ondersteunde apparaatgegevens. Het begint vol te raken, jij kunt er ook aan meedoen. Er zijn RSS-feeds voor zowel een specifiek type hardware als voor allemaal tegelijk.

- Een prachtige bron op Linux-apparaten met links naar HOWTO's en "hoe in te stellen". Op de pagina staat een indeling per apparaattype, gevolgd door links naar hoe u dit instelt en welke problemen zich kunnen voordoen. Er zijn ook links naar algemene informatie volgens deze apparaten. Zeer informatief. Er is een nieuwsfeed voor de site (nieuwe documentatie).

http://cdb.suse.de/?LANG=en_UK - lijst met apparaten die compatibel zijn met SuSE Linux. Bijgewerkte database compatibele apparaten met SuSe Linux. In de regel werken deze apparaten ook in andere distributies.

http://www.linuxtested.com/ - compatibiliteit en werking van apparaten in verschillende distributies. De site bevat informatie over het testen van apparaten in de volgende distributies: SuSE, Redhat / Fedora, TurboLinux, Debian, Mandrake.

http://www.linux.org/hardware/ - hardware die op Linux draait. De lijst is niet compleet, maar kan nuttig zijn: er is informatie over exotische hardware waarvoor Linux ondersteuning biedt.

http://www.linux-drivers.org/ - Links naar veel bronnen over Linux-compatibiliteit. Grote hoeveelheid links naar bronnen en hardwareondersteuning in Linux.

http://hardware4linux.info/ - Linux-compatibele map hardware , onderverdeeld in categorieën: “werkt direct uit de doos”, “werkt met aanpassingen”, “onbekend”, “werkt gedeeltelijk” en “werkt niet”. Een vrij grote en voortdurend bijgewerkte database met apparaten.

http://www.linmodems.org/ - database over ondersteuning voor kwaadaardige apparaten als Win-modems. Daarin worden alle hoofdactiviteiten overgedragen aan de bestuurder, geschreven voor je-weet-wel-systeem. Als gevolg hiervan zitten er bijna geen ‘hersens’ op het apparaat, net zoals de fabrikanten van dergelijke apparaten die niet hebben. Dankzij de inspanningen van vrije programmeurs kunnen veel van deze apparaten geschikt worden gemaakt voor Linux.

De opsplitsing van Linux in vele distributies vindt ongetwijfeld plaats. Maar laten we eens kijken of “de duivel zo verschrikkelijk is” door eerst de vraag te beantwoorden wat Linux is. Allereerst is dit natuurlijk de kern. En deze kernel wordt ontwikkeld binnen het raamwerk van één enkel project, waarbij geleidelijk vertakkingen en patches van veel ontwikkelaars worden verzameld, en er is nog geen tendens tot fragmentatie van het systeem op kernelniveau waargenomen. Het volgende is een complex van systeemomgeving: middelen voor het laden en initialiseren van het systeem; ondersteuningsprogramma's voor kernelfunctionaliteit; middelen om gebruikersinteractie met het systeem te ondersteunen; systeembrede bibliotheken; ondersteunende hulpmiddelen voor grafische interfaces; pakketbeheertools.

De systeemomgeving omvat, naast de bootloader zelf, waarvan de functies bij het opstarten van het systeem zijn uitgeput en op geen enkele manier het verdere werk beïnvloeden, ook een reeks systeeminitialisatiescripts en hun configuratiebestanden. Deze sets zijn specifiek voor elke distributie, maar elk ervan biedt de download van alles wat daarvoor nodig is verder werk startdiensten - er is niets meer van hen vereist.

Hulpprogramma's voor het ondersteunen van kernelfunctionaliteit, tools voor het ondersteunen van gebruikersinteractie met het systeem en systeembrede bibliotheken - dit alles is een al lang bestaande reeks programma's (het kan Base Linux worden genoemd), voornamelijk afkomstig van het GNU-project en verwante programma's, bijna identiek in alle gangbare distributies en daarin synchroon bijgewerkt. Ook hier is er dus geen sprake van een bijzondere fragmentatie.

GUI-ondersteuning omvat het X Window-systeem, vensterbeheerders en geïntegreerde desktopomgevingen, samen met de bibliotheken waarop ze zijn gebaseerd. De eerste wordt nu in vrijwel alle Linux-distributies (en in de meeste Unix-achtige systemen in het algemeen) vertegenwoordigd door één enkele implementatie: Xorg. Natuurlijk zijn er ook hier versieverschillen, maar deze hebben alleen invloed op de ondersteuning voor extra decoratieve functies.

Wat overblijft zijn de pakketbeheertools, en hier manifesteert de specificiteit van distributies zich uiteraard in grotere mate dan in de set initialisatietools. Eigenlijk wordt de specificiteit van distributiekits bepaald door de principes van hun configuratie.

Vanuit het oogpunt van de "kernfabrikanten" zijn er slechts drie volledig originele historische systemen: Slackware, Debian en Red Hat. De rest is ofwel genetisch verwant, ofwel ontwikkeld onder de invloed van een van hen (hoewel de invloed van BSD-systemen niet buiten beschouwing kan worden gelaten). Aan de andere kant is het vertrek van ‘klonen’ uit de voorouderlijke verspreiding slechts een kwestie van tijd en intensiteit van ontwikkeling. Wie zou nu denken dat Suse uit Slackware komt, en Mandriva (oorspronkelijk Mandrake) historisch gezien gewoon Red Hat was met KDE als desktop? Van de kant van de derde, vanwege open model Tijdens de ontwikkeling bevinden alle distributies zich in een staat van constante wederzijdse beïnvloeding, en het is vaak niet mogelijk om de mate van relatie tussen een afstammeling en zijn voorouders te bepalen, wat rechtstreeks verband houdt met het compatibiliteitsprobleem.

Verdeling van besturingssystemen per toepassing - ja, er is een reden om distributies voor algemene doeleinden en systemen die zich richten op speciale gebruiksgebieden te scheiden. Maar in de eerste plaats kan vrijwel elke algemene distributie worden geïnstalleerd en geconfigureerd speciaal gebruik. Ten tweede is dit precies hoe alles is gemaakt. speciale systemen. Ten derde worden distributies, die aanvankelijk voor speciale doeleinden zijn gemaakt, vaak overwoekerd met attributen als installatieprogramma's en pakketbeheertools, waardoor ze veranderen in systemen voor algemeen gebruik.

In feite zijn er slechts twee belangrijke classificatiekenmerken om distributies te onderscheiden: de vorm van distributie en de manier om de componenten ervan te beheren. Volgens de eerste kunnen twee groepen worden onderscheiden: draagbaar of draagbaar en verpakt. Draagbare distributies worden meestal Source Based System genoemd, wat niet helemaal correct lijkt, omdat ze meestal niet in brontekstvorm worden verspreid. Hun hoofdcomponent is een systeem voor het verkrijgen van broncodes van auteurspakketten van internet, het samenstellen ervan en het opnemen ervan in het bestandssysteem van de doelmachine (een typisch voorbeeld hier is Gentoo met zijn Portage-systeem). In FreeBSD, waar dit concept is ontleend, wordt zo'n systeem ports genoemd, wat raadzaam is om te behouden als de generieke naam voor al dergelijke beheertools voor distributiecomponenten. Dienovereenkomstig zijn de gcc-compiler en de bijbehorende bouwtools een integraal onderdeel van geporteerde distributies. Batchdistributies worden gedistribueerd in de vorm van vooraf gecompileerde binaire pakketten, die kunnen samenvallen met de originele pakketten of meer fractioneel kunnen zijn.

Er is geen scherpe grens tussen draagbare en verpakte distributies. De eerste bevatten in ieder geval voorgecompileerd basissysteem, zonder welke de werking van het havensysteem onmogelijk zou zijn. Bovendien verbiedt niemand de distributie ervan in de vorm van binaire pakketten die door het ports-systeem worden gegenereerd (dit is de belangrijkste manier om FreeBSD te distribueren). Pakketdistributies bevatten vaak onafhankelijke “poortachtige” systemen (Archlinux, CRUX), of hun pakketbeheertools stellen u in staat de distributie volledig opnieuw op te bouwen vanaf de broncode (Debian en zijn klonen). Verpakte distributies kunnen echter zonder compiler worden gedistribueerd bijbehorende gereedschappen Ze hebben echter een soort pakketbeheersysteem als integraal onderdeel. Welke hangt grotendeels af van het formaat van de pakketten: tar-archieven gecomprimeerd met gzip of bzip2; rpm-pakketten en deb-pakketten. In overeenstemming hiermee kunnen verpakte distributies worden onderverdeeld in drie groepen, die elk hun eigen set hebben nutsvoorzieningen op laag niveau om ze te installeren, dus het gebruik van pakketten van het ene formaat in een distributie die voor een ander formaat is ontworpen, veroorzaakt meestal problemen. Dit is echter geen onoverkomelijke grens, aangezien er tools bestaan ​​om pakketten van het ene formaat naar het andere te converteren, en veel pakketbeheersystemen op hoog niveau die oorspronkelijk voor deb-pakketten zijn ontworpen, zijn met succes aangepast aan andere formaten.

Het is uiteraard niet nodig dat een willekeurig pakket dat is geconverteerd naar een deb-formaatpakket met succes wordt geïnstalleerd op een deb-georiënteerde distributie - naast mogelijke schendingen van de afhankelijkheid kunnen verschillen in de hiërarchie van het bestandssysteem dit ook voorkomen, maar de noodzaak voor een dergelijke praktijk komt zeer zelden voor. In feite is het aanvullen van de distributie met pakketten, het oplossen van hun afhankelijkheden, het aanpassen aan het functioneren in de omgeving van een bepaald systeem en het bijwerken van versies de taak van distributiebouwers, waarmee ze redelijk succesvol omgaan.

De tijd dat programma's werden geschreven met de focus op een specifieke distributie is al lang voorbij. Tegenwoordig worden ze bijna altijd gemaakt voor gebruik in abstracte Linux, of zelfs in een Unix-achtig systeem in het algemeen. In ieder geval is het aanpassen van applicaties voor een specifieke distributie en systeem de zorg van de assembleurs. Natuurlijk zou het roekeloos zijn om compatibiliteitsgaranties te verwachten van de assembleurs van vrij verspreide distributies (en ook van de ontwikkelaars van welke vrije software dan ook), hoewel deze garantie in de praktijk een reputatie is. Maar distributeurs van bedrijfsedities van commerciële distributies Red Hat, Novell en Mandriva bieden dergelijke garanties.

Het probleem van compatibiliteit tussen distributies en applicatieprogramma's bestaat, maar het gaat niet om open en vrije software, maar om propriëtaire software die niet in de broncode beschikbaar is en dus niet door aanpassing aan een specifiek systeem kan worden aangepast. De fabrikanten van dergelijke programma's testen hun producten zelf alleen op compatibiliteit met bepaalde distributies en garanderen hun prestaties op andere systemen niet. Tot voor kort waren dus alleen Red Hat en Suse gecertificeerd om met het Oracle DBMS te werken (nu is de “eigen” distributie van Oracle daaraan toegevoegd). De kernproducten van IBM, zoals DB2, zijn gericht op Red Hat. Maar ook hier is alles niet zo eng. Ten eerste is het ontbreken van een fabrieksgarantie helemaal niet gelijkwaardig aan de gegarandeerde onbruikbaarheid van zijn producten in andere distributies. Ten tweede is het doel van het maken van Red Hat-klonen als Scientific Linux bijvoorbeeld precies om dit te bereiken volledige functionaliteit oudersysteem, ook vanuit het oogpunt van compatibiliteit met applicaties van derden. En ten derde is het vaak mogelijk om propriëtaire programma's te draaien op systemen die hier niet voor ontworpen lijken te zijn, met behulp van speciale technieken.

Laat je reactie achter!

26.02.2007 Alexey Grinevich, Denis Markovtsev, Vladimir Rubanov

Als je teruggaat naar eind jaren 90 en je in de wereld stort besturingssystemen van die tijd zou bijna niemand twijfelen aan de onverdeelde heerschappij van Unix-compatibele systemen. Alles staat aan de kant van Unix - de familie van deze besturingssystemen wordt bestudeerd aan universiteiten, er zijn honderdduizenden applicaties voor gemaakt, het wordt met succes gebruikt in verschillende sectoren van de economie, er zijn veel boeken en documentatie geschreven erover. Het is waar dat je Unix niet kunt kopen, maar je kunt wel IBM AIX, BSD, HP-UX, Sun Solaris, enz. kopen. Tegelijkertijd zijn er extra inspanningen nodig om een ​​programma dat bijvoorbeeld voor AIX is gemaakt, onder Solaris te laten werken. Verschillende Unix-klonen bleken slecht compatibel. Soortgelijke problemen bestaan ​​tegenwoordig voor het Linux-besturingssysteem.

Om het infrastructuurprobleem van slechte compatibiliteit tussen verschillende versies van Unix op te lossen, begon IEEE in 1985 te werken aan een standaard om de draagbaarheid van software te garanderen. In 1990 werd de IEEE 1003-standaard, ook wel POSIX genoemd, uitgebracht, die programma-interfaces (API's) en een lijst met opdrachten voor Unix-klonen regelde. Voor spelers op de Unix-markt heeft de eenwording echter tot complexe politieke problemen geleid: elke beslissing, elke keuze tussen alternatieve opties om tot overeenstemming te komen, leidt ertoe dat de oplossing van de ene leverancier als “meer standaard” wordt beschouwd dan de andere. Als gevolg hiervan staat de standaard vol met dubbelzinnige uitspraken als “in in dit geval een van de twee alternatieve gedragsopties is mogelijk” en witte vlekken zoals “de standaard reguleert het gedrag van de functie in dit geval niet.” Op het einde, fragmentatie werd een van de belangrijkste redenen voor de nederlaag van de Unix-wereld. Spelers op deze markt concurreerden niet alleen met andere soorten besturingssystemen, maar ook met elkaar, waarbij eigen extensies en gesloten interfaces werden geïntroduceerd, waardoor het bereik van de besturingssystemen werd beperkt. mogelijke toepassingen welke kloon dan ook.

Het Linux-besturingssysteem, dat begin jaren negentig verscheen, bevatte code die binnen de GNU-beweging was gemaakt en absorbeerde de belangrijkste ideeën van Unix, dankzij zijn openheid en onafhankelijkheid, en werd een universeel compromis. De code werd helemaal opnieuw geïmplementeerd en vertrouwde niet op enige implementatie, maar alleen op de tekst POSIX-standaard. Als gevolg hiervan bleek het systeem vanaf het begin POSIX-compatibel te zijn, en zijn onafhankelijkheid maakte het mogelijk om de inspanningen van verschillende Unix-marktspelers te combineren in de strijd om het verloren segment van pc-besturingssystemen terug te geven. Het probleem van fragmentatie blijft echter relevant voor Linux: de aanwezigheid van concurrerende distributies roept zorgen op over de waarschijnlijke herhaling van het lot van Unix.

Op het eerste gezicht lijkt het gevaar van fragmentatie zelf nogal illusoir - sterker nog, er is een gemeenschappelijke code, de meeste distributies werken op basis van dezelfde kernel, dezelfde bibliotheken, die grotendeels de compatibiliteit bepalen. Het lijkt erop dat applicaties functioneel en compatibel moeten blijven tussen verschillende versies van Linux. Maar dit wordt in de praktijk niet bevestigd. Samen met de fragmentatie van de Linux-distributiemarkt volgens benaderingen en extra functionaliteit, er zijn aanzienlijke onevenwichtigheden in de ondersteuning van verschillende klonen, zelfs voor gewone en standaard toepassingen- gebruikt in verschillende distributies verschillende versies kernels en systeembibliotheken(voornamelijk glibc). Dit leidt ertoe dat de samenstelling en het gedrag van de systeeminterfaces die door het systeem aan applicaties worden geleverd, veranderen van distributie tot distributie. Om de trieste ervaring met Unix-klonen niet te herhalen, begon in 1998, binnen het raamwerk van een speciaal opgerichte organisatie Free Standards Group (nu de Linux Foundation), te werken aan de LSB-standaard (Linux Standard Base - “de basisfamilie van Linux normen”). Dankzij de inspanningen van de X/Open-, IEEE- en ISO-organisaties, die de POSIX-standaard en enkele tests openstelden voor vrije toegang, werd de basis gelegd voor de standaardisatie van Linux.

Maar wat moet er precies worden gestandaardiseerd en waarom? Is het echt hetzelfde open bron is op zichzelf niet een uniforme en open standaard?

Compatibiliteitsproblemen met applicaties

Hoe zijn de verschillen tussen Linux-distributies in de praktijk en hoe ernstig is het probleem? Laten we een voorbeeld geven. Het commerciële aanbod van IBM is gebaseerd op vijf productlijnen softwareproducten: DB2, Websphere, Rational, Tivoli en Lotus. De praktijk leert dat het ondersteunen van alle vijf de lijnen voor één Linux-distributie jaarlijks miljoenen dollars kost, die naar ontwikkelaars en testers gaan die verantwoordelijk zijn voor het ondersteunen van applicaties voor een specifieke Linux-distributie. Bijgevolg worden die uitkeringen ondersteund waarvoor de winst uit de verkoop van producten deze miljoenen overschrijdt; in feite zijn dit alleen distributies van SuSE en Red Hat. Dit creëert een situatie van inconsistentie: wat op sommige distributies werkt, werkt niet op andere.

Een geheel andere situatie wordt waargenomen voor Sun Solaris. Allereerst garandeert Sun Microsystems dat een programma dat voor Solaris 2.6 is gecompileerd, zonder hercompilatie en onder versie 10 zal werken. De ontwikkelaars van Sun doen grote inspanningen om dit te bereiken; Elke keer dat de code verandert, worden er meer dan 2400 applicaties uitgevoerd voor verschillende doeleinden en compositie. Bovendien, als iemand ontdekt dat een applicatie niet meer werkt vanwege incompatibiliteit tussen Solaris-versies, neemt Sun de verantwoordelijkheid en de kosten voor het corrigeren van de inconsistentie op zich. In het geval van Linux OS werkt dit voor een lange tijd niet werd gehandhaafd, leefden applicaties en distributies hun eigen, gescheiden leven. Het treurigste hieraan is het ontbreken van een universele manier om een ​​programma zo te schrijven dat portabiliteit gegarandeerd is. De inspanningen van het Linux Foundation-consortium, dat de belangen behartigt van de belangrijkste spelers op de Linux-markt, zijn erop gericht dit probleem op te lossen.

Linux-structuur

Linux wordt vaak alleen maar de kernel genoemd, maar er zijn veel dingen die een kernel niet zou moeten doen. Werken met documenten, e-mail verzenden, XML verwerken, vensters tekenen - voor dit alles zijn er in bijna alle distributies speciale bibliotheken opgenomen. Deze bibliotheken leiden op de een of andere manier tot een aanroep van de kernel, maar problemen en fouten kunnen niet alleen in de kernel voorkomen, maar ook in de bibliotheken zelf.

Er is een mening dat als een programma stopt met werken bij het wijzigen van de Linux-distributie (of de versie ervan), het met de broncodes heel gemakkelijk te corrigeren is en daarom zijn er geen compatibiliteitsproblemen. Voordat we bespreken of dit waar is of niet, laten we eerst eens kijken naar de structuur van het Linux-besturingssysteem.

"Gegeneraliseerd" model van het systeem ingeschakeld Linux-gebaseerd gepresenteerd op

Rijst. 1. Systeemmodel gebaseerd op Linux OS

Elk specifiek Linux-systeem is gemaakt om een ​​of meer applicaties uit te voeren, maar de applicatiecode zelf is niet voldoende om de service die gebruikers nodig hebben uit de hardware te halen - de meeste applicaties gebruiken in hun werk oproepen naar bibliotheekfuncties. De LSB Core 3.1-standaard definieert de volgende systeembibliotheken: libc, libcrypt, libdl, libm, libpthread, librt, libutil, libpam, libz, libncurses. Op moderne Linux-systemen worden de interfaces naar deze systeembibliotheken geïmplementeerd door de glibc-, Linux-PAM-, zlib- en ncurses-bibliotheken, die daadwerkelijk implementeren meer interfaces dan gedefinieerd in LSB Core.

Op basis van de mate van interactie met de Linux-kernel kunnen de functies van systeembibliotheken als volgt worden geclassificeerd:

  • de implementatie van de functie is volledig opgenomen in de bibliotheek en de kernel wordt niet gebruikt (bijvoorbeeld strcpy, tsearch);
  • de bibliotheek implementeert een triviale “wrapper” voor het aanroepen van de corresponderende kernelinterface (bijvoorbeeld lezen, schrijven);
  • De implementatie van de functie bevat zowel aanroepen naar de kernelsysteeminterfaces (en mogelijk meerdere verschillende) als een deel van de code in de bibliotheek zelf (bijvoorbeeld pthread_create, pthread_cancel).

De Linux-kernel zelf bevat veel exporteerbare toegangspunten, maar de overgrote meerderheid daarvan is dat wel interne interface voor gebruik door modules en subsystemen van de kernel zelf. De externe interface bevat ongeveer 250 functies (versie 2.6). Hiervan gebruikt de glibc 2.3.5-bibliotheek er bijvoorbeeld 137 bij de implementatie ervan.

Configuraties

Onder configuratie Het systeemgedeelte van de distributie wordt opgevat als een combinatie van de kernelversie (inclusief individuele patches), versies van systeembibliotheken, hun buildparameters en de architectuur waarop het allemaal werkt. Op Er wordt een voorbeeld gegeven van de assemblageconfiguratie van twee hypothetische distributies, die een verzameling versies van componenten en patches zijn. Tussen versies van componenten worden nieuwe functionaliteit toegevoegd en verouderde interfaces en functies verwijderd. In dit diagram is het dus gemakkelijk te zien dat aangezien distributies 1 en 2 verschillende versies van GCC gebruiken, de broncodecompatibiliteit tussen beide gedeeltelijk verloren gaat - niet alles dat is gecompileerd met gcc 3.4 kan zonder aanpassingen worden gecompileerd met gcc 4.0.

Rijst. 2. Voorbeeld van configuratie van distributieopbouw

Uitkeringen

Op adres lwn.net/Distributies/ je kunt een lijst vinden bekende distributies Linux (er waren er 542 op het moment van schrijven), open voor het grote publiek. Hierbij is geen rekening gehouden met versies gemaakt voor intern gebruik door individuele liefhebbers, maar ook door diverse bedrijven, afdelingen etc. Volgens GNU-licenties, kun je een willekeurige distributie nemen, er wijzigingen in aanbrengen (tenminste aan componenten die onder GNU vallen) en verder distribueren.

Uitkeringen kunnen worden geclassificeerd op basis van een aantal criteria.

  • Door basisfabrikanten. Red Hat, Slackware, SuSE, Debian, Asianux, Mandriva en Gentoo vertegenwoordigen bijvoorbeeld de belangrijkste “takken” van de Linux-industrie. Deze verdelingen zijn geen afstammelingen van de andere (hoewel er wel enkele historische afhankelijkheden tussen bestaan). Ze kunnen worden beschouwd als strategische richtingen voor de ontwikkeling van Linux in het algemeen. De meeste van de overige distributies behoren duidelijk tot een van de genoemde takken - waarbij de meeste de broncode en applicaties overnemen en specifieke functionaliteit toevoegen.
  • Door lokalisatie. In veel landen is er een lokale Linux-fabrikant (in Rusland kent bijvoorbeeld iedereen de ASP Linux- en ALT Linux-distributies).
  • Per toepassing. Distributies voor ingebed gebruik in mobiele apparaten; distributies die werken zonder ondersteuning voor bestandssystemen; lichtgewicht versies voor gebruik in PDA's; draagbare versies voor gebruik vanaf beperkte media (Linux op een diskette, Linux op een cd, enz.).
  • Door specialisatie. Distributies ter ondersteuning van een specifieke hardwarearchitectuur (AlphaLinux met ondersteuning voor Alpha-processorarchitectuur, ARM Linux met ondersteuning voor ARM, enz.).

Linux-buildprocedure

Het lijkt misschien dat om betrouwbaarheid en compatibiliteit op het gedragsniveau van systeembibliotheekinterfaces te bereiken, het voldoende is dat de ontwikkelaars van de kernel en bibliotheken testen uitvoeren, maar dat is niet zo. Al op het niveau van systeembibliotheekinterfaces zijn er veel dimensies die bijna elk Linux-systeem uniek maken in termen van kwaliteit. Het gedrag van applicatie-interfaces wordt bepaald door een combinatie van bibliotheken, kernel en hardware. De kernel en bibliotheken worden op hun beurt bepaald door hun versie (inclusief officiële of niet-officiële patches en aanpassingen) en, heel belangrijk, door de build-configuratie.

De verscheidenheid aan verschillende componenten in Linux en de vele afhankelijkheden daartussen kunnen worden geïllustreerd aan de hand van de procedure voor het bouwen van een kernel. Het Linux From Scratch-project bevat de reeks stappen die nodig zijn om een ​​Linux-distributie helemaal opnieuw op te bouwen. De vereenvoudigde montagevolgorde voor de LFS Linux-distributieversie 6.0 ziet er als volgt uit:

1. Binutils-2.15.94.0.2.2 - Pass 1
2. GCC-3.4.3 - Voldoen aan 1
3. Linux-Libc-Headers-2.6.11.2
4. Glibc-2.3.4

87.Util-linux-2.12q
88. Opstartconfiguratie
89. Linux-2.6.11.12 - Kernel

De kernel wordt in de allerlaatste stap samengesteld met behulp van de eerder samengestelde binaire hulpprogramma's. Het is belangrijk om rekening te houden met de versies van de component die in elk lijstelement worden vermeld. Het vervangen van de ene versie van een component door een andere is niet altijd triviaal; het assembleren van het systeem kan onmogelijk zijn vanwege het ontbreken of veranderen van een functie, of het kan ingewikkeld zijn. De montage van veel componenten vereist aanvullende acties De instructies voor het samenstellen van flex voor deze distributie bevatten bijvoorbeeld een opmerking :

Flex bevat verschillende bekende bugs. Deze kunnen worden gerepareerd met de volgende patch:
patch -Np1 -i ../flex-2.5.31-debian_fixes-3.patch

Het assemblageproces omvat de assemblage van compilatietools, die in de loop van de tijd ook aanzienlijke veranderingen ondergaan. Zelfs elementaire Linux-componenten zijn vaak verouderd. De compilerversie gcc 4.0.0 is dus niet geschikt voor het bouwen van kernel 2.6.11 (hoewel het tijdgenoten zijn) en vereist het gebruik van een speciale patch om deze incompatibiliteit te elimineren.

Gevangen door verslavingen

Fragmentatie op bibliotheekniveau is een groot probleem in de moderne Linux-wereld. Het veelvuldig uitbrengen van nieuwe versies van Linux-bibliotheken wordt doorgaans als een goede zaak beschouwd en dit is inderdaad de enige manier om snel nieuwe ideeën toe te passen en te testen en de nieuwste verworvenheden van de “engineering” beschikbaar te maken: wijdverbreid gebruik soms zijn er tientallen versies van dezelfde bibliotheek. Tegelijkertijd is het een integraal onderscheidend kenmerk van de ontwikkeling individuele componenten Linux OS is zijn gedecentraliseerde karakter. Vaak verschijnen er vrijwel gelijktijdig nieuwe versies diverse componenten zijn duidelijk incompatibel, wat betekent dat het volkomen onmogelijk is om te garanderen dat verschillende combinaties van bibliotheken adequaat worden getest op compatibiliteit en garantie stabiel werk systemen voor iedereen mogelijke combinaties. Als gevolg hiervan valt de volledige last van de problemen op de gebruiker die besluit een programma of bibliotheek te installeren waarvan duidelijk niet gegarandeerd is dat deze werkt in de omgeving die op zijn machine aanwezig is, en deze situatie komt vrij vaak voor.

De categorie problemen die verband houdt met de incompatibiliteit van bibliotheekversies wordt de afhankelijkheidshel genoemd. en.wikipedia.org/wiki/Dependency_hell). Welke problemen kan een gebruiker tegenkomen als hij een soort Linux-besturingssysteem in zijn versie installeert? nieuwe bibliotheek? In dit geval functioneren applicaties die de vorige versie draaiden mogelijk niet meer correct omdat deze applicaties mogelijk expliciet of impliciet afhankelijk waren van bepaalde bugs en bijwerkingen, aanwezig in de oude versie. Ook behoorlijk reëel omgekeerde situatie wanneer de nieuwe versie eenvoudigweg bevat nieuwe fout. Maar het echte probleem komt wanneer het systeem meerdere systemen moet draaien diverse toepassingen, die sterk afhankelijk zijn van verschillende versies van dezelfde bibliotheek; Het kan blijken dat het simpelweg onmogelijk is dat deze applicaties samenwerken. Soms is het mogelijk om meerdere versies van dezelfde bibliotheek op het systeem te hebben, en dit zal behoorlijk zijn veilige oplossing, dit wordt echter helemaal niet aanbevolen in het geval van de glibc-bibliotheek.

Het belangrijkste evolutionaire pad naar het bereiken van compatibiliteit tussen verschillende Linux-distributies is standaardisatie. Een volwassen en volledig ondersteunde standaard zal de kosten van het garanderen van de draagbaarheid van Linux-oplossingen verlagen, wat zal bijdragen aan de groei van het aantal applicaties voor dit platform, en daarmee aan de populariteit van Linux in het algemeen. Tegenwoordig fungeert Linux Standard Base als een dergelijke “besparende” standaard.

LSB is de belangrijkste standaard die compatibiliteitsvereisten voor Linux-systemen definieert. Basisinformatie over deze standaard is bijvoorbeeld al gepubliceerd in het werk, dat echter wel gedekt is oude versie standaard en de rol van kernelinterfaces werd enigszins overdreven. In werkelijkheid specificeert de LSB-standaard geen kernelinterfaces, maar definieert hij applicatie-interfaces op een hoger niveau die door verschillende bibliotheken zijn geïmplementeerd. LSB probeert geen vervanging te zijn voor bestaande standaarden, maar bouwt eerder voort op alle belangrijke standaarden die al wortel hebben geschoten in Linux. Het legt versies en subsets van componentstandaarden vast om consistentie te garanderen, en vormt een aanvulling op de beschrijvingen van die interfaces die de facto aanwezig zijn in de meeste Linux-distributies, maar in geen enkele distributie zijn opgenomen. bestaande normen. Het grootste deel van de LSB-standaard bestaat uit eisen voor systeeminterfaces die door alle Linux-distributies moeten worden ondersteund (een soort “gemene deler” van alle Linux-systemen). In dit deel verwijst LSB zwaar naar de POSIX-standaard.

Het belangrijkste verschil met LSB is dat applicatieontwikkelaars zich op één platform kunnen richten, bijvoorbeeld LSB 3.1, en dit zal voldoende zijn om op alle LSB 3.1-compatibele distributies te werken. Hetzelfde geldt voor distributieaanbieders: zodra de naleving van LSB 3.1 is bereikt, ondersteunt de distributie automatisch alle applicaties die ermee compatibel zijn. IBM levert bijvoorbeeld, als onderdeel van het Chiphopper-initiatief, hardwareoplossingen die alleen LSB-compatibele distributies draaien. Grotendeels dankzij de activiteit van grote spelers hebben grote distributieaanbieders al de LSB-certificering behaald of hun voornemen aangekondigd om gecertificeerd te worden ( www.linux-foundation.org/en/LSB_Distribution_Status).

Momenteel is de belangrijkste zwakte van de LSB-standaard het gebrek aan tests. Er zijn gevallen waarin de in de standaard beschreven interface anders werkt, en toch slaagt het systeem met succes voor de certificering. Dit wordt verklaard door het feit dat de test voor deze interface simpelweg niet, of het is te zwak om de functionaliteit van de interface volledig te testen. Het is zeer passend om de uitspraak van Ian Murdoch, de schepper van Debian en vandaag de dag hoofd technologie van de Linux Foundation, te citeren: “Het is bekend dat een interfacestandaard slechts zo goed is als de testdekking die de naleving van die standaard verifieert. ”

De Open Group heeft een aantal van zijn POSIX-tests opengesteld voor opname in de LSB-certificeringstestsuite. De LSB-set bevat gratis tests van de standaard GNU C++ Runtime Library Test Suite, tests aangepast voor libgtk en libxml. De Linux Foundation overweegt een uitkoop om verschillende betaalde testsuites te openen en op te nemen in de LSB.

Ook in ons land zijn ze bezig dit probleem op te lossen. Zo werd op basis van het Instituut voor Systeemprogrammering van de Russische Academie van Wetenschappen het Linux OS Verificatiecentrum gecreëerd, waar de open testsuite OLVER wordt ontwikkeld, die naar verwachting zal worden opgenomen in de officiële LSB-tests. Er is een samenwerkingsovereenkomst gesloten tussen het Centrum en de Linux Foundation, in het kader waarvan wordt gewerkt aan het verbeteren van de LSB-testdekking en de ontwikkeling van een nieuwe infrastructuur voor de ontwikkeling van deze standaard aan de gang is.

Conclusie

Om de fragmentatie die al heeft plaatsgevonden met het Unix-besturingssysteem te voorkomen, zijn maatregelen nodig om de compatibiliteit tussen distributies te garanderen – door ten minste, binnen een bepaalde subset van functionaliteit. De overdraagbaarheid van applicaties binnen deze subset zal het mogelijk maken om Linux als één enkel platform te verenigen en de kosten voor het ontwikkelen en ondersteunen van applicaties aanzienlijk te verlagen, wat een positieve invloed zou moeten hebben op hun aantal en de populariteit van Linux-oplossingen in het algemeen.

Tegenwoordig is het belangrijkste portabiliteitsinitiatief de open LSB-standaard, overgenomen door toonaangevende distributie- (Red Hat, SuSe, Mandriva) en applicatiefabrikanten (MySQL, RealPlayer, SAP MaxDB). Achter deze standaard staat het krachtige Linux Foundation-consortium en zijn actieve leden zoals IBM, Intel, HP en Oracle, waardoor we kunnen hopen op de succesvolle ontwikkeling en wijdverspreide implementatie ervan in echte leven. Zo is in de vorm van de LSB-standaard een betrouwbare basis gelegd voor één enkel, ongefragmenteerd Linux-platform dat de portabiliteit van applicaties zowel op basis van broncode als in binaire vorm garandeert.

Maar zelfs zeer goede normen blijven slechts goede wensen, zolang er geen gemakkelijke en betrouwbare manieren zijn om de naleving ervan te verifiëren. Daarom is het verbeteren van de kwaliteit van de LSB-testdekking een van de belangrijkste prioriteiten van de samenwerking tussen het Linux OS Verification Center en de Linux Foundation.

  • het opsporen van onnauwkeurigheden en fouten in de tekst van de LSB en gerelateerde standaarden en het rapporteren ervan aan de oorspronkelijke ontwikkelaars voor wijzigingen in toekomstige versies;
  • ontwikkeling van formele specificaties in de SeC-taal (specificatie-uitbreiding van de C-taal), die de vereisten van de LSB Core 3.1-standaard voor 1530-interface zullen weerspiegelen Linux-functies;
  • ontwikkeling van open testsuites voor het functioneel testen van verschillende Linux-systemen op naleving van de vereisten van de LSB Core 3.1-standaard (het gedrag van de programmeerinterfaces van Linux-systeemapplicaties wordt gecontroleerd).
  • De testsuite is gebaseerd op het automatisch genereren van tests op basis van formele eisenspecificaties en bijbehorende testgevallen met behulp van UniTESK-technologie.

    Eind 2006 was de hoofdfase van het project afgerond; alle resultaten van het project worden gepubliceerd op de website van het Centrum. Het project bevindt zich momenteel in de fase van ondersteuning en uitbreiding van het spectrum doelplatforms(combinaties van hardware-architectuur met een specifieke distributie).

    * Flex bevat verschillende bekende bugs. Ze kunnen worden opgelost met de volgende patch...



    Van tijd tot tijd koop je nieuwe apparatuur, en je wilt natuurlijk dat deze op Linux werkt. Het is niet zo dat de vrije gemeenschap geen apparaten kan of wil ondersteunen; de ervaring leert dat dit wel kan en gebeurt. Het punt is dat hebzuchtige en domme fabrikanten niet alleen stuurprogramma's voor hun hardware willen schrijven, maar zelfs de specificaties voor hun apparaten willen openen. Als de hardware niet op Linux draait, is die fabrikant meestal helemaal niet het overwegen waard.

    Dit bericht gaat over Linux en het installeren van hardware in Linux. Het installeren van hardware op Linux is eenvoudig en hieronder vindt u bronnen die u hierbij kunnen helpen.

    Waar kan ik informatie vinden over de compatibiliteit van apparaten en randapparatuur met Linux?
    http://linux-wless.passys.nl/ - een uitgebreide database met WiFi-kaarten voor Linux Dit is de meest complete bron voor het ondersteunen van draadloze netwerkkaarten in Linux, je kunt zoeken op fabrikant - en als deze wordt ondersteund, de naam van de bestuurder wordt onmiddellijk gegeven.

    http://www.sane-project.org/sane-mfgs.html - lijst met scanners in Linux die worden ondersteund door het SANE-subsysteem. Lijst met scannermodellen die in Linux werken, afhankelijk van de fabrikant. Compatibiliteitsgradaties: volledige ondersteuning, gedeeltelijk, basis, geen ondersteuning. Het geeft ook aan welke backend nodig is om het apparaat te laten werken.

    http://openprinting.org/printer_list.cgi - een database met werkende Linux-printers die worden ondersteund door het CUPS-afdruksubsysteem, dat Linux-stuurprogramma's biedt voor printers in Linux-distributies. Handig zoeken op printermodellen en fabrikant. Gradaties van compatibiliteit: werkt, werkt bijna, werkt in beperkte mate, ballast.

    Databases per apparaatcategorie
    http://www.linuxcompatibel.org/compatibility.html - een database van alle Linux-compatibele apparaten, van geluidskaarten tot printers en scanners. Er zijn gradaties van compatibiliteit: het werkt perfect, het werkt voor het grootste deel, sommige functies werken, ballast. De database is zeer uitgebreid en wordt van tijd tot tijd bijgewerkt door de makers van de site. Hoe dan ook: een prachtige bron.

    http://kmuto.jp/debian/hcl/ - database met apparaten die worden ondersteund door kernels 2.6.15 en hoger. We kopiëren eenvoudigweg de uitvoer van lspci -n van de console en krijgen informatie over de ondersteuning van de hardware op het moederbord.

    http://www.linux-laptop.net/ is de meest uitgebreide bron over het draaien van Linux op laptops. De pagina bevat een classificatie per fabrikant, gevolgd door links per model naar specifieke pagina's van gebruikers die vertellen wat en hoe ze hebben gedaan om de functionaliteit van hun laptops te krijgen. De meeste informatie is in het Engels, maar ook andere talen zijn aanwezig.

    http://start.at/modem is een geweldige bron voor het ondersteunen van defecte apparaten zoals winmodems. Uit deze ballast blijkt ook nog iets te halen: er is een indrukwekkende lijst met ondersteunde apparaten.

    http://www.phoronix.com/lch/ - gebruikersdatabase van ondersteunde apparaten. Het begint vol te raken, jij kunt er ook aan meedoen. Er zijn RSS-feeds voor zowel een specifiek type hardware als voor allemaal tegelijk.

    - Een prachtige bron op Linux-apparaten met links naar HOWTO's en "hoe in te stellen". Op de pagina staat een indeling per apparaattype, daarna staan ​​links hoe je dit instelt en welke problemen er kunnen optreden. Er zijn ook links naar algemene informatie over deze apparaten. Zeer informatief. Er is een nieuwsfeed voor de site (nieuwe documentatie).

    http://cdb.suse.de/?LANG=en_UK - lijst met apparaten die compatibel zijn met SuSE Linux. Bijgewerkte database met apparaten die compatibel zijn met SuSe Linux. In de regel werken deze apparaten ook in andere distributies.

    http://www.linuxtested.com/ - compatibiliteit en werking van apparaten per distributie. De site bevat informatie over het testen van apparaten in de volgende distributies: SuSE, Redhat / Fedora, TurboLinux, Debian, Mandrake.

    http://www.linux.org/hardware/ - hardware die werkt in Linux De lijst is niet compleet, maar kan nuttig zijn - er is informatie over exotische hardware waarvoor ondersteuning is in Linux.

    http://www.linux-drivers.org/ - links naar veel bronnen over Linux-compatibiliteit. Een groot aantal links naar bronnen en hardware-ondersteuning in Linux.

    http://hardware4linux.info/ - map met Linux-compatibele hardware, onderverdeeld in categorieën: “werkt direct uit de doos”, “werkt met aanpassingen”, “onbekend”, “werkt gedeeltelijk” en “werkt niet”. Een vrij grote en voortdurend bijgewerkte database met apparaten.

    http://www.linmodems.org/ - een database met ondersteuning voor kwaadaardige apparaten zoals Win-modems. Daarin worden alle hoofdactiviteiten overgedragen aan de bestuurder, geschreven voor je-weet-wel-systeem. Als gevolg hiervan zitten er bijna geen ‘hersens’ op het apparaat, net zoals de fabrikanten van dergelijke apparaten die niet hebben. Dankzij de inspanningen van vrije programmeurs kunnen veel van deze apparaten geschikt worden gemaakt voor Linux.

    Linux gebruikt een standaard schijfpartitieschema en kan een harde schijf delen met andere systemen, incl. met DOS.

    Er is een bootloader waarmee u selectief het vereiste besturingssysteem vanaf schijf kunt laden.

    Ondersteuning voor bestandssystemen van andere besturingssystemen.

    Vanuit Linux kunt u op de gebruikelijke manier werken met harde schijfpartities en diskettes die bestandssystemen van andere besturingssystemen bevatten, incl. DOS-, Windows 95-, Minix-, Xenix-, Coherent-, System V-bestandssystemen zijn beschikbaar in de alleen-lezenmodus.

    Bestandssystemen DoubleSpace/Stacked, enz. leesbaar en beschrijfbaar worden in Linux wanneer de DOS-emulator actief is.

    Bestandssysteem Linux OS ondersteunt alle standaard CD-ROM-formaten.

    Linux kan zowel een client als een server zijn voor het NFS-netwerkbestandssysteem. Linux ondersteunt NCP- en SMB-protocollen en kan dienen als bestandsserver of toegang krijgen tot NetWare en Ramen voor Werkgroepen, Windows NT.

    Linux installeren op een DOS-partitie.

    Linux ondersteunt het UMSDOS-bestandssysteem, wat het mogelijk maakt om Linux rechtstreeks in een DOS-bestandssysteem te installeren zonder de partities op de harde schijf opnieuw in te delen.

    Een Mini-Linux-distributiekit met 4 floppy's is gebouwd op basis van UMSDOS, dat in het DOS-bestandssysteem is geïnstalleerd.

    Werken met diskettes in DOS-formaat.

    Vanuit Linux kun je DOS-diskettes lezen en schrijven. Dit gebeurt zowel met behulp van conventionele Linux-tools (waarna de diskette wordt aangekoppeld als onderdeel van het bestandssysteem) als met speciale opdrachten voor het onderhoud van DOS-diskettes. Floppy disks zijn ook beschikbaar in de DOS-emulator.

    Uitvoering van DOS-applicatieprogramma's.

    Linux draait dosemu, een DOS-emulator. Met dit programma kun je een DOS-systeem op Linux draaien, waarop normaal DOS-applicatieprogramma's draaien. U kunt veel DOS-programma's uitvoeren, maar niet allemaal. Met een DOS-emulator kun je bijvoorbeeld werken

    • informatiedatabases:
      • Adviseur +,
      • Prijspuls,
      • Groothandelaars in Rusland,
      • enz.;
    • softwarepakketten voor boekhoudtaken.

    DOS-toepassingen die op Linux draaien, kunnen het DOS-partitiebestandssysteem of het bestandssysteem gebruiken Linux-systeem, incl. NFS-netwerkbestandssysteem.

    De DOS-applicatie draait parallel met andere processen. U kunt meerdere DOS-toepassingen tegelijkertijd uitvoeren.

    Werken met MS Windows-applicaties.

    Er is een WINE-systeem in ontwikkeling waarmee MS Windows-applicatieprogramma's op X Windows kunnen worden uitgevoerd. In dit geval wordt MS Windows niet gebruikt en is de aanwezigheid ervan niet vereist. Momenteel kunt u met WINE een beperkt aantal MS Windows-applicaties uitvoeren. Populaire programma's als Word, PageMaker en CorelDraw werken nog niet met het WINE-systeem. Het WINE-project wordt momenteel actief ontwikkeld en deze en andere applicaties zullen binnenkort beschikbaar zijn voor gebruik op X Windows.

    De DOS-emulator kan MS Windows 3.0 in echte modus en gerelateerde toepassingen uitvoeren. MS Windows 3.1 en Windows for Workgroups draaien op emulatorversie 0.63, hoewel dosemu voor deze doeleinden voorlopig als een alfaversie moet worden beschouwd. De DOS-emulator ontwikkelt zich snel.

    Willows Software, Inc. ontwikkelde het commerciële TWIN XPDK-systeem. Dit systeem bevat een component die functioneel vergelijkbaar is met WINE, die wordt gebruikt om X Windows uit te voeren Microsoft-applicaties Office-applicaties, Word, Excel en Project. Over het algemeen is TWIN XPDK een set tools voor ontwikkelaars van MS Windows-applicaties (inclusief voor Win95), waarmee de ontwikkelaar applicaties eenvoudig kan overbrengen tussen een aantal platforms, waaronder Unix, OS/2 en Mac.

    Caldera, Inc. , startkapitaal waaronder investeringen van Noorda Family Trust, Inc. (Ray Noorda is de voormalige CEO van Novell), verkoopt het op Linux gebaseerde Caldera Network Desktop-systeem. Caldera heeft een licentie verkregen van SunSoft, Inc. voor Wabi, een commercieel systeem dat functioneel vergelijkbaar is met het gratis WINE-systeem. Wabi, geprijsd op $ 200 of minder, zal verkrijgbaar zijn als onderdeel van de Caldera Solutions CD.

    Uitvoering van programma's uit verschillende versies van Unix.

    Met behulp van de iBCS2-emulator kunt u met het Linux-systeem downloadbare programma's uitvoeren van SCO Unix, Xenix V/386, SVR3 generic, Wyse V/386, SVR4 (Unixware, USL, Dell), BSD/OS, FreeBSD-systemen. SCO Unix-applicaties zoals CorelDraw, WordPerfect en Oracle draaien bijvoorbeeld op Linux.

    Programma's van Linux kunnen eenvoudig op bronniveau worden overgezet naar Linux (en vice versa). Unix-systemen Systeem V en BSD.

    Linux ondersteunt open systeemstandaarden, incl. POSIX. De wereldleider op het gebied van standaardisatie van informatietechnologie en houder van het UNIX-handelsmerk X/Open heeft het Linux-besturingssysteem een ​​POSIX.1 FIPS151-2-standaardcertificaat toegekend. Dit betekent officiële erkenning van het feit dat bijna alle Unix-applicaties eenvoudig naar Linux kunnen worden geport. Certificering met betrekking tot POSIX.2, POSIX.4 en POSIX.7 ligt in het verschiet. Lasermoon, die de Linux-FT-distributie produceert, heeft een X/Open-lidmaatschap.