Die Version nicht als LTS herauszugeben ist doch eine sinnvolle Entscheidung wenn gerade erst KDE4 integriert wurde. Da sollte man lieber eine Version später als LTS bringen.
Aber bei einem Desktopsystem wohl nicht unbedingt notwendig. In Unternehmen sehr wohl. Dort wird nicht jedes halbe Jahr ein Dist-Upgrade durchgeführt.
Für Server gibt es Debian mit dem entsprechenden langen Support. Der war gut. Wenn sich Lenny nicht verzögert, gibts für Etch gerade einmal insgesamt 2,5 Jahre Support. Wer heute Etch installiert, muss in weniger als 2 Jahren upgraden, sonst gibts keine Security-Updates. Für Enterprise-Distributionen (RHEL, SLES, Ubuntu LTS Server) gibt es mindestens 5 Jahre Support und längere zeitliche Überschneidungen der Releases, damit man nicht im Worst-Case nur etwa 1 Jahr Security-Updates erhält.
Von vicbrother am Fr, 21. Dezember 2007 um 15:37 #
Und warum sind fünf Jahre Support nun so toll? Weil MS einen fünf Jahresrythmus bei der Veröffentlichung von Betriebsystemen hat oder weil Hardwareverträge solange laufen? Also ich finde zehn Jahre Support klasse, aber 2,5 Jahre sind doch auch gut.
Und warum sind fünf Jahre Support nun so toll? Weil PCs über 3 Jahre abgeschrieben werden und man so noch etwas Puffer hat.
Also ich finde zehn Jahre Support klasse, aber 2,5 Jahre sind doch auch gut. Die 2,5 Jahre hast du aber nur, wenn du Etch direkt ab dem Release-Datum einsetzt. Wenn du heute Debian stable installierst, sind es nur noch 21 Monate. Und ab Mitte des kommenden Jahres wäre es nur noch knapp über 1 Jahr, innerhalb dessen man ein komplettes Distributionsupgrade machen muss. Diese Upgrades kosten den Admin Zeit. Und Zeit ist Geld.
Von vicbrother am Fr, 21. Dezember 2007 um 17:56 #
In Südafrika, Amerika und Deutschland gilt die gleiche Abschreibungsregelung? Das finde ich ja interessant...
Mir ging es eigentlich um die Frage, wer das mal so festgelegt hat und welche Gründe es damals dafür gab. Ich denke es ist eine Festlegung von MS und wird einfach so übernommen. M.E. kann man Linux auf Servern viel länger betreiben und kann so aicj den Schweinezyklus der Entscheidung "Bleiben wir bei Linux oder nutzen wir Windows, der Support läuft ja nun aus" viel besser durchbrechen, wenn man antizyklische Supportzeiten hat. Aber natürlich kann man andere Supportzeiträume über Dritte einkaufen, das stelle ich nicht in Frage
In Südafrika, Amerika und Deutschland gilt die gleiche Abschreibungsregelung? Das finde ich ja interessant... Wen interessiert Südafrika, wen Amerika?
Ich denke es ist eine Festlegung von MS und wird einfach so übernommen. Bei Microsoft ist der Supportzeitraum noch viel länger, für Windows XP Professional z.B. bei 14 Jahren.
M.E. kann man Linux auf Servern viel länger betreiben und kann so aicj den Schweinezyklus der Entscheidung "Bleiben wir bei Linux oder nutzen wir Windows, der Support läuft ja nun aus" viel besser durchbrechen, wenn man antizyklische Supportzeiten hat. Ach, du meinst, mit "Wir releasen, wenn wir Lust dazu haben, wann der Support ausläuft, können wir auch nicht vorher sagen" kommt man in den Unternehmen besser an? RHEL gibt es etwa alle 18 Monate in einer neuen Major-Version und jede wird 5 Jahre supported. So hat man also immer eine Möglichkeit zum Absprung und dann noch mindestens 3 Jahre Security-Updates für das zu dem Zeitpunkt aktuelle Release durch den Distributor.
Niemand hindert dich daran nach 2,5 Jahren weiter Etch einzusetzen und dir Support von einem entsprechenden Anbieter zu kaufen, der kann dann sogar dank Freier Software weit über 5 Jahre gehen!
Niemand hindert dich daran nach 2,5 Jahren weiter Etch einzusetzen und dir Support von einem entsprechenden Anbieter zu kaufen Doch, die Wirtschaftlichkeit.
der kann dann sogar dank Freier Software weit über 5 Jahre gehen! Und das geht bei RHEL oder Ubuntu LTS Server etwa nicht?
Ingmar schrieb: Die Version nicht als LTS herauszugeben ist doch eine sinnvolle Entscheidung wenn gerade erst KDE4 integriert wurde. Da sollte man lieber eine Version später als LTS bringen.
Jain! Den eine Verschiebung des LTS Zyklus zu dem von Ubuntu bedeutet das man eben auch das Basissystem komplett warten muss und nicht auf Ubuntu zurückgreifen kann. Denn warum sollte Ubuntu außerhalb seiner LTS-Releases das Basissystem länger unterstützen?
Wie bereits an anderer Stelle der Artikeldiskussion erwähnt war das imho ein falscher Schritt. Man hätte ohne weiteres ein Kubuntu 8.04 LTS mit KDE 3.5 und einen Zusatzrepository mit KDE 4 das schon in der Sources.list steht bringen können ohne bei KDE 4 gegenüber anderen Distributionen ins Hintertreffen zu geraten. Und genau dieses 'ins Hintertreffen geraten' war ja offenbar der Grund warum man den Schritt mit den man jetzt die Community konfrontiert hat gemacht hat. Das dabei die Interessen des Großteils der Community (nämlich ein einfach zu benutzendes, stabiles und ausgereiftes System zu bekommen) dabei mit Füßen getreten wird war offenbar bei der Entscheidung egal.
Die Version nicht als LTS herauszugeben ist doch eine sinnvolle Entscheidung wenn gerade erst KDE4 integriert wurde. Da sollte man lieber eine Version später als LTS bringen.
Grüße
Ingmar
Und du meinst das wird passieren?
Wo wäre das Problem gewesen die Variante mit KDE 3.5.x als LTS herauszubringen oder den neuen LTS um ein halbes Jahr zu verschieben?
Aber bei einem Desktopsystem wohl nicht unbedingt notwendig.
Für Server gibt es Debian mit dem entsprechenden langen Support.
In Unternehmen sehr wohl. Dort wird nicht jedes halbe Jahr ein Dist-Upgrade durchgeführt.
Für Server gibt es Debian mit dem entsprechenden langen Support.
Der war gut. Wenn sich Lenny nicht verzögert, gibts für Etch gerade einmal insgesamt 2,5 Jahre Support. Wer heute Etch installiert, muss in weniger als 2 Jahren upgraden, sonst gibts keine Security-Updates.
Für Enterprise-Distributionen (RHEL, SLES, Ubuntu LTS Server) gibt es mindestens 5 Jahre Support und längere zeitliche Überschneidungen der Releases, damit man nicht im Worst-Case nur etwa 1 Jahr Security-Updates erhält.
Weil PCs über 3 Jahre abgeschrieben werden und man so noch etwas Puffer hat.
Also ich finde zehn Jahre Support klasse, aber 2,5 Jahre sind doch auch gut.
Die 2,5 Jahre hast du aber nur, wenn du Etch direkt ab dem Release-Datum einsetzt. Wenn du heute Debian stable installierst, sind es nur noch 21 Monate. Und ab Mitte des kommenden Jahres wäre es nur noch knapp über 1 Jahr, innerhalb dessen man ein komplettes Distributionsupgrade machen muss. Diese Upgrades kosten den Admin Zeit. Und Zeit ist Geld.
Mir ging es eigentlich um die Frage, wer das mal so festgelegt hat und welche Gründe es damals dafür gab. Ich denke es ist eine Festlegung von MS und wird einfach so übernommen. M.E. kann man Linux auf Servern viel länger betreiben und kann so aicj den Schweinezyklus der Entscheidung "Bleiben wir bei Linux oder nutzen wir Windows, der Support läuft ja nun aus" viel besser durchbrechen, wenn man antizyklische Supportzeiten hat.
Aber natürlich kann man andere Supportzeiträume über Dritte einkaufen, das stelle ich nicht in Frage
Wen interessiert Südafrika, wen Amerika?
Ich denke es ist eine Festlegung von MS und wird einfach so übernommen.
Bei Microsoft ist der Supportzeitraum noch viel länger, für Windows XP Professional z.B. bei 14 Jahren.
M.E. kann man Linux auf Servern viel länger betreiben und kann so aicj den Schweinezyklus der Entscheidung "Bleiben wir bei Linux oder nutzen wir Windows, der Support läuft ja nun aus" viel besser durchbrechen, wenn man antizyklische Supportzeiten hat.
Ach, du meinst, mit "Wir releasen, wenn wir Lust dazu haben, wann der Support ausläuft, können wir auch nicht vorher sagen" kommt man in den Unternehmen besser an?
RHEL gibt es etwa alle 18 Monate in einer neuen Major-Version und jede wird 5 Jahre supported. So hat man also immer eine Möglichkeit zum Absprung und dann noch mindestens 3 Jahre Security-Updates für das zu dem Zeitpunkt aktuelle Release durch den Distributor.
Doch, die Wirtschaftlichkeit.
der kann dann sogar dank Freier Software weit über 5 Jahre gehen!
Und das geht bei RHEL oder Ubuntu LTS Server etwa nicht?
Jain! Den eine Verschiebung des LTS Zyklus zu dem von Ubuntu bedeutet das man eben auch das Basissystem komplett warten muss und nicht auf Ubuntu zurückgreifen kann. Denn warum sollte Ubuntu außerhalb seiner LTS-Releases das Basissystem länger unterstützen?
Wie bereits an anderer Stelle der Artikeldiskussion erwähnt war das imho ein falscher Schritt. Man hätte ohne weiteres ein Kubuntu 8.04 LTS mit KDE 3.5 und einen Zusatzrepository mit KDE 4 das schon in der Sources.list steht bringen können ohne bei KDE 4 gegenüber anderen Distributionen ins Hintertreffen zu geraten. Und genau dieses 'ins Hintertreffen geraten' war ja offenbar der Grund warum man den Schritt mit den man jetzt die Community konfrontiert hat gemacht hat. Das dabei die Interessen des Großteils der Community (nämlich ein einfach zu benutzendes, stabiles und ausgereiftes System zu bekommen) dabei mit Füßen getreten wird war offenbar bei der Entscheidung egal.
Grüße
Sascha