Boycott Systemd

Status
Für weitere Antworten geschlossen.
Warum also dieses andauernde schimpfen auf Linux, das ist als ob ich auf Äpfel schimpfe weil ich es vorziehe Birnen zu essen. Natürlich kann man Birnen für gesünder halten als Äpfel, aber macht das Sinn darüber zu streiten? :rolleyes:
Mag nicht auf Linux schimpfen und stimme dir zu dass Streiten nicht viel bringt. Andererseits mag ich aber auch nicht, dass jemand von Unternehmen X kommt und die was einbauen, was komplett von denen kontrolliert wird und dann Macht ausgeübt wird. Das sehe ich bei Betriebssystemen nicht so arg, aber bei anderer Software hat man das schon, dass die von einem Unternehmen kontrolliert werden und vieles was die Community angeht einfach kaputt geht. Schaut euch mal an was bei Sun -> Oracle passiert ist. Manchen Projekten hat es richtig geschadet, anderen weniger und es jetzt einfach mehrere OpenOffices ohne wirklichen technischen Grund. Klar, man kommt darüber irgendwie hinweg, aber gut ist das trotzdem nicht.

Ich glaube wenn RedHat entweder gekauft wird oder sich einfach anders zu handlen beginnt kann es ähnliches geben.

Und ja, ich weiß, viele schimpfen über 50 MP3 Player, aber auf der anderen Seite ist es gut, wenn es nicht nur einen einzigen gibt von dem quasi alles abhängt. Probleme gibt es mehr, wenn die jetzt alle nur einen anderen Namen hätten und sich nur kaum unterscheiden. Weil da baut man sich Sackgassen und das wiederum ist ein typischer Pluspunkt von offenen Communities, dass da sogar kommerzielle Spieler dann versuchen niemand anderen eine Sackgasse bauen zu lassen. Systemd wird eine Sackgasse, wenn viel Software darauf aufbaut und eben nicht nur nutzen kann, sondern es wirklich benötigt. Das ist ja der Grund, warum es diesen Aufschrei seitens der BSDs gab und warum uselessd entstanden ist und gezeigt hat, dass es auch anders geht. Ich denke mal, solange es Distributionen gibt, die eben kein Systemd haben ist alles in Ordnung, aber ich fand's dann halt irgendwo erstaunlich das aus so fünf verschiedenen Systemen plötzlich eines wurde. Finde es ja gut, wenn man sich zusammenrauft und es soll wirklich nicht alles negativ gesehen werden, sondern durchaus auch positiv. Nur wundert es mich doch, wenn OpenPKG, LSB, etc. es nicht schaffen und es bei systemd mit doch großem Aufschrei doch so viele Entscheidungsträger überzeugt. Find's komisch. Habe ich bisher eben nicht mitbekommen. Bei anderen Theman war es doch dann eher ein "Ja, wir sind nicht glücklich und der Code ist mies, aber bis es was besseres gibt passt's". Vielleicht und wahrscheinlich wird auch systemd mal ersetzt, aber dadurch, dass es doch diese riesige Ansammlung von Modulen ist ist das komplette ersetzen ein ziemliches Projekt. Das ist dann wieder die technische Kritik. Man schickt Unmengen an Zeug mit, die zwar modular sind im Sinne von grundsätzlich austauschbar, aber ich glaube nicht, dass die Tools so eine Verbreitung hätten, wenn sie nicht mit einem quasi davon unabhängingen Software mitgeschickt worden wären. Und das meinte ich mit Politik. Das ist ja doch recht nah an Bloatware auf dem Laptop und (vorausgesetzt es ist wirklich modular) nicht wirklich sinnoll.
 
Wirklich? Ich erinnere mich da an relativ lange Threads, Leute die sich beschweren, dass KISS nicht ernst genommen wird, dass die zentrale Konfiguration nicht wegfällt, etc.

Du kannst jede Kleinigkeit ändern, irgendwer beschwert sich immer. Forks sind auch schon aus ganz anderen Dingen entstanden. Die Frage ist nicht "es gab einen Fork", sondern "gibt es den Fork auch länger?". Damals gab es auch Krach bei FreeBSD und daraus ist DragonFly BSD entstanden. Verachtest du deswegen jetzt FreeBSD? kA, ich nicht ;)

Ich hab den Wechsel nach systemd damals mitgemacht und in der Zeit davor kann ich mich noch sehr gut daran erinnern, dass alle Nase lang ein "wann kommt systemd?" und Themen über das damals noch optionale systemd wie man es nutzt usw.

Es gab damals auch eine Debatte, ob systemd jetzt das KISS System von ArchLinux kaputt macht und man kam zum Schluss, dass es das nicht tut. Die damalige rc.conf war damals sowieso schon nur noch mehr Schein als Sein. Vieles konnte man einfach nicht darüber konfigurieren und ob ich nun meinen Hostname in die rc.conf schreibe, oder hostnamectl set-hostname "hostname" eintippe... wayne.

Netzwerkkonfiguration wurde ebenso schon länger extern gemacht... und die Dienstverwaltung kann systemd viel besser, vconsole richte ich auch nicht alle Nase lang neu ein.

Die damalige Kritik an systemd konnte ich gut nachvollziehen. Es war zuweilen buggy. Alle Nase lange startete das System wegen Race-Conditions nicht und hier und da Kleinigkeiten. Gilt heute alles nicht mehr. Längst behoben. Es beschwert sich auch keiner mehr über systemd.
 
Stimm dir da zu. Ist besser geworden. Dass Leute sich irgendwann nicht mehr beschweren hat drei Gründe: Es ist besser, man hat sich abgefunden oder man ist entweder auf Arch Linux selbst auf ein anderes init umgestiegen (gibt einiges an runit und OpenRC User) oder hat die Distribution verlassen. Ich halte da Leute für pragmatisch genug. ;)

Find's aber ehrlich gut, dass mit Voidlinux, Alpine Linux und die BSDs usermäßig profitiert haben. Teilweise auch Gentoo und Slackware, Crux, etc., aber die hatten schon davor ihre eingesessene Userbase. Gab mal wieder einen Anreiz was neues zu machen. Fand auch cool, dass es einen Wettstreit um minimalistischere Init-Systeme gab. Hat anfangs nicht so ausgesehen. Da sieht man mal wieder wer die echten Hacker sind. :)
 
Also bei ArchLinux war es ein sehr starker Wunsch der Nutzerschaft. Man hat schlicht das umgesetzt, was die meisten Nutzer wollten und ich sehe auch in den entsprechenden Arch-Communities keine großen Jammereien deswegen. Als auf systemd umgestellt wurde, wurde das eher mit offenen Armen empfangen.

Ich habe sehr viel mehr von Klagen wegen dem Wechsel mitbekommen als von diesem Konsens. Das liegt sicherlich auch an meinem Umfeld, aber so ganz unumstritten, wie du es jetzt schilderst, kann diese Entscheidung also doch nicht gewesen sein.

Ansonsten hat Athaba alles viel besser ausgedrückt, als ich es könnte ;)
 
Wirklich? Ich erinnere mich da an relativ lange Threads, Leute die sich beschweren, dass KISS nicht ernst genommen wird, dass die zentrale Konfiguration nicht wegfällt, etc. Wurde nicht sogar LSD Linux (Less SystemdD) von ehemaligen Arch-Leuten begonnen. [...] Ich kann garnicht zählen wie oft ich von Leuten höre, dass sie von Arch auf OpenBSD oder FreeBSD gewechselt sind. [...]

Wie gesagt, geht weniger darum ob systemd nun gut oder schlecht ist sondern um den Entscheidungsprozess. Arch Linux hat schon verhältnismäßig "krasse" Entscheidungen getroffen wg. Simplicity und das war vor allem Anfangs ein großer Grund gegen Systemd, auch weil sie Software schlicht und ergreifend noch nicht so modular war, wie sie jetzt ist. [...]

[...] auch wenn ich es cool finde, dass Leute sich jetzt BSDs ansehen ist es jetzt auch nicht das Beste, wenn der Grund dafür einfach nur ist, dass sie systemd nicht wollen. Ich glaube auch echt nicht, dass es gut für die BSDs ist, wenn das große Feature, das Leute zum Umsteigen bewegt die Abwesenheit von systemd ist.

Naja, sojemand bin ich ja auch. Gentoo war ja damals cool, weil man alles anpassen und viel über das System lernen konnte. Arch war dann ähnlich anpaßbar (wenn auch nicht in so einer Tiefe), aber wesentlich einfacher zu nutzen. KISS ist toll. Systemd war nicht wirklich kiss, und damals auch nicht so ganz flexibel (wie es heute ist, kann ich nicht beurteilen). - Wie auch immer: Ich denke nicht, daß systemd der Grund ist, warum einige Leute weg von Arch bzw. von Linux gehen und sich auch mal die BSDs ansehen oder ganz was anderes. Ich denke vielmehr, systemd hat das Faß zum überlaufen gebracht. Ich mochte mein Gentoo, ich mochte auch mein Arch. Das waren schöne Systeme, und beide haben sich auf die Fahne geschrieben, von BSD inspiriert zu sein: Gentoo mit seinem Portssystem, Arch mit der zentralen rc.conf.

Was mir aber im Lauf der Zeit sauer aufgestoßen ist: Man muß alle halbe Jahr sein halbes System umbauen. Von devfs nach hal, nach udev, nach systemd, und zwischendrin mal consolekit und polkit rein, dann wieder weg und alle halbe Jahr bricht was auseinander, weil wieder irgendwas halbgares ein anderes totgelaufenes Projekt ersetzt. Spaßig war das ganz besonders, als mein dm-crypt Segfaults geworfen hat weil sich mal wieder das halbe System geändert hat. Nein danke, auf sowas hab ich keine Lust mehr, dafür ist mir meine Zeit und mein Herz zu schade. - Was liegt also näher, als sich genau die Systeme anzusehen, von denen diese Distributionen, die ich mochte, inspiriert waren? Lange bin ich noch nicht bei FreeBSD, aber das was ich hier gefunden habe, ist genau das richtige für mich. Hier bricht nicht ständig was auseinander, hier wird nicht ständig das ganze System umgebaut, hier hab ich meine Ruhe, denn das System tut genau das was es soll, ohne mir im Weg zu stehn.

tl;dr: nicht systemd ist das, was mich am Linuxland nervt, sondern daß alles ständig auseinanderbricht.
 
Lange bin ich noch nicht bei FreeBSD, aber das was ich hier gefunden habe, ist genau das richtige für mich. Hier bricht nicht ständig was auseinander, hier wird nicht ständig das ganze System umgebaut, hier hab ich meine Ruhe, denn das System tut genau das was es soll, ohne mir im Weg zu stehn.

Na dann benutze FreeBSD noch mal eine Weile :D FreeBSD baut auch alle Nase lang Dinge um. Mal kleinere Sachen, mal größere. Sowas lässt sich nicht vermeiden, wenn man mit der Zeit gehen will. Aber gerade das recht marode Ports System zwingt einen oft zum manuellen Eingreifen und pkg ist da noch nicht weit genug entwickelt, um daran was zu verbessern.

Für mein Empfinden ändert FreeBSD Dinge nicht sonderlich weniger als ArchLinux und ich hab da beides täglich im Einsatz.
 
Ja klar, über die Ports brauchen wir hier nicht zu reden. Das ist ein anderes Thema. Ich habe mich hier auf das OS an sich beschränkt, da krieg ich halt FreeBSD aus einem Guß und das bleibt so wie es ist. Ich muß am Userland nicht selbst rumfrickeln, damit es läuft, was man halt bei Arch und Gentoo regelmäßig muß.

A propos: "nicht lange" ist relativ. Ich hab auch schon Major-Upgrades hinter mir...und auch das ist problemloser, als wenn bei Arch mal wieder von einem auf ein anderes Paket umgeschwenkt wird.
 
Joahr, solange bis das Projekt umgesetzt ist, welches das Base-System aufbricht und als Ports umsetzt. ;) Dann ist FreeBSD genauso wie ArchLinux.
 
Das glaub ich kaum - die klatschen ja Base nicht aus zig Quellen zusammen und hoffen, daß es überall läuft. Das ist m.E. schon weitaus besser aufeinander abgestimmt.
 
Das OpenSSL im Base ist kein anderes als das in den Ports, nur ggf. eine ältere Version und mit anderen Optionen kompiliert. Ebenso alle anderen Projekte die du im Base findest. Gleiches kannst du mittels Ports/pkg erledigen innerhalb eines "Base"-Repos. Das wäre dann nichts anderes als das Core-Repo bei Arch.

Und das wird schon noch kommen, keine Angst ;) Kann zwar noch etwas dauern, aber wie schon gesagt: "Benutze FreeBSD noch mal eine Weile". Ich bin seit 6.x dabei und da war einiges zu tun.
 
Lassen wir uns überraschen. Ich kann da wie gesagt nur von meinen Erfahrungen ausgehen, und da hatte ich mit Linuxen in kürzerer Zeit mehr böse Überraschungen.
 
Das hat aber weniger mit systemd zu tun. Das hat eher was damit zu tun, dass einige Hersteller wichtige EFI-Bereiche mal eben Schreibbar an das OS weitergeben. Auch wenn systemd das jetzt Read-Only mounten sollte, im Standard. Ein Angreifer der Root erlangt könnte dann trotzdem noch ganz einfach deine Hardware schrotten.

Ist also mehr ein Problem von EFI, bzw. das EFI _einiger_ Hersteller.
 
Haben wir eine andere Seite gelesen als du vielleicht?
Den Schreibzugriff erst auf kritischste freizugeben und dann den Vorschlag zu machen, fstab anzuweisen wieder als ro mounten.
Das kann man nur mit einen Satz beschreiben, kaputt ausliefern und hoffen das nix passiert oder der Nutzer das selbst fixt.
 
Das Traurige ist, dass die Hardware in einem solchen Zustand ist, dass man überhaupt Debatten führen kann, wer den größeren Fuckup produziert. Warum _kann_ UEFI überhaupt gebrickt werden, wenn man ein paar Variablen verändert? Dass das OS ggf. nicht mehr bootet, OK, works as designed, das fällt für mich auch nicht unter "bricked". Aber dass das UEFI selber mit den vorgegebenen Interfaces nicht mehr in einen benutzbaren Zustand zu bringen ist? Warum jagen wir diese Volltrottel, die sowas verbrechen, nicht mit den Mistgabeln aus der Stadt?

Ob da andere Volltrottel nicht genug Workaround für den Fuckup der ersten Volltrottel applizieren, geht mir dann ehrlich gesagt am Arsch vorbei. Das ist alles so eine Seuche geworden...
 
Normal denkende Menschen würden jedenfalls solche Optionen deaktivieren und bei Bedarf dem Nutzer überlassen ob sie diese gerade brauchen um kurzzeitig diese zurücksetzen. Lennard weiß es ja besser. Klar gibts viele Möglichkeiten sein System zu zerstören nur sind das wenige die irreparabel sind und die sind bei Default nicht auf geisteskrank geschaltet.
 
Haben wir eine andere Seite gelesen als du vielleicht?
Den Schreibzugriff erst auf kritischste freizugeben und dann den Vorschlag zu machen, fstab anzuweisen wieder als ro mounten.
Das kann man nur mit einen Satz beschreiben, kaputt ausliefern und hoffen das nix passiert oder der Nutzer das selbst fixt.

Ist ja nicht so als wenn das Ganze nur passiert, wenn systemd den Kram mountet. Als Ubuntu bei der Installation diverse Notebooks geschrottet hat, aufgrund desselben Fehlers hat keiner upstart den Kram in die Schuhe geschoben.

Es Bedarf hier kein "Augen zu, als ro mounten und hoffen". Das Problem muss einfach grundlegend angegangen werden.
 
Joahr, Kernel-Entwickler... das EFI meldet "folgende Sachen kannst du bearbeiten". Der Linux-Kernel bindet jede Variable als Datei gemappt ein. Problem ist jetzt: der Mainboard-Hersteller bindet essentielle Variable ein, welche eigentlich nicht gelöscht werden dürfte (nur bearbeitet). Jetzt kommt aber der Nutzer und löscht sie... Tjoahr...

Ich hätte das so auch nicht erwartet und ich vermute die Kernel-Entwickler auch nicht. Ich hätte ja vermutet, dass die Hersteller da zumindest eine Sicherung drin haben, "Variable fehlt->Reset" oder sowas.

Also entweder fixen die Mainboard-Hersteller das, oder der Linux-Kernel gibt keinen Zugriff mehr auf die EFI-Variablen (was er im Großteil der Fälle schon tut, siehe unten).
 
@-Nuke-: Mal wieder was gelernt. *freu*

Interessantes Projekt auf github, danke fuer die erhellenden Informationen, :)

Ich hätte das so auch nicht erwartet und ich vermute die Kernel-Entwickler auch nicht. Ich hätte ja vermutet, dass die Hersteller da zumindest eine Sicherung drin haben, "Variable fehlt->Reset" oder sowas.
Fehlendes Exception-handling... das erklaert einiges.

Also entweder fixen die Mainboard-Hersteller das, oder der Linux-Kernel gibt keinen Zugriff mehr auf die EFI-Variablen (was er im Großteil der Fälle schon tut, siehe unten).

Ich denke Alle drei Beteiligten (HW Vendor, Linux-Kernel Maintainer sowie
S*stemD-dev's) haben hier, meiner Meinung nach, mir ein Totalversagen.
dargeboten (und nebenbei eine gute Show). :D

Obwohl, dass ein Kernel Zugriff auf {U}EFI hat, das ist akzeptabel.

Wiso ist es fuer ein init^H^H^H^H ... aeeh Prozesmangaer (oder was auch
immer dieses eierlegende Chamaelion darstellen soll) unumgaenglich, auf
die Umgebungsvariablen bzw. Environment von {U}EFI Zugriff zu haben???

Was soll das? Lustiges Feature. :D

Wie ich es versucht habe zu verstehen, soll doch S*stemD, unabhaengig
von Abhaengigkeiten (daher vermutlich der Term "Socket-activation" und
Aehnliches, um "Race Conditions" u. A. zu umsegeln... oder so aehnlich),
Prozesse fork()en und den Life-cycle von Prozess zu ueberwachen und
verwalten?
 
Wie ich schon sagte (und der Autor von efivars) hat das Ganze wenig mit systemd zu tun. Das einzige was systemd im Standard macht ist efivars zu mounten, da diverse Programme Zugriff auf die EFI-Variablen brauchen (nächsten Boot einstellen, Bootmanager-Config etc.). Das war's auch schon.

systemd selbst macht hier nichts kaputt. Und den Kram ReadOnly mounten löst halt echt das Problem nicht.
 
Bei naeherer Betrachtung...

systemd selbst macht hier nichts kaputt.

... stimmt! :D

Kritikwuerdig ist, dass der Kernel die Variablen als rw in den Userspace mmap()d
bzw. dass die Moeglichkeit existiert, das Prozesse _direkt_ auf {U}EFI Environment
einen _direkten_ rw Zugriff haben bzw. dass keine Discretionary oder Mandatory
Access Control auf {U}EFI-Umgebungsvariablen, seitens des Kernels (meiner
Meinung) nach nicht existiert.

Sei's drumm, ich verliere mich selbst in zu viele Details und fange langsam an,
als Blinder mich ueber Farben aufzuregen. Lustiges Thema, das mit {U}EFI. :)
 
Sehr schön ist auch das hier: http://www.postgresql.org/message-i...mEfMphieT57X4KqZv-RhWxzEpu1fJQ@mail.gmail.com Wenn PostgreSQL durch einen Nicht-System-User gestartet wurde, löscht systemd ihm beim Logout des User die Semaphoren unter dem Hintern weg. Auch das mag unter den von systemd getroffenen Annahmen korrekt sein, es erscheint aber schon sehr bedenklich.

Danke an douple-p für das Schmeißen des Links in ##bsdforen.de.
 
Also in dem Fall der EFI Variablen würde ich die Schuld ausnahmsweise mal nicht bei systemd sehen. Die betroffene EFI Implementierung ist broken und braucht einen Workaround um sich nicht zu bricken. Die EFI Variablen zu ändern oder auch einige zu löschen ist z.B. fürs Einrichten von Bootloadern nötig. Was mich wirklich interessieren würde ist ob die EFI Spezifikation dieses bescheuerte Verhalten erlaubt, es gar nahe legt oder "nur" die Implementierung von Vollidioten auf Minimalkurs verbrochen wurde.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben