OpenSuSe ist für mich die Distribution, bei der immer unnötig an allen möglichen Quellen herumgepatcht wird, die auch mal irgendwelche Zwitterlösungen wie KDE 3.5+4.0 ausliefert, wirr am Paketmanagement rumbaut (yum/zypper/sonstwas, unterschiedliche Arten für Paketquellen), bei der man sich grundsätzlich notwendige Dinge wie Codecs oder Proprietäre Treiber aus Drittquellen unbekannter Qualität holen muss und bei der Upgrades recht häufig in die Hose gehen. Die Release-Politik ist genau so undurchsichtig wie alles andere auch. Ich habe bis heute nicht so richtig einordnen können, an wen sich OpenSuSe wendet und welche Vorteile es bieten möchte.
Wir betreiben an meinem Arbeitsplatz mehrere Hundert Maschinen mit SLES 11, für welches übrigens die selben Kritikpunkte gelten. Und bei SLES kommt noch hinzu, dass man nicht nur nie weiß, wann die nächste SLES-Version erscheinen wird, sondern diese Verrückten auch noch so Späße treiben, wie innerhalb eines Service Packs auf eine komplett andere Kernelversion (2.6.32 auf 3.0.0) umzustellen. Das ist genau das, was man bei einer Enterprise-Distribution einfach nicht gebrauchen kann. Man setzt eine Enterprise-Distribution ja hauptsächlich deswegen ein, weil alle anderen Dritthersteller ihre Software gegen eine bestimmte Version einer Enterprise-Distribution bauen und dann für diese zertifizieren. Oft genug sind da auch Kernel-Module dabei, die dann natürlich plötzlich nicht mehr bauen. Von den Änderungen an Kernel-Subsystemen und den Bugs, die eine neue Kernel-Version möglicherweise mitbringt, ganz zu schweigen.
Service Packs sind für subtile Änderungen und Fehlerkorrekturen da, nicht für Änderungen, welche eigentlich ein neues Major Release rechtfertigen. Wir sind uns relativ einig in der Meinung, dass SuSe sich aktuell nicht nur bei der freien Variante verzettelt, sondern auch bei der kommerziellen. Mit recht fatalen Folgen für die Anwender. Wenn Ubuntu mehr Support von der Enterprise-Seite hätte, würde ich jedenfalls sofort umsteigen.
Nun man darf bei OpenSUSE nicht vergessen, dass es sich dabei primär um die "Spielwiese" für SLES/SLED handelt. Das hier mal unschöne Änderungen einfliessen muss man eben hinnehmen, vergleiche das mit Fedora.
Leider ist es nicht möglich so praktische Tools wie yast zu erstellen, ohne die Programme, die Konfiguriert werden sollen an manchen stellen etwas zu Patchen. Wo dabei wirr am Paketmanagement rumgebaut wird kann ich beim besten willen nicht erkennen. Die Frontends wechseln von Zeit zu Zeit, bleiben aber kompatibel zueinander (sollte einen Sysadmin ja eigentlich vor kein Problem stellen) Die Codec Geschichte hat Lizensrechtliche Hintergründe, die mittlerweile jedem hinreichend bekannt sein sollten. Auch andere Distributionen haben dieses Problem. Nur weil manche das ignorieren, weil noch nichts passiert ist, heisst das noch lange nicht, dass das so korrekt ist. Die Releasepolitik ist seit mindestens drei Jahren bekannt: alle 8 Monate ein neues Release. Bei SLES/SLED ist das leider wirklich etwas intransparent.
Ich denke OpenSUSE richtet sich primär an Leute, die ihren Rechner schnell und unkompliziert konfiguriert haben wollen (yast). Genau das ist auch der Vorteil gegenüber anderen Distris.
Das Problem mit den Service Packs kann ich nicht wirklich nachvollziehen: Es wird nicht von selbst installiert, man muss es explizit installieren. Von daher kann man das ja erstmal auf einer Testmaschine machen und falls Probleme (z.B. Kernel Module) auftreten, ein paar Wochen warten bis der Hersteller sein Produkt gepatcht hat. Das letzte Service Pack wird ja immer noch für eine Übergangszeit supportet.
> Die Codec Geschichte hat Lizensrechtliche Hintergründe, die mittlerweile jedem hinreichend bekannt sein sollten. Auch andere Distributionen haben dieses Problem.
Jein. Das Problem mit Codecs und proprietärer Software/Treibern/Firmware ist letztendlich immer jenes, dass die Distributoren diese nicht direkt mit ihrem "Produkt" ausliefern dürfen, wenn der Hersteller/Lizenzgeber dies nicht wünscht. Heißt: Ubuntu darf den Kram nicht mit in die ISO der Standardinstallation packen, aber ich als Endnutzer darf mir die Software ziehen und es installieren. SuSe, Fedora und manch andere gehen den einfachsten Weg und lassen mich als Nutzer einfach im Regen stehen. Ich muss mich aus Drittquellen bedienen, über deren Sicherheit und Qualität ich nichts weiß. Wenn ich später dann ein Problem habe, bekomme ich keinen Support. Das ist in der Realität einfach nicht praktikabel. 95% der Nutzer wollen nun mal MP3s hören und die z.B. Videobeschleunigung ihrer Grafikkarte nutzen. Dieses Verhalten ist einfach kontraproduktiv und muss nicht sein, wie Ubuntu ja schön zeigt: Bei denen liegen die ganzen Pakete schön fertig und qualitätsgesichert in den distributionseigenen Repositories, aber halt in einem Pfad, welcher in der Default-Installation nicht aktiviert ist. Während der Installation setze ich als Nutzer einen Haken, und mein System zieht die Pakete automatisch nach. Die Problematik wird umgangen, ohne dass ich als Nutzer jemals belästigt, im Regen stehen gelassen oder in die Nutzung fremder Repositories getrieben werde.
Was OpenSuSe und Fedora da machen, ist einfach unzeitgemäßer Kindergarten, der mit der mantraartig wiederholten Lüge "das halt halt lizenzrechtliche Gründe" gerechtfertigt werden soll. Wenn man sich z.B. mal bei RPM Fusion umschaut, um wie viele Pakete es da wirklich geht, kann man eigentlich nur lachen. Aber es sind halt genau die Pakete, unter deren Abwesenheit man ziemlich leidet. Und die einen unbedarften Anfänger dann zu Ubuntu treiben, weil er dort seinen Grafikkartentreiber einfach über eine schöne GUI aktivieren kann.
genau das kann ich mir nicht vorstellen: Der Distributor gibt weiterhin Software weiter, ohne die Zustimmung des Herstellers/Lizensgebers. Dass das in einem anderen, nicht per Default aktivem Repo liegt ändert nichts an dieser Tatsache. Genauso wenig die Aussage, es nur nutzen zu sollen, wenn man dies im eigenen Land darf (bzw. es noch zu keinen Klagen gekommen ist).
In SLES/SLED sind meines IMO auch diese Pakete enthalten, also ein MP3-Codec, Flashplayer, Adobe Reader, etc. Dafür werden dann natürlich auch entsprechend Lizenzgebühren bezahlt.
"Ich muss mich aus Drittquellen bedienen, über deren Sicherheit und Qualität ich nichts weiß."
Im Fall von openSUSE trifft das nicht zu. Die Repos für die Multimediacodecs sind samt und sonders über die Yast-Paketverwaltung über "Hinzufügen/Community-Repos" zugänglich und können mit einem Mausklick ausgewählt werden. Es steht auch ausrücklich da, für welche Anwendungszwecke die jeweiligen Repos gedacht sind. Die Repos, auch Packman, werden mit den entsprechenden Schlüsseln versehen und gewartet.
"95% der Nutzer wollen nun mal MP3s hören und die z.B. Videobeschleunigung ihrer Grafikkarte nutzen."
Der rechtlich korrekt lizenzierte Fluendo-MP3-Codec ist über das standardmäßig aktivierte Non-OSS-Repo zugänglich, andere MP3- und Multimediacodecs u.a. über das voreingetragene Packman-Repo. Die proprietären Grafiktreiber von AMD/Ati und Nvidia werden von openSUSE aktiv mit Unterstützung der Hersteller gewartet. Siehe u.a. diese Diskussion: https://bugzilla.novell.com/show_bug.cgi?id=756962 Hieraus geht klar hervor, dass z.B. die NVidia-Treiber für openSUSE tatsächlich "gewartet" werden.
Was Du also in punkto openSUSE schreibst, ist eher eine unzutreffende Legende. Du kennst openSUSE sehr wahrscheinlich nur sehr obrflächlich aus eigener Anschauung, ansonsten wären Dir diese Dinge irgendwann einmal aufgefallen.
Dass openSUSE seine Nutzer in punkto MP3- und Multimediacodecs sowie im Hinblick auf die unfreien AMD/ATI- bzw. Nvidia-Grafiktreiber im Regen stehen lassen würde, das trifft hundertprozentig nicht zu. Man muss natürlich als Computernutzer schon so weit sein, dass man in der Lage ist, ein Repo namens "Nvidia" hinzuzufügen, wenn man denn die unfreien Grafiktreiber benutzen möchte. Das ist aber selbst bei Leuten, die gerade erst bei Linux neu aufgeschlagen sind, durchweg der Fall. Computer-DAUs benutzen meist kein Linux, ansonsten hätte Ubuntu schon 10% Marktanteil und würde nicht immer noch bei unter 1% herumdümpeln.
"Wenn Ubuntu mehr Support von der Enterprise-Seite hätte, würde ich jedenfalls sofort umsteigen."
Dem ist aber nichts so, das gilt für den Support und das gilt fürs Know-How. Es hat schon seinen Grund, warum ihr SLES einsetzt. Das Marketinggeblubber kommt nämlich dort ganz schnell an seine Grenze, wo konkrete, schwierige Probleme zu lösen sind.
> Dem ist aber nichts so, das gilt für den Support und das gilt fürs Know-How. Ich stoße fast wöchentlich auf irgend einen Schmu unter der Haube von SLES, den andere Distributionen so viel besser gelöst haben, dass "die Idioten aus Nürnberg" bei uns zum Standard-Spruch geworden ist.
> Es hat schon seinen Grund, warum ihr SLES einsetzt. Ja, aber der hat nichts mit SLES selbst zu tun: Wir nehmen SLES, weil die Dritthersteller unter "Supported Platforms" meist genau zwei Distributionen auflisten: SLES und RHEL. Wir nehmen SLES nicht deshalb, weil wir den SuSe-Support so toll finden, sondern weil der Support des Drittherstellers rummosert, wenn wir eine Distribution verwenden, welche nicht offiziell abgesegnet ist. Ubuntu hätte für uns keinen einzigen Nachteil: Es gibt stabile Versionen mit langjähriger Unterstützung, es gibt kommerziellen Support, und wir würden sogar die Lizenzkosten sparen. Wir könnten auch RHEL nehmen, aber das wäre ja noch schlimmer, als SuSe.
> Das Marketinggeblubber kommt nämlich dort ganz schnell an seine Grenze, wo konkrete, schwierige Probleme zu lösen sind. SuSe liefert genau die selbe Software aus, wie alle anderen Distributionen auch. Jedes Problem, welches mit SLES gelöst werden kann, ist auch mit anderen Distributionen lösbar. SLES ist nicht stabiler und nicht qualitativ hochwertiger, als alle anderen auch. Mittlerweile gehe ist sogar eher vom Gegenteil aus.
SLES 11 fing mit Kernel 2.6.27 an, dann kam ein Megaupdate auf Kernel 2.6.32 samt Glibc, Xorg und Gcc und jetzt sind wir bei Kernel 3.0. Fast schon ein Rolling Release, eine openSUSE 11.1 in dieser Form wäre der Star am Distrohimmel.
OpenSuSe ist für mich die Distribution, bei der immer unnötig an allen möglichen Quellen herumgepatcht wird, die auch mal irgendwelche Zwitterlösungen wie KDE 3.5+4.0 ausliefert, wirr am Paketmanagement rumbaut (yum/zypper/sonstwas, unterschiedliche Arten für Paketquellen), bei der man sich grundsätzlich notwendige Dinge wie Codecs oder Proprietäre Treiber aus Drittquellen unbekannter Qualität holen muss und bei der Upgrades recht häufig in die Hose gehen. Die Release-Politik ist genau so undurchsichtig wie alles andere auch. Ich habe bis heute nicht so richtig einordnen können, an wen sich OpenSuSe wendet und welche Vorteile es bieten möchte.
Wir betreiben an meinem Arbeitsplatz mehrere Hundert Maschinen mit SLES 11, für welches übrigens die selben Kritikpunkte gelten. Und bei SLES kommt noch hinzu, dass man nicht nur nie weiß, wann die nächste SLES-Version erscheinen wird, sondern diese Verrückten auch noch so Späße treiben, wie innerhalb eines Service Packs auf eine komplett andere Kernelversion (2.6.32 auf 3.0.0) umzustellen. Das ist genau das, was man bei einer Enterprise-Distribution einfach nicht gebrauchen kann. Man setzt eine Enterprise-Distribution ja hauptsächlich deswegen ein, weil alle anderen Dritthersteller ihre Software gegen eine bestimmte Version einer Enterprise-Distribution bauen und dann für diese zertifizieren. Oft genug sind da auch Kernel-Module dabei, die dann natürlich plötzlich nicht mehr bauen. Von den Änderungen an Kernel-Subsystemen und den Bugs, die eine neue Kernel-Version möglicherweise mitbringt, ganz zu schweigen.
Service Packs sind für subtile Änderungen und Fehlerkorrekturen da, nicht für Änderungen, welche eigentlich ein neues Major Release rechtfertigen. Wir sind uns relativ einig in der Meinung, dass SuSe sich aktuell nicht nur bei der freien Variante verzettelt, sondern auch bei der kommerziellen. Mit recht fatalen Folgen für die Anwender. Wenn Ubuntu mehr Support von der Enterprise-Seite hätte, würde ich jedenfalls sofort umsteigen.
Nun man darf bei OpenSUSE nicht vergessen, dass es sich dabei primär um die "Spielwiese" für SLES/SLED handelt. Das hier mal unschöne Änderungen einfliessen muss man eben hinnehmen, vergleiche das mit Fedora.
Leider ist es nicht möglich so praktische Tools wie yast zu erstellen, ohne die Programme, die Konfiguriert werden sollen an manchen stellen etwas zu Patchen. Wo dabei wirr am Paketmanagement rumgebaut wird kann ich beim besten willen nicht erkennen. Die Frontends wechseln von Zeit zu Zeit, bleiben aber kompatibel zueinander (sollte einen Sysadmin ja eigentlich vor kein Problem stellen)
Die Codec Geschichte hat Lizensrechtliche Hintergründe, die mittlerweile jedem hinreichend bekannt sein sollten. Auch andere Distributionen haben dieses Problem. Nur weil manche das ignorieren, weil noch nichts passiert ist, heisst das noch lange nicht, dass das so korrekt ist.
Die Releasepolitik ist seit mindestens drei Jahren bekannt: alle 8 Monate ein neues Release. Bei SLES/SLED ist das leider wirklich etwas intransparent.
Ich denke OpenSUSE richtet sich primär an Leute, die ihren Rechner schnell und unkompliziert konfiguriert haben wollen (yast). Genau das ist auch der Vorteil gegenüber anderen Distris.
Das Problem mit den Service Packs kann ich nicht wirklich nachvollziehen:
Es wird nicht von selbst installiert, man muss es explizit installieren. Von daher kann man das ja erstmal auf einer Testmaschine machen und falls Probleme (z.B. Kernel Module) auftreten, ein paar Wochen warten bis der Hersteller sein Produkt gepatcht hat. Das letzte Service Pack wird ja immer noch für eine Übergangszeit supportet.
> Die Codec Geschichte hat Lizensrechtliche Hintergründe, die mittlerweile jedem hinreichend bekannt sein sollten. Auch andere Distributionen haben dieses Problem.
Jein. Das Problem mit Codecs und proprietärer Software/Treibern/Firmware ist letztendlich immer jenes, dass die Distributoren diese nicht direkt mit ihrem "Produkt" ausliefern dürfen, wenn der Hersteller/Lizenzgeber dies nicht wünscht. Heißt: Ubuntu darf den Kram nicht mit in die ISO der Standardinstallation packen, aber ich als Endnutzer darf mir die Software ziehen und es installieren. SuSe, Fedora und manch andere gehen den einfachsten Weg und lassen mich als Nutzer einfach im Regen stehen. Ich muss mich aus Drittquellen bedienen, über deren Sicherheit und Qualität ich nichts weiß. Wenn ich später dann ein Problem habe, bekomme ich keinen Support. Das ist in der Realität einfach nicht praktikabel. 95% der Nutzer wollen nun mal MP3s hören und die z.B. Videobeschleunigung ihrer Grafikkarte nutzen. Dieses Verhalten ist einfach kontraproduktiv und muss nicht sein, wie Ubuntu ja schön zeigt: Bei denen liegen die ganzen Pakete schön fertig und qualitätsgesichert in den distributionseigenen Repositories, aber halt in einem Pfad, welcher in der Default-Installation nicht aktiviert ist. Während der Installation setze ich als Nutzer einen Haken, und mein System zieht die Pakete automatisch nach. Die Problematik wird umgangen, ohne dass ich als Nutzer jemals belästigt, im Regen stehen gelassen oder in die Nutzung fremder Repositories getrieben werde.
Was OpenSuSe und Fedora da machen, ist einfach unzeitgemäßer Kindergarten, der mit der mantraartig wiederholten Lüge "das halt halt lizenzrechtliche Gründe" gerechtfertigt werden soll. Wenn man sich z.B. mal bei RPM Fusion umschaut, um wie viele Pakete es da wirklich geht, kann man eigentlich nur lachen. Aber es sind halt genau die Pakete, unter deren Abwesenheit man ziemlich leidet. Und die einen unbedarften Anfänger dann zu Ubuntu treiben, weil er dort seinen Grafikkartentreiber einfach über eine schöne GUI aktivieren kann.
genau das kann ich mir nicht vorstellen:
Der Distributor gibt weiterhin Software weiter, ohne die Zustimmung des Herstellers/Lizensgebers. Dass das in einem anderen, nicht per Default aktivem Repo liegt ändert nichts an dieser Tatsache. Genauso wenig die Aussage, es nur nutzen zu sollen, wenn man dies im eigenen Land darf (bzw. es noch zu keinen Klagen gekommen ist).
In SLES/SLED sind meines IMO auch diese Pakete enthalten, also ein MP3-Codec, Flashplayer, Adobe Reader, etc. Dafür werden dann natürlich auch entsprechend Lizenzgebühren bezahlt.
"Ich muss mich aus Drittquellen bedienen, über deren Sicherheit und Qualität ich nichts weiß."
Im Fall von openSUSE trifft das nicht zu. Die Repos für die Multimediacodecs sind samt und sonders über die Yast-Paketverwaltung über "Hinzufügen/Community-Repos" zugänglich und können mit einem Mausklick ausgewählt werden. Es steht auch ausrücklich da, für welche Anwendungszwecke die jeweiligen Repos gedacht sind.
Die Repos, auch Packman, werden mit den entsprechenden Schlüsseln versehen und gewartet.
"95% der Nutzer wollen nun mal MP3s hören und die z.B. Videobeschleunigung ihrer Grafikkarte nutzen."
Der rechtlich korrekt lizenzierte Fluendo-MP3-Codec ist über das standardmäßig aktivierte Non-OSS-Repo zugänglich, andere MP3- und Multimediacodecs u.a. über das voreingetragene Packman-Repo.
Die proprietären Grafiktreiber von AMD/Ati und Nvidia werden von openSUSE aktiv mit Unterstützung der Hersteller gewartet.
Siehe u.a. diese Diskussion:
https://bugzilla.novell.com/show_bug.cgi?id=756962
Hieraus geht klar hervor, dass z.B. die NVidia-Treiber für openSUSE tatsächlich "gewartet" werden.
Was Du also in punkto openSUSE schreibst, ist eher eine unzutreffende Legende. Du kennst openSUSE sehr wahrscheinlich nur sehr obrflächlich aus eigener Anschauung, ansonsten wären Dir diese Dinge irgendwann einmal aufgefallen.
Dass openSUSE seine Nutzer in punkto MP3- und Multimediacodecs sowie im Hinblick auf die unfreien AMD/ATI- bzw. Nvidia-Grafiktreiber im Regen stehen lassen würde, das trifft hundertprozentig nicht zu. Man muss natürlich als Computernutzer schon so weit sein, dass man in der Lage ist, ein Repo namens "Nvidia" hinzuzufügen, wenn man denn die unfreien Grafiktreiber benutzen möchte. Das ist aber selbst bei Leuten, die gerade erst bei Linux neu aufgeschlagen sind, durchweg der Fall. Computer-DAUs benutzen meist kein Linux, ansonsten hätte Ubuntu schon 10% Marktanteil und würde nicht immer noch bei unter 1% herumdümpeln.
"Wenn Ubuntu mehr Support von der Enterprise-Seite hätte, würde ich jedenfalls sofort umsteigen."
Dem ist aber nichts so, das gilt für den Support und das gilt fürs Know-How.
Es hat schon seinen Grund, warum ihr SLES einsetzt.
Das Marketinggeblubber kommt nämlich dort ganz schnell an seine Grenze, wo konkrete, schwierige Probleme zu lösen sind.
> Dem ist aber nichts so, das gilt für den Support und das gilt fürs Know-How.
Ich stoße fast wöchentlich auf irgend einen Schmu unter der Haube von SLES, den andere Distributionen so viel besser gelöst haben, dass "die Idioten aus Nürnberg" bei uns zum Standard-Spruch geworden ist.
> Es hat schon seinen Grund, warum ihr SLES einsetzt.
Ja, aber der hat nichts mit SLES selbst zu tun: Wir nehmen SLES, weil die Dritthersteller unter "Supported Platforms" meist genau zwei Distributionen auflisten: SLES und RHEL. Wir nehmen SLES nicht deshalb, weil wir den SuSe-Support so toll finden, sondern weil der Support des Drittherstellers rummosert, wenn wir eine Distribution verwenden, welche nicht offiziell abgesegnet ist. Ubuntu hätte für uns keinen einzigen Nachteil: Es gibt stabile Versionen mit langjähriger Unterstützung, es gibt kommerziellen Support, und wir würden sogar die Lizenzkosten sparen. Wir könnten auch RHEL nehmen, aber das wäre ja noch schlimmer, als SuSe.
> Das Marketinggeblubber kommt nämlich dort ganz schnell an seine Grenze, wo konkrete, schwierige Probleme zu lösen sind.
SuSe liefert genau die selbe Software aus, wie alle anderen Distributionen auch. Jedes Problem, welches mit SLES gelöst werden kann, ist auch mit anderen Distributionen lösbar. SLES ist nicht stabiler und nicht qualitativ hochwertiger, als alle anderen auch. Mittlerweile gehe ist sogar eher vom Gegenteil aus.
SLES 11 fing mit Kernel 2.6.27 an, dann kam ein Megaupdate auf Kernel 2.6.32 samt Glibc, Xorg und Gcc und jetzt sind wir bei Kernel 3.0.
Fast schon ein Rolling Release, eine openSUSE 11.1 in dieser Form wäre der Star am Distrohimmel.
Zu SLES11:
Eine Roadmap gibt es hier: http://www.slideshare.net/NOVL/suse-linux-enterprise-technology-roadmap
Zum Anderen werden "innerhalb eines Servicepacks" keine Kernelmajorupdates gemacht.
SLES11 SP1: 2.6.x -> SLES11 SP2: 3.0.x