für den Enduser, aber weitaus besser wäre es wenn man sich verdammtnochmal auf ein Binär-Paketsystem einigen könnte. Im moment sind ja nichtmal Pakete des gleichen Systems aber von verschiedenen Distributionen kompatibel (rpm: fc1,fc2,fc3,suse,mdk ...)
Da sich nun die Entwickler (völlig zurecht wie ich finde) nicht den Stress machen für jedes System ein eigenes Paket bereitzustellen schadet es im Endeffekt auch dem Endnutzer, da dieser lange darauf warten muss bis sich einer Developer der Distribution seiner Wahl die Mühe macht ein Paket zu erstellen.
Ich erwarte ja nicht, dass Debian jetzt auf rpm umsteigt aber um himmels Willen der jetzige Wirrwar ist einfach unzumutbar.
Die einzige Hoffnung die ich im Bezug auf SmartPM habe ist, dass mehr Entwickler das ihrer Meinung nach beste Paketsystem (und nicht das verbreitetste) benutzen und sich im Endeffekt dann eines herauskristallisiert. Aber das ist wohl noch ein langer Weg.
Frisches SUSE 9.2, autopackage für GAIM, was sagt er? Geht nicht, gtkspell fehlt. Toll... Apt sagt, es sollte Teil von GAIM sein, bei SUSE gibts das also nicht extra. Bei Autopackage ist es aber ein Extra Paket das erwartet wird.
Nette Idee, aber nicht sehr nützlich. Auch ist es bei SUSE 9.2 English, obwohl ich überall sonst Deutsch sehe. Und GTK, obwohl ich unter KDE bin (warum nutzt er nicht sein QT Interface).
AutoPackage ist ein guter Ansatz. Allerdings ist das Projekt noch extremst Alpha, hat mir mal wegen eines Bugs das halbe System geloescht, bis ich in Panik CTRL-C gedrueckt hatte...
Den Nutzer braucht es doch gar nicht zu interessieren, ob da jetzt ein .deb ein .rpm oder vieleicht sogar ein Gentoo-Ebuild dahinter steht. Ihn interessiert es nur, das er auf jedem System seine Pakete ähnlich verwalten kann. Genau da geht SmartPM den richtigen Weg, den der Unterstützung von sovielen Paketsystemen wie möglich.
Zum Theme Hersteller und Binärpakete: Durchgängige Binärkompatibilität wird es unter Linux nie geben! Letzendlich sind einige Distributionen trotzdem dabei dem nachzuhelfen (LSB2.0 Zertifizierungen etc.).
>Zum Theme Hersteller und Binärpakete: >Durchgängige Binärkompatibilität wird es unter Linux nie geben! > Letzendlich sind einige Distributionen trotzdem dabei dem >nachzuhelfen (LSB2.0 Zertifizierungen etc.). Ich denk mal, dass wenn mal alle Distris LSB 2.0 unterstützen werden, das Problem mit der Binärkompatiblität gegessen sein wird -> sogar n C++-ABI ist darin definiert! Aber bisher unterstützen wahrscheinlich die meisten aktuell installierten Systeme nicht mal LSB 1.x, von daher muss ja Abwärtskompatiblität gewahrt werden ;-). Danach steht einheitlichen Paketen kaum (ich denk da nur an die uneinheitlichen Konfigurationssysteme der verschiedenen Distris) mehr was im Weg. ...
Durchgängige Binärkompatibilität wird es unter Linux nie geben!
Durchgängige Binärkompatibilität ist unter GNU/Linux sehr wohl möglich. Das ELF-Binärformat funktioniert ohnehin auf jedem Linuxkernel, nur bei zahlreichen Bibliotheken können bei Major-Release-Upgrades Probleme durch inkompatible Schnittstellen entstehen. Ich kann mich noch an das glibc-Upgrade von 2.1 auf 2.2 erinnern, welches die halbe Distro über den Jordan zog, da etliche Funktionen anders verteilt wurden. Bei GTK+ 1.x und 2.x sind die Unterschiede ebenfalls sehr groß. Deshalb werden auf vielen Distributionen immer noch alte 1er-Glib und -Gtk neben der 2er-Serie mitgezogen, weil irgendein Uraltprogramm diese benötigt.
Ich könnte mir sogar vorstellen, dass die Lösung des Bibliothekenkonflikts langfristig Aufgabe des dynamischen Linkers "ld-linux.so" sein kann. Dann bekommt dieser quasi nur noch die Information "hier will jemand Gtk+ 3.x und Glib 3.x mit x > 42, bitte bedienen", und wie er die Bibliotheken findet sowie welche er heranzieht ist sein Problem.
Bei GTK hat man absichtlich einen Bruch zwischen GTK 1 und GTK 2 gemacht.
Dadurch konnte man den alten Ballast von GTK 1 rausschmeisen und das nützliche Zeug in GTK 2 sowie deren Zusatzbibliotheken einbauen.
Und zum Thema Binärkompatibilität solltet ihr mal dieses Kapitel lesen, das ist ne schöne Zusammenfassung und wenn man richtig vorgeht, dann kann man Programme ziemlich Distirbutionsunabhängig programmieren;
ich bin vor einiger Zeit von Windows auf Linux umgestiegen. Viele Dinge, finde ich, sind unter Linux besser gelöst als unter Windows. Was jedoch die Installation neuer Programme / Erweiterungen angeht kann Linux noch viel von Microsoft lernen. Vorausgesetzt die Software ist ordentlich entwickelt worden, kann man unter Windows mit einer Setup.exe jedes Programm absolut einfach und problemlos installieren.
Unter Linux hat man verschiedene Pakete für jeden Hersteller UND Versionsnummern. Außerdem kommt es noch häufig vor, das irgendwelche Abhängigkeiten nicht erfüllt sind. Ganz schlimm wird es wenn die Software nur im Source vorliegt. Auf meiner Standard SuSE 9.1 Installation hat noch nie das ./configure, make, install Trio problemlos funktioniert. Ich weiß, das Windows-Software im Source ebenfalls schwierig zu installieren sind. Aber unter Linux existieren wesentlich häufiger nur Sourcen zur Installation als unter Windows.
Ich möchte hier nicht die Vorzüge von Windows darstellen, schließlich bin ich wegen den vielen Nachteilen zu Linux gekommen. Aber anstatt nur immer Windows zu verteufeln (wie Microsoft immer Linux verteufelt) sollte man sich lieber mit den Vorteilen von Windows auseinander setzen und daraus lernen um somit Linux noch besser zu machen.
Ich weiß aus meinem Bekanntenkreis, dass gerade wegen den Installationsschwierigkeiten noch viele vor einem Umstieg nach Linux zurückschrecken.
Was den Komfort angeht kann man von Linux vielleicht etwas lernen, nicht jedoch, was die Mechanismen angeht. Bist Du Dir bewusst, was es für ein Aufwand ist, einen Installer zusammenzubasteln? Hast Du mal gezählt, wieviele verschiedene Installer unter Windows existieren (da ist Linux ja richtig einheitlich) und sind Dir auch schon mal MSI-Inkompatibilitäten begegnet? Dass jeder Benutzer mit Installationsroutinen in der Standardkonfiguration sein System zu Schrott fahren kann ist wohl auch alles andere als vorteilhaft. Der Komfort unter MS wird mit vielen Folgeproblemen erkauft und wenn schon komfortabel, dann lieber wie beim Mac.
Von Marcus Moeller am Mo, 3. Januar 2005 um 19:50 #
Das Problem unter Windows ist das viele Anwendungen statisch gelinkt sind. D.h. sie bringen ihre eigenen Librarys mit die fest in die Anwenung eingebunden sind. Dadurch werdenn die Anwendungen teils sehr gross, lassen sich aber leicht und ohne Abhängigkeiten installieren.
Alternativ werden unter Windows sog. DLLs (Dynamically Loaded Library) genutzt. Aber auch DLLs liegen in unterschiedlichen Versionsständen vor, was z.T. zu Inkompatibilitäten führt (bestes Beispiel ist die mapi.dll diverser Anwendungen [Outlook/Exchange/Tobit/diverse Mailer..)
Das Problem ist also nicht nur auf der freien Betriebssystemplattform Linux vorhanden. Allerdings entwickelt sich Linux erheblich schneller (und für den Anwender transparenter) als Windows was zu häufigen Änderungern in Toolkits o.ä. führt. Als Beispiel führe ich hier das kommende QT4 an, das nach meinem jetzigen Wissensstand keine Binärkompatibilität zu älteren Versionen bietet.
Hinzu kommt der Distributionszoo, der dafür sorgt das jede Linux Distro nur mit sich selbst kompatibel ist.
Ich persönlich nutze überwiegend Slackware und bin mit der "Einfachheit" der Paketinstallation (Entpacken von Tarballs) sehr zufrieden. Abhängigkeiten löse ich allerdings händisch auf ;)
... SuSE 9.1 Installation hat noch nie das ./configure, make, install Trio problemlos funktioniert. ...
Probiere doch einfach mal $ ./configure $ make $ make install (Betonung auf "make install")
Dass unter SuSE sowas Ärger macht kann schon mal vorkommen. Habe da (zu 7.2-Zeiten) ähnliche Erfahrungen gemacht. Unter Debian funzt configure-make-make install ausgesprochen gut. Hatte da nie Probleme. Man muss halt anfangs ein bissl lesen und an diversen (Pfad-)Schrauben drehen.
Die Tatsache, dass fast alle Programme als Source vorliegen finde ich übrigens genial - mal so ganz nebenbei - so kannste wichtige/wuchtige Programme (wie Mozilla) selber kompilieren und profitierst vom Geschwindigkeitsgewinn.
Das würde ich aber nicht empfehlen, da du damit den Paketmanager umschiffst. Jeder der configure;make;make install ausführen kann, kann auch dh_make; dpkg-buildpackage; ausführen und damit ein Debianpackage bauen das man dann mit dpkg -i paketname installieren kann.
Statt "make install" sollte man dann ein "checkinstall" ausfuehren. Damit kann man die installierten Dateien sehr leicht wieder deinstallieren. Ausserdem wird das Packet ggf. bei neueren, offiziell eintreffenden Versionen automatisch rausgeschmissen. checkinstall selber kann mit Hilfe von "apt-get install checkinstall" installiert werden.
Dass unter SuSE sowas Ärger macht kann schon mal vorkommen. Habe da (zu 7.2-Zeiten) ähnliche Erfahrungen gemacht. Unter Debian funzt configure-make-make install ausgesprochen gut. Hatte da nie Probleme. Man muss halt anfangs ein bissl lesen und an diversen (Pfad-)Schrauben drehen.
Trotz aller "Standardisierungen" durch die LSB (Linux Standard Base), welche den Filesystem Hierarchy Standard (FHS) nach eigener Aussage beinhaltet, gibt es immer noch erhebliche Unterschiede in der Verzeichnisstruktur zwischen den sog. nach LSB zertifizierten Distributionen. Das ist auch die simple Ursache dafür, dass die #include Pfade in den Makefiles häufig umgesetzt werden müssen, wenn man auf einer anderen Distribution aus einem Sourcepaket eine Anwendung kompilieren und linken möchte. Bekanntes Beispiel ist die Verwendung des /opt Verzeichnisses: Laut FHS ist dieser Pfad für Add-on Software reserviert. In diesem Zusammenhang ist mir schleierhaft wie die SuSE 9.x Distributionen nach LSB zertifiziert werden konnten, obwohl sie (als einzige mir bekannte Distribution) die Desktops GNOME und KDE (letzterer als sogar als Default) unter diesem Pfad installieren. Im Gegensatz dazu halten alle anderen mir bekannten Distributoren /opt frei für Software ("Add-on" Pakete halt), die nicht Bestandteil deren Standard-Distribution sind.
Bevor jetzt wieder ein SuSE-Jünger über mögliche alternative Definitionen von Add-on Software zu streiten anfängt: Es mag ja sein, dass die LSB bzw. FHS (wie generell die meisten "Gesetze") Schlupflöcher für solche Extravaganzen offenhalten (ist ja auch kein Wunder, da sich in den entsprechenden Gremien auch SuSE-Mitarbeiter befinden). Auf jeden Fall schaden solche völlig unnötigen Extravaganzen den oben beschriebenen Bestrebungen nach mehr Kompatibilität zwischen den verschiedenen Distributionen.
"Bevor jetzt wieder ein SuSE-Jünger über mögliche alternative Definitionen von Add-on Software zu streiten anfängt:"
Du solltest Kritik an deiner Meinung nicht gleich so abtun :)
Ich finde den SUSE Weg besser. Die Zerstreuung von tausenden Programmen auf die wenigen Unix Verzeichnisse finde ich zumn kotzen. Wenn ich selbst Software kompiliere, landen die auch immer ein geordneten Verzeichnissen. Nicht jedes mini Programm braucht eigene Ordner, aber doch zumindest große Gruppen sollten aufgetrennt sein, um Ordnung zu wahren.
Ich fände es ehrlich gesagt wesentlich besser, wenn die anderen Distries hier SUSEs Weg mitgehen würden, das wäre für die Ordnung in der Linuxwelt von wesentlichem Vorteil.
Magst du anders sehen, aber deswegen gibt es ja auch mehr als eine Distrie
Du solltest Kritik an deiner Meinung nicht gleich so abtun.
Wie ich oben ausgeführt habe, ist das nicht nur meine Meinung, sondern die Meinung aller Linux-Distributionen mit Ausnahme von SuSE. Konventionen/Abmachungen entspringen nun mal üblicherweise der Meinung einer Mehrheit...
Die Zerstreuung von tausenden Programmen auf die wenigen Unix Verzeichnisse finde ich zumn kotzen.
Ist irgendwie ein Widerspruch in sich selbst: Entweder sind die "tausend Programme" zerstreut, weil es so viele Verzeichnisse gibt, oder aber wenn es (wie Du sagst) so "wenige Unix-Verzeichnisse" gibt, liegen die Programme als Unterverzeichnisse (und damit nicht zerstreut) unterhalb eines bestimmten Pfades (z.B. /usr).
Nicht jedes mini Programm braucht eigene Ordner, aber doch zumindest große Gruppen sollten aufgetrennt sein, um Ordnung zu wahren.
Ob ich nun /opt/kde3 und daneben /opt/gnome oder /usr/lib/kde3 und daneben /usr/lib/gnome habe, ist von der Übersichtlichkeit her das Gleiche. Nur: Wenn man als Administrator gemäß des FHS eine Partition /opt anlegt für Add-on Software (z.B. kommerzielle Third-Party Software), erwartet man logischerweise von einer sog. FHS konformen Distribution nicht, dass sie ihre Desktop-Standardpakete (z.B. KDE bei SuSE) darin installiert.
Ich fände es ehrlich gesagt wesentlich besser, wenn die anderen Distries hier SUSEs Weg mitgehen würden, das wäre für die Ordnung in der Linuxwelt von wesentlichem Vorteil.
Genau umgekehrt: Wenn man sich den weltweiten Verbreitungsgrad der verschiedenen Distributionen anschaut, wäre es in diesem Zusammenhang sinnvoller (weil weniger aufwendig), wenn SuSE den Weg aller anderen Distributionen gehen würde. Oder bist Du etwa für einen lokalisierten (z.B. deutschen) Filesystem Hierarchy Standard ?
das problem ist bekannt und nachvollziehbar, hat aber gründe:
in der linux-szene wird diskontinuierlich entwickelt (meist zumindest), d.h. immer dann, wenn man mal zeit hat. dann werden oft neue dinge ausprobiert, die jedoch die kompatibilität zur alten version eines programms einschränken oder ganz aufgeben.
nun gibt es aber das problem der abhängigkeit - man stelle sich vor, in der bibliothek, die z.B. für das abspielen von mp3-dateien zuständig ist, wird irgendetwas fundamentales verändert: alle player, die diese bibliothek müssten dann ebenfalls ein update erhalten, damit sie weiterhin mit der bibliothek funktionieren. und dieser kreis zieht sich immer weiter und weiter. bei einigen paketen (libc) ist es bei einer neuen version nötig, fast das gesamte system neu aufzuspielen, da alle pakete darauf beruhen.
da es viele distributionen gibt und alle mit leicht verschiedenen konfigurationen ausgestattet sind (distri a benutzt paket version 1.1, distri b aber 1.2beta), ist auch keine distributionsübergreifende binärkompatibilität möglich.
die einzige möglichkeit wäre: "statische" programme, die quasi alles "mitbringen", was sie selbst brauchen - das ist aber unelegant, bläht die programme auf und macht die wartung des gesamtsystems schwierig.
warum geht es dann unter windows? weil es nur EIN windows gibt, EIN set aus systemdateien - aber auch unter windows wird es nicht möglich sein, ein altes win3.1-programm unter XP aufzuspielen. dafür gibt es unter windows so etwas wie die "dll-hölle", in die wohl schon jeder windowsuser hineingefallen ist... ;-)
vielleicht wäre es ganz gut, für "consumer-distributionen" eine art standardausrüstung zentraler bibliotheken zu haben, die von einem "gremium" bestimmt und turnusmäßig erneuert werden. distributionen, die in dem system mitmachen, dürfen dafür ein siegel verwenden. ein installationssystem wie autopackage schaut dann nach, ob es die benötigten pakete findet und bietet im zweifelsfall an, die mitgelieferten zu installieren oder die quellen der distribution zu benutzen - oder aber es bietet an, auf den nächsten "standard-level 2004 / 2005 / 200x" aufzurüsten. das ganze sollte natürlich so angelegt sein, dass erfahrene user trotzdem noch ihr neuen kde, gnome oder sonstwas installieren können, während alle anderen, die das system einfach nur BENUTZEN wollen, jedes halbe jahr mit neuen versionen bedacht werden (sicherheitsupdates natürlich ausgespart).
aber ich bin in sachen technik eher laie, deswegen will ich mich nicht weiter zu den vor- und nachteilen solcher theorien äußern... wenn man es wirklich will, dann wird man auch als halb-DAU irgendwann halbwegs versierter (debian)linux-nutzer...
> da es viele distributionen gibt und alle mit leicht verschiedenen konfigurationen ausgestattet sind > (distri a benutzt paket version 1.1, distri b aber 1.2beta), ist auch keine > distributionsübergreifende binärkompatibilität möglich.
Doch das ist möglich, es ist dazu nur aber etwas Sorgfalt bei demjenigen notwendig, der das Paket compiliert und zusammenschnürrt. Mit anderen Worten muß er das Programm für den kleinsten gemeinsammen Nenner compilieren, sprich auf Version 1.1 anstatt 1.2beta aufbauen.
Von romantic gorilla am Mo, 3. Januar 2005 um 22:25 #
> Aber unter Linux existieren wesentlich häufiger nur Sourcen zur Installation als unter Windows.
*rotfl* - ja und unter windows gibt es viele progs nur als binary. was ist dir lieber?
> sollte man sich lieber mit den Vorteilen von Windows auseinander setzen
ausser windows und linux scheinst du nix zu kennen. so kommst du direkt auf die idee, dass man ausgerechnet von windows etwas lernen könnte. dazu müsste man sich aber mit windows beschäftigen, und das kannst du wohl niemandem ernsthaft zumuten. ganz abgesehen davon, dass es unmoralisch ist, windows zu benutzen.
Von carsten michels am Mo, 3. Januar 2005 um 23:15 #
Da hat jemand geschrieben das statiche Programme das System aufblähen und ein Warten des Systems erschweren.
Das stimmt ja wohl so nicht ganz. Ich als Linux Anfänger hab alle Suse CDs instaliert weil ich nicht genau weiß was ich brauch.
Und an einem Beipiel zb DVDRip das bis heute nicht geht zu erläutern. Es kann doch nicht sein das man mehere 10-15 Pakete instalieren muss bis ein Programm mit wenigen Funktion läuft. Unter Windows ist etwas verlgeichbares 2-3 MB groß.... und bei Linux mit all den Paketen....40-50 mb?
Da instalier ich lieber ein PRogramm was vieleicht ein paar MB größer ist aber dafür perfekt Funktioniert ohne Abhänigkeiten.
Und Installer gibt es auch gute. Zb den von dem Apollo Filesharing Programm oder das Autpoackgae von Gaim. Das hat bei mir Suse 9.2 wunderbar Funktioniert. Das kann noch mit allen Programmen Funktionieren....
ich bin nicht 100%ig firm in solchen fragen (wie gesagt - ich bin interessierter user), allerdings ist das von dir gebrauchte beispiel nicht ganz realistisch. schon eher der vergleich vom "statischen mozilla" (von mozilla.org) und einem distributionsspezifischen paket (das meist einige mb kleiner ist).
du erwähnst dvdrip - aber dvdrip ist kein programm, welches unter windows 3mb groß ist. rechne die codecs dazu (die bei windows dabei sind - oder dann eben fehlen) und rechne ferner hinzu, dass suse (afaik) kein deCSS mitliefern darf, was dann umständlich von hand installiert werden muss...
außerdem könnte dein problem ein effekt der "ausdehnung von abhängigkeiten" sein - a braucht b und b braucht c ad infinitum. manchmal gehen distributionen SEHR großzügig mit abhängigkeiten um: dann brauchen pakete andere pakete, obwohl sie nicht zwingend notwendig wären.
eine andere sache ist dann noch das linux(distributions)-entwicklungsmodell: ein großer "haufen" verschieden schnell entwickelter, einzelner bauteile, die sich (auch sehr nah am "system") permanent verändern und oft zu alten versionen nicht mehr kompatibel sind. wenn man unter windows permanent den "neuesten stand" der GUI-entwicklung haben könnte (z.B. jetzt den aktuellen entwicklungsstand des longhorn-gui), dann sähe das problem genauso aus... und dann wäre es auch nicht so einfach, ein programm zu installieren, da programme wiederum das longhorn-gui benutzen.
und wenn ALLE programme ihre bibliotheken mitbringen, wie soll man dann das ganze system in einem rutsch updaten (inkl. anwendungssoftware)? wie würde ein system aussehen, in dem jedes programm sein eigenes toolkit, seine eigenen codecs, etc. mitbringen würde? ist es nicht passender (und unix-like), immer ein tool zu haben, welches eine begrenzte funktionalität dafür umso perfekter erledigt?
auch als nicht-techniker bin ich davon überzeugt, dass der linux(distributions)-way die technisch "bessere" lösung ist, um ein system dauerhaft in einem konsistenten zustand zu lassen, während bei mir bisher jedes windows-system nach ein, zwei jahren dauernutzung (inkl. installieren, deinstallieren, patches aufspielen) immer langsamer wurde.
Von Manfred Tremmel am Di, 4. Januar 2005 um 12:31 #
Stell Dir vor, es tritt eine Sicherheitslücke in ssh auf. Wenn Programme dynamisch gelinkt wurden, reicht es ein Update des ssh Pakets einzuspielen und alle Programme profitieren davon. Wären aber Programme statisch gegen die libsssh gelinkt, müsste jedes Programm aktualisiert werden. Das mag bei Programmen, die mitgeliefert werden mit automatischen Updateprogrammen (wie z.B. YOU bei SuSE) gehen, kostet aber dort schon massiv Bandbreite. Bei externen Programmen verliert man aber schnell den Überblick.
Zu DVDRip, binde Packman als Installationsquelle in YaST ein und lass diesen sich um die Abhängigkeiten kümmern. Die Datenmenge kommt wohl deshalb zusammen, weil DVDRip viele externe Programme nutzt, aber eben jeweils nur einen teil der Funktionen, teilweise auch alternativ. Das ergibt halt.
Mein Gott, was hat Dich denn gestochen, daß Du gleich so rumkeifst. Er HAT nett gefragt und ich empfand ihn alles andere als trollig. Du pflaumst nur rum.
Also ich sehe im Moment nur ein System was idR die Installation wirklich benutzerfreundlich gestaltet: MacOSX!! Dort starte ich eine dmg-Datei, (es ist ein komprimiertes Image-File), dieses Image wird dann gemountet (wie ein USB-Stick zum Beispiel). Dann habe ich dort ein Icon (zb das FireFox-Icon). Dieses ziehe ich dann in den Programme Ordner. FERTIG!! Das wars! Nix Setup, nix rpm, nix Abhängigkeiten falsch auflösen. Es gibt einige wenige Programme, die eine Install-Routine (ähnlich Windows) mitbringen. Diese ist dann jedoch auch komfortabel gelöst und das Programm einfach zu installieren. Ich finde, dass hier der "Power of Unix" (wie es so schön heißt), Configurationsdateien für Benutzer nur im Benutzer-Home etc. und die Einfachheit der Bedienung wirklich nahe an der Perfektion ist. Hier kann Windows und auch Linux noch viel Lernen. Nicht dass wir uns falsch verstehn, ich baue selbst rpms (im konkreten Fall für Mandrake), bin also durch aus vom Fach. Aber hier ist Apple einfach den anderen Systemen weit voraus. Zum Thema Windows vs. Linux Installationen: Wenn man bei Linux mal stecken bleibt (Installation klappt nicht wegen Abhängigkeiten), dann kann man sich mit etwas Grundwissen (auf der Kommandozeile Installation testen, Fehlerausgaben auswerten evtl. auch mal Googlen) die Abhängigkeiten lösen und das Ding dann doch installiert bekommen. Unter Windows (wo Installationen auch des öfteren schief gehen :: ich rede nicht von einem komplett neu aufgestetzen System, sondern von einem System was schon ein Jahr mit ettlichen Installationen und Deinstallationen läuft....) ist das ein Ding der Unmöglichkeit. Ich erinnere da nur an die Adobe Installationsroutinen: Fehlermeldung: Das Programm kann nicht installiert werden. (das wars auch schon, keine weitere Auskunft weshalb oder warum).
Ah, mal wieder ein Windowser, der meint, Linux und Windows müssten/sollten genauso funktionieren, nur beide Betriebsysteme sind. Ist genau wie bei Autos und Motorrädern. Beides Fahrzeuge, aber sonst alles anders.
Wieso sollte LINUX von WINDOWS etwas lernen? gerade umgekehrt. Die installationsrutienen von M$ Windows mögen zwar einfach sein, aber GUT sind sie noch lange nicht.
> Auf meiner Standard SuSE 9.1 Installation hat noch nie das ./configure, make, install Trio problemlos funktioniert. Kann ja auch nicht. Es heiß ja nicht ./configure, make, install sondern ./configure, make, make install ! Ich habe im Drchschnitt höchtens bei 2-3 von 100 Programme Probleme, sie zu installieren, wenn ich die README und INSTALL Dateien lese.
Wenn du erstnal eine Zeit mit Linux so Programme instaliert hast, ist das für dich das einfachste de Welt.
Ich benutzte zu Hause und auf Servern nur Linux und wenn ich mal wieder bei Verwandten zu Windows komme, ärgere ich mich immer über die Setup assistenten von Win. Weißt du, Warum: Weil sie mich mit Lizenzen nervern und mich bevormunden wollen. Mit Linux-Programmen kannst du alles genau so haben, wie du es willst. Die Kenntnisse vorrausgesetzt.
> Ich weiß aus meinem Bekanntenkreis, dass gerade wegen den Installationsschwierigkeiten noch viele vor einem Umstieg nach Linux zurückschrecken.
Na und, auch wenn es schwierig ist, lernen kann man es trotztdem. Im Internet. Und danach ist es einfacher als "Installation" zu sagen.
Habe SmartPM unter FC3 vom DAG-Repositorium ausprobiert. Sehr fein sind die Einbindungsmöglichkeiten aller möglicher Quellen (oder wie nennt man das?): yum, apt, rpm-db u.v.a. Dazu kann man nun sämtliche Quellen auch mit Prioritäten belegen (ging bisher nur unter apt).
Alles fein bis dahin, nur: leider blieb das Ding beim ersten Installations-Probelauf nach dem ersten installierten Paket einfach hängen und ist eingefroren. Der Prozess ließ sich nicht killen, auch ein Neustart von X hat nichts geholfen --> reboot. Ob das daran liegt, dass es unter Python läuft?
Naja, bleibe ich einstweilen bei apt und probiere es unter FC4 wieder aus. Tendenziell ist das Ding ja super, wie gesagt.
Da sich nun die Entwickler (völlig zurecht wie ich finde) nicht den Stress machen für jedes System ein eigenes Paket bereitzustellen schadet es im Endeffekt auch dem Endnutzer, da dieser lange darauf warten muss bis sich einer Developer der Distribution seiner Wahl die Mühe macht ein Paket zu erstellen.
Ich erwarte ja nicht, dass Debian jetzt auf rpm umsteigt aber um himmels Willen der jetzige Wirrwar ist einfach unzumutbar.
Die einzige Hoffnung die ich im Bezug auf SmartPM habe ist, dass mehr Entwickler das ihrer Meinung nach beste Paketsystem (und nicht das verbreitetste) benutzen und sich im Endeffekt dann eines herauskristallisiert. Aber das ist wohl noch ein langer Weg.
mfg, Tim
Könnte das Zukunft haben?
Frisches SUSE 9.2, autopackage für GAIM, was sagt er? Geht nicht, gtkspell fehlt. Toll... Apt sagt, es sollte Teil von GAIM sein, bei SUSE gibts das also nicht extra. Bei Autopackage ist es aber ein Extra Paket das erwartet wird.
Nette Idee, aber nicht sehr nützlich. Auch ist es bei SUSE 9.2 English, obwohl ich überall sonst Deutsch sehe. Und GTK, obwohl ich unter KDE bin (warum nutzt er nicht sein QT Interface).
Schöne Idee, aber maue Umsetzung. Echt schade.
Zum Theme Hersteller und Binärpakete:
Durchgängige Binärkompatibilität wird es unter Linux nie geben! Letzendlich sind einige Distributionen trotzdem dabei dem nachzuhelfen (LSB2.0 Zertifizierungen etc.).
>Durchgängige Binärkompatibilität wird es unter Linux nie geben!
> Letzendlich sind einige Distributionen trotzdem dabei dem
>nachzuhelfen (LSB2.0 Zertifizierungen etc.).
Ich denk mal, dass wenn mal alle Distris LSB 2.0 unterstützen werden, das Problem mit der Binärkompatiblität gegessen sein wird -> sogar n C++-ABI ist darin definiert! Aber bisher unterstützen wahrscheinlich die meisten aktuell installierten Systeme nicht mal LSB 1.x, von daher muss ja Abwärtskompatiblität gewahrt werden ;-).
Danach steht einheitlichen Paketen kaum (ich denk da nur an die uneinheitlichen Konfigurationssysteme der verschiedenen Distris) mehr was im Weg. ...
Durchgängige Binärkompatibilität ist unter GNU/Linux sehr wohl möglich. Das ELF-Binärformat funktioniert ohnehin auf jedem Linuxkernel, nur bei zahlreichen Bibliotheken können bei Major-Release-Upgrades Probleme durch inkompatible Schnittstellen entstehen. Ich kann mich noch an das glibc-Upgrade von 2.1 auf 2.2 erinnern, welches die halbe Distro über den Jordan zog, da etliche Funktionen anders verteilt wurden. Bei GTK+ 1.x und 2.x sind die Unterschiede ebenfalls sehr groß. Deshalb werden auf vielen Distributionen immer noch alte 1er-Glib und -Gtk neben der 2er-Serie mitgezogen, weil irgendein Uraltprogramm diese benötigt.
Ich könnte mir sogar vorstellen, dass die Lösung des Bibliothekenkonflikts langfristig Aufgabe des dynamischen Linkers "ld-linux.so" sein kann. Dann bekommt dieser quasi nur noch die Information "hier will jemand Gtk+ 3.x und Glib 3.x mit x > 42, bitte bedienen", und wie er die Bibliotheken findet sowie welche er heranzieht ist sein Problem.
/.
DocSnyder.
Dadurch konnte man den alten Ballast von GTK 1 rausschmeisen und das nützliche Zeug in GTK 2 sowie deren Zusatzbibliotheken einbauen.
Und zum Thema Binärkompatibilität solltet ihr mal dieses Kapitel lesen,
das ist ne schöne Zusammenfassung und wenn man richtig vorgeht, dann kann
man Programme ziemlich Distirbutionsunabhängig programmieren;
http://autopackage.org/docs/devguide/ch07.html
Hat das Projekt eine Chance in nächster Zeit apt4rpm abzulösen oder in dem Umfang eingesetzt zu werden?
ich bin vor einiger Zeit von Windows auf Linux umgestiegen. Viele Dinge, finde ich, sind unter Linux besser gelöst als unter Windows. Was jedoch die Installation neuer Programme / Erweiterungen angeht kann Linux noch viel von Microsoft lernen. Vorausgesetzt die Software ist ordentlich entwickelt worden, kann man unter Windows mit einer Setup.exe jedes Programm absolut einfach und problemlos installieren.
Unter Linux hat man verschiedene Pakete für jeden Hersteller UND Versionsnummern. Außerdem kommt es noch häufig vor, das irgendwelche Abhängigkeiten nicht erfüllt sind. Ganz schlimm wird es wenn die Software nur im Source vorliegt. Auf meiner Standard SuSE 9.1 Installation hat noch nie das ./configure, make, install Trio problemlos funktioniert. Ich weiß, das Windows-Software im Source ebenfalls schwierig zu installieren sind. Aber unter Linux existieren wesentlich häufiger nur Sourcen zur Installation als unter Windows.
Ich möchte hier nicht die Vorzüge von Windows darstellen, schließlich bin ich wegen den vielen Nachteilen zu Linux gekommen. Aber anstatt nur immer Windows zu verteufeln (wie Microsoft immer Linux verteufelt) sollte man sich lieber mit den Vorteilen von Windows auseinander setzen und daraus lernen um somit Linux noch besser zu machen.
Ich weiß aus meinem Bekanntenkreis, dass gerade wegen den Installationsschwierigkeiten noch viele vor einem Umstieg nach Linux zurückschrecken.
Alternativ werden unter Windows sog. DLLs (Dynamically Loaded Library) genutzt. Aber auch DLLs liegen in unterschiedlichen Versionsständen vor, was z.T. zu Inkompatibilitäten führt (bestes Beispiel ist die mapi.dll diverser Anwendungen [Outlook/Exchange/Tobit/diverse Mailer..)
Das Problem ist also nicht nur auf der freien Betriebssystemplattform Linux vorhanden. Allerdings entwickelt sich Linux erheblich schneller (und für den Anwender transparenter) als Windows was zu häufigen Änderungern in Toolkits o.ä. führt. Als Beispiel führe ich hier das kommende QT4 an, das nach meinem jetzigen Wissensstand keine Binärkompatibilität zu älteren Versionen bietet.
Hinzu kommt der Distributionszoo, der dafür sorgt das jede Linux Distro nur mit sich selbst kompatibel ist.
Ich persönlich nutze überwiegend Slackware und bin mit der "Einfachheit" der Paketinstallation (Entpacken von Tarballs) sehr zufrieden. Abhängigkeiten löse ich allerdings händisch auf ;)
MfG
Marcus
SuSE 9.1 Installation hat noch nie das ./configure, make, install Trio problemlos funktioniert.
...
Probiere doch einfach mal
$ ./configure
$ make
$ make install
(Betonung auf "make install")
Dass unter SuSE sowas Ärger macht kann schon mal vorkommen.
Habe da (zu 7.2-Zeiten) ähnliche Erfahrungen gemacht. Unter Debian funzt configure-make-make install ausgesprochen gut. Hatte da nie Probleme. Man muss halt anfangs ein bissl lesen und an diversen (Pfad-)Schrauben drehen.
Die Tatsache, dass fast alle Programme als Source vorliegen finde ich übrigens genial - mal so ganz nebenbei - so kannste wichtige/wuchtige Programme (wie Mozilla) selber kompilieren und profitierst vom Geschwindigkeitsgewinn.
Grüße,
chakaroth
Das würde ich aber nicht empfehlen, da du damit den Paketmanager umschiffst. Jeder der configure;make;make install ausführen kann, kann auch dh_make; dpkg-buildpackage; ausführen und damit ein Debianpackage bauen das man dann mit dpkg -i paketname installieren kann.
Mind
Dass unter SuSE sowas Ärger macht kann schon mal vorkommen. Habe da (zu 7.2-Zeiten) ähnliche Erfahrungen gemacht. Unter Debian funzt configure-make-make install ausgesprochen gut. Hatte da nie Probleme. Man muss halt anfangs ein bissl lesen und an diversen (Pfad-)Schrauben drehen.
Trotz aller "Standardisierungen" durch die LSB (Linux Standard Base), welche den Filesystem Hierarchy Standard (FHS) nach eigener Aussage beinhaltet, gibt es immer noch erhebliche Unterschiede in der Verzeichnisstruktur zwischen den sog. nach LSB zertifizierten Distributionen. Das ist auch die simple Ursache dafür, dass die #include Pfade in den Makefiles häufig umgesetzt werden müssen, wenn man auf einer anderen Distribution aus einem Sourcepaket eine Anwendung kompilieren und linken möchte.
Bekanntes Beispiel ist die Verwendung des /opt Verzeichnisses:
Laut FHS ist dieser Pfad für Add-on Software reserviert. In diesem Zusammenhang ist mir schleierhaft wie die SuSE 9.x Distributionen nach LSB zertifiziert werden konnten, obwohl sie (als einzige mir bekannte Distribution) die Desktops GNOME und KDE (letzterer als sogar als Default) unter diesem Pfad installieren. Im Gegensatz dazu halten alle anderen mir bekannten Distributoren /opt frei für Software ("Add-on" Pakete halt), die nicht Bestandteil deren Standard-Distribution sind.
Bevor jetzt wieder ein SuSE-Jünger über mögliche alternative Definitionen von Add-on Software zu streiten anfängt: Es mag ja sein, dass die LSB bzw. FHS (wie generell die meisten "Gesetze") Schlupflöcher für solche Extravaganzen offenhalten (ist ja auch kein Wunder, da sich in den entsprechenden Gremien auch SuSE-Mitarbeiter befinden). Auf jeden Fall schaden solche völlig unnötigen Extravaganzen den oben beschriebenen Bestrebungen nach mehr Kompatibilität zwischen den verschiedenen Distributionen.
Günther
Du solltest Kritik an deiner Meinung nicht gleich so abtun :)
Ich finde den SUSE Weg besser. Die Zerstreuung von tausenden Programmen auf die wenigen Unix Verzeichnisse finde ich zumn kotzen. Wenn ich selbst Software kompiliere, landen die auch immer ein geordneten Verzeichnissen.
Nicht jedes mini Programm braucht eigene Ordner, aber doch zumindest große Gruppen sollten aufgetrennt sein, um Ordnung zu wahren.
Ich fände es ehrlich gesagt wesentlich besser, wenn die anderen Distries hier SUSEs Weg mitgehen würden, das wäre für die Ordnung in der Linuxwelt von wesentlichem Vorteil.
Magst du anders sehen, aber deswegen gibt es ja auch mehr als eine Distrie
Du solltest Kritik an deiner Meinung nicht gleich so abtun.
Wie ich oben ausgeführt habe, ist das nicht nur meine Meinung, sondern die Meinung aller Linux-Distributionen mit Ausnahme von SuSE.
Konventionen/Abmachungen entspringen nun mal üblicherweise der Meinung einer Mehrheit...
Die Zerstreuung von tausenden Programmen auf die wenigen Unix Verzeichnisse finde ich zumn kotzen.
Ist irgendwie ein Widerspruch in sich selbst: Entweder sind die "tausend Programme" zerstreut, weil es so viele Verzeichnisse gibt, oder aber wenn es (wie Du sagst) so "wenige Unix-Verzeichnisse" gibt, liegen die Programme als Unterverzeichnisse (und damit nicht zerstreut) unterhalb eines bestimmten Pfades (z.B. /usr).
Nicht jedes mini Programm braucht eigene Ordner, aber doch zumindest große Gruppen sollten aufgetrennt sein, um Ordnung zu wahren.
Ob ich nun /opt/kde3 und daneben /opt/gnome oder /usr/lib/kde3 und daneben /usr/lib/gnome habe, ist von der Übersichtlichkeit her das Gleiche.
Nur: Wenn man als Administrator gemäß des FHS eine Partition /opt anlegt für Add-on Software (z.B. kommerzielle Third-Party Software), erwartet man logischerweise von einer sog. FHS konformen Distribution nicht, dass sie ihre Desktop-Standardpakete (z.B. KDE bei SuSE) darin installiert.
Ich fände es ehrlich gesagt wesentlich besser, wenn die anderen Distries hier SUSEs Weg mitgehen würden, das wäre für die Ordnung in der Linuxwelt von wesentlichem Vorteil.
Genau umgekehrt: Wenn man sich den weltweiten Verbreitungsgrad der verschiedenen Distributionen anschaut, wäre es in diesem Zusammenhang sinnvoller (weil weniger aufwendig), wenn SuSE den Weg aller anderen Distributionen gehen würde.
Oder bist Du etwa für einen lokalisierten (z.B. deutschen) Filesystem Hierarchy Standard
Gruß
Günther
in der linux-szene wird diskontinuierlich entwickelt (meist zumindest), d.h. immer dann, wenn man mal zeit hat. dann werden oft neue dinge ausprobiert, die jedoch die kompatibilität zur alten version eines programms einschränken oder ganz aufgeben.
nun gibt es aber das problem der abhängigkeit - man stelle sich vor, in der bibliothek, die z.B. für das abspielen von mp3-dateien zuständig ist, wird irgendetwas fundamentales verändert: alle player, die diese bibliothek müssten dann ebenfalls ein update erhalten, damit sie weiterhin mit der bibliothek funktionieren. und dieser kreis zieht sich immer weiter und weiter. bei einigen paketen (libc) ist es bei einer neuen version nötig, fast das gesamte system neu aufzuspielen, da alle pakete darauf beruhen.
da es viele distributionen gibt und alle mit leicht verschiedenen konfigurationen ausgestattet sind (distri a benutzt paket version 1.1, distri b aber 1.2beta), ist auch keine distributionsübergreifende binärkompatibilität möglich.
die einzige möglichkeit wäre: "statische" programme, die quasi alles "mitbringen", was sie selbst brauchen - das ist aber unelegant, bläht die programme auf und macht die wartung des gesamtsystems schwierig.
warum geht es dann unter windows? weil es nur EIN windows gibt, EIN set aus systemdateien - aber auch unter windows wird es nicht möglich sein, ein altes win3.1-programm unter XP aufzuspielen. dafür gibt es unter windows so etwas wie die "dll-hölle", in die wohl schon jeder windowsuser hineingefallen ist... ;-)
vielleicht wäre es ganz gut, für "consumer-distributionen" eine art standardausrüstung zentraler bibliotheken zu haben, die von einem "gremium" bestimmt und turnusmäßig erneuert werden. distributionen, die in dem system mitmachen, dürfen dafür ein siegel verwenden. ein installationssystem wie autopackage schaut dann nach, ob es die benötigten pakete findet und bietet im zweifelsfall an, die mitgelieferten zu installieren oder die quellen der distribution zu benutzen - oder aber es bietet an, auf den nächsten "standard-level 2004 / 2005 / 200x" aufzurüsten. das ganze sollte natürlich so angelegt sein, dass erfahrene user trotzdem noch ihr neuen kde, gnome oder sonstwas installieren können, während alle anderen, die das system einfach nur BENUTZEN wollen, jedes halbe jahr mit neuen versionen bedacht werden (sicherheitsupdates natürlich ausgespart).
aber ich bin in sachen technik eher laie, deswegen will ich mich nicht weiter zu den vor- und nachteilen solcher theorien äußern... wenn man es wirklich will, dann wird man auch als halb-DAU irgendwann halbwegs versierter (debian)linux-nutzer...
> (distri a benutzt paket version 1.1, distri b aber 1.2beta), ist auch keine
> distributionsübergreifende binärkompatibilität möglich.
Doch das ist möglich, es ist dazu nur aber etwas Sorgfalt bei demjenigen notwendig, der das
Paket compiliert und zusammenschnürrt.
Mit anderen Worten muß er das Programm für den kleinsten gemeinsammen Nenner compilieren,
sprich auf Version 1.1 anstatt 1.2beta aufbauen.
Siehe hier:
http://autopackage.org/docs/devguide/ch07.html
*rotfl* - ja und unter windows gibt es viele progs nur als binary. was ist dir lieber?
> sollte man sich lieber mit den Vorteilen von Windows auseinander setzen
ausser windows und linux scheinst du nix zu kennen. so kommst du direkt auf die idee, dass man ausgerechnet von windows etwas lernen könnte. dazu müsste man sich aber mit windows beschäftigen, und das kannst du wohl niemandem ernsthaft zumuten. ganz abgesehen davon, dass es unmoralisch ist, windows zu benutzen.
Das stimmt ja wohl so nicht ganz. Ich als Linux Anfänger hab alle Suse CDs instaliert weil ich nicht genau weiß was ich brauch.
Und an einem Beipiel zb DVDRip das bis heute nicht geht zu erläutern. Es kann doch nicht sein das man mehere 10-15 Pakete instalieren muss bis ein Programm mit wenigen Funktion läuft. Unter Windows ist etwas verlgeichbares 2-3 MB groß.... und bei Linux mit all den Paketen....40-50 mb?
Da instalier ich lieber ein PRogramm was vieleicht ein paar MB größer ist aber dafür perfekt Funktioniert ohne Abhänigkeiten.
Und Installer gibt es auch gute. Zb den von dem Apollo Filesharing Programm oder das Autpoackgae von Gaim. Das hat bei mir Suse 9.2 wunderbar Funktioniert. Das kann noch mit allen Programmen Funktionieren....
du erwähnst dvdrip - aber dvdrip ist kein programm, welches unter windows 3mb groß ist. rechne die codecs dazu (die bei windows dabei sind - oder dann eben fehlen) und rechne ferner hinzu, dass suse (afaik) kein deCSS mitliefern darf, was dann umständlich von hand installiert werden muss...
außerdem könnte dein problem ein effekt der "ausdehnung von abhängigkeiten" sein - a braucht b und b braucht c ad infinitum. manchmal gehen distributionen SEHR großzügig mit abhängigkeiten um: dann brauchen pakete andere pakete, obwohl sie nicht zwingend notwendig wären.
eine andere sache ist dann noch das linux(distributions)-entwicklungsmodell: ein großer "haufen" verschieden schnell entwickelter, einzelner bauteile, die sich (auch sehr nah am "system") permanent verändern und oft zu alten versionen nicht mehr kompatibel sind. wenn man unter windows permanent den "neuesten stand" der GUI-entwicklung haben könnte (z.B. jetzt den aktuellen entwicklungsstand des longhorn-gui), dann sähe das problem genauso aus... und dann wäre es auch nicht so einfach, ein programm zu installieren, da programme wiederum das longhorn-gui benutzen.
und wenn ALLE programme ihre bibliotheken mitbringen, wie soll man dann das ganze system in einem rutsch updaten (inkl. anwendungssoftware)? wie würde ein system aussehen, in dem jedes programm sein eigenes toolkit, seine eigenen codecs, etc. mitbringen würde? ist es nicht passender (und unix-like), immer ein tool zu haben, welches eine begrenzte funktionalität dafür umso perfekter erledigt?
auch als nicht-techniker bin ich davon überzeugt, dass der linux(distributions)-way die technisch "bessere" lösung ist, um ein system dauerhaft in einem konsistenten zustand zu lassen, während bei mir bisher jedes windows-system nach ein, zwei jahren dauernutzung (inkl. installieren, deinstallieren, patches aufspielen) immer langsamer wurde.
Zu DVDRip, binde Packman als Installationsquelle in YaST ein und lass diesen sich um die Abhängigkeiten kümmern. Die Datenmenge kommt wohl deshalb zusammen, weil DVDRip viele externe Programme nutzt, aber eben jeweils nur einen teil der Funktionen, teilweise auch alternativ. Das ergibt halt.
Er HAT nett gefragt und ich empfand ihn alles andere als trollig. Du pflaumst nur rum.
MacOSX!! Dort starte ich eine dmg-Datei, (es ist ein komprimiertes Image-File), dieses Image wird dann gemountet (wie ein USB-Stick zum Beispiel). Dann habe ich dort ein Icon (zb das FireFox-Icon). Dieses ziehe ich dann in den Programme Ordner. FERTIG!! Das wars! Nix Setup, nix rpm, nix Abhängigkeiten falsch auflösen. Es gibt einige wenige Programme, die eine Install-Routine (ähnlich Windows) mitbringen. Diese ist dann jedoch auch komfortabel gelöst und das Programm einfach zu installieren. Ich finde, dass hier der "Power of Unix" (wie es so schön heißt), Configurationsdateien für Benutzer nur im Benutzer-Home etc. und die Einfachheit der Bedienung wirklich nahe an der Perfektion ist. Hier kann Windows und auch Linux noch viel Lernen.
Nicht dass wir uns falsch verstehn, ich baue selbst rpms (im konkreten Fall für Mandrake), bin also durch aus vom Fach. Aber hier ist Apple einfach den anderen Systemen weit voraus.
Zum Thema Windows vs. Linux Installationen: Wenn man bei Linux mal stecken bleibt (Installation klappt nicht wegen Abhängigkeiten), dann kann man sich mit etwas Grundwissen (auf der Kommandozeile Installation testen, Fehlerausgaben auswerten evtl. auch mal Googlen) die Abhängigkeiten lösen und das Ding dann doch installiert bekommen. Unter Windows (wo Installationen auch des öfteren schief gehen :: ich rede nicht von einem komplett neu aufgestetzen System, sondern von einem System was schon ein Jahr mit ettlichen Installationen und Deinstallationen läuft....) ist das ein Ding der Unmöglichkeit. Ich erinnere da nur an die Adobe Installationsroutinen: Fehlermeldung: Das Programm kann nicht installiert werden. (das wars auch schon, keine weitere Auskunft weshalb oder warum).
Viele Grüße Tanja
denn diese Installationsmethode hat auch gravierende Nachteile.
Das kannst du bei dieser FAQ unter dem Abschnitt
"What's wrong with NeXT/MacOSX style appfolders?"
nachlesen:
http://autopackage.org/faq.html
Mit anderen Worten, diese Installationsmethode ist zwar einfach,
aber sie ist deswegen noch lange nicht gut.
Wieso sollte LINUX von WINDOWS etwas lernen? gerade umgekehrt.
Die installationsrutienen von M$ Windows mögen zwar einfach sein, aber GUT sind sie noch lange nicht.
> Auf meiner Standard SuSE 9.1 Installation hat noch nie das ./configure, make, install Trio problemlos funktioniert.
Kann ja auch nicht. Es heiß ja nicht ./configure, make, install sondern ./configure, make, make install !
Ich habe im Drchschnitt höchtens bei 2-3 von 100 Programme Probleme, sie zu installieren, wenn ich die README und INSTALL Dateien lese.
Wenn du erstnal eine Zeit mit Linux so Programme instaliert hast, ist das für dich das einfachste de Welt.
Ich benutzte zu Hause und auf Servern nur Linux und wenn ich mal wieder bei Verwandten zu Windows komme, ärgere ich mich immer über die Setup assistenten von Win. Weißt du, Warum:
Weil sie mich mit Lizenzen nervern und mich bevormunden wollen. Mit Linux-Programmen kannst du alles genau so haben, wie du es willst. Die Kenntnisse vorrausgesetzt.
> Ich weiß aus meinem Bekanntenkreis, dass gerade wegen den Installationsschwierigkeiten noch viele vor einem Umstieg nach Linux zurückschrecken.
Na und, auch wenn es schwierig ist, lernen kann man es trotztdem. Im Internet. Und danach ist es einfacher als "Installation" zu sagen.
Alles fein bis dahin, nur: leider blieb das Ding beim ersten Installations-Probelauf nach dem ersten installierten Paket einfach hängen und ist eingefroren. Der Prozess ließ sich nicht killen, auch ein Neustart von X hat nichts geholfen --> reboot. Ob das daran liegt, dass es unter Python läuft?
Naja, bleibe ich einstweilen bei apt und probiere es unter FC4 wieder aus. Tendenziell ist das Ding ja super, wie gesagt.
Hubertus