Von Sil53r Surf3r am Mi, 7. August 2013 um 14:42 #
> Nur weil bei euch alles tutti ist, heißt es nicht, dass das Programm optimal ist.
Dann sollte man es optimieren. Das ist kein überzeugendes Argument für einen Fork. (Die genannten Vorwürfe, Inflexibilität und Trägheit im Originalprojekt, können es sein. Wenn sie gerechtfertigt sind.)
> Und die in der News beschriebene Tatsache, dass das MPlayer-Projekt an veraltetem Code festhält habt ihr wohl beide überlesen.
Nein. "Veraltet" ist Definitionssache. Heißt oft: ausgetestet und stabil. Kann heißen: schimmelt schon. Kann auch vieles mehr heißen - von dem das meiste dann weniger mit dem Code und dessen Qualität, als mit den Menschen zu tun hat, die ihn entwickeln. Von daher ist es durchaus angebracht, solchen Etiketten in einer Kurzmeldung mit einer gewissen Skepsis zu begegnen.
Mag sein, so oft ich mir MPlayer in den letzten 10 Jahren angesehen habe, hatte er bei all seinen Stärken auch immer die Schwäche, ziemlich kapriziös zu wirken. Kein anderer Medienplayer ist bei mir immer wieder so böse abgeschmiert und lange Jahre konnte ein MPLayerabsturz auch das Audiosystem ziemlich übel beeinflussen.
Jetzt habe ich ihn testweise wieder mal göffnet und siehe: eine Videodatei, die VLC problemlos abspielt, wird nur als Ton wiedergegeben und nach ein paar Sekunden geht MPLayer ganz ein mit irgendwelchem Gejammer über nicht vorhandene VDPAU-Module.
Kurz: es würde mich nicht wundern, wenn es im Code tatsächlich vieles zu modernisieren und aufzuräumen gäbe.
Von Sil53r Surf3r am Mi, 7. August 2013 um 23:29 #
Was ich mir, glaube ich, gewünscht hätte, wäre ein kurzer Satz gewesen, weshalb man eine Neuentwicklung verworfen hat.
Wenn es um die Codebasis so schlecht bestellt ist, warum dann noch einzelne Speichen aus dem eiernden Rad pflücken, anstatt gleich ein schönes neues zu dengeln?
Für den Anwender sieht es vorerst so aus, als gäbe es nun drei Versionen - aber keine davon tut's richtig, und untereinander inkompatibel sind sie teilweise auch noch. Bei der Fülle vorhandener Audioplayer muss es schon gute Gründe für einen solchen Schritt geben. Die hätten mich interessiert, denn die Vorgehensweise scheint mir recht energieintensiv.
No offense meant. Ich werde die Entwicklung sicherlich mitverfolgen und wünsche dem Projekt alles Gute.
> Nur weil bei euch alles tutti ist, heißt es nicht, dass das Programm optimal ist.
Dann sollte man es optimieren. Das ist kein überzeugendes Argument für einen Fork. (Die genannten Vorwürfe, Inflexibilität und Trägheit im Originalprojekt, können es sein. Wenn sie gerechtfertigt sind.)
> Und die in der News beschriebene Tatsache, dass das MPlayer-Projekt an veraltetem Code festhält habt ihr wohl beide überlesen.
Nein. "Veraltet" ist Definitionssache. Heißt oft: ausgetestet und stabil. Kann heißen: schimmelt schon. Kann auch vieles mehr heißen - von dem das meiste dann weniger mit dem Code und dessen Qualität, als mit den Menschen zu tun hat, die ihn entwickeln. Von daher ist es durchaus angebracht, solchen Etiketten in einer Kurzmeldung mit einer gewissen Skepsis zu begegnen.
>Heißt oft: ausgetestet und stabil.
Mag sein, so oft ich mir MPlayer in den letzten 10 Jahren angesehen habe, hatte er bei all seinen Stärken auch immer die Schwäche, ziemlich kapriziös zu wirken. Kein anderer Medienplayer ist bei mir immer wieder so böse abgeschmiert und lange Jahre konnte ein MPLayerabsturz auch das Audiosystem ziemlich übel beeinflussen.
Jetzt habe ich ihn testweise wieder mal göffnet und siehe: eine Videodatei, die VLC problemlos abspielt, wird nur als Ton wiedergegeben und nach ein paar Sekunden geht MPLayer ganz ein mit irgendwelchem Gejammer über nicht vorhandene VDPAU-Module.
Kurz: es würde mich nicht wundern, wenn es im Code tatsächlich vieles zu modernisieren und aufzuräumen gäbe.
Was ich mir, glaube ich, gewünscht hätte, wäre ein kurzer Satz gewesen, weshalb man eine Neuentwicklung verworfen hat.
Wenn es um die Codebasis so schlecht bestellt ist, warum dann noch einzelne Speichen aus dem eiernden Rad pflücken, anstatt gleich ein schönes neues zu dengeln?
Für den Anwender sieht es vorerst so aus, als gäbe es nun drei Versionen - aber keine davon tut's richtig, und untereinander inkompatibel sind sie teilweise auch noch. Bei der Fülle vorhandener Audioplayer muss es schon gute Gründe für einen solchen Schritt geben. Die hätten mich interessiert, denn die Vorgehensweise scheint mir recht energieintensiv.
No offense meant. Ich werde die Entwicklung sicherlich mitverfolgen und wünsche dem Projekt alles Gute.