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

[SVΞN]

Redox OS ist ein freies, Unix-ähnliches Betriebssystem auf Basis der quelloffenen Systemprogrammiersprache Rust und setzt anders als Linux-Distributionen, die auf einem monolithischen Kernel aufbauen, auf einen Mikrokernel, bei dem sämtliche Treiber für mehr Stabilität und Sicherheit als normale Prozesse ausgeführt werden.

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

 

[Rockhound]

Gibt es denn Browser oder andere Software die darauf schon heute läuft?

 

[bodd]

Auf dem Screenshot sieht man schon das es einen "Browser" gibt. Werde das heute mal Testen :-)

 

[ReactivateMe347]

Ich verstehe nicht, wieso man nicht auf volle Linux-Kompatibilität geht. so müssen Hobby-gefrickelte Treiber verwendet werden, weil wohl kein großer Hardware-Hersteller diese unbedeutende Plattform unterstützen wird und man so wohl keine ordentlich Effizienz erreichen können wird.

Könnte man hingegen Linux-Treibercode als Module laden, so wäre das ein sehr vielversprechendes Projekt (Solange man nicht dogmatisch auf 100% Rust besteht und daher alles andere verweigert)

 

[Garmor]

Das Problem ist weniger der sehr rudimentäre Browser, sondern wahrscheinlich der fehlende Netzwerktreiber.

 

[LochinSocke]

Ich verstehe nicht, wieso man nicht auf volle Linux-Kompatibilität geht.

Also eine neue (die 65498716te) Linuxdisro from scratch?

 

[Creeping.Death]

Sehr interessantes Projekt, aber vermutlich ohne echte Zukunft. Nicht weil es schlecht wäre, sondern weil (wahrscheinlich) der Treibersupport nicht gegeben sein wird.

 

[Termy]

Ich bin auch sehr gespannt, was auf lange Sicht aus Redox wird. Die Ansätze sind sehr interessant, das bisherige Entwicklungstempo und die -ausdauer bewundernswert.
Ich würde es auf jeden Fall begrüßen, wenn daraus mal eine vollwertige Linux-Alternative/"Nachfolger" ohne die ganzen historischen Altlasten wird. Aber selbst wenn es dazu kommen sollte liegt das wohl noch mindestens ein paar Jahre in der Zukunft, selbst für ambitionierte Bastler (als Daily-Driver).

 

[Piktogramm]

Ich verstehe nicht, wieso man nicht auf volle Linux-Kompatibilität geht. so müssen Hobby-gefrickelte Treiber verwendet werden, weil wohl kein großer Hardware-Hersteller diese unbedeutende Plattform unterstützen wird und man so wohl keine ordentlich Effizienz erreichen können wird.

Redox nutzt die MIT Lizenz, sich da dann bei GPLv2 Linux Code zu bedienen sorgt unmittelbar für Probleme. Zudem ist Linux bzw. Linus zwar ultra konservativ was APIs für den Userspace angeht, essentielle Komponenten vom Kernel komplett zu überarbeiten ist jedoch im Rahmen des Möglichen. Wenn man also anfängt Komponenten von Linux zu nutzen, unterwirft man sich den dortigen Entwicklungen. Gerade bei kleineren Projekten hat man dann auch das Problem, dass man erstmal genug kompetente Entwickler·innen braucht, um mit dem Tempo von Linux mitzuhalten.

Was Treiber und Hobbygefrickel angeht. Gescheit aufgezogene Projekte haben oftmals eine deutlich höhere Codequalität als kommerzielle Entwickler. Beim Eintritt in die kommerzielle Welt hat es mir die Schuhe ausgezogen, was für wirklich reudiger Code bei sehr teuren Produkten im Produktiveinsatz ist. Also wirklich abartiger Müll, den wenn man ihn bei den meisten FOSS Projelten pushen würde, nur dazu führt, dass man da gebannt wird.

 

[iron-man]

Technisch sehr interessant. Aber:
Meiner Meinung nach liegt die Zukunft in der Nische ( wenn überhaupt ).
Zu mehr wird es auf Grund von fehlendem breit gefechertem Treibersupport und ebenso fehlenden Anwendungsprogrammen nicht reichen.
Und:
Wozu noch ein Community-getriebenes Betriebssystem ?
Oder baut man jetzt für jede neue Programmiersprache das dazugehörige Betriebssystem ?

 

[esb315]

Das Konzept ist nicht schlecht. Minix hab ich vor langer Zeit auch schon getestet. War wirklich nur rudimentär. Das hier werd ich mir auch mal anschauen.

 

[Beelzebot]

Der Mikrokernel ist der bessere Ansatz, aber solange man kein starkes Zugpferd als OS am Markt hat fristet sowas ein Schattendasein.
War es nicht aber so, dass in jeder Intel CPU seit Sandy Bridge ein abgeändertes Minix läuft?

Beim Eintritt in die kommerzielle Welt hat es mir die Schuhe ausgezogen, was für wirklich reudiger Code bei sehr teuren Produkten im Produktiveinsatz ist.

Das ist überall so, dass meiste Geld geht für Marke und Marketing drauf, nicht für das Produkt selbst. Die Qualität hinreichend zu bewerten können nämlich die wenigsten.
Nicht umsonst sagt ja selbst Microsoft, dass die OpenSource Lösungen mindestens gleichwertig zu ihren eigenen sind.

 

[Lora]

@SVΞN Du schreibst:

• Adressiert an Desktop, Workstation und Server

Da sollte Laptop an erster Stelle stehen, auf der Redox Seite steht:
Please consider contributing to our hardware compatibility list here

https://gitlab.redox-os.org/redox-os/redox/-/blob/master/HARDWARE.md

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

 

[Piktogramm]

Wozu noch ein Community-getriebenes Betriebssystem ?

1. Because they/we/I can!
...
2. Rust als relative neue Programmiersprache und recht viel "Buzz" dahinter weckt Interesse, und irgend ein "Bastelprojekt" zum Probieren zu haben ist nicht schlecht
3. Je stärker Rust genutzt wird, desto mehr hilft das der Weiterentwicklung der Sprache, Standardbibliothken und Compilern
4. Alte und neue Konzepte von Betriebssystemen testen, die "Learnings" helfen dann auch etablierten Projekten
5. Neue, kleine Projekte sind praktischer für Studenten (da wird zwar gern Linux genommen, das ist aber Imho schon lange zu monströs für einen schönen Einstieg)

Ergänzung (29. November 2022)

Nicht umsonst sagt ja selbst Microsoft, dass die OpenSource Lösungen mindestens gleichwertig zu ihren eigenen sind.

Bei dem, was man bei Ms einsehen kann und bei dem was man so sieht, wenn man die richtigen Werkzeuge drauf wirft, ist der Code bei Ms eine Wohltat. Ich habe da Albträume von ganz anderen Kalibern..

 

[Bigeagle]

Für mich als OS Laien wäre ja interessant ob die etwas anders machen beim Mikrokernelansatz. Soweit ich das im Kopf habe ist das Konzept schon früh interessant gewesen, aber schwieriger bei der Umsetzung und mit Nachteilen bei der Performance, je nachdem eher geringfügig bis 'will man nicht auf dem Server haben'.

Ist das jetzt 'Minix in Rust', oder gibts abseits der Programmiersprache eine Neuerung, oder interessante Abweichung?

 

[DevPandi]

Also wirklich abartiger Müll, den wenn man ihn bei den meisten FOSS Projelten pushen würde, nur dazu führt, dass man da gebannt wird.

Kenne ich, schlechter Code kommt halt dabei raus, wenn für die Produktivität die abgearbeiten Tasks am Tag der Indikator ist und nicht am Ende die Codequalität.

Einer der Gründe, warum ich raus bin aus der Entwicklung, weil man irgendwann einfach nur noch das "Prototypeing" in die Repositorien einspielt, damit der Task beendet ist, egal wie schlecht man den eigenen Prototyp findet und man auch weiß, dass man den überarbeiten muss.

Bei dem, was man bei Ms einsehen kann und bei dem was man so sieht, wenn man die richtigen Werkzeuge drauf wirft, ist der Code bei Ms eine Wohltat

Liegt wohl daran, dass Microsoft für die Produktivität - nicht wie andere Firmen - nie die Anzahl an Codezeilen oder Tasks heran gezogen hat für die Entwickler, sondern andere Faktoren und man daher bei MS durchaus dafür belohnt wird, dass man erst mal ein Prototypen einreicht, dann diesen verbessert und irgendwann ins fertige System einzieht.

MS ist, was Entwickler angeht, wirklich ein sehr angenehmer Laden.

Ich habe da Albträume von ganz anderen Kalibern.

Oh ja, gerade so manche unsere mittelständischen IT-Firmen sind da echt grausam. Hatte mal für ein paar der Namen auftragsarbeiten und es war erstaunlich, wie schnell die "schlechte" Prototypen abgesegnet hatten, obwohl ich die als erste groben Entwurf markiert hatte, damit man von da weiter arbeiten kann.

 

[IBISXI]

Die Technik ist interessant.

Aber was macht man mit so einem OS?

Fenster hin und herschieben?

 

[sedot]

Aber was macht man mit so einem OS?

Dem inneren Nerd freien Lauf lassen, fällt mir spontan ein. 🙂

Darüberhinaus landen auch von Redox sicher früher oder später Teile im großen Mix, von dem alle User auf die eine oder andere Art profitieren könn(t)en.
Es braucht (auch abseitigere) Experimente für Evolution.

 

[mae]

Ich verstehe nicht, wieso man nicht auf volle Linux-Kompatibilität geht. so müssen Hobby-gefrickelte Treiber verwendet werden, weil wohl kein großer Hardware-Hersteller diese unbedeutende Plattform unterstützen wird und man so wohl keine ordentlich Effizienz erreichen können wird.

Könnte man hingegen Linux-Treibercode als Module laden, so wäre das ein sehr vielversprechendes Projekt (Solange man nicht dogmatisch auf 100% Rust besteht und daher alles andere verweigert)

Andere schreiben, warum Linux-Treiber problematisch sind, wobei die Lizenzfrage m.E. kein Problem ist.

Aber es gibt auch grundsaetzlichere Gruende: die Idee von Redox ist ja, dass in Rust geschriebene Software sicherer ist. Da werden sie sich nicht irgendwelche in C getriebene Treiber von Linux holen, von denen Linus Torvalds selbst sagt, dass sie Mist sind. Ausserdem passt das nicht zum Konzept des Microkernels, der wohl u.a. deswegen gewaehlt wurde, um den Betriebssystemkern vom Treibercode zu isolieren.

 

[ReactivateMe347]

Aber es gibt auch grundsaetzlichere Gruende: die Idee von Redox ist ja, dass in Rust geschriebene Software sicherer ist.

Und das sicherste OS ist eins, was auf deiner Hardware gar nicht erst ausgeführt wird, weil es nicht performant ist, das stimmt natürlich. Natürlich müsste man dem Nutzer aktiv die Wahl lassen, welchen Weg er gehen möchte (Rust only oder Kompatibilität)

Ausserdem passt das nicht zum Konzept des Microkernels, der wohl u.a. deswegen gewaehlt wurde, um den Betriebssystemkern vom Treibercode zu isolieren.

Ja, man müsste die Treiber natürlich modularisieren. Das dürfte aber sehr viel einfacher sein, als sie komplett neu zu schreiben. Auch besteht beim Neuschreiben gerade als Hobby-Projekt die Gefahr, dass trotz Rust Angriffsflächen entstehen -- soweit ich weiß eliminiert Rust nicht alle Arten von Schwachstellen.

Ergänzung (29. November 2022)

Gerade bei kleineren Projekten hat man dann auch das Problem, dass man erstmal genug kompetente Entwickler·innen braucht, um mit dem Tempo von Linux mitzuhalten.

Immer noch besser, als wenn man vieles gar nicht zum laufen bekommt und das Projekt damit ein reines Spielzeug bleibt.

Was Treiber und Hobbygefrickel angeht. Gescheit aufgezogene Projekte haben oftmals eine deutlich höhere Codequalität als kommerzielle Entwickler. Beim Eintritt in die kommerzielle Welt hat es mir die Schuhe ausgezogen, was für wirklich reudiger Code bei sehr teuren Produkten im Produktiveinsatz ist. Also wirklich abartiger Müll, den wenn man ihn bei den meisten FOSS Projelten pushen würde, nur dazu führt, dass man da gebannt wird.

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. Immerhin wäre in meinem Beispiel ja der Vergleich Linux vs. Redox OS.

Ergänzung (29. November 2022)

Also eine neue (die 65498716te) Linuxdisro from scratch?

Nein. Mikrokernel und Rust-Basis beibehalten, aber (Kernel)module aus Linuxcode ermöglichen, damit das ganze voran kommt.