News Linux: Freeze für Debian 9 „Stretch“ hat begonnen

fethomm

Commander
Registriert
Okt. 2012
Beiträge
2.597
Am 5. November hat das Debian-Release-Team den ersten von vier Schritten zur Veröffentlichung von Debian 9 „Stretch“ getan. Dies geschah durch die Einleitung der ersten Phase des Freeze. Damit wird das System, das normalerweise den Testing-Zweig aktualisiert, schrittweise eingefroren.

Zur News: Linux: Freeze für Debian 9 „Stretch“ hat begonnen
 
Oje, keiner will ein System, das einfriert. Das hätte ich mir von Debian nicht erwartet, soll ja eigentlich auf stabil getrimmt sein.
:lol:

...ok, der Witz war ziemlich flach..


Ich freu mich schon auf Debian 9, vielleicht löst es ja mein OpenSuse System ab.
 
Ja, wie damals bei Debian 8 bin auch jetzt gespannt, weil ich die Debian-Welt aufgrund der Verbreitung als interessanter empfinde. Leider bleibt bei denen der Kernel dann auch stehen, und wird nicht, wie bei Ubuntu oder Fedora, oft auf die neue Version gebracht, was ich gerade bei Grafiktreiberunterstützung wichtig finde. Ich muss gestehen, dass ich noch Linux-Anfänger bin, und ich nicht sicher bin, ob ich einfach bei einer beliebigen Distro einen neuen Kernel drüberbügeln darf, wobei mir schon klar ist, dass ich dann der Distro sagen muss, dass sie bitte nicht auf den Standardkernel zurückpatcht.

Mal sehen

LG
 
Das hatte ich noch nicht gehört. Aber mir geht es eher daraum, wenn Beispielsweise Kernel 4.10 genutzt wird, dass es dann nur leicht Anpassungen gibt à la 4.10.xx.yy.zz, aber eben nicht mehr auf 4.11 und größer, ergo neue Features dann nicht mehr eingepflegt werden, sondern nur Bugfixes kommen. Bei Ubuntu, was ja auf Debian aufsetzt, wird mit jedem Release auch die Kernelversion angehoben auf einen relativ neuen Stand, meist einen unter dem neuesten, soweit ich gesehen habe. Und gerade, wenn ich bei AMD die Treiberentwicklung sehe, die in den Kernel einfließt, hätte ich da gern die Möglichkeit, aktuell zu bleiben, ohne gleich das Terminal anwerfen zu müssen, um per Konsole neue Kernel einzupflegen, ohne sicher zu sein, ob ich nicht damit bei einigen Abhängigkeiten alte Pakete zerschieße.

Und nachdem ich schon auf einer VM einige Male Linuxe zerschossen habe, als ich versucht habe, gewisse Treiber einzubinden, bin ich da vorsichtig geworden. Wobei ich mal annehme, dass in einer VM diese Treiber vielleicht garnicht installiert werden dürfen, was aber, in diesem Fall Ubuntu, damals nicht sehen konnte/gesehen hat, und dann einfach nur in einen schwarzen Bildschirm gebootet hat.

Naja, wenn es nen neuen Rechner auf ZEN-Basis gibt, werde ich auf dem alten mal Linux native drauf installieren und ausprobieren.

LG
 
bei debian würd ich keine kernel selber backen ... maximal ein paar module zur not
den rest über backports ... allein wegen den security features .... es ist schließlich kein gentoo ;-)
 
Das alles "eingefriert" wird und nur noch "Security Patches" kommen, hat ja seinen Sinn. Das ist ja alles so gewollt. Ist manchmal unbefriedigend. Aber letztlich geht es da um Stabilität. Wer etwas experimentierfreudiger ist, nimmt halt aktuelle Testing-Builds. Aber der Stable sollte schon Stable sein und da hat z.B. ein Kernel-Update einfach auch nichts zu suchen.
 
Wie kachiri sagt, der Sinn von Debian ist ja gerade vom Release an ein festes Featurelevel zu haben, mit entsprechenden API's etc. pp., die sich nicht plötlich ändern.

Wer jeweils aktuelle Kernel u.ä. braucht, ist bei Debian falsch. Da ist dann Ubuntu wahrscheinlich besser, oder wenn man bleeding edge will, Arch und Gentoo.
 
Hi und danke @ y-Chromosome,

das schaue ich mir gleich mal an.

LG
 
Modin666 schrieb:
Ich muss gestehen, dass ich noch Linux-Anfänger bin, und ich nicht sicher bin, ob ich einfach bei einer beliebigen Distro einen neuen Kernel drüberbügeln darf, wobei mir schon klar ist, dass ich dann der Distro sagen muss, dass sie bitte nicht auf den Standardkernel zurückpatcht.

Mal sehen

LG
Am einfachsten klappt ein Kernelwechsel meist mit Rolling-Release Distributionen.
Ich kann z.B. per GUI einen (oder mehrere) Kernel der Wahl installieren und deinstallieren (momentan 11 Stück, vom noch nicht fertigen 4.9rc4-1 über Real-Time Varianten bis zum alten 3.10.104-1). Dabei wird dann auch alles andere notwendige erledigt (z.B. Nvidia Kernel-Module etc.). Da die Distribution ja die Auswahl bereitstellt, sollte es keine Probleme mit den Treibern etc. geben, egal ob mit proprietären oder Open-Source Treibern.

Dauert keine Minute und beim nächsten Boot wird der neueste Kernel verwendet. Im Boot-Menu (grub2) stehen aber auch alle installierten Kernel zur Auswahl und diese Auswahl wird auch für den nächsten Boot beibehalten.
Optimal also für Versuche mit den neuesten Open-Source Grafiktreibern. (Da Rolling-Release sind die restlichen Komponenten ja eh immer auf einem sehr aktuellen Stand).

Rolling-Release Versionen haben außer Vorteilen natürlich auch Nachteile, für einen absoluten Anfänger könnten die ab und zu entstehenden Problemchen evtl. zu frustrierend sein, auch wenn es dazu meist klare Anleitungen gibt, wie man das lösen kann, meist aber per Kommandozeile.

Für einen 2. PC, der eben nicht zu 100% garantiert immer laufen muss aber wohl eine Überlegung Wert, auch zum dazulernen...
 
Modin666 schrieb:
Aber mir geht es eher daraum, wenn Beispielsweise Kernel 4.10 genutzt wird, dass es dann nur leicht Anpassungen gibt à la 4.10.xx.yy.zz, aber eben nicht mehr auf 4.11 und größer, ergo neue Features dann nicht mehr eingepflegt werden, sondern nur Bugfixes kommen.
Ich glaube, es hilft, wenn man sich von der eigentlichen Bedeutung der Adjektive „stable“, „testing“ und „unstable“ löst[1]. Gemeinhin gilt „testing“ als stabil genug für den Desktop-Betrieb, nur für den Server-Einsatz, wo neue Treiber und generell Software eine viel geringere Rolle spielen, wird „stable“ eindeutig bevorzugt. Mit Testing entfällt dann auch der Upgrade-Zyklus, weil es effektiv eine „rolling distribution“ ist. Und selbst wenn man lieber auch auf dem Desktop „stable“ einsetzt, gibt es noch immer die sogenannten „Backports“, durch die bestimmte Software wie eben z.B. der Kernel oder Browser neuere Versionen aus Testing erhalten.

Übrigens ist der Kernel im Vergleich zu anderen Komponenten sehr leicht ersetzbar; ich kenne Maschinen, die auf Wheezy laufen (eigentlich hatte das schon Kernel 3.2) und bis vor kurzem 2.6.26 vom Lenny-Xen-Host verwendet haben - jetzt immerhin 2.6.32 aus den Squeeze-Backports, weil das die letzte Version ist, die korrekt bootet (= keine Kernel-Panic erzeugt).

Und der Grund ist einfach und heißt Linus:
Linus Torvalds schrieb:

Abschließend möchte ich dir noch Manjaro Linux ans Herz legen, wenn dir der Stand der Technik wichtig ist. Es baut auf Arch Linux auf, das, meiner bescheidenen Meinung nach, Rolling-Release derzeit am besten beherrschen, auch, weil es nicht als vorgelagerte Test-Umgebung für eine stabilere Distribution mit klassischen Releases konzipiert ist. Manjaro scheint es zu schaffen, das eindeutig auf erfahrene Linuxer ausgelegte Arch auch für Anfänger zugänglich zu machen. Selbst habe ich zugegebenermaßen nur mit „vanilla“ Arch Linux Erfahrung.

[1]https://de.wikipedia.org/wiki/Debian#Ver.C3.B6ffentlichungszyklus
 
Nabend zusammen.

Erst einmal vielen Dank für die vielen, unerwarteten Rückmeldungen. Da muss ich mich wohl der Qual der Wahl stellen, was die rolling-releases angeht. Ja, manjaro kenne ich schon vom lesen, hatte mich zu Arch-Derivaten nur noch nicht durchgerungen. Vielleicht mache ich das ja mal. In nem halben Jahr gibt es hoffentlich nen neuen Rechner, dann spiel ich mit dem alten mal rum.

@ Steb: An welche Rolling-Distro hattest du denn gedacht?

Ich muss auch gestehen, dass ich mir da wohl zu sehr einen Kopf mache. Wenn ich sehe, wie oft der Micheal auf Phoronix.com seine Kernel durchwechselt für Benchmarks, dann sollte sich das, insbesondere mit den Einstellungsmöglichkeiten unter Grub(2), ja nicht zu schwer ausmachen.

Ich denke, einfach keine Angst haben und mal machen - auf dem alten System dann nachher :).

Vielen Dank nochmal für die netten Rückmeldungen. Ich probier das aus.

Liebe Grüße
 
Modin666 schrieb:
Ich muss auch gestehen, dass ich mir da wohl zu sehr einen Kopf mache. Wenn ich sehe, wie oft der Micheal auf Phoronix.com seine Kernel durchwechselt für Benchmarks, dann sollte sich das, insbesondere mit den Einstellungsmöglichkeiten unter Grub(2), ja nicht zu schwer ausmachen.
Das macht der vermutlich aber auch nur auf Testsystemen oder VMs und nicht auf seinem Produktivsystem, sonst könnte er nicht täglich ein Dutzend Artikel raushauen.

Jedenfalls wenn du möglichst aktuelle Software oder Kernel haben willst, lass die Finger von Debian. Das ist nicht dafür gedacht.
 
Die Nachricht kommt tatsächlich überraschend.
Ich dachte der Freeze wäre verschoben, weil Debian auf den neuen LTS Kernel 4.10 warten will?!

Aktuell befindet sich ja noch nicht einmal 4.8 in der Testing Umgebung, obwohl das langsam mal Zeit wird.
 
textract schrieb:
Die Nachricht kommt tatsächlich überraschend.
Ich dachte der Freeze wäre verschoben, weil Debian auf den neuen LTS Kernel 4.10 warten will?!

Aktuell befindet sich ja noch nicht einmal 4.8 in der Testing Umgebung, obwohl das langsam mal Zeit wird.

Die Verschiebung wurde im März in der Annahme beschlossen, dass 4.10 der nächste LTS-Kernel werden wird. Das war aber eine Fehleinschätzung, da es 4.9 LTS sein wird. Der 5.11 ist nun schon der um 2 Monate nach hinten verschobene Termin. Als klar war, dass es 4.10 nicht werden wird, beliess man es bei dem neuen Termin.
 
Das problem mit testing ist das es eben auch eingefrohren wird daher wirds um das release herum sau alt alles, davon ist sogar unstable betroffen das also als rolling zu bezeichnen halte ich fuer mutig.
Einigen wir uns auf ne mischform.

Debian ist zu konservativ und hat grosse probleme. Centos hat laengere supportzeitraeume mit dnf und selbst Yum bessere packetmanager. Fuer server bevorzugen die meisten die zur debwelt gehoeren meist auch ubuntu.

Es verkommt ein wenig zur reinen metadistro also als reine basis fuer andere distros.

Nun hat es ein kleines revival fuer den desktop weil eine alte gnomeshell version immernoch 10x mehr neues bietet, als das 3 jahre alte fast voellig unveraenderte unity 7? Oder welche version war das noch. Selbst ubuntu gnome liefert nur irgend ne uralte gnome version dann kann man grad zum original greifen.

Debian profitiert grad wenn ueberhaupt eher von der schwaeche anderer Alternativen, als das es selbst toll ist.

Features die ich vermisse:
- reproducable builds
- revert funktion von updates
- mehr speed von apt
- automatische deinstallation alter kernel bis auf die neuesten 2 oder wegen mir auch 5.
- gute integration von 3. Party installern wie Pip und gem und co.
- ein paketformat das kein pain in the ass ist, hab schon debs gebaut macht kein spass
- dann noch das offensichliche mehr auf desktop getrimmt, ein tree ohne freezes, z.b.

Die systemtools sind noch im grunde nach die selben wie vor 15 jahren und nach und nach stoert das im vergleich zur konkurenz die fortschritte machen mehr und mehr.
 
Zuletzt bearbeitet:
Reproducable Builds in Debian sind zu 90% fertig. Um APT zu beschleunigen gibt es z.B. apt-fast. Für die Deinstallation alter Kernel gibt es (bei siduction) das Tool Kernel-Remover, funktioniert seit mindestens 10 Jahren einwandfrei. Ein bisschen über den Tellerrand schauen hilft immer mal. Pip ist nur ein apt install weit entfernt. Insgesamt kann ich deine Kritik nicht teilen, auch wenn ich selbst Debian mit-geforkt habe. Die Grundlagen sind immer noch klasse.
 
fethomm schrieb:
Reproducable Builds in Debian sind zu 90% fertig. Um APT zu beschleunigen gibt es z.B. apt-fast. Für die Deinstallation alter Kernel gibt es (bei siduction) das Tool Kernel-Remover, funktioniert seit mindestens 10 Jahren einwandfrei. Ein bisschen über den Tellerrand schauen hilft immer mal. Pip ist nur ein apt install weit entfernt. Insgesamt kann ich deine Kritik nicht teilen, auch wenn ich selbst Debian mit-geforkt habe. Die Grundlagen sind immer noch klasse.

Erstmal danke fuer die vielen tipps, ich "trolle" auch gerne um gute antworten und informationen zu bekommen oder man koennte auch sagen ich stelle eine these in den raum.
Das an reproducable builds gearbeitet wird wusste ich, nur hatte ich da keine informationen wie weit man ist.

Siduction tools muss man als debianuser aber nicht kennen, zumal es mich primaer bei ubuntu nervt wo das ganze noch laecherlicher ist, da man ja vor gibt dau kompatibel sein zu wollen und dann bei sowas auf wildeste befehle oder cronjobs hin verwiesen wird und das als feature gesehen wird.

Ein extra tool dafuer ist schon mal super frag mich trotzdem warum fedora und archlinux das schafft das bei der installation von neuen kernel die alten automatisch deinstalliert werden ich sehe keinen Grund warum debian keinen solchen mechanismus haben sollte,selbst wenn es standartmaesig aus geschalten waere.

Mit Pip meinte ich nicht das man Pip installieren kann, selbstverstaendlich geht das ich habe eher ein problem damit das man diese konkurenzpaketmanager auf dauer aktzeptiert. Nixos und Guixsd bzw deren paketsysteme nutzen diese paketsysteme um diese als eigene Pakete zu verwende.

Es ist nicht wuenschenswert das man irgendwann 20 paketmanager die bedienung lernen muss. Das mag ok sein fuer windows da dort nur einzelne setup.msi installer ohne abhaengigkeiten die alternative ist, aber sicher keine bereicherung fuer linux, eben nur eine notloesung.
 
Zurück
Oben