lightdm autostart verhindern

[Marcel Mueller]

Hallo,

wie wird man denn den lightdm autostart los?
Das ganze ist ein Raspberry Pi, und ein unnützer Start von lightdm
kostet schon mal wenigstens 5 Minuten, deshalb möchte ich ihn ggf.
manuell starten.

Ich habe einiges probiert, aber gewirkt hat bisher ausschließlich die
Holzhammermethode: sudo chmod /usr/sbin/lightdm -x
Das ist natürlich totaler Mist, weil man immer erst die Rechte ändern
muss, um ihn zu starten. Aber das ist zumindest besser als vorher.

Was nicht funktioniert, ausnahmslos keine Wirkung:
raspi-config / Choose boot option
sudo update-rc.d lightdm disable
echo "manual" | sudo tee -a /etc/init/lightdm.override

Bekommt man den Burschen auch irgendwie anders los? Der ist ja
hartnäckiger als ein Virus.

Distri ist Raspbian Jessie mit Kernel 3.16.


Marcel

[Andreas Kohlbach]

Ohne Raspberry Pi zu kennen, und auf die Gefahr mich voll ins
Fettnäpfchen zu setzen. Das ist doch Debian? Hat es dann etwas wie
systemd (Jehova!) oder init? Dann müsste vielleicht

service disable lightdm # (bei systemd)

helfen. Oder über update-rc.d sonst.
--
Andreas

I wish my grass was emo. Then it would cut itself.

[Marcel Mueller]

On 02.01.15 22.18, Andreas Kohlbach wrote:
> Ohne Raspberry Pi zu kennen, und auf die Gefahr mich voll ins
> Fettnäpfchen zu setzen. Das ist doch Debian? Hat es dann etwas wie
> systemd (Jehova!) oder init? Dann müsste vielleicht

Also der Tip mit systemd war schon mal gut. Laut log versucht der
derzeit verzweifelt den desinfizierten Dienst zu starten, holt sich
aufgrund meines chmod ein paar mal eine blaue Nase und gibt dann auf.

> service disable lightdm # (bei systemd)

Vmtl. service lightdm disable

Interessiert ihn aber auch nicht. Versucht trotzdem zu starten.

> helfen. Oder über update-rc.d sonst.

Hatten wir auch schon.


Marcel

[Sven Hartge]

Marcel Mueller <news.5...@spamgourmet.org> wrote:
> On 02.01.15 22.18, Andreas Kohlbach wrote:

>> Ohne Raspberry Pi zu kennen, und auf die Gefahr mich voll ins
>> Fettnäpfchen zu setzen. Das ist doch Debian? Hat es dann etwas wie
>> systemd (Jehova!) oder init? Dann müsste vielleicht

> Also der Tip mit systemd war schon mal gut. Laut log versucht der
> derzeit verzweifelt den desinfizierten Dienst zu starten, holt sich
> aufgrund meines chmod ein paar mal eine blaue Nase und gibt dann auf.

>> service disable lightdm # (bei systemd)

> Vmtl. service lightdm disable

> Interessiert ihn aber auch nicht. Versucht trotzdem zu starten.

systemctl disable lightdm.service

S°

--
Sigmentation fault. Core dumped.

[Marc Haber]

Vielleicht mag mich mal jemand erleuchtet, warum das gerade erst
mühsam erlernte service von systemd nicht kompatibel ersetzt wird.
Hier ein bisschen Kompatibilität zu schaffen wäre jetzt sicher keine
Raketenwissenschaft gewesen.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Florian Weimer]

* Marc Haber:

> Vielleicht mag mich mal jemand erleuchtet, warum das gerade erst
> mühsam erlernte service von systemd nicht kompatibel ersetzt wird.

Hat “service … disable” jemals irgendwo funktioniert?

> Hier ein bisschen Kompatibilität zu schaffen wäre jetzt sicher keine
> Raketenwissenschaft gewesen.

Bei Fedora und Downstreams funktioniert “chkconfig … off” (mit Upstart
und systemd).

Bei Debian müßte “update-rc.d … disable” angepaßt werden (falls das
jemand verwendet, das Abschalten von Diensten ist ja nicht gerade die
Stärke von Debians sysvinit-Implementierung).

[Marc Haber]

Florian Weimer <f...@deneb.enyo.de> wrote:
>* Marc Haber:
>> Vielleicht mag mich mal jemand erleuchtet, warum das gerade erst
>> mühsam erlernte service von systemd nicht kompatibel ersetzt wird.
>
>Hat “service … disable” jemals irgendwo funktioniert?

Weiß ich nicht, aber service foo stop funktioniert auf einem
systemd-Debian ja auch nicht mehr.

Grüße

[Jan Heitkötter]

Am 02.01.2015 um 18:37 schrieb Marcel Mueller:
> Was nicht funktioniert, ausnahmslos keine Wirkung:
> raspi-config / Choose boot option
> sudo update-rc.d lightdm disable
> echo "manual" | sudo tee -a /etc/init/lightdm.override
>
> Bekommt man den Burschen auch irgendwie anders los? Der ist ja
> hartnäckiger als ein Virus.

Wenn "choose boot option" ohne Wirkung ist, dann könnte etwas in Jessie
kaputt sein. Hier (Wheezy) funktioniert es nämlich.

Gruß

Jan

[Florian Weimer]

* Marc Haber:

> Florian Weimer <f...@deneb.enyo.de> wrote:
>>* Marc Haber:
>>> Vielleicht mag mich mal jemand erleuchtet, warum das gerade erst
>>> mühsam erlernte service von systemd nicht kompatibel ersetzt wird.
>>
>>Hat “service … disable” jemals irgendwo funktioniert?

> Weiß ich nicht, aber service foo stop funktioniert auf einem
> systemd-Debian ja auch nicht mehr.

Oh, in der Tat. Unter Fedora bzw. Downstream wurde das angepaßt.

Ist die fehlende Anpassung eine Folge der Unterstützung mehrerer
Init-Systeme bei Debian, weil dort “service ≅ sysvinit” gilt?

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>>Marcel Mueller <news.5...@spamgourmet.org> wrote:
>>> On 02.01.15 22.18, Andreas Kohlbach wrote:
>>
>>>> Ohne Raspberry Pi zu kennen, und auf die Gefahr mich voll ins
>>>> Fettnäpfchen zu setzen. Das ist doch Debian? Hat es dann etwas wie
>>>> systemd (Jehova!) oder init? Dann müsste vielleicht
>>
>>> Also der Tip mit systemd war schon mal gut. Laut log versucht der
>>> derzeit verzweifelt den desinfizierten Dienst zu starten, holt sich
>>> aufgrund meines chmod ein paar mal eine blaue Nase und gibt dann auf.
>>
>>>> service disable lightdm # (bei systemd)
>>
>>> Vmtl. service lightdm disable
>>
>>> Interessiert ihn aber auch nicht. Versucht trotzdem zu starten.
>>
>>systemctl disable lightdm.service

> Vielleicht mag mich mal jemand erleuchtet, warum das gerade erst
> mühsam erlernte service von systemd nicht kompatibel ersetzt wird.
> Hier ein bisschen Kompatibilität zu schaffen wäre jetzt sicher keine
> Raketenwissenschaft gewesen.

"service $dienst (start|stop|reload|restart|status)" funktioniert unter
systemd ebenso wie unter SysV-Init oder Upstart, wie man es gewohnt ist.

Das "service $dienst disable" irgendwo existiert, wäre mir neu.

"systemctl disable $dienst" ruft unter Debian auch update-rc.d auf, um
die Änderungen auch für SysV-Init zu erledigen. Ob update-rc.d ebenfalls
systemctl aufruft, habe ich jetzt nicht geprüft.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Florian Weimer <f...@deneb.enyo.de> wrote:
>>* Marc Haber:

>>> Vielleicht mag mich mal jemand erleuchtet, warum das gerade erst
>>> mühsam erlernte service von systemd nicht kompatibel ersetzt wird.
>>
>> Hat “service … disable” jemals irgendwo funktioniert?

> Weiß ich nicht, aber service foo stop funktioniert auf einem
> systemd-Debian ja auch nicht mehr.

Huh? Funktioniert hier mit sowohl einem tagesaktuellen Sid wie auch
einem aktuellen Jessie einwandfrei.

[Florian Weimer]

* Sven Hartge:

>> Weiß ich nicht, aber service foo stop funktioniert auf einem
>> systemd-Debian ja auch nicht mehr.
>
> Huh? Funktioniert hier mit sowohl einem tagesaktuellen Sid wie auch
> einem aktuellen Jessie einwandfrei.

Interessant.

Mit einem aktuellen jessie funktionierte es gestern bei mir für
»unbound« nicht zuverlässig. Ich sehe, daß /usr/sbin/service das
Umschreiben auf “systemctl” macht (was auch funktioniert), also ist
wohl eher die /etc/init.d-Unterstützung von systemd leicht defekt
(unbound wurde nicht über eine .service-Datei geladen).

Moment läuft etwas in der VM, so daß ich das nicht einfach nochmal
nachstellen kann. Mal schauen.

[Sven Hartge]

Florian Weimer <f...@deneb.enyo.de> wrote:
> * Sven Hartge:

>>> Weiß ich nicht, aber service foo stop funktioniert auf einem
>>> systemd-Debian ja auch nicht mehr.
>>
>> Huh? Funktioniert hier mit sowohl einem tagesaktuellen Sid wie auch
>> einem aktuellen Jessie einwandfrei.

> Interessant.

Hier als Beispiel für Apache2, der über kein Unit-File verfügt:

ds9:~# systemctl status apache2
● apache2.service - LSB: Apache2 web server
Loaded: loaded (/etc/init.d/apache2)
Active: active (running) since Mon 2015-01-05 16:48:00 CET; 3h 42min ago
Process: 4289 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/apache2.service
├─ 5676 /usr/sbin/apache2 -k start
├─ 5715 /usr/sbin/apache2 -k start
├─ 9141 /usr/sbin/apache2 -k start
├─18147 /usr/sbin/apache2 -k start
├─22656 /usr/sbin/apache2 -k start
├─29153 /usr/sbin/apache2 -k start
└─32120 /usr/sbin/apache2 -k start

Jan 05 16:47:53 ds9 apache2[4289]: Starting web server: apache2[Mon Jan 05 16:47:53.187139 20...tch.
Jan 05 16:48:00 ds9 apache2[4289]: . . . . . . ..
Jan 05 16:48:00 ds9 systemd[1]: Started LSB: Apache2 web server.
Hint: Some lines were ellipsized, use -l to show in full.
ds9:~# service apache2 restart
ds9:~# systemctl status apache2
● apache2.service - LSB: Apache2 web server
Loaded: loaded (/etc/init.d/apache2)
Active: active (running) since Mon 2015-01-05 20:30:36 CET; 2s ago
Process: 10885 ExecStop=/etc/init.d/apache2 stop (code=exited, status=0/SUCCESS)
Process: 10909 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/apache2.service
├─10923 /usr/sbin/apache2 -k start
├─10926 /usr/sbin/apache2 -k start
├─10928 /usr/sbin/apache2 -k start
├─10929 /usr/sbin/apache2 -k start
└─10933 /usr/sbin/apache2 -k start

Jan 05 20:30:35 ds9 systemd[1]: Starting LSB: Apache2 web server...
Jan 05 20:30:35 ds9 apache2[10909]: Starting web server: apache2[Mon Jan 05 20:30:35.882786 2...tch.
Jan 05 20:30:36 ds9 apache2[10909]: ..
Jan 05 20:30:36 ds9 systemd[1]: Started LSB: Apache2 web server.
Hint: Some lines were ellipsized, use -l to show in full.

[Marc Haber]

Florian Weimer <f...@deneb.enyo.de> wrote:
>Ist die fehlende Anpassung eine Folge der Unterstützung mehrerer

>Init-Systeme bei Debian, weil dort “service ? sysvinit” gilt?

Ich vermute das. Die systemd-"Integration" in Debian ist weniger als
halbgar.

[Marc Haber]

Für tagesaktuelles sid kann ich das bestätigen, wenn man mal die
völlige Abwesenheit von Feedback jeglicher Art außer Acht lässt:

|[1/500]mh@swivel:~$ pgrep named
|3662
|[2/501]mh@swivel:~$ sudo service bind9 stop
|[3/502]mh@swivel:~$ pgrep named
|[4/503]mh@swivel:~$ sudo service bind9 start
|[5/504]mh@swivel:~$ pgrep named
|24872
|[6/505]mh@swivel:~$

Ich ziehe meine Äußerung zurück.

[Kay Martinen]

Am 05.01.2015 um 15:42 schrieb Florian Weimer:
> * Marc Haber:
>
>> Vielleicht mag mich mal jemand erleuchtet, warum das gerade erst
>> mühsam erlernte service von systemd nicht kompatibel ersetzt wird.

K.A. vielleicht wird lightdm nicht als service angesehen? ;)

> Hat “service … disable” jemals irgendwo funktioniert?

Ach, so was gibt es?

>> Hier ein bisschen Kompatibilität zu schaffen wäre jetzt sicher keine
>> Raketenwissenschaft gewesen.

Naja, du weißt doch. Runter kommen sie alle. Nur die frage, in welchem
Zustand. Geplant - oder als Schrott. :)
Ich finde diese systemd debatte unerträglich. Schlimmer noch das man
einem nicht mehr die wahl lassen will welches man haben will - durch
abhängigkeiten zu bestimmten paketen - die m.E. nicht sein müssen.

> Bei Fedora und Downstreams funktioniert “chkconfig … off” (mit Upstart
> und systemd).

iiihhh! Feuer, Mister CheckOFF :-)

>
> Bei Debian müßte “update-rc.d … disable” angepaßt werden (falls das
> jemand verwendet, das Abschalten von Diensten ist ja nicht gerade die
> Stärke von Debians sysvinit-Implementierung).

Würde ich so nicht finden. update-rc.d scheint mir eher zum einrichten
der runlevel in denen ein dienst laufen soll gut zu sein. Mit dem
generellen abschalten hat das eher weniger zu tun.


Seit systemd hab ich keine Detailierteren Blick mehr geworfen aber in
/etc/default finden sich fur die meisten sachen dateien in denen ein
"enable=false" oder ähnliches die gewünschte wirkung haben sollte.

Kay

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Florian Weimer <f...@deneb.enyo.de> wrote:
>>>>* Marc Haber:

>>>>> Vielleicht mag mich mal jemand erleuchtet, warum das gerade erst
>>>>> mühsam erlernte service von systemd nicht kompatibel ersetzt wird.
>>>>
>>>> Hat “service … disable” jemals irgendwo funktioniert?
>>
>>> Weiß ich nicht, aber service foo stop funktioniert auf einem
>>> systemd-Debian ja auch nicht mehr.
>>
>>Huh? Funktioniert hier mit sowohl einem tagesaktuellen Sid wie auch
>>einem aktuellen Jessie einwandfrei.

> Für tagesaktuelles sid kann ich das bestätigen, wenn man mal die
> völlige Abwesenheit von Feedback jeglicher Art außer Acht lässt:

Das irritierte mich auch am Anfang. Man bekommt halt nut $? zurück und
nicht mehr. Für den Rest soll man dann wohl das journal bemühen, welche
die Äußerungen des Init-Scripts oder der Unit beinhaltet, sofern es
welche gibt.

[Kay Martinen]

Am 02.01.2015 um 18:37 schrieb Marcel Mueller:

> Hallo,
>
> wie wird man denn den lightdm autostart los?
> Das ganze ist ein Raspberry Pi, und ein unnützer Start von lightdm
> kostet schon mal wenigstens 5 Minuten, deshalb möchte ich ihn ggf.
> manuell starten.

Warum deinstallierst du ihn dann nicht einfach?

> sudo update-rc.d lightdm disable

update-rc.d versteht/verstand auch mal runlevel...

>
> Bekommt man den Burschen auch irgendwie anders los? Der ist ja
> hartnäckiger als ein Virus.

Nein. Viren sind deutlich kleiner und kompakter Programmiert. :)

> Distri ist Raspbian Jessie mit Kernel 3.16.

Hast du mal versucht den runlevel zu ändern. Also die konfigs so ändern
das du einen runlevel hast in dem lightdm nicht startet und du den zum
default machst?

Ich sehe grade das ich hier auch keine inittab mehr finde. Lange her...
wo das jetzt steht weiß ich auch nicht, tippe aber auf /etc/init/

Kay

[Ralph Aichinger]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ich vermute das. Die systemd-"Integration" in Debian ist weniger als
> halbgar.

Sie ist auch noch die neueste unter den großen Distris. Das wird schon
noch Debian-typisch stabil und perfekt dokumentiert werden.

Ich verwende systemd jetzt seit ca einem Jahr auf manchen Systemen,
u.a. auch boot-mäßig etwas heiklen headless Raspberry Pis (nein, ich
will *wirklich* nicht einen Monitor zu meinem im Rack auf einem 19"-
Träger verbauten Raspi schleppen, oder umgekehrt diesen aus dem Rack
rausschauben, wenn das Ding nicht bootet) und habe keine ernsten Probleme
gehabt. Und das war teilweise noch *vor* der TC-Entscheidung, wie systemd
noch eine experimentelle Nischenlösung in Debian war. Am lästigsten waren
(vor ca. einem Jahr?) mal irgendwelche seltsamen Wechselwirkungen mit
Gnome 3, dem Display Manager und Gnome Shell auf meinem Desktoprechner.
Ein paar Tage ohne X tun ganz gut, um zu sehen, daß man "Terminal-only"
noch fit ist ;)

Wenn in vielleicht einem Monat der Release rauskommt, dann wird sicher
erst mal 2-3 Monate das Geschrei von Endusern losbrechen, deren Setups
brechen, und nach und nach wird alles gefixt werden. Und *dann* wird
systemd in Debian so stabil sein wie Exim, oder PostgreSQL[1] oder andere
Teilsysteme.

/ralph

[1] Man kann den Packagern von PostgreSQL in Debian gar nicht genug
danken, sie schaffen es schon seit Jahren, daß diese Datenbank ohne
nennenswerte Schmerzen in den meisten Fällen völlig oder fast ganz
automatisch upgedatet werden kann. Ohne Daten zu verlieren.

[Helmut Hullen]

Hallo, Ralph,

Du meintest am 06.01.15:

>> Ich vermute das. Die systemd-"Integration" in Debian ist weniger als
>> halbgar.

> Sie ist auch noch die neueste unter den großen Distris. Das wird
> schon noch Debian-typisch stabil und perfekt dokumentiert werden.

Heilsversprechen als Funktions-Ersatz?

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Marc Haber]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ich vermute das. Die systemd-"Integration" in Debian ist weniger als
>> halbgar.
>
>Sie ist auch noch die neueste unter den großen Distris. Das wird schon
>noch Debian-typisch stabil und perfekt dokumentiert werden.

Wir haben eingefroren und wollen innerhalb des nächsten Quartals
releasen. Ich sehe da schwarz.

[Marc Haber]

Für Batchaktionen ist das akzeptabell, auf der Shell ist es ähnlich
sinnvoll wie Start => Programme => Zubehör => EventViewer.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>> Marc Haber <mh+usene...@zugschl.us> wrote:

>>> Für tagesaktuelles sid kann ich das bestätigen, wenn man mal die
>>> völlige Abwesenheit von Feedback jeglicher Art außer Acht lässt:
>>
>> Das irritierte mich auch am Anfang. Man bekommt halt nut $? zurück
>> und nicht mehr. Für den Rest soll man dann wohl das journal bemühen,
>> welche die Äußerungen des Init-Scripts oder der Unit beinhaltet,
>> sofern es welche gibt.

> Für Batchaktionen ist das akzeptabell, auf der Shell ist es ähnlich
> sinnvoll wie Start => Programme => Zubehör => EventViewer.

Zustimmung.

Technisch gesehen allerdings nachvollziehbar, wenn man sich ansieht, was
passiert.

Bei SysVinit startet "service" ja direkt das Init-Script (in einer
gesäuberten Umgebung) als eigenes Kind und kann daher die Ausgabe direkt
an das kontrollierende Terminal leiten.

Bei systemd startet "service" bzw. "systemctl" gar nichts, sondern teilt
nur via dbus dem systemd mit, das dieser tätig werden soll. Die Ausgabe
landet via systemd im journal, weil es kein kontrollierendes Terminal
für die Unit gibt.

[Ralph Aichinger]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Wir haben eingefroren und wollen innerhalb des nächsten Quartals
> releasen. Ich sehe da schwarz.

Ich nicht. Du solltest als Debian-Entwickler überzeugter von deinem
Produkt sein. Stichwort: Hundefutter ;)

Nein, ernsthaft, wenn man sich die Statistiken da ansieht, dann
schaut das alles andere als schlecht aus:

http://richardhartmann.de/blog/posts/2015/01/02-Debian_Release_Critical_Bug_report_for_Week_01/

Und ich freu mich schon auf einen Release rund um meinen Geburtstag am
21. Februar ;)

/ralph -- ja, der wirkliche Qualitäts- und Funktionalitätssprung bei
systemd wird bestimmt erst im nächsten Zyklus passieren. Aber
zumindest Bugs werden bestimmt auch in Stable bis zu einem
gewissen Grad ausgemerzt werden.

[Sven Hartge]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Wir haben eingefroren und wollen innerhalb des nächsten Quartals
>> releasen. Ich sehe da schwarz.

> Ich nicht. Du solltest als Debian-Entwickler überzeugter von deinem
> Produkt sein. Stichwort: Hundefutter ;)

> Nein, ernsthaft, wenn man sich die Statistiken da ansieht, dann
> schaut das alles andere als schlecht aus:

> http://richardhartmann.de/blog/posts/2015/01/02-Debian_Release_Critical_Bug_report_for_Week_01/

Das Problem bei den Bugs mit systemd ist, dass viele im Debian-Umfeld
noch nicht bekannt sind, aus unter anderem folgenden Gründen:

systemd wurde sehr sehr spät als Default-Init-System in Sid integriert
und kam daher auch sehr sehr spät nach Testing. Deswegen hat es bisher
keine umfassenden Tests erhalten. Desweiteren zeigte sich schon in der
Vergangenheit, dass die Menge der Leute, die Testing auch wirklich
testen eher gering ist. Zu gering, um viele Use-Cases abzudecken und
abzuklopfen. Zusätzlich gab und gibt es eine deutliche FUD-Bewegung, die
den Leuten schon fast aktiv ausredet, systemd auch nur anzusehen. Das
konnte man in der englischen Debian-Users-ML sehr schön beobachten, wie
beim puren Erwähnen von systemd schon wieder die Grabenkämpfe ausbrachen
und oftmals als erste Hilfe kam "hier, so stellst du wieder auf
SysV-Init um" anstelle systemd eine Chance zu geben und es zu testen.

Deswegen fürchte ich, dass Jessie ein Desaster wird, weil viele Bugs,
die die Entwickler nicht sehen konnten (weil sie einen bestimmten
Use-Case nicht haben), erst nach dem Release auftauchen werden, wenn die
Breite Masse Jessie einsetzt.

Und noch härter wird es die Leute treffen, die ihre Installation von
Wheezy auf Jessie updaten, vor allem, wenn bisher gemachte Änderungen an
z.B. der Startreihenfolge nicht komplett oder korrekt übernommen werden.

Ich persönlich habe keine Probleme (mehr) mit systemd, alle meine
privaten Systeme laufen damit, vom Laptop über den Home-Server und den
Arbeitsplatz-PC hin zum Cubietruck als Router.

Für die beruflichen Server, die ich betreue werde ich aber mit
ziemlicher Sicherheit erst einmal via puppet auf allen Systemen ein
Pinning einrichten, welches beim Upgrade die Installation von systemd
verhindert, bis sich gezeigt hat, wie sicher und stabil die Geschichte
ist.

Meiner Meinung nach hat die komplette Entscheidungsfindung bei Debian zu
lange gedauert und kam dann zum schlechtest möglichen Zeitpunkt. Ich
hätte es für sinnvoll gefunden, Jessie noch ohne systemd zu releasen und
dann _direkt_ nach dem Release Sid umzustellen, damit ein kompletter
Entwicklungszyklus schon mit dem neuen Standard läuft.

Allerdings hätte das vermutlich dazu geführt, dass Projekte wie Gnome3
aus Debian geflogen (oder stark verstümmelt gewesen) wären, da sich die
Entwickler bei einigen Core-Komponenten (Sitzungs-Verwaltung) recht
drastisch an systemd angekoppelt haben.

So oder so muss aber die weitere Entwicklung zeigen, was passiert.

Und eines ist auch mal klar: Selbst wenn man absolut gegen systemd ist,
testen und Bugs reporten sollte man die Sache dennoch, um sicher zu
gehen das a) auch nicht-systemd-Systeme korrekt funktionieren und b)
Systeme mit systemd sich nicht daneben benehmen.

Grüße,
Sven.

[Marc Haber]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Wir haben eingefroren und wollen innerhalb des nächsten Quartals
>> releasen. Ich sehe da schwarz.
>
>Ich nicht. Du solltest als Debian-Entwickler überzeugter von deinem
>Produkt sein. Stichwort: Hundefutter ;)

Ich benutze Debian unstable und bin mit dem derzeitigen State of
Affairs mehr als unzufrieden. Eine etwas längere Entwicklungsphase vor
dem Freeze hätte nicht nur der systemd-Integration und den von mir
betreuten Paketen gut getan.

Das Update auf jessie wird das schmerzhafteste, was Debian seit der
Umstellung auf die glibc erlebt hat.

In den Nullerjahren hat Debian die Nutzer verloren, die einen
schnelleren Updatezyklus haben wollten. Jetzt verliert Debian die
Nutzer, denen der aktuelle Updatezyklus zu schnell ist.

>Nein, ernsthaft, wenn man sich die Statistiken da ansieht, dann
>schaut das alles andere als schlecht aus:
>
>http://richardhartmann.de/blog/posts/2015/01/02-Debian_Release_Critical_Bug_report_for_Week_01/

Das liegt ungefähr daran, dass sich niemand traut, releasekritische
Bugreports als solche einzuwerfen.

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Bei systemd startet "service" bzw. "systemctl" gar nichts, sondern teilt
>nur via dbus dem systemd mit, das dieser tätig werden soll. Die Ausgabe
>landet via systemd im journal, weil es kein kontrollierendes Terminal
>für die Unit gibt.

Dann besteht ja immer noch Hoffnung, dass systemctl --verbose
--journal den entsprechende Aufruf von journalctl vielleicht mal mit
erledigt. Was natürlich nicht hilft, wenn man sich fragt, warum das
service bind9 stop so lange dauert.

Es ist wohl gedacht, dass man in einem anderen Fenster das Journal
mitliest.

Schöne neue Welt.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:

> In den Nullerjahren hat Debian die Nutzer verloren, die einen
> schnelleren Updatezyklus haben wollten. Jetzt verliert Debian die
> Nutzer, denen der aktuelle Updatezyklus zu schnell ist.

Du kannst halt nicht gewinnen, egal was du machst.

Um jeden zufrieden zu stellen bräuchte Debian soetwas wie bei Ubuntu, wo
bestimmte Releases LTS-Versionen sind und länger gepflegt werden.

Es muss sich zeigen, wie sich die aktuelle Squeeze-LTS- und evtl. auch
Wheezy-LTS-Kampagne auswirkt und ob auf lange Sicht genug Geld und damit
Leute vorhanden sind, um die Pflege der Versionen durchzuführen.

Red Hat, SuSE und Ubuntu haben nun einmal Firmen mit Kunden mit
Wartungsverträgen dahinter, die können einfach Geld auf das Problem
werfen, Debian hat nur Freiwillige, die manchmal von Firmen bezahlt
werden.

Schwer, mit so einer Basis ein Rundum-Glücklich-Sorglos-Paket für alle
Einsatzzwecke zu schnüren.

[Stefan Froehlich]

On Tue, 06 Jan 2015 23:16:14 Marc Haber wrote:
> Das Update auf jessie wird das schmerzhafteste, was Debian seit der
> Umstellung auf die glibc erlebt hat.

Danke für die Warnung. Es gibt da zwar ein paar Dinge, die ich gerne
hätte, aber zur Not lässt sich auch noch ein Jahr darauf warten. Und
bis dahin sollte sich dann ja gezeigt haben, welche Probleme man sich
mit einem Update eintritt...

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Ranke Ohren erwartet unsere Gesellschaft: Stefan!
(Sloganizer)

[Michael Baeuerle]

Marcus Jodorf wrote:
>
> Da wechsel ich lieber das System. Wenn das genug Leute machen, kommt
> vielleicht auch mal wieder mehr Schwung in die BSD Entwicklung und wenn
> alle Linuxvarianten erst mal gleichgeschaltet sind, ist das vielleicht
> wirklich nicht der schlechteste Weg.

Das Problem bei BSD ist, dass die Sache dort immer mehr zersplittert.
Angefangen hat es (bei den freien Varianten) mit FreeBSD und NetBSD.
Später wurden beide geforkt und es entstanden OpenBSD und DragonFly,
Erst kürzlich wurde nun OpenBSD geforkt und es entstand Bitrig.

Mir macht diese Zersplitterung Sorgen, denn anders als Linux-
Distributionen sind das wirklich verschiedene OS wo auch der Kernel
jeweils anders funktioniert. Irgendwann wird die begrenzte Manpower
nicht mehr ausreichen um so viele Varianten weiterzuentwickeln.

> Ich hab jedenfalls keine Absicht, einfach nur den Mitläufer bei der
> Sache zu machen.

Ich auch nicht. Aber ich befürchte wir werden eine kleine Minderheit
sein.

[Manuel Reimer]

On 01/07/2015 01:28 PM, Michael Baeuerle wrote:
> Das Problem bei BSD ist, dass die Sache dort immer mehr zersplittert.

Im Linux-Bereich sind die Distributionen gerade dabei sich auf
einheitliche Standards zu einigen. Das ist einigen aber ja auch nicht
recht ;)

Gruß

Manuel

[Manuel Reimer]

On 01/07/2015 02:13 AM, Marcus Jodorf wrote:
> Mich interessiert welchen Flurschaden das in der Linuxlandschaft durch
> sein politisch motiviertes Design in Zukunft anrichtet, wie es die
> unixoide Welt mal wieder spaltet und wie groß wohl damit der Einfluß
> von RedHat in der Linuxwelt zukünftig sein wird.

Alle großen Distributionen können im systemd-GIT selber einchecken. Wo
siehst du also das Problem?

Gruß

Manuel

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> In den Nullerjahren hat Debian die Nutzer verloren, die einen
>> schnelleren Updatezyklus haben wollten. Jetzt verliert Debian die
>> Nutzer, denen der aktuelle Updatezyklus zu schnell ist.
>
>Du kannst halt nicht gewinnen, egal was du machst.
>
>Um jeden zufrieden zu stellen bräuchte Debian soetwas wie bei Ubuntu, wo
>bestimmte Releases LTS-Versionen sind und länger gepflegt werden.
>
>Es muss sich zeigen, wie sich die aktuelle Squeeze-LTS- und evtl. auch
>Wheezy-LTS-Kampagne auswirkt und ob auf lange Sicht genug Geld und damit
>Leute vorhanden sind, um die Pflege der Versionen durchzuführen.

Bis dahin sind die wenigen verbliebenen Enterprise-User längst bei
RHEL oder CentOS gelandet.

>Red Hat, SuSE und Ubuntu haben nun einmal Firmen mit Kunden mit
>Wartungsverträgen dahinter, die können einfach Geld auf das Problem
>werfen, Debian hat nur Freiwillige, die manchmal von Firmen bezahlt
>werden.

Genau.

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Deswegen fürchte ich, dass Jessie ein Desaster wird, weil viele Bugs,
>die die Entwickler nicht sehen konnten (weil sie einen bestimmten
>Use-Case nicht haben), erst nach dem Release auftauchen werden, wenn die
>Breite Masse Jessie einsetzt.

Genau. Dies gepaart damit, dass systemd sagen wir mal "Eigenschaften"
hat, die bei anderen Paketen sofort zu einem RC-Bug führen würden.
Aber systemd ist gleicher als andere Pakete.

Außerdem gehen mit systemd auch durchaus Funktionalitäten verloren.

>Und noch härter wird es die Leute treffen, die ihre Installation von
>Wheezy auf Jessie updaten, vor allem, wenn bisher gemachte Änderungen an
>z.B. der Startreihenfolge nicht komplett oder korrekt übernommen werden.

Es bestehen ja noch Hoffnungen, dass beim Update wheezy => jessie kein
automatischer Wechsel des Initsystems passieren wird. Da stehen uns
eher haufenweise nette Bugs ins Haus, die aus Bitrot an nicht mehr
verwendeten Initscripten entstanden sind, aber an solche Bugs sollten
wir uns besser heute als morgen gewöhnen, sie sind unvermeidbar.

Wenn eine Neuinstallation in die Hose geht sehe ich das deutlich
weniger kritisch als wenn ein Update failed.

Debian hat haufenweise User wegen seines langen Releaserhythmus
verloren. Seit squeeze und wheezy gehen die User, die nicht regelmäßig
updaten wollen. Wenn wir jetzt mit jessie auch noch die User
vergraulen, die bereitwillig updated haben, indem wir das Update zum
epishcen Fail werden lassen, taugt Debian bald nur noch als Grundlage
für anderer Leute Distributionen. Den Ruf des Technologieführers haben
wir ja längst an Fedora verloren.

>Meiner Meinung nach hat die komplette Entscheidungsfindung bei Debian zu
>lange gedauert und kam dann zum schlechtest möglichen Zeitpunkt.

... während die systemd-Fraktion unmittelbar nach der in ihrer
Richtung ausgegangenen Entscheidung schlagartig die
Maximalimplementierung committed und durchgedrückt hat, um
schnellstmöglich den Point of No Return zu überschreiten.

>Ich
>hätte es für sinnvoll gefunden, Jessie noch ohne systemd zu releasen und
>dann _direkt_ nach dem Release Sid umzustellen, damit ein kompletter
>Entwicklungszyklus schon mit dem neuen Standard läuft.

Genau das wäre sinnvoll gewesen, ja.

>Allerdings hätte das vermutlich dazu geführt, dass Projekte wie Gnome3
>aus Debian geflogen (oder stark verstümmelt gewesen) wären, da sich die
>Entwickler bei einigen Core-Komponenten (Sitzungs-Verwaltung) recht
>drastisch an systemd angekoppelt haben.

Auch diese Analyse ist richitg.

>So oder so muss aber die weitere Entwicklung zeigen, was passiert.

Debian wird weiterhin Personpower und Benutzer verlieren, so weit ist
sicher.

>Und eines ist auch mal klar: Selbst wenn man absolut gegen systemd ist,
>testen und Bugs reporten sollte man die Sache dennoch, um sicher zu
>gehen das a) auch nicht-systemd-Systeme korrekt funktionieren und b)
>Systeme mit systemd sich nicht daneben benehmen.

Amen.

[Ralph Aichinger]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Debian wird weiterhin Personpower und Benutzer verlieren, so weit ist
> sicher.

Ist das dein persönliches Gefühl, oder gründet sich das auf irgendwas?

Ich habe den gegenteiligen Eindruck: Debian wird aus meiner Sicht immer
populärer, und selbst Microsoft kann man schon Ansätze zur Debianisierung
von Windows 10 unterstellen:

http://www.howtogeek.com/200334/windows-10-includes-a-linux-style-package-manager-named-oneget/

/ralph

[Helmut Hullen]

Hallo, Ralph,

Du meintest am 07.01.15:

???
Im ganzen Artikel taucht nirgendwo das Wort "Debian" auf; im Artikel
geht es um "package management", was es nicht nur bei Debian gibt,
sondern beispielsweise auch bei SuSE und bei RedHat.

Und wenn Microsoft so etwas einführt, dann geht ein wesentlicher Vorteil
von Microsoft-"Distributionen" gegenüber (z.B.) Debian flöten: Microsoft
kontrolliert bisher nicht, welche Fremdprogramme der Endanwender
benutzt. Die Paketverwaltung führt zu einer GÄngelung des Endanwenders
(klar: die Verfechter der Linux-Distributionen mit Paket-Management
behaupten, das Paket-Management sei ein Vorteil - "nimm nichts von
fremden Onkels!").

[Ralph Aichinger]

Helmut Hullen <Hel...@hullen.de> wrote:
> Im ganzen Artikel taucht nirgendwo das Wort "Debian" auf; im Artikel
> geht es um "package management", was es nicht nur bei Debian gibt,
> sondern beispielsweise auch bei SuSE und bei RedHat.

Klar, aber apt-get und das zugehörige Package- und Verteilmodell war
für mich immer eines der zentralen Merkmale von Debian. Debian hat
dieses Modell wohl begründet. Andere haben es später übernommen.

> Und wenn Microsoft so etwas einführt, dann geht ein wesentlicher Vorteil
> von Microsoft-"Distributionen" gegenüber (z.B.) Debian flöten: Microsoft
> kontrolliert bisher nicht, welche Fremdprogramme der Endanwender
> benutzt. Die Paketverwaltung führt zu einer GÄngelung des Endanwenders
> (klar: die Verfechter der Linux-Distributionen mit Paket-Management
> behaupten, das Paket-Management sei ein Vorteil - "nimm nichts von
> fremden Onkels!").

Also ich fände es begrüßenswert, wenn ich auf einem frisch installierten
Windows nur "Get-Package firefox putty gimp libreoffice" oder so eintippen
müßte (so wie auf Debian halt).

/ralph

[Helmut Hullen]

Hallo, Ralph,

Du meintest am 07.01.15:

>> Im ganzen Artikel taucht nirgendwo das Wort "Debian" auf; im Artikel
>> geht es um "package management", was es nicht nur bei Debian gibt,
>> sondern beispielsweise auch bei SuSE und bei RedHat.

> Klar, aber apt-get und das zugehörige Package- und Verteilmodell war
> für mich immer eines der zentralen Merkmale von Debian. Debian hat
> dieses Modell wohl begründet. Andere haben es später übernommen.

???
Da gab es u.a. auch noch "yast" ...

>> Und wenn Microsoft so etwas einführt, dann geht ein wesentlicher
>> Vorteil von Microsoft-"Distributionen" gegenüber (z.B.) Debian
>> flöten: Microsoft kontrolliert bisher nicht, welche Fremdprogramme
>> der Endanwender benutzt. Die Paketverwaltung führt zu einer
>> GÄngelung des Endanwenders (klar: die Verfechter der
>> Linux-Distributionen mit Paket-Management behaupten, das
>> Paket-Management sei ein Vorteil - "nimm nichts von fremden
>> Onkels!").

> Also ich fände es begrüßenswert, wenn ich auf einem frisch
> installierten Windows nur "Get-Package firefox putty gimp
> libreoffice" oder so eintippen müßte (so wie auf Debian halt).

Und dann meldet mir der Dustributions-Paketmanager: "in dieser
Distribution gibt es das Paket hotzlipotz nicht".

Microsoft wurde irgendwann dazu verdonnert, auch andere Browser als nur
den Internet-Explorer anzubieten ...

[Stefan Froehlich]

On Wed, 07 Jan 2015 20:01:00 Helmut Hullen wrote:
> Und wenn Microsoft so etwas [wie das Debian-Paketmanagement]

> einführt, dann geht ein wesentlicher Vorteil von
> Microsoft-"Distributionen" gegenüber (z.B.) Debian flöten:
> Microsoft kontrolliert bisher nicht, welche Fremdprogramme der
> Endanwender benutzt. Die Paketverwaltung führt zu einer GÄngelung
> des Endanwenders

Inwiefern führt die Paketverwaltung von Debian zu einer Gängelung?
Man *muss* ja nicht über die bereitgestellten Repositories
installieren, sondern kann seine Software auch - wie unter Windows -
selbst aus anderen Quellen installieren oder sogar selbst
übersetzen. Bei Debian ist das halt nur selten notwendig, weil es
für Fast Alles[TM] schon ein Paket gibt.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan! Da steckt mehr drin, als man vemutet.
(Sloganizer)

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:

>>> In den Nullerjahren hat Debian die Nutzer verloren, die einen
>>> schnelleren Updatezyklus haben wollten. Jetzt verliert Debian die
>>> Nutzer, denen der aktuelle Updatezyklus zu schnell ist.
>>
>>Du kannst halt nicht gewinnen, egal was du machst.
>>
>>Um jeden zufrieden zu stellen bräuchte Debian soetwas wie bei Ubuntu,
>>wo bestimmte Releases LTS-Versionen sind und länger gepflegt werden.
>>
>>Es muss sich zeigen, wie sich die aktuelle Squeeze-LTS- und evtl. auch
>>Wheezy-LTS-Kampagne auswirkt und ob auf lange Sicht genug Geld und
>>damit Leute vorhanden sind, um die Pflege der Versionen durchzuführen.

> Bis dahin sind die wenigen verbliebenen Enterprise-User längst bei
> RHEL oder CentOS gelandet.

Je nachdem, was sie für Software einsetzen sind sie das eh schon lange.
Ich habe hauptsächlich Debian (und ein paar Ubuntu LTS) im Einsatz, aber
ich muss auch SLES für ein bestimmtes Produkt einsetzen, weil nichts
anderes vom Hersteller supported ist.

Was will ich machen? Mir bleibt da kaum etwas anderes übrig.

[Helmut Hullen]

Hallo, Stefan,

Du meintest am 07.01.15:

>> Und wenn Microsoft so etwas [wie das Debian-Paketmanagement]
>> einführt, dann geht ein wesentlicher Vorteil von
>> Microsoft-"Distributionen" gegenüber (z.B.) Debian flöten:
>> Microsoft kontrolliert bisher nicht, welche Fremdprogramme der
>> Endanwender benutzt. Die Paketverwaltung führt zu einer GÄngelung
>> des Endanwenders

> Inwiefern führt die Paketverwaltung von Debian zu einer Gängelung?
> Man *muss* ja nicht über die bereitgestellten Repositories
> installieren, sondern kann seine Software auch - wie unter Windows -
> selbst aus anderen Quellen installieren oder sogar selbst
> übersetzen. Bei Debian ist das halt nur selten notwendig, weil es
> für Fast Alles[TM] schon ein Paket gibt.

Klar - "man muss nicht". Aber warum benutzen immer noch so viele Leute
den "Internet Explorer"? Warum benutzen immer noch so viele Leute MS-
Office? Eben weil es vom Hersteller des Betriebssystems kommt. Nicht
etwa, weil es besser ist als die Produkte der Mitbewerber.

Un bei den Microsoft-Produkten kommt noch hinzu, dass sie oft bis
meistens teurer sind als die Produkte der Mitbewerber. Die
Paketverwaltung fördert nun mal, "alles aus einer Hand" zu benutzen. Das
Prinzip hat anno dunnemals schon IBM grossgemacht.

"World domination" ist nicht nur dann schlecht, wenn der Herrscher IBM
oder Microsoft heisst.

[Oliver Sch@d]

Sven Hartge wrote:

> Marc Haber <mh+usene...@zugschl.us> wrote:
>> Sven Hartge <sh-...@svenhartge.de> wrote:
>>> Marc Haber <mh+usene...@zugschl.us> wrote:
>
>>>> Für tagesaktuelles sid kann ich das bestätigen, wenn man mal die
>>>> völlige Abwesenheit von Feedback jeglicher Art außer Acht lässt:
>>>
>>> Das irritierte mich auch am Anfang. Man bekommt halt nut $? zurück
>>> und nicht mehr. Für den Rest soll man dann wohl das journal bemühen,
>>> welche die Äußerungen des Init-Scripts oder der Unit beinhaltet,
>>> sofern es welche gibt.
>
>> Für Batchaktionen ist das akzeptabell, auf der Shell ist es ähnlich
>> sinnvoll wie Start => Programme => Zubehör => EventViewer.
>
> Zustimmung.
>
> Technisch gesehen allerdings nachvollziehbar, wenn man sich ansieht, was
> passiert.

Nein, das Verhalten ist Bullshit.

> Bei SysVinit startet "service" ja direkt das Init-Script (in einer
> gesäuberten Umgebung) als eigenes Kind und kann daher die Ausgabe direkt
> an das kontrollierende Terminal leiten.

Ja.

> Bei systemd startet "service" bzw. "systemctl" gar nichts, sondern teilt
> nur via dbus dem systemd mit, das dieser tätig werden soll. Die Ausgabe
> landet via systemd im journal, weil es kein kontrollierendes Terminal
> für die Unit gibt.

Wenn man schon mit Dbus operiert, dann hätte man ja auch die
Fehlermeldungen darauf kippen können.

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen

[Oliver Sch@d]

Dass Lösch-Commits nicht akzeptiert werden.

[Michael Baeuerle]

Manuel Reimer wrote:
> Michael Baeuerle wrote:
> >
> > Das Problem bei BSD ist, dass die Sache dort immer mehr zersplittert.
>
> Im Linux-Bereich sind die Distributionen gerade dabei sich auf
> einheitliche Standards zu einigen. Das ist einigen aber ja auch nicht
> recht ;)

Richtig. Ich finde weder ein zentral gesteuertes Einheits-OS noch eine
Lähmung durch fehlende Manpower erstrebenswert.

[Sven Hartge]

Oliver Sch@d <nospam.spa...@oschad.de> wrote:
> Sven Hartge wrote:

>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Sven Hartge <sh-...@svenhartge.de> wrote:
>>>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>
>>>>> Für tagesaktuelles sid kann ich das bestätigen, wenn man mal die
>>>>> völlige Abwesenheit von Feedback jeglicher Art außer Acht lässt:
>>>>
>>>> Das irritierte mich auch am Anfang. Man bekommt halt nut $? zurück
>>>> und nicht mehr. Für den Rest soll man dann wohl das journal bemühen,
>>>> welche die Äußerungen des Init-Scripts oder der Unit beinhaltet,
>>>> sofern es welche gibt.
>>
>>> Für Batchaktionen ist das akzeptabell, auf der Shell ist es ähnlich
>>> sinnvoll wie Start => Programme => Zubehör => EventViewer.
>>
>> Zustimmung.
>>
>> Technisch gesehen allerdings nachvollziehbar, wenn man sich ansieht, was
>> passiert.

> Nein, das Verhalten ist Bullshit.

Das es doof, zumindest ungewohnt, ist, bestreite ich ja nicht. Ich sage
lediglich, dass ich das Verhalten auf technischer Ebene nachvollziehen
kann.

>> Bei systemd startet "service" bzw. "systemctl" gar nichts, sondern teilt
>> nur via dbus dem systemd mit, das dieser tätig werden soll. Die Ausgabe
>> landet via systemd im journal, weil es kein kontrollierendes Terminal
>> für die Unit gibt.

> Wenn man schon mit Dbus operiert, dann hätte man ja auch die
> Fehlermeldungen darauf kippen können.

Da muss ich passen, was die möglichen Möglichkeiten angeht.

[Manuel Reimer]

On 01/08/2015 11:25 AM, Oliver Sch@d wrote:
>> Alle großen Distributionen können im systemd-GIT selber einchecken. Wo
>> siehst du also das Problem?
>
> Dass Lösch-Commits nicht akzeptiert werden.

In welchem Zusammenhang?

Das der eine dem anderen nicht die Features rauslöschen soll ist
irgendwo klar.

Wo hat es einen konkreten Fall gegeben, dass eine Änderung, die ein
Distributor dringend braucht, nicht akzeptiert wurde?

Gruß

Manuel

[Oliver Sch@d]

Manuel Reimer wrote:

> On 01/08/2015 11:25 AM, Oliver Sch@d wrote:
>>> Alle großen Distributionen können im systemd-GIT selber einchecken. Wo
>>> siehst du also das Problem?
>>
>> Dass Lösch-Commits nicht akzeptiert werden.
>
> In welchem Zusammenhang?
>
> Das der eine dem anderen nicht die Features rauslöschen soll ist
> irgendwo klar.

Ich meinte den einen Bug: "systemd"

[Manuel Reimer]

On 01/08/2015 05:41 PM, Oliver Sch@d wrote:
> Manuel Reimer wrote:
>
>> On 01/08/2015 11:25 AM, Oliver Sch@d wrote:
>>>> Alle großen Distributionen können im systemd-GIT selber einchecken. Wo
>>>> siehst du also das Problem?
>>>
>>> Dass Lösch-Commits nicht akzeptiert werden.
>>
>> In welchem Zusammenhang?
>>
>> Das der eine dem anderen nicht die Features rauslöschen soll ist
>> irgendwo klar.
>
> Ich meinte den einen Bug: "systemd"

Beweis durch Fußaufstampfen gilt nicht ;)

Ich finde es gut, dass Distributionen in diesem Bereich zusammenarbeiten
und bisher bin ich mit systemd mehr als zufrieden.

Gruß

Manuel

[Marc Haber]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>On Wed, 07 Jan 2015 20:01:00 Helmut Hullen wrote:
>> Und wenn Microsoft so etwas [wie das Debian-Paketmanagement]
>> einführt, dann geht ein wesentlicher Vorteil von
>> Microsoft-"Distributionen" gegenüber (z.B.) Debian flöten:
>> Microsoft kontrolliert bisher nicht, welche Fremdprogramme der
>> Endanwender benutzt. Die Paketverwaltung führt zu einer GÄngelung
>> des Endanwenders
>
>Inwiefern führt die Paketverwaltung von Debian zu einer Gängelung?

Einfach ignorieren. Thread went Hullen and died.

Er findet alles, was über die "Leistungsfähigkeit" des
Slackware-"Paketmanagements" hinausgeht eine Gängelung. Insbesondere
wenn etwas so schreckliches wie Paket-Dependencies implementiert sind.

[Marc Haber]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Debian wird weiterhin Personpower und Benutzer verlieren, so weit ist
>> sicher.
>
>Ist das dein persönliches Gefühl, oder gründet sich das auf irgendwas?

Meine persönliche Erfahrung in Unternehmen, die Debian nie eingesetzt
haben (released zu langsam) oder die gerade von Debian auf
Enterprise-Linux migrieren (released zu schnell).

[Marc Haber]

Sven Hartge <sh-...@svenhartge.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Bis dahin sind die wenigen verbliebenen Enterprise-User längst bei
>> RHEL oder CentOS gelandet.
>
>Je nachdem, was sie für Software einsetzen sind sie das eh schon lange.
>Ich habe hauptsächlich Debian (und ein paar Ubuntu LTS) im Einsatz, aber
>ich muss auch SLES für ein bestimmtes Produkt einsetzen, weil nichts
>anderes vom Hersteller supported ist.

In meiner Umgebung passieren solche Migrationen ohne Not mit der
Begründung der zu häufigen Releases und des zu kurzen
Supportzeitraums.

[Helmut Hullen]

Hallo, Marc,

Du meintest am 08.01.15:

>> Inwiefern führt die Paketverwaltung von Debian zu einer Gängelung?

> Einfach ignorieren. Thread went Hullen and died.

> Er findet alles, was über die "Leistungsfähigkeit" des
> Slackware-"Paketmanagements" hinausgeht eine Gängelung.

Nein.

> Insbesondere wenn etwas so schreckliches wie Paket-Dependencies
> implementiert sind.

Nein. Auch bei Slackware-Paketen taucht ab und zu so etwas wie "slack-
depends" auf. Du diffamierst nur. Gebricht es Dir an inhaltlichen
Argumenten?

[Florian Weimer]

* Marc Haber:

> In meiner Umgebung passieren solche Migrationen ohne Not mit der
> Begründung der zu häufigen Releases und des zu kurzen
> Supportzeitraums.

Kommt man zu dieser Einschätzung mit oder ohne EUS auf Red-Hat-Seite?

Ohne EUS gibt es Support nur für das letzte Minor Release innerhalb
eines Major Release. (Es gibt etwa zwei neue Minor Releases pro Jahr.)
Ab und zu werden ganze Subsysteme durch neue Upstream-Versionen
ausgetauscht, d.h. es gibt *wesentlich* mehr Änderungen als während
der Lebenszeit eines typischen Debian “stable”.

Ich frage mich, ob jene Zusammenhänge diesen Leuten bewußt sind und ob
sie gar von vorneherein EUS beziehen.

[Sven Hartge]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>> Marc Haber <mh+usene...@zugschl.us> wrote:

>>> Bis dahin sind die wenigen verbliebenen Enterprise-User längst bei
>>> RHEL oder CentOS gelandet.
>>
>>Je nachdem, was sie für Software einsetzen sind sie das eh schon
>>lange. Ich habe hauptsächlich Debian (und ein paar Ubuntu LTS) im
>>Einsatz, aber ich muss auch SLES für ein bestimmtes Produkt einsetzen,
>>weil nichts anderes vom Hersteller supported ist.

> In meiner Umgebung passieren solche Migrationen ohne Not mit der
> Begründung der zu häufigen Releases und des zu kurzen
> Supportzeitraums.

Nun, wenn IT als unnötige Kosten angesehen wird und man am Besten alles
mit einem externen Dienstleister, der natürlich nur einmal im Jahr für 3
Stunden beauftragt werden darf, leisten will, dann wird man als Firma
eben den Weg gehen, Dinge nur einmal aufzusetzen und diese dann zu Tode
zu reiten, bis es nicht mehr geht.

Glücklicherweise muss ich nicht in so einer Umgebung arbeiten.

[Edzard Egberts]

Sven Hartge wrote:
> Red Hat, SuSE und Ubuntu haben nun einmal Firmen mit Kunden mit
> Wartungsverträgen dahinter, die können einfach Geld auf das Problem
> werfen

Na ja, Geld alleine hilft auch nicht:

Habe mir "zwischen den Jahren" erneut CentOS 7 angeguckt und
festgestellt, dass sich bei GNOME 3 _immer_noch_nicht_ mit der Maus die
Panels konfigurieren lassen (wie lange ist der Schrott schon draußen?)
und dann erst einmal XFCE installiert (das gefiel mir!). Danach wollte
ich Software installieren und ... kein CenOS 7 auf RPMfusion, also z.B.
kein Seamonkey im Repo. Kann ich natürlich selber installieren, zeigt
mir aber, dass das alles noch nicht richtig fertig ist und ich besser
noch ein Jahr warte.

Dazu muss ich noch sagen, dass das Update von CentOS 6.5 auf CentOS 6.6
einige neue Fehler eingebaut hat und eine meiner Maschinen jetzt mit
einem CentOS 6.5-Kernel läuft und alle Updates abgeschaltet hat, damit
ich auf die Webcam zugreifen kann (das Kernel-Update hat nichts
gebracht). Auch stürzen mir neuerdings alle möglichen Programme beim
ersten Aufruf ab (habe ich aber noch nicht genau untersucht). Das hat
mich also auch nicht so überzeugt. :o(

Damit halte ich die ganzen "Neuerungen" für reichlich experimentell und
bin nicht der Meinung, dass die in eine "Produktivumgebung" gehören -
sozusagen das Windows-Vista der Linux-Welt. Wenn hier also Leute
glauben, dass "Jessie" ein Desaster wird, kann ich das nachvollziehen,
da das Zeugs noch nicht einmal bei den Leuten funktioniert, die diese
Entwicklung voran treiben.

Zum Glück bin ich mit CentOS 6 weitgehend zufrieden und kann noch bis
2020 auf einen vollständigen Bugfix warten. :o)

[Ralph Angenendt]

Well, Edzard Egberts <ed...@tantec.de> wrote:
> Habe mir "zwischen den Jahren" erneut CentOS 7 angeguckt und
> festgestellt, dass sich bei GNOME 3 _immer_noch_nicht_ mit der Maus die
> Panels konfigurieren lassen (wie lange ist der Schrott schon draußen?)

Die Version in CentOS 7 sind älter als die aktuelle Gnome-Version -
außerdem läuft das im Classic-Mode *und* bei Gnome 3 gibt es keine
Panels mehr. Was willst du da konfigurieren?

> und dann erst einmal XFCE installiert (das gefiel mir!). Danach wollte
> ich Software installieren und ... kein CenOS 7 auf RPMfusion, also z.B.
> kein Seamonkey im Repo. Kann ich natürlich selber installieren, zeigt
> mir aber, dass das alles noch nicht richtig fertig ist und ich besser
> noch ein Jahr warte.

RPMFusion ist ein von CentOS komplett unabhängiges Repository. Da hat
CentOS auch keinen Einfluss drauf.

> Dazu muss ich noch sagen, dass das Update von CentOS 6.5 auf CentOS 6.6
> einige neue Fehler eingebaut hat und eine meiner Maschinen jetzt mit
> einem CentOS 6.5-Kernel läuft und alle Updates abgeschaltet hat, damit
> ich auf die Webcam zugreifen kann (das Kernel-Update hat nichts
> gebracht). Auch stürzen mir neuerdings alle möglichen Programme beim
> ersten Aufruf ab (habe ich aber noch nicht genau untersucht). Das hat
> mich also auch nicht so überzeugt. :o(

Wir freuen uns über bugreports.

> Damit halte ich die ganzen "Neuerungen" für reichlich experimentell und
> bin nicht der Meinung, dass die in eine "Produktivumgebung" gehören -
> sozusagen das Windows-Vista der Linux-Welt. Wenn hier also Leute
> glauben, dass "Jessie" ein Desaster wird, kann ich das nachvollziehen,
> da das Zeugs noch nicht einmal bei den Leuten funktioniert, die diese
> Entwicklung voran treiben.

Frage mich gerade welches "Zeugs" du damit meinst.

Ralph
--
His goal in life was to be an echo

[Edzard Egberts]

Ralph Angenendt wrote:
> Well, Edzard Egberts <ed...@tantec.de> wrote:
>> Habe mir "zwischen den Jahren" erneut CentOS 7 angeguckt und
>> festgestellt, dass sich bei GNOME 3 _immer_noch_nicht_ mit der Maus die
>> Panels konfigurieren lassen (wie lange ist der Schrott schon draußen?)
>
> Die Version in CentOS 7 sind älter als die aktuelle Gnome-Version -
> außerdem läuft das im Classic-Mode *und* bei Gnome 3 gibt es keine
> Panels mehr. Was willst du da konfigurieren?

Die Leisten am oberen und unteren Bildschirmrand, insbesondere die obere
Leiste mit Schnellstartern versehen. Aber GNOME ist für mich sowieso
inzwischen grundsätzlich gelaufen, oder funktioniert der
Dual-Screen-Support wieder? Was soll ich mit einer Touch-Oberfläche auf
einer Dual-Screen-Workstation anfangen?

> RPMFusion ist ein von CentOS komplett unabhängiges Repository. Da hat
> CentOS auch keinen Einfluss drauf.

Kann es sein, dass es nicht trivial ist, bestehende Software für CentOS
7 neu zu compilieren?

>> Auch stürzen mir neuerdings alle möglichen Programme beim
>> ersten Aufruf ab (habe ich aber noch nicht genau untersucht). Das hat
>> mich also auch nicht so überzeugt. :o(
>
> Wir freuen uns über bugreports.

Okay, Augen verdrehen und noch einmal klicken bringt es irgendwie
wirklich nicht. ;o)

> Frage mich gerade welches "Zeugs" du damit meinst.

GNOME3 und systemd - seit ich weiß, dass die GNOME-Entwickler bei
systemd mitmischen, halte ich alle Proteste für berechtigt. GNOME 3
wurde als unfertige Software mit idiotischen Hardwareanforderungen und
an den Bedürfnissen der Anwender vorbei herausgehauen und lässt sich im
Fiaskofaktor bestens mit Windows 8 vergleichen - für so etwas bin ich
eigentlich nicht auf Linux umgestiegen. Zum Glück kann man sich da
Desktop/ Fenstermanager auswählen.

BTW - der Installer ist mir bei der Festplattenpartionierung dauernd
abgestürzt: Mein Ziel waren 4 Standard-Partitionen für /boot, /, /home,
/swap (keine Extended Partition für /home!), weil sich das mit den
üblichen Tools (z.B. Clonezilla) am Besten bearbeiten lässt. Keine
Chance, lässt sich nur mit externen Tools ("gparted von Rescue-CD")
einrichten und dann im Installer übernehmen. Im Vergleich mit dem CentOS
6-Installer fand ich das Ding nur ärgerlich, muss aber zugeben, dass die
Icons hübscher sind.

[Michael Baeuerle]

Edzard Egberts wrote:
>
> [...] Was soll ich mit einer Touch-Oberfläche auf
> einer Dual-Screen-Workstation anfangen?

Fingerabdrücke auf deine Monitore machen.

> [...] GNOME 3

> wurde als unfertige Software mit idiotischen Hardwareanforderungen und
> an den Bedürfnissen der Anwender vorbei herausgehauen und lässt sich im
> Fiaskofaktor bestens mit Windows 8 vergleichen - für so etwas bin ich
> eigentlich nicht auf Linux umgestiegen. Zum Glück kann man sich da
> Desktop/ Fenstermanager auswählen.

Nur ob der Window manager in Zukunft überhaupt noch das Aussehen der
Fenster bestimmt ist die Frage. Die GNOME Leute sind der Meinung sie
könnten das besser und haben deswegen GTK+ so modifiziert, dass dieses
die Titelleiste selbst erzeugen kann und der WM nur noch einen Rahmen
bereitstellen soll:
http://blogs.gnome.org/mclasen/2014/01/13/client-side-decorations-continued/
https://bugzilla.xfce.org/show_bug.cgi?id=10631

Früher hat man seinen bevorzugten WM aktiviert und danach ließen sich
alle Fensterrahmen gleich bedienen. Ein Theme wirkte auf alle Fenster,
etc. Das war eine logische Trennung, das Programm kümmerte sich um den
Inhalt, der WM um die "decoration".
Und nun das, was natürlich nur bei GNOME bzw. GTK+ basierten Programmen
funktionieren wird. Das kann doch nur grauenhaft enden wenn man auch
Programme benutzt die auf Qt oder einem anderen Toolkit basieren ...

[Ralph Angenendt]

Well, Edzard Egberts <ed...@tantec.de> wrote:

> Ralph Angenendt wrote:
>> RPMFusion ist ein von CentOS komplett unabhängiges Repository. Da hat
>> CentOS auch keinen Einfluss drauf.
>
> Kann es sein, dass es nicht trivial ist, bestehende Software für CentOS
> 7 neu zu compilieren?

Glaube ich nicht. Bei EPEL funktioniert das eigentlich ganz gut. Und auc
RPMFusion hat den Vorteil, dass Fedora ja schon ein wenig länger systemd
hat - da also drauf eingestellt ist. Bei RPMFusion paketieren allerdings
relativ wenige Leute - und die haben zuerst einmal Interesse Pakete für
Fedora bereitzustellen - und erst dann (wenn überhaupt) für die
Enterprise-Distributionen.

> BTW - der Installer ist mir bei der Festplattenpartionierung dauernd
> abgestürzt: Mein Ziel waren 4 Standard-Partitionen für /boot, /, /home,
> /swap (keine Extended Partition für /home!), weil sich das mit den
> üblichen Tools (z.B. Clonezilla) am Besten bearbeiten lässt. Keine
> Chance, lässt sich nur mit externen Tools ("gparted von Rescue-CD")
> einrichten und dann im Installer übernehmen. Im Vergleich mit dem CentOS
> 6-Installer fand ich das Ding nur ärgerlich, muss aber zugeben, dass die
> Icons hübscher sind.

Ja, das Partitionstool in Anaconda hat schon bei Fedora (18? 19?)
ziemlich viel Kritik abbekommen.

[Edzard Egberts]

Ralph Angenendt wrote:
> Well, Edzard Egberts <ed...@tantec.de> wrote:
>> BTW - der Installer ist mir bei der Festplattenpartionierung dauernd
>> abgestürzt: Mein Ziel waren 4 Standard-Partitionen
>

> Ja, das Partitionstool in Anaconda hat schon bei Fedora (18? 19?)
> ziemlich viel Kritik abbekommen.

Das funktionierte doch alles einmal. Ich verstehe überhaupt nicht, was
für Nieten da programmieren, dass beim "Aufhübschen" die Funktionalität
flöten geht. Sehe ich das viel zu radikal (ich entwickele maschinennahe
Software und frage mich immer, ob ich mein Beatmungsgerät damit
betreiben würde ;o), oder liegt da etwas im Argen?

Für meine Begriffe wird da viel zu blauäugig drauflos entwickelt und die
Wichtigkeit von "felsenfest" maßlos unterschätzt. Ist es eine
Generationsfrage, dass ich in Computern kein Spielzeug sehe?

[Oliver Sch@d]

Ralph Angenendt wrote:

> Well, Edzard Egberts <ed...@tantec.de> wrote:
>> Ralph Angenendt wrote:
>>> RPMFusion ist ein von CentOS komplett unabhängiges Repository. Da hat
>>> CentOS auch keinen Einfluss drauf.
>>
>> Kann es sein, dass es nicht trivial ist, bestehende Software für CentOS
>> 7 neu zu compilieren?
>
> Glaube ich nicht. Bei EPEL funktioniert das eigentlich ganz gut.

wget "http://mirror.switch.ch/ftp/mirror/epel/fullfilelist" \
-O /dev/stdout | grep '^[0-9].*x86_64.*\.rpm$' | cut -f1 -d/ |
sort | uniq -c

3314 4
8458 5
13390 6
8650 7

Sieht nicht nach einer Erfolgsgeschichte aus. 1/3 weniger Pakete für
CentOS 7 als für CentOS 6. Übrigens auch so unwichtige Pakete wie
mod_passenger fehlen - damit fällt einem dann so unwichtige Sachen wie
Puppet-Master oder Rails-Applikationen auf die Füße. Aber wer braucht das
schon ...

[Juergen Ilse]

Hallo,

Michael Baeuerle <michael....@stz-e.de> wrote:
> Früher hat man seinen bevorzugten WM aktiviert und danach ließen sich
> alle Fensterrahmen gleich bedienen. Ein Theme wirkte auf alle Fenster,
> etc. Das war eine logische Trennung, das Programm kümmerte sich um den
> Inhalt, der WM um die "decoration".

Das ist die logische Trennung, wie ich sie *eigentlich* erwarte.

> Und nun das, was natürlich nur bei GNOME bzw. GTK+ basierten Programmen
> funktionieren wird. Das kann doch nur grauenhaft enden wenn man auch
> Programme benutzt die auf Qt oder einem anderen Toolkit basieren ...

Was meinst du wie lange ich gebraucht habe, um den "undo" Button bei
Microsoft Office 2010 zu finden? Und nur, weil irgend ein hirnverbrannter
Vollidiot es fuer eine ganz tolle Idee hielt, den Button in der Tielleiste
zu verstecken (wo ich ihn beim besten Willen niemals erwartet haette).
Da nebenbei auch noch der Menupunkt fuer "undo" entsorgt wurde, hat das
bei mir sehr lange Zeit fuer extreme Frustration gesorgt ...
Bedienelemente des Programms gehoeren *nicht* in die Titelleiste, die
Titelleiste hat Sache des Window-Managers zu sein. Das ist IMHO die einzig
sinnvolle Einteilung.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Christoph 'Mehdorn' Weber]

Hallo!

* Florian Weimer <f...@deneb.enyo.de>:

> Bei Debian müßte “update-rc.d … disable” angepaßt werden (falls das
> jemand verwendet, das Abschalten von Diensten ist ja nicht gerade die
> Stärke von Debians sysvinit-Implementierung).

-v

Bei mir hat das bisher wie dokumentiert funktioniert (allerdings
habe ich das bisher nur mit sysv-rc und Abschaltung in allen
Runlevels versucht): Die Symlinks wurden auf K gefolgt von
100-Sequenznummer umbenannt und wurde dann auch zuverlässig nicht
mehr beim Booten gestartet; auch über Updates ging das nicht
kaputt.

Auf einigen Systemen verwende ich file-rc und habe dort bisher
immer manuell die /etc/runlevel.conf bearbeitet -- ohne
update-rc.d -- aber auch das ging bei Updates nicht kaputt.


Viel ekliger sind da diveres Maintainer-Scripte, die statt
update-rc.d mit start/stop/restart/reload stattdessen das
Init-Script direkt aufrufen und somit die aktive Policy
umgehen/ignorieren.

Aber zumindest das könnte mit systemd endlich anders werden, da
ich annehme, daß es Probleme gibt, wenn man systemd per Initscript
umgeht.

Christoph

--
Und wann wird USA endlich durch USB abgeloest?
Und wie verhaelt sich das dann mit USV?
(Mark Lothschuetz)

[Michael Baeuerle]

Edzard Egberts wrote:
>
> Das funktionierte doch alles einmal. Ich verstehe überhaupt nicht, was
> für Nieten da programmieren, dass beim "Aufhübschen" die Funktionalität
> flöten geht. Sehe ich das viel zu radikal (ich entwickele maschinennahe
> Software und frage mich immer, ob ich mein Beatmungsgerät damit
> betreiben würde ;o), oder liegt da etwas im Argen?

http://www.jwz.org/doc/cadt.html

[Marc Haber]

Florian Weimer <f...@deneb.enyo.de> wrote:
>* Marc Haber:
>> In meiner Umgebung passieren solche Migrationen ohne Not mit der
>> Begründung der zu häufigen Releases und des zu kurzen
>> Supportzeitraums.
>
>Kommt man zu dieser Einschätzung mit oder ohne EUS auf Red-Hat-Seite?

Man könnte auch CentOS nehmen.

[Marc Haber]

Edzard Egberts <ed...@tantec.de> wrote:
>Damit halte ich die ganzen "Neuerungen" für reichlich experimentell und
>bin nicht der Meinung, dass die in eine "Produktivumgebung" gehören -
>sozusagen das Windows-Vista der Linux-Welt. Wenn hier also Leute
>glauben, dass "Jessie" ein Desaster wird, kann ich das nachvollziehen,
>da das Zeugs noch nicht einmal bei den Leuten funktioniert, die diese
>Entwicklung voran treiben.

Ja, der Vergleich zwischen Debian Jessie und Windows Vista drängt sich
mir auch auf. Ich habe noch Hoffnung, dass er unberechtigt ist.

[Ulf Volmer]

Marc Haber <mh+usene...@zugschl.us> schrieb:

> Florian Weimer <f...@deneb.enyo.de> wrote:
>>* Marc Haber:
>>> In meiner Umgebung passieren solche Migrationen ohne Not mit der
>>> Begründung der zu häufigen Releases und des zu kurzen
>>> Supportzeitraums.
>>
>>Kommt man zu dieser Einschätzung mit oder ohne EUS auf Red-Hat-Seite?
>
> Man könnte auch CentOS nehmen.

Nein, auch CentOS unterstützt nur das letzte Minor- Release, hat also die
gleichen Probleme wie RHEL ohne EUS.

Gruß
Ulf

[Edzard Egberts]

Edzard Egberts schrieb:

> Ralph Angenendt wrote:
>> Well, Edzard Egberts <ed...@tantec.de> wrote:
>>> Auch stürzen mir neuerdings alle möglichen Programme beim
>>> ersten Aufruf ab (habe ich aber noch nicht genau untersucht). Das hat
>>> mich also auch nicht so überzeugt. :o(
>>
>> Wir freuen uns über bugreports.
>
> Okay, Augen verdrehen und noch einmal klicken bringt es irgendwie
> wirklich nicht. ;o)

Ups - Update-Experience? Kann das jetzt nicht mehr reproduzieren.

[Bernd Nawothnig]

On 2015-01-06, Marc Haber wrote:
> Dann besteht ja immer noch Hoffnung, dass systemctl --verbose
> --journal den entsprechende Aufruf von journalctl vielleicht mal mit
> erledigt. Was natürlich nicht hilft, wenn man sich fragt, warum das
> service bind9 stop so lange dauert.
>
> Es ist wohl gedacht, dass man in einem anderen Fenster das Journal
> mitliest.
>
> Schöne neue Welt.

In einem anderen Fenster das syslog zu lesen ist ja nun sowas neues
oder ungewöhnliches auch nicht. Und es passt auch besser zu einem
Initsystem, welches ja in erster Linie dazu da ist, Diemste
automatisch zu starten oder zu anzuhalten. Ausgaben im Konsolenfenster
passen da eher schlecht zu.




Bernd

--
no time toulouse

[Marc Haber]

Es ist also ernsthaft gemeint, dass man anstelle einen hängenden
Dienst zu treten das ganze System durchbooten soll?

Es ist ja schließlich nicht meine Schuld, dass systemd den Start und
Stop von Diensten in seine Hohheit gezogen hat und es keine
Initscripts mehr gibt.

[Marc Haber]

Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:
> Viel ekliger sind da diveres Maintainer-Scripte, die statt
>update-rc.d mit start/stop/restart/reload stattdessen das
>Init-Script direkt aufrufen und somit die aktive Policy
>umgehen/ignorieren.

Du hast Bugs eingereicht?

[Bernd Nawothnig]

On 2015-01-10, Marc Haber wrote:
>>> Dann besteht ja immer noch Hoffnung, dass systemctl --verbose
>>> --journal den entsprechende Aufruf von journalctl vielleicht mal mit
>>> erledigt. Was natürlich nicht hilft, wenn man sich fragt, warum das
>>> service bind9 stop so lange dauert.
>>>
>>> Es ist wohl gedacht, dass man in einem anderen Fenster das Journal
>>> mitliest.
>>>
>>> Schöne neue Welt.
>>
>>In einem anderen Fenster das syslog zu lesen ist ja nun sowas neues
>>oder ungewöhnliches auch nicht. Und es passt auch besser zu einem
>>Initsystem, welches ja in erster Linie dazu da ist, Diemste
>>automatisch zu starten oder zu anzuhalten. Ausgaben im Konsolenfenster
>>passen da eher schlecht zu.
>
> Es ist also ernsthaft gemeint, dass man anstelle einen hängenden
> Dienst zu treten das ganze System durchbooten soll?

Ich bezog mich auf das Mitlesen des journals bzw. des syslogs vs.
Ausgaben im Konsolenfenster.

> Es ist ja schließlich nicht meine Schuld, dass systemd den Start und
> Stop von Diensten in seine Hohheit gezogen hat und es keine
> Initscripts mehr gibt.

Wogegen ja auch prinzipiell nichts einzuwenden ist. Klar muss es dann
auch funktionieren, aber das ist ja nun bei allen Ansätzen so.

[Stefan Froehlich]

On Fri, 09 Jan 2015 15:09:09 Michael Baeuerle wrote:
> [...] ob der Window manager in Zukunft überhaupt noch das Aussehen

> der Fenster bestimmt ist die Frage. Die GNOME Leute sind der
> Meinung sie könnten das besser und haben deswegen GTK+ so
> modifiziert, dass dieses die Titelleiste selbst erzeugen kann und

> der WM nur noch einen Rahmen bereitstellen soll: [...]

Ob das eine wirklich gute Idee ist?

> Früher hat man seinen bevorzugten WM aktiviert und danach ließen
> sich alle Fensterrahmen gleich bedienen.

Weder früher noch "gleich" - mein WindowManager ist so konfiguriert,
dass er durchaus zwischen verschiedenen Fenstern differenziert. Aber
klar, es ist schon so, wie Du das meinst: *ich* gebe die Regeln vor,
nicht die jeweilige Applikation.

> Und nun das, was natürlich nur bei GNOME bzw. GTK+ basierten
> Programmen funktionieren wird.

Das ist für mich insofern noch kein Problem, als ich keinen Gnome
verwende und das auch nicht plane. Aber wie sieht es umgekehrt aus:
was machen dann die GTK+-basierten Programme, wenn sie auf einen
fvwm treffen, der ihnen keinen Zugriff auf die Dekoration gestattet?

> Das kann doch nur grauenhaft enden wenn man auch Programme benutzt
> die auf Qt oder einem anderen Toolkit basieren ...

Eventuell trägt das ja sogar mit zur Motivation bei?

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - Lachen ohne wenn und aber!
(Sloganizer)

[Marc Haber]

Es muss funktionieren und sollte sich möglichst so verhalten wie es
vorher war. Selbst das "Starting foo ... success" ins Journal zu
kippen ist im interaktiven Betrieb nicht sinnvoll.

[Bernd Nawothnig]

On 2015-01-10, Marc Haber wrote:
>>> Es ist ja schließlich nicht meine Schuld, dass systemd den Start und
>>> Stop von Diensten in seine Hohheit gezogen hat und es keine
>>> Initscripts mehr gibt.
>>
>>Wogegen ja auch prinzipiell nichts einzuwenden ist. Klar muss es dann
>>auch funktionieren, aber das ist ja nun bei allen Ansätzen so.
>
> Es muss funktionieren und sollte sich möglichst so verhalten wie es
> vorher war.

Selbstverständlich.

> Selbst das "Starting foo ... success" ins Journal zu kippen ist im
> interaktiven Betrieb nicht sinnvoll.

Aber ein Drama ist es andererseits auch nicht. Mit zwei offenen
Terminalfenstern oder unter Verwendung von screen ist das doch kein
echtes Problem. Und der Vorteil dabei ist auch, dass Du einige Zeit
später immer noch nachgucken kannst.

[Stefan Froehlich]

On Sun, 11 Jan 2015 09:42:51 Bernd Nawothnig wrote:
> > interaktiven Betrieb nicht sinnvoll.

> Aber ein Drama ist es andererseits auch nicht. Mit zwei offenen
> Terminalfenstern oder unter Verwendung von screen ist das doch kein
> echtes Problem.

Problem nicht, aber... jessas, einfach Aufwand, der nicht notwendig wäre
und daher lästig ist.

Wenn ich in Eile bin und einmal "apache restart" eingebe, ist es
durchaus hilfreich, im *gleichen* Fenster ein "failed" zu bekommen,
um mich darauf aufmerksam zu machen, dass ich gerade Mist gebaut
habe.

> Und der Vorteil dabei ist auch, dass Du einige Zeit später immer
> noch nachgucken kannst.

Es spricht ja nichts dagegen, das *zusätzlich* im Log zu haben (ist
typischerweise momentan ohnehin auch der Fall).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - Genau mein Ding!
(Sloganizer)

[Michael Baeuerle]

Stefan Froehlich wrote:
> Michael Baeuerle wrote:
> >
> > [...] ob der Window manager in Zukunft überhaupt noch das Aussehen
> > der Fenster bestimmt ist die Frage. Die GNOME Leute sind der
> > Meinung sie könnten das besser und haben deswegen GTK+ so
> > modifiziert, dass dieses die Titelleiste selbst erzeugen kann und
> > der WM nur noch einen Rahmen bereitstellen soll: [...]
>
> Ob das eine wirklich gute Idee ist?
>
> > Früher hat man seinen bevorzugten WM aktiviert und danach ließen
> > sich alle Fensterrahmen gleich bedienen.
>
> Weder früher noch "gleich" - mein WindowManager ist so konfiguriert,
> dass er durchaus zwischen verschiedenen Fenstern differenziert. Aber
> klar, es ist schon so, wie Du das meinst: *ich* gebe die Regeln vor,
> nicht die jeweilige Applikation.

Man ist auf jeden Fall nicht an die Vorstellungen des jeweiligen
Programms gebunden.

> > Und nun das, was natürlich nur bei GNOME bzw. GTK+ basierten
> > Programmen funktionieren wird.
>
> Das ist für mich insofern noch kein Problem, als ich keinen Gnome
> verwende und das auch nicht plane.

Geht mir momentan genauso. Aber da sie das nicht in GNOME, sondern in
GTK+ implementiert haben, holt man sich das in Zukunft vielleicht auch
mit non-GNOME Programmen ins Haus die auf GTK+ basieren.

> Aber wie sieht es umgekehrt aus:
> was machen dann die GTK+-basierten Programme, wenn sie auf einen
> fvwm treffen, der ihnen keinen Zugriff auf die Dekoration gestattet?

fvwm unterstützt "mwm hints", d.h. er wird da wohl problemlos mit-
spielen.
Probleme sehe ich da eher bei Tiling-WMs die schon per default keine
"window decoration" verwenden. Wenn da nun ein GTK+ Programm seine
hässliche Titlebar reinmalt - *würg*.

> > Das kann doch nur grauenhaft enden wenn man auch Programme benutzt
> > die auf Qt oder einem anderen Toolkit basieren ...
>
> Eventuell trägt das ja sogar mit zur Motivation bei?

Möglich. Da man hier aber noch keinen Hebel hat es allen Leuten (auch
gegen deren Willen) in den Rachen zu stopfen, dürfte sich das IMHO nicht
durchsetzen.

[Marc Haber]

Florian Weimer <f...@deneb.enyo.de> wrote:
>Ohne EUS gibt es Support nur für das letzte Minor Release innerhalb
>eines Major Release. (Es gibt etwa zwei neue Minor Releases pro Jahr.)
>Ab und zu werden ganze Subsysteme durch neue Upstream-Versionen
>ausgetauscht, d.h. es gibt *wesentlich* mehr Änderungen als während
>der Lebenszeit eines typischen Debian “stable”.

Interessant. Das war mir nicht bewusst. Was wurde denn innerhalb der
Red Hat 6 Lebenszeit beispielsweise in einem Minor Relase
ausgetauscht?

[Marc Haber]

Stefan...@Froehlich.Priv.at (Stefan Froehlich) wrote:
>On Sun, 11 Jan 2015 09:42:51 Bernd Nawothnig wrote:
>> > interaktiven Betrieb nicht sinnvoll.
>> Aber ein Drama ist es andererseits auch nicht. Mit zwei offenen
>> Terminalfenstern oder unter Verwendung von screen ist das doch kein
>> echtes Problem.
>
>Problem nicht, aber... jessas, einfach Aufwand, der nicht notwendig wäre
>und daher lästig ist.
>
>Wenn ich in Eile bin und einmal "apache restart" eingebe, ist es
>durchaus hilfreich, im *gleichen* Fenster ein "failed" zu bekommen,
>um mich darauf aufmerksam zu machen, dass ich gerade Mist gebaut
>habe.

Amen. Dieses "Feature" ist mal wieder ein Zeichen dafür, dass die
systemd-Leute die Befindlichkeiten von Betriebsleuten einfach
ignorieren.

[Marc Haber]

Bernd Nawothnig <Bernd.N...@t-online.de> wrote:
>Aber ein Drama ist es andererseits auch nicht. Mit zwei offenen
>Terminalfenstern oder unter Verwendung von screen ist das doch kein
>echtes Problem.

Schon an einem iLO wird es mindestens unhandlich, an einer womöglich
langsamen seriellen Konsole sowieso. Und in _meinem_ Geschäft kommt es
mehrfach im Jahr vor, dass ich in so eine Verlegenheit komme. systemd
wird mir da die Arbeit erheblich erschweren.

>Und der Vorteil dabei ist auch, dass Du einige Zeit
>später immer noch nachgucken kannst.

Den Vorteil habe ich bei vernünftig loggenden Anwendungen schon heute.
Und wäre systemd vernünftig implementiert, hätte man das beste von
beiden Möglichkeiten. Hat man nicht gemacht. War egal. Schade, schade,
schade. Aber einen eigenen ntpd mitbringen, das war notwendig.

[Oliver Sch@d]

Marc Haber wrote:

> Bernd Nawothnig <Bernd.N...@t-online.de> wrote:
>>Aber ein Drama ist es andererseits auch nicht. Mit zwei offenen
>>Terminalfenstern oder unter Verwendung von screen ist das doch kein
>>echtes Problem.
>
> Schon an einem iLO wird es mindestens unhandlich, an einer womöglich
> langsamen seriellen Konsole sowieso. Und in _meinem_ Geschäft kommt es
> mehrfach im Jahr vor, dass ich in so eine Verlegenheit komme. systemd
> wird mir da die Arbeit erheblich erschweren.
>
>>Und der Vorteil dabei ist auch, dass Du einige Zeit
>>später immer noch nachgucken kannst.
>
> Den Vorteil habe ich bei vernünftig loggenden Anwendungen schon heute.
> Und wäre systemd vernünftig implementiert, hätte man das beste von
> beiden Möglichkeiten. Hat man nicht gemacht. War egal. Schade, schade,
> schade. Aber einen eigenen ntpd mitbringen, das war notwendig.

Und einen Crond und einen Atd und einen Logger, Handhabung von Mount-
Punkten, Swap, Automounter, Dienste wie Logind, Hostnamed, Localed,
Verbindungen auf Udev usw.

[Juergen Ilse]

Bei interaktiver Bedienung erwarte ich zumindest ein sinnvolles Mass an
interaktiver Ruewckmeldung. Wenn das nicht gegeben ist, ist das IMHO ein
*BUG*, und ein solcher scheint da bei systemd vorzuliegen (auch wenn manche
die Motivation dieser Implementierung verstehen moegen).

Das erinnert fast an den *BUG* von Djb-DNS keine Zonentransfers zu unter-
stuetzen (ja, das ist in meinen Augen ein Bug, auch wenn der Autor argu-
mentiert "Zonentransfers sind sowieso bloed, kopiert doch lieber die Zonen-
daten per ssh zwischen den Servern hin und her").

[Ralph Angenendt]

Well, Oliver Sch@d <nospam.spa...@oschad.de> wrote:

> Ralph Angenendt wrote:
>> Glaube ich nicht. Bei EPEL funktioniert das eigentlich ganz gut.
>
> wget "http://mirror.switch.ch/ftp/mirror/epel/fullfilelist" \
> -O /dev/stdout | grep '^[0-9].*x86_64.*\.rpm$' | cut -f1 -d/ |
> sort | uniq -c
>
> 3314 4
> 8458 5
> 13390 6
> 8650 7
>
> Sieht nicht nach einer Erfolgsgeschichte aus. 1/3 weniger Pakete für
> CentOS 7 als für CentOS 6. Übrigens auch so unwichtige Pakete wie
> mod_passenger fehlen - damit fällt einem dann so unwichtige Sachen wie
> Puppet-Master oder Rails-Applikationen auf die Füße.

Na ja. Bei EPEL muss man immer uach mal gucken wieviele Pakete auf einem
akuellen Stand sind, da werden bei 6 dann auch noch mal stapelweise
Applikationen wegfallen.

Man kann ja auhc einen Bugreport aufmachen, wenn man sein
"Lieblingsprojekt" vermisst, ich habe da aber bisher gemischte
Erfahrungen gemacht.

Aber dass nicht so viele Applikationen für 7 da sind wie für 6 sollte
eigentlich nix damit zu tun haben, dass es schwieriger ist, Software auf
7 zu kompilieren als auf 6. Unter Fedora laufen die Dinger ja auch alle
- und das ist nun mal nicht *so* verschieden.

[Ralph Angenendt]

Well, Ralph Angenendt <ihr....@strg-alt-entf.org> wrote:
> uach
> akuellen
>
>
> auhc
>
>
>

Weia. :)

[Oliver Sch@d]

Ralph Angenendt wrote:

> Well, Ralph Angenendt <ihr....@strg-alt-entf.org> wrote:
>> uach
>> akuellen
>>
>>
>> auhc
>>
>>
>>
>
> Weia. :)

Andere machen acuh Fehler, kein Ding.

[Oliver Sch@d]

Ralph Angenendt wrote:

> Aber dass nicht so viele Applikationen für 7 da sind wie für 6 sollte
> eigentlich nix damit zu tun haben, dass es schwieriger ist, Software auf
> 7 zu kompilieren als auf 6. Unter Fedora laufen die Dinger ja auch alle
> - und das ist nun mal nicht *so* verschieden.

Ich kann dir nicht sagen, warum der Unterschied da ist. Aber die
Portieraufwände scheinen ja da zu sein, sonst könnte man den Kram ja
einfach durchkompilieren.

[Florian Weimer]

* Ralph Angenendt:

> Aber dass nicht so viele Applikationen für 7 da sind wie für 6 sollte
> eigentlich nix damit zu tun haben, dass es schwieriger ist, Software auf
> 7 zu kompilieren als auf 6.

Für 32-Bit-Software in RPM-Form gibt es das Hindernis, daß man kein
Buildroot mehr mit mock erzeugen kann.

[Florian Weimer]

* Marc Haber:

> Florian Weimer <f...@deneb.enyo.de> wrote:
>>Ohne EUS gibt es Support nur für das letzte Minor Release innerhalb
>>eines Major Release. (Es gibt etwa zwei neue Minor Releases pro Jahr.)
>>Ab und zu werden ganze Subsysteme durch neue Upstream-Versionen
>>ausgetauscht, d.h. es gibt *wesentlich* mehr Änderungen als während
>>der Lebenszeit eines typischen Debian “stable”.
>
> Interessant. Das war mir nicht bewusst. Was wurde denn innerhalb der
> Red Hat 6 Lebenszeit beispielsweise in einem Minor Relase
> ausgetauscht?

OpenSSL und X, letzteres mehrfach. Für mehr Beispiele müßte ich die
Release Notes heranziehen.

[Marc Haber]

OpenSSL gegen eine neuere Version inklusive libopenssl?

X ist im Serverbetrieb irrelevant.

[Friedemann Stoyan]

Marc Haber wrote:

> X ist im Serverbetrieb irrelevant.

HaHaHa. Hast Du schon jemals eine RedHat Installation gesehen, die von den
Experten hinterlassen wurde? Man hat den Eindruck, dass ohne Gnome oder wie
der ganze Scheiß heist nichts läuft. Lokale Anmeldung per GDM. My Ass.

Aber im Prinzip hast Du natütlich Recht. Aber auch in diesem Bereich ist die
Windowisierung weit vorangeschritten.

mfg Friedemann

[Marc Haber]

Friedemann Stoyan <use...@ip6-mail.de> wrote:
>Marc Haber wrote:
>> X ist im Serverbetrieb irrelevant.
>
>HaHaHa. Hast Du schon jemals eine RedHat Installation gesehen, die von den
>Experten hinterlassen wurde? Man hat den Eindruck, dass ohne Gnome oder wie
>der ganze Scheiß heist nichts läuft. Lokale Anmeldung per GDM. My Ass.

Das kommt auf die Experten an, zugegeben. In meiner Umgebung ist das
normalerweise der Fall.

[Oliver Sch@d]

Beispiele:

http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.4/German#head-5b2ff8adf0905dff24c9b0c3349f77ac09b38422
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5/German#head-
e980833f6147096dbcebb0bb085c74abae1c6f1d

[Florian Weimer]

* Marc Haber:

>>> Interessant. Das war mir nicht bewusst. Was wurde denn innerhalb der
>>> Red Hat 6 Lebenszeit beispielsweise in einem Minor Relase
>>> ausgetauscht?
>>
>>OpenSSL und X, letzteres mehrfach.
>
> OpenSSL gegen eine neuere Version inklusive libopenssl?

Ja, Red Hat Enterprise Linux 6.4 hatte OpenSSL 1.0.0, 6.5 dann 1.0.1e.
Zwischen den Versionen gibt es deutliche Unterschiede, die der
Versionsunterschied nicht vermuten läßt.

> X ist im Serverbetrieb irrelevant.

Es gibt auch ein Desktop-Produkt. Einiges an kommerzieller
Server-Software kommt zudem mit grafischen Installationsprogrammen,
weswegen es auch einen Desktop für ppc64 und s390x gibt.

[Edzard Egberts]

Friedemann Stoyan wrote:
> Marc Haber wrote:
>
>> X ist im Serverbetrieb irrelevant.
>
> HaHaHa. Hast Du schon jemals eine RedHat Installation gesehen, die von den
> Experten hinterlassen wurde? Man hat den Eindruck, dass ohne Gnome oder wie
> der ganze Scheiß heist nichts läuft. Lokale Anmeldung per GDM. My Ass.

Das schreibt sich aber "Experte"! CentOS (/RedHat) bietet durchaus
verschiedene Installationsalternativen, von "Minimal" über "Server" bis
"Desktop" und da kann man auch noch Details auswählen, also z.B. GNOME
abkreuzen. Für meine XFCE-Installation habe ich erst Minimal installiert
und dann den Desktop-Kram komplett GNOMEless hinzugefügt und ich bin
eigentlich auch eher "Experte" als Experte.

[Peter Schneider]

Am 13.01.2015 um 23:33 schrieb Marc Haber:

> X ist im Serverbetrieb irrelevant.

Nein, ist es nicht.

Die Oracle Datenbank z.B. kommt mit einem grafischen Installer (OUI) und
grafischen Administrationstools (dbca, netca, netmgr etc.)

Gruß
Peter

--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.

[Oliver Sch@d]

Peter Schneider wrote:

> Am 13.01.2015 um 23:33 schrieb Marc Haber:
>
>> X ist im Serverbetrieb irrelevant.
>
> Nein, ist es nicht.
>
> Die Oracle Datenbank z.B. kommt mit einem grafischen Installer (OUI) und
> grafischen Administrationstools (dbca, netca, netmgr etc.)

Aber die Installation kann man auch scripten.

[Michael Baeuerle]

Florian Weimer wrote:

> Marc Haber wrote:
> >
> > OpenSSL gegen eine neuere Version inklusive libopenssl?
>
> Ja, Red Hat Enterprise Linux 6.4 hatte OpenSSL 1.0.0, 6.5 dann 1.0.1e.
> Zwischen den Versionen gibt es deutliche Unterschiede, die der
> Versionsunterschied nicht vermuten läßt.

Warum haben sie das gemacht?

Ich vermute man wollte Support für TLS v1.1 und TLS v1.2 bieten, beides
gibt es erst seit Version 1.0.1.
Die Branches 0.9.8 und 1.0.0 werden ja ebenfalls noch gepflegt, d.h. sie
hätten ansonsten auch einfach auf das neueste 1.0.0 updaten können.

[Ralph Angenendt]

OpenOffice -> LibreOffice.

Cheers,

[Peter Schneider]

Am 14.01.2015 um 11:45 schrieb Oliver Sch@d:
> Peter Schneider wrote:
>
>> Am 13.01.2015 um 23:33 schrieb Marc Haber:
>>
>>> X ist im Serverbetrieb irrelevant.
>>
>> Nein, ist es nicht.
>>
>> Die Oracle Datenbank z.B. kommt mit einem grafischen Installer (OUI) und
>> grafischen Administrationstools (dbca, netca, netmgr etc.)
>
> Aber die Installation kann man auch scripten.

Hab ich noch nie gemacht, und ich kenn auch keinen, der das schonmal
gemacht hätte.

Auf allen meinen Oracle DB Servern läuft ein GUI.