Auf Pinguinzubehör schimpft Daniel heute über Opera, die ihren Browser zwar endlich wieder für Linux anbieten, dies allerdings lediglich in Form eines DEB-Pakets für Ubuntu tun. An dieser Stelle möchte ich mal eine Lanze für die wirklich armen Paketschnürer brechen, die das entweder in ihrer Freizeit oder für eine Softwarefirma knechtend machen müssen. Das Paketieren von Software für Hinz-und-Kunz-Linux ist aufwändig — um es mal nett auszudrücken. Vor dieser Aufgabe scheuen sich nicht nur kommerzielle Unternehmen, auch Linus Torvalds himself versucht sich so weit wie möglich davor zu drücken.
Video-Link: https://youtu.be/5PmHRSeA2c8?t=4m58s
Auf der DebConf14 stand Linus Torvalds wie üblich in einer längeren Q&A-Runde Rede und Antwort. Auch diesmal nimmt er kaum ein Blatt vor dem Mund, auch wenn er diesmal auf einen Stinkefinger verzichtet. Auf die Frage, wie man denn endlich das Jahr des Linux-Desktops erreichen könnte, lässt er sich besonders über das Paketieren von Anwendungen aus. Linus spricht da aus eigener Erfahrung — abseits des Kernels. Seine Tauchsoftware Subsurface gibt es für MacOS X und Windows als Binary, unter Linux ist dies so gut wie unmöglich.
…making binaries for Linux desktop applications is a major fucking pain in the ass. You don’t make binaries for Linux, you make binaries for Fedora 19, Fedora 20, maybe even RHEL5 from 10 years ago. You make binaries for Debian Stable…well actually no, you don’t make binaries for Debian Stable because Debian Stable has libraries that are so old that anything built in the last century doesn’t work.
…and this [„Don’t Break Userspace!“] is like, a big deal for the kernel, and I put a lot of effort into explaining to all the developers that this is a really important thing, and then all the distributions come in, and they screw it all up. Because they break binary compatibility left and right.
Man kann also sehr gut verstehen, dass sich ein Unternehmen wie Opera, das in einem beinharten Konkurrenzkampf mit den größten und reichsten Konzernen der Welt steht, in Bezug auf Linux auf die Distribution konzentriert, die mit Abstand am häufigsten am Markt vertreten ist — schaut man beispielsweise auf die Statistiken der Wikimedia, dann ist das eben Ubuntu mitsamt seinen unzähligen Derivaten. Es ist ja auch nicht so, als ob sich die Distributoren nicht selber um das Paketieren kümmern könnten.
Einen möglichen Ausweg aus dem Bibliotheken-Chaos unter Linux sieht er übrigens in Valve. Steam bietet statisch kompilierte Bibliotheken, gegen die man seine Anwendung bauen kann. Funktioniert ein Programm mit Steam für Linux, so sollte das Ding auch unter allen anderen Systemen laufen, auf denen Steam installiert ist. Dieser Weg ist für freie Software natürlich ein Schuss ins Knie, für kommerzielle Anwendungen könnte dies aber tatsächlich der Weg auf den Linux-Desktop werden.
Ich habe es selbst zwar nie auf einem bestehenden System /sauber/ ans laufen bekommen, aber kennst du nix-pkg und/oder guix? In der Theorie verspricht das Loesung und Besserung.
http://nixos.org/nix/
http://www.gnu.org/software/guix/
So kann man das nicht stehen lassen. Grundsaetzlich hat Linus Torvalds vollkommen recht, die Maintainer der Libraries muessen sich um Kompatibitaet bemuehen.
Und so sieht es aus:
1. Windows schleppt einen gewaltigen Bloat vor sich her um kompatibel zu allen moeglichen alten Versionen zu sein. Daraus folgend sind Windowsinstallation stetig wachsend Monster. Ebenso geht das nur Dank eine gigantischen Qualitatssicherungen.
Microsoft kann gar nicht anders, weil fuer fast alle Programme kein Quellcode vorliegt sondern nur Binaries. Und aus der Kompatibitaet zu MS-DOS Programmen, ueber Win9x bis zu NT 6.1 kommt Microsofts Machtbasis.
Das andere extrem ist MacOS, die bleiben eine Zeit lang stabil und dann verzichten sie einfach auf jede Rueckwaertskompatibiltaet (Classic-Anwendungen, PowerPC…).
2. Windowsprogrammierer haben den Begriff DLL-Hell gepraegt. Windows hat keine Paketverwaltung und daher ist das unter jede einzelnen Windows ein undefinierter Zustand. Also liefert halt jede Anwendung eigene DLLs oder ist gleich statisch gelinkt. Wer mit .NET (speziell unter Windows XP) kontakt hatte duerfte auch sehr unliebsame Erfahrungen gemacht hat. Kleine Installationsorgie ueber Windowsupdate.
3. GNU/Linux und hat eine Paketverwaltung, unsere Systems sind in der Regel somit in einem wohl definierten Zutand und die DLL-Hell ist nicht mehr so schlimm, vor allem weil Paketmaintainer sich um die schmutzigen Details kuemmern (duerfen) statt Programmierer. Ausserdem liegt der Quellcode de-fakto immer vor, es ist also kein Problem Anpassungen vorzunehmen und gegen neuen Versionen von Bibliotheken zu linken. Somit ist die typische GNU/Linux-Installation so wunderbar schlank, dass wir ein komplettes Betriebssystem auf 1000 MByte unterbekommen (das CD-Zeitalter ist wohl auch vorbei).
Wenn es kein fertiges Paket gibt, ist die Standardinstallationsanweisung:
„configure;make;make install“. Eventuell vorher Abhaengigkeiten selbst installieren -> „–asdeps“.
Das grosse Problem ist die ganze Closed-Source-Software unter GNU/Linux:
Anstatt das Paketieren den Maintainer der Distributionen zu ueberlassen, paketieren die selbst fuer ausgewaehlte Distributionen. Passen die Pakete neuen Versionen der Distribution nicht an und erlauben im schlimmsten Fall „keine Veraenderung“ oder „Weiterverbreitung“. Ein gutes Negativbeispiel ist der Amazon-MP3-Downloader (braucht man fuer ganz Alben), weswegen ziemlich jeder Amazonkunde das kleine Kommandozeilenprogramm „amz“ verwendet.
Der Softwarehersteller sollte einfach nur ein „tar.gz“ mit den Binaries bereitstellen und explizit Neupaketierung erlauben. Um fuer die Zukunft vorbereitet zu sein, sollte gleich von Anfang an auch eine statisch gelinkte Variante bereitgestellt werden (siehe Beschreibung zu Windows oben)!
Wer weiss wie lange das Programm verwendet werden muss, dynamisch gegen GTK1 gelinkte Programme erzeugen heute keine Freude mehr, wenn der Quellcode nicht vorliegt, die Firma laengst vom Markt verschwunden ist und der Anwender damit eine Industrieanlage betreiben muss.
Mit Docker, App-Bundles und CGROUPS koennte sich hier auch einiges noch veraendern. Wenn um Software geht, die nicht von der Distribution bereitgestellt wird.
Und wie loesen das Industriebetriebe mit so einer alten MS-DOS Executable? So lange der 486er noch laeuft und niemand ins Firmennetz kommt…
Dann sieh einfach zu, ob Du wirklich hinter dem „Upstream“ hinterherhecheln musst.
Offenbar besteht hier ein verdammt tiefes Unverständnis, was Paketverwaltung betrifft.
Falscher Faden, ich bitte um Vergebung.
Das ganze Panel ist sehr gut, die Stelle über verschiedene Distributionen ist sehr interessant und ich genieße Arch auf dem Laptop und näher am Upstream zu sein.
Herrlich ist auch als er irgendwann sagt, dass das Problem eigentlich simpel ist, aber alle die sich dessen annahmen total bescheuert waren 😀
Genieße Arch, es sei Dir gegönnt, nur wenn ich Pakete für Tausende zur Verfügung stellen will, sind Arch und Gentoo keine Optionen.
Ich finde den Ansatz großartig, sich die Dinge selbst zurechtzulegen.
Nur für Anwender, die einfach die aktuellen Gimp- und G’MIC-Versionen benutzen wollen, ist Eigenbau keine Option.
Ich erzähle hier keine Scheiße.
> Ich erzähle hier keine Scheiße.
Seit wann baut man unter Arch seine Pakete selber? Das sind Binaries wie bei fast jeder anderen Distribution doch auch. Mal abgesehen vom AUR.
Arch Linux‘ KISS-Ansatz ist doch eigentlich auch nicht schlecht, denn die Pakete sind ja nicht viel anders als Tar-Ordner und wenn es kein Paktet gibt, besteht im Prinzip die Möglichkeit, ein Pkgbuild im AUR zu veröffentlichen.
Das Problem habe ich so verstanden, das jede Distribution im schlimmsten Fall andere Versionen der benötigten Lib(s) mitliefert und das die (Upstream-)Maintainer der Libs sich nicht sonderlich darum scheren, das ihre ABIs stabil sind, weshalb man quasi gezwungen ist, die Programme bei jedem Update einer Lib neu bauen zu müssen, damit einem das Programm nicht um die Ohren fliegt.
Oder um es aus der Sicht eines Programmierers zu sagen: Wenn ein ABI einmal öffentlich ist, dann muss ich mich darauf verlassen können, das sich das Verhalten des ABIs und sein Aufruf nicht mehr grundlegend ändert. Ebenso muss ich mich darauf verlassen können, dass das Entfernen von Funktionen aus Libs vorher mit ausreichend Vorlauf (IMHO mind. 2 Minor-Releases) angekündigt wird. Beides ist leider unter Linux keine Selbstverständlichkeit.
Dann sieh einfach zu, ob Du wirklich hinter dem „Upstream“ hinterhecheln musst.
Offenbar besteht hier ein verdammt tiefes Unverständnis, was Paketverwaltung betrifft.
Liebe Leute, das einzige, was mir gerade Kopfschmerzen bereitet, ist, ob ich wirklich Gimp 2.8.x und Gimp 2.9.x – hoffentlich bald Gimp 2.10.x in meinem blöden PPA parallel zulasse.
Das ist keine Raketenwissenschaft. Es ist lediglich eine Frage der Hingabe.
Ich habe den Artikel gelesen und einige Kommentare. Ihr solltest nochmal nachlesen was der unterschied zwischen einem Paket und einer Binarie ist. Ich will nicht trollen.
Thja, die „schlauen“ Entwickler und die FSF sehen ja die Fehler lieber bei Windows… und dann wundern sich alle, dass der Marktanteil von Linux bei mageren 1% stagniert. Das gibt für jede der zig tausend Distributionen einen Marktanteil um die Promille. Mit Sicherheit wird es eines Tages eine „Top-Distribution“ (Name von LinuxUser.de .. ha ha) alle anderen übertreffen… ja ganz sicher!
Auf Windows 8 installier ich euch Programme für Windows 95 OHNE irgend eine Emulation zu installieren. Aber he ja, Linux ist anders und halt besser, ja sicher, ehrlich! Aber ich erzähl ja nix inteligentes. Die Linuxer halten sich ja alle für sooo schlau.
Wenn ich Programierer wäre, ich würde native Programme nicht für „Linux“ entwickeln.
Steam hat’s doch hingekriegt. Bei Valve kann jeder unbedarfte Gamer seine Software problemlos unter Linux installieren. Einfacher geht’s nicht mal unter MacOS 😉
Wo er recht hat, hat er recht.. dieses ganze geforke und dröflzigmilliarden Distributionen, die ihr eigenes Süpchen kochen mag zwar für Abwechslung sorgen, sorgt aber halt auch dafür, dass es eben nicht jede Software für alles gibt. Es währe schön wenn da mal alle, oder die meisten, zumindest die Grossen, also Debian/Ubuntu, Arch und Fedora/RHEL sich mal Zusammensetzen (besser, man müsste die Maintainer wohl zusammensperren) und erst dann wieder von einander lassen, wenn sie sich auf sich auf eine Binärkompatibilität geeinigt haben. Aber das wird wohl nie geschehen, wenn sich ja schon wieder Entwickler von Debian abspalten und ihr eigenes system bauen wollen, weil sie sich ja nicht einmal beim init system einig sind
Der OpenSuse Build Service wurde […] von Novell unter der GPL offiziell freigegeben. Damit lässt sich Software kompilieren und in entsprechende Pakete verpacken. Nicht nur für die Suse-Distribution ist dies möglich, sondern auch für Fedora, Debian und Ubuntu.