scientific hat geschrieben:07.09.2017 13:30:05Warum eigentlich will man udev nicht?
Weil es Dinge vereinfacht? Weil Mounten und Plug'n Play möglich und komfortabel wird?
Manchmal ist das eben das kleinere Übel...scientific hat geschrieben:07.09.2017 18:23:31Aber irgendwie erinnert mich das, wenn sich jemand den Arm abschneidet, und sich dann beschwert, dass mit der Prothese irgendwie nix mehr so recht funktioniert...
Aber warum so viele schon lang vor systemd udev ablehnten, würd ich schon gern wissen wollen... Obwohl... Ist auch so sinnvoll wie - siehe Prothesenvergleich.
https://de.wikipedia.org/wiki/Aron_Ralston
https://de.wikipedia.org/wiki/Nekrektomie
Aber wer beschwert sich hier, dass etwas nicht mehr funktioniert? Na klar geht Plug'n Play nicht mehr, aber wer braucht das wirklich? Ich habe eine einzige Anwendung, bei der gelegentlich Tastatur und Maus ein- und ausgesteckt werden. Da läuft dann ausnahmsweise ein udev. Ich habe lange versucht, den auf diese Hot-Plug-Funktion abzuspecken, er hat trotzdem noch fest eingebaute unnütze Funktionen. Wenigstens bringt er das Netzwerk nicht mehr durcheinander.
Bei mir hat udev vom Start weg verschi keine Chance gehabt, weil die Netzwerk-Interfaces immer wieder andere Namen bekommen haben, jetzt mit stretch gibt es schon wieder ein neues Schema[1]. Und das ist der zweite grobe Fehler: man hat keine Chance, udev an seine Bedürfnisse anzupassen, weil ungefähr mit jeder Version etwas geändert wird (geändert, nicht nur erweitert). Natürlich ist damit die Dokumentation auch oft veraltet.
udev war ca. der dritte Versuch, von statischen /dev-Dateisystem weg zu kommen (der vierte hat dann geklappt). Das war gut gemeint und teilweise wohl auch ein Fortschritt - bis auf die Kleinigkeit, dass es vom Prinzip her nicht funktionieren konnte. Es gibt immer Zeitfenster, in dem Kernel und udev unterschiedlicher Meinung zum Systemzustand sind. Das dauert etwas länger, wenn udev noch nicht läuft. Dann kommt nur die Meldung "Waiting for /dev to be fully populated", naja. Wenn udev nicht (mehr) läuft, wird es lustiger. Das ist auch mit stretch und systemd-udevd nicht besser geworden.
Das ist deshalb tragisch, weil es seit[2] Kernel 2.6.32(!) mit devtmpfs eine wirklich funktionierende Lösung gibt und die halbe Daseinsberechtigung für udev deshalb entfallen ist.
Für die andere Hälfte, Hot Plug, gab es schon vor udev eine Lösung, die nur nicht gut skalierte (/sbin/hotplug). Dank devtmpfs müssten aber viel weniger Ereignisse bearbeitet werden. Für die restlichen könnte man jetzt auch wieder die alte Technik verwenden. Natürlich könnte man auch udev leicht modifizieren, dass es per Default nichts macht und nur als Filter zwischen der netlink-Schnittstelle und benutzer-definierten Scripten arbeitet. Naja, man darf ja noch träumen...
[1] https://www.debian.org/releases/stretch ... face-names
[2] https://www.heise.de/ct/artikel/Die-Neu ... 70416.html