Boycott Systemd

Status
Für weitere Antworten geschlossen.
Rettet die IFDEFs, verschachelt oder nicht, kann man davon jemals zu wenige haben?
...jetzt wo die GOTOs ihren Käfig im Zoo gefunden haben.
 
Einige GoTos werden wieder in die freie Wildbahn entlassen, hoffen wir mal nicht zu viele, sonst vermehren die sich noch unkontrolliert.
 
Okay, ich habe den ersten Artikel ganz gelesen, den zweiten nur stückweise.
Der erste besagt im wesentlichen, Portabilität sei fein und wünschenswert, und Systemd sei gerade der Königsweg, um die Portabilität zu verbessern. So ungefähr. :D Nein, im Ernst: Der Autor bezieht sich auf die (mit Ausnahme von logind) guten und dokumentierten Interfaces der Systemd-Komponenten und meint, es sei nicht schwer, diese auch auf anderen Systemen bereitzustellen. Genau das will OpenBSD jetzt tun. Auch wenn ich diese Argumentation verstehe, finde ich sie zum jetzigen Zeitpunkt ... fragwürdig.
Die Kommentare sind dann nicht ganz so vernünftig, u. a. um FreeBSD solle man sich besser gar nicht kümmern, die lehnen ja sogar die GPL ab, diese Schweine ;)
Der zweite Blog versucht vor allem, die Argumente der Systemd-Gegner zu entkräften, hörst Du, nakal? Den Follow-ups war u. a. zu entnehmen, daß sich KDE bisher noch sehr stark zurückhält, irgendeine Abhängigkeit zu Systemd zu schaffen.

PS: Kamikaze, das war ein sehr mutiges Outing, und damit machst Du allen Mut, die sich ihrer Neigung zum Goto immer noch schämen. Danke!!! Eines Tages werden wir eine große Bewegung sein. Joh! :gpaul:
 
Ich verstehe nicht was ihr gegen goto habt. Es ist meisterhaft in FreeBSD-Sourcen verwendet worden. Da sieht man auch wieso und warum es viel besser als alle Alternativen sind. Wie auch andere C-Anweisungen, sollte man stets wissen wann es Vorteile hat, sie zu verwenden. goto zugegeben sehr selten, aber es ist da und es will genutzt werden.

Lasst Euch nicht von irgendwelchen Leuten, die selbst nicht programmieren (insbesondere Profs) in die Irre leiten.
 
Kurz mein Senf dazu, auch wenn ich das sicher schon mal hier geäußert hatte. Das Grundproblem ist und bleibt wie in allen Beiträgen das fehlende Verständnis was Portabilität bedeutet. Nach Ansicht dieser beiden Herren eine Metapher: Ein Zug kann gut auch auf der Straße fahren, es muss sich nur jemand finden der was dafür baut.
Nach meinem Verständnis ist das genau das Gegenteil von Portabilität. Mal abgesehen davon, dass der Code dann ungewartet und unverstanden im Repo schlummert und andere sich darauf verlassen und das mehr als peinlich. Entweder gehört Portabilität mit zum Projekt, dann muss ich mich wohl oder übel auch woanders einarbeiten oder ich lass es ganz bleiben. Dann sind die Patches eben in Ports/Pkgsrc.
Ich versteh den Grund warum man Systemd nutzen will, man braucht die Funktionalität aber will sie lieber nicht selbst programmieren und warten.
Eigentlich wie im richtigen Arbeitsleben, jemand anderes soll's machen. Macht ja auch mehr her, fehlerfrei dank weniger Code, nur wenn ich portable Software schreiben will, muss ich mich doch vorher kundig machen, ob die von mir unterstützten Systeme das auch nutzen können. Ich kann mich nicht entsinnen, dass die Entscheidung Pro-Systemd auf Basis des unfertigen BSD Daemon basierte.
Gut dazu passt ja auch die Begründung warum Gnome portabel ist, Leute bei OpenBSD und FreeBSD haben das gemacht. Ich hoffe wirklich sehr, Leute bei Gnome haben auch was dazu beigetragen. Und ahoi, wo kommen wir denn da hin, wenn praktisch Externe ihren Code zusteuern müssen und das eigentliche Release ungetestet ist. Dann kommt einer noch mit der Aussage, es kann gut sein, dass die Patches/Hacks wieder rausgewurfen werden.
Dass im Kommentarbereich dieses Gnome Blocks dann überwiegend Gleichgesinnte auftreten, die sich dann selbst bestätigen, gibt dann den Rest. Ja wir mögen Systemd nicht, nicht weil euer Linuxökosystem einen riesigen Single Point of Failure bekommt, sondern weil unsere genutzte Software immer mehr Aufwand bedarf, um sie weiterhin zu nutzen.
Wenn ein Stück Software so nah beim User sitzt, nämlich der Desktop, dann brauchts auch vernünftige getrennte Implementierungen meinetwegen APIs wo die OSes ihren Teil implementieren können und keine IFDEF Kaskaden, die dann ohnehin rausgeschmissen werden, wenn ein Linux Entwickler meint, es wird nicht mehr gebraucht.
Ich möchte dann doch noch die Gegenbeispiele wie libressl oder Lumina erwähnen. Lumina funktioniert derzeit auch auf Linux, Support für andere OSe wird wohl noch kommen, ja sogar vor Open-, Net- und Dragonfly BSD. Und wie lange hat's da gedauert die BSDismen zu abstrahieren und einen Port zu basteln? Oder LibreSSL, mehr oder weniger sauber getrennte Logik. Der Kern ist wartbar. Ich würde mir wünschen, die Leute würden Portabilität so verstehen wie der Name sagt. Ich selbst unterstützte aktiv andere Plattformen und kümmere mich bei Bugs um die Behebung statt irgendein PR Mist von sich zu geben.
 
Ich verstehe nicht was ihr gegen goto habt. Es ist meisterhaft in FreeBSD-Sourcen verwendet worden. Da sieht man auch wieso und warum es viel besser als alle Alternativen sind. Wie auch andere C-Anweisungen, sollte man stets wissen wann es Vorteile hat, sie zu verwenden. goto zugegeben sehr selten, aber es ist da und es will genutzt werden.

Lasst Euch nicht von irgendwelchen Leuten, die selbst nicht programmieren (insbesondere Profs) in die Irre leiten.

So, mein letzter Beitrag zum Thema goto, weil das Off-Topic ist. Ich will hier noch mal klarstellen was goto in C/C++ bedeutet und wofür es gut ist.

Erst einmal, in C/C++ kann man goto nur innerhalb einer Funktion/Methode machen. Das hat einen großen Vorteil: Springen ohne den Stack zu verändern. Das hat man mit If und Schleifen auch, aber goto ist keine Alternative dazu sondern eine Möglichkeit Code-Duplizierung zu minimiren ohne neue Funktionen zu definieren, die semantisch einen eigenen Kontext haben, der das Programm weniger lesbar machen kann. Dazu müsste man die Funktionen noch inline definieren, damit der Compiler das zusätzliche Stack-Frame einsparen kann (in bestimmten Kontexten inlinen Kompiler auch automatisch).

Das Paradebeispiel ist das was ich als Common-Exit-Code Pattern bezeichnen würde (keine Ahnung was die offizielle Bezeichnung ist).

Code:
if (inputs.empty()) {
     [Aktion 0]
     return true;
}

while (auto val : inputs) {
    if (!val) {
        [Aktion 1];
        return false;
    }
}

[Aktion 0]
return true;

Wie man in dem Beispiel sieht, nicht-triviale, mehrere Zeilen Code [Aktion 0] ist dupliziert. Der eine oder andere Compiler erkennt solchen Common-Exit-Code automatisch und macht genau das daraus was man alternativ in C/C++ direkt schreiben kann:
Code:
if (inputs.empty()) {
    goto exit_success;
}

while (auto val : inputs) {
    if (!val) {
        [Aktion 1];
        return false;
    }
}

exit_success:
[Aktion 0]
return true;

Wenn man sich vorstellt, dass [Aktion 0] 5 Zeilen Code sind … hier ein Echtwelt-Beispiel:
Code:
void Node::collapse(size_t scale) {
	Node * parents[sizeof(voxel) * 8];
	parents[scale] = nullptr;
	Node * node = this;

	while (node && node->touched) {
		/*
		 * Delve deeper, this relies on some conditions:
		 *	- All touched nodes have children
		 *	- An untouched node never has touched descendants
		 */
		while (Node::getTouchedChild(scale, parents, node));

		/*
		 * Collapse the affected branches.
		 */
		/* Stop collapsing if non-leaf nodes are encountered. */
		for (size_t i = 0; i < 8; ++i) {
			if (node->children[i].hasChildren()) {
				goto ascent;
			}
		}

		/* Do not collapse if nodes have different solid states. */
		node->solid = node->children[0].solid;
		for (size_t i = 1; i < 8; ++i) {
			if (node->children[i].solid != node->solid) {
				goto ascent;
			}
		}

		/* Collapse. */
		delete[] node->children;
		node->children = nullptr;

	ascent:
		/* Leave this node behind and return to the parent. */
		node->touched = 0;
		node = parents[scale++];
	}
}

Ein anderes typisches Beispiel ist das gezielte ausbrechen aus verschachtelten Schleifen.
 
Mein letztes off-topic: Ja eben das. Einer der Anwendungsfälle, in dem ich goto für gut erachte. Der Code sollte aber auch oft "sprechend" sein. So ist auch oft "goto try_again_with_another_request;" aus einer tieferen Logikverschachtelung einfacher zu verstehen als kaskadierende if/break-Anweisungen, um sauber aus Loops herauszukommen. break/continue/switch ist übrigens ähnlich wie goto und case sind wie jump-Labels.
 
Nur bei logind dürfte es schwierig werden, die API ist unnötig komplex und packt für meinen Geschmack zu viel Funktionalität mit zu wenig Abstraktion in ein einziges Interface. Vermutlich wird man hier in der Praxis mit einer überschaubaren Untermenge an tatsächlich implementierter Funktionalität auskommen, das wird aber trotzdem eine undankbare Aufgabe.
Die anderen 3 APIs sind gut gemacht und sollten einen Entwickler, der etwas Ahnung in der Domäne hat, vor keine größere Herausforderung stellen.
Gerade logind ist ja scheinbar für eine ganze Reihe von Projekten und für typische Desktopsysteme interessant.

Hatte generell mit meiner Aussage an logind gedacht, weil OpenBSD IMO aus guten Grund auch kein PAM hat. Das OpenBSD-Projekt ist generell auch kein riesiger Fan von Abstraktion - bzw. nicht von zu viel natürlich. Da ist es im Verhältnis zu anderen Systemen recht konservativ, auch wenn sie natürlich existiert wo es Sinn macht.

Klar, PAM ist nicht logind und das ist ja auch nur ein Beispiel, aber gerade das macht das OpenBSD-systemd-Interface es ja gerade so spannend. Das OpenBSD ist ja auch mal der Ansicht Standards entweder nicht vollständig zu implementieren oder gar zu brechen, wenn sie es für Schwachsinn halten. Wenn nun systemd ein Interface für X bereitstellt und das OpenBSD das für Schwachsinn hält, dann treffen da zwei Welten aufeinander.

Kann mir aber mittlerweile gut vorstellen, dass das irgendwie ausgelagert wird und dieses ganze Zeug wirklich außerhalb von Base gehalten wird, auch wenn es sonst sehr nahe am System ist.
 
Hmmm aus der Quelle hier lese ich heraus

http://www.undeadly.org/cgi?action=article&sid=20140915064856
Upon completion and review, my code will most likely end up as a port to be installed along with the GNOME suite, or any other ports that depend on systemd (upstream) and need a compatibility layer to work properly on non-systemd operating systems.


das du da genau recht hast - das wird ein Paket sein das ggf. als abhängigkeit für Gnome & Co. Installiert wird.
 
Gerade was systemd in GNOME angeht, neige ich dazu, den oben zitierten Blogeinträgen recht zu geben.

Portabilität bedeutet mMn nicht, dass GNOME-Entwickler, welche auf Linux only arbeiten, Unterstützung für BSD einbauen müssen. Portabilität bedeutet für mich "Offen für Erweiterung, geschlossen für Änderung". In dem Fall genügt es meiner Meinung nach, wenn diese Entwickler auf ein Interface hinprogrammieren und Patches annehmen. Es liegt dann an den BSD-Affinen Leuten diese Interfaces bereitzustellen, Zwischenlayer einzuziehen, Patches zu liefern oder sich auch mal gegen etwas zu wehren. (Vollkommen klar. Ist genauso unser gutes Recht.)

Wenn in einem Open Source Projekt der Anteil an Entwicklern(!), welche ein bestimmtes Ziel (ein bestimmtes OS) unterstützen gering ist, ist es eine ganz natürliche Entwicklung, dass dieses Ziel in diesem Projekt an Bedeutung verliert. Natürlich ist das fustrierend, wenn es einen trifft. Ich kann auch das raunzen und boykottieren usw. nachvollziehen. Aber ehrlich gesagt, ein OpenSource-Entwickler unter Linux ist nicht verantwortlich dafür, dass das Zeug unter BSD läuft. Wer das Zeug haben will, muss es entwickeln, oder darauf warten, bis es genügend Leute gibt, die es wollen und entwickeln.

Mich würde es wirklich interessieren, worum es hier geht. :-) Warum soll ich als Entwickler/Anwender Systemd boykottieren?

Wenn ich eine systemd API anbieten muss, um zu bekommen, das ich will, ist es doch sinnvoll, diese Api wie auch immer anzubieten? (oder wie auch immer eine Alternative zu bieten)

Oder geht ich zu sehr von der Prämisse aus, dass es hier um "Wir wollen das neue Zeug nicht, weil dazu müssen wir... und außerdem ist es eh nicht ausgereift usw... " geht und eigentlich geht es viel mehr um einen aus der Historie begründeten Frust, dass bereits funktionierende Dinge kaputt gehen?

Aber warum sind kaputte Pakete ein valides Argument? Eigentlich ist ja das bestehende stabile System nicht kaputt, man bekommt das Update "lediglich" nicht gratis. D.h. man muss was tun, um was zu bekommen.
 
Wenn der Kern aus Systemd Funktionalität besteht und dieses Stück Software nicht portabel ist, kann auch ein Produkt welches dieses nutzt, auch nicht sein, qed. Zumal Gnome gerade die Alternativen zusammenstreicht. Soweit ich das überblicke ist der OpenBSD Ansatz, schau mal da läuft was, was Systemd heißt, drunter machts was komplett anderes. Das komplette OS Verhalten müsste im Daemon implementiert werden, damit Gnome sich dort genauso verhält wie unter Linux.
 
Wenn ich eine systemd API anbieten muss, um zu bekommen, das ich will, ist es doch sinnvoll, diese Api wie auch immer anzubieten? (oder wie auch immer eine Alternative zu bieten)

Ich kann dieser und vimix' anderen Ausführungen nur zustimmen.

Wenn der Kern aus Systemd Funktionalität besteht und dieses Stück Software nicht portabel ist, kann auch ein Produkt welches dieses nutzt, auch nicht sein, qed.

Was soll denn das für ein Beweis sein?!

Du bist doch auch auf BSDForen.de unterwegs, das AJAX-Aufrufe mittels XHR-API im Browser absetzt. Dessen allererste Implementierung war via ActiveX im Internet Explorer vorhanden.

Analog dazu ist es GNOME völlig egal, welche Implementierung tatsächlich hinter einer systemd-API (z.B. SetHostname()) tatsächlich steckt.

Zumal Gnome gerade die Alternativen zusammenstreicht. Soweit ich das überblicke ist der OpenBSD Ansatz, schau mal da läuft was, was Systemd heißt, drunter machts was komplett anderes. Das komplette OS Verhalten müsste im Daemon implementiert werden, damit Gnome sich dort genauso verhält wie unter Linux.

Genau dafür erschafft man doch Abstraktionen - damit der Anwendung darüber die Implementierungsdetails egal sein können.

Auch systemd kocht nur mit Wasser, die APIs und Funktionalität sind kein Hexenwerk - dementsprechend sollten die BSDs deren Implementierung doch bewerkstelligen können. Falls man es aber tatsächlich nicht hinbekommen sollte, eine funktional äquivalente Implementierung der erwähnten APIs zu entwickeln, muss man sich mal tief in die Augen schauen.
 
Natürlich hängts davon ab was man wie implementiert. Im Fall von Gnome brauchts du Funktionalität X, erwartest folgende Eigenschaften und rufst dann Systemd Subsystem auf, bekommst genau das was du gewollt hast. Du hast nirgends definiert, ich benutzte folgende API Funktionen, die sich wie folgt verhalten(Laufzeit, Ausgaben, etc.). Das kann bei Web mehr oder weniger problematisch sein, bei Systembsd ist das die Achillesferse..
Genau dasselbe Problem bekommt man auch bei Wayland, die API ist zwar definiert, die Client erwarten aber bestimmtes Verhalten oder patcht sich das wieder zurecht.
Alleine die API nachzuahmen ist nur der halbe Weg. Anschließend müsste man den Entwicklern sagen, das es andere Implementierungen gibt, wo Teile gar nicht oder anders funktionieren, das bestimmte Annahmen eben nur das sind.
Schlussendlich stehen wir dann wieder vor dem Problem wie kompatibel sind die Systemd Alternativen bzw. die Kernel zueinander. Gibts Denkpausen der Verarbeitung nur weil eine Infobeschaffung länger braucht als bei Linux. Wie oft muss die Systemd Alternative im Sync gehalten werden und nachgebessert werden, brechen Apps bei unterschiedlichen Versionen. Die Verzahnung von Linux & Kernel zu Systemd sind doch bereits hinreichend bekannt.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben