wenn du linux laufen hast, kannst bestimmt auch den linux decoder benutzen ode?
wenn du linux laufen hast, kannst bestimmt auch den linux decoder benutzen ode?
Die Threads, die ich gefunden habe, verwiesen alle direkt oder indirekt auf diesen hier.
Dann muß ich wohl noch weiter suchen ...
Das kann noch eine Weile dauern, da ich keine Lust habe in drei Wochen wieder einen neuen Decoder zu bauen werde ich jetzt erst mal warten. Es gibt da zur Zeit noch Überarbeitungsbedarf an den Verfahren.Zitat von MKay
Deswegen würde mich interessieren, ob du evtl. schon eine gewisse Vorstellung hast, wann dein Decoder für Linux fertig sein wird?
In meinem LinOTR fehlt eigentlich hauptsächlich nur noch der Cutlist und Decoder-Teil, deswegen würde mich interessieren, wie lange ich warten müsste
BSD heißt man kann verwenden wie ich möchte. Das tut aber nichts zur Sache, da es wahrscheinlich auf eine Programmkombi Komandozeilendecoder + GUI rausläuft.
Das wird zwar jetzt off-topic, aber ich wollte es nur kurz anmerken: Ich glaube mich erinnern zu können, daß man Qt unter QPL mit Code unter BSD-Lizenz linken darf. Die QPL fordert aber auch, daß man den Quellcode weitergibt - was dann wieder mit BSD nicht kompatibel wäre. Weiß also nicht mehr genau, wie die Lizenzlage aussieht.
Aber nur mit der BSD-3-clause Lizenz, die 4-clause-Variante ist mit der GPL technisch gesehen inkompatibel.
Für Qt gibt es afaik auch kommerzielle lizenzen, aber damit habe ich mich nie wirklich beschäftigt
Die Variante ist zum Glück so gut wie tot. Unter BSD versteht man heutzutage eigentlich immer die 3-clause.
Ja, gibt es. Aber schau Dir mal die Preise an :).
Ich halte es nach wie vor für bescheuert, das GUI unbedingt auf einem Kommandozeilendings aufsetzen zu wollen. Da gibt es eine Closed-Source Decoder-DLL, die dann direkt von den Decoderinterfaces genutzt wird. Viel schöner, als da groß mit Kommandozeilenkrams rumfuchteln zu müssen.
Ich denke, Deine Einstellung dazu liegt an einem Mißverständnis. Die eigentliche Arbeit wird von einem Dekoderkern erledigt, der womöglich closed source ist und darüber sitzt eine GUI - soweit stimmen wir überein.
Ob der Dekoderkern nun ein Kommandozeilenprogramm oder eine DLL (shared library unter *NIX) ist, ist eher ein technisches Detail. Für die meisten Benutzer macht es *keinen* Unterschied, denn sie sehen nur die GUI und die Schnittstelle zwischen GUI und Dekoder ist für sie völlig uninteressant.
Daß ein Kommandozeilenprogramm besser ist, hat eine Vielzahl von Gründen. Dazu zählt etwa, daß man ihn halt von der Kommandozeile nutzen kann, wenn man will - mehr Flexibilität für Poweruser also. Auch hat man so einen Prozeßtrennung, was die Speicherbereiche von GUI und Dekoder voneinander abgrenzt. Weiter entspricht so eine Aufteilung auch der *NIX Philosophie und macht etwa Debugging einfacher. Und schließlich vermeidet man auch Lizenzprobleme, weil GUI und Dekoder nicht miteinander gelinkt werden.
Wenn Du ein Benutzer bist, der eine GUI will, ist der Unterschied zwischen DLL und Kommandozeilendekoder für Dich also egal. Für Poweruser und Programmierer ist ein Kommandozeilenprogramm besser. Damit sollte die Entscheidung einfach sein :).
So, um die Dieskussion zu einem Ende zu bringen: QT gibt es in zwei Ausführungen, nämlich OpenSource (GPL) und kommerziell (BSD). Da der Decodercode wahrscheinlich geheim bleibt wird es also einen Kommandozeilendecoder geben und eine seperate GUI! Für eine komplette Implementierung müsste man ein anderes Toolkit nehmen (z. B. wxWindows LGPL).
Seperates GUI - ok. Ich würde aber nach wie vor auch den Kommandozeilendecoder vom Decodercode trennen.*mich wiederhol*
Berechtigungen
