Ich sehe das eher nicht negativ, allerdings aus der Sicht eines Desktopnutzers.
Uns wird ja immer gesagt, dass eine stabile Distro möglichst nicht verändert oder gar aktualisiert werden sollte, Kernel, Xorg, Glibc, Gcc, etc. upzugraden, würde das System instabil machen. Suse führt doch hier das genaue Gegenteil vor: Etwa alle zwei Jahre gibt es eine wohl gelungene Generalüberholung mittels Service Packs. Das wäre doch ein Supportmodell, mit dem man vielleicht sogar wieder eine kommerziell erfolgreiche Desktopdistribution herausbringen könnte.
Wer sich die anfängliche Softwareausstattung von SLES 11 anschaut und diese nun mit derjenigen der SLES 11 SP2-Distro vergleicht, kommt doch aus dem Staunen nicht mehr heraus: Solche Giganto-Updates sind also tatsächlich relativ gefahrlos möglich, nach etwa zweijährigen "Stabilitätsphasen" unterzieht man sich jeweils einer solchen Prozedur ohne Neuinstallation und verfügt dann wieder über eine aktuelle, "stabile" Distro. Einfach traumhaft.
Das Problem dabei ist, dass es keine zwei Jahre sind, sondern irgendwas zwischen 0,5 und 1,5 Jahren. Das ist total beschissen planbar, wenn man unternehmenskritische Anwendungen darauf betreibt, und pro Jahr nur eine Downtime seitens des Kunden möglich ist, diese Downtime aber auch mit vielen anderen Abteilungen abgestimmt werden muss. Ich halte Ubuntu nicht für eine servertaugliche Distro, dort wäre es aber um Längen besser gelöst, nicht nur wegen den LTS-Varianten, sondern weil man relativ feste Erscheinungstermine hat und dementsprechend langfristig planen kann.
Die großen Updates sind eben nicht gefahrlos möglich, im Rechenzentrum sitzen die Admins ja nicht gelangweilt rum und warten auf irgendeine Beschäftigung, sondern haben durchaus auch anderes zu tun. Irgendwann meint SuSE ein SP rauszubringen, und ab da bleiben 6 Monate um zu testen, ob alle (beschissenen programmierten und z.T. arsch-alten) Anwendungen auch mit einem Kernel 3.x laufen, die Änderung des langen Datumsfomates für alle Eventualitäten passt, usw. usf. Da sind 6 Monate reichlich knapp, wenn in der Zeit schon andere arbeitsintensive Sachen geplant sind. Mich regt das auf, und ich wäre sofort dafür zu einer anderen Enterprise-Distrie zu wechseln. Leider treff ich diese Entscheidung nicht allein, und 3rd-Party-software ist zum Teil nur für SLES zertifiziert.
Ich weiß nicht was sich SuSE dabei gedacht hat, aber wenn ich andere Sachen angucke (z.B. btrfs ist supportet, aber ext4 nicht) dann weiß ich nicht ob sich dabei überhaupt irgendwas gedacht wurde, oder ob man einfach nur anders sein will.
Der Zeitraum in welchem neue Servicepacks veröffentlicht werden ist doch egal. Bei uns wird auch hauptssächlich SLES eingesetzt - und ich finde das gut. Wenn deine Kunden Software einsetzen, die nicht sauber programmiert ist, und Probleme mit neuen Kerneln hat, dann müssen die sich halt selbst um die Probleme kümmern. So wird das bei uns gemacht: Sandartsoftware wird getestet - bei Solchen Applikationen wie Oracle, SAP etc. sind die Hersteller eh bei den Betatests von SLES dabei und geben ihre eigene Software für das neue Servicepack frei... Wenn jemand Bastelsoftware einsetzen muß (warum auch immer) und von dessen Hersteller keine Freigabe für eine neue Betriebssystemversion bekommen kann, dann machen wir das angebot, die Software auf der alten Version weiterzubetreiben, aber wir übergeben das Risiko von Problemen an den Kunden. Haben wir die Software im Auftrag des Kunden beschafft, dann gehen wir auf den Hersteller zu und verlangen eine Freigabe oder eine neue Version. Macht der Hersteller das nicht, oder gibt es ihn nicht mehr, dann ist wieder der Kunde am zug sich eine neue Software zu suchen, oder mit dem Risiko zu leben...
> Bei uns wird auch hauptssächlich SLES eingesetzt - und ich finde das gut. Nur so ausm Bauch, oder mit Gründen?
> wie Oracle, SAP etc. sind die Hersteller eh bei den Betatests von SLES dabei SAP sicher, die bieten ja selber auch SAP auf SLES zusammen mit Fujitsu an. Oracle macht OEL, RHEL und SLES, und zwar in der Reihenfolge. Supportet ist das zwar meistens irgendwie, aber wir hatten schon oft Supporter die bei SLES passen mussten, haben einige Fehler in Dokus oder Installskripten gefunden, und die Krönung war ein hochbezahlter Consultant der bei uns Oracle RAC auf SLES installieren sollte, und beim ersten Unterschied zu Red Hat gescheitert ist.
Schön wenn ihr nur Oracle und SAP einsetzt, und das immer in den aktuellsten und zum aktuellen SLES passenden Versionen. Bei uns siehts leider etwas anders aus..
Ich sehe das eher nicht negativ, allerdings aus der Sicht eines Desktopnutzers.
Uns wird ja immer gesagt, dass eine stabile Distro möglichst nicht verändert oder gar aktualisiert werden sollte, Kernel, Xorg, Glibc, Gcc, etc. upzugraden, würde das System instabil machen. Suse führt doch hier das genaue Gegenteil vor: Etwa alle zwei Jahre gibt es eine wohl gelungene Generalüberholung mittels Service Packs. Das wäre doch ein Supportmodell, mit dem man vielleicht sogar wieder eine kommerziell erfolgreiche Desktopdistribution herausbringen könnte.
Wer sich die anfängliche Softwareausstattung von SLES 11 anschaut und diese nun mit derjenigen der SLES 11 SP2-Distro vergleicht, kommt doch aus dem Staunen nicht mehr heraus: Solche Giganto-Updates sind also tatsächlich relativ gefahrlos möglich, nach etwa zweijährigen "Stabilitätsphasen" unterzieht man sich jeweils einer solchen Prozedur ohne Neuinstallation und verfügt dann wieder über eine aktuelle, "stabile" Distro. Einfach traumhaft.
Das Problem dabei ist, dass es keine zwei Jahre sind, sondern irgendwas zwischen 0,5 und 1,5 Jahren. Das ist total beschissen planbar, wenn man unternehmenskritische Anwendungen darauf betreibt, und pro Jahr nur eine Downtime seitens des Kunden möglich ist, diese Downtime aber auch mit vielen anderen Abteilungen abgestimmt werden muss. Ich halte Ubuntu nicht für eine servertaugliche Distro, dort wäre es aber um Längen besser gelöst, nicht nur wegen den LTS-Varianten, sondern weil man relativ feste Erscheinungstermine hat und dementsprechend langfristig planen kann.
Die großen Updates sind eben nicht gefahrlos möglich, im Rechenzentrum sitzen die Admins ja nicht gelangweilt rum und warten auf irgendeine Beschäftigung, sondern haben durchaus auch anderes zu tun. Irgendwann meint SuSE ein SP rauszubringen, und ab da bleiben 6 Monate um zu testen, ob alle (beschissenen programmierten und z.T. arsch-alten) Anwendungen auch mit einem Kernel 3.x laufen, die Änderung des langen Datumsfomates für alle Eventualitäten passt, usw. usf. Da sind 6 Monate reichlich knapp, wenn in der Zeit schon andere arbeitsintensive Sachen geplant sind. Mich regt das auf, und ich wäre sofort dafür zu einer anderen Enterprise-Distrie zu wechseln. Leider treff ich diese Entscheidung nicht allein, und 3rd-Party-software ist zum Teil nur für SLES zertifiziert.
Ich weiß nicht was sich SuSE dabei gedacht hat, aber wenn ich andere Sachen angucke (z.B. btrfs ist supportet, aber ext4 nicht) dann weiß ich nicht ob sich dabei überhaupt irgendwas gedacht wurde, oder ob man einfach nur anders sein will.
Für die Klagen zahlender Kunden haben sie sicher ein offenes Ohr. Hast du dich deshalb bereits an den Kundendienst gewendet?
Ja. Es wurde als Wunsch aufgenommen und an irgendwen weitergeleitet.
Der Zeitraum in welchem neue Servicepacks veröffentlicht werden ist doch egal. Bei uns wird auch hauptssächlich SLES eingesetzt - und ich finde das gut.
Wenn deine Kunden Software einsetzen, die nicht sauber programmiert ist, und Probleme mit neuen Kerneln hat, dann müssen die sich halt selbst um die Probleme kümmern. So wird das bei uns gemacht: Sandartsoftware wird getestet - bei Solchen Applikationen wie Oracle, SAP etc. sind die Hersteller eh bei den Betatests von SLES dabei und geben ihre eigene Software für das neue Servicepack frei... Wenn jemand Bastelsoftware einsetzen muß (warum auch immer) und von dessen Hersteller keine Freigabe für eine neue Betriebssystemversion bekommen kann, dann machen wir das angebot, die Software auf der alten Version weiterzubetreiben, aber wir übergeben das Risiko von Problemen an den Kunden. Haben wir die Software im Auftrag des Kunden beschafft, dann gehen wir auf den Hersteller zu und verlangen eine Freigabe oder eine neue Version. Macht der Hersteller das nicht, oder gibt es ihn nicht mehr, dann ist wieder der Kunde am zug sich eine neue Software zu suchen, oder mit dem Risiko zu leben...
> Bei uns wird auch hauptssächlich SLES eingesetzt - und ich finde das gut.
Nur so ausm Bauch, oder mit Gründen?
> wie Oracle, SAP etc. sind die Hersteller eh bei den Betatests von SLES dabei
SAP sicher, die bieten ja selber auch SAP auf SLES zusammen mit Fujitsu an. Oracle macht OEL, RHEL und SLES, und zwar in der Reihenfolge. Supportet ist das zwar meistens irgendwie, aber wir hatten schon oft Supporter die bei SLES passen mussten, haben einige Fehler in Dokus oder Installskripten gefunden, und die Krönung war ein hochbezahlter Consultant der bei uns Oracle RAC auf SLES installieren sollte, und beim ersten Unterschied zu Red Hat gescheitert ist.
Schön wenn ihr nur Oracle und SAP einsetzt, und das immer in den aktuellsten und zum aktuellen SLES passenden Versionen. Bei uns siehts leider etwas anders aus..