Was viele nicht wissen, mit systemd ist es sogar viel einfacher, die Sicherheit zu erhöhen. Da man dem systemd Code einen Code Audit unterziehen kann und dann die Compilate mit Prüfsummen whitelisten kann. Die einzelnen Systemd Programme sind einzelne in sich abgeschlossene Einheiten und die Konfiguration erfolgt nicht durch Skripte, sondern durch Konfigurationsdaten.
Eine Überprüfung des Systems, ob dieses bspw. komprimiert wurde, ist damit dann sehr einfach.
Bei Init Scripten gilt das nicht, weil das keine in sich abgeschlossenen Einheiten sind, sondern jeder Wald und Wiesen Admin da seinen Code dranfrimmelt. Prüfsummen und ein Whitelisting sind da also gar nicht möglich bzw. müsste die jeder Admin für sich selber anlegen.
Andere Projekte haben auch weit mehr Code drin als nach dem kompilieren jemals zum Einsatz kommt.
EDIT: Mich persönlich kotzt diese Argumentationsweise einfach nur noch an. Zwischen Owncloud und Nextcloud (ja ich weiß hier wird nichts kompiliert, ist aber für den vergleich irrelevant) teilen sich auch die Geister aber kaum jemand argumentiert dort auf diese Weise, nur bei systemd ist offenbar jedes Mittel recht.
Und wenn wir schon mal dabei sind, wie viel Code kommt wohl dabei heraus wenn man das zusammenzählt was vor systemd alles zum Einsatz kam weil man mit sysvinit alleine kein brauchbares Linux hochziehen konnte?! Es braucht mir keiner zu erzählen das dabei deutlich weniger Code bei raus kommen würde.
Eigentlich wollte ich nicht so viel dazu schreiben aber solche Artikel fordern das ja regelrecht heraus...
Dieser Beitrag wurde 4 mal editiert. Zuletzt am 24. Mai 2019 um 11:06.
> Kritiker bemängeln unter anderem, dass die neue Lösung viele Ansätze von Unix verwerfe
Das sieht Lennart selbst ausdrücklich anders; und ich weiß auch nicht genau, worauf diese Leute hinauswollen, außer ...
> und einen monolithischen, kaum zu überblickenden Block darstelle, der stetig an Komplexität zunehme, ohne merkliche Vorteile zu bringen
Das mit der Größe des Monolits und der Komplexität könnte ein Problem sein. Ich kenne den inneren Aufbau nicht. Dass systemd keine merklichen Vorteile bringt, ist hingegen Quatsch. Automatisches Neustarten von verendeten Prozessen ist nur ein Vorteil. Die Liste an Dingen, die mit systemd so nebenbei gehen, und die bei sysvinit einfach garnicht drin waren, ist wohl länger.
> Systemd einen zweiten Kernel, der sich über das komplette Linux-Okösystem ausbreitet und immer mehr Funktionalität in sich vereine
Ja, wie gesagt, ist doof... Andererseits: In der Praxis kommt auch nur Kacke dabei raus, wenn x Teams an x verschiedenen kleinen Modulchen schrauben, die nachher zusammenarbeiten sollen. Es klappt ja schon in der FOSS-Szene nicht, von zwei Seiten ein klar definiertes Interface gescheit so zu implementieren, dass es nachher einfach rennt. Im Desktop-Bereich darf man sowas ja an allen Enden und Ecken bewundern...
> So setzen inzwischen einige Anwendungen auf Komponenten von Systemd auf, was beispielsweise die Entwickler unter BSD in Bedrängnis bringt.
Owww.... Eine Runde Mitleid......... Systemd ist also sozusagen das WhatsApp der Init-Systeme, ja? :))) Und bei WhatsApp, naja, da schließt sich ja auch der Kreis zu BSD wieder.....
> Wie die Seite diese Woche berichtet, besteht die Alternative für Init mittlerweile aus mehr als 1,2 Millionen Zeilen Code.
Es macht ja auch noch allerhand mehr... Äpfel... Birnen...
Wenn ich eine Linux-Distro installiert habe, versuche ich als erstes, alles los zu werden und abzuschalten, was ich nicht brauche und was nur aus Stolpersteinen und entbehrlichen Zwischenschichten besteht, die ein Eigenleben entwickeln. PulseAudio und Networkmanager zum Beispiel, und auch irgendwelche Automounter, von denen es alle paar Jahre eine neue Geschmacksrichtung gibt.
Bei herkömmlichen Init-Systemen habe ich das immer recht schnell hinbekommen, bei systemd gucke ratlos ich in einen Ordner mit ca. 240 unit-files, die alle - schnell erkennbare Hierarchie - scheinbar nebeneinander her dümpeln. So ähnlich wie bei Windows, wo man auch eine Ordner-Darstellung mit allen Systemdiensten hat, inclusive der Warnung "wenn sie diesen Dienst deaktivieren, werden alle darauf aufbauenden Dienst nicht mehr funktionieren". Und Wochen später, nachdem man irgendwas abgeschaltet hat, wundert man sich dann, dass irgendetwas scheinbar ganz anderes nicht mehr funktioniert....
Wie bekommt man bei systemd ein Bein an die Erde? Die Doku, die ich bisher gefunden habe (z.B. bei RedHat) ist sehr komplex und richtet sich an Admins, die damit ständig arbeiten, nicht an Leute, die das einmal einrichten und dann vergessen wollen bzw. nur noch selten daran herumfummeln wollen.
[..] nicht an Leute, die das einmal einrichten und dann vergessen wollen bzw. nur noch selten daran herumfummeln wollen.
Entweder willst du am System basteln oder du lässt es bleiben. Und ja, systemd ist auf den ersten Blick komplexer als sysv-Init. Es hat aber den Riesenvorteil, dass Unit-Dateien deutlich einfacher aufgebaut sind als die alten Skripte und man Funktionalität, die unter dem alten Init-System nur umständlich oder gar nicht möglich ist, geschenkt bekommt.
Ein Beispiel ist z.B. einen Dienst nur bei Bedarf und/oder mit eingeschränkten Rechten zu starten. Unter sysv-Init musste man dazu "su" im Skript benutzen (Mit allen Problemen die das bringen kann) unter systemd gibt man in der Unit-Datei einfach "User" und/oder "Group" an und der Dienst wird als dieser Benutzer bzw. in dieser Gruppe gestartet.
Mehr ist nicht notwendig um den "Turboprint Daemon" als Benutzer "lp" zu starten. Falls der Daemon abstürzt, wird er automatisch neu gestartet. Die Unit-Datei habe ich selbst geschrieben, da die originale Datei sich noch zu sehr an sysv-Init orientiert und externe Skripte aufruft, welche exakt das gleiche tun wie die kurze Datei.
Die Zahlen im Artikel sind mir suspekt. Ein großer Anteil der Quellen systemds sind vermutlich Entwickler-/Deploymentwerkzeuge, Dokumentation, Tests, Hardwaredatenbankeinträge für udev (auch im Quellverzeichnis enthalten), Unit-Dateien (rein deskriptiv) etc. pp.
Kennt jemand Details darüber, wie Git die Statistiken erhebt? Was wird da genau gezählt?
Andere Angaben findet man auf OpenHub oder Coverity. Für eine eigene Analyse hatte ich bisher leider noch keine Zeit.
P.S.: Die ausartenden und unsachlichen Kommentare zum Thema systemd im Allgemeinen sind mal wieder typisch. Dabei geht es im Artikel allein um die Anzahl der Quelltextzeilen im systemd-Repo. Was "systemd" nun tatsächlich ist bzw. wie viel davon in der Regel zum Einsatz kommt oder welche Aussagen man aus dieser fraglichen Metrik (Git stats LOC) hineininterpretieren kann (d.h. darf!), steht auf einem ganz anderen Blatt. Das scheint hier scheinbar keinen zu kümmern. Aber schön die Klappe aufreißen und irgendwelchen teils unsachlichen und inhaltslosen Müll von sich geben...
Was viele nicht wissen, mit systemd ist es sogar viel einfacher, die Sicherheit zu erhöhen.
Da man dem systemd Code einen Code Audit unterziehen kann und dann die Compilate mit Prüfsummen whitelisten kann.
Die einzelnen Systemd Programme sind einzelne in sich abgeschlossene Einheiten und die Konfiguration erfolgt nicht durch Skripte, sondern durch Konfigurationsdaten.
Eine Überprüfung des Systems, ob dieses bspw. komprimiert wurde, ist damit dann sehr einfach.
Bei Init Scripten gilt das nicht, weil das keine in sich abgeschlossenen Einheiten sind, sondern jeder Wald und Wiesen Admin da seinen Code dranfrimmelt.
Prüfsummen und ein Whitelisting sind da also gar nicht möglich bzw. müsste die jeder Admin für sich selber anlegen.
Andere Projekte haben auch weit mehr Code drin als nach dem kompilieren jemals zum Einsatz kommt.
EDIT:
Mich persönlich kotzt diese Argumentationsweise einfach nur noch an.
Zwischen Owncloud und Nextcloud (ja ich weiß hier wird nichts kompiliert, ist aber für den vergleich irrelevant) teilen sich auch die Geister aber kaum jemand argumentiert dort auf diese Weise, nur bei systemd ist offenbar jedes Mittel recht.
Und wenn wir schon mal dabei sind, wie viel Code kommt wohl dabei heraus wenn man das zusammenzählt was vor systemd alles zum Einsatz kam weil man mit sysvinit alleine kein brauchbares Linux hochziehen konnte?! Es braucht mir keiner zu erzählen das dabei deutlich weniger Code bei raus kommen würde.
Eigentlich wollte ich nicht so viel dazu schreiben aber solche Artikel fordern das ja regelrecht heraus...
Dieser Beitrag wurde 4 mal editiert. Zuletzt am 24. Mai 2019 um 11:06.> Kritiker bemängeln unter anderem, dass die neue Lösung viele Ansätze von Unix verwerfe
Das sieht Lennart selbst ausdrücklich anders; und ich weiß auch nicht genau, worauf diese Leute hinauswollen, außer ...
> und einen monolithischen, kaum zu überblickenden Block darstelle, der stetig an Komplexität zunehme, ohne merkliche Vorteile zu bringen
Das mit der Größe des Monolits und der Komplexität könnte ein Problem sein. Ich kenne den inneren Aufbau nicht. Dass systemd keine merklichen Vorteile bringt, ist hingegen Quatsch. Automatisches Neustarten von verendeten Prozessen ist nur ein Vorteil. Die Liste an Dingen, die mit systemd so nebenbei gehen, und die bei sysvinit einfach garnicht drin waren, ist wohl länger.
> Systemd einen zweiten Kernel, der sich über das komplette Linux-Okösystem ausbreitet und immer mehr Funktionalität in sich vereine
Ja, wie gesagt, ist doof... Andererseits: In der Praxis kommt auch nur Kacke dabei raus, wenn x Teams an x verschiedenen kleinen Modulchen schrauben, die nachher zusammenarbeiten sollen. Es klappt ja schon in der FOSS-Szene nicht, von zwei Seiten ein klar definiertes Interface gescheit so zu implementieren, dass es nachher einfach rennt. Im Desktop-Bereich darf man sowas ja an allen Enden und Ecken bewundern...
> So setzen inzwischen einige Anwendungen auf Komponenten von Systemd auf, was beispielsweise die Entwickler unter BSD in Bedrängnis bringt.
Owww.... Eine Runde Mitleid......... Systemd ist also sozusagen das WhatsApp der Init-Systeme, ja? :))) Und bei WhatsApp, naja, da schließt sich ja auch der Kreis zu BSD wieder.....
> Wie die Seite diese Woche berichtet, besteht die Alternative für Init mittlerweile aus mehr als 1,2 Millionen Zeilen Code.
Es macht ja auch noch allerhand mehr... Äpfel... Birnen...
Wenn ich eine Linux-Distro installiert habe, versuche ich als erstes, alles los zu werden und abzuschalten, was ich nicht brauche und was nur aus Stolpersteinen und entbehrlichen Zwischenschichten besteht, die ein Eigenleben entwickeln. PulseAudio und Networkmanager zum Beispiel, und auch irgendwelche Automounter, von denen es alle paar Jahre eine neue Geschmacksrichtung gibt.
Bei herkömmlichen Init-Systemen habe ich das immer recht schnell hinbekommen, bei systemd gucke ratlos ich in einen Ordner mit ca. 240 unit-files, die alle - schnell erkennbare Hierarchie - scheinbar nebeneinander her dümpeln. So ähnlich wie bei Windows, wo man auch eine Ordner-Darstellung mit allen Systemdiensten hat, inclusive der Warnung "wenn sie diesen Dienst deaktivieren, werden alle darauf aufbauenden Dienst nicht mehr funktionieren". Und Wochen später, nachdem man irgendwas abgeschaltet hat, wundert man sich dann, dass irgendetwas scheinbar ganz anderes nicht mehr funktioniert....
Wie bekommt man bei systemd ein Bein an die Erde? Die Doku, die ich bisher gefunden habe (z.B. bei RedHat) ist sehr komplex und richtet sich an Admins, die damit ständig arbeiten, nicht an Leute, die das einmal einrichten und dann vergessen wollen bzw. nur noch selten daran herumfummeln wollen.
Deine Aussage macht irgendwie keinen Sinn:
Entweder willst du am System basteln oder du lässt es bleiben. Und ja, systemd ist auf den ersten Blick komplexer als sysv-Init. Es hat aber den Riesenvorteil, dass Unit-Dateien deutlich einfacher aufgebaut sind als die alten Skripte und man Funktionalität, die unter dem alten Init-System nur umständlich oder gar nicht möglich ist, geschenkt bekommt.
Ein Beispiel ist z.B. einen Dienst nur bei Bedarf und/oder mit eingeschränkten Rechten zu starten. Unter sysv-Init musste man dazu "su" im Skript benutzen (Mit allen Problemen die das bringen kann) unter systemd gibt man in der Unit-Datei einfach "User" und/oder "Group" an und der Dienst wird als dieser Benutzer bzw. in dieser Gruppe gestartet.
Hier mal ein Beispiel:
[Unit]
Description=Turboprint Monitor Daemon
After=cups.service
[Service]
Type=forking
User=lp
Group=lp
ExecStart=/usr/bin/tprintdaemon 0
Restart=on-abort
[Install]
WantedBy=multi-user.target
Mehr ist nicht notwendig um den "Turboprint Daemon" als Benutzer "lp" zu starten. Falls der Daemon abstürzt, wird er automatisch neu gestartet. Die Unit-Datei habe ich selbst geschrieben, da die originale Datei sich noch zu sehr an sysv-Init orientiert und externe Skripte aufruft, welche exakt das gleiche tun wie die kurze Datei.
In der Physik sucht man nach möglichst einfachen Lösungen für komplexe Probleme.
In der IT scheint es genau umgekehrt zu sein.
...ein paar Anregungen zum drüber nachdenken:
https://www.youtube.com/watch?v=o_AIw9bGogo
Die Welt ist ja üblicherweise nicht nur schwarz und weiß...
Die Zahlen im Artikel sind mir suspekt. Ein großer Anteil der Quellen systemds sind vermutlich Entwickler-/Deploymentwerkzeuge, Dokumentation, Tests, Hardwaredatenbankeinträge für udev (auch im Quellverzeichnis enthalten), Unit-Dateien (rein deskriptiv) etc. pp.
Kennt jemand Details darüber, wie Git die Statistiken erhebt? Was wird da genau gezählt?
Andere Angaben findet man auf OpenHub oder Coverity.
Für eine eigene Analyse hatte ich bisher leider noch keine Zeit.
P.S.: Die ausartenden und unsachlichen Kommentare zum Thema systemd im Allgemeinen sind mal wieder typisch. Dabei geht es im Artikel allein um die Anzahl der Quelltextzeilen im systemd-Repo. Was "systemd" nun tatsächlich ist bzw. wie viel davon in der Regel zum Einsatz kommt oder welche Aussagen man aus dieser fraglichen Metrik (Git stats LOC) hineininterpretieren kann (d.h. darf!), steht auf einem ganz anderen Blatt. Das scheint hier scheinbar keinen zu kümmern. Aber schön die Klappe aufreißen und irgendwelchen teils unsachlichen und inhaltslosen Müll von sich geben...