News Linux: Freeze für Debian 9 erreicht die letzte Stufe

Gibts schon Infos zu Migrationspfaden? von 7 auf 8 gab es ja noch die Option systemd zu sperren. - Übrigens eine gute Entscheidung, da für die verwendete Virtualisierungsvariante bei mir systemd nichts als Probleme gemacht hat und erst nach einem Rollback und Upgrade ohne systemd problemlos zu betreiben war. (Auf meinem Notebook gibts derzeit auch mehr Gründe, die gegen systemd sprächen als dafür. Aber das ist ein anderes Kapitel.)

Regards, Bigfoot29
 
Bigfoot29 schrieb:
Gibts schon Infos zu Migrationspfaden?
Immerhin sind die Packages sysvinit-core und sysvinit-utils auch in Debian 9 noch vorhanden.

Bigfoot29 schrieb:
Gibts schon Infos zu Migrationspfaden? von 7 auf 8 gab es ja noch die Option systemd zu sperren. - Übrigens eine gute Entscheidung, da für die verwendete Virtualisierungsvariante bei mir systemd nichts als Probleme gemacht hat
Bloß keine Details nennen. Könnte ja informativ werden.
Oder gings nur um eine Salve gegen systemd ?
 
Würde mich auch interessieren welche Problem es bei dir gab. Ich nutze div. Debian 8 installationen, habe erst vor ein paar Wochen ein neuen Server damit eingerichtet, und die laufen ohne Probleme mit systemd.
 
easteregg schrieb:
schade das es php 7.1 scheinbar nichtmehr geschafft hat.
Da PHP ohnehin eher ein Antifeature ist, finde ich das nicht schlimm.
Abgesehen davon, dass es nicht so schwer ist das händisch nachzuinstallieren.

Der Typ von dotdeb.org stellt notfalls auch fertige Packages bereit, sie sich in APT integrieren lassen:
https://www.dotdeb.org/category/php/
 
Die Frage ist auch warum PHP 7 nutzen? Ich finde es muss sich erst mal beweisen bevor man überhastete Entscheidungen trifft. Debian ist ja bekannt bei einigen Paketen eher konservativ zu sein. Die 5% die es effezinter läuft sollte bei heutigen Servern denke ich nicht das Problem bzw. Hauptargument gegen das Debian PHP sein. Dazu kommt 5.6 wird auch noch knapp 2 Jahre supportet.
 
php 7.0 is ja ohnehin schon drin. Der versionsprung auf 7.1 is kaum mit inkompatibilität gegenüber 7.0 einher gegangen, vondaher wäre es mögich gewesen, aber das release kam scheinbar schlicht zu spät.


@andy_m4 nimm halt lisp oder irgendwas anderes ,wenn dir php nich passt. is ja zum glück ne freie welt ....
 
easteregg schrieb:
nimm halt lisp oder irgendwas anderes ,wenn dir php nich passt.
Mach ich ja auch. :-)


easteregg schrieb:
is ja zum glück ne freie welt ....
Ja. Daher auch der Hinweis aufs PHP-Repository.
Wobei der Typ wohl nicht weiter machen will. Keine Ahnung, obs ähnliche Projekte gibt.

Bleibt das manuelle installieren, was aber nur auch kein Hexenwerk ist.
Insofern ist es vielleicht schade, weils etwas Mehraufwand bedeutet. Aber es bedeutet eben nicht, dass PHP 7.1 auf Debian stretch nicht machbar ist.
Ergänzung ()

Cool Master schrieb:
Die Frage ist auch warum PHP 7 nutzen? Ich finde es muss sich erst mal beweisen bevor man überhastete Entscheidungen trifft. Debian ist ja bekannt bei einigen Paketen eher konservativ zu sein. Die 5% die es effezinter läuft sollte bei heutigen Servern denke ich nicht das Problem bzw. Hauptargument gegen das Debian PHP sein. Dazu kommt 5.6 wird auch noch knapp 2 Jahre supportet.
Naja. 7.0 ist ja drin. Und 7.1 bringt viele Bugfixes. Allerdings auch neue Features. Und keine Ahnung, aber womöglich gibts auch veränderte System-Requirements.
So gibt es also ein Für und Wider und am Ende wirds wohl tatsächlich schlicht die Zeit gewesen sein. Irgendwo muss man halt mal doch ein Schnitt machen.
 
php 7.1 is kein bugfix release, dafür gibts die 7.0.x sowie 7.1.x. neue features gibts nur mit 7.1

es ist klar, dass man das alles nach und nach selbst ich bauen kann, das is auch nich die welt. aber es is doch sehr schön wenns in der main distribution mit drin ist und man keine extra sources dafür braucht. es ist halt in dem context schon getestet, dass alles seinen dienst verrichtet wie es soll, was ja das hauptargument für das nutzen einer distribution wie debian ist.
ansonst könnte man sich das komplette system selbst zusammensetzen. ;)
 
easteregg schrieb:
php 7.1 is kein bugfix release,
Hab ich auch nirgends behauptet.

easteregg schrieb:
es ist klar, dass man das alles nach und nach selbst ich bauen kann, das is auch nich die welt. aber es is doch sehr schön wenns in der main distribution mit drin ist und man keine extra sources dafür braucht. es ist halt in dem context schon getestet, dass alles seinen dienst verrichtet wie es soll, was ja das hauptargument für das nutzen einer distribution wie debian ist.
Ist mir schon klar. Trotzdem sehe ich es immer noch nicht als Weltuntergang, wenns nicht dabei ist.

easteregg schrieb:
ansonst könnte man sich das komplette system selbst zusammensetzen. ;)
Genau. Nur weils bei Debian nicht dabei ist, gehen wir gleich auf Linux-from-Scratch.
Ich frag mich, warum es immer in Extreme abrutschen muss.
 
Probleme gab es sowohl bei der Parametrisierung von RAID-Laufwerken als auch bei der beliebigen Unbrauchbarmachung von IP-Adressen, nachdem die von systemd-fremden Prozessen auf ihren finalen Stand hin "migriert" wurden. Ist jetzt über ein Jahr her und die Konfiguration ist doch recht eigen, weswegen ich das oberflächlich gelassen habe.

Und um weiter völlig ohne Begründung über systemd zu schimpfen, weils vor wenigen Wochen erst passiert ist: versuch mal, einen Laptop unter Ubuntu 16.04 mit geschlossenem Deckel zu booten. Ubuntu verweist hier eindeutig (und zu Recht) auf systemd. Fällt meistens nur auf, dass der Rechner beim "ersten Mal Powerknopf auf der Dockingstation drücken" "irgendwie nicht richtig startet" und nach dem zweiten Mal sofort da ist. --> systemd meint halt irrsinnigerweise, man hätte den Rechner nach Boot-Start zugeklappt und müsse jetzt zwingend suspenden. Damit gibts dann den zweiten Bug, dass systemd-suspend sich nach erfolgreichem Restore nicht beendet. Da aber systemd-suspend nicht beendet, ist ein herunterfahren des Rechners nichtmal über die üblichen Zwangsmaßnahmen init 6/init 0 möglich, solange man nicht über systemd-suspend stolpert. Und als 08/15-User soll man darüber erstmal stolpern.

Auch werden eth-devices ohne systemd-eigene Not mal eben umgeschubst und in ein neues Namensschema überführt (hat mit dem Problem oben übrigens nix zu tun), nur weil sie meinen, ein Host müsste komplett stateless booten können. Nein, muss er nicht. Es gibt IMMER einen Config-Host, der eine Büchse beim booten unterstützt und daher Hilfsparameter mitgeben kann. Also wird die bewährte Methode, ETH-Bezeichnungen per udev-Regeln fix an die MAC zu binden, über Bord geworfen und stattdessen eth-Bezeichnungen über ihren PCI-Pfad zu definieren. (Blöd nur, wenn das auch nicht konsistent ist, da nicht jedes System PCI nutzt und man dann WIEDER auf andere Naming-Logiken zurückgreifen muss. Also fängt man an, um diesen Schwachsinn in systemd herumzubasteln. Und ab dem Punkt kann ich dann auch fast schon wieder Windows nehmen, wenn ich die gefühlt persönlichen Animositäten der Entwickler mit Workarounds fixen muss.

Reicht das als Begründung, warum systemd nix als Ärger macht? Oder muss ich jetzt noch tiefer in die Geräte-Spezifikation einsteigen, um zu erklären, dass ein simples "init"-System damit schlicht nichts zu tun haben DARF?
- War eine rhetorische Frage. Falls es Dir echt nicht klar ist, ist eine Diskussion ohnehin sinnlos.

Und wie gut Poettering Software schreibt, sieht man an PulseAudio. Da weiß ich immer noch nicht, wo ich anfangen soll, zu kotzen und was das Ding jetzt letztlich besser machen soll, außer Overhead zu erzeugen. esound, Alsa und Co konnten das, was PA heute vorgibt, zu können schon seit Jahren. Und zwar ohne Frickelei und deutlich zuverlässiger. Beispiel: Höllisches Knacken bei HDMI-Audio und Video-Wiedergabe. Verschwindet schlagartig, wenn man PA deinstalliert und über Alsa arbeitet. War bis vor 2 Jahren jedenfalls selbst der empfohlene Workaround in den Foren. War schlicht nicht anders behebbar.

One tool, one function. Und das ist systemd eben NICHT. Es ist ein kaum wartbares und noch viel schlechter auditierbares Monster.

Ist jetzt aber glaub ich BISSERL OT. Aber ja, ich schieb einiges an gewachsener Frustration gegen Poetterings "Projekte". Großkotzig und ohne nach rechts und links zu schauen. Traurigerweise machen gefühlt viel zu viele Entwickler bei seinen Eskapaden mit. Es ist heute schon unglaublich schwierig, etwas zu entwickeln, was nicht beispielsweise explizit auf systemd oder eines seiner Module Rücksicht nehmen muss, sobald man aus der reinen Userland-Entwicklung weggeht. Die Einbahn-Straße, die das bedeutet, falls sich Poettering mal völlig verrent, und man zurückrudern müsste, sieht entweder keiner oder es möchte niemand die Resourcen dafür bereitstellen. Die Devuan-Jungs werden ja für ihren Ansatz, eine Alternative bereit zu haben, auch weitestgehend verlacht.

Danke für die Infos bezüglich sysvinit-core und sysvinit-utils. Scheint also auch für Debian 9 noch zu funktionieren. - Aber warten wir mal die Release- und Upgrade-News ab. :)

Regards, Bigfoot29
 
@Bigfoot29

Danke für Dein ausführliches Posting. Ich fand es äußerst informativ.

Bigfoot29 schrieb:
Auch werden eth-devices ohne systemd-eigene Not mal eben umgeschubst und in ein neues Namensschema überführt (hat mit dem Problem oben übrigens nix zu tun), nur weil sie meinen, ein Host müsste komplett stateless booten können.
Stimmt. Darüber bin ich selbst mal indirekt gestolpert. Hatte mal eine Anleitung geschrieben, wo dann eben auch ne Stelle vorkam a-la "wenn Du ein LAN-Port hast, müsste das Interface irgendwas mit eth0 heißen". Gabs beim angeschriebenen aber nicht. Stattdessen eben Devices mit neuem Namensschema. Da musste ich auch erst recherchieren und hab dann herausgefunden, dass das eben mit systemd zusammenhängt.

Wobei der Sinn dahinter ja nicht ganz von der Hand zu weisen ist. Nur löst das halt Probleme, die ganz viele User nicht haben und diese stellt es dann ggf. vor Probleme.



Bigfoot29 schrieb:
One tool, one function. Und das ist systemd eben NICHT. Es ist ein kaum wartbares und noch viel schlechter auditierbares Monster.
Wobei ich einige der Ideen die sich in systemd manifestiert habe durchaus begrüße.
Zum Beispiel die Behandlung von Abhängigkeiten oder die deklarativen Unit-Dateien statt hunderte Init-Skripte die im Kern eigentlich alle das Gleiche machen.

Daher muss man sicher differenzieren zwischen den Ansätzen und wie die dann konkret implementiert werden.

Das Init IV abgelöst gehört, finde ich übrigens auch.

Bigfoot29 schrieb:
Danke für die Infos bezüglich sysvinit-core und sysvinit-utils. Scheint also auch für Debian 9 noch zu funktionieren. - Aber warten wir mal die Release- und Upgrade-News ab. :)
Ja.
Auch wenn ich selber kein Init IV Fan bin, würde ich es begrüßen.
Von mir aus können die auch noch ein paar andere Init-Systeme hinzunehmen. Meistens weisen die ja ne Init IV Kompatibilität auf, so dass man da nicht mal Init-Skripte anpassen bräuchte.
 
Das gute, alte Debian. Egal welche Linux Distributionen ich ausprobiere, auch wenn ich nur auf Windows zocken kann, auch wenn ich bei der Arbeit mit einem Mac zurecht kommen muss.... letzten Endes lande ich immer wieder bei Debian.
 
surxenberg schrieb:
auch wenn ich nur auf Windows zocken kann, auch wenn ich bei der Arbeit mit einem Mac zurecht kommen muss.... letzten Endes lande ich immer wieder bei Debian.
Ich wiederhole es gern, unter Linux zockt es sich mittlerweile recht gut. Steam gibt es als .deb und sieht aus wie unter Windows. Mit moderner Hardware mangelt es nur noch an AAA Titeln und am Einsatz von Vulkan, letzteres wird den Durchbruch für Linux bringen. Dann geht auch erst das Konzept der Steam Machines auf. Ich schicke dir gern mal einen Screenshot von meinem 2007er Dell Vostro 1500 mit Debian 8.7.1, SSD und GF8600GT auf dem sogar Civ V läuft. Ok die Ladezeiten sind länger aber die Hardware ist ja auch uralt. CSS rennt bei meinen beiden Linuxkisten besser als unter Windows!
 
Zurück
Oben