Da hast du recht. Danke!
Da hast du recht. Danke!
Gruß
PeGu
Ob das Archiv sich selbst entpackt, oder ob man ein Archivprogramm hat, ist wohl nicht sooooo furchtbar kompliziert für Newbies. Ich könnte mir vorstellen, dass es die Bibliotheken sind, die das Problem darstellen. Jetzt, wo du das ansprichst, könnte man das vielleicht so lösen wie Skype das macht? Eine rpm-Lösung für die Standard-Anwender mit geringen Kenntnissen, und tar.bz2 mit bzw. ohne eingelinkte Bibliotheken für die, die sich ihr System selbst pflegen möchten?
http://www.skype.com/intl/de/download/skype/linux/
Mr. S, wie wär das mit den beiden tar-Lösungen? Wäre das nicht einfacher für dich und genauso bequem für den User? Ich mein, ein rpm oder deb oder sonst ein Paket schnürt sich ja auch nicht von allein?
Gruß
PeGu
@PeGu
Das muss ich erst mal ausprobieren, wie das alles so funktioniert. Bisher habe ich nämlich noch nie meine Linux-Programme verpacktDie Linux-Programme die ich bisher geschrieben habe laufen nämlich als Cron-Jobs auf einem Server, die werden nicht weitergegeben. Aber wenn ich Fragen habe, weiss ich ja wen ich fragen kann, oder?
P.S.: Es werden CURL und eine GUI-Lib benötigt. Was ich für eine GUI nehme weiss ich noch nicht (KDE, wxWindows, QT oder GTK).
Hm, da hab ich mich in was reinmanoevriert...
Ich habe auch noch nie ein Programm verpackt (bin auch alles andere als Programmierer). Ich browse aber für mein Leben gerne rpm-Archive, und gehe auf die Suche nach libs.
So wie ich deinen Post verstehe, läuft es wohl auf eine ELF-Datei raus mit dem Decoder und ein GUI-Script. Curl und Gui-Libs entweder dynamisch (da ist das Problem mit der Größe, ist aber einfach) oder statisch (klein, evtl. mit Problemen fürs configure-Skript) mit drin. Wenn du möchtest, packe ich gerne Testversionen in meine Sandbox und meckere über alles, was nicht klappt.
Gruß
PeGu
Da würde noch die Auswahl 'Andere Linux Distribution' fehlen
Momentan verwende ich den konsolen-original-decoder in nem kleinen bash-skript.
source ebuilds würden wohl von Anfang an ausscheiden, aber gegen Binaries hätte ich nichts - wobei der Aufwand für ein portage-overlay (portage ist gentoos paketverwaltung) sicher höher wäre als für einen kleinen tarball.
Andere Frage: Wäre das lizenztechnisch überhaupt sauber? Immerhin linkst du dein Programm gegen (L)GPL-Libs (libc?)?
Edit: Ach ja: Ganz vergessen: Ich verwende Gentoo Linux
Um das ganze DistributionsUNabhaengig fuer Linux zu machen empfehle ich einfach /usr/local/.... (bin,lib,etc). Das sollte dann eigentlich mit so ziemlich allen Distris ohne PATH-Gefummel klappen.
KDE als Basis fuer die GUI wuerde ich nicht empfehlen, da meckern dann die GNOME, etc User. Mit GTK,wxW oder QT bist du da sicher besser bedient, das ist weniger spezifisch.
Alles unter der Annahme, das du es eben, wie selber geschrieben, moeglichst Anfaengerfreundlich machen willst. Ein tar.gz mit entsprechendem Installscript duerfte da imo gut klappen. Sobald du dich naemlich auf RPM, deb, pak.... einschiesst wird irgendwer wieder Probleme haben ;-) Es koennen dir ja theoretisch dann immernoch User dabei helfen, Distributionspakete daraus zu machen, die zusaetzlich angeboten werden...
Bezueglich des Libverlinkens hab ich auch nicht so die tiefgreifende Ahnung aber ich denke statisch muesste besser sein, weniger Libprobleme
Was die Lizenzsache angeht, gut da bin ich mir auch nicht so sicher aber gegen GPL Libs zu verlinken sollte kein Thema sein, da haetten es sonst viele Kommerzielle Linux-SW Anbieter Sorgen... Wenn du aber GPL Code in deiner Software einbaust, musst du natuerlich den Code freigeben...
Ich hoffe das klingt jetzt nicht zu Arrogant, ist mein erstes Post hier ;-)
So, dann schreibe ich auch mal kurz mein Betriebssystem mit rein. Ich dekodiere ausschließlich unter FreeBSD. Der Linuxdekoder läßt sich bei mir zwar starten, hat dann aber Probleme beim Netzwerkzugriff, kommt also nicht an den Schlüssel und funktioniert folglich nicht. Auch mit Wine und den Windowsdekodern hatte ich irgendwie kein Glück.
Ich benutze einen selbstgeschriebenen Dekoder - keine 200 Zeilen C++ und äußerst zuverlässig. Anders als die meisten anderen Dekoder legt meiner die Zieldatei zuerst in voller größe an und wenn das schiefgeht (kein Platz / kein Schreibzugriff), dann wird erst gar nicht dekodiert. Wundert mich immer, daß andere Dekoder das nicht machen.
Wenn jetzt der neue Algorithmus kommt, werde ich bei FreeBSD bleiben und wohl einen neuen Dekoder schreiben, denn ich denke kaum, daß FreeBSD es in die Top 3 der ünterstützten Betriebssysteme schafft :).
Hey, es gibt erstaunlich viele FreeBSD-Anhänger, sag das nicht. Leider kann man nicht mehr als 10 Umfragepunkte einbauen.
Das Lizenzproblem ist eigentlich keins, da die libc von FreeBSD z. B. unter der BSD-Lizenz läuft, die den Einsatz in Closed-Source zuläßt. glibc steht unter LGPL, die auch begrenzt in Closed-Source eingesetzt werden kann. Das gleiche gilt auch für die verwendeten C++-Bibliotheken.
Ich verwende an Bibliotheken nur CURL (macht der offizielle Dekoder ja auch) und OpenSSH (weil ich zu faul war, Blowfish selbst zu implementieren :). Beides ist von der Lizenz her kein Problem.
Ich würde meinen Quellcode gerne unter der BSD-Lizenz freigeben, weil ich das aus Prinzip für richtig halte. Aber ich verstehe auch, daß OTR gute Argumente braucht, falls mal wieder irgendwer gegen sie klagen will und will denen nicht in den Rücken fallen. Deswegen habe ich meinen Quellcode bisher für mich behalten und werde es auch weiter tun.
Mir fällt noch was zu dem neuen Dekoder ein: Wenn Du willst, können wir bei dem Frontend dafür zusammenarbeiten, so daß Du einen Linux- und ich einen FreeBSD-Dekoder machen kann, die dieselben Parameter aufweisen und von derselben GUI aus gesteuert werden. Die Kryptoroutinen schreibe ich gerne selber. Da habe ich dann Spaß am Reverse Engineering :).
Tzz... keines meiner Systeme dabei. :'(Zitat von Mr. S
Windows Server 2003 Enterprise Edition
FreeBSD 6.1
FreeBSD 6.2
Berechtigungen
