Boycott Systemd

Status
Für weitere Antworten geschlossen.
darktrym schrieb:
[...] würde denn nicht Drittsoftware darauf setzen [...]
Zum Vergrößern anklicken....
Das Problem lässt sich m.M.n. relativ "einfach" beheben:
Den Entwicklern mitteilen das man aufgrund ihrer Entscheidung auf systemd zu setzten die Software in Zukunft meidet und das jeweilige Projekt (sofern gegeben) nicht mehr unterstützt.
 
  • Like
Reaktionen: Chu
gadean schrieb:
Das Problem lässt sich m.M.n. relativ "einfach" beheben:
Den Entwicklern mitteilen das man aufgrund ihrer Entscheidung auf systemd zu setzten die Software in Zukunft meidet und das jeweilige Projekt (sofern gegeben) nicht mehr unterstützt.
Zum Vergrößern anklicken....
Nur juckt das die Entwickler wenig. Die freuen sich dann noch, weil sie ein paar #ifdefs raus dem Code rausnehmen können.
 
Hm bei einigen mag das bestimmt zutreffen aber ich denke nicht bei allen und es gibt sicherlich einige Projekte bei denen aus dem *BSD Lager commits einfliesen. Wenn die wegfallen wird das sicherlich einige interessieren. Ich als Entwickler würde mir schon Gedanken machen wenn auf einmal ein Teil meiner Userbase weg rennt.
 
  • Like
Reaktionen: Chu
Diese "beleidigte Leberwurst"-Taktik wirkt nicht und sich selbst belügen auch nicht. FreeBSD ist zwar gut, aber niemanden juckt es, wenn es keine Anwendungen am Laufen hat. Mich übrigens dann auch nicht, weil ich an einem Betriebssystem welches nur da ist, um da zu sein (und mehr dann nicht), kein Interesse habe.

Es ist nur von Vorteil, dass ich KDE und Gnome nicht mehr nutze und rechtzeitig einige Alternativen ausprobiert habe, um ein sauber und schmerzlos funktionierendes System zu bekommen. Die Schmerzen wären aber recht groß, wenn ich abhängig gewesen wäre, denn diese Desktop-Umgebungsprojekte können wir getrost begraben, wie es aussieht.
 
XFCE hat es damals auch nicht gejuckt. Zwar kam der Hinweis, na baut mal sowas wie bei Linux x, y. Aber wenn man selber keinen Plan von anderen Betriebssystemen hat, sollte man lieber nicht Vorschläge nach API Nachbaus stellen. So schwer ist es nicht die Leute zu fragen, ob was existiert, den Kram zu sammeln und sich was zu bauen. So haben die mich als Anwender verloren.
 
Ich sehe das nicht als "beleidigte Leberwurst"-Taktik, wenn mir etwas missfällt dann tu ich das gegenüber dem Entwickler kund und wenn es ihn nicht interessiert, dann will er mich nicht als User/Kunde haben, also geh ich woanders hin und wenn dem genug User folgen wird der Entwickler evtl. noch mal darüber nachdenken und ist evtl. zu einem Kompromiss bereit.

Aber ja, viel Erfolg wird das wohl nicht haben, wenn ich mir so die Spielebranche anschaue, ich werde trotzdem diesen Weg wählen.
 
  • Like
Reaktionen: Chu
Ganz nebenbei, ich habe nach der Pleite mit den meisten Desktop-Environments mir angeschaut wie Sessions eigentlich unter X laufen sollten (dazu schaut man sich ganz einfache Window-Manager an, *box oder Xmonad oder was auch immer). Ich habe gesehen, dass diese WMs eigentlich einer guten Idee folgen und sich an Standards halten, die die Großen ganz grob ignorieren und dadurch auch unglaublich kompliziert werden.

Als nächstes habe ich mir genau die Vebrechen angeschaut, die zu den Brüchen mit Standards führen und habe festgestellt, dass in allen... aber auch wirklich in allen Sachen, die schwachsinnig sind(!), der Lennart seine Finger drin hatte. Sogar in dem bescheuerten "Standardanwendungen"-Skript "xdg-open", was immer Firefox öffnet, wenn es keine Standardanwendung für einen Dateityp gibt (auch von Chrome aus natürlich!). Das schafft mir ein gutes Gesamtbild wer Schwachsinn entwickelt, finde ich.
 
Ja... ich weiß(???!) Deswegen habe ich auch FreeBSD im Einsatz... auch deswegen, weil die Features bequem konfigurierbar sind (make config). Ich rede nur von der Tendenz wo es hingehen könnte.
 
Alles, was vielleicht weniger wird, ist Desktopspielzeug von GNOME und Konsorten. Das braucht aber nun wirklich niemand. :D
 
CrimsonKing schrieb:
FreeBSD hat mehr Anwendungen als Debian Linux.
Zum Vergrößern anklicken....
Debian ist aber „bequemer“, nicht zuletzt weil sie ihre Pakete Batteries Included konfigurieren.
Ich wollte auch Binärpakete verwenden, aber dass beispielweise Git ohne GUI kommt ist mehr als nur unpraktisch.
Mich halten die Ports nicht davon ab, FreeBSD zu benutzen, aber sonst eine ganze Menge Leute.
(Allerdings denke ich ist das genau die Menge Leute, die sich auch nicht gegen die Schäden durch systemd zur Wehr setzt).
 
Macht es aber sehr viel einfacher, die aktuellen Änderungen in kleine commits aufzuteilen.
Aber das weicht vom Thema ab, Fakt ist dass ich u.A. deswegen wieder Ports kompiliere, was viele nicht tun würden,
und die meisten Linux-Distributionen (von Gentoo und Arch etc. abgesehen) das einfach durch Monster-Pakete vermeiden.
 
Ich bin für die meisten git-GUIs, ehrlich gesagt, zu blöde. SourceTree kann ich zwar bedienen, aber das hat mir zu viele Bugs, die im täglichen Betrieb doch sehr auffallen, spätestens wenn man mergen möchte.

Da lieber 'n paar Shellscripts.
 
Ich meinte tatsächlich das bei git mitgelieferte git-gui. Mehr als Quellcode markieren und zum staging hinzuzufügen mache ich auch nicht.
 
Athaba schrieb:
Aber ganz ehrlich finde ich die OpenBSD-Kompatibilitätssache nicht so toll, weil sie ja eher einen letzten Ausweg darstellt.
Zum Vergrößern anklicken....

Stimmt. Hätte man rechtzeitig eine Alternative auf die Beine gestellt, könnte man sich die Arbeit jetzt sparen. :(

Athaba schrieb:
systemd ist komplex und nicht simpel und braucht viel Kontrolle. Wenn ich ein Interface mache, dann braucht das ja zumindest ähnlich viel Kontrolle und komplexe Teile zu wrappen ist ja auch nicht gerade das Beste und auch nicht simpel.
Zum Vergrößern anklicken....

Nicht notwendigerweise - Interface-Design ist eine Wissenschaft für sich. Eine komplexere Implementierung ermöglicht oftmals ein simpleres Interface (ZFS oder SQL lassen grüßen).
Welcher Grad an Interface- und Implementierungs-Komplexität an welcher Stelle der richtige ist, ist immer Gegenstand einer hitzigen Debatte. Zu einfache APIs sind eben so schlecht wie zu komplexe. Das Kunststück ist, die notwendige Komplexität an den richtigen Stellen zu verpacken.

Im Falle von systemd sind die entsprechenden 4 APIs (logind, hostnamed, localed, timedated) dokumentiert und besitzen mit systemd selbst eine offene Referenzimplementierung, an der man sich orientieren kann - beste Voraussetzungen.

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.

darktrym schrieb:
Dies ist problematisch weil die API nur den aktuellen Stand abbildet und von den Systemd Entwickeln null Support auf Langlebigkeit geben wird.
Zum Vergrößern anklicken....

Das wage ich in Anbetracht von Red Hat im Hintergrund zu bezweifeln - schließlich verdienen sie mit Langlebigkeit ihr Geld:
Interface Portability and Stability Chart

gadean schrieb:
Das Problem lässt sich m.M.n. relativ "einfach" beheben:
Den Entwicklern mitteilen das man aufgrund ihrer Entscheidung auf systemd zu setzten die Software in Zukunft meidet und das jeweilige Projekt (sofern gegeben) nicht mehr unterstützt.
Zum Vergrößern anklicken....

Ich würde eher schauen, dass man Alternativen anbieten kann. Die Verweigerungshaltung gegenüber den Anforderungen der Entwickler hat die systemd-Dominanz erst möglich gemacht. Ein Betriebssystem steht und fällt mit den Anwendungen, die darauf laufen.

Lamentieren hilft nichts, jetzt heißt es Arschbacken zusammenkneifen, einen Kompatibilitäts-Layer bereitstellen und parallel dazu etwas Besseres als systemd auf die Beine zu stellen, das auch moderne Anforderungen erfüllt. Sonst führt man ein Rückzugsgefecht, das man nur verlieren kann.
 
Wie(so) soll man Alternativen anbieten für eine Sache, die überflüssig ist, weil sie nichts sinnvolles tut? Am besten ist, das ganze auszusitzen und zu gucken was für ein Schwachsinn weiter daraus wird. Wer weiß, vielleicht findet sich wenigstens EINE Sache, die dabei einen Mehrwert ergibt.
 
peterle schrieb:
Slackware hat ein reichlich umständliches System die gewünschte Software zu bauen.
Zum Vergrößern anklicken....

Als Slackware-Derivat wäre sicherlich SalixOS erwähnenswert. Deren "Basic"-Version nutze ich auf meinem alten Acer Laptop.
SalixOS ist soetwas wie das PC-BSD für FreeBSD von Slackware. Die Abstufung in "Core", "Basic" & "Full" finde ich darüber hinaus sehr sinnvoll und entscheidend, dass vollständig zu Slackware kompatibel.
Dann gäbe es ja noch die Derivate wie "Absolute" oder "Zenwalk".
 
Azazyel schrieb:
Stimmt. Hätte man rechtzeitig eine Alternative auf die Beine gestellt, könnte man sich die Arbeit jetzt sparen.
Zum Vergrößern anklicken....
Eine Alternative zu Systemd? Und was hätte das geändert? Den meisten OS-Entwicklern, z. B. aus dem GNOME-Lager, sind die BSDs doch sch...egal. Hältst Du es für wahrscheinlich, daß man in GNOME neben der Systemd-Verbindung auch eine (alternative) Verbindung zu einem "FreeBSDd" eingebaut hätte, wenn es so einen gäbe?
nakal schrieb:
Wie(so) soll man Alternativen anbieten für eine Sache, die überflüssig ist, weil sie nichts sinnvolles tut?
Zum Vergrößern anklicken....
Also, das ist nun wirklich Käse! Etliche der Funktionen von Systemd sind durchaus nützlich, etwa daß man mit localed die Tastaturbelegung ändern kann (wenn Du mal eine Russin heiratest) oder daß logind eine allgemeine Anlaufstelle für User logins bereitstellt, ohne die die jeweiligen Softwarekomponenten (z. B. Display manager) viel mehr selbst erledigen müssen - und daß er allgemein der von Azazyel erwähnten "Interface Portability and Stability Chart" Vorschub leistet. Bei anderen Teilen (hostnamed, timedated) gebe ich Dir durchaus recht, die halte ich auch für Firlefanz. (Aber vielleicht weiß ich einfach nicht genug darüber.)
 
Tronar schrieb:
Den meisten OS-Entwicklern, z. B. aus dem GNOME-Lager, sind die BSDs doch sch...egal.
Zum Vergrößern anklicken....

Ganz im Gegenteil, die GNOME-Entwickler treiben sogar großen Aufwand, um die Portabilität zu gewährleisten.
Einer der Entwickler hat sogar darüber geschrieben, dass ihn der unberechtigte Vorwurf sehr schmerzt (den Link habe ich auf die schnelle nicht gefunden, bei Bedarf kann ich mich aber auf die Suche machen).

Tronar schrieb:
Hältst Du es für wahrscheinlich, daß man in GNOME neben der Systemd-Verbindung auch eine (alternative) Verbindung zu einem "FreeBSDd" eingebaut hätte, wenn es so einen gäbe?
Zum Vergrößern anklicken....

Die GNOME-Entwickler selbst haben ausführlich darüber geschrieben:
Beide Links sind äußerst lesenswert, weil sie die ganze Diskussion in diesem Thread sehr schön aus Entwicklersicht eines Open-Source-Projekts beschreiben. Mit allen Vor- und Nachteilen der einzelnen Möglichkeiten.

Fazit: ja, sie hätten.
 
Ich werd mir mal die Links durchlesen auch wenn ich nicht weiß ob sich das lohnt.
Jemand der unter Portabilität sich vorstellt seinen Code mit IFDEFS zuzukleistern, sollte lieber umschulen oder was in der QA machen, imho.
Sich ein Schild umzuhängen mit wir sind portabel, wenn ihr uns die passenden Patches liefert, ist ein Armutszeugnis.

#1000:D
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben