Login
Newsletter
Werbung

Thema: Systemd: Mehr als 1,2 Millionen Zeilen Code

121 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
4
Von Ghul am Fr, 24. Mai 2019 um 08:50 #

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.

2
Von schmidicom am Fr, 24. Mai 2019 um 09:09 #

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.
1
Von Josef Hahn am Fr, 24. Mai 2019 um 10:35 #

> 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...

1
Von Anonymous am Fr, 24. Mai 2019 um 11:58 #

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.

2
Von pointer am Fr, 24. Mai 2019 um 20:02 #

In der Physik sucht man nach möglichst einfachen Lösungen für komplexe Probleme.

In der IT scheint es genau umgekehrt zu sein. :)

1
Von guzzisti am Sa, 25. Mai 2019 um 10:28 #

...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ß...

1
Von klopskind am Sa, 25. Mai 2019 um 16:46 #

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... :down: :shock:

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung