Linus Torvalds hat sich mal ein anderes Kind der systemd-Leute näher angesehen, und kam zu einem niederschmetternden Ergebnis. 
https://blog.fefe.de/?ts=abc108c4
https://blog.fefe.de/?ts=abc108c4
Boycott Systemd
- Ersteller Athaba
- Erstellt am
- Status
darktrym
Fahnenträger
Ich blick nicht mehr durch. Ist nun KDBUS neu und der Userlevel Kram wurde 1:1 aus dbus übernommen? Dann frage ich mich, wieso das solange dauert und warum das nicht gleich richtig macht und von neuem beginnt so wie damals vorgeschlagen. Und ja es kommt aus dem Dunstkreis von Lenny Leonard.
foxit
Well-Known Member
Das stimmt so nicht! Das einzige was ihm nicht gefällt, sind die Metadaten! Das ganze Projekt hat schon seinen Sinn:
...Die Metadaten enthalten Informationen über die beiden an der Kommunikation beteiligten Prozesse, darunter deren Berechtigungen (Capabilities). Stein des Anstoßes sind aber nicht die Capabilities, die Torvalds als sinnvoll ansieht, sondern andere Dinge wie die Kommandozeilenargumente des Prozesses. Er fordert die Entfernung der überflüssigen Daten, die seiner Ansicht nach zu Sicherheitslücken führen könnten... [1]
Gruss
[1] http://www.pro-linux.de/news/1/22272/linux-kernel-41-tritt-in-die-testphase-ein.html
kdbus ist eine Implementierung des dbus-Protokolls für den Kernel. Der Code ist allerdings weitgehend neu. Meine persönliche Meinung ist, dass ein Desktop-IPC im Kernel eine gute Idee ist. Man dann aber vielleicht doch statt des grützigen dbus-Protokolls etwas neues, sauberes spezifizieren sollte.darktrym schrieb:
-Nuke-
Well-Known Member
Nein, das war mal. Er kritisiert jetzt insgesamt KDBUS, weil er nicht feststellen kann, dass die DBUS-Performance Probleme durch den Kernel kommen.
http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939166
Sein jetziger Stand:
Macht erst DBUS schneller, dann können wir noch mal über KDBUS reden. Das Thema KDBUS ist damit erst mal vom Tisch, sofern ihn nicht noch jemand umstimmen kann.
http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1939166
darktrym
Fahnenträger
Ich seh das ja auch ein, IPC in den Kernel wenn es wirklich für was sinnvolles gebraucht wird. Aber der ganze Android IPC-Kram erfüllt das auch schon heute. Da brauch ich nicht die Semantik für etwas was genauso gut außerhalb läuft und performanzmäßig stets den kürzeren zieht.
Aber hat nicht Linus in der Mailingliste bemängelt, dass zuviel Overhead dabei ist und die Namen schauen schon verdächtig nach den alten Kram aus.
nakal
Anfänger
Braucht man nicht eher einige wenige Syscalls im Kernel, um das was Highlevel-Desktop-IPC herumschaufelt zu unterstützen? Braucht man echt solche Mechanismen (insbesondere Parser, die sowieso riskant für Sicherheit sind, weil sie oft kritische Fehler beinhalten) direkt im Kernel? Ich brauche DBUS eigentlich gar nicht in meiner Desktop-Konfiguration, aber ich sehe ein, dass das Prinzip für manche Zwecke vielleicht einen Nutzen hat.
Wobei es ist mir immer wieder aufgefallen, dass hier die Plattformneutralität bei solchen Sachen versagt. Früher als ich mich mit KDE/Gnome beschäftigt habe, hat DBUS stets hunderte von Warnungen in die Session-Logs gepumpt. Vor allem total uninteressantes Zeug. Und außerdem unterstützt DBUS das totale Desktop-Antipattern, Anwendungen mehrfach zu öffnen zu beseitigen. Das ist das, wofür es am meisten gebraucht wird, wie ich das sehe (aber totaler Schwachsinn, nebenbei erwähnt).
Wobei es ist mir immer wieder aufgefallen, dass hier die Plattformneutralität bei solchen Sachen versagt. Früher als ich mich mit KDE/Gnome beschäftigt habe, hat DBUS stets hunderte von Warnungen in die Session-Logs gepumpt. Vor allem total uninteressantes Zeug. Und außerdem unterstützt DBUS das totale Desktop-Antipattern, Anwendungen mehrfach zu öffnen zu beseitigen. Das ist das, wofür es am meisten gebraucht wird, wie ich das sehe (aber totaler Schwachsinn, nebenbei erwähnt).
Ich stimme zu, dass das DBUS-Protokoll nicht optimal ist (das würde ich jetzt auch niemanden groß vorwerfen, weil es irgendwo auch mal ein durchaus interessanter erster Wurf war, denn irgendwie muss man mal beginnen). Ich bin mir aber nicht so sicher, ob das im Kernel Sinn macht bzw. ob man für das alles nicht auf anderen IPC-Mechanismen aufbauen könnte bzw. sollte. Der Zug für die Diskussion ist zwar schon ziemlich abgefahren, in der Hinsicht, dass schon einfach viel zu viel Zeug DBUS so nutzt, aber ich finde die Idee irgendwie seltsam. "Lasst uns zu den vielen Möglichkeiten für IPC noch eine hinzufügen, die dann alle nutzen" Also kurzum denke ich, dass da Standards mit Technologien und Implementierungen vermischt werden was nicht per se immer schlecht ist (besser als Standards ganz abstrakt und damit komplex zu implementieren zu machen, was auch oft passiert), aber in dem Fall geht es ja darum - und bitte korrigiert mich, wenn ich da falsch liege - dass wir DBUS als Protokoll/Standard haben, man aber auf Grund der Kontext-Switches das Problem hat, dass die Transport Layer/Implementierung für Einige als zu ineffizient angesehen wird.
Sollte man diese Dinge nicht getrennt sehen? Ein IPC-Mechanismus, der vom Kernel zur Verfügung gestellt wird halte ich für mitunter sinnvoll, bei einem Verbund aus einem "neuen" IPC-Mechanismus im Kernel und einem Protokoll klingt ein bisschen danach einen komplexen, sehr spezifischen Monolithen bauen zu wollen, der weil er so spezifisch ist und wahrscheinlich viel optimiert wird (Performance ist das Problem, das man lösen will und so Punkte wie die Validieren und Parsen scheinen ja, wenn man der Diskussion folgt auch große Brocken für sich zu sein). Das ganze macht dann auf der einen Seite Sinn, wenn man das gerade braucht, aber aus der Sicht, dass da viel Zeit für Debugging draufgehen wird, dass damit großes Potential für Sicherheitslücken im Kernel entsteht, etc. macht mir da schon keinen guten Eindruck. DBUS ist ja eigentlich dazu da Dinge einfacher, generischer zu machen, um einen Standardweg zu haben. Vielleicht fährt man wenn das Problem der Durchsatz ist wirklich mit Alternativen, mit anderen Limitierungen, Vor- und Nachteilen besser, als wie wenn man versucht DBUS als Antwort für alles oder zumindest alles was irgendwie mit IPC zu tun hat verwenden zu wollen. Gerade bei spezielleren Sachen, wo Durchsatz ein Thema ist würde ich mir eher Alternativen ansehen, als DBUS zu verwenden.
Ich denke da liegt auch ein wenig das Problem mit dem ganzen Desktop/X.org/DBUS/systemd/..-Zeug. Man will aus Sachen wie einem Desktop-Bus oder einem Init-System eine eierlegende Wollmilchsau, die alles abdeckt machen und dann geht das ganze noch in den Server-Bereich und man spricht davon wie schön das dann mit Microservices, etc. funktioniert, die aber eigentlich genau den gegenteiligen Ansatz haben und eben wirklich eine Sache, statt allem machen.
Ein weiteres Problem, das ich sehe dürfte dieser Stress von einem Projekt auf das nächste zu Springen sein. Pulseaudio hat noch immer mal wieder Macken und im Besten Fall verbrennt es nur grundlos CPU-Zeit, dann kommt systemd, das ebenfalls immer noch seine Wehwehchen hat und wo einfach auch genug neues da ist, dass es quasi niemanden gibt, der oder die wirklich vertraut ist mit der Materie in der Hinsicht, dass es schon ein paar Jährchen an Erfahrung mit den einzelnen "Modulen" (oder wie man das Konglomerat an systemd-Tools nennen sollte, das ständig ausgeweitet wird) hätte. Und ohne praktischer Erfahrung (man muss die auch mal mit selbst programmierter Software sammeln, damit man weiß was man verbessern könnte) da aufzubauen und ohne Reviews (quasi Studien) von den Problemen damit ständig so tiefe Eingriffe im Kernel eines OS zu fordern und wie man ja in dem Mailing-Listen-Thread auch lesen konnte zu verlangen, dass Code einfach gemerged wird, ohne, dass es wirkliche Reviews gab führt zu Plattformen, die man eigentlich weitestgehend umschiffen will, wenn man nicht gerade Lust auf Abenteuer und viel eigenes Interesse an dem zu lösenden Problem hat.
Sollte man diese Dinge nicht getrennt sehen? Ein IPC-Mechanismus, der vom Kernel zur Verfügung gestellt wird halte ich für mitunter sinnvoll, bei einem Verbund aus einem "neuen" IPC-Mechanismus im Kernel und einem Protokoll klingt ein bisschen danach einen komplexen, sehr spezifischen Monolithen bauen zu wollen, der weil er so spezifisch ist und wahrscheinlich viel optimiert wird (Performance ist das Problem, das man lösen will und so Punkte wie die Validieren und Parsen scheinen ja, wenn man der Diskussion folgt auch große Brocken für sich zu sein). Das ganze macht dann auf der einen Seite Sinn, wenn man das gerade braucht, aber aus der Sicht, dass da viel Zeit für Debugging draufgehen wird, dass damit großes Potential für Sicherheitslücken im Kernel entsteht, etc. macht mir da schon keinen guten Eindruck. DBUS ist ja eigentlich dazu da Dinge einfacher, generischer zu machen, um einen Standardweg zu haben. Vielleicht fährt man wenn das Problem der Durchsatz ist wirklich mit Alternativen, mit anderen Limitierungen, Vor- und Nachteilen besser, als wie wenn man versucht DBUS als Antwort für alles oder zumindest alles was irgendwie mit IPC zu tun hat verwenden zu wollen. Gerade bei spezielleren Sachen, wo Durchsatz ein Thema ist würde ich mir eher Alternativen ansehen, als DBUS zu verwenden.
Ich denke da liegt auch ein wenig das Problem mit dem ganzen Desktop/X.org/DBUS/systemd/..-Zeug. Man will aus Sachen wie einem Desktop-Bus oder einem Init-System eine eierlegende Wollmilchsau, die alles abdeckt machen und dann geht das ganze noch in den Server-Bereich und man spricht davon wie schön das dann mit Microservices, etc. funktioniert, die aber eigentlich genau den gegenteiligen Ansatz haben und eben wirklich eine Sache, statt allem machen.
Ein weiteres Problem, das ich sehe dürfte dieser Stress von einem Projekt auf das nächste zu Springen sein. Pulseaudio hat noch immer mal wieder Macken und im Besten Fall verbrennt es nur grundlos CPU-Zeit, dann kommt systemd, das ebenfalls immer noch seine Wehwehchen hat und wo einfach auch genug neues da ist, dass es quasi niemanden gibt, der oder die wirklich vertraut ist mit der Materie in der Hinsicht, dass es schon ein paar Jährchen an Erfahrung mit den einzelnen "Modulen" (oder wie man das Konglomerat an systemd-Tools nennen sollte, das ständig ausgeweitet wird) hätte. Und ohne praktischer Erfahrung (man muss die auch mal mit selbst programmierter Software sammeln, damit man weiß was man verbessern könnte) da aufzubauen und ohne Reviews (quasi Studien) von den Problemen damit ständig so tiefe Eingriffe im Kernel eines OS zu fordern und wie man ja in dem Mailing-Listen-Thread auch lesen konnte zu verlangen, dass Code einfach gemerged wird, ohne, dass es wirkliche Reviews gab führt zu Plattformen, die man eigentlich weitestgehend umschiffen will, wenn man nicht gerade Lust auf Abenteuer und viel eigenes Interesse an dem zu lösenden Problem hat.
Ich sehe das wie Athaba. Kdbus ist wieder das typische Linux-Gebastel, ohne Rücksicht auf Verluste. Man kann doch nicht ständig neue Standards kreieren, das ist ja schlimmer als bei Microsoft. Wie will man denn Software auf andere *nix Systeme portieren, wenn man dauernd neue Kernel-Funktionen für irgendwelche Zwecke erfindet? Man muss doch auch mal klar trennen was Aufgabe eines Kernels ist, und was in den Userspace gehört. Dieser ganze Desktop-Kram gehört für mich nicht in den Kernel. Ich bin froh dass wenigstens Linus da immer wieder mal die Bremse reinhaut und nicht alles zulässt.
BTW: mich regt auch tierisch dieses "Gnome Virtual Filesystem" auf. Es legt im Homeverzeichnis des Users ein .gvfs Verzeichnis an das von root nicht gelesen werden kann, nicht mal ein stat() ist möglich. Somit fliegt an der Stelle jeder Backup aus der Kurve. Ich frage mich wie man es überhaupt fertig bringt dass root etwas nicht darf, das widerspricht sämtlichen Unix-Gepflogenheiten. Die Gnome-Leute machen irgendwie alles kaputt.
BTW: mich regt auch tierisch dieses "Gnome Virtual Filesystem" auf. Es legt im Homeverzeichnis des Users ein .gvfs Verzeichnis an das von root nicht gelesen werden kann, nicht mal ein stat() ist möglich. Somit fliegt an der Stelle jeder Backup aus der Kurve. Ich frage mich wie man es überhaupt fertig bringt dass root etwas nicht darf, das widerspricht sämtlichen Unix-Gepflogenheiten. Die Gnome-Leute machen irgendwie alles kaputt.
Der scheiss fliegt mir insbesondere @wörk ständig um die Ohren, völlig untauglich bei einem Multiuser System ...
Ich hab mir gerade mal den aktuellen Statusbericht des Devuan Projekts angesehen. Man sieht da sehr schön, dass systemd eben doch mehr als ein init-system ist, und bereits viele Dienste assimiliert hat. Aktuell arbeitet man daran mit vdev ein udev-Äquivalent zu programmieren welches ohne systemd auskommt. udev wurde schon komplett in systemd integriert. An den vielen Baustellen sieht man schön wie schwierig es jetzt schon ist aus Debian Jessie das systemd wieder herauszubekommen. Und Jessie ist ja erst der Anfang dieser ganzen Entwicklung. Gerade einen BSDler sollte das doch sehr beunruhigen, weil das Portierungen in Zukunft immer schwieriger macht.
Aber andererseits... Es gab in den letzten 20 Jahren so viel Kram aus dem Linux-Lager der nicht einfach zu portieren war oder sogar ganz klar in Richtung Vendor Lock-In lief. HAL, PolKit, ConsoleKit, nur um mal die letzte Runde aus der Kiste zu wühlen. Es gab so viele als fragwürdig aufgefasste Ideen, denen man sich nicht entziehen konnte. Beispielsweise das 1:1-Threading. Und trotzdem ging es am Ende immer irgendwie weiter, nicht einmal so schlimm wie man anfangs dachte. Daher mache ich mir keine Sorgen mehr, bevor Probleme nicht wirklich akut werden. Selbst Wayland läuft inzwischen auf FreeBSD, das einzige verbliebene Problem ist das krampfhafte bestehen auf evdev als einziges Backend für libinput.
Hier: https://lists.freebsd.org/pipermail/freebsd-x11/2015-April/016396.html
Im letzten Status-Report ist noch etwas mehr:
Im letzten Status-Report ist noch etwas mehr:
Aus: https://www.freebsd.org/news/status/report-2015-01-2015-03.html
-Nuke-
Well-Known Member
Wenn erst mal das ganze KMS Geraffel im Kernel steht und Mesa nicht allzu alt ist, dann ist Wayland ja auch nicht mehr allzu weit entfernt. Alles andere setzt dann ja wieder oben drauf und hat dann mit Wayland so direkt nichts zu tun.
Aber mangels Anwendungen die ohne XWayland funktionieren, sehe ich auch unter Linux noch keinen Drang zum Wechseln. Also in meinem Fall wären das z.B. Google Chrome, Pidgin, Gimp und Blender. Der Port von GNOME ist mit 3.16 ja auch noch nicht vollständig und benötigt noch XWayland.
Aber mangels Anwendungen die ohne XWayland funktionieren, sehe ich auch unter Linux noch keinen Drang zum Wechseln. Also in meinem Fall wären das z.B. Google Chrome, Pidgin, Gimp und Blender. Der Port von GNOME ist mit 3.16 ja auch noch nicht vollständig und benötigt noch XWayland.
darktrym
Fahnenträger
Jetzt bewahrheitet sich auch der letzte Schluss, die Bibliotheken zur Nutzung der D-Bus Funktionalität bekommen mit SD-Bus ihre Entsprechung in Systemd. Damit wirds wohl nur noch eine Frage der Zeit sein, wann auch der letzte Entwickler von D-Bus/GDBus keine Verwendung findet. Warum auch, schließlich ist auf allen Rechner Systemd installiert?
D
das.chaos
Guest
Manchmal frage ich mich... wozu SystemD, wenn es doch
schon http://smarden.org/runit/ als hinreichende Loesung
existiert???
Mal abgesehen davon (will jetzt echt nicht laestern, auch wenn es leicht
unprofessionell erscheinen vermag), mit einem GNU/Linux basierten System
eine Toolchain fuer Cross-compiling darzustellen, inklusiv einer Distribution
(Kernel, uClibc,...) als Projektionsflaeche, um Software zu entwickeln, ist
pain-in-the-ass... Steinzeit!!!
SystemD in eingebetteten Systemen... das wird interessant. :-).
schon http://smarden.org/runit/ als hinreichende Loesung
existiert???
Mal abgesehen davon (will jetzt echt nicht laestern, auch wenn es leicht
unprofessionell erscheinen vermag), mit einem GNU/Linux basierten System
eine Toolchain fuer Cross-compiling darzustellen, inklusiv einer Distribution
(Kernel, uClibc,...) als Projektionsflaeche, um Software zu entwickeln, ist
pain-in-the-ass... Steinzeit!!!
SystemD in eingebetteten Systemen... das wird interessant. :-).
chaos
*nix'ler
Systemd existiert, um ein geschlossenes System auf opensourcebasis implementieren zu können.
Besonders im sicherheitsrelevanten Bereich......
D
das.chaos
Guest
C
CrimsonKing
Guest
Ich find's witzig. 
Ich find's schade.
Nein, ernsthaft. Irgendwie spiegelt das die IT wieder. Der Sektor ist einfach zu groß geworden. Ich meine das nicht, dass es cool und "Underground" ist, sondern die Tatsache, dass mehr Leute auch mehr Leute, die einfach mitschwimmen bedeutet, etc. Das Selbe lässt sich über alles was groß wird und im Trend liegt sagen. Habe Leute sagen hören, dass sich das als die .com-Blase geplatzt ist wieder gelegt haben und Dinge besser wurden. Ich schätze mal es liegt daran, dass wir (vielleicht auch durch die Wirtschaftskrise?) einfach einen Boom von Investments führt, was bedeutet, dass einfach auch mehr Unsinn gemacht wird. Irgendwann lässt das nach oder platzt auch wieder und dann wird es wohl ans aufräumen gehen bis zum nächsten Boom.
Eine vage Theorie, aber irgendwie sehe ich so Parallelen gerade im ganzen IT-Bereich und zwar vom kleinen Unternehmen bis zu Wissenschaft (also dem Teil, den ich durch Papers oder so mitbekomme, aber mag sein, dass das daran liegt, dass ich die Populäreren lese).
Nein, ernsthaft. Irgendwie spiegelt das die IT wieder. Der Sektor ist einfach zu groß geworden. Ich meine das nicht, dass es cool und "Underground" ist, sondern die Tatsache, dass mehr Leute auch mehr Leute, die einfach mitschwimmen bedeutet, etc. Das Selbe lässt sich über alles was groß wird und im Trend liegt sagen. Habe Leute sagen hören, dass sich das als die .com-Blase geplatzt ist wieder gelegt haben und Dinge besser wurden. Ich schätze mal es liegt daran, dass wir (vielleicht auch durch die Wirtschaftskrise?) einfach einen Boom von Investments führt, was bedeutet, dass einfach auch mehr Unsinn gemacht wird. Irgendwann lässt das nach oder platzt auch wieder und dann wird es wohl ans aufräumen gehen bis zum nächsten Boom.
Eine vage Theorie, aber irgendwie sehe ich so Parallelen gerade im ganzen IT-Bereich und zwar vom kleinen Unternehmen bis zu Wissenschaft (also dem Teil, den ich durch Papers oder so mitbekomme, aber mag sein, dass das daran liegt, dass ich die Populäreren lese).
D
das.chaos
Guest
Apropos...
http://linux.slashdot.org/story/15/...tering-announces-the-first-systemd-conference
Das ist krank!!!
Die IT-industrie rennt in eine systemische Kriese... bzgl. dem
Darstellen und Implementieren von Betriebssystemen.
Imho, wegen R*dH*t und Konsorten verlernt die Industrie Betriebsysteme
dartzustellen, weil sich alle von diesem Zirkuns (imho) abhaengig machen....
eine GNU/Linux oder GNU/Systemd/Linux Monokultur (oder eher Sumpf), wo
nur noch improvisiert wird und Pseudostandards auf Basis von Konventionen,
"Social-networking" und persoenliches geschmaeckle (von Entwicklern)
durchegboxt werden entwickelt sich meines erachtens zum Security GAU...
... das ist esotherik ... das ist *pita*... nein das will ich nicht!
:-(
Vielleicht schaetze ich die Lage etwas duester ein, wenn ich versuche
in die Kristallkugel zu glotzen.
Ich find's krank.
http://linux.slashdot.org/story/15/...tering-announces-the-first-systemd-conference
Das ist krank!!!
Die IT-industrie rennt in eine systemische Kriese... bzgl. dem
Darstellen und Implementieren von Betriebssystemen.
Imho, wegen R*dH*t und Konsorten verlernt die Industrie Betriebsysteme
dartzustellen, weil sich alle von diesem Zirkuns (imho) abhaengig machen....
eine GNU/Linux oder GNU/Systemd/Linux Monokultur (oder eher Sumpf), wo
nur noch improvisiert wird und Pseudostandards auf Basis von Konventionen,
"Social-networking" und persoenliches geschmaeckle (von Entwicklern)
durchegboxt werden entwickelt sich meines erachtens zum Security GAU...
... das ist esotherik ... das ist *pita*... nein das will ich nicht!
:-(
Vielleicht schaetze ich die Lage etwas duester ein, wenn ich versuche
in die Kristallkugel zu glotzen.
- Status