Freie Software ist immer im Vorteil gegenüber den 3-Zeichen Dateianhangs- und Lizenzkeygeneraotren- und Crackquellen-Experten.

Freie Software ist gut für freie Bürger.
Freier Quellcode ist die Basis für fundierte Systemkenntnis.

Wo sich die Vasallen von M$ Frickelware im Dunst
der Registry-Finsternis und DLL-Konflikte rumplagen
da liest der aufgeklärte OpenSource Benutzer
schnell die passende Manpage und erfreut sich
auch Freitags gern am lehrreichen Quellcode.

So muss das sein!

Linux und *BSD sind klar im Vorteil!

 

Bei einem OS wie XP gibt es das nicht mehr. Meine letzen dll-Konflikte liegen lange zurück.Schlag nach bei Side-By-Side-Assemblies ! Dagegen ist der Dependencies Jungle bei Linux höchst lebendig.

 

"Bei Linux" (und *BSD) gibt es die Wahl:

Die Wahl des Distributors und der Art,
wie der das gewählte Paketmanagement-System mit Inhalt füllt.
Abhängigkeiten liegen dabei in der Natur der Sache.

Wenn du mit Paketabhängigkeiten und -konflikten beim M$-OS
nicht in Berührung kommst, dann liegt das daran, dass es dort
gar kein vergleichbares Paketmanagement-System gibt.

Versuch dort mal eine installierte Softwarekomponente
sauber zu de-installieren.
Wenn der Autor der Komponente kein oder ein fehlerhaftes
De-Install-Script beigelegt hat, dann hast du eben pech gehabt.

Mit einem Paketmanagement-System wäre das nicht passiert.

 

> Bei einem OS wie XP gibt es das nicht mehr
Und ich dachte, da wäre es noch schlimmer geworden. Jedes Programm hat seine eigenen DLLs und ähnliches. Aber ich habe auch keine Ahnung. <:

> Dagegen ist der Dependencies Jungle bei Linux höchst lebendig.
Sehr richtig. Ein Umstand, den man so schnell auch nicht abschaffen können wird. Die Lösung ist aber immerhin allemal zufriedenstellender als die bisherigen unter Windows. Aber jetzt gab ja Microsoft MSI 3.0 raus, womit sich zumindest die Abhängigkeiten von verschiedenen Patches auflösen lassen sollte. Auch bei Microsoft geht es also vorwärts. (:

@blablah:
> Mit einem Paketmanagement-System wäre das nicht passiert.
Wenn der Autor des Pakets Mist baut, beispielsweise eine falsche pkg-plist angibt, kann das auch doof werden. <: Sehr schön sind auch immer wieder zwei Pakete, die gleichnamige Dateien im gleichen Verzeichnis installieren.

 

Guter Witz. Ich kann mich nicht daran erinnern in den letzten 2 Jahren auf einem meiner XP-Systeme ein Bibliotheksproblem gehabt zu haben (und ich installiere und teste sehr viele Programme). Mit dem Side-By-Side-Assemblies-Konzept hat sich das erledigt. Bei Linux ist dagegen die Bibliothekenproblematik ein alltäglicher Krampf. Auch mit Mitteln wie apt oder up2date oder yum (bei Fedora) Neulich mußte ich, um unter Debian Synaptic in der aktuellen Fassung installieren zu können, 20 MB Bibliotheken aus dem Internet nachladen und installieren, war entsprechend zeitaufwendig). Für mich ist das der gravierende Nachteil von Linux. Wenn ich irgendwo im Internet ein interessantes Programm entdecke, dann habe ich unter XP dieses Programm bis auf ganz wenige Ausnahmen in Sekunden zum Laufen gebracht. Nicht so bei Linux. Wenn ich da nicht alle vertikalen ( Distributionsebene ) und horizontalen (Distriversion ) Bibliotheksabhängigkeiten beachte, habe ich wenig Chancen, ein solches Programm zum Laufen zu bewegen. Dieser Umstand ( der ja bei Linux konzeptbedingt ist und sich nicht ohne weiteres ändern läßt), hat mir schon oft den Spass an einem OS verleidet, für das ich ansonsten durchaus Sympathie empfinde.

Rainer Hattenhauer schreibt in seinem Buch : Red Hat & Fedora Linux S.261 dazu :

Gemeinerweise genügt es oft nicht, die angemahnten Pakete nachzuinstallieren. Diese können selbst auch von weiteren Paketen abhängen, sodass man sich durch einen wahren Abhängigkeitsdschungel arbeiten muss.Und wenn gar bestimmte Pakete nur mit bestimmten Bibliotheksversionen harmonieren, ist da Chaos perfekt.

Wer dann angesichts einer solchen Situation schreibt :

leidet unter einem starken Realitätsverlust und verliert für mich an argumentativer Glaubwürdigkeit.

 

@franzkat:
> Mit dem Side-By-Side-Assemblies-Konzept hat sich das erledigt.
Wo ist da das besondere? Unter Unix oder vielmehr Linux kann man ebenfalls Libraries mit unterschiedlicher Major-Version installieren, falls du darauf hinaus willst. Und man kann sich auch gleichzeitig nutzen, falls du das meinst. Dynamisch gelinkte Applikationen haben natürlich weiterhin ihre Abhängigkeiten, weshalb das Argument irgendwie keinen wirklichen Wert hat. Das Major-Versionen nicht mehr überschrieben werden müssen und man mehrere gleichzeitig laden kann, ist natürlich eine sehr schöne Sache, aber nichts, was es nicht schon Jahrzehnte vorher bei anderen OS gab. *g*

In Sachen Shared Libraries, dynamischem Linken und Effizienz hatte Microsoft sehr viel aufzuholen. Wie du richtig erkannt hast, ist mit Side-by-Side-Assemblies da unter XP schonmal ein großer Schritt getan und ein Großteil der DLL-Hölle beiseite geräumt. Ich kenne SbSA nur oberflächlich, habe mich für die Details und Whitepapers nie interessiert, aber gerüchteweise soll das ganze sogar sehr sauber und gut durchdacht sein. Leider gab es das nicht von Anfang an und es dauert immer recht lange, bis sowas etabliert ist. AFAIK gibt es SbSA auch erst ab XP?

> 20 MB Bibliotheken aus dem Internet nachladen und installieren
Ja und wo ist das Problem? Die 20MB Bibliotheken brauchst du auf jeden Fall, ob sie nun mit im selben Paket oder in extra Paketen sind. Shared Libaries zusammen in das Paket eine Applikation zu packen, ist nur meist höchst unsinnig. Sie sollen ja gerade unabhängig sein, von vielen Programmen geteilt, getrennt geupdatet werden können etc.. Was du hier gerade machst, ist den Zweck von Shared Libaries als Gegenargument für Shared Libs zu verwenden.

Hier wäre Mozilla ein ganz gutes Beispiel. Nutzt ein anderer Browser wie Galeon zum Rendern Gecko, muß das komplette Mozilla mit allem Krempel drumherum installiert werden, selbst wenn man das nicht will. Und wenn Gecko weiterentwickelt wurde, muß man warten, bis es ein Update für Mozilla gibt. Sehr viel sinnvoller wäre es hier, Gecko in ein extra Paket auszulagern und nur als Abhängigkeit zu haben.

> Wenn ich da nicht alle vertikalen ( Distributionsebene ) und horizontalen (Distriversion ) Bibliotheksabhängigkeiten beachte, habe ich wenig Chancen, ein solches Programm zum Laufen zu bewegen
Und ohne Treibstoff fliegt ein Flugzeug nicht. Wenn dem Linker Libs fehlen, startet die Applikation nicht. Logisch. Und das ist natürlich unter Windows ganz genauso. Also was willst du mir damit sagen?

> Dieser Umstand ( der ja bei Linux konzeptbedingt ist und sich nicht ohne weiteres ändern läßt)
Da gibt es eigentlich auch nichts zu ändern, außer man verzichtet auf Shared Libs. Und das tut man ganz sicherlich nicht. (:

> leidet unter einem starken Realitätsverlust
Nunja, hast du mal eine Software unter Windows installiert? Da werden in der Regel gar keine Abhängigkeiten überprüft (wie auch). Sehr einfaches Beispiel: du installierst Cgoban2, eine Java-Applikation. Java hingegen wird nicht mitinstalliert. Der User muß wissen, wie die Abhängigkeiten sind und sie manuell nachinstallieren, ansonsten startet Cgoban2 erst gar nicht. Das gleiche gilt in dem Beispiel dafür, Java zu updaten, wenn die Version zu alt ist. Will man eine alte Version parallel installieren, könnte das ebenfalls schwer werden. Es gibt keine Möglichkeit, Abhängigkeiten unter Windows schnell herauszufinden oder gar automatisch aufzulösen. Soviel zur Paketebene.

Auf der Lib-Ebene das gleiche Spiel. Vielleicht wolltest du ja auch darauf anspielen, daß einem beim Compilieren häufig irgendwelche Header fehlen, die man dann nachinstallieren muß? Nunja, compilier mal etwas unter Windows (am besten die selbe Software) und du wirst genau die selben notwendigen Abhängigkeiten feststellen und Header nachinstallieren müssen. Aber man muß ja nicht gleich kompilieren. Es ist überall so, wo Libs nicht statisch gelinkt oder redundant in jedem "Paket" mitgeliefert werden. Wegen seiner Größe häufig weggelassen und einzeln gezogen werden muß beispielsweise vb6.dll von Visual Basic. Vielleicht hat das auch lizenzrechtliche Gründe.

 

Deine Argumentation in diesem Zusammenhang ist schief und geht an meiner Position vorbei :


Erst behauptest du :

Wenn man dass dann widerlegt, wechselst du die Argumentationsebene und sagst, wo denn das besondere an einem solchen Konzept sei, das sei doch nichts Neues.

Das heißt, deine Argumentation in diesem Zusammenhang ist inkonsistent und ausweichend.

Es ging darum, dass unter XP nicht mehr wie früher Probleme mit Dlls auftauchen, weil M$ hier gelernt hat und das Problem in den Griff bekommen hat.

Ich finde es nicht normal, wenn ich für ein 500 KB-Programm erstmal 20 MB- Bibliotheken nachladen und vor allem zeitaufwendig installieren muss. Wenn ich das Programm nicht nutzen wollte, brauchte ich die Bibliotheken eben nicht. Da mir im Gegensatz zu dir eine einseitige Argumentation fremd ist, sei hier dazugefügt, dass es auch solche Fälle unter Windowes gibt, die aber im Gegensatz zu Linux selten auftreten. Beispiel :
Wenn ich das hilfreiche Tool Freefiles nutzen möchte (auch ein kleines Tool von <1MB ) muss ich MS-DOT-Net mit 23MB nachinstallieren.

Nein, das ist es nicht. In der überwiegenden Mehrzahl sind frei verfügbare Programme kompatibel mit aktuellen Windows-Versionen (meistens sogar bis Win 95 B zurück ). Das heißt bis auf wenige Ausnahmen, muss ich mich bei Windows-Programmen nicht um diese Problematik kümmern.

Die im letzten Abschnitt angeführten Beispiele sind sehr manipulativ, weil jeder, der sich mit der M$-Java/Sun-Problematik beschäftigt hat, weiß dass das ein Sonderfall ist, den man so für die Problematik sicher nicht verallgemeinern kann.
Es geht hier auch nicht um die spezielle Problematik eines Programmierers, sondern um die eines normalen Users, der -wie ich oben sagte - irgendein kleines Tool im Internet findet und installieren möchte.

Insgesamt muss man feststellen, dass du die Problematik des Dependencies Jungle völlig leugnest ( und was wohl bedeutet die Metapher des Dschungels in diesem Zusammenhang ? - auf das Hattenhauer-Zitat gehst du ja bezeichnenderweise überhaupt nicht ein) bzw. die Behauptung aufstellst, bei M$ sei das im Prinzip auch nicht anders und der User hätte da mit den gleichen Problemen zu kämpfen.

 

> Deine Argumentation in diesem Zusammenhang ist schief und geht an meiner Position vorbei
Schön, daß du meine Postings wenigstens aufmerksam liest (das ist ernst gemeint). Vielleicht fehlte hinter meiner Aussage ein zweiter <: oder :>. Das war auch etwas sarkastisch und provokant gemeint, weil schon der Satz, auf den ich mich bezog, etwas abhoben und provokant war.

> Wenn ich das Programm nicht nutzen wollte, brauchte ich die Bibliotheken eben nicht
Dann mußt du sie auch nicht installieren. Trivial. (: Und die Leute, die sie schon haben, müssen sie kein zweites mal herunterladen.

> Nein, das ist es nicht.
Ist es. Lösch eine DLL, auf die ein Programm gelinkt ist, und es startet nicht mehr. Probier es einfach aus, darüber muß man nicht diskutieren.

> Insgesamt muss man feststellen, dass du die Problematik des Dependencies Jungle völlig leugnest
Nein, das hast du falsch aufgefaßt. Ich würde es zwar nicht als Dschungel bezeichnen, aber unschön ist es allemal, da sich Abhängigkeiten, die Abhängigkeiten haben, sehr schlecht manuell auflösen lassen. Die Notwendigkeit zusätzlicher Tools und Datenbanken ist natürlich schlechter, als wenn dem nicht so wäre. Komplexität ist immer unschön.

Nur liegen Abhängigkeiten in der Natur von Shared Libs (und nicht nur dort), weshalb daran nichts zu ändern ist. Wenn du mein anderes Posting genau gelesen hast, wirst du dort auch eine Aussage finden, daß die einzige Abhilfe statisches Linken wäre, was man natürlich nicht wolle. Da kann man wohl nur schwerlich auf Leugnung kommen. In einem anderen Thread schrieb ich, daß ich Linux ohne Internetanschluß auch nicht nutzen wollen würde. Sich die Pakete per Hand von CDs zu suchen, ist nicht schön.

> die Behauptung aufstellst, bei M$ sei das im Prinzip auch nicht anders und der User hätte da mit den gleichen Problemen zu kämpfen
Selbstverständlich nicht. Ein Programm braucht eine Lib, schon hast du eine Abhängigkeit. Das ist nunmal so und eigentlich sehr einfach zu verstehen. Dem Benutzer wird aber häufig entgegengekommen. Wie ich schon schrieb, werden Programme statisch gelinkt. Das mag im Einzelfall eine Lösung sein, ist ansonsten aber Unsinn. Einfach, aber Unsinn. Ist unter Linux genauso machbar, nur wird es glücklicherweise bis jetzt weitesgehend vermieden. Die DLL-Hölle vor XP macht das aber oft quasi notwendig unter Windows.

Der zweite Fall wäre, daß Programme ihre Libs selbst mitbringen. Das führt den Sinn und Zweck von Shared Libs natürlich völlig ad absurdum und darüber brauchen wir nicht weiter diskutieren. Auch hier kann es nur eine Lösung für den Einzelfall sein und auch hier ist es unter Linux realisierbar und auch hier wurde man davon bisher weitesgehend verschont und auch hier war es unter Windows eine Notwendigkeit, um größeren DLL-Problemen aus dem Weg zu gehen.
Du verkennt übrigens die Situation. Windows ist ein OS, das nur auf sehr wenigen Architekturen läuft. Selbst wenn man es wollte - man will es nicht - wäre der Weg, einem Unix-Programm Libs beizulegen, absolut inakzeptabel. Es läuft unter dutzenden von Architekturen und dutzenden von Betriebssystemen. Die Kombination aller ist so groß, daß es faktisch nicht möglich ist, für jede ein Paket mit allen Libs zu erstellen. Selbst wenn man auf Updatebarkeit, Modularität, Sicherheit und Robustheit pfeift, wäre es daher keine akzeptable Lösung.

Der dritte Weg, dem Benutzer entgegen zu kommen, ist, daß beispielsweiser einer CD die Abhängigkeiten als zusätzliche Software beiliegen. DirectX wäre hier ein Beispiel. Diese Lösung ist völlig akzeptabel, wenn man denn den Platz auf dem Medium hat. Das läßt sich unter beiden OS praktizieren und wird auch gemacht. Da unter Linux bereits bestimmte APIs und Desktops Abhängigkeiten sind (die man unter Windows immer und garantiert verfügbar hat), kann da allerdings einige zusammen kommen.

Der vierte Weg - der, der unter Windows fehlt - ist der, zu jedem Programm die Abhängigkeiten zu verzeichnen, die dann automatisch aufgelöst und installiert oder aktuallisiert werden können. Dieser Weg ist bezüglich der Einfacheit, Sicherheit und Robustheit der beste Weg. Nachteil ist hier eben, daß man ein Paket braucht, in dem die Abhängigkeiten vermerkt sind. Hat man das nicht, hat man im Endeffekt die selbe Situation wie unter Windows, nur wird man meist auch weder statische gelinkte Programme, noch Programme, die die Libs mitliefern finden. Gut! Hier die Abhängigkeiten dann selbst aufzulösen, bedeutet dann allerdings Aufwand. Wie unter Windows im übrigen auch, nur wird dort eben häufig stattdessen Weg 1 und 2 fabriziert.

 

> bzw. die Behauptung aufstellst, bei M$ sei das im Prinzip auch nicht anders und der User hätte da mit den gleichen Problemen zu kämpfen.
Letzteres habe ich soweit ich weiß nicht so gesagt. Die Problematik von Shared Libs ist die gleiche, der User hat aber nicht die gleichen Probleme. Statisch gelinkte Programme sind einfach ohne Abhängigkeiten zu installieren. Das gleiche mit Programmen, die ihre Libs selbst mitbringen und ins eigene Verzeichnis installieren. Für den User stellt das kein Problem dar, die eigentlichen Probleme bleiben ihm verborgen. Einfach eine Lib updaten, die dann von allen Programmen genutzt wird, ist so nämlich nicht mehr möglich, aber das erwähnte ich ja jetzt oft genug. Das ist einer von vielen Faktoren bei der (Un)Sicherheit und (Un)Stabilität, die unter Windows einfach so in Kauf genommen und akzeptiert werden.

PS: Keine Angst, unter Linux macht man bezüglich Sicherheit auf dem Desktop auch viele Fehler und Abstriche. Das wollte ich nur gesagt haben, damit du dich nicht über Einseitigkeit beklagst. (:

 

Manchmal glaube ich wirklich, Linux Nerds haben überhaupt keine soziale Interaktion außerhalb ihres Computers, wo sie über das Internet Windows Benutzer mit ihrem unsinnigen Gebrabbel nerven.

 

Zuerst muss ich mal sagen: Alle Achtung und Respekt vor dem Hintergrundwissen (Wenn es denn ein solches ist ) der bisherigen Poster.
Ich verstehe kein Wort, mir schlackern nur die Ohren.

Aber genau das ist der springende Punkt: Solange ich

begreifen muss, um Linux auch nur zum Start bewegen zu können, disqualifiert es sich. Die Diskussion "Pro/Kontra Linux" führt sich ad absurdum.
Und ich gehöre nicht mal zu den allerdümmsten Usern, arbeite seit 1 1/2 Jahrzehnten täglich viele Stunden mit dem PC, eins meiner Hobbies ist er obendrein.

 

@woistmeinaccount:
> Solange ich [...] begreifen muss, um Linux auch nur zum
> Start bewegen zu können, disqualifiert es sich.
Mußt du nicht. (: Zumal das Side-by-Side sich beispielsweise auf Windows bezieht, ebenso wie die "DLL-Hölle". Dein Argument wäre also höchstens dafür eines, den Computer ganz abzuschaffen.

> Die Diskussion "Pro/Kontra Linux" führt sich ad absurdum.
Nicht wirklich. Nur weil Linux für die wenigsten User in Frage kommt (ob dem tatsächlich so ist, lasse ich mal offen), ist das kein Urteil über die Qualität.

Hinter Unix, damit auch in gewisser Weise hinter Linux, steht schon eine gewisse Philosophie und eine "Liebe" zum System. Ich bin strikt dagegen, daß Umsteiger zu Linux wechseln, ohne diese zu übernehmen oder zu teilen. Man sollte Linux nutzen, weil man Linux mag. Oft scheint es aber so zu sein, daß User nur Linux nutzen, weil sie Windows nicht mögen. Und weil es eben Trend ist, keine Microsoft-Software zu nutzen und weil viele dem Irrtum unterliegen, daß Linux viel elitärer und cooler sei.

Gerade Desktopprojekte wie KDE oder GNOME scheinen sich auch eher an Windows und die "Windows-Philosophie" anzulehnen und zu kopieren (auch schlechtes), anstatt einfach unabhängig von anderen gute und innovative Software zu schreiben. Das gleiche gilt für die "großen Distributionen" wie SuSE oder Mandrake, die auch in Sachen undurchsichtige Fehler und Probleme zu Windows aufschließen. Die Augen sind viel zu oft auf Windows gerichtet, als müsse man zu Windows in Konkurrenz stehen oder gar die gleiche Zielgruppe an Usern haben. Muß man nicht.

 

Achso. Nun, der Massenanwender (wie ich) merkt bei Windows jedenfalls nichts von Side by side und DLL-Hölle, was meine zuvor dargebrachte Meinung ja nur nochmehr bestätigt. Ich rede allerdings von der breiten Masse und bin mir der vielen Hilferufe hier im Forum schon bewusst...

Sehe ich auch so...

Das sollte es auch nicht sein, bewahre, das kann ich mir nun wirklich nicht anmassen.
Ansonsten stimme ich Dir völlig zu.
Wenn Linux und die dazugehörige Software mal irgendwann mit wenigen Mausklicks zu installieren und bedienen ist und die Software mal aussagekräftigere Namen kriegt wie Grub, Gnome, Kantonix, Honkybonky, pinkywinky, R2D2..., dann gehöre ich bestimmt zu den ersten, die es auch ausprobieren würden...

 

@woistmeinaccount:
Glücklicherweise sind die Namen der Software unter Windows aussagekräftiger: Opera, FlashXP, Emule, Gimp. Unter Linux kannst du dir sehr schnell eine Beschreibung angucken, beispielsweise mit "whatis gimp", sofern Manpages dafür existieren. Leider geht hier bei etlichen Desktopprogrammen dazu, diese hervorragende Art der Dokumentation zu ignorieren. Jeder Paketmanager hat aber auch eine Beschreibung für die Pakete inklusive Weblinks, hier geht es beispielsweise mit pkg_info -x gimp.

> Nun, der Massenanwender (wie ich) merkt bei Windows jedenfalls nichts von Side by side und DLL-Hölle, was meine zuvor dargebrachte Meinung ja nur nochmehr bestätigt.
Du verkennst irgendwie, daß Side-by-Side etwas positives ist. Es ist ein Lösungsansatz, der mit XP kam, um die DLL-Hölle in den Griff zu bekommen. Die Problematik mit der DLL-Hölle beschrieb ich oben, indirekt merkt der User etwas davon durch beispielsweise erhöhte Sicherheitsproblematik und erhöhten Updateaufwand. Naja, eigentlich wollte ich auf so ein Blabla nicht weiter eingehen, steht alles sehr ausführlich bereits oben.

> Wenn Linux und die dazugehörige Software mal irgendwann mit wenigen Mausklicks zu installieren und bedienen ist
Nunja, das geht bei mir seit Jahren. "portinstall firefox" läd Firefox runter und installiert es. "portupgrade firefox" updatet es auf die neuste Version. Fertig, das war es. Das gleiche mit apt-get/dpkg (Debian) oder emerge (Gentoo). Ich will wissen, welche Programme nicht aktuell sind: portversion -l \<. Oder welche Programme aktuell sind: portversion -l \=.
Auch Frontends für sowas existieren. Firefox in Liste auswählen, Doppelklick, fertig. Kein Suchen von Quellen zum Runterladen, kein Entpacken, keine Pfadangaben, kein verpassen von Updates, etc. Deinstallieren ist ebenso einfach mit einem Befehl möglich, ebenso wie das Ersetzen von Programmen durch andere. Man könnte auch angeben, daß alle Programe, die seit dem 01.12.2003 installiert wurden, geupdatet werden sollen.

Ein komplettes Update des kompletten Systems und aller Programme: portupgade -aR, fertig. Das alles fällt unter Punkt 4 in meinem obigen Text, der unter Windows nicht möglich ist. Einfacher geht es nicht. Viele User scheinen einfach mit dem Gedanken eines Paketmanagers nicht zurecht zu kommen, weil sie es von Windows her nicht kennen.

 

Das hat doch nichts mit den Dateigrößen zu tun. Diese ganze "Problematik" ist eigentlich gar keine. Ich habe auf meinem System z.B. kein einziges GTK-Programm installiert, sondern nur QT-Programme. Wenn ich jetzt ein einziges GTK-Programm installieren wollte, und auch wenn es nur 2KB groß ist, hätte ich als Abhängigkeit das GTK-Paket mit einigen 10 MB - aber das ist ja auch normal, es ist ja schließlich ein GTK-Programm, und das braucht nun mal GTK. Wäre es dir lieber wenn die Entwickler dieser vielen winzig kleinen GTK-Programme jedesmal GTK komplett mit reinpacken, so dass man jedesmal statt einigen KB gleich zig MB herunterladen muss?

Ich persönlich finde diese Abhängigkeits"problematik" unter Linux völlig belanglos, wenn ich mit Adept ein Programm installieren will, wird alles was dazu nötig ist automatisch heruntergeladen und installiert - also einfacher gehts ja wohl nicht. Das eigentliche Problem besteht eigentlich daran zu wissen welches Programm man für was installieren muss, die Installation selbst ist aber deutlich einfacher als unter Windows - sofern das Paket im Repository ist, was bei mir zur Zeit fast 19000 Stück sind - und das sollte reichen ;-)


Tom

 

Full ack! Ich behaupte einfach mal das die Installation von Programmen unter Linux in vielen Fällen sogar einfacher ist als unter Windows. Ich habe für eine Freundin Kubuntu installiert, sie hat wirklich keine Ahnung von PCs, ich habe ihr aber Adept gezeigt (der grafische Paketmanager von Kubuntu) und sie kommt wunderbar damit klar. Sie hat z.B. Impress gebraucht (das OpenOffice-Pendant zu PowerPoint). Die Installation ist kinderleicht: Adept starten, Passwort eingeben, "Impress" aus der Liste heraussuchen, auf "Installieren" klicken, ein paar Sekunden warten - fertig. Firefox geht genau so einfach: Firefox aus der Liste aussuchen, auf "Installieren" klicken, ein bißchen warten bis er es herunterlädt - fertig.

Dieses "Abhängigkeitsproblem" ist einfach eine Frage des Paketmanagers - bei einem guten Paketmanager (für mich Portage & apt-get, und somit sicher auch die BSD-Ports, wobei ich die leider nicht kenne) tritt es für den Endanwender nicht in Erscheinung, weil man sich einfach nicht drum kümmern muss. Wer auf RPM-basierte Distros setzt, ist in diesem Punkt selbst schuld.


Tom