To decide which of the three APIs to use for you C project, here are short guidelines:
If you hack on a GLib/GObject project, GDBus is definitely your first choice.
If portability to non-Linux kernels -- including Windows, Mac OS and other UNIXes -- is important to you, use either GDBus (which more or less means buying into GLib/GObject) or libdbus (which requires a lot of manual work).
Otherwise, sd-bus would be my recommended choice.
Die Frage wäre wohl eher, ob Toolkits wie Qt (aktuell mit QtDBus als Wrapper für libdbus) sich den Aufwand machen würden beide Implementationen (libdbus und sdbus) zu unterstützen. Auf libdbus können die nicht verzichten auf Grund des Windows-Support.
Generell bleibt die Frage unbeantwortet, wie groß der Aufwand wäre beide Implementationen bzw. sdbus zusätzlich zu unterstützen. Was natürlich auch daran liegt, dass das sicherlich von der spezifischen Anwendung abhängt.
Dass er sagt, dass Leute sdbus nutzen sollen, damit das nur noch auf Linux funktioniert kann man ihm zumindest in diesem Blogpost nicht vorwerfen. Auch wenn Lennart hin und wieder mal diese Einstellung zu Tage bringt.
Die Frage wäre wohl eher, ob Toolkits wie Qt (aktuell mit QtDBus als Wrapper für libdbus) sich den Aufwand machen würden beide Implementationen (libdbus und sdbus) zu unterstützen.
Das hätte nur Mehraufwand für wenig bis keinen Nutzen.
QtDBus ist m.W. dabei, so wie anderen Highlevelimplementierungen davor, D-Bus direkt zu umzusetzen, also ohne über libdbus zu gehen
Was ich auf die Schnelle dazu gefunden habe: http://lists.qt-project.org/pipermail/development/2014-October/018576.html http://quickgit.kde.org/?p=dferry.git&a=blob&h=c599c0bf5349bdb6ec2a9cc873bd57f135a92484&hb=ca12f211982de76aa7e629d61a8fefeda27aa7ad&f=plan.txt
Mit beiden Bibliotheken kann man auch ein System benutzen, in dem kdbus den Bus bereitstellt.
Das Ziel ist längerfristig aber ohnehin eine direkte Implementierung des Protokolls, so wie GDBus und die Implementierungen von Mono und Java das schon machen
sd-bus ist die Client-Seite. Die Client-Seite braucht sowieso nicht portabel zu sein. Dies ist wie das Web: die Web-Seite wird von dem Server zur Verfügung gestellt (z.B. als Apache), verschiedene Clients können dann die Web-Seite anzeigen (Firefox, Chrome, Opera, IE, usw.). Apache sollte portabel sein, damit ich Linux oder BSD oder Windows auf dem Server benutzen kann. Die Clients brauchen aber nicht portabel zu sein.
kdbus oder der d-bus Daemon ist die Server-Seite. sd-bus ist der Client. d-bus ist das Protokoll.
Dir ist schon klar, das es sich hier um eine Client BIBLIOTHEK handelt die von anderen Programmen verwendet werden soll. Wenn also die Programmierer meinen die lausige Performance von D-Bus reicht nicht aus oder die Abhängigkeit ist kein Problem weil sie ohnehin überall gegeben ist und setzen dann auf SD-Bus, hast du wieder das gleiche Problem wie mit allen Systemd-Kram. Man darf patchen, forken eben einen wesentlich aufwendigeren Weg sich basteln, aus der scheinbaren Alternative Systemd wird eine De-facto-Abhängigkeit.
Nicht mein Problem. Wenn es ein Problem für dich ist hast du die Möglichkeiten: a) öffne einen Bug-Report. b) schreibe einen Patch, c) setzte ein anderes Programm ein dass nicht sd-bus benutzt. Oder auch d) bezahle einen Entwickler der einen Patch für dich schreibt.
Der Artikel liest sich fast so als ob sd-bus einen kdbus überflüssig machen könnte, was ich bezweifle. Wie soll eine Programmierschnittstelle die bisher genannten Defizite der userspace basierenden dbus-server beheben können?
die kdbus, ..gibts für das 'die\ eine begründung der bus, daher der kdbus würd ich meinern oder doch das kdbus weils a ein ding ist. aber doch nicht die,
Ein alternativer Server ist mit kdbus in Arbeit, einer Implementation im Linux-Kernel, die hauptsächlich wegen technischer Bedenken, die aber lösbar sind, nicht in den neuen Kernel 4.1 aufgenommen wurde.
Ist das wieder die Poetteringsche Darstellung oder eine objektive, technisch fundierte Aussage des Autors?
Das liest sich in einem Posting von Linus Torvalds, das jemand im heise-Forum verlinkt hat, nämlich ein ganz klein wenig anders: https://lkml.org/lkml/2015/4/27/741
"Just to make sure, I did a system-wide profile (so that you can actually see the overhead of context switching better), and that didn't change the picture.
The scheduler overhead *might* be 1% or so.
So really. The people who talk about how kdbus improves performance are just full of sh*t. Yes, it improves things, but the improvement seems to be 100% "incidental", in that it avoids a few trips down the user-space problems."
Da besteht doch eher die Vermutung, dass Poettering jetzt irgendsoein neues sd-bus zusammenfrickelt, weil er begriffen hat, dass er keine Chance hat, kdbus jemals in den Kernel zu bekommen und Kernel-Entwickler zu werden, aber dank seiner Weltherrschaftsphantasien unbedingt was eigenes für sein Poetterix zusammenfrickeln muss, was dann natürlich nur zusammen mit systemd läuft.
Dass dieses sd-bus mit an Sicherheit grenzender Wahrscheinlichkeit nur den Softwareentwicklern offen steht, deren Software auch zwingend systemd vorraussetzt, verschweigt er natürlich mal wieder dezent, weil es für ihn ja überhaupt nicht vorstellbar ist, dass es tatsächlich noch Leute gibt, die noch immer nicht auf sein ach so supertolles systemd stehen.
Das würde auch erklären, dass die Poettering-Fanboys in letzter Zeit so ruhig geworden sind und nicht mehr permanent, die Foren und Mailinglisten mit ihrem Gejammer über kdbus zugetextet haben. Es wäre sonst auch recht verwunderlich, dass ausgerechnet Greg KH Kernel 4.1 zum LTS-Kernel erklärt hätte, wenn die Wahrscheinlichkeit gegeben wäre, dass kdbus in Kernel 4.2 integriert würde. Denn immerhin muss systemd so ja noch jahrelange mit einem Kernel ohne kdbus zusammenarbeiten, was bei Poettering doch bestimmt eine Lebenskrise hervorgerufen hat.
Dein Posting ist wieder mal ein gutes Beispiel dafür, was in der systemd-Diskussion schief läuft. Im Ansatz bringst Du berechtigte (technische) Kritik, die Du mit Zitaten hinterlegst. Soweit ok, hier hätte man einen guten Ausgangspunkt zum debattieren.
Bloß dann, sorry für die Wortwahl, versaust Du es gewaltig mit Sprüchen und Begriffen wie
zusammenfrickelt
(als ob die SysVInit-Skripte das nicht wären...)
dank seiner Weltherrschaftsphantasien unbedingt was eigenes für sein Poetterix zusammenfrickeln muss
- eine unsachliche und persönliche Polemik
nicht auf sein ach so supertolles systemd stehen
- Polemik
Poettering-Fanboys [...] mit ihrem Gejammer
- persönliche Herabwertung der "Gegenseite"
was bei Poettering doch bestimmt eine Lebenskrise hervorgerufen hat
- Polemik auf Kindergarten-Niveau
Sorry, es ist wirklich kein Wunder, wenn Diskussionen SO immer direkt in Flamewars ausarten. Macht wirklich keinen Spaß...
Nicht wirklich, zumindest mal bei weitem nicht so wie das Zeug von Poettering.
dank seiner Weltherrschaftsphantasien unbedingt was eigenes für sein Poetterix zusammenfrickeln muss
eine unsachliche und persönliche Polemik
Keineswegs und schon gar nicht unsachlich. Eine Analyse all dessen, was Poettering so von sich gibt und wie er sich vor allem seinen Kritikern gegenüber verhält. Nur er hat die Weisheit mit Löffeln gefressen, alle anderen haben keine Ahnung. Und wer nicht für ihn ist, ist gegen ihn, dabei ist er gegen jeden, der nicht seiner Meinung ist. Und außerdem hatte er schon mit PulseAudio versucht, diesen halbfertigen und unter professionellen Bedingungen nicht funktionierenden Krempel als Pseudostandard in allen Distributionen durchzudrücken. Ist ihm erfreulicherweise bis heute nicht gelungen. Mit systemd, das für professionelle Anwendungen auch überhaupt nichts taugt, sondern allenfalls in einzelnen Consumeranwendungen irgendwie halbwegs läuft, versucht er es um so drastischer. Und alle seine Fanboys laufen ihm wie einem Guru hinterher.
nicht auf sein ach so supertolles systemd stehen
Polemik
Auch keine Polemik. Er und seine Fanboys halten es doch für so supertoll. Es gibt genügend andere Leute, die wissen, dass es Schrott ist. Und das mit den technischen Argumenten, hast sogar du zugegeben.
Komisch ist doch, dass Poettering und seine Fanboys ständig technische Argumente verlangen. Liefert man ihnen die dann, sind es auf einmal keine technischen Argumente. Stattdessen gibt es nur sinnfreies Geblubber als Antwort und haufenweise Beleidigungen seiner Kritiker gegenüber insbesondere auch in Poetterings eigener ach so technischen systemd-Dokumentation.
Man sollte erstmal vor seiner eigenen Türe kehren, bevor man anderen Polemik vorwirft.
Poettering-Fanboys [...] mit ihrem Gejammer
persönliche Herabwertung der "Gegenseite"
Auch falsch. Die genau passende Beschreibung von Poettering und seinen Fanboys, die ihm ständig mit ihrer rosa-roten Brille wie einem Guru hinterherlaufen. Außerdem wer beleidigt denn wen in seiner ach so technischen Dokumentation und in allen Diskussionen? Das sind doch wohl Poettering und seine Fanboys. Wenn man Leute, die anderer Meinung sind und vielleicht ein wenig mehr technisches Verständnis haben als man selbst, ständig niederredet und ständig beleidigt, muss man sich über entsprechende Reaktionen nicht wundern.
Wie gesagt, erstmal vor der eigenen Türe kehren.
was bei Poettering doch bestimmt eine Lebenskrise hervorgerufen hat
Polemik auf Kindergarten-Niveau
Auch keine Polemik, sondern auch wieder Beobachtung des Verhaltens von Poettering und seinen Fanboys und daraus resultierende sachliche Schlussfolgerung.
Sorry, es ist wirklich kein Wunder, wenn Diskussionen SO immer direkt in Flamewars ausarten.
Auch hier verwechselst du wieder Ursache und Wirkung. Wer nicht diskutieren kann, weil er überhaupt nicht dazu in der Lage ist, auch nur ansatzweise andere Meinungen und Kritik zu akzeptieren, sind Poettering und seine Fanboys. Poettering und seine Fanboys halten sich für die Helden und alle anderen für ahnungslose Vollidioten und behandeln sie auch so.
Es wurden seitens der Poettering-Kritiker schon viele Versuche einer sachlichen Diskussion unternommen. Sind leider alle daneben gegangen eben wegen des Verhaltens von Poettering und seinen Fanboys.
Und hätte Poettering nicht diese Weltherrschaftsphantasien und würde er systemd schlicht als zusätzliches, alternatives Init-System anbieten und nicht versuchen, dieses Teil jedem User aufzwingen zu wollen, ob er (der User) will oder nicht, (Stichwort: Weltherrschaftsphantasien), und würde er seine Kritiker mal ernst nehmen, gäbe es diese Flamewars überhaupt nicht.
Nimm also erstmal deine rosa-rote Brille ab und beschäftige dich mal ein wenig mehr mit Poettering und zwar nicht nur aus der Sicht eines Fanboys, sondern aus objektiver Sicht.
Macht wirklich keinen Spaß...
Richtig! Es macht wirklich keinen Spaß, mit Poettering und seinen Fanboys zu diskutieren, weil es schlicht nicht möglich ist, mit denen eine sachliche Diskussion zu führen, weil man nämlich ständig gegen eine Wand redet.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Jun 2015 um 21:03.
Lass gut sein, es reicht. Ich hoffe, Du erwartest keine Antwort auf den Wortschwall. Nur eins:
Mit systemd, das für professionelle Anwendungen auch überhaupt nichts taugt
Red Hat Enterprise Linux 7 (http://distrowatch.com/table.php?distribution=redhat) SUSE Linux Enterprise 12 (http://distrowatch.com/table.php?distribution=sle) Debian GNU/Linux 8 (http://distrowatch.com/table.php?distribution=debian)
Bitte jeweils unter "Pakete", "systemd" nachschauen. Danke.
Bitte jeweils unter "Pakete", "systemd" nachschauen. Danke.
Und? Spricht nicht gerade für diese Distributionen. Ich hoffe du weißt aber auch, dass Poettering bei Redhat angestellt ist, was übrigens auch nicht gerade für Redhat spricht, aber mit Sicherheit der wesentliche Grund dafür ist, dass Redhat auf systemd umgestiegen ist.
Im Übrigen halte ich gerade diese Distributionen überhaupt nicht mehr geeignet für den professionellen Einsatz und das übrigens nicht nur wegen systemd. Nur weil da irgendwo ein "Enterprise" dran hängt, heißt das noch lange nicht, dass das die ultimative Profi-Distribution ist.
Sieh du dich lieber mal u.a. bei Gentoo, Slackware, Mint und Void um. Da gibts systemd allenfalls optional als eines von mehreren Init-Systemen, wenn überhaupt, und definitiv nicht als Default- oder Zwangs-Init-System.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Jun 2015 um 22:59.
Mit systemd, das für professionelle Anwendungen auch überhaupt nichts taugt
Nur weil da irgendwo ein "Enterprise" dran hängt,
bezahlen Unternehmen Unsummen für Support-Abonnements und erwarten zugleich hochgradige Performance und Stabilität bis hin zur Hochverfügbarkeit. Wer bezeichnet sowas schon als professionell, wenn er täglich mit Gentoo, Slackware oder Mint (!) zu tun hat?
bezahlen Unternehmen Unsummen für Support-Abonnements und erwarten zugleich hochgradige Performance und Stabilität bis hin zur Hochverfügbarkeit.
Selbst schuld, wenn sie für ein freies Betriebssystem Unsummen zahlen, nur weil da ein "Enterprise" dranhängt. Übrigens nicht, dass ich was gegen finanzielle Untestützung der OpenSource-Community hätte.
Das liest sich in einem Posting von Linus Torvalds, das jemand im heise-Forum verlinkt hat, nämlich ein ganz klein wenig anders:
Was Linus sagt ist, dass ein Argument Performance "Bullshit" sei, aber (zumindest in dieser Email) nicht, dass es KDBus nicht in den Kernel schaffen wird.
Da besteht doch eher die Vermutung, dass Poettering jetzt irgendsoein neues sd-bus zusammenfrickelt, weil er begriffen hat, dass er keine Chance hat, kdbus jemals in den Kernel zu bekommen und Kernel-Entwickler zu werden, aber dank seiner Weltherrschaftsphantasien unbedingt was eigenes für sein Poetterix zusammenfrickeln muss, was dann natürlich nur zusammen mit systemd läuft.
Da muss ich dich enttäuschen: https://github.com/systemd/systemd/commit/de1c301ed165eb4d04a0c9d4babe97912b5233bb D.h. das ist schon über 2 Jahre alt.
Auf den Rest deiner Lebenskrise gehe ich mal nicht ein...
Was Linus sagt ist, dass ein Argument Performance "Bullshit" sei, aber (zumindest in dieser Email) nicht, dass es KDBus nicht in den Kernel schaffen wird.
Dann lies mal, was Linus sonst noch so zu Poettering im Allgemeinen und zu kdbus im Speziellen geschrieben hat. Linus hat nämlich durchaus schon mal darauf hingewiesen, dass er Poettering nicht unter den Kernelentwicklern haben möchte und das aus sehr guten Gründen. Und dass er von kdbus nicht viel hält, sondern lieber eine andere, bessere und vor allem allgemein besser nutzbare IPC-Implementation im Kernel hätte, wenn überhaupt, hat er auch schon geschrieben.
D.h. das ist schon über 2 Jahre alt.
Hat Poettering da also noch was angefangen und nicht zu Ende gebracht? Wieso wundert mich das nicht? Und wozu dann noch diesen kdbus, wenn er doch schon so ein supertolles sd-bus entwickelt hat?
Auf den Rest deiner Lebenskrise gehe ich mal nicht ein...
Ich hab keine Lebenskrise, aber vermutlich Poettering, weil kdbus noch immer nicht im Kernel steckt, er noch immer kein Kernelentwickler ist und ihn und seine Software noch immer nicht alle Linux-User so supertoll finden. Ich schrieb es ja bereits: Weltherrschaftsphantasien. Zumindest ist er ganz gewaltig gestört. Sonst würde er sich anders verhalten.
Oh und wie gerade auf Phoronix verlinkt würde ich dir empfehlen mal diese Email von Linus Torvalds zu lesen: http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html
Das klingt nun gar nicht danach als wollte er es unbedingt ablösen, sondern eher so wie ich es in der ersten Antwort schrieb: Er ist von dem Performance Argument einfach nicht überzeugt.
Aber die Email heißt auch überhaupt nicht (wie von Phoronix jetzt angegeben), dass es bald gemergt wird.
Oh und wie gerade auf Phoronix verlinkt würde ich dir empfehlen mal diese Email von Linus Torvalds zu lesen:
Hab ich gemacht. Ich hoffe, du hast diese e-mail von Linus Torvalds auch gelesen und auch verstanden. Er hat da nämlich noch so einige Argumente mehr aufgezählt, warum er kdbus nicht im Kernel haben will. Er hats in dieser e-mail nur mal etwas weniger drastisch formuliert.
Als Linus schrieb das https://lkml.org/lkml/2015/4/28/733
"It's *stupid* to add a kernel driver to get 2x improvement, when there's a 10x bloat in user space."
ist es etwas Schade das niemand darauf hingewiesen hat, das die angebliche 2x Performancesteigerung nicht mal gegeben ist. Die Genivi-Leute haben das ausführlich untersucht und festgestellt
"The bottom line is, that these implementation and API problems together additionally provide similar performance increase compared to moving the message routing into the kernel."
Eine komplette Nullnummer und am Ende hängt dbus im Kernel. Tux-Webserver die Zweite.
.. und laestern
Und wie immer konstruktive Kritik
Versteh ich das richtig, man soll doch lieber SDBus nutzen damit das ganze nur noch auf Linux funktioniert statt auf D-Bus und GDBus.
Das sagt Lennart dazu:
Die Frage wäre wohl eher, ob Toolkits wie Qt (aktuell mit QtDBus als Wrapper für libdbus) sich den Aufwand machen würden beide Implementationen (libdbus und sdbus) zu unterstützen. Auf libdbus können die nicht verzichten auf Grund des Windows-Support.
Generell bleibt die Frage unbeantwortet, wie groß der Aufwand wäre beide Implementationen bzw. sdbus zusätzlich zu unterstützen. Was natürlich auch daran liegt, dass das sicherlich von der spezifischen Anwendung abhängt.
Dass er sagt, dass Leute sdbus nutzen sollen, damit das nur noch auf Linux funktioniert kann man ihm zumindest in diesem Blogpost nicht vorwerfen. Auch wenn Lennart hin und wieder mal diese Einstellung zu Tage bringt.
Das hätte nur Mehraufwand für wenig bis keinen Nutzen.
QtDBus ist m.W. dabei, so wie anderen Highlevelimplementierungen davor, D-Bus direkt zu umzusetzen, also ohne über libdbus zu gehen
Was ich auf die Schnelle dazu gefunden habe:
http://lists.qt-project.org/pipermail/development/2014-October/018576.html
http://quickgit.kde.org/?p=dferry.git&a=blob&h=c599c0bf5349bdb6ec2a9cc873bd57f135a92484&hb=ca12f211982de76aa7e629d61a8fefeda27aa7ad&f=plan.txt
Ob es sich dafür lohnt kann ich natürlich nicht beantworten, kann ja auch sehr spezifisch sein.
Mit beiden Bibliotheken kann man auch ein System benutzen, in dem kdbus den Bus bereitstellt.
Das Ziel ist längerfristig aber ohnehin eine direkte Implementierung des Protokolls, so wie GDBus und die Implementierungen von Mono und Java das schon machen
Auf libdbus können die nicht verzichten auf Grund des Windows-Support.
Nicht nur Windows sondern auch zB BSD. Auch alles Linux was nicht zwangsweise systemd hat wie ChromeOS, etc.
sd-bus ist die Client-Seite. Die Client-Seite braucht sowieso nicht portabel zu sein.
Dies ist wie das Web: die Web-Seite wird von dem Server zur Verfügung gestellt (z.B. als Apache), verschiedene Clients können dann die Web-Seite anzeigen (Firefox, Chrome, Opera, IE, usw.). Apache sollte portabel sein, damit ich Linux oder BSD oder Windows auf dem Server benutzen kann. Die Clients brauchen aber nicht portabel zu sein.
kdbus oder der d-bus Daemon ist die Server-Seite. sd-bus ist der Client. d-bus ist das Protokoll.
Dir ist schon klar, das es sich hier um eine Client BIBLIOTHEK handelt die von anderen Programmen verwendet werden soll. Wenn also die Programmierer meinen die lausige Performance von D-Bus reicht nicht aus oder die Abhängigkeit ist kein Problem weil sie ohnehin überall gegeben ist und setzen dann auf SD-Bus, hast du wieder das gleiche Problem wie mit allen Systemd-Kram. Man darf patchen, forken eben einen wesentlich aufwendigeren Weg sich basteln, aus der scheinbaren Alternative Systemd wird eine De-facto-Abhängigkeit.
Nicht mein Problem. Wenn es ein Problem für dich ist hast du die Möglichkeiten: a) öffne einen Bug-Report. b) schreibe einen Patch, c) setzte ein anderes Programm ein dass nicht sd-bus benutzt. Oder auch d) bezahle einen Entwickler der einen Patch für dich schreibt.
Der Artikel liest sich fast so als ob sd-bus einen kdbus überflüssig machen könnte, was ich bezweifle. Wie soll eine Programmierschnittstelle die bisher genannten Defizite der userspace basierenden dbus-server beheben können?
"Das Hauptargument für sd-bus ist, dass es die kdbus, den Server-Code im Kernel, nutzen kann, wenn vorhanden."
Dieser eine Satz macht den letzten den Absatz auch nicht leichter zu lesen...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Jun 2015 um 09:24.die kdbus, ..gibts für das 'die\ eine begründung
der bus, daher der kdbus würd ich meinern
oder doch das kdbus weils a ein ding ist.
aber doch nicht die,
sd-bus ist eine C Bibliothek für Anwendungs-/Dienstentwickler, denen libdbus zu low-level und GDBus zu high-level ist.
Dass sd-bus sowohl mit einem dbus-daemon basierten System als auch mit einem kdbus basiertem System arbeiten kann ist mehr ein Zusatzfeature.
Das liest sich in einem Posting von Linus Torvalds, das jemand im heise-Forum verlinkt hat, nämlich ein ganz klein wenig anders:
https://lkml.org/lkml/2015/4/27/741
"Just to make sure, I did a system-wide profile (so that you can
actually see the overhead of context switching better), and that
didn't change the picture.
The scheduler overhead *might* be 1% or so.
So really. The people who talk about how kdbus improves performance
are just full of sh*t. Yes, it improves things, but the improvement
seems to be 100% "incidental", in that it avoids a few trips down the
user-space problems."
Da besteht doch eher die Vermutung, dass Poettering jetzt irgendsoein neues sd-bus zusammenfrickelt, weil er begriffen hat, dass er keine Chance hat, kdbus jemals in den Kernel zu bekommen und Kernel-Entwickler zu werden, aber dank seiner Weltherrschaftsphantasien unbedingt was eigenes für sein Poetterix zusammenfrickeln muss, was dann natürlich nur zusammen mit systemd läuft.
Dass dieses sd-bus mit an Sicherheit grenzender Wahrscheinlichkeit nur den Softwareentwicklern offen steht, deren Software auch zwingend systemd vorraussetzt, verschweigt er natürlich mal wieder dezent, weil es für ihn ja überhaupt nicht vorstellbar ist, dass es tatsächlich noch Leute gibt, die noch immer nicht auf sein ach so supertolles systemd stehen.
Das würde auch erklären, dass die Poettering-Fanboys in letzter Zeit so ruhig geworden sind und nicht mehr permanent, die Foren und Mailinglisten mit ihrem Gejammer über kdbus zugetextet haben. Es wäre sonst auch recht verwunderlich, dass ausgerechnet Greg KH Kernel 4.1 zum LTS-Kernel erklärt hätte, wenn die Wahrscheinlichkeit gegeben wäre, dass kdbus in Kernel 4.2 integriert würde. Denn immerhin muss systemd so ja noch jahrelange mit einem Kernel ohne kdbus zusammenarbeiten, was bei Poettering doch bestimmt eine Lebenskrise hervorgerufen hat.
Dein Posting ist wieder mal ein gutes Beispiel dafür, was in der systemd-Diskussion schief läuft. Im Ansatz bringst Du berechtigte (technische) Kritik, die Du mit Zitaten hinterlegst.
Soweit ok, hier hätte man einen guten Ausgangspunkt zum debattieren.
Bloß dann, sorry für die Wortwahl, versaust Du es gewaltig mit Sprüchen und Begriffen wie
(als ob die SysVInit-Skripte das nicht wären...) - eine unsachliche und persönliche Polemik - Polemik - persönliche Herabwertung der "Gegenseite" - Polemik auf Kindergarten-NiveauSorry, es ist wirklich kein Wunder, wenn Diskussionen SO immer direkt in Flamewars ausarten.
Macht wirklich keinen Spaß...
Komisch ist doch, dass Poettering und seine Fanboys ständig technische Argumente verlangen. Liefert man ihnen die dann, sind es auf einmal keine technischen Argumente. Stattdessen gibt es nur sinnfreies Geblubber als Antwort und haufenweise Beleidigungen seiner Kritiker gegenüber insbesondere auch in Poetterings eigener ach so technischen systemd-Dokumentation.
Man sollte erstmal vor seiner eigenen Türe kehren, bevor man anderen Polemik vorwirft.
Auch falsch. Die genau passende Beschreibung von Poettering und seinen Fanboys, die ihm ständig mit ihrer rosa-roten Brille wie einem Guru hinterherlaufen. Außerdem wer beleidigt denn wen in seiner ach so technischen Dokumentation und in allen Diskussionen? Das sind doch wohl Poettering und seine Fanboys. Wenn man Leute, die anderer Meinung sind und vielleicht ein wenig mehr technisches Verständnis haben als man selbst, ständig niederredet und ständig beleidigt, muss man sich über entsprechende Reaktionen nicht wundern.Wie gesagt, erstmal vor der eigenen Türe kehren.
Auch keine Polemik, sondern auch wieder Beobachtung des Verhaltens von Poettering und seinen Fanboys und daraus resultierende sachliche Schlussfolgerung.Auch hier verwechselst du wieder Ursache und Wirkung. Wer nicht diskutieren kann, weil er überhaupt nicht dazu in der Lage ist, auch nur ansatzweise andere Meinungen und Kritik zu akzeptieren, sind Poettering und seine Fanboys. Poettering und seine Fanboys halten sich für die Helden und alle anderen für ahnungslose Vollidioten und behandeln sie auch so.Es wurden seitens der Poettering-Kritiker schon viele Versuche einer sachlichen Diskussion unternommen. Sind leider alle daneben gegangen eben wegen des Verhaltens von Poettering und seinen Fanboys.
Und hätte Poettering nicht diese Weltherrschaftsphantasien und würde er systemd schlicht als zusätzliches, alternatives Init-System anbieten und nicht versuchen, dieses Teil jedem User aufzwingen zu wollen, ob er (der User) will oder nicht, (Stichwort: Weltherrschaftsphantasien), und würde er seine Kritiker mal ernst nehmen, gäbe es diese Flamewars überhaupt nicht.
Nimm also erstmal deine rosa-rote Brille ab und beschäftige dich mal ein wenig mehr mit Poettering und zwar nicht nur aus der Sicht eines Fanboys, sondern aus objektiver Sicht.
Richtig! Es macht wirklich keinen Spaß, mit Poettering und seinen Fanboys zu diskutieren, weil es schlicht nicht möglich ist, mit denen eine sachliche Diskussion zu führen, weil man nämlich ständig gegen eine Wand redet. Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Jun 2015 um 21:03.Lass gut sein, es reicht.
Red Hat Enterprise Linux 7 (http://distrowatch.com/table.php?distribution=redhat)Ich hoffe, Du erwartest keine Antwort auf den Wortschwall. Nur eins:
SUSE Linux Enterprise 12 (http://distrowatch.com/table.php?distribution=sle)
Debian GNU/Linux 8 (http://distrowatch.com/table.php?distribution=debian)
Bitte jeweils unter "Pakete", "systemd" nachschauen. Danke.
Im Übrigen halte ich gerade diese Distributionen überhaupt nicht mehr geeignet für den professionellen Einsatz und das übrigens nicht nur wegen systemd. Nur weil da irgendwo ein "Enterprise" dran hängt, heißt das noch lange nicht, dass das die ultimative Profi-Distribution ist.
Sieh du dich lieber mal u.a. bei Gentoo, Slackware, Mint und Void um. Da gibts systemd allenfalls optional als eines von mehreren Init-Systemen, wenn überhaupt, und definitiv nicht als Default- oder Zwangs-Init-System.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Jun 2015 um 22:59.Wer bezeichnet sowas schon als professionell, wenn er täglich mit Gentoo, Slackware oder Mint (!) zu tun hat?
Gute Nacht...
https://github.com/systemd/systemd/commit/de1c301ed165eb4d04a0c9d4babe97912b5233bb
D.h. das ist schon über 2 Jahre alt.
Auf den Rest deiner Lebenskrise gehe ich mal nicht ein...
Oh und wie gerade auf Phoronix verlinkt würde ich dir empfehlen mal diese Email von Linus Torvalds zu lesen:
http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html
Das klingt nun gar nicht danach als wollte er es unbedingt ablösen, sondern eher so wie ich es in der ersten Antwort schrieb: Er ist von dem Performance Argument einfach nicht überzeugt.
Aber die Email heißt auch überhaupt nicht (wie von Phoronix jetzt angegeben), dass es bald gemergt wird.
oT
Der von Lennart verlinkte Performancevergleich testet nur gdbus nicht aber libdbus. gdbus ist bekannterweise langsamer als libdbus.
http://lists.freedesktop.org/archives/dbus/2010-October/013628.html
Als Linus schrieb das https://lkml.org/lkml/2015/4/28/733
"It's *stupid* to add a kernel driver to get 2x
improvement, when there's a 10x bloat in user space."
ist es etwas Schade das niemand darauf hingewiesen hat, das die angebliche 2x Performancesteigerung nicht mal gegeben ist. Die Genivi-Leute haben das ausführlich untersucht und festgestellt
http://lists.genivi.org/pipermail/genivi-ipc/2013-February/000037.html
"The bottom line is, that these implementation and API problems together additionally provide similar performance increase compared to moving the message routing into the kernel."
Eine komplette Nullnummer und am Ende hängt dbus im Kernel. Tux-Webserver die Zweite.