[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Systemd-Zwang in Debian (war: Re: Debian Jessie => Stretch ... Und Tschüss)



Marc Haber - 20.06.17, 21:33:
> On Tue, 20 Jun 2017 20:21:26 +0200, Martin Steigerwald
> 
> <martin@lichtvoll.de> wrote:
> >Marc Haber - 20.06.17, 11:53:
> >> Das kann ich nicht bestätigen. Ich arbeite täglich mit einem T520 und
> >> habe ein zweites als Virtualisierungs-Server nicht ganz ohne Last im
> >> Testlabor stehen, das tut und ist auch stabil.
> >
> >Ich teste neuere Kernel als Kernel 4.9.
> 
> Ich benutze stets den aktuellen Stable-Vanilla-Kernel von Greg,
> aktuell 4.11.6.

Das ist interessant. Ich hab 4.11.3 und damit gab es Hänger bei Suspend to 
RAM. Liefen auch frühere Versionen von 4.11 bei Dir schon stabil?

Hast Du irgendwas in /etc/X11/xorg.conf.d wie Aktivieren von DRI3, was mir ein 
Intel-Entwickler mal empfahl? Ich hab da derzeit nix, da ich immer mehr dazu 
tendiere, keine eigenen Anpassungen mehr vorzunehmen. Das Ding ist: Vielleicht 
ist das ja dann erstmal stabil, geht dann aber in einer neuen Version nochmal 
kaputt, und das testen dann ja noch weniger Leute.

Das Folgende hatte ich dann doch wieder gemacht:

merkaba:/etc> cat sysfs.d/intel.conf 
[…]
# Ab Kernel 4.12 dann Standard:
# http://www.phoronix.com/scan.php?page=news_item&px=Intel-Atomic-Default-Change
module/i915/parameters/nuclear_pageflip=1

Hmmm, ich nehme das mal wieder raus, wird ja eh Standard. Und dann probiere 
ich gelegentlich nochmal mit dem aktuellen 4.11.x.

> > Mit dem läuft das weitgehend, bis auf
> >
> >das gelegentlichen Hänger beim Tiefschlafen, wahrscheinlich noch beim
> >Einfrieren der Prozesse, das sollte aber entweder fehlschlagen oder
> >funktionieren, nicht hängen bleiben, oder beim Freigeben von Speicher.
> 
> Ich suspende immer nur ins RAM.

Tagsüber mache ich das auch so… aber wie geschrieben, das klappte dann ja für 
mich mit 4.11 und 4.12 auch nicht.

> >> > Leider sehe ich diese Haltung teilweise auch
> >> > beim Debian-Systemd-Paketbetreuerteam.
> >> 
> >> Nein, das kann ich nicht bestätigen. Martin und Michael sind _sehr_
> >> hilfreich, akzeptieren Bugreports, gehen professionell damit um und
> >> haben mir schon mehr als einmal konstruktiv geholfen, wie ich mein
> >> Ziel trotz systemd wieder erreichen kann. Von den beiden habe ich
> >> dabei mehr gelernt als durch ausgiebige, mehrfache Lektüre der
> >> dankenswerterweise in großem Umfang vorhandenen Dokumentation.
> >
> >Hilfreich ist Michael oft. Das sehe ich ja auch hier. Und mit Martin habe
> >ich bislang kaum Kontakt. Ich sehe auch, dass die beiden ein Spagat
> >zwischen Upstream und Debian-Anwender hinzubekommen zu versuchen.
> >Bisweilen sah ich aber auch da die Tendenz "Das macht Systemd so, also
> >muss das richtig sein". Oder zumindest habe ich die Antwort so gedeutet,
> >die Michael möglicherweise anders gemeint hat. Ich hab Michael auf der
> >Debconf in Heidelberg gesehen und da war ich auch positiv überrascht.
> 
> Vielleicht ist es eher "das ist systemd, wir haben eh keine Chance
> dass Upstream irgendwas ändert oder gar auf uns hört, also machen wir
> das beste draus und helfen den Anwendern, das beste draus zu machen".
> Ein durchaus valider Ansatz; als Distributions-Maintainer muss man
> auch darauf achten, dass man sich das Verhältnis zum Upstream nicht
> verbrennt. Und der Weg zu Herrn Pöttering wäre einer
> Indiana-Jones-Schlußszene würdig.

Hmmm, vielleicht. Ich beneide in der Tat die Paketbetreuer für Systemd in 
Debian nicht um ihren Job und spüre keine Motivation, auch mich nur in die 
Nähe von einem solchen Job zu bewegen.

Ciao,
-- 
Martin


Reply to: