Warum ich udev nicht will

[cosmac]

Dies ist nur der Versuch einer Antwort auf eine Frage aus einem anderen Thread, der auch nicht von systemd handelt. Ich sehe keinen Zusammenhang zwischen udev und systemd, außer, dass systemd evt. auf udev angewiesen ist. Es sind einfach zwei Programme, für die es technisch bessere Alternativen gibt, wie z.B. für minicom. Das kommt mir dank picocom auch nicht auf die Platte. Wenn ein Moderator meint, wir brauchen nicht noch so einen Thread, ist das auch o.k.

Warum eigentlich will man udev nicht?
Weil es Dinge vereinfacht? Weil Mounten und Plug'n Play möglich und komfortabel wird?

Aber 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.

Manchmal ist das eben das kleinere Übel...
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

[scientific]

Gleich eine Frage vorweg:
Laptop oder Standrechner?

Ich hab einen Laptop, und ich bin doch ab und zu einmal damit unterwegs. Beamer einstecken, Beamer ausstecken. Drucker, Scanner rein und raus.
Ich habe ein Backupskript, welches auf udev aufsetzt und bei Einstecken der Platte automount-Punkte aktiviert und das Skript automatisch startet. Das ist benutzerfreundlich... so muss ich meiner Schwiegermutter nur sagen: "Steck die Platte einmal die Woche ein, und warte, bis das rote Icon oben im Panel wieder weiß ist, dann kannst du die Platte wieder austecken"...

Die Geschichte ist so ähnlich wie mit dem Network-Manager. Am Stand-PC oder am Laptop, der bloß daheim am LAN-Kabel hängt, benötige ich keinerlei Network-Manager. Aber wenn ich mal per LAN, mal per WLAN in unterschiedlichsten Netzen bin (Daheim, Firma, Zug, Internetcafe), mal per USB oder BT-Tethering übers Smartphone ins Netz gehe, dann benötige ich einen Networkmanager - was bei mir z.B. der Fall ist. Und wenn ich meiner Bekannten Linux auf den Laptop installiere, die zwar Surfen und Briefe schreiben kann, aber ansonsten nicht viel mit Computern zu tun haben will, dann soll ich auch im Urlaub den Surf-Stick einstecken oder sich mit dem Hotel-WLAN verbinden können, und bloß PIN oder PSK eingeben müssen und schon kann sie lossurfen... ohne eine Konfigdatei als root bearbeiten zu müssen (Ich hab ihr den Rechner so eingerichtet, dass sie in Gnome-Software Programme als User installieren, aber nix deinstallieren kann... damit sie einfach nix kaputt machen kann)

Ich war damals verwirrt, als /dev/hda1 plötzlich /dev/sda1 hieß... nun heißt wlan0 halt wlo1 und eth0 enps01 oder so. Und wenn ich von jessie auf stretch update, heißt eth0 immer noch eth0.
Ich hab bei meinem alten Laptop ein neues Mainboard bekommen, weil die Graphikkarte einen Produktionsfehler hatte. Damit war die Ethernetschnittstelle auch neu und hieß nicht mehr eth0 sondern eth1. Ja, da lief das Netzwerk nicht mehr... Dann erfuhr ich von der udev-Regel persistent-net.rules und änderte dort eth1 auf eth0 und löschte den ursprünglichen eth0-Eintrag... daraufhin hieß weitere 6 Jahre die erste und einzige Ethernet-Schnittstelle eth0... und wäre er nicht eingegangen, hieß die jetzt mit stretch immer noch eth0...

Dass USB-Sticks beim Booten bei mir vor der internen HD/SSD entdeckt werden und /dev/sda benannt werden ist blöd. Skripte die auf /dev/sda aufbauen und damit die interne Platte meinen sind halt so zum Scheitern verurteilt. Deshalb gibts ja auch die UUID. Über die sich manche ja auch beschweren... "wer braucht denn sowas?"

Ich seh es so:
Am besten kaufe ich mir eine Kombizange. Damit kann ich etwas halten, Nägel ausziehen, Draht abzwicken, Schrauben öffnen, Glas zurechtbrechen, Nägel einschlagen usw. Ein geniales Allzweckgerät. Reicht für die meisten Haushalte und die handwerklichen Fähigkeiten der meisten Familienmitglieder vollkommen als einziges Werkzeug aus...

Komischerweise haben irgendwelche antikonservativen Handwerksteufel Seitenschneider, Hammer, Nagelauszieher, Flachzange, Rundzange, Glasschneider, Fliesenschneider, Schraubendreher usw. und das alles auch noch in verschiedensten Größen und Formen erfunden, wo es doch eine Kombizange alleine auch täte.
Eine /etc/interfaces reicht auch. Und dann kam WLAN. Damit kam wpa_supplicant. Und dennoch wurde connman, wicd, network-manager usw. erfunden und entwickelt... Warum bloß? connman kann p2p, networkmanager nicht. connman ist in Gnome nicht integriert, nm schon. Connman führt ein Schattendasein, NM nicht. Jetzt kann man natürlich behaupten, NM ist VIEL zu Mainstream, und das will ich nicht sein... Wenn ich etwas nutze, das einfach gut funktioniert und gut integriert ist, ist es doch würdig und recht.

Ich war lange Zeit voll stolz, einen total schlanken FVWM zu nutzen. Ein paar Dinge von FVWM vermisse ich immer noch... aber ich bin bei Gnome gelandet, weil mich das Konzept von Gnome überzeugt hat. Bin ich jetzt bubuh, weil ich einen Mainstream-Desktop nutze?
Ich wiederhole mich gerne. systemd mag seine Macken haben. Momentan mit der bash-completion... Und systemd tat am Anfang oft nicht, was ich wollte... bis ich verstanden habe, wie der funktioniert. Seitdem kan ich ihn bedienen, und systemd tut für mich, was ich will, und nicht umgekehrt. Pöttering mag ein Rüpel mit großem Ego sein... das ist Torwalds auch, was man so hört... na und? Beide haben großartiges geschaffen.

Zurück zum Thema... udev... Wenn ich nicht weiß, wie man Regeln für udev schreibt, ist es ein ziemlich ungutes und undurchschaubares Monster... Wenn man die Regeln zu schreiben weiß, wird er plötzlich zahm. Dann weiß man auch um die Fähigkeiten und Grenzen. So wie bei systemd.

Aber es ist halt Mainstream, und man kann nicht mehr im Linux-Minderheiten-Cafe damit prahlen, dass man im Desktop-Minderheitenprogramm noch einmal im Minderheitenprogramm der systemd-udev-networkmanager-Verweigerer ist und den total coolen Dingsbums verwendet, weil der voll super ist und die Wäsche weißer als weiß wäscht. Die paar Farbkleckse werden sicher auch noch ausgebessert, die Dingsbums unerwünschterweise zurücklässt. Dann einmal. Sicher irgendwann. Und wenn die Kombizange unschöne Kratzer an der Zierschraube beim Zudrehen hinterlässt, dann ist die Schraube schuld, oder man benötigt sie doch gar nicht, weil echte Männer verwenden keine Zierschrauben...

Ach was... ich glaube, dieser Thread ist unnötig wie ein Kropf.

Warum sich Betamax und Video2000 nicht gegen das viel schlechtere VHS durchgesetzt haben??? Pornos. Die ersten Pornos in Massen gabs auf VHS. Und dann starben Betamax und Video2000.
Warum sich systemd gegenüber initv, upstart usw. durchgesetzt hat? Er funktioniert schlüssig, kann wahnsinnig viel und vor allem... systemd wurde innerhalb kürzester Zeit von fast allen großen und kleinen Distris eingesetzt... und schon ist er da.
Warum sich hal nicht durchgesetzt hat? Weil udev einfacher zu konfigurieren ist.
Warum sich devtempfs nicht durchgesetzt hat? Weil udev jetzt da ist.

Manchmal ist es echt so einfach. Und die Realität kann man im kleinen für sich verändern... aber dann muss man sich halt auch damit abfinden, dass manches einfach nicht mehr so oder so gut funktioniert wie "früher"... Weil der Zahn der Zeit daran nagte.

Eines kannst du dir merken, weil du angemerkt hast, dass sich bei udev mit jedem Upgrade irgendwas ändert, und dass immer irgendwas nicht mehr so ist, wie es vorher war...
Das einzige was bleibt wie es ist, ist die Veränderung.
Je mehr du von den Hauptentwicklungen abweichst, desto mehr Fehlfunktionen und Eigenentwicklung musst du in Kauf nehmen. Wenns das Hobby ist... ok. Dann ist Jammern aber einfach nicht angebracht.

Meine Meinung.

scientific

[DeletedUserReAsG]

Ob der Threadtitel noch geändert werden könnte? „Man“ impliziert ja auch mich – aber ich mag udev. Hab noch keine andere brauchbare Lösung gefunden, mit der ich beim Anstecken spezifischer Hardware entsprechende Funktionen anschubsen kann (z.B. „Backupplatte einstecken → Backup wird selbsttätig gestartet“), dafür kann ich aber für mich keine Nachteile von udev entdecken. Ich möchte also nicht, dass sich jemand hinstellt und mir erzählt, warum ich udev nicht wollen würde.

[TuxPeter]

Hi,

ob ich udev mag oder will, das weiß ich genauso wenig wie bei systemd. Aber zumindest weiß ich nach dem gut zu lesenden Beitrag von scientific (danke dafür) einigermaßen, was es tut und habe mir "mal udev-rules angucken" auf einen Zettel geschrieben. Ich finde es allerdings klasse, wenn das System einfach so funktioniert wie es soll und es mich nicht bei den Sachen stört, die ich mit dem Computer machen will.

Zwar habe ich den starken Eindruck, dass vieles in der Software- und Hardwaretechnologie, ja in der gesamten Technosphäre in Richtung sinnloser Komplexitätssteigerung sich entwickelt, einer Verkomplizierung, die keinen wirklich für Menschen brauchbaren Nutzeffekt mit sich bringt. Aber nun ausgerechnet Linux bzw. Debian dafür zu schelten, dass es maßvoll an dieser Entwicklung teilnimmt, das muss nicht sein.

Und gehen wir doch mal zum Arzt, einem Zahnarzt vielleicht: Wer möchte da, neben dem jeweiligen handwerklichen Können des Maestro in Weiß auch noch der Medizintechnik von vor 30, 40 oder gar 50 Jahren ausgesetzt sein?

[cosmac]

Ob der Threadtitel noch geändert werden könnte? „Man“ impliziert ja auch mich – aber ich mag udev.

Natürlich, das war nicht so gemeint. Ich hab' einfach die Frage von scientific übernommen.

(...) dafür kann ich aber für mich keine Nachteile von udev entdecken

naja, ich schon. Wer mein Netzwerk sabotiert, fliegt raus. Das war der Anlass und ist der entscheidende Grund.

[owl102]

Pöttering mag ein Rüpel mit großem Ego sein... das ist Torwalds auch, was man so hört...

Hat schon mal jemand in /drivers/base/devtmpfs.c reingeschaut?

Code: Alles auswählen

/*
 * devtmpfs - kernel-maintained tmpfs-based /dev
 *
 * Copyright (C) 2009, Kay Sievers <kay.sievers@vrfy.org>

Also von Mr. Primadonna persönlich! Also nein danke, devtmpfs ist für mich gestorben, dann doch lieber udev. Moment, da war doch was?

udev Entwickler: Greg Kroah-Hartman, Kay Sievers, Dan Stekloff u. v. a

Pöttering und Sievers, sie sind überall, die feindliche Übernahme von Linux durch Red Hat ist nicht mehr zu verhindern.

Ich wechsele zu BSD. Oder Atari ST. Mal schauen.

[scientific]

Naja... Sabotieren setzt Bösartigkeit voraus. Weiterentwicklung ist keine Bösartigkeit.
Die neue Benennung soll - so hab ichs vetstanden - genau das in Zukunft vermeiden, dass beim Tausch der Netzwerkkarte das Ethernetmodul anders heißt wie zuvor das einzige (eth0 vs. eth1)

Wenn man das weiß - und das war WIMRE in den Releasenotes - gi ts keine Sabotage, sondern sinnvolle Veränderung. Und diese Umbenennung im Bereich Netzwerm ist in den 12 Jahren, seit ich Linux nutze, die einzige gewesen.
Der Typ, von dem ich Linux "lernte", ist ein leichter Asperger, der mit Veränderungen nicht gut klar kommt. Der hat mir damals schon von eth0 erzählt. Und dass fvwm1 der einzig wahre fvwm wäre, und fvwm2 viel zu modern... Also gehe ich davon aus, dass eth0 immer schon so hieß, und jetzt einmalig eine Veränderung erfahren hat... So what!

Damit hat nicht udev dein Netzwerk sabotiert, sondern deine Unwissenheit und die fehlende Bereitschaft, auf Veränderungen regieren zu wollen.

Btw... Wenn dein Device eth0 hieß, blieb das beim Upgrade von udev auch so. Wenns anders war, hast du wohl vorher irgendwas manuell verändert. Dann liegt die "Schuld" wiederum nicht bei udev... Sondern am PEBKAC.

Lg scientific

[pferdefreund]

Pöttering mag ein Rüpel mit großem Ego sein... das ist Torwalds auch, was man so hört...

Hat schon mal jemand in /drivers/base/devtmpfs.c reingeschaut?

Code: Alles auswählen

/*
 * devtmpfs - kernel-maintained tmpfs-based /dev
 *
 * Copyright (C) 2009, Kay Sievers <kay.sievers@vrfy.org>

Also von Mr. Primadonna persönlich! Also nein danke, devtmpfs ist für mich gestorben, dann doch lieber udev. Moment, da war doch was?

udev Entwickler: Greg Kroah-Hartman, Kay Sievers, Dan Stekloff u. v. a

Pöttering und Sievers, sie sind überall, die feindliche Übernahme von Linux durch Red Hat ist nicht mehr zu verhindern.

Ich wechsele zu BSD. Oder Atari ST. Mal schauen.

Linux bietet sich doch weiterhin an um ein wirklich funktionales BS zu betreiben. MVS 3.8 unter Hercules ist der Burner - grins.

[cosmac]

Gleich eine Frage vorweg:
Laptop oder Standrechner?

Privat Laptop und Desktop, in der Firma Desktop, ein File- und Intranet-Server, Prüfgeräte, Visualisierungs- und Headless-Rechner.

Die Geschichte ist so ähnlich wie mit dem Network-Manager. Am Stand-PC oder am Laptop, der bloß daheim am LAN-Kabel hängt, benötige ich keinerlei Network-Manager. Aber wenn ich mal per LAN, mal per WLAN in unterschiedlichsten Netzen bin (Daheim, Firma, Zug, Internetcafe), mal per USB oder BT-Tethering übers Smartphone ins Netz gehe, dann benötige ich einen Networkmanager - was bei mir z.B. der Fall ist.

Bei mir auch, wozu habe ich einen Laptop? Aber den meist-installierten Networkmanager kenne ich nur aus Problem-Threads im Forum Was könnte der mehr als iwconfig und wpa_supplicant? Trau' keiner Automatik, die du nicht selbst programmiert hast.

Und wenn ich meiner Bekannten Linux auf den Laptop installiere, die zwar Surfen und Briefe schreiben kann, aber ansonsten nicht viel mit Computern zu tun haben will, dann soll ich auch im Urlaub den Surf-Stick einstecken oder sich mit dem Hotel-WLAN verbinden können, und bloß PIN oder PSK eingeben müssen und schon kann sie lossurfen...

In so einem Fall habe ich tatsächlich einmal Ubuntu installiert und die zweite Kandidatin ist jetzt ein Apple-Fan

nun heißt wlan0 halt wlo1 und eth0 enps01 oder so. Und wenn ich von jessie auf stretch update, heißt eth0 immer noch eth0.

eben, "oder so". Und wenn du stretch frisch installierst, heisst es wieder anders, obwohl sich Kernel-seitig nichts geändert hat.

Ich hab bei meinem alten Laptop ein neues Mainboard bekommen, weil die Graphikkarte einen Produktionsfehler hatte. Damit war die Ethernetschnittstelle auch neu und hieß nicht mehr eth0 sondern eth1. Ja, da lief das Netzwerk nicht mehr...

Genau in dem Fall war das Umbenennen doch absolut falsch. Ich gebe zu, dass es Anwendungen geben könnte, wo es einen Vorteil bringt, aber ich kenne keine.

Dass USB-Sticks beim Booten bei mir vor der internen HD/SSD entdeckt werden und /dev/sda benannt werden ist blöd. Skripte die auf /dev/sda aufbauen und damit die interne Platte meinen sind halt so zum Scheitern verurteilt. Deshalb gibts ja auch die UUID. Über die sich manche ja auch beschweren... "wer braucht denn sowas?"

Naja, für die Distributions-Installer sind die UUID schon praktisch, für den Benutzer gibt es LABEL.

Am besten kaufe ich mir eine Kombizange. Damit kann ich etwas halten, Nägel ausziehen, Draht abzwicken, Schrauben öffnen, Glas zurechtbrechen, Nägel einschlagen usw. Ein geniales Allzweckgerät. Reicht für die meisten Haushalte und die handwerklichen Fähigkeiten der meisten Familienmitglieder vollkommen als einziges Werkzeug aus...

Ist das einzige Werkzeug, was man kennt, ein Knüppel, sehen alle Probleme aus wie Robbenbabys.

Wenn ich etwas nutze, das einfach gut funktioniert und gut integriert ist, ist es doch würdig und recht.

Absolut richtig. Nur leider ist udev eher das Gegenteil von einfach und funktioniert nur meistens.

Ich wiederhole mich gerne. systemd mag seine Macken haben. Momentan mit der bash-completion... Und systemd tat am Anfang oft nicht, was ich wollte... bis ich verstanden habe, wie der funktioniert.

systemd ist aber eine ganz andere Baustelle als udev, ich sehe da keinen Zusammenhang.

Wenn ich nicht weiß, wie man Regeln für udev schreibt, ist es ein ziemlich ungutes und undurchschaubares Monster... Wenn man die Regeln zu schreiben weiß, wird er plötzlich zahm.

Nein, weil manche Funktionen fest eingebaut sind.

Aber es ist halt Mainstream, und man kann nicht mehr im Linux-Minderheiten-Cafe damit prahlen, dass man im Desktop-Minderheitenprogramm noch einmal im Minderheitenprogramm der systemd-udev-networkmanager-Verweigerer ist und den total coolen Dingsbums verwendet, weil der voll super ist und die Wäsche weißer als weiß wäscht. Die paar Farbkleckse werden sicher auch noch ausgebessert, die Dingsbums unerwünschterweise zurücklässt. Dann einmal. Sicher irgendwann.

Oder niemals, weil sie das kleinere Übel sind... Aber Mainstream-Verweigerer dürften aber erst recht kein Linux benutzen, und ich arbeite in einer Firma, die VMS und SunOS durch Linux ersetzt hat

Warum sich devtempfs nicht durchgesetzt hat? Weil udev jetzt da ist.

devtmpfs wurde eingeführt, weil udev nicht so gut funktioniert hat. Und ich bin fast sicher, dass udev heute auf devtmpfs angewiesen ist.

Und die Realität kann man im kleinen für sich verändern... aber dann muss man sich halt auch damit abfinden, dass manches einfach nicht mehr so oder so gut funktioniert wie "früher"... Weil der Zahn der Zeit daran nagte.

Wer jammert denn, dass es ohne udev schlecht funktioniert? Meine selbst gebastelten udev-Ersatz-Teile sind zwangsläufig neuer als udev

[owl102]

Die neue Benennung

Ich finde es etwas putzig, dieses Feature als "neu" zu lesen, obwohl es ja für die Debian-Welt erst mit Stretch als default bei Neuinstallationen eingeführt wurde.

Die "neue Benennung" ist recht alt und wurde zum Beispiel schon vor über 6 Jahren(!) in Fedora eingeführt: https://fedoraproject.org/wiki/Features ... viceNaming

Kurzum: Es ist keine "neue" Bennennung. Es ist eine Benennung, die sich bereits in jahrelanger Praxis bewährt hat, und die Debian deswegen jetzt als default übernommen hat.

[BenutzerGa4gooPh]

Pöttering und Sievers, sie sind überall, die feindliche Übernahme von Linux durch Red Hat ist nicht mehr zu verhindern.
...
Ich wechsele zu BSD. Oder Atari ST. Mal schauen.

Wenn der Atari nicht wäre, hätte ich es ernst genommen: _BSD könnte für eine gewisse Konstanz und KISS-Prinzip stehen, welches man nur bei Notwendigkeit und nicht wegen Mainstream-Bequemlichkeit brechen sollte. Vorrangig sichere, stabile und von vielen (!) Entwicklern verifizier- und wartbare Funktionalitäten bzw. deren Code. Oder eben deren/dessen Sicherheitslücken.
Nutzerunfreundlichkeit allerdings schafft vermeidbare Sicherheitslücken durch Konfigurationsfehler. Spagat?

https://www.openbsd.org/faq/pf/filter.html
Leichte Kost.

Edit:
Um mal schnell aber dauerhaft einen iperf/iperf3-Server zu starten, gibt es mit systemd glücklicherweise (noch) 2 Möglichkeiten. Vielleicht fehlt für allgemeine Akzeptanz einfach die Nutzerfreundlichkeit?!

Goldene Kälber und andere Götzen haben sich bislang nicht bewährt ... austauschbar, modernisierbar.

Rechtschreibung korrigiert.

[cosmac]

Zwar habe ich den starken Eindruck, dass vieles in der Software- und Hardwaretechnologie, ja in der gesamten Technosphäre in Richtung sinnloser Komplexitätssteigerung sich entwickelt, einer Verkomplizierung, die keinen wirklich für Menschen brauchbaren Nutzeffekt mit sich bringt. Aber nun ausgerechnet Linux bzw. Debian dafür zu schelten, dass es maßvoll an dieser Entwicklung teilnimmt, das muss nicht sein.

Ich schelte weder Linux noch Debian, im Gegenteil, ich finde es sehr gut, was Debian bietet. Natürlich gibt es einzelne Programme, die ich nicht gebrauchen kann.

Und gehen wir doch mal zum Arzt, einem Zahnarzt vielleicht: Wer möchte da, neben dem jeweiligen handwerklichen Können des Maestro in Weiß auch noch der Medizintechnik von vor 30, 40 oder gar 50 Jahren ausgesetzt sein?

Es geht hier auch garnicht um alt oder neu, sondern darum, dass udev etwas macht, was der Kernel schon lange, und immer noch, besser kann.

Die neue Benennung soll - so hab ichs vetstanden - genau das in Zukunft vermeiden, dass beim Tausch der Netzwerkkarte das Ethernetmodul anders heißt wie zuvor das einzige (eth0 vs. eth1)

Das Problem, das man da vermeiden will, gibt es ohne udev garnicht. Der Kernel nennt das Interface schon immer und immer noch eth0. Es ist nicht der erste Versuch, diese udev-Funktion benutzerfreundlich zu machen. Die vernünftige Lösung wäre, sie nur in den wenigen Spezialanwendungen zu aktivieren.

Und diese Umbenennung im Bereich Netzwerm ist in den 12 Jahren, seit ich Linux nutze, die einzige gewesen. (...) Also gehe ich davon aus, dass eth0 immer schon so hieß, und jetzt einmalig eine Veränderung erfahren hat...

Naja, früher hat udev "nur" eth0 in eth1 oder eth2 umbenannt...

Btw... Wenn dein Device eth0 hieß, blieb das beim Upgrade von udev auch so. Wenns anders war, hast du wohl vorher irgendwas manuell verändert. Dann liegt die "Schuld" wiederum nicht bei udev... Sondern am PEBKAC.

Ja, ich hab' etwas verändert, ethx heißt hier immer so, wie der Kernel es nennt. Seit es udev gibt, hat es bei jeder neuen Debian-Version eine Chance bekommen und wurde anschließend deinstalliert oder wenigstens nicht mehr gestartet. Aber PEBKAC stimmt natürlich, ich könnte ja auch udev laufen lassen und die Probleme irgendwie anders umgehen.

[smutbert]

Für mich stellt sich die Sache eigentlich so dar, dass es vor allem vor udev das Problem gegeben hat, dass die Namen der Netzwerkinterfaces von der Reihenfolge des Ladens der Treiber und damit zum Teil vom Zufall abhängig waren. Bei udev hat Debian im nächsten Schritt mit einer simplen udev-Regel dafür gesorgt, dass die Netzwerkschnittstellen anhand ihrer MAC identifziert werden und immer dieselben Namen erhalten (aber immer noch eth0, eth1,...).

Das jetzige Benennungsschema mit anderen aber ebenfalls gleichbleibenden Namen (wlp5s0, eno1,...) konnte man meines Wissens auch schon vor stretch mit der Kerneloption net.ifnames=1 verwenden.

Nervig war meiner Auffassung nach in erster Linie das Verhalten vor udev mit den zufällig vergebenen Namen... aber mit den Blockgeräten und dem Soundsystem gab und gibt es ja ganz ähnliche Schwierigkeiten, nur kann man denen leichter aus dem Weg gehen, indem man einfach die UUIDs/Dateisystemlabel und Namen der Soundkarten verwendet.


Bevor udev aufgekommen ist, habe ich ja gehofft, dass sich devfs (nicht zu verwechseln mit devtmpfs!) durchsetzt - das hatte ich nämlich zu Zeiten zu denen ich mir noch selbst einen Kernel kompiliert habe, gerne verwendet und das hat afair auch ganz ordentlich funktioniert, aber mir wäre Firewire auch lieber gewesen als USB - man kann sich eben nicht alles aussuchen.

[cosmac]

Für mich stellt sich die Sache eigentlich so dar, dass es vor allem vor udev das Problem gegeben hat, dass die Namen der Netzwerkinterfaces von der Reihenfolge des Ladens der Treiber und damit zum Teil vom Zufall abhängig waren.

Das ist in der Tat lästig, aber man kann ja die Lade-Reihenfolge von Hand festlegen. Mit fest eingebauten Treibern bekommt man u.U. echten Hardware-Zufall, leider nur 1 bis 2 Bit

Bei udev hat Debian im nächsten Schritt mit einer simplen udev-Regel dafür gesorgt, dass die Netzwerkschnittstellen anhand ihrer MAC identifziert werden und immer dieselben Namen erhalten (aber immer noch eth0, eth1,...).

Außer, die Hardware ändert sich. Dann vergibt udev einen zufälligen Namen. Mit ifrename vergibt der Benutzer den Namen und ist selber Schuld, wenn dann eth0 und eth1 vertauscht sind.

[DeletedUserReAsG]

Wenn sich die Hardware ändert, woher sollte udev, oder auch der Kernel, oder sonst ein Mechanismus, denn wissen, was der User in welcher Reihenfolge haben will? Natürlich muss der User sich drum kümmern, wenn er einen bestimmten Namen für ein bestimmtes Interface haben will – und das ist dank udev seit einigen Jahren ziemlich einfach. Wenn er’s dann trotzdem vertauscht, ist er auch selbst schuld. Also der User, jetzt.

[Colttt]

Außer, die Hardware ändert sich. Dann vergibt udev einen zufälligen Namen. Mit ifrename [...]

Das stimmt so nicht ganz wenn du vorher eth0 und eth1 hattest jetzt die hardware tauschst, also sagen wir eth0 dann wird das nächste device eth2 heissen und jeder der was anderes behauptet möchte ich ein beweis sehen und zwar mit oldstable und nicht angefasster udev-config


@cosamac so richtig erkennen konnte ich bis jetzt aber nich nicht was dich an udev wirklich stört mit handfesten beweisen/Beispielen.

[cosmac]

Außer, die Hardware ändert sich. Dann vergibt udev einen zufälligen Namen. Mit ifrename [...]

Das stimmt so nicht ganz wenn du vorher eth0 und eth1 hattest jetzt die hardware tauschst, also sagen wir eth0 dann wird das nächste device eth2 heissen

Außer, man erlebt das zum ersten Mal und steckt eine weitere neue Interface-Karte rein (die erste war ja offensichtlich auch defekt). Also, für jemanden, der den Trick nicht kennt, ist das praktisch zufällig.

@cosamac so richtig erkennen konnte ich bis jetzt aber nich nicht was dich an udev wirklich stört mit handfesten beweisen/Beispielen.

* diese eth-Umbenennung war der Auslöser und reicht mir völlig. Sowas darf nicht per Default eingeschaltet sein.
* einzelne Funktionen sind fest einprogrammiert und lassen sich nicht per udev-Regel ändern.
* "Synthesizing the initial hotplug events" dauert sehr lange.
* es ist auch eine Kosten/Nutzen-Frage. Ich brauche udev ganz einfach nicht. Alles, was ich benutze, funktioniert auch ohne. Die einzige Funktion, die ich mal genutzt habe, ist Hot Plug für die Tastatur. Aber auch dafür habe ich inzwischen zwei andere Lösungen. Steckt eigentlich noch irgendwer seine Tastatur im Betrieb ein- und aus?

Vielleicht ist manches davon heute nicht mehr so schlimm, seit ein paar Debian-Versionen läuft udev hier nur beim allerersten Start nach der Installation.

[detix]

und du bist dir ganz sicher das so eine Benennung der Netzwerkinterfaces an udev und nicht vielleicht an der automatisch erstellten /boot/initrd.img... liegt?

[scientific]

Außer, die Hardware ändert sich. Dann vergibt udev einen zufälligen Namen. Mit ifrename [...]

Das stimmt so nicht ganz wenn du vorher eth0 und eth1 hattest jetzt die hardware tauschst, also sagen wir eth0 dann wird das nächste device eth2 heissen

Außer, man erlebt das zum ersten Mal und steckt eine weitere neue Interface-Karte rein (die erste war ja offensichtlich auch defekt). Also, für jemanden, der den Trick nicht kennt, ist das praktisch zufällig.

@cosamac so richtig erkennen konnte ich bis jetzt aber nich nicht was dich an udev wirklich stört mit handfesten beweisen/Beispielen.

* diese eth-Umbenennung war der Auslöser und reicht mir völlig. Sowas darf nicht per Default eingeschaltet sein.

Also es ist eine Änderung, die du nicht mitbekommen hast, und die dich am falschen Fuß erwischte. Jetzt bist du auf udev böse.

* einzelne Funktionen sind fest einprogrammiert und lassen sich nicht per udev-Regel ändern.

Welche? Und warum stören die?

* "Synthesizing the initial hotplug events" dauert sehr lange.

Bist du diesem Problem schon einmal nachgegangen?
Wie lange ist "sehr lange"?

* es ist auch eine Kosten/Nutzen-Frage. Ich brauche udev ganz einfach nicht. Alles, was ich benutze, funktioniert auch ohne. Die einzige Funktion, die ich mal genutzt habe, ist Hot Plug für die Tastatur. Aber auch dafür habe ich inzwischen zwei andere Lösungen. Steckt eigentlich noch irgendwer seine Tastatur im Betrieb ein- und aus?

Es ist nicht nur die Tastatur. Es sind Drucker, mobile Internet-Sticks, USB-Speichersticks, externe Festplatten, USB-Mäuse, Funkmäuse, Lautsprecher, Dockingstations usw. usf. und ja, auch ab und zu mal eine Tastatur zum Testen, ob die noch funktioniert...
Udev auf Tastatur und Netzwerkgeräte zu reduzieren ist ein wenig gar einfach.

Vielleicht ist manches davon heute nicht mehr so schlimm, seit ein paar Debian-Versionen läuft udev hier nur beim allerersten Start nach der Installation.

Schön für dich, dass du eine für dich funktionierende Lösung gefunden hast. Ich für meinen Teil finde udev gut funktional. Es tut genau, was ich will. Mittels udev-Regeln starte ich für verschiedene externe Platten verschiedene Backup-Aufrufe. Ansonsten ist es unauffällig. Mir persönlich sind Animositäten von Softwareentwicklern wie Pöttering, Sievers oder Torvalds ziemlich schnuppe. Und Neues... ja, manchmal find ichs blöd, manchmal nicht. Wenn ich muss, teste ich es und lerne damit umzugehen, wenn ich nicht muss, mach ich's auch manchmal so.

lg scientific

[cosmac]

und du bist dir ganz sicher das so eine Benennung der Netzwerkinterfaces an udev und nicht vielleicht an der automatisch erstellten /boot/initrd.img... liegt?

ziemlich sicher, weil die initrd garnicht benutzt wird. Und wenn ich dann udev laufen lasse:

Code: Alles auswählen

$ uname -a
Linux kuemmel 4.12.0-dt4 #2 SMP Wed Jul 19 12:23:07 CEST 2017 i686 GNU/Linux
$ zgrep INITRD /proc/config.gz
# CONFIG_BLK_DEV_INITRD is not set
$ ps -f -C systemd-udevd
UID        PID  PPID  C STIME TTY          TIME CMD
root       239     1  0 13:16 ?        00:00:00 /lib/systemd/systemd-udevd --daemon
$ grep eth0 /var/log/syslog
Sep 11 13:16:49 kuemmel kernel: [    4.663876] r8169 0000:01:00.0 eth0: RTL8168g/8111g at 0xf815a000, 90:1b:0e:8c:d5:c7, XID 0c000800 IRQ 30
Sep 11 13:16:49 kuemmel kernel: [    4.664129] r8169 0000:01:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
Sep 11 13:16:49 kuemmel kernel: [    7.226800] r8169 0000:01:00.0 enp1s0: renamed from eth0
$

Also es ist eine Änderung, die du nicht mitbekommen hast, und die dich am falschen Fuß erwischte. Jetzt bist du auf udev böse.

Genau so ist es.

* einzelne Funktionen sind fest einprogrammiert und lassen sich nicht per udev-Regel ändern.

Welche? Und warum stören die?

Das war ganz zu Anfang, da wollte ich udev tatsächlich benutzen und eigene Regeln schreiben. Und ich wollte die meisten mitgelieferten Regeln außer Betrieb nehmen, mangels Bedarf. Das ging nicht vollständig, ich glaube, es war was mit CD-Laufwerken, zu lange her für Einzelheiten

* "Synthesizing the initial hotplug events" dauert sehr lange.

Bist du diesem Problem schon einmal nachgegangen?

Im Prinzip ja: mit devtmpfs ist der ganze Mechanismus überflüssig. Deshalb ist es mir total egal, ob man udev-seitig etwas optimieren könnte.

* es ist auch eine Kosten/Nutzen-Frage. Ich brauche udev ganz einfach nicht. Alles, was ich benutze, funktioniert auch ohne. Die einzige Funktion, die ich mal genutzt habe, ist Hot Plug für die Tastatur. Aber auch dafür habe ich inzwischen zwei andere Lösungen. Steckt eigentlich noch irgendwer seine Tastatur im Betrieb ein- und aus?

Es ist nicht nur die Tastatur. Es sind Drucker, mobile Internet-Sticks, USB-Speichersticks, externe Festplatten, USB-Mäuse, Funkmäuse, Lautsprecher, Dockingstations usw. usf. und ja, auch ab und zu mal eine Tastatur zum Testen, ob die noch funktioniert...

Mäuse sind quasi Tastaturen, s.o., Drucker werden per Netzwerk angeschlossen (für Parallelport-Drucker funktioniert udev sowieso nicht), Dockingstations habe ich keine und der Rest funktioniert auch ohne udev.

Ich für meinen Teil finde udev gut funktional. Es tut genau, was ich will.

Ich will es dir auch nicht ausreden.

Und Neues... ja, manchmal find ichs blöd, manchmal nicht.

Da sind wir direkt einer Meinung

[scientific]

Also doch nur ein Sturm im Wasserglas der Befindluchkeiten, und nichts wirklich technisch begründ- und belegbares...

Na gut.

[BenutzerGa4gooPh]

Betrachtet doch mal den Fall mit/ohne udev: https://www.amazon.de/Celeron-Firewall- ... 3741P&th=1
Ich hatte mal PFSense/BSD darauf. Wären die Interface-Bezeichnungen bereits mit Jessie immer konstant und der Reihe nach?
Vielleicht lässt sich cosmac so überzeugen?

[cosmac]

Wären die Interface-Bezeichnungen bereits mit Jessie immer konstant und der Reihe nach?

Ein 2.6er Kernel würde konstante eth0 bis eth3 liefern, aber seitdem läuft im Kernel immer mehr parallel. Trotzdem könnte es speziell mit dieser Hardware (wahrscheinlich 4 Interfaces im gleichen Chip) auch noch so funktionieren. Dann braucht man kein udev und keine Tricks.

Wenn das nicht so ist, nimmt man ifrename statt udev.

Mit udev und eigenen udev-Regeln hat es gefälligst en0 bis en3 zu heißen (oder rot, gelb, gruen, blau), und zwar konstant und mit jeder Debian-Version seit es udev gibt. Aber dazu müsste man erstmal die mitgelieferten Regeln abschalten können.

Vielleicht lässt sich cosmac so überzeugen?

Will man das? Sollte man nicht lieber scientific überzeugen?
Obwohl, letzten Samstag hat man mich mit einer Schwarzwälder Kirschtorte "überzeugt"

[detix]

du macht es einem auch nicht gerade einfach:

CONFIG_BLK_DEV_INITRD is not set
root 239 1 0 13:16 ? 00:00:00 /lib/systemd/systemd-udevd --daemon

systemds udev läuft offensichtlich, aber dies spielt auch gern mit der initrd rum,
dazu mal in die /usr/share/doc/udev/README.Debian.gz hineinschauen,
das Ein oder Andere wird durch systemds udev also schon in die initrd gebrannt...

hier zB definitiv die selbsterstellten *.link -Dateien (Benennung der Interfaces) in /etc/systemd/network/
selbst kleinste Änderungen dort erfordern ein „update-initramfs -u”

[BenutzerGa4gooPh]

Obwohl, letzten Samstag hat man mich mit einer Schwarzwälder Kirschtorte "überzeugt"

Fällt das unter "ueberzeugen" oder bestechen?
Aber danke für die Antwort. Auf udev bin ich erst durch deinen Thread aufmerksam geworden, die neue "Benamserung" der IFs ab Stretch und deren Gründe war mir bekannt. Und nun lese ich still weiter mit.