Linux ohne Linus: Ein Blick in die Zukunft?

[ModellbahnerTT]

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?

Wenn das dazu führt das es für alle SBC auf Basis von ARM nur ein Image braucht wie bei x86 dann ja bitte. Ein BIOS oder UEFI braucht es aber nicht zu sein ein Coreboot und andere freiere Alternativen sind ebenfalls gerne gesehen.

 

[Hancock]

Wenn das dazu führt das es für alle SBC auf Basis von ARM nur ein Image braucht wie bei x86 dann ja bitte.

Was ist ein SBC? Ein Pi Pico? Oder erst ab dem Zero oder erst ab Pi 1B oder erst ab Pi 4B (ab dem man ihn wirklich als (low-end) Desktop-Replacement verwenden kann, laut einigen Leuten)?

Soll deine RGB-Lampe auch ein Flash haben, und dein Ladegerät? Bist du bereit, für dein Ladegerät 20 % mehr zu bezahlen? Geschweige denn von dem Overhead und Elektromüll, der durch so etwas entsteht.

Hättest du gerne auch die Nachteile eines "BIOS"? Wie zum Beispiel nicht-detektierbare Rootkits? https://blog.fefe.de/?ts=9f30b7a9

Für große Kisten ist u-boot eine nette Sache, für kleine Dinger aber oft "cost prohibitive". So lange da MS, Google und Apple kein Standard vorgeben (alle 3 zusammen) wird es aber niemals einen geben.

 

[RalphS]

Offtopic? 🤔
Jedenfalls, bitte nicht den Fehler begehen und CPU-Architektur mit Rechnerarchitektur verwechseln. X64 gibt, oder von mir aus auch gab, es bspw als "PC" und als "Macintosh". Mit unterschiedlicher Firmware-Architektur.

Klar hat ARM seine Macken, allen voran der Umstand, daß ARM keine "CPU" ist, sondern einfach ein Modell, aus dem auch nach Herzenslaune entfernt werden kann; entsprechend gibt es Hunderte ARM-CPUs inzwischen, die alle nicht notwendigerweise miteinander kompatibel sind oder notwendigerweise per demselben Input dasselbe tun, auch wenn hoffentlich derselbe Output herauskommt.

Aber von den erwähnten Kostengründen ist es völlig egal, was da für ein Firmware-Modell danebensteht. ARM funktioniert auch mit ACPI, PnP, EFI 1.x oder 2.x, und was weiß ich nicht noch; man muß es halt nur implementieren.

Mein Core-i hat auch keine Ahnung davon, wo die Festplatte hängt. Wozu auch?

 

[aki]

Bitte zurück zur Ausgangsfrage.

Bei dem riesigen Geflecht an Maintainern geht auch heute schon die meiste Arbeit an Linus vorbei. Viel basiert auf Vertrauen, weil er natürlich nicht von allen Teilgebieten des Kernels Ahnung haben kann. Dazu ist der Code viel zu groß geworden.
Wahrscheinlich ist die Nachfolge auch im engsten Kreise bereits geregelt, falls es zu einem Unfall oder sonstigem kommen sollte.

Angenommen Linux zerbricht irgendwann ebenfalls in diesen Flickenteppich.

Dafür sind zu viele große Firmen involviert. Außerdem könnten alle sinnvollen Entwicklungen des anderen Kernels dank Open Source einfach wieder übernommen werden.

 

[McMoneysack91]

Na das meine ich ja, trotz des hypothetischen Zerfalls in Flickenteppiche würde ja alles anch wie vor 100% open source bleiben. Ich wollte keinesfalls damit suggerieren dass jeder sein eigenes closed source Süppchen daraus machen würde.

Nur würden sich vielleicht diverse Gruppierungen nur diverser Bereiche des Kernels bedienen. X86 und dem Linux-Kernel wird ja vorgeworfen gigantisch bloated und voller Altlasten zu sein. Vielleicht würden ja einige zukunftsorientierte Distros einen modernen, leichten Kernel mit nur wenige Jahre zurückreichender Rückwärtskompatibilität etc basteln. Usw usf.

 

[Linuxfreakgraz]

Das hat man glücklicherweise immer zu verhindern gewußt, ein Mainline Kernel für alle. Wie es sonst aussieht, sieht man bei BSDs jeder backt seinen eigenen Kernel was bedeutet das jede Hardwareunterstützung aufwendig portiert werden muss. Weil man den Code notfalls an den eigenen speziellen Code anpassen muss. Die eine Hardware die bei einem BSD funktioniert, funktioniert nicht immer beim anderen. Das ist ein nicht zu vernachlässigender Mehraufwand.

 

[andy_m4]

X86 und dem Linux-Kernel wird ja vorgeworfen gigantisch bloated und voller Altlasten zu sein.

Da ist auch was dran. Wobei der viel Code auf Hardwaretreiber zurückzuführen ist.
Aber auch abseits davon hast Du Einiges. Man denke nur an die ganzen verschiedenen Sicherheitsframeworks (SELinux, AppArmor, Seccomp usw.).

Vielleicht würden ja einige zukunftsorientierte Distros einen modernen, leichten Kernel mit nur wenige Jahre zurückreichender Rückwärtskompatibilität etc basteln. Usw usf.

Dafür muss es aber keine Forks geben die ja dann auch das Problem der Inkompatibilitäten mitsich bringen. Und angepasste Kernel kannst Du auch schon jetzt haben bzw. gibt es die ja auch schon.

Wie es sonst aussieht, sieht man bei BSDs jeder backt seinen eigenen Kernel was bedeutet das jede Hardwareunterstützung aufwendig portiert werden muss.

Dieser Vergleich ist ... schwierig. :-)
Die BSDs haben sich auch relativ stark in unterschiedliche Richtungen entwickelt und verfolgen teilweise auch ziemlich unterschiedliche Ziele die auch zum Teil unvereinbar miteinander sind. Es wäre schwierig geworden alles unter einen Hut zu kriegen und damit sozusagen in einem System zu vereinen, wo man dann halt nur paar Compilerflags setzt um daraus das gewünschte BSD zu erhalten. Das praktisch zu handlen wäre darauf hinausgelaufen, das man hätte Kompromisse eingehen müssen die aber für jedes Ziel ein suboptimales Ergebnis gewesen wären. Ob das besser wäre ist fraglich.