Von NaturalPrankster am Mo, 16. Dezember 2013 um 13:19 #
Es gibt auf den Installationsmedien eine Datei namens default.preseed. Dort ist am Ende die automatische Partitionierung angegeben. Einfach ändern oder löschen.
Oder den Installtionskernel ohne den Parameter preseed starten.
Kann ich meinen Sixaxis anschliessen und dieser wird erkannt? Auch ueber BT? Oder nur durch manuelles Frickeln? Leider habe ich kein anderes Eingabegeraet fuer meine Jump&Runs.
Von oldmcdonald am Mo, 16. Dezember 2013 um 13:54 #
Wow, Steam! Als ich gehört habe, dass SteamOS kommt, dachte ich: Basiert auf Ubuntu, der beliebten Insellösung, alle anderen Distros haben das nachsehen und Mir wird Standard. Jetzt ist der Unterbau Debian Stable! Alles wieder offen! Und Debian wird auch noch gepusht und von Valve unterstützt! Alle wünsche werden wahr!
Von Nicht naiv am Mo, 16. Dezember 2013 um 15:38 #
Hat Canonical am Anfang auch gemacht. Das hat nichts zu sagen, außer eben um in der Frühphase Linuxer zu ködern und dann, wenn der Marktanteil groß genug ist, die Linuxer sich beim Bewerben des Systems mißbrauchen liesen, dann wird mit einem eigenen Inselweg voll zugeschlagen, wenn warum sollte man sich auf Dauer Debian ans Bein binden?
Von oldmcdonald am Mo, 16. Dezember 2013 um 22:42 #
"Hat Canonical am Anfang auch gemacht."
Eben nicht. Ubuntu und Debian haben erst im Laufe der Zeit Zusammenarbeit gelernt. In den ersten Versionen von Ubuntu wurde einfach ein Sid-Snapshot geforkt und dann ein halbes Jahr gefixt, bis es lief - da kam überhaupt nichts mehr zurück. Erst später hat man Launchpad und den Bugtracker von Debian vernetzt, so dass Bugfixes auch wieder in Debian übernommen werden konnten. Das hat JAHRE gedauert.
Valve hingegen fixt upstream, sowohl im Kernel als auch in Debian als auch direkt in den einzelnen Software-Projekten (z.B. Pulseaudio). Ich glaube auch nicht, dass sie großes Interesse habe, eine eigene Bugfix-Infrastruktur zu etablieren - das ist viel zu aufwändig.
Von Nicht naiv am Mo, 16. Dezember 2013 um 15:37 #
Du redest vielleicht einen Käse.
Ubuntu basiert auf Debian und wenn du meinst, dass Ubuntu eine Insellösung geworden ist, dann ist das gleiche auch für Steam OS möglich, obwohl es wie Ubuntu, auch auf Debian basiert.
Debian wird hier lediglich mißbraucht, warte mal ein paar Versionen und Valve geht ihren eigenen Weg, so wie es Canonical zu einem großten Teil inzwischen mit Ubuntu macht.
Von oldmcdonald am Mo, 16. Dezember 2013 um 22:30 #
Abwarten…
Es macht für Valve keinen Sinn, das Rad neu zu erfinden. Sie benötigen lediglich einen leichtgewichtigen Unterbau, auf dem der Steam-Client stabil und schnell läuft. Den haben sie mit Debian und was stört, wird gefixt - nicht mehr, aber auch nicht weniger. Sie wollen ja keinen kompletten Desktop mit zigtausend Anwendungen, um Windows Konkurrenz zu machen, sondern Spiele verkaufen.
Von Nicht naiv am Di, 17. Dezember 2013 um 08:41 #
Sie benötigen lediglich einen leichtgewichtigen Unterbau,
Das ist ein weiteres Problem, denn es bedeutet, dass man alles von Debian, was man nicht benötigt, einfach wegrationalisieren kann.
Valve bräuchte z.B: keinen Window Manager, denn dieses Big Picture Mode Dingens könnte auch direkt auf dem X Server laufen, für neu gestartete Spiele kann man dann einen zweiten starten, das macht das System stabiler.
Das Terminal sowie viele Tools darunter usw. all das kann man ebenfalls wegrationalisieren, denn das Ding soll nur eine Konsole werden. sshd usw. braucht die Konsole auch nicht.
Von no Linux Standard Base am Mo, 16. Dezember 2013 um 15:34 #
Viele dürften bisher nur daran gedacht haben, das Valve ja nur ein OS für ihre Konsolen haben will.
Ich aber sage, es ist schlimmer. Bei Steam OS geht es hauptsächlich darum, den Spieleentwicklern eine festgeschriebene einheitliche Plattform zu bieten, für die sie dann zuverlässig entwickeln können, ohne Angst zu haben, dass es zu Inkompatibilitäten kommt.
Auf andere Linux Distributionen wird hierbei natürlich keine Rücksicht genommen, auch nicht auf die LSB, welche ja genau für so einen Zweck eingeführt wurde, damit alle Linux Anwendungen auch auf allen Linux Distributionen laufen. Steam OS ist also der Versuch einen quasi Standard durchzudrücken und alle anderen Linux Distributionen die dann nicht zu Steam OS kompatibel sind, die haben das Nachsehen.
Wer für Steam OS und die Steam Konole Linux Spiele entwickeln will, muss also nur zusehen, dass sie unter Steam OS laufen. Ubuntu, Debian, Fedora, SUSE usw. sind hierbei egal. Das gleiche gilt leider auch für proprietäre Treiber.
Von no Motzerei am Mo, 16. Dezember 2013 um 17:56 #
Wirf doch einfach mal einen Blick in die FAQ:
Q: Didn't you tell me to develop for Ubuntu? Do I need to install Debian to build for SteamOS? All Steam applications execute using the Steam Runtime which is a fixed binary-compatibility layer for Linux applications. This enables any application to run on any Linux distribution that supports the Steam Runtime without recompiling. As long as your development environment targets Ubuntu 12.04 LTS with the Steam Runtime, it will run without change on SteamOS. If you are a Steam partner, see the Linux development page for more details on creating Steam applications for Linux and SteamOS.
Nach dem Motto: Entwickelt ihr die Spiele und wir kümmern uns darum, dass die Schnittstellen für euch stabil und zuverlässig bleiben, (fast) egal auf welcher Distribution das Spiel ausgeführt wird.
Von no Linux Standard Base am Mo, 16. Dezember 2013 um 21:25 #
Hier sollte man übrigens nicht vergessen, dass es nichtmal überall Linux Distributionen gibt, die die LSB unterstützen.
Wer also glaubt, dass das mit der Steam Plattform noch besser wird, der ist sehr naiv. Es ist und bleibt ein Steam Allaingang und die Definition einer Steam eigenen Plattform und alle anderen müssen nachrücken, wenn sie Steam kompatibel sein wollen. Demokratie, Mitbestimmung usw. ist da nirgends vorhanden.
Die LSB ist doch schon seit Ewigkeiten kaputt. Es ist wirklich keine Kunst Programme zu schreiben, die den Konformitätstest bestehen und trotzdem nicht Cross-Distro sind. Die Testsuiten sind fehlerhaft und unvollständig. Noch dazu ist die LSB ständig veraltet und die angebotenen APIs aus Sicht eines kommerziellen Spieleanbieters eher ein schlechter Scherz. Sorry, die LSB konnte bis heute nicht wirklich halten was sie verspricht. Man sieht es schon daran, dass kaum Drittsoftware sie verwendet hat. Es wundert mich deshalb auch überhaupt nicht, dass Valve seine eigene Distributionsabstraktion (hier speziell für Spiele) entwickelt. Valve macht nur die Hausaufgaben, die die Linuxer seit zig Jahren verpennt haben: ABI/API Kompatibilität für Anwendungssoftware jenseits der Repository-Ghettos. Das ist übrigens auch einer der Hauptgründe warum sich Linux bis zum heutigen Tage kaum auf dem Desktop etablieren konnte: Es gibt faktisch keinen wirklich ernst zunehmenden Drittsoftware-Markt, weil sich kaum ein Entwickler auf das total fragmentierte und halbkompatible Distributions-Potporre einlassen will. Ein vitales Desktop-Ökosystem besteht eben nicht nur daraus welches tolle Desktop-Environment, Terminal-Emulator oder Dock ich installieren kann, sondern von einem vielfältigem Software-Markt, der nun mal größtenteils von Dritten unabhängig vom Betriebssystem distribuiert wird. Für einen Linuxer besteht ja die eigene Softwarewelt nur aus dem, was sein Distributor ihm gnädigerweise zur Verfügung stellt. Also nicht aufregen wenn Valve etwas entwickelt was schlicht notwendig ist. Die Linuxer hätten hier schon längst selbst vernünftige Standards setzen können, haben sie aber nicht.
Von Problematisch am Di, 17. Dezember 2013 um 08:48 #
Es wird natürlich SteamOS wie bei Windows mit der Zeit aufblähen, weil man dann alte Bibliotheken mitschleppen muss, um die ABI/API Kompatibilität aufrecht zu erhalten.
Windows besteht nicht umsonst aus 19 GB nur alter Libs, mitgeschleppt seit Windows NT 3.0 und mit jeder Windows Version werden neue DLLs zu den alten hinzugefügt.
Ich bezweifle, dass Windows aus 19 GB alten Libs besteht, abgesehen davon würde das bei heutigen Festplattenkapazitäten niemanden wirklich interessieren. Eine Softwareauswahl jenseits irgendwelcher Distributionseigenbrödlereien wäre eh viel wertvoller als ein paar GB mehr Festplattenverbrauch.
Von tomkater68 am Di, 17. Dezember 2013 um 11:29 #
Valve macht nur die Hausaufgaben, die die Linuxer seit zig Jahren verpennt haben: ABI/API Kompatibilität für Anwendungssoftware jenseits der Repository-Ghettos.
Damit wir jahrzehntelang alte Libs rumschleppen, weil die Anwendungsentwickler keinen Bock haben, auf aktuelle Frameworks zu portieren?
Für einen Linuxer besteht ja die eigene Softwarewelt nur aus dem, was sein Distributor ihm gnädigerweise zur Verfügung stellt
Die Distributionen liefern "gnädigerweise" soviel Software, dass ich keinen Bedarf für Drittanbieter und schon gar nicht für kommerzielle Anbieter sehe.
Die Linuxer hätten hier schon längst selbst vernünftige Standards setzen können, haben sie aber nicht.
Linux ist vor allem Freiheit und die ist nun mal nicht kompatibel mit dem kommerziellen Einheitsbrei. Wenn ich den wollte, würde ich Windows benutzen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Dez 2013 um 11:34.
> Die Distributionen liefern "gnädigerweise" soviel Software, dass ich keinen Bedarf für Drittanbieter und schon gar nicht für kommerzielle Anbieter sehe. Linux ist vor allem Freiheit ...
Na wenn das deine Definition von Freiheit ist, vom Distributor bevormundet zu werden. Da sind deine Ansprüche aber extrem gering. Also mach mal nen Reality-Check: Die Welt besteht nicht nur aus Puritanern, Rohköstlern und "Mir reicht ein Terminal"-Admins. Das Software-Distributionskonzept von Linux kann jenseits deiner puritanischen Ansprüche leider nicht wirklich skalieren.
> ... und die ist nun mal nicht kompatibel mit dem kommerziellen Einheitsbrei. Wenn ich den wollte, würde ich Windows benutzen.
Von welchem Einheitsbrei redest du? Die Software-Welt ist jenseits von Desktop-Linux in quantitativer als auch qualitativer Hinsicht deutlich umfangreicher als das was man in jedem Distributionsrepsitory findet.
> Wenn ich den wollte, würde ich Windows benutzen.
Das machen die meisten ja eh schon. Niemand will sich unnötig einschränken.
auch nicht auf die LSB, welche ja genau für so einen Zweck eingeführt wurde, damit alle Linux Anwendungen auch auf allen Linux Distributionen laufen.
Das ist so nicht ganz korrekt.
Das Ziel der LSB ist es, alles Linux Server Anwendungen auf allen Linux Server Distributionen laufen lassen zu können. Die Linux Foundation hat sich explizit dagegen entschieden, die LSB zu einer Basis für Desktop- bzw Privatbenutzeranwendungen zu machen.
Bei Projekten der Linux Foundation muss man sich stehts vor Augen führen, dass dort der Begriff "End User" nicht die Leute am Arbeitsplatz-PC meint, sondern die Administratoren.
Nichtsdestotrotz könnten die für die LSB entwickelten Werkzeuge (ABI Checker usw.) auch zum Testen einer Desktop- bzw. Anwenderentwicklungssicht benutzt werden. Eventuell benutzt Valve die sogar
Meines Wissens nach wollte und konnte man sich damals nur noch nicht auf die Toolkits festlegen, weil die selbst alle noch ziemlich in Bewegung waren.
Die LSB enthält sowohl GTK+ als auch Qt.
Die von mir angesprochene Festlegung auf Serveranwendungen kommt durch die Wahl der Bibiotheksversionen für neue Versionen der LSB.
Wenn eine neue Version der LSB geplant wird, ein Schritt der die Aktualisierung von enthaltenen Bibliotheken erlaubt, wird als Basis das zu diesem Zeitpunkt bereits veröffentlichte RHEL benutzt.
D.h. das Ziel ist, dass mit der zukünftigen LSB Version entwickelte Programme automatisch auf zur Zeit benutzten Serversystemen läuft.
Das ist für Desktop- bzw. Endanwendersoftware ja nach Alter von RHEL zu diesem Zeitpunkt irgendwo zwischen relativ unbrauchbar und obsolet.
Eine absolut unnötige Einschränkung weil für RHEL (und SLES) ohnehin speziell paketiert und zertifiziert wird.
Mein letztes LSB Meeting ist schon ein paar Jahre her, aber es würde mich stark wundern, wenn sich da etwas geändert hätte. Damals haben sich die anwesenden Desktop- und Toolkitentwickler, inklusiver großer ISVs (u.a. Adobe), an der ungeschriebenen RHEL Regel die Zähne ausgebissen.
Als Beispiel: die aktuelle LSB (Version 4.x) spezifiziert u.a. GTK+ 2.8 und Qt 4.2. Selbst Debian Stable (Lenny), nicht gerade berühmt für super aktuelle Versionen, hatte da schon GTK+ 2.12.12
Wie relevant diese Versionen aktuell sind kann man sich denken.
Es gibt auf den Installationsmedien eine Datei namens default.preseed. Dort ist am Ende die automatische Partitionierung angegeben.
Einfach ändern oder löschen.
Oder den Installtionskernel ohne den Parameter preseed starten.
Kann ich meinen Sixaxis anschliessen und dieser wird erkannt? Auch ueber BT? Oder nur durch manuelles Frickeln?
Leider habe ich kein anderes Eingabegeraet fuer meine Jump&Runs.
Wow, Steam!
Als ich gehört habe, dass SteamOS kommt, dachte ich: Basiert auf Ubuntu, der beliebten Insellösung, alle anderen Distros haben das nachsehen und Mir wird Standard.
Jetzt ist der Unterbau Debian Stable! Alles wieder offen! Und Debian wird auch noch gepusht und von Valve unterstützt! Alle wünsche werden wahr!
Schöne Grüße und weiter so!
Welchen Vorteil hat Debian konkret von SteamOS? Gibt Valve irgend etwas an Debian zurück?
Artikel lesen und verstehen.
Hat Canonical am Anfang auch gemacht.
Das hat nichts zu sagen, außer eben um in der Frühphase Linuxer zu ködern und dann, wenn der Marktanteil groß genug ist, die Linuxer sich beim Bewerben des Systems mißbrauchen liesen, dann wird mit einem eigenen Inselweg voll zugeschlagen, wenn warum sollte man sich auf Dauer Debian ans Bein binden?
"Hat Canonical am Anfang auch gemacht."
Eben nicht. Ubuntu und Debian haben erst im Laufe der Zeit Zusammenarbeit gelernt. In den ersten Versionen von Ubuntu wurde einfach ein Sid-Snapshot geforkt und dann ein halbes Jahr gefixt, bis es lief - da kam überhaupt nichts mehr zurück. Erst später hat man Launchpad und den Bugtracker von Debian vernetzt, so dass Bugfixes auch wieder in Debian übernommen werden konnten. Das hat JAHRE gedauert.
Valve hingegen fixt upstream, sowohl im Kernel als auch in Debian als auch direkt in den einzelnen Software-Projekten (z.B. Pulseaudio). Ich glaube auch nicht, dass sie großes Interesse habe, eine eigene Bugfix-Infrastruktur zu etablieren - das ist viel zu aufwändig.
Grüße!
Du redest vielleicht einen Käse.
Ubuntu basiert auf Debian und wenn du meinst, dass Ubuntu eine Insellösung geworden ist, dann ist das gleiche auch für Steam OS möglich, obwohl es wie Ubuntu, auch auf Debian basiert.
Debian wird hier lediglich mißbraucht, warte mal ein paar Versionen und Valve geht ihren eigenen Weg, so wie es Canonical zu einem großten Teil inzwischen mit Ubuntu macht.
Nicht immer so naiv sein.
Abwarten…
Es macht für Valve keinen Sinn, das Rad neu zu erfinden. Sie benötigen lediglich einen leichtgewichtigen Unterbau, auf dem der Steam-Client stabil und schnell läuft. Den haben sie mit Debian und was stört, wird gefixt - nicht mehr, aber auch nicht weniger. Sie wollen ja keinen kompletten Desktop mit zigtausend Anwendungen, um Windows Konkurrenz zu machen, sondern Spiele verkaufen.
Grüße!
Das ist ein weiteres Problem, denn es bedeutet, dass man alles von Debian, was man nicht benötigt, einfach wegrationalisieren kann.
Valve bräuchte z.B: keinen Window Manager, denn dieses Big Picture Mode Dingens könnte auch direkt auf dem X Server laufen, für neu gestartete Spiele kann man dann einen zweiten starten, das macht das System stabiler.
Das Terminal sowie viele Tools darunter usw. all das kann man ebenfalls wegrationalisieren, denn das Ding soll nur eine Konsole werden.
sshd usw. braucht die Konsole auch nicht.
Ist der client jetzt endlich 64 Bittig ?
Nein, ist er noch nicht. Multiarch kommt zum Zug.
Viele dürften bisher nur daran gedacht haben, das Valve ja nur ein OS für ihre Konsolen haben will.
Ich aber sage, es ist schlimmer.
Bei Steam OS geht es hauptsächlich darum, den Spieleentwicklern eine festgeschriebene einheitliche Plattform zu bieten, für die sie dann zuverlässig entwickeln können, ohne Angst zu haben, dass es zu Inkompatibilitäten kommt.
Auf andere Linux Distributionen wird hierbei natürlich keine Rücksicht genommen, auch nicht auf die LSB, welche ja genau für so einen Zweck eingeführt wurde, damit alle Linux Anwendungen auch auf allen Linux Distributionen laufen.
Steam OS ist also der Versuch einen quasi Standard durchzudrücken und alle anderen Linux Distributionen die dann nicht zu Steam OS kompatibel sind, die haben das Nachsehen.
Wer für Steam OS und die Steam Konole Linux Spiele entwickeln will, muss also nur zusehen, dass sie unter Steam OS laufen.
Ubuntu, Debian, Fedora, SUSE usw. sind hierbei egal.
Das gleiche gilt leider auch für proprietäre Treiber.
https://github.com/ValveSoftware/steam-runtime
Fazit:
Ich habe recht, nur hast du den zitierten Satz gar nicht verstanden.
Wirf doch einfach mal einen Blick in die FAQ:
Q: Didn't you tell me to develop for Ubuntu? Do I need to install Debian to build for SteamOS?
All Steam applications execute using the Steam Runtime which is a fixed binary-compatibility layer for Linux applications. This enables any application to run on any Linux distribution that supports the Steam Runtime without recompiling. As long as your development environment targets Ubuntu 12.04 LTS with the Steam Runtime, it will run without change on SteamOS. If you are a Steam partner, see the Linux development page for more details on creating Steam applications for Linux and SteamOS.
Nach dem Motto: Entwickelt ihr die Spiele und wir kümmern uns darum, dass die Schnittstellen für euch stabil und zuverlässig bleiben, (fast) egal auf welcher Distribution das Spiel ausgeführt wird.
Das Motto heißt aber auch:
Ihr müßt euch darum kümmern, dass auf eurer Distribution unsere Steam Plattform läuft.
Steht ganz fett hier:
Wer hat also recht?
Ich natürlich.
Würde man so die LSB durchdrücken, dann wäre sie unbeliebt, aber erfolgreich.
Hier sollte man übrigens nicht vergessen, dass es nichtmal überall Linux Distributionen gibt, die die LSB unterstützen.
Wer also glaubt, dass das mit der Steam Plattform noch besser wird, der ist sehr naiv.
Es ist und bleibt ein Steam Allaingang und die Definition einer Steam eigenen Plattform und alle anderen müssen nachrücken, wenn sie Steam kompatibel sein wollen.
Demokratie, Mitbestimmung usw. ist da nirgends vorhanden.
Die LSB ist doch schon seit Ewigkeiten kaputt. Es ist wirklich keine Kunst Programme zu schreiben, die den Konformitätstest bestehen und trotzdem nicht Cross-Distro sind. Die Testsuiten sind fehlerhaft und unvollständig. Noch dazu ist die LSB ständig veraltet und die angebotenen APIs aus Sicht eines kommerziellen Spieleanbieters eher ein schlechter Scherz. Sorry, die LSB konnte bis heute nicht wirklich halten was sie verspricht. Man sieht es schon daran, dass kaum Drittsoftware sie verwendet hat. Es wundert mich deshalb auch überhaupt nicht, dass Valve seine eigene Distributionsabstraktion (hier speziell für Spiele) entwickelt. Valve macht nur die Hausaufgaben, die die Linuxer seit zig Jahren verpennt haben: ABI/API Kompatibilität für Anwendungssoftware jenseits der Repository-Ghettos.
Das ist übrigens auch einer der Hauptgründe warum sich Linux bis zum heutigen Tage kaum auf dem Desktop etablieren konnte: Es gibt faktisch keinen wirklich ernst zunehmenden Drittsoftware-Markt, weil sich kaum ein Entwickler auf das total fragmentierte und halbkompatible Distributions-Potporre einlassen will. Ein vitales Desktop-Ökosystem besteht eben nicht nur daraus welches tolle Desktop-Environment, Terminal-Emulator oder Dock ich installieren kann, sondern von einem vielfältigem Software-Markt, der nun mal größtenteils von Dritten unabhängig vom Betriebssystem distribuiert wird. Für einen Linuxer besteht ja die eigene Softwarewelt nur aus dem, was sein Distributor ihm gnädigerweise zur Verfügung stellt.
Also nicht aufregen wenn Valve etwas entwickelt was schlicht notwendig ist. Die Linuxer hätten hier schon längst selbst vernünftige Standards setzen können, haben sie aber nicht.
Es wird natürlich SteamOS wie bei Windows mit der Zeit aufblähen, weil man dann alte Bibliotheken mitschleppen muss, um die ABI/API Kompatibilität aufrecht zu erhalten.
Windows besteht nicht umsonst aus 19 GB nur alter Libs, mitgeschleppt seit Windows NT 3.0 und mit jeder Windows Version werden neue DLLs zu den alten hinzugefügt.
Steam OS wird das gleiche Schicksal haben.
Ich bezweifle, dass Windows aus 19 GB alten Libs besteht, abgesehen davon würde das bei heutigen Festplattenkapazitäten niemanden wirklich interessieren. Eine Softwareauswahl jenseits irgendwelcher Distributionseigenbrödlereien wäre eh viel wertvoller als ein paar GB mehr Festplattenverbrauch.
Damit wir jahrzehntelang alte Libs rumschleppen, weil die Anwendungsentwickler keinen Bock haben, auf aktuelle Frameworks zu portieren?
Die Distributionen liefern "gnädigerweise" soviel Software, dass ich keinen Bedarf für Drittanbieter und schon gar nicht für kommerzielle Anbieter sehe.
Linux ist vor allem Freiheit und die ist nun mal nicht kompatibel mit dem kommerziellen Einheitsbrei. Wenn ich den wollte, würde ich Windows benutzen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Dez 2013 um 11:34.> Die Distributionen liefern "gnädigerweise" soviel Software, dass ich keinen Bedarf für Drittanbieter und schon gar nicht für kommerzielle Anbieter sehe. Linux ist vor allem Freiheit ...
Na wenn das deine Definition von Freiheit ist, vom Distributor bevormundet zu werden. Da sind deine Ansprüche aber extrem gering. Also mach mal nen Reality-Check: Die Welt besteht nicht nur aus Puritanern, Rohköstlern und "Mir reicht ein Terminal"-Admins. Das Software-Distributionskonzept von Linux kann jenseits deiner puritanischen Ansprüche leider nicht wirklich skalieren.
> ... und die ist nun mal nicht kompatibel mit dem kommerziellen Einheitsbrei. Wenn ich den wollte, würde ich Windows benutzen.
Von welchem Einheitsbrei redest du? Die Software-Welt ist jenseits von Desktop-Linux in quantitativer als auch qualitativer Hinsicht deutlich umfangreicher als das was man in jedem Distributionsrepsitory findet.
> Wenn ich den wollte, würde ich Windows benutzen.
Das machen die meisten ja eh schon. Niemand will sich unnötig einschränken.
Das ist so nicht ganz korrekt.
Das Ziel der LSB ist es, alles Linux Server Anwendungen auf allen Linux Server Distributionen laufen lassen zu können. Die Linux Foundation hat sich explizit dagegen entschieden, die LSB zu einer Basis für Desktop- bzw Privatbenutzeranwendungen zu machen.
Bei Projekten der Linux Foundation muss man sich stehts vor Augen führen, dass dort der Begriff "End User" nicht die Leute am Arbeitsplatz-PC meint, sondern die Administratoren.
Nichtsdestotrotz könnten die für die LSB entwickelten Werkzeuge (ABI Checker usw.) auch zum Testen einer Desktop- bzw. Anwenderentwicklungssicht benutzt werden. Eventuell benutzt Valve die sogar
Dazu hätte ich jetzt gerne eine Quelle.
Meines Wissens nach wollte und konnte man sich damals nur noch nicht auf die Toolkits festlegen, weil die selbst alle noch ziemlich in Bewegung waren.
Die LSB enthält sowohl GTK+ als auch Qt.
Die von mir angesprochene Festlegung auf Serveranwendungen kommt durch die Wahl der Bibiotheksversionen für neue Versionen der LSB.
Wenn eine neue Version der LSB geplant wird, ein Schritt der die Aktualisierung von enthaltenen Bibliotheken erlaubt, wird als Basis das zu diesem Zeitpunkt bereits veröffentlichte RHEL benutzt.
D.h. das Ziel ist, dass mit der zukünftigen LSB Version entwickelte Programme automatisch auf zur Zeit benutzten Serversystemen läuft.
Das ist für Desktop- bzw. Endanwendersoftware ja nach Alter von RHEL zu diesem Zeitpunkt irgendwo zwischen relativ unbrauchbar und obsolet.
Eine absolut unnötige Einschränkung weil für RHEL (und SLES) ohnehin speziell paketiert und zertifiziert wird.
Mein letztes LSB Meeting ist schon ein paar Jahre her, aber es würde mich stark wundern, wenn sich da etwas geändert hätte.
Damals haben sich die anwesenden Desktop- und Toolkitentwickler, inklusiver großer ISVs (u.a. Adobe), an der ungeschriebenen RHEL Regel die Zähne ausgebissen.
Als Beispiel: die aktuelle LSB (Version 4.x) spezifiziert u.a. GTK+ 2.8 und Qt 4.2.
Selbst Debian Stable (Lenny), nicht gerade berühmt für super aktuelle Versionen, hatte da schon GTK+ 2.12.12
Wie relevant diese Versionen aktuell sind kann man sich denken.