...schon alleine der Einfachheit wegen. Debian hätte genug Entwickler um beide init Systeme zu unterstützen, aber wozu wenn SysV init sowieso "sterben wird" für debian. Ich schaue mir das Theater mal gerne an, und es ist ein Theater und zwar nicht unter den Häuptlingen sondern eher unter den Indianern.
Über kurz oder lang sollte SystemD sich durchsetzten werden wohl Einige Entwickler gehen, was ich vollkommen verstehe. Und es werden andere Entwickler kommen.
Ich finde das gut, dass Sam Hartman jetzt eine GR einberuft. Strategisch sehr gut, Probleme sind dazu da um sie zu lösen. Technische Probleme lassen sich einfach lösen, schwieriger sind die zwischenmenschlichen Probleme wenn es um IT Themen geht.
Ich denke ebenfalls, dass es für das Debian-Projekt nur wenig Sinn ergibt, weiterhin SysV zu unterstützen, da einerseits bereits gute Alternativen existieren (Devuan etc.), und andererseits die Weiterpflege vermeidbare aber nicht vernachlässigbare Komplexität (technical debt) schafft und somit unnötig Ressourcen binden würde.
...] da einerseits bereits gute Alternativen existieren (Devuan etc.)
Mal gucken wie lange, wenn sämtliche Distributionsbestandteile, die mit Systemd/Init in Berührung kommen eigenständig (spätestens dann sicherlich immer öfter ohne jeglichen Upstream-Support), eigenständig gepflegt werden müssen. Systemd kann bestimmte Dinge sicherlich besser als die Init-Systeme hergebrachter Prägung; Aber eine der Stärken von Linux , die Granularität, ist mit Systemd so weit dahin, dass es bei Systemd-Distributionen theoretisch fast schon egal ist, ob sie mit einem Linux-Kernel oder mit etwas anderem betrieben werden.
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).
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.
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.
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).
> 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 [...
...schon alleine der Einfachheit wegen. Debian hätte genug Entwickler um beide init Systeme zu unterstützen, aber wozu wenn SysV init sowieso "sterben wird" für debian. Ich schaue mir das Theater mal gerne an, und es ist ein Theater und zwar nicht unter den Häuptlingen sondern eher unter den Indianern.
Über kurz oder lang sollte SystemD sich durchsetzten werden wohl Einige Entwickler gehen, was ich vollkommen verstehe. Und es werden andere Entwickler kommen.
Ich finde das gut, dass Sam Hartman jetzt eine GR einberuft. Strategisch sehr gut, Probleme sind dazu da um sie zu lösen. Technische Probleme lassen sich einfach lösen, schwieriger sind die zwischenmenschlichen Probleme wenn es um IT Themen geht.
Ich denke ebenfalls, dass es für das Debian-Projekt nur wenig Sinn ergibt, weiterhin SysV zu unterstützen, da einerseits bereits gute Alternativen existieren (Devuan etc.), und andererseits die Weiterpflege vermeidbare aber nicht vernachlässigbare Komplexität (technical debt) schafft und somit unnötig Ressourcen binden würde.
Hat aber _nichts_ mit Technical Debt zu tun, wenn man ein System komplexer macht/lässt, um flexibler zu bleiben.
...] da einerseits bereits gute Alternativen existieren (Devuan etc.)
Mal gucken wie lange, wenn sämtliche Distributionsbestandteile, die mit Systemd/Init in Berührung kommen eigenständig (spätestens dann sicherlich immer öfter ohne jeglichen Upstream-Support), eigenständig gepflegt werden müssen. Systemd kann bestimmte Dinge sicherlich besser als die Init-Systeme hergebrachter Prägung; Aber eine der Stärken von Linux , die Granularität, ist mit Systemd so weit dahin, dass es bei Systemd-Distributionen theoretisch fast schon egal ist, ob sie mit einem Linux-Kernel oder mit etwas anderem betrieben werden.
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).
Gäbe es denn überhaupt noch jemanden der einen neuen UNIX-Standard definieren könnte?
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?
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.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).
> 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.