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).
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).