Von Josef Hahn am Mo, 23. Dezember 2019 um 11:16 #
> [...] geht immer noch nicht richtig und die kommen schon mit [...++] daher
Ist doch überall das gleiche Spiel. Schließe doch schonmal Wetten ab, wann irgendjemand HTTP3 doof findet und in einer spontanen Sonntagslaune HTTP4 entwickelt - und alle wie die Lemminge hinterherrennen...
Meine "Fix $WHATEVER" Einträge auf der TODO Liste nehmen seit geraumer Zeit jeder neuen Aktion den Atem. Sei es grub (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311 - nicht mein Ticket, betrifft mich aber), oder Pulseaudio auf einigen Embedded Systems, oder Tools die mit nftables noch nicht so ganz zurechtkommen, ...
Alles Dinge, die schon funktioniert haben, dann aber mit dem nächsten Ubuntu bzw. Debian nicht mehr gingen.
Die bekommen sogar die Scrollradlogik kaputt. Das tut's hier sporadisch schonmal nicht, und ich muss hinundherfokussieren, damit es wieder klappt. Wachstumsschmerz bei irgendwelchen Wayland-Anpassungen (ich hab allerdings immernoch X, weil Wayland ja _immernoch_ kein robuster und vollwertiger Ersatz zu sein scheint)?!
Desktop, Server, Embedded... Was nicht heute schon kaputt ist, wartet daruf, dass du es in deine Toolchain aufnimmst, um dann mit dem nächsten Release kaputtzugehen.
Die ideologische Komponente wäre mir da inzwischen echt wurst... Wenn es einen Weg gäbe, _sicherzustellen_, dass es keinerlei Datenabflüsse gibt, und ein paar andere Modalitäten, würde ich jetzt sofort nach dem Frühstück losgehen und ein paar Apple-Geräte kaufen.
Von Josef Hahn am Mo, 23. Dezember 2019 um 11:20 #
... der Bezug zu deinem Posting: Ja - am besten nimmt man uraltes Zeug und ist bescheidener, dann hat man zumindest gewisse Chancen, dass es keiner anfasst und kaputtpratscht. Es kann halt nur irgendwann ganz verschwinden; das ist dabei wieder der Nachteil. USB Storage gibt's aber sicher noch eine Weile...
Ja, unter Linux gehen immer mal wieder Dinge kaputt. Das hat zweierlei Gründe. Einerseits werden ständig Schnittstellen 'from scratch' neu implementiert, teils mit extrem fehlerhafter oder schlich nicht existenter Abwärtskompatibilität, und andererseits werden oftmals keine LTS-Distributionen eingesetzt, wo diese nötig wären. Letzteres liegt an dem Dilemma zwischen stabiler und getesteter/verlässlicherer Software in unteren Teilen der Systemschichten und aktuelle Anwendungssoftware. (Ausnahme sind Dinge wie Kernel und Mesa etc., die aufgrund der Treiberpolitik und der Notwendigkeit der Unterstützung aktueller Hardware mitunter aktualisiert werden müssen.)
Abhilfe könnte hier eine bessere Trennung von Basissystem und Rest sein, wie etwa bei FreeBSD mit den Ports. Dann könnte es noch ein besseres Backports oder PPA-System geben. Die andere Lösung könnten AppImage, Snap oder Flatpak etc. sein, aber das lehen viele Kritiker hier in der Leserschaft ja auch wieder kompromisslos ab.
Web-Standards sind nochmal ein ganz anderes Thema außerhalb der Distributionen.
Meine "Fix $WHATEVER" Einträge auf der TODO Liste nehmen seit geraumer Zeit jeder neuen Aktion den Atem. Sei es grub (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311 - nicht mein Ticket, betrifft mich aber), [...]
Das liegt laut Kommentar #23 scheinbar weniger an GRUB (2.02 vs 2.04) als daran, wie GRUB 2.04 in Ubuntu 19.10 con Canonical paketiert oder kaputtgefrickelt wurde. Ergo: Auf LTS-Zweigen bleiben oder Distribution wechseln, wenn's unbedingt etwas aktueller sein soll.
[...] oder Pulseaudio auf einigen Embedded Systems, [...]
Wie lauten denn diese Einträge? Wie lief es vorher?
[...] oder Tools die mit nftables noch nicht so ganz zurechtkommen, ...
Hm ja, das ist blöd. Aber wer zwingt einen zum Umstieg? In LTS-Distros wird doch weiterhin iptables angeboten, oder? Über welche Werkzeuge sprechen Sie?
Alles Dinge, die schon funktioniert haben, dann aber mit dem nächsten Ubuntu bzw. Debian nicht mehr gingen.
Ubuntu und Debian bieten doch beide weiterhin iptables, oder? Wieso dann nftables nutzen? Bei welcher Aktualisierung hatten Sie die Probleme mit Pulseaudio von oben? Im GRUB-Beispiel oben sollte man aber nicht verschweigen, dass Ubuntu 19.10 eine STS-Veröffentlichung ist.
Wachstumsschmerz bei irgendwelchen Wayland-Anpassungen (ich hab allerdings immernoch X, weil Wayland ja _immernoch_ kein robuster und vollwertiger Ersatz zu sein scheint)?!
Bisher betrifft das eigentlich nur GNOME, oder? Deswegen würde ich die Kritik an GNOME und die Distributionen richten - die betreiben scheinbar kein vernünftiges QA. Erwarten können Sie das allerdings auch nur bei LTS-Veröffentlichungen.
Desktop, Server, Embedded... Was nicht heute schon kaputt ist, wartet daruf, dass du es in deine Toolchain aufnimmst, um dann mit dem nächsten Release kaputtzugehen.
Klingt ein wenig pauschal. Ich denke, dass es viele Aktualisierungen gab, die glatt liefen/laufen. Nicht immer werden Release-Upgrades auch tatsächlich unterstützt.
Insgesamt hält sich Linux bei Regressionen inzwischen die Waage mit Windows 10
Die ideologische Komponente wäre mir da inzwischen echt wurst... Wenn es einen Weg gäbe, _sicherzustellen_, dass es keinerlei Datenabflüsse gibt, und ein paar andere Modalitäten, würde ich jetzt sofort nach dem Frühstück losgehen und ein paar Apple-Geräte kaufen.
Da hilft momentan wahrscheinlich nur offline bleiben oder viel Monitoring und Filterregeln in einer vorgeschalteten Firewall verwenden. Dass das noch keine hinreichend profitable Marktlücke ist, wundert mich inzwischen ein wenig. Gerade seriöse Unternehmen mit IP, Arztpraxen und Kanzleien sollten solche Produkte doch wertschätzen und fordern. Vielleicht erlebe ich soetwas ja noch
Von Josef Hahn am Mo, 23. Dezember 2019 um 14:28 #
Hi. Ja, LTS-Versionen könnten das teilweise eindämmen, das stimmt. Dass man es damit löst, wage ich aber zu bezweifeln. Man bekommt dann auch Fixes erstmal nicht. LTS-Versionen haben vielleicht weniger von den groben Schnitzern, dafür sitzt man länger auf den kleinen Ärgerlichkeiten. Ich habe bspw. mit jeder Version die Hoffnung, dass Suspend-to-RAM irgendwann wieder gescheit tut (so dass auch USB-Geräte nach Resume wieder tun, usw, usf). Außerdem ist ja Debian per se LTS-artig, und da habe ich auch Probleme (o.g. Pulseaudio, nftables, ...).
> Das liegt laut Kommentar #23 scheinbar weniger an GRUB (2.02 vs 2.04) als daran, wie GRUB 2.04 in Ubuntu 19.10 con Canonical paketiert oder kaputtgefrickelt wurde.
Dass es da auch immer handfeste technische Hintergründe gibt, ist mir auch klar. Aber "was zählt ist auf dem Platz", oder so... Am Ende helfen mir die Hintergründe ja nicht, wenn das System nicht läuft. Woran es in diesem Fall genau liegt, ist ja auch noch unklar.
>> Pulseaudio > Wie lief es vorher?
Naja - es lief halt... Ich starte es als systemd Service im "system mode" auf einem Banana Pi, und da macht es dann so seinen Job. Mit Debian Buster allerdings immer nur für ein Stündchen oder so. Dann hängt es sich weg, bis man den Service wieder neu startet. Das lief rock stable mit >1y Uptime vor dem Update.
Zu nftables: Debian steigt da halt gerade drauf um. Klar konnte man auch bei iptables bleiben. Hätte ich das mal getan. Überall (z.B. https://wiki.debian.org/nftables) heißt es aber, nftables ist der neue Default, und man _soll_ jetzt das benutzen, usw. Habe ich dann halt gemacht. Iptables auf Kommandozeile soll ja sogar weiter funktionieren (allerdings scheinbar nicht ganz!?) mit nftables als Backend. Und dann kommt bspw. fail2ban und kommt mit nftables einfach nicht richtig zurecht, und macht wirres Zeug. Auch libvirt benutzt es intern für VM-Networking, und ich hatte den (bisher unbestätigten) Eindruck, dass ich ein bisschen manuell nachschieben musste, bis meine Netzwerkkonfiguration damit lief. Ja, hätte ich mal nicht auf die Ratschläge gehört, und wäre bei iptables only geblieben...
>> Wachstumsschmerz bei irgendwelchen Wayland-Anpassungen > Bisher betrifft das eigentlich nur GNOME, oder?
Hm, wäre ja schlimm genug. Kann sein. Zuletzt aufgefallen ist es mir bei Evolution. Den brauche ich halt, weil Kontact/Akonadi (hier?!) hier nicht gescheit läuft. Da hatte ich vor einigen Wochen mal meinen Rant zu abgelassen.
> Ich denke, dass es viele Aktualisierungen gab, die glatt liefen/laufen.
Mag so sein. Aber die, die nicht glatt laufen, füllen seit einer Weile meine TODO Listen auf eine Weise, die ich nicht mehr schön finde.
> Insgesamt hält sich Linux bei Regressionen inzwischen die Waage mit Windows 10
Das ist zwar auch ein bisschen pauschal, und ich weiß nicht, ob man das wirklich so sagen kann, aber wie auch immer... Windows habe ich auf der Firma, aber das wäre privat ganz sicher auch nicht mein Fall. Klar, da versuchen sie mir mit jedem Update, das ClassicShell lahmzulegen, oder mir ihren Edge aufzudrücken, Privacy-Settings zu resetten, ... auch alles Mist. Deshalb hatte ich Windows auch nicht genannt, sondern Apple.
> Da hilft momentan wahrscheinlich nur offline bleiben oder viel Monitoring und Filterregeln in einer vorgeschalteten Firewall verwenden.
Beides nicht praktikabel. So viel Monitoring kann man garnicht betreiben, insbesondere weil Datenverkehre ja nunmal auch verschlüsselt sein können, und nicht immer sauber von gutmütiger Kommunikation zu unterscheiden ist. Offline bleiben: Klar; so ähnlich kann man auch aller FOSS Fuzzyness aus dem Weg gehen. Mit den Worten von Peter Lustig: Ausschalten!
Von Josef Hahn am Mo, 23. Dezember 2019 um 14:35 #
>> Ich denke, dass es viele Aktualisierungen gab, die glatt liefen/laufen.
... wobei ich auch erwähnen muss: Technisch gesehen sind das niemals Aktualisierungen. Ich installiere immer frisch neu, und habe dann ein paar Skripte, die es einrichten. Es geht dabei also nicht darum, dass vielleicht Updateprozeduren nicht funktioniert hätten.
Hi. Ja, LTS-Versionen könnten das teilweise eindämmen, das stimmt. Dass man es damit löst, wage ich aber zu bezweifeln. Man bekommt dann auch Fixes erstmal nicht. LTS-Versionen haben vielleicht weniger von den groben Schnitzern, dafür sitzt man länger auf den kleinen Ärgerlichkeiten.
Was ist Ihnen denn lieber?
Dass man keine Fixes bekommt, stimmt so auch nicht. Debian verfolgt hier eine sehr harte Linie, auch weil die Ressourcen fehlen und alles auf freiwilliger Basis ist. OpenSUSE Leap aktualisiert und verbessert bspw. auch Desktop-Pakete auf stabilen Entwicklungszweigen. Wenn man weiß, was man tut, kann man da auch aktuellere Versionen einzelner Pakete oder Paketgruppen via separaten OBS-Repos aktualisieren. Und die kommen von der Distribution selbst, das sind keine Community-Repos. Im Prinzip ist das eine sinnvolle Umsetzung von dem, was Debian-Backports mMn eigentlich sein sollten. Letzteres wird noch viel zu sporadisch verwendet. (Sind die Anforderungen des Paketierens zu hoch?)
Ich habe bspw. mit jeder Version die Hoffnung, dass Suspend-to-RAM irgendwann wieder gescheit tut (so dass auch USB-Geräte nach Resume wieder tun, usw, usf). Außerdem ist ja Debian per se LTS-artig, und da habe ich auch Probleme (o.g. Pulseaudio, nftables, ...).
Ja, Debian stable bekommt LTS. Was ich bis heute noch nicht verstehe, ist, wie die es schaffen, gleichzeitig mehrere stabile Zweige zu pflegen.
Treten die Problem mit Suspend-to-RAM auch mit LTS-Distros auf? Bis auf die Sache mit nftables sind solche Regressionen natürlich immer ärgerlich.
Zu nftables: Ja, es ist tatsächlich ärgerlich. Aber laut dem Wiki hätten Sie das vermeiden können. Das neue nftables-Backend unterstützt ja weiterhin die alten iptables-Werkeuge und Syntax, ist also abwärtskompatibel. Zumindest soll es das sein. Oder gab es genau damit bei Ihnen Probleme? Über Ihren Wiki-Verweis bin ich auf das nftables-Wiki gestoßen. Dort heißt es, dass fail2ban damit bereits klarkäme. Auf der Seite von fail2ban sind alle Tickets mit 'nftables' geschlossen. Die Unterstützung wurde hiermit hinzugefügt. Wenn man das so ließt, wirkt das ziemlich unausgegoren, rudimentär oder experimentell. Dass die das so veröffentlichen, ist nicht gerade vertrauenserweckend und eigentlich sogar peinlich für ein Sicherheitswerkzeug.
Unabhängig davon halte ich von fail2ban nicht viel. Es nützt nichts gegen DDoS oder die effektivste Methode: 'social engineering'. Snort fand ich immer ganz gut und ausgereift. Das läuft auch nicht nur unter Linux. Haben Sie das mal ausprobiert?
Ich kann inzwischen nicht mehr guten Gewissens zu Debian raten. Es ist zu viel inkonsistentes und komplexes Gefrickel am Werk. Zu viele Köche verderben den Brei. Das Projekt tut sich mit sehr wichtigen technischen Entscheidungen extrem schwer, und praktiziert lieber ellenlange und verwüstende Diskussionen, und hält sich endlos an internen Reibereien auf. Siehe die aufflammende GR-Debatte um init/systemd. Ich frage mich, wie unter diesen Bedingungen überhaupt noch effizient etwas Vernünftiges entstehen kann. In diesem Sinne: Haben Sie es denn mal mit den kostenlosen Varianten von den kommerziellen Distributoren versucht, sprich OpenSUSE oder gleich CentOS? Sie könnten auch auf Ubuntu LTS verweilen bis die Unterstützung ausläuft. Eventuell wäre sogar FreeBSD etwas für Sie.
Von Josef Hahn am Mo, 23. Dezember 2019 um 17:12 #
>> LTS-Versionen haben vielleicht weniger von den groben Schnitzern, dafür sitzt man länger auf den kleinen Ärgerlichkeiten. > Was ist Ihnen denn lieber?
Jaja, schon richtig. Bei LTS-Versionen zu bleiben, könnte durchaus eine Lehre sein, die ich aus dem Ganzen jetzt ziehe. Nur damit allein wird halt auch nicht alles gut. Meine Debian-Probleme löst es nicht. Und warum das Grub-Problem nicht zufällig auch eine LTS hätte treffen können, weiß ich auch nicht. Auch da gibt es ja neue Paketversionen, und da kann es sich auch einschleichen. Nur sind sie vielleicht mit den Versionssprüngen und Änderungen in der Paketierung vielleicht vorsichtiger. Das _könnte_ helfen.
> Treten die Problem mit Suspend-to-RAM auch mit LTS-Distros auf?
Ja, gut funktionierendes Suspend-to-RAM hatte ich hier schon lange nicht mehr. Das ist natürlich auch immer ein Hardwarethema. Das ist aber immer ein Aspekt, der mich bisher auch immer von den LTS-Versionen weggelockt hat; nach dem Motto "Dann installiere ich mal das neue Ubuntu, vielleicht tuts das dann auch endlich mal wieder". Sauberer Shutdown der Desktopsitzung ist auch so eine Sache, wo ich mir immer Verbesserungen verspreche. Das stolpert manchmal auch eher so vor sich hin, als dass es nach einem durchdachten Ablauf aussieht. Wegen sowas habe ich die LTS-Schiene in der Vergangenheit dann immer wieder verlassen. War i.d.R. unnötig, und ich habe draus gelernt.
> Zu nftables: Ja, es ist tatsächlich ärgerlich. Aber laut dem Wiki hätten Sie das vermeiden können. Das neue nftables-Backend unterstützt ja weiterhin die alten iptables-Werkeuge und Syntax, ist also abwärtskompatibel. Zumindest soll es das sein. Oder gab es genau damit bei Ihnen Probleme?
Ich hätte es vermeiden können, wenn ich den Ratschlägen im Debian-Wiki mißtraut hätte, und einfach bei iptables geblieben wäre, ja. Nun habe ich dem aber geglaubt (wenn die konservativen Debianer das schon anraten), und habe zu nftables gewechselt. Und als alles soweit war, und einige Wochen ins Land gestrichen sind, fielen mir die ersten Probleme etwa mit fail2ban auf. Die Version in Buster war definitiv an einer relevanten Stelle buggy, und ich musste in der Config ein bisschen tricksen. Das kostet aber alles viel Zeit, und ist auch sonst ärgerlich. Es ist auch klar, dass mein dirty workaround mit der Folgeversion wieder bedroht sein wird. Es wirkte alles beta-mäßig. Ich sehe in deinem Link gerade: 'Protocol "all" is not supported, only "tcp" and "udp". Should be relatively easily fixable with shell conditionals for iptables-allports, but I'm lazy.' - Ja, das hatte ich nach einiger verbröselter Zeit auch gemerkt. :-/
Die iptables-Werkzeuge funktionieren wohl auf dem nftables Backend, aber auch nur eingeschränkt. Ich hatte auch schon Firewallregeln, wo iptables dann nur sinngemäß nur noch gesagt hat "Deinen nft-Kram kann ich nicht mehr abbilden, nimm bitte jetzt direkt nftables". Als fail2ban wieder vorwärts humpelte, war es mir aber erstmal wieder egal. Die TODO-Liste solcher Dinge ist halt lang. :-/
> Unabhängig davon halte ich von fail2ban nicht viel. Es nützt nichts gegen DDoS oder die effektivste Methode: 'social engineering'.
Ja, vielleicht sollte ich irgendwann auch mal nach einem Replacement für fail2ban suchen. Snort ist besser? Muss ich dann mal schauen. Wobei man ja gegen DDoS nicht so wirklich viel tun kann, oder? Und Social Engineering ist für meinen Anwendungsfall auch kein Thema. Aber wenn es den Rest gescheit macht, ist das prima. Steht jetzt auf meiner Liste.
> Ich kann inzwischen nicht mehr guten Gewissens zu Debian raten. Es ist zu viel inkonsistentes und komplexes Gefrickel am Werk.
Das ist schade, denn ich hatte schon überlegt, meine Ubuntus auch durch Debians zu ersetzen. Ich habe aber auch schon von anderen Stellen gehört, dass man sich davon nicht zuviel versprechen sollte. :-/
> In diesem Sinne: Haben Sie es denn mal mit den kostenlosen Varianten von den kommerziellen Distributoren versucht, sprich OpenSUSE oder gleich CentOS?
Lange nicht mehr. Ich habe halt heutzutage eine doch recht umfangreiche Sammlung an Skriptchen, die bspw. auch Installationen (debian preseed-basiert) und Systemeinrichtung automatisieren, und die nur unter enormem Aufwand umzustellen sind. Aber ja, lange kann ich mir dieses Spielchen nicht mehr ansehen, und wenn ich irgendwann endgültig die Schnauze voll habe, und die Gewissheit habe, dass das Gras woanders wirklich grüner ist, dann werde ich mal diesen Schritt machen. Auch BSDs kommen dann prinzipiell in Frage. Aber ich müsste es dann sorgfältig prüfen, um nicht nach Monaten an Migrationsarbeiten wieder vor dem selben Scherbenhaufen zu stehen. Ich befürchte auch, sehr viele Probleme hat man einfach mit der Qualität der Software selbst, und nicht mit der Integration in die jeweiligen Distris. Das mag jetzt bei dem Grub-Fall anders sein.
Das weiß ich nicht. Das hängt vom Bedarf und den Ressourcen ab. Und obwohl sich der Artikel um die Unterstützung von USB4 dreht, war das ja kein explizites Kriterium in Josef Hahns Kritik. Oder habe ich das überlesen?
Erstens hat das nichts mit dem Diskussionsthema zu tun.
Zweitens gibt es kein Dateisystem, welches gegen Bit-Rot sicher gefeit wäre. Es ist nach dem bisherigen wissenschaftlichen Kenntnisstand der Menschheit anzunehmen, das ein solches Dateisystem in unserer Welt nicht existieren kann. Insofern lautet die Antwort 'unendlich viele Jahre' (kurz: nie), und dies gilt wahrscheinlich nicht nur im Bezug auf Linux sondern sogar für jede beliebige Implementierung innerhalb dieser Welt.
Doch gibt es ZFS... Was schreibst Du da fuer pseudo-physik-zeugs? Sicherlich kann ein solches Dateisystem existieren (gib bitte einen grund an weshalb dies nicht so sein soll). Du spielst wahscheinlich darauf an, dass es u.U sein koennte dass das eine durch bit-rot veraenderte Daten die exakt gleiche checksumm ergeben kann...das ist moeglich aber die chance extrem klein, bei gespiegelten platten ist diese chance nomals hoch 2 kleiner.
PS: Hat sehr wohl was mit dem thema zutun, du macht BSD an weil sie lange brauchten um USB3 zu implementieren....anerkennst aber nicht das ein viel wichtigeres thema wie z.B ein gutes Filesystem in Linux nicht existent ist.
Ich vermute, dass an dieser Stelle ein guter Satz an Controllern existiert, bei denen UASP zu fehlerhaft implementiert worden ist. Das gibt's bei Peripherie häufig: Hauptsache erster auf dem Markt sein und billig. Das ist es, was die Kunden wollen. Da wird vorher auch nicht nachgeschaut, ob das Teil denn tatsächlich UASP kann. Es wird einfach gekauft, was MM/Saturn/ProMarkt/Conrad anbieten.
Ich habe ein ext. Gehäuse von DeLOCK für 2,5'-Laufwerke, welches UASP via USB3 unter Linux unterstützt. Bisher hatte ich damit auch keine Probleme.
Gibt es da entsprechende Fehlerberichte o.Ä., die über diese Macken berichten? Danke
Von Steve Ballmer am Mo, 23. Dezember 2019 um 13:46 #
Dann sind alle USB2SATA-Bridges kaputt die ich hier habe: JMicron, diverse ASmedia das sind die gängigsten die verbaut sind, unter Windows laufen die alle mit aktiviertem UAS nur unter Linux geht es nicht (mehr). USB unter Linux ist ein Trauerspiel sondersgleichen schon seit Jahren einer Dauerbaustelle an der nur rumgepfuscht wird.
Mein Beileid. Meistens liegt das aber eben auch häufig an den Controller-Herstellern, die keine Dokumentation rausrücken und die vielen Bugs unerwähnt lassen. Die kümmern sich zumeist auch nicht um die Linux-Unterstützung (siehe bspw. auch die ganzen Webcams). Deswegen sollte man die Hersteller in die Pflicht nehmen.
Wenn ich mich nicht täusche, habe ich hier einen Controller von JMicron, der bisher scheinbar ohne erkennbare Macken funktioniert.
Von Steve Ballmer am Mo, 23. Dezember 2019 um 14:48 #
Dann mach mal dmesg -w und schau mal was dort genutzt wird. Vielleicht ist es schon blacklisted (kann man selber nachträglich in /etc/mod.probe/uas.conf eintragen) und es wird automatisch usbstorage verwendet. Wenn nicht, muss nicht unbedingt ein Prob auftauchen. Das Problem ist, dass die Übertragung ab und an hängen bleibt und dann wieder aufwacht dabei wird das usbdev resetet, neu eingebunden. Inzw. ist der Treiber so intelligent nicht das dev komplett zu entfernen und richtet auch keine Datenkorruption mehr an (wohl eher Glückssache) aber es dauert eben lange wenn man was kopiert. Früher war es noch übler, da gabs immer nette Busresets, was aber kein UAS-Problem war, da es lange gar keine UAS-Implementierung gab. Hatte man z.B. Reiser oder JFS auf der USB-Platte war das FS danach komplett am Ar*, ext4 oder FAT und NTFS lies sich meistens wieder reparieren. Da das aber auch noch nur zufällig auftaucht kann es sein dass mal ein paar Stunden problemlos geht und irgendwann halt ständig diese Gedenksekunden eingelegt werden. Kopierst du nur wenig von/auf eine USB Platte merkst der Normalanwender davon auch nix. Auffällig wird es erst wenn man ungefähr abschätzt wie lange eine Kopierorgie ungefähr dauert und das dann viel länger dauert als abgeschätzt. Kopiert man viele kleine Dateien fällt es noch weniger auf da hier sowieso der Durchsatz niedriger ist
Mal zwei Kandidaten die Ärger machen: JMicron USB_3_to_SATA: USB-ID 152d:0578 JMicron USB_2_to_SATA: USB-ID 152d:2509
Die meisten ASmedia werden schon per default nicht mit UAS betrieben wenn sie angeklemmt werden, deshalb galten die auch immer als zuverlässig. Die Probleme mit denen waren nur früh genug bekannt und man die dann per default immer mit usbstorage eingebunden.
Hängen die entspr. Platten mit den entspr. Bridges schon beim booten dramn, werden sie auch öfters nicht mit uas betrieben. Klemmt man sie kurz ab und wieder an nach dem booten, werden per UAS betrieben, ausser sie sind entspr. oben als Quirk ein der uas.conf eingetragen.
Irgendwo habe ich mal gelesen, dass es mit Intel zusammenhängt. Für UAS muss man seine Treiber von Intel zertifizieren lassen, das machen die Entwickler des Linuxtreibers nicht oder wollen es nicht, ob das stimmt, keine Ahnung.
Mir war bekannt, dass da unter der Haube viel gefrickelt wird (blacklist / quirks). Ich glaube, dass ich das damals auch berücksichtigt hatte und speziell nach einem Gehäuse mit einem Controller gesucht hatte, der keine Zicken machen soll. Dabei hatte ich mich an diese Dokumentation und den Verweise darin gehalten, wenn ich mich recht entsinne. Für Konkreteres habe ich aber gerade keinen Zugriff auf das Gerät.
Ich denke, dass es damit zusammenhängt, dass die ganzen Consumer-Peripherieprodukte wie so häufig nur mit Windows getestet werden. Laut Wikipedia bietet Microsoft einen Test für Hardwarehersteller an. Intel als Hüter der USB-Spezifikation bietet bestimmt etwas Ähnliches, möglicherweise auch für die Treiberkompatibilität (nur unter Windows?). Das ist wie mit ACPI und vielen anderen komplexen unterspezifizierten Konsortienstandards. Das macht immer Probleme.
So ist man immer gezwungen das lahmere USBstorage zu verwenden, das funktioniert wenigstens und keine Aussetzer wie UAS/UASP.
> [...] geht immer noch nicht richtig und die kommen schon mit [...++] daher
Ist doch überall das gleiche Spiel. Schließe doch schonmal Wetten ab, wann irgendjemand HTTP3 doof findet und in einer spontanen Sonntagslaune HTTP4 entwickelt - und alle wie die Lemminge hinterherrennen...
Meine "Fix $WHATEVER" Einträge auf der TODO Liste nehmen seit geraumer Zeit jeder neuen Aktion den Atem. Sei es grub (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311 - nicht mein Ticket, betrifft mich aber), oder Pulseaudio auf einigen Embedded Systems, oder Tools die mit nftables noch nicht so ganz zurechtkommen, ...
Alles Dinge, die schon funktioniert haben, dann aber mit dem nächsten Ubuntu bzw. Debian nicht mehr gingen.
Die bekommen sogar die Scrollradlogik kaputt. Das tut's hier sporadisch schonmal nicht, und ich muss hinundherfokussieren, damit es wieder klappt. Wachstumsschmerz bei irgendwelchen Wayland-Anpassungen (ich hab allerdings immernoch X, weil Wayland ja _immernoch_ kein robuster und vollwertiger Ersatz zu sein scheint)?!
Desktop, Server, Embedded... Was nicht heute schon kaputt ist, wartet daruf, dass du es in deine Toolchain aufnimmst, um dann mit dem nächsten Release kaputtzugehen.
Die ideologische Komponente wäre mir da inzwischen echt wurst... Wenn es einen Weg gäbe, _sicherzustellen_, dass es keinerlei Datenabflüsse gibt, und ein paar andere Modalitäten, würde ich jetzt sofort nach dem Frühstück losgehen und ein paar Apple-Geräte kaufen.
... der Bezug zu deinem Posting: Ja - am besten nimmt man uraltes Zeug und ist bescheidener, dann hat man zumindest gewisse Chancen, dass es keiner anfasst und kaputtpratscht. Es kann halt nur irgendwann ganz verschwinden; das ist dabei wieder der Nachteil. USB Storage gibt's aber sicher noch eine Weile...
Ja, unter Linux gehen immer mal wieder Dinge kaputt. Das hat zweierlei Gründe. Einerseits werden ständig Schnittstellen 'from scratch' neu implementiert, teils mit extrem fehlerhafter oder schlich nicht existenter Abwärtskompatibilität, und andererseits werden oftmals keine LTS-Distributionen eingesetzt, wo diese nötig wären. Letzteres liegt an dem Dilemma zwischen stabiler und getesteter/verlässlicherer Software in unteren Teilen der Systemschichten und aktuelle Anwendungssoftware. (Ausnahme sind Dinge wie Kernel und Mesa etc., die aufgrund der Treiberpolitik und der Notwendigkeit der Unterstützung aktueller Hardware mitunter aktualisiert werden müssen.)
Abhilfe könnte hier eine bessere Trennung von Basissystem und Rest sein, wie etwa bei FreeBSD mit den Ports. Dann könnte es noch ein besseres Backports oder PPA-System geben. Die andere Lösung könnten AppImage, Snap oder Flatpak etc. sein, aber das lehen viele Kritiker hier in der Leserschaft ja auch wieder kompromisslos ab.
Web-Standards sind nochmal ein ganz anderes Thema außerhalb der Distributionen.
Das liegt laut Kommentar #23 scheinbar weniger an GRUB (2.02 vs 2.04) als daran, wie GRUB 2.04 in Ubuntu 19.10 con Canonical paketiert oder kaputtgefrickelt wurde. Ergo: Auf LTS-Zweigen bleiben oder Distribution wechseln, wenn's unbedingt etwas aktueller sein soll.Wie lauten denn diese Einträge? Wie lief es vorher?Hm ja, das ist blöd. Aber wer zwingt einen zum Umstieg? In LTS-Distros wird doch weiterhin iptables angeboten, oder? Über welche Werkzeuge sprechen Sie?Ubuntu und Debian bieten doch beide weiterhin iptables, oder? Wieso dann nftables nutzen?Bei welcher Aktualisierung hatten Sie die Probleme mit Pulseaudio von oben?
Im GRUB-Beispiel oben sollte man aber nicht verschweigen, dass Ubuntu 19.10 eine STS-Veröffentlichung ist.Bisher betrifft das eigentlich nur GNOME, oder? Deswegen würde ich die Kritik an GNOME und die Distributionen richten - die betreiben scheinbar kein vernünftiges QA. Erwarten können Sie das allerdings auch nur bei LTS-Veröffentlichungen.Klingt ein wenig pauschal. Ich denke, dass es viele Aktualisierungen gab, die glatt liefen/laufen. Nicht immer werden Release-Upgrades auch tatsächlich unterstützt.
Insgesamt hält sich Linux bei Regressionen inzwischen die Waage mit Windows 10
Da hilft momentan wahrscheinlich nur offline bleiben oder viel Monitoring und Filterregeln in einer vorgeschalteten Firewall verwenden. Dass das noch keine hinreichend profitable Marktlücke ist, wundert mich inzwischen ein wenig. Gerade seriöse Unternehmen mit IP, Arztpraxen und Kanzleien sollten solche Produkte doch wertschätzen und fordern.Vielleicht erlebe ich soetwas ja noch
Hi. Ja, LTS-Versionen könnten das teilweise eindämmen, das stimmt. Dass man es damit löst, wage ich aber zu bezweifeln. Man bekommt dann auch Fixes erstmal nicht. LTS-Versionen haben vielleicht weniger von den groben Schnitzern, dafür sitzt man länger auf den kleinen Ärgerlichkeiten. Ich habe bspw. mit jeder Version die Hoffnung, dass Suspend-to-RAM irgendwann wieder gescheit tut (so dass auch USB-Geräte nach Resume wieder tun, usw, usf). Außerdem ist ja Debian per se LTS-artig, und da habe ich auch Probleme (o.g. Pulseaudio, nftables, ...).
> Das liegt laut Kommentar #23 scheinbar weniger an GRUB (2.02 vs 2.04) als daran, wie GRUB 2.04 in Ubuntu 19.10 con Canonical paketiert oder kaputtgefrickelt wurde.
Dass es da auch immer handfeste technische Hintergründe gibt, ist mir auch klar. Aber "was zählt ist auf dem Platz", oder so... Am Ende helfen mir die Hintergründe ja nicht, wenn das System nicht läuft. Woran es in diesem Fall genau liegt, ist ja auch noch unklar.
>> Pulseaudio
> Wie lief es vorher?
Naja - es lief halt...
Ich starte es als systemd Service im "system mode" auf einem Banana Pi, und da macht es dann so seinen Job. Mit Debian Buster allerdings immer nur für ein Stündchen oder so. Dann hängt es sich weg, bis man den Service wieder neu startet. Das lief rock stable mit >1y Uptime vor dem Update.
Zu nftables: Debian steigt da halt gerade drauf um. Klar konnte man auch bei iptables bleiben. Hätte ich das mal getan. Überall (z.B. https://wiki.debian.org/nftables) heißt es aber, nftables ist der neue Default, und man _soll_ jetzt das benutzen, usw. Habe ich dann halt gemacht. Iptables auf Kommandozeile soll ja sogar weiter funktionieren (allerdings scheinbar nicht ganz!?) mit nftables als Backend. Und dann kommt bspw. fail2ban und kommt mit nftables einfach nicht richtig zurecht, und macht wirres Zeug. Auch libvirt benutzt es intern für VM-Networking, und ich hatte den (bisher unbestätigten) Eindruck, dass ich ein bisschen manuell nachschieben musste, bis meine Netzwerkkonfiguration damit lief. Ja, hätte ich mal nicht auf die Ratschläge gehört, und wäre bei iptables only geblieben...
>> Wachstumsschmerz bei irgendwelchen Wayland-Anpassungen
> Bisher betrifft das eigentlich nur GNOME, oder?
Hm, wäre ja schlimm genug. Kann sein. Zuletzt aufgefallen ist es mir bei Evolution. Den brauche ich halt, weil Kontact/Akonadi (hier?!) hier nicht gescheit läuft. Da hatte ich vor einigen Wochen mal meinen Rant zu abgelassen.
> Ich denke, dass es viele Aktualisierungen gab, die glatt liefen/laufen.
Mag so sein. Aber die, die nicht glatt laufen, füllen seit einer Weile meine TODO Listen auf eine Weise, die ich nicht mehr schön finde.
> Insgesamt hält sich Linux bei Regressionen inzwischen die Waage mit Windows 10
Das ist zwar auch ein bisschen pauschal, und ich weiß nicht, ob man das wirklich so sagen kann, aber wie auch immer... Windows habe ich auf der Firma, aber das wäre privat ganz sicher auch nicht mein Fall. Klar, da versuchen sie mir mit jedem Update, das ClassicShell lahmzulegen, oder mir ihren Edge aufzudrücken, Privacy-Settings zu resetten, ... auch alles Mist. Deshalb hatte ich Windows auch nicht genannt, sondern Apple.
> Da hilft momentan wahrscheinlich nur offline bleiben oder viel Monitoring und Filterregeln in einer vorgeschalteten Firewall verwenden.
Beides nicht praktikabel. So viel Monitoring kann man garnicht betreiben, insbesondere weil Datenverkehre ja nunmal auch verschlüsselt sein können, und nicht immer sauber von gutmütiger Kommunikation zu unterscheiden ist. Offline bleiben: Klar; so ähnlich kann man auch aller FOSS Fuzzyness aus dem Weg gehen. Mit den Worten von Peter Lustig: Ausschalten!
>> Ich denke, dass es viele Aktualisierungen gab, die glatt liefen/laufen.
... wobei ich auch erwähnen muss: Technisch gesehen sind das niemals Aktualisierungen. Ich installiere immer frisch neu, und habe dann ein paar Skripte, die es einrichten. Es geht dabei also nicht darum, dass vielleicht Updateprozeduren nicht funktioniert hätten.
Dass man keine Fixes bekommt, stimmt so auch nicht. Debian verfolgt hier eine sehr harte Linie, auch weil die Ressourcen fehlen und alles auf freiwilliger Basis ist. OpenSUSE Leap aktualisiert und verbessert bspw. auch Desktop-Pakete auf stabilen Entwicklungszweigen.
Ja, Debian stable bekommt LTS. Was ich bis heute noch nicht verstehe, ist, wie die es schaffen, gleichzeitig mehrere stabile Zweige zu pflegen.Wenn man weiß, was man tut, kann man da auch aktuellere Versionen einzelner Pakete oder Paketgruppen via separaten OBS-Repos aktualisieren. Und die kommen von der Distribution selbst, das sind keine Community-Repos. Im Prinzip ist das eine sinnvolle Umsetzung von dem, was Debian-Backports mMn eigentlich sein sollten. Letzteres wird noch viel zu sporadisch verwendet. (Sind die Anforderungen des Paketierens zu hoch?)
Treten die Problem mit Suspend-to-RAM auch mit LTS-Distros auf?
Bis auf die Sache mit nftables sind solche Regressionen natürlich immer ärgerlich.
Zu nftables: Ja, es ist tatsächlich ärgerlich. Aber laut dem Wiki hätten Sie das vermeiden können. Das neue nftables-Backend unterstützt ja weiterhin die alten iptables-Werkeuge und Syntax, ist also abwärtskompatibel. Zumindest soll es das sein. Oder gab es genau damit bei Ihnen Probleme?
Über Ihren Wiki-Verweis bin ich auf das nftables-Wiki gestoßen. Dort heißt es, dass fail2ban damit bereits klarkäme. Auf der Seite von fail2ban sind alle Tickets mit 'nftables' geschlossen. Die Unterstützung wurde hiermit hinzugefügt. Wenn man das so ließt, wirkt das ziemlich unausgegoren, rudimentär oder experimentell. Dass die das so veröffentlichen, ist nicht gerade vertrauenserweckend und eigentlich sogar peinlich für ein Sicherheitswerkzeug.
Unabhängig davon halte ich von fail2ban nicht viel. Es nützt nichts gegen DDoS oder die effektivste Methode: 'social engineering'. Snort fand ich immer ganz gut und ausgereift. Das läuft auch nicht nur unter Linux.
Haben Sie das mal ausprobiert?
Ich kann inzwischen nicht mehr guten Gewissens zu Debian raten. Es ist zu viel inkonsistentes und komplexes Gefrickel am Werk. Zu viele Köche verderben den Brei. Das Projekt tut sich mit sehr wichtigen technischen Entscheidungen extrem schwer, und praktiziert lieber ellenlange und verwüstende Diskussionen, und hält sich endlos an internen Reibereien auf. Siehe die aufflammende GR-Debatte um init/systemd. Ich frage mich, wie unter diesen Bedingungen überhaupt noch effizient etwas Vernünftiges entstehen kann.
In diesem Sinne: Haben Sie es denn mal mit den kostenlosen Varianten von den kommerziellen Distributoren versucht, sprich OpenSUSE oder gleich CentOS? Sie könnten auch auf Ubuntu LTS verweilen bis die Unterstützung ausläuft. Eventuell wäre sogar FreeBSD etwas für Sie.
>> LTS-Versionen haben vielleicht weniger von den groben Schnitzern, dafür sitzt man länger auf den kleinen Ärgerlichkeiten.
> Was ist Ihnen denn lieber?
Jaja, schon richtig. Bei LTS-Versionen zu bleiben, könnte durchaus eine Lehre sein, die ich aus dem Ganzen jetzt ziehe. Nur damit allein wird halt auch nicht alles gut. Meine Debian-Probleme löst es nicht. Und warum das Grub-Problem nicht zufällig auch eine LTS hätte treffen können, weiß ich auch nicht. Auch da gibt es ja neue Paketversionen, und da kann es sich auch einschleichen. Nur sind sie vielleicht mit den Versionssprüngen und Änderungen in der Paketierung vielleicht vorsichtiger. Das _könnte_ helfen.
> Treten die Problem mit Suspend-to-RAM auch mit LTS-Distros auf?
Ja, gut funktionierendes Suspend-to-RAM hatte ich hier schon lange nicht mehr. Das ist natürlich auch immer ein Hardwarethema. Das ist aber immer ein Aspekt, der mich bisher auch immer von den LTS-Versionen weggelockt hat; nach dem Motto "Dann installiere ich mal das neue Ubuntu, vielleicht tuts das dann auch endlich mal wieder". Sauberer Shutdown der Desktopsitzung ist auch so eine Sache, wo ich mir immer Verbesserungen verspreche. Das stolpert manchmal auch eher so vor sich hin, als dass es nach einem durchdachten Ablauf aussieht. Wegen sowas habe ich die LTS-Schiene in der Vergangenheit dann immer wieder verlassen. War i.d.R. unnötig, und ich habe draus gelernt.
> Zu nftables: Ja, es ist tatsächlich ärgerlich. Aber laut dem Wiki hätten Sie das vermeiden können. Das neue nftables-Backend unterstützt ja weiterhin die alten iptables-Werkeuge und Syntax, ist also abwärtskompatibel. Zumindest soll es das sein. Oder gab es genau damit bei Ihnen Probleme?
Ich hätte es vermeiden können, wenn ich den Ratschlägen im Debian-Wiki mißtraut hätte, und einfach bei iptables geblieben wäre, ja. Nun habe ich dem aber geglaubt (wenn die konservativen Debianer das schon anraten), und habe zu nftables gewechselt. Und als alles soweit war, und einige Wochen ins Land gestrichen sind, fielen mir die ersten Probleme etwa mit fail2ban auf. Die Version in Buster war definitiv an einer relevanten Stelle buggy, und ich musste in der Config ein bisschen tricksen. Das kostet aber alles viel Zeit, und ist auch sonst ärgerlich. Es ist auch klar, dass mein dirty workaround mit der Folgeversion wieder bedroht sein wird. Es wirkte alles beta-mäßig. Ich sehe in deinem Link gerade: 'Protocol "all" is not supported, only "tcp" and "udp". Should be relatively easily fixable with shell conditionals for iptables-allports, but I'm lazy.' - Ja, das hatte ich nach einiger verbröselter Zeit auch gemerkt. :-/
Die iptables-Werkzeuge funktionieren wohl auf dem nftables Backend, aber auch nur eingeschränkt. Ich hatte auch schon Firewallregeln, wo iptables dann nur sinngemäß nur noch gesagt hat "Deinen nft-Kram kann ich nicht mehr abbilden, nimm bitte jetzt direkt nftables". Als fail2ban wieder vorwärts humpelte, war es mir aber erstmal wieder egal. Die TODO-Liste solcher Dinge ist halt lang. :-/
> Unabhängig davon halte ich von fail2ban nicht viel. Es nützt nichts gegen DDoS oder die effektivste Methode: 'social engineering'.
Ja, vielleicht sollte ich irgendwann auch mal nach einem Replacement für fail2ban suchen. Snort ist besser? Muss ich dann mal schauen. Wobei man ja gegen DDoS nicht so wirklich viel tun kann, oder? Und Social Engineering ist für meinen Anwendungsfall auch kein Thema. Aber wenn es den Rest gescheit macht, ist das prima. Steht jetzt auf meiner Liste.
> Ich kann inzwischen nicht mehr guten Gewissens zu Debian raten. Es ist zu viel inkonsistentes und komplexes Gefrickel am Werk.
Das ist schade, denn ich hatte schon überlegt, meine Ubuntus auch durch Debians zu ersetzen. Ich habe aber auch schon von anderen Stellen gehört, dass man sich davon nicht zuviel versprechen sollte. :-/
> In diesem Sinne: Haben Sie es denn mal mit den kostenlosen Varianten von den kommerziellen Distributoren versucht, sprich OpenSUSE oder gleich CentOS?
Lange nicht mehr. Ich habe halt heutzutage eine doch recht umfangreiche Sammlung an Skriptchen, die bspw. auch Installationen (debian preseed-basiert) und Systemeinrichtung automatisieren, und die nur unter enormem Aufwand umzustellen sind. Aber ja, lange kann ich mir dieses Spielchen nicht mehr ansehen, und wenn ich irgendwann endgültig die Schnauze voll habe, und die Gewissheit habe, dass das Gras woanders wirklich grüner ist, dann werde ich mal diesen Schritt machen. Auch BSDs kommen dann prinzipiell in Frage. Aber ich müsste es dann sorgfältig prüfen, um nicht nach Monaten an Migrationsarbeiten wieder vor dem selben Scherbenhaufen zu stehen. Ich befürchte auch, sehr viele Probleme hat man einfach mit der Qualität der Software selbst, und nicht mit der Integration in die jeweiligen Distris. Das mag jetzt bei dem Grub-Fall anders sein.
was meinst du wie lange Freebsd für USB4 braucht? 1 Jahr 10 Jahre?
Das weiß ich nicht. Das hängt vom Bedarf und den Ressourcen ab. Und obwohl sich der Artikel um die Unterstützung von USB4 dreht, war das ja kein explizites Kriterium in Josef Hahns Kritik. Oder habe ich das überlesen?
Ich wünsche Ihnen schöne Festtage.
Wielange glaubst du bis der linux-kernel ein bit-rot sicheres filesystem bekommt 1jahr 16 jahre?
Erstens hat das nichts mit dem Diskussionsthema zu tun.
Zweitens gibt es kein Dateisystem, welches gegen Bit-Rot sicher gefeit wäre. Es ist nach dem bisherigen wissenschaftlichen Kenntnisstand der Menschheit anzunehmen, das ein solches Dateisystem in unserer Welt nicht existieren kann. Insofern lautet die Antwort 'unendlich viele Jahre' (kurz: nie), und dies gilt wahrscheinlich nicht nur im Bezug auf Linux sondern sogar für jede beliebige Implementierung innerhalb dieser Welt.
Doch gibt es ZFS... Was schreibst Du da fuer pseudo-physik-zeugs? Sicherlich kann ein solches Dateisystem existieren (gib bitte einen grund an weshalb dies nicht so sein soll). Du spielst wahscheinlich darauf an, dass es u.U sein koennte dass das eine durch bit-rot veraenderte Daten die exakt gleiche checksumm ergeben kann...das ist moeglich aber die chance extrem klein, bei gespiegelten platten ist diese chance nomals hoch 2 kleiner.
PS: Hat sehr wohl was mit dem thema zutun, du macht BSD an weil sie lange brauchten um USB3 zu implementieren....anerkennst aber nicht das ein viel wichtigeres thema wie z.B ein gutes Filesystem in Linux nicht existent ist.
Ich vermute, dass an dieser Stelle ein guter Satz an Controllern existiert, bei denen UASP zu fehlerhaft implementiert worden ist. Das gibt's bei Peripherie häufig: Hauptsache erster auf dem Markt sein und billig. Das ist es, was die Kunden wollen. Da wird vorher auch nicht nachgeschaut, ob das Teil denn tatsächlich UASP kann. Es wird einfach gekauft, was MM/Saturn/ProMarkt/Conrad anbieten.
Ich habe ein ext. Gehäuse von DeLOCK für 2,5'-Laufwerke, welches UASP via USB3 unter Linux unterstützt. Bisher hatte ich damit auch keine Probleme.
Gibt es da entsprechende Fehlerberichte o.Ä., die über diese Macken berichten? Danke
Dann sind alle USB2SATA-Bridges kaputt die ich hier habe: JMicron, diverse ASmedia das sind die gängigsten die verbaut sind, unter Windows laufen die alle mit aktiviertem UAS nur unter Linux geht es nicht (mehr). USB unter Linux ist ein Trauerspiel sondersgleichen schon seit Jahren einer Dauerbaustelle an der nur rumgepfuscht wird.
Mein Beileid. Meistens liegt das aber eben auch häufig an den Controller-Herstellern, die keine Dokumentation rausrücken und die vielen Bugs unerwähnt lassen. Die kümmern sich zumeist auch nicht um die Linux-Unterstützung (siehe bspw. auch die ganzen Webcams). Deswegen sollte man die Hersteller in die Pflicht nehmen.
Wenn ich mich nicht täusche, habe ich hier einen Controller von JMicron, der bisher scheinbar ohne erkennbare Macken funktioniert.
Dann mach mal dmesg -w und schau mal was dort genutzt wird. Vielleicht ist es schon blacklisted (kann man selber nachträglich in /etc/mod.probe/uas.conf eintragen) und es wird automatisch usbstorage verwendet. Wenn nicht, muss nicht unbedingt ein Prob auftauchen. Das Problem ist, dass die Übertragung ab und an hängen bleibt und dann wieder aufwacht dabei wird das usbdev resetet, neu eingebunden. Inzw. ist der Treiber so intelligent nicht das dev komplett zu entfernen und richtet auch keine Datenkorruption mehr an (wohl eher Glückssache) aber es dauert eben lange wenn man was kopiert. Früher war es noch übler, da gabs immer nette Busresets, was aber kein UAS-Problem war, da es lange gar keine UAS-Implementierung gab. Hatte man z.B. Reiser oder JFS auf der USB-Platte war das FS danach komplett am Ar*, ext4 oder FAT und NTFS lies sich meistens wieder reparieren.
Da das aber auch noch nur zufällig auftaucht kann es sein dass mal ein paar Stunden problemlos geht und irgendwann halt ständig diese Gedenksekunden eingelegt werden. Kopierst du nur wenig von/auf eine USB Platte merkst der Normalanwender davon auch nix. Auffällig wird es erst wenn man ungefähr abschätzt wie lange eine Kopierorgie ungefähr dauert und das dann viel länger dauert als abgeschätzt. Kopiert man viele kleine Dateien fällt es noch weniger auf da hier sowieso der Durchsatz niedriger ist
Mal zwei Kandidaten die Ärger machen:
JMicron USB_3_to_SATA: USB-ID 152d:0578
JMicron USB_2_to_SATA: USB-ID 152d:2509
Die meisten ASmedia werden schon per default nicht mit UAS betrieben wenn sie angeklemmt werden, deshalb galten die auch immer als zuverlässig. Die Probleme mit denen waren nur früh genug bekannt und man die dann per default immer mit usbstorage eingebunden.
Hängen die entspr. Platten mit den entspr. Bridges schon beim booten dramn, werden sie auch öfters nicht mit uas betrieben. Klemmt man sie kurz ab und wieder an nach dem booten, werden per UAS
betrieben, ausser sie sind entspr. oben als Quirk ein der uas.conf eingetragen.
Irgendwo habe ich mal gelesen, dass es mit Intel zusammenhängt. Für UAS muss man seine Treiber von Intel zertifizieren lassen, das machen die Entwickler des Linuxtreibers nicht oder wollen es nicht, ob das stimmt, keine Ahnung.
Mir war bekannt, dass da unter der Haube viel gefrickelt wird (blacklist / quirks). Ich glaube, dass ich das damals auch berücksichtigt hatte und speziell nach einem Gehäuse mit einem Controller gesucht hatte, der keine Zicken machen soll. Dabei hatte ich mich an diese Dokumentation und den Verweise darin gehalten, wenn ich mich recht entsinne.
Für Konkreteres habe ich aber gerade keinen Zugriff auf das Gerät.
Ich denke, dass es damit zusammenhängt, dass die ganzen Consumer-Peripherieprodukte wie so häufig nur mit Windows getestet werden. Laut Wikipedia bietet Microsoft einen Test für Hardwarehersteller an. Intel als Hüter der USB-Spezifikation bietet bestimmt etwas Ähnliches, möglicherweise auch für die Treiberkompatibilität (nur unter Windows?).
Das ist wie mit ACPI und vielen anderen komplexen unterspezifizierten Konsortienstandards. Das macht immer Probleme.
Lieber noch auf den eindeutigen Nachfolger USB4.1 gen 2x2 2.0 warten, der hat noch mehr drauf
Meinst du jetzt die A, B oder die A micro-E Variante?
Danke USB-Konsortium.
Physikalische stecker werden nicht in Software programiert.