|
|
|
|
|
|
|
|
Mein Server meinte beim letzten Reboot statt ens* wieder eth für den Netzwerkadapter verwenden zu müssen. Großartig. Weiß der Geier wieso, die dafür nötige Konfiguration konnte ich nirgends finden :<
|
|
|
|
|
|
|
|
|
|
|
Wie passend.
/etc/udev/rules.d/70-persistent-net.rules ?
|
|
|
|
|
|
|
|
|
|
Herr Tod: ich hab hier wohl ein leichtes Echo in den Posts. 
Rufus: jaja, das scheint aber von der udev-Version abzuhängen (sprich je Version alt/neu muss die Regeldatei unterschiedlich heißen m():
mit dem Kernelparameter net.ifnames=0 kann man das dauerhaft ausschalten, falls gewünscht und udevd >=v199.
Erst wars /etc/udev/rules.d/80-net-setup-link.rules (v197 bis v208), Stand bis heute: 80-net-name-slot.rules.
Und wieso ist Lennart ein Arschloch? Finde ich nicht. Die User und (Kernel)Devs geben ihm halt genug Seil sich/uns aufzuhängen. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von teK
Rufus: jaja, das scheint aber von der udev-Version abzuhängen (sprich je Version alt/neu muss die Regeldatei unterschiedlich heißen m():
mit dem Kernelparameter net.ifnames=0 kann man das dauerhaft ausschalten, falls gewünscht und udevd >=v199.
Erst wars /etc/udev/rules.d/80-net-setup-link.rules (v197 bis v208), Stand bis heute: 80-net-name-slot.rules.
| |
Also ist einfach solange neue Hardware kaufen und Distros proberen bis es wie gewünscht läuft schon irgendwo der leichtere Weg, oder?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 30.06.2014 0:58]
|
|
|
|
|
|
|
|
|
An sich ist die vorhersehbare Benennung schon sinnvoll.
Das Nervige geht aber schon im ersten Satz los "but should fix real problems". Na-ja.
Also die Namen sind z.B. bei SLES auch schon immer predictable gewesen, weil es nach der Hinzufügereihenfolge und Schema f die Geräte von eth0..n benannt hat. So macht das übrigens Windows auch.
Das bedeutet, dass man nur beim ersten Start mit >1 Karte nicht vorhersagen konnte, wie welche Karte genannt wird. Kann man beim aktuellen Default von udevd aber auch nicht.
Da hilft mir vor allem folgende Beschreibung genau gar nicht:
| |
Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0) | |
Hmja, lieber Mal den Parameter beim Booten (mein bisheriges init-System hat bisher ohne Kernelparameter getan, die werden dann aber bald Argument sein, systemd in den Kernel oder umgekehrt umzuziehen) auf 0 stellen ODER (mit KVM) neustarten und schaun, welches Device wie benannt wurde.
Auch ist interessant, dass das Verhalten, das udev standardmäßig jetzt an den Tag legt, auch locker im Userspace (durch Distros) implementiert hätte sein/werden können. Warum das in den letzten >15 (!!) Jahren noch nicht geschehen ist, darf sich das junge Gemüse hier gerne selber zusammenreimen.
(Protip: udev gibts noch nicht so lange, lasse ich gar nicht erst zählen!!1)
Wahrscheinlich gibt es dann bald Konfigurationsformate bei den großen Distros, die eine Konfiguration der Netzwerkparameter auf Grund der MAC-Adresse erlauben, was m.E. nach sowieso das Sinnvollste wäre, weil die on- und offline je Karte supereinfach zu bestimmen ist – ich sehe gerade, dass udev das auch kann, dürfte aber nicht default sein.
Die Lösung ist einfach ein wenig wie zu sagen: "Wir haben hier was ganz Neues, Tolles, das all eure Probleme lösen wird!" und wenn man dann genauer hinschaut, ist es aber die selbe Kacke in anderer Farbe.
Oh und im übrigen spielt es gar keine Rolle, ob hier die Distro und oder udev verkackt hat. Relevant ist, dass deren dynamisches Trio aus der Unterwelt einfach die Komplexität erhöht hat und so die Fehler überhaupt auftreten können. An dieser Stelle hab ich wirklich lieber keine Features in sysvinit, wo systemd "Bugs" hat.
Ich hoffe wirklich wirklich, dass Gentoo eudev weiterpflegen wird, ansonsten sieht es bald wirklich düster aus. Wie weitere Programme, die heute dbus nutzen, ohne kdbus aus systemd funktionieren werden, sobald dbus einfach nicht mehr funktioniert/weiterentwickelt wird, mag ich mir noch gar nicht ausmalen. Thanks, Lennart.jpg.
Weiter verweise ich auf meine anderen Beiträge zu diesem Thema aus der Vergangenheit, Gegenwart und allen noch zu entdeckenden Dimensionen.
Next-up: die Integration von pulseaudio in systemd und die Ablösung von sämtlichen alsa-Tools. Und wer mir jetzt einen Link zu solchen Plänen schickt, bekommt fünf Tage Forenauszeit.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von teK am 30.06.2014 1:26]
|
|
|
|
|
|
|
|
|
Ich weiß bis heute gar nicht wirklich, was udev eigentlich ist. Ich hab ab und an mal gegoogelte Sachen damit gemacht um USB-Schnickschnack zum Laufen zu kriegen oder eben Benennungen von Interfaces festgelegt (daher mein Verweis auf das File oben). Und auch wenn ich hüpfende interface-Namen mal festgelegt bekam, war das immernoch viel Magie und hielt mitunter nur drei Reboots länger. Überhaupt nicht nachvollziehbar irgendwie.
Aber wenn ich deinen Post lese (der für mich genauso klingt wie eigentlich alles zu dem Thema), hat es offensichtlich auch gar keinen Sinn, sich damit zu befassen, weil es eh bald anders/kaputt/weg/erneuert sein wird.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rufus am 30.06.2014 1:42]
|
|
|
|
|
|
|
|
|
Handfeste Dinge:
Was tut eigentlich rsync -z genau? Die übertragene Filegröße ist ziemlich identisch mit der Größe des Files in gzip-ter Fassung. Ist das Zufall? Macht rsync -z einfach gzip? Oder ist es cleverer bei der Auswahl des Algorithmus, sodass u.U. auch bzip2 mal genutzt würde? Und hat gzip --rsyncable was damit zu tun?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 30.06.2014 1:46]
|
|
|
|
|
|
|
|
|
Ja, dass die gerne Mal was brechen (müssen, schließlich ist deren Zeug ja neu, Fehler macht man bei ausreichender Kompetenz eher am Anfang), ist auch mein Eindruck. Das wird auch nicht in Frage gestellt, weil systemd!
Früher gabs devfs, dass die Nodes unter /dev statisch angelegt hat. Wenn du was Neues angesteckt hast, was da auftauchen muss, dann war das entweder da, man hats via MAKEDEV foo bar oder mknod (c|b|p) major minor angelegt.
Heute hast du dort ein devtmpfs, dass trotz udev vorbelegt mit /dev/{null,zero,console} ist. Da wurstelt der udev dann rum, wenn neue /dev/-Nodes "on-demand" angelegt werden. Früher hattest du halt schonmal /dev/sd[a-z][1-9][0-9]? rumliegen.
Das war alles relativ statisch und kaum standardisiert konfigurierbar. Spoiler - markieren, um zu lesen:
Jetzt gibt es udev und die Sachen sind immer noch kaum konfigurierbar, weil die Logik hinter den Regeldateien schräg ist, und wer das auf Anhieb gebacken kommt, hat meinen Respekt. Wer nicht, hat das selbe Problem, wie ich. Recht viel dynamischer wirds trotzdem nicht.
Ich habe damals aber nichtmal ein Skript (ja, war nötig) + udev-Regel für den iPod meiner Freundin hinbekommen. Ziel war, chmod, mount und ln -s passend zum Anstecken und Abstecken aufzurufen. Am Ende hats zwei Skripte gebraucht, weil der fucking udev keine Argumente (anstecken, abstecken) übergeben wollte.
Letztlich bin ich bei udevil gelandet.
Warum man für so simple Sachen keine einfache Publisher/Subscriber-Schnittstelle am Kernel für solche Helferprogramme angeboten hat, sondern man einen daemon UND eine lib braucht, verstehe ich nicht wirklich. Das kann aber auch an bestimmten Prioritäten für die Grenze zwischen Kernel- und Userspace liegen, die ich nicht kenne.
Grundsätzlich habe ich aber wenig bis nichts gegen udev.
e: zu QT/GTK gebe ich morgen meinen Senf ab, danke aber schomal an euch für die interessanten Argumente!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von teK am 30.06.2014 2:01]
|
|
|
|
|
|
|
|
|
oh sorry 
|
|
|
|
|
|
|
|
|
|
|
Das heißt „Qt“, zefix!
„QT“ is QuickTime.
|
|
|
|
|
|
|
|
|
|
|
Sprecht ihr es denn "cute" oder "Q-T" aus? Das scheint jeder anders zu machen, auch wenn "cute" wohl das richtige ist 
|
|
|
|
|
|
|
|
|
|
|
|
Ich denke man spricht es "cutee" aus
|
|
|
|
|
|
|
|
|
|
|
|
Nein, richtig ist das englische cute = hübsch, also "kjut"
|
|
|
|
|
|
|
|
|
|
|
qt -> cute
QtCore -> Q t core
keine Ahnung ob das richtig ist, fühlt sich richtig an, weil ich es komisch finde bei Objektnamen irgendwas speziell auszusprechen. Dann weiß eh wieder keiner was gemeint ist.
| | Pressing the undock button will immediately unplug all dock attached devices. This can easily lead to problems, for instance if you have a USB or Ultrabay storage device attached to the dock and have a filesystem mounted RW, this can easily lead to filesystem corruption.
The solution for now is to always make sure any storage devices attached to the dock are unmounted BEFORE pressing the undock button. | |
genius.jpg
|
|
|
|
|
|
|
|
|
|
|
Gruselig an udev finde ich die schlechte Dokumentation. Udev ist eines dieser Linux-Sachen, bei denen ALLE voneinander abschreiben und keiner wirklich versteht, was oder wieso das funktioniert.
Es scheint ja schon niemand zu wissen, wann udev seine Regeln neu lädt. Manchmal reicht ein udevadm ... --reload, manchmal muss es ein reboot sein. Oder mehrere. Warum auch immer.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
Handfeste Dinge:
Was tut eigentlich rsync -z genau? Die übertragene Filegröße ist ziemlich identisch mit der Größe des Files in gzip-ter Fassung. Ist das Zufall? Macht rsync -z einfach gzip? Oder ist es cleverer bei der Auswahl des Algorithmus, sodass u.U. auch bzip2 mal genutzt würde? Und hat gzip --rsyncable was damit zu tun?
| |
Niemand?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Daddi89
Nein, richtig ist das englische cute = hübsch, also "kjut"
| |
Ja, aber...
|
|
|
|
|
|
|
|
|
|
|
|
Schau halt in den Source, so viel ist das bei rsync nicht.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
Handfeste Dinge:
Was tut eigentlich rsync -z genau?
| |
Bitte
| |
READ THIS BEFORE TRYING TO DYNAMICALLY LINK RSYNC AND ZLIB!
zlib has been adapted slightly for use in rsync. (...).
Specific changes that have been made to zlib for rsync include:
- add Z_INSERT_ONLY to allow for efficient history updating without
actually emitting any data. This is used to compress the matched
blocks that don't cross the wire, which gives better compression
ratios on the literal data.(...)
As a result of the first item, the streams from rsync's version of
zlib are *not compatible* with those produced by the upstream version
of rsync. In other words, if you link rsync against your system's
copy, it will not be able to interoperate with any other version if
the -z option is used. (Sorry. Sometimes standard is better than
better.)
| |
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Schau halt in den Source, so viel ist das bei rsync nicht.
| |
Warum verwenden die nicht einfach Github, deren eigenes System ist ein Haufen Scheiße.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Merkwürdig, gerade eben und neulich als ich mir rsyncs --ignore-errors ansehen wollte lud das den ganzen Tag nicht, jetzt gerade gehts bei mir auch.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TheRealHawk am 30.06.2014 14:34]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*auf_tek_wart*
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Da könnten sie wenigstens GNU/Linux schreiben.
|
|
|
|
|
|
|
|
|
|
|
Kennt sich wer mit CTAGS aus?
http://stackoverflow.com/questions/24489855/generate-ctags-for-libstdc-from-current-gcc
CTAGS sind vom Prinzip her schoen einfach und schlicht, deswegen wuerde ich gerne CTAGS mit der aktuellen STL (kompliziert) zum laufen bekommen. YouCompleteMe (LLVM/CLANG) waere mein naechster Ansatz, scheinbar kann man das irgendwie auch auf die Header von GCC loslassen. Wobei sich ja beide Compiler beim Support von C++11 nichts schenken.
|
|
|
|
|
|
|
|
|
|
|
https://www.cloudpipes.com
Coole Idee, ich verknüpfe die APIs meiner Systeme über einen fancy Cloudservice hinter dem eine Limited steht zu der man rein gar nichts findet  Ich bekomm gar nicht erst 'ne Mail.
|
|
|
|
|
|
|
|
|
|
|
|
Nicht denken, cloud clouden. Los!
|
|
|
|
|
|
|
|
|
|
|
|
Hatten wir das nicht schonmal?
|
|
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.30 gute Gründe für systemd ) |
