Login
Newsletter
Werbung

Thema: Redox OS 0.5 erschienen

12 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von ehWurst am Mo, 25. März 2019 um 23:13 #

Sieht ja wirklich schön aus, aber kann mir wer sagen, wer es benützt und wo wird es gebraucht, wenn schon soviel Arbeit hineingesteckt wird?

[
| Versenden | Drucken ]
  • 0
    Von theuserbl am Di, 26. März 2019 um 00:56 #

    Redox ist halt anders, weil es in Rust geschrieben wurde und somit einige Sicherheitslöcher von der Programmiersprache her ausgeschlossen werden.
    Die Entwickler sind halt der Meinung, daß alleine dieser Umstand ausreicht, um dieses Betriebssystem zu entwickeln.

    Guck Dir allene mal diese Liste an Betreibssysteme an, die der Entwickler des ToaruOS Betriebssystems erstellt hat:
    https://github.com/klange/hobby-os-landscape

    KolibriOS hat z.B. auch keine große Verbreitung oder so. Aber der Vorteil gegenüber anderen Systemen ist, daß das gesamte Betriebssystem extrem klein und schnell ist, weil es komplett in Assembler geschrieben wurde.

    Oder HelenOS, ToarusOS und Sortix. Da weiß ich noch nicht mal was der Unterschied zu anderen Betriebsystemen sein soll, außer daß Personen ihre eigenen Betriebssysteme entwickelt haben.

    Und die Liste ist ja noch nicht mal vollstädig. Es sind lediglich die Systeme die derzeit noch weiterentwickelt werden.
    TempleOS (wo der Entwickler gestorben ist), AtheOS/Syllable, MonaOS (wo die Entwickler aufgehört haben), etc werden noch nicht einmal erwähnt. Aber AROS ist ja auch nicht in der Liste drin, obwohl es stetig weiterentwickelt wird.

    [
    | Versenden | Drucken ]
    • 0
      Von Ghul am Di, 26. März 2019 um 05:58 #

      KolibriOS hat z.B. auch keine große Verbreitung oder so. Aber der Vorteil gegenüber anderen Systemen ist, daß das gesamte Betriebssystem extrem klein und schnell ist, weil es komplett in Assembler geschrieben wurde.

      Was sind denn die Mindestsystemvorraussetzungen von Kolibri OS?
      Reicht ein 486er mit 8 MB RAM?

      Ich habe leider keine Angaben auf der Webseite gefunden, welche Befehlssatzerweiterungen mindestens notwendig sind.
      Alles was ich bis jetzt weiß ist, dass es ein 32 Bit OS ist, welches mindestens 8 MB RAM benötigt.
      Diese Anforderungen würde schon ein 386er erfüllen.
      Sollten aber noch MMX oder SSE2 Befehle benötigt werden, dann sieht es natürlich ganz anders aus.

      Das ist leider der Nachteil von so einem OS in Assembler. Man kann nicht einfach mal schnell ein Binary erstellen, dass mit weniger Befehlen auskommt oder neue Befehlssatzerweiterungen unterstützt.

      Ebenso würde mich noch interessieren, ob es Mehrbenutzertauglich ist und über ein Rechtemanagement verfügt.

      Und die Liste ist ja noch nicht mal vollstädig. Es sind lediglich die Systeme die derzeit noch weiterentwickelt werden.
      GNU Hurd fehlt in der Liste oder es ist kein "Hobby OS", so wie die Liste die Betriebssysteme nennt, die da aufgelistet sind.

      [
      | Versenden | Drucken ]
      • 0
        Von theuserbl am Di, 26. März 2019 um 08:56 #

        Welchen Befehlssatz KolibriOS nutzt, weiß ich selber nicht.

        Aber zum Thema GNU Hurd. Wenn man den in die Liste mit aufnimmt, dann kann man auch L4/Plan9, RiscOS (seit einiger Zeit OpenSource), Minix3, Davros , Fuchsia, FreeDOS, Sculpt OS, MikeOS (noch immer aktiv), Illumos, FreeRTOS, JNode, VisOpSys und viele andere mit in die Liste aufnehmen.

        Und VisOpSys und MikeOS sind wirklich Hobby-Betriebssysteme.

        [
        | Versenden | Drucken ]
      0
      Von Atalanttore am Di, 26. März 2019 um 20:52 #

      TempleOS (wo der Entwickler gestorben ist)

      Der Entwickler wurde nicht von Gott für ein himmlisches IT-Projekt angeworben!? Da habe ich mich wohl verlesen.

      [
      | Versenden | Drucken ]
      0
      Von Anon am Mi, 27. März 2019 um 08:46 #

      > Redox ist halt anders, weil es in Rust geschrieben wurde und somit einige Sicherheitslöcher von der Programmiersprache her ausgeschlossen werden.

      Das ist in C++ seit der Einführung von Smartpointern um die Jahrtausendwende herum auch ausgeschlossen. Hier wird ein Problem erschaffen, dass es nicht gibt.

      In C wird absichtlich auf den Destruktor verzichtet um das letzte Stück Performance (~5%) gegenüber C++ herauszuholen. Es ist also eher eine Designentscheidung, da man annimmt, dass diese Sicherheitslöcher im Kernel im Verhältnis zur Quellcodemenge selten sind.

      [
      | Versenden | Drucken ]
    0
    Von msi am Di, 26. März 2019 um 18:28 #

    https://doc.redox-os.org/book/introduction/why_redox.html

    Zudem hat das Projekt offensichtlich das Ziel, zu beweisen, dass Rust tatsächlich dazu taugt, ein komplettes Betriebssystem zu schreiben, und zwar in diverser Hinsicht besser als C. (Da ich C kaum und Rust (bis auf den Namen) überhaupt nicht kenne, kann ich das leider nicht weiter beurteilen.)

    [
    | Versenden | Drucken ]
0
Von kraileth am Di, 26. März 2019 um 08:33 #

Viele Leute stehen solchen Neuentwicklungen skeptisch oder gleich ablehnend gegenüber. Da werden Argumente ins Feld geführt von „Zeitverschwendung“ bis „braucht doch eh keiner“. Kann man vertreten. Hintergrund ist hier aber eine ziemlich enge Sichtweise darauf, was sinnvoll ist und was nicht. Tatsache ist, daß wir heute in der IT mit Systemen umgehen, die so komplex geworden sind, daß der Aufwand, um mit einer Neuentwicklung auch nur in die Nähe dessen zu kommen, derart gigantisch ausfiele, daß eine solche Sichtweise dies komplett ausschließt.

Eine andere Betrachtungsweise wäre die, daß wir feststellen: Wir arbeiten heute mit Systemen, die ihre theoretischen Grundlagen weit im letzten Jahrtausend haben. Natürlich haben wir dabei alles, was uns in die Finger kam, massiv aufgebohrt und auch mal mehr, mal weniger zaghaft größere Änderungen vorgenommen. Trotzdem hängt uns vielfach das Erbe von Jahrzehnten wie ein Klotz am Bein: Wer sich jetzt fragt, was ich meine, der schaut z.B. einfach mal nach /dev/tty* auf seiner Arbeitsstation und denkt eine Sekunde darüber nach, was ein Teletypewriter war und was der mit einem modernen Desktop zu tun hat (und bevor die Fensterfreunde jetzt spotten: Wer das auch nicht ganz taufrische Konzept von Laufwerksbuchstaben verwendet, der darf schön ruhig sein).

Linux hatte in den frühen 90ern gegenüber *BSD den Nachteil, daß es erst noch den Windeln entwachsen mußte, während letzteres bereits für reife Systeme stand. Es hatte aber den unschätzbaren Vorteil, in vielen Dingen neubeginnen zu können, ohne bremsende Altlasten. Daß dabei nicht alles glücklich gelaufen ist und einige Chancen verpaßt wurden, ist leider so. Ein Beispiel wäre, daß ironischerweise Linux noch heute block devices nutzt, während FreeBSD diese vor langer Zeit abgeschafft hat, da technisch inzwischen widersinnig. Allerdings braucht es schon einen echten Fundamentalisten, um zu behaupten, es sei keine gute Idee gewesen, Linux zu beginnen.

Ob RedoxOS zu einem Betriebssystem für den täglichen Gebrauch heranreifen wird, weiß ich natürlich nicht. Vielleicht wird mit Version 0.6 die Portierung auf RISC-V verkündet und in fünf Jahren gibt es eine beschauliche Anzahl von Recken, die damit arbeiten. Vielleicht schläft die Entwicklung auch einfach irgendwann ein. Unabhängig davon behaupte ich, daß es eigentlich eine ziemlich gute Idee ist, wenn etwa jedes Jahrzehnt eine Gruppe von Technikbegeisterten „einfach mal neuanfängt“ - vor allem dann, wenn sie es systematisch tut und bewußt auf dem aktuellen Stand und mit Verständnis der Irrtümer der Vergangenheit tut. Insofern fand ich RedoxOS von Anfang an absolut super.

Selbst wenn es nie zum Produktiveinsatz kommen würde (die Hürden dafür sind einfach verdammt hoch), fallen ohne Frage interessante Einzelteile davon ab (z.B. RelibC, die man aus meiner Sicht gar nicht stark genug hervorheben kann!) oder neue Ideen sind zumindest mal ausprobiert worden. Daher: Wer mit solchen Projekten nichts anfangen kann, bitte einfach in eine andere Richtung schauen und nicht den Sauertopf spielen, der experimentierfreudigeren Leuten unnötig die Laune verdirbt. :)

[
| Versenden | Drucken ]
  • 0
    Von Anonymous am Di, 26. März 2019 um 09:25 #

    Sehe ich auch so.

    C ist älter als die meisten Leute, die es benutzen, war damals ein dirty hack und ist in fast 50 Jahren nicht besser geworden.

    An Sicherheit, Internet oder "always connected" hat damals noch niemend gedacht, und trotzdem wird mit dem Mist unverdrossen weitergemacht.

    Das Problem ist halt, dass in 50 Jahren ein Riesen-Misthaufen aufgetürmt wurde, den man praktisch nicht mehr ersetzen kann. Es sei denn, in der IT würde endlich mal die Produkthaftung eingeführt, dann müsste sich was ändern.

    Aber wahrscheinlich würde das ganze Kartenhaus in sich zusammenfallen und die kommerziellen Anbieter reihenweise pleite gehen.

    Also machen alle weiter wie bisher.

    [
    | Versenden | Drucken ]
    • 0
      Von theuserbl am Di, 26. März 2019 um 09:43 #

      C hat aber weiterhin seine Daseinsberechtigung.
      Klar, für Desktoprechner ist es sicher besser, wenn ein modernes Betriebssystem in Rust geschrieben wird.
      Einige Kernel sind aber auch in C++ statt C geschrieben.

      Jedoch ist C gerade für Microcontroller und so gut geeignet.
      Viele sehen es daher als das "bessere" und "platformunabhängige" Assembler an.
      Es gibt auch einige Personen die Assembler durch Makros dermaßen erweitert haben, daß daraus ein Assembler mit C Erweiterungen wird.

      Ein Arduino wird man wohl nie in Rust oder so programmieren können. Genau für soetwas ist C noch immer gut.

      [
      | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung