> Etwas überraschend klingt dagegen die Ankündigung, Btrfs als offiziell von Suse unterstütztes Dateisystem in SLES 11 SP2 anzubieten,
das habe ich anders in Erinnerung: Das Btrfs ist schon fertig und stabil, aber das Filesystem checkingtool wurde wohl erst vor kurzem (21.02.12?) für stabil eingestuft....
Nicht, wenn man den Kernel-Entwicklern glaubt. Hier die Beschreibung aus dem Git-Tree des Kernels:
[..]
Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED. You should say N here unless you are interested in testing Btrfs with non-critical data.
wieso ist die Ankündigung der offiziellen Unterstützung von BTRFS überrasschend? das Wurde schon letzten Juli angekündigt. Auch wurde damals angekündigt EXT4 nicht zu unterstützen... Ab SLES12 soll BTRFS sogar das default-FS bei SLES werden. (oh - hab ich jetzt schon wieder was überaus neues verraten?
und nein - ich arbeite nicht bei suse.. ich nutze nur SLES
Schon zum zweiten Mal sind die Änderungen wirklich massiv. Eigentlich handelt es sich nicht mehr um SLES11, sondern um eine Art "SLES 13". Eine neue Distro also. Innerhalb von SLES11 wurd defacto von "openSUSE 11.1" auf "openSUSE 12.1" aktualisiert. Auch ein Weg, eine Distro zukunftsfähig zu halten.
Das sehe ich ähnlich, aber negativ. SLES-Nutzer sind gezwungen innerhalb von 6 Monaten nach Erscheinen eines Servicepacks auf dieses zu wechseln. SLES bringt die aber ohne festen Zeitplan raus, und haut noch dazu massive Änderungen rein. Planbarkeit und Enterprise sieht in meinen Augen anders aus.
Warum sollten denn SLES-Nutzer gezwungen sein, dies innerhalb dieser Zeit zu tun? Der Supportzeitraum ist auf das SP bezogen und wohl länger als ein halbes Jahr.
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..
Von Acader (Nickles-VIP) am So, 4. März 2012 um 03:49 #
Ich muss immer etwas über die Suse-User lächeln. Um Ihnen ihre Wissenslücken vor Augen zu führen, bitte ich sie immer um Beantwortung folgender Fragen: http://www.linux-kurs.eu/linux_tests.php .
Nachdem man diese verschiedenen Tests abgearbeitet hat, wird man über seinen Wissenstand sehr erstaunt sein oder auch überrascht, wie viel man im Laufe der Zeit schon wieder vergessen hat. Somit bieten diese Tests auch eine gute Möglichkeit sein Wissen wieder neu aufzupolieren. Ich kam gerade mal auf insgesamt nur 88 % . Suse-User können davon allerdings nur träumen.
> Etwas überraschend klingt dagegen die Ankündigung, Btrfs als offiziell von Suse unterstütztes Dateisystem in SLES 11 SP2 anzubieten,
das habe ich anders in Erinnerung:
Das Btrfs ist schon fertig und stabil, aber das Filesystem checkingtool wurde wohl erst vor kurzem (21.02.12?) für stabil eingestuft....
Nicht, wenn man den Kernel-Entwicklern glaubt. Hier die Beschreibung aus dem Git-Tree des Kernels:
wieso ist die Ankündigung der offiziellen Unterstützung von BTRFS überrasschend? das Wurde schon letzten Juli angekündigt. Auch wurde damals angekündigt EXT4 nicht zu unterstützen... Ab SLES12 soll BTRFS sogar das default-FS bei SLES werden. (oh - hab ich jetzt schon wieder was überaus neues verraten?
und nein - ich arbeite nicht bei suse.. ich nutze nur SLES
Schon zum zweiten Mal sind die Änderungen wirklich massiv.
Eigentlich handelt es sich nicht mehr um SLES11, sondern um eine Art "SLES 13". Eine neue Distro also.
Innerhalb von SLES11 wurd defacto von "openSUSE 11.1" auf "openSUSE 12.1" aktualisiert.
Auch ein Weg, eine Distro zukunftsfähig zu halten.
Das sehe ich ähnlich, aber negativ. SLES-Nutzer sind gezwungen innerhalb von 6 Monaten nach Erscheinen eines Servicepacks auf dieses zu wechseln. SLES bringt die aber ohne festen Zeitplan raus, und haut noch dazu massive Änderungen rein. Planbarkeit und Enterprise sieht in meinen Augen anders aus.
Warum sollten denn SLES-Nutzer gezwungen sein, dies innerhalb dieser Zeit zu tun?
Der Supportzeitraum ist auf das SP bezogen und wohl länger als ein halbes Jahr.
Keine Ahnung warum. Frag SuSE/Attachmate/Novell. Der Support für ein Servicepack endet 6 Monate nach Erscheinen des Folge-Servicepacks.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 01. Mär 2012 um 23:38.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..
Ich muss immer etwas über die Suse-User lächeln. Um Ihnen ihre Wissenslücken vor Augen zu führen, bitte ich sie immer um Beantwortung folgender Fragen: http://www.linux-kurs.eu/linux_tests.php .
Nachdem man diese verschiedenen Tests abgearbeitet hat, wird man über seinen Wissenstand sehr erstaunt sein oder auch überrascht, wie viel man im Laufe der Zeit schon wieder vergessen hat.
Somit bieten diese Tests auch eine gute Möglichkeit sein Wissen wieder neu aufzupolieren.
Ich kam gerade mal auf insgesamt nur 88 % . Suse-User können davon allerdings nur träumen.
Gottseidank gibt es ja immer noch Helden wie Dich...