GNU/Linux ist also ein Betriebssystem, das mindestens aus mehreren Programmen besteht: Linux Kenel, GCC, Gnu-Binutils, Gnome-Desktop usw.
Was macht eine Linux-Distribution zu GNU? Sind es die Werkzeuge, mit denen der Kernel kompiliert wurde? Sind es die Werkzeuge, mit denen die Distribution ausgeliefert wird?
Gibt es voll funktionsfähige Desktop-Betriebssysteme, die auf Linux basieren, aber nicht auf GNU?
Antwort1
DerDie Free Software Foundation argumentiertdass die Mehrheit der Linux-Distributionen tatsächlich GNU-Systeme sind, die zufällig einen Linux-Kernel verwenden. Sie stützen diese Behauptung auf die Tatsache, dass GNU ein langjähriges Projekt zur Entwicklung eines freien Betriebssystems war, bevor Linux auf den Markt kam, und dassder Kernel war nur das letzte fehlende Stück. Sie haben Recht, da praktisch alle Linux-basierten Desktop- und Server-Distributionen zumindest einige GNU-Komponenten verwenden, vielleicht am wichtigsten dieGNU C-Bibliothek(glibc),GNU-Kernprogramme(coreutils) und dieSchlagShell. Darüber hinaus ist die Linux-Kernel-Entwicklung von Natur aus an GCC gebunden, aufgrund derNutzung von GCC-Erweiterungen.
Einige eingebettete Systeme, vor allem Googles Android, verwenden keine GNU-Komponenten oder -Bibliotheken. In Android wird beispielsweise die GNU C-Bibliothek durch Googles eigene, BSD-basierte Bionic C-Bibliothek ersetzt. Die FSF stimmt zu, dass es nicht angemessen ist, ein solches System als„GNU-Systeme“ oder „GNU/Linux“, aber andererseits wollen sie auch nicht, dass diese nur als "Linux"-Systeme bezeichnet werden. Zumindest können wir daraus schließen, dass es Konsens darüber zu geben scheint, dass die Verwendung von GNU-Tools zum Erstellen des KernelsnichtMachen Sie ein System zu einem „GNU-System“.
Antwort2
Die Geschichte der GNU/Linux-Terminologie reicht bis in die frühen 1990er Jahre zurück.
1991 startete Linus Torvalds das Linux-Kernel-Projekt in seinem Schlafzimmer in Helsinki. Nicht lange danach gewann der Linux-Kernel erheblich an Bedeutung, was durch den Aufstieg des Internets begünstigt wurde.
Richard Stallmans GNU-Projekt plante damals noch, den HURD-Mikrokernel als Kernel des geplanten GNU-Betriebssystems zu verwenden. Als sich jedoch Linux-Distributionen (freie Unix-ähnliche Betriebssysteme auf Basis des Linux-Kernels) rund um das neue Linux-Kernel-Projekt bildeten, wurde Stallmans Interesse geweckt. Als das Debian-Projekt 1993 unter der Leitung von Ian Murdock begann, unterstützte die FSF das junge Projekt finanziell. Die Debian-Entwickler trennten sich jedoch schnell von Stallman und der FSF, teilweise aus technischen Gründen. Ein Problem war beispielsweise, dass Stallman die Debugsymbole im Programm beibehalten wollte, während Debian sie entfernen wollte.
Nachdem sich Debian und die FSF getrennt hatten, bat Stallman darum, dass Debian sich als GNU/Linux bezeichnen sollte. Diese Bitte wurde an Bruce Perens gerichtet, da Murdock die Leitung an ihn übergeben hatte. Da sich diese Organisationen im Guten getrennt hatten und gemeinsame Ziele hatten (und haben), taten die Debian-Entwickler seine Bitte. Natürlich hat Stallman derartige Namen unabhängig voneinander gefördert, aber die Kooperation eines tatsächlichen Linux-basierten Betriebssystems, das sich selbst als solches bezeichnete, war für die Förderung der Verwendung eines solchen Namens von entscheidender Bedeutung.
Stallmans Begründung lautete, dass (a) der Kern des Systems abgesehen vom Linux-Kernel größtenteils aus GNU-Tools bestand, (b) der Linux-Kernel in gewisser Weise die Krönung/Vollendung des GNU-Projekts war, das seit einiger Zeit versucht hatte, einen funktionierenden Kernel zu bekommen, und daher diesen Namen als eine Möglichkeit verwenden sollte, die Ideale des GNU-Projekts anzuerkennen und die Leute daran zu erinnern. Grund (a) wird tendenziell häufiger genannt, obwohl er damals nicht ganz zutraf und heute noch weniger zutrifft. Obwohl wichtige Teile eines Linux-basierten Betriebssystems eindeutig von GNU-Tools abhängen, z. B. Bash, GCC, Binutils, GDB, Libc usw., können diese in einigen Fällen durch andere Tools ersetzt werden. Solche Argumente sind also zumindest diskutabel und wurden tatsächlich viel diskutiert.
Soweit ich weiß, bezeichnen sich nur Debian und (einige) seiner Derivate (die dem Beispiel seines Vorgängers folgen) als GNU/Linux. Die anderen sogenannten Linux-Distributionen wie Fedora, Gentoo usw. unterscheiden sich jedoch im Wesentlichen nicht von Debian – es handelt sich größtenteils um dieselbe Software. Man hat also ebenso gute Gründe, sie als GNU/Linux zu bezeichnen.
Es gibt nicht viele Systeme, die den Linux-Kernel ohne das GNU-Userland verwenden, da die beiden größtenteils gemeinsam entwickelt wurden und auf verschiedene Weise miteinander verflochten sind. (Beispielsweise ist der Linux-Kernel in der erweiterten (GNU) C von gcc geschrieben und lässt sich nicht mit einem Standard-C-Compiler erstellen.) Wie Thomas sagte, ist Android das offensichtlichste Beispiel, aber da es von Google so stark geforkt wurde, ist es fraglich, ob es noch richtig ist, den Android-Kernel als Linux zu bezeichnen, obwohl von einer zukünftigen Zusammenführung/Versöhnung die Rede ist.
Nebenbei bemerkt muss man leider feststellen, dass Stallman und die FSF die GNU/Linux-Terminologie anscheinend ziemlich stark vorantreiben. Jonathan Corbet zum Beispielschrieb in einem LWN-Kommentardass die FSF sich weigert, mit ihm zu sprechen, es sei denn, er verwendet den Begriff GNU/Linux. Jon ist nicht nur Gründer von LWN, sondern auch ein erfahrener und angesehener Kernel-Entwickler. Der Kommentar lautet in seiner Gesamtheit:
Um das klarzustellen: Wir haben schon vor vielen Jahren aufgehört, die FSF um Kommentare zu bitten, weil die FSF sich weigerte, mit uns zu sprechen, ohne dass wir ihr vorher versprochen hatten, was wir sagen und welche Begriffe wir verwenden würden. Wir sind nicht bereit, solche Versprechen zu machen. Wenn sich die Politik der FSF in solchen Dingen geändert hat, würden wir uns freuen, davon zu erfahren.
Dies ist unter anderem eindeutig ein Hinweis auf das Beharren auf der GNU/Linux-Terminologie.
Die obige Geschichte wird ausführlich in Kapitel 6 („Boot Then Root“) von „Rebel Code“ von Glyn Moody behandelt.
Antwort3
Ein Betriebssystem ist eine Kombination aus Kernel und Userland. Der Kernel verwaltet im Wesentlichen die Hardware, während das Userland den Benutzern eine umfassende Schnittstelle bietet.
In einer gängigen GNU/Linux-DistributionLinuxstellt den Kernel bereit, während derGNU-Projektbringt die Userland-Tools. GNU wurde lange vor Linux gestartet und bietet eine große Anzahl von Dienstprogrammen zum Erstellen eines vollständigen Betriebssystems.
Allerdings fehlte ihnen ein Kernel. Obwohl sie denHurdKernel, es dauerte zu lange, bis er fertig war. Und dannkam LinuxDank der großen Begeisterung, die es verbreitete, hat es sich schneller entwickelt als Hurd.
Sie haben jetzt ein Userland und einen Kernel aus zwei verschiedenen Projekten. Und da beide für ein Betriebssystem unerlässlich sind, warum benennen Sie die Assoziation nicht?GNU/Linuxalso erhält jedes Projekt seinen Anteil am Verdienst?
Sie haben andere Userlands wie die BSD-Utilities oderBusyBox. Allerdings sind sie im Vergleich zu den GNU-Dienstprogrammen mehr oder weniger vollständig und manche Software funktioniert nur mit einem GNU-Userland. Beispielsweise verwenden die meisten BSD-Betriebssysteme GCC als Compiler, währendLLVMwird diese Situation bald ändern.
Und als universelles Betriebssystem können SieDebian mit einem FreeBSD-Kernel und einem GNU-Userland.
Antwort4
Was macht eine Linux-Distribution zu GNU? Sind es die Werkzeuge, mit denen der Kernel kompiliert wurde? Sind es die Werkzeuge, mit denen die Distribution ausgeliefert wird?
Ja und ja. Der Kernel ist eine monolithische, eigenständige ausführbare Datei.Allessonst befindet sich in "Benutzerland". Im Allgemeinen verwenden Userland-Anwendungen mindestens eine Systembibliothek, die Standard-C-Bibliothek. 1 Neben verschiedenen Hilfsfunktionen bietet diese den Zugriff auf Systemaufrufe – Aufforderungen an das System, d. h. den Kernel, etwas zu tun –, was selbst für sehr grundlegende Aufgaben wie das Arbeiten mit Dateien erforderlich ist. Die unter Linux verwendete C-Bibliotheksimplementierung ist glibc – die GNU C-Bibliothek.
Der Linux-Kernel selbst ist in C geschrieben und benötigt ebenfalls eine C-Bibliothek, um zu funktionieren – allerdings sind in diesem Fall die erforderlichen Teile einkompiliert und nicht extern. Der dafür normalerweise verwendete Compiler ist GCC – die „GNU Compiler Collection“ – und die C-Bibliothek ist glibc.
Da praktisch das gesamte Userland mit glibc kompiliert wird, ist es nach dem Kernel eines der wichtigsten Dinge im System. Eine weitere wichtige Komponente ist der Linker, der eine ausführbare Datei mit einer externen Bibliothek verbindet. Auch das ist ein GNU-Produkt.
Um dies zu veranschaulichen, können Sie es lddauf verschiedene ausführbare Dateien anwenden, einschließlich Bibliotheken (die ausführbar sind, aber nicht für sich allein stehen). Wie es in der Manpage heißt, „druckt ldd die gemeinsam genutzten Bibliotheken aus, die von jedem Programm oder jeder gemeinsam genutzten Bibliothek benötigt werden, die in der Befehlszeile angegeben werden.“ Beispiel:
> ldd /bin/bash
linux-vdso.so.1 => (0x00007fff7348e000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fdbdae7f000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fdbdac7b000)
libc.so.6 => /lib64/libc.so.6 (0x00007fdbda8c3000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdbdb0c8000)
Beachten Sie „libc.so.6“ – das ist glibc (nicht zu verwechseln mit glib, einem anderen GNU-Produkt, das für Linux grundlegend ist, aber nicht so grundlegend wie glibc). Wenn Sie sich alle anderen erwähnten Dinge ansehen (außer dem ersten, das unten erklärt wird), werden Sie feststellen, dass sie alle selbst auf libc verweisen. Sehen wir uns libc.so.6 selbst an:
> ldd /lib64/libc.so.6
/lib64/ld-linux-x86-64.so.2 (0x00007f9cefa04000)
linux-vdso.so.1 => (0x00007fffb21ff000)
"ld-linux-x86-64.so.2" ist der oben erwähnte Linker (im Allgemeinen , ldund er hat eine Manpage). Sie können ldd nicht darauf ausführen, aber filees wird gesagt, dass er dynamisch verknüpft ist, vermutlich mit libc (das mag zirkulär klingen, ist es aber nicht) und linux-vdso. Letzterer ist ziemlich interessant, weil Sie nur eine Adresse nach dem bemerken werden =>. Das liegt daran, dass er tatsächlich Teil des Kernels ist.
Die C-Bibliothek ist meines Wissens nach dienurgemeinsam genutztes Objekt auf dem System, das nicht mit der C-Bibliothek verknüpft ist - es befindet sichdas Zentrumdes ganzen Durcheinanders. Sogar die Basisbibliothek anderer kompilierter Sprachen verwendet libc, z. B.:
> ldd libstdc++.so.6.0.17
linux-gate.so.1 => (0xf77b8000)
libm.so.6 => /lib/libm.so.6 (0xf7684000)
libc.so.6 => /lib/libc.so.6 (0xf74d2000)
/lib/ld-linux.so.2 (0xf77b9000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf74b5000)
Beachten Sie, dass Bibliotheken und der Linker verschiedene Pseudonyme haben, die mit symbolischen Links implementiert werden (z. B. ist /lib64/ld-linux-x86-64.so.2 tatsächlich /lib64/ld-2.15.so).
Beachten Sie auch, dass gccder „native“ Compiler (da er den Kernel und die C-Bibliothek kompiliert) nicht auf dem System vorhanden sein muss, libc und ld jedoch schon, da sonst nichts funktioniert.
Das ist nicht das Einzige, was GNU bietet. Sie sind auch für die bashShell und andere Kerntools und -programme verantwortlich, die das System *nix-ähnlich und (weitgehend) POSIX-kompatibel machen. Und GNOME, eine der ersten Linux-DEs und eine der am weitesten verbreiteten. Und das bereits erwähnte glib, das viele hochrangige Funktionen zur Unterstützung von Dingen wie GNOME und anderen DEs bietet. GNOME basiert auf GTK, das ursprünglich für GIMP entwickelt wurde. GTK ist auch grundlegend für verschiedene andere DEs; GTK und GIMP sind ebenfalls GNU-Produkte. Sie haben viel gemacht.
1 Es gibt so etwas wie eine Userland-Anwendung, die nicht mit einer Bibliothek verknüpft ist; diese heißenstatischausführbare Dateien und es bedeutet im Wesentlichen, dass Teile dieser Bibliothek in sie kompiliert wurden (genau wie beim Kernel).