23 Punkte von kuroneko 2023-08-31 | 10 Kommentare | Auf WhatsApp teilen
  • Ein Versuch, ein Non-Unix-OS mit Rust zu entwickeln.
  • Der aktuelle Stand unterstützt grafische Ausgabe, dynamische Speicherzuweisung, gleichzeitige Ausführung sowie Tastatur und Maus.
  • Eine Besonderheit ist, dass alle Apps so entworfen sind, dass sie als einzelne Funktion arbeiten können.
    • Apps werden ausgeführt, indem ihnen ein Context mit den OS-Funktionen übergeben wird, daher laufen alle Interaktionen über den Context.
    • Dadurch werden Sandboxing, Debugging usw. sehr einfach, und da auch der Erhalt des Speichers über den Context erfolgt, sind Neustarts und Energiesparmodus leicht umzusetzen.
  • Das App-Design ist noch nicht vollständig, daher gibt es weiterhin Probleme, etwa dass alle Apps den Speicher der anderen sehen können.
  • Persistenter Speicher, GPU- und Netzwerkunterstützung müssen noch implementiert werden.

10 Kommentare

 
honglu 2023-08-31

Das Konzept ist sexy. Die ganze Welt ist aus Rust ... hahaha

 
botplaysdice 2023-08-31

„Apps können den Speicher der jeweils anderen sehen“ ... :)

 
ahwjdekf 2023-08-31

Ja, das ist wirklich sehr lustig.

 
xguru 2023-08-31

VirGL - Virtuelle 3D-GPU, die in QEMU-VMs verwendet werden kann

Mit Unterstützung für VirGL kann es in QEMU installiert und getestet werden.

 
kuroneko 2023-08-31

Eine Zukunft, in der Rust-Programme auf einem Rust-OS laufen ...? Die ganze Welt ist voller Rust.

 
heycalmdown 2023-08-31

Wenn es im Kommentar einen HN-Thread gäbe, wäre es schön, wenn neo ihn automatisch zusammenfassen würde, haha. Ich kann ohne neo nicht leben.

 
kuroneko 2023-08-31

Ab jetzt werde ich auch KI-Zusammenfassungen mitbringen. Interessanterweise scheint sie nach den einzelnen Behauptungen einer Person zusammenzufassen?

  • danhau: Stellt infrage, ob kooperatives Scheduling wie von anderen behauptet tatsächlich zum Scheitern verurteilt ist, und äußert Bedenken darüber, dass Apps bereits jetzt kooperieren. Er befürchtet, dass Denial-of-Service-Angriffe ein solches System leicht lahmlegen könnten.
  • aseipp: Stimmt danhau zu und sagt, dass kooperatives Scheduling einfache Fehler für das System fatal machen könne, was bei der Ausführung beliebiger Programme problematisch sei.
  • gnulinux: Schlägt vor, dass es nicht alles oder nichts sein müsse, und meint, es könnte Wege geben, kooperative Apps zuzulassen und dennoch zu verhindern, dass das System durch Endlosschleifen stillsteht. Zum Beispiel durch Timeouts oder Schleifenerkennung.
  • DSMan195276: Behauptet, dass es in der Praxis eben doch ein Alles-oder-nichts-Thema sei, weil kooperative Programme davon ausgehen, nicht präemptiert zu werden. Selbst eine geringere Präemption würde seiner Meinung nach Änderungen an der Art erfordern, wie Programme geschrieben werden.
  • getpokedagain: Sagt, dass nicht jedes Betriebssystem unvorhersehbare Multiuser-Apps ausführen muss und dass das kooperative Modell auf eingeschränkten Systemen wie Embedded-Geräten oder Spielkonsolen funktionieren könne.
  • Symmetry: Sagt, dass moderne CPUs mehrere Threads haben, daher könne das Modell von Fomos funktionieren, ohne vollständig zum Stillstand zu kommen, wenn das OS zurückkehren kann, während es die übermäßige Nutzung einiger Threads überwacht.
  • cmrdporcupine: Erwähnt, dass spezielle Anwendungsfälle von einem Modell profitieren können, bei dem Arbeit direkt freien Kernen zugewiesen wird, dass die Komplexität der Nebenläufigkeitsbehandlung jedoch möglicherweise nicht wesentlich einfacher ist als die Implementierung von Time-Slicing.
  • JoeAltmaier: Sagt, dass eine while(true)-Schleife in einem Thread andere Threads vielleicht nicht beeinflusst, dass aber der Anstieg von Akkuverbrauch/Temperatur weiterhin ein Ressourcenproblem zeigt, das gemanagt werden muss.
  • keyle: Zeigt sich begeistert von diesem Projekt und dem minimalistischen Ansatz und freut sich auf weitere Entwicklungen, etwa ein Dateisystem, das die traditionellen Anforderungen zum Ausführen von DOOM erfüllt.
  • mepian: Stellt klar, dass Smalltalk-Methoden zwischen Objekten aufgerufen werden und keine unabhängigen Funktionen sind, und erklärt, dass einige frühe Lisp-OS schon vor Objektsystemen Funktionen verwendeten.
 
xguru 2023-08-31

Zum Glück? hat Neo denselben Beitrag schon bearbeitet haha

Fomos: Experimentelles Betriebssystem, das mit Rust entwickelt wurde

 
xguru 2023-08-31

Das Problem ist, dass ich beim Anschauen des Links selbst auch gerade mit am Zusammenfassen war schnief

Ihr könnt euch gleich drei verschiedene Zusammenfassungen ansehen und vergleichen haha

  • Ich wollte ein Non-Unix-OS bauen
  • Exo-Kernel ist interessant, aber meist eher Theorie, daher hilft das beim Verständnis dieses Musters
  • Funktionen
    • Grafikausgabe, dynamische Allokation, alle Apps laufen in einer asynchronen Schleife
    • Virtio-Maus/Tastatur (die Treiber sind ebenfalls asynchrone Tasks)
    • kooperatives Scheduling (Apps geben die Kontrolle möglichst oft ab)
    • nach dem Booten keine Kontextwechsel mehr
    • unterstützt Virgl™ fast
  • Besondere Punkte
    • die Signatur der App pub extern "C" fn _start(ctx: &mut Context) -> i32
    • Apps brauchen keine Standardbibliothek, und alle OS-Funktionen werden über Context an die App übergeben
    • In Fomos ist eine App einfach nur eine einzelne function. Das ist der wichtigste Punkt. Ausführbare Dateien in Unix-/Windows-OS sind im Vergleich zu einer Funktion sehr viel komplexer.
 
roxie 2023-09-04

Es gibt kein „thumbs down“, also wie ist Ihr Karma ins Minus gerutscht?