Linux-Distribution

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Linux-Distributor)
Wechseln zu: Navigation, Suche
Das Linux-Maskottchen Tux

Eine Linux-Distribution ist eine Sammlung von Programmen, die den Linux-Kernel als Betriebssystem und eine Anzahl von Anwendungen enthält. Fast jede Linux-Distribution ist um eine Paketverwaltung herum zusammengestellt, d. h. dass sämtliche Bestandteile als Software-Pakete vorliegen und sich über die Paketverwaltung installieren, deinstallieren und auch updaten lassen. Software-Pakete werden dazu online in sogenannten Repositories vorgehalten.

Eine Distribution wird von einem Linux-Distributor zusammengestellt, bedingt durch den Umstand, dass der Linux Kernel und der überwiegende Anteil der Programme freie Software sind, und somit die Weitergabe und Verbreitung durch Dritte ausdrücklich erlaubt ist. Der Distributor wählt sich beliebige Software aus dem ganzen Pool an verfügbarer freier Software aus, passt diese mehr oder weniger an seine Vorstellungen an, paketiert diese für die Paketverwaltung seiner Wahl und bietet das Ergebnis, die Linux-Distribution, aller Welt oder Kunden an. Lediglich wenige Programme werden vom Distributor selbst geschrieben, z. B. der Debian-Installer. Der Distributor kann ein Unternehmen oder eine Gruppe von weltweit verteilten Freiwilligen sein und er kann kommerziellen Support anbieten.

Konzept[Bearbeiten]

Aufgabe eines Linux-Distributors ist die Zusammenstellung eines für den vorgesehenen Anwendungszweck verwendbaren Gesamtsystems aus Sourcecodes und teilweise auch proprietären, binären Softwareteilen von anderen Softwareherstellern, um dieses dann als sogenannte Distribution anzubieten. Den zentralen Teil bilden dabei der Linux-Kernel selbst sowie Systemprogramme und Bibliotheken. Je nach dem vorgesehenen Anwendungszweck der Distribution werden verschiedene Anwendungsprogramme (z. B. Webbrowser, Office-Anwendungen, Zeichenprogramme, Mediaplayer etc.) hinzugefügt.

Da Linux-Distributionen die Anwendungsprogramme beinhalten, besitzen sie normalerweise eine sehr große Auswahl an installierbaren Anwendungen. Dies steht im konzeptuellen Gegensatz zu anderen Betriebssystemen wie Windows oder Mac OS X, die neben dem Betriebssystem selbst nur wenige Anwendungen enthalten, dafür auf die Integration von Programmen von externen Anbietern, sogenannten ISVs, setzen.

Ein Differenzierungsmerkmal der Distributionen untereinander sind die Unterstützungszeiträume bzw. die Update-Zyklen. Es existieren Distributionen, bei denen dieselbe Version über mehr als 7 Jahre mit Updates versorgt wird, (z. B. RHEL) während bei anderen schon nach einem halben Jahr zu einem Update auf die nächste Version geraten wird. Andere Distributionen haben gar keine Versionen, sondern sind sogenannte Rolling Releases, welche permanent Systemteile und Anwendungen erneuern.

Weitere Unterschiede zwischen den Distributionen können bezüglich der Lizenzpolitik gesehen werden. Einige Distributionen integrieren ausschließlich Freie Software, binär vertriebene proprietäre Software wird nicht in einer solchen Distribution zugelassen. Andere integrieren auch Proprietäre Software.

Weitere Aufgaben der Distributionen sind die Anpassung der Programme (durch Patchen), Hinzugabe von eigenen Programmentwicklungen (vor allem zur Installation und Konfiguration des Systems wie zum Beispiel apt, Synaptic, YaST) sowie (bis auf wenige Ausnahmen, z. B. Gentoo) Kompilierung und Paketierung (.deb, .rpm) der Programme. Die Bereitstellung von zusätzlichen Programmen und Updates erfolgt typischerweise zentral über ein Repository, welches über ein Paketverwaltungs-System mit dem Betriebssystem synchronisiert wird.

Auch wenn Linux-Betriebssysteme in der Form einer Distribution die bei weitem üblichste Variante ist, ist ein Betrieb von Linux auch ohne eine vorgefertigte Distribution möglich, wie das Projekt Linux From Scratch zeigt.

Zusammensetzung[Bearbeiten]

Bestandteile einer Linux-Distribution

Neben dem Linux-Kernel besteht eine Distribution meist aus der GNU-Software-Umgebung, die das grundlegende Basissystem mit den zahlreichen Systemdiensten (sogenannte Daemons) sowie diverse Anwendungen bereitstellt, die bei einem unixoiden System erwartet werden. Distributionen, welche auch oder nur für Desktop-Systeme gedacht sind, verfügen meist über ein X Window System. Ein solches ist für das Ausführen einer grafischen Benutzeroberfläche erforderlich. Darauf aufbauend steht meist eine Desktopumgebung, wie bspw. Gnome oder die KDE Software Compilation zur Verfügung, welche neben der reinen Benutzeroberfläche noch eine Vielzahl an Anwendungsprogrammen mitbringt.

Ergänzend fügt ein Distributor normalerweise zahlreiche weitere Anwendungen bei. Dies sind beispielsweise Office-Pakete, Multimediasoftware, Editoren, E-Mail-Programme, Browser, aber auch Server-Dienste. Daneben finden sich meist Softwareentwicklungs-Werkzeuge wie Compiler bzw. Interpreter sowie Editoren.

Viele Softwarebestandteile (z. B. der Compiler GCC), aus denen Linux-Distributionen bestehen, stammen aus dem älteren GNU-Projekt. Dieses hatte sich schon vor der Entwicklung von Linux die Aufgabe gestellt, eine Alternative zu den kommerziellen Unix-Betriebssystemen zu entwickeln. Da der eigene Kernel des GNU-Projekts, GNU Hurd, beim Erscheinen von Linux noch in der Entwicklung war, wurde als verfügbarer Ersatz der Linux-Kernel verwendet. Daher ist auch der Doppelname GNU/Linux für eine Distribution geläufig (z. B. bei Debian).

Es gibt auch Linux-Distributionen, die auf die GNU-Softwareanteile oder ein X Window System komplett verzichten und alternative Software an deren Stelle nutzen. Diese Distributionen verhalten sich, wie beispielsweise FreeVMS oder Cosmoe, teilweise auch nicht annähernd wie ein Unix-System.

Vertrieb[Bearbeiten]

Während proprietäre Betriebssysteme häufig über den Einzelhandel vertrieben werden, ist dies bei Linux-Distributionen eher die Ausnahme. Die meisten Distributionen können heute kostenlos von der Website der Anbieter heruntergeladen werden. Diese finanzieren sich über Spenden, über kostenpflichtigen Support oder auch einfach nur über die Beteiligung von Freiwilligen. Nur vergleichsweise wenige Distributionen werden von gewinnorientierten Firmen entwickelt und sind teilweise über den Einzelhandel verfügbar. Zahlreiche Linux-Distributionen werden auch, von den Kunden unbemerkt, als Firmware auf einem Gerät oder sogar in größeren Maschinen oder Anlagen erworben. Dabei kann es sich z. B. um Werkzeugmaschinen, Fahrzeuge, Haushaltsgeräte, SPS, Messgeräte, Mobiltelefone, Modems, Digitalkameras, NAS oder Fernseher handeln.

Geschichte[Bearbeiten]

Hauptartikel: Geschichte von Linux
Zeitleiste mit der Entwicklung verschiedener Linux-Distributionen

Da Linux nur ein Betriebssystem-Kernel ist, wird weitere Software benötigt, um ein benutzbares Betriebssystem zu erhalten. Aus diesem Grund kamen die ersten Linux-Distributionen schon kurz nach der GPL-Lizenzierung 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 beispielsweise mit der Software des GNU-Projekts zu einem arbeitsfähigen Betriebssystem zu bündeln. Zu ihnen gehörten MCC Interim Linux, das 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 zur gleichen Zeit erstellt wurde, und Softlanding Linux System (SLS). Die erste kommerziell auf CD erhältliche Distribution war 1992 das von Adam J. Richters entwickelte Yggdrasil Linux. Am 16. Juli 1993 veröffentlichte Patrick Volkerding die Distribution Slackware. Sie ist die älteste heute noch aktive Linux-Distribution.

Die ersten Nutzer kannten noch freie Software aus der Zeit vor den 1980er-Jahren und schätzten Linux, weil sie wieder die Verwertungsrechte an der von ihnen verwendeten Software besaßen. Spätere Nutzer waren Unix-Anwender, die Linux zunächst vor allem privat einsetzten und sich vor allem über den geringen Preis freuten. 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 Entwicklergruppen als auch von Firmen oder gemeinnützigen Projekten entwickelt und betrieben.

Die Frage, welche Distributionen besonders beliebt sind, lässt sich nur schwer beantworten. Im deutschsprachigen Raum werden vor allem Ubuntu, Debian, openSUSE und Knoppix häufiger auch außerhalb der IT-Presse erwähnt. Darüber hinaus wäre Fedora zu nennen, das von dem börsennotierten US-Unternehmen Red Hat entwickelt wird.

Arten von Distributionen[Bearbeiten]

Da Distributionen praktisch eigene Produkte sind, konkurrieren diese am Markt miteinander und versuchen sich einerseits voneinander abzugrenzen, andererseits aber auch anderen Distributionen keinen zu großen Vorteil zu überlassen. Daher unterscheiden sich zwar sämtliche Distributionen, es gibt aber kaum etwas, wofür sich nicht jede Distribution anpassen ließe. Hiervon ausgenommen sind nur Spezial-Systeme, etwa als Software im Embedded-Bereich.

Einige Distributionen sind speziell auf einen Anwendungsfall optimiert, so gibt es etwa Systeme speziell für den Einsatz in Bildungseinrichtungen mit hierfür spezialisierter Software und zumeist einem Terminal-Server-System, wodurch nur ein leistungsstarker Rechner benötigt wird und ansonsten auch ältere Hardware ausreicht. Beispiele sind hier Edubuntu oder Skolelinux. Ebenso gibt es Systeme speziell für veraltete Rechner, die einen geringeren Funktionsumfang haben und geringe Systemanforderungen stellen. Beispiele sind etwa Damn Small Linux oder Puppy Linux, die einen Umfang von nur 50 beziehungsweise 100 MB haben.

Smartphone-Distributionen[Bearbeiten]

Android-4.1-Oberfläche

Für Smartphones gibt es spezielle Linux-Distributionen.[1] Sie bieten neben den Telefonie- und Textnachrichten-Funktionen diverse PIM-, Navigations- und Multimedia-Funktionen. Die Bedienung erfolgt meist über Multi-Touch oder mit einem Stift. Diese Linux-Distributionen werden meist von einem Firmenkonsortium oder einer einzelnen Firma entwickelt. Teilweise unterscheiden sie sich sehr stark von den sonst klassischen Desktop- und Server-Distributionen. Anders als im Embedded-Bereich sind die Smartphone-Distributionen aber nicht auf ein bestimmtes Gerät beschränkt. Sie dienen als Betriebssystem für Geräte ganz unterschiedlicher Modellreihen, die oft sogar von verschiedenen Herstellern angeboten werden.

Vertreter sind Android, Bada, Maemo, Mobilinux und WebOS. Die Architektur solcher Smartphone-Linux-Distributionen,[1] wie z. B. Android, hat neben dem Linux-Kernel nur wenig Gemeinsamkeiten mit klassischen Linux-Distributionskonzepten. Es wird typischerweise auch nur ein kleiner Teil der sonst üblichen GNU-Software-Umgebung und -Tools genutzt.[2] Da Android nicht vollständig freie Software ist (u.a. sind Googles Anteile nur unter der GPLv2-inkompatiblen Apache-Lizenz freigegeben[3]) und Googles Android Market die Verwendung unkontrollierter proprietärer Binär-Software ermöglicht, steht Richard Stallman und die FSF Android sehr kritisch gegenüber und empfehlen die Verwendung von Alternativen.[2][4] Bei Android wurden einige üblicherweise mit Linux genutzte UNIX-artige Dienste, Bibliotheken und Tools durch Java-Runtime-basierende Dienste und Tools ersetzt, wodurch eine Portierung vorhandener nativer Linux-Applikationen oder Bibliotheken schwierig sein kann.[5] Die neu definierten Programmierschnittstellen lassen sich jedoch auch auf klassischen Linux-Systemen emulieren bzw. umsetzen.[6]

Während die Marktanteile von bisher verbreiteten Mobil-Plattformen wie Apples iOS, Microsofts Windows Mobile und Nokias Symbian OS sanken, konnte Android Marktanteile hinzugewinnen.[7] Seit Ende 2010 haben Linux-basierte Distributionen die Marktführerschaft auf dem schnell wachsenden Smartphone-Markt übernommen.[8] Sie wiesen zusammen im Juli 2011 eine Marktanteil von mindestens 45 %[9] auf. Während sich die Linux-basierenden Smartphone-Distributionen Bada oder WebOs nicht am Markt durchsetzen konnten (Stand 2012), ist die Nachfrage nach Googles Android weiter gewachsen. Während im August 2012 die Android-Distribution bereits einen Marktanteil von 69,1 % erreicht hatte, konnte er ein Jahr später noch weiter auf 79, 3% gesteigert werden.[10]

Live-Systeme[Bearbeiten]

Hauptartikel: Live-System

Eine Besonderheit bilden Live-Systeme, die von CD, DVD, USB und anderen Medien gebootet werden. Handelte es sich hierbei zunächst nur um spezialisierte Distributionen, die den Funktionsumfang von Linux demonstrieren sollten, gehört es inzwischen zum guten Ton unter Linux-Distributionen, den Standard-Umfang in Form einer Live-CD oder (seltener) -DVD anzubieten. Einige dieser Systeme lassen sich auch direkt von der CD aus installieren.

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. Live-Systeme 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.

Linux-Distributionen neben anderen Betriebssystemen[Bearbeiten]

Die meisten Linux-Distributionen können auf derselben Hardware parallel zu anderen Betriebssystemen installiert werden. Als solche kommen bspw. eine weitere Linux-Distribution, ein anderes unixoides Betriebssystem wie Mac OS X oder Solaris, oder aber auch ein Windows in Betracht. Prinzipiell sind zwei Vorgehensweisen zu unterscheiden:

Multi-Boot[Bearbeiten]

Hauptartikel: Multi-Boot-System

In einer Multi-Boot-Konfiguration werden zwei oder mehr Betriebssysteme parallel auf verschiedene Festplatten-Partitionen installiert. Installationsprogramme moderner Linux-Distributionen können meist bereits installierte Betriebssysteme erkennen und eigenständig eine Multi-Boot-Konfiguration einrichten. Nach der Installation kann beim Bootvorgang über einen Bootloader oder Bootmanager gewählt werden, welches Betriebssystem starten soll.

Virtualisierung[Bearbeiten]

Werden die Betriebssysteme häufig gleichzeitig genutzt, bietet sich u. U. eher eine Virtualisierungs-Lösung an. Zu unterscheiden sind hierbei das Host- und Gast-System. Ersteres ist tatsächlich physisch auf der Hardware installiert. Innerhalb dessen kommt eine Virtualisierungssoftware wie bspw. VirtualBox oder KVM zum Einsatz. Diese emuliert für das Gast-System die gesamte erforderliche Hardware oder bietet durch ein Sicherheitssystem direkten Zugriff auf die tatsächlich vorhandene Hardware des Computers. Da diese in einer solchen Konfiguration für den gleichzeitigen Betrieb beider Systeme erforderlich ist, kann es zu Geschwindigkeitseinbußen kommen.

Unterschiede zwischen einzelnen Distributionen[Bearbeiten]

Selbst wenn man Spezial-Distributionen außer Acht lässt, unterscheiden sich auch gängige Linux-Distributionen in einigen Punkten. Wichtige Einstellungsmerkmale bilden zunächst Werkzeuge zur Installation wie bspw. Partitionierungstools. Diese richten sich meist nach dem Nutzerkreis einer Distribution. Während Anfängern bspw. nur wenig Optionen angeboten werden, um diese nicht zu überfordern, richten sich andere Distributionen an fortgeschrittenere Anwender, welche mehr Einstellungsmöglichkeiten bereits im Installationsstadium bevorzugen. Nach der Installation setzt sich dieser Unterschied, orientiert am Nutzerkreis, meist im Umfang von Konfigurationsprogrammen fort. So bieten manche Distributionen ausgereifte grafische Werkzeuge zur Bearbeitung von Konfigurationsdateien an, während andere lediglich die direkte Bearbeitung solcher vorsehen. Letzteres bietet jedoch oftmals die Möglichkeit einer genaueren Anpassung auf die eigenen Bedürfnisse, setzt im Gegenzug jedoch umfangreicheres Wissen beim Anwender voraus.

Weiter unterscheiden sich Distributionen häufig erheblich in ihrem Umfang und der Anzahl der unterstützten Architekturen. Auch spielen Art und Umfang der Dokumentation eine Rolle. So liegen einigen Produkten Handbücher bei, während andere nur Dokumentation auf Webseiten veröffentlichen. Manche verzichten ganz auf eine offizielle Dokumentation und lassen eine solche lieber – bspw. in Form von Wikis – von der Nutzerschaft pflegen. Kommerzielle Distributoren bieten daneben meist offiziellen Support an, welcher als Dienstleistung allerdings vergütet werden muss. Daneben gibt es Unterschiede im Hinblick auf die jeweilige Politik bezüglich proprietärer Software wie bspw. Adobe Flash, dem MP3-Codec oder proprietären Hardwaretreibern. Während einige Distributionen wie zum Beispiel Debian auf proprietäre Pakete prinzipiell verzichten, liefern andere diese mit, um die Nutzung zu vereinfachen. Zu unterscheiden sind weiter Community-Distributionen (bspw. Debian) von solchen, hinter denen Unternehmen stehen (bspw. Ubuntu). Entsprechend der Zielgruppe einer Distribution sind auch Größe und Fachkenntnis und Größe der Nutzerschaft verschieden. Hinsichtlich der installierbaren Software spielt für viele Nutzer auch das Angebot von bereits angepassten und fertig verpackten Softwarepaketen eine Rolle.

Kompatibilität zwischen den Distributionen[Bearbeiten]

Die Unterschiede zwischen den Distributionen wirken sich oftmals auf deren Kompatibilität aus.[11]

Schon früh in der Geschichte der Distributionen entstanden Konzepte, die Installation weiterer Software zu vereinfachen. Meist sollte Software in Form kompilierter Pakete bereitgestellt und ein Mechanismus mitgeliefert werden, der funktionelle Abhängigkeiten zwischen installierten und nachgeladenen Paketen auflösen kann. Die entstandenen Paketmanagement-Systeme arbeiten mit je eigenen Paketformaten, zum Beispiel RPM oder dpkg. Viele Linux-Distributionen haben eine eigene Softwareverwaltung mit eigenen Binärpaketen, die zu anderen Distributionen teilweise inkompatibel sind.

Die Kritik am Prinzip der Linux-Distributionen setzt unter anderem an diesem Punkt an.[11][12] Da nicht jedes Software-Projekt und nicht jeder Software-Entwickler die Kenntnisse und Ressourcen hat, Software für jede einzelne Linux-Distribution bereitzustellen, wird oft nur der Quelltext veröffentlicht. Aus dem veröffentlichten Quelltext lauffähige Anwendungen zu erzeugen, ist jedoch potentiell ein komplizierter und fehlerträchtiger Prozess, der vielen Anwendern zu kompliziert sein kann. Diese bleiben dann oft auf die von der Distribution mitgelieferte Software angewiesen bzw. limitiert.[13] Die Bereitstellung des Quellcodes als Softwareauslieferungsmethode ist jedoch für Anbieter kommerzieller Software, die Software binär ausliefern wollen, keine Option, weswegen diese die Menge von Distributionen und deren Paketformaten mit spezifischen Paketen bedienen müssen, was einen großen Mehraufwand bedeutet.[14][15][16] Im Umfeld von Unternehmen hat deshalb nur eine begrenzte Auswahl an Distributionen eine Chance als allgemeine Arbeitsplattform.

Standardisierungsansätze[Bearbeiten]

Damit sich die Distributionen nicht weiter auseinanderentwickeln, wurde die Free Standards Group (heute Linux Foundation) mit dem Ziel gegründet, entsprechende Standards zwischen Distributionen zu fördern. Der Bekannteste ist die Linux Standard Base zur Förderung der binären Kompatibilität der Distributionen. Die LSB wird dabei von den verschiedenen Distributionen unterschiedlich strikt umgesetzt. Sie definiert ü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 Software anderer Anbieter unterstützt werden muss.

Die praktische Bedeutung dieser Regeln ist allerdings nur begrenzt.[17] Die einseitige Festlegung auf des RPM-Paketformat wird teilweise angezweifelt, nachdem in den letzten Jahren durch Ubuntu oder Linux Mint das dpkg-Format eine große Verbreitung erlangt hat. Weil die meisten Distributionen die dpkg nutzen, direkt auf Debian basieren, sind deren Pakete oft in anderen Distributionen die ebenfalls auf Debian basierenden installierbar. Auf der anderen Seite setzen alle von Fedora (respektive Red Hat Linux), OpenSuse und Mandriva abstammenden Distributionen auf RPM. Es ist mit einigen Einschränkungen durchaus möglich - z. B. mit Hilfe des OpenSuse Build Service - RPM-Pakete zu erstellen, die auf allen diesen Distributionen nutzbar sind.[18]

Eine weitere Standardisierung stellt der Filesystem Hierarchy Standard dar, der eine gemeinsame Benennung einiger Datei- und Verzeichnisnamen und eine übereinstimmende Struktur der Basisverzeichnisse ermöglichen soll. Allerdings sind auch hier Details nicht geregelt, die bisher die Inkompatibilitäten erzeugten. Andere Probleme ergeben sich erst durch die feste Integration von Anwendungen in den Systemverzeichnisbaum.[19] Er wird von der Linux Standard Base vorausgesetzt.

Weil die Standards nicht ausreichend umgesetzt wurden, kündigte im Dezember 2006 Ian Murdock, damals Technikchef der Free Standards Group, im Rahmen der Linux Standard Base eine weitere Initiative an, die Installation von Software zu vereinfachen. Kern des Verfahrens ist eine Programmierschnittstelle, die über das Paketmanagement der jeweiligen Distribution gelegt wird. Diese Schnittstelle kann Standardfunktionen für das Softwarepaket bereitstellen und sie für die jeweilige Distribution umsetzen. So soll es möglich sein, Dateien und Abhängigkeiten an das distributionseigene Paketmanagementsystem weiterzugeben.[20][21] Eine praktische Umsetzung hierzu gab es jedoch zumindest bis Anfangs 2013 nicht.

Alternativansätze für die Programmverbreitung[Bearbeiten]

Es gibt einige Alternativansätze zu dem Modell der zentralen Softwareverbreitung über die Distributionen und deren Repositories. Projekte wie Autopackage[22], Zero Install[23] oder der Klik-Nachfolger PortableLinuxApps[24] versuchen eine einheitliche, aber dezentrale, distributionsunabhängige, binäre Softwareverbreitungsmöglichkeit zu schaffen, konnten aber bis jetzt faktisch keine relevante Verbreitung oder Unterstützung der Linux-Community erreichen.[25]

Ein Schritt in diese Richtung war 2011 die Einführung eines Software Center in Ubuntu[26], nach dem Modell des App Stores von Apple, um die Anzahl der Applikationen signifikant erhöhen zu können, da das Distributionsmodell nur begrenzt skaliert.[27]

2012 betonte auch Kernelentwickler Ingo Molnar die Notwendigkeit der Bereitstellung einer solchen dezentralen, skalierungfähigen und distributionsunabhängigen Softwareverbreitungsmethode; das Fehlen eines solchen Mechanismus sei eines der Kernprobleme des Linux-Desktops.[28]

Siehe auch[Bearbeiten]

Literatur[Bearbeiten]

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. a b Adrian Kingsley-Hughes: The death of the Linux distro (englisch) In: The death of the Linux distro. CBS Interactive. 14. Februar 2012. Abgerufen am 19. September 2012: „"Take a look at how Android has become the dominant Linux distro on mobile platforms. […] So again, while B2G is essentially a Linux distro, people will come […]
  2. a b Richard Stallman: Is Android really free software? - Google's smartphone code is often described as 'open' or 'free' – but when examined by the Free Software Foundation, it starts to look like something different (englisch) The Guardian. 19. September 2011. Abgerufen am 9. September 2012: „the software of Android versions 1 and 2 was mostly developed by Google; Google released it under the Apache 2.0 license, which is a lax free software license without copyleft. […] The version of Linux included in Android is not entirely free software, since it contains non-free "binary blobs" […] Android is very different from the GNU/Linux operating system because it contains very little of GNU.
  3. Licenses (englisch) In: Licenses. Open Handset Alliance. Abgerufen am 9. September 2012: „The preferred license for the Android Open Source Project is the Apache Software License, 2.0. [...] Why Apache Software License? [...] For userspace (that is, non-kernel) software, we do in fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other licenses such as LGPL. Android is about freedom and choice. The purpose of Android is promote openness in the mobile world, but we don't believe it's possible to predict or dictate all the uses to which people will want to put our software. So, while we encourage everyone to make devices that are open and modifiable, we don't believe it is our place to force them to do so. Using LGPL libraries would often force them to do so.
  4. Richard Stallman: Android und die Freiheit der Nutzer - Unterstützen Sie die Kampagne Befreien Sie Ihr Android!. gnu.org. 5. August 2012. Abgerufen am 9. September 2012: „Obwohl heutige Android-Telefone erheblich weniger schlecht als Apple- oder Windows-Smartphones sind, kann nicht gesagt werden, dass sie die Freiheit der Nutzer respektieren.
  5. Ryan Paul: Dream(sheep++): A developer's introduction to Google Android (englisch) In: Ars Technica. 23. Februar 2009. Abgerufen am 15. Februar 2012: „The problem with Google's approach is that it makes Android an island. The highly insular nature of the platform prevents Android users and developers from taking advantage of the rich ecosystem of existing third-party Linux applications. Android doesn't officially support native C programs at all, so it won't be possible to port your favorite GTK+ or Qt applications to Android.
  6. What is Android? (englisch)
  7. Kennzahlen zum Mobile-Markt von Business Insider, 15. April 2012, Alexander Oschatz, Radenbul, zugegriffen: 19. Juni 2012
  8. Google’s Android becomes the world’s leading smart phone platform (englisch), zugegriffen 11. August 2011
  9. Nokias Krise verschärft sich. NZZ-Online. 11. August 2011. Abgerufen am 10. Januar 2012.
  10. Marktforscher: Windows Phone explodiert. heise online news. 7. August 2013. Abgerufen am 8. April 2014.
  11. a b Tony Mobily: 2009: software installation in GNU/Linux is still broken -- and a path to fixing it. www.freesoftwaremagazine.com. 23. Juni 2009. Abgerufen am 4. August 2011.
  12. Troy Hepfner: Linux Game Development Part 2 - Distributable Binaries (englisch) 1. Oktober 2007. Archiviert vom Original am 13. Oktober 2007. Abgerufen am 19. Dezember 2011: „Creating an executable that works on almost all Linux distributions is a challenge. There are a number of factors that contribute to the problem […]
  13. John King: Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS - Bug #578045 (englisch) In: Launchpad. Ubuntu. 10. Mai 2010. Abgerufen am 27. Mai 2012: „It is easier to upgrade to the newest stable versions of most applications -- even open source applications -- on a proprietary operating system than it is on Ubuntu.
  14. Eskild Hustvedt: Playing well with distros (englisch) Linux Game Publishing. 24. November 2009. Abgerufen am 15. Januar 2012.
  15. Miguel de Icaza: Linux and Independent Software Vendors (englisch) primates.ximian.com. 4. November 2003. Abgerufen am 7. April 2012: „[…] staffing requirements for maintaining and testing […] software for a dozen of distributions and release versions quickly becomes a big burden […]
  16. Dave Burke: Porting Osmos to Linux: A Post-Mortem (part 2/3) (englisch) hemispheregames.com. 18. Mai 2010. Abgerufen am 16. Juni 2012: „Didn’t Love: Packaging the Game. It took days of effort to create the binary packages for Osmos […] How should an app be packaged in Linux? […]There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32bit and 64bit executables […]
  17. Eric Brown: LSB 4.0 certifications aim to heal Linux fragmentation (englisch) linuxfordevices.com. 8. Dezember 2010. Abgerufen am 16. November 2011: „[…] LSB helps to reduce fragmentation, it does not eliminate it. "The issue of packaging and broader dependencies is still a big one (for me) at least," writes Kerner. "The same RPM that I get for Fedora won't work on Ubuntu, and Ubuntu DEB packages won't work on SUSE etc etc." […]
  18. openSUSE:Build Service cross distribution howto. Suse (Novell), 11. Mai 2013, abgerufen am 6. Februar 2014 (englisch).
  19. Hisham Muhammad: The Unix tree rethought: an introduction to GoboLinux. www.kuro5hin.org. 9. Mai 2003. Abgerufen am 3. Juni 2010.
  20. Ian Murdock: Software installation on Linux: Today, it sucks (part 1) in seinem Weblog, 15. Dezember 2006
  21. Ian Murdock: Software installation on Linux: Tomorrow, it won’t (with some cooperation) (part 2) in seinem Weblog, 19. Dezember 2006
  22. Robert Staudinger: Distributionsunabhängige Pakete mit Autopackage - Eines für alle. Linux-Magazin 2006/02. 1. Februar 2006. Abgerufen am 11. April 2012: „Obwohl sie nach dem gleichen Prinzip arbeiten, laufen RPMs von Suse 9.2 nicht unter Suse 9.3 und schon gar nicht unter Red Hat. Das Autopackage-Projekt setzt auf einen einheitlichen Standard für die Erstellung von Installationspaketen. Dabei lösen die einzelnen Pakete ihre Abhängigkeiten selbst auf.
  23. Thomas Leonard: Decentralised Installation Systems (englisch) osnews.com. 16. Januar 2007. Abgerufen am 3. Mai 2012.
  24. Simon Peter: AppImageKit Documentation 1.0 (pdf; 38 kB) PortableLinuxApps.org. S. 2-3. 2010. Abgerufen am 29. Juli 2011: „Linux distributions mostly use package managers for everything. While this is perceived superior to Windows and the Mac by many Linux enthusiasts, it also creates a number of disadvantages: Centralization […], Duplication of effort […], Need to be online […], No recent apps on mature operating systems […], No way to use multiple versions in parallel […], Not easy to move an app from one machine to another […]. The AppImage format has been created with specific objectives in mind: Be distribution-agnostic […], Maintain binary compatibility […]
  25. Bruce Byfield: Autopackage struggling to gain acceptance (englisch) linux.com. 12. Februar 2007. Archiviert vom Original am 31. März 2008. Abgerufen am 21. Januar 2012: „If Hearn is correct, the real lesson of Autopackage is not how to improve software installation, but the difficulty -- perhaps the impossibility -- of large-scale changes in Linux architecture this late in its history. It's a sobering, disappointing conclusion to a project that once seemed so promising.
  26. Software Center ersetzt Synaptic. 23. Juni 2011, abgerufen am 29. September 2011 (englisch).
  27. Matthew Paul Thomas: UDS N Monday plenary: Getting great applications on Ubuntu (englisch) In: Ubuntu Developer Summit 2010. 25. Oktober 2010. Abgerufen am 29. April 2012.
  28. Ingo Molnar: Ingo Molnar (englisch) plus.google.com. 17. März 2012. Abgerufen am 16. Juni 2012: „So, to fix desktop Linux we need a radically different software distribution model: less of a cathedral, more of a bazaar. […] - totally flat package dependencies (i.e. a package update does not forcibly pull in other package updates) […] - a guaranteed ABI platform going forward (once a package is installed it will never break or require forced updates again). Users want to be free of update pressure from the rest of the system, if they choose to.