News Uselessd: Die erste Abspaltung von Systemd nach Streit

Was für ein gelungener Name ... klingt so nutzlos.
 
Ich finde die Idee gut das ganze schlanker zu gestalten, so dass man mehr individuell gestalten kann.

Den Durchschnittsnutzer interessiert das vielleicht nicht, aber Leute die Tiefer im System hängen werden es wohl mehr mögen.
 
and violent slap in the face to the Unix philosophy
Ab da musste ich schon nicht mehr weiter lesen. Ich frage mich wie oft dieses Paradigma noch von selbst ernannten Geeks missverstanden und ins absolut Absurde geführt werden muss. Und der Rundown, meine Güte. Da stänkert das Projekt gegen systemd aber nutzt systemd 208 als Grundlage, wo doch Init so viel toller war. Dann möchte man die Freiheit haben eudev zu nutzen, was nichts weiter als eine Abspaltung von udev ist. Quasi die gleiche Funktion nur per service aufgerufen. Journald nicht ACID ... gut geschenkt. Wenn ich die Sicherheit benötige kann man ja weiterhin syslog-ng nehmen. Ansonsten nutze ich die Vorteile von Indizierung, Zugriff und Suche des binären Formats.

Aber die Leute scheinen sich anscheinend die Zeiten zurückzuwünschen als man sich noch mit PAM, ConsoleKit und weiß der Geier wie vielen Login Managern herumschlagen musste, weil A zwar mit B ging, aber nicht mit C wollte.

Zur weiteren Kritik von boykottsystemd lässt sich da einiges finden:
Boycott systemd | Hacker News
 
Eierlegende Wollmilchsäue machen vieles, aber erfahrungsgemäß höchstens ein oder zwei Dinge davon richtig. Mir ist noch keines untergekommen, dass seinem selbsternannten Anspruch gerecht geworden wäre. Bei dieser Auseinandersetzung lehne ich mich aber zurück und packe Mate und Popcorn aus. Denn ich kann mit jedem Werkzeug arbeiten, solange es nicht vollkommen untauglich ist. (Wenn $Kunde es wünscht, schlage ich auch mit der Schere Nägel in die Wand.)
 
Zuletzt bearbeitet: (Signatur überflüssig)
Wieder mal ein glänzendes Beispiel dafür, warum Linux-basierte Systeme nie Massentauglichkeit erreichen werden. Aber so wie das aussieht, wird das vom Großteil auch nicht gewünscht. Just fork it!
 
yeah....lasst uns Entwicklerresourcen aufspalten, auf 2 Projekte...die zu 95% identisch sind. So wird das nie was.....
 
Die sollten wenn dann systemd in 2 Projekte aufteilen und dann gemeinsam den init-teil pflegen. Wäre doch deutlich effizienter.
 
@vorposter... Bitte informiert euch nochmal etwas genauer. Systems ist nicht ohne Grund als eierlegende Wollmilchsau geplant. Ziel ist es damit in Zukunft mehrere *nix Systeme auf einer Partitiknt laufen zu lassen. Wenn jede Distribution auf Basis von systemd läuft, dann kann man gleiche Daten darunter transparent halten und so Platz sparen, gemeinsam mit btrfs und copy in write gar kein Problem. Der Entwickler für sytemd ist in seinen Überlegungen schon 2 Schritte weiter als viele der jünger der "reinen Lehre". Auch jurnald ist aus meiner Sicht ein Traum. Endlich nicht durch tausende logs einzeln wühlen.
 
neo-logism schrieb:
@vorposter... Bitte informiert euch nochmal etwas genauer. Systems ist nicht ohne Grund als eierlegende Wollmilchsau geplant. Ziel ist es damit in Zukunft mehrere *nix Systeme auf einer Partitiknt laufen zu lassen. Wenn jede Distribution auf Basis von systemd läuft, dann kann man gleiche Daten darunter transparent halten und so Platz sparen, gemeinsam mit btrfs und copy in write gar kein Problem. Der Entwickler für sytemd ist in seinen Überlegungen schon 2 Schritte weiter als viele der jünger der "reinen Lehre". Auch jurnald ist aus meiner Sicht ein Traum. Endlich nicht durch tausende logs einzeln wühlen.

Genau, besser könnte ich es nicht ausdrücken. =)
 
Ehrlich gesagt kann ich auch nach kurzem Blick auf die Seite und lesen des Artikels nicht ausmachen, warum denn nun auf Systemd rumgehackt wird?

Zugegebenermaßen stecke ich da auch nicht tief genug in der Materie, um mich mit den genauen Unterschieden wirklich objektiv auseinandersetzen zu können, aber für mich klingt das ganze bis jetzt nach: Systemd macht/plant viel zu viel, was ich gar nicht will. Alles doof, die älteren Init-Systemen waren besser.

Oder irre ich da und es gibt tatsächlich vernünftige Argumente?

Mag jemand Versiertes das eventuell mal analysieren?
 
Da frage ich mich eher … gibt es nicht langsam mal einen Gnome Fork ohne Gnome Unfug und REGISTRY? Wenn systemd Unixphilosophie verletzt, dann foltert und vergewaltigt Gnome sie. :p

kelox schrieb:
yeah....lasst uns Entwicklerresourcen aufspalten, auf 2 Projekte...die zu 95% identisch sind. So wird das nie was.....

Na ja, doch, wenn die Projekte wirklich fast identisch sind, wird das dadurch meist umso mehr was. Beispiel ffmpeg/libav, so unsinnig der Streit dort ist, die Entwicklung hat er enorm beschleunigt. Na ja, von ffmpeg. :p
 
ascer schrieb:
Ehrlich gesagt kann ich auch nach kurzem Blick auf die Seite und lesen des Artikels nicht ausmachen, warum denn nun auf Systemd rumgehackt wird?

Mag jemand Versiertes das eventuell mal analysieren?

Da gibts imgo nicht wirklich viel zu analysieren. Da stoßen zwei Lager aufeinander. Die einen prophezeien den Untergang von Linux durch Systemd, die anderen freuen sich darüber, das alte Zöpfe abgeschnitten werden und sich was vorwärts bewegt.
 
Typo in der News:
Hier ist der Kritikpunkt, dass die binären Logs,

Ich verstehe den Namen "uselessd" eher wie "uselessed" also wie systemd nur nutzlos gemacht.
 
ascer schrieb:
Ehrlich gesagt kann ich auch nach kurzem Blick auf die Seite und lesen des Artikels nicht ausmachen, warum denn nun auf Systemd rumgehackt wird?

Argumente sind da, jedoch kommt es auf die Verpackung (Kontext) an, ob diese auch sinnvoll sind. Eben das von mir erwähnte Beispiel mit der nicht ACID Eigenschaft von journald. Die Leute glauben wohl nicht, dass es noch nie Logcorruptions bei normalen Textdateien gab? Wenn die Syntax einer Logzeile nicht passt, kann ich mir auswürfeln, wie entsprechende Skripte unter der Nutzung von sed, grep etc. reagieren werden. Wenn man wirklich ACID will, dann nimmt man andere Backends.

Am Ende ist es genauso wie du es beschrieben hast:
Systemd macht/plant viel zu viel, was ich gar nicht will. Alles doof, die älteren Init-Systemen waren besser.
Viele Leute verstehen nicht, dass die Unix Phiolosophie, bzw. dieser eine oft zitierte Satz, allein für sich unvollständig ist. Vielmehr sollte man begreifen, dass die Granulärität an Funktionen und Komponenten, sich entgegengesetzt der Komplexität verhalten muss!
Selbst gewisse BSD Leute sehen die Sache nüchtern: Boycott Systemd | BSDForen.de - Die BSD-Community (Siehe Nutzer -Nuke-)

Ich weise einfach nochmal auf diesen sehr guten Thread hin: Boycott systemd | Hacker News
 
Zuletzt bearbeitet:
Also ich für meinen Teil sehe systemd ebenfalls sehr skeptisch.

Poettering hat sich in der Vergangenheit nicht mit Ruhm bekleckert, und jetzt will er das halbe System umgraben? Wem da nicht die Augenbraue zuckt, der hat aus der Geschichte nichts gelernt...

Warum soll der Init-Prozess, der eigentlich nur alles andere in die Wege bringen soll, plötzlich mehr als das tun? Das ist vollkommen irrational. Spezialisierung und Fragmentierung sind ein VORTEIL. Ein spezialisiertes Programm hat garantiert weniger Fehler als eines, dass versucht überall zugleich zu rühren. Sollte ein spezialisiertes Programm doch Fehler aufweisen, kannst du es recht leicht austauschen.
Der einzige Grund, warum sich systemd wie eine Plage über die verschiedenen Distributionen verteilt ist doch, dass an anderen Stellen bereits auf systemd gebaut wird und hier absolut unnötige Abhängigkeiten erzeugt werden. Die ganze systemd-Geschichte riecht verdächtig nach Vendor Lock-In, etwas, dass man mit Open Source eigentlich vermeiden will.

Wenn also uselessd tatsächlich die Abhängigkeiten von systemd erfüllt, ohne einen hier mit der allumfassenden Glanzlösung zu erschlagen, dann ist das ein wirklich geiles Projekt und tatsächlich eine echte Alternative zu klassischem Init oder Upstart.
 
Systemd bricht offensiv mit einigen Konventionen. Dabei ist der Bruch mit Konventionen durchaus üblich, nur so offensiv wie es bei der Entwicklung von systemd passiert und kommuniziert wird gibt es entsprechende Unruhen. Dabei sind solche Konventionen teils schlicht Tradition, manchmal aber auch einfach aus kollektiven Erfahrungen heraus entstanden.

Es kommt auch häufig genug vor, dass miese Projekte sich an Konventionen nicht halten und man umgekehrt am Missachten solcher Konventionen miese Projekte erkennt. Das ist im alltäglichem Leben so (zum Beispiel bei der Nutzung von Sprache, wer sich da an Konventionen eines gepflegten Sprachgebrauchs hält muss damit rechnen nicht ernst genommen zu werden, eben weil ein Großteil derer die natürliche Sprache nicht gescheit nutzen auch nichts gescheites zu sagen haben) und auch in der Wissenschaft (wer da gegen wissenschaftliche Konventionen verstößt und das nicht einleuchtend begründet wird nicht für voll genommen).

Jetzt will systemd mit vielen dieser Konventionen brechen, begründet dies wohl meist auch, aber ob die Begründung nun akzeptiert wird oder nicht ist eine ganz andere Frage und da fängt die aktuelle Diskussion an. Denn selbst technische und sachliche Begründungen bieten einen weiten Raum zu Beurteilung dieser anhand persönlicher Vorlieben und Erfahrungen.

Zusätzlich kommt hinzu, dass die Autoren von systemd zumindest streitbar sind.



Dort wo ich noch halbwegs etwas verstehe geht es beispielsweise um die binären Logfiles.
http://www.freedesktop.org/wiki/Software/systemd/journal-files/

Die Vorteile klingen gut ohne Frage. Nur begrüße ich persönlich Logs in "natürlicher" Sprache die plattformunabhänig überall analysiert werden können. Ich habe die Erfahrung gemacht, dass Binärfiles mitunter ein echtes Problem sind wenn (aus welchen Gründen auch immer) das Programm welches zum Lesen dieses Files notwendig ist nicht verfügbar ist. Was bringt es mir, beispielsweise wenn ich ein Logfile von meinem Server habe und ich es auf einem Ipad/Windowstablet/Android Smartphone nicht auslesen kann zeitnah an kein anderes Gerät herankomme? Genauso sind solche Binärformate anfällig gegenüber Änderungen in der Kodierung....
Da wird in meinen Augen ein leistungsfähigeres Journaling gegen potentielle Inkompatibilität getauscht. Ein Tausch, den ich äußerst kritisch bewerte. Andere finden wohl, dass potentielle Inkompatibilität aufgrund von OpenSource lösbar ist und das leistungsfähigere Journaling nur zu begrüßen ist.
 
Zuletzt bearbeitet:
joni16 schrieb:
Wieder mal ein glänzendes Beispiel dafür, warum Linux-basierte Systeme nie Massentauglichkeit erreichen werden. Aber so wie das aussieht, wird das vom Großteil auch nicht gewünscht. Just fork it!
Vielfalt ist ja grundsätzlich kein Problem für die Masse. Android zeigt wie hervorragend ein Linux auch für die Masse funktioniert. Wahrscheinlich wissen 95% der Nutzer gar nicht was da drunter schlummert.

Systemd zeigt aber auch wie viel sich bei Linux auch heute noch unter der Oberfläche tut. Dass das nicht jedem Entwickler passt und auf einigen Seiten dann news zum Kindergarten der Entwickler erscheinen interessiert aber die Masse 0,0.
 

Ähnliche Themen

Zurück
Oben