Login
Newsletter
Werbung

Thema: Debian entscheidet über alternative Init-Systeme

6 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von klopskind am Do, 31. Oktober 2019 um 11:20 #

Es geht im Kollaboration. Entweder ist man Teil des Ökosystems und greift auf bestehende Lösungen und Features der Plattform zurück, oder man muss sich eben anderweitig umschauen oder eigene Wege gehen.

Das Grundinteresse der einflussreichsten Distributoren, die Fragmentierung des Ökosystems einzudämmen, bestand schon seit deren Existenz. So gesehen ist das nichts Neues.
Allerdings decken diese auch nicht den gesamten Markt ab, beherrschen also nicht ganz Gallien. Android oder die (restliche) embedded-Industrie, z.B. in Form von Projekten der Linux-Foundation wie Yocto (OpenEmbedded), nutzen oftmals kein systemd, und das aus gutem Grund, selbst wenn Linux zum Einsatz kommt.

Entweder bietet eine Distribution besagte Plattformschnittstellen, per systemd oder Reimplementierung/Hack, oder eben nicht. Dann darf man sich hinterher aber auch nicht beschweren, dass es nicht läuft, außer es handelt sich um von oben herab geplantem politischem Vorsatz mit verwerflichen Absichten à la EEE. Aber direkte, stichhaltige Beweise für Letzeres liegen mir in Fall systemd bisher nicht vor.

Zudem haben die BSDs schon seit Jahren Probleme, Software, die nur mit Linux im Hinterkopf entwickelt worden ist, zum Laufen zu kriegen. Neben proprietärer Software wie Adobe Reader, Adobe Flash, MATLAB, etc. gilt das auch für OSS wie Firefox (häufige Crashes und Aussetzer, Deaktivierung von Sicherheitsfunktionen wie der seccomp-Sandbox etc.) aber auch viele Dinge von X.org, FreeDesktop.org, GNOME, KDE und Wayland. Unter BSD sind oftmals nicht die selben oder vergleichbare Schnittstellen vorhanden. POSIX genügt schon seit Jahren nicht mehr, um die Entwickler- & Nutzeranforderungen zu befriedigen. Das liegt auch in der Natur der Sache: Ein Standard eines Konsortiums ist quasi schon per Definition nicht zeitgemäß für diejenigen, die die Grenzen des Möglichen stets ausreizen (wollen).

  • 0
    Von schmidicom am Do, 31. Oktober 2019 um 11:57 #

    Gäbe es denn überhaupt noch jemanden der einen neuen UNIX-Standard definieren könnte?

    • 1
      Von klopskind am Do, 31. Oktober 2019 um 12:51 #

      Da weiß ich zu wenig, um eine aufschlussreiche und belastbare Antwort geben zu können. Wie stellen Sie sich "einen neuen UNIX-Standard" vor?

      Ich denke, dass das auf absehbare Zeit die Entstehung eines "neuen UNIX-Standard" unwahrscheinlich bleibt. Die SUS wird gemächlich erweitert. Es ist quasi der kleinste gemeinsame Nenner. Die Konkurrenten des Marktes können sich nicht auf diesem Minimum ausruhen. Aber die derzeitige Fragmentierung scheint noch keine branchenschädliches Maß erreicht zu haben. Erst dann würden sich die Hersteller zusammenraufen.

      In gewisser Weise hat ja Linux den klassischen Unix-Markt konsolidiert und umgekrempelt, und damit auch einen neuen de-facto-Standard etabliert.
      Heutzutage werden die allermeisten Systeme und Schnittstellen via Virtualisierung, Docker etc. "standardisiert"definiert. Eine weitere Vereinheitlichung/Standardisierung in diesem Umfeld halte ich derzeit für geschäftsschädigend.

      Was denken Sie?

      • 1
        Von schmidicom am Do, 31. Oktober 2019 um 13:28 #

        Der Link zum SUS-Artikel auf Wikipedia beantwortet die Frage eigentlich schon ziemlich gut, Danke.

        Ich finde es halt einfach verdammt schade das immer wieder Developer, bezüglich fehlender Portabilität, kritisiert werden nur weil sie interessante Kernel-Features benutzen welche es aktuell halt leider nur unter Linux gibt. Ein aktualisiertes SUS könnte die BSD-Derivate vielleicht endlich mal dazu bringen sowas wie zum Beispiel die "cgroups" zu implementieren.

        Lennart hat mal in einem Interview klar zu verstehen gegeben das es nie das Ziel war systemd so zu entwerfen das es nur unter Linux läuft, aber weder er noch seine Kollegen haben vor sinnvoll nutzbare Kernel-Features zu ignorieren nur weil ein anderes Betriebssystem diese eventuell nicht haben könnte. Das Linux-only war und ist keine Absicht, es hat sich einfach so ergeben.

        Dieser Beitrag wurde 1 mal editiert. Zuletzt am 31. Okt 2019 um 13:29.
        • 1
          Von klopskind am Do, 31. Oktober 2019 um 15:42 #

          Größtenteils Zustimmung, aber zwei Einwände habe ich dann doch:

          zu Absatz 2:
          Ich weiß nicht, ob das wirklich hilft, denn würden die Systeme alle einen neueren, breiteren SUS-Standard umsetzen, würden sie sich so sehr angleichen, dass sie sich wegen andere Eigenschaften (z.B. Treiberunterstützung) marginalisieren würden. Nur der Aufwand wäre mehrfach vorhanden, aber quasi unnütz. Das wäre nicht ökonomisch.
          Demnach wäre dieser Weg also nicht für jedes Betriebssystem sinnvoll, und ich vermute, dass das auch der Grund ist, weswegen, der Standard nur gemächlich weiterentwickelt wird. Letztlich sind es ja genau diese Interesseenparteien, die sich in den SUS-Standardisierungsprozess involvieren.

          Es bleibt quasi ein ökonomisches Dilemma oder eine Gratwanderung. Ich kann nicht erkennen, dass sich diese Situation mittel- oder langfristig signifikant ändert.

          Man sollte auch nicht vergessen, dass das eine gegenseitige Beziehung ist. Klar liegt das Momentum seit Jahren auf der Seite von Linux. Aber es hat schon mehrere Fälle gegeben, wo es umgekehrt war oder sein hätte können (manche würden auch sagen müssen), so z.B. strl*, getentropy/getrandom, kqueue vs epoll (kqueue existierte bereits früher und hat eine sauberere API mit weniger Nebeneffekten; die BSD-Community und insbesondere Bryan Cantrill können davon ein Lied singen), bei OSS vs ALSA war/sind mir die genauen Hintergründe bis heute unklar (OSS war angeblich proprietär? Aber inzwischen nicht mehr. Warum sind wir dann nicht wieder bei OSS?).

          zu Absatz 3 (v.A. letzter Satz):
          Jein, man sollte nicht vergessen, dass es von Anfang an eine bewusste Entscheidung gewesen ist. In diesem Sinne würde ich "das Linux-only" schon als Absicht der Entwickler auslegen. Sie hatten einfach andere Prioritäten und im Sinne der minderpriorisierten Portabilität gab es einfach keine gescheiten Alternativen/Ressourcen (bzw. siehe Aufwand zu Nutzen).

    1
    Von ac am Do, 31. Oktober 2019 um 22:00 #

    > Es geht im Kollaboration. Entweder ist man Teil des Ökosystems und greift auf bestehende Lösungen und Features der Plattform zurück, oder man muss sich eben anderweitig umschauen oder eigene Wege gehen.

    Die Frage ist doch, wer da kollaboriert. Das Linux-Ökosystem ist so durchkommerzialisiert, dass die Big Player (wenn man sich ehrlich macht: IBM/Red Hat) ihre Vorstellungen über ihre Marktmacht technisch durchdrücken können; Friss oder stirb.

    Zudem haben die BSDs schon seit Jahren Probleme [...

    In der Tat.

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung