Software-Installationen

Immer häufiger werde ich in letzter Zeit gefragt, ob ich dem Otto-Normalnutzer Linux empfehlen würde. Klar, eigentlich kein Problem, die Software, die bereit steht, ist sehr gut und funktioniert brauchbar, und wenn es auch noch Kompatibilitätsprobleme mit MS Office gibt, so können diese mit ein paar Erklärungen auch gut umgangen werden.

Aber: ich sage trotzdem immer, dass die Zeit dafür noch nicht reif ist – denn es ist für einen Neuling schwer bis unmöglich, Software zu installieren. Ich habe es schon mehrfach geschrieben, und es lässt mich nicht los.

Und es gibt kaum sinnvolle Lösungen, die sich ernstzunehmend am Horizont abzeichnen. Eine von mir favorisierte wäre ja, dass alle wichtigen Distris auf ein gemeinsames Format umschwenken, und sich daran halten. Nur macht es leider keiner, obwohl die Ideen dazu schon lange vorhanden sind.
In mir wächst weiter die Idee einer Online-Petition dazu, immerhin wüsste ich jetzt schon mal, wo ich die aufsetzen könnte.

Eine andere interessante Lösung wäre, wenn das neue Suse und Fedora am besten noch zusammen mit Mandrake auf eine gemeinsame Basis aufsetzen würden – eine Art Verschmelzung der Community-Projekte wäre zwar sehr komplex und sicherlich auch alles andere als einfach, würde aber auf Dauer mehr Vorteile als Nachteile mit sich bringen – denn danach würden die wichtigsten RPM-Distris das gleiche Format akzeptieren können!
Wenn es wenigsten nur noch zwei Formate im Linux-Bereich geben würde (rpm und deb) statt zig, wäre schon viel geholfen:-/

So bleibt mir nichts weiter, als weiter nach verbündeten zu suchen, die mir helfen würden, eine Petition aufzuziehen – wer irgendwas beisteuern könnte (z.B. eine Übersetzung ins französische oder so), dem wäre ich sehr dankbar.
Einfahc hier einen Kommentar hinterlassen, um die Welt zu verändern🙂

3 thoughts on “Software-Installationen”

  1. Da muss ich doch gleich mal darauf antworten.😉

    Ich bin leider noch nicht in die Verlegenheit gekommen, jemandem effektiv GNU/Linux ans Herz gelegt zu haben,so dass es gewirkt hat. Dementsprechend kann ich nur aus meiner Perspektive darüber nachdenken, wie die Softwareinstallation auf einen Unerfahrenen wirken mag.
    Ich würde da pauschal einmal behaupten, sie ist einfach und kompliziert zugleich.🙂 Einfach in dem Zusammenhang, wenn man sich nur auf die schon verpackten Pakete in den offiziellen Repositories einer Distribution beschränkt. Das sind bei Debian/Ubuntu eine Menge, bei Fedora auch ausreichend viele. Schwieriger wird es bei nicht verpackten Programmen.
    Aber das sind Standardargumente, die hinlänglich diskutiert werden/wurden und bekannt sind.
    Wie sieht aber die Installation für einen (um mal das Stereotyp zu benutzen) mausverwöhnten Windows-DAU aus? Die Kommandozeile muss dabei aussen vor bleiben, denn sie wäre zu kompliziert. Bleiben also die grafischen Aufsätze auf yum/apt-get. Egal ob Synaptic/kyum/yumex, alle bieten imho eine unintuitive Oberfläche. Die einzelnen Pakete sind vermeintlich wild verteilt in solch nichtssagenden Untersektionen wie “Applications/Multimedia” oder “User Interface/Desktop”. Der Unerfahrene sucht z.B. einen MP3-Player, findet mpg321 in der ersten Kategorie, wundert sich über den englischen Text, der dort als Beschreibung steht – oder versteht ihn erst gar nicht – und hat auf einmal ein Konsolenprogramm installiert, obwohl er einen Winamp-Klon suchte.
    Die Kategegorien können den grafischen Oberflächen nicht angelastet werden, denn die Ursache der Informationen liegt schon im Paket selbst. Die Programme an sich machen schon das möglichste (allen voran Synaptic).
    Wie sollte also eine einfache grafische Installation aussehen? Eine Lokalisierung der Paketbeschreibungen in die verschiedenen Landessprachen sollte selbstverständlich sein. Das ist auch heute schon möglich, aber noch zu selten umgesetzt. Viel wichtiger wäre aber noch eine bessere Aufbereitung der gegebenen Informationen in sinnvollerere Untersektionenen. Dazu müssten die Paketformate Metainformationen verstehen können, wie z.B.:
    – für den KDE-Desktop (bzw. Qt-basierend)
    – für den Gnome-Desktop (bzw. gtk+-basierend)
    – Konsolenprogramm
    – Lokalisierung (deutsch, englisch, französisch, etc)
    Alleine diese vier würden imho schon reichen, um schon etwas Verwirrung zu nehmen. Denn so könnte effektiver gesucht werden. Nimmt man jetzt z.B. einen Filter daher und setzt sein Häkchen nur bei KDE und Lokalisierung, würde die verfügbare Paketmenge schon beträchtlich schrumpfen und man installiert nicht zufällig ein Programm aus derselben Sektion (wie z.B. “Programme/Multimedia”), dass auf gtk+ basiert und sich dementsprechend nur schlecht in den KDE-Destkop integriert. Der entsprechende Filtermechanismus sollte beim ersten Start des yum/apt-get-Aufsatzes abgefragt werden (und natürlich änderbar sein).
    Das würde die Installation von vorbereiteter Software schon vereinfachen – imho. Das Problem dabei bleibt trotzdem, dass die schon bestehdenen Verhaltensweisen (Webseite besuchen, Installationsprogramm runterladen, Doppeklick auf setup.exe) aufgebrochen werden müssen. Die Mechanismen von yum/apt-get haben ohne Zweifel ihre Vorteile: einfaches Installieren (inklusiver benötigter Abhängigkeiten) und keine Sorge mehr wegen Updates. Auch der Download muss nicht erst von Hand angeschmissen werden.
    Problematisch wird es natürlich dann, wenn die Pakete kompatibel mit anderen Distributionen sein sollen. Eine Verwendung eines einheitlichen Paketformates wäre da vielleicht ein Schritt, er wäre aber meiner Meinung nach nicht ausreichend. Dass ein RPM nicht auf allen drei großen RPM-basierenden Plattformen (Fedora, Suse, Mandrake), läuft ist schon jetzt bekannt. Das fängt bei einfachen Benennungen der Abhängigkeiten an, indem manche Pakete und Fedora anders heissen als unter Suse und die Installation daran scheitert (was aber eigentlich i.d.R. ein Fehler des Paketes ist) und hört zum anderen mit der verwendeten Version des in die Distribution integrieten Paketes auf. Wer will der Distribution vorschreiben, welche KDE-Version sie z.B. integriert? Es mag manche Programme geben, die nur mit KDE 3.4 funktionieren, nicht aber mit KDE 3.3. Oder einzelnen Bibliotheken? Oder, noch schlimmer, der glibc? Fedora hat einen (ursprünglichen) Releasezyklus von ca. 6 Monaten, Suse ebenso. Mandrake ist auf ein Jahr hochgewandert. Bei Debian dauert es, bis es fertig ist.
    Die LSB ist in diesem Sinne vielleicht eine Möglichkeit, den kleinsten gemeinsamen Nenner zu schaffen, sie packt das Problem jedoch nicht am Ansatz an: Den unterschiedlichen Philosophien und Ausrichtungen der verschiedenen Distributionen. Trotzdem ist es ein wichtiger Schritt, um zumindest auf Unternehmensbasis Einheitlichkeit (durch Binärkompatibilität) zu schaffen. Aber das gilt natürlich nur für die Programme, die das auch wollen. Problematisch wird es jetzt schon bei den kleinen “Gimmicks” von gnomefiles oder kde-apps. Noch schwieriger dürfte es werden, wenn z.B. die ersten “normalen” Zeitschriften, mit kleinen Progrämmchen drauf erscheinen. Werden die z.B. ein Jahr später mal wieder ausgebuddelt, ist die Karawane schon längst weitergezogen.
    Das alles einem normalen Windows-User zu erklären, der den Stillstand von Microsoft kennt, dürfte schwierig werden.
    Den Ansatz, den ich verfolgen würde, wäre keine Vereinheitlichung des Paketformates, denn er löst die Probleme nicht, sondern eine Vereinfachung der Installation über offizielle Repositories. Denn nur diese sind auch wirklich passend zur gewählten Distribution. Sicher löst das auch nicht alle Probleme, denn um z.B. Fedora auf die Paketanzahl von Debian zu bringen, sind noch ein Haufen mehr Freiwillige vonnöten. Auch die Programme von kde-apps oder gnomefiles liegen dann trotzdem noch im Quelltext vor. Aber das ist ein Umstand, mit dem Mann unter GNU/Linux imho umgehen lernen muss, denn er liegt in der Natur, dem Aufbau und dem “fliessenden” Zustand des Systems.

    Und da ist der Kommentar schon länger als der Blog-Eintrag geworden. Mir fallen schon leicht die Augen zu, deswegen bitte ich kleinere Unstrukuriertheiten zu entschuldigen.😉

    Sebastian

  2. Ich kann dazu erst mal sagen: ja. Du hast mit nahezu allem Recht. Ich möchte aber einige Sachen deutlicher herausstreichen: mir geht es nicht nur um den Nutzer, der eventuell tatsächlich auf eine andere Softwareinstallationsweise getrimmt werden könnte, es geht mir auch um die Leute, die Pakete bereit stellen – und die werden nie mehr als zwei oder drei verschiedene Linux-Pakete bereit stellen, wenn überhaupt. Und auch auf die muss man Rücksicht nehmen. Und dafür brauchen wir eine Methode, die es erlaubt, auf wenigstens allen großen Distributionen ein solches Paket problemlos zu installieren.

    Denn auch wenn die Packager der Distris teilweise großartige Arbeit leisten – es werden niemals auch nur ansatzweise genug Packager zur Verfügung stehen, alle aktuelle Software in die Repos einzupflegen (und dort auch zu pflegen), vor allen Dingen dann nicht, wenn Linux sich weiter verbreiten wird. Schon jetzt ist die Softwaremenge auf kde-apps unüberschaubar, wer da gerne mal was austesten will, kommt ums kompilieren nicht mehr hinweg. Deswegen halte ich den Ansatz über die bestehenden statisch gehaltenen Repos nicht für zukunftsträchtig.

    In dem Zusammenhang meine ich mit einheitlichem Paketformat auch nicht nur z.B. RPM, sondern eine binäre Einheitlichkeit, die auf allen Distris funktioniert. Dafür braucht man ja auch teilweise ähnline Systempfade, etc.
    Das dies das alles noch komplexer macht, ist mir klar, aber ich bin trotzdem der Meinung, dass das Problem dringend angegangen werden muss, weil es sonst nur schlimmer wird.

    Die beste Idee, die ich bisher in der Hinsicht präsentieren kann, wäre eine Art Ur-Distri von wenigstens Suse, Fedora und Mandrake, auf der die jeweiligen Distris aufbauen. Auf dieser könnte dann mit einem Paketformat, dass die einfache “Windows-Like” Installation mit den Vorteilen der Repositories verbindet (die Infos kann man ja ruhig im Paket selbst unterbringen, warum auch nicht?) aufbauen. Damit wäre schon mal viel geschafft, und jeder könnte seine Software neben dem Quellcode dafür verpacken. Die anderen Distris (Gentoo, etc.) würden dann über kompatibilitäts-Schnittstellen wie z.B. Alien ihren Weg finden.

    Eine andere, die mir gerade spontan einfällt, wäre es, das Bauen eines Pakets so weit zu automatisieren, dass die großen Distris nur noch Paketisierungsserver bereit stellen müssten, auf die man die Quellen packt, und die diese dann selbst in die Repos schiebt.

    So oder so denke ich, dass das Problem zwar bewußt ist, aber niemand ernsthaft über Lösungen diskutiert, und die möglichen Lösungen nicht ernst genug angepackt werden. Deswegen will ich in der Hinsicht Druck ausüben, und die Diskussion darüber anregen.

    Auf alle Fälle aber danke für den langen Kommentar und die konstruktive Kritik🙂

  3. Ah, jetzt wird mir Dein Anliegen auch schon etwas deutlicher.😉

    Einfallen würden mir zwei Möglichkeiten, dieses zu lösen:
    1. Pakete werden LSB-Konform von den Autoren erstellt.
    2. Es gibt eine Art Vorlage, in der die Autoren grundlegende Informationen eintragen müssen, damit das Programm auf allen (großen) Distries compilieren kann.

    Zu 1.)
    Dies wäre sicherlich für den/die Autor(en) eine der einfachsten Möglichkeiten. Ein LSB-konformes RPM sollte sich auf allen LSB-basierenden Distries installieren lassen. Problematisch könnte dabei allerdings werden, wie ich weiter oben schon meinte, (ich habe mich mit den LSB-Vorraussetzungen allerdings noch nicht wirklich auseinandergesetzt), die gemeinsame Mindestbasis werden. Gerade kde-apps ist sicherlich oftmals bleeding/cutting edge. Außerdem müssten die Autoren überhaupt gewillt (oder befähigt) sein, ein solches Paket zu erstellen. Ob Autoren, die selber z.B. gentoo benutzen, an einem LSB-konformen RPM interessiert sind, dürfte zumindest fragwürdig sein (bezogen auf den Installationsprozess bei gentoo. AFAIR kann es auch LSB-konform werden).

    Zu 2.)
    Ein Vorlage würde ich mir in der Form eines abgespeckten SPECs vorstellen: Eingetragen werden die grundlegenden Informationen sowie eine ausführliche Liste der BuildRequires und Requires. Die Namen für die Pakete von letzterem sollte auf einer standardisierten Liste basieren (wo Devel-Pakete z.B. grundsätzlich mit “*-devel” aufhören, nicht wie bei Debian mit -dev). Die Autoren sollten am besten Wissen, was gebraucht wird. Auch evtl. benötigte Compiler-Optionen sollten gesetzt werden. Die %files-Liste wird dabei aber weggelassen. Selber compilieren sollte der Autor es nicht müssen, das eintragen der Informationen dürfte dadurch auch nicht lange dauern.
    Anschließend sollte es ein Programm geben, dem man diese “SPEC” einfach übergeben kann und es kümmert sich um den Rest: Angefangen beim Download über das Auflösen der BuildRequires (anhand einer lokal vorhandenenen “Übersetzungsliste”, in der die generischen Programmnamen mit dem reellen Namen des in der Distribution enthaltenen Paketes abgeglichen wird (Bsp.: Imagemagick -> ImageMagick (Fedora) -> imagemagick (Debian)). Anschließend werden die Distributionsspezifischen Compileroptionen hinzugefügt (zusammen mit den vorgegebenen) und das Paket gebaut. %files wird dabei automatisch gesetzt (rpmbuild müsste dafür etwas “intelligenter werden).
    Problematisch ist aber wiederum, wer dieses Paket dann baut: Der User, der es haben will? Der Autor selber? Oder, wie von Dir angedacht, die Distribution in einm automatischen Prozess. Ersteres könnte ich mir am ehesten vorstellen. Die Vorraussetzung dafür ist natürlich, dass der Buildprozess wirklich automatisch durchläuft. Bei dem Autor selber dürfte es evtl. problematisch werden: Entweder er hat kein Interesse an einem Paket (siehe oben, dass Eintragen der Informationen dürfte aber trotzdem machbar sein, da nicht allzu aufwendig) oder er auf seiner Installation teilweise zu neue Pakete drauf, gegen die das Paket dann gelinkt würde. Und nicht jeder hat die Möglichkeit oder die Muße, ein chroot oder Buildsystem zu installieren (was auch ein Problem bei LSB-konformen Paketen darstellen könnte).
    Denkbar wäre sicherlich auch ein automatischer Buildprozess von der Distribution und verschieben in ein Repo. Allerdings braucht ein Repo i.d.R. wohl mehr Pflege (gerade Konflikte zwischen einzelnen Paketen). Von einem Repository erwarte ich zumindest, dass es zumindest in sich (möglichst) problemlos ist. Wenn trotzdem Probleme auftauchen (was eigentlich nicht zu vermeiden ist), braucht es wieder Freiwillige, die diese beheben.

    Am schwierigsten dürfte dabei werden, möglichst viele Autoren/Programme dazu zu bekommen, einen dieser Wege einzuschlagen. Denn es bringt imho relativ wenig, wenn z.b. bei kde-apps nur 50% oder weniger der dort angegebenen Programme auf diese Weise installiert werden können, der Rest aber dennoch compiliert werden muss. Der zweite Vorschlag wäre dort wohl am ehesten umsetzbar. Wer die Programme dann compiliert, bleibt die zu klärende Frage.
    Allerdings birgt natürlich auch alles gewisse Risiken: Ein RPM zu erstellen, ist für einen fortgeschrittenen User mMn. nicht unbedingt das Problem (die BuildRequires ist ja meistens am schwierigsten). Bei Debs ist es mit der “Quick & Dirty”-Methode sogar ohne Vorwissen machbar. Ein sauberes RPM/Deb ist dabei aber weitaus schwieriger (rpmlint lässt grüßen). Und ob unsaubere Pakete nicht eher schädlicher wären, als dass sie helfen würden, bleibt dabei zu klären (Windows lässt grüßen).
    Zu bedenken wäre dabei auch noch, inwieweit alle angesprochenen Methoden vertrauenswürdig wären. Die in den offiziellen Repos enthaltenen Pakete sind z.B. alle signiert und qualitativ relativ hochwertig. Bei RPMs von kde-apps bin ich selbst aber oftmals auch am Zweifeln, ob ich nicht gleich aus dem Source compiliere. Für böswillige Naturen dürfte ist die Angriffsfläche auf jedenfall größer.

    Ich stimme allerdings mit Dir überein, dass es mehr vorgefertigte Pakete geben sollte. Nur über den Weg dahin bin ich mir selbst noch nicht im Klaren. Autopackage hegt ja z.B. auch diese Ziele. Nur hört man wiederum von mehreren Seiten, dass diese Pakete auch nicht gerade sauber sind. Vom vorbeiinstallieren an dem Distributionseigenen Paketsystem mal zu schweigen. Alien wiederum setzt und löst keine Abhängigkeiten, was es zum Teil unbrauchbar macht.

    Soweit erstmal.😉

    Sebastian–>

Comments are closed.