• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Alien - Pakete konvertieren

Hallo,

ich experimentiere gerade zum ersten Mal mit Alien.
Hierzu habe ich mir das Paket PDFStudio_v9_2_1_linux64.deb von der Seite http://www.qoppa.com/pdfstudio/demo/download/ gezogen und im Terminal als Root mit
Code:
alien -r --keep-version --scripts PDFStudio_v9_2_1_linux64.deb
in ein RPM-Paket konvertiert.
Es kamen keine Fehlermeldungen und am Schluss hatte ich ein RPM-Paket der Datei.
Da ich Alien zum ersten Mal benutze bin ich mir etwas unsicher ob ich diese Datei jetzt gefahrlos mittels Yast oder Zypper installieren kann!

Folgende Information habe ich aus Wikipedia:
Wikipedia schrieb:
Die Formatkonvertierung ist im Allgemeinen nicht verlustfrei oder kann gelegentlich zu fehlerhaften Paketen führen, weswegen eine genauere Prüfung der erzeugten Pakete nach jedem Aufruf von alien zu empfehlen ist.
Quelle: https://de.wikipedia.org/wiki/Alien_(Software)

Hat jemand Erfahrung mit Alien? Wie kann ich denn das erstellte RPM-Paket wie im Zitat empfohlen überprüfen?
Sollte ich sonst noch was beachten?
 

manzek

Hacker
Wenn ich die Integrität eines Programmes testen will, installiere ich es in einer virtuellen Umgebung wie VirtualBox oder vmware. :D
 

Sauerland

Ultimate Guru
alien: kann funktionieren, muss nicht.
Zum Thema ausprobieren hatte ich ja auch schon einmal eine VM angemerkt.......

Ich lass die Finger davon........

Befasse Dich doch statt mit solchen Lösungen mit dem rpm-Paketbau, fang langsam an und versuch doch einfach irgend ein Paket auf Deinem Rechner nachzubauen.
Untersuched das spec-File, so fang ich gerade auch klein an.
 
OP
linux-freund

linux-freund

Member
Ich konkretisiere mal etwas:

Ich habe das RPM-Paket mit dem o.g. Befehl erstellt.
Ergebnis: pdfstudio-9.2.1-1.noarch.rpm 53,8 MB
Original-Paket: PDFStudio_v9_2_1_linux64.deb 62,3 MB
--> Das RPM-Paket ist kleiner.. ist das normal?

Die Option --scripts habe ich angegeben nachdem ich ohne diese Option folgenden Output erhielt:
Code:
Warning: Skipping conversion of scripts in package pdfstudio: postinst prerm
Warning: Use the --scripts parameter to include the scripts.
Mit
Code:
man alien
erhalte ich folgende Info zu dieser Option
Code:
-c, --scripts
Try to convert the scripts that are meant to be run when the package is installed and removed. Use this with caution, because these scripts might be designed to work on a system unlike your own, and could cause problems. It is recommended that you examine the scripts by hand and check to see what they do before using this option.
--> Hier werde ich also auch gewarnt - dieses mal aber vor dem Gebrauch dieser Option!
Das Paket wurde mit --scripts ohne Fehlermeldungen erstellt. Ist das Hinweis genug das alles ok ist?

Zur Frage des Paket testens:
Code:
-T, --test
Test the generated packages. Currently this is only supported for debian packages, which, if lintian is installed, will be tested with lintian and lintian's output displayed.
Für Debian-Pakete gibt es also eine integrierte Möglichkeit. Wie sieht es mit RPM-Paketen aus-- gibt es Alternativen (außer der Installation in einer VM)?

Was ist allgemein vom Gebrauch des Tools Alien zu halten? Liefert das i.d.R. zuverlässige Ergebnisse oder ist davon abzuraten?
Was ist von der Konvertierung von kostenpflichtigen Paketen zu halten (besagtes PDFStudio ist eine Trial-Version)?
 
OP
linux-freund

linux-freund

Member
Sauerland schrieb:
Befasse Dich doch statt mit solchen Lösungen mit dem rpm-Paketbau, fang langsam an und versuch doch einfach irgend ein Paket auf Deinem Rechner nachzubauen.
Untersuched das spec-File, so fang ich gerade auch klein an.
Das will ich auch noch lernen!
Bevor ich mich aber an die "Königsklasse" rpmbuild begebe möchte ich wenigstens die simpleren Kompilierungs-Methoden auch mal verstanden haben.
Es kann ja auch ganz nützlich sein als Vorstufe zu rpmbuild:
Code:
 -g, --generate
Generate a temporary directory suitable for building a package from, but do not actually create the package. This is useful if you want to move files around in the package before building it. The package can be built from this temporary directory by running "debian/rules binary", if you were creating a Debian package, or by running "rpmbuild -bb <packagename>.spec" if you were creating a Red Hat package.
 

josef-wien

Ultimate Guru
Ein Paket besteht neben Abhängigkeitsdefinitionen hauptsächlich aus 2 Teilen: aus einer Verzeichnisstruktur mit Dateien, die entsprechend entpackt werden, und (nicht in allen Fällen) aus Skripten, die vor bzw. nach der Installation oder Deinstallation ausgeführt werden. Beim ersten Teil hast Du das Problem, das auch besteht, wenn Du ein RPM-Paket einer fremden Distribution verwendest: Es gibt ab und zu Unterschiede, wo bestimmte Dateien gespeichert werden (müssen). Beim zweiten Teil wird es schon schwieriger: Ohne Analyse der Skripte kannst Du nicht wissen, ob das, was in der Quell-Distribution erfolgt, auch in der Ziel-Distribution Sinn macht.
 
OP
linux-freund

linux-freund

Member
@Josef-Wien:
Danke für die Erklärung!

Da es sich bei besagtem Tool um ein Linux-Allround-Paket handelt gehe ich davon aus das Verzeichnisstruktur und Skripte so gewählt sind das sie auf allen Distributionen laufen sollen. Normalerweise wird auf http://www.qoppa.com/pdfstudio/demo/download/ das Shell-Skript "PDFStudio_v9_2_1_linux64.sh" für Linux zum Download angeboten.
Das Paket "PDFStudio_v9_2_1_linux64.deb" wird wie folgt beschrieben:
http://www.qoppa.com/ schrieb:
To install PDF Studio on multiple computers through command-line, you may use our 64 bit Debian package (right-click and save link as) . This package will install PDF Studio in the “/opt” directory.
Anhand der Infos gehe ich davon aus das man keine Debian-spezifischen Änderungen im DEB-Paket eingebaut, sondern das Standard-Paket in ein DEB-Paket kompiliert hat.
So gesehen dürfte es punkto Verzeichnisstruktur und Skripten keine Probleme geben denke ich.

Was ich mich frage ist ob ein proprietäres Paket überhaupt kompiliert werden kann?
https://en.wikipedia.org/wiki/PDF_Studio schrieb:
Type: Cross Platform PDF Editor written in Java
License: Proprietary, Shareware
Benötigt man hierfür nicht den Source-Code?
Wie gesagt hat Alien mir ein RPM-Paket ohne Fehlermeldungen erstellt.
 

josef-wien

Ultimate Guru
Der Vorteil von Java ist, daß es sich um Quell-Code handelt, der (analog einem Bash-Skript) zur Laufzeit ausgeführt wird. Damit ist man plattformunabhängig, denn das Plattformspezifische erledigt die Laufzeit-Umgebung.

Das "Skript mit integriertem Archiv" PDFStudio_v9_2_1_linux64.sh macht ziemlich viel (man fragt sich wirklich, warum bei einem Java-Programm kein simples Archiv zum Auspacken zur Verfügung gestellt wird). Schau Dir daher einmal das Ergebnis von
Code:
rpm -qp --scripts --triggers /pfad/zu/dateiname.rpm
an.
 
OP
linux-freund

linux-freund

Member
Ergebnis von
Code:
rpm -qp --scripts --triggers /pfad/zu/pdfstudio-9.2.1-1.noarch.rpm
Code:
postinstall scriptlet (using /bin/sh):
#!/bin/sh
I4J_INSTALL_LOCATION="/opt/pdfstudio9"
cd "$I4J_INSTALL_LOCATION"
ln -sf "$I4J_INSTALL_LOCATION/pdfstudio9" /usr/local/bin/
/bin/echo -e "#!/usr/bin/env xdg-open
[Desktop Entry]
Type=Application
Name=PDF Studio 9
Exec=/bin/sh \"$I4J_INSTALL_LOCATION/pdfstudio9\"
Icon=$I4J_INSTALL_LOCATION/.install4j/pdfstudio9.png
" >> "$I4J_INSTALL_LOCATION/pdfstudio9.desktop"
chmod +x "$I4J_INSTALL_LOCATION/pdfstudio9.desktop"
ln -sf "$I4J_INSTALL_LOCATION/updater" /usr/local/bin/
ln -sf "$I4J_INSTALL_LOCATION/pdfstudiosu" /usr/local/bin/

if [ -f "$I4J_INSTALL_LOCATION/jre/lib/rt.jar.pack" ]; then
  old_pwd200=`pwd`
  cd "$I4J_INSTALL_LOCATION/jre"
  echo "Preparing JRE ..."
  for pack_file in lib/*.jar.pack
  do
    jar_file=`echo "$pack_file" | awk '{ print substr($0,1,length-5) }'`
    bin/unpack200 -r "$pack_file" "$jar_file"
  done
  for pack_file in lib/ext/*.jar.pack
  do
    jar_file=`echo "$pack_file" | awk '{ print substr($0,1,length-5) }'`
    bin/unpack200 -r "$pack_file" "$jar_file"
  done                                                                                                                                                                      
  bin/java -Xshare:dump >/dev/null 2>&1                                                                                                                                     
  cd "$old_pwd200"                                                                                                                                                          
fi                                                                                                                                                                          
exit 0                                                                                                                                                                      
preuninstall scriptlet (using /bin/sh):                                                                                                                                     
#!/bin/sh                                                                                                                                                                   
I4J_INSTALL_LOCATION="/opt/pdfstudio9"                                                                                                                                      
cd "$I4J_INSTALL_LOCATION"                                                                                                                                                  
                                                                                                                                                                            
rm "/usr/local/bin/pdfstudio9" 2>/dev/null                                                                                                                                  
rm "$I4J_INSTALL_LOCATION/pdfstudio9.desktop"                                                                                                                               
rm "/usr/local/bin/updater" 2>/dev/null                                                                                                                                     
rm "/usr/local/bin/pdfstudiosu" 2>/dev/null                                                                                                                                 
rm -Rf "$I4J_INSTALL_LOCATION/jre/lib"                                                                                                                                      
exit 0

Das sieht mir jetzt nicht unbedingt nach so viel aus, oder doch?

Nachtrag:
Ich habe mir gerade mal das Skript "PDFStudio_v9_2_1_linux64.sh" im Terminal ansehen wollen
Code:
cat PDFStudio_v9_2_1_linux64.sh
erbrachte eine endlose Schleife von Hyroglyphen... beendet mit Q.
Mit kwrite konnte ich das Skript öffnen.. es war leserliche Skriptsprache bis zu "Starting Installer".. ab dann kamen schier endlos viele Hyroglyphen.
Ich nehme an dieser Part ist proprietär und verschlüsselt!?
 

TomcatMJ

Guru
http://icculus.org/loki_setup/ oder ein ähnliches Installtool dürfte sich wohl in dem vermeintlichen Shellscript befinden ;) Da ist zu Anfang ein Shellscriptteil der einen Binary-Blob der dann kodiert in der Datei enthalten entpackt und dessen im inneren befindliche eigentliche Setuproutine startet, je nach Umgebung sogar mit grafischem Einstellungsmenü oder eben rein textbasiert mit oder auch ohne Interaktion des Benutzers....
 
OP
linux-freund

linux-freund

Member
@TomcatMJ:
Besten Dank für die Info! :thumbs:
Bei PDFStudio startet mit Aufruf des "Shell-Skriptes" eine Setuproutine mit grafischem interaktivem Einstellungsmenu.

Allerdings scheint dieser Part nicht in meinem mit Alien erstellten RPM vorhanden zu sein.. siehe Ausgabe letzter Post von mir.
Der Preinstall-Teil der im Skript "PDFStudio_v9_2_1_linux64.sh" enthalten ist wurde nicht mit ausgegeben.
Ich denke das man diesen Teil im DEB-Paket weggelassen hat, da über das Paketmanagement installiert wird.

Ich bin übrigens zwischenzeitlich dank des Hinweises von josef-wien ( :thumbs: ) auf die Idee gekommen mit dem rpm Kommando das Paket zu überprüfen:
Code:
>rpm --checksig pdfstudio-9.2.1-1.noarch.rpm
pdfstudio-9.2.1-1.noarch.rpm: sha1 md5 OK

>rpm -qp -l pdfstudio-9.2.1-1.noarch.rpm
# unzählige Dateien in /opt/pdfstudio9
# verteilt auf /opt/pdfstudio9/.install4j, /opt/pdfstudio9/jre, /opt/pdfstudio9/labels, /opt/pdfstudio9/lib

>rpm -qp -R pdfstudio-9.2.1-1.noarch.rpm
/bin/bash
/bin/sh
/bin/sh
/bin/sh
libX11.so.6()(64bit)
libXext.so.6()(64bit)
libXi.so.6()(64bit)
libXt.so.6()(64bit)
libXtst.so.6()(64bit)
libasound.so.2()(64bit)
libasound.so.2(ALSA_0.9)(64bit)
libawt.so()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libjava.so()(64bit)
libjava.so(SUNWprivate_1.1)(64bit)
libjli.so()(64bit)
libjli.so(SUNWprivate_1.1)(64bit)
libjvm.so()(64bit)
libjvm.so(SUNWprivate_1.1)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libmawt.so()(64bit)
libmawt.so(SUNWprivate_1.1)(64bit)
libnet.so()(64bit)
libnet.so(SUNWprivate_1.1)(64bit)
libnsl.so.1()(64bit)
libodbc.so()(64bit)
libodbcinst.so()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
libverify.so()(64bit)
libverify.so(SUNWprivate_1.1)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsLzma) <= 4.4.6-1

>rpm -qp --provides pdfstudio-9.2.1-1.noarch.rpm
libJdbcOdbc.so()(64bit)
libawt.so()(64bit)
libcmm.so()(64bit)
libcmm.so(SUNWprivate_1.1)(64bit)
libdcpr.so()(64bit)
libdcpr.so(SUNWprivate_1.1)(64bit)
libdeploy.so()(64bit)
libdt_socket.so()(64bit)
libdt_socket.so(SUNWprivate_1.1)(64bit)
libfontmanager.so()(64bit)
libfontmanager.so(SUNWprivate_1.1)(64bit)
libhpi.so()(64bit)
libhpi.so(SUNWprivate_1.1)(64bit)
libhprof.so()(64bit)
libhprof.so(SUNWprivate_1.1)(64bit)
libinstrument.so()(64bit)
libinstrument.so(SUNWprivate_1.1)(64bit)
libioser12.so()(64bit)
libioser12.so(SUNWprivate_1.1)(64bit)
libj2gss.so()(64bit)
libj2gss.so(SUNWprivate_1.1)(64bit)
libj2pcsc.so()(64bit)
libj2pcsc.so(SUNWprivate_1.1)(64bit)
libj2pkcs11.so()(64bit)
libj2pkcs11.so(SUNWprivate_1.1)(64bit)
libjaas_unix.so()(64bit)
libjava.so()(64bit)
libjava.so(SUNWprivate_1.1)(64bit)
libjava_crw_demo.so()(64bit)
libjava_crw_demo.so(SUNWprivate_1.1)(64bit)
libjavaplugin_jni.so()(64bit)
libjawt.so()(64bit)
libjawt.so(SUNWprivate_1.1)(64bit)
libjdwp.so()(64bit)
libjdwp.so(SUNWprivate_1.1)(64bit)
libjli.so()(64bit)
libjli.so(SUNWprivate_1.1)(64bit)
libjpeg.so()(64bit)
libjpeg.so(SUNWprivate_1.1)(64bit)
libjsig.so()(64bit)
libjsound.so()(64bit)
libjsound.so(SUNWprivate_1.1)(64bit)
libjsoundalsa.so()(64bit)
libjsoundalsa.so(SUNWprivate_1.1)(64bit)
libjvm.so()(64bit)
libjvm.so(SUNWprivate_1.1)(64bit)
libmanagement.so()(64bit)
libmanagement.so(SUNWprivate_1.1)(64bit)
libmawt.so()(64bit)
libmawt.so(SUNWprivate_1.1)(64bit)
libmlib_image.so()(64bit)
libmlib_image.so(SUNWprivate_1.1)(64bit)
libnative_chmod.so()(64bit)
libnative_chmod_g.so()(64bit)
libnet.so()(64bit)
libnet.so(SUNWprivate_1.1)(64bit)
libnio.so()(64bit)
libnio.so(SUNWprivate_1.1)(64bit)
libnpjp2.so()(64bit)
libnpt.so()(64bit)
libnpt.so(SUNWprivate_1.1)(64bit)
librmi.so()(64bit)
librmi.so(SUNWprivate_1.1)(64bit)
libsplashscreen.so()(64bit)
libsplashscreen.so(SUNWprivate_1.1)(64bit)
libunpack.so()(64bit)
libunpack.so(SUNWprivate_1.1)(64bit)
libverify.so()(64bit)
libverify.so(SUNWprivate_1.1)(64bit)
libzip.so()(64bit)
libzip.so(SUNWprivate_1.1)(64bit)
pdfstudio = 9.2.1-1
tessjni()(64bit)
Wenn ich diese Ausgabe richtig interpretiere heißt das alle Dateien werden in /opt installiert. Ich vermute in den anderen relevanten Linux-Verzeichnissen (in /usr/local/bin/) werden Symlinks erstellt!? Das sollte ja dann unproblematisch sein denke ich!
Zu den genannten Abhängigkeiten - werden diese automatisch nachinstalliert, falls nicht vorhanden?
Ich denke das könnte die einzigste Problematik an der Sache sein.
Was mich außerdem stutzig macht: Warum ist das RPM-Paket 8,5 MB kleiner als das DEB-Paket? Sind RPM-Pakete generell kleiner? Kann ich mir nicht vorstellen.
 

TomcatMJ

Guru
linux-freund schrieb:
@TomcatMJ:
Besten Dank für die Info! :thumbs:
Bei PDFStudio startet mit Aufruf des "Shell-Skriptes" eine Setuproutine mit grafischem interaktivem Einstellungsmenu.

Allerdings scheint dieser Part nicht in meinem mit Alien erstellten RPM vorhanden zu sein.. siehe Ausgabe letzter Post von mir.
Der Preinstall-Teil der im Skript "PDFStudio_v9_2_1_linux64.sh" enthalten ist wurde nicht mit ausgegeben.
Ich denke das man diesen Teil im DEB-Paket weggelassen hat, da über das Paketmanagement installiert wird.
Vermutlich lässt sich die Setup-Routine auch mit Parametern aufrufen die dann durch die Konvertierung mit alien gesetzt wurden.
Zu den genannten Abhängigkeiten - werden diese automatisch nachinstalliert, falls nicht vorhanden?
Ich denke das könnte die einzigste Problematik an der Sache sein.
Hm, gute Frage we mit nicht-aufgelösten Abhängigkeiten verfahren wird...vermutlich sollte man dazu dann zypper anstelle von purem rpm nutzen um dies herauszufinden.

Was mich außerdem stutzig macht: Warum ist das RPM-Paket 8,5 MB kleiner als das DEB-Paket? Sind RPM-Pakete generell kleiner? Kann ich mir nicht vorstellen.
Das dürfte stark vom verwendeten Kompressionsalgorithmus abhängig sein,soweit ich es im Kopf habe nutzt rpm bei opensuse inzwischen (seit einem der 9er Releases glaub ich) nicht mehr das einfache compress wie es in deb Paketen immer üblich war und bei rpm zu Anfang auch sondern einen modifizierten lzh-Algorithmus. Daher dürften rpm Pakete derselben Software etwas besser komprimiert sein,braucht dann vermutlich nur unwesentlich länger beim Einpacken als mit compress.
 
OP
linux-freund

linux-freund

Member
Danke für die sehr aufschlussreichen Infos, TomcatMJ!

Ich habe gerade mal testhalber mit Yast2 die Installation des Paketes aktiviert... und dann abgebrochen.
Folgende zusätzliche Pakete sollen installiert werden: unixODBC
Darin sind dann wohl zahlreiche der angegebenen benötigten Dateien enthalten.

Wenn keine Probleme in Zusammenhang mit diesem Paket zu erwarten sind denke ich das Paket installieren zu können.
 

josef-wien

Ultimate Guru
linux-freund schrieb:
Das sieht mir jetzt nicht unbedingt nach so viel aus, oder doch?
Bei postinstall fällt mir nichts Bedenkliches auf, auf den ersten Blick löscht preuninstall alles wieder, das Ganze sieht also sauber aus. Auf jeden Fall ist alles viel klarer und einfacher als bei der sh-Datei.

linux-freund schrieb:
Ich nehme an dieser Part ist proprietär und verschlüsselt!?
Wie TomcatMJ schon angedeutet hat, ist das ein komprimiertes Archiv.

linux-freund schrieb:
Wenn keine Probleme in Zusammenhang mit diesem Paket zu erwarten sind denke ich das Paket installieren zu können.
Auch wenn es schon mehrfach gesagt wurde, erstelle Dir für künftige Experimente eine entsprechende Testumgebung, das Produktionssystem sollte man nicht gefährden.
 
OP
linux-freund

linux-freund

Member
So, ich habe nach einigem Zögern das Paket jetzt einfach mal über Yast installiert.
Es kam kein interaktives Installationsmenu, das Paket wurde einfach ohne grafische Dialoge installiert. Vorab wurde das Paket unixODBC als Abhängigkeit installiert.
Es ist wie schon vorab gepostet in /opt zu finden.
Dort liegt auch der Starter für Qoppa PDFStudio.
Den habe ich angeklickt und das Programm ist fehlerfrei gestartet! :)
Scheint alles problemlos funktioniert zu haben!!

josef-wien schrieb:
Auch wenn es schon mehrfach gesagt wurde, erstelle Dir für künftige Experimente eine entsprechende Testumgebung, das Produktionssystem sollte man nicht gefährden.
Ja, ist schon besser. Aber ehrlich gesagt bin ich kein Freund dieser Virtualisiererei..
Werde mir bei Gelegenheit aber mal eine openSUSE-VM anlegen - ist schon besser so was zu haben gerade z.B. um selbst erstellte Pakete oder andere Software zu testen.

Danke schonmal an alle fürs Helfen! :thumbs:

Werde noch berichten wie´s mit der Deinstallation funktioniert hat.
 

josef-wien

Ultimate Guru
linux-freund schrieb:
kein Freund dieser Virtualisiererei
Als Alternative kannst Du auch auf einer eigenen Partition ein zweites Linux installieren (bzw. das bisherige (mit modifizierter fstab) kopieren und je nach Bedarf immer wieder auf den Stand des Produktionssystems bringen).
 
OP
linux-freund

linux-freund

Member
josef-wien schrieb:
Als Alternative kannst Du auch auf einer eigenen Partition ein zweites Linux installieren (bzw. das bisherige (mit modifizierter fstab) kopieren und je nach Bedarf immer wieder auf den Stand des Produktionssystems bringen).
Dann doch lieber Virtualisiererei :lol:
 

abgdf

Guru
josef-wien schrieb:
Der Vorteil von Java ist, daß es sich um Quell-Code handelt, der (analog einem Bash-Skript) zur Laufzeit ausgeführt wird.
Hmm, nee, Java-Source-Code (.java) muß erst kompiliert werden. Dafür braucht man das "Software Development Kit" (Java-SDK). Dann erhält man z.B. ein .class-File, das man ausführen könnte.
http://www.sergiy.ca/how-to-compile-and-launch-java-code-from-command-line/
Meist werden aber jede Menge von diesen .class-Files in einem .jar-File zusammengepackt. Dieses kann man dann mit dem Interpreter, dem "Runtime Environment" (JRE), ausführen:
Code:
java -jar file.jar
josef-wien schrieb:
Damit ist man plattformunabhängig, denn das Plattformspezifische erledigt die Laufzeit-Umgebung.
Das stimmt dann wieder (Laufzeit-Umgebung == JRE).

Man muß also im Verhältnis zu echten Skript-Sprachen (wie Perl oder Python) relativ viel Code schreiben (als Skript-Sprache für das JRE gibt es daher als Alternative die Sprache "Groovy"). Außerdem muß man in Java auch noch kompilieren. Und trotzdem läuft das Ergebnis dann (im Verhältnis zu C/C++) relativ langsam. Aus diesen Gründen mag ich Java nicht besonders und vermeide es, wenn ich kann.
 
OP
linux-freund

linux-freund

Member
josef-wien schrieb:
Auch wenn es schon mehrfach gesagt wurde, erstelle Dir für künftige Experimente eine entsprechende Testumgebung, das Produktionssystem sollte man nicht gefährden.
Das habe ich jetzt gemacht.
Dank Eurer Hinweise habe ich mir mal ein Herz gefasst und mich wieder mal mit QEMU/KVM beschäftigt. Bislang hatte ich nur Windows8.1 virtualisiert.
Jetzt habe ich mir noch einen openSUSE13.1-Gast eingerichtet und dabei feststellen können das die Einrichtung eines Linux-Gastes mit QEMU/KVM besser unterstützt wird und einfacher von der Hand geht!
Ich konnte direkt bei den Installationseinstellungen "Paravirtualisierung" einstellen und hatte per default sämtliche paravirtualisierten virtio-Treiber in der VM eingerichtet.
Alles was ich noch tun musste war die Pakete "spice-vdagent-0.15.0-15.2.x86_64.rpm" und "xf86-video-qxl-0.1.0-6.1.2.x86_64.rpm" nachzuinstallieren um eine QXL-Grafikkarte nutzen zu können.
Die VM ist optisch nicht vom Host-System zu unterscheiden - Volle HD-Auflösung. Die Netzwerkgeschwindigkeit ist jedoch etwas langsamer.
Es kann zukünftig also fleissig getestet werden! ;)
 

thio

Hacker
Für die wenigen Pakete die ich von .deb auf .rpm konvertiert habe, haben mit dem "Package Converter 3.0.x" gut funktioniert.
 
Oben