News Redox OS 0.8.0: Rust-Betriebssystem für x86 und Arm64 mit Mikrokernel

[blackiwid]

Hmm ich wunder mich grad ob die leute von GNU/Hurd nicht den Kernel klauen oder mit den Kooperieren, "Hurd" steht ja eh nicht fuer einen spezifischen Kernel der wurde schon mehrfach ausgewechselt, das Ziel ist ja Freiheit und Microkernel und BSD -> GPL umlizensieren bei der eigenen Kopie ist ja erlaubt. Naja es gab wohl verschiedene Implementationen von Mach... aber was Mach ist scheint so ne Art Standard zu sein.

Das einzige Problem wäre wenn man laengerfristig source kompatibel bleibt mit dem Kernel oder er der mehr populäre Kernel wäre, dann haette man wieder die gleiche Problematik mit Linux-libre das die Leute den in der Regel fuer nen normalen ersetzen wenn die Distros nicht eh mit dem normalen default kommen.

Ausserdem denk ich das die beste free Software / Hacker Sprache lisp ist, daher sollte das das endziel sein bei Gnu/Guix hat man schon das meiste mit lisp implementiert, aka bootloader und co, nur der Kernel fehlt noch aber emacs zählt ja auch als Betriebssystem

 

[Tanzmusikus]

Ich sehe da eigentlich nur Laptops, oder täusche ich mich?

Mach einfach Desktop-Laptops daraus - und schon passt es.

 

[Lora]

Lol, ja so kann man es auch machen

Trotzdem wäre diese Distribution nichts für mich.
Da muss man schon sehr viel Zeit und Nerven mitbringen, ist vielleicht was für die ganz üblen Nerds.

 

[Piranha771]

Es ist keine Linux-Distribution.

 

[Lora]

Stimmt, Sorry

 

[Caramon2]

Klingt interessant.

Dabei musste ich allerdings an ReactOS denken:

Im aktuellen Zustand ist Redox OS allerdings noch nicht für den täglichen Gebrauch vorgesehen, sondern noch als experimentell eingestuft. Ein modernes „Unix“ soll irgendwann dabei herauskommen, hier sprechen wir aber von Jahren.

 

[Piktogramm]

Immer noch besser, als wenn man vieles gar nicht zum laufen bekommt und das Projekt damit ein reines Spielzeug bleibt.[...]
Das stimmt wohl, so allgemein kann man das nicht sagen. Wenn aber zig und hunderte Entwickler von Linux gegen eine Hand voll Hobbyentwickler stehen dürfte ersteres doch besser sein

Das Problem sind die hunderte (eher tausende) Entwickler, die gleichzeitig an allen Komponenten von Linux, all dessen Standardbibliotheken, Compilern etc. schrauben. Wenn man dieser enormen Entwicklungsgeschwindigkeit folgen will, sind alle Entwickler des Projektes nur damit ausgelastet. Die Entwicklung des eigentlichen Betriebssystems kann so nicht mehr stattfinden. Da ist es echt schlauer rudimentäre Treiberunterstützung einfach selbst zu schreiben und (vorerst) damit zu leben, dass einige Sachen nicht vollständig funktionieren.

Das ist der gleiche Trick wieso Großkonzerne dazu gezwungen sind GPL lizenziertes Linux zu unterstützen anstatt irgendwelche "out of tree" Forks zu pflegen. Man kommt der Entwicklung nicht hinterher, selbst wenn man Google, Facebook, Amazon, Microsoft oder sonstwer ist. Selbst Nvidia scheint ja eingeknickt zu sein und das Leiden bei Qualcomm, Mediathek SoC mit out of tree Forks kennen wir ja alle

 

[ReactivateMe347]

Wenn man dieser enormen Entwicklungsgeschwindigkeit folgen will, sind alle Entwickler des Projektes nur damit ausgelastet.

Das sollte man natürlich automatisieren - aber selbst wenn man nur den jetzigen IST-Stand übernimmt, wäre das noch immer sehr viel besser im Ergebnis als Eigenbau-Treiber.

dass einige Sachen nicht vollständig funktionieren.

Klar, wenn man 2.000€ Hardware nur für Minesweeper und Solitär benutzen will, dann kann man da so machen. Dann bleibt das aber eben auch ein Hobby/Forschungs-Projekt. Ich als Entwickler würde dann eher daran arbeiten wollen, ab Linux 6.1 sicherheitskritische Teile in Rust neu aufzusetzen (Dann soll ja Rust Teil des Kernels werden, soweit ich weiß).

 

[Piktogramm]

Das sollte man natürlich automatisieren

Du hast selbst noch nicht viel Code geschrieben, geschweige denn, fremde APIs genutzt oder?
Wenn der Spaß irgendwie realistisch automatisieren lassen würde, gäbe es das ganze HickHack rund um die Treiberentwicklung für alle OS überhaupt nicht.

- aber selbst wenn man nur den jetzigen IST-Stand übernimmt, wäre das noch immer sehr viel besser im Ergebnis als Eigenbau-Treiber.

Das ist einfach falsch. Das Übernehmen klappt aufgrund des anderen Konzepts, anderer Designentscheidungen ja nicht. Das muss portiert werden. Wenn man da aktuell ein Minimum an Komponenten des Linuxkernels nimmt um x86_64 und aarch64 zu unterstützen ist das extrem viel Arbeit. Bevor man damit fertig ist, schreiben wir das Jahr 2050 und hätte nichts erreicht, außer den technischen Stand von 2022 zu erreichen. Das ist lächerlich!
Wie gesagt, du unterschätzt den Aufwand..

Klar, wenn man 2.000€ Hardware nur für Minesweeper und Solitär benutzen will, dann kann man da so machen. Dann bleibt das aber eben auch ein Hobby/Forschungs-Projekt.

Dieses Forschungsprojekt (neben anderen) hat das Ökosystem um Rust überhaupt erst soweit gebracht, dass Rust ernsthaft in den Linuxkernel einziehen kann. Selbst wenn Redox nie wirklich produktiv wird, ist der Beitrag immens.

Ich als Entwickler würde dann eher daran arbeiten wollen, ab Linux 6.1 sicherheitskritische Teile in Rust neu aufzusetzen (Dann soll ja Rust Teil des Kernels werden, soweit ich weiß).

Es gibt nicht so viele Bereiche im Kernel, die keine mittelbare Relevanz für die Sicherheit haben. Ich glaube ich habe es schonmal erwähnt, aber der Linuxkernel ist ein MASSIVES Biest, bei dem es unrealistisch ist kurzfristig große Teile auf eine andere Programmiersprache zu portieren.

 

[ReactivateMe347]

Du hast selbst noch nicht viel Code geschrieben, geschweige denn, fremde APIs genutzt oder?
Wenn der Spaß irgendwie realistisch automatisieren lassen würde, gäbe es das ganze HickHack rund um die Treiberentwicklung für alle OS überhaupt nicht.

Wenn du bestehenden Code modularisierst geht das mit ordentlichem IDE ziemlich leicht, nennt man Refactoring. Ja, man muss sich einmal überlegen, wie man das Mapping hinbekommt, spätere Anpassungen am Treiber sollten Änderungen am Interface Mikrokernel<-> Treiber-Kernelmodul in der Regel nicht erforderlich machen.

Das ist einfach falsch. Das Übernehmen klappt aufgrund des anderen Konzepts, anderer Designentscheidungen ja nicht.

Genau das ist das Problem, weil man "POSIX-ähnlich" ist und das nicht von vorn herein bedacht/ so konzipiert hat.

Das muss portiert werden. Wenn man da aktuell ein Minimum an Komponenten des Linuxkernels nimmt um x86_64 und aarch64 zu unterstützen ist das extrem viel Arbeit. Bevor man damit fertig ist, schreiben wir das Jahr 2050 und hätte nichts erreicht, außer den technischen Stand von 2022 zu erreichen. Das ist lächerlich!
Wie gesagt, du unterschätzt den Aufwand..

Wenn das 2 Hobbyprogrammierer machen, dann kann das schon so sein. Aber wie lange würden die 2 Hobbyprogrammierer brauchen, um auch nur die Grafikkarten eines Herstellers ordentlich zu unterstützen? Bis 2100? (Man betrachte ReactOS ...)

Dieses Forschungsprojekt (neben anderen) hat das Ökosystem um Rust überhaupt erst soweit gebracht, dass Rust ernsthaft in den Linuxkernel einziehen kann. Selbst wenn Redox nie wirklich produktiv wird, ist der Beitrag immens.

Was hat Redox OS mit der Integration von Rust in Linux zu tun? Mir erschließt sich da kein Zusammenhang.

Es gibt nicht so viele Bereiche im Kernel, die keine mittelbare Relevanz für die Sicherheit haben. Ich glaube ich habe es schonmal erwähnt, aber der Linuxkernel ist ein MASSIVES Biest, bei dem es unrealistisch ist kurzfristig große Teile auf eine andere Programmiersprache zu portieren.

Soweit ich weiß wird Rust gleichsam zu Binaries compiliert wie C. Wenn ich da so drüber nachdenke, dann müsste es doch sogar egal sein, ob im Kernelcode nun statisch gelinkt ein C-Binary oder ein Rust-Binary verwendet wird, oder? Will meinen: Hat die Implementierung von Rust in Linux 6.1 überhaupt was mit Kernelkomponenten zu tun, oder geht es nur darum, nativ Rust-Anwendungsprogramme nutzen zu können?!