FreeBSD 7.2 EOL am 30.06.10

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
Nur ein kurzer Hinweis: FreeBSD 7.2 erreicht am 30.06 - also am Ende des Monates - seinen EOL-Status. Das bedeutet, dass es keinerlei Sicherheitsupdates durch das FreeBSD Security Team geben wird. Ports werden das Release weitgehend weiterunterstützen, da RELENG_7 unterstützt bleibt. Allen Nutzern wird geraten auf FreeBSD 7.3 zu aktualisieren, was noch bis zum 31.03.2012 unterstützt werden wird.
 
Leider ist das so.
Sie Tatsache, dass ein letztes Release eines Zweiges nicht mindestens weitere 12 Monate unterstuetzt wird, hat FreeBSD schon Schaden bereitet. Gemeint ist nicht unbedingt ein technischer Schaden, sondern ein weniger guter Ruf und somit ein geringere Akzeptanz im professionellen Bereich.
Hat man (der ISP, das Systemhaus, die Organisation oder auch der Kunde der genannten drei) die Wahl zwischen einem Esel mit 7 Jahren Support (Updates/Patches) oder einem Rennpferd mit einigen Jahren weniger Unterstützung, entscheidet man sich nicht ganz unberechtigt fuer den Esel. Ich heisse diesen Umstand nicht unbedingt fuer gut und versuche oftmals diese Entscheidung mit der Hilfe anderer Argumente zu beeinflussen, kann und muss die Wahl des Kunden aber akzeptieren.
Wenn man bedenkt wie lang und entspannt damals die Zeitspanne zwischen den spaeten 4-current und 4.11 gewesen ist. Einfach eine sehr schoene Sache.
 
j_t schrieb:
Sie Tatsache, dass ein letztes Release eines Zweiges nicht mindestens weitere 12 Monate unterstuetzt wird, hat FreeBSD schon Schaden bereitet.
Zum Vergrößern anklicken....
Jeder Zweig wird 24 Monate über das letzte Release hinaus unterstützt. Das letzte Release aus RELENG_7 war 7.3, dessen Unterstützung erst am 31.03.2012 auslaufen wird. 7.2 hingegen war ein Release mit gerader Versionsnummer und nicht das letzte des Zweiges, hat also nur 12 Monate Unterstützung. Daher ergibt sich: Erscheinungsdatum 04.05.2009 -> Ende nächster Monate 30.06.2009 + 12 Monate = 30.06.2010 EOL.
 
Zuletzt bearbeitet:
Das Problem liegt meiner Meinung nach auch in der Nomenklatur als neues »Release«. Innerhalb einer Major-Release-Generation zu upgraden, ist ungefähr genauso viel Aufwand wie das Einspielen eines Service Packs/Updates bei SLES oder RHEL (und der 7-Jahre-Support gilt da ja auch nur z.B. für die ganze 5er oder 4er-Generation). Also immerhin vier bis fünf Jahre Support bei FreeBSD. Dazu kommt, daß *BSD wohl wesentlich weniger administrativen Aufwand bedeutet. Allein der halbjährliche lokale Root-Exploit im Linux-Kernel … Wenn man da nicht permanent aufpaßt wie ein Schießhund, dann gute Nacht.
 
j_t schrieb:
Sie Tatsache, dass ein letztes Release eines Zweiges nicht mindestens weitere 12 Monate unterstuetzt wird, hat FreeBSD schon Schaden bereitet. Gemeint ist nicht unbedingt ein technischer Schaden, sondern ein weniger guter Ruf und somit ein geringere Akzeptanz im professionellen Bereich.
Zum Vergrößern anklicken....

In Anbetracht der begrenzten Entwicklerressourcen hat FreeBSD doch nicht viel Wahl - entweder Releases sehr lange unterstützen oder mehr Neuentwicklung.

j_t schrieb:
Hat man (der ISP, das Systemhaus, die Organisation oder auch der Kunde der genannten drei) die Wahl zwischen einem Esel mit 7 Jahren Support (Updates/Patches) oder einem Rennpferd mit einigen Jahren weniger Unterstützung, entscheidet man sich nicht ganz unberechtigt fuer den Esel. Ich heisse diesen Umstand nicht unbedingt fuer gut und versuche oftmals diese Entscheidung mit der Hilfe anderer Argumente zu beeinflussen, kann und muss die Wahl des Kunden aber akzeptieren.
Zum Vergrößern anklicken....

In dem Bereich hatte ich bislang den Eindruck, dass es meistens der Inhouse-Admin eines kleinen Unternehmens ist, der FreeBSD einsetzt und pflegt - dort spielt die Supportdauer nicht die große Rolle. Solange der Betrieb läuft, interessiert es eh keinen.

Seit "Windows ist so instabil und unzuverlässig" nicht mehr zieht und man über Linux im Handelsblatt lesen kann, ist es schwer, überzeugende Argumente für FreeBSD zu finden - unabhängig von etwaigen technischen Vorteilen.

j_t schrieb:
Wenn man bedenkt wie lang und entspannt damals die Zeitspanne zwischen den spaeten 4-current und 4.11 gewesen ist. Einfach eine sehr schoene Sache.
Zum Vergrößern anklicken....

Das war eine andere Zeit - Windows NT war eine Krücke, Windows 2000 erst frisch auf dem Markt, Linux noch in den Kinderschuhen und ein Server mit Solaris oder AIX unbezahlbar.
 
Die BSD-Welt hat leider keine Lobby in der breiten IT-Öffentlichkeit. Und wenn ich mir mal die Massenmedien im IT-Sektor ansehe, und damit meine ich die ohne "Sachverstand" (also PC-Welt, Computer-Bild, PC Praxis, Com!, etc.), dann ist Linux, und dann besonders immer wieder die Ubuntu-Familie oder gelegentlich auch mal OpenSuSE das Thema. Sehr sehr selten kommt auch mal die BSD-Welt vor, aber irgendwie schmeißen die das medial immer "zum Pinguin", womit die Zielgruppe dann ein BSD einfach nur für ein Linux-Derivat hält. Die Publikationen von Linux New Media hingegen (EasyLinux, LinuxUser, Linux-Magazin sowie deren Sonderhefte) trennen das durchaus. Im aktuellen Admin-Sonderheft zum Beispiel gibts nen Artikel über FreeNAS und es wird nicht um Linux erklärt. Selbst der Heise-Verlag macht einen für mich immer wieder ärgerlichen Fehler und druckt in der c't eventuelle News aus der BSD-Welt unter "Linux" ab. Ich bin jetzt zwar nicht so BSD-affin, aber es ärgert mich doch sehr ...
 
@Yamagi

Mir ist voellig klar, wie sich die Supportzeiten herleiten udnd das 7.3 noch eine gewisse Weile supportet werden wird. Vergleiche ich den Supportzeitraum eines Releases von FreeBSD mit dem dem von Rothut, sehe ich aber genau die oben beschriebenen Probleme. _Weitere_ 12 Monate mindestens waeren eine wirklich feine Sache. Und natuerlich ist es die vergleichsweise geringe Manpower die Ursache.
Es ist doch so: Eine Vielzahl der typischen Server im ISP Umfeld braucht nicht staendig den allerneuesten Apache mit der letzten Testversion von PHP (was ist bei PHP eigentlich keine Alpha...?) und man freut sich den Server zu installieren und ueber lange Jahre hinweg auf dem Releasestand zu belassen. Auch das OS selbst (Kernel & Userland) __muss__ nicht immer der letzte Schrei sein. Mit FreeBSD ist dieses Szenario eher schwrierig zu verwirklichen.
Das ist nur meine Sicht der Dinge, welche sich ueber die letzten Jahre allerdings stark verfestigt hat und daher kann ich nur hoffen, dass sich die Situation doch noch von der aktuellen Schnelllebigkeit weg hin zu mehr Nachhaltigkeit verbessert.
 
Tja, das gute ist, FreeBSD Support kann man auch von einem freien Berater kaufen. Was spricht im professionellen Umfeld dagegen?! Oft ist der persönliche Support sowieso unschlagbar. Und es muss nicht mal teuer sein. Ein Kunde von mir hat für ein kommerzielles Unix die letzten zwei Jahre 4 kEUR bezahlt, wobei das meiste davon Anpassungen waren, die im Herstellersupport sowieso nicht drin gewesen wären. Der Herstellersupport hätte in der Zeit fünfstellig gekostet...
 
@ed1949

Ich vermisse in deinem Post jeden Bezug zum Thema. Selbstverstaendlich kann man auch fuer FreeBSD externen Support einkaufen. Ja und?
Wenn das jetzt wieder ein klassicher Versuch sein sollte irgendwie in die weltfremde Richtung zu lenken, das es ja schliesslich Opensource ist und daher jeder selbst seine Patches erstellen kann, dann bitte ich um Vergebung mich ueberhaupt zu Wort gemeldet zu haben...
 
j_t schrieb:
... und man freut sich den Server zu installieren und ueber lange Jahre hinweg auf dem Releasestand zu belassen. Auch das OS selbst (Kernel & Userland) __muss__ nicht immer der letzte Schrei sein. Mit FreeBSD ist dieses Szenario eher schwrierig zu verwirklichen. ...
Zum Vergrößern anklicken....
Kann ich nicht nachvollziehen. Einfach stehen und laufen lassen geht doch prima, egal ob es Support gibt oder nicht.

Das wirklich tolle ist doch, dass der Update Pfad zu aktuellen Versionen dann trotzdem noch vorhanden ist. Man könnte auch jetzt noch Problemlos ein 5.3er System auf den 8er oder 9er Zweig updaten.
 
j_t schrieb:
@ed1949

Ich vermisse in deinem Post jeden Bezug zum Thema. Selbstverstaendlich kann man auch fuer FreeBSD externen Support einkaufen. Ja und?
Zum Vergrößern anklicken....

OK, Zusammenfassung meiner Meinung: Der EOL ist im professionellen Bereich nicht wichtig. Man kann hier die Rechner ohne Probleme auf einem alten Releasestand lassen, da der Admin sich um die Rechner kümmert. Im Hobby-Bereich ist es kein Drama auf 7.3 oder gleich auf 8 zu gehen - oder eben auch den alten Stand zu lassen. Und natürlich verdient in der Realität nicht alles was sich professionell nennt, diese Bezeichnung - das ist aber wirklich OT.

Damit ist EOL einfach eine interessante Notiz wie z.B. ein neues Release oder ein Security Advisory. Nicht mehr und nicht weniger.
 
Kamikaze schrieb:
Kann ich nicht nachvollziehen. Einfach stehen und laufen lassen geht doch prima, egal ob es Support gibt oder nicht.

Das wirklich tolle ist doch, dass der Update Pfad zu aktuellen Versionen dann trotzdem noch vorhanden ist. Man könnte auch jetzt noch Problemlos ein 5.3er System auf den 8er oder 9er Zweig updaten.
Zum Vergrößern anklicken....

Wobei es wesentlich einfacher ist, die Kiste neu aufzusetzen, als hier den Weg 5->6->7->8(->9) zu gehen.
 
Ich habe die Kiste noch nie neu aufgesetzt. Meistens geht ja auch der direkte Weg über mehrere Versionen hinweg. Wenn das nicht klappt merkt man das ja schon beim Kompilieren.
 
Dito, ist schon interessant, wenn man dann im /root oder anderen Ordnern irgendwelche Dateien aus 1994 oder so findet. Neuaufsetzen ist etwas für Warmduscher :D
 
Kamikaze schrieb:
Ich habe die Kiste noch nie neu aufgesetzt. Meistens geht ja auch der direkte Weg über mehrere Versionen hinweg. Wenn das nicht klappt merkt man das ja schon beim Kompilieren.
Zum Vergrößern anklicken....
Mache ich genauso. Ich installiere nur beim Hardware-Wechsel neu, ansonsten wird aktualisiert. Mit meiner alten Desktop-Gurke habe ich es von 5.1 bis 7.1 gemacht und mit der Jetzigen von 7.1 bis aktuell 8.0 und da das Chefchen noch keine neue Hardware rausrückt, werde ich das auch noch so weiter machen.
Bei Servern sowieso. Habe noch nie Probleme damit gehabt.

Und wenn man mergemaster mittels mergemaster.rc richtig konfiguriert, geht so ein Update ruckzuck.

c.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben