News Debian erhält 5 Jahre Langzeitunterstützung

[fethomm]

Seit einiger Zeit gab es in der unabhängigen Linux-Distribution Debian eine Diskussion über Langzeitsupport. Das Sicherheitsteam der Distribution hatte bei einem Treffen im Linux-Hotel in Essen im Februar die Möglichkeit der Realisierung von Langzeitsupport bereits für die Version Debian 6 „Squeeze“ angedeutet.

Zur News: Debian erhält 5 Jahre Langzeitunterstützung

 

[Daaron]

Mein erster Gedanke war: JUHU!... und dann hab ich gesehen, dass es nur Squeeze betrifft. Zwar gibt es noch einige Squeeze-Server, aber die meisten Administratoren haben ja wohl langsam auf Wheezy aufgerüstet, eben weil der Support enden sollte.

So toll Debian grundsätzlich auch ist, insgesamt fehlt der Einsatzzweck. Für Server hätte man gern mehr als die aktuellen 2-3 Jahre Support. Für Desktops hätte man gern aktuellere Pakete.

 

[Torty]

So toll Debian grundsätzlich auch ist, insgesamt fehlt der Einsatzzweck. Für Server hätte man gern mehr als die aktuellen 2-3 Jahre Support. Für Desktops hätte man gern aktuellere Pakete.

So sehe ich das auch. Zusätzlich, kann Debian Stable je nach Konfiguration auch ziemlich flott sein. Abgesehen von den veralteten Paketen kann es dadurch für manche Desktops trotzdem recht interessant sein, für schwächere Hardware zum Beispiel. Dort kommt dann die 5-Jahre-LTS wie gerufen.

 

[fethomm]

Mein erster Gedanke war: JUHU!... und dann hab ich gesehen, dass es nur Squeeze betrifft. Zwar gibt es noch einige Squeeze-Server, aber die meisten Administratoren haben ja wohl langsam auf Wheezy aufgerüstet, eben weil der Support enden sollte.

So toll Debian grundsätzlich auch ist, insgesamt fehlt der Einsatzzweck. Für Server hätte man gern mehr als die aktuellen 2-3 Jahre Support. Für Desktops hätte man gern aktuellere Pakete.

Es steht aber auch da, dass LTS für Squeeze und Jessie wahrscheinlich übernommen wird sofern die Unterstützung nicht abreisst. Squeeze hat ja immerhin noch rund 2 Jahre normalen Support.

 

[Daaron]

Das sind viele "Wenns". Auf so etwas kann man sich nicht verlassen. Da setze ich bei Servern doch lieber wahlweise auf CentOS (7 Jahre Support und mit RHEL Unmengen an Finanzen im Hintergrund) oder Ubuntu LTS (5 Jahre, Canonical geht wohl auch nicht gleich morgen pleite)

Ich versteh eh nicht, wieso nicht Canonical den Debian LTS übernehmen. Ist ja im Endeffekt eh dasselbe Basissystem. Wenn die an Debian herumspielen, dann können sie weite Teile davon direkt in Ubuntu LTS verbraten.

 

[Moranaga]

So toll Debian grundsätzlich auch ist, insgesamt fehlt der Einsatzzweck. Für Server hätte man gern mehr als die aktuellen 2-3 Jahre Support. Für Desktops hätte man gern aktuellere Pakete.

Wenn man seine Serverfarm nicht innerhalb von sechs Monaten auf ein neues Release gehievt bekommt, ist der betreffende Migrationsprozess kaputt.

 

[engineer123]

So toll Debian grundsätzlich auch ist, insgesamt fehlt der Einsatzzweck.

Im Text steht ja schon die Antwort:
"Die Bitte nach Langzeitunterstützung für seine Veröffentlichungen wurde aus dem unternehmerischen und institutionellen Umfeld an Debian herangetragen."
Da ist Valve und andere wegen SteamOS dahinter, die machen Druck damit SteamOS mit dem Debian-Kern langfristig so sicher und stabil wie möglich läuft.

 

[Blutschlumpf]

Juhu, hab die letzten Woche alle "faulen" Kollegen verrückt gemacht, dass wir noch Systeme mit 6 haben und die Updates im Mai enden.

Generell schön, aber wieso zum Teufel Debian 6?
Ich wünschte mir, dass die das für 7 zusagen und explizit nicht für 6, sprich den im Mai beenden.
Die jetzige Variniante hilft doch nur denen, die ihr 6 nicht upgegraded haben, alle anderen bleiben im Ungewissen.
Sehr viel wichtiger wäre der LTS imho aber beim Zeitpunkt der Installation (als Gewissheit, dass man das System die nächsten 4-5 Jahre bedenkenlos nutzen kann), wird ja jetzt kaum noch einer 6 installieren.

Imho absolut die falsche Umsetzung.

 

[fethomm]

Juhu, hab die letzten Woche alle "faulen" Kollegen verrückt gemacht, dass wir noch Systeme mit 6 haben und die Updates im Mai enden.

Generell schön, aber wieso zum Teufel Debian 6?
Ich wünschte mir, dass die das für 7 zusagen und explizit nicht für 6, sprich den im Mai beenden.
Die jetzige Variniante hilft doch nur denen, die ihr 6 nicht upgegraded haben, alle anderen bleiben im Ungewissen.
Sehr viel wichtiger wäre der LTS imho aber beim Zeitpunkt der Installation (als Gewissheit, dass man das System die nächsten 4-5 Jahre bedenkenlos nutzen kann), wird ja jetzt kaum noch einer 6 installieren.

Imho absolut die falsche Umsetzung.

Das ist genau die richtige Umsetzung, da bei Debian selbst keiner bezahlt wird. Also kann Debian den Service nicht selbst tragen, da die eh immer Mangel an Leuten haben. Es wäre also unverantwortlich, das jetzt bereits am Beginn des Betriebs für kommende Releases zuzusagen. Wenn das aber mal ein Jahr oder zwei läuft und man sieht dass das gut unterstützt wird und sich auch noch trägt, wenn mal eine Unterstützer-Firma wegfällt, dann kann man das eher als ständigen Service zusagen.

 

[websurferin83]

Also ich sehe das auch so, wie die meisten meiner Vorredner:
Besser wäre es, wenn gleich bei der Veröffentlichung eine Betriebssystems klar wäre, wie lange es supportet wird, um Planungssicherheit zu haben. Alles andere ist für mich "eine Katze im Sack". Dann greife ich lieber zu CentOS, wo von vorn herein klar ist, dass es mindestens 7 Jahre Softwareupdates erhalten wird.

 

[Blutschlumpf]

@fethomm: Ansichtssache.
Wenn die mit der LTS-Zusage erst ein paar Tage vor Ende des "normalen" Supportzeitraums kommen, dann ist das imho absolut nutzlos weil jeder mit dem ernsthaften Bedürfnis nach Sicherheitsupdates eh schon auf 7 upgegraded hat oder es zumindest für die nächsten Tage anvisierte. 6 noch zu pflegen tendiert für mich dann in Richtung verschwendete Arbeitszeit.
Aber ich kann deinen Einwand aus der Anbieterseite nachvollziehen, auch wenn es für den Anwender imho zweitrangig ist.

Wenn die den "Makel" des fehlenden LTS loswerden wollen um Debian weiter zu verbreiten und es attraktiver für Nutzer machen wollen (ich kenne die Motive der Entwickler ja nicht), dann besser so, dass es dem Anwender einen Mehrwert bringt wenn er die Distribution auswählt.

Ich denke das Stichwort "Planungssicherheit" ist aus Anwedersicht hier wirklich der Schlüsselpunkt.

 

[Daaron]

Wenn man seine Serverfarm nicht innerhalb von sechs Monaten auf ein neues Release gehievt bekommt, ist der betreffende Migrationsprozess kaputt.

Schon mal daran gedacht, dass man teilweise nicht migrieren WILL? Eventuell hat man bestimmte Anwendungen, die wiederum bestimmte Versionen anderer Anwendungen/Bibliotheken voraussetzen.
Ich denke da nur an PHP-Krams, der noch auf 5.3 setzt und mit 5.4 & neuer einfach nicht will. Oder wie sieht es mit der Apache-Konfiguration aus? Wenn man die neuen Features der 2.4 nicht braucht, dann tut man sich die Umstellung der Konfiguration von 2.2 auf 2.4 (die Unterschiede sind gewaltig) nicht an.

Die Tatsache, dass jetzt endlich über LTS für Debian gesprochen wird, beweist doch, dass LTS nicht nur ein hübsches Label ist, dass man sich drauf klebt. Betreiber großer, komplexer Netzwerke wollen Planungssicherheit für ihre Software.

Oder denk mal an Office Desktops, z.B. das LiMux - Projekt. Da kannst du doch nicht mit 2 Jahren planen. Da musst du WISSEN, dass du dir erst nach 4 Jahren Gedanken um eine Migration machen musst.

Ich denke das Stichwort "Planungssicherheit" ist aus Anwedersicht hier wirklich der Schlüsselpunkt.

Ganz meine Meinung. Für Debian 6 war der Zug zwar noch nicht abgefahren, der Schaffner stand aber schon am Bahnsteig und hat den letzten Aufruf gestartet. Warum wurde hier noch ne Verzögerung nachgeschoben?

Für was entscheide ich mich jetzt, wenn ich ein neues Produktiv-System plane:
- Debian 6, das jetzt als LTS noch 2 sichere Jahre hat
- Debian 7, das ebenfalls nur 2 SICHERE Jahre hat, evtl. mit viel Glück aber LTS wird
- Ubuntu 14.04, bei dem ich garantiert 5 Jahre habe

Sorry, aber da liegt Debian weit zurück. Hätten sie direkt LTS für Debian 7 sichergestellt, dann sähe die Sache anders aus.

 

[Moranaga]

Schon mal daran gedacht, dass man teilweise nicht migrieren WILL?

Man will: Patch early, patch often. Eine Anwendung muss ein Patchlevel-Upgrade des OS überleben, oder sie ist nicht abnahme- und betriebsfähig (d.h., es ist die falsche Software). Sie muss ein ein Upgrade der Minor-Version mit geringfügigem Anpassungsaufwand überstehen, oder ... (s.o.).

Bei einem Major-Upgrade muss der Anpassungsprozess so beschaffen sein, dass er im erwähnten Zeitrahmen und zudem handhabbar bleibt.

Eventuell hat man bestimmte Anwendungen, die wiederum bestimmte Versionen anderer Anwendungen/Bibliotheken voraussetzen.

Darüber macht man sich vor der Inbetriebnahme Gedanken. Das gehört in die Konzeptionsphase eines Projekts, und sich daraus ergebende Probleme sollten allerspätestens bei der Qualitätssicherung auffallen.

Die Tatsache, dass jetzt endlich über LTS für Debian gesprochen wird, beweist doch, dass LTS nicht nur ein hübsches Label ist, dass man sich drauf klebt. Betreiber großer, komplexer Netzwerke wollen Planungssicherheit für ihre Software.

Das ist ein Euphemismus für "ich habe keinen Bock, meine Geschäftsprozesse in Ordnung zu bringen".

Planungssicherheit ist weitgehend unabhängig vom Zeitrahmen. Wenn ein Betreiber seine Migrationsprozesse innerhalb von zwei Jahren nicht in den Griff bekommt, wird ihm das auch in fünf nicht gelingen. Im Gegenteil, danach hat sich die Problematik "ich hocke auf steinalter Anwendungssoftware, die ich nicht mehr aufwandsarm migriert bekomme" hochgradig und gefährlich verschärft.

Windows XP ist, nebenbei bemerkt, ein hervorragendes Beispiel dafür, was passiert, wenn man in diese Falle tappt.

Oder denk mal an Office Desktops, z.B. das LiMux - Projekt. Da kannst du doch nicht mit 2 Jahren planen.

Wenn das nicht geht, ist ein Linux-Desktop u.U. schlicht die falsche Wahl. S.o. Ein Beispiel aus der Praxis: Der Wechsel von XP zu Windows 7 ist für eine vierstellige Anzahl von Arbeitsplätzen innerhalb von drei Monaten zu schaffen. Provokante Frage: Wenn das umgekehrt bei Linux-Desktops nicht geht, was ist dann kaputt, der Desktop oder der Prozess?

LTS ist der Versuch, ein organisatorisches Problem auf technischer Ebene zu lösen.

Für was entscheide ich mich jetzt, wenn ich ein neues Produktiv-System plane:
- Debian 6, das jetzt als LTS noch 2 sichere Jahre hat
- Debian 7, das ebenfalls nur 2 SICHERE Jahre hat, evtl. mit viel Glück aber LTS wird
- Ubuntu 14.04, bei dem ich garantiert 5 Jahre habe

Da muss man nicht lang überlegen. Da PHP erwähnt wurde, nehme ich an, dass es um Webanwendungen geht. Die will man nicht auf einem überalterten OS betreiben, LTS hin oder her. Ubuntu hat eine fragwürdige Paketqualität in vielen Bereichen und ist auch aus politischen Überlegungen heraus anzweifelbar, das möchte man auch eher nicht auf einem Server betreiben.

Ich würde Wheezy (Debian 7) wählen und die zwei Jahre dazu nutzen, meine Prozesse in Ordnung zu bringen.

Alles IMHO, und NOM, selbstverständlich.

 

[Daaron]

Man will: Patch early, patch often. Eine Anwendung muss ein Patchlevel-Upgrade des OS überleben, oder sie ist nicht abnahme- und betriebsfähig (d.h., es ist die falsche Software).

Spätestens, wenn du Webhosting für Dritte anbietest, ist DAS eben keine Option mehr. Wie ich schon sagte, PHP 5.3 - Anwendungen vs. Debian 7 (PHP 5.4)... das führt schon teilweise zu größeren Konflikten. Du kannst aber deinen Kunden (also die, die du hostest) nicht kommentarlos sagen: Ihr habt jetzt noch 2 Monate Zeit, euren Kram in Ordnung zu bringen, dann schalten wir euch kommentarlos ab. Und in 2 Jahren spätestens habt ihr wieder 2 Monate...
Das ist nicht kundenfreundlich, das ist extremer Mehraufwand.

Planungssicherheit ist weitgehend unabhängig vom Zeitrahmen. Wenn ein Betreiber seine Migrationsprozesse innerhalb von zwei Jahren nicht in den Griff bekommt, wird ihm das auch in fünf nicht gelingen.

Warum? Was ZWINGT mich dazu, z.B. Ubuntu 12.04 Server durch 14.04 zu ersetzen? Es bringt mir keinen Mehrwert, solange meine Anwendungen sauber laufen und alle Pakete gegenüber aktuellen Sicherheitslücken gepatcht sind. Statt dessen habe ich erhöhten Aufwand (alle 2 Jahre patchen statt alle 4) und erhöhte Downtimes.

Nach deiner Argumentation wäre ja Rolling Release ideal für professionelle Einsatzzwecke, schließlich ist hier nie irgend etwas "alt", nie hat man große Update-Zyklen, nie hat man Migrationen. Statt dessen hat man eben nur alle 2-3 Tage wieder mal 10 Minuten Downtime, wenn sich das halbe System umfrickelt.

Da PHP erwähnt wurde, nehme ich an, dass es um Webanwendungen geht. Die will man nicht auf einem überalterten OS betreiben, LTS hin oder her.

Der Zaubertrick ist: Ein LTS, insbesondere mit guten Backports, IST nicht überaltert oder gar veraltet. Es ist genau so sicher wie das neue Release, nur ohne dessen Geburtsschmerzen. Ein vollkommen gepatchter Apache 2.2 steht einem Apache 2.4 in Sicherheit und Geschwindigkeit in nichts nach, es fehlen nur einige unbedeutende neue Features.

Nochmal: Wenn die aus LTS resultierende Planungssicherheit keine Relevanz hätte: Erklär mir SLES, RHEL, CentOS, Ubuntu LTS, den Schritt zu Debian LTS.

Ubuntu hat eine fragwürdige Paketqualität in vielen Bereichen und ist auch aus politischen Überlegungen heraus anzweifelbar, das möchte man auch eher nicht auf einem Server betreiben.

Fragwürdige Paketqualität? Hier musst du mal konkrete Beispiele und Beweise bringen. Andernfalls bist du auch nur so ein Sabbelkopf.
Die "politischen Überlegungen"... Ja welche betreffen Server denn? Die Amazon-Integration in Unity kann es kaum sein. MIR kann es auch nciht sein, wobei ich persönlich MIR sogar für eine echt gute Idee halte.

 

[Blutschlumpf]

@Moranaga: Selten so einen weltfremden Mist gelesen.
Wirf mal das Buch "perfekte Welt" weg und begib dich in die Realität.

PHP z.B. wirft hin und wieder weit verbreitete Funktionen ohne Not raus. Eine Anwendung, die vor 3 Jahren einwandfrei lief und damals perfekt geschrieben war (sprich ohne Funktionen auf der Streichliste), läuft heute vielleicht nicht mehr weil jemand der Meinung war ne PHP-Funktion durch eine nahezu gleiche mit nem minimal veränderten Namen und evtl. leicht veränderter Parameter zu ersetzen (ich denk da z.B. an den Schwachsinn mit ereg und preg).
Das ist dann häufig keine Frage des Geschäftsprozesses, sondern eine finanzielle. Nicht jede Firma hat Ressourcen wie IBM und kann da hunderte Leute für solchen belanglosen Bullshit abstellen.

Darüber macht man sich vor der Inbetriebnahme Gedanken.

Klar, du weißt ja heute schon was sich in 3 Jahren bei Library xy ändert.

Zudem wird 99,x% der Software auf dem Planeten ja vor der Benutzung Zeile für Zeile vom Benutzer durchgearbeitet und dahingehend überprüft ob da ggf. beim Upgrade des OS in ein paar Jahren Fehler auftreten könnten.
Weiterhin gibt es ja auch keine Software auf dem Markt, für die es keinen gleichwertigen Ersatz gibt, der für die Ewigkeit funktioniert.

 

[DiamondLucy]

Also die News vom 14.3.2014 von unten besagt dass auch für Whezzy LTS geplant, bzw. schon daran gearbeitet wird.
Sehr lobenswert, ich verwende auf allen Rechnern Debian 7.4.
War mir aber irgendwie klar dass das jetzt mal kommt, sehr gut!

Werde mir Jessie auch erst draufmachen wenn es ein Zeit lang stable ist und vielleicht schon ein 8.1 Version draussen ist.


Debian Developers Are Preparing an LTS Version for "Wheezy"

he Debian developers are considering the release of an LTS (long-term support version) for their Wheezy branch, but nothing has been settled so far and they are looking for people with the available time and energy for such a project.

The most prolific distributions out there that do provide long-winded LTS versions are Red Hat Enterprise Linux and Ubuntu. RHEL 6 was released in 2010 and will have support until 2023, and Ubuntu usually has a fix period of five years.

It's not surprising that Debian developers would want to provide something similar, although no specific periods have been determined as of yet.

“At the moment it seems likely that an extended security support timespan for squeeze is possible. The plan is to go ahead, sort out the details as as it happens, and see how this works out and whether it is going to be continued with wheezy. The rough draft is that updates will be delivered via a separate suite (e.g. squeeze-lts), where everyone in the Debian keyring can upload in order to minimise bottlenecks and allow contributions by all interested parties," said Moritz Muehlenhoff in the official mailing list.

If this LTS release happens, it will be for Debian 7.0.x (Wheezy), which has already had a number of upgrades. Now, before getting excited about the possibility of an LTS release, you have to know that it doesn't mean that the entire operating system will be overhauled for a few years.

Just like in the case of Red Hat Enterprise Linux and Ubuntu, the developers usually provide security upgrades for various problems that are found from time to time, and if the situation arises, a few Linux kernel updates are also promoted to keep the operating system in line with the hardware releases.

All the plans for a Debian LTS release are now in the beginning stages, so it will take some time for everything to get sorted out. One of the most important components is the human factor. Both Canonical and Red Hat pay their developers to maintain the system, but Debian is not organized in that manner.

One the reasons why Ubuntu and RHEL are so popular and used (in different mediums) is this LTS capability that allows users to feel safe when using an OS, even a few years after the initial launch. It also helps business with consistency over long periods.

If Debian gets an LTS version, we will

Quelle:
http://news.softpedia.com/news/Debi...LTS-Version-for-quot-Wheezy-quot-432130.shtml

 

[mensch183]

Klar, du weißt ja heute schon was sich in 3 Jahren bei Library xy ändert.

Normalerweise muß man sowas nicht wissen, weil inkompatible Bibliotheken normalerweise via Versionen identifizierbar und vom nutzenden Programm gezielt, d.h. versionspezifisch nutzbar sind. Es ist allein der Gammeligkeit der PHP-Welt geschuldet, ständig inkompatible Versionen in die freie Wildbahn zu entlassen, ohne ein _elegantes_ Verfahren zum Parallelbetrieb anzubieten.

 

[Blutschlumpf]

Und ? Er sagt doch aus, dass es vermeidbar sei auf eine Anwendung zu setzen, die ein dist-upgrade nicht verträgt.
Wenn du dein Programm auf eine Version der library festlegst, kann es sein, dass die im nächsten Release nicht mehr drin ist.
Wenn du es nicht machtst, kann es zu Inkompatibilitäten kommen, die ein Upgrade der Software verlangen, schließlich kann die Info "Version xy ist inkompatibel" in der Ursprungssoftware ja noch nicht drin sein.

 

[Moranaga]

@Daaron: Gerade im Webhosting für Dritte müssen Anwendungen Patchlevel-Upgrades überstehen. In Zeiten nach Heartbleed lässt sich die Notwendigkeit von Sicherheitsupdates selbst dem stursten Kunden begreiflich machen.

Eine vernünftig gebaute PHP-Anwendung ist mit vertretbarem Aufwand upgradefähig. Ansonsten ist es, wie bereits gesagt, die falsche Wahl.

Warum? Was ZWINGT mich dazu, z.B. Ubuntu 12.04 Server durch 14.04 zu ersetzen?

Der Kunde. Und zwar der, der neuere Software und Feature XYZ "braucht". Und zwar "unbedingt und gestern". Noch nie erlebt?

Nach deiner Argumentation wäre ja Rolling Release ideal für professionelle Einsatzzwecke, schließlich ist hier nie irgend etwas "alt", nie hat man große Update-Zyklen, nie hat man Migrationen. Statt dessen hat man eben nur alle 2-3 Tage wieder mal 10 Minuten Downtime, wenn sich das halbe System umfrickelt.

Im Prinzip wäre ersteres richtig, wenn die Wechselzyklen genügend lang und Test-Suites vollständig wären. In der Praxis verursachen RRs-OS mehr Probleme, als sie zu lösen versprechen, sind also keine wahre Alternative. Die Welt besteht allerdings zum Glück nicht nur aus Schwarz und Weiß.

Eine Downtime von >20 Minuten pro Woche ist aber kein Beleg für die Untauglichkeit von RRs, sondern dafür, dass ein Upgrade-Prozess kaputt ist. In dieser Zeit deployt man vier produktionsreife Maschinen neu, inkl. Abnahme und Doku. Es gibt keine Entschuldigung für derart hohe Ausfallzeiten.

Zu LTS: Der Kunde bestimmt, ob die Absenz neuer Features "unbedeutend" ist.

LTS ist nicht gleich Planungssicherheit. Ersteres ist ein technischer Prozess, letzteres eine betriebswirtschaftliche Größe. LTS kann ein Bestandteil von Geschäftsprozessen sein, die Planungssicherheit herstellen, ist aber weder Synonym noch Garant dafür.

Ein Laden, der seinen Migrationsablauf in zwei Jahren nicht auf die Kette kriegt, schafft das auch in drei nicht. Oder in vier. Oder in fünf. Das ist keine Frage der Zeitspanne mehr in dieser Größenordnung, sondern eine der Organisation.

Weshalb SLES, RHEL usw.? Weil es ein Markt ist, selbstverständlich. Der von genau den Läden belebt wird, von denen just die Rede war.

Zur Paketqualität: Ich muss überhaupt nichts. Wenn der Gegenbeweis erbracht ist, reden wir weiter. Ein Qualitätsmerkmal unter vielen ist beispielsweise die Absenz von Lintian overrides.

Das ist dann häufig keine Frage des Geschäftsprozesses, sondern eine finanzielle.

Das erstaunt mich jetzt aber. Wo ist der Unterschied?

Nicht jede Firma hat Ressourcen wie IBM und kann da hunderte Leute für solchen belanglosen Bullshit abstellen.

Wir reden hier schon von professionellen Anbietern und nicht von einem Studenten mit MacBook und Gewerbeschein, der seine Dienstleistung aus dem heimischen Schlafzimmer heraus anbietet. Oder?

Genau die Haltung unterscheidet letzteren nämlich von ersteren.

Klar, du weißt ja heute schon was sich in 3 Jahren bei Library xy ändert.

Ich weiß etwas erheblich viel wichtigeres: Ich weiß, dass sie sich ändern wird.

Dieses Wissen kann man selbstverständlich ignorieren. Man kann auch den Wandel von Märkten ignorieren. Man kann ebenfalls ignorieren, dass die Evolution Agilität und Flexibilität bevorzugt.

LTS ist eine Krücke, nicht die Lösung eines Problems.

 

[Daaron]

@Daaron: Gerade im Webhosting für Dritte müssen Anwendungen Patchlevel-Upgrades überstehen. In Zeiten nach Heartbleed lässt sich die Notwendigkeit von Sicherheitsupdates selbst dem stursten Kunden begreiflich machen.

Heartbleed und andere Sicherheitsupdates ändern aber genau GAR NICHTS.
Ich kann kistenweise Kernel-Updates und PHP Security Patches einspielen, zusammen mit ner neuen OpenSSL-Version, nem Security-Fix für MySQL und sonstwas noch alles. Nichts davon beeinflusst die Funktionstüchtigkeit von Legacy-Software. Und WARUM tut sie das nicht?
Genau: Weil es LTS ist, und weil bei LTS sicher gestellt wird, dass man innerhalb eines Major Releases bleibt (und somit 100% kompatibel) und nur Bugs behoben werden.

Ubuntu 12.04 hat PHP 5.3, und es wird noch PHP 5.3 haben wenn es 2017 in die Mottenkiste wandert. Bis dahin ändert sich genau eins: die hinterste Zahl in der Version, die die verschiedenen Security Fixes wiederspiegelt.

Eine vernünftig gebaute PHP-Anwendung ist mit vertretbarem Aufwand upgradefähig. Ansonsten ist es, wie bereits gesagt, die falsche Wahl.

Wenn du damals dein Programm mit "ereg" für RegExp geschrieben hast, dann musst du bei einem Upgrade der PHP-Version zwingend jede Stelle auf "preg" umschreiben. Es war damals NICHT falsch, "ereg" zu verwenden. Es war sogar ziemlich lange die einzige Lösung, bis "preg" hinzu kam.
Warum also soll der Kunde seine ganze PHP-Anwendung unnötig umschreiben, wenn der Server problemlos über viele Jahre stabil und sicher betrieben werden kann, OHNE dem Kunden solche Probleme ans Bein zu nageln?

Kundenfreundlich ist, was dem Kunden Zeit & Geld spart.

Der Kunde. Und zwar der, der neuere Software und Feature XYZ "braucht". Und zwar "unbedingt und gestern". Noch nie erlebt?

Tatsächlich: Nein.
Denkst du wirklich, irgend jemand braucht unbedingt PHP 5.4 oder 5.5? Jedes der üblichen PHP-Systeme (CMS, Shop,...) läuft auf 5.3.

Zu LTS: Der Kunde bestimmt, ob die Absenz neuer Features "unbedeutend" ist.

WIR hosten für UNSERE Kunden UNSERE Entwicklungen, also entscheiden WIR, was für Features wir benötigen und welche nicht. Und tatsächlich, ich habe noch NIE PHP 5.4 benötigt, genauso wenig ultra-neue MySQL-Releases oder gar Apache 2.4.

LTS ist nicht gleich Planungssicherheit.

Es ist aber ein wichtiger Aspekt, um endlich mal sagen zu können: SO machen wir es HEUTE, und haben somit für VIELE Jahre unsere Ruhe.

Zur Paketqualität: Ich muss überhaupt nichts. Wenn der Gegenbeweis erbracht ist, reden wir weiter.

Warum? Du behauptest, die Qualität wäre schlecht. Du stellst eine Behauptung auf, also liegt die Beweislast bei dir.

Es gibt verdammt viele Ubuntu Server, die stabil wie ein Fels laufen. Die Betreiber sind sicher nicht deiner Meinung, also bist du definitiv im Zugzwang.

Wir reden hier schon von professionellen Anbietern und nicht von einem Studenten mit MacBook und Gewerbeschein, der seine Dienstleistung aus dem heimischen Schlafzimmer heraus anbietet. Oder?

Kleiner Tip: "Professionell" heißt, die Person verdient damti ihren Lebensunterhalt. Vergleiche dazu mal das englische Wort "profession"....

Und jetzt denk mal eine kleine Firma, die eben KEIN Personal dafür abstellen kann, alle Furze lang ihre Maschinen umzustricken. Dämmerts? 1x alle 5 oder 7 Jahre um die Scheiße kümmern ist viel billiger als sich alle 2 Jahre darum zu kümmern.

Ich weiß etwas erheblich viel wichtigeres: Ich weiß, dass sie sich ändern wird.

Das hilft dir genau WIE?
Du schreibst heute Software für die Bibliotheken von heute. In 1-2 Jahren ändern sich die Bibliotheken. Du weißt, dass sie sich ändern, aber nicht wie. Kannst du heute also schon so schreiben, dass du keine Probleme kriegen wirst? NÖÖÖÖÖ!