Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
es ist ja echt schön, dass der Linus Linux gebaut hat. Aus Herzensblut, Enthusiasmus und weil er mit dem ursprünglichen UNIX nicht vollends zufrieden war. Oder welche Ursprungslegenden auch immer existieren.
Doch was oder wie wird Linux sein, wenn Linus mal "in' Sack haut"? Ob er nun aussteigt, oder einfach das Zeitliche segnet. Ich bin wirklich nicht bewandt in den Chef-Etagen von Linux und was da abgeht und wer da was zu sagen hat.
Wird sich drastisch und gravierend etwas ändern? Wird sich GAR NICHTS ändern? Verschwindet Linux komplett? Oder ist das mittlerweile ein solch gigantisches Geflecht mit so unfassbar vielen Trägern und Machern, dass das nichts mehr zur Debatte tun wird, ob der Urvater die Tastatur ins Korn wirft?
Der Name ist mir entfallen aber sämmtliche Kernel Versionen der letzten Jahre werden nicht von Linus signiert sondern von einem anderen Chefentwickler, inoffiziell gilt der als Nachfolger.
Linus hat sich dazu schon mal geäußert:
Es gibt ein paar Senior-Kernelentwickler (u.a. Greg Kroah-Hartman), die ihn auch schon mal vertreten haben, als er z.B. mal 1, 2 Monate Auszeit genommen hat.
Die könnten den Maintainer-Job direkt übernehmen. (GKH ist ja jetzt schon der Maintainer aller LTS-Releases)
/edit: Ob und wie ein Nachfolger den Job anders machen würde, steht natürlich in den Sternen. Es gibt bislang aber keine echten Anzeichen, dass Herr Torvalds den Job in näherer Zeit abgeben will/wird.
Es wird auch schon deswegen nicht verschwinden, weil es die Geschäftsgrundlage einiger Unternehmen ist. Firmen wie RedHat beschäftigen ja sogar Vollzeit-Entwickler für Beiträge zum Kernel und dem Linux-Ökosystem an sich. Und "das Linux" von Linus ist ja erstmal nur der Kernel und Linus selbst hat ja eher nur noch eine steuernde Funktion, indem er das letzte Wort hat, was in den Kernel kommt und was nicht - die tatsächlich Entwicklung wird schon lange mehrheitlich von freiwilligen oder auch bezahlten Entwicklern geleistet.
Fortatus schrieb:
Ob und wie ein Nachfolger den Job anders machen würde, steht natürlich in den Sternen
Ich denke mal, dass so jemand wie Greg Kroah-Hartman ziemlich gut mit Linus' Philosphie zur Pflege/Weitentwicklung des Kernels vertraut ist und die dann wohl auch ähnlich weiterführen wird - evlt. halt in einem anderen Ton bei Diskussionen.
Dass das Wort SUSE im Zusammenhang mit ihm fiel, gefällt mir irgendwie.
Jetzt mal ganz spekulativ. Sehen wir uns mal den Flickenteppich an, den die Distros jetzt darstellen. Der Kernel ist ja bei allen gleich, abgesehen vom Aktualitätsstand. Die Distros stellen ja nur die Pakete an Software und Design zusammen.
Angenommen Linux zerbricht irgendwann ebenfalls in diesen Flickenteppich. IST es denn dann möglich, dass die größten Größen sich wieder formieren und aus bloßen Distros tatsächlich vollständige OS werden (so wie die BSD Betriebssysteme).
Ich stelle mir das so vor, dass alle die Können und Ressourcen haben sich die aktuellen Fortschritte des Kernels zu Nutze machen und ihr eigenes Ding basteln? Dabei stelle ich mir als Big Player so Sachen wie Cannonical, SUSE, RedHat etc. vor. Die einen entwickeln ihren Kernel eher für Server und Business Machines, die anderen eher für den Desktop Endanwender, manche irgendwas dazwischen.
Die Nachfolge ist eigentlich kein Problem.
Das eigentliche Problem ist ARM, die Prozessor Architektur hat zwar offiziell Standards aber niemand hält sich daran. Deshalb braucht es für jedes ARM Device eigene Treiber und eigene Kernel Images.
Wer soll sich die Mühe machen für die alle eine Variante heraus zu bringen?
Noch dazu sind alle Android Treiber Proprietär. Es gibt so gut wie keine freien Treiber. Deshalb setzen Projekte wie Ubuntu Touch, KDE und Sailfish auf den Android Kernel auf alles andere ist fast nicht möglich. Es sei den man ist eine Profitable Firma die gleich die eigenen Geräte vermarktet.
Der klassische x86 PC wird von dem 0815 User der nur den Webbrowser und ein paar Apps nutzt immer weniger nachgefragt, ARM ist aber keine universal Kompatible Plattform. Wo mit einem Binary Intel und AMD läuft.
Die Apps in Android laufen deshalb in einer Speziellen VM in der die Hardware abstrahiert wird.
Das eigentliche Problem ist ARM, die Prozessor Architektur hat zwar offiziell Standards aber niemand hält sich daran. Deshalb braucht es für jedes ARM Device eigene Treiber und eigene Kernel Images.
Hmm, ich kompiliere meine ARM images mit CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm und bin fertig. Klar ich muss ein Device-Tree dazu packen, aber das ist quasi wie die ACPI-Table bei x86. Den Kernel kompiliere ich nur neu, wenn ich vergessen habe, einen Treiber einzukompilen, was in der Regel ein USB-Gerät oder ein Dateisystem ist. Aber das ist ja nicht das Problem von ARM, sondern mein Fehler.
@Topic: Wenn Linus geht, gibt es genügend Maintainer, die weitermachen. Ich seh da kein Problem. Meine Linux-commits hat Greg accepted und commited.
Eher aus Neugier und es war auch ursprünglich gar nicht seine Absicht ein Betriebssystem zu schreiben. Das hat sich so ergeben.
Es war auch kein UNIX mit welchem er dabei zu tun hatte, sondern Minix (was zwar durchaus Verwandtschaft mit UNIX aufweist aber eben auch neue Konzepte einführt und daher schlecht als "ursprüngliches UNIX" bezeichnet werden kann). Und das Problem mit Minix war auch weniger ein Technisches, als die Tatsache das es damals noch nicht frei verfügbar war.
McMoneysack91 schrieb:
Wird sich drastisch und gravierend etwas ändern? Wird sich GAR NICHTS ändern? Verschwindet Linux komplett?
Linux hat so eine große Bedeutung das selbst wenn Torvalds und die Kernelentwickler die sich um ihn scharen wegfallen würden, es weitergehen würde.
Aber auch jetzt ist es schon so, das Linus zwar an der Spitze steht aber ganz viel Arbeit schon vorher von anderen Leuten abgenommen wird. Seine Aufgabe besteht heute weniger im programmieren als eher in der Koordination.
Linuxfreakgraz schrieb:
Das eigentliche Problem ist ARM, die Prozessor Architektur hat zwar offiziell Standards aber niemand hält sich daran.
Das Problem an ARM ist weniger die Architektur. Die ist vorgegeben und da hält man sich dran. Das Problem ist eher das drum herum. Eine CPU-Architektur alleine macht ja noch keinen Computer.
McMoneysack91 schrieb:
Angenommen Linux zerbricht irgendwann ebenfalls in diesen Flickenteppich
Ist vorstellbar, aber trotzdem unwahrscheinlich. Ja die Distributionen sind unterschiedlich. Aber bei konkreten Projekten gibts diese Zersplitterung meist nicht (zumindest nicht in dem Ausmaß). Man denke da beispielsweise an OpenOffice.org, wo sich LibreOffice weggeforkt hat. Sah erst mal wie ein Split drauf, aber ziemlich schnell hat LibreOffice die Stellung von OpenOffice übernommen und OpenOffice selbst ist nur noch eine Randerscheinung.
Und das beobachtet man bei Forks ziemlich häufig. Das sie vorkommen und teilweise auch eine zeitlang nebeneinander existieren aber dann entweder wiedervereinigt werden oder jemand dann doch die dominante Rolle übernimmt.
In der Dezember Ausgabe diese Jahres hat Radio Tux das noch ausführlicher behandelt. Da gibt es zum Beispiel ein Problem mit Speicher Kontroller die bei fast jeden ARM Chip anders implementiert ist.
Bestreitet ja niemand, das es Probleme gibt und das die Probleme teilweise drastisch sind.
Nur hat das das was mit der CPU-Architektur im engeren Sinne zu tun hat (weshalb das auch RISC-V nicht lösen kann es sei denn, man einigt sich auf ein Standard für das drumherum; bis dahin hat RISC-V nur den Vorteil das Du für die Architektur als solches keine Lizenz erwerben musst).
Ein ARM Gerät weiss einfach nicht, welche Bauteile es besitzt, an welchen Anschlüssen sie sich befinden und wie sie angesprochen werden müssen. Beim normalen Computer weiss es das BIOS.
Und jetzt? Das BIOS ist wo abgespeichert? Auf dem MB in nem QSPI Flash mit ganzen 16 (32) MB. Sollen wir jetzt nem Pi für 5 € nen Flash draufknallen, der 1 € im Einkauf kostet? Dann flashen wir da das "BIOS" drauf und tun auf die SD-Karte nur noch das kernel.img, tadaaa, wir haben einen ARM-PC gebaut, aber leider 20 % teurer.
Und wie funktioniert das genau nochmal auf dem PC, startet da der Windows Kernel direkt nach dem Reset? Nein, es startet ein proprietären Blob, genannt BIOS.
Wenn jemand nen sauberes ARM System hat, dann lädt zuerst etwas wie u-boot und das lädt dann den Device-Tree, und ganz am Ende dann das uImage oder zImage und führt dann das aus, da hat man eine saubere Übergabe zwischen "BIOS" und Linux.
Hier ne kurze Übersicht, wie der Bootvorgang einer ARM-Platform aussieht
Eine Hardware die ich gut kenne: Nen Xilinx Zynq (FPGA + 2 ARM Cores), eigentlich ein Gerät aus der Hölle, da die Idee gerade ja ist, dass man die Devices im laufenden Betrieb tauschen kann und es voll Exoten-Devices ist (da "virtuell").
Der Bootvorgang sieht so aus:
0. Powerup, IC kommt aus dem Reset nachdem die Spannungen stabil sind.
1. ROM samplet die BOOTMODE-Pins (0-stage bootloader)
2. ROM entscheidet, was zu tun ist
a.) SD-Karten-Boot
b.) QSPI-Boot
c.) andere nicht relevante Boots
Wir nehmen mal QSPI-Boot
ROM lädt die ersten paar kB in den RAM und führt die aus
3. FSBL (First stage bootloader) wird ausgeführt (max. Größe 256 kB, da noch kein RAM initialisiert)
a.) RAM initialisieren (optional)
b.) Cache aktivieren (optional)
c.) FPGA Config laden (optional)
d.) Peripherie initialisieren (optional)
e.) Second stage loader laden
Wir nehmen mal an, das ist u-boot
4. u-boot läuft
waiting for key press 3..2..1..continuing
Hier wird es jetzt spannend: Wie lädt u-boot den Kernel? Da gibt es verschiedene Varianten, manche legen den Kernel an einer festen Adresse im QSPI ab, manche laden es als uImage von der ersten Partition der SD Karte. Aber alle Methoden haben eines gemeinsam, am Ende wird ein boot, bootm, oder bootz aufgerufen.
Die Gerätekonfiguration wird mit dem "dritten Parameter" übergeben als device-tree.
Wie konfiguriert man die Platform: Nun, man kann u-boot parametrisieren mit eigenen Skripten, das ist quasi wie im BIOS die Bootreihenfolge ändern. Dazu braucht man nur ein UART und etwas Können. Die Skripte werden dann in den Flash geschrieben, alternativ kann man paar Bit in einem Batterie-Speicher ablegen (Clear CMOS winkt hier mit dem Zaunpfahl), das muss dann das Skript aber auch laden und interpretieren.
Tricky bei der ganzen Geschichte ist, dass man gerne die FPGA-Config (mit mehreren Linux-"devices") dynamisch laden will, aber dafür gibt es Device-Tree-Overlays, mit denen man den generischen Tree patchen kann, bevor man alles an Linux übergibt. Wenn man das macht, dann tauchen (wie bei x86) magisch alle Geräte richtig auf.
Und wo muss ich nochmal Linux an die Platform anpassen? Antwort: Nirgends, so lange ich mindesten die Grund-Treiber einkompiliere, funktioniert es "out-of-the-box".
Was ARM eigentlich fehlt, ist eine klare Ansage, wie das Layout der Bootpartition zu sein hat. Aber dann stellt sich wieder die Frage, ob das überhaupt machbar und sinnvoll ist. Oftmals läuft das OS auch komplett aus dem Flash ohne ein echtes Dateisystem. Nicht jeder ARM ist ein M1, manche sind ein Pi, manche sind aber auch im USB-C PD Controller für das Ladegerät. Die sehen nie mehr als "ihre" 64 kB ROM und 128 kB RAM, oder noch weniger. Das ist ein Spagat, den so x86 nie gemacht hat (und machen kann?).
BTT: Linux geht ohne Thorvalds und Linux und ARM verstehen sich schon. Es ist halt nicht alles "PC-groß" und dadurch basteliger.
Linuxfreakgraz schrieb:
Versuche das mal bei einem Samsung Galaxy oder einem Tablet. Wo es nur Android Roms gibt.
Das gleiche mit meinem TV (Ok, ich hab Android TV, aber ich mein jetzt die "dummen" alten), da kann ich auch nur das vom Hersteller draufspielen, oder meine Waschmaschine, oder mein Monitor, Navi, ...
Das Problem ist, dass die Hersteller keinen Markt für mehr als "ihr" OS sehen. Ich mein ich hab nen Honor 8x rumliegen, da bringt mir ein GNU Linux ROM gar nix, weil ich kann das Handy ja nicht mal Unlocken.
Mglw. wäre da mal der Gesetzgeber gefragt... (right to repair --> right to (only) run my own code)