Neues Support-Modell für FreeBSD

Yamagi

Possessed With Psi Powers
Teammitglied
Hallo,
in den letzten Tagen war hier im Forum bereits öfter Thema, dass das FreeBSD Projekt sein Support-Modell grundlegend umstellen möchte. Das derzeitige Schema Releases mit gerader Endung ein Jahr und Releases mit ungerader Endung zwei Jahre zu unterstützen, hat dem Projekt in den letzten Jahren gute Arbeit geleistet. Allerdings ist es durch sich ändernde Rahmenbedingungen überholt worden. Die unten stehende Ankündigung fasst die Änderungen gut zusammen und geht auch auf die dahinter stehenden Überlegungen ein. Die wichtigsten Änderungen sind:
  • Das FreeBSD Projekt garantiert fortan, dass Zweige mindestens 5 Jahre unterstützt werden.
  • Hauptreleases werden zukünftig seltener erfolgen, damit nicht zu viele Zweige parallel laufen.
  • Subreleases werden nur noch 3 Monate unterstützt, wenn ein folgendes Subrelease erschienen ist.
Dazu zu sagen ist, dass in den letzten Jahren begonnen wurde, wesentlich mehr Änderungen aus -CURRENT in das letzte -STABLE zu mergen, wodurch der Sprung zwischen aktuellen Subreleases und neuen Hauptreleases wesentlich kleiner geworden ist. Zugleich ist durch verschiedene Maßnahmen das Update von einem Subrelease auf ein folgendes Subrelease nahezu trivial geworden, ähnlich dem Einspielen von Service Packs unter Windows oder Service-Releases kommerzieller Linux-Distributionen.

Die Ankündigung:
Code:
Changes to the FreeBSD Support Model
-----------------------------------------------------------------------

Over the past several months, the teams responsible for supporting the
FreeBSD operating system discussed the current support model, and how
that model can be improved to provide better support for FreeBSD users
and consumers.

The changes below greatly improve FreeBSD support, reduce turnaround time
for Errata Notices and Security Advisories, provide consistency between
binary package sets and the underlying FreeBSD base system version, and
reduce the amount of time before new features are included in the official
FreeBSD binary package sets.


Changes Proposed in a New FreeBSD Support Model
-----------------------------------------------------------------------

The proposed changes include:

- Moving from a point release-based support model to a set of releases
  from a branch with a guaranteed support lifetime.

- Resolving our arbitrary (and unofficial) 5-year branch lifetime
  guarantee.  The support policy is that the stable/X branch will be
  supported for 5 years (minimum) from the point X.0-RELEASE is released.
  We now guarantee a 5-year lifetime on the branch, regardless of how many
  releases are built from the branch. Additionally, a "last minute"
  release from the stable/X branch does not constitute expanding the support
  lifetime for the branch as a whole for an additional two years.

- The Security Officer or Ports Management Team may extend support for any
  individual numbered release or branch at their discretion, in
  exceptional cases.

- A new stable/ branch release will not occur before two years after the
  X.0-RELEASE from the prior branch.  This limits the number of
  simultaneous supported branches, which will greatly reduce the overall
  number of branches that must be maintained and build-tested for
  Security Advisories and Errata Notices, reducing turnaround time.

- Each new release from the stable/X branch deprecates the previous
  release on the branch, providing a three-month window within which
  consumers are urged to upgrade to the latest release.  During this
  three-month window, Security Advisories and Errata Notices will still
  be issued for the previous release, as necessary.


How These Changes Benefit FreeBSD Consumers
-----------------------------------------------------------------------

These changes to the FreeBSD support policy will reduce turnaround time
for security advisories and errata notices, provide binary package sets
that are more closely aligned with the latest FreeBSD release from a given
branch, and clearly define the minimum length of time that a branch will
receive support.


When The New FreeBSD Support Policy Will Become Effective
-----------------------------------------------------------------------

These changes are planned to become effective with FreeBSD 11.0-RELEASE,
which is still a number of months away.

FreeBSD releases from earlier branches will continue to be supported in
accordance with the policy that was in effect at the time they were
released.


Deficiencies in the Current FreeBSD Support Model
-----------------------------------------------------------------------

- The FreeBSD support model is release-based, versus branch-based.
  Specifically, we determine if a FreeBSD release will be a normal- or an
  extended-support release in the final phases of the release cycle, while
  in reality we have no way to determine how successful the release is
  until weeks or months later.

- We do not clearly define how long the stable/X branch will be supported
  after its creation.  Since FreeBSD 5.x, we have historically supported a
  stable/X branch for a minimum of five years after the X.0-RELEASE is
  available.  The length of time is not a defined policy, which can make
  it difficult to decide which branch to track.

- The current support model prevents building third-party binary packages
  for the most recent release from a stable/ branch because we must
  provide packages that can be run on the oldest supported release from
  the branch.

- Ports maintainers must support the oldest supported release on the
  branch within the Ports Collection. This adds significant complexity to
  the tree in general, but also prevents enabling new features by default.
  An example is the upgrade to WITH_NEW_XORG where these features depend
  on changes to the base system that are only available in X.Z-RELEASE.

- The support model can overlap in non-intuitive ways, making it difficult
  to decide when evaluating FreeBSD features versus support timeframe from
  any given branch.  When changes to the support model were initially
  being discussed, the FreeBSD supported releases were:
  - 8.4-RELEASE: June 30, 2015
  - 9.1-RELEASE: December 31, 2014
  - 9.2-RELEASE: September 30, 2014

  (Note that in this case support for the newer 9.2 release ends before
  support for FreeBSD 9.1.)

- A new release from a branch automatically extends the support lifetime
  by two years, minimum.  If X.Y-RELEASE was initially planned to be the
  final release from the stable/X branch, it is an extended-support
  release by definition.  If it is necessary to follow X.Y-RELEASE with
  X.Z-RELEASE for any reason, we would have two concurrent
  extended-support releases from the same branch in sequence. This has a
  serious impact on the quality of an update when there are multiple
  supported releases on a branch. The problem becomes worse when the
  oldest supported release on the branch has a longer support lifetime
  than the newest release on the branch.


Key Items Considered in Changes to the FreeBSD Support Model
-----------------------------------------------------------------------

Some of the things that should be included in a new FreeBSD support
model include:

- Guaranteeing, and explicitly stating, the support lifetime of the
  stable/X branch as a whole, versus independently determining the
  support lifetime of the individual releases from the stable/X branch.
- Providing package sets that are compatible with the latest release from
  the branch, ensuring that new features introduced into the FreeBSD base
  system can be enabled by default in binary package builds.
- Security Advisories and Errata Notices should be more aligned between
  src/ and ports/.  There is an endless list of edge cases with this
  particular point, but consider a situation where a critical security
  vulnerability is discovered, and the underlying code has changed between
  X.Y-RELEASE and X.Z-RELEASE.  In addition to the possibility of
  regression in one (or both) of the supported releases due to subtle
  changes in the security fix, it introduces potential delay in providing
  the security fix as the number of supported releases increases.  Each
  supported release adds to the amount of time it takes for:

  - 1) patching the vulnerability,
  - 2) testing the patch,
  - 3) verifying the patch is correct, and
  - 4) building the freebsd-update(8) binary update bits.

  If a problem is discovered at any time during step (4), procedure resets
  to step (1).  (It should be stressed that this is not due to lack of
  hardware, but the order in which the various steps of issuing Security
  Advisories and Errata Notices must occur.)

- Providing a support model that is easier more predictable and easier to
  follow.

--
Matthew Seaman  Core Team Secretary
matthew@FreeBSD.org  core-secretary@FreeBSD.org
 
Zuletzt bearbeitet:
Ich frage mich, warum eigentlich nicht echtes rolling Release wie zB. Arch oder Gentoo?
Ernst gemeinte Frage :)
 
Ich frage mich, warum eigentlich nicht echtes rolling Release wie zB. Arch oder Gentoo?
Ernst gemeinte Frage :)

Naja, ich glaube FreeBSD schreibt sich hauptsächlich ein Server-Dasein auf die Nase (-> The Power to Serve). Server und Rolling-Release.... neeeee. Und wie schon gesagt, hast du ja noch die Wahl auf -STABLE und -CURRENT zu gehen.

Ich hatte schon teilweise Stress mit neueren FreeBSD-Versionen oder kommerzielle Pakete die unter einer neuen FreeBSD-Version zeitweise nicht liefen. Da ist man froh auf irgendwas früheres definiertes und supportetes zurückgehen zu können,
 
Ich sehe es so, dass Rolling Releases durchaus ihre Berechtigung haben. Ich stehe zum Beispiel seit langem auf dem Standpunkt, dass neuere Software immer besser als ältere ist und es daher nicht viel Sinn hat, krampfhaft an alten Versionen festzuhalten. Daher nutze ich z.B. Arch Linux auf meinem Laptop und auch das FreeBSD auf dem Desktop wird jede Woche aktualisiert. Aber das bedeutet nicht, dass Rolling Releases nun für alle Situationen die beste Wahl wären. Wenn man große Deployments mit hunderten oder tausenden Instanzen hat - ein Bereich, in dem viele Nutzer FreeBSD einsetzen - will man möglichst homogene Strukturen aufbauen, die sich dann mit Automatisierungstools wie Saltstack managen lassen. Das klappt am einfachsten, wenn man definierten Versionen hat und Updates sehr gezielt durchführen kann. Ich bin daher auch sehr froh, dass FreeBSD inzwischen bei Ports / Paketen zwei langsamere Zweige neben dem Rolling Release anbietet und auch dort eine relativ hohe Stabilität bieten kann.
 
Ich stehe auf den Standpunkt, dass das ständige Herauspusten von neuen Versionen des Produkts ganzheitlich schlechter macht. Das krampfhafte Festhalten an neu ist besser ist kontraproduktiv und verlagert die Probleme auf die Nutzerseite.
Aus Entwicklersicht ist klar, bei neuen Versionen wird neuer Kram Einzug halten und es verbleibt weniger Zeit alte Features zu pflegen. Es mag den OSS-Prinzip Release early and often entsprechen und dem eigenen Ego schmeicheln(das Projekt gerät nicht in Vergessenheit) bringt aber das Problem, ständig Code-Freezes und Releases zu organisieren und auch Qualität der Releases herabzusetzen, wenn man hinter dem willkürlich gesetzten Zeitplan hinkt. Auch mit den ständigen Optimieren unter der Prämisse Zielgruppen zu 100% zu erreichen, sehe ich problematisch. Die Mehrheit der Nutzer wäre mit 10% der Features zufrieden, wenn sie denn funktionieren. Gerade im kommerz. FreeBSD-Umfeld sehe ich nicht die Notwendigkeit auf Rolling-Releases umsteigen zu müssen und privat sehe ich keinen Vorteil. Da wo es sinnvoll wäre bspw. Updates der DRI scheint die Entwicklung sehr zäh zu sein.
Arch ist da ein gutes Beispiel für RR. Früher eine eher nischige Distro mit eigenen Charakter nun ein generischen Yet-another-Linux-Distro mit Einheitsbrei bei dem die QA der Nutzer übernimmt. Ich bin aus dem Alter heraus, irgendwelche obskuren Workarounds anzuwenden nur weil wieder keine Zeit zum testen war, dank Rolling-Releases. Wir alle wissen, es reicht nicht aus das es nur kompiliert. Und jedes Mal ins Wiki schauen zu müssen nur damit es so funktioniert wie früher, ist keine Lösung. In der Regel möchte ich einzelne Anwendungen aktualisiert sehen und nicht alles auf einmal ändern.
 
Ich stehe auf den Standpunkt, dass das ständige Herauspusten von neuen Versionen des Produkts ganzheitlich schlechter macht. Das krampfhafte Festhalten an neu ist besser ist kontraproduktiv und verlagert die Probleme auf die Nutzerseite.
Aus Entwicklersicht ist klar, bei neuen Versionen wird neuer Kram Einzug halten und es verbleibt weniger Zeit alte Features zu pflegen. Es mag den OSS-Prinzip Release early and often entsprechen und dem eigenen Ego schmeicheln(das Projekt gerät nicht in Vergessenheit) bringt aber das Problem, ständig Code-Freezes und Releases zu organisieren und auch Qualität der Releases herabzusetzen, wenn man hinter dem willkürlich gesetzten Zeitplan hinkt. Auch mit den ständigen Optimieren unter der Prämisse Zielgruppen zu 100% zu erreichen, sehe ich problematisch. Die Mehrheit der Nutzer wäre mit 10% der Features zufrieden, wenn sie denn funktionieren. Gerade im kommerz. FreeBSD-Umfeld sehe ich nicht die Notwendigkeit auf Rolling-Releases umsteigen zu müssen und privat sehe ich keinen Vorteil. Da wo es sinnvoll wäre bspw. Updates der DRI scheint die Entwicklung sehr zäh zu sein.
Arch ist da ein gutes Beispiel für RR. Früher eine eher nischige Distro mit eigenen Charakter nun ein generischen Yet-another-Linux-Distro mit Einheitsbrei bei dem die QA der Nutzer übernimmt. Ich bin aus dem Alter heraus, irgendwelche obskuren Workarounds anzuwenden nur weil wieder keine Zeit zum testen war, dank Rolling-Releases. Wir alle wissen, es reicht nicht aus das es nur kompiliert. Und jedes Mal ins Wiki schauen zu müssen nur damit es so funktioniert wie früher, ist keine Lösung. In der Regel möchte ich einzelne Anwendungen aktualisiert sehen und nicht alles auf einmal ändern.

Ist nur die Frage, wohin sich die BSD's bewegen ...
 
Ich mag das "rolling release"-Prinzip eher bei den Ports als bei Base. Problem ist aber bei FreeBSD, dass da sehr essentielle Werkzeuge in Base sind (Compiler und gutes Stück vom Toolchain), die ich gerne lieber aktuell hätte. Und andererseits gibt es auch Treiber, die dann sehr lange in -CURRENT sind, auf die man sehr lange warten muss und dann am Ende die Hardware veraltet ist, wenn -CURRENT zu -STABLE wird. Sowas nervt, wenn man länger als 6 Monate warten muss, obwohl man weiß, dass es möglich ist, nur der ganze Kram im anderen Zweig ist, der jederzeit explodieren kann (und deswegen will man den eher nicht). Zudem geht die Entwicklung in CURRENT (an einzelnen Stellen dann) auch schleppender, wenn man die Massen nicht für Tests missbrauchen kann, ohne jemand gleich ganz CURRENT auf die Nase binden zu müssen.

Um nur ein Beispiel zu nennen: es soll angeblich 11n hostap mit Atheros in HEAD gehen. Ja toll. Wenn es dann raus ist, dann ist 11n (wahrscheinlich) tot und immer noch nicht zugenüge getestet.
 
Ich stehe auf den Standpunkt, dass das ständige Herauspusten von neuen Versionen des Produkts ganzheitlich schlechter macht. Das krampfhafte Festhalten an neu ist besser ist kontraproduktiv und verlagert die Probleme auf die Nutzerseite.

Kommt aber auch immer auf das Projekt an. Wenn der Entwickler einer Anwendung sagt: "Hier ist meine neue Stable-Version!", warum sollte sch da eine Distribution dazwischen stellen und sagen: "Nö! Die _KANN_ gar nicht stabil sein!". Als Beispiel mal Bürosoftware, Browser, Multimedia-Software. Die werden ja nicht mit jeder Version komplett umgeschrieben, sondern meist nur erweitert und verbessert.

Klar gibt es auch Projekte die explizit sagen: "Es ist an den Distributionen unsere Releases zu testen" (*hust* systemd ), aber diese Projekte sind doch eher in der Minderheit.

Und wenn ich bei ArchLinux Stress hatte, dann hat meist irgendwer was im Kernel zerferkelt, aber auch bei ArchLinux habe ich die Wahl linux-lts als Kernel zu wählen. Normale Software wie der ganze GNOME-Kram, Browser, IM und Multimedia-Player machen so gut wie nie Stress bei Upgrades.
 
Das steht und fällt doch alles mit dem Anwendungsfall.

Beim Betrieb meiner Server finde ich die Idee mir 5 Jahre keine ernsten gedanken um ein Upgrade des OS zu machen sehr sympathisch. Lieber einmal Schmerzen, als dauernd welche.

Generell betrachtet, hat tedunangst sicherlich mit seinem Einwurf recht, allerdings sind die OpenBSDler ja eher analfixierte Paranoiker, die permanent ihre Zwanghaftigkeit gegen ihre Ängste ausspielen. (nicht ganz ernst gemeint)
Nichtsdestoweniger wollen die erst mal Sicherheit und dann schauen, was noch geht. Aus der Perspektive viele Feature und schnell und dann mal nach Sicherheit schauen, stellt sich das Problem schon anders dar.
 
Ich mag das "rolling release"-Prinzip eher bei den Ports als bei Base. Problem ist aber bei FreeBSD, dass da sehr essentielle Werkzeuge in Base sind (Compiler und gutes Stück vom Toolchain), die ich gerne lieber aktuell hätte.

In deinem restlichen Post stimme ich dir voll zu, aber gerade Compiler sind so eine Sache, wo es noch wenig weh tut. Da hat man das Basissystem, wenn man ganz sicher sein will, dass da keine neuen Probleme auftauchen, aber wenn du einen aktuelleren Compiler willst kann man ihn ja relativ einfach aus den Ports nehmen. Das ist echt schön, weil selbst wenn man wo eine ältere Production-Kiste rumstehen hat kann man da einfach mal sagen wir mal sein gcc5 rauftun, wenn man es unbedingt braucht (war bei mir kürzlich der Fall). Und am anderen Ende bin ich glücklich, dass ich bei den restlichen Probleme auch ältere Sachen am Laufen haben kann. Auf einem Desktop ist Rolling Release toll, aber wenn man X Server hat kann das echt blöd sein, wenn man sich zwischen Major Upgrade oder Sicherheitslücke entscheiden muss, wenn die Zeit ohnehin schon knapp ist oder ähnliches. Ja, im Optimalfall kommt es nicht dazu, aber ja im Optimalfall wäre vieles anders.

Ich habe auch lieber aktuellere Software und ich dränge darauf, aber manchmal wäre das vielleicht optimal, nur eben nicht realistisch. Leider.
 
Ja, Du hast Recht. Man kann meistens eine neuere Version des Compilers aus den Ports installieren (clang und gcc). Falsches Beispiel.
 
"Latest" Pakete werden nun übrigens deutlich öfter gebaut, man versucht auf einen 24h Zyklus zu kommen.
 
Die wollen jeden Tag ALLE Pakete neu bauen?

Die sind wahnsinnig, da gibt doch täglich einen Haufen kaputter Pakete, die nicht bauen.
 
FreeBSD wird immer mehr zu Debian. :D

Nicht nur altes Base, sondern auch alte Pakete. Naja, wenigstens nehme ich immer noch portmaster anstatt pkg.
 
Ich habe einen selten genutzten Desktop und der läuft mit irgendwelchen pkg Dingern eigentlich rund, aber produktiv nutze ich zugegebenerweise lieber Handarbeit.
Es hat vermutlich alles seinen Anwendungsbereich.
 
Ich denke der Gedanke hinter häufigerem Bau der aktuellen Pakete ist, dass man damit eine bessere Testabdeckung bekommt. Derzeit wird ein Port commitet. Danach dauert es Worst Case 7 Tage, bis er gebaut wird. Schlägt der Bau fehlt, ist das Paket nun mindestens 7 Tage nicht verfügbar. Baut man hingegen täglich, ist die Lücke wesentlich kleiner. Man sieht zeitnah, dass das Paket nicht baut und kann kurzfristig darauf reagieren, sodass es idealerweise schon beim nächsten Bau wieder bereit steht. Davon einmal abgesehen ist die Anzahl nicht bauender Pakete recht konstant, es gibt nur ab und nach nach Änderungen an kritischen Basispaketen mal größere Ausreißer.

Nutzer profitieren von dem engeren Intervall ebenfalls. Derzeit ist es ein Ärgernis, dass Ports und Pakete nach einigen tagen nicht unerheblich abweichen. Das wird nicht mehr der Fall sein. Änderungen werden schneller verfügbar, man muss keine Woche mehr warten. An der Stabilität bzw. Qualität wird es kaum etwas ändern. Ob man den Portstree nun alle 24 Stunden oder alle 7 Tage durch Poudriere schiebt, ändert ja nichts.

Die Quarterly Packages wurden eingeführt, weil viele Nutzer explizit nach einem langsameren, konservativeren Branch verlangten und sich nicht mit den einmal zum Release gebauten Release Packages zufrieden geben wollten. Anders als bei z.B. Debian sind die Quarterly Packages aber nicht ultrakonservativ und werden auch nicht bis zur Unkenntlichkeit gepatcht. Es ist einfach ein zum Zeitpunkt X erstellter Zweig, in den bei Bedarf neuere Versionen von Port gemerged werden. Zum Beispiel im Falle von Sicherheitsproblemen, aber auch nach schweren Bugs. Gerade für Administratoren ist das ein guter Kompromiss. Die Pakete sind halbwegs aktuell, es ändert sich aber auch nicht täglich was.

Und das Wechseln zwischen den Zweigen ist nun wirklich trivial. Die Konfigurationsdatei in /etc/pkg/ ändern, 'pkg update' zum Synchronisieren des neuen Repos und ein 'pkg upgrade' hinterher. Wenn man ganz sicher sein will, macht man ein 'pkg upgrade -f'.
 
...aber produktiv nutze ich zugegebenerweise lieber Handarbeit.
Ich baue auch alle meine Pakete selber aber halt aus dem "quarterly branch" mit poudriere.

@Yamagi
Eine andere Lösung wäre es, die Datei "/usr/local/etc/pkg/repos/FreeBSD.conf" mit folgendem Inhalt zu erstellen:
Code:
FreeBSD: { enabled: no }
... und eine weitere mit dem neuen Repo "/usr/local/etc/pkg/repos/FreeBSD-quarterly.conf":
Code:
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
Mit "enabled: yes/no" kann man dann relativ zügig die Repos umstellen (gibt ja mehrere Quartals Branches), sollte man das mal benötigen.

Gruss
 
Ja, das ist sogar sinnvoller. Wenn man die Datei in /etc/pkg ändert, bekommt man beim nächsten Update eventuell Probleme. Es wird überschrieben oder man muss von Hand mergen.
 
Zurück
Oben