Boycott Systemd

Status
Für weitere Antworten geschlossen.
Der Vollständigkeit halber der Link zum Vortrag:

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Interessant finde ich ja, dass dieser Vortrag ein wenig in Richtung Marketing-Gequatsche geht, mal da ein flacher Spruch, und dann Lacher aus dem Publikum.

Der Vortrag besteht zu 80% aus der Erläuterung von technischen Features.

Erfreulicherweise hat man inzwischen auch in der IT eingesehen, dass ein Konferenzsaal nicht einem Schlafsaal gleichen sollte und ein Vortrag zwischendurch auch unterhaltsam sein darf. :)

In der Linux-Szene war S. Ballmer (mit ähnlicher Auftritts-Attitüde) ein Flopp, und Poettering heutzutage ist hipp ... sowas nennt man wohl auch Paradigmenwechsel :)

Der aggressive Vortragsstil eines Steve Ballmer ist eine ganz andere Hausnummer. Selbst auf seine alten Tage merkt man ihm die Aggressivität an:

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

In jüngeren Jahren ist Ballmer noch über die Bühne getanzt und hat "I love this company" geschrien:

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Das kann ich mir bei Poettering schwerlich vorstellen.

Nimmt den Jungen noch irgendwer ernst?

Er wird als Keynote-Speaker auf Konferenzen eingeladen - das dürfte die Frage doch eigentlich beantworten. ;)
 
Aber naja, dass SELinux ein überaus komplexes System ist, damit hat er ja nun nicht unrecht. Es ist so komplex, dass bisher kaum eine andere Distribution außer RedHat nutzt. Es ist halt ein verdammt mächtiges, aber kompliziertes Tool, mit welchem man Sicherheitsrichtlinien nach diversen Standards umsetzen kann. Davon braucht man Ahnung, viel Ahnung. Nicht umsonst schalten die meisten Noob-Server-Tutorials erst mal SELinux aus. Fatal meiner Meinung nach. (eine SELinux Policy für nginx kann man z.B. hier betrachten: https://github.com/jahrmando/selinux-nginx-rhel/blob/master/nginx/nginx.te )

Im Endeffekt sind hier Ubuntu (mit AppArmor) und RedHat (+ Deriavate) die wenigen Distributionen die standardmäßig ihre Dienste in Sandboxes packen.

Eine, wenn auch weniger mächtige, Standard-Variante über systemd ist da doch an sich keine schlechte Sache. Wird ja auch jetzt schon über die cgroups in kleinen Teilen gemacht (z.B. kein Schreibzugriff auf das gesamte OS).
 
Aber naja, dass SELinux ein überaus komplexes System ist, damit hat er ja nun nicht unrecht. Es ist so komplex, dass bisher kaum eine andere Distribution außer RedHat nutzt.
Cyanogenmod nutzt es schon länger, und die neueren Android-Versionen glaube ich auch. Also ich finde es nicht kompliziert. Bin ich besser als Poettering? :D
 
Der Vollständigkeit halber der Link zum Vortrag:

Herzallerliebst, wie er mit seinem INI-Konfigformat rumwurschtelt und sich eine völlig krude Syntax für alles mögliche ausdenkt.

DeviceAllow=char-alsa rw für "character devices of kernel subsystem type alsa". Warum auch nicht ein Minus zur Trennung nehmen und dann die Rechte einfach durch Leerzeichen getrennt hinten dran. Sieht ja voll logisch und intuitiv aus. /facepalm
 
Hallo,
danke für den Link zum Vortrag, den werde ich mir mal anschauen, vielleicht passt der Vergleich zu Ballmer ja doch nicht.

@JochenF: Vielleicht schaust Du Dir mal MX-Linux an, basiert auf Debian Jessie, aber systemd wird gemieden (bei Bedarf kannst Du es aber verwenden).
Eine Nischendistribution, aber meines Erachtens sehr interessant, ist Void Linux.

Viele Grüße,
Holger
 
hi

welche pillen nimmt der pottering .... ich brauche die auch .....systemd neues init system zum schnellerem laden des os ..... nun security ..............


und ich sach noch .... ne ssd hättes es auch getan.


too many functions for one tool


holger
 
Erfreulicherweise hat man inzwischen auch in der IT eingesehen, dass ein Konferenzsaal nicht einem Schlafsaal gleichen sollte und ein Vortrag zwischendurch auch unterhaltsam sein darf. :)
Na ja, ich kenne den Uni-Betrieb, Vorlesungen / Vorträge u.ä. und zwischen unterhaltsam und flacher Locker-Flockig-Rhetorik liegen doch große Unterschiede.

Aber ich werde mir mal den gesamten Vortrag anschauen.

Viele Grüße,
Holger
 
Wisst ihr noch? Damals. Als es so kompliziert war. hostname um den hostname zu bekommen und hostname <hostname> um ihn zu setzen.

Aber zum Glück leben wir ja jetzt in der Zukunft und haben "hostnamectl set-hostname <hostname>".

EDIT: Sorry, habe gerade Frust dabei so ein System aufzusetzen.
 
Hallo,

ich werde demnächst mal parallel ein Antergos aufsetzen, dieses quasi native Arch System mit lediglich einem bequemen Installer bietet immer das aktuellste systemd, dann kann ich mal einige Neuerungen daran nach vollziehen.

Und nun noch einige Bemerkung zu meiner Ablehnung von systemd, die ich natürlich vor allem aus Nutzerperspektive nur begründen kann, da ich kein Entwickler bin:
Zu meinen Manjaro-Zeiten war ich eher systemd freundlich eingestellt und habe auch jetzt noch nach wie vor den Eindruck, dass es auch technisches Potenzial hat, zumal einige Entwickler regelrecht freudestrahlend über positive Sachen dort berichten. Und das nehme ich denen auch ab. In einem Forum eines Debian Derivates, in welchem ich sogar zu früheren Zeiten mal als Moderator tätig war, habe ich trotz meiner Kritik auch die positive Haltung einiger Entwickler nach voll ziehen können (davon abgesehen habe ich auch schon manche "Kritik" zu systemd gelesen, die ich, um es diplomatisch zu sagen, etwas merkwürdig fand).

In besagtem Debian Derivat Forum fiel mir allerdings eines auf: Bei Problemen mit systemd wussten die Befürworter zwar häufig bestens Bescheid über Analysewerkzeuge, aber gaben weitaus weniger gezielte hilfreiche Hinweise zur Lösung dieser Probleme. Und wenn gehäuft Leute, die in früheren Zeiten dermaßen souverän mit Debian Sid umgehen konnten (in besagtem Forum sind Leute aktiv, die Debian Sid seit der Entstehung von Kanotix bestens kennen), und zu fast allen Schwierigkeiten sofort Lösungen wussten, nun selbst anfangen, bei systemd bedingten Fehlern eher zu spekulieren, dann fällt das auf. Meine Argumentation, dass Werkzeuge, die Komplexität versuchen zu verbergen, selbst komplex sind, und bei Fehlern damit man es dann doch mit der Komplexität des Betriebsystemes zu tun bekommt plus der Komplexität des Werkzeuges, und dass Troubleshooting dann eher schwieriger ist (wie ich ja selbst erfahren habe), hätte ich vermutlich genauso gegenüber einer Mauer bringen können. Ärgerlich war zudem - ich möchte es mal Eiertanzmentalität nennen - dass zum einen bei Problemen den Usern gesagt wurde, wie das nun mit systemd zu funktionieren hat, zum anderen aber genauso Empfehlungen kamen, es doch an systemd vorbei zu konfigurieren, das ist für Nutzerinnen und Nutzer, die etwas über ein System lernen möchten, einfach nervig. Und doof sind auch folgende Konstruktionen: In Debian ist /etc/resolv.conf keine Datei mehr, sondern ein Link auf ..../run/systemd blah blah. Und wenn man nun dort einfach eigene Nameserver eintragen möchte, erlebt man eine Überraschung - klar, für Nameserver ist ab sofort systemd verantwortlich und dafür muss man dann statt wie bisher Schritt a nun Schritt x machen u.s.f. ... und das nun soll einfacher sein?

In einem anderen auch eher systemd freundlichen Forum, ebenfalls mit Schwerpunkt Debian, wurde es dann richtig frech: Auf meinen Einwand in einem Thread pro systemd, dass ich im englischsprachigen FreeBSD Forum schon einige Meinungen von Unixadministratoren gelesen habe, die systemd ablehnen und sich auch um Begründung bemühen - davon abgesehen verwies ich wieder darauf, dass ich gut verstehen kann, wenn einige Entwickler Sachen rund um systemd herum toll finden, kamen dann zwei Reaktionen, die leider typisch sind für fanatische Leute: Sie entgegneten mir positive Sachen zu systemd, die ich selbst direkt davor geschrieben habe (das ist ja noch lustig), aber zu der Ablehnung seitens der FreeBSD Leute wurden dann sofort Spekulationen zum Teil sehr böswilliger Art über deren Unfähigkeit los getreten, ohne etwas über diese Leute zu wissen. Im letzteren Forum gibt es nun aber einige, die die Entwicklung von Devuan sehr genau verfolgen und das sogar installieren (zu Devuan, seinen Qualitäten wie auch Unzulänglichkeiten kann ich gar nichts sagen, ich kenne es nicht).

Ich habe schon manche Diskussion hinter mir wegen systemd - und ich pflege an Diskussionen oftmals so teil zu nehmen, dass ich Pro und Contra versuche zu verstehen, Pro und Contra dann formuliere, damit eventuell bei Missverständnissen meinerseits andere da korrigieren können, aber gerade zu systemd läuft es leider oftmals auf folgende Formel hinaus, die zum Teil ziemlich aggressiv vertreten wird:
pro systemd bedeutet Kompetenz aber zum Teil auch ein Mitlaufen ohne Kompetenz (dem kann ich durchaus zustimmen)
kontra systemd bedeutet grundsätzlich Inkompetenz

Auf so etwas habe ich keine Lust mehr, weshalb ich mich aus zwei Linuxforen letztens verabschiedet habe.

Viele Grüße,
Holger
 
"There is a copious amount of noise in Linux fora" ist der treffendste Kommentar, den ich dazu je las (in einem Unixforum).

Kompetente Leute, die einfache Zweizeiler lieber durch irgendwelche Runlevel ersetzen. Glauben die das echt?
 
"There is a copious amount of noise in Linux fora" ist der treffendste Kommentar, den ich dazu je las (in einem Unixforum).

Kompetente Leute, die einfache Zweizeiler lieber durch irgendwelche Runlevel ersetzen. Glauben die das echt?

OffTopic: Richtig KISS artig und gut finde ich ja folgendes:
http://smarden.org/runit/

Das Handeling von runit unter Void Linux ist sehr leicht zu lernen.

Ob das wohl gut mit FreeBSD zum Laufen zu bekommen ist? Hier im Wiki gibt es ja einen begonnenen Eintrag zur Installation von runit, leider bricht der bei den geplanten Beispielen dann ab (soll kein Vorwurf an den Autor sein).

Viele Grüße,
Holger
 
@Yamagi, @holgerw: Ich benutze noch immer runit unter FreeBSD. Ich hatte es auf meinem Laptop als PID 1 (aka init) Ersatz in Verwendung, aber jetzt bevorzuge ich es unter dem FreeBSD init aus /etc/ttys zu starten. Der Nachteil dieser Lösung ist es, dass runit erst zum Ende des Bootvorgangs zusammen mit den gettys gestartet wird. Dafür muss ich aber weniger am System ändern und Bootzeit ist mir nicht so wichtig.

Darüber hinaus würde ich für neue Setups s6 mit s6-rc bevorzugen, aber ich habe halt schon runit gut am Laufen. In einer kleinen Test-VM läuft s6 wunderbar als init unter FreeBSD und s6-rc ist deutlich mächtiger und imo besser designed als rcNG.

Ein Problem an s6 und s6-rc ist allerdings, dass es fast nur Mechanismen bietet und keine fertige und bequeme Policy mitbringt. Deswegen fühlt sich trotz der reichlichen und präzisen Doku die Lernkurve eher wie eine Wand an.
 
Aprilscherz im August.
tumblr_muxryzfOtz1qh59n0o1_500.gif
 
Es ging um den Scherz, dass der Kernel-source-Tree angeblich ins SystemD repository integriert wurde, das ist schon eine Weile her.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben