Boycott Systemd

Status
Für weitere Antworten geschlossen.
Ich frage mich so wieso was die ganzen Linux Kernel Entwickler dazu meinen? Einer aus dem systemd Lager wurde von Linus persönlich gesperrt und er kann keine Commits mehr machen beim Kernel.
 
Um mal auf die Alternativen zu sprechen zu kommen. Nehmen wir an man braucht Linux weil das eine große Abhängigkeit für ein Projekt ist. Sehe ich das richtig, dass Slackware die einzige (größere bzw. stabile) Distribution mit Binärpaketen, ohne systemd ist? CRUX und Gentoo setzen ja auf selbst kompilieren.


Es sind auch Binaerpackete machbar, aber (die scheinbar dennoch) selbst kompiliert werden muessen, und dann auf eigenen Server liegen. Guckst Du hier, und eventl ist es in Deinem Sinne: http://wiki.gentoo.org/wiki/Binary_package_guide
 
Mir fällt auf, dass mit jeder neuen Idee für systemd das Geschrei darüber größer wird. Noch vor einiger Zeit, als dieser Irrsinn mit der Integration von NTP und DHCP losging, waren in der Linuxwelt positive Kommentare deutlich in der Mehrzahl. Inzwischen werden die Kommentare von deutlichen Gegenstimmen und Galgenhumor geprägt: http://www.pro-linux.de/news/1/21461/comm/1/show-all-comments.html
NTP und dhcp mögen vielleicht noch Sinn machen für den einen oder anderen Nutzer (ich schließse mich da mal aus), doch alles Andere, was der LenNerd da baut, braucht in der Form kein Mensch.
[Verschwörungstheorie]
Wenn er sagen würde, dass er sich sein eigenes, linuxbasiertes OS baut, würde vermutlich keiner was dagegen sagen. Ich unterstelle ihm mal als Ziel die Vernichtung von Linux bzw. unixoiden Systemen in der Hoffnung damit Nutzer für sein, inoffiziell angestrebtes OS zu gewinnen.
[/Verschwörungstheorie]
 
Irgendwie kommt mir dieses systemd so bekannt vor...

... Gab's da nicht mal ein auf Linux basierendes System Namens Android?

Und das ist den Lizenznazis aus der GNU-Ecke nicht gut genug, weswegen es entsprechend ihrer Ideologie nachgebaut, verdraengt und ausgerottet werden muss!
SCNR

Aber das Thema Featureparitaet und Inkompatibilitaet mit Android kommt auch immer oefter hoch in der Diskussion um systemd.
 
Aber ganz ehrlich finde ich die OpenBSD-Kompatibilitätssache nicht so toll, weil sie ja eher einen letzten Ausweg darstellt. 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.

Oder sehe ich das falsch?
 
Wie setzen die von OpenBSD das eigentlich um? Wenn ich das richtig verstehe, dann wollen sie APIs anbieten, die total hirnrissig sind (Locale/Zeit vom Desktop aus setzen, Ausloggen über DBUS etc). Sollen das Dummies sein, die nichts tun?
 
Ja, tust du. Es geht ja nicht um einen Nachbau.
Ja, mir ist schon klar, es geht darum ein Interface zur Verfügung zu stellen, aber wenn Software dieses und jenes (logind, etc.) alles will und eigentlich mit allem zu rechnen ist muss dahinter alles zur Verfügung gestellt werden. Auch ändert das nichts daran, dass du dir nicht einfach ein rc-script machen kannst, etc. Da bleibt ja dann nicht mehr soviel übrig und es bleibt der letzte Ausweg für Software die das erwartet, was mitunter sehr viel sein kann, wenn alle möglichen Init-Systeme unter Linux ersetzt werden und da ja sehr tiefgreifend eingegriffen wird. Und wenn GNOME, X, etc. es brauchen und dann erwartet ist die Implementierung im Hintergrund ein BSD-Code, aber sonst dürften die Unterschiede ja nicht so groß sein.

OpenBSD hätte ja auch PAM-Interfaces zur Verfügung stellen können, aber auch dort im Hintergrund die ganze Komplexität unterstützen müssen. (Zugegebenermaßen vielleicht nicht der allerbeste Vergleich)

Wie gesagt, mir ist schon klar dass es um eine Kompatibilität geht und nur ein Interface zur Verfügung gestellt werden soll, aber auch wenn die Implementierungen zur Bereitstellung des Interfaces ganz anders sind, als das was unter systemd auf Linux der Fall ist muss am Ende das Selbe da sein und da systemd ein riesiges, alles mögliche betreffendes Ding ist gibt sehe ich da ein Problem aufkommen, wenn das alles unterstützt werden muss, auf Grund von Komplexität, diverser Dummheiten, etc. Scheint ja auch immer mehr zu werden was da reinkommt, ein Interface braucht, damit von Software potentiell erwartet werden kann/erwartet wird. Dazu kommt noch, dass das Ding ohne soweit ich das sehe Standard oder Specs als unportabel entwickelt wird. Dann steht OpenBSD vor der Frage, ob eine Dummheit unterstützt wird, was dazu führt, dass es womöglich unsicher ist oder das Interface nicht kompatibel ist.

Ich finde es cool, dass sich jemand die Arbeit antut, ich habe aber auch die Changelogs von systemd gelesen und selbst wenn die Implementierung hinter dem systemd-Interface sauber ist, kann es sein, dass eben so Dinge, wie von nakal erwähnt supported werden müssen. Damit hat man dann den Teil, der an systemd blöd ist erst wieder drin. Wie gesagt, die systemd-Changelogs schauen da ziemlich erschreckend/nach Aprilscherz aus.
 
Nur falls es einen interessieren sollte, LFS 7.6-rc1 setzt dann auf eudev (gentoos udev fork) - anstatt udev aus systemd zu extrahieren.

Wenn ich mich recht erinner, fahren sie, LFS,(momentan) auch zweigleisig. Wer mag mit systemd, wer nicht, der ohne. Oder so war es...
 
Ein pragmatischer Sysadmin, der sich so richtig über die Einführung von systemd unter Debian freut meinte folgendes zu dem Thema:
I feel like we should institute something like the "mourning for Kim-Jong-Il" thing in North Korea.
mandatory 5 mins. in the morning for being loudly upset with systemd

Irgendwie habe ich dashier ganz übersehen.
 
Dass es keine Ausweichmöglichkeit sei, klingt als ob OpenBSD auf systemd umsteigt. Das wird erst im nächsten Satz komplett entkräftet. Bei dem vorigen Satz kann man aber auch aufhören zu lesen, weil es einfach nur blöd klingt, was die da geschrieben haben.
 
Ich spring ihm mal bei:
Kritik kommt von vielen Lagern, auch Linuxer sind nicht sonderlich glücklich. Ein BSD Nutzer ist Systemd scheißegal, würde denn nicht Drittsoftware darauf setzen und somit andere Betriebssysteme dabei kastrieren.
Ob alle Thesen widerlegbar sind, kann ich nicht beurteilen, der Autor offensichtlich auch nicht. Er hat es ja nicht mal geschafft eine Quelle dafür anzugeben, auch ist der Artikel nicht sonderlich objektiv/neutral geschrieben.
Dazu wird auch keine Systemd Funktionalität geben sondern die vorher eigenständige Projekte, werden ansprechbar gemacht mit dem gleichen Interface wie es aktuell Systemd verwendet. Dies ist problematisch weil die API nur den aktuellen Stand abbildet und von den Systemd Entwickeln null Support auf Langlebigkeit geben wird. Besser wäre sicher eine Lösung die sich unterscheidet und den Upstream die Änderungen mitzuteilen. Sonst hängt man schnell am Tropf.
Alle GSoC Projekte sind der Not geschuldet, weil freiwillig das keiner machen wollte, nun bekommt man Geld und Ansehen. So gut wie alle Projekte brauchen Liebe nach der Zeit um den Code ins Projekt einzupflegen und wartbar zu machen, gerade wenn der Schreiber nicht weiter am Projekt arbeiten will.

Über den Stil der Nachricht selbst, jemand der keine Ahnung vom Thema hat, hätte diesen Text ebenfalls zusammenwürfeln können. Ein unschöner Mix aus Nachricht, Meinung, Vermutung, Unwissen. Aber wer liest schon freiwillig Computerbase?
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben