Die Bezeichnung predictible ist einfach die einzig korrekte. Stabiel waren sie vorher:
Es wurde per UDV eine regel angelegt und danach behielt das gleiche device immer den selben Namen. – Das ist stabil.
Völlig anders jetzt: Jedes BIOS-Update killt dir erst mal die Banamung weil es die PCIe-Nummerirung ändern und jedes zweite Kernel Update ändert sie auch, weil der Treiberherautor sich ein anderes Namensschema ausgedacht hat. Das ist eben ganz und gar nicht mehr stabiel, aber wenn man alle äußeren umstände kennt, vorhersehbar.
Und ich sehe da halt schon ganz dick den systemd Einfluss: Früher Konfigurationsdatei um auf individuelle Bedürfnisse reagieren zu können, heute Bevormundung durch Systemd. Um das nochmal zu verdeutlichen:
Und ja, der Admin kann auch heute natürlich via UDEV bestimmen, so wie du sagst, wie die NICs heissen sollen .... die Besonderheit dabei ist, "er kann", und nicht "er muss'. Mit den predictable NIC-Names muss er das nämlich nicht mehr und hat deshalb trotzdem keine Nachteile...
Nein. eben genau anders herum wird ein Schuh draus: Früher konnte ich auch genau das in udev-Regeln gießen was heute die predictable Names machen. Weitestgehend ist das auch das was die meisten RZs gemacht haben aber halt an die individuellen Bedürftnise angepasst: eth0 immer die GbE-Karte zur Providionierung – Erkennbar daran, dass sie die einzige GbE-Karte ist. int erkennbar daran, dass es Mellanox-Karten sind immer das interne netz ext immer der 40GbE-Uplink.... Schön predictable UND stabiel. – Aber halt etwas Handarbeit erforderlich. Schaltest du jetzt prdictable names an, heißen die Schnittstellen trotz explizit anders lautender UDEV-Regel anders – Und alle Scripte müssten für eine unnötige Autokonfiguration geändert werden. – Und zwar bei jedem Update. Und genau deswegen sind die predictable Names auch in fast allen größeren RZs aus. Nette Idee aber viel zu starr für den Gebrauch im RZ.
PS: Ja ich weiß, dass man es mit systemd-networkd wieder hinbiegen könnte. Aber warum soll ich funktionierende udev-Einzeiler in 20 Zeilen Systemd-Konfig umschreiben, nur damit wieder alles so funktioniert wie vorher.
Das ist halt allgemein der Grund, warum systemd so fett da scheitert wo es am meisten benötigt würde: Die Philosophie unkonfigurierbar ist besser passt halt nur für den 0815-User. Und das hat in UDEV genau so Einzug gefunden wie überall sonst in Systemd-Projekten.
)