• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Boycott Systemd

Status
Nicht offen für weitere Antworten.

Azazyel

Well-Known Member
Mittlerweile ist man dabei den Kern von Linux schlechthin zu zerballern.
Wärst du so frei, das etwas auszuführen und zu begründen?

Ihr braucht noch mehr gender Experten
Nein danke. Mir reichen schon auf Arbeit die Kollegen, die viel Augenmerk auf "gender & diversity issues" setzen und auch ansonsten durch mangelnde Kompetenz und keinerlei nützliche Beiträge zum Gesamtwerk auffallen.

Das hat dann ntpd gemacht. Sollte bei openntpd nicht anders sein. systemd hat damit dann relativ wenig zu tun.
Ich hatte mit OpenNTPD auch Probleme unter Debian, damals noch unter SysVinit. In den einschlägen Foren gab es reichlich Leute mit dem gleichen Problem; ich habe es aber nicht weiter verfolgt und einfach chrony genommen.
 
Der Kern von Linux ist im wesentlichen Linus.

Nicht einfach, weil er's nunmal geboren hat und schon gar nicht, weil er der Einzige ist, der ordentlich entwicklen/proggen kann. Sondern weil seine Ruppigkeit und technische Besessenheit unverzichtbar sind. Aber auch weil weit und breit niemand in Sicht ist, der ihn ersetzen könnte (und akzeptiert würde, usw). Hässliches Beispiel: greg kroah-hartman? Dann wird aus linux bald ein diversity und social factor blabla Diskutierclub.

Und An- und Übergriffe gibt's doch schon reichlich. redhat, sara dingsbums und ihr Schneckchenrechte Club, systemd ...

Meine persönliche Einschätzung: Der Plan, den u.a. gkh hinterhältig (mal wieder) mitträgt und betreibt ist, "Belastung von Linus zu nehmen" und "die Vielfalt hinter Linux auch an der Spitze zu repräsentieren" und eine Art Leitungsgruppe zu etablieren, der Linus vorsteht ... aber nicht lange ... dann kommen sara und Komplizen, Firmenvertreter ("die tragen ja auch am meisten Code und Kohle bei") ... usw. bis alles verstümmelt und verkackt und mit Hintertüren verseucht ist.
 

-Nuke-

Well-Known Member
sowas (aus Application Layer) hat imho nicht im Kernelspace zu suchen.
Linux hatte bisher keinen "eigenen" IPC-Mechanismus im Gegensatz zu OS X oder Android.

Der IPC Kram von Android wurde/wird auch in den Mainline Kernel aufgenommen. Aber auch nicht aus dem Grund "er ist toll", sondern "er läuft auf Millionen Geräten und funktioniert dort, obwohl der Code scheiße ist".

Hauptgrund ist Performance und nicht nur systemd benutzt dbus. So ziemlich alles unter Linux benutzt mittlerweile dbus. Die grundlegende IPC davon im Userspace zu machen hat keine Vorteile, im Gegenteil, es kostet Performance und damit Energie und damit Akkulaufzeit.

Das erste Konzept von kdbus war scheiße und wurde jetzt über die Jahre aufgebessert. So viel Kritik gibt's da eigentlich nicht mehr, oder sagen wir mal lieber "nicht mehr als anderswo nicht auch schon".

Und selbst in einem Microkernel ist IPC Bestandteil des Kernels. Woanders macht das auch wenig Sinn, außer man kopiert die Daten wie blöde hin und her.
 
D

das.chaos

Guest
@Nuke volle Zustimmung...

... aber kdbus ist imho kein IPC Mechanismus (im eigendlichen
Sinne, wie IPC definiert ist) das ist eine Applikation von IPC.

*Sorry das konnte ich mir jetzt nicht verkneifen* :-)

Wenn ich mir schon das...

https://github.com/systemd/systemd/search?utf8=✓&q=alloca

ansehe... wird mir schwindelig.

Irgendwie kommt mir der Eindruck das systemd+Konsorten
das technische Niveau von OS Entwicklung momentan gewaltig
"herunterziehen".
 

-Nuke-

Well-Known Member
... aber kdbus ist imho kein IPC Mechanismus (im eigendlichen
Sinne, wie IPC definiert ist) das ist eine Applikation von IPC.
???

kdbus überträgt Nachrichten von Prozess A nach Prozess B. Mehr nicht. Was ist daran jetzt nicht so wie IPC definiert ist? Der ganze andere Kram bleibt im Userspace.

Das der ganze Kram so kompliziert erscheint liegt hauptsächlich daran, dass Linux eben kein Microkernel ist und grundlegende Sicherheits-Angelegenheiten eben nicht per Definition korrekt sind, sondern eben erst auf Korrektheit geprüft werden müssen.
 

-Nuke-

Well-Known Member
Es geht dabei nicht um "nicht realisieren können", sondern rein um Performance, vermeiden von dauender kopiererei, etc.. Der verlinkte Heise Artikel + der dort verlinkte Heise Artikel zu kdbus sagt eigentlich alles, auch warum Binder von Android nicht dazu passt ;)

Sockets und Co. sind alle Low Level Ansätze mit all ihren Problemen (z.B. kein Zero Copy, kein festgelegtes Protokoll, ...).

Es gibt auch zig verschiedene Scheduler in Linux. Ist nicht so, als wenn Linux immer nur eine Implementierung von irgendwas hat.Aber High Level IPC ist noch ein Punkt der so gar nicht vorhanden ist.
 

darktrym

Fahnenträger
In Sachen Performanz für Embedded Systems wie es bei Smartphones der Fall ist, ist Android Binder nicht langsamer, eigentlich ist KDBUS da sogar langsamer. Hier gehts um die erweiterte Semantik, Prozesse abonnieren Nachrichten des Buses. Mehr Sicherheit kann damit gewährleistet werden und eben über das Netzwerk kann das geschehen. Shared Memory ist trotzdem immer performanter da primitiver und passender für viele Usecases. Da DBUS Anwendungen künftig über Systemd verkehren werden kann man sich das ausrechnen, was da auf einen zukommt. DBUS-artige Anwendungen werden von weniger Kontextwechseln profitieren.
 

-Nuke-

Well-Known Member
In Sachen Performanz für Embedded Systems wie es bei Smartphones der Fall ist, ist Android Binder nicht langsamer, eigentlich ist KDBUS da sogar langsamer. Hier gehts um die erweiterte Semantik, Prozesse abonnieren Nachrichten des Buses. Mehr Sicherheit kann damit gewährleistet werden und eben über das Netzwerk kann das geschehen.
Richtig, darum ist die Android Variante keine Option.

Shared Memory ist trotzdem immer performanter da primitiver und passender für viele Usecases. Da DBUS Anwendungen künftig über Systemd verkehren werden kann man sich das ausrechnen, was da auf einen zukommt. DBUS-artige Anwendungen werden von weniger Kontextwechseln profitieren.
Shared Memory folgt aber keinerlei Regeln. Jede Anwendung hat quasi vollen Zugriff und kann dir ggf. alle Anwendungen "zerferkeln". Das passiert dir bei "vernünftiger IPC" nicht, da der Kernel Kontrolle hat wer was macht. Dazu muss der Kernel aber wissen was du machen willst, statt dass er einfach nur ein Stück Speicher allen Anwendungen zur Verfügung zu stellen. Das ist dann gut, wenn du mit deinen eigenen Prozessen kommunizieren willst. Aber wenn du einer x-beliebigen Anwendung Zugriff geben willst, dann ist Shared Memory "leicht doof". Und DBUS ist nun auch kein Weg, dass du ALLES darüber machen sollst. Es soll einfach nur das sowieso schon extrem vorhandene DBUS stark beschleunigen und somit auch Energie sparen.

Und wie gesagt. So ziemlich alles arbeitet bei Linux über DBUS. Ob du deine Lautstärke einstellst, einen USB-Controller anschließt oder dein Netzwerk mal eben Offline ging. Alles dbus-Nachrichten.
 

Athaba

Libellenliebhaber
Themenstarter #637
libsystemd-bus
New client library, designed to be easy to use
Not portable to non-Linux
Assemble and parse messages with format strings
Handles introspection, signal dispatching, method vtables,
properties, object manager
Lots of convenience functions
Focus on converting errno from/to bus errors
Connect to container, connect to remote
Credentials include units, slices, sessions, . . .
It's probably what you want to use when you hack on system level
software, and up
Mal das Spannendste herausgehoben. ;)

Quelle: https://archive.fosdem.org/2014/sch.../anatomy_of_kdbus/slides/460/kdbus_fosdem.pdf

Aber nachdem BSD ja eh ein wenig Hype halt in letzter Zeit hat könnte man vielleicht ein nettes Interface, vielleicht basierend auf bestehenden Mitteln bauen.

Ich verstehe auch das nicht-portierbar nicht. Irgendwie hat das so wie ich das sehe nichts, was man grundsätzlich nicht portieren könnte (nur gibt's eben den systemd-Schweif als Abhängigkeit).
 

darktrym

Fahnenträger
Es gibt dazu einen Vortrag, den ich komplett vergessen hab, aber ich könnte mir vorstellen, die Formulierung liegt im Kernel begründet. Um diesen Service für systembsd nachzubauen, muss dbus im Kernel sein.
 

-Nuke-

Well-Known Member
Naja, im Endeffekt bewegt man sich damit langsam in die Arbeitsweisen die im Microkernel Umfeld schon seit ewig quasi Standard sind. Nur halt ohne Microkernel und damit halt ne ganze Ecke komplexer (man bewegt sich relativ lange im Kernelspace, daher viele Prüfungen nötig).

Das dürfte sicherlich auch so ein heimlicher Grund sein, warum vernünftiges IPC im Linux Kernel bisher keinen Einzug gehalten hat. Linus hat sich im Streit mit Tanenbaum direkt gegen solche Konzepte entschieden. Auch FUSE hat es schwer gehabt.

Das macht natürlich aus Linux noch lange keinen Microkernel und das wird Linux auch nie werden, aber die Anwendungen werden dann wohl mehr und mehr so arbeiten als wäre es ein Microkernel.
 
Also Linus hat offiziell auch gesagt, dass zerocopy scheiße ist und BSDs sollen das für sich behalten. Dass die lokale Kommunikation mit Sockets dann kein zerocopy kann ist rein ihre eigene Politik. Ich bin da auch skeptisch bei "high-level" und "Kernel". Ein Kernel sollte minimal sein und nur die Mittel dazu liefern, alles mit Anwendungen zu realisieren.

Ich weiß immer noch nicht was mir kdbus liefert, was ich benötigen könnte. Mich hat dbus sehr genervt, weil die Anwendungen es dazu genutzt haben, zu verhindern, dass man eine zweite Instanz starten kann (und das ist mir einfach zu blöd, weil ich diese Funktion oft gerade beabsichtige). Also noch einmal... was kann kdbus nützliches für Anwendungen liefern (und sagt nicht Kommunikation, das ist nicht präzise genug! es geht um Mechanismen, die fehlen und nicht Mechanismen, die einfach anders sind).

(Btw, die haben doch irgendetwas im Kernel nachimplementiert, was kdbus erst erlaubt hat zu funktionieren. Das ist wahrscheinlich das was tatsächlich gefehlt hat und der Rest ist eigentlich Bloat.)
 

-Nuke-

Well-Known Member
Also Linus hat offiziell auch gesagt, dass zerocopy scheiße ist und BSDs sollen das für sich behalten. Dass die lokale Kommunikation mit Sockets dann kein zerocopy kann ist rein ihre eigene Politik. Ich bin da auch skeptisch bei "high-level" und "Kernel". Ein Kernel sollte minimal sein und nur die Mittel dazu liefern, alles mit Anwendungen zu realisieren.
Da bist du aber auch bei den BSDs falsch. ;) Die BSD-Kernel sind auch alles andere als "Minimal".

Ich weiß immer noch nicht was mir kdbus liefert, was ich benötigen könnte. Mich hat dbus sehr genervt, weil die Anwendungen es dazu genutzt haben, zu verhindern, dass man eine zweite Instanz starten kann (und das ist mir einfach zu blöd, weil ich diese Funktion oft gerade beabsichtige). Also noch einmal... was kann kdbus nützliches für Anwendungen liefern (und sagt nicht Kommunikation, das ist nicht präzise genug! es geht um Mechanismen, die fehlen und nicht Mechanismen, die einfach anders sind).
kdbus liefert dir vom Funktionsumfang erst mal nicht mehr als das alte dbus. Es frisst eben nur deutlich weniger Ressourcen. Es geht hierbei nicht darum irgendetwas neues, anderes zu machen, sondern das vorhandene weniger stumpfsinnig ablaufen zu lassen. Und nein, man hat nicht KOMPLETT dbus in den Kernel verlagert.

Was dbus als ganzes liefert ist aber nunmal die Kommunikation zwischen den einzelnen Schichten. Du schließt ein USB-Controller an, dann kann dein Spiel informiert werden, dass dies geschehen ist. Dein Netzwerk fällt aus, dann kann dein Netzwerkdienst die Anwendungen informieren, dass sie nicht versuchen brauchen weiter Daten ins Netz zu senden und auf Timeouts zu warten. Du stellst deine Sound-Ausgabe auf Stumm, dann brauchen deine Anwendungen auch keinen Ton mehr ausgeben, kommt ja bei dir eh nicht mehr an.

All solche Sachen.

Und da braucht man jetzt nicht mit dem Argument kommen: "Das geht auch alles ohne dbus"... ja, natürlich, indem jede Anwendung für jede Art von Gegenanwendung die entsprechenden Schnittstellen implementiert und dauert am pollen ist. Und genau das verhindert dbus. Es ist ein einheitlicher Weg Nachrichten zwischen Anwendungen auszutauschen. Egal welche.

Ob die Implementierung jetzt besonders toll ist, sei mal dahin gestellt. Es kam ja nun auch niemand mit irgend etwas besserem hervor. Und wer jetzt das IPC von Android nennt, der soll sich mal die Kritik daran angucken ;)

Und IPC auf Kernel Ebene ist jetzt echt nichts neues xD Und das Argument "das geht auch alles mit dem Bisherigen" hat uns so tolle Sachen wie Xorg eingebracht... ne Danke ;)
 
Da bist du aber auch bei den BSDs falsch. ;) Die BSD-Kernel sind auch alles andere als "Minimal".
Ich weiß. Aber Du brauchst mir aber auch nicht mit den Mikrokerneln zu kommen. Ich brauche schon irgendwas als Betriebssystem, was wenigstens einen Browser hat, nicht so wie Minix.

hat uns so tolle Sachen wie Xorg eingebracht
Du meinst wahrscheinlich HALD. Aber deswegen gibt es ja auch das ganze Anti-systemd-Theater, weil HALD war ja der letzte Hype, der von Linux kam und wo alles an Anwendungen das in den Himmel gelobt haben und wir sollten da alle unbedingt mitgehen. Am Ende wo man mit der Implementation gerade fertig war, haben sie es dann begraben.

Wir haben ja jetzt devd und devfs, was über Hardware Anwendungen benachrichtigen kann. Bei vielen Sachen wo man annimmt, dass man Anwendungen sagen kann "es ist nicht mehr nötig", wäre ich vorsichtig. Ich gebe Dir einige Beispiele:

1) Nur weil ich einen USB-Controller anschließe, heißt es noch lange nicht, dass es für die Anwendung gedacht ist.
2) Mit TCP sieht man, dass es keine Netzwerkanbindung mehr gibt, außerdem ist das Protokoll so gestrickt, dass es keine Pakete verliert, wenn das Netz minutenlang weg ist.
3) Nur weil ich den Mixer abdrehe, heißt es nicht, dass der Sound nicht aufgenommen werden soll, die Anwendung soll den Sound gefälligst auch dann produzieren. Er wird halt nur nicht abgespielt.
 

-Nuke-

Well-Known Member
Ich weiß. Aber Du brauchst mir aber auch nicht mit den Mikrokerneln zu kommen. Ich brauche schon irgendwas als Betriebssystem, was wenigstens einen Browser hat, nicht so wie Minix.
Ich ziehe nur einen Vergleich zur Arbeitsweise, nicht zu den MK-Systemen.

Du meinst wahrscheinlich HALD.
Nein, ich meine schon Xorg. Diese riesige Ansammlung an Workarounds mit einer extra Ladung Sicherheitslücken.

Wir haben ja jetzt devd und devfs, was über Hardware Anwendungen benachrichtigen kann.
Ja, FreeBSD-Only ;) Linux-Only ankreiden und FreeBSD-Only feiern ist keine Verbesserung. Auf devd und devfs kannst du dann auch dbus-Nachrichten aufbauen. Und Lautstärkeänderungen erkennt das trotzdem nicht.

1) Nur weil ich einen USB-Controller anschließe, heißt es noch lange nicht, dass es für die Anwendung gedacht ist.
2) Mit TCP sieht man, dass es keine Netzwerkanbindung mehr gibt, außerdem ist das Protokoll so gestrickt, dass es keine Pakete verliert, wenn das Netz minutenlang weg ist.
3) Nur weil ich den Mixer abdrehe, heißt es nicht, dass der Sound nicht aufgenommen werden soll, die Anwendung soll den Sound gefälligst auch dann produzieren. Er wird halt nur nicht abgespielt
Es geht hier nicht darum was dbus macht, sondern was möglich ist. dbus verdreht dir _NICHTS_ im System. Es sendet nur Nachrichten. Bei TCP kriegst du keine Info "Paket kann nicht ankommen, du hast gerade kein Internet", sondern du musst auf einen Timeout warten. Wenn du die WLAN-Verbindung manuell trennst und kein LAN-Kabel dran hast, dann kannst du das der Anwendung auch direkt sagen, ohne gigantische Timeouts. Genauso würde ich mir wünschen, dass mein Client sich neu verbindet, wenn mein Internet wieder da ist. Auf TCP warten ist blödsinn, meine IP-Adresse kann sich bis dahin geändert haben. Das ist auch der Grund warum sich Sachen wie XMPP nicht im Mobilbereich durchsetzen konnten. Sie bauen auf altmodischem Kram auf, der im mobilen Bereich so nicht funktioniert. Was braucht man? Workarounds!

Und klar, man kann sich seine Welt bauen wie man will. Für Leute die alles per Hand verdrahten wollen, für die ist das natürlich nichts. Da haben aber ein Großteil der anderen Leute sicherlich kein Bock drauf, inkl. mir. Und ich wüsste auch nicht warum ich einen Controller per Hand verdrahten sollte, statt das die Anwendung einfach einen erkennt und ich dann die Option habe diesen zu nutzen.

Solange halt keiner mit einer guten Alternative kommt, ist und bleibt dbus das Medium dafür. Und nein, alles manuell machen ist keine gute Alternative.
 
Das hat aber nichts mit Xorg zu tun, was IPC angeht.

Dafür kann man nichts. Wir haben devfs schon sehr lange. Linux-Entwickler haben sich immer erfolgreich um eine gute Implementation gedrückt und haben so lange wir devfs haben schon 3(?) dev-Pseudodateisysteme gehabt. Am Ende sind sie bei udev gelandet, was eigentlich ziemlich gut dem devfs entspricht, nur eben immer noch blöd ist. Da kann man nichts machen, wenn sie jahrelang daneben entwickeln, obwohl alles schon da ist und gut funktioniert.

Wieso funktioniert Lautstärke nicht? Ich habe sie sogar im Dock oben angezeigt und mit Hotkeys kann man sie hoch und runter regeln. Das ist doch keine Raketenwissenschaft.

Ich weiß, dass dbus nichts verdreht. Ich habe über das Durcheinander gesprochen, was daraus resultiert, dass Anwendungen sich gegenseitig beeinflussen.

Nein bei TCP kann es sein, dass das Modem neu gestartet wird. Das habe ich schon zahlreiche Male gemacht und noch nie eine Verbindung verloren. Da ändert sich auch nicht die IP, die legt der Router fest. Da neu zu verbinden ist total Schwachsinn, weil solange das Modem nicht up ist und Pakete weiter schaufelt, ist da nichts mit Neuverbinden.

XMPP ist einfach Scheiße im Mobilbereich, weil es TCP ist und das kein Roaming kann. Deswegen nimmt man da BOSH als Krücke. Der Entwickler muss einfach nur das Hirn einschalten und feststellen, dass was er da entwickelt fürn A**ch ist. Das kann man auch mit solchen Blödsinn wie Neustarts nicht mehr retten, was bei systemd offensichtlich die Lösung für jede Art von Problem ist. Und das ist einfach nur ganz grobe Kacke.
 

Tronar

aus Überzeugung altmodisch
XMPP ist einfach Scheiße im Mobilbereich, weil es TCP ist und das kein Roaming kann. Deswegen nimmt man da BOSH als Krücke.
BOSH ist doch auch TCP. Es geht wohl eher um die Richtung, in der die Verbindung aufgebaut wird. Und eigentlich ist BOSH ja dazu gemacht, durch Firewalls durchzukommen.
Welches freie Instant-messaging-System würdest Du denn empfehlen. SIP z. B. hat die Nachteile von XMPP doch noch in verschärfter Form - und sonst gibt es da kaum was ...
 
BOSH ist auch TCP, aber funktioniert nach Request-Reply, so wie HTTP es eben gestaltet ist. Für Web-Seiten-Angucken brauchst Du ja auch nicht eine permanente Verbindung zu halten.

Ich empfehle gar nichts. Ich nehme natürlich XMPP, weil es nichts anderes gibt. Aber es heißt nicht, dass ich es gut finde. Hätte der Tag 72h, dann hätte ich schon längst was geschrieben. Die Zeiten als ich Schüler war und sehr produktiv war, sind schon längst um. :)
 

CommanderZed

OpenBSD User
Mitarbeiter
XMPP läuft doch eigentlich recht gut Mobil? Lt. diversen Infos basiert doch sogar WhatsApp auf XMPP, welches ja, hab ich mir sagen lassen, im Mobilbereich "relativ" erfolgreich sein soll *hust*
 

pwp

Well-Known Member
XMPP läuft doch eigentlich recht gut Mobil?
Ich habe damit auch keine Probleme. Betreibe einen Server mit prosody und speziell mod_smacks, wodurch die Erweiterung XEP-0198 (Stream Management) implementiert wird. Ich verwende unter Android als Client yaxim (das XEP-0198 ebenfalls unterstützt), was mir auch bei Zugfahrten durchs halbe Bundesland mit etlichen Disconnects keine Probleme bereitet.
 

Tronar

aus Überzeugung altmodisch
Nakal bezog sich wohl auf den Fall wechselnder IP-Adressen, z. B. wenn das Handy in den Bereich eines WLANs kommt und von UMTS auf WLAN schaltet. Damit habe ich noch keine Erfahrung, Ihr? Hilft da XEP-0198 was?
 

CommanderZed

OpenBSD User
Mitarbeiter
pwp> Bei Yaxim läuft es bei mir ähnlich gut, auch beim wechsel ins heimische WLAN - hab aber glaub ich weder BOSH noch XEP auf meiner prosody installation aktiviert oO
 
Status
Nicht offen für weitere Antworten.