NEWS
/dev/tty... vs /dev/serial/by-id
-
Ich sehe das ganze rein aus Praktischer Sicht eines Nutzers. Man sieht nicht was sich hinter tty/USBx für ein Gerät verbirgt, die by-id ist in der Regel Sprechend.
Also ist das selbst erklärend und man sieht sofort ob es richtig eingestellt ist.
Denn genau das Problem hatte ich mehrfach bei Benutzern die sich mit Linux wenig bis gar nicht ausgekannt haben, es war nicht ersichtlich das sich was geändert hat.
Da ist es auch Unerheblich was technisch die bessere Wahl währe.Aber alleine das wir darüber Diskutieren sollte ein eindeutiger Hinweis darauf sein, dass die Auswahl des richtigen USB Geräts in manchen Adaptern komplizierter ist als nötig.
Die Adapter sollten selbst alle passenden Geräte suchen, den Optimalen Pfad wählen und diese mit eindeutigem Namen Anzeigen. Was da im Hintergrund läuft oder über welchen Pfad das Gerät angesprochen wird sollte für den Benutzer egal sein.@jey-cee sagte in /dev/tty... vs /dev/serial/by-id:
Aber alleine das wir darüber Diskutieren sollte ein eindeutiger Hinweis darauf sein, dass die Auswahl des richtigen USB Geräts in manchen Adaptern komplizierter ist als nötig.
Die Adapter sollten selbst alle passenden Geräte suchen, den Optimalen Pfad wählen und diese mit eindeutigem Namen Anzeigen. Was da im Hintergrund läuft oder über welchen Pfad das Gerät angesprochen wird sollte für den Benutzer egal sein.Dem stimme ich voll zu. Das ist aber insbesondere OS / Distributionsübergreifend kaum zu realisieren - zumindest im Zigbee Adapter. Der Wildwuchs ist da zu gross und die Identifikation klappt nur bedingt.
Wenn alle nur auf Debian arbeiten würden könnte es noch gehen, wenn denn alle Signaturen im Adapter hinterlegt würden, oder wenn die Firmwares entsprechende Abfragen sauber unterstützen. Die Tatsache das das Onboarding bei Z2M nur in einem Teil der Fälle wirklich klappt ist da durchaus sprechend.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Wobei sich auch jederzeit das LinkTarget ändern kann.
Ist zuletzt bei den Netzwerkinterfaces passiert. Wenn der Kerneltreiber umgeschrieben wird stehst du da.
Das System der dynamisch an die Situation angepassten Links 'by-id' dürfte sich in absehbarer aber Zeit eher nicht ändern.Ja, das kann passieren. Und nein, das mit dem by-id ist davor genausowenig gefeit wie die direkten Link Targets. Ist also meiner Meinung nach ein leeres Argument.
Beide können eine Änderung erfahren - wenn das passiert hat man pech gehabt.
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Und wenn ich eine andere Hardware verwende, dann kann ich auch (wenn ich um die 'richtige' Einstellung weiß) dann auch den Eintrag 'by-id' an die andere Hardware anpassen. Ich muss mich ja eh mit den Einstellungen nochmal beschäftigen und schauen ob es nun läuft.
Es geht nicht darum "eine andere" Hardware sondern "eine andere Instanz der gleichen Hardware" zu verwenden - da muss ich nicht umkonfigurieren. Wenn es vorher lief und richtig konfiguriert war läuft es hinterher auch.
@asgothian sagte in /dev/tty... vs /dev/serial/by-id:
Und nein, das mit dem by-id ist davor genausowenig gefeit wie die direkten Link Targets.
Das stimmt ja nun nicht. Wenn entschieden wird, das ein Chipsatz statt auf /dev/ttyUSBx besser auf /dev/ttyACM aufgehobe ist, dann wird das im Treiber und/oder in der udev-Regel so angepasst. Könnte z. B. bei einer neuen Version von systemd passieren. Der 'by-id'-Link zeigt dann aber automagisch auf die andere Geräte-Datei, ganz ohne mein Zutun.
Das setzt nur voraus, das man einmalig bei der Einrichtung auch diesen Link angibt. -
@asgothian sagte in /dev/tty... vs /dev/serial/by-id:
Und nein, das mit dem by-id ist davor genausowenig gefeit wie die direkten Link Targets.
Das stimmt ja nun nicht. Wenn entschieden wird, das ein Chipsatz statt auf /dev/ttyUSBx besser auf /dev/ttyACM aufgehobe ist, dann wird das im Treiber und/oder in der udev-Regel so angepasst. Könnte z. B. bei einer neuen Version von systemd passieren. Der 'by-id'-Link zeigt dann aber automagisch auf die andere Geräte-Datei, ganz ohne mein Zutun.
Das setzt nur voraus, das man einmalig bei der Einrichtung auch diesen Link angibt.@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Der 'by-id'-Link zeigt dann aber automagisch auf die andere Geräte-Datei, ganz ohne mein Zutun.
so lange bis entschieden wird das die Struktur der /dev/..../by_id vielleicht doch besser anders aufgebaut werden sollte. Auch da ist eine Konfiguration / regel / software hinter. Da haben sich Leute was bei gedacht. So wie auch bei der USB / AMA / ACM einodnung. Wer sagt mir das die Meinungen da so bleiben ?
Und im Ernst - mir ist bisher noch kein USB Gerät von USB zu AMA zu ACM gesprungen. (Edit : Klarstellung - bei Beibehalten der gleichen Distro)
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@jey-cee sagte in /dev/tty... vs /dev/serial/by-id:
Aber alleine das wir darüber Diskutieren sollte ein eindeutiger Hinweis darauf sein, dass die Auswahl des richtigen USB Geräts in manchen Adaptern komplizierter ist als nötig.
Die Adapter sollten selbst alle passenden Geräte suchen, den Optimalen Pfad wählen und diese mit eindeutigem Namen Anzeigen. Was da im Hintergrund läuft oder über welchen Pfad das Gerät angesprochen wird sollte für den Benutzer egal sein.Dem stimme ich voll zu. Das ist aber insbesondere OS / Distributionsübergreifend kaum zu realisieren - zumindest im Zigbee Adapter. Der Wildwuchs ist da zu gross und die Identifikation klappt nur bedingt.
Wenn alle nur auf Debian arbeiten würden könnte es noch gehen, wenn denn alle Signaturen im Adapter hinterlegt würden, oder wenn die Firmwares entsprechende Abfragen sauber unterstützen. Die Tatsache das das Onboarding bei Z2M nur in einem Teil der Fälle wirklich klappt ist da durchaus sprechend.
A.
@asgothian Flexibilität, Fluch und Segen.
Persönlicher Support
Spenden -> paypal.me/J3YC33 -
@asgothian Flexibilität, Fluch und Segen.
@jey-cee sagte in /dev/tty... vs /dev/serial/by-id:
@asgothian Flexibilität, Fluch und Segen.
Exakt.
-
Mir sind das zu viele WENNs.
Ein einmal sauber eingerichteter Link 'by-id' landet IMMER zu 100% auf dem definierten Gerät.Wenn ich auf /dev/ttyXYZ gehe, dann kann da mit unterschiedlicher Wahrscheinlichkeit auch ein anderes Gerät liegen. Das hat der Nutzer nämlich nicht in der Hand, das entscheidet udev/der Kernel.
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Mir sind das zu viele WENNs.
Ein einmal sauber eingerichteter Link 'by-id' landet IMMER zu 100% auf dem definierten Gerät.Wenn ich auf /dev/ttyXYZ gehe, dann kann da mit unterschiedlicher Wahrscheinlichkeit auch ein anderes Gerät liegen. Das hat der Nutzer nämlich nicht in der Hand, das entscheidet udev/der Kernel.
Dem kann ich zu 100% zustimmen. Insbesondere dem 1. Teil: Dir sind das zu viele Wenns.
Das reicht mir aber nicht die Behauptung aufzustellen das diese Einstellung die richtige ist die alle benutzen sollen
A.
-
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Der 'by-id'-Link zeigt dann aber automagisch auf die andere Geräte-Datei, ganz ohne mein Zutun.
so lange bis entschieden wird das die Struktur der /dev/..../by_id vielleicht doch besser anders aufgebaut werden sollte. Auch da ist eine Konfiguration / regel / software hinter. Da haben sich Leute was bei gedacht. So wie auch bei der USB / AMA / ACM einodnung. Wer sagt mir das die Meinungen da so bleiben ?
Und im Ernst - mir ist bisher noch kein USB Gerät von USB zu AMA zu ACM gesprungen. (Edit : Klarstellung - bei Beibehalten der gleichen Distro)
A.
@asgothian sagte in /dev/tty... vs /dev/serial/by-id:
Da haben sich Leute was bei gedacht.
Ja, und das Ergebnis ist vorhersagbar. Im Gegensatz zur direkten Geräte-Datei, die kann mal hier und mal da landen.
Deswegen hat man ja auch vor einiger Zeit diese sehr sperrigen 'predictable network interfaces' eingeführt.
Die sind nämlich genauso stabil und vorhersehbar wie die by-id-Links.
Das ganze ist für Endanwender aber zugegeben auch zunächst komplizierter als einfach /dev/eth0 anzusprechen (Und davon auszugehen, dass die Netzwerkkarte schon da liegen wird, hat sie ja sonst auch immer).
Der Auslöser für diese Umstellung waren aber ganz ähnliche Überlegungen. Man will eine stabile, ganz eindeutige Adressierung der Geräte haben.Kannst du hier sehr ausführlich erklärt nachlesen:
https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
Lässt sich 1:1 auf die seriellen USB-Interfaces anwenden. Die Problematik ist die gleiche.Aus dem obigen Link:
Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single eth0 interface. With this new scheme in place, an administrator now has to check first what the local interface name is before they can invoke commands on it, where previously they had a good chance that eth0 was the right name.
Ersetze eth0 durch ttyUSBx dann passt es. Eine 'good chance that ttyUSB0 was the right name' reicht nicht aus, man will ja genau das bestimmte Gerät treffen. Und das geht nur über dessen ID.
-
@thomas-braun sagte in /dev/tty... vs /dev/serial/by-id:
Der 'by-id'-Link zeigt dann aber automagisch auf die andere Geräte-Datei, ganz ohne mein Zutun.
so lange bis entschieden wird das die Struktur der /dev/..../by_id vielleicht doch besser anders aufgebaut werden sollte. Auch da ist eine Konfiguration / regel / software hinter. Da haben sich Leute was bei gedacht. So wie auch bei der USB / AMA / ACM einodnung. Wer sagt mir das die Meinungen da so bleiben ?
Und im Ernst - mir ist bisher noch kein USB Gerät von USB zu AMA zu ACM gesprungen. (Edit : Klarstellung - bei Beibehalten der gleichen Distro)
A.
@asgothian sagte in /dev/tty... vs /dev/serial/by-id:
Und im Ernst - mir ist bisher noch kein USB Gerät von USB zu AMA zu ACM gesprungen. (Edit : Klarstellung - bei Beibehalten der gleichen Distro)
jetzt sag ich doch was dazu, gerade nach dem edit:
lang ist's her, da hatte ich keine Ahnung von /by-id/ & co, und nur 1 USB Gerät. selbst da lief es manchmal nach Neustart nicht, erst nach erneutem Neustart.
seit ich /by-id/ kenne nutze ich es, und weder bei der Umstellung von USB0 nach AMA0 usw. habe ich nie Probleme gehabt, und auch beim Umzug von verschiedenen Hardware nicht.
Mittlerweile nutze ich einen aktiven Hub mit 4 USB Geräten und kann die Hardware und die Distro wechseln und brauche nur den Hub umzusteckenkein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@asgothian sagte in /dev/tty... vs /dev/serial/by-id:
Und im Ernst - mir ist bisher noch kein USB Gerät von USB zu AMA zu ACM gesprungen. (Edit : Klarstellung - bei Beibehalten der gleichen Distro)
jetzt sag ich doch was dazu, gerade nach dem edit:
lang ist's her, da hatte ich keine Ahnung von /by-id/ & co, und nur 1 USB Gerät. selbst da lief es manchmal nach Neustart nicht, erst nach erneutem Neustart.
seit ich /by-id/ kenne nutze ich es, und weder bei der Umstellung von USB0 nach AMA0 usw. habe ich nie Probleme gehabt, und auch beim Umzug von verschiedenen Hardware nicht.
Mittlerweile nutze ich einen aktiven Hub mit 4 USB Geräten und kann die Hardware und die Distro wechseln und brauche nur den Hub umzusteckenIm weiteren verweise ich nur noch auf die Anleitung von zigbee2mqtt, wie man das richtig konfiguriert.
Da haben die sich mit Sicherheit nämlich auch was bei gedacht, das so "umständlich" über 'by-id' anzulegen:https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html#basic-configuration
-
Also ich denke, das der Standard schon eher die persistente Benennung von Interfaces/Hardwares etc. sein sollte.
Die Experten haben eher Ahnung wo sie suchen sollen, falls sich da mal eine Interface ID ändert.
Die meisten User hier, haben aber davon keine Ahnung, warum das selbe Gerät plötzlich USB1 und nicht mehr wie immer USB0 heißt. Dann kann man denen sicherlich von irgendwelchen Race Conditions im Kernel erzählen, weil sie evtl eine Software/Treiber installiert haben, die da einen Einfluss hat. Ihr werdert das aber auch nicht für den User analysieren. Helfen tuts dem User ebenfalls nicht. Schlauer werden sie dadurch nur bedingt.Viele hier sind von Linux schon überfordert und sind froh, das sie einigermaßen die Befehle abgetippt bekommen, die sie irgendwo finden. Ich glaube das habt ihr alle fast täglich hier schon erlebt.
-
Also ich denke, das der Standard schon eher die persistente Benennung von Interfaces/Hardwares etc. sein sollte.
Die Experten haben eher Ahnung wo sie suchen sollen, falls sich da mal eine Interface ID ändert.
Die meisten User hier, haben aber davon keine Ahnung, warum das selbe Gerät plötzlich USB1 und nicht mehr wie immer USB0 heißt. Dann kann man denen sicherlich von irgendwelchen Race Conditions im Kernel erzählen, weil sie evtl eine Software/Treiber installiert haben, die da einen Einfluss hat. Ihr werdert das aber auch nicht für den User analysieren. Helfen tuts dem User ebenfalls nicht. Schlauer werden sie dadurch nur bedingt.Viele hier sind von Linux schon überfordert und sind froh, das sie einigermaßen die Befehle abgetippt bekommen, die sie irgendwo finden. Ich glaube das habt ihr alle fast täglich hier schon erlebt.
@oliverio sagte in /dev/tty... vs /dev/serial/by-id:
Die Experten haben eher Ahnung wo sie suchen sollen, falls sich da mal eine Interface ID ändert.
Der Punkt ist: Die Experten müssen erst gar nicht in solchen Fällen suchen, weil sie nämlich gleich die persistenten Links verwenden und somit auch nie in diese 'Falle' tappen.
Support us
777
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge