Von hanspeterwurst am Mo, 26. November 2012 um 21:38 #
Schonmal Software aus Sourcen installiert? Ich denke die Antwort ist nein.
Das Problem ist folgendes: wenn du Software direkt von den Sourcen installierst, machst du typischerweise folgendes:
./configure make sudo make install
oder wenn nicht mal autoconf dabei ist:
make
Warum ist das schlecht? Du installierst gerade 1.0rc1 und merkst auf einmal die Version ist Muell oder zu instabil. Stattdessen laedst du jetzt 0.9.18 runter und bist gluecklich. Naja, fast... Im Zweifelsfall konntest du die Reste des alten Paketes nicht rueckstandsfrei beseitigen.
Zwar liefern manche Pakete sowas wie ein make uninstall mit, aber das funktioniert ungefaehr so gut wie ein Uninstaller von Windows 95. Eine Abhilfe ist sowas:
./configure --prefix=$HOME/abc-0.9
...oder man verwendet sowas wie stow oder xstow. Das garantiert spurenfreie Deinstallationen, ist aber teilweise sehr muehsam in der Benutzung -- und hat kein Dep-Management integriert.
Jetzt fragts du vielleicht: prinzipiell nicht schlecht aber warum sollte man ueberhaupt von Sourcen installieren? Dafuer gibt es viele gute Gruende:
- manchmal braucht man einfach das neueste vom neusten - oder die Binaerpakete, die bei der Distribution sind nicht konfiguriert oder optimiert wie man es gern haette, oder gar kaputt-gepatcht
In Grenzen eine Alternative zu stow. (Wobei stow mit symbolischen Links aus anderen Verzeichnissen arbeitet und man so garantiert, dass niemals Dateien von Fremdpaketen ueberschrieben werden.)
Aber Guix ist ja viel maechtiger. Der Witz an Guix ist ja gerade das Dependency-Management. Ich empfehle mal Gnome von Hand zu installieren, dann weisst du was ich meine...
Aber der Programmiersprachenwechsel verspricht ja schon mal das sich die Massen darauf stürzen werden. "Guile Scheme anstelle der Nix Language" Also Guile Scheme können bestimmt viel mehr Leute als Nix Language.
Mit Lisp/Scheme dürften vermutlich viele Informatikstudenten während des Studiums einmal Kontakt gehabt haben. Bei uns war es gleich im ersten Semester.
Von Anerkannter Hater am Mo, 26. November 2012 um 18:32 #
Tja die meisten dürften das auch schon wieder verdrängt haben. Lisp hat der Welt ja schöne Features gezeigt, aber jetzt, wo andere Programmiersprachen die wirklich wichtigen davon übernommen und verbessert haben, kann man diese ja anhand dieser wirklich besseren, völlig zurecht nicht ausgestorbenen Sprachen zeigen. Die Lispsyntax ist nur "genial" für faule Leute die den Parser entwickeln müssen; das menschliche Gehirn benötigt Kontraste.
Von Anerkannter Hater am Di, 27. November 2012 um 17:50 #
Ich habe LISP nicht nur gelernt und verstanden, ich habe im Gegensatz zu dir auch die richtigen Schlüsse daraus gezogen.
Es gibt einen guten Grund, warum selbst PHP eine weitere Verbreitung als LISP hat. Und der liegt nicht daran, dass die meisten zu unfähig für LISP sind.
\ironie{on} Ich glaube es gibt unter Linux mehr Paketmanager, als Viren unter Windows. Beides ist aber genauso ärgerlich.
Android wäre auch kein echtes Linux, wenn es nicht sein eigenen Paketmanager mit brächte.
Ach, ich sehe gerade, Windows hat auch mehrere Paketmanager anzubieten: http://de.wikipedia.org/wiki/Paketverwaltung#.C3.9Cbersicht_verbreiteter_Updatesoftware_f.C3.BCr_Windows_und_Mac_OS_X
...Na, da hat ja Linux schon fast seine Existenzberechtigung verloren. Aber ich hab' auch noch eine Idee: Ich schreib jetzt ein Paketmanager-Manager. Damit soll es dann möglich sein, alle Paketmanager des ganzen Universums in einer einzigen Distribution zu verwenden. Dann kann Windows einpacken! \ironie{off}
Ich versteh dein Problem nicht. Falls es eines gibt, liegt es nicht an den verschiedenen Paketmanagern, sondern die Abhängigkeiten die die Pakete generieren.
Von Kubuntu-User am Mo, 26. November 2012 um 17:29 #
Wie soll ich nämlich meinem Vater erklären, dass er nicht einfach "Setup.exe" herunterladen kann, sondern entweder irgendwelche Backports (???) nutzen oder gleich auf eine neue Version (!!!) der Distribution warten muss?
(Der Nutzen eines Paketmanagers ist MIR schon bewusst, aber Normalsterblichen eben nicht...)
Dein Vater muss sich halt ins Linuxsystem einarbeiten, genauso wie er das einstmals unter Windows getan hat. Linux kann - von Wine einmal abgesehen - gar nichts mit setup.exes anfangen. Punkt. Linux ist nicht Windows.
Ich kann mir auch nicht vorstellen, dass Dein Vater auf ewig von Deiner Expertise abhängig sein will. Die Ubuntuusers.de-Wiki lässt grüßen.
Zusätzliche Software gibt es genug, siehe OBS oder Universe-/Multiverse-/Backports-Repos. Es handelt sich hier - neumodisch formuliert - um gigantische, unter Debian und openSUSE immer kostenfreie "App-Stores" (Ubuntu hat in seinem Softwarecenter ein paar Kaufsoftwareangebote mit im Angebot). Damit ist man auch selbst dann, wenn man zunächst gar keine Linuxahnung haben sollte, erst einmal ganz gut aufgehoben.
Stichwort Abofalle ist da immer ein gutes Argument.
Ausserdem seh ich nicht ein, weshalb ich unter Windows irgendwelche .exe aus dem Netz ziehen muss und nicht mal nachschauen kann, was die jetzt tut oder welche Dateien installiert wurden.
Mein Vater ist nach einer kleinen Einführung in synaptic damit echt zufrieden.
Von zettberlin am Mo, 26. November 2012 um 19:09 #
> dass er nicht einfach "Setup.exe" herunterladen kann
Bedeutet erst mal, dass er bis dahin noch nie auf irgend einer ominösen Webseite irgendwas herunterladen musste -- die ganzen 5-600 Endanwenderprogramme von der Office-suite bis zum Kartoffelknülch muss man nur in einem übersichtlichen Paketmanager anklicken und schon sind sie automagisch installiert....
Zum anderen: wenn er unbedingt eine alte oder eine ganz neue Version eines Programms benötigt, kann das Projekt, das die Software anbietet, auch eine ganz normale Standalone-Version dieses Programms anbieten. Das geht für die Mozilla-Sachen, Libre Office und selbst Boliden wie Ardour3 mit komplexen Abhängigkeiten. Es gibt auch eine ganze Reihe proprietärer Bezahlsoftware, die genau so angeboten wird und dann auch ganz normal funktioniert.
Wenn Softwareprojekte sowas nicht anbieten, ist das jedenfalls kein technisches Problem. Machen kann man es schon immer.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Nov 2012 um 19:11.
Von LSB Unterstützen! am Mi, 28. November 2012 um 11:53 #
das die Software anbietet, auch eine ganz normale Standalone-Version dieses Programms anbieten.
"Kann", der Schwerpunkt liegt auf kann. Das Problem ist, das es kaum ein Projekt macht, hier ist das Problem, aber das habe ich ja unten schon angeführt.
Die LSB wäre eine gute Basis für solche Binärcompilate.
Dann muss man ihm mal den Konflikt zwischen Bequemlichkeit und Sicherheit erklären.
Irgendeine Setup.exe bringt IRGENDWAS auf den Rechner. Im besten schlechten Fall nur minderwertige Software, die den Rechner mit der xten Variante von DLLs vollmüllt. Die meisten Windows-Download-Anbieter führen ja nicht mal eine Prüfsumme, geschweige denn Signatur an, obwohl das gerade hier besonders wichitg wäre. Da der Hauptangriffsvektor Windows-PCs sind, ist es recht wahrscheinlich, dass man sich beim Holen irgendwelcher Pakete von irgendwelchen Webseiten schnell etwas einfägt.
Beim Linux-Paketmanagement hat man durch die Signierung mit den Standard-Repositories erstmal eine grosse Sicherheit. Mit ein wenig Nachschlagen kann ein Übervorsichtiger auch rauskriegen, wie man ein RPM-, DEB- etc. Paket auspacken und sich alles ganau ansehen kann, bevor man es installiert. Das dürfte bei einer Setup.exe erheblich schwieriger sein
Noch einfacher ist das bei Distris, die einfache Archive einsetzen. Natürlich schützt das auch nicht vor einem bösen Binary. Da muss man auf signierte Pakete achten und den Betreuern der Downloadserver vertrauen.
Um ganz sicher zu gehen hilft allerdings nur das Selbst-Kompilieren nach Quelltextanalyse ... immerhin ein Weg, der unter Linux bei freier Software IMMER geht.
Apropos Bequemlichkeit: Die üblichen Paketmanager haben neben den meist bekannten den rieisigen Vorteil, dass Programme einfach, vollständig und ohne Nebenwirkungen deinstalliert werden können, zumindest bei beim APT-System mit oder ohne Erhalt der Konfiguration. Das APT- und YUM-Paketmanagement (letzteres mit Plugins) enthalten auch Möglichkeiten zur Konfliktlösung, Fortführung abgebrochener Aktionen, Entsorgung unbenutzter Pakete etc.
Nochmal zu den Paketmanagern für Einsteiger: - Standard-Repositories verwenden - auf Signierung bei Zusatzrepositories achten / prüfen - Fremdpakete - nach Recherche - von möglichst vertrauenswürdigen Servern unter Beachtung von Prüfsumme / Signatur laden (Prüfsummen lassen sich auch mit einigen Dateimanagern ermitteln)
Ist ein Paket nicht verfügbar, Quelltextpakete verwenden, das ist meist kein Teufelswerk: Abhängigkeitsangaben beachten, README und INSTALL o.ä. lesen und beachten.
Und es gibt noch das nette Alien, mit welchem man Pakete der führenden Formate ineinander umwandeln kann.
Um ganz sicher zu gehen hilft allerdings nur das Selbst-Kompilieren nach Quelltextanalyse ... immerhin ein Weg, der unter Linux bei freier Software IMMER geht.
Er geht nicht nur nicht immer, sondern praktisch nie. Niemand hat die Ressourcen, den Quelltext nichttrivialer Programme hinreichend genau zu analysieren, um Manipulationen auszuschließen.
Von Sicher ist nicht sicher am Mi, 28. November 2012 um 11:58 #
Um ganz sicher zu gehen hilft allerdings nur das Selbst-Kompilieren nach Quelltextanalyse ... immerhin ein Weg, der unter Linux bei freier Software IMMER geht.
Sag deinem Vadder, dass bei Linux schon alle Software die es gibt in der jeweils aktuellen Version dabei ist und er sie nur über die Paketverwaltung an- oder abschalten muss. Reicht doch?! Mehr braucht man gar nicht erklären.
"Im Paketmanager nach gewünschtem Programm suchen und auf installieren klicken"
vs
"Im Internet nach bestimmten Programm suchen, $SicherheitsbelehrungUndSchulungWieManSchadseitenUndAboFallenErkenntUndVermeidet, installer herunterladen, Installer auf dem vollgemüllten Desktop suchen, doppelklick, Ja, Weiter, Ja, Weiter, Weiter, $BelehrungÜberToolbarsUndWerbeDreck, angepasste Installation, Toolbars rausnehmen sonst http://www.computerrepairnorfolkva.com/blog/wp-content/uploads/2011/10/too_many_toolbars.jpg fertig, evtl sicherheitshalber neu starten, updater dringed immer laufen lassen, wenn kein Updater vorhanden rss vom Entwickler abonieren oder einmal im Monat manuell schauen $SicherheitsbelehrungWarumUpdatesWichtigSind "
Ich verstehe dein Argument nicht. Bitte erläutern.
Sag doch einfach, das geht jetzt wie auf dem Telefon. Da haben komischerweise selbst die hartnäckigsten setup.exe-Verfechter kein Problem mit einem zentralen Repositorium.
Sag doch einfach, das geht jetzt wie auf dem Telefon. Da haben komischerweise selbst die hartnäckigsten setup.exe-Verfechter kein Problem mit einem zentralen Repositorium.
Von LSB Unterstützen! am Mo, 26. November 2012 um 23:48 #
Das Problem ist nicht lösbar, solange Open Source Entwickler keine, gegen die lsb gelinkte Compilate, ihrer aktuellen Software anbieten und etwaige nicht enthaltene Libs gleich mitliefern oder statisch linken. Des weitern müßte diese Compilate dann selsbtverständlich mit einem netten installer (z.B. Loki installer) ausgeliefert werden und nach /opt installiert werden.
NUR so läßt sich das Problem, dass DAUs von einigen Programmen die aktuelle Version, die nicht in ihrerer Distribution beiliegen, für jedwede Distribution die die LSB unterstützt, installieren können.
Aber dazu BEDARF es der Bereitschaft der Open Source Entwickler solche LSB Compilate, und nicht nur den Sourcecode anzubieten.
Aber solange die Meinung vertreten wird, dass, wenn man für Open Source entwickelt, müsse man gar nichts, außer das, worauf man als Entwickel selbst Bock hat, wird das leider nichts werden.
Dass DAUs ihre Systeme verlumpen ist halt auch nicht das Problem der Entwickler. Die bekommen das ja auch gar nicht mit, wenn ein DAU sich im chip.de-Forum ausheult :) BTW: DAUs legen auch ihr Windows lahm. C’est la vie...
Von zettberlin am Di, 27. November 2012 um 11:26 #
>ausgeliefert werden und nach /opt installiert werden.
http://ardour.org/download
Bitte beachte die Zeile ganz unten bezüglich der Spendenzahlung. Wenn Nutzer es so wollen, muss das irgendwie finanziert werden. Die von vielen anscheinend so geschätzten Setup-Exen sind meist durch schlichte Bezahlung einer Lizenzgebühr und/oder durch Werbemüll von Adfly-Nervereien bis Spywareinfektion finanziert.
Wer freie Software auf diese spezielle Weise haben will, obwohl die Paketrepos der Distributionen für fast alles akzeptabel aktuelle Versionen aller gängigen Pakete sehr komfortabel anbieten, soll sagen, was er dafür ausgibt.
Von LSB Unterstützen! am Mi, 28. November 2012 um 11:49 #
Wer für den Verkauf von Software Geld verdienen will, der soll auch eine propritäre Lizenz wählen bei der man das "kostenlos weiterverteilen" verhindern kann.
> Wenn Nutzer es so wollen, muss das irgendwie finanziert werden.
Ein LSB Compilat zu erzeugen ist ein einziges Script und dieses Script wird ein einziges mal erstellt. Ich wüßte nicht welchen Aufwand (bis auf das einmalige erstellen des Scriptes) du hier anführen möchtest?
Im übrigens gibt's auch nicht nur Großprojekte wie Ardour die meist eine static binarys Lösung auf irgendeine oder andere Weise haben, sondern es gibt auch die tausende kleineren OS Projekte zu denen es nur den Quellcode gibt.
> obwohl die Paketrepos der Distributionen für fast alles akzeptabel aktuelle Versionen aller gängigen Pakete sehr komfortabel anbieten
Wenn es so wäre, würde für solche Compilate kein Bedarf bestehen. Guck dir mal ne aktuelle Debian stable an, dann weißt du wie alt die Software ist. Die meisten Pakete mögen ausreichen, es gibt aber auch Ausnahmen wo eine aktuelle Version notwendig ist und dann sollte die Open Source Szene bessere Lösungen bereitstellen als nur den Quellcode, wenn das mit Linux auf dem Desktop etwas werden soll.
Ich weiß auch gar nicht was dieses "dagegen wettern" wie du es hier durch "das Aufzählen von Gründen um das Versagen zu begründen" versuchst bringen soll, es ist nun einmal eine Tatsache, das das 1001+n-te Paketsystem das eigentliche Problem nicht löst. Die LSB ist aber die, sie müßte nur einmal verwendet werden.
Und wie dann die Installer ausgeliefert werden, im Prinzip würde auch deb oder rpm gehen, ist nebensächlich. Wichtig ist, das die Compilate gegen die LSB gelinkt werden und ihre Libs die sie nutzen und nicht in der LSB sind mitliefern.
Von zettberlin am Mi, 28. November 2012 um 14:33 #
> Wer für den Verkauf von Software Geld verdienen will, der soll auch eine propritäre Lizenz wählen bei der man das "kostenlos weiterverteilen" verhindern kann.
Ardour bekommt als absolut freies Projekt jeden Monat 4.500 Dollar von den Nutzern rein, das ist nicht sehr viel, reicht aber anscheindend durchaus auch für einen generischen Installer.
>MÜSSEN Pakete bereitstellen
Nein, müssen sie gar nicht, genau gesehen müssen sie nicht mal die Quellcodes veröffentlichen, sie tun es trotzdem, weil sie Vorteile davon haben. Das ist ein Geben und (ein bisschen) Zurückbekommen.
Wer hätte nun einen Vorteil von immer aktuell gehaltenen Installationspaketen? Ach so, die Nutzer. Na dann: lasst Euch mal eine motivierende Aktivität einfallen, ihr Nutzer!
Wie absurd dieses "MÜSSEN" eigentlich ist, sieht man daran, dass interessierte Nutzer nur sehr selten auch nur *fragen*, ob sie so ein Paket bekommen können. Du tust es und ich gehe davon aus, dass Du entsprechende Mails an die Entwickler geschickt hast, von deren Programmen Du so ein Paket gerne haben möchtest.
Aber wer noch? Wieviele Anfragen dieser Art gehen wohl bei den Entwicklern ein? Ich weiß jedenfalls von vielen Projekten, die aus Repos zehntausende Male installiert werden und die Monatelang nicht eine Feedbackmail bekommen.
>Ich weiß auch gar nicht was dieses "dagegen wettern" wie du es hier durch "das Aufzählen von Gründen um das Versagen zu begründen" versuchst bringen soll, es ist nun einmal eine Tatsache, das das 1001+n-te Paketsystem das eigentliche Problem nicht löst.
Von "Versagen" spricht man, wenn jemand einen Auftrag annimmt und dann nicht oder nicht richtig ausführt. Die allermeisten freien Entwickler haben keinen Auftrag, sie tun, was sie tun, weil sie es tun wollen und damit übernehmen sie allenfalls die Verpflichtung, saubere Software zu schreiben -- so zu sagen aus Handwerkerehre.
> Und wie dann die Installer ausgeliefert werden, im Prinzip würde auch deb oder rpm gehen, ist nebensächlich. Wichtig ist, das die Compilate gegen die LSB gelinkt werden und ihre Libs die sie nutzen und nicht in der LSB sind mitliefern.
In dem Punkt kann ich Dir nur voll und ganz zustimmen. Wenn schon ein Paket, dann richtig....
Endlich noch ein Paketmanager !
Und das sogar im Alphastadium !!
Darauf habe ich schon lange gewartet.
Das braucht die Linux-Welt !
Klappspaten, die Idioten kopieren, die die Errungenschaften modernen Paketmanagements aus dämlichen Motivien negieren oder erst gar nicht verstehen.
EOT
Schonmal Software aus Sourcen installiert? Ich denke die Antwort ist nein.
Das Problem ist folgendes: wenn du Software direkt von den Sourcen installierst, machst du typischerweise folgendes:
./configure
make
sudo make install
oder wenn nicht mal autoconf dabei ist:
make
Warum ist das schlecht? Du installierst gerade 1.0rc1 und merkst auf einmal die Version ist Muell oder zu instabil. Stattdessen laedst du jetzt 0.9.18 runter und bist gluecklich. Naja, fast... Im Zweifelsfall konntest du die Reste des alten Paketes nicht rueckstandsfrei beseitigen.
Zwar liefern manche Pakete sowas wie ein make uninstall mit, aber das funktioniert ungefaehr so gut wie ein Uninstaller von Windows 95. Eine Abhilfe ist sowas:
./configure --prefix=$HOME/abc-0.9
...oder man verwendet sowas wie stow oder xstow. Das garantiert spurenfreie Deinstallationen, ist aber teilweise sehr muehsam in der Benutzung -- und hat kein Dep-Management integriert.
Jetzt fragts du vielleicht: prinzipiell nicht schlecht aber warum sollte man ueberhaupt von Sourcen installieren? Dafuer gibt es viele gute Gruende:
- manchmal braucht man einfach das neueste vom neusten
- oder die Binaerpakete, die bei der Distribution sind nicht konfiguriert oder optimiert wie man es gern haette, oder gar kaputt-gepatcht
Wie wärs mit
./configure
make
checkinstall
?
In Grenzen eine Alternative zu stow. (Wobei stow mit symbolischen Links aus anderen Verzeichnissen arbeitet und man so garantiert, dass niemals Dateien von Fremdpaketen ueberschrieben werden.)
Aber Guix ist ja viel maechtiger. Der Witz an Guix ist ja gerade das Dependency-Management. Ich empfehle mal Gnome von Hand zu installieren, dann weisst du was ich meine...
Aber der Programmiersprachenwechsel verspricht ja schon mal das sich die Massen darauf stürzen werden. "Guile Scheme anstelle der Nix Language" Also Guile Scheme können bestimmt viel mehr Leute als Nix Language.
Schade. Nix kann jeder.
Ach Mist, ich kann nur garnix
Mit Lisp/Scheme dürften vermutlich viele Informatikstudenten während des Studiums einmal Kontakt gehabt haben. Bei uns war es gleich im ersten Semester.
Tja die meisten dürften das auch schon wieder verdrängt haben.
Lisp hat der Welt ja schöne Features gezeigt, aber jetzt, wo andere Programmiersprachen die wirklich wichtigen davon übernommen und verbessert haben, kann man diese ja anhand dieser wirklich besseren, völlig zurecht nicht ausgestorbenen Sprachen zeigen.
Die Lispsyntax ist nur "genial" für faule Leute die den Parser entwickeln müssen; das menschliche Gehirn benötigt Kontraste.
Es scheint, du hast LISP entweder nie gelernt oder nie verstanden.
Ich habe LISP nicht nur gelernt und verstanden, ich habe im Gegensatz zu dir auch die richtigen Schlüsse daraus gezogen.
Es gibt einen guten Grund, warum selbst PHP eine weitere Verbreitung als LISP hat.
Und der liegt nicht daran, dass die meisten zu unfähig für LISP sind.
\ironie{on}
Ich glaube es gibt unter Linux mehr Paketmanager, als Viren unter Windows. Beides ist aber genauso ärgerlich.
Android wäre auch kein echtes Linux, wenn es nicht sein eigenen Paketmanager mit brächte.
Ach, ich sehe gerade, Windows hat auch mehrere Paketmanager anzubieten:
http://de.wikipedia.org/wiki/Paketverwaltung#.C3.9Cbersicht_verbreiteter_Updatesoftware_f.C3.BCr_Windows_und_Mac_OS_X
...Na, da hat ja Linux schon fast seine Existenzberechtigung verloren. Aber ich hab' auch noch eine Idee: Ich schreib jetzt ein Paketmanager-Manager. Damit soll es dann möglich sein, alle Paketmanager des ganzen Universums in einer einzigen Distribution zu verwenden. Dann kann Windows einpacken!
\ironie{off}
Gruß
Man kann den gleichen Paketmanager auf allen Distributionen verwenden. Angeboten werden diese ja meist alle: zypper, yum, apt, smart, usw.
Von daher ist dieses Problem nicht technischer Natur.
Ich versteh dein Problem nicht. Falls es eines gibt, liegt es nicht an den verschiedenen Paketmanagern, sondern die Abhängigkeiten die die Pakete generieren.
Wie soll ich nämlich meinem Vater erklären, dass er nicht einfach "Setup.exe" herunterladen kann, sondern entweder irgendwelche Backports (???) nutzen oder gleich auf eine neue Version (!!!) der Distribution warten muss?
(Der Nutzen eines Paketmanagers ist MIR schon bewusst, aber Normalsterblichen eben nicht...)
Dein Vater muss sich halt ins Linuxsystem einarbeiten, genauso wie er das einstmals unter Windows getan hat. Linux kann - von Wine einmal abgesehen - gar nichts mit setup.exes anfangen. Punkt. Linux ist nicht Windows.
Ich kann mir auch nicht vorstellen, dass Dein Vater auf ewig von Deiner Expertise abhängig sein will. Die Ubuntuusers.de-Wiki lässt grüßen.
Zusätzliche Software gibt es genug, siehe OBS oder Universe-/Multiverse-/Backports-Repos. Es handelt sich hier - neumodisch formuliert - um gigantische, unter Debian und openSUSE immer kostenfreie "App-Stores" (Ubuntu hat in seinem Softwarecenter ein paar Kaufsoftwareangebote mit im Angebot). Damit ist man auch selbst dann, wenn man zunächst gar keine Linuxahnung haben sollte, erst einmal ganz gut aufgehoben.
Stichwort Abofalle ist da immer ein gutes Argument.
Ausserdem seh ich nicht ein, weshalb ich unter Windows irgendwelche .exe aus dem Netz ziehen muss und nicht mal nachschauen kann, was die jetzt tut oder welche Dateien installiert wurden.
Mein Vater ist nach einer kleinen Einführung in synaptic damit echt zufrieden.
> dass er nicht einfach "Setup.exe" herunterladen kann
Bedeutet erst mal, dass er bis dahin noch nie auf irgend einer ominösen Webseite irgendwas herunterladen musste -- die ganzen 5-600 Endanwenderprogramme von der Office-suite bis zum Kartoffelknülch muss man nur in einem übersichtlichen Paketmanager anklicken und schon sind sie automagisch installiert....
Zum anderen: wenn er unbedingt eine alte oder eine ganz neue Version eines Programms benötigt, kann das Projekt, das die Software anbietet, auch eine ganz normale Standalone-Version dieses Programms anbieten. Das geht für die Mozilla-Sachen, Libre Office und selbst Boliden wie Ardour3 mit komplexen Abhängigkeiten. Es gibt auch eine ganze Reihe proprietärer Bezahlsoftware, die genau so angeboten wird und dann auch ganz normal funktioniert.
Wenn Softwareprojekte sowas nicht anbieten, ist das jedenfalls kein technisches Problem. Machen kann man es schon immer.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Nov 2012 um 19:11."Kann", der Schwerpunkt liegt auf kann.
Das Problem ist, das es kaum ein Projekt macht, hier ist das Problem, aber das habe ich ja unten schon angeführt.
Die LSB wäre eine gute Basis für solche Binärcompilate.
Dann muss man ihm mal den Konflikt zwischen Bequemlichkeit und Sicherheit erklären.
Irgendeine Setup.exe bringt IRGENDWAS auf den Rechner.
Im besten schlechten Fall nur minderwertige Software, die den Rechner mit der xten Variante von DLLs vollmüllt. Die meisten Windows-Download-Anbieter führen ja nicht mal eine Prüfsumme, geschweige denn Signatur an, obwohl das gerade hier besonders wichitg wäre.
Da der Hauptangriffsvektor Windows-PCs sind, ist es recht wahrscheinlich, dass man sich beim Holen irgendwelcher Pakete von irgendwelchen Webseiten schnell etwas einfägt.
Beim Linux-Paketmanagement hat man durch die Signierung mit den Standard-Repositories erstmal eine grosse Sicherheit.
Mit ein wenig Nachschlagen kann ein Übervorsichtiger auch rauskriegen, wie man ein RPM-, DEB- etc. Paket auspacken und sich alles ganau ansehen kann, bevor man es installiert.
Das dürfte bei einer Setup.exe erheblich schwieriger sein
Noch einfacher ist das bei Distris, die einfache Archive einsetzen.
Natürlich schützt das auch nicht vor einem bösen Binary. Da muss man auf signierte Pakete achten und den Betreuern der Downloadserver vertrauen.
Um ganz sicher zu gehen hilft allerdings nur das Selbst-Kompilieren nach Quelltextanalyse ... immerhin ein Weg, der unter Linux bei freier Software IMMER geht.
Apropos Bequemlichkeit: Die üblichen Paketmanager haben neben den meist bekannten den rieisigen Vorteil, dass Programme einfach, vollständig und ohne Nebenwirkungen deinstalliert werden können, zumindest bei beim APT-System mit oder ohne Erhalt der Konfiguration. Das APT- und YUM-Paketmanagement (letzteres mit Plugins) enthalten auch Möglichkeiten zur Konfliktlösung, Fortführung abgebrochener Aktionen, Entsorgung unbenutzter Pakete etc.
Nochmal zu den Paketmanagern für Einsteiger:
- Standard-Repositories verwenden
- auf Signierung bei Zusatzrepositories achten / prüfen
- Fremdpakete - nach Recherche - von möglichst vertrauenswürdigen Servern unter Beachtung von Prüfsumme / Signatur laden (Prüfsummen lassen sich auch mit einigen Dateimanagern ermitteln)
Ist ein Paket nicht verfügbar, Quelltextpakete verwenden, das ist meist kein Teufelswerk: Abhängigkeitsangaben beachten, README und INSTALL o.ä. lesen und beachten.
Und es gibt noch das nette Alien, mit welchem man Pakete der führenden Formate ineinander umwandeln kann.
Vertraust du deinem Compiler?
Sag deinem Vadder, dass bei Linux schon alle Software die es gibt in der jeweils aktuellen Version dabei ist und er sie nur über die Paketverwaltung an- oder abschalten muss.
Reicht doch?! Mehr braucht man gar nicht erklären.
(Setup.exe?! pff, sowas von mega unflott!)
"Im Paketmanager nach gewünschtem Programm suchen und auf installieren klicken"
vs
"Im Internet nach bestimmten Programm suchen, $SicherheitsbelehrungUndSchulungWieManSchadseitenUndAboFallenErkenntUndVermeidet, installer herunterladen, Installer auf dem vollgemüllten Desktop suchen, doppelklick, Ja, Weiter, Ja, Weiter, Weiter, $BelehrungÜberToolbarsUndWerbeDreck, angepasste Installation, Toolbars rausnehmen sonst http://www.computerrepairnorfolkva.com/blog/wp-content/uploads/2011/10/too_many_toolbars.jpg fertig, evtl sicherheitshalber neu starten, updater dringed immer laufen lassen, wenn kein Updater vorhanden rss vom Entwickler abonieren oder einmal im Monat manuell schauen $SicherheitsbelehrungWarumUpdatesWichtigSind "
Ich verstehe dein Argument nicht. Bitte erläutern.
Sag doch einfach, das geht jetzt wie auf dem Telefon. Da haben komischerweise selbst die hartnäckigsten setup.exe-Verfechter kein Problem mit einem zentralen Repositorium.
Sag doch einfach, das geht jetzt wie auf dem Telefon. Da haben komischerweise selbst die hartnäckigsten setup.exe-Verfechter kein Problem mit einem zentralen Repositorium.
Das Problem ist nicht lösbar, solange Open Source Entwickler keine, gegen die lsb gelinkte Compilate, ihrer aktuellen Software anbieten und etwaige nicht enthaltene Libs gleich mitliefern oder statisch linken.
Des weitern müßte diese Compilate dann selsbtverständlich mit einem netten installer (z.B. Loki installer) ausgeliefert werden und nach /opt installiert werden.
NUR so läßt sich das Problem, dass DAUs von einigen Programmen die aktuelle Version, die nicht in ihrerer Distribution beiliegen, für jedwede Distribution die die LSB unterstützt, installieren können.
Aber dazu BEDARF es der Bereitschaft der Open Source Entwickler solche LSB Compilate, und nicht nur den Sourcecode anzubieten.
Aber solange die Meinung vertreten wird, dass, wenn man für Open Source entwickelt, müsse man gar nichts, außer das, worauf man als Entwickel selbst Bock hat, wird das leider nichts werden.
Dass DAUs ihre Systeme verlumpen ist halt auch nicht das Problem der Entwickler. Die bekommen das ja auch gar nicht mit, wenn ein DAU sich im chip.de-Forum ausheult :)
BTW: DAUs legen auch ihr Windows lahm. C’est la vie...
>ausgeliefert werden und nach /opt installiert werden.
http://ardour.org/download
Bitte beachte die Zeile ganz unten bezüglich der Spendenzahlung. Wenn Nutzer es so wollen, muss das irgendwie finanziert werden. Die von vielen anscheinend so geschätzten Setup-Exen sind meist durch schlichte Bezahlung einer Lizenzgebühr und/oder durch Werbemüll von Adfly-Nervereien bis Spywareinfektion finanziert.
Wer freie Software auf diese spezielle Weise haben will, obwohl die Paketrepos der Distributionen für fast alles akzeptabel aktuelle Versionen aller gängigen Pakete sehr komfortabel anbieten, soll sagen, was er dafür ausgibt.
Wer für den Verkauf von Software Geld verdienen will, der soll auch eine propritäre Lizenz wählen bei der man das "kostenlos weiterverteilen" verhindern kann.
> Wenn Nutzer es so wollen, muss das irgendwie finanziert werden.
Ein LSB Compilat zu erzeugen ist ein einziges Script und dieses Script wird ein einziges mal erstellt.
Ich wüßte nicht welchen Aufwand (bis auf das einmalige erstellen des Scriptes) du hier anführen möchtest?
Im übrigens gibt's auch nicht nur Großprojekte wie Ardour die meist eine static binarys Lösung auf irgendeine oder andere Weise haben, sondern es gibt auch die tausende kleineren OS Projekte zu denen es nur den Quellcode gibt.
> obwohl die Paketrepos der Distributionen für fast alles akzeptabel aktuelle Versionen aller gängigen Pakete sehr komfortabel anbieten
Wenn es so wäre, würde für solche Compilate kein Bedarf bestehen.
Guck dir mal ne aktuelle Debian stable an, dann weißt du wie alt die Software ist.
Die meisten Pakete mögen ausreichen, es gibt aber auch Ausnahmen wo eine aktuelle Version notwendig ist und dann sollte die Open Source Szene bessere Lösungen bereitstellen als nur den Quellcode, wenn das mit Linux auf dem Desktop etwas werden soll.
Ich weiß auch gar nicht was dieses "dagegen wettern" wie du es hier durch "das Aufzählen von Gründen um das Versagen zu begründen" versuchst bringen soll, es ist nun einmal eine Tatsache, das das 1001+n-te Paketsystem das eigentliche Problem nicht löst.
Die LSB ist aber die, sie müßte nur einmal verwendet werden.
Und wie dann die Installer ausgeliefert werden, im Prinzip würde auch deb oder rpm gehen, ist nebensächlich.
Wichtig ist, das die Compilate gegen die LSB gelinkt werden und ihre Libs die sie nutzen und nicht in der LSB sind mitliefern.
> Wer für den Verkauf von Software Geld verdienen will, der soll auch eine propritäre Lizenz wählen bei der man das "kostenlos weiterverteilen" verhindern kann.
Ardour bekommt als absolut freies Projekt jeden Monat 4.500 Dollar von den Nutzern rein, das ist nicht sehr viel, reicht aber anscheindend durchaus auch für einen generischen Installer.
>MÜSSEN Pakete bereitstellen
Nein, müssen sie gar nicht, genau gesehen müssen sie nicht mal die Quellcodes veröffentlichen, sie tun es trotzdem, weil sie Vorteile davon haben. Das ist ein Geben und (ein bisschen) Zurückbekommen.
Wer hätte nun einen Vorteil von immer aktuell gehaltenen Installationspaketen? Ach so, die Nutzer.
Na dann: lasst Euch mal eine motivierende Aktivität einfallen, ihr Nutzer!
Wie absurd dieses "MÜSSEN" eigentlich ist, sieht man daran, dass interessierte Nutzer nur sehr selten auch nur *fragen*, ob sie so ein Paket bekommen können. Du tust es und ich gehe davon aus, dass Du entsprechende Mails an die Entwickler geschickt hast, von deren Programmen Du so ein Paket gerne haben möchtest.
Aber wer noch? Wieviele Anfragen dieser Art gehen wohl bei den Entwicklern ein? Ich weiß jedenfalls von vielen Projekten, die aus Repos zehntausende Male installiert werden und die Monatelang nicht eine Feedbackmail bekommen.
>Ich weiß auch gar nicht was dieses "dagegen wettern" wie du es hier durch "das Aufzählen von Gründen um das Versagen zu begründen" versuchst bringen soll, es ist nun einmal eine Tatsache, das das 1001+n-te Paketsystem das eigentliche Problem nicht löst.
Von "Versagen" spricht man, wenn jemand einen Auftrag annimmt und dann nicht oder nicht richtig ausführt. Die allermeisten freien Entwickler haben keinen Auftrag, sie tun, was sie tun, weil sie es tun wollen und damit übernehmen sie allenfalls die Verpflichtung, saubere Software zu schreiben -- so zu sagen aus Handwerkerehre.
> Und wie dann die Installer ausgeliefert werden, im Prinzip würde auch deb oder rpm gehen, ist nebensächlich.
Wichtig ist, das die Compilate gegen die LSB gelinkt werden und ihre Libs die sie nutzen und nicht in der LSB sind mitliefern.
In dem Punkt kann ich Dir nur voll und ganz zustimmen. Wenn schon ein Paket, dann richtig....