Fragen? Antworten! Siehe auch: Alternativlos
Spannend an dem finde ich vor allem den Teil hier:
[Feel free to send this to the FreeBSD lists or whatever to get it fixed. I honestly can't be bothered making a throwaway email and going through the subscription process, nor do I want "TheGrandSchlonging" to appear in FreeBSD commit logs.]
TheGrandSchlonging is sein Reddit-Username.Und inhaltlich geht mir das ja ähnlich. Ich ärgere mich jedes Mal, wenn ich irgendwo einen Bug melden will, und die mich erstmal durch irgendeine Account-Prozedur durchtrichtern wollen. Das ist ja nicht so, als bin ich hier der Bittsteller, der was von euch will. Im Gegenteil. Ihr wollt was von mir. Nämlich dass ich euch von dem Bug erzähle, den ich gefunden habe. Also hört mal bitte auf, mir künstliche Barrieren in den Weg zu legen.
Ich hab eh schon vor Jahren völlig aufgehört, nach Bugs in kommerziellen Produkten zu suchen, außer ich werde dafür bezahlt. Und dieser Account-Bullshit und wie die Leute in den Bugtrackern dann teilweise mit ihren Usern umgehen, das ist echt abschreckend und führt nicht zu mehr gemeldeten Bugs.
Aktuelles Beispiel, auch wenn das kein Security-Bug ist, war für mich mpv. mpv ist das Nachfolge-Projekt von mplayer. Mit mplayer oder mpv spiele ich seit gefühlt 20 Jahren meine Video-Dateien ab und hören mir meine mp3-Sammlung unter Linux an. Das Programm ist für mich also eher wichtig. Ich hatte mir ja kürzlich einen Acer Swift 1 gekauft, weil der besonders gute Akkulaufzeit hat und sich besonders gut zum Video-Abspielen eignet dank Hardware-Decoding von H.264, H.265 inklusive 10-Bit Farbtiefe, und VP9. Linux unterstützt das. mpv unterstützt das. Ich spiele also mit mpv ein Video ab und kriege massives Stottern und Frame Dropping. Das habe ich sehr vielen Jahren nicht mehr erlebt, dass ein Player Frames droppt, weil die Performance nicht reicht. Da kommt dann noch so eine von-oben-herab-Fehlermeldung, dass dann wohl das System kacke sei, auf dem man gerade arbeitet, oder zumindest die Treiber, die man verwendet.
Ich habe also vlc probiert, und das flutscht. Da stottert nichts. Stellt sich raus: mpv hat zwar -vo vaapi und -vo xv (dekodiert mit CPU aber macht Farbraumkonvertierung und Skalierung in Hardware) und kann damit stotterfrei dekodieren, aber besteht per Default auf -vo gpu, und der macht irgendwelchen Shader-Kram, der auf Gamer-Hardware prima tut und womöglich auch bessere Qualität liefert (nicht dass ich das hätte beobachten können), und zusätzliche Filter erlaubt, die ich noch nie benutzt habe. Aber auf dem Gemini Lake Atom-Derivat in dem Swift 1 flutscht das halt nicht. Ich habe also einen Bug gefiled, dass sie in der Fehlermeldung möglicherweise auf -vo vaapi hinweisen könnten statt dem Benutzer die am wenigsten hilfreiche Meldung aller Zeiten zu geben ("du hast wohl Scheiß Hardware").
Es gibt auch ein mpv-Wiki, wo drinsteht, dass niemand jemals etwas anderes also -vo gpu nehmen soll, weil das so geil ist, und andere Alternativen werden dort auch gar nicht erwähnt.
Nun kann mir das ja eigentlich alles egal sein. Ich hab ja die Lösung gefunden, nämlich -vo vaapi (damit spielt das Gerät auf Akku über 10h am Stück Video ab und hat dabei eine CPU-Auslastung von unter 5%). Aber das Projekt liegt mir halt am Herzen. Schreiben die zurück: Deine Hardware ist kacke, nein wir ändern das nicht, und wenn wir da ranschreiben, dass vaapi weniger Strom verbraucht als gpu, dann benutzt ja niemand jemals gpu.
Ich kommentierte dann noch, dass wenn sie das nicht fixen, dass die Kunden dann halt zu vlc abwandern, wenn mpv "zu lahm" ist, was es ja nicht wirklich ist, aber es sieht halt so aus. Und sie sollen mal lieber ehrlich sein mit ihren Kunden. Daraufhin meinte dann jemand, ich könne ja gehen, wenn mir mpv nicht gefällt, und machte den Bug zu.
Liebe Leser, wenn ihr jemals in der Situation seit, einen Bugtracker zu pflegen, dann macht lieber gar nichts als euch so zu verhalten. User verprellen ist so das schlechteste, was man tun kann. Fragt euch mal selbst, ob ihr einem Projekt helfen wollen würdet, das euch beim ersten Versuch so den Stinkefinger ins Gesicht hält.
Ich erwähne das, weil FreeBSD so das Gegenteil davon ist. FreeBSD, PostgreSQL und LLVM sind Projekte, die mit Bugreports professionell, zeitnah und sauber umgehen, und wenig überraschend sind die auch echt erfolgreich am Ende. Projekte wie gcc, bei denen auf dem Bugtracker häufig eher User-Abwehr statt Bug-Beseitigung betrieben wird, geraten halt ins Hintertreffen. Und mpv, wenn es sich so verhält, wird als Privatprojekt von irgendeinem Frickel-Nerd in seinem Keller enden, das niemand kennt und niemand benutzt. Schade eigentlich, denn die verspielen da über Jahre aufgebautes Karma.
Update: Ein Einsender kommentiert:
es wird deutlich darauf lhingewiesen (https://www.freebsd.org/security/), dass security-related Krams per Mail an secteam@ berichtet werden soll/kann. Der Link steht auch im Default-motd, sollte also jeder FreeBSD-User mal gesehen haben :)
Oh das wusste ich nicht. Dann gibt es in der Tat nicht so viele Ausreden, den Bug auf reddit zu posten statt den FreeBSDlern zu mailen.
Update: mpv hat den Bug nicht nur geschlossen sondern als "too heated" gelockt, womit weitere Kommentare von Externen nicht mehr erlaubt sind. Gute Arbeit, Jungs. So strahlt man Souveränität aus.
Update: Haha, geil, jetzt werde ich da auch noch als Lügner bezeichnet. Natürlich schön nachdem man mir die Kommentiermöglichkeit weggenommen hat. Tolles Projekt, dieses mpv. Da will man doch mithelfen!1!!
Aber ein Detail noch: In der Zwischenzeit hat sich gezeigt, dass auch -vo gpu flutschen kann, wenn man bloß auch noch --hwdec=auto macht. Ja, ich bin genau so belustigt wie ihr. Die haben eine auto-Option für den Hardware-Decoder und machen die dann nicht an. Der Lacher ist ja, dass -vo xv auch Software-Decoding macht und bei weitem schnell genug ist. Wir wissen also zwei Dinge jetzt: Die CPU ist schnell genug für Software-Decoding, und das OpenGL ist schnell genug fürs Rendering. Aber in Kombination verkackt mpv es. Ich hätte ihnen ja beim Debuggen geholfen. Aber ich helfe nur Projekten, die ihren Usern Menschenwürde zugestehen.