Was ist UNIX?
Entstehung von Unix
Was ist Linux?
Entstehung von Linux
Linux-Einsatzbereiche
Die Struktur von Linux
Linux-Distributionen
Freie Software und Lizenzierung
Linux-Kernel
Datei:Grafik31.pngSysteme, die ihren Ursprung im Unixsystem von AT&T haben
oder dessen Konzepte implementieren
UNIX ein eingetragenes Markenzeichen der Open Group
Nur durch die Open Group zertifizierte Systeme dürfen den Namen UNIX führen
Dennoch ordnet man Unix-artige Betriebssysteme wie Linux der Unix-Familie zu
Der Name Unix
Wortspiel
Unics bzw. UNIX enthält ein zweifaches Wortspiel:
Zum einen die Vorsilbe Uni-als Gegenstück zu Multi-, zum anderen wird UNIX genauso gesprochen wie "Eunuchs" -typischer Programmiererhumor dieser Zeit. Kernighan nannte das System leicht spöttisch Unics, in Anspielung auf Multics, da es nur bis zu 2 Benutzer unterstützte: "Emasculated Multics is Unics." (Entmanntes Multics ist Unics).
Abkürzung
Der Name sollte später zu Unix verkürzt werden.
Akronyme
Der Name "Unics" wurde gerne auch als Uniplexed Information and Computing Service interpretiert, allerdings ist dies eine nachträgliche Interpretation – weder "Unics" noch "Unix" oder "UNIX" sind Akronyme.
Schreibweise UNIX
entstand 1974 aus purer Begeisterung für Kapitälchen
"... we had a new typesetter and troff had just been invented and we were intoxicated by being able to produce small caps." (Dennis Ritchie)
Es gibt/gab zahlreiche UNIX-Derivate (Dialekte), von verschiedenen Herstellern:
System
Hersteller
Ursprung
AIX
IBM
AT&T
DG-UX
Data General
HP-UX
Hewlett-Packard
BSD
IRIX
Silicon Graphics
Mac OS X
Apple
BSD
Solaris
Sun
BSD
Digital UNIX
Digital
BSD
SCO-UNIX
SCO
AT&T
Sinix
Siemens
AT&T
Da BSD und System V die Hauptentwicklungslinien aller UNIX-Systeme darstellen, enthalten alle UNIX-Dialekte viele Eigenschaften beider Systeme und lassen sich wie folgt einander zuordnen:
Die lange Geschichte von Unix hat ein komplexes System verschiedenartiger Betriebssysteme hervorgebracht, die in unterschiedlicher Weise mit dem Begriff „Unix“ assoziiert werden
Diesen Systemen gemeinsam ist der POSIX - Standard, der gewisse grundlegende Eigenschaften definiert.
Es gibt grundsätzlich zwei verschiedene Kategorien Unix-artiger Betriebssysteme: * „Generische“ Unices, die vom Quellcode des ursprünglichen, von den Bell Laboratories entwickelten, Unix abstammen und
„funktionellen“ Unices, die unabhängig davon entwickelt wurden, aber dessen Funktionsweise nachahmen.
Der Hacker und Programmierer Eric Steven Raymond hat zusätzlich eine dritte Kategorie vorgeschlagen, sodass die Einteilung folgendermaßen aussieht:
Generisches Unix
auch als Unix-Derivate bezeichnet
historische Verbindung zur AT&T-Codebasis
In diese Kategorie fallen
die meisten proprietären Unix-Varianten (z.B. AIX, IRIX und HP-UX)
BSD-Systeme; enthalten heute keinen originalen Unix-Quellcode mehr (FreeBSD, NetBSD und OpenBSD)
Warenzeichen „UNIX“
von der Open Group zertifizierte Systeme
erfüllen die Single Unix Specification
dürfen das Warenzeichen UNIX® tragen
meist kommerzielle Systeme sind und originäre Unix-Derivate
manche (z.B. IBMs z/OS) haben das Warenzeichen durch eine POSIX-Kompatibilitätsschicht bekommen und sind ansonsten keine echten Unix-Systeme.
Funktionelles Unix
jedes Unix-ähnliche System
das sich in ähnlicher Weise wie Unix verhält
spezieller Linux und Minix
Die meisten freien UNIX-Implementierungen fallen in diese Kategorie, da eine Zertifizierung durch die Open Group sehr kostenintensiv ist.
Die Einordnung eines Systems vor allem in die erste und die letzte Kategorie ist nicht immer eindeutig möglich, da diese Systeme aufgrund ihrer freien Lizenzen und der bei Unix üblichen Trennung zwischen Kernel und Userland (s.u.) durchaus auch kombiniert werden können, wie etwa bei Gentoo/FreeBSD. Als Überbegriff wird auch Un*x gebraucht.
Merkmale von Unix-Systemen
Was ist nun das Besondere, das UNIX auszeichnet? UNIX hatte Eigenschaften, die heute zwar selbstverständlich geworden sind, aber damals neu waren.
Unix ist historisch eng mit der Programmiersprache C verknüpft – beide verhalfen sich gegenseitig zum Durchbruch, und so ist C auch heute noch die bevorzugte Sprache unter Unixsystemen.
Unix-Kernel
exklusiver Zugriff auf die Hardware (über enthaltene Gerätetreiber)
verwaltet Prozesse
Dateisysteme
Netzwerkprotokollstapel
Speicherschutz
Programmierfehler/Absturz eines einzelnen Programms beeinträchtigen nicht die Stabilität anderer Programme oder des Gesamtsystems
Virtueller Speicher
Der verfügbare Arbeitsspeicher ist unabhängig vom real vorhandenen
Das Dateisystem ist als einzelner hierarchischer Baum mit beliebigen Unterverzeichnissen organisiert
Das Wurzelverzeichnis (Rootverzeichnis) dieser Hierarchie ist das Verzeichnis „/“
Festplattenpartitionen, Wechseldatenträger und Netzwerklaufwerke werden in diesen Baum als Verzeichnisse ein gehangen
Die Shell
Kommandointerpreter
Prozess ohne Privilegien
Ein-/Ausgabeumleitung
Pipes zur Kommunikation zwischen Prozessen
Zahlreiche Standardkommandos ermöglichen eine unerreicht einfache Ein-/Ausgabeumleitung in diese Dateien, und über Pipes die Kommunikation zwischen Prozessen.
Die meisten Betriebssysteme sind auf einen bestimmten Prozessortyp zugeschnitten
Inklusive der Anwendungen
UNIX ist so aufgebaut, dass Anpassungen an Hardwareplattformen leicht zu realisieren sind
UNIX abstrahiert die Hardware soweit, dass es möglich ist, das System auf andere Plattformen zu portieren und dann UNIX-Programme dort zu starten
Entwicklungswerkzeuge und Bibliotheken
man muss nicht erst lange viel Software nachinstallieren, sondern findet das Wichtigste schon vor und kann davon ausgehen, dass auf jedem entsprechenden UNIX-System das gleiche vorhanden sein wird.
Ein legendäres Programm, das schnell zum Grundbestandteil eines UNIXes wurde, war z. B. die Shell sh, die Steve Bourne schrieb.
Der Linuxgemeinde ist sein Name in der allseits bekannten bash (Bourne Again Shell) überliefert.
Netzwerkfähigkeit
TCP/IP – Netzwerkunterstützung
schon sehr früh wurden die UNIX-Kernel mit einem TCP/IP-Stack ausgestattet und bildeten so sehr schnell das Rückgrat des damals noch jungen Internets.
zuerst in der BSD -Linie
Weitere Merkmale eines typischen Unix-Systems
Hohe Stabilität
Am 30.10.2000 wurde die letzte Installation von Multics abgeschaltet
Hohe Skalierbarkeit
Von der Armbanduhr bis zum Supercomputer
Hervorragende Scripting-Eigenschaften
Einfache Automatisierung
Durch die Programmiermöglichkeiten der Sehlls und Skript-Sprachen wie Perl und awk. Zahlreiche Aufgaben lassen sich unter UNIX sehr einfach automatisieren.
Daemonen
Hintergrundprozesse
Diverse grafische Benutzeroberfläche
basierend auf X11
Unix-Philosophie
Datei:.pngDouglas McIlroyMcIlroy: A Quarter Century of Unix
Die Unix-Philosophie ist eine Menge von Regeln und Herangehensweisen bei der Software-Entwicklung, die auf den Erfahrungen der führenden Unix-Programmierer basieren.
Douglas McIlroy (Unix-Pipes): * Schreibe Programme so, dass sie nur eine Aufgabe erledigen
Diese eine Aufgabe sollen sie gut machen
Schreibe Programme so, dass sie zusammenarbeiten
Schreibe Programme so, dass sie Textdateien verarbeiten
Textdateien sind eine universelle Schnittstelle
Kurz: Tue nur eine Sache, diese aber gut!
Von diesen drei Lehrsätzen sind vor allem die ersten beiden nicht auf Unix beschränkt, jedoch betonen Unix-Programmierer alle drei Lehrsätze stärker als andere Programmierer.
Wähle stets die einfachste mögliche Lösung (KISS)
KISS-Prinzip
wird häufiger im allgemeinen Zusammenhang mit komplexen Planungsaufgaben verwendet
auch im Bereich der Informatik verbreitet
Designprinzip zur optimale Lösung eines Problems
möglichst einfache
minimalistische
im Nachhinein leicht verständliche Lösung
Ein gutes Beispiel dafür in der Informatik ist das Internet, das auf der TCP/IP - Protokollfamilie basiert.
Der einfache Aufbau dieser Protokolle hat dafür gesorgt, dass dieses Netz das sehr schnelle Wachstum seit dem Aufkommen des World Wide Web ohne große Probleme überstanden hat, obwohl die TCP/IP-Protokolle ursprünglich für ein wesentlich kleineres Netzwerksystem (für die Forschungszentren der DARPA) entwickelt wurden.
KISS ein Akronym für
Keep it simple and stupid
Halte es einfach und dumm
Keep it simple, stupid.
Halte es einfach, Dummkopf
Keep it small and simple
Gestalte es klein und einfach
Keep it sweet and simple
Gestalte es gefällig und einfach
Keep it simple and straightforward
Gestalte es einfach und überschaubar
Keep it simple and smart
Mach es einfach und clever
Keep it strictly simple
Mach es strikt einfach
Keep it silly and stupid
Mach es dumm und dümmer
Pike: Notes on Programming in C
Rob Pike schlägt in dem Text Notes on Programming in C die folgenden Regeln als Grundsätze des Programmierens vor, jedoch kann man sie genauso als Kerngedanken der Unix-Philosophie sehen:
Regel 1
Man kann nicht sagen, welcher Programmteil den Hauptteil der Leistung fressen wird. Da Flaschenhälse oft an überraschenden Stellen auftauchen, soll man nichts zur Erhöhung der Geschwindigkeit einbauen, bevor man gezeigt hat, wo der Flaschenhals sitzt.
Regel 2
Miss die Programmlaufzeit. Feile erst an der Geschwindigkeit, wenn du sie gemessen hast, und selbst dann erst, wenn der betrachtete Teil einen dominierenden Anteil der Rechenzeit frisst.
Regel 3
Ausgefallene Algorithmen sind langsam, wenn die Eingabedatenmenge [siehe Komplexitätstheorie] klein ist, und das ist der Normalfall. Ausgefallene Algorithmen haben große Fixkosten. Solange man nicht weiß, dass häufig große Werte annehmen wird, soll man auf ausgefallene Algorithmen verzichten. (Und selbst wenn groß wird, gilt zuerst Regel 2.)
Regel 4
Ausgefallene Algorithmen sind fehlerhafter als einfache, und sie sind viel schwieriger zu implementieren. Benutze sowohl einfache Algorithmen als auch einfache Datenstrukturen.
Regel 5
Daten sind wichtiger. Wenn du die richtigen Datenstrukturen gewählt hast und alles gut gestaltet ist, werden sich die Algorithmen fast immer von alleine ergeben. Datenstrukturen sind das zentrale Thema des Programmierens, nicht Algorithmen.
Regel 6
Es gibt keine Regel 6.
Die Regeln 1 und 2 wiederholen den berühmten Grundsatz von Tony Hoare: „Zu frühe Optimierung ist die Wurzel allen Übels.“ Ken Thompson formulierte die Regeln 3 und 4 als „Verwende im Zweifelsfall rohe Gewalt“; diese Regeln sind Beispiele für das KISS-Prinzip.
Die Regel 5 stammt von Fred Brooks, der sie im Buch The Mythical Man-Month erwähnt hat, und wird oft formuliert als „schreibe dummen Code, der schlaue Daten verwendet“.
Die Regel 6 ist dem Bruces-Sketch aus Monty Python’s Flying Circus (Folge 22) entlehnt.
Mike Gancarz: The UNIX Philosophy
1994 veröffentlichte Mike Gancarz seine eigenen Erfahrungen mit Unix (er gehörte zu den Entwicklern des X Window System) zusammen mit Gedanken aus Diskussionen mit Kollegen sowie Leuten aus anderen Gebieten, welche ebenfalls auf Unix angewiesen waren, zusammengefasst als The Unix Philosophy.
Darin werden neun Hauptforderungen genannt:# Klein ist schön.
Gestalte jedes Programm so, dass es eine Aufgabe gut erledigt.
Erzeuge so bald wie möglich einen funktionierenden Prototyp.
Bevorzuge Portierbarkeit vor Effizienz.
Speichere Daten in einfachen Textdateien.
Verwende die Hebelwirkung der Software zu deinem Vorteil.
Verwende Shell-Skripte, um die Hebelwirkung und die Portierbarkeit zu verbessern.
Vermeide Benutzeroberflächen, die den Benutzer fesseln.
Mache jedes Programm zu einem Filter.
Die folgenden zehn weniger strengen Forderungen werden nicht allgemein als Teil der Unix-Philosophie akzeptiert und führen zum Teil auch zu heftigen Debatten (beispielsweise beim Thema monolithischer Kernel vs. Microkernel):# Lass den Benutzer die Umgebung nach seinen Bedürfnissen festlegen.
Mache Betriebssystemkernel klein und leichtgewichtig.
Benutze Kleinschreibung und halte Befehlsnamen kurz.
Verschwende keine Bäume.
Schweigen ist Gold.
Denke parallel.
Die Summe der Teile ist mehr als das Ganze.
Suche die 90/10-Lösung.
Schlechter ist besser.
Denke hierarchisch.
Schlechter ist besser
Richard P. Gabriel behauptet, ein grundlegender Vorteil von Unix komme von einer Designphilosophie, die er als schlechter ist besser bezeichnet. Nach dieser Philosophie ist die Einfachheit sowohl der Benutzerschnittstelle als auch der Umsetzung im Programm viel wichtiger als jede andere Eigenschaft des Systems – inklusive Eigenschaften wie Fehlerfreiheit, Konsistenz und Vollständigkeit.
Gabriel argumentiert, dass diese Vorgehensweise grundlegende Vorteile bei der Weiterentwicklung der Software bietet, allerdings zweifelt er auch an der Qualität bei so mancher Umsetzung dieser Vorgehensweise. In solchen Fällen bevorzugten Ken Thompson und Dennis Ritchie Einfachheit vor Perfektion. Aus diesen Gründen war Unix in seiner Anfangszeit das Betriebssystem, das am häufigsten abstürzte (mehrmals pro Tag), allerdings auch den schnellsten Neustart hatte.
Wegen seiner Einfachheit wurde innerhalb von zehn Jahren aus Unix das stabilste System, das mit fehlerfreien Laufzeiten im Bereich von Monaten und Jahren statt Stunden aufwarten konnte.
Raymond: The Art of Unix Programming
Eric S. Raymond fasst in seinem Buch The Art of Unix Programming die Unix-Philosophie mit der allseits bekannten Ingenieursweisheit Keep it Simple, Stupid (KISS) zusammen.
Anschließend beschreibt er, wie diese Grundhaltung seiner Meinung nach in der Praxis der Unix-Kultur umgesetzt wird (wobei in der Praxis natürlich gelegentlich sehr deutlich gegen diese Regeln verstoßen wird):
Regel der Modularität
Schreibe einfache Bestandteile, die durch saubere Schnittstellen verbunden werden.
Regel der Klarheit
Klarheit ist besser als Gerissenheit.
Regel des Zusammenbaus
Entwirf Programme so, dass sie mit anderen Programmen verknüpft werden können.
Regel der Trennung
Trenne den Grundgedanken von der Umsetzung, trenne die Schnittstellen von der Verarbeitungslogik.
Regel der Einfachheit
Entwirf mit dem Ziel der Einfachheit; füge Komplexität nur hinzu, wenn es unbedingt sein muss.
Regel der Sparsamkeit
Schreibe nur dann ein großes Programm, wenn sich klar zeigen lässt, dass es anders nicht geht.
Regel der Transparenz
Entwirf mit dem Ziel der Durchschaubarkeit, um die Fehlersuche zu vereinfachen.
Regel der Robustheit
Robustheit ist das Kind von Transparenz und Einfachheit.
Regel der Darstellung
Stecke das Wissen in die Datenstrukturen, so dass die Programmlogik dumm und robust sein kann.
Regel der geringsten Überraschung
Mache beim Entwurf der Schnittstellen immer das Nächstliegende, welches für die wenigsten Überraschungen beim Benutzer sorgt.
Regel der Stille
Wenn ein Programm nichts Überraschendes zu sagen hat, soll es schweigen.
Regel des Reparierens
Wenn das Programm scheitert, soll es das lautstark und so früh wie möglich tun.
Regel der Wirtschaftlichkeit
Die Arbeitszeit von Programmierern ist teuer; spare sie auf Kosten der Rechenzeit.
Regel der Code-Generierung
Vermeide Handarbeit; schreibe Programme, die Programme schreiben, falls möglich.
Regel der Optimierung
Erstelle Prototypen, bevor du dich an den Feinschliff machst. Mache es lauffähig, bevor du es optimierst.
Regel der Vielseitigkeit
Misstraue allen Ansprüchen auf „den einzig wahren Weg“.
Regel der Erweiterbarkeit
Entwirf für die Zukunft, denn sie wird schneller kommen als du denkst.
Viele dieser Normen werden auch außerhalb der Unix-Gemeinde anerkannt – wenn sie nicht zuerst bei Unix verwendet wurden, wurden sie bald übernommen.
Trotzdem betrachten Unix-Experten eine Kombination dieser Regeln als die Grundlage des Unix-Stils.
Rolle des Betriebssystems
Obige Aussagen beschreiben, welche Eigenschaften Programme haben, die Unix zu dem machen, was es ist.
Ein weiterer Aspekt der Unix-Philosophie betrifft jedoch auch das Betriebssystem selbst:
Damit Programme möglichst einfach, klar und modular gehalten werden können, damit sie gut zusammenarbeiten können und damit sie gut portierbar sein können, muss das Betriebssystem die entsprechenden Voraussetzungen in Form von klaren Schnittstellen und hoher Abstraktion schaffen. In der Praxis:* Alles ist eine Datei:
lokale Laufwerke
Netzlaufwerke
Virtuelle Laufwerke (Image-Dateien)
Kernel-Daten (/proc. )
Kommunikation erfolgt grundsätzlich über Netzwerk-Verbindungen. Auch die interne Kommunikation zwischen beispielsweise Client-Programmen und Daemons wird über Netzwerkschnittstellen geführt, so dass die Programmierung einheitlich ist und die Programme auch wahlweise über das Netzwerk verwendet werden können.
Aus diesem Grund gibt es bei Unix nicht für jedes Anwendungsgebiet eine spezialisierte Programmierschnittstelle, sondern auch vergleichsweise exotische Anwendungen werden auf Dateien oder Netzwerkverbindungen abgebildet.
Zitate
„Unix ist einfach. Es erfordert lediglich ein Genie, um seine Einfachheit zu verstehen.“ – Dennis Ritchie
„Unix wurde nicht entwickelt, um seine Benutzer daran zu hindern, dumme Dinge zu tun, denn das würde diese auch davon abhalten, schlaue Dinge zu tun.“ – Doug Gwyn
Jeder Hersteller änderte und erweiterte das System in den 80er Jahren des 20. Jahrhunderts nach eigenen Vorstellungen.
Es entwickelten sich Versionen mit unterschiedlichen Fähigkeiten, Kommandos, Kommandooptionen und Programmbibliotheken.
POSIX
Um 1985 begann die IEEE zunächst, die Schnittstellen für Anwendungsprogramme zu standardisieren.
Daraus entwickelte sich der IEEE 1003 -Standard, der auf Anregung von Richard Stallman POSIX genannt wird.
Er besteht heute aus etwa 15 Dokumenten, die sich mit allen Aspekten von Unix-Systemen wie dem Kommandozeileninterpreter (POSIX schreibt zwingend die Korn Shell vor), den Unix-Kommandos und deren Optionen, der Ein-/Ausgabe und anderem befassen.
Portable Operating System Interface ISO/IEC/IEEE 9945
Das Portable Operating System Interface (POSIX) ist ein gemeinsam von der IEEE und der Open Group für Unix entwickeltes standardisiertes Application Programming Interface, das die Schnittstelle zwischen Applikation und dem Betriebssystem darstellt. Die internationale Norm trägt die Bezeichnung ISO/IEC/IEEE 9945.
Entwicklung
Die heutigen Standards sind eine Weiterentwicklung aus einem Projekt im Jahr 1985.
Der Begriff POSIX wurde von Richard Stallman als Reaktion auf den IEEE-Aufruf nach einem einprägsamen Namen vorgeschlagen; zuvor trug der Standard die Bezeichnung IEEE-IX.
Die meisten Unix-Derivate halten sich mehr oder weniger an die in IEEE1003.1 (1990) und IEEE1003.2 (1992) festgelegten Standards.
Diese älteren Versionen wurden 2001 durch die überarbeitete Version IEEE Std 1003.1-2001 der IEEE und Open Group abgelöst.
2004 wurde eine leicht korrigierte Version IEEE Std 1003.1, 2004 Edition veröffentlicht. Die gegenwärtig aktuelle Version ist die Überarbeitung von 2008.
Es besteht die Möglichkeit, ein Produkt zertifizieren zu lassen.
Einige Linux-Distributoren werben inzwischen damit, ein POSIX-konformes Betriebssystem zu vertreiben.
Spezifikation
Die Spezifikation der Benutzer- und Software-Schnittstelle des Betriebssystems ist in vier Teile unterteilt, die zusammen den Standard IEEE Std 1003.1-2008 bilden:
Basis-Definitionen
Eine Liste der im Standard benutzten Konventionen, Definitionen, und Konzepte.
System-Schnittstelle
Die C-Systemaufrufe und dazugehörige Header-Dateien.
Kommandozeileninterpreter und Hilfsprogramme
Eine Liste der Hilfsprogramme und der Kommandozeileninterpreter.
Erklärungen
Erläuterungen, warum der Standard so ist, wie er ist.
Die Standard-POSIX-Shell ist die Unix-Shell.
Weitere Hilfsprogramme wie awk, vi oder echo sind ebenfalls Teil des POSIX-Standards.
Die C-Funktionen stellen unter anderem Ein- bzw. Ausgabe (für Dateien, Terminals und Netzwerkdienste) zur Verfügung, daneben Erzeugung und Kontrolle von Prozessen sowie Benutzer- und Gruppenverwaltung.
Weblinks
standards.ieee.org/regauth/posix
Portable Application Standards Committee, dieses Gremium pflegt den Standard beim IEEE weiter (englisch) www.pasc.org
Die Preise der IEEE für die POSIX-Dokumentation sind sehr hoch, die Veröffentlichung ist durch Urheberrecht untersagt.
In neuerer Zeit ist deshalb eine Tendenz zum Single Unix Specification -Standard der Open Group zu verzeichnen.
Dieser Standard ist offen, im Internet frei verfügbar und akzeptiert Vorschläge von jedem.
Entstehung von Unix
Die Geschichte von UNIX liest sich stellenweise wie ein Heldenepos oder ein Kriminalroman, manchmal auch wie eine Groteske.
Schon die Geburt von UNIX vollzog sich unter eigenartigen Umständen, denn es entsprang einem gescheiterten Projekt.
Die Welt vor UNIX
Setzt man sich heute vor einen Rechner, startet ein Programm, wartet einige Sekunden, bis dieses endlich die erhofften Resultate präsentiert, dann blättert man alsbald durch Prospekte der Computer-Discounter und liebäugelt mit neuer, leistungsfähigerer Technik.
Mit keinem Gedanken erinnert man sich an die monströsen Ungetüme aus Röhren und Transistoren im Turnhallenformat, die noch in den 70er Jahren die Leistung kleiner Kraftwerke erforderten, um letztlich nur einen Bruchteil an heutiger Rechenleistung zu vollbringen.
Zu jener Zeit wurden die "Rechengenies" noch per Hand mit Daten gefüttert, vom Administrator, der den Lochkartenstapel einlegte und nach Stunden oder gar erst Tagen die Resultate ebenfalls in Form von Lochkarten entnahm.
Ein Betriebssystem kannte und brauchte man damals noch nicht.
Als Ken Thompson 1969 bei Bell Laboratories (AT&T), die Entwicklung eines neuen Betriebssystems begann, waren die meisten der vorhandenen Systeme sog. Batch-Systeme:
Ein Programmierer gab seine Lochkarten oder Lochstreifen beim Operator ab, diese wurden in den Rechner eingelesen und ein Rechenauftrag nach dem anderen abgearbeitet.
Der Programmierer konnte dann nach einiger Zeit seine Ergebnisse abholen.
Alle diese Systeme wurden jeweils speziell für den Computer geschrieben, auf dem sie liefen.
Gemeinsam Programmieren
Datei:.pngKen Thompson (links) und Dennis Ritchie (rechts)
UNIX ist entstanden, aus der Notwendigkeit zur Programmerstellung ein Betriebssystem, zu entwickeln, an dem mehrere Programmierer im Team und im Dialog mit dem Rechner arbeiten können.
Timesharing-Verarbeitung mit Magnetbändern
Die Rechner wurden kleiner, passten schon in einen einzigen Raum, ihre Verarbeitungsgeschwindigkeit stieg und übertraf bald die Fähigkeit des Administrators, die Magnetbänder rechtzeitig zu wechseln.
Es wurde Zeit, den Ballast der reinen Stapelverarbeitung (ein Job nach dem anderen) aufzugeben und zur Timesharing-Verarbeitung überzugehen.
Man erweiterte den damals sündhaft teuren Arbeitsspeicher, so dass mehrere Jobs gleichzeitig rechenbereit auf die CPU warten konnten und teilte jedem Job eine genau festgelegte Zeitscheibe an CPU-Zeit zu.
Von einer Interaktion mit dem Nutzer war man noch meilenweit entfernt.
Das erste Ergebnis dieser Entwicklung war MULTICS, das für den Mainframe-Rechner GE645 in Maschinensprache (Assembler) geschrieben wurde.
1965 wurden im Rahmen der Fall Joint Computer Conference einige Papiere über ein neu zu erstellendes Betriebssystem namens Multics veröffentlicht.
Hinter Multics stand ein Konsortium aus MIT * General Electric
Bell Labs
Honeywell.
Ebenfalls am Rande beteiligt war IBM, in deren Programmiersprache PL/I Multics entwickelt werden sollte.
MULTICS (Multiplexed Information and Computing System) mit der Vorstellung ins Leben gerufen, ein Betriebssystem für eine Maschine zu entwickeln, die über so viel Rechenkapazität verfügen sollte, um alle Einwohner von Boston bedienen zu können.
Das Scheitern von Multics
1969 zogen sich die Bell Labs aus dem Projekt zurück. Die Erwartungen an Multics waren überzogen, die Hardware dieser Zeit konnte kein System dieser Komplexität und Größe in angemessener Geschwindigkeit liefern.
Dennoch brachte das Projekt das spätere Verständnis des Aussehens von Betriebssystemen wertvolle Erkenntnisse.
Dennis Ritchie äußerte sich in einem 1979 veröffentlichtem Papier:
"... the problem was the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system,..." (...das Problem war die zunehmende Gewissheit, dass Multics auf absehbare Zeit nicht brauchbar sein würde...)
Entwicklungsziele
Das Team um Ritchie, darunter Ken Thompson, Douglas McIlroy und Joseph Ossanna wollte aber nicht aufgeben. Es ging ihnen vor allem darum, * ein Mehrbenutzersystem zu haben,
das es ihnen erlaubte, nicht nur zusammen zu programmieren
sondern auf dessen Basis sich auch eine echte Gemeinschaft herausbilden konnte.
Zu diesem Zweck musste das System einige technische Spezialitäten unterstützen, die damals keineswegs selbstverständlich waren, so zum Beispiel, dass mehrere Benutzer gleichzeitig an Dateien arbeiten konnten, ohne sich gegenseitig in die Quere zu kommen.
Während das Team vergeblich versuchte, die Bell Labs vom Kauf einer geeigneten Maschine zu überzeugen, begannen gleichzeitig die technischen Vorarbeiten.
Auf Notizzetteln und Tafeln wurden die Konzepte zu einem Dateisystem entwickelt, das später zu einem der Kernstücke von Unix werden sollte.
Thompson entwickelte auch einige Prototypen eines Dateisystems und eines primitiven Kernels, die auf einer GE-645 lauffähig waren, musste das Projekt aber einstellen, nachdem klar wurde, dass die GE-645 auf absehbare Zeit aus den Labors entfernt werden würde.
Space Travel die PDP-7
Er fand schließlich eine weitgehend unbenutzte PDP-7, auf die er ein zuvor für Multics und GECOS entwickeltes Spiel namens Space Travel portieren wollte.
Das Unternehmen erwies sich komplizierter als zunächst gedacht, da für die PDP-7 kein eigenes Entwicklungssystem vorlag, und so sämtliche Entwicklung unter GECOS stattfinden musste, welches dann den PDP-7 Code produzierte.
Erste Werkzeuge
Um diesen Missstand abzustellen, begann Thompson unter Mithilfe von Ritchie die Implementierung des zuvor konzipierten Dateisystems mitsamt einem primitiven Prozessmanagement, und anschließend einer Reihe kleinerer Programme, die das System benutzbar machen sollten:
Editor, kleinere Dateiverwaltungsprogramme, und ein einfacher Kommandozeileninterpreter (Shell), bis das System schließlich ausreichend ausgestattet war, um ohne den GECOS-Umweg direkt auf der PDP-7 zu entwickeln.
Fertigstellung und Verbreitung
Umstieg auf die PDP-11
Die PDP-7 war zu dieser Zeit bereits ein Auslaufmodell und gehörte dem Team noch nicht mal, aber schließlich erwiesen sich die Bemühungen, einen eigenen Computer für die Unix-entwicklung zu beschaffen, als erfolgreich, und eine PDP-11 wurde in Auftrag gegeben.
Unix war rasch portiert, und das System wurde ab 1971 erfolgreich im Patentbüro der Bell Labs als Textverarbeitungssystem eingesetzt.
Das System war, durch die Umstände bedingt, erstaunlich klein verglichen mit heutigen Betriebssystemen:
Es bestand aus 16 KiB Speicher für das System, 8 KiB für die Benutzerprogramme, einer 512-KiB- Festplatte und Dateien konnten maximal 64 KiB groß werden.
Datei:.png1972: Ken Thompson (rechts) and Dennis Ritchie (links) vor einer PDP-11 mit Teletype 33 terminalsBewährung im Patentbüro
Der Einsatz im Patentbüro gab der Gruppe genug Glaubwürdigkeit, damit Unix als Projekt für die Bell Labs interessant wurde und um die Anschaffung einer PDP 11/74 zu rechtfertigen, und die AT&T Unix Systems Group (später: Unix Systems Group) wurde als offizielles Projekt der Bell Labs gegründet.
Die Portierung auf C
Parallel begann eine Entwicklung, die ausschlaggebend für den späteren Erfolg von Unix war:
Die Entwicklung der Sprache C.
Thompson entwickelte 1971 eine interpretierte Programmiersprache für die PDP-7 namens B, welche auf BCPL basiert war.
Ritchie fügte der Sprache auf der PDP-11 Datentypen hinzu und nannte sie zunächst NB (für New B) und begann einen Compiler für die Sprache zu entwickeln.
1972 begann nun die Neuerstellung von Unix in dieser Sprache, die mittlerweile den Namen C erhielt, um zukünftig die Portierung von Unix auf neue Rechner zu erleichtern.
Die Portierung wurde 1973 abgeschlossen und erhielt den Namen Unix V4. Erst mit UNIX Release 7 (1979) wurde der Code wirklich portabel.
Gleichzeitig wurde Unix, auf Anregung von Doug McIlroy, um das Konzept der Pipes erweitert.
Pipes verbinden kleine Programme, und erlauben das Ergebnis eines Programmes im Rahmen einer einzigen Kommandozeilenanweisung in einem anderen Programm weiterzuverarbeiten
Sie stellten später eines der wichtigen Kernelemente von Unix dar, da erst sie das Konzept der kleinen spezialisierten Werkzeuge, die genau eine Aufgabe erledigen, ermöglichten.
Unix verlässt die Bell Labs
Unix lief mittlerweile innerhalb der Bell Labs auf mehr als 25 Rechnern, und durch einen Vortrag 1973 auf einem ACM Symposium wird es erstmals außerhalb der Bell Labs bekannt.
Der Vortrag erschien in überarbeiteter Fassung dann 1974 als The UNIX Time-Sharing System in CACM. Das Interesse an Unix stieg auch außerhalb der Bell Labs gewaltig an.
Unix zum Datenträgerpreis
Der 1956 abgeschlossene Consent Decree verbot AT&T, Muttergesellschaft der Bell Labs, das Betreten neuer Märkte wie des Computermarktes. Aus diesem Grund wurde Unix (in der 1975 aktuellen Version 6) für lediglich den Preis der Datenträger verschiedenen Universitäten zur Verfügung gestellt, mitsamt dem vollständigen Quellcode.
1976 schrieb der australische Professor John Lions ausführliche Kommentare zum Quellcode von Unix-V6, die als Lions Book berühmt wurden.
Die Kompaktheit und strukturelle Einfachheit des Systems ermunterte viele Benutzer zur eigenen Aktivität und Weiterentwicklung des Systems, so dass UNIX recht schnell einen relativ hohen Reifegrad erreichte.
Dies ist deshalb bemerkenswert, da kein Entwicklungsauftrag hinter diesem Projekt stand, und die starke Verbreitung von UNIX nicht auf den Vertrieb oder die Werbung eines Herstellers, sondern primär auf das Benutzerinteresse zurückzuführen ist.
Besonders beliebt war Unix an der Universität von Kalifornien in Berkeley (UCB), wo sofort eine Reihe von Verbesserungen an Unix entwickelt wurden.
Als Ken Thompson ab 1976 eine Gastprofessur in der neu gegründeten Informatikabteilung von Berkeley antrat, wurde die Universität endgültig zu einem der wichtigen Zentren der Unix-Entwicklung.
Die Universität steuerte später zu Unix wichtige Beiträge, wie die Unterstützung von TCP/IP, bei, die später auch in die offizielle Unixversion von AT&T übernommen wurden. Ab 1977 veröffentlicht die Universität unter Leitung von Bill Joy eine eigene Unixdistribution: BSD - Berkeley Software Distribution.
1978 über 600 Computer mit UNIX-Betriebssystemen
Die großen „Unix-Kriege“
Der Quellcode wird geschlossen
1979 wird schließlich durch AT&T die letzte UNIX-Version mit freiem Quellcode, nämlich UNIX V7, veröffentlicht. UNIX V7 stellt einen Wendepunkt in der Geschichte von UNIX dar, da sich AT&T erstmals in größerem Umfang an einer kommerziellen Vermarktung versuchte.
Microsoft erwirbt 1979 eine Unixlizenz und beginnt unter dem Namen Xenix die Arbeiten an Portierungen auf u. a. Intel 8086, Motorola 68000 und Zilog Z8000 -Prozessoren.
In den späten 1980er entwickelte Microsoft zusammen mit IBM OS/2 (später aufgespalten in IBM's OS/2 und Microsoft's Windows NT).
Da man mit OS/2 (bzw. Windows NT) und Xenix zwei Serverbetriebssysteme im Angebot gehabt hätte, die sich gegenseitig Konkurrenz gemacht hätten, entschied Microsoft 1987 die Rechte an Xenix an die Firma Santa Cruz Operations (SCO, heute Tarantella, Inc.) zu verkaufen, die schon seit 1983 Lizenznehmer von Xenix war.
Im Jahr 1980 erschien die erste Portierung von UNIX V7 auf eine 32-Bit-Maschine, die VAX, mit UNIX 32V und 3BSD.
Im Laufe der 1980er wurden UNIX V8, V9 und V10 zwar noch entwickelt, aber nur an ein paar Universitäten vorgestellt, obwohl auch schriftliche Beschreibungen der Arbeit an diesen Versionen erstellt wurden.
Die Überlegungen bei dieser Arbeit führten aber letztendlich auch zur Entwicklung des Betriebssystems Plan 9.
Datei:.pngPlan 9 from Bell Labs on IBM's Blue Gene Supercomputers
Die 1980er Jahre sind gekennzeichnet durch den Beginn der großen "Unix-Kriege" und die Kommerzialisierung von Unix. AT&T betrat offiziell den Computermarkt und begann 1983 ein auf Unix V7 basierendes System, System V genannt, zu vermarkten.
Das Militär
Die Universität von Berkeley zeitgleich 4.2BSD veröffentlichte, das Neuerungen wie TCP/IP oder Signale mit sich brachte. Mittlerweile hat auch die DARPA Interesse an Unix entwickelt und unterstützt die Entwicklungen in Berkeley finanziell.
1984 trennte sich AT&T von etlichen Tochterfirmen, womit ihr auch gestattet wurde, sich als gewöhnlicher Wettbewerber auf dem Computermarkt zu betätigen.
Damit wurden auch die Lizenzgebühren für UNIX drastisch angehoben und der Zugang zum Quellcode mehr und mehr eingeschränkt.
Die Folge war, dass die Kooperation zwischen den Firmen, die UNIX kommerziell vermarkteten, immer mehr zurückging und jeder in "seiner" UNIX-Version seine eigenen Erweiterungen und Verbesserungen einbaute, bis UNIX heillos in unterschiedliche Versionen aufgesplittet war:* SunOS von SUN,
HP-UX von Hewlett-Packard,
AIX von IBM,
Ultrix von Digital,
SINIX von Siemens,
Microsoft versuchte sich auf dem UNIX-Markt mit Xenix.
Ein großer Vorteil, die leichte Portierbarkeit der UNIX-Programme, drohte mit dieser Zersplitterung zu verschwinden und viele Stimmen prophezeiten auch ein mittelfristiges Ende von UNIX.
Als AT&T nach der Zerschlagung als Wettbewerber auftreten durfte, versuchte es auch, einen Standard zu schaffen: System V (wobei das V für die Zahl 5 steht und nicht für den Buchstaben, also "System Five" gesprochen).
AT&T versucht einen Standard zu setzen
1985 brachte AT&T das "System V Interface Definition" oder auch "lila Buch" heraus.
Dieses Dokument stellte ein Standard für die UNIX-Schnittstellen dar. Zusätzlich enthielt es auch eine Menge Werkzeuge, die ein System auf die Konformität mit dem Standard V überprüfte.
Diese von AT&T 1983 freigegebene Version "UNIX System V" war zu dieser Zeit die dominierende Version, dies stellte den Versuch dar, die Hersteller auf einen Standard zu einen.
Die Antwort: POSIX
Um sich nicht von einer einzigen Firma abhängig zu machen, entstanden im Laufe der Zeit andere Standards, wie z. B. POSIX(Portable Operating System based on UNIX).
Weil AT&T alle Rechte an dem Namen UNIX hatte, wurde vom IEEE (Institute of Electrical and Electronic Engineers) dieser Name für diesen Standard gewählt.
Ein anderes Beispiel hierfür ist X/Open: Das X/Open Konsortium ist ein Zusammenschluss verschiedener Computerhersteller, die einen De-Facto-Standard schaffen wollten. 1988 wurde der X/Open Portability Guide veröffentlicht.
Um eine weitere Aufspaltung zu verhindern, wurde das POSIX Standardisierungsprojekt ins Leben gerufen, das eine einheitliche Schnittstelle für Unix definieren sollte. 1988 wurde schließlich POSIX.1 veröffentlicht (heute auch ein IEEE -Standard unter der Nummer 1003.1).
Es bildeten sich daraufhin eine Reihe von (teils wechselnden) Allianzen, die verschiedene Unix-Versionen favorisierten:
Open Software Foundation
Die OSF wurde 1985 gegründet, teilweise aufgrund der Meinung der Beteiligten, dass der POSIX-Standard AT&T zu stark bevorzugen würde, teilweise auch aufgrund von Befürchtungen, dass AT&T und Sun Microsystems, die ab 1987 kooperieren, den Markt unter sich aufteilen könnten.
Gründungsmitglieder der OSF waren u. a. DEC, Siemens, HP und IBM.
Das Konsortium hatte sich zum Ziel gesetzt, ein gemeinsames Unix unter dem Namen OSF/1 zu veröffentlichen.
Unix International
UI wurde als unmittelbare Reaktion auf die OSF gegründet durch Anhänger des AT&T Unixs wie z. B. Olivetti, Unisys und eben AT&T und Sun.
X/Open
Ursprünglich 1983 unter dem Namen Bison von einer Reihe europäischer Unternehmen wie Bull, Siemens, Olivetti gegründet, um gemeinsame europäische Interessen besser gegen die US-Firmen vertreten zu können, wurde das Konsortium später mit der Aufnahme von US-Firmen umbenannt.
Während OSF/1 bis in die 1990er Jahre nicht fertiggestellt wurde, veröffentlichten AT&T und UI weitere Verbesserungen an Unix System V.
Freie Software
1983 begann Richard Stallman, verärgert über die Proprietarisierung von Unix, mit der Arbeit an einem eigenen, Unix-ähnlichen Betriebssystem namens GNU und rief mit der Veröffentlichung des GNU Manifests 1985 eine immer stärker werdende Bewegung für freie Software ins Leben.
Die Rechte am Warenzeichen liegen dagegen bei der Open Group
Unix-ähnliche Betriebssysteme
Vorgeschichte
redundant?
Bis Unix V7 1979 erschien, wurde der Quellcode von Unix gegen Erstattung der Kopier- und Datenträgerkosten an Universitäten verteilt. Unix hatte damit den Charakter eines freien, portablen Betriebssystems.
Der Code wurde in Vorlesungen und Veröffentlichungen verwendet und konnte nach eigenen Vorstellungen geändert und ergänzt werden.
Die Universität Berkeley entwickelte eine eigene Distribution mit wesentlichen Erweiterungen, die Berkeley Software Distribution (BSD).
In den frühen 80er Jahren beschloss AT&T, Unix zu vermarkten; der AT&T-Quellcode durfte ab diesem Zeitpunkt nicht mehr öffentlich zugänglich gemacht werden.
Auch die Verwendung in Vorlesungen etc. war ausgeschlossen. Auch für auf BSD basierende Systeme wurden – da ein Teil des Codes von AT&T stammte – hohe Lizenzgebühren erhoben.
Viele Firmen lizenzierten den UNIX-Quellcode und brachten ihre eigenen Varianten auf den Markt, selbst Microsoft hatte mit Xenix einige Zeit ein Unix im Angebot.
GNU
Die Nichtverfügbarkeit des Quellcodes veranlasste Richard Stallman, 1983 das GNU-Projekt („GNU's Not Unix“) ins Leben zu rufen.
Ziel des Projekts war die Schaffung eines freien Unix-kompatiblen Betriebssystems. Bis 1990 hatte das Projekt alle wesentlichen Teile – inklusive des GNU-C-Compilers – entwickelt, jedoch mit Ausnahme des Kernels.
Minix
1987 erschien das Lehrsystem Minix, entwickelt von Andrew S. Tanenbaum an der Freien Universität Amsterdam.
Minix war ein Unix-Klon mit Mikrokernel, C- Compiler, Texteditor und vielen Kommandos, das auf anspruchsloser PC -Hardware lief.
Der Quellcode war Teil des Lieferumfangs. Es war zwar kommerziell und proprietär, hatte aber einen sehr niedrigen Preis. Wie vormals Unix diente dieses System vielen als Ausgangspunkt für eigene Experimente.
Linux
1991 arbeitete der Student Linus Torvalds an einem Terminal-Emulator, mit dem er auf einen Uni-Computer zugreifen wollte.
Mit der Zeit baute er Dateisystem-Zugriff und viele andere nützliche Features ein. Bald bemerkte er, dass er mehr als einen Terminal-Emulator programmierte.
Den Sourcecode veröffentlichte er in der Newsgroup comp.os.minix als Betriebssystemkern, das auf einem Intel - 386er -PC lauffähig sein sollte.
Ein anderes Projekt rund um ein Betriebssystem aus freier Software war in den 1980er Jahren auch die Berkeley Software Distribution, kurz BSD.
Diese hatte sich aus Eigenentwicklungen der Universität Berkeley aus den Unix-Versionen der 4er Edition und folgender von AT&T entwickelt.
Da aber in den BSD-Versionen noch immer Code von AT&Ts Unix enthalten war, kam es Anfang der 1990er Jahre zu einem Rechtsstreit zwischen AT&T und der Universität Berkeley, der die Entwicklung von BSD stark einschränkte und einige Jahre stark verlangsamte.
1992 erschien mit 386BSD von Bill Jolitz ein weiteres freies System für 80386-Prozessoren. * Es bestand aus einem Patch für die nicht von AT&T stammenden freien Teile der BSD-Distribution und bildete ein weiteres freies, sehr fortgeschrittenes Betriebssystem für Intel-Prozessoren.
1994 veröffentlichte Berkeley mit 4.4BSDLite die letzte Version ihrer Distribution, die von AT&T-Quellcode befreit war. * Dieses bildete zusammen mit 386BSD die Grundlage für NetBSD, FreeBSD und kurz darauf OpenBSD.
2000 gab Apple den Quelltext des Betriebssystems Darwin, Bestandteil von Mac OS X, frei. * Es basiert auf 4.4BSD und dem Mach -Mikrokernel
Der Darwin-Kernel von Mac OS X ist ein Hybridkernel
der versucht die Vorteile eines monolithischen mit denen eines Mikrokernels zu verbinden
Seit 2005 ist auch Solaris (Version 10) in der jeweils aktuellen Fassung für die gebührenfreie Benutzung erhältlich.
Solaris läuft auf 32-Bit-Prozessoren (x86) von AMD und Intel sowie auf 64-Bit-Systemen mit Suns UltraSPARC und sogenannten x64-Systemen wie zum Beispiel AMDs Opteron.
Für Zugriff auf Quellen und Mitarbeit inklusive Erweiterung ist es in der Fassung OpenSolaris erhältlich, die sich funktionell nicht von der Binärversion unterscheidet.
Sun Microsystems verlangt allerdings eine Registrierung und hat eigene Lizenzbestimmungen, die von der GNU GPL abweichen.
Im engeren Sinne mein der Begriff nur den Kern des Betriebssystems. Im Alltag wird mit „Linux“ oft das Gesamtsystem aus Kernel, Betriebssystemumgebung und Anwendungen gemeint.
Modular Aufbau
Ein wichtiger Aspekt ist der modulare Aufbau des Systems und der Tatsache, dass diese Module in vielen verschiedenen Projekten von Softwareentwicklern auf der ganzen Welt entwickelt werden.
Die folgende Darstellung gibt einen interessanten Überblick über die möglichen Teile eines Linux-Systems:
Mittlerweile verdienen eine Reihe von Firmen mit Linux Geld. Diese Firmen, von denen die meisten auch Mitglieder der Open Source Development Labs sind, investieren teilweise erhebliche Ressourcen in die Weiterentwicklung und den Ausbau von Linux, um es für verschiedene Einsatzbereiche tauglich zu machen.
Dies reicht von Hardwarespenden an Entwickler über Treiber und Geldspenden für Stiftungen, die sich mit Linux-Software beschäftigen, bis hin zur Anstellung von Programmierern bei der Firma selbst.
Bekannte Beispiele dafür sind IBM und HP, die Linux vor allen Dingen auf den eigenen Servern einsetzen, als auch Red Hat, das eine eigene Distribution unterhält.
Ebenso unterstützt Trolltech Linux durch die Entwicklung und der GPL-Lizenzierung von Qt, was die Entwicklung von KDE erst möglich macht, und durch die Förderung einiger X- und KDE-Entwickler.
Sie erhalten Support von zahlreichen Internet Quellen
Community-Support* Foren
Newsgroups
Mailinglisten und
Ungezählten WWW-Seiten.
Dem Programmierer einer Software direkt eine Mail schreiben.
Lokale Linux oder Unix User Group Kontakt aufnehmen.
Kommerzielle Support * Distributoren
Einige Entwickler bieten auch kommerziellen Support an
IT-Dienstleister, die Linux einsetzt
Eine Liste solcher Firmen erscheint z.B. im Linux-Magazin (www.linux-magazin.de).
Entstehung von Linux
Als Linux Anfang der 1990er Jahre das Licht der Welt erblickte, war das nur möglich, weil viele Menschen zuvor die Grundlagen dafür die Grundlagen gelegt haben.
Seit seiner ersten Veröffentlichung hat sich Linux, ein auf GNU basierendes Betriebssystem, stark weiterentwickelt. Es gab Streit um den Namen und neue Unterstützer sind ebenso hinzugekommen, wie auch Gegner.
1983 gründete Richard Stallman das GNU-Projekt mit dem Ziel, ein UNIX -ähnliches, POSIX -kompatibles Betriebssystem zu schaffen.
Zwei Jahre später gründete er die Free Software Foundation (FSF) und schrieb die GNU General Public License (GPL), um freie Software im Copyright -System zu ermöglichen.
Auf diesem Wege verbreitete sich die GNU-Software sehr schnell und wurde von vielen Menschen weiterentwickelt.
Es entstand in kurzer Zeit eine Vielzahl von Programmen, so dass bereits Anfang 1990 genug GNU-Software bereitstand, um ein eigenes Betriebssystem daraus zu erstellen.
Allerdings fehlte noch immer ein Kernel. Dieser sollte eigentlich im Projekt GNU Hurd entwickelt werden.
Doch der als Mikrokernel ausgelegte Kern entwickelte sich nur sehr schleppend, weil das Finden und Beheben von Fehlern (Debuggen) aufgrund technischer Besonderheiten sehr schwierig und aufwändig war. Anfang der 1990er gab es also kein vollständiges, freies System.
Die Zukunft von BSD war wegen des Rechtsstreits ungewiss, die Weiterentwicklung gelähmt.
das GNU-Projekt wurde zwar konstant weiterentwickelt und ausgebaut, verfügte aber über keinen UNIX-artigen Kernel,
vielmehr war es eine Anzahl freier Softwareprojekte, die auf den verschiedensten (proprietären) UNIX-Varianten mittels des GNU-Compilers übersetzt werden konnten und lauffähig waren.
1987 entwickelte der in Amsterdam lehrende amerikanische Informatiker Professor Andrew S. Tanenbaum ein Unix-ähnliches Betriebssystem namens Minix.
Minix sollte der Lehre dienen, um seinen Studenten die Grundlagen eines Betriebssystems zu veranschaulichen, da die zunehmend restriktiveren AT&T-Lizenzen für Unix ihn bei der Arbeit behinderten. Minix selbst gewann nie groß an Bedeutung.
Größtes Manko von Minix waren die durch den Autor beschränkten Erweiterungsmöglichkeiten im Kernel, so dass z.B. das X-System niemals unter Minix laufen kann.
Es inspirierte jedoch Linus Torvalds zur Arbeit am Linux-Kernel.
Um seinen 386er genauer zu inspizieren, schrieb ein finnischer Student namens Linus Torvalds im Jahr 1991 einige Assemblerroutinen, die schließlich ein minimales Betriebssystem formten.
Linux erblickte das Licht der Welt, und da Torvalds den Sourcecode an interessierte Minixer verschickte, fanden sich bald weltweit Interessenten zusammen, die fortan über das Internet kommunizierten und ihre neuesten Erweiterungen zu Linux verbreiteten.
Von Anfang an stellte Torvalds seine Sources unter die Verantwortung der GPL, so dass diese frei kopiert werden konnten und jedem Interessenten zur Verfügung standen.
Gleichzeitig war man bei der Entwicklung auf Konformität zum POSIX-Standard bedacht, wodurch Linux ohne großen Aufwand auf andere Hardware-Plattformen portierbar wurde.
1991 begann Linus Torvalds in Helsinki mit der Entwicklung des Kernels, der später Linux genannt wurde. Anfänglich war es eine Terminalemulation, die Torvalds zum Zugriff auf die großen UNIX - Server der Universität benutzte.
Er schrieb das Programm hardwarenah und unabhängig von einem Betriebssystem, weil er die Funktionen seines neuen PCs mit einem Prozessor des Typs 80386, dessen Nachfolgerserie x86 auch heute noch zum Standard zählt, optimal nutzen wollte. Als Grundlage dienten dabei das Minix-System und der GNU-C-Compiler.
Irgendwann, so Torvalds in seinem Buch Just for Fun merkte er, dass er eigentlich ein Betriebssystem geschrieben hatte.
Am 25. August 1991 kündigte er in einem Usenet -Posting an die Gruppe comp.os.minix dieses System an. Dieses Usenet-Posting wird an vielen Stellen immer wieder zitiert und dürfte zu den bekanntesten Postings im Usenet zählen.
Am 17. September 1991 wurde Linux in der Version 0.01 das erste Mal öffentlich auf einem FTP-Server zur Verfügung gestellt.
Eigentlich sollte Linux nach dem Willen von Linus Torvalds Freax heißen, eine Wortschöpfung aus Freak (Verrückter, aber auch jemand, der sich für etwas begeistert), Free für Freie Software und dem oftmals üblichen x in Anspielung auf die Ähnlichkeit zu Unix.
Aus diesem Grund hatte Torvalds zu Beginn seiner Arbeit an dem System etwa ein halbes Jahr lang die Dateien unter Freax abgelegt.
Auch den Namen Linux hatte sich Torvalds bereits überlegt, er erschien ihm aber zu egozentrisch.
Um anderen Leuten die Möglichkeit zu geben, am System mitzuarbeiten oder Verbesserungsvorschläge zu machen, sollten die Dateien im September 1991 auf dem FTP-Server (ftp.funet.fi) der Helsinki University of Technology (HUT) abgelegt werden.
Der damalige Verantwortliche für den Server, Ari Lemmke (Mitarbeiter am HUT), war mit dem Namen Freax nicht einverstanden, er bevorzugte den Arbeitsnamen Linux.
Ohne mit Torvalds darüber zu diskutieren, nannte er den Bereich am Server einfach Linux, was Torvalds schließlich akzeptierte, um große Diskussionen zu vermeiden und auch, wie Torvalds zugibt, weil Linux einfach der bessere Name war.
Im Sourcecode der Version 0.01 von Linux kam noch der Name Freax vor („Makefile for the FREAX-kernel“), später wurde nur noch der Name Linux verwendet. So setzte sich der eigentlich gar nicht geplante Name Linux weltweit durch.
Linux unter der GNU GPL
Torvalds gab Linux zuerst unter einer eigenen, proprietären Lizenz heraus, entschied sich aber später dafür, die GNU GPL den übrigen Urhebern vorzuschlagen.
Im Changelog zur Version 0.12 im Januar 1992 kündigt er die Lizenzänderung an. Die Mitte Dezember 1992 veröffentlichte Version 0.99 ist die erste Version unter der GNU GPL.
Dieser Schritt machte es erst möglich, Linux als freies Betriebssystem zu vertreiben.
Dieses Ereignis zog weltweit viele Programmierer an, die sich an der Entwicklung von Linux und GNU beteiligten.
Später sagte Linus Torvalds in einem Interview, dass die Entscheidung, Linux unter die GNU GPL zu stellen, die beste gewesen sei, die er je getroffen habe: „Making Linux GPL'd was definitely the best thing I ever did.“
Die Bezeichnung Linux wurde von Torvalds anfänglich nur für den von ihm initiierten Kernel genutzt.
Der Kernel wurde aber häufig zusammen mit anderer Software, vor allen der des GNU-Projekts ausgeliefert.
Diese GNU-Variante wurde schnell zur meist genutzten Variante von GNU, da es zu dieser Zeit keinen anderen funktionierenden freien Kernel gab.
Als im Laufe der Zeit der Name Linux auch häufig für diese Softwaresammlungen genutzt wurde, versuchte der Gründer des GNU-Projekts, Richard Stallman, bald, den Namen GNU/Linux durchzusetzen, um der Rolle von GNU eine in seinen Augen angemessene Geltung zu verschaffen.
Im Juni 1994 wurde im GNU’s Bulletin mit „freier UNIX-Klon“ auf Linux verwiesen und im selben Jahr gab das Debian -Projekt seiner GNU/Linux-Distribution den Namen GNU/Linux.
In der Januarausgabe 1995 des GNU’s Bulletin änderten sich die Verweise auf Linux zu GNU/Linux. Im Mai 1996 gab Richard Stallman den Editor Emacs 19.31 heraus, in dem der Systemtyp von Linux nach Lignux umbenannt wurde.
Er meinte, es wäre angemessen, die Begriffe Linux-based GNU system, GNU/Linux system oder Lignux zu benutzen, um auf die Kombination von Linux-Kernel und GNU-Software hinzuweisen.
Er gab jedoch bald den Ausdruck Lignux auf und benutzte nur noch GNU/Linux.
Insgesamt stieß die Forderung auf unterschiedliche Reaktionen. Während das GNU-Projekt und das Debian -Projekt den Namen annahmen, lehnten die meisten Entwickler und anderen Linux-Distributoren dies ab oder widersetzten sich deutlich.
Begründet wurde dies einerseits mit Bequemlichkeit, weil der Name Linux als einfacher angesehen wurde, und andererseits mit dem Hinweis, dass mittlerweile eine beachtliche Menge der mit Linux ausgelieferten Software nicht aus dem GNU-Projekt stamme.
Ein Grund für das Ausbleiben des Begriffs»GNU/Linux«ist sicherlich, dass»Linux«einfach ein deutlich einfacherer, griffigerer Begriff ist. Das System einfach»GNU«zu nennen und den Kernel dabei unter den Tisch fallen zu lassen, traut sich niemand.
Ein weiterer Grund für die weit verbreitete Nutzung des Begriffs»Linux«für das System ist wohl, dass Linus Torvalds es seit der Veröffentlichung 1992 schon immer Linux genannt hatte.
Stallman hingegen meldete seine Forderung nach Namensänderung erst an, nachdem das System bereits populär geworden war.
1996 kündigte Torvalds ein Maskottchen für Linux an, es sollte ein Pinguin werden.
Die Bedingungen, die an das Maskottchen gestellt wurden, finden sich unter anderem in Torvalds Biografie Just For Fun:
„Aber Linus wollte keinen x-beliebigen Pinguin. Sein Pinguin sollte glücklich aussehen, so als hätte er grade eine Maß Bier genossen und den besten Sex seines Lebens gehabt.“
Larry Ewing erstellte daraufhin den ursprünglichen Entwurf des heute bekannten Maskottchens.
Den Namen Tux schlug James Hughes als Ableitung von Torvalds Uni X vor.
Ein weiterer Grund für diese Konstruktion ist vermutlich auch, dass die Farben der Pinguine den Eindruck vermitteln, als würden sie einen Smoking tragen, der im Englischen tuxedo heißt.
Der größte Teil der Arbeit an und um Linux wird durch die Community, also durch freiwillige Mitarbeiter auf der ganzen Welt, erledigt.
Diese teilweise auch von Firmen unterstützten oder direkt angestellten Programmierer und Entwickler helfen nicht nur direkt bei der Entwicklung des Kernels, sondern auch beim Schreiben der gesamten Zusatzsoftware, die für und rund um Linux zur Verfügung steht.
Dabei gibt es sowohl die vollständig frei und selbstorganisierten Projekte wie Debian, aber auch die mit Firmen direkt verbundenen Projekte wie Fedora Core und openSUSE.
Die Mitglieder der jeweiligen Projekte treffen bei verschiedenen Konferenzen und Messen zusammen, um sich auszutauschen.
Eine der größten Messen ist dabei der LinuxTag, bei dem jährlich etwa 10.000 Menschen zusammen kommen, um sich über Linux und die darum angesiedelten Projekte zu informieren und auszutauschen.
Open Source Development Labs
Die Open Source Development Labs (OSDL) wurden im Jahr 2000 gegründet und sind eine unabhängige und gemeinnützige Organisation, die das Ziel verfolgt, Linux für den Einsatz in Daten-Centern und im Carrier-Bereich zu optimieren.
Es dient als gesponserte Arbeitsstelle für Linus Torvalds und lange Zeit auch für Andrew Morton, der aber Mitte 2006 zu Google wechselte, in dessen Auftrag er seit dem am Linux-Kernel arbeitet.
Torvalds kümmert sich im Auftrag des OSDL in Vollzeit um die Entwicklung des Linux-Kernels.
Finanziert wird die nichtkommerzielle Einrichtung von namhaften Firmen wie Red Hat, Novell, Mitsubishi, Intel, IBM, Dell und HP.
Streit um Linux
Im Laufe der Jahre musste sich Linux gegen Angriffe von verschiedenen Seiten und auf verschiedenen Ebenen verteidigen. Immer wieder gab es Streit um das System.
1992 kam es durch einen Usenet-Artikel Andrew S. Tanenbaums in der Newsgroup comp.os.minix mit dem Titel „Linux is obsolete“ zu einer berühmt gewordenen Debatte um die Struktur des Linux-Kernels, in dem der anerkannte Informatiker und Autor des Mikrokernel -Systems Minix Tanenbaum eine ganze Reihe von Kritikpunkten an dem damals noch recht jungen Linux-Projekt anbrachte.
Vor allem kritisierte er * das Design des Kernels als monolithisch und damit als unzeitgemäß
die in seinen Augen schlechte Portierbarkeit durch Ausnutzung sämtlicher Funktionen der Intel-386-Prozessoren
das liberale Verteilungs- und Entwicklungsmodell der Software, ohne strenge Kontrolle des Quellcodes durch eine einzelne Person
den Einbau einer Reihe von Funktionen, die aus Tanenbaums Sicht unnütz waren (so erachtete er ein Dateisystem, das den parallelen Zugriff mehrerer Programme gestattet, als überflüssigen performance hack)
Rückblickend kann man heute sagen, dass Tanenbaum mit seiner Prognose, Linux sei innerhalb weniger Jahre veraltet und durch ein (aus seiner Sicht) modernes GNU Hurd ersetzt, falsch lag.
Linux ist auch auf alle wichtigen Plattformen portiert worden. Das liberale Entwicklungsmodell hat zu einer beispiellosen Geschwindigkeit bei der Weiterentwicklung geführt, GNU Hurd ist immer noch nicht so weit, dass man es auf einem Server einsetzen könnte.
==== Das Buch Samizdat
neuer text aus wiki-artikel
Linux – ein Plagiat?
====
Jahre später wurde Andrew Tanenbaum erneut mit Linux in Verbindung gebracht.
Als Ken Brown sein bis heute nicht erschienenes Buch Samizdat schrieb und deshalb mit Tanenbaum sprach, erklärte dieser, Torvalds habe nicht von ihm abgeschrieben.
In seiner Stellungnahme zu Brown schrieb er einen Abschnitt, der sein Verhältnis zu Linux gut dokumentiert: Natürlich habe Torvalds sein Buch und Minix gekannt.
Obwohl es Torvalds nach eigener Aussage nicht interessierte, ob Microsoft (Hersteller u.a. des Betriebssystems Windows) durch Linux in der Vergangenheit in Bedrängnis geriet (1997–2001), wurde von beiden Seiten ein harter Konkurrenzkampf ausgetragen.
Das erste Mal äußerte sich dies deutlich, als Ende Oktober 1998 das erste Halloween-Dokument von Eric S. Raymond an die Öffentlichkeit gebracht wurde.
Dieses von einem Microsoft-Entwickler verfasste Dokument beschäftigt sich ausführlich mit den Gefahren freier Software für Microsoft und zeigt Strategien auf, diesen zu begegnen.
Die Free Software Foundation distanzierte sich von der dadurch ausgelösten Verachtung, die sich speziell auf Microsoft bezog, und erinnerte die Community daran, dass jeder Produzent proprietärer Software den Software-Anwendern schade.
Anfang 2004 erreichte der Konkurrenzkampf eine neue Phase, als Microsoft eine Reihe von in Auftrag gegebenen Studien zum Thema „Windows vs. Linux“ unter dem Namen „Get the Facts“ auf einer eigenen Webseite veröffentlichte.
Die Studien sollten anhand von Umfragen, Erhebungen und Untersuchungen nachweisen, dass sich der Betrieb von Linux auf Servern verglichen mit Windows nachteilig auswirkt.
Die kommerziellen Anbieter von Linux-Software bemühten sich daraufhin, ebenfalls durch Studien, Umfragen und Erfahrungsberichten, Microsofts Kampagne etwas entgegenzustellen.
So hat Novell Ende 2004 eine eigene Webseite unter dem Titel „Die reine Wahrheit“ geschaltet, auf der die Vorteile als auch die rechtliche Sicherheit von Linux hervorgehoben werden.
Im Herbst 2006 kündigten Novell und Microsoft aber an, künftig bei den Themen Interoperabilität und Patentschutz zusammenarbeiten zu wollen.
Im Rahmen der Virtualisierung wurde vereinbart, den Austausch von Office-Dokumenten zu verbessern, die Virtualisierung der Enterprise-Lösungen jeweils unter dem Konkurrenz-Produkt zu vereinfachen, sowie die Eingliederung von Linux- und Windows-Maschinen in eine gemeinsame Directory-Struktur zu vereinfachen.
Der Patentschutz sah gleichzeitig vor, dass Kunden eines Anbieters für die Nutzung dessen Software vom jeweils anderen Anbieter nicht wegen Patentverletzung verklagt werden dürfen.
Dieser Patentschutz wurde auch auf nicht-kommerzielle Freie-Software-Entwickler ausgedehnt. Gerade der letzte Schritt erntete auch Kritik, da er nur nicht-kommerzielle Entwickler mit einschloss.
2003 erhob die Firma SCO schwere Vorwürfe gegen den Weltkonzern IBM: Laut der Darstellung von SCO haben IBMs Linux-Entwickler Code unverändert aus UNIX übernommen und in Linux eingepflegt.
Da SCO für sich die Urheberrechte an UNIX beansprucht und in dem Verhalten von IBM eine Verletzung der eigenen Rechte sieht, wurde eine Klage gegen IBM angestrengt.
Gleichzeitig verkauft SCO seit dem Beginn des Verfahrens Linux-Lizenzen an Nutzer, die keine mögliche Klage von Seiten SCOs riskieren wollen.
Aber auch das Urheberrecht rund um UNIX ist nicht geklärt: Da Novell dieses ebenfalls für sich beansprucht, eröffnete es ein Verfahren gegen SCO.
Markenrecht am Namen
kürzen
1994 und 1995 hatten mehrere Personen in verschiedenen Ländern versucht, den Namen Linux als Markennamen eintragen zu lassen. Daraufhin ergingen an mehrere Linux-Firmen Aufforderungen zu Lizenzzahlungen, womit viele Entwickler und Anhänger des Linux-Systems nicht einverstanden waren.
Linus Torvalds ging mit Hilfe von Linux International gegen diese Eintragungen vor und bekam die Markenrechte der Marke Linux zugeteilt. Diese übergab Torvalds an Linux International, später übernahm diese Arbeit die dafür gegründete, nicht gewinnorientierte Organisation Linux Mark Institute. 2000 legte Linus Torvalds die Grundregeln für die Vergabe der Lizenzen fest.
Diese besagen, dass jeder, der ein Produkt oder eine Dienstleistung mit dem Namen Linux anbietet, eine Lizenz dafür besitzen muss, welche durch einen einmaligen Kauf erlangt werden kann.
Ausnahmen bilden dabei nicht-kommerzielle Verwendungen, die eine kostenlose Lizenz erhalten können oder keine benötigen. Im Juni 2005 kam ein neuer Streit um die Lizenzgebühren für die Benutzung des geschützten Markennamens Linux auf, weil das Linux Mark Institute, welches Linus Torvalds Rechte vertritt, Preise von 5.000 Dollar statt bislang 500 Dollar für die Verwendung des Namens angekündigt hatte.
Begründet wurde der Schritt mit den gestiegenen Kosten für die Durchsetzung der Rechte am Markennamen. In der Community sorgte diese Erhöhung für Unmut und Missverständnisse, weshalb sich Linus Torvalds am 21. August 2005 selbst zu der Thematik zu Wort meldete, um die Wogen zu glätten und die Missverständnisse aufzulösen.
In einer E-Mail erläuterte er ausführlich die aktuelle Situation sowie die Hintergründe und ging auch auf die Frage ein, wer Lizenzkosten zahlen müsse.
Linux-Einsatzbereiche
Linux wurde ursprünglich als Terminal-Emulator für Computer mit einem x86-Prozessor geschrieben. Mit dem wachsenden Erfolg des Programms wurden die Einsatzmöglichkeiten erweitert.
Dieser Artikel gibt einen Überblick über die technischen Einsatzmöglichkeiten von Linux; diese können von Privatpersonen, Unternehmen und auch öffentlichen Einrichtungen genutzt werden.
Linux als Server
Bild
Aufgrund der Verwandtschaft von Linux mit UNIX hat sich Linux auf dem Servermarkt besonders schnell etabliert.
Da für Linux schon früh viel häufig verwendete und benötigte Serversoftware wie Webserver, Datenbankserver und Groupware kostenlos und weitgehend uneingeschränkt zur Verfügung stand, wuchs dort der Marktanteil stetig.
Da Linux als stabil, sicher und einfach zu warten gilt, erfüllt es auch die besonderen Bedingungen, die an ein Server-Betriebssystem gestellt werden.
Der modulare Aufbau des Linux-Systems ermöglicht zusätzlich das Betreiben kompakter, dedizierter Server. Außerdem hat die Portierung von Linux auf verschiedenste Hardware-Komponenten dazu geführt, dass Linux alle bekannten Serverarchitekturen unterstützt.
Marktanteile
aktualisieren
Gemessen am Umsatz wurde der Marktanteil von Linux 2005 bei mit Betriebssystem verkauften Servern je nach Studie und Zählweise auf etwa 12% geschätzt.
Das jährliche Wachstum betrug dabei etwa 35%. Nach Stückzahlen gemessen lag das Wachstum bei 20,5%.
Dieses Wachstum geht teilweise auch auf Kosten traditioneller UNIX-Systeme, die durch Linux abgelöst werden.
Die Firmen, die früher ein eigenes UNIX entwickelt und verkauft haben, verkaufen zunehmend Rechner mit Linux und beteiligen sich immer stärker an der Entwicklung von Linux.
Der größte Konkurrent für Linux auf dem Servermarkt ist Microsoft Windows, das Studien zu Folge 2005 einen Anteil von etwa einem Drittel am Gesamtmarkt hatte.
Die Zählungen der Studien sind aber nur bedingt repräsentativ, da Linux auf beliebigen Geräten installiert werden kann, ohne dass dafür eine Lizenz entrichtet werden muss.
So entsteht eine unbekannte Dunkelziffer an Linux-Servern, die von den Studien nicht erfasst werden.
Einsatzbeispiele
Webserver - LAMP-Systeme
Eines der wohl bekanntesten Beispiele für eine Linux-Server-Konfiguration ist LAMP.
LAMP steht dabei als Abkürzung für den kombinierten Einsatz der Softwareprodukte Linux, Apache, MySQL und PHP (manchmal auch Perl oder Python).
Diese Kombination ermöglicht es, auf einem Computer einen Webserver zu betreiben, der beim Aufruf der Seiten mit dem Webbrowser dynamische Inhalte aus Datenbanken zu generieren, und auch Inhalte wieder in diese Datenbank zu schreiben.
Ein bekanntes Beispiel für einen solchen Einsatz ist die Software MediaWiki, die auf einem LAMP-System läuft.
LDAP
Ein anderer häufiger Einsatzbereich von Linux ist die Nutzung von Samba, oft auch in Verbindung mit einem LDAP-Verzeichnisdienst.
Während der Verzeichnisdienst eine zentrale Anmeldung von Windows- und Linux-Clients ermöglicht, ermöglichen die Fähigkeiten von Samba den Dateiaustausch zwischen Computern mit Linux-Betriebssystemen und Computern mit Windows-Betriebssystemen.
SAMBA
So ermöglicht Samba, in gemischten Netzwerken einen Linux-Rechner als zentralen Datei- und Drucker-Server einzusetzen.
Dabei werden alle wichtigen Dateien an einem zentralen Punkt gespeichert, und so mehreren Nutzern gleichzeitig zur Verfügung gestellt.
Da Samba ebenso wie Linux von seinen Nutzern für seine Stabilität, Performance und Skalierbarkeit gelobt wird, eignet sich die Kombination sehr gut für zentrale und wichtige Knotenpunkte von großen Netzwerken, bei denen eine heterogene Umgebung vorliegt.
Als Beispiel kann das Projekt MigOS des Deutschen Bundestags gelten. Hierbei wurden insgesamt über 100 Server von Windows NT auf Linux umgestellt.
Die etwa 5000 Arbeitsplatzrechner (mit Windows) der Abgeordneten und Verwaltungsangestellten wurden über Samba und OpenLDAP eingebunden.
VOIP
Neben diesen weit verbreiteten Einsatzbereichen gibt es noch eine Reihe weiterer Server-Software, die unter Linux betrieben wird. So wird die Software-Telefonanlage Asterisk häufig als zentrale Schnittstelle in Firmennetzen genutzt.
DNS- und Mailserver
Ebenso werden viele für Netzwerke elementare Dienste auf Linux-Rechnern betrieben. Dazu gehören sowohl DNS-Server als auch Mailserver und Datenbankserver.
Gameing-Server
Interessanterweise werden auch viele Server von Online-Spielen, so genannte Spieleserver unter Linux betrieben, selbst dann, wenn das eigentliche Spiel nicht unter Linux zur Verfügung steht.
Mit den grafischen Benutzeroberflächen wie KDE oder GNOME bietet Linux im Bereich der Desktops mittlerweile einen vergleichbaren Komfort zu Microsoft Windows oder Mac OS. Umfangreiche Tests der Umgebungen auf Benutzerfreundlichkeit und Effizienz ermöglichen ein Nutzen des Computers ohne besondere Kenntnisse.
Techniken wie Xgl oder AIGLX ermöglichen darüber hinaus hardware-beschleunigte, grafische Effekte auf dem Desktop.
Neben dem wachsenden Angebot proprietärer Software für Linux hat vor allen Dingen die Community das Softwareangebot für Linux stetig vergrößert und in unterschiedlichste Bereiche ausgedehnt:
Mit der Zeit sind immer mehr freie Softwareprojekte entstanden, die von Entwicklungsumgebungen über Businessanwendungen bis hin zu komplexen Multimediaanwendungen reichen.
Die Windows-API-Nachbildung Wine erlaubt es außerdem, mit einer stetig steigenden Anzahl von für Windows geschriebenen Programmen auch unter Linux zu arbeiten.
Die auf den Desktop ausgelegten Distributionen lassen sich einfach installieren, es werden aber auch zunehmend Komplettrechner mit vorinstalliertem Linux ausgeliefert, was der Verbreitung als Einzelplatzsystem Vorschub leistet.
Im Bereich mit Masseninstallationen wie in Firmen oder Behörden hat Linux durch groß angelegte Migrationen z.B. in München oder Wien von sich Reden gemacht.
Der Erfolg eines Desktopsystems wird aber auch durch die Verbreitung von Spielen entschieden.
Einige neue Spiele der großen Spielehersteller kommen auch in Linuxversionen heraus, so stehen z.B. auch id Softwares grafiklastige Spiele Doom 3, Quake 4 sowie die Teile 1 bis 3 der Quake-Reihe für Linux zur Verfügung.
Eine anspruchsvolle Computerinstallation ist der PC als Schreibtischgerät.
Der Benutzer soll mit ihm arbeiten können, ohne sich des technischen Hintergrunds des Systems bewusst sein zu müssen.
Eine typische Installation einer Linux-Distribution enthält einen X11 -Grafikserver sowie eine Desktopumgebung und wichtige Anwenderprogramme.
Dazu gehören sowohl Office-Programme wie OpenOffice.org, als auch Programme zur Bildbearbeitung (häufig Gimp), Browser und E-Mail-Programme.
Bei Installationen für Firmen und Büros kommen noch andere Programme wie zum Beispiel zur Unternehmensplanung hinzu. Für Entwickler gibt es Entwicklerwerkzeuge wie Eclipse oder KDevelop.
Marktanteile
aktualisieren
In der Praxis wird Linux eher zögerlich im Desktop-Bereich eingesetzt.
Die Verbreitung kann wegen der kostenlosen und dezentralen Verfügbarkeit nur schwer abgeschätzt werden.
Zahlen liegen dementsprechend kaum vor, einer Erhebung zufolge lief Linux aber auf 2,8% aller 2002 verkauften Rechner.
Die Gründe für die geringe Verbreitung werden kontrovers diskutiert.
So wird häufig das faktische Monopol des Betriebssystems Windows und die daher notwendige Umgewöhnung der Benutzer auf ein neues System genannt.
Als Grund wird häufig genannt, dass das Installieren von Software aus Dritt-Quellen oft schwerer zu handhaben sei als beispielsweise unter Windows.
Datei:.pngGNOME-Desktop mit Epiphany, Nautilus und „Datei öffnen“-DialogGrafische Oberflächen
KDE
K Desktop Environment
GNOME
GNU Network Object Model Environment
TWM
Tab Window Manager
VTWM
Virtual Tab Window Manager
CDE
Common Desktop Environment
Heutzutage sind viele übliche Funktionen des Systems über intuitive Benutzeroberflächen administrierbar, einige Funktionen zur Feinabstimmung sind vergleichsweise umständlich zu handhaben.
Aus diesem Grund wird bei der Weiterentwicklung der direkten Schnittstelle mit dem Nutzer, der Desktopumgebung, immer mehr Wert auf eine benutzer- und einsteigerfreundliche Gestaltung gelegt.
Die beiden größten Desktopumgebungen für Linux, GNOME und KDE, haben dafür Richtlinien erstellt, die von jedem Programm und jeder Funktion eingehalten werden sollten, um dem Benutzer ein einheitliches Erscheinungsbild und Bedienkonzept (Look & Feel) zu bieten.
Da die Richtlinien beider Desktops voneinander abweichen, erscheinen Programme der einen Umgebung in der anderen Umgebung fremdartig.
Diesem Problem soll durch Standardisierung und Zusammenarbeit der Projekte begegnet werden. Am bekanntesten ist hier die Initiative freedesktop.org. Auch die Linux Standard Base hat eine eigene Projektgruppe, die LSB Workgroup, ins Leben gerufen.
Hier liegt der Schwerpunkt in der Schaffung verlässlicher Standards für Entwickler grafischer Programme für Linux-Desktops. Andere Projekte kümmern sich auch um Einzelbereiche, dazu gehört z.B. das Tango!-Projekt, welches ein einheitliches
Aussehen durch Gestaltungsrichtlinien und die Verwendung einheitlicher Icons (Schaltflächen) zu erreichen versucht.
Projekte wie Xgl oder AIGLX bemühen sich außerdem darum, mit Hilfe von Composition Managern hardwarebeschleunigte 3D-Effekte auf den Desktop zu bringen, und diesen so noch ansprechender zu gestalten.
Um die Entwicklung und auch die Verbreitung von Linux auf dem Desktop voran zu bringen, hat sich in der Linux Foundation die The Desktop Linux Working Group gebildet, die alle Kräfte bündeln und koordinieren soll, die sich mit der Thematik beschäftigen.
Multimedia
Datei:.pngEin Programm zum Abspielen von Audiodateien: amaroK
Die Multimediaunterstützung wird je nach Nutzerbedarf- und verhalten unterschiedlich bewertet. Der Umgang mit gängigen Musik-Formaten ist kein Problem.
Es existiert eine Reihe von weit entwickelten Musik-Abspielprogrammen unter Linux, die neben der Unterstützung verschiedener Musik-Formate noch mit einer ganzen Reihe komfortabler Extras aufwarten können.
Ein bekanntes Beispiel für ein auf KDE-Bibliotheken basierendes Multimedia-Programm ist dabei Amarok.
Die Unterstützung von aktuellen, auf Desktop-Computern verbreiteten Video-Techniken ist jedoch noch lückenhaft, da LinDVD, die einzige uneingeschränkt legale Unterstützung von verschlüsselten DVDs, kostenpflichtig, closed source und nur als OEM-Produkt (zusammen mit Hardware) erhältlich ist.
So können Probleme mit verschlüsselten DVDs durch Einsatz von DeCSS leicht umgangen werden, dies ist aber in einigen Staaten, so auch in Deutschland, verboten, oder die rechtliche Lage ist unklar. Ebenso gibt es auch keine Linux-Version der beiden weit verbreiteten Multimediaprogramme QuickTime Player und Microsoft Windows Media Player.
Auf der anderen Seite gibt es von ebenfalls weit verbreiteten Programmen wie dem RealPlayer und dem VideoLAN -Player Linux-Versionen. Hinzu kommen einige in erster Linie für Linux programmierte Softwareprojekte, die die vorhandenen Lücken schließen.
Zu nennen sind hier vor allem die Programme MPlayer und Xine, die es auch ermöglichen, Videos in Formaten wie WMV, ASF und ähnlichen abzuspielen, wofür teilweise Windows- Programmbibliotheken eingesetzt werden.
Das Abspielen von DRM-geschützten Audio- und Videodateien ist unter Linux bei den meisten Formaten oft nur in Ausnahmefällen möglich.
Eine deutlich andere Situation zeigt sich im Bereich professioneller Multimedia-Bearbeitung. Mit dem JACK Audio Connection Kit steht unter Linux eine spezielle Sound-Architektur zur Verfügung, die besonders niedrige Latenzzeiten bietet.
Sie wird von Programmen wie Ardour genutzt. In der Filmbranche erfreut sich Linux besonderer Beliebtheit: die Spezialeffekte vieler Filme wurden mit Hilfe von Linux-Rechnerverbünden gerendert. So hat beispielsweise das häufig unter Linux eingesetzte Programm CinePaint bei der Erstellung von Filmen wie den Harry Potter -Verfilmungen geholfen.
Zwischen diesen verschiedenen Situationen ist der Übergang aber fließend. Mit der zunehmenden Entwicklung proprietärer Lösungen auch für Linux ist aber davon auszugehen, dass die vorhandenen Lücken in naher Zukunft geschlossen werden.
Ein Beispiel ist der Bereich des Videoschnitts, bei dem es sowohl proprietäre Lösungen wie das Programm MainActor der Firma MainConcept gibt, als auch Lösungen der Freie Software -Bewegung wie z.B. die Software Kino oder Cinelerra, das für professionelle Hardware ausgelegt ist.
Desktop-Migration
Einige Verwaltungen und Unternehmen erwägen eine Umstellung ihrer Arbeitsplatzrechner von verschiedenen Plattformen zu Linux-Desktops.
Ein bekanntes Beispiel dafür sind die Stadtverwaltungen von Wien und München, die viele ihrer Computer auf die dafür angepassten Distributionen Wienux und Limux umgestellt haben, und der Auto-Hersteller Citroën, der 20.000 Desktops auf Linux umgestellt hat.
Schwierigkeiten entstehen meist dadurch, dass im Unix -Bereich ein völlig anderer Softwaremarkt herrscht.
Bekannte Programme gibt es für diese Plattform oft nicht bzw. werden von anderen, bislang unbekannten Herstellern unter unbekannten Namen herausgegeben und sind oftmals nicht komplett mit der bestehenden Lösung kompatibel.
So kann die technische Umstellung der Zusatzsoftware teuer werden, andererseits müssen sich viele Benutzer auch erst an die neue Desktopumgebung gewöhnen, was eventuell zeit- und kostenintensiv werden könnte.
Ein lohnender Zeitpunkt für eine Umstellung der Firmendesktops ist daher, wenn ohnehin auf ein neues Betriebssystem mit all seinen Neuerungen in der Ablauflogik umgestellt werden muss, da der Hersteller seine alte Version oder den Support dafür aufgekündigt hat.
Die Umgewöhnung eines Sachbearbeiters von Windows NT 4.0 auf Windows XP ist etwa vergleichbar mit der Umgewöhnung von Windows NT 4.0 auf den KDE-Desktop unter Linux.
Da eine Umrüstung auf eine aktuelle Windows-Version sehr oft auch den Kauf neuer Hardware erfordert, setzen viele Institutionen verstärkt auf eine Thin Client -Lösung mit Linux, bei der die rechenintensiven Aufgaben nicht mehr von den Arbeitsplätzen, sondern von zentralen Servern erledigt werden.
Auf diese Weise erspart man sich große Teile eines sonst fälligen Hardware-Updates.
Unterstützung von Windows-Anwendungen
Da sich Linux in der Betriebssystemarchitektur stark von unterscheidet, ist es nicht direkt möglich, Windows-Programme unter Linux zu betreiben. In diesen Fällen bieten sich verschiedene Alternativen an:
Plattformübergreifende Programmierung
Viele Programme aus der Freie-Software-Szene sind für mehr als nur eine Plattform verfügbar.
So gibt es z.B. von den populären Programmen OpenOffice.org, Mozilla Firefox oder auch Gimp Versionen sowohl für Linux als auch für Windows.
Windowsprogramme für Linux
Eine Reihe proprietärer Programme stehen unter Linux zur Verfügung. Gerade im Bereich der wissenschaftlichen Software gibt es viele Programme für beide Plattformen.
Beispiele dafür sind Programme wie MATLAB, Mathematica oder Maple.
Portierung
Bestehende Windows-Programme können auf die Linux-Plattform portiert werden. Dies ist üblicherweise nur ein geringer Programmieraufwand, da lediglich Eigenheiten des Betriebssystems angepasst werden müssen.
Trotzdem ist diese Lösung oft sehr teuer und die Möglichkeit einer Portierung hängt auch von der Firmenpolitik des jeweiligen Softwareherstellers ab.
Eine Portierung ergibt insbesondere dann Sinn, wenn es sich um speziell für den Unternehmens- oder Verwaltungszweck entwickelte Software handelt, oder wenn es auch andere Firmen gibt, die an einer Portierung interessiert sind.
Mittlerweile gibt es auch schon Werkzeuge des WINE -Projekts, die eine automatisierte Softwareportierung ohne großen Programmieraufwand ermöglicht, wodurch man auch in den Genuss einer nativen Lösung für Linux kommt.
Emulation
WINE stellt eine auf Linux übersetzte Variante der Windows-API zur Verfügung.
Damit können einige Programme direkt unter Linux laufen.
Obwohl diese Varianten kein gesamtes Windows-System emulieren, ist diese Lösung manchmal langsamer (manchmal aber auch schneller) und weniger Erfolg versprechend als eine Portierung.
Mit kommerziellen Softwarepaketen, die auf Wine aufbauen, lassen sich aus der Windows-Welt bekannte Programme fast problemlos nutzen.
Dabei bietet CrossOver Unterstützung für zahlreiche Bürosoftware wie Microsoft Office und Adobe Photoshop an, während sich Cedega auf Windows-Spiele spezialisiert hat.
Virtualisierung
Eine weitere Möglichkeit ist der Einsatz einer virtuellen Maschine wie VMware, Bochs oder QEMU, die einen gesamten PC emuliert und es möglich macht, Microsoft Windows darin komplett zu installieren.
Dabei leidet allerdings die Geschwindigkeit deutlich. Auch wird einer der entscheidenden Vorteile einer Migration, die Herstellerunabhängigkeit, so wieder ausgehebelt.
Dualboot
Linux und Windows können parallel auf einem Rechner installiert werden.
Über einen Bootmanager wie zum Beispiel Grub oder Lilo kann ein Nutzer beim Systemstart entscheiden, welches System er starten will.
Damit kann man bei einem Neustart einfach ein anderes Betriebssystem wählen.
Remote-Desktop
Weiterhin besteht die Möglichkeit, Windows-Programme auf einem Windows-Server zu starten und deren grafische Ausgabe mit Hilfe von Remote-Desktop -Software wie z.B. NX oder rdesktop (für RDP) auf Linux Clients ausgeben zu lassen.
Dieses Verfahren erfordert eine ständig bestehende Netzwerkverbindung zwischen beiden Rechnern, ermöglicht aber auch die Weiternutzung betagter Hardware als Thin Clients.
.NET mit Mono
Mit Hilfe der .NET -Implementierung Mono ist es möglich, Programme, die mit Microsofts neuester Programmplattform.NET entwickelt wurden, ohne Portierarbeit direkt unter Linux zu starten.
Bauen die Programme noch auf der DOS -Ebene auf, so lassen sich viele mit dem Programm Dosemu betreiben.
Für DOS-Spiele bietet sich dabei auch DOSBox an. Auch für andere Spielkonsolen und Betriebssysteme gibt es unter Linux Emulatoren.
Umstieg auf Linux-Programme
Für viele Funktionen gibt es unter Linux eigene Programme.
Wenn also ein Programm nicht unter Linux verfügbar ist, so ist meist aber die Funktion in einem anderen Programm verfügbar.
Beispiele dafür sind Programme wie Kontact, Novell Evolution und Konqueror.
Eigene Programme schreiben
Zumindest theoretisch besteht die Möglichkeit, selbst als Programmierer ein Programm zu schreiben, das die benötigten Funktionen enthält.
Da viele freie Oberflächenbibliotheken zur Verfügung stehen, die ohne Lizenzgebühren genutzt werden können, und in den meisten Linux-Distributionen viele Softwareentwicklungswerkzeuge beigefügt sind, bietet sich einem Programmierer eine sehr programmierfreundliche Umgebung.
Der meisten der hier aufgeführten Lösungen sind auf diesem Weg entstanden oder angestoßen worden.
Unterstützung von Menschen mit Behinderungen
Um unter Linux Barrierefreiheit zu gewährleisten, arbeiten mehrere Projekte an der Thematik.
Während die beiden großen Desktops, Gnome und KDE, jeweils eigene Projektgruppen haben, die sich mit der Thematik beschäftigen, gibt es auch Arbeitsgruppen innerhalb der Distributoren oder Gruppen, die Projekt- und Firmenübergreifend arbeiten. Am bekanntesten ist hierbei die FSG Accessibility Workgroup.
Die Arbeit dieser Projekte ermöglicht es unter anderem, unter Linux Braillezeilen zu nutzen, sich aus vielen Programmen
Dokumente und Geschriebenes vorlesen zu lassen oder auf dem Bildschirm nur mit Maus oder nur mit speziellen Tasten zu navigieren.
Hardware
Die Hardware, auf der Linux als Server betrieben werden kann, ist vielfältig.
Da Linux auf eine Vielzahl von Plattformen portiert wurde, kann ein Linux Server ebenso auf handelsüblichen PCs wie auch auf klassischen Serverarchitekturen, wie Alpha oder SPARC betrieben werden.
Ein Beispiel für die Linux-Unterstützung auch modernster Server-Hardware ist der IBM eServer p5. Diese Familie von 64-Bit Servern basiert auf IBM POWER -CPUs, und gehört zu den Schwergewichten der verfügbaren Server-Hardware.
Auf dieser Hardware können mehrere Linux-Installationen parallel gestartet und betrieben werden, um so bis zu 256 gestartete Linux-Systeme parallel betreiben zu können.
IT-Sicherheit
Die Gründe für die Bewertung von Linux als sicheres System sind verschieden und hängen von dessen Aufgaben ab.
So verfügt Linux als Desktop-System über eine strenge Unterteilung der Zugriffsrechte, die bei anderen verbreiteten Desktop-Systemen im Normalfall nicht eingehalten wird.
Dies führt unter anderem dazu, dass viele Funktionsprinzipien verbreiteter Würmer und Viren bei Linux nicht greifen können, beziehungsweise nur den ausführenden Benutzer, jedoch nicht das ganze System kompromittieren können.
Bisher traten nur zwei Viren unter Linux auf, Staog und Bliss.
Im Vergleich zu anderen Desktop-Systemen hat Linux die erste größere Verbreitung bei Nutzern mit einem sehr technischen und sicherheitsbewussten Umfeld erfahren.
Die Entwicklung geschah somit, verglichen mit anderen verbreiteten Desktop-Systemen, unter den Augen eines sehr sicherheitskritischen Publikums.
Im Gegensatz zu Desktop-Systemen hängt die Sicherheit bei Serversystemen primär vom Grad der Erfahrung der Administratoren mit dem System selbst ab.
Linux punktet dabei durch die freie Verfügbarkeit, die es Administratoren ermöglicht, das System ohne Mehrkosten in verschiedensten Testszenarien zu installieren und dort ausgiebig zu untersuchen.
Zudem gibt es eine Reihe von speziell gehärteten Linux-Distributionen, welche besonderen Wert auf Sicherhheitsapsekte legen.
Initiativen wie SELinux bemühen sich dort um das Erfüllen hoher Sicherheitsstandards.
Würmer und Viren können sich immer nur auf dem Teil der Linux-Systeme verbreiten, auf deren Hardware sie zugeschnitten sind. Hinzu kommt, dass Linux quelloffene Software ist.
Jeder kann also den Quellcode studieren, untersuchen und anpassen.
Dies führt unter anderem auch dazu, dass der Quelltext (sei es zum Zwecke der Anpassung, zum Zwecke der Schulung, aus dem Sicherheitsinteresse einer Institution oder eines Unternehmens heraus oder aus privatem Interesse) von mehr Menschen studiert wird, als dies bei proprietären Programmen der Fall sein kann.
Technische Fähigkeiten
Vom technischen Gesichtspunkt her verfügt Linux über viele Fähigkeiten, die eine sicherheitstechnisch anspruchsvolle Umgebung erfordert.
Dazu gehört sowohl eine einfache Nutzer- und Gruppenrechteverwaltung mittels Role Based Access Control, wie auch eine komplexere Rechteverwaltung mit Hilfe von Access Control Lists.
Zusätzlich implementieren viele aktuelle Distributionen auch Mandatory-Access-Control-Konzepte mit Hilfe der SELinux/AppArmor-Technik.
Ebenso bietet fast jede Linux-Distribution auch eine Secure-Shell-Implementierung, mit der verschlüsselte und deswegen sichere Verbindungen zwischen Computern gewährleistet werden können.
Andere Verschlüsselungstechnologien wie Transport Layer Security werden ebenfalls voll unterstützt.
Im Rahmen der Verschlüsselung für auf Medien gespeicherte Daten steht das Kryptographie-Werkzeug dm-crypt zur Verfügung, das eine Festplattenverschlüsselung ermöglicht.
Es bietet dabei die Möglichkeit der Verschlüsselung nach aktuellen Standards wie dem Advanced Encryption Standard. Transparente Verschlüsselung, bei der nur einzelne Dateien statt ganzer Festplatten verschlüsselt werden, stellen die Verschlüsselungserweiterung EncFS oder das Dateisystem ReiserFS zur Verfügung.
Zu den Sicherheitszertifikaten, die im Zusammenhang mit Linux erworben wurden.
Großrechnern
Mit der freien Verfügbarkeit des Quellcodes und der daraus resultierenden Möglichkeit, das System bestimmten Zwecken anzupassen, hat sich Linux auch in den Anwendungsbereichen von Rechenzentren ausgebreitet.
So macht Linux auf Großrechnern, die auf Zuverlässigkeit und hohen Datendurchsatz optimiert sind und häufig in Banken, Versicherungen und großen Unternehmen gefunden werden können, dem dort früher häufig installierten speziellen UNIX-Versionen zunehmend Konkurrenz.
Computercluster
Eine weitere Anwendung ist im Bereich der Computercluster zu finden, bei dem Linux, häufig im Zusammenhang mit Grid-Computing, auf den einzelnen Computern arbeitet, die dann zu großen Netzwerken zusammengeschlossen werden.
Dafür stehen neben speziell angepassten Linux-Distributionen auch besondere Dateisysteme wie z.B. das Global File System zur Verfügung.
Häufig wird auch ein Linux-Cluster genutzt, um damit die Hochverfügbarkeit unternehmenskritischer Netzwerk-Infrastrukturen sicherzustellen.
Supercomputer
Der wohl prestigeträchtigste Einsatz von Linux ist der in Supercomputern. Diese Computer stellen die Spitze aktueller Hochleistungsrechner dar, und ernten aus diesem Grund meist besondere Aufmerksamkeit der Presse.
Eine im Juni 2006 veröffentlichte Studie der 500 schnellsten Supercomputer zeigte, dass über 70% mit Linux betrieben wurden.
Als ein Beispiel sei hier der MareNostrum -Supercomputer genannt, der in Spanien unter anderem in der Klima- und Genforschung eingesetzt wird und unter Linux läuft.
Embedded Linux
Datei:.pngSharp Zaurus SL-5500 mit dem Linux-basierten OpenZaurus und der Oberfläche OPIE
Der Begriff Embedded Linux bezieht sich auf den Einsatz von Linux in kleineren Endgeräten für den Massenmarkt wie in Mobiltelefonen oder PDAs.
Vorteil ist dabei, dass jeder Hersteller Linux auf der einen Seite nach eigenen Bedürfnissen verändern kann, auf der anderen Seite aber auch eine sehr aktive Entwicklergemeinschaft vorherrscht, auf deren Ressourcen (z.B. umfangreiche Entwickler-Programmen, bereits bestehender Code wie die Benutzeroberflächen OPIE oder GPE Palmtop Environment, Erfahrung, etc.) die Hersteller dabei zurückgreifen können.
Unterstützung finden viele Hersteller dabei bei eigens zu diesem Zweck gegründeten Foren, die Anleitungen, Programme und beispielhaften Programmcode zur Verfügung stellen, und sich um eine Standardisierung der Schnittstellen bemühen.
So hat das OSDL am 17. Oktober 2005 die Gründung der Mobile Linux Initiative bekannt gegeben, welche die Verbreitung von Linux im Markt für mobile Geräte beschleunigen soll.
Auch das gemeinnützige Consumer Electronics Linux Forum bemüht sich, Linux als Plattform für mobile Endgeräte zu verbreiten und die Zusammenarbeit zwischen den Firmen, die Mitglied im Forum sind, zu forcieren.
Technisch gesehen werden diese Geräte meist mit spezialisierten stromsparenden Prozessoren und einem Flash-Speicher ausgestattet.
Dort wird dann ein angepasstes und kompaktes Linux betrieben. Beispiele für Hardware, auf der heutzutage Linux eingesetzt wird, sind die Motorola Mobiltelefone A728, A760, A768, A780, A910, E680, E895, das Nokia 770 Internet Tablet und der Sharp Zaurus PDA, im Bereich SOHO einige Router von Linksys und WLAN -Geräte wie das 4G Access Cube.
Auch in vielen Festplattenrekordern, Satellitenreceivern und DVD-Abspiel- und Aufnahmegeräten findet sich häufig eine angepasste Linux-Variante.
PDA - Distributionen
* Familiar Linux
GPE Palmtop Environment
Maemo
* Mobilinux
OpenZaurus
OPIE
* Poky Linux
Qtopia
Elektronik
Neben der Nutzung von Linux in verbreiteten Kommunikationsgeräten wird es auch in elektronischen Steuerungen und Geräten der Mess - und Regelungstechnik und im Bereich der µC (Microcontroller) eingesetzt.
Im Unterschied zum Embedded Linux wird das System in diesem Fall für technische Spezialanwendungen eingesetzt.
Damit entfällt auf der einen Seite der Massenmarkt, auf der anderen Seite besteht zum Beispiel aber auch weniger Bedarf an einer benutzerfreundlichen und einfach gehaltenen Oberfläche.
Zur Verdeutlichung der Zusammenarbeit verschiedener Komponenten in einem Rechnersystem wird oft ein Schalenmodell verwandt.
Dabei werden die einzelnen Komponenten in Form von Schalen oder Schichten dargestellt. Die Grenze zwischen den einzelnen Schalen werden dabei als Schnittstellen bezeichnet.
Shells
Die Dialogsschnittstelle zur Kommunikation mit dem Benutzer (zeichenorientiert) wird dabei als Shell bezeichnen. Shell unter UNIX haben dabei zwei Funktionen, sie werden als# Kommandointerpreter und
Skriptsprache
verwendet. Die zweite Funktion ist unter UNIX bedeutend, da die Verwaltung des Betriebssystems mit Shell-Skripten erfolgt.
Angelehnt an verschiedene Programmiersprachen sind unterschiedliche Shells entwickelt worden.
sh
Bourne Shell an die Programmiersprache ALGOL 68 angelehnt
csh
C-Shell an die Programmiersprache C angelehnt
ksh
Korn-Shell vereinigt Bourne- und C-Shell
bash
Bourne-Again-Shell (Erweiterung der Bourne Shell) Standart unter Linux
Eine Shell ist dabei nichts anderes als jedes andere UNIX-Programm, nur das dieses Programm direkt nach der Anmeldung gestartet wird. Diese Shell nennt man daher auch „Login-Shell“.
Mit den oben genannten Kommandos ist es möglich aus der Login-Shell heraus eine weitere beliebige Shell aufzurufen und mit exit wieder zu verlassen.
Neben der Shell gibt es eine große Zahl von UNIX-Kommandos und Tools. Diese unterscheiden sich von Anwendungsprogrammen nur dadurch, dass sie im Lieferumfang des UNIX-Systems enthalten sind. Das eigentlich Betriebssystem jedoch ist der Kernel.
Xming ist eine Implementierung eines X-Servers für Windows. Der Xming-Server basiert auf dem X.Org-Server und wird mit MinGW sowie Posix-Threads kompiliert. (Xming basiert nicht auf der Cygwin-Emulation, ist also nicht mit Cygwin/X zu verwechseln.)
Xming kann mit SSH-Implementierungen wie PuTTY genutzt werden, so dass X11-Sitzungen verschlüsselt von entfernten Unix-Maschinen laufen können. Das Xming-Paket umfasst keine eigenen X-Clients.
Vor der ersten Installation steht der Linux-Neuling vor der Wahl einer so genannten Distribution.
Prinzipiell ist das Aufsetzen eines Linuxsystems auch aus den Quellen möglich (Linux from the scratch). Neben Zeit und Erfahrung erfordert das Vorgehen allerdings auch eine gewisse Experimentierfreude und ist für den Neu- oder Umsteiger keinesfalls zu empfehlen.
Eine Linux - Distribution ist eine Zusammenstellung von hauptsächlich freier Software zum Zwecke der Weitergabe oder des kommerziellen Vertriebs. Die Distributionen enthalten neben dem eigentlichen Linux-Kernel noch weitere Software, um so den jeweiligen Ansprüchen an das Gesamtsystem besser gerecht zu werden.
Im praktischen Einsatz werden meist sogenannte Linux-Distributionen genutzt, in denen verschiedene Software zu einem fertigen Paket zusammengestellt ist. * Jede Distribution enthält somit Linux beziehungsweise den Linux-Kernel.
So ist Linux im Server-Markt wie auch im mobilen Bereich eine feste Größe, während es auf dem Desktop bisher nur eine geringe Rolle spielt.
Ebenfalls spielt die wirtschaftliche und geographische Lage einer Region eine wichtige Rolle. So planen vorrangig südamerikanischeSchwellenländer den verstärkten Einsatz von Linux.[1][2]
Im praktischen Einsatz werden meist sogenannte Linux-Distributionen genutzt, in denen verschiedene Software zu einem fertigen Paket zusammengestellt ist.
Jede Distribution enthält somit Linux bzw. den Linux-Kernel.
Es gibt eine Vielzahl von Linux-Distributionen, aber für die aktuellen Kernel 2.2.x, 2.4.x und 2.6.x jeweils nur eine stabile, eine aktiv gepflegte und eine weiter entwickelte Version – nebenbei wird der (stabile) 2.6.16er-Zweig noch gepflegt und es werden Patches für vorhergehende Versionen bereitgestellt.
Allerdings passen viele Distributoren und versierte Benutzer den Kernel mehr oder weniger für ihre Zwecke an. Letztere nennen diese Prozedur umgangssprachlich „einen Kernel backen“.
Die Einsatzbereiche von Linux sind vielfältig und umfassen unter anderem die Nutzung auf Desktop-Rechnern, Servern, Mobiltelefonen, Routern, Multimedia-Endgeräten und Supercomputern. Dabei variiert die Verbreitung von Linux in den einzelnen Bereichen drastisch. So ist Linux im Server-Markt eine feste Größe, während es auf dem Desktop bisher nur eine geringe Rolle spielt. Ebenfalls spielt die wirtschaftliche und geographische Lage einer Region eine wichtige Rolle. So planen vorrangig südamerikanische Schwellenländer den verstärkten Einsatz von Linux.
Nach der Veröffentlichung des Linux-Quelltextes durch Linus Torvalds wurden verschiedene Programme für Linux angepasst, um das System zu erweitern.
Da Linux von Anfang an nur als Kern eines Systems geplant war und bis heute als solcher weiterentwickelt wird, bestand von Beginn an der Bedarf an zusätzlichen Programmen für Linux, um z. B. eine grafische Oberfläche zu erhalten oder auch nur um das System einfacher zu konfigurieren und zu steuern.
Aus diesem Grund kamen die ersten Linux-Distributionen schon kurz nach der Veröffentlichung von Linux auf, als Anwender, die nicht zum direkten Entwicklerkreis gehörten, Linux zu nutzen begannen.
Die ersten Distributionen hatten dabei das Ziel, das System z. B. mit der Software des GNU-Projekts zu einem arbeitsfähigen Betriebssystem zu entwickeln.
Zu ihnen gehörten MCC Interim Linux, welches auf den FTP-Servern der University of Manchester im Februar 1992 veröffentlicht wurde, TAMU, das von einigen Programmierern der Texas A&M University etwa zum gleichen Zeitpunkt erstellt wurde und Softlanding Linux System (SLS).
Da keine dieser Distributionen richtig gepflegt wurde, veröffentlichte Patrick Volkerding am 16. Juli 1993 die Distribution Slackware .
Sie ist die älteste heute noch aktive Linux-Distribution.
Durch die Linux-Distributionen erweiterten sich die Einsatzmöglichkeiten von Linux drastisch.
Es entwickelte sich zunehmend zu einer interessanten Alternative von proprietären Systemen wie UNIX, Microsoft Windows und Mac OS .
Die ersten Nutzer kannten UNIX von der Arbeit oder aus der Schule und hatten dementsprechende Vorkenntnisse.
Sie schätzten Linux wegen der Stabilität und der Tatsache, dass sie kein Geld bezahlen mussten, wegen des Umfangs der beiliegenden Software und wegen der Möglichkeit, das System wegen der offenen Quellen eigenen Bedürfnissen anzupassen.
Waren die ersten Distributionen nur der Bequemlichkeit halber geschaffen worden, sind sie doch heute die übliche Art für Nutzer wie auch Entwickler, ein Linux-System zu installieren.
Dabei werden die Linux-Distributionen heutzutage sowohl von Entwickler-Gruppen, als auch von Firmen oder gemeinnützigen Projekten entwickelt und betrieben.
Die Zusammensetzung einer üblichen Linux-Distribution für den Desktop-PC umfasst zum Beispiel: * Linux-Kerneldie Basis grundlegende Systemfunktionen
GNU -Softwaregrundlegendes BasissystemKommando-zeilenwerkzeugen
KommandozeileninterpreterShell
X-Window-SystemBasis für grafische Benutzeroberflächen
Desktop oder Windowmanagerals grafische Benutzeroberflächeerlaubt eine komfortable Bedienung in X-Window-System
Anwendungsprogramme Office-Pakete, Editoren, E-Mailprogramme, Browser, Server -Software, Bildbetrachter /-bearbeiter und viele mehr
Konfigurationsprogrammeum das System eigenen Bedürfnissen anzupassen, Software zu installieren und Hardware einzurichten
Entwickler-Werkzeuge Compiler oder Interpreter für Programmiersprachen
Softwareprogrammen und -bibliothekenDienste und Funktionalitäten, die von anderen Programmen genutzt werden
Boot-Managerzum Starten des installierten Systems und eventueller anderer installierter Systeme
Dabei werden die meisten Distributionen in Form fertiger CD-Images im Internet bereit gestellt. Einige Distributoren verpacken ihr Angebot aber auch mit gedruckten Handbüchern oder Supportverträgen, und bieten diese kombinierten Angebote zum Verkauf an.
Aktuelle Distributionen
Viele, vor allen Dingen kleine Distributionen, werden von kleinen Projekten oder auch Einzelpersonen gewartet und entwickelt, die sich meist über das Internet koordinieren und austauschen.
Größere Distributionen haben in den meisten Fällen eine Stiftung gegründet, um die Arbeit besser und gezielter verwalten und geschlossener auftreten zu können.
Diese Stiftungen werden teilweise von Firmen unterstützt oder sind direkt von ihnen gegründet worden, um die Gemeinschaft der Entwickler besser an der Entwicklung der firmeneigenen Distribution zu beteiligen.
Der Einsatzbereich der Distribution kann dabei sehr unterschiedlich sein, und reicht vom Desktop-PC über Server-Installationen und Distributionen mit speziellen Netzwerkfähigkeiten bis hin zu Live-CDs oder Distributionen für Mobiltelefone, die jeweils einen ganz unterschiedlichen Funktionsumfang haben können.
Eine Besonderheit bilden dabei die Live-Systeme, die von CD, DVD und anderen Medien gebootet werden.
Diese werden von extra darauf ausgerichteten Distributionen oder von bestehenden Distributionen als Zusatz zu den Installationsdatenträgern erstellt.
Live-Systeme können als vollständiges Linux gestartet werden, ohne auf die Festplatte zu schreiben und ohne die bestehende Konfiguration eines Rechners zu verändern.
So kann die entsprechende Linux-Distribution gefahrlos auf einem Computer getestet werden.
Livesysteme eignen sich auch hervorragend zur Datenrettung und Systemanalyse, da sie von der Konfiguration des bereits bestehenden Systems unabhängig sind, und so auch von möglichen Infektionen durch Würmer und Viren nicht betroffen werden können.
Tools zur Installation, z.B. Partitionierungstools
Enthaltene Software
Welche Software -Pakete werden beigelegt und verwendet (z.B. welche grafische Benutzeroberflächen werden beigelegt und wie gut werden sie von der Distribution vorkonfiguriert)?
Verwaltungswerkzeuge
Welche Werkzeuge werden eingesetzt, um das System leichter verwaltbar zu machen?
Handbücher
Wie sieht es mit vorhandener Literatur (z.B. in Form von Handbüchern) aus?
Support
Gibt es offiziellen Support seitens des Distributors, in welchem Umfang und zu welchen Konditionen (Preisen)?
Distributionspolitik
Wie sieht die Distributionspolitik aus, zu der auch gehört, ob kommerzielle Software beigelegt/verwendet wird?
Community oder Kommerziell
Wird die Distribution in einem Projekt von Freiwilligen, von einer Firma oder gar von beiden gemeinsam entwickelt?
Zertifizierte Software
Wird die Distribution offiziell von kommerziellen Software-Anbietern unterstützt? Gibt es z.B. die bevorzugte Firmensoftware für diese Distribution?
Community
Auch kann die Größe, Hilfsbereitschaft und Kenntnisse der Nutzergemeinschaft von Distribution zu Distribution erheblich variieren.
Weitere Software
Angebot der bereits von Drittanbietern an die Distribution angepassten und für diese fertig verpackten Software
Kompatibilität zwischen den Distributionen
Schon kurz nach dem Aufkommen der ersten Distributionen kamen verschiedene Ideen auf, wie die Installation von weiterer Software vereinfacht werden könnte.
Dabei war das Ziel meist, die wichtigste Software bereits in Form fertiger, kompilierter Pakete bereit zu stellen und zusätzlich einen Mechanismus zur Verfügung zu stellen, der Abhängigkeiten weiterer für die Funktion des zu installierenden Pakets unabdingbare Pakete auflösen kann.
Aus diesem Bedarf heraus sind verschiedene Paketmanagement -Systeme entstanden, die mit jeweils eigenen Paketformaten wie zum Beispiel RPM oder deb arbeiten.
Dadurch hat nahezu jede Linux-Distribution eine eigene Softwareverwaltung mit eigenen Binärpaketen, die zu den Binärpaketen der anderen Distributionen teilweise inkompatibel sind.
Da aber nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und die Ressourcen hat, seine Software für jede Linux-Distribution einzeln bereitzustellen, wird diese meist nur im Quelltext veröffentlicht.
Dieser ist aber nicht so einfach zu installieren, so dass normale Computer-Nutzer selten Software neben der von der Distribution mitgelieferten installieren.
Dies ist zugleich auch einer der größten Kritikpunkte vieler Nutzer an Linux, bzw. an den Linux-Distributionen.
Außerdem können so viele kommerzielle Softwareanbieter ihre Software nur unter bestimmten Distributionen anbieten, was dazu führt, dass nur bestimmte Distributionen im Firmenumfeld eine Chance haben.
Um zu verhindern, dass sich die einzelnen Distributionen mit fortschreitender Entwicklung noch weiter von einander entfernen, wurde die Free Standards Group ins Leben gerufen, die das Ziel hat, die binäre Interoperabilität zwischen den verschiedenen Distributionen zu ermöglichen.
Unter ihren verabschiedeten Standards gibt es die Linux Standard Base, welche übereinstimmende Binärschnittstellen („ ABI “ genannt, für Application Binary Interface ), einige Details zum inneren Aufbau und ein Paketsystem (hier RPM ), das für die Installation von Drittanbieter-Software unterstützt werden muss definiert.
Des Weiteren gibt es mit dem Filesystem Hierarchy Standard auch einen Dateisystem-Standard, der eine gemeinsame Benennung einiger Datei- und Verzeichnisnamen und eine übereinstimmende Struktur der Basisverzeichnisse ermöglicht und auch von der Linux Standard Base vorausgesetzt wird.
Zur Zeit werden diese Standards von den meisten Distributoren aber nur halbherzig umgesetzt, selbst wenn die Distributoren Mitglied bei der Stiftung sind.
Die Situation verbessert sich langsam, da sich die kommerziellen Distributionen mehr an die LSB Standards annähern. Des Weiteren gibt es zwar auch andere Lösungsansätze wie Autopackage oder Klik, diese haben aber derzeit faktisch keine Relevanz.
Linux und Windows
Die meisten Linux-Distributionen können neben bestehenden Installationen anderer Betriebssysteme installiert werden. Beim Start gibt dann der Boot-Manager eine Auswahl, aus der der Nutzer das zu startende Betriebssystem wählt.
Es gibt aber auch Linux-Distributionen, die innerhalb einer Windows -Sitzung oder innerhalb einer Windows- Partition verwendet werden können.
Dabei werden sie unter Windows wie gewöhnliche Software installiert und entweder über einen Boot-Loader in Windows gebootet oder wie ein herkömmliches Windows-Programm gestartet.
Solche Distributionen sind in der Regel für Probe- und Testzwecke gedacht oder werden als technische Machbarkeitsstudie entwickelt.
Da bei diesen Distributionen Windows und Linux gleichzeitig laufen, sind diese Distributionen vergleichsweise langsam. Ein weiterer Nachteil ist die meist recht geringe Paket- bzw. Programmauswahl.
Verschiedene Distributionen
Grundlegende generelle Informationen über die Distributionen (Hersteller/Firma, Lizenz/Preis, etc.):
Die meisten Distributionen installieren standardmäßig nur bestimmte Software.
Die hier in den Tabellen angegebene Software bezieht sich also auf den Standard der jeweiligen Distribution - andere Software gleicher Funktion kann meist problemlos nachinstalliert werden.
Dateimanager
Desktopumgebung
Fenstermanager
GUI Styling
Ark Linux
Konqueror
KDE
KWin
Plastik Theme
Debian
kein Standard (alle optional)
kein Standard (alle optional)
kein Standard (alle optional)
kein Standard (alle optional)
Fedora Core
Nautilus
GNOME
Metacity
Clearlooks Theme
Gentoo Linux
kein Standard (alle optional)
kein Standard (alle optional)
kein Standard (alle optional)
kein Standard (alle optional)
Mandriva
Konqueror
KDE
KWin
Mandrakegalaxy Theme
Slackware
Konqueror
KDE
KWin
Plastik Theme
SUSE Linux
Nautilus oder Konqueror
GNOME oder KDE
Metacity oder KWin
Plastik Theme
Ubuntu
Nautilus
GNOME
Metacity
Human Theme
Kubuntu
Konqueror
KDE
KWin
Plastik Theme
X-Server (falls eingesetzt)
Office Suite
Personal Information Management
Instant Messenger
Browser
Ark Linux
X.Org-Server
OpenOffice.org
Kontact
Kopete
Konqueror
Debian
XFree86
kein Standard (alle optional)
kein Standard (alle optional)
kein Standard (alle optional)
kein Standard (alle optional)
Fedora Core
X.Org-Server
OpenOffice.org
Evolution
Gaim
Mozilla Firefox
Gentoo Linux
X.Org-Server
kein Standard (alle optional)
kein Standard (alle optional)
kein Standard (alle optional)
kein Standard (alle optional)
Mandriva
X.Org-Server
OpenOffice.org
Kontact
Kopete
Konqueror
Slackware
X.Org-Server
kein Standard (alle optional)
kein Standard (alle optional)
Gaim
Mozilla Firefox
SUSE Linux
X.Org-Server
OpenOffice.org
Evolution oder Kontact
Gaim oder Kopete
Mozilla Firefox
Ubuntu
X.Org-Server
OpenOffice.org
Evolution
Gaim
Mozilla Firefox
Quellen
"The Top Ten Distributions" distrowatch.com
Weblinks
Auswahlhilfe für eine passende Linux-Distribution (englisch) Linux Distribution Chooser www.zegeniestudios.net/ldc/
Freie Software und Lizenzierung
Seit den 50er Jahren dominierte IBM mit seinen Mainframes (Großrechnern) den Hardwaremarkt.
Man kann Parallelen zu heutigen Ereignissen sehen... zumindest missbrauchte auch damals IBM seine Vormachtstellung und diktierte das Geschehen rund um Hard- und Software.
Die Konsequenz war, dass nahezu jede Hardware und nahezu jedes Stück Programm aus der firmeneigenen Schmiede stammte und andere Anbieter keinen Fuß in diesem Marktsegment fassen konnten.
Auch damals schob erst das Gesetz einen Riegel vor die Machenschaften von IBM. Im so genannten Antitrust-Gesetz wurde IBM 1972 in eine Hardware- und eine Softwarefirma aufgeteilt.
Die Phase gilt als der eigentliche Beginn der Ära der Softwareindustrie.
Was ist „Freie Software?
Freie Software ist Software, die für jeden Zweck ausgeführt, untersucht, modifiziert und in ursprünglicher oder modifizierter Form weiterverbreitet werden darf.
Das schließt auch die kommerzielle Nutzung ein. Freie-Software-Lizenzen können eine Copyleft-Klausel enthalten, die besagt, dass bearbeitete und wiederveröffentlichte Versionen der Software ebenfalls frei sein müssen.
Aber auch die BSD-artigen Lizenzen, die kein Copyleft erfordern, sind Freie-Software-Lizenzen.
Freier Software steht die unfreie und/oder proprietäre Software gegenüber, die diese Freiheiten nicht oder nicht in vollem Umfang bietet. Diese Unterscheidung wurde von der Free Software Foundation (FSF) geprägt.
Die Free Software Foundation definiert Software als Freie Software, wenn ihre Lizenz folgende Freiheiten einräumt:
Freiheit 0:
Das Programm zu jedem Zweck auszuführen.
Freiheit 1:
Das Programm zu untersuchen und zu verändern.
Freiheit 2:
Das Programm zu verbreiten.
Freiheit 3:
Das Programm zu verbessern und diese Verbesserungen zu verbreiten, um damit einen Nutzen für die Gemeinschaft zu erzeugen.
Für die Freiheiten (1) und (3) ist der Zugang zum Quelltext Voraussetzung, da sonst das Verändern eines Programms schwierig bis unmöglich ist. Sind eine oder mehrere dieser Bedingungen nicht erfüllt, wird die Software als proprietär oder „unfrei“ bezeichnet.
Freeware
In der englischen Sprache bedeutet free nicht nur „frei“, sondern auch „kostenlos“ oder „kostenfrei“.
Englischsprachige Entwickler und Aktivisten machen die Unterscheidung mit Free as in Freedom („Frei wie in Freiheit“) und free as in free beer („frei wie Freibier“) deutlich.
Bei Freie Software (engl. Originalausdruck: free software) bezieht sich „frei“ auf die erste Definition, auf die Freiheiten für den Nutzer der Software.
Zu den garantierten Freiheiten gehört auch, freie Software zu einem beliebigen Preis verkaufen zu dürfen. Freie-Software-Lizenzen beinhalten eine Copyleft-Regelung (auch: share alike), das heißt, die Freiheiten dürfen bei der Verbreitung der Software nicht eingeschränkt werden.
Freeware hingegen bezieht sich auf die zweite Bedeutung, „kostenlos“.
Diese Software räumt dem Benutzer nicht die von der Free Software Foundation aufgelisteten Freiheiten ein, sondern die der individuellen Lizenzvereinbarung mit dem Urheber. Daher gilt sie als „unfreie“ Software.
Open Source
Der Begriff Open Source (zu deutsch „quelloffen“) wurde von Eric S. Raymond, Bruce Perens und Tim O’Reilly, Gründer der Open Source Initiative (OSI), eingeführt.
Sie glaubten, dass das unangenehme Thema Freiheit potentielle Geldgeber für entsprechende Projekte abschrecken könnte.
In der Darstellung der Open-Source-Bewegung wird die Freiheit, die freie Software den Benutzern gibt, daher nicht erwähnt. Sie betont, dass Open Source zu besserer und preisgünstigerer Software führt als geschlossene, proprietäre Konstruktionen. Die Free Software Foundation hingegen meint, dass proprietäre Software allein schon aus moralischen Gründen abzulehnen sei, selbst wenn sie besser als quelloffene wäre.
Software soll transparent und überprüfbar sein. Richard Stallman von der FSF lehnt die Bezeichnung Open Source und den dahinterstehenden Standpunkt grundsätzlich ab. Dennoch arbeiten Anhänger beider Lager bei Projekten zusammen.
Auch ist die GNU GPL die beliebteste Lizenz selbst bei Projekten, die von Open-Source-Anhängern dominiert werden. Alternative Kompromissbezeichnungen wie „Free/Libre Open Source Software“, die von Anhängern beider Positionen (einschließlich Richard Stallman) akzeptiert werden, sollen diese Gemeinsamkeiten betonen.
Der Begriff „Open-Source-Software“ scheint mit der Betonung der Überlegenheit des Entwicklungsprozesses eher aus Sichtweise der Entwickler wiederzugeben, während der Begriff „Freie Software“ auch die Sicht der Anwender einbezieht.
In ihren konkreten Forderungen an Softwarelizenzen unterscheiden sich die beiden Bewegungen ebenfalls kaum: „Open Source“ bezieht sich darauf, dass der Quellcode eines Programmes offenliegt.
Nicht nur das Programm wird verbreitet, sondern auch der Quellcode, auf Grundlage dessen das Programm erstellt wurde.
Wer den Quellcode kennt, kann ihn, wie bei Freie Software, untersuchen („studieren“), ändern und neue Programme daraus generieren. Das Bekanntsein des Quellcodes ist wichtig dafür, dass Software frei verbreitet werden kann.
Bisweilen wird zwar auch Software, deren Quellcode nur eingesehen, aber nicht verändert oder weitergegeben werden darf, als „Open Source“ vermarktet. Dies entspricht jedoch nicht der Open Source Definition der OSI.
Halbfreie Software
Aus Angst vor kommerzieller Ausnutzung oder amoralischem Gebrauch der eigenen Software gab und gibt es Bestrebungen, nicht alle Freiheiten aus der Definition freier Software in seiner Lizenz zu gewähren.
Die Programmierer des Amiga-Emulators WinUae z. B. ärgerten sich darüber, dass das Unternehmen Cloanto den Emulator in einer Kollektion mit diversen Spielen und Hilfsprogrammen als Amiga Forever Pack für ungefähr 60 Dollar verkaufte.
Die eMule-Entwickler sahen sich mit Unternehmen wie 3PO Web-Invest konfrontiert, die eine neue proprietäre Version (eMcrypt-Emule) erstellten und kommerziell vertrieben, die sich vom Original nur durch hinzugefügte Spyware unterschied.
Solche Vorfälle führen zu Erwägungen eines Modells, das die Freiheiten der freien Software um die kommerzielle Weiterverbreitung vermindert (aber die sonstigen unverändert beibehält).
Von der FSF wird so etwas als halbfreie Software (semi-free software) abgelehnt.
Lizenzmodelle
Der simple Vergleich versucht die gängigsten Lizenzmodelle unter Aspekt ihrer Nutzungsbedingungen gegenüber zu stellen.
»Nichts kosten« besagt allerdings nur, dass die Software kostenlos erhältlich ist, es sagt nichts über die Folgekosten während der Nutzung aus
Kostetnichts
Unbeschränkte Nutzungsdauer
Quellenverfügbar
Ableitungen stets frei
Ableitung fällt unter dieselbe Lizenz
Kommerziell
Shareware
teils
Freeware
x
x
BSD-Lizenz
x
x
x
Künstlerische Lizenz
x
x
x
Gnu LGPL
x
x
x
x
Gnu GPL
x
x
x
x
x
GPL und LGPL
Die Gnu General Public License und Gnu Library General Public License unterscheiden sich nur in Details. So soll nur auf erstere genauer eingegangen und die Änderungen bez. der Software-Bibliotheken im Anschluss kurz genannt werden.
Das Wesen beider, von der Free Software Foundation in Leben berufener Lizenzformen offenbart sich schon in den einleitenden Worten: Lizenzen der meisten Softwareprodukte zielen darauf ab, dem Nutzer die Freiheit der Verbreitung und Änderung der Software zu nehmen.
Im Unterschied hierzu ist die GNU-General Public License eine Garantie der Freiheit, freie Software auszutauschen und zu teilen - um zu sichern, dass diese Software für alle Nutzer frei ist.
Kernaussagen der GPL
Geltungsbereich
Ihr Geltungsbereich erstreckt sich auf alle Programme, deren Entwickler den Copyright-Hinweis ausdrücklich zu diesem hinzugefügt haben, sowie auf alle Programme, die Teile eines GPL-Programms enthalten.
Kopierbarkeit
Programme sind frei kopierbar, jeder Kopie ist der Text der GPL beizulegen. Die Kosten für den Kopiervorgang dürfen erhoben werden.
Der Quelltext des Programms muss mit der Kopie nicht vertrieben werden, jedoch ist jedem Interessenten Zugang zu diesem zu gewähren (für eine Zeitdauer von mindestens 3 Jahren ab Vertrieb).
Modifzierbarkeit
Die Modifzierbarkeit ist gewährleistet, wobei jede Änderung im Quelltext zu kennzeichnen ist (Datum und Grund der Änderung, Name des Programmierers).
Ein Programm, das Teile aus GPL-Software enthält, unterliegt damit automatisch der GPL. Dies gilt nicht für klar abtrennbare Programmteile, die vollständig ohne GPL-Code implementiert sind.
Diese können anderen Lizenzbedingungen unterstehen.
Haftungsausschluss
Der Urheber des Programms trägt keine Verantwortung für die Korrektheit der Software und muss für eventuelle Schäden durch den Betrieb dieser nicht aufkommen.
Nach den obigen Bestimmungen wäre es unmöglich, basierend auf einer GPL-Softwareumgebung kommerzielle Software zu entwickeln, da z.B. unter Linux bereits die Compiler und Bibliotheken reine GPL-Software sind.
Die LGPL definiert folgende Erweiterungen
Geltungsbereich
Die entstehende Software muss selbst eine Bibliothek sein.
Wird innerhalb einer Bibliotheksfunktion aus Teile eines Nicht-GPL-Anwendungsprogrammes zurückgegriffen, so muss sicher gestellt sein, dass die Bibliothek auch ohne dieses Programms korrekt arbeitet.
Ein Programm, das mit Teilen einer LGPL-Bibliothek gebunden wurde, unterliegt der LGPL.
Lizenz- Hinweise
Um die LPGL anstelle der GPL zu benutzen, müssen entsprechende Hinweise in die Software aufgenommen werden
Definition
Ein Werk, das die Bibliothek benutzt ist ein Programm, das weder abgeleitete noch andere Teile einer Bibliothek besitzt, aber so hergestellt wurde, dass es durch Compilieren und Binden mit der Bibliothek mit dieser zusammen arbeitet.
Ein solches "Werk" fällt nicht unter die Lizenz.
In gewissem Umfang dürfen in Software Teile aus GPL-Programmen verwendet werden, ohne dass das entstehende Werk der Lizenzbedingung unterliegt
Ableitungen
Enthält eine Bibliothek sowohl Funktionen, die auf GPL-Software basieren, als auch eigene Funktionen, so muss der Quelltext der unter die GPL-Lizenz fallenden Funktionen für jedermann zugänglich sein.
BSD Lizenz
Die BSD-Lizenz beinhaltet keinerlei Einschränkungen für den Gebrauch und die Weiterverbreitung von Quellcode und Programmen. Einzig einen Copyright-Hinweis, die BSD-Lizenzbedingungen selbst und ein Garantieausschluss sind dem Werk beizulegen.
Außerdem darf in einem abgeleiteten Werk nicht mit dem Namen des ursprünglichen Entwicklers geworben werden, es sei denn, dieser erklärt sich ausdrücklich damit einverstanden.
Ein Betriebssystemkern oder Systemkern (engl. kernel [ ˈkɝːnəl ]) ist der zentrale Bestandteil eines Betriebssystems.
In ihm ist die Prozess- und Datenorganisation festgelegt, auf der alle weiteren Softwarebestandteile des Betriebssystems aufbauen.
Die Konstruktion eines stabilen Betriebssystemkerns ist eine Aufgabe aus den Bereichen der Informatik und des Softwareengineerings.
Gängige Anforderungen an einen Systemkern sind Parallelverarbeitung verschiedener Aufgaben (Multitasking), Einhaltung zeitkritischer Grenzen, Offenheit für unterschiedlichste Anwendungen und Erweiterungen.
Ein bekanntes Beispiel für einen Kernel ist der Linux-Kernel, von Linus Torvalds 1991 erstellt und seitdem als Open-Source -Projekt weltweit weiterentwickelt.
Nicht zum Systemkern gehörende Teile werden als Userland bezeichnet.
Grundlegende Technologie
Die Bezeichnung Linux wurde von Linus Torvalds anfänglich nur für den Kernel genutzt, der Software eine Schnittstelle zur Verfügung stellt, mit der sie auf die Hardware zugreifen kann, ohne sie genauer zu kennen.
Der Linux-Kernel ist ein in der Programmiersprache C geschriebener monolithischer Betriebssystemkern, wichtige Teilroutinen, sowie zeitkritische Module sind jedoch in Assembler programmiert.
Der Kernel ermöglicht es, nur die für die jeweilige Hardware nötigen Treiber zu laden, weiterhin übernimmt er auch die Zuweisung von Prozessorzeit und Ressourcen zu den einzelnen Programmen, die auf ihm gestartet werden.
Bei den einzelnen technischen Vorgängen orientiert sich das Design von Linux stark an seinem Vorbild Unix.
Der Linux-Kernel wurde zwischenzeitlich auf eine sehr große Anzahl von Hardware-Architekturen portiert.
Das Repertoire reicht von eher exotischen Betriebsumgebungen wie dem iPAQ-Handheld-Computer oder gar Digitalkameras bis hin zu Großrechnern wie IBMs System z und neuerdings auch Mobiltelefonen wie dem Motorola A780.
Trotz Modulkonzept blieb die monolithische Grundarchitektur erhalten.
Die Orientierung der Urversion auf die verbreiteten x86-PCs führte früh dazu, verschiedenste Hardware effizient zu unterstützen und die Bereitstellung von Treibern auch unerfahrenen Programmierern zu ermöglichen.
Die hervorgebrachten Grundstrukturen beflügelten die Verbreitung.
Aufgaben eines Kernels
Ein Kernel hat die folgenden Aufgaben:
Schnittstelle
zu Anwenderprogrammen (Starten, Beenden, Ein-/Ausgabe, Speicherzugriff)
Kontrolle
des Zugriffs auf Prozessor, Geräte, Speicher (Scheduler, Gerätetreiber, Speicherschutz). Möglichst alleiniger Zugriff des Kernels auf diese Ressourcen.
Verteilung der Ressourcen
etwa der Prozessorzeit(en) (bzw. der Prozessoren) auf die Anwenderprogramme
Strukturierung
der Ressourcen, etwa Abbildung von Dateisystemen auf blockorientierte Geräte wie Festplatten, Netzwerkprotokollstapel auf Netzwerkkarten.
Auflösung von Zugriffskonflikten
etwa Verriegelung bei Mehrprozessorsystemen, Warteschlangen bei knappen Ressourcen
Ein Systemkern ist in Schichten (oder Layer s. Schichtenmodell) aufgebaut, wobei die unteren (maschinennäheren) Schichten die Basis für die oberen (maschinenferneren) Schichten bilden.
Die oberen Schichten können die Funktionen der unteren Schichten aufrufen, aber nicht umgekehrt.
Folgende Schichten sind vorhanden (von unten nach oben): * Schnittstelle zur Hardware (Geräte, Speicher, Prozessoren)
Wenn alle diese Funktionen im Systemkern selbst vorhanden sind, spricht man von einem monolithischen Kernel. Bei einem Mikrokernel finden wesentliche Teile in getrennten Prozessen statt. Daneben, bzw. zwischen den beiden liegend, gibt es noch den so genannten Makrokernel.
Auf jeden Fall außerhalb des Kernels laufen die Anwenderprozesse, die sich der vom Kernel angebotenen Funktionen bedienen, um mit der Maschine zu kommunizieren.
Zur Realisierung eines Betriebssystems wird oft das Konzept eines Prozesses (oder auch einer Task) verwendet. Ein Prozess enthält (mindestens) einen Registersatz des Prozessors und kann über den Scheduler angehalten und wieder gestartet werden.
Jeder Prozess hat daneben kontrollierten Zugriff auf einen Teil des Speichers sowie Ein- und Ausgabekanäle, die auf Dateien oder Geräte zugreifen. Mit dem Kernel kommuniziert er über Systemaufrufe.
Ein Anwenderprogramm läuft normalerweise in genau einem, in Ausnahmefällen auch in mehreren Prozessen. Auch manche Systemdienste laufen innerhalb von Prozessen.
Initialisierung
Beim Starten eines Computers wird nach einem eventuellen Hardwarecheck und einer teilweisen Geräteinitialisierung der Kernel in den Speicher geladen und gestartet. Er initialisiert die Geräte vollständig und startet den ersten Prozess.
Bei einfachen Systemen wie MS-DOS ist dies ein Kommandozeileninterpreter, bei Mehrprozesssystemen ein bestimmter Prozess (bei Linux/Unix init), der die Systemdienste (als Prozesse) lädt und wieder, evtl. nach Eingabe von Namen und Passwort, einen oder mehrere Kommandointerpreter oder eine graphische Benutzeroberfläche als Prozesse startet.
Danach übernimmt er mit Hilfe der Systemaufrufe das Starten/Stoppen von weiteren Prozessen (Anwenderprogrammen) sowie die Zuteilung von Speicher und Ein-/Ausgabekanälen auf die einzelnen Prozesse.
Kernel-Arten
Können auf einem Kernel mehrere Prozesse gleichzeitig laufen, spricht man von Multitasking-Kerneln. In Wirklichkeit wird jedoch immer nur ein Prozess von der CPU behandelt (außer bei Mehrkernsystemen).
Diesen Wechsel regelt in den meisten Fällen der Scheduler. Wird ein Multitasking-Kernel durch eine Zugriffsverwaltung auf Prozesse und Geräte ergänzt, erhält man ein Multiuser-(oder Mehrbenutzer-)System. Hierauf können mehrere Benutzer gleichzeitig arbeiten.
Jeder Benutzer muss sich einloggen (Authentifizierung).
Der Kernel teilt jedem Prozess einen Benutzer zu, jeder Benutzer kann jedoch mehrere Prozesse besitzen. Abhängig vom Benutzer werden Prozessrechte eingeschränkt.
Der Kernel ist für die Separation der Prozesse und damit der Benutzer zuständig.
Obwohl heutige Desktopsysteme in der Regel nur von einem Benutzer gleichzeitig verwendet werden, sind sie als Mehrbenutzersystem ausgelegt.
Dies nicht nur deswegen, weil dann mehrere Nutzer mit jeweils eigenen Präferenzen das System verwenden können. Zusätzlich werden die Systemdienste unter anonymen Benutzern gestartet.
Jedem Systemdienst und jedem Benutzer können dadurch eigene, eingeschränkte Zugriffsrechte eingeräumt werden, die für die Arbeit nötig sind. Die Systemsicherheit wird dadurch drastisch erhöht.
Programmiersprache
Linux ist fast komplett in der Programmiersprache C geschrieben, wobei einige GNU -C-Erweiterungen benutzt werden.
Eine Ausnahme bilden die architekturabhängigen Teile des Codes (im Verzeichnis arch innerhalb der Linux- Sourcen), wie z.B. der Beginn des Bootvorganges, die in Assemblersprache geschrieben sind.
Funktionsweise
Bei einem strikt monolithischen Kernel wird der gesamte Quellcode inklusive aller Treiber in das Kernel-Image (den ausführbaren Kernel) kompiliert.
Im Gegensatz dazu kann Linux Module benutzen, die während des Betriebs geladen und wieder entfernt werden können.
Damit wird die Flexibilität erreicht, um unterschiedlichste Hardware ansprechen zu können, ohne sämtliche (auch nicht benötigte) Treiber und andere Systemteile im Speicher halten zu müssen.
Sind Teile der Hardwarespezifikationen nicht genügend offen gelegt, so stützt sich Linux notfalls über spezielle VM86-Modi auch auf das BIOS des Systems, u.a. auf die Erweiterungen gemäß den Standards APM, ACPI und VESA.
Um unter diesen Voraussetzungen x86 -kompatible Hardware z.B. auf der DEC - Alpha -Plattform zu betreiben, werden teilweise sogar Emulatoren zur Ausführung entsprechenden ROM - Codes verwendet.
Linux selbst übernimmt das System beim Bootprozess typischerweise in dem Moment, wo der BIOS - Bootloader erfolgreich war und alle Systeminitialisierungen des BIOS abgeschlossen sind.
Der Kernel ist ein Betriebssystemkern und darf nicht als das eigentliche Betriebssystem verstanden werden.
Dieses setzt sich aus dem Kern und weiteren grundlegenden Programmen (die den Computer erst bedienbar machen) zusammen.
Linux ist ein monolithischer Kernel. Die Treiber im Kernel und die Kernel- Module laufen im privilegierten Modus (x86: Ring0), haben also unbeschränkten Zugriff auf die Hardware.
Einige wenige Module des Kernels laufen im eingeschränkten Benutzermodus (x86: Ring3). Die Level 1 und 2 der x86 -Architektur werden von Linux nicht genutzt.
Nahezu jeder Treiber kann auch als Modul zur Verfügung stehen und vom System dann dynamisch nachgeladen werden.
Ausgenommen davon sind Treiber, die für das Starten des Systems verantwortlich sind, bevor auf das Dateisystem zugegriffen werden kann.
Man kann allerdings den Kernel so konfigurieren, dass ein Cramfs - oder Initramfs - Dateisystem vor dem tatsächlichen Root-Dateisystem geladen wird, welches die weiteren für den Startprozess notwendigen Module enthält.
Dadurch kann die Kernelgröße verringert und die Flexibilität drastisch erhöht werden.
Im System laufende Programme bekommen wiederum vom Kernel Prozessorzeit zugewiesen.
Jeder dieser Prozesse erhält einen eigenen, geschützten Speicherbereich und kann nur über Systemaufrufe auf die Gerätetreiber und das Betriebssystem zugreifen.
Die Prozesse laufen dabei im Benutzermodus (user mode), während der Kernel im Kernel-Modus (kernel mode) arbeitet. Die Privilegien im Benutzermodus sind sehr eingeschränkt.
Abstraktion und Speicherschutz sind nahezu vollkommen, ein direkter Zugriff wird nur sehr selten und unter genau kontrollierten Bedingungen gestattet.
Dies hat den Vorteil, dass kein Programm z.B. durch einen Fehler so das System zum Absturz bringen kann.
Linux stellt wie sein Vorbild Unix eine vollständige Abstraktion und Virtualisierung für nahezu alle Betriebsmittel bereit (z.B. virtueller Speicher, Illusion eines eigenen Prozessors etc.).
Die Tatsache, dass Linux nicht auf einem Mikrokernel basiert, war Thema eines berühmten Flame Wars zwischen Linus Torvalds und Andrew S. Tanenbaum. Anfang der 1990er Jahre, als Linux entwickelt wurde, galten monolithische Kernels als obsolet (Linux war zu diesem Zeitpunkt noch rein monolithisch).
Die Diskussion und Zusammenfassungen sind im Artikel Geschichte von Linux näher beschrieben.
Durch Erweiterungen wie FUSE und durch die zunehmende Verwendung von Kernel-Prozessen fließen mittlerweile auch Mikrokernel -Konzepte ein.
Portierbarkeit
Obwohl Linus Torvalds eigentlich nicht beabsichtigt hatte, einen portierbaren Kernel zu schreiben, hat sich Linux dank des GNU Compilers GCC doch in diese Richtung entwickelt.
Es ist inzwischen mit eines der am häufigsten portierten Systeme (nur noch NetBSD läuft auf etwa gleich vielen Architekturen).
Das Repertoire reicht dabei von eher selten anzutreffenden Betriebsumgebungen wie dem iPAQ -Handheld-Computer oder gar Digitalkameras bis hin zu Großrechnern wie IBMs zSeries.
Obwohl die Portierung auf die S/390 ursprünglich ein vom IBM-Management nicht genehmigtes Unterfangen war, hat IBM wohl inzwischen Gefallen am Linux-System gefunden, und so soll auch die nächste IBM-Supercomputergeneration Blue Gene mit einem eigenen Linux-Port ausgestattet werden, sobald sie fertig ist.
Ursprünglich hatte Torvalds eine ganz andere Art von Portierbarkeit für sein System angestrebt, nämlich die Möglichkeit, freie GPL- und andere quelloffene Software leicht unter Linux kompilieren zu können.
Dieses Ziel wurde bereits sehr früh erreicht und macht sicherlich einen guten Teil des Erfolges von Linux aus, da es jedem eine einfache Möglichkeit bietet, auf einem freien System freie Software laufen zu lassen.
AMD64 (auch bekannt als x86–64): AMDs 64-bit Prozessoren Athlon 64, Opteron und Turion, sowie Intel-Prozessoren mit EM64T-Erweiterung (Xeon 4E)
Axis Communications ' CRIS
Compaq Alpha-Prozessor
Hitachi H8/300
Hewlett Packard PA-RISC
IA-64 : PCs mit 64bit Intel Itanium -Prozessor
IBM S/390 und zSeries
Intel 80386 und neuer: IBM-PCs und kompatible mit den CPUs 80386, 80486, und Pentium -Serie; AMD Athlon, Duron, Thunderbird ; Cyrix -Prozessoren. Unterstützung für Intel 8086, 8088, 80186, 80188 und 80286 CPUs wird derzeit entwickelt (siehe auch das ELKS -Projekt)
MIPS : Maschinen von Silicon Graphics …
Motorola 68020 und neuer: neuere Amigas, einige Atari und Apple Computer (siehe Linux68k)
NEC v850e
PowerPC : die meisten neueren Apple Computer (alle PCI-basierten Power Macintosh, der Gamecube, begrenzte Unterstützung für NuBus Power Macs), Clones der Power Macs von Power Computing, UMAX und Motorola, mit einer „Power-UP“-Karte verbesserte Amigas (z.B. Blizzard oder CyberStorm), sowohl POWER als auch PowerPC-basierte IBM RS/6000 -Systeme, verschiedenen eingebetteten PowerPC-Plattformen
Sun SPARC und UltraSparc : Sun -Workstations
Hitachi SuperH : Sega Dreamcast
User Mode Linux
Ein besonderer Port ist das User Mode Linux (UML). Prinzipiell handelt es sich dabei um einen Port von Linux auf sein eigenes Systemcall-Interface.
Dies ermöglicht es, einen Linux-Kernel als normalen Prozess auf einem laufenden Linux-System zu starten.
Der User-Mode-Kernel greift dann nicht selbst auf die Hardware zu, sondern reicht entsprechende Anforderungen an den echten Kernel durch.
Durch diese Konstellation werden „ Sandkästen “ ähnlich den Virtual Machines von Java oder den Jails von FreeBSD möglich, in denen ein normaler Benutzer Root-Rechte haben kann, ohne dem tatsächlichen System schaden zu können.
Auf der Website kernel.org werden alle alten und neuen Kernel-Versionen archiviert.
Die dort befindlichen Referenzkernel werden auch als Vanilla-Kernel bezeichnet (von umgangssprachlich engl. vanilla für Standard bzw. ohne Extras im Vergleich zu Distributionskernels).
Auf diesem bauen die sogenannten Distributionskernel auf, die von den einzelnen Linux-Distributionen um weitere Funktionen ergänzt werden.
Versionsnummern-Schema
Die Versionen von Linux folgen dabei einem bestimmten Schema:
Die erste Ziffer wird nur bei grundlegenden Änderungen in der Systemarchitektur angehoben.
Während der Entwicklung des 2.5er Kernels kam wegen der relativ grundlegenden Änderungen, verglichen mit dem 2.4er Kernel, die Diskussion unter den Kernel-Programmierern auf, den nächsten Produktionskernel als 3.0 zu deklarieren.
Torvalds war aber aus verschiedenen Gründen dagegen, sodass der resultierende Kernel als 2.6 bezeichnet wurde.
Die zweite Ziffer gibt das jeweilige „Majorrelease“ an. Bisher wurden stabile Versionen (sogenannte Produktionskernel) von den Entwicklern stets durch gerade Ziffern wie 2.2, 2.4 und 2.6 gekennzeichnet, während die Testversionen (sogenannte Entwicklerkernel) immer ungerade Ziffern trugen, wie z.B. 2.3 und 2.5; diese Trennung ist aber seit Juli 2004 ausgesetzt, es gibt zur Zeit (2006) keinen Entwicklerkernel mit der Nummer 2.7, stattdessen werden die Änderungen laufend in die 2.6er-Serie eingearbeitet.
Zusätzlich bezeichnet eine dritte Zahl das „Minorrelease“, das die eigentliche Version kennzeichnet. Werden neue Funktionen hinzugefügt, steigt die dritte Zahl an.
Der Kernel wird damit zum Beispiel mit einer Versionsnummer wie 2.6.7 bestimmt.
Um die Korrektur eines schwerwiegenden NFS -Fehlers schneller verbreiten zu können, wurde mit der Version 2.6.8.1 erstmals eine vierte Ziffer eingeführt.
Seit März 2005 (Kernel 2.6.11) wird diese Nummerierung offiziell verwendet. So ist es möglich, die Stabilität des Kernels trotz teilweise sehr schneller Veröffentlichungszyklen zu gewährleisten und Korrekturen von kritischen Fehlern innerhalb weniger Stunden in den offiziellen Kernel zu übernehmen – wobei sich die vierte Ziffer erhöht (z.B. von 2.6.11. 1 auf 2.6.11. 2).
Die Minorreleasenummer, also die dritte Ziffer, wird hingegen nur bei Einführung neuer Funktionen hochgezählt.
Neue Funktionen finden sich im sogenannten -mm Kernel des Kernelentwicklers Andrew Morton und werden anschließend in den Hauptzweig von Torvalds übernommen.
Somit werden große Unterschiede zwischen Entwicklungs- und Produktionskernel und damit verbundene Portierungsprobleme zwischen den beiden Serien vermieden.
Durch dieses Verfahren gibt es auch weniger Differenzen zwischen dem offiziellen Kernel und den Distributionskernel (früher wurden Features des Entwicklungszweiges von den Distributoren häufig in ihre eigenen Kernels rückintegriert).
Allerdings litt 2004/2005 die Stabilität des 2.6er Kernels unter den häufig zu schnell übernommenen Änderungen.
Ende Juli 2005 wurde deshalb ein neues Entwicklungsmodell beschlossen, das nach dem Erscheinen der Version 2.6.13 erstmals zur Anwendung kommt:
Neuerungen werden nur noch in den ersten zwei Wochen der Kernelentwicklung angenommen, wobei anschließend eine Qualitätssicherung bis zum endgültigen Erscheinen der neuen Version erfolgt.
Während Torvalds die neuesten Entwicklungsversionen veröffentlicht, wurde die Pflege der älteren „stabilen“ Versionen an andere Programmierer abgegeben.
Gegenwärtig ist David Weinehall für die 2.0er Serie verantwortlich, Marc-Christian Petersen (zuvor Alan Cox) für den Kernel 2.2, Willy Tarreau (zuvor Marcelo Tosatti) für den Kernel 2.4, Greg Kroah-Hartmann und Chris Wright für die aktuellen stabilen Kernel 2.6.x.y(-stable), Linus Torvalds für die aktuellen „normalen“ Kernel 2.6.x, und Andrew Morton für seinen experimentellen -mm-Zweig, basierend auf dem neuesten 2.6.x. Zusätzlich zu diesen offiziellen und über Kernel.org oder einen seiner Mirrors zu beziehenden Kernel-Quellcodes kann man auch alternative „Kernel-Trees“ aus anderen Quellen benutzen.
Distributoren von Linux-basierten Betriebssystemen pflegen meistens ihre eigenen Versionen des Kernels und beschäftigen zu diesem Zwecke fest angestellte Kernel-Hacker, die ihre Änderungen meist auch in die offiziellen Kernels einfließen lassen.
Distributions-Kernel sind häufig intensiv gepatcht, um auch Treiber zu enthalten, die noch nicht im offiziellen Kernel enthalten sind, von denen der Distributor aber glaubt, dass seine Kundschaft sie benötigen könnte und die notwendige Stabilität respektive Fehlerfreiheit dennoch gewährleistet ist.
Als Linux-Kernel -Betreuer sind neben Torvalds auch Alan Cox und Marcelo Tosatti sehr bekannt. Cox betreute bis Ende 2003 die Kernel-Reihe 2.2, Tosatti kümmerte sich bis Mitte 2006 um die Version 2.4 und Andrew Morton steuert die Entwicklung und Verwaltung des neuen 2.6-Kernels, welcher am 18. Dezember 2003 in einer als stabil (stable) vorliegenden Version veröffentlicht wurde.
Auch die älteren Zweige werden nach wie vor ständig verbessert.
Der Erfolg von Linux in vielen Einsatzbereichen ist insbesondere auf die Eigenschaften freier Software bezüglich Stabilität, Sicherheit, Erweiterbarkeit und Wartbarkeit, aber auch auf die entfallenden Lizenzkosten zurückzuführen.
Gegenwärtig ist David Weinehall für die 2.0er Serie verantwortlich, Marc-Christian Petersen für den Kernel 2.2, Willy Tarreau für den Kernel 2.4 und Andrew Morton für den aktuellen stabilen Kernel 2.6.
Die Kernel-Reihe 2.6 wurde ab Dezember 2001 auf Basis des damaligen 2.4er Kernels entwickelt und wies umfangreiche Neuerungen auf.
Für die Entwicklung war der neue Kernel-Code übersichtlicher und leichter zu pflegen, während Anwender durch die Überarbeitung der Scheduler und des I/O-Bereichs und von geringeren Latenzzeiten profitierten.
Dies wurde durch eine Reihe von Maßnahmen erreicht, die im Folgenden besprochen werden sollen:
Der O(1)-Scheduler
Der Scheduler ist der Teil der Prozessverwaltung, der den Prozessen Rechenzeit zuteilt. Ingo Moln hat Scheduler für den 2.6er Kernel komplett neu konzipiert und implementiert.
O(1)-Scheduler
* die vom Scheduler für eigene Aufgaben benötigte Prozessorzeit unabhängig von der Anzahl der verwalteten Prozesse bzw. Threads ist, er also Komplexität O(1) hat
Der O(1)-Scheduler arbeitet daher auch bei sehr vielen Prozessen überaus effizient und benötigt selbst sehr wenig Rechenzeit.
Verbesserte Interaktivität
* Der interne „Takt“ des Kernels wurde ab dem Kernel 2.6 von 100 Hz auf 1000 Hz erhöht, das heißt, die kürzestmögliche Länge einer Zeitscheibe beträgt nun eine Millisekunde.
verbessertes
Thread -Management
symmetrisches Multiprocessing (SMP)
Hyper-Threading
* Dies kommt vor allem hoch belasteten Servern zugute. In Testsituationen konnten unter dem neuen Scheduler 100.000 Threads gestartet werden, ohne dass das System subjektiv langsamer wurde.
Weiterhin sorgt der neue Scheduler dafür, dass die zur Verfügung stehenden CPUs optimal ausgelastet werden, ohne Prozesse übermäßig oft zwischen zwei CPUs hin- und herwechseln zu lassen.
Präemptiver Kernel
Der Kernel ist ab Version 2.6 in den meisten Funktionen präemptiv, d.h. selbst wenn das System gerade im Kernel-Modus Aufgaben ausführt, kann dieser Vorgang durch einen Prozess aus dem User-Modus unterbrochen werden. Das kommt ebenfalls der Interaktivität zugute.
Zugriffskontrolllisten
Seit dem Kernel 2.6 werden für Linux Zugriffskontrolllisten (access control lists) nativ eingeführt. Damit können beliebig viele Berechtigungen auf Dateien vergeben werden.
Inotify
Dies ermöglicht das permanente Überwachen von Dateien und Ordnern: Wird eines der überwachten Objekte geändert oder ein neues Objekt im Überwachungsraum erschaffen, gibt Inotify eine Meldung aus, die wiederum andere Programme zu definierten Tätigkeiten veranlassen kann.
Dies ist insbesondere für Such- und Indexierungsmechanismen der Datenbestände von entscheidender Bedeutung, und ermöglicht erst den sinnvollen Einsatz von Desktop-Suchmaschinen wie Kat oder Beagle.
Ohne eine solche Benachrichtigungsfunktion des Kernels müsste ein Prozess die zu überwachende Datei bzw. den zu überwachenden Ordner in bestimmten Zeitintervallen auf Änderungen überprüfen, was im Gegensatz zu Inotify zusätzliche Performance-Einbußen mit sich brächte.
Weitere wichtige Änderungen
Die Maximalzahl für diverse Ressourcen wurden angehoben
Die Anzahl von möglichen Benutzern und Gruppen wurde von 65.000 auf über 4 Milliarden
die Anzahl der Prozess-IDs (von 32.000 auf 1 Milliarde)
die Anzahl der Geräte (Major/Minor-Nummern)
Weitere leistungssteigernde Maßnahmen
das Threading mit der neuen Native POSIX Thread Library und den
Netzwerk-Stack: skaliert nun in den meisten Tests O(1)
für die Verwaltung der I/O-Gerätedateien wurde devfs durch udev ersetzt
Weitere Kernel-Funktionen
Software-RAID
PCMCIA-Unterstützung
Quota
Loopback für Netzwerk
Loopback für Dateisysteme
Der Kernel zeichnet sich durch eine sehr hohe Stabilität aus, Uptimes von über einem Jahr sind durchaus möglich. Außerdem ist er ressourcensparend, da er die Hardware besser ausnutzt besser angepasst werden kann).
Zukünftige Entwicklungen
Einheitliches WLAN-Subsystem
Jeff Garzik stellte Anfang 2006 fest, dass die Situation rund um WLAN-Treiber in Linux unausgegoren war:
Die meisten Treiber bauten auf verschiedenen, nicht einheitlichen Systemen auf.
Neue Treiber konnten damit nur schwer entwickelt werden, da schon zu Beginn unklar war, für welches Subsystem sie entwickelt werden sollten.
Auch war das Warten verschiedener Subsysteme und alter Treiber schwierig und erforderte einen großen Zeitaufwand.
Um diesen Problemen zu begegnen, wurde ein Verwalter für das WLAN-Subsystem bestimmt, John W. Linville, der sich seitdem um die Entwicklung kümmert.
Seitdem wird an einem einheitlichen Subsystem auf der Basis des Advanced Datapath Drivers gearbeitet, der von der Firma Devicescape für den Kernel 2.6 freigegeben wurde.
Entwicklungsprozess
Die Entwicklung von Linux liegt durch die GNU General Public License und durch ein sehr offenes Entwicklungsmodell nicht in der Hand von Einzelpersonen, Konzernen oder Ländern, sondern in der Hand einer weltweiten Gemeinschaft vieler Programmierer, die sich hauptsächlich über das Internet austauschen.
In vielen Mailinglisten, aber auch in Foren und im Usenet besteht für jedermann die Möglichkeit, die Diskussionen über den Kernel zu verfolgen, sich daran zu beteiligen und auch aktive Beiträge zur Entwicklung zu leisten.
Durch diese unkomplizierte Vorgehensweise ist eine schnelle und stetige Entwicklung gewährleistet, die auch die Möglichkeit mit sich bringt, dass jeder dem Kernel Fähigkeiten zukommen lassen kann, die er benötigt.
Eingegrenzt wird dies nur durch die Kontrolle von Linus Torvalds und einigen besonders verdienten Programmierern, die das letzte Wort über die Aufnahme von Verbesserungen und Patches in die offizielle Version haben.
Manche Linux-Distributoren bauen auch eigene Funktionen in den Kernel ein, die im offiziellen Kernel (noch) nicht vorhanden sind.
Der Entwicklungsprozess des Kernels selbst ist wie der Kernel ebenfalls immer weiterentwickelt worden.
So führte der Rechtsprozess der SCO Group um angeblich illegal übertragenen Code in Linux zur Einführung eines „Linux Developer's Certificate of Origin“, das von Linus Torvalds und Andrew Morton bekanntgegeben wurde.
Diese Änderung griff das Problem auf, dass nach dem bis dahin gültigen Modell des Linux-Entwicklungsprozesses die Herkunft einer Erweiterung oder Verbesserung des Kernels nicht nachvollzogen werden konnte.
Das Versionskontrollsystem git
Die Versionskontrolle des Kernels unterliegt dem Programm git. Dies wurde speziell für den Kernel entwickelt und auf dessen Bedürfnisse hin optimiert.
Es wurde im April 2005 eingeführt, nachdem sich abgezeichnet hatte, dass das alte Versionskontrollsystem BitKeeper nicht mehr lange für die Kernelentwicklung genutzt werden konnte.
Lizenz
Die bei GPL-Software übliche Klausel, dass statt der Version 2 der GPL auch eine neuere Version verwendet werden kann, fehlt beim Linux-Kernel.
Die Entscheidung, ob die im Juni 2007 erschienene Version 3 der Lizenz für Linux verwendet wird, ist damit prinzipiell nur mit Zustimmung aller Entwickler möglich.
In einer Umfrage haben sich Torvalds und die meisten anderen Entwickler für die Beibehaltung der Version 2 der Lizenz ausgesprochen.
