4. Linux Distributionen: binäre kompatibilität der Anwendungen?

Linux Distributionen: binäre kompatibilität der Anwendungen?

  • A

    Ich habe OpenSuse installiert und beschäftige mich ein wenig damit. Mir ist hin und wieder in Foren und Blogs über den Weg gelaufen, das Packete bzw. Anwendungen für eine bestimmte Distribution gebaut werden. Aber teilweise heißt es sogar, für eine bestimmte Version einer Distri.

    Das verwirrt mich doch etwas als langjähriger Windows-Anwender.

    Wie ist es denn nun? Müssen native Anwendungen immer speziell für eine Distribution und sogar bestimmte Version gebaut werden?

    Ich kann es ja noch einsehen, das man sagt: "Ich baue nur für OpenSuse und Ubuntu. Alle anderen Distris müssen auf mein Programm verzichten!"

    Aber was ist mit einem Versionswechsel? Gibt es da eine Webseite wo sowas mal zusammen gefasst beschrieben wird?

    0
  • Mod

    Normalerweise baust du die Software immer für dein System neu. Dazu gibt es Buildsysteme, damit ist die Portierung der Software auf andere Systeme kein/kaum ein Problem. Eine bestimmte Distribution ist einheitlich genug, dass der Distributor die Software schon bei sich bauen kann und dann nur die ausführbare Datei verteilen kann, was Zeit sparen kann. Dafür bekommt man dann natürlich die Buildeinstellungen, die der Distributor für richtig hielt. Manche Distributionen (z.B Gentoo) schwören hingegen da drauf, dass der Nutzer alles bei sich lokal baut und so alle Einstellungen feintunen kann.
    Der große Unterschied zu Windows ist halt, dass alles Open Source ist, daher kann man das so machen. Wenn man hingegen eine Binary verteilen möchte, dann hat man ein mittelschweres Problem. Dann muss man es eben wie bei Windows machen und alle Abhängigkeiten mit verteilen, was dann zu relativ großen Programmpaketen führt (für Windowsnutzer aber normal). Die Software wird natürlich trotzdem nicht auf jedem Linux laufen, da der gemeinsame Nenner zu klein ist und man irgendwann Kompromisse eingehen muss. Z.B. dass für ein Spiel eine OpenGL-Schnittstelle oder wenigstens ein X-Server vorhanden ist. Dies gilt dann in diesem Beispiel eben nur für ein typisches Desktoplinux, nicht jedoch für einen Server der auf einer Kaffeemaschine läuft.

    Frage beantwortet?

    edit: Ach, Versionswechsel: Wenn du eine fertige Distribution benutzt, dann wird der Distributor sich um alles kümmern. Außer bei Sachen die wirklich tief im System sitzen, wirst du aber in der Praxis kaum Probleme bekommen, selbst wenn du selber ein paar Programme gebaut hast und diese ohne Neubau weiter benutzt. Du kannst in der Praxis auch ziemlich gut Executables zwischen verschiedenen Rechnern hin und her schieben, selbst wenn sie dynamisch gelinkt sind (sofern die Abhängigkeiten erfüllt sind). Es kann halt zu Problemen kommen, daher macht man es gewöhnlicherweise nicht, aber es wird oftmals funktionieren.

    0
  • A

    Also geht es eigentlich eher um die Abhängigkeiten? Ob also eine Komponente vorhanden ist oder nicht? Das kann ich verstehen. Wäre ja unter Windows auch nicht anders.

    Aber anscheinend gibt es bei Closed Source doch Schwierigkeiten?

    Ich habe mal http://www.opera.com/browser/download/?os=linux-x86-64&ver=12.00b1&local=y angeschaut. Die Auswahl macht es nicht gerade einfach Linux auf dem Desktop durch zusetzen.

    0
  • Z

    Die Auswahl macht es nicht gerade einfach Linux auf dem Desktop durch zusetzen.

    Auf der Opera Seite hat man doch für eigentlich alle Distros den benötigten Download?
    z.B. auch RPM Pakete für Suse.
    http://de.opensuse.org/Portal:Paket-Management

    Es gibt auch Community-Repos(Bezeichnung falsch?), die über solche Programme, wie Opera, verfügen.

    0
  • C

    Artchi schrieb:

    Also geht es eigentlich eher um die Abhängigkeiten?

    Primär, ja.

    Artchi schrieb:

    Ich habe mal http://www.opera.com/browser/download/?os=linux-x86-64&ver=12.00b1&local=y angeschaut. Die Auswahl macht es nicht gerade einfach Linux auf dem Desktop durch zusetzen.

    Zentrale Aufgabe von Distributionen ist die Paketverwaltung, im Gegensatz zu Windows wird es nicht jedem einzelnen Programm überlassen, sich um die Installation/Deinstallation etc. selbst zu kümmern, dafür ist der jeweilige Paketmanager zuständig. Konsequenterweise sollte es selten erforderlich sein, so wie in dem Link oben, die Programme direkt herunterladen zu müssen.

    0
  • A

    zuckerlie schrieb:

    Die Auswahl macht es nicht gerade einfach Linux auf dem Desktop durch zusetzen.

    Auf der Opera Seite hat man doch für eigentlich alle Distros den benötigten Download?
    z.B. auch RPM Pakete für Suse.
    http://de.opensuse.org/Portal:Paket-Management

    Es gibt auch Community-Repos(Bezeichnung falsch?), die über solche Programme, wie Opera, verfügen.

    Ja, eben. Man muss anscheinend als Hersteller so viele Distributionen beachten und für so viele bauen. Das der unbedarfte Anwender auch noch sein System kennen muss, macht es nicht einfacher.

    Die Repos sind mir mittlerweile bekannt. Für Open Source ist das ja alles auch kein Problem. Im Repo stöbern und installieren. Wunderbar! 👍

    Aber was ist mit Closed Source?

    0
  • A

    camper schrieb:

    Zentrale Aufgabe von Distributionen ist die Paketverwaltung, im Gegensatz zu Windows wird es nicht jedem einzelnen Programm überlassen, sich um die Installation/Deinstallation etc. selbst zu kümmern, dafür ist der jeweilige Paketmanager zuständig. Konsequenterweise sollte es selten erforderlich sein, so wie in dem Link oben, die Programme direkt herunterladen zu müssen.

    Aber diese Repo-Manager wird sich doch eher nicht mit allen Closed Source Produkten kümmern? Oder wie läuft das da ab?

    Mal ein konkretes Beispiel: was macht z.B. Crytek, wenn sie morgen ihr Crysis 3 für Linux raus bringen wollen würden? Müssen die einen Download/DVD-ROM für jede (besser verbreitete) Linux-Distribution raus bringen? Oder können die sagen: für alle Linuxe mit mind. Linux Kernel 3 und OpenGL 3 gibt es diesen einen Download/DVD-ROM?

    0
  • A

    OK, OpenSuse nutzt RPM für die Packetverwaltung. Auch Fedora scheint dieses zu nutzen. (Ubuntu auch?)

    Wenn man also sagen würde: man stellt ein RPM-Binary bereit, das die wichtigsten Libs mitbringt und andere voraussetzt (z.B. GTK+, weil es eh für Desktop-User ist). Würde man dann wenigstens die RPM-nutzenden Distries abdecken können?

    0
  • ?

    Artchi schrieb:

    Ja, eben. Man muss anscheinend als Hersteller so viele Distributionen beachten und für so viele bauen. Das der unbedarfte Anwender auch noch sein System kennen muss, macht es nicht einfacher.

    Die Repos sind mir mittlerweile bekannt. Für Open Source ist das ja alles auch kein Problem. Im Repo stöbern und installieren. Wunderbar! 👍

    Aber was ist mit Closed Source?

    Dafür gibt's die LSB:
    http://de.wikipedia.org/wiki/Linux_Standard_Base

    Das was die LSB dann nich selbst unterstützt, muß man als Abhängigkeit dann eben mitliefern oder statisch linken, sofern lizenztechnisch erlaubt.

    0
  • ?

    Artchi schrieb:

    Mal ein konkretes Beispiel: was macht z.B. Crytek, wenn sie morgen ihr Crysis 3 für Linux raus bringen wollen würden? Müssen die einen Download/DVD-ROM für jede (besser verbreitete) Linux-Distribution raus bringen? Oder können die sagen: für alle Linuxe mit mind. Linux Kernel 3 und OpenGL 3 gibt es diesen einen Download/DVD-ROM?

    Schau doch mal wie es Google mit Google Earth macht.

    Die liefern ein tar.gz Datei (kein RPM Paket) mit einem eigenen Installer, der installiert dann alle Abhängigkeiten nach /opt in den Ordner von Google Earth und auch nur für diese Anwendung.

    D.h. am Paketmanager wird vorbei installiert und closed Source Hersteller liefern die Abhängigkeiten einfach mit dem eigenständigen Programm mit.
    Achten muss man dann nur noch auf absolute Grundlagen, wie z.B. die libc & Co, aber dafür gibt's ja dann die LSB an die man sich halten kann.

    PS:
    Es gibt auch in den Repos Möglichkeiten Google Earth zu installieren, aber das ist eben nicht der offizielle Weg seitens Google.

    0
  • ?

    Artchi schrieb:

    OK, OpenSuse nutzt RPM für die Packetverwaltung. Auch Fedora scheint dieses zu nutzen. (Ubuntu auch?)

    Nein, Ubuntu verwendet offiziell DEB, kann aber als LSB Distri mit RPM umgehen.

    Wenn man also sagen würde: man stellt ein RPM-Binary bereit, das die wichtigsten Libs mitbringt und andere voraussetzt (z.B. GTK+, weil es eh für Desktop-User ist). Würde man dann wenigstens die RPM-nutzenden Distries abdecken können?

    Die LSB hat das RPM Paket in den Standard mit aufgenommen, daher kann jede LSB Distri auch RPM.

    Üblich ist allerdings bei Closed Source Anwendungen der Windows Weg mit Installer.

    Bei Spielen hat man z.B. oft den Loki Installer verwendet.
    Lad dir mal die Quake 3 Demo für Linux runter, dann kannst du ausprobieren wie der Loki Installer funktioniert.

    0
  • A

    Aha! Das mit LSB war der entscheidende Hinweis! 💡 Danke! 👍

    Es gibt also doch eine Spezifikation die einen gewissen Teil abdeckt. Ich sehe das z.B. im LSB das GTK+ 2.1 und Qt 4 vorhanden sein muss. Das ist doch schon mal eine gute Basis für grafische Anwendungen. Damit wird doch auch schon so ein Paket kleiner und weniger komplex.

    Quake 3 werde ich mal anschauen.

    0
  • R

    das "Format" des Packetmanagers ist glaub ich das wichtigste Unterscheidungsmerkmal der Distries ...

    OpenSuse nutzt RPM für die Packetverwaltung. Auch Fedora scheint dieses zu nutzen

    japp, d.h. aber noch lange ned, das die Packete kompatibel sind ... es ist nur ein "Format" wie die packete gepackt sind, nicht ueber den Inhalt, also die Art und weisse wie es im rpm strukturiert wird.
    Die meisten Dinge sind aber grob kompatibel. Aber details unterscheiden sich dann doch. Deswegen gibts meist Suse / Redhat Packete und keine generischen.

    Is oft so, wenn 2 Distries den selben Packetmanager verwenden, aber nicht miteinander verwand sind ....
    Red Hat und Fedora wiederum sind um welten kompatibler, weil miteinander verwand ^^

    Ubuntu ist Quasi mit debian verwand -> benutzt deb's (Debian packages)!

    http://upload.wikimedia.org/wikipedia/commons/8/8c/Gldt.svg

    Es gibt auch konverter, die Packete umpacketieren koennen, bzw machen das die packetmanager teilweisse auch selber. Also kann man nen dep auch in nen rpm verwandeln ... allerdings ist das sehr fehleranfällig (funktioniert selten ohne handarbeit).

    Müssen die einen Download/DVD-ROM für jede (besser verbreitete) Linux-Distribution raus bringen? Oder können die sagen: für alle Linuxe mit mind. Linux Kernel 3 und OpenGL 3 gibt es diesen einen Download/DVD-ROM?

    - Hier spielen ne Menge faktoren rein ^^
    Ein Programm kann mehrere Abhaengigkeiten haben:

    - der verwendete Prozessor / Befehlssatz (die hats immer)

    - die verwendete c- runtime (wenns nicht in assembler geschrieben wurde)
    - BS - Bibliotheken (posix, system V ... )

    - c++ runtime
    - ne ganze Menge 3d party libs.

    Nicht jedes Program hat alle abhanegigkeiten ^^
    Nen c- consolenprogram wird z.b. nur von der c- runtime abhaengig sein, und diese wiederum kann binaerkompatibel ueber mehrere compiler und generationen sein ^^ sprich diese dinger sind recht stabil

    nen c++ programm mit QT ist sicher von der cpp runtime und den QT libs (dynamisch gelinkt) aebhaengig. diese sind nicht compilerunabhaengig. Sprich ne neue gcc version, bzw andere system-compiler-flags -> möglicherweisse musst alles neu uebersetzen.

    Abhilfe: statisch linken !
    Dann ist dein programm zwar mega gross, aber meist nur noch vom den verwendeten schnittstellen nach aussen abhaengig ...
    Das geht effektiv aber nur mit kleinen Konsolenprogrammen ...

    Hasst Du X-Abhaengigkeiten drinne -> abhaengigkeiten die nicht aufloesen kannst (gegen xorg kannst IMHO nicht statisch linken ... und ab und an aendern die Ihre ABI auch -> seihe ATI Treiber dilemma etc)

    Sprich, fuer Closed Source Projecte ist linux ne Alptraum-Plattform.
    Siehst ja z.b. wie die Grafikkarten-treiber typen das versuchen zu loesen ... nen kern der Propertiär ist ... wo die ganzen Geheimnisse drinn stecken ^^ und nen Wrapper drumherum, der das ganze aufs system mappt / anpasst. Der ist opensource ....

    Wer pflegt die Packete ?
    Hier genau so kommt es genau so drauf an.
    Isses was rudimentaeres, was die Distri meint zu brauchen ... wird das auch das Team der Distri anpassen und pflegen ....
    Hasst nur Du als hersteller das Intresse, das Zeugs auf zig Distries zu verteilen, wirst du wohl alle Packete selkber pflegen muessen ....
    Hat keiner von beiden Bock, und es ist open source -> ./configure ./make ./make install Spass fuer den User.
    Hat keiner von beiden Bock, und es ist Closed source -> 30 DINA4 Seiten Readme und 200000 wrapper scripte + nen ueberfuelltes Flame-Forum wo man draus ableiten kann das es noch nie richtig unter linux (ausser auf dem Rechner des Urhebers) gelaufen ist .... ^^

    Tja, deswegen ist in der kommerziellen closed source Welt windows so toll !
    WINAPI -> binaerkompatibel (ABI) ! und abwaertskompatibel ... und dafuer voller altlasten ^^

    Oder man baut selber die Distrie fuer sein produkt (Oracle Linux)
    Oder man bezahlt ne Distri (SLES )
    Oder versucht sein glueck mit nem Unix was weniger derivate hat (BSD, SOLARIX)

    Denk mal, das sind genug Gruende, warum es Crysis 3 für Linux ned so schnell geben wird. Abgesehen davon, das linux weniger "schmutzige" hacks wie windows hat, um direkt auf die Hardware zu kommen um ne gewisse Performance zu erzielen .

    Ciao ...

    0
  • ?

    Artchi schrieb:

    Ich sehe das z.B. im LSB das GTK+ 2.1 und Qt 4 vorhanden sein muss. Das ist doch schon mal eine gute Basis für grafische Anwendungen.

    Ja, allerdings ist GTK 2.10 uralt und wenn das eigene Programm LSB konform sein soll, dann muss man sich auf 2.10 konforme Funktionen beschränken.

    Hier ist ein grober Überblick was man alles noch nicht nutzen kann:
    http://en.wikipedia.org/wiki/GTK%2B#History

    Mir wäre so etwas wie GTK 2.20 lieber gewesen.
    GTK 3.0 muss nicht sein, GTK 2.20 reicht eigentlich, schön wäre GTK 3.0 dennochk, aber 2.10 ist zu alt und featurelos.

    0
  • ?

    RHBaum schrieb:

    das "Format" des Packetmanagers ist glaub ich das wichtigste Unterscheidungsmerkmal der Distries ...

    OpenSuse nutzt RPM für die Packetverwaltung. Auch Fedora scheint dieses zu nutzen

    japp, d.h. aber noch lange ned, das die Packete kompatibel sind ... es ist nur ein "Format" wie die packete gepackt sind, nicht ueber den Inhalt, also die Art und weisse wie es im rpm strukturiert wird.
    Die meisten Dinge sind aber grob kompatibel. Aber details unterscheiden sich dann doch. Deswegen gibts meist Suse / Redhat Packete und keine generischen.

    Is oft so, wenn 2 Distries den selben Packetmanager verwenden, aber nicht miteinander verwand sind ....
    Red Hat und Fedora wiederum sind um welten kompatibler, weil miteinander verwand ^^

    Es sprich nichts dagegen RPM zu verwenden, allerdings sollte es man tunlichst unterlassen Teile des CS Programms in was anderes als /opt/[Progname] zu installieren.

    Sprich, fuer Closed Source Projecte ist linux ne Alptraum-Plattform.
    Siehst ja z.b. wie die Grafikkarten-treiber typen das versuchen zu loesen ... nen kern der Propertiär ist ... wo die ganzen Geheimnisse drinn stecken ^^ und nen Wrapper drumherum, der das ganze aufs system mappt / anpasst. Der ist opensource ....

    Du kannst Treiber nicht mit Anwendungen vergleichen!

    Bei den NVidia Treiber macht man das so, weil die Funktionsaufrufe des Kernels sich jederzeit ändern könnten, wenn Linus lustig ist.
    Es gibt nämlich keine fest definierte Kernel ABI.

    Bei Anwendungen sieht das anders aus, denn die nutzen in der Regel die Kernelfunktionen nicht direkt, sondern greifen über Libs, POSIX usw. darauf zu und Libs und POSIX ist in der Regal ABI stabil.
    Unterschide gibt's für die Libs nur bei Majorversionen oder eben wegen Compilerspezifischen Umbauten (z.b. das C++ Dilemma vor ca. 10 Jahren, als man den G++ auf Intel konforme Funktionsaufrufe umgestellt hat).

    @TS
    eine Große Hilfe ist übrigens das Programm ldd, damit kann man herausfinden, was auf dem eigenen System noch fehlt, wenn man mit einem dynamisch gelinkten CS Programm mal Probleme hat.

    Tja, deswegen ist in der kommerziellen closed source Welt windows so toll !
    WINAPI -> binaerkompatibel (ABI) ! und abwaertskompatibel ... und dafuer voller altlasten ^^

    Sowie ein OS, dessen Speicherplatzbedarf für die Grundinstallation mit jeder neuen Version etwa verdoppelt.

    Denk mal, das sind genug Gruende, warum es Crysis 3 für Linux ned so schnell geben wird.

    Die Gründe dürften eher am einem fehlenden Markt liegen bzw. solange Linux User bereit sind, Windows Dual zu booten, kann man sich die Arbeit für ne extra Linux Version sparen.
    Und genau Gamer tun das, die installieren Windows als Dual Boot System auch dann, wenn sie mit Linux hauptsächlich arbeiten.

    Lediglich die wenig Gamer verzichten auf die Windows Dual Boot Installation, aber die sind dann auch kein Markt für Crytek.

    Insofern, hätte es Gnome nicht mit dem Gnome 3 Desktop verbockt und KDE nicht mit dem instabilen KDE 4, dann hätte jetzt Linux auf dem Desktop ne gute Chance haben können Windows zu verdrängen, weil MS auf bestem Weg ist mit der Metro Oberfläche Windows 8 zu verbocken.

    Da Linux auf dem Desktop wegen Gnome 3 und KDE 4 aber auch nicht viel besser dasteht und XFCE eher ne Notlösung ist, werden die User bei Windows 8 mit Metro zähneknirschend bleiben.

    Lediglich Apple könnte IMO daraus mit OS X noch den größten Vorteil ziehen.
    Für Linux ist der Zug auf dem Desktop aber vorerst abgefahren.
    Gnome 3 Shell Mist sei Dank.

    Mit XFCE füblt sich so ein Desktop Linux leider wie vor 10 Jahren an, als KDE 1 neu war.
    Gnome 2 wird nicht mehr supported und Gnome 3 ist rotz.

    Zwar gibt's noch Cinnamon und Mate, aber die müssen erstmal zeigen, daß ihr Weg funktioniert und solange große fette Userdistris wie Ubuntu da nicht mitmachen, haben die auch keine große Chance.
    Das erste was der Linuxeinsteiger heutzutage sehen würde, ist der Unity oder Gnome 3 rotz.

    0
  • N

    Artchi: Für Closed-Source-Zeug ist der Hinweis auf /opt und viel statisches Linken und Dependencies notfalls selbst mitbringen und LSB gut. (Wurde zwar alles schon erwähnt, aber vielleicht ist es so kompakt zusammengefasst trotzdem leichter verdaulich. :))

    0
  • ?

    nman schrieb:

    Artchi: Für Closed-Source-Zeug ist der Hinweis auf /opt und viel statisches Linken und Dependencies notfalls selbst mitbringen und LSB gut. (Wurde zwar alles schon erwähnt, aber vielleicht ist es so kompakt zusammengefasst trotzdem leichter verdaulich. :))

    unterschreib

    0
  • A

    Genau, wegen Win8 und seinem Metro-Zwang schaue ich mir Alternativen. Win7 ist ein super System, wie ich finde. Und werde es deshalb auch noch benutzen. Aber Win7 wird irgendwann veraltet sein, und dann muss man sich umorientiert haben.

    Ich habe mir deshalb mal parallel OpenSUSE 12.1 und jetzt auch noch PC-BSD 9 mit jeweils KDE und XFCE installiert.

    Die Systeme haben sich wirklich für den Desktop-User (der kein Konsolen-Guru ist) gut weiter entwickelt. 👍 Aber die Systeme sollten schon zu sich selbst kompatibel sein, wenn sie z.B. auch Closed-Source-freundlich sein sollen. 😉

    Für PC-BSD gibt es ja zum FreeBSD-Package-System auch noch zusätzlich das hauseigene PBI bzw. neue AppCafe: da wird alles in einen Anwendungs-Installer (Binary-Archiv) rein gepackt, was nicht in der Standard-Installation von PC-BSD drin ist. Somit ist da schon ein einfacher Music-Player gut 70 MB groß. 😮 Aber es gibt dadurch keine Abhängigkeitskonflickte, auch beim Deinstallieren nicht. Es ist also eine Lösung pro Mainstream-Anwender.

    Beim Linux könnte man ähnlich vorgehen.

    Also sehe ich da nur folgende vertretbare Möglichkeit für einen kleinen Closed-Source-Entwickler: er unterstützt nur ein oder zwei alternative Systeme, die die meisten potenziellen Kunden haben. Denn sonst wird es unmöglich das Testing und Support-Anfragen zu bewältigen.

    Ich werde mich aber mit OpenSUSE und PC-BSD weiter beschäftigen. 🙂

    0
  • D

    Man kann als Closed Source Entwickler unter Linux auch einfach Open Source in Malbolge entwickeln.
    Dann kann das jeder bei sich kompilieren, aber sonst kann man nichts weiter damit anfangen.

    Da wäre vllt mal ein C-zu-Malbolge-Compiler ein cooles Projekt 🙂

    0
  • R

    Die Sachen die vom Paketmanager installiert werden, haben ja eh keine Abhängigkeitsprobleme. Es gab aber mal den Vorschlag ein "FatELF" einzuführen, also wohl so ähnlich wie die Binary-Archives von PC-BSD oder OSX Apps. Das wurde aber von den Kernel-Entwicklern abgelehnt und das Projekt liegt wohl derzeitig auf Eis: http://icculus.org/fatelf/

    Die meiste kommerzielle Software installiert sich einfach unter /opt/ und liefert alle Libraries etc. mit. Hatte damit bisher eigentlich keine Probleme.

    0
Anmelden zum Antworten