Aus meiner Sicht hauptsächlich, dass es Shell-Skript-basiert ist. systemd hat einen rein deklarativen Ansatz, das ist einfach um Größenordnungen leichter zu administrieren und zu debuggen. Man kann in OpenRC inzwischen optional aber auch deklarativ arbeiten, du hast dann trotzdem noch ein Shell-Skript, in dem aber nur Konstanten deklariert werden. So ähnlich war das in Upstart auch, mit dem Resultat, dass nur wenige Services von diesen Features Gebrauch gemacht haben. Man musste sich also trotzdem noch dauernd mit imperativen Skripts rumärgern.
Das musst du bei systemd eben nicht mehr. Du hast nur noch deklarative Unit-Files, das ganze SysV-Gerümpel ist entsorgt, und als Daemon-Entwickler musst du keinen Boilerplate mehr schreiben, weil dir systemd sehr viel Arbeit schon abnimmt. Es ist manchmal einfach notwendig, alte Zöpfe abzuschneiden und grundlegende Änderungen einzuführen. Eine Migration auf OpenRC wäre von meinem Standpunkt aus also wieder ein Rückschritt.
Schön wäre, wenn es zu systemd eine Alternative gäbe, die zumindest einige der Features -wie z.B. die Unit-Files- implementiert. Dann könnte man zwei Init-Systeme anbieten; diese würden aber mit der gleichen (oder zumindest ähnlichen) Konfiguration arbeiten.
Theoretisch spricht ja nichts dagegen eine systemd-Alternative zu entwickeln, die auf die unit-Files zugreift und diese versteht.
Systemd wandelt ja auch on-the-fly sysv-scripte in units um. Ich mag systemd und die deutlich vereinfachte Konfiguration mit den Units und deren Abhängigkeiten usw. Das aber alles mit systemd erschlagen werden muss (DNS? Zeitserver? Login?) find ich arg übertrieben.
Der Hintergedanke dabei ist, dass dann z.B. die NTP-,Resolver-, Netzwerkkonfiguration,... über alle systemd-basierten Distribution einheitlich wäre. Also ein Schritt in die Vereinheitlichung der Linux-Distributionen.
Wir haben bei uns z.B. SLES, Redhat, Debian und Ubuntu-Systeme, die alle unterschiedlich zu konfigurieren sind und ich hab noch nicht verstanden, warum das so sein muss.
Von einfache Antworten sind gefrag am Di, 10. Dezember 2019 um 08:49 #
>... und ich hab noch nicht verstanden, warum das so sein muss. Dann könnte man ja die ganzen verschiedenen Distributionen einstellen und nur noch eine verbreiten. Aber welcher "Hersteller" will sein Produkt und seinen Führungsanspruch aufgeben???
Debian sollte sich unbedingt in der Kerninfrastruktur unabhängig von Redhat / IBM /NOvell etc. machen bzw. bleiben. Die Unix-Ideen wie ein Tool für eine Aufgabe und "alles" ist ein File sind für eine unabhänigige Zukunft freier Software wichtig.
... das mag ja sein, aber niemand spricht hier von einer Migration.
Es geht bei der Abstimmung nicht darum, Debian von systemd irgenwohin zu migrieren, sondern Alternativen dafür anzubieten, zu denen auch OpenRC gehört. Für Freunde von systemd bedeutet ja jedes andere Init-System einen Rückschritt, insofern würde Deine Aussage aus Deiner Sicht wohl auch für RunIt, Upstart und SysV gelten.
Da es aber, wie bereits erwähnt, nicht um eine Migration geht, sondern um Wahlfreiheit beim Init-System, ist Dein qualifizierender (das ganze SysV-Gerümpel ist entsorgt") Kommentar eigentlich "off topic".
Ich persönlich hoffe, dass Debian wieder zu seiner Offenheit (Wahlfreiheit) zurückfindet und die Nutzer entscheiden lässt, mit welchem Init-System sie arbeiten wollen.
Rückkehr zur Wahlfreiheit? Die gab es doch noch nie beim Init-System von Debian. Lange Zeit war SysVInit das einzig unterstützte Init-System, wer etwas anderes benutzen wollte, der musste sich selbst darum kümmern. Jetzt ist systemd das einzig unterstützte Init-System, wer etwas anderes benutzen will, der muss sich selbst darum kümmern.
Eine Wahlfreiheit auf Seiten der Anwender bedeutet außerdem einen Zwang auf Seiten der Entwickler, denn die müssen all ihre Pakete auf verschiedenen Init-Systemen testen und ggf. Anpassungen vornehmen. Wenn ich z.B einen Daemon schreibe, der in Debian aufgenommen werden, dann darf ich mich also weiterhin mit SysV-Skripten rumärgern.
Das ist auch gemeint mit "wenn es nicht den Fortschritt bremst". Ich habe nichts dagegen, wenn es noch andere Init-Systeme für Debian gibt, aber als Entwickler sollte man sich mit dem antiquiertem Zeug nicht mehr beschäftigen müssen. Es gibt ja schließlich noch andere Distributionen, zu denen man beitragen kann...
...ich bin ein Programmier-Laie, daher folgende Frage:
Gibt es keine Möglichkeit, die Unterstützung der verschiedenen Init-Systeme zu automatisieren? Zum Beispiel mit Kompilier-Optionen? Oder über ein allgemeingültiges Skript?
SysV ist nicht antiquiert, sondern verfolgt einfach einen völlig anderen Ansatz als systemd. Nicht alles, was ein gewisses Alter überschritten hat, ist aus diesem Grund überholt.
Gibt es keine Möglichkeit, die Unterstützung der verschiedenen Init-Systeme zu automatisieren? Zum Beispiel mit Kompilier-Optionen? Oder über ein allgemeingültiges Skript?
Sicherlich gibt es irgendeine Möglichkeit. Aber welchen Preis hat sie? Haben bisherige Entwickler etwas derartiges erdacht und umgesetzt? Offenbar nicht, sonst wären wir jetzt nicht hier an dieser Stelle.
Ein Vorschlag zielte indirekt darauf ab eine Art "saubere" Init-System-Spezifikation zu definieren, wofür dann mehrere Implementierungen geschrieben werden können. Das wurde zumindest auf den Mailingliste diskutiert, aber wurde dort auch relativ schnell zum Scheitern verurteilt, müsste ich jetzt heraussuchen. :/
Ich stelle mir das äußerst kompliziert vor, v.A. weil es die ganzen verschiedenen Ansätze zu vereinen, bzw. eine maximale Schnittmenge zu finden. Die Komplexität der Spezifikation dürfte ausufern. Sie müsste den Init-Kern des de-facto-Standards systemd umfassen, und sich auch weiter fortentwickeln, um nicht an Bedeutung zu verlieren. Insbesondere müsste eine große Kompatibilität zu systemd bestehen. Und dann fehlen noch die Implementierungen... Wer soll das alles bewältigen? Und wozu? Die Implementierungen gleichen sich doch alle, oder aber die Spezifikation ist zu vage, dass sie die unterschiedlichsten Implementierungen zulässt, oder die Implementierungen implementieren nur unterscheidliche Teilmengen der Spezifikation und wären damit inkompatibel, womit man wieder am Anfang wäre. Das ist die Quadratur des Kreises.
Sicherlich könnte man eine relevante Teilmenge systemds reimplementieren. Es ist nicht alles spezifiziert. Zudem bedarf es eines enormen Aufwands, wenn man dies korrekt machen möchte, also nicht alle Fehler wiederholen möchte, die systemd zu beheben versucht hat (race-conditions, korrekte service supervision, debuggability). Wenn mich nicht alles täuscht, habe ich mal irgendwo gelesen, logind wäre da wohl so eine komplizierte Ausnahme, die schwieriger zu reimplementieren sei, ohne es fehleranfällig zu machen und ohne auf systemd- und Linux-spezifische Schnittstellen zuzugreifen.
SysV ist nicht antiquiert, sondern verfolgt einfach einen völlig anderen Ansatz als systemd. Nicht alles, was ein gewisses Alter überschritten hat, ist aus diesem Grund überholt.
Wer entscheidet, ob etwas "antiquiert" ist?
Formal ist Ihre Aussage zwar in der Tat korrekt, sie bedeutet aber nicht, dass es für heutige Probleme und Aufgaben teils unbrauchbar ist, da der Ansatz beim Entwurf diese nicht berücksichtigt und nicht in diese Richtung erweiterbar sinnvoll ist. Zumindestens sehen das offenbar viele Leute so, die sich mit der Materie besser auskennen als wir beide.
Gibt es keine Möglichkeit, die Unterstützung der verschiedenen Init-Systeme zu automatisieren? Zum Beispiel mit Kompilier-Optionen? Oder über ein allgemeingültiges Skript?
Theoretisch ja, aber es geht ja nicht nur um eine formelle Unterstützung, sondern der andere Weg sollte ja auch halbwegs getestet sein, sonst kann man es sich eigentlich auch sparen. Zudem kommt das Problem dazu, dass systemd und sysvinit sehr unterschiedliche Ansätze verfolgen, was so eine Automatisierung weiter erschwert. Nicht zuletzt gibt es dann auch noch die Hürde, dass systemd-freie Systeme auch noch andere Alternativen für verschiedene Dienste verlangen, was die Umsetzung auch etwas komplexer macht. Unmöglich ist es aber nicht, nur das zu testen ist halt mehr Aufwand.
Generell sehe ich auch nicht so wirklich die Notwendigkeit. Für die, welche systemd unbedingt vermeiden wollen gibt es ja auch noch Devuan
SysV ist nicht antiquiert, sondern verfolgt einfach einen völlig anderen Ansatz als systemd. Nicht alles, was ein gewisses Alter überschritten hat, ist aus diesem Grund überholt.
sysvinit war schon vor 15-20 Jahren antiquiert und überholt. Im Grunde will den Schrott auch keiner wirklich mehr haben. Das Problem ist doch eigentlich nur, dass manche systemd nicht haben wollen (aus verschiedenen Gründen persönlicher und technischer Natur die wir hier jetzt nicht unbedingt wiedergeben müssen).
... das mag ja sein, aber niemand spricht hier von einer Migration.
Es geht bei der Abstimmung nicht darum, Debian von systemd irgenwohin zu migrieren, sondern Alternativen dafür anzubieten, zu denen auch OpenRC gehört.
Inwiefern geht es bei Optionen 1 (Vorschlag F) um das Anbieten von Alternativen? Da geht es um "systemd first". Auch Option 2 (Vorschlag B) lässt wenig Spielraum für Alternativen.
Für Freunde von systemd bedeutet ja jedes andere Init-System einen Rückschritt, insofern würde Deine Aussage aus Deiner Sicht wohl auch für RunIt, Upstart und SysV gelten.
Puh, das ist ein wenig pauschal... Wer sind "Freunde von systemd"? Und warum sollten die alle glauben, dass es nie auch je ein in ihrem Sinne "besseres" Init-System geben könnte? Das ist schon ein sehr starke Behauptung, die Sie da implizieren. Ich denke nicht, dass alle glauben, systemd wäre für immer und ewig der heilige Gral.
Andererseits, selbst wenn dem tatsächlich so wäre: Das OSS-Ökosystem ist schon immer eine Meritokratie der Entwickler gewesen. Es gibt auch erfolgreiche Ausnahmen mit einem wohlwollenden Diktator. Ich glaube nicht, dass sich das so schnell ändern wird, und ich kann mir ein Funktionieren der bestehenden Form dieses Ökosystems ohne Meritokratie nicht so recht vorstellen. Ich lasse mich da aber gern vom Gegenteil überzeugen. In diesem Sinne erklärt sich mir schlicht nicht, warum eine mutmaßliche "Mehrheit" dieser Meritokratie nicht das bekommen sollte, was sie möchte, nur weil andere es ihnen versagen statt selbst zu Lösungen zu liefern. Und wenn jene, diese Lösungen nicht wünschen, habe Sie weiterhin die Freiheit, etwas anderes einzusetzen, zu pflegen und zu verbessern.
Wenn die Interessenten an systemd effektiv mehr leisten und dadurch wichtigere, entscheidendere, bessere oder einfach mehr praktische Lösungen vorweisen können, an welchen es der Konkurrenz scheinbar mangelt, warum sollten die Ihre Verdienste und Lösungen schmälern müssen? Nur um Kompatibilität auf dem kleinsten gemeinsamen Nenner herzustellen? Die gab es doch schon mit den geteilten bzw. abgespaltenen Entwicklung von System V und Abkömmlingen von 7th Edition Unix (BSD) nicht. Ein Schisma, welches mit den Differenzen und Patentstreitigkeiten zwischen AT&T und Berkeley begann und in den sogenannten Unix-Kriegen mit endlos vielen inkompatiblen Erweiterungen und Unterscheiden fortgeführt worden ist. Wie das ausging, wissen Sie sicherlich: Der Markt war zu fragmentiert, Abwicklung und Konsolidierung, POSIX und Linux entstanden.
In gewisser Weise wiederholt sich hier die Geschichte - nur auf einer anderen Ebene. Und systemd ist natürlich auch kein Standard wie POSIX. Aber es entwickelt sich immer mehr zum de-facto-Standard unter Linux. Einige Systeme haben Alternativen, von welchen sich die Entwickler inspirieren lassen haben (Apple mit launchd in macOS etc. und Sun/Oracle mit SMF in Solaris und illumos und Derivaten). Kommiteestandards wie POSIX haben eben nicht nur Vorteile.
Aber POSIX reicht schon lange nicht mehr, um viele modernere technische Probleme lösen zu können. Deshalb wird inzwischen viel weitestgehend unportabler Quelltext, der auf inkompatiblen (oder teils alternativlosen) Schnittstellen beruht, verfasst. Das manifestiert sich auch in den zunehmenden Schwierigkeiten, die die BSD-Systeme haben, den ganzen Kram am Laufen zu halten (betrifft nicht nur GNOME, sondern auch KDE Plasma oder Firefox). Dort findet sich einfach kaum einer, der die Arbeiten übernimmt. Auf der anderen Seite, schreiben die BSDs selbst Erweiterungen und unportablen Code (siehe OpenBSD: strlcpy, getentropy/getrandom, arc4random, LibreSSL, OpenSSH, signify, ...), der dann hinterher portiert wird - aber nur, weil sich in der Linux-Fraktion Leute finden, die sich darum kümmern. Die Ressourcen sind dort einfach weniger rar. Es ist eben auch eine Frage des stärkeren Momentums.
Ja, es ist schade, dass die Situation so ist. Und Softwarediversität ist an bestimmten Punkten äußerst wichtig. Jeder kann mit seinen Mitteln und Beiträgen dagegensteuern.
Da es aber, wie bereits erwähnt, nicht um eine Migration geht, sondern um Wahlfreiheit beim Init-System, ist Dein qualifizierender (das ganze SysV-Gerümpel ist entsorgt") Kommentar eigentlich "off topic".
De-facto fand die Migration über die letzten Jahre stetig statt, weswegen auch Probleme wie die schwierige Integration von elogind bestehen und Zerwürfnisse, wie es sich in der Abspaltung Devuans und dem Entwicklerabgang Debians der letzten Jahre (Joey Hess, Lars Wirzenius, Martin Pitt, Michael Stapelberg) manifestiert, das Projekt lähmen (< - Übertreibung).
Nun sind die inneren Reibereien nach der Nicht-Entscheidung der letzten GR einfach wieder zu groß geworden, als dass sie dauerhaft gesund fürs Projekt wären.
In der Entscheidung hier, geht es nun endlich darum, wie mit dieser Realität umgegangen werden soll. Das liest sich auch daran ab, dass es bei der GR eine Wahloption gibt, die den Fokus des Projekts auf systemd legt, aber keine, die es auf eine konkrete Alternative legt.
Das "SysV-Gerümpel" sollte vermutlich eher ein Ausdruck für das Alter von SysV bzw. dessen Entwurfszielen und den heutzutage teils unzulänglichen Lösungsansätzen sein, sowie für die Nachteile, die die Init-Shell-Skripte mit sich gebracht haben, stehen. Es war mal das Maß der Dinge zur Lösung von Problemen, reicht je nach Anwendungsfall aus heutiger Perspektive in vielerlei Hinsicht schlicht nicht mehr aus.
Ich persönlich hoffe, dass Debian wieder zu seiner Offenheit (Wahlfreiheit) zurückfindet und die Nutzer entscheiden lässt, mit welchem Init-System sie arbeiten wollen.
Jein, das "Universal OS" hat immer auf den kleinsten gemeinsamen Nenner abgezielt (z.B. wurde immer embedded unterstützt), orthogonale Optionalitäten und Alternativen angeboten, wo es machbar war. Das hat natürlich Grenzen, z.B. in der Komplexität der Vereinbarkeit teils gegensätzlicher Einstellungen, Funktionalitäten und Interessen, in der Kommunikation und teils sogar in der sozialen Struktur innerhalb Debians. Wo die Grenzen liegen, zeigen sich nun seit einigen Jahren recht deutlich. Kann man das leugnen?
Ging es innerhalb des OSS-Ökosystems, innerhalb Debians jemals tatsächlich um die Wahlfreiheit der Nutzer? Ich denke nicht. Bei der GR entscheiden schließlich auch nicht die (alle) Nutzer, sondern die Entwickler (welche natürlich auch Nutzer sind).
Mir persönlich ist es einerlei, wofür die Entwickler stimmen. Ich habe nichts gegen eine Entscheidung für systemd, Upstart, sysvinit, OpenRC, runit oder s6 usw. Ich halte es aber definitiv für unklug, für Option 8 zu stimmen. Das löst den inneren Konflikt des Projekts nicht.
Jeder Entwickler oder Nutzer, der mit dem Ausgang nicht zufrieden ist, kann die Distribution wechseln oder forken. Das ist die Freiheit, die OSS Ihren Nutzern lässt. Zudem befriedet die inneren Reibereien Debians, und führt zu einer höheren Produktivität der verbleibenden Entwicklerschaft. Wäre das nicht eine Win-Win-Situation?
Ob ich Debian ohne systemd für meinen Desktop weiterbenutzen möchte, weiß ich jedoch auch nicht. Das hängt von der konkreten Lösung/Umsetzung ab. Jedenfalls habe ich nach der GR immer noch die Freiheit, eine andere Distribution zu wählen. Das ist, was für mich primär zählt. Sekundär wünsche ich mir, dass Debian nicht in der Bedeutungslosigkeit innerhalb der Distributionsangebote untergeht.
Das ist viel zu viel Technik-Diskussion ! Die technischen Vor- und Nachteile sind bekannt. Vielleicht sollte man ehr darueber diskutieren, in wie weit die die Art und Weise der "demokratischen Teilhabe" bei Debian umgesetzt wird. Das Monster mit seiner Buerokratie hat einen nicht reformierbaren Punkt erreicht. Es werden zu viele "gemuetliche Stimmen aus der bequemen und Haengematte" gezaehlt, statt gewogen.
Ausserdem sollte mal bedacht werden, welchen Einfluss Red Hat hat. Und welche "besonderen" Nutzer und Fuersprecher es hat ... und welche politischen und finanziellen Moeglichkeiten diese Nutzer und Fuersprecher haben.
Fakt ist, Red Hat hat zu viel Einfluss. Und der Linux "Standard" Desktop ist Gnome. Das Standard Init System ist systemd.
Und alle nennenswerten Distributionen sind Anglo-Amerikaner. Die Linux Foundation ebenfalls. Achso ... fast vergessen. Microsoft und Github auch
Finden Sie? Ich hatte eigentlich versucht, genau davor eher Abstand zu halten, und die sozialen und ökonomischen Perspektiven näher zu beleuchten.
Und ein bisschen technisch ist es immer, wenn es um das OSS-Ökosystem geht. Die Architekten sind die Software-Ingenieure und Ingenieure haben zwangsweise etwas mit Technik zu tun.
Die technischen Vor- und Nachteile sind bekannt.
Das ist wohl wahr. Die Debatten und Argumente wurden schon sehr häufig geführt.
Vielleicht sollte man ehr darueber diskutieren, in wie weit die die Art und Weise der "demokratischen Teilhabe" bei Debian umgesetzt wird. Das Monster mit seiner Buerokratie hat einen nicht reformierbaren Punkt erreicht. Es werden zu viele "gemuetliche Stimmen aus der bequemen und Haengematte" gezaehlt, statt gewogen.
Da steckt aus meiner Sicht ein wahrer Kern drin. Die Teilhabe der Hundertschaften an Debian-Entwickler ist sicherlich sehr verschieden. Sollten die Entwickler der verschiedenen Init-Systeme in Debian die selbe Stimmgewichtung besitzen wie die direkten Nutzer jener Schnittstellen (etwa Entwickler von Diensten, die von Init abhängen oder verwaltet werden)? Sollten Entwickler, die init-unabhängige Software entwickeln oder pflegen das selbe Stimmgewicht haben?
Sollten alle Entwickler die gleiche Stimme haben, wie es zumindest formal in einer idealen Demokratie festgelegt ist? Wenn es nach dem meritokratischen Grundgedanken von OSS ginge, sicherlich nicht. Genau letztere strebt das Debian-Projekt aber per Konstitution an. Die Ideen dahinter sind nicht ganz ungerechtfertigt, wenn man sich das Ideal unserer relativ demokratischen Gesellschaften zu Gemüte führt. Den Debian-Gesellschaftsvertrag haben alle Debianer akzeptiert. Man kann sogar jederzeit wieder aussteigen, falls es einem doch nicht so passt. Damit ist Debian auch als ein soziales (Pilot-)Projekt, um nicht zu sagen Experiment, zu werten, welches es in dieser Form vorher nocht nicht gegen hat, wenn man vom Linux-Kernel absieht, der auch wesentlich meritokratischer funktioniert.
Ausserdem sollte mal bedacht werden, welchen Einfluss Red Hat hat. Und welche "besonderen" Nutzer und Fuersprecher es hat ... und welche politischen und finanziellen Moeglichkeiten diese Nutzer und Fuersprecher haben.
Nun, wenn man von Red Hat unabhängig sein möchte, muss man entweder die Entwicklung dominieren, was ziemlich kompliziert wird. Oder man muss OSS-Silos bauen, wie es Canonical mit den ganzen Eigenentwicklungen und CLAs oder Apple mit Darwin oder Google mit Android, Chrome OS, coreboot oder die in gewisser Weise die BSDs etc. tun. Auch die Distris ohne glibc sind weigehend unabhängige Kandidaten. Allerdings verwenden letztlich doch die selbe Toolchain etc.
Red Hat profitiert natürlich davon, die Fragmentierung durch Vereinheitlichung einzudämmen. Das erfolgt nicht nur als rein profitorientierten Interessen. Es ist in den gesetzten Umständen schlicht ökonomischer. Hätte Red Hat kein Eigeninteresse an systemd würde es vermutlich nicht existieren.
Allerdings sollte man auch froh sein, wie offen die Entwicklung geschieht und wie frei der Zugang zu der Software und der Doku ist. Man darf schließlich auch etwas anderes Verwenden, ohne dass eine Gestapo mit roten Hüten Ihre Tür eintritt und Sie mit Deportation bedroht, wenn Sie etwas anderes nutzen oder entwickeln möchten.
An welche „"besonderen" Nutzer und Fuersprecher“ und „politischen und finanziellen Moeglichkeiten diese Nutzer und Fuersprecher“ denken Sie denn da konkret?
Fakt ist, Red Hat hat zu viel Einfluss. Und der Linux "Standard" Desktop ist Gnome. Das Standard Init System ist systemd.
Hm, also der Markt besteht nicht nur aus Red Hat... klar dominieren einen gewissen Teilmarkt. Aber es gibt dort Oracle, HP, Microsoft, Google, Amazon, Apple, Facebook, SUSE, Canonical, die ganzen Embeddedunternehmen/-produktem wie QNX etc., die sich den Betriebsystemmarkt mit unterschiedlichen Schwerpunkten aufteilen.
Was heißt da also „zu viel“? Wofür? Und im Vergleich zu wem? Warum schreiten die Kartellbehörden nicht ein? Wieso nicht erstmal dominantere Player zerschlagen?
Was Sie als Standard in Gänsefüßchen bezeichnen, ist ein gängiges Phänomen in OSS und anderen Bereichen. Der stärkere setzt sich durch. Es hat also mehr mit Popularität zu tun. Zudem gibt es schlicht keine ernsthafte Desktop-Konkurrenz im Linux-Ökosystem zu FreeDesktop/GNOME. Jedenfalls ist mir keine bekannt. KDE setzt inzwischen immer mehr auf Techniken aus dem anderen Lager und hat teils unterlegene alternative Komponenten in essentiellen Bereichen (siehe allein GStreamer, gnome-keyring vs KDE Wallet, gvfs/GIO vs KIO, native Mail-Klienten, bis vor einem Jahr nativer Browser - Falcon hat das ein wenig ausgeglichen). In diesem Sinne ist es also bestenfalls ein meritokratischer de-facto Standard. Man sollte auch nicht vergessen, wie viele Systeme ohne systemd betrieben werden (Embedded / Container / Docker).
Und alle nennenswerten Distributionen sind Anglo-Amerikaner. Die Linux Foundation ebenfalls. Achso ... fast vergessen. Microsoft und Github auch
Anglo-Amerikaner ist ein bisschen weitgefasst, oder? Meinen Sie vielleicht einfach US-amerikanisch?
Richtig, dort und inzwischen auch in China findet der große Hauptteil der Innovation und Entwicklung der IT-Branche statt. Das ist nichts neues. Was wollen Sie damit aussagen?
Allerdings sitzt Canonical in UK, Isle of Man / London. SUSE sitzt wieder in Nürnberg. Der derzeitige Investor EQT Partners ist international tätig und hat einen schwedischen / nord-amerikanischen / europäischen Hintergrund; indirekt gegründet von dem Investiotionsunternehmen der Wallenbergfamilie. Das ist nicht gerade anglo-amerikanisch. Sind die beiden nicht nennenswert?
Finde den Fehler ??
?? Ich komme nicht drauf - bin zu blöd. Bitte helfen Sie mir auf die Sprünge und benennen Sie bitte diese sogenannten „Fehler“ präzise. Danke!
systemd hat einen rein deklarativen Ansatz, das ist einfach um Größenordnungen leichter zu administrieren und zu debuggen.
Leichter zu administrieren ja. Leichter zu debuggen eher nein. Weil Du halt nicht mehr einfach in den Code reinschauen kannst.
So ähnlich war das in Upstart auch, mit dem Resultat, dass nur wenige Services von diesen Features Gebrauch gemacht haben.
Upstarts Problem war vorallem, das es Abhängigkeiten nicht automatisch aufgelöst hat, wie systemd es tut.
Du hast nur noch deklarative Unit-Files, das ganze SysV-Gerümpel ist entsorgt
Leider ist systemd monolithisch. Sonst könnte man sich ja den angenehmen Teil mit den deklarativen Unit-Files reinfach rausnehmen.
So muss man systemd mitschleppen. Was durchaus problematisch sein kann. Denn systemd ist zwingend auf einen Linux-Kernel angewiesen. Systemd-freie Distributionen konnte man bis dato relativ problemlos in eine FreeBSD-Jail installieren. Das geht dann nicht mehr.
Leichter zu debuggen eher nein. Weil Du halt nicht mehr einfach in den Code reinschauen kannst.
Auch systemd ist Open Source. Klar kann man in den Code reinschauen. Abgesehen davon bietet systemd auch vernünftige Tools um Probleme zu analysieren.
Das war bei den Init Scripten nicht wirklich der Fall. Ich hatte tatsächlich mal den Fall, dass ein Dienst nicht wirklich starten wollte und habe dann versucht nachzuvollziehen was die Scripte tun, denn außerhalb des Init Systems (also manuell gestartet) funktionierte der Dienst wunderbar. Nach ein paar Stunden habe ich aber entnervt aufgegeben, zu verstrickt und undurchsichtig war die ganze Sache.
Leichter zu debuggen eher nein. Weil Du halt nicht mehr einfach in den Code reinschauen kannst.
systemd bringt ziemlich viele Werkzeuge mit, die ein Debugging ermöglichen. Wie viele bringt eine Shell mit?
Also Shell-Skript zu debuggen, ist nicht gerade ein Vorteil der Shell-Sprachen. Schlechter geht es eigentlich kaum...
Was tun Sie bei einer schlecht reproduzierbaren Race-Condition während es Bootens mit SysV? systemd verfolgt einen besseren Ansatz zur Vorbeugung von Race-Conditions.
Upstarts Problem war vorallem, das es Abhängigkeiten nicht automatisch aufgelöst hat, wie systemd es tut.
Upstart war vor Allem der Versuch, ein Event-basiertes Init über SysV zu stülpen. Das hat mehr schlecht als recht funktioniert, gab sogar der Hauptentwickler schlussendlich zu. Die Idee des Konzepts eines Event-basierten Inits an sich war allerdings sehr gut.
Das zeigt letztlich auch, dass die Grenzen von SysV ausgereizt wurden, und wie systemd mit neuen Ansätzen die Ansätze von SysV strikt und sauberer erweitert hat. Man kann die Funktionen und Schnittstellen systemds nicht 1:1 auf SysV zurückführen, ohne zentrale Konzepte und Bausteine von systemd zu verwenden oder vollständig zu reimplementieren.
Leider ist systemd monolithisch. Sonst könnte man sich ja den angenehmen Teil mit den deklarativen Unit-Files reinfach rausnehmen.
Okay, guter Einwand. Ich glaube aber, dass ein Rosinenpicken schwierig wird. You can't have your cake and eat it too.
Welche nicht rein optionalen Teile von systemd wollen Sie denn nicht haben/einsetzen? udev? logind? PAM? cgroups? Was bleibt noch? Welchen konkreten Zweck verfolgen Sie damit?
So muss man systemd mitschleppen.
Das ganze Projekt sicher nicht.
Was durchaus problematisch sein kann.
Wieso? Konkreter Anwendungsfall?
Damit möchte ich nicht sagen, dass es keine gibt. Aber ich finde solche Aussagen immer viel zu vage. Und meistens sind je nach Anwendungsfall Alternativen mitunter einfach besser. Das bestreitet auch keiner. Sie können weiterhin eingesetzt werden.
Denn systemd ist zwingend auf einen Linux-Kernel angewiesen.
Das soll eine Begründung dafür sein, dass es problematisch sein kann, dass man systemd mitschleppen muss? Hä? Die Assoziationskette kann ich nicht nachvollziehen.
systemd wurde mit dem expliziten Anspruch entwickelt, Features von Linux zu nutzen und zu vereinheitlichen. Ähnlich wie die glibc es tut, nur auf einer anderen Ebene. Und warum werden andere Projekte, wie die BSDs, Darwin, macOS, Solaris/illumos, Windows etc. dafür nicht kritisiert? Da steckt zumeist alles in einem Monorepo und ist in essentiellen Teilen unportabel bzw. wurde nicht mit dem Hintergedanken der Portabilität entwickelt.
Systemd-freie Distributionen konnte man bis dato relativ problemlos in eine FreeBSD-Jail installieren. Das geht dann nicht mehr.
Wann ging das jemals? Quelle?
Eine FreeBSD-Jail ist kein Hypervisor oder gar eine vollständigere VM für beliebige fremdartige Gäste. Die FreeBSD-Jail kann nur auf dem FreeBSD-Kernel zusätzliche voneinander isolierte user-space-Umgebung instanziieren. Andere Gäste wie Linux, Windows etc. lassen sich darin nicht „installieren“.
Übrigens ist FreeBSD-Jails ein FreeBSD-spezifisches Feature, das nicht portabel ist. Und DTrace ist auch nicht einfach portierbar! Schande! /s
Sie meinen eventuell den rein optionalen Linuxulator, der auf CentOS 6 und Linux 2.6.x basiert, inzwischen total ungepflegt und so unsicher und verbuggt ist, dass OpenBSD das Ding hochkant aus dem Orbit katapultiert hat. Nur bei FreeBSD huldigt man diesem Stück Legacy. Es ist Magie. Es funktioniert, manchmal, irgendwie. Die Frage ist, wie lange noch? Speziellere Linux-Kernel-Features bleiben unimplementiert oder sind unvollständig implementiert. Das kann keine dauerhafte Alternative für den Produktiveinsatz sein.
Ihre Argumente lassen viele Lücken oder viele Fragen offen.
1. Der derzeitige DPL Sam Hartman formuliert eine knappe Antwort auf eine analoge Frage so. Sind Ihnen das Gründe genug?
Es ist anzunehmen, dass der DPL beabsichtigt, das beste fürs Projekt zu tun. Zwar hat er die GR maßgeblich initiiert, aber erstens schien die Gefahr des langsamen Verfalls oder der Implosion des Projekts durch die internen Reibereien und Missstände zwischen den Entwicklern auch im Fall der Integration von elogind stetig zu steigen, zweitens das hat er erstens vor seiner demokratischen Wahl und Ernennung in dessen Programm indirekt angekündigt solche Schritte zu wagen (Zitat: „I think the DPL's ability to propose general resolutions is under-utilized. I think that having the DPL propose a GR including the major options could be a much less confrontational way to bring closure to an issue than having an individual developer propose a GR and seek seconds. If the process feels a lot more like polling the project and guiding the resolution to a policy discussion, I think voting can bring things to closure.“), und drittens spielt er dabei eher die Rolle eines Moderators, als eines Entscheiders oder Meinungsbildners. Über die endgültige Entscheidung stimmen die Entwickler ab, von welchen er nur einer mit dem selben Stimmgewicht wie allen anderen ist.
Zur letzten GR zu diesem Thema gab es ja keine Entscheidung (siehe Artikel). Das bedeutet, dass der Konflikt de-facto ungelöst blieb und mit allen Nachteilen wieder auf die Entwicklungsarbeiten zurückübertragen wurde. Es wurde sogesehen erstmal unter den Teppich gekehrt. Das kann nicht lange gut gehen. Das Problem wird wieder zutage treten und sich wieder zuspitzen müssen, was ja auch geschehen ist (elogind). Aber nur eine Entscheidung kann die immer wieder aufkeimenden internen Reibereien tatsächlich schlichten. Und ich vermute, dass genau das der Beweggrund des DPL war, die Debatte erneut zu führen und mit einem GR zu einer echten Lösung zu führen.
2. Welcher "Kompromiss" dabei herauskommt, wird sich zeigen. Ich hoffe für das Projekt, dass es nicht die selbe Entscheidung wie beim letzten Mal wird - nämlich keine. Debian muss zentrale technische Entscheidungen fällen können, um ein erfolgreiches und ernstzunehmendes Distributionsprojekt zu sein. Andernfalls sehe ich das Projekt nur langsam vor sich hinsiechen und ausbluten bis es letztlich stirbt.
Welche Lösung letztlich gewählt wird, wäre mir persönlich egal. Derzeit erkenne ich von außen aber eine Mehrheit an Entwickler-"mindshare" pro systemd bzw. nicht contra systemd. Außerdem kann ich keine fertiggestellten Ersatzalternativen zum zentralen Konzept und Bestandteil vom Init-Teil von systemd ausmachen. Um die ganzen optionalen Komponenten wie networkd, timesyncd etc. pp. geht es an dieser Stelle ja gar nicht. Die können ohnehin beliebig gewählt und reimplementiert werden.
Andersherum betrachtet, ist eine andere Frage, die sich mir stellt: Was hätte das Debian-Projekt davon, es Devuan, Slackware, Alpine, Void, Hyperbola, Artix etc. gleichzutun? Die haben alle Ihre Daseinsberechtigung, ohne Frage. Und es ist gut, dass es sie gibt. Das bedeutet auch, dass die Wahlfreiheit der Nutzer effektiv bestehen bleibt. Aber die Gesamtheit der Distributionen, die sich systemd gänzlich verweigern, stellt in meinen Augen eine Nische der Nische dar. Da gibt es nicht viel zu holen an Nutzern oder Entwicklern. Gleichzeitig sehe ich das Risiko, dass die fähigsten Entwickler Debian meiden oder verlassen werden, um sich anderen Projekten anzuschließen, falls hier keine sozialverträgliche und technisch zu bewältigende Entscheidung fällt. Die Entwicklerressourcen sind nunmal begrenzt.
Warum also alles innerhalb eines Projekts umsetzen? Das führt doch quasi automatisch zu Gegensätzen und Widersprüchen.
Und die Debian-Ports kFreeBSD und HURD sind quasi rein experimentell oder tot. Sollen die die restliche Entwicklung Debians bremsen dürfen?
Änderung um der Änderungen Willen ist die eine Seite der Medaille. Aber deswegen keine alten Zöpfe abschneiden oder zentrale technische Entscheidungen fällen zu dürfen/können, halte ich für tödlich (für das Projekt).
Letztlich entscheiden die Entwickler, was geschieht. Und das bedeutet, dass deren Argumente am schwersten wiegen.
p.s.: Alles unter Punkt 2 ist meine persönliche Meinung. Ich bin Außenstehender und meine Meinung ist nicht in Stein gemeißelt. Ich ändere Sie aber nur, falls ich gute sachliche nachvollziehbare Gegenargumente vernehmen kann, die der Gesamtheit aller Pro-Argumente überwiegen.
Das problem mit Systemd für GNU Hurd und FreeBSD ist, dass systemd linux cgroups verwendet. Die sind soweit ich weiß nicht in FreeBSD oder Hurd implementiert. Ich weiß aber nicht ob man die in Hurd oder FreeBSD implementieren könnte.
Kann man GNU Hurd und den Kernel von FreeBSD systemd tauglich machen oder sind da Lizenzen im Weg?
Theoretisch bestimmt. Ich glaube, dass das keine leichte Aufgabe wäre. Und ich würde keine Wetten darauf abschließen, dass mittelfristig ein Haufen Quelltext über den Zaun geworfen wird, der das implementiert.
Ich wage zu bezweifeln, dass die Lizenzen das Problem wären, da der Code eh neu geschrieben werden müsste. Ich glaube nicht, dass es sich lohnen würde, den bestehenden Code aus Linux zu kopieren und anzupassen. Dafür sind die Innereien zu verschieden.
Ein Beispiel ist das unten erwähnte Linux-Feature namens cgroups. Ich kenne keine etwa gleichmächtige oder ebenbürtige Schnittstelle in FreeBSD. Für HURD gilt vermutlich das Gleiche. Aber HURD ist gleich nochmal anders. Ich bezweifle, dass systemd dort mit den anderen Message-Passing-Konzepten überhaupt idiomatisch wäre. Hoffentlich lehne ich mich da nicht zu weit aus dem Fenster...
Was sagen dir dortigen Kernelentwickler zu systemd?
Keine Ahnung. Wenn Sie es wirklich wissen wollen, schlage ich Ihnen vor, direkt zu fragen.
In FreeBSD gibt/gab es Ideen dazu, etwas Ähnliches zu systemd, aber in Anlehung an eine Inspirationsquelle systemds namens launchd (OS X), umzusetzen.
Also prinzipiell interessiert scheinen einige Entwickler an einer Alternative zu sein. Allerdings erinnere ich mich dunkel, dass es da intern auch viel Gegenwind gab.
Weiß jemand, wie die zu einem demokratischen Ergebnis kommen? D.h. weiß jemand, wie die Abstimmung bewertet werden soll? Ich meine es kann ja nicht sein, dass die Option mit den meisten Stimmen einfach so gewinnt, da die Befürworter der reinen SystemD-Lehre genau 1 Option haben, und die Befürworter von mehr oder weniger Vielfalt sich auf 7 weitere Optionen verteilen. D.h. 12,5% + 1 Stimme könnten theoretisch ausreichen, um Alternativen auszuschließen.
"D.h. 12,5% + 1 Stimme könnten theoretisch ausreichen, um Alternativen auszuschließen." Was ist daran undemokratisch? Das gibt es bei Volkentscheiden - die keine Mindesteilnehmerquote > 25% voraussetzen - auch.
Gerade gefunden: https://www.debian.org/devel/constitution#item-A Alles klar, da wird rangiert und "der Sieger aus den Wahlmöglichkeiten in der Schwartzschen Menge ausgewählt". Ich tue mir das jetzt nicht an, sieht kompliziert aus
...spricht eigentlich gegen OpenRC?
Keine Unterwanderung durch Babylon?
Aus meiner Sicht hauptsächlich, dass es Shell-Skript-basiert ist. systemd hat einen rein deklarativen Ansatz, das ist einfach um Größenordnungen leichter zu administrieren und zu debuggen. Man kann in OpenRC inzwischen optional aber auch deklarativ arbeiten, du hast dann trotzdem noch ein Shell-Skript, in dem aber nur Konstanten deklariert werden. So ähnlich war das in Upstart auch, mit dem Resultat, dass nur wenige Services von diesen Features Gebrauch gemacht haben. Man musste sich also trotzdem noch dauernd mit imperativen Skripts rumärgern.
Das musst du bei systemd eben nicht mehr. Du hast nur noch deklarative Unit-Files, das ganze SysV-Gerümpel ist entsorgt, und als Daemon-Entwickler musst du keinen Boilerplate mehr schreiben, weil dir systemd sehr viel Arbeit schon abnimmt. Es ist manchmal einfach notwendig, alte Zöpfe abzuschneiden und grundlegende Änderungen einzuführen. Eine Migration auf OpenRC wäre von meinem Standpunkt aus also wieder ein Rückschritt.
Schön wäre, wenn es zu systemd eine Alternative gäbe, die zumindest einige der Features -wie z.B. die Unit-Files- implementiert. Dann könnte man zwei Init-Systeme anbieten; diese würden aber mit der gleichen (oder zumindest ähnlichen) Konfiguration arbeiten.
Theoretisch spricht ja nichts dagegen eine systemd-Alternative zu entwickeln, die auf die unit-Files zugreift und diese versteht.
Systemd wandelt ja auch on-the-fly sysv-scripte in units um. Ich mag systemd und die deutlich vereinfachte Konfiguration mit den Units und deren Abhängigkeiten usw. Das aber alles mit systemd erschlagen werden muss (DNS? Zeitserver? Login?) find ich arg übertrieben.
Der Hintergedanke dabei ist, dass dann z.B. die NTP-,Resolver-, Netzwerkkonfiguration,... über alle systemd-basierten Distribution einheitlich wäre. Also ein Schritt in die Vereinheitlichung der Linux-Distributionen.
Wir haben bei uns z.B. SLES, Redhat, Debian und Ubuntu-Systeme, die alle unterschiedlich zu konfigurieren sind und ich hab noch nicht verstanden, warum das so sein muss.
>... und ich hab noch nicht verstanden, warum das so sein muss.
Dann könnte man ja die ganzen verschiedenen Distributionen einstellen und nur noch eine verbreiten. Aber welcher "Hersteller" will sein Produkt und seinen Führungsanspruch aufgeben???
Debian sollte sich unbedingt in der Kerninfrastruktur unabhängig von Redhat / IBM /NOvell etc. machen bzw. bleiben. Die Unix-Ideen wie ein Tool für eine Aufgabe und "alles" ist ein File sind für eine unabhänigige Zukunft freier Software wichtig.
... das mag ja sein, aber niemand spricht hier von einer Migration.
Es geht bei der Abstimmung nicht darum, Debian von systemd irgenwohin zu migrieren, sondern Alternativen dafür anzubieten, zu denen auch OpenRC gehört.
Für Freunde von systemd bedeutet ja jedes andere Init-System einen Rückschritt, insofern würde Deine Aussage aus Deiner Sicht wohl auch für RunIt, Upstart und SysV gelten.
Da es aber, wie bereits erwähnt, nicht um eine Migration geht, sondern um Wahlfreiheit beim Init-System, ist Dein qualifizierender (das ganze SysV-Gerümpel ist entsorgt") Kommentar eigentlich "off topic".
Ich persönlich hoffe, dass Debian wieder zu seiner Offenheit (Wahlfreiheit) zurückfindet und die Nutzer entscheiden lässt, mit welchem Init-System sie arbeiten wollen.
Beste Grüsse
Roland
Rückkehr zur Wahlfreiheit? Die gab es doch noch nie beim Init-System von Debian. Lange Zeit war SysVInit das einzig unterstützte Init-System, wer etwas anderes benutzen wollte, der musste sich selbst darum kümmern. Jetzt ist systemd das einzig unterstützte Init-System, wer etwas anderes benutzen will, der muss sich selbst darum kümmern.
Eine Wahlfreiheit auf Seiten der Anwender bedeutet außerdem einen Zwang auf Seiten der Entwickler, denn die müssen all ihre Pakete auf verschiedenen Init-Systemen testen und ggf. Anpassungen vornehmen. Wenn ich z.B einen Daemon schreibe, der in Debian aufgenommen werden, dann darf ich mich also weiterhin mit SysV-Skripten rumärgern.
Das ist auch gemeint mit "wenn es nicht den Fortschritt bremst". Ich habe nichts dagegen, wenn es noch andere Init-Systeme für Debian gibt, aber als Entwickler sollte man sich mit dem antiquiertem Zeug nicht mehr beschäftigen müssen. Es gibt ja schließlich noch andere Distributionen, zu denen man beitragen kann...
...ich bin ein Programmier-Laie, daher folgende Frage:
Gibt es keine Möglichkeit, die Unterstützung der verschiedenen Init-Systeme zu automatisieren? Zum Beispiel mit Kompilier-Optionen? Oder über ein allgemeingültiges Skript?
SysV ist nicht antiquiert, sondern verfolgt einfach einen völlig anderen Ansatz als systemd. Nicht alles, was ein gewisses Alter überschritten hat, ist aus diesem Grund überholt.
Beste Grüsse
Roland
Ein Vorschlag zielte indirekt darauf ab eine Art "saubere" Init-System-Spezifikation zu definieren, wofür dann mehrere Implementierungen geschrieben werden können. Das wurde zumindest auf den Mailingliste diskutiert, aber wurde dort auch relativ schnell zum Scheitern verurteilt, müsste ich jetzt heraussuchen. :/
Ich stelle mir das äußerst kompliziert vor, v.A. weil es die ganzen verschiedenen Ansätze zu vereinen, bzw. eine maximale Schnittmenge zu finden. Die Komplexität der Spezifikation dürfte ausufern. Sie müsste den Init-Kern des de-facto-Standards systemd umfassen, und sich auch weiter fortentwickeln, um nicht an Bedeutung zu verlieren. Insbesondere müsste eine große Kompatibilität zu systemd bestehen. Und dann fehlen noch die Implementierungen... Wer soll das alles bewältigen? Und wozu? Die Implementierungen gleichen sich doch alle, oder aber die Spezifikation ist zu vage, dass sie die unterschiedlichsten Implementierungen zulässt, oder die Implementierungen implementieren nur unterscheidliche Teilmengen der Spezifikation und wären damit inkompatibel, womit man wieder am Anfang wäre. Das ist die Quadratur des Kreises.
Sicherlich könnte man eine relevante Teilmenge systemds reimplementieren. Es ist nicht alles spezifiziert. Zudem bedarf es eines enormen Aufwands, wenn man dies korrekt machen möchte, also nicht alle Fehler wiederholen möchte, die systemd zu beheben versucht hat (race-conditions, korrekte service supervision, debuggability). Wenn mich nicht alles täuscht, habe ich mal irgendwo gelesen, logind wäre da wohl so eine komplizierte Ausnahme, die schwieriger zu reimplementieren sei, ohne es fehleranfällig zu machen und ohne auf systemd- und Linux-spezifische Schnittstellen zuzugreifen.
Wer entscheidet, ob etwas "antiquiert" ist?Formal ist Ihre Aussage zwar in der Tat korrekt, sie bedeutet aber nicht, dass es für heutige Probleme und Aufgaben teils unbrauchbar ist, da der Ansatz beim Entwurf diese nicht berücksichtigt und nicht in diese Richtung erweiterbar sinnvoll ist. Zumindestens sehen das offenbar viele Leute so, die sich mit der Materie besser auskennen als wir beide.
Zudem kommt das Problem dazu, dass systemd und sysvinit sehr unterschiedliche Ansätze verfolgen, was so eine Automatisierung weiter erschwert.
Nicht zuletzt gibt es dann auch noch die Hürde, dass systemd-freie Systeme auch noch andere Alternativen für verschiedene Dienste verlangen, was die Umsetzung auch etwas komplexer macht.
Unmöglich ist es aber nicht, nur das zu testen ist halt mehr Aufwand.
Generell sehe ich auch nicht so wirklich die Notwendigkeit. Für die, welche systemd unbedingt vermeiden wollen gibt es ja auch noch Devuan
sysvinit war schon vor 15-20 Jahren antiquiert und überholt.Im Grunde will den Schrott auch keiner wirklich mehr haben.
Das Problem ist doch eigentlich nur, dass manche systemd nicht haben wollen (aus verschiedenen Gründen persönlicher und technischer Natur die wir hier jetzt nicht unbedingt wiedergeben müssen).
Andererseits, selbst wenn dem tatsächlich so wäre: Das OSS-Ökosystem ist schon immer eine Meritokratie der Entwickler gewesen. Es gibt auch erfolgreiche Ausnahmen mit einem wohlwollenden Diktator. Ich glaube nicht, dass sich das so schnell ändern wird, und ich kann mir ein Funktionieren der bestehenden Form dieses Ökosystems ohne Meritokratie nicht so recht vorstellen. Ich lasse mich da aber gern vom Gegenteil überzeugen.
In diesem Sinne erklärt sich mir schlicht nicht, warum eine mutmaßliche "Mehrheit" dieser Meritokratie nicht das bekommen sollte, was sie möchte, nur weil andere es ihnen versagen statt selbst zu Lösungen zu liefern. Und wenn jene, diese Lösungen nicht wünschen, habe Sie weiterhin die Freiheit, etwas anderes einzusetzen, zu pflegen und zu verbessern.
Wenn die Interessenten an systemd effektiv mehr leisten und dadurch wichtigere, entscheidendere, bessere oder einfach mehr praktische Lösungen vorweisen können, an welchen es der Konkurrenz scheinbar mangelt, warum sollten die Ihre Verdienste und Lösungen schmälern müssen?
Nur um Kompatibilität auf dem kleinsten gemeinsamen Nenner herzustellen? Die gab es doch schon mit den geteilten bzw. abgespaltenen Entwicklung von System V und Abkömmlingen von 7th Edition Unix (BSD) nicht. Ein Schisma, welches mit den Differenzen und Patentstreitigkeiten zwischen AT&T und Berkeley begann und in den sogenannten Unix-Kriegen mit endlos vielen inkompatiblen Erweiterungen und Unterscheiden fortgeführt worden ist. Wie das ausging, wissen Sie sicherlich: Der Markt war zu fragmentiert, Abwicklung und Konsolidierung, POSIX und Linux entstanden.
In gewisser Weise wiederholt sich hier die Geschichte - nur auf einer anderen Ebene. Und systemd ist natürlich auch kein Standard wie POSIX. Aber es entwickelt sich immer mehr zum de-facto-Standard unter Linux. Einige Systeme haben Alternativen, von welchen sich die Entwickler inspirieren lassen haben (Apple mit launchd in macOS etc. und Sun/Oracle mit SMF in Solaris und illumos und Derivaten).
Kommiteestandards wie POSIX haben eben nicht nur Vorteile.
Aber POSIX reicht schon lange nicht mehr, um viele modernere technische Probleme lösen zu können. Deshalb wird inzwischen viel weitestgehend unportabler Quelltext, der auf inkompatiblen (oder teils alternativlosen) Schnittstellen beruht, verfasst. Das manifestiert sich auch in den zunehmenden Schwierigkeiten, die die BSD-Systeme haben, den ganzen Kram am Laufen zu halten (betrifft nicht nur GNOME, sondern auch KDE Plasma oder Firefox). Dort findet sich einfach kaum einer, der die Arbeiten übernimmt.
Auf der anderen Seite, schreiben die BSDs selbst Erweiterungen und unportablen Code (siehe OpenBSD: strlcpy, getentropy/getrandom, arc4random, LibreSSL, OpenSSH, signify, ...), der dann hinterher portiert wird - aber nur, weil sich in der Linux-Fraktion Leute finden, die sich darum kümmern. Die Ressourcen sind dort einfach weniger rar. Es ist eben auch eine Frage des stärkeren Momentums.
Ja, es ist schade, dass die Situation so ist. Und Softwarediversität ist an bestimmten Punkten äußerst wichtig. Jeder kann mit seinen Mitteln und Beiträgen dagegensteuern.
De-facto fand die Migration über die letzten Jahre stetig statt, weswegen auch Probleme wie die schwierige Integration von elogind bestehen und Zerwürfnisse, wie es sich in der Abspaltung Devuans und dem Entwicklerabgang Debians der letzten Jahre (Joey Hess, Lars Wirzenius, Martin Pitt, Michael Stapelberg) manifestiert, das Projekt lähmen (< - Übertreibung).Nun sind die inneren Reibereien nach der Nicht-Entscheidung der letzten GR einfach wieder zu groß geworden, als dass sie dauerhaft gesund fürs Projekt wären.
In der Entscheidung hier, geht es nun endlich darum, wie mit dieser Realität umgegangen werden soll. Das liest sich auch daran ab, dass es bei der GR eine Wahloption gibt, die den Fokus des Projekts auf systemd legt, aber keine, die es auf eine konkrete Alternative legt.
Das "SysV-Gerümpel" sollte vermutlich eher ein Ausdruck für das Alter von SysV bzw. dessen Entwurfszielen und den heutzutage teils unzulänglichen Lösungsansätzen sein, sowie für die Nachteile, die die Init-Shell-Skripte mit sich gebracht haben, stehen.
Jein, das "Universal OS" hat immer auf den kleinsten gemeinsamen Nenner abgezielt (z.B. wurde immer embedded unterstützt), orthogonale Optionalitäten und Alternativen angeboten, wo es machbar war. Das hat natürlich Grenzen, z.B. in der Komplexität der Vereinbarkeit teils gegensätzlicher Einstellungen, Funktionalitäten und Interessen, in der Kommunikation und teils sogar in der sozialen Struktur innerhalb Debians. Wo die Grenzen liegen, zeigen sich nun seit einigen Jahren recht deutlich. Kann man das leugnen?Es war mal das Maß der Dinge zur Lösung von Problemen, reicht je nach Anwendungsfall aus heutiger Perspektive in vielerlei Hinsicht schlicht nicht mehr aus.
Ging es innerhalb des OSS-Ökosystems, innerhalb Debians jemals tatsächlich um die Wahlfreiheit der Nutzer? Ich denke nicht. Bei der GR entscheiden schließlich auch nicht die (alle) Nutzer, sondern die Entwickler (welche natürlich auch Nutzer sind).
Mir persönlich ist es einerlei, wofür die Entwickler stimmen. Ich habe nichts gegen eine Entscheidung für systemd, Upstart, sysvinit, OpenRC, runit oder s6 usw. Ich halte es aber definitiv für unklug, für Option 8 zu stimmen. Das löst den inneren Konflikt des Projekts nicht.
Jeder Entwickler oder Nutzer, der mit dem Ausgang nicht zufrieden ist, kann die Distribution wechseln oder forken. Das ist die Freiheit, die OSS Ihren Nutzern lässt. Zudem befriedet die inneren Reibereien Debians, und führt zu einer höheren Produktivität der verbleibenden Entwicklerschaft. Wäre das nicht eine Win-Win-Situation?
Ob ich Debian ohne systemd für meinen Desktop weiterbenutzen möchte, weiß ich jedoch auch nicht. Das hängt von der konkreten Lösung/Umsetzung ab. Jedenfalls habe ich nach der GR immer noch die Freiheit, eine andere Distribution zu wählen. Das ist, was für mich primär zählt. Sekundär wünsche ich mir, dass Debian nicht in der Bedeutungslosigkeit innerhalb der Distributionsangebote untergeht.
Beste Grüsse
klopskind
Vielen Dank Klopskind. Du hast mit deinem Text meinen persönlichen Nerv getroffen und sprichst mir aus der Seele.
Das ist viel zu viel Technik-Diskussion ! Die technischen Vor- und Nachteile sind bekannt.
Vielleicht sollte man ehr darueber diskutieren, in wie weit die die Art und Weise der "demokratischen Teilhabe" bei Debian umgesetzt wird.
Das Monster mit seiner Buerokratie hat einen nicht reformierbaren Punkt erreicht. Es werden zu viele "gemuetliche Stimmen aus der bequemen und Haengematte" gezaehlt, statt gewogen.
Ausserdem sollte mal bedacht werden, welchen Einfluss Red Hat hat. Und welche "besonderen" Nutzer und Fuersprecher es hat ...
und welche politischen und finanziellen Moeglichkeiten diese Nutzer und Fuersprecher haben.
Fakt ist, Red Hat hat zu viel Einfluss. Und der Linux "Standard" Desktop ist Gnome. Das Standard Init System ist systemd.
Und alle nennenswerten Distributionen sind Anglo-Amerikaner. Die Linux Foundation ebenfalls.
Achso ... fast vergessen. Microsoft und Github auch
Finde den Fehler ??
Und ein bisschen technisch ist es immer, wenn es um das OSS-Ökosystem geht. Die Architekten sind die Software-Ingenieure und Ingenieure haben zwangsweise etwas mit Technik zu tun.
Das ist wohl wahr. Die Debatten und Argumente wurden schon sehr häufig geführt. Da steckt aus meiner Sicht ein wahrer Kern drin. Die Teilhabe der Hundertschaften an Debian-Entwickler ist sicherlich sehr verschieden. Sollten die Entwickler der verschiedenen Init-Systeme in Debian die selbe Stimmgewichtung besitzen wie die direkten Nutzer jener Schnittstellen (etwa Entwickler von Diensten, die von Init abhängen oder verwaltet werden)? Sollten Entwickler, die init-unabhängige Software entwickeln oder pflegen das selbe Stimmgewicht haben?Sollten alle Entwickler die gleiche Stimme haben, wie es zumindest formal in einer idealen Demokratie festgelegt ist? Wenn es nach dem meritokratischen Grundgedanken von OSS ginge, sicherlich nicht.
Nun, wenn man von Red Hat unabhängig sein möchte, muss man entweder die Entwicklung dominieren, was ziemlich kompliziert wird. Oder man muss OSS-Silos bauen, wie es Canonical mit den ganzen Eigenentwicklungen und CLAs oder Apple mit Darwin oder Google mit Android, Chrome OS, coreboot oder die in gewisser Weise die BSDs etc. tun. Auch die Distris ohne glibc sind weigehend unabhängige Kandidaten. Allerdings verwenden letztlich doch die selbe Toolchain etc.Genau letztere strebt das Debian-Projekt aber per Konstitution an. Die Ideen dahinter sind nicht ganz ungerechtfertigt, wenn man sich das Ideal unserer relativ demokratischen Gesellschaften zu Gemüte führt. Den Debian-Gesellschaftsvertrag haben alle Debianer akzeptiert. Man kann sogar jederzeit wieder aussteigen, falls es einem doch nicht so passt.
Damit ist Debian auch als ein soziales (Pilot-)Projekt, um nicht zu sagen Experiment, zu werten, welches es in dieser Form vorher nocht nicht gegen hat, wenn man vom Linux-Kernel absieht, der auch wesentlich meritokratischer funktioniert.
Red Hat profitiert natürlich davon, die Fragmentierung durch Vereinheitlichung einzudämmen. Das erfolgt nicht nur als rein profitorientierten Interessen. Es ist in den gesetzten Umständen schlicht ökonomischer.
Hätte Red Hat kein Eigeninteresse an systemd würde es vermutlich nicht existieren.
Allerdings sollte man auch froh sein, wie offen die Entwicklung geschieht und wie frei der Zugang zu der Software und der Doku ist.
Man darf schließlich auch etwas anderes Verwenden, ohne dass eine Gestapo mit roten Hüten Ihre Tür eintritt und Sie mit Deportation bedroht, wenn Sie etwas anderes nutzen oder entwickeln möchten.
An welche „"besonderen" Nutzer und Fuersprecher“ und „politischen und finanziellen Moeglichkeiten diese Nutzer und Fuersprecher“ denken Sie denn da konkret?
Hm, also der Markt besteht nicht nur aus Red Hat... klar dominieren einen gewissen Teilmarkt. Aber es gibt dort Oracle, HP, Microsoft, Google, Amazon, Apple, Facebook, SUSE, Canonical, die ganzen Embeddedunternehmen/-produktem wie QNX etc., die sich den Betriebsystemmarkt mit unterschiedlichen Schwerpunkten aufteilen.Was heißt da also „zu viel“? Wofür? Und im Vergleich zu wem? Warum schreiten die Kartellbehörden nicht ein? Wieso nicht erstmal dominantere Player zerschlagen?
Was Sie als Standard in Gänsefüßchen bezeichnen, ist ein gängiges Phänomen in OSS und anderen Bereichen. Der stärkere setzt sich durch. Es hat also mehr mit Popularität zu tun. Zudem gibt es schlicht keine ernsthafte Desktop-Konkurrenz im Linux-Ökosystem zu FreeDesktop/GNOME. Jedenfalls ist mir keine bekannt. KDE setzt inzwischen immer mehr auf Techniken aus dem anderen Lager und hat teils unterlegene alternative Komponenten in essentiellen Bereichen (siehe allein GStreamer, gnome-keyring vs KDE Wallet, gvfs/GIO vs KIO, native Mail-Klienten, bis vor einem Jahr nativer Browser - Falcon hat das ein wenig ausgeglichen). In diesem Sinne ist es also bestenfalls ein meritokratischer de-facto Standard.
Anglo-Amerikaner ist ein bisschen weitgefasst, oder? Meinen Sie vielleicht einfach US-amerikanisch?Man sollte auch nicht vergessen, wie viele Systeme ohne systemd betrieben werden (Embedded / Container / Docker).
Richtig, dort und inzwischen auch in China findet der große Hauptteil der Innovation und Entwicklung der IT-Branche statt. Das ist nichts neues. Was wollen Sie damit aussagen?
Allerdings sitzt Canonical in UK, Isle of Man / London. SUSE sitzt wieder in Nürnberg. Der derzeitige Investor EQT Partners ist international tätig und hat einen schwedischen / nord-amerikanischen / europäischen Hintergrund; indirekt gegründet von dem Investiotionsunternehmen der Wallenbergfamilie.
?? Ich komme nicht drauf - bin zu blöd. Bitte helfen Sie mir auf die Sprünge und benennen Sie bitte diese sogenannten „Fehler“ präzise. Danke!Das ist nicht gerade anglo-amerikanisch.
Sind die beiden nicht nennenswert?
So muss man systemd mitschleppen. Was durchaus problematisch sein kann. Denn systemd ist zwingend auf einen Linux-Kernel angewiesen.
Systemd-freie Distributionen konnte man bis dato relativ problemlos in eine FreeBSD-Jail installieren. Das geht dann nicht mehr.
Abgesehen davon bietet systemd auch vernünftige Tools um Probleme zu analysieren.
Das war bei den Init Scripten nicht wirklich der Fall.
Ich hatte tatsächlich mal den Fall, dass ein Dienst nicht wirklich starten wollte und habe dann versucht nachzuvollziehen was die Scripte tun, denn außerhalb des Init Systems (also manuell gestartet) funktionierte der Dienst wunderbar.
Nach ein paar Stunden habe ich aber entnervt aufgegeben, zu verstrickt und undurchsichtig war die ganze Sache.
Also Shell-Skript zu debuggen, ist nicht gerade ein Vorteil der Shell-Sprachen. Schlechter geht es eigentlich kaum...
Was tun Sie bei einer schlecht reproduzierbaren Race-Condition während es Bootens mit SysV? systemd verfolgt einen besseren Ansatz zur Vorbeugung von Race-Conditions.
Upstart war vor Allem der Versuch, ein Event-basiertes Init über SysV zu stülpen. Das hat mehr schlecht als recht funktioniert, gab sogar der Hauptentwickler schlussendlich zu. Die Idee des Konzepts eines Event-basierten Inits an sich war allerdings sehr gut.Das zeigt letztlich auch, dass die Grenzen von SysV ausgereizt wurden, und wie systemd mit neuen Ansätzen die Ansätze von SysV strikt und sauberer erweitert hat. Man kann die Funktionen und Schnittstellen systemds nicht 1:1 auf SysV zurückführen, ohne zentrale Konzepte und Bausteine von systemd zu verwenden oder vollständig zu reimplementieren.
Okay, guter Einwand. Ich glaube aber, dass ein Rosinenpicken schwierig wird. You can't have your cake and eat it too.Welche nicht rein optionalen Teile von systemd wollen Sie denn nicht haben/einsetzen? udev? logind? PAM? cgroups? Was bleibt noch?
Das ganze Projekt sicher nicht. Wieso? Konkreter Anwendungsfall?Welchen konkreten Zweck verfolgen Sie damit?
Damit möchte ich nicht sagen, dass es keine gibt. Aber ich finde solche Aussagen immer viel zu vage. Und meistens sind je nach Anwendungsfall Alternativen mitunter einfach besser. Das bestreitet auch keiner. Sie können weiterhin eingesetzt werden.
Das soll eine Begründung dafür sein, dass es problematisch sein kann, dass man systemd mitschleppen muss? Hä? Die Assoziationskette kann ich nicht nachvollziehen.systemd wurde mit dem expliziten Anspruch entwickelt, Features von Linux zu nutzen und zu vereinheitlichen. Ähnlich wie die glibc es tut, nur auf einer anderen Ebene.
Wann ging das jemals? Quelle?Und warum werden andere Projekte, wie die BSDs, Darwin, macOS, Solaris/illumos, Windows etc. dafür nicht kritisiert? Da steckt zumeist alles in einem Monorepo und ist in essentiellen Teilen unportabel bzw. wurde nicht mit dem Hintergedanken der Portabilität entwickelt.
Eine FreeBSD-Jail ist kein Hypervisor oder gar eine vollständigere VM für beliebige fremdartige Gäste. Die FreeBSD-Jail kann nur auf dem FreeBSD-Kernel zusätzliche voneinander isolierte user-space-Umgebung instanziieren. Andere Gäste wie Linux, Windows etc. lassen sich darin nicht „installieren“.
Übrigens ist FreeBSD-Jails ein FreeBSD-spezifisches Feature, das nicht portabel ist. Und DTrace ist auch nicht einfach portierbar! Schande! /s
Sie meinen eventuell den rein optionalen Linuxulator, der auf CentOS 6 und Linux 2.6.x basiert, inzwischen total ungepflegt und so unsicher und verbuggt ist, dass OpenBSD das Ding hochkant aus dem Orbit katapultiert hat. Nur bei FreeBSD huldigt man diesem Stück Legacy.
Es ist Magie. Es funktioniert, manchmal, irgendwie. Die Frage ist, wie lange noch? Speziellere Linux-Kernel-Features bleiben unimplementiert oder sind unvollständig implementiert. Das kann keine dauerhafte Alternative für den Produktiveinsatz sein.
Ihre Argumente lassen viele Lücken oder viele Fragen offen.
1. Der derzeitige DPL Sam Hartman formuliert eine knappe Antwort auf eine analoge Frage so.
Sind Ihnen das Gründe genug?
Es ist anzunehmen, dass der DPL beabsichtigt, das beste fürs Projekt zu tun. Zwar hat er die GR maßgeblich initiiert, aber erstens schien die Gefahr des langsamen Verfalls oder der Implosion des Projekts durch die internen Reibereien und Missstände zwischen den Entwicklern auch im Fall der Integration von elogind stetig zu steigen, zweitens das hat er erstens vor seiner demokratischen Wahl und Ernennung in dessen Programm indirekt angekündigt solche Schritte zu wagen (Zitat: „I think the DPL's ability to propose general resolutions is under-utilized. I think that having the DPL propose a GR including the major options could be a much less confrontational way to bring closure to an issue than having an individual developer propose a GR and seek seconds. If the process feels a lot more like polling the project and guiding the resolution to a policy discussion, I think voting can bring things to closure.“), und drittens spielt er dabei eher die Rolle eines Moderators, als eines Entscheiders oder Meinungsbildners. Über die endgültige Entscheidung stimmen die Entwickler ab, von welchen er nur einer mit dem selben Stimmgewicht wie allen anderen ist.
Zur letzten GR zu diesem Thema gab es ja keine Entscheidung (siehe Artikel). Das bedeutet, dass der Konflikt de-facto ungelöst blieb und mit allen Nachteilen wieder auf die Entwicklungsarbeiten zurückübertragen wurde. Es wurde sogesehen erstmal unter den Teppich gekehrt. Das kann nicht lange gut gehen. Das Problem wird wieder zutage treten und sich wieder zuspitzen müssen, was ja auch geschehen ist (elogind). Aber nur eine Entscheidung kann die immer wieder aufkeimenden internen Reibereien tatsächlich schlichten.
Und ich vermute, dass genau das der Beweggrund des DPL war, die Debatte erneut zu führen und mit einem GR zu einer echten Lösung zu führen.
2. Welcher "Kompromiss" dabei herauskommt, wird sich zeigen. Ich hoffe für das Projekt, dass es nicht die selbe Entscheidung wie beim letzten Mal wird - nämlich keine. Debian muss zentrale technische Entscheidungen fällen können, um ein erfolgreiches und ernstzunehmendes Distributionsprojekt zu sein. Andernfalls sehe ich das Projekt nur langsam vor sich hinsiechen und ausbluten bis es letztlich stirbt.
Welche Lösung letztlich gewählt wird, wäre mir persönlich egal. Derzeit erkenne ich von außen aber eine Mehrheit an Entwickler-"mindshare" pro systemd bzw. nicht contra systemd.
Außerdem kann ich keine fertiggestellten Ersatzalternativen zum zentralen Konzept und Bestandteil vom Init-Teil von systemd ausmachen. Um die ganzen optionalen Komponenten wie networkd, timesyncd etc. pp. geht es an dieser Stelle ja gar nicht. Die können ohnehin beliebig gewählt und reimplementiert werden.
Andersherum betrachtet, ist eine andere Frage, die sich mir stellt: Was hätte das Debian-Projekt davon, es Devuan, Slackware, Alpine, Void, Hyperbola, Artix etc. gleichzutun? Die haben alle Ihre Daseinsberechtigung, ohne Frage. Und es ist gut, dass es sie gibt. Das bedeutet auch, dass die Wahlfreiheit der Nutzer effektiv bestehen bleibt.
Aber die Gesamtheit der Distributionen, die sich systemd gänzlich verweigern, stellt in meinen Augen eine Nische der Nische dar. Da gibt es nicht viel zu holen an Nutzern oder Entwicklern.
Gleichzeitig sehe ich das Risiko, dass die fähigsten Entwickler Debian meiden oder verlassen werden, um sich anderen Projekten anzuschließen, falls hier keine sozialverträgliche und technisch zu bewältigende Entscheidung fällt. Die Entwicklerressourcen sind nunmal begrenzt.
Warum also alles innerhalb eines Projekts umsetzen? Das führt doch quasi automatisch zu Gegensätzen und Widersprüchen.
Und die Debian-Ports kFreeBSD und HURD sind quasi rein experimentell oder tot. Sollen die die restliche Entwicklung Debians bremsen dürfen?
Änderung um der Änderungen Willen ist die eine Seite der Medaille. Aber deswegen keine alten Zöpfe abschneiden oder zentrale technische Entscheidungen fällen zu dürfen/können, halte ich für tödlich (für das Projekt).
Letztlich entscheiden die Entwickler, was geschieht. Und das bedeutet, dass deren Argumente am schwersten wiegen.
p.s.: Alles unter Punkt 2 ist meine persönliche Meinung. Ich bin Außenstehender und meine Meinung ist nicht in Stein gemeißelt. Ich ändere Sie aber nur, falls ich gute sachliche nachvollziehbare Gegenargumente vernehmen kann, die der Gesamtheit aller Pro-Argumente überwiegen.
Kann man GNU Hurd und den Kernel von FreeBSD systemd tauglich machen oder sind da Lizenzen im Weg?
Was sagen dir dortigen Kernelentwickler zu systemd?
Das problem mit Systemd für GNU Hurd und FreeBSD ist, dass systemd linux cgroups verwendet. Die sind soweit ich weiß nicht in FreeBSD oder Hurd implementiert.
Ich weiß aber nicht ob man die in Hurd oder FreeBSD implementieren könnte.
Ich wage zu bezweifeln, dass die Lizenzen das Problem wären, da der Code eh neu geschrieben werden müsste. Ich glaube nicht, dass es sich lohnen würde, den bestehenden Code aus Linux zu kopieren und anzupassen. Dafür sind die Innereien zu verschieden.
Ein Beispiel ist das unten erwähnte Linux-Feature namens cgroups. Ich kenne keine etwa gleichmächtige oder ebenbürtige Schnittstelle in FreeBSD. Für HURD gilt vermutlich das Gleiche. Aber HURD ist gleich nochmal anders. Ich bezweifle, dass systemd dort mit den anderen Message-Passing-Konzepten überhaupt idiomatisch wäre. Hoffentlich lehne ich mich da nicht zu weit aus dem Fenster...
Keine Ahnung. Wenn Sie es wirklich wissen wollen, schlage ich Ihnen vor, direkt zu fragen.In FreeBSD gibt/gab es Ideen dazu, etwas Ähnliches zu systemd, aber in Anlehung an eine Inspirationsquelle systemds namens launchd (OS X), umzusetzen.
Also prinzipiell interessiert scheinen einige Entwickler an einer Alternative zu sein. Allerdings erinnere ich mich dunkel, dass es da intern auch viel Gegenwind gab.
Weiß jemand, wie die zu einem demokratischen Ergebnis kommen? D.h. weiß jemand, wie die Abstimmung bewertet werden soll? Ich meine es kann ja nicht sein, dass die Option mit den meisten Stimmen einfach so gewinnt, da die Befürworter der reinen SystemD-Lehre genau 1 Option haben, und die Befürworter von mehr oder weniger Vielfalt sich auf 7 weitere Optionen verteilen. D.h. 12,5% + 1 Stimme könnten theoretisch ausreichen, um Alternativen auszuschließen.
"D.h. 12,5% + 1 Stimme könnten theoretisch ausreichen, um Alternativen auszuschließen."
Was ist daran undemokratisch? Das gibt es bei Volkentscheiden - die keine Mindesteilnehmerquote > 25% voraussetzen - auch.
Das ist ja nicht vergleichbar. Ich rede von 12,5% + 1 Stimme der abgegebenen Stimmen.
Gerade gefunden: https://www.debian.org/devel/constitution#item-A
Alles klar, da wird rangiert und "der Sieger aus den Wahlmöglichkeiten in der Schwartzschen Menge ausgewählt". Ich tue mir das jetzt nicht an, sieht kompliziert aus
Debian nutzt die Condorcet-Methode, die auch bei der Wahl des Projektleiters Anwendung findet. Mehr dazu gibt es auf https://www.debian.org/vote/