ich schätze das machen sie auch um ein stabiles kde 4.9 zu intigrieren und nicht erst nach zu schieben vieleicht schau ich es mir auch mal an doch zurzeit bin ich mit ubuntu sehr zufrieden
kann sein das dies als nebeneffekt genutzt wird, aber nur vielleicht. Denn eigentlich hackt es gewaltig an Paketierern, Entwicklern und Helfern die beim stabilisieren fehlen, was vor allem auch zu dieser Verzögerung führte. Liest man sich die mails auf der Liste durch, wird deutlich das es da Pakete gibt die schon seit mehreren Monaten nicht mehr gepflegt wurden und auch auf nachfrage keiner sich Verantwortlich fühlte einzugreifen. Ähnlich lief das mit der letzten openSUSE (12.1), als man mit der ersten Beta bemerkte das es das Art-team nicht mehr gab und kein neues Branding, Theme für 12.1 angelegt war. Erst als Coolo (Release Manager) anmerkte ob das Stripes-Theme von 11.4 verwendet werden solle, kam das auf den Radar und man erstellte in letzter Minute ein Theme samt Branding, was unter uns gesagt viel besser war als das von 11.4 (Stripes OK, Farbe Grün pfui ) wo man Zeit hatte diese auszubrüten.
Letztendlich ist es nicht wichtig ob KDE 4.9 in 12.2 drin ist oder nicht. Wichtiger ist das man sich auf ein Release Modell einigt das den vorhandenen aktiven beim Projekt entspricht und man die anfallende Arbeit auch schafft. Es nutzt niemanden was alle 8 Monate eine Distri rauszuhauen die von der Qualität immer miserabler wurde, und das war bei openSUSE so. Ein upgrade auf kde 4.9 ist bei openSUSE kein Problem nachträglich auszuführen, dazu muss nur die richtige Repo her die es ja mit K:R:49 wohl dann geben wird.
Es fehlen.den Projekt nicht unbedingt die Helfer. Eher im Gegenteil, die haben ein Problem die alle zu organisieren. Die Struktur von openSUSE war wohl für wenige kleine Teams gedacht.
Nun bietet openSUSE dank Buildservice hervorragende möglichkeiten Pakete zu bauen. So haben die nun wahnsinnig viele Entwickler die sich in unzälige Team splitten und schwer zu wartende chaotische Abhängigkeiten erzeugen.
Den zustand wollen sie wohl irgendwie endgegenwirken. Es kann echt nicht sein das niemand mehr weiß wer für was zustandig ist.
Hatte ich auch gehofft, wird vom Release Manager aber derzeit abgeblockt. Verständlich, das er in der derzeitigen Situation nicht noch neue große und bedeutende Baustellen aufmachen will. Wenn KDE im release nicht rund läuft, wäre das schon ein gewaltiger Schaden für das openSUSE Image. Eine vertane Chance wäre es trotzdem, dann sollen Sie eben Anfang Oktober releasen. Auf die 2-3 Wochen kommt es dann auch nicht mehr an.
Von kljkljkljkljklj am Fr, 15. Juni 2012 um 20:34 #
Nein, das wurde schon verworfen. Lies einmal auf den Mailinglisten mit, openSUSE hat mit 12.2 völlig andere Sorgen. KDE 4.9 wird aus dem üblichen KDE4-Repo nachinstallierbar sein. Mittlerweile ist es soweit, dass man am besten openSUSE 12.3 auslässt. openSUSE sollte in Zukunft einfach die Version, die dadurch zustande kommt, dass sich SLES/SLED bei ihrem Upstream openSUSE "bedienen", als LTS-Version für drei Jahre unterstützen, mit striktem Fokus auf den Desktop. Der Support ist ja das Entscheidende an SLES/SLED, nicht die Basissoftware an sich, die gibt es sowieso für alle "umsonst".
mit später um stabiler bin ichs auch zufrieden. KDE 4.9 waren aber wohl so große Anderungen dass es erst wieder etwas reifen sollte. Habe lieber ein stabileres kde 4.8 ;o)
Die Berliner wollten wenigstens 800 Leiharbeiter einstellen um die 800 Brandschutztüren an nagelneuen Flughafen von Hand zu schließen. Berlin=Technik pur
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.
Die Verschiebung des Release 12.2 finde ich nicht schlimm. Ich will mit Opensuse arbeiten, d.h. wir setzen in unserer Firma (4 PC's) ausschließlich Linux- und OS-Software ein. Da kann ich sowieso nicht alle 6 Monate die ganzen Systeme updaten. 1x jährlich reicht mir völlig, manchmal sogar nur alle 2 Jahre. Wichtig ist für mich, dass ein neues Release wirklich auf Anhieb funktioniert - out of the box, oder direkt vom Download. Und da habe ich mit opensuse bisher gute Erfahrungen gemacht, die 12.1 war perfekt: DVD rein, paar mal klicken, Kaffee holen gehen, bißchen dem System zugucken, fertig. (Um Längen besser und schneller als alle "Fenster"installationen, die ich bisher machen mußte.) Also freue ich mich mal auf 13.1 oder 13.2...
Solange Du openSUSE 11.1 als reines Desktopsystem hinter einem Router mit entsprechender Firewall benutzt, die unabhängig von Deinem Rechnersystem agiert, solange wird das vermutlich auch klappen. Momentaner Stand ist, dass u.a. Kernel, Glibc, Openssl, Samba, Bind und einige Grafikbibliotheken (libtiff, libpng) in openSUSE 11.1 mehr oder weniger schwere Sicherheitslücken aufweisen, aber wenigstens hast Du aktuell gepatchte Mozillaprodukte in Form von Firefox-ESR und Thunderbird-ESR zur Verfügung.
Ja, und ich hatte bis unlängst die Evergreen 11.1 REPOs. Ferner gibt es z.B. die Adobe Produkte auch als Universal-RPM. Schließlich kann man div. Programme als Quellcode runterladen und per make & make install verfügbar machen. --- Kann mir jemand sagen, warum bei der openSUSE 12.2 Beta Installation im "Grub2" nur ein einziger Booteintrag (=Linux) angelegt wird? Das war für mich ein Grund auf der Stelle abzubrechen, da manuelles Anlegen weiterer Booteinträge gar nicht vorgesehen zu sein scheint.
"Schließlich kann man div. Programme als Quellcode runterladen und per make & make install verfügbar machen."
Das mache ich genauso, ich baue einfach die meisten openSUSE 11.2-Pakete für openSUSE 11.1 (das sich ja noch im Evergreen-Support befindet) aus dem entsprechenden 11.2-Quellcode nach. Ich hatte zwar schon gewisse Bedenken, Glibc 2.10 über meine 32bit-openSUSE 11.1 drüber zu bügeln, aber es hat funktioniert. Ansonsten funktionieren noch die meisten SLES11-OBS-Repos.
openSUSE 12.2 ist noch ziemlich unfertig. Trotzdem sollten sich andere Betriebssysteme und Bootloader über die 40_custom-Datei nachtragen lassen. Alternativ gibt es vielleicht ein Yast-Grub2-Modul?
ich schätze das machen sie auch um ein stabiles kde 4.9 zu intigrieren und nicht erst nach zu schieben vieleicht schau ich es mir auch mal an doch zurzeit bin ich mit ubuntu sehr zufrieden
kann sein das dies als nebeneffekt genutzt wird, aber nur vielleicht. Denn eigentlich hackt es gewaltig an Paketierern, Entwicklern und Helfern die beim stabilisieren fehlen, was vor allem auch zu dieser Verzögerung führte. Liest man sich die mails auf der Liste durch, wird deutlich das es da Pakete gibt die schon seit mehreren Monaten nicht mehr gepflegt wurden und auch auf nachfrage keiner sich Verantwortlich fühlte einzugreifen. Ähnlich lief das mit der letzten openSUSE (12.1), als man mit der ersten Beta bemerkte das es das Art-team nicht mehr gab und kein neues Branding, Theme für 12.1 angelegt war. Erst als Coolo (Release Manager) anmerkte ob das Stripes-Theme von 11.4 verwendet werden solle, kam das auf den Radar und man erstellte in letzter Minute ein Theme samt Branding, was unter uns gesagt viel besser war als das von 11.4 (Stripes OK, Farbe Grün pfui
) wo man Zeit hatte diese auszubrüten.
Letztendlich ist es nicht wichtig ob KDE 4.9 in 12.2 drin ist oder nicht. Wichtiger ist das man sich auf ein Release Modell einigt das den vorhandenen aktiven beim Projekt entspricht und man die anfallende Arbeit auch schafft. Es nutzt niemanden was alle 8 Monate eine Distri rauszuhauen die von der Qualität immer miserabler wurde, und das war bei openSUSE so. Ein upgrade auf kde 4.9 ist bei openSUSE kein Problem nachträglich auszuführen, dazu muss nur die richtige Repo her die es ja mit K:R:49 wohl dann geben wird.
Es fehlen.den Projekt nicht unbedingt die Helfer. Eher im Gegenteil, die haben ein Problem die alle zu organisieren.
Die Struktur von openSUSE war wohl für wenige kleine Teams gedacht.
Nun bietet openSUSE dank Buildservice hervorragende möglichkeiten Pakete zu bauen.
So haben die nun wahnsinnig viele Entwickler die sich in unzälige Team splitten und schwer zu wartende chaotische Abhängigkeiten erzeugen.
Den zustand wollen sie wohl irgendwie endgegenwirken. Es kann echt nicht sein das niemand mehr weiß wer für was zustandig ist.
Hatte ich auch gehofft, wird vom Release Manager aber derzeit abgeblockt. Verständlich, das er in der derzeitigen Situation nicht noch neue große und bedeutende Baustellen aufmachen will. Wenn KDE im release nicht rund läuft, wäre das schon ein gewaltiger Schaden für das openSUSE Image.
Eine vertane Chance wäre es trotzdem, dann sollen Sie eben Anfang Oktober releasen. Auf die 2-3 Wochen kommt es dann auch nicht mehr an.
Nein, das wurde schon verworfen.
Lies einmal auf den Mailinglisten mit, openSUSE hat mit 12.2 völlig andere Sorgen.
KDE 4.9 wird aus dem üblichen KDE4-Repo nachinstallierbar sein.
Mittlerweile ist es soweit, dass man am besten openSUSE 12.3 auslässt.
openSUSE sollte in Zukunft einfach die Version, die dadurch zustande kommt, dass sich SLES/SLED bei ihrem Upstream openSUSE "bedienen", als LTS-Version für drei Jahre unterstützen, mit striktem Fokus auf den Desktop. Der Support ist ja das Entscheidende an SLES/SLED, nicht die Basissoftware an sich, die gibt es sowieso für alle "umsonst".
mit später um stabiler bin ichs auch zufrieden. KDE 4.9 waren aber wohl so große Anderungen dass es erst wieder etwas reifen sollte. Habe lieber ein stabileres kde 4.8 ;o)
Haben sie etwa auch Probleme mit dem Brandschutz? (Berliner Insiderwitz)
Die Berliner wollten wenigstens 800 Leiharbeiter einstellen um die 800 Brandschutztüren an nagelneuen Flughafen von Hand zu schließen. Berlin=Technik pur
Die bestimmt bestimmt ein Fenster-System eingesetzt, oder?
Das dass ....
Schönes WE allen!
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
Die Verschiebung des Release 12.2 finde ich nicht schlimm. Ich will mit Opensuse arbeiten, d.h. wir setzen in unserer Firma (4 PC's) ausschließlich Linux- und OS-Software ein. Da kann ich sowieso nicht alle 6 Monate die ganzen Systeme updaten. 1x jährlich reicht mir völlig, manchmal sogar nur alle 2 Jahre.
Wichtig ist für mich, dass ein neues Release wirklich auf Anhieb funktioniert - out of the box, oder direkt vom Download.
Und da habe ich mit opensuse bisher gute Erfahrungen gemacht, die 12.1 war perfekt: DVD rein, paar mal klicken, Kaffee holen gehen, bißchen dem System zugucken, fertig. (Um Längen besser und schneller als alle "Fenster"installationen, die ich bisher machen mußte.)
Also freue ich mich mal auf 13.1 oder 13.2...
Ich arbeite noch mit openSUSE 11.1 und freue mich auf Version 12.2 !
Bis es im September soweit ist, langt mir die 11.1er mit den Mozilla, VideoLan & Packman REPO-Updates noch.
Und vor 11.1 hatte ich openSUSE 10.2 im Einsatz, sonst nichts.
Solange Du openSUSE 11.1 als reines Desktopsystem hinter einem Router mit entsprechender Firewall benutzt, die unabhängig von Deinem Rechnersystem agiert, solange wird das vermutlich auch klappen. Momentaner Stand ist, dass u.a. Kernel, Glibc, Openssl, Samba, Bind und einige Grafikbibliotheken (libtiff, libpng) in openSUSE 11.1 mehr oder weniger schwere Sicherheitslücken aufweisen, aber wenigstens hast Du aktuell gepatchte Mozillaprodukte in Form von Firefox-ESR und Thunderbird-ESR zur Verfügung.
Ja, und ich hatte bis unlängst die Evergreen 11.1 REPOs.
Ferner gibt es z.B. die Adobe Produkte auch als Universal-RPM. Schließlich kann man div. Programme als Quellcode runterladen und per make & make install verfügbar machen.
---
Kann mir jemand sagen, warum bei der openSUSE 12.2 Beta Installation im "Grub2" nur ein einziger Booteintrag (=Linux) angelegt wird?
Das war für mich ein Grund auf der Stelle abzubrechen, da manuelles Anlegen weiterer Booteinträge gar nicht vorgesehen zu sein scheint.
"Schließlich kann man div. Programme als Quellcode runterladen und per make & make install verfügbar machen."
Das mache ich genauso, ich baue einfach die meisten openSUSE 11.2-Pakete für openSUSE 11.1 (das sich ja noch im Evergreen-Support befindet) aus dem entsprechenden 11.2-Quellcode nach. Ich hatte zwar schon gewisse Bedenken, Glibc 2.10 über meine 32bit-openSUSE 11.1 drüber zu bügeln, aber es hat funktioniert. Ansonsten funktionieren noch die meisten SLES11-OBS-Repos.
openSUSE 12.2 ist noch ziemlich unfertig. Trotzdem sollten sich andere Betriebssysteme und Bootloader über die 40_custom-Datei nachtragen lassen. Alternativ gibt es vielleicht ein Yast-Grub2-Modul?