Buster ohne systemd

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Buster ohne systemd

Paul Muster-21
Hallo,

einige meiner Systeme laufen nach wie vor ohne systemd. Sichergestellt
wird das durch diese Konfiguration:

system:~# cat /etc/apt/preferences.d/no-systemd
Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1
system:~#

Wird das mit Buster weiterhin funktionieren? Oder gehen die
Debian-Entwickler mittlerweile davon aus, dass alle Systeme mit systemd
laufen?


Danke & viele Grüße

Paul

Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Sven Hartge-5
Paul Muster <[hidden email]> wrote:

> einige meiner Systeme laufen nach wie vor ohne systemd. Sichergestellt
> wird das durch diese Konfiguration:

> system:~# cat /etc/apt/preferences.d/no-systemd
> Package: systemd-sysv
> Pin: release o=Debian
> Pin-Priority: -1
> system:~#

> Wird das mit Buster weiterhin funktionieren? Oder gehen die
> Debian-Entwickler mittlerweile davon aus, dass alle Systeme mit
> systemd laufen?

Offiziell nicht.

Aber du hast natürlich das offensichtliche Problem, das der Code,
welcher nicht-systemd-Systeme unterstützt mit der Zeit vom Bitrot
heimgesucht wird, weil er nicht mehr wirklich weiter gepflegt wird.

Das betrifft sowohl Debian selbst als auch natürlich die paketierten
Programme selbst, deren Entwickler sich in einer immer mehr auf systemd
fokussierenden Welt auch eben mehr in diese Richtung orientieren.

Wenn ein Programm keine Unterstützung für nicht-systemd-Systeme mehr
mitbringt, gibt es natürlich recht wenig, das ein Debian-Entwickler dann
noch machen kann (außer natürlich die neue Version nicht paketieren).

S!

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Martin Steigerwald
Hi Sven.

Sorry, wenn das etwas wie ein Rant ausfällt, aber da waren einfach zu
viele Stellen in deiner Antwort, wo ich den Eindruck hatte, dass Du
einfach nicht weißt, was im Bereich Sysvinit gerade Phase ist.

Sven Hartge - 06.09.19, 19:57:19 CEST:

> Paul Muster <[hidden email]> wrote:
> > einige meiner Systeme laufen nach wie vor ohne systemd.
> > Sichergestellt wird das durch diese Konfiguration:
> >
> > system:~# cat /etc/apt/preferences.d/no-systemd
> > Package: systemd-sysv
> > Pin: release o=Debian
> > Pin-Priority: -1
> > system:~#
> >
> > Wird das mit Buster weiterhin funktionieren? Oder gehen die
> > Debian-Entwickler mittlerweile davon aus, dass alle Systeme mit
> > systemd laufen?
>
> Offiziell nicht.
>
> Aber du hast natürlich das offensichtliche Problem, das der Code,
> welcher nicht-systemd-Systeme unterstützt mit der Zeit vom Bitrot
> heimgesucht wird, weil er nicht mehr wirklich weiter gepflegt wird.

sysvinit, startpar, insserv und einige weitere erfahren seit einiger
Zeit intensive Pflege in Debian. Ich hab vor einiger Zeit dabei mit
geholfen, dass eine Zusammenarbeit zwischen Debian und Devuan-Entwickler
entstand (Debian Init Diversity). Und ich würde sagen, die war bisher
äußerst produktiv.

sysvinit, startpar, insserv haben seit einiger Zeit auch wieder einen
Upstream-Maintainer, der aktiv Bugreports bei Debian durchforstet und
fixt. In den letzten Monaten haben Upstream-, Devuan- und Debian-
Entwickler ohne Weiteres mehrere Dutzend Bugreports gefixt. Ich hab nicht
genau gezählt, aber es könnten auch locker über 50 sein. Darunter
durchaus auch über 5 Jahre nicht gefixte Bugs.

Schau Dir einfach mal das Changelog von sysvinit-core an… und staune.

Mit allem Respekt, Sven, hier von Bitrot zu sprechen… das trifft so aus
meiner Beobachtung heraus einfach nicht zu.

> Das betrifft sowohl Debian selbst als auch natürlich die paketierten
> Programme selbst, deren Entwickler sich in einer immer mehr auf
> systemd fokussierenden Welt auch eben mehr in diese Richtung
> orientieren.

Zudem gibt es mit elogind auch eine Alternative zu systemd-logind. Das
ist zwar im Grunde der aus Systemd herausgelöste systemd-logind als
Extra-Paket unter eigenen Namen.

Damit, und mit derzeit bei Debian, nicht bei Devuan, noch einem Paket
aus Experimental, das einige Symlinks umbiegt, und so nicht in Debian
reinkommen darf… habe ich hier seit Monaten ein Debian Unstable mit KDE
Plasma laufen. Es laufen Arbeiten, ein default-logind und generisches
logind-Paket einzuführen und die Abhängigkeiten der Pakete, die den
brauchen, entsprechend anzupassen.

Auf meinem Laptop sieht dann so aus:

% dpkg -l | grep systemd
[ keine Ausgabe ]

Interessanterweise lief elogind auch ohne Weiteres zu tun hier gleich
mit CGroup V2, während Systemd vor meinem Umstieg noch CGroup V1
verwendete. (Ich weiß, dass Systemd schon länger CGroup V2 kann.)

> Wenn ein Programm keine Unterstützung für nicht-systemd-Systeme mehr
> mitbringt, gibt es natürlich recht wenig, das ein Debian-Entwickler
> dann noch machen kann (außer natürlich die neue Version nicht
> paketieren).

Ich habe zudem seit Monaten zwei Server-VMs mit Devuan am Laufen und die
ganzen Dienste laufen *alle* noch unter Sysvinit, darunter unter
anderem:

- Postfix
- Dovecot
- rspamd
- Apache 2
- php-fpm
- Quasselcore
- unbound (leider nicht knot-resolver, da ist nur eine Systemd-Service-
Datei drin)

Das ist grundsätzlich auch bei Debian so möglich, da bin ich fast
vollkommen sicher.

Bei allem Respekt Sven, gerade in Bezug auf deine üblicherweise gut
fundierten Beiträge… bitte informiere dich hier erst mal, bevor du Dinge
vom Stapel lässt, die so sachlich einfach nicht zutreffen.

Selbst mein Musik-Laptop läuft mittlerweile ohne Systemd.

Und… es läuft einfach, ohne merkwürdige Effekte, ohne einen extrem frühen
Bedarf an Zufallszahlen für die UUID-Erstellung, für das Erstellen von
SSH-Keys, falls nicht vorhanden, dann natürlich schon, ohne einen Haufen
der CVEs von Systemd, darunter aus meiner Sicht schon einige arge
Knaller, ohne merkwürdiges Verhalten, falls ein Dateisystem nicht mal
nicht mounten lässt, ohne dass ich "nofail" in der /etc/fstab stehen hab
und… ohne eine ganze Reihe an weiteren Merkwürdigen, die mir in der Zeit
mit Systemd aufgefallen sind. Also eben ohne die ganze Policy – so ist
das richtig, und nur so und zwar für alle –, die in Systemd hart rein
kodiert ist. Außerdem bootet es gefühlt genauso schnell und fährt das
Laptop gefühlt auch genauso schnell runter.

Komfortverlust dadurch? Nahezu nicht vorhanden. Nur Pulseaudio starte
ich derzeit manuell bzw. mit Runit, da es Plasma ohne Präsenz von
Systemd nicht automatisch mit startete, was mich ehrlich gesagt etwas
verwunderte, da Plasma als Desktop-Umgebung grundsätzlich ohne feste
Abhängigkeiten zu Systemd oder sogar systemd-logind auskommt und
grundsätzlich sogar noch mit ConsoleKit 2 funktionieren würde. Unter
anderem, da es auch unter FreeBSD läuft.

Ja, ich hab bestimmte Befehle nicht, die an sich ganz nett sind… aber
ganz ehrlich: Bislang habe ich Systemd nicht so richtig vermisst. Und
dem Plasma oder dem Dovecot oder dem Apache ist das schnurz piep egal,
was für ein Prozess als PID 1 läuft.

Und ich hab das hier:

% ls -l /sbin/init
-rwxr-xr-x 1 root root 53176 Aug 24 16:46 /sbin/init

Schöne Übersichtliche ca. 50 KiB für PID 1.

Ganz ehrlich: Ich mag das.

Und wer Systemd mag, kann den auch haben. So stelle ich mir persönlich
ein universelles Betriebssystem vor und ich bin froh, dass ich das auch
mit Debian Unstable so ziemlich ohne Weiteres noch haben kann.


Und ich kann PID 1 auch nicht mit 3-10 SIGILL-Signalen hintereinander
ins Nirvana befördern, wie das zumindest bis vor ca. einem Monat mit
Debian 9 noch ohne Weiteres möglich war. Das haben Teilnehmer in einer
Linux-Schulung herausgefunden. Ich war da selbst ziemlich erstaunt,
konnte das aber ohne Weiteres mehrfach reproduzieren. Aufgrund meiner
Erfahrungen mit Fehlerberichten zu Systemd habe ich mir erspart, dazu
einen Bugreport einzureichen. Es ist mir ehrlich gesagt auch
mittlerweile egal. Aber fühle Dich frei das zu tun, sofern Du das
nachvollziehen kannst.

while true; do kill -ILL 1 ; sleep 1 ; done

sollte recht schnell zu einem Totalabsturz des Systems führen, während
Sysvinit das schnurz piep egal ist. Ich hab nicht getestet, inwiefern
das unter Debian 10 immer noch geht. Warum Systemd da abkachelt, habe
ich nicht untersucht und es interessiert mich auch nicht. Ich bin der
Meinung gerade PID 1 sollte Signale ignorieren, für die es sich nicht
interessiert.

Vielen Dank,
--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Martin Steigerwald
In reply to this post by Paul Muster-21
Hi Paul

Paul Muster - 06.09.19, 17:32:13 CEST:

> einige meiner Systeme laufen nach wie vor ohne systemd. Sichergestellt
> wird das durch diese Konfiguration:
>
> system:~# cat /etc/apt/preferences.d/no-systemd
> Package: systemd-sysv
> Pin: release o=Debian
> Pin-Priority: -1
> system:~#
>
> Wird das mit Buster weiterhin funktionieren? Oder gehen die
> Debian-Entwickler mittlerweile davon aus, dass alle Systeme mit
> systemd laufen?

Das funktioniert mit Debian Sid ganz hervorragend, siehe meine Antwort
auf Sven's Antwort. Mit Debian Buster müsste das auch tun, wobei es
eventuell in Bezug auf die elogind-Geschichte ein paar Einschränkungen
gibt. Ich denke aber es müsste grundsätzlich funktionieren.

Und falls nicht, könntest du dann auch Devuan Beowulf verwenden. Die
Devuan-Entwickler werden sicherstellen, dass es funktioniert.

Achja, die von mir in der anderen Mail erwähnten Server laufen beide
bereits mit Devuan Beowulf, auch wenn es offiziell noch nicht veröffentlich
ist. Aber die Grundlage Debian Buster ist es ja.

Ciao,
--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Martin Steigerwald
In reply to this post by Paul Muster-21
Paul Muster - 06.09.19, 17:32:13 CEST:

> einige meiner Systeme laufen nach wie vor ohne systemd. Sichergestellt
> wird das durch diese Konfiguration:
>
> system:~# cat /etc/apt/preferences.d/no-systemd
> Package: systemd-sysv
> Pin: release o=Debian
> Pin-Priority: -1
> system:~#
>
> Wird das mit Buster weiterhin funktionieren? Oder gehen die
> Debian-Entwickler mittlerweile davon aus, dass alle Systeme mit
> systemd laufen?

Einen Zusatz habe ich noch, und da ich immer noch nicht meine Mail an
die Liste zurück hab, eben als weitere Mail:

Der Umstieg auf elogind ist derzeit nicht ganz trivial. Der Umstieg von
Systemd auf Sysvinit ohne eine vorhandene auf systemd-logind angewiesene
Desktop-Umgebung erst zu entfernen und dann wieder zu installieren auch
nicht… da eine Deinstallation von Systemd bei laufendem Systemd mit
einer harten Fehlermeldung abbricht und um Extremfall das System durch
eine Eigenheit, wie apt diese Situation handhabt, das System ohne eine
lauffähige libsystemd oder eben die elogind-basierte Alternative
zurückbleiben kann. Dazu sind gerade mehrere Bugreports offen.

Da dein System aber ohnehin bereits mit Sysvinit läuft sollte das kein
Problem sein. Und möglicherweise hat du Systemd oder zumindest
libsystemd0 ohnehin weiterhin installiert. Es geht in Debian Buster und
Debian Sid grundsätzlich auch ohne diese beiden Pakete. So läuft mein
Debian Sid ja bereits seit Monaten. Ich hab auch kein Pinning dazu aktiv
und bislang haben apt oder aptitude nicht versucht, wieder systemd zu
installieren.

--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Sven Hartge-5
In reply to this post by Martin Steigerwald
Martin Steigerwald <[hidden email]> wrote:

> Sorry, wenn das etwas wie ein Rant ausfällt, aber da waren einfach zu
> viele Stellen in deiner Antwort, wo ich den Eindruck hatte, dass Du
> einfach nicht weißt, was im Bereich Sysvinit gerade Phase ist.

Das ist falsch, siehe unten.

> Sven Hartge - 06.09.19, 19:57:19 CEST:
>> Paul Muster <[hidden email]> wrote:
>> > einige meiner Systeme laufen nach wie vor ohne systemd.
>> > Sichergestellt wird das durch diese Konfiguration:
>> >
>> > system:~# cat /etc/apt/preferences.d/no-systemd
>> > Package: systemd-sysv
>> > Pin: release o=Debian
>> > Pin-Priority: -1
>> > system:~#
>> >
>> > Wird das mit Buster weiterhin funktionieren? Oder gehen die
>> > Debian-Entwickler mittlerweile davon aus, dass alle Systeme mit
>> > systemd laufen?
>>
>> Offiziell nicht.
>>
>> Aber du hast natürlich das offensichtliche Problem, das der Code,
>> welcher nicht-systemd-Systeme unterstützt mit der Zeit vom Bitrot
>> heimgesucht wird, weil er nicht mehr wirklich weiter gepflegt wird.

> sysvinit, startpar, insserv und einige weitere erfahren seit einiger
> Zeit intensive Pflege in Debian. Ich hab vor einiger Zeit dabei mit
> geholfen, dass eine Zusammenarbeit zwischen Debian und Devuan-Entwickler
> entstand (Debian Init Diversity). Und ich würde sagen, die war bisher
> äußerst produktiv.

Du mißverstehst mich.

Ich meine nicht den SysV-Init-Code selbst, sondern den Code, der
sich in Pakete und Programmen befindet, wie z.B. Init-Scripte selbst
oder auch nur der Glue-Code, der in Paketen oder an andere Stelle
benötigt wird, um mit SysV-Init zu interagieren.

Das gerade erneuerte Energien in die SysV-Init-Tools gesteckt werden,
weiß ich sehr wohl, ich lese debian-devel.

Das ändert aber leider nichts an der Tatsache, das außerhalb der Blase
der Init-System-Entwicklung die Entscheidung pro-systemd schon längst
gefallen ist.

> Mit allem Respekt, Sven, hier von Bitrot zu sprechen… das trifft so aus
> meiner Beobachtung heraus einfach nicht zu.

Wie gesagt, ich meine den Bitrot an anderer Stelle und mitnichten in
SysV-Init selbst.

Ich selbst erlebe gerade, wie Hersteller von (proprietärer) Software nur
noch systemd unterstützen und gar keine SysV-Initscripte mehr mitliefern
oder, in einem Fall, gar nicht mehr ohne systemd-Features funktioneren
wollen, weil bestimmte Funktionen aus dem eigenen Code entfernt und
durch die externe systemd-Implementierung ersetzt werden.

Den Rest deines Rants snippe ich einfach einmal, da deine Aussagen auf
einem grundlegenden Mißverständnis meiner Aussage basieren.

S!

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Kai Herlemann-2
In reply to this post by Martin Steigerwald
Moin,

Am 06.09.19 um 21:39 schrieb Martin Steigerwald:

> Und falls nicht, könntest du dann auch Devuan Beowulf verwenden. Die
> Devuan-Entwickler werden sicherstellen, dass es funktioniert.
>
> Achja, die von mir in der anderen Mail erwähnten Server laufen beide
> bereits mit Devuan Beowulf, auch wenn es offiziell noch nicht veröffentlich
> ist. Aber die Grundlage Debian Buster ist es ja.

mh – ich steh zu Devuan etwas skeptisch, da es aufgrund der kleineren
Entwicklergemeinschaft und Userschar potenziell mehr Fehler enthält,
auch wenn das meiste wahrscheinlich auf Debian aufbaut.

Wie siehst du das?

Gruß,
Kai


Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Martin Steigerwald
Hi Kai.

Kai Herlemann - 06.09.19, 22:26:31 CEST:

> Am 06.09.19 um 21:39 schrieb Martin Steigerwald:
> > Und falls nicht, könntest du dann auch Devuan Beowulf verwenden. Die
> > Devuan-Entwickler werden sicherstellen, dass es funktioniert.
> >
> > Achja, die von mir in der anderen Mail erwähnten Server laufen beide
> > bereits mit Devuan Beowulf, auch wenn es offiziell noch nicht
> > veröffentlich ist. Aber die Grundlage Debian Buster ist es ja.
>
> mh – ich steh zu Devuan etwas skeptisch, da es aufgrund der kleineren
> Entwicklergemeinschaft und Userschar potenziell mehr Fehler enthält,
> auch wenn das meiste wahrscheinlich auf Debian aufbaut.
>
> Wie siehst du das?

99% ist Debian, daher mache ich mir da nicht mehr all zu viel Gedanken.
Ich habe am Anfang durchaus gezögert, aber nach mittlerweile zwei Devuan
Veröffentlichungen und einen Einblick in deren Community sehe ich, dass
da Menschen am Werk sind, die durchaus entschlossen sind, das weiter zu
machen.

Allerdings gab es ab und zu Probleme damit, Updates aus Debian
rechtzeitig zu integrieren. Da gab es wohl Schwierigkeiten mit dem dazu
verwendeten Amprolla, einer Eigen-Entwicklung der Devuan-Entwickler.

Mehr möchte ich dazu nicht schreiben, da hier an sich Off Topic.

Ciao,
--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Martin Steigerwald
In reply to this post by Sven Hartge-5
Sven Hartge - 06.09.19, 22:12:06 CEST:
> Martin Steigerwald <[hidden email]> wrote:
[…]

> > Sven Hartge - 06.09.19, 19:57:19 CEST:
> >> Paul Muster <[hidden email]> wrote:
> >> > einige meiner Systeme laufen nach wie vor ohne systemd.
> >> > Sichergestellt wird das durch diese Konfiguration:
> >> >
> >> > system:~# cat /etc/apt/preferences.d/no-systemd
> >> > Package: systemd-sysv
> >> > Pin: release o=Debian
> >> > Pin-Priority: -1
> >> > system:~#
> >> >
> >> > Wird das mit Buster weiterhin funktionieren? Oder gehen die
> >> > Debian-Entwickler mittlerweile davon aus, dass alle Systeme mit
> >> > systemd laufen?
> >>
> >> Offiziell nicht.
> >>
> >> Aber du hast natürlich das offensichtliche Problem, das der Code,
> >> welcher nicht-systemd-Systeme unterstützt mit der Zeit vom Bitrot
> >> heimgesucht wird, weil er nicht mehr wirklich weiter gepflegt wird.
> >
> > sysvinit, startpar, insserv und einige weitere erfahren seit einiger
> > Zeit intensive Pflege in Debian. Ich hab vor einiger Zeit dabei mit
> > geholfen, dass eine Zusammenarbeit zwischen Debian und
> > Devuan-Entwickler entstand (Debian Init Diversity). Und ich würde
> > sagen, die war bisher äußerst produktiv.
>
> Du mißverstehst mich.
>
> Ich meine nicht den SysV-Init-Code selbst, sondern den Code, der
> sich in Pakete und Programmen befindet, wie z.B. Init-Scripte selbst
> oder auch nur der Glue-Code, der in Paketen oder an andere Stelle
> benötigt wird, um mit SysV-Init zu interagieren.
>
> Das gerade erneuerte Energien in die SysV-Init-Tools gesteckt werden,
> weiß ich sehr wohl, ich lese debian-devel.
>
> Das ändert aber leider nichts an der Tatsache, das außerhalb der Blase
> der Init-System-Entwicklung die Entscheidung pro-systemd schon längst
> gefallen ist.

Das sehe ich etwas differenzierter. Auf meinen Devuan-Server habe ich
bislang nur bei Knot Resolver gesehen.

> Ich selbst erlebe gerade, wie Hersteller von (proprietärer) Software
> nur noch systemd unterstützen und gar keine SysV-Initscripte mehr
> mitliefern oder, in einem Fall, gar nicht mehr ohne systemd-Features
> funktioneren wollen, weil bestimmte Funktionen aus dem eigenen Code
> entfernt und durch die externe systemd-Implementierung ersetzt
> werden.

Proprietäre Software interessiert mich für meine eigenen privat
genutzten Server nicht. Im Unternehmensumfeld… ja sehe ich das durchaus
als Herausforderung. Dort nutze ich Debian mit Systemd, habe in den
Kursen auch als für Teilnehmer verfügbare VM-Vorlagen aber mittlerweile
Devuan mit drinnen, und habe auch vor die Sysvinit-Folien erst mal
weiterhin bereit zu stellen.

Und auch hier gibt es weiterhin Hersteller, die beides anbieten. So
haben sämtliche Pakete des Elastic Stacks beides und es gibt da mit ich
glaube das heißt pleaserun ein Framework, das automatisch Systemd-
Dateien und Init-Skripte erzeugt. Die nutzen das nämlich.

Es gibt auch einige Hoster, die Devuan anbieten, und auch Unternehmen,
die damit arbeiten. Vielleicht nicht viele, aber einige.

Ich sehe Sysvinit viel weniger als eine Blase als Systemd. Ein Thema,
das ich mit Systemd habe, ist ja gerade der Anspruch, ja, ich würde
sagen, die Arroganz einiger Upstream-Entwickler den heiligen Gral
gefunden zu haben. So habe ich das zumindest interpretiert, was ich da
selbst an Reaktionen auf Bugreports gesehen hab und wovon ich gelesen
hab.

> Den Rest deines Rants snippe ich einfach einmal, da deine Aussagen auf
> einem grundlegenden Mißverständnis meiner Aussage basieren.

Nur teilweise. Ich bin durchaus auch darauf eingegangen, was meine
Erfahrungen sind, wie gut unter *Debian* bzw. Devuan, gängige Dienste
noch mit Sysvinit funktionieren. Und da ist bislang meine Erfahrung,
dass sehr vieles einfach funktioniert.

Ciao,
--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Sven Hartge-5
Martin Steigerwald <[hidden email]> wrote:

> Nur teilweise. Ich bin durchaus auch darauf eingegangen, was meine
> Erfahrungen sind, wie gut unter *Debian* bzw. Devuan, gängige Dienste
> noch mit Sysvinit funktionieren. Und da ist bislang meine Erfahrung,
> dass sehr vieles einfach funktioniert.

Das ist auch meine Erfahrung. Vieles funktioniert (noch) mit systemd.
(Wenn man Dinge in bestimmten Desktop-Environments, die sich stark an
systemd angekoppelt haben, mal wegnimmt.)

Mit Betonung auf "noch". Ich bin da leider ein wenig pessimistischer,
das die Zukunft angeht, egal wieviel Arbeit in die Erneuerung,
Weiterentwicklung und Aufrechterhaltung der anderen Init-Systeme angeht.

Wenn man sich einmal ansieht, seit wann systemd erst wirklich in der
Breite Verwendung findet und was in der kurzen Zeit sich bereits in
dessen Richtung verschoben hat, versteht man hoffentlich meinen
Pessimismus.

Debian Stretch (2017) war das erste Debian Release mit vollem system Support
(Jessie hatte ja nur eine Tech-Demo.), Buster (2019) ist das zweite Release.

Ubuntu LTS selbst hat mit 16.04 (2016) das erste systemd-basierte Release
gehabt.

RHEL 6 hat noch Upstart benutzt, erst RHEL 7 (2014) verwendet systemd.

SLES 11 hatte noch SysV-Init, SLES 12 (2014) verwendet systemd.

SLES 12 und RHEL 7 haben damit zwar theoretisch die Nase vorn, aber
meiner Erfahrung nach mit Software, die SLES oder RHEL benutzt, wurde
bis ~2016/17 noch fast immer nur der Vorgänger als unterstützte Version
für den Produktionsbetrieb supported.

Alles zusammen kann man meiner Ansicht nach sagen, dass systemd in der
großen Breite erst ab Mitte/Ende 2016 eingesetzt wurde.

Und in den drei/zwei Jahren seitdem hat systemd doch mehr Umwälzungen
erzeugt wie alle andern Init-Systeme in 30 Jahren vorher.

Daher meine Aussage von "noch" von weiter oben.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Marc Haber-14
On Sat, 7 Sep 2019 12:24:47 +0200, Sven Hartge <[hidden email]>
wrote:
>RHEL 6 hat noch Upstart benutzt, erst RHEL 7 (2014) verwendet systemd.

Und zwar sehr konsequent: Ein RHEL 7 Standardsystem hat nach der
Installation exakt Null legacy initscripts. Das hat mich sehr
beeindruckt. Debian dagegen verbrennt weiterhin die Zeit freiwilliger
Entwickler mit der Forderung nach Support für Initscripts.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Sven Hartge-5
Marc Haber <[hidden email]> wrote:
> On Sat, 7 Sep 2019 12:24:47 +0200, Sven Hartge <[hidden email]> wrote:

>> RHEL 6 hat noch Upstart benutzt, erst RHEL 7 (2014) verwendet
>> systemd.

> Und zwar sehr konsequent: Ein RHEL 7 Standardsystem hat nach der
> Installation exakt Null legacy initscripts. Das hat mich sehr
> beeindruckt. Debian dagegen verbrennt weiterhin die Zeit freiwilliger
> Entwickler mit der Forderung nach Support für Initscripts.

Das ist halt der deutliche Unterschied zwischen einer firmengetriebenen
und einer Community Distribution.

Red Hat hat halt gesagt "Keine Initscripte mehr! Umsetzen!" und damit
war das Thema dann durch.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Marc Haber-14
On Sat, 7 Sep 2019 14:18:33 +0200, Sven Hartge <[hidden email]>
wrote:

>Marc Haber <[hidden email]> wrote:
>> On Sat, 7 Sep 2019 12:24:47 +0200, Sven Hartge <[hidden email]> wrote:
>
>>> RHEL 6 hat noch Upstart benutzt, erst RHEL 7 (2014) verwendet
>>> systemd.
>
>> Und zwar sehr konsequent: Ein RHEL 7 Standardsystem hat nach der
>> Installation exakt Null legacy initscripts. Das hat mich sehr
>> beeindruckt. Debian dagegen verbrennt weiterhin die Zeit freiwilliger
>> Entwickler mit der Forderung nach Support für Initscripts.
>
>Das ist halt der deutliche Unterschied zwischen einer firmengetriebenen
>und einer Community Distribution.
>
>Red Hat hat halt gesagt "Keine Initscripte mehr! Umsetzen!" und damit
>war das Thema dann durch.

Richtig. Das ist einer der Gründe, warum Debian nicht mehr
technologisch führend ist, sondern nur noch das - besser! - nachbaut,
was Red Hat entschieden hat.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Sven Hartge-5
Marc Haber <[hidden email]> wrote:
> On Sat, 7 Sep 2019 14:18:33 +0200, Sven Hartge <[hidden email]> wrote:
>> Marc Haber <[hidden email]> wrote:
>>> On Sat, 7 Sep 2019 12:24:47 +0200, Sven Hartge <[hidden email]> wrote:

>>>> RHEL 6 hat noch Upstart benutzt, erst RHEL 7 (2014) verwendet
>>>> systemd.
>>
>>> Und zwar sehr konsequent: Ein RHEL 7 Standardsystem hat nach der
>>> Installation exakt Null legacy initscripts. Das hat mich sehr
>>> beeindruckt. Debian dagegen verbrennt weiterhin die Zeit
>>> freiwilliger Entwickler mit der Forderung nach Support für
>>> Initscripts.
>>
>> Das ist halt der deutliche Unterschied zwischen einer
>> firmengetriebenen und einer Community Distribution.
>>
>> Red Hat hat halt gesagt "Keine Initscripte mehr! Umsetzen!" und damit
>> war das Thema dann durch.

> Richtig. Das ist einer der Gründe, warum Debian nicht mehr
> technologisch führend ist, sondern nur noch das - besser! - nachbaut,
> was Red Hat entschieden hat.

Irgendwann, mit zunehmender Größe, kehrt sich die flache bzw. nicht
vorhandene Hierarchie einer Community Distribution gegenüber den
Entscheidungsebenen einer gewinn- und businessorientierten Firma halt
um.

Wenn du ein so großer Player wie Red Hat bist, dann hast du halt immer
eine Mindestmenge an Personen(gruppen), die Entscheidungen fällen,
bewerten und absegnen müssen. Immerhin muss Red Hat mit einer einmal
getroffenen Entscheidung mehr wie 10 Jahre leben, das erzeugt Overhead.

Allerdings hast du halt auch den Vorteil, das diese Personen(gruppen)
dann Entscheidungsgewalt haben und sagen können, wo es lang geht.

Eine Community Distribution kann bestimmte Dinge schneller entscheiden
und umsetzen, bis zu einer bestimmten Größe. Sobald eine kritische Menge
allerdings überschritten ist, tritt eine interne Fragmentation in
kleinere Gruppierungen auf, deren (Nicht)Interaktion dann einen
Lähmungseffekt hat. Dazu dann noch im Falle von Debian ein fehlendes
Organ, das Entscheidungen treffen und durchsetzen kann und du hast die
Situation von heute.

S!

--
Sigmentation fault. Core dumped.

Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Martin Steigerwald
In reply to this post by Sven Hartge-5
Sven Hartge - 07.09.19, 12:24:47 CEST:

> Martin Steigerwald <[hidden email]> wrote:
> > Nur teilweise. Ich bin durchaus auch darauf eingegangen, was meine
> > Erfahrungen sind, wie gut unter *Debian* bzw. Devuan, gängige
> > Dienste
> > noch mit Sysvinit funktionieren. Und da ist bislang meine Erfahrung,
> > dass sehr vieles einfach funktioniert.
>
> Das ist auch meine Erfahrung. Vieles funktioniert (noch) mit systemd.
> (Wenn man Dinge in bestimmten Desktop-Environments, die sich stark an
> systemd angekoppelt haben, mal wegnimmt.)
>
> Mit Betonung auf "noch". Ich bin da leider ein wenig pessimistischer,
> das die Zukunft angeht, egal wieviel Arbeit in die Erneuerung,
> Weiterentwicklung und Aufrechterhaltung der anderen Init-Systeme
> angeht.

Auch wenn es zeitweise ein ziemlich anstrengender Weg war bislang, habe
ich mich dafür entschieden, so gut ich kann, meine Zukunft selbst zu
gestalten, anstatt irgendwelchen Anderen Macht darüber zu geben.

Mit einer ähnlichen Argumentation wie der deinen könnte ich auch in
Bezug auf Klimawandel, Überwachungsstaat, Überwachungskapitalismus
(Facebook, Google und Co) und viele andere Entwicklungen, die ich
kritisch sehe, den Kopf in den Sand stecken.

So oder so, ich halte es für müßig zu spekulieren, wie die Zukunft
aussehen wird und nutze den Einfluss den ich habe, selbst zu gestalten,
so gut ich eben kann. Für mich hat Devuan sogar genau das, was mir bei
Debian auch teilweise fehlt: Den Charme eines kleinen Community-
Projektes. Und ja, mir ist klar, ohne Debian würde es Devuan nicht
geben. Und ich bin sehr dankbar für Debian und alle, die etwas dazu
beitragen.

--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Martin Steigerwald
In reply to this post by Marc Haber-14
Marc Haber - 08.09.19, 14:23:34 CEST:
> >Das ist halt der deutliche Unterschied zwischen einer
> >firmengetriebenen und einer Community Distribution.
> >
> >Red Hat hat halt gesagt "Keine Initscripte mehr! Umsetzen!" und damit
> >war das Thema dann durch.
>
> Richtig. Das ist einer der Gründe, warum Debian nicht mehr
> technologisch führend ist, sondern nur noch das - besser! - nachbaut,
> was Red Hat entschieden hat.

Für mich ist das eine Frage der Perspektive.

In Bezug auf Wahlfreiheit ist Debian für mich gegenüber um Längen
gegenüber vielen anderen Distributionen weit vorne. Denn bei Debian habe
ich diese noch in wesentlichen Aspekten (Init System, Netzwerk-
Konfiguration und einiges weitere mehr), wo ich die bei RHEL nicht mehr
habe oder gar nie hatte. Für mich ist das ein wichtiger Aspekt, da mir,
je mehr ich mit freier Software Arbeit eben genau dieser Aspekt der
Freiheit immer wichtiger geworden ist.


Was ich auch sehe ist, dass viele Upstream-Entwickler bei Red Hat
arbeiten, und das eben auch an den Upstream-Projekten. Bezahlt. Es gibt
bei Debian auch Entwickler, die bei Upstream-Projekten mit helfen, unter
anderem einige im Debian/Kubuntu Qt/KDE Team. Jedoch ist das bei diesen
Entwicklern in der Regel neben bezahlter Job und der Debian-Arbeit. Da
dürfte deutlich weniger Zeit dafür bleiben als bei zumindest teilweise
bezahlter Upstream-Arbeit. Manchmal paketieren Upstream-Entwickler als
Debian-Entwickler auch gleich für Debian, das dürfte auf andere
Distributionen jedoch ebenso zutreffen.

Kurz gefasst: Neben hierarchischer Entscheidungs-Strukturen spielt hier
noch etwas Anderes mit. Geld. Und zwar Einiges an Geld. Und in Zukunft
wahrscheinlich noch mehr Geld, nachdem IBM Red Hat gekauft hat.

Da kommen ja auch einige nette Entwicklungen bei raus: z.B. die
Weiterentwicklung von Chrony, meinen bevorzugtem NTP-Dienst, oder das
neue Pipewire. Wobei das mal interessant ist, da ich da in der Tat
vermute, dass von Seiten des Upstream-Projektes Sysvinit keine Rolle
spielt. Aber das startet ja wahrscheinlich die Desktop-Umgebung via
DBUS. Und da einige Desktop-Umgebungen auch für FreeBSD und teilweise,
zumindest was einige Anwendungen betrifft, für FreeBSD und Co sowie Mac
OS X und Windows verfügbar sind, gehe ich davon aus, dass sich Pipewire
auch ohne Systemd betreiben lassen wird. Auch für diese bezahlte
Upstream-Arbeit bin ich dankbar und ich sehe, wie auch Debian von
zumindest einem Teil davon einen Nutzen hat.


Es ist leicht hier zu vereinfachen, und

1. von einer technologischen Führung durch Red Hat auszugehen und

2. diese dann an einem Aspekt – hier hierarchische
Entscheidungsstrukturen – fest zu machen.

Allerdings treffen solche einfachen Erklärungen oft eben allenfalls
teilweise zu.


Da ich davon ausgehe, dass wir (teilweise) bei unterschiedlichen
Ansichten bleiben, erkläre ich hier meine Bereitschaft, das einfach so
sein zu lassen ("agree to disagree"). Möglicherweise ist das mein
letzter Beitrag zu diesem Diskussionsfaden.

Ciao,
--
Martin


Reply | Threaded
Open this post in threaded view
|

AqBanking und die PSD2

Helge Reimer
In reply to this post by Martin Steigerwald
Hallo,

am 14. September ist offizieller Starttermin der PSD2, der neuen Richtlinien für
Zahlungsdienste.
Viele Banken haben schon umgestellt und die restlichen werden noch folgen. Bei
meiner Bank ist seit einigen Tagen bei jedem Login zum Onlinebanking eine 2-
Faktor-Authentifizierung  notwendig. So weit kein Problem. Ist eingerichtet und
funktioniert.

Das Problem ist, daß Finanzsoftware wie 'KMyMoney' oder 'GnuCash' die  
Homebanking-Bibliothek 'AqBanking'  benötigt.
'AqBanking' in Debian sid liegt in der Version 5.8.2-0.1 vor. Diese Version
unterstützt unter anderem kein 2FA.
Onlinebanking ist mit Debian also erstmal nicht mehr möglich. Das ist sehr
ärgerlich.
Vor einigen Tagen wurde 'AqBanking 5.99.25beta' veröffentlicht. Diese Version
ist vorbereitet für PSD2 und somit auch dem 2FA beim Login.

Ist dem Paketbetreuer von 'AqBanking', Micha Lenk, dieses Problem bekannt?
Kann ich herausfinden, ob bereits an einer Paketierung von 'AqBanking
5.99.25beta' gearbeitet wird?
Kann ich irgendwie sinnvoll aktiv werden, oder nur abwarten und Tee trinken?


--
Gruß
Helge


Reply | Threaded
Open this post in threaded view
|

Re: AqBanking und die PSD2

Helge Reimer
Sorry.
Das sollte hier nicht hin.


--
Gruß
Helge


Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Paul Muster-21
In reply to this post by Martin Steigerwald
Am 06.09.2019 um 21:58 schrieb Martin Steigerwald:
> Paul Muster - 06.09.19, 17:32:13 CEST:

>> einige meiner Systeme laufen nach wie vor ohne systemd. Sichergestellt
>> wird das durch diese Konfiguration:
>>
>> system:~# cat /etc/apt/preferences.d/no-systemd
>> Package: systemd-sysv
>> Pin: release o=Debian
>> Pin-Priority: -1
>> system:~#
>>
>> Wird das mit Buster weiterhin funktionieren? Oder gehen die
>> Debian-Entwickler mittlerweile davon aus, dass alle Systeme mit
>> systemd laufen?
>
> Einen Zusatz habe ich noch, und da ich immer noch nicht meine Mail an
> die Liste zurück hab, eben als weitere Mail:
>
> Der Umstieg auf elogind ist derzeit nicht ganz trivial. Der Umstieg von
> Systemd auf Sysvinit ohne eine vorhandene auf systemd-logind angewiesene
> Desktop-Umgebung erst zu entfernen und dann wieder zu installieren auch
> nicht… da eine Deinstallation von Systemd bei laufendem Systemd mit
> einer harten Fehlermeldung abbricht und um Extremfall das System durch
> eine Eigenheit, wie apt diese Situation handhabt, das System ohne eine
> lauffähige libsystemd oder eben die elogind-basierte Alternative
> zurückbleiben kann. Dazu sind gerade mehrere Bugreports offen.
>
> Da dein System aber ohnehin bereits mit Sysvinit läuft sollte das kein
> Problem sein. Und möglicherweise hat du Systemd oder zumindest
> libsystemd0 ohnehin weiterhin installiert. Es geht in Debian Buster und
> Debian Sid grundsätzlich auch ohne diese beiden Pakete. So läuft mein
> Debian Sid ja bereits seit Monaten. Ich hab auch kein Pinning dazu aktiv
> und bislang haben apt oder aptitude nicht versucht, wieder systemd zu
> installieren.

Hmm, hmm, hmmm. Meinen Laptop hat es beim Upgrade (von Stretch auf
Buster) ziemlich auf den Rücken gelegt.

Trotz des o.g. Pinnings wurde beim 'apt full-upgrade' systemd-sysv
installiert (und am Ende gestartet). Rebootet habe ich noch nicht, weil
ich nicht den Eindruck habe, dass das System sauber ist und wieder
hochkommt:

Letztendlich läuft es meinem Verständnis dessen, was aptitude* anzeigt,
darauf hinaus, dass libpam-systemd von systemd und systemd-sysv abhängt
und seinerseits von udisks2, policykit-1 und network-manager verlangt
wird. Einen Ansatzpunkt, hier wieder bzw. weiterhin mit sysvinit-core zu
arbeiten (und - das ließ sich m.W. schon in Stretch nicht vermeiden -
systemd-shim), kann ich nicht finden.

Ideen?

* Ja, aptitude verwende ich hier aufgrund der Vorschläge zur Auflösung
von Abhängigkeitsproblemen. Hoffe, das ist nicht Ursache des Problems.

Danke & viele Grüße

Paul

Reply | Threaded
Open this post in threaded view
|

Re: Buster ohne systemd

Ansgar Burchardt-8
Paul Muster writes:
> Letztendlich läuft es meinem Verständnis dessen, was aptitude*
> anzeigt, darauf hinaus, dass libpam-systemd von systemd und
> systemd-sysv abhängt und seinerseits von udisks2, policykit-1 und
> network-manager verlangt wird. Einen Ansatzpunkt, hier wieder
> bzw. weiterhin mit sysvinit-core zu arbeiten (und - das ließ sich
> m.W. schon in Stretch nicht vermeiden -
> systemd-shim), kann ich nicht finden.

In Debian 10 wird als logind als einziges Backend für policykit-1
unterstützt.

> Ideen?

Upgrade auf systemd oder kein policykit verwenden.

Ansgar

12