Als ich das letzte Mal alien benutze, hat es die Abhängigkeiten des RPMs nicht mit übernommen. Also mussten diese "manuell" via apt nachinstalliert werden.
Die Benutzung von alien halte ich für relativ böse, eben genau wegen diesen Abhängigkeiten und der Tatsache, dass konvertierte Pakete u.U. Dateien aus anderen Paketen ersetzen, da eben fremde Pakete nicht auf die nativen abgestimmt sind. Ich nutze nur .debs, und wenn ein Paket mal nicht verfügbar ist, dann sollte man sich lieber inoffizielle Builds suchen oder den Sourcecode selber bauen, und aus diesen anschließend am besten per checkinstall ein .deb erstellen.
...und wer will, dass es tut, der nimmt Gentoo, oder wie? Hat Slackware named runlevels, dependency services, läuft es auf 12 Architekturen? Hat es 10000 Pakete? Hat es mehr PS und ist angesagter (jo ho in tha hood, we all use Slackware, bro!)? Warum können manche Leute nicht akzeptieren, dass es mehrere Distries gibt mit verschiedenen Stärken und Schwächen, und warum glauben so tolle Poster wie du sie wüssten irgendwas über Gentoo?
Von Gentoo Symphatisant am Do, 1. Juni 2006 um 00:03 #
Also ich weiß nicht was das ganze soll. Gentoo ist doch wirklich einmalig (auch wenn ich es bisher nicht benutze).
Wo ist Open Source besser umgesetzt? Wenn ich Gentoo auf Platform XYZ Gentoo einsetzen möchte, dann brauche ich einfach nur neu zu compilieren - Sourcecode reicht! Bei welcher anderen Distribution kann ich aus sonst etwas lauffähiges aus dem SourceCode generieren?
M$ weiß schon warum sie Daniel Robbins, den Gentoo Gründer und Papst gegen gutes Gehalt aus dem Verkehr gezogen haben.
Hab grade beim lesen des Postigs gedacht ich könnte mal wieder ne Slackware installieren. Auf der Webseite (slackware.org) ist die letzte News vom 14.9.2005, und auf #slackware@freenode wurde grade über us Bundesstaaten diskutiert...
also gentoo ist ja auch von vom "Distributor" und seinen Paketen abhängig. Du musst es nur alles selber kompilieren. Wenn du wirklich ein System haben willst, dass du zu 100% selber bestimmst, dann geht letzt endlich doch nur LFS
Irgendwelche halbinstallierten Programme, die aber alles blocken und mit den obengenannten Tools nicht zu reparieren sind.. Uhm, entweder diese Programme deinstallieren (falls das möglich ist), oder "dpkg --configure -a" ausführen. Ohne genauere Informatioen ist es relativ schwer eine Problemlösung zu finden.
danke.. das dpkg --configure, da bin ich schlussendlich auch gelandet, zuerst hab ich aber noch was im /var/cache/dpkg/irgendwo gelöscht, betreffend der packete... Danach ging mal was.. immerhin (ich weiss.. keine gute Lösung)
Schuld war ein freeze bei einem update im X. Danach waren unter anderem kghostview und libtiff4 ssh openssh-server nicht mehr update-fähig mit apt-get.
Aber das rauszufinden war enorm schwer, da mir gar nicht klar wurde, welche Applikation das reparieren sollte.
das Problem fing an, als dri mit Savage aktiviert werden sollte, was übrigens auch funktionierte. Es bringt Vorteile. Wer's nicht will, der muss ja nicht.
falls du mich meinst: 1. ich schreib schweizer-halbhochdeutsch. Merkst du das nicht? 2. Schleichgefühl.. muss jeder den Spezialisten raushängen lassen? 3. anklagelose Sprache, Provokationen bringen dich und mich nicht weiter. Die lautesten Prediger sind meistens die ungläubigsten.
schön, dass Du Dir fremde Sätze merken kannst. Ich hoffe aber, Du kannst auch eigene formen und seien es nur schweizer-halbhochdeutsche.
Ei, das ist nett, nach den Pro-Gentoo Trollen kommen jetzt die Contra Trolle aus dem Keller.
Warum kann Gentoo wegen zeroinstall einpacken? Weil es eine flexible Distribution ist und eine der ersten, die ZeroInstall im Paketmanager hatte? Oder weil man jetzt kein Paketmanagement mehr braucht?
... wird dabei aber übersehen. Es hat auch seine Vorteile, auf die Distribution angepaßte Pakete zu erzeugen, bzw. dafür zu sorgen, dass die Software in diese aufgenommen wird. Wie verpasse ich der im Userverzeichnis installierten Software ein automatisches Sicherheitsupdate? Wie schütze ich den User meines Systems vor seiner eigenen Fahrlässigkeit, "mal eben" aus dem Netz schnell das neueste "Superprogramm" runterzuladen und sich damit irgendeinen Trojaner ins Haus zu holen? Wie vollziehe ich auf einem solchen System eine ABI-Transition, wie sie schon häufiger vonnöten war? Verkommt der lokale Usercache dann nicht mit der Weile zum System im System? Und das womöglich für jeden User separat? Wäre die LSB nicht der bessere, weil systemweite Ansatz, wenn es darum geht, eine Kompatibilitätsschicht zu haben?
Ja, ich weiss, man muss es ja nicht installieren. Und ich finde den Ansatz trotzdem wichtig. Das macht die Nachteile, wenn man es einsetzt, aber dennoch nicht wett und man sollte sie nicht vergessen. Davon abgesehen ist es heutzutage wirklich ein Kinderspiel, Software zu installieren unter Verwendung des Paketmanagements der Distribution. Synaptic und Adept zeigen schon für Debian, wie es gehen kann. Für die anderen Distributionen gibt es garantiert auch genug Lösungen.
zu mehr als zum Ausprobieren taugen ZeroInstall und vergleichbare Techniken nicht, weil sie ein eigenes Paketmanagement parallel zu dem des Systems aufbauen. Das Ergebnis sind verkonfigurierte und kaputtinstallierte Systeme, wie wir sie von MS-Windows ("setup.exe" + Benutzereinstellungen) kennen. Immerhin kann man das Homeverzeichnis komplett löschen und das Zeug so wieder restlos entsorgen.
Für Entwickler ist es auch keine Option. Pakete, die ZeroInstall problemlos auf einem anderen System unterbringt, kann auch alien konvertieren. Das einzige, was es diesem voraus hat ist das automatische Auflösen von Abhängigkeiten -- wobei ich nicht glaube, dass die problematischsten Abhängigkeiten (z.B. von der Kernel- oder der X-*Konfiguration*) automatisch aufgelöst werden können. Das endet wiederum in einem kaputtkonfigurierten System.
Letztendlich muss der Admin über seine Maschine Bescheid wissen, das kann ihm keine Software abnehmen.
Wie schütze ich den User meines Systems vor seiner eigenen Fahrlässigkeit, "mal eben" aus dem Netz schnell das neueste "Superprogramm" runterzuladen und sich damit irgendeinen Trojaner ins Haus zu holen?
Gar nicht, denn (1) ist es wohl nicht Deine Aufgabe, und (2) leistet das auch das Paketsystem der Distribution nicht: Wie will die denn verhindern, daß Anwender "mal eben" Sourcecode aus dem Netz laden und sich damit den Trojaner frisch für ihr System kompilieren?
Wie vollziehe ich auf einem solchen System eine ABI-Transition, wie sie schon häufiger vonnöten war?
Am besten garnicht, weil man damit Software kaputt macht, die sich der Anwender veilleicht gekauft hat! Was ja durchaus vorkommen kann. Solange darauf keine Rücksicht genommmen wird, ist Linux nicht für Heim-Anwender geeignet, und man sollte anfangen, das offen zuzugeben statt den Leuten etwas vorzumachen.
Natürlich hat es auch seine Vorteile, Pakete für die Distribution zu bauen, wenn es möglich ist. Aber man sollte sehen, daß es einerseits nicht Aufgabe der Anwendungsentwickler sein kann, das zu tun; es aber andererseits für sie durchaus sinnvoll ist, distributions-unabhängige Binärpakete zum Download zur Verfügung stellen.
Oder soll jedes Entwickler-Team gleich eine ganze LiveCD produzieren -- so wie es die Amorok getan hat --, nur damit die neuste Version sofort von einer breiten Basis zur Verfügung steht?
Die Nachteile einer Lösung wie ZeroInstall sind durchaus klar. Aber Du solltest vielleicht auch mal die Nachteile der gegenwärtigen Lösung betrachten: den Zeitverlust bei hunderttausenden von Anwendern, die langsame Verbreitung neuer Versionen und Informationen, die ausufernden Kosten, etc.
> Gar nicht, denn (1) ist es wohl nicht Deine Aufgabe Weil heutzutage User == Administrator? Zeroinstall richtet sich doch nicht nur an den Heimanwender.
> (2) leistet das auch das Paketsystem der Distribution nicht Natürlich. Sie bietet die Infrastruktur, die Software aus sicheren Quellen heraus zu installieren und die Konfiguration auch ans System anzupassen.
> : Wie will die denn verhindern, daß Anwender "mal eben" Sourcecode aus dem Netz laden > und sich damit den Trojaner frisch für ihr System kompilieren? aptitude purge gcc
> Am besten garnicht Ach und Du meinst, die Distributionen vollziehen ABI-Changes, weil es ihnen Spaß macht?
> die sich der Anwender veilleicht gekauft hat Meinen Hinweis auf die LSB hast Du auch gelesen?
> distributions-unabhängige Binärpakete zum Download zur Verfügung stellen. Herzlich willkommen bei der LSB.
> den Zeitverlust bei hunderttausenden von Anwendern aptitude install Schneller gehts nicht.
Zeroinstall richtet sich doch nicht nur an den Heimanwender.
Lautet nicht die goldene Regel: Anwender, die an fremden (Firmen-)Rechnern sitzen, sollte keine Software installieren wollen, und wenn sie es wollen, sollten sie den Admin bitten müssen, es zu tun?
Wenn ein Admin seinen Anwendern die Installation per ZeroInstall erlaubt, wird er dafür gute Gründe haben. Und um das klar zu machen: Mir geht es um Heimanwender und ihre Probleme.
aptitude purge gcc
Viele Skripte dürften sich nicht vom Fehlen des GCCs beeindrucken lassen.
Die LSB ist im übrigen ein zahnloser Tiger, wenn die Distributionen den vollen Zugang zum Endanwender haben, und die Entwickler von Anwendungssoftware sich vollständig auf die Distributionen verlassen.
aptitude install Schneller gehts nicht.
Wohl kaum. Die Heim-Anwender werden wohl durchschnittlich mehrere Monate warten dürfen bis sich die nächste Version 2.0 von Firefox in den offiziellen Repositories wiederfindet. Bis dahin haben die Jungs auf dem Schulhof einen jungen Linux-Anwender wohl schon mehrfach ausgelacht -- es ist keine Überraschung, daß man Gentoo nachsagt, so viele junge Nutzer zu haben.
> Wenn ein Admin seinen Anwendern die Installation per ZeroInstall erlaubt, wird er > dafür gute Gründe haben "Gute Gründe" sind doch nur relativ anhand des Wissens des Administrators festlegbar. Sein Wissen bildet sich aus seiner Erfahrung und Erfahrung sammelt er durch die Informationen. Informationen die, wie bei diesem Beitrag, sehr einseitig ausfallen können. Deshalb wies ich auf ein paar Nachteile hin.
> Mir geht es um Heimanwender und ihre Probleme. In Ordnung. Dann erkläre mir bitte mal, inwiefern sich folgende Sachverhalte hinsichtlich der Einfachheit der Installation eines Heimanwenders (Anwender und Administrator in Personalunion) ansich voneinander unterscheiden:
0install: - Anwender besucht www.tollesprogramm.org - Anwender klickt auf "Download" - Anwender klickt auf "Paket für Tollesprogramm" - Anwender wählt "Öffnen mit Zeroinstall-Injector..." aus - Anwender lässt Tollesprogramm im Userspace installieren
deb/rpm: - Anwender besucht www.tollesprogramm.org - Anwender klickt auf "Download" - Anwender liest: "Pakete für MeineDistri installieren Sie mit ..." - Anwender öffnet Rootshell oder Paketverwaltungsprogramm - Anwender sucht gegebenenfalls und installiert dann Tollesprogramm
> Viele Skripte dürften sich nicht vom Fehlen des GCCs beeindrucken lassen. Skripte sind keine Userspaceanwendungen. Und Userspaceanwendungen bringen in der Regel keinen eigenen Compiler mit. Außerdem war das nur ein Beispiel, das für die Aussage "ohne Build-Umgebung kein Anwendungsselberbauen" stehen sollte.
> Die LSB ist im übrigen ein zahnloser Tiger Und woran machst Du das fest? Die Distribution verbürgt sich mit dem dazugehörigen Zertifikat dafür, sich an die Bedingungen der LSB-Umgebung zu halten.
> die Entwickler von Anwendungssoftware sich vollständig auf die Distributionen verlassen Das müssen sie eben nicht, das ist ja der Punkt. LSB == "such Dir irgendeine aus". Die Distribution, die dann nicht damit arbeitet, obwohl sie zertifiziert ist, hat ein Problem.
> Die Heim-Anwender werden wohl durchschnittlich mehrere Monate warten dürfen Ich bitte Dich. Das ist doch ein Märchen.
> es ist keine Überraschung, daß man Gentoo nachsagt, so viele junge Nutzer zu haben Weil?
>deb/rpm: - Anwender besucht www.tollesprogramm.org >- Anwender klickt auf "Download" >- Anwender liest: "Pakete für MeineDistri installieren Sie mit ..." >- Anwender öffnet Rootshell oder Paketverwaltungsprogramm >- Anwender sucht gegebenenfalls und installiert dann Tollesprogramm
tolles-programm braucht libA,B,C in den Versionen X,Y,Z Anwender trägt in sources.list ein: deb tolles-programm-repository apt-macht-das-schon
Anwender freut sich. Beim dist-upgrade in einem Monat ist sein System durch viele solche Einträge (die wirklich alles im System installieren können was sie wollen) total zerschossen.
klik: Anwender hat eine .cmg Datei, in der alle benötigten Abhängigkeiten enthalten sind. Das System bleibt vor Veränderungen durch externe Pakete verschont.
> Beim dist-upgrade in einem Monat ist sein System [...] total zerschossen Ist es das? Mal ganz davon abgesehen, dass man sein System, um eben nichts deinstalliert zu bekommen, auch per "upgrade" aktualisieren kann, frage ich mich, ob die Leute bei Distributionen Langeweile haben. Was genau kann Zeroinstall an der Tatsache, daß Abhängigkeiten sich in stetiger Entwicklung befinden, ändern? Wie sieht ein Zeroinstallcache nach einem Jahr aus? Wie nach drei? Nach fünf? Sauberere Abhängigkeiten kann man nicht mal eben "herzaubern", nur, weil man nicht mehr deb oder rpm heißt.
> klik: Stimmt, Klik war hier aber nicht das Thema. ;)
>Ist es das? Die Gefahr besteht nun mal. Wieso muss jedes kleine GUI-Programm wie ein fester Bestandteil der Distribution behandelt werden, wenn es auch einfacher und eben auch sicherer geht (weil nicht mit root-rechten installiert)?
>Stimmt, Klik war hier aber nicht das Thema.;) Ob es nun klik, 0install, oder das offizielle tar.gz Archiv von mozilla-firefox ist, in allen Fällen erhält man doch am Ende ein fat-binary, dass die meisten Bibliotheken einfach selber mitbringt.
> (weil nicht mit root-rechten installiert) Die Installation ansich ist doch nur dann ein Thema, wenn ich Fremdquellen einbeziehe, so, wie es verstärkt auftritt, wenn One-Klick-Ansätze wie eben Zeroinstall benutzt werden. Es geht aber auch um die damit einhergehende Gefahr der installierten Binaries. Du brauchst keine Rootrechte, um Dein Home vollständig gelöscht zu bekommen, Du brauchst auch keine, um einen Socket auf einem höheren Port lauschen zu lassen und viele Exploits lassen sich erst lokal ausnutzen. Wenn der Nutzer die Software dank der "Download and Klickinstall"-Lastigkeit erstmal aufs lokale System geholt hat, ist eine Hürde schon mal genommen. Ich verteufle Zeroinstall auch nicht ansich, mein Ursprungsartikel wollte auf die Schattenseiten dessen hinweisen, die, wie ich finde, wichtig sind.
Es geht aber auch um die damit einhergehende Gefahr der installierten Binaries.
Achso, der Debian Server ist also noch nie gehackt worden? Oder der GNOME Server? Vielleicht trifft es morgen den KDE Server?
Das obige Argument ist blödsinnig, auch wenn es jeder wiederholt. In der Praxis haben wir allen Heim-Anwender beigebracht, wie sie Quelltexte installieren können, ohne ihnen beigebracht zu haben, wie man Malware im Quelltext erkennt!
Mit einem simplen "make install" kann man sich Python oder Perl Skripte ins System installieren, die alles dürfen, oder man redet Anwendern inoffizielle Repositories ein, wie dieses hier. Woran soll man erkennen, daß die Pakete nicht gehackt sind?
Offizielle Binary-Pakete von der Homepage der Anwendung oder Sourceforge sind da genauso sicher oder unsicher.
Ich spreche Software aus Fremdquellen prinzipiell weniger Sicherheit zu als denen, die von der Distribution geliefert werden, ob nun als Binary oder nicht. Um die Frage Binary oder nicht geht es mir hierbei nicht.
> Achso, der Debian Server ist also noch nie gehackt worden? Ist er, aber wie Du der entsprechenden Meldung entnehmen kannst, waren die Paketarchive nicht betroffen. Davon abgesehen argumentierst Du an dem Punkt etwas unsinnig. Natürlich gibt es keine absolute Sicherheit, deshalb sprach ich auch nie davon. Aber man kann Risiken zumindest minimieren und das Paradigma des Verzichtes auf Fremdquellen bei der Softwareinstallation gehört dazu. Wenn ich mir überall im Internet One-Klick-Binaries holen kann, steigt auch das potentielle Sicherheitsrisiko, das willst Du doch nicht bestreiten?
> Woran soll man erkennen, daß die Pakete nicht gehackt sind? Offizielle Paketarchive der Distributoren bieten zumindest mehr Sicherheitsfeatures als die meisten Projektseiten.
> Offizielle Binary-Pakete von der Homepage der Anwendung oder Sourceforge Auch das habe ich nie bestritten.
Wenn ich mir überall im Internet One-Klick-Binaries holen kann, steigt auch das potentielle Sicherheitsrisiko, das willst Du doch nicht bestreiten?
Doch, natürlich will ich das: Das "potentielle Sicherheitsrisiko" hängt vom Verhalten und den Wünschen des Anwenders ab. Die bloße Existenz von One-Klick-Binaries ändert dessen Verhalten und dessen Wünsche nicht!
Im Gegenteil: Wer Firefox 2.0 installieren will, sobald es da ist, wird alle Quellen nutzen, die dann zur Verfügung stehen. Je schwieriger die Installation von der Mozilla Homepage wird, desto eher wird ein solcher Anwender in-offizielle Repositories nutzen, die möglicherweise gehackte Firefox-Binaries liefern.
Oder als Gedanken-Experiment: Nimm an, alle Windows-Nutzer steigen morgen auf Linux um. Sie werden vielleicht ein Jahr brauchen um sich zu akklimatisieren, aber auch dann werden manche Leute einer Anleitung irgendeiner Internet-Seite Folge leisten, wenn sie das angebotene Spiel haben wollen. Auch, wenn da steht: "Öffnen Sie ein Terminal und tippen sie 'sudo make install' und geben sie ihr Passwort ein."
Achso, der Debian Server ist also noch nie gehackt worden? Oder der GNOME Server? Vielleicht trifft es morgen den KDE Server? Das würde spätestens bei der Überprüfung der GPG-Signatur auffallen, welche diverse Paketmanager standardmäßig durchführen und bei fehlerhafter Signatur den Installationsvorgang abbrechen.
>Du brauchst keine Rootrechte, um ... Das ist schon klar, aber ein Paket muss ja nicht unbedingt aus Böse-Quelle-tm kommen, um was am System kaputt zu machen, es kann auch einfach schlecht gemacht sein (z.B. sich nicht an konventionen halten), einen Fehler im installations-shell-skript haben, etc. Wenn ich im Paketsystem nur offizielle Quellen hab, dann brauch ich mich auch nicht um Konflikte zwischen offiziellen und externen Paketen sorgen.
>Ich verteufle Zeroinstall auch nicht ansich, mein Ursprungsartikel wollte auf die Schattenseiten dessen hinweisen, die, wie ich finde, wichtig sind.
Ok, ich seh ja auch die Vorteile, alles aus einer Quelle zu haben und möglichst aufzuteilen (zB Fehler in einer lib für viele installierte Programme fixen). Aber mit dem alles-aus-einer-Hand-Prinzip wird man halt niemals alle existierenden Anwendungen erreichen, und deswegen sehe ich schon einen Bedarf für die Grenzziehung zwischen dem eigentlichen System und den wichtigen Bibliotheken und Tools auf der einen Seite und den unmengen an Desktop-Anwendungen die eigentlich kein fester Bestandteil der Distribution mehr sind auf der anderen. Wie genau die Lösung dafür aussieht, das ist die große Herausforderung für Desktop-Linux.
Noch was zum Thema Klik, 0install und so weiter: 0install packt meines Wissens im Gegensatz zu Klik die Dependencies nicht mit ins Ergebnisarchiv hinein. Die Dependencies landen separat im Cache und werden von dort aus dynamisch verwendet.
"Gute Gründe" sind doch nur relativ anhand des Wissens des Administrators festlegbar. Sein Wissen bildet sich aus seiner Erfahrung und Erfahrung sammelt er durch die Informationen. Informationen die, wie bei diesem Beitrag, sehr einseitig ausfallen können. Deshalb wies ich auf ein paar Nachteile hin.
Absolut. Und weil Deine Aufzählung der Nachteile genauso einseitig war -- schließlich hast Du weder auf die Nachteile der Distributionslösung hingewiesen, noch deutlich gemacht, daß sich Deine Hinweise an System-Administratoren richten --, habe ich noch ein, zwei Punkte aus Sicht eines Heimanwenders hinterfragt. ;-)
Wie ich schon zu Anfang geschrieben habe:
"Aber Du solltest vielleicht auch mal die Nachteile der gegenwärtigen Lösung betrachten: den Zeitverlust bei hunderttausenden von Anwendern, die langsame Verbreitung neuer Versionen und Informationen, die ausufernden Kosten, etc."
Wobei ich im übrigen nicht behauptet haben, daß ZeroInstall hier eine Lösung wäre.
Der wesentliche Punkt ist, daß sich Open Source Entwickler zu häufig auf die Distributionen verlassen, wenn es um das Auslieferen ihrer Software an den Heim-Anwender geht. Somit ist auch die LSB für den Heim-Anwender wenige relevant: Wen kümmert es, eine Anwendung nach LSB installieren zu können, wenn es keine solchen Anwendungen gibt?
Deine Darstellung von Installationen unter PRM/DEB trifft übrigens nur im Idealfall zu. Realistische Beispiele:
Lade bitte das "offizielle" Paket von gPodder für Ubuntu Linux. Es ist prompt kaputt, wahrscheinlich weil es für Ubuntu 5.04 gepackt wurde, und nicht für Ubuntu 5.10. Sage mir: Woran soll der Heimanwender das erkennen, bevor er damit seine Zeit verschwendet hat?
Versuche, die neuste Version Ekiga zu installieren. Selbst wenn unser Heim-Anwender weiß, daß er Ubuntu installiert hat: Welche Version denn eigentlich und was ist amd64, i386, und powerpc? Nehmen wir an, er wählt breezy_i386: Welches von den 11 Paketen soll er den nun installieren und in welcher Reihenfolge? Und wer sagt ihm, daß er tunlichst seine alten Pakete im System erstmal deinstallieren sollte, damit es da nicht zu Problemen kommt?
Mit anderen Worten: Entweder man verrennt sich in komische Problem mit RPM/DEB Paketen und verschwendet damit seine Zeit, oder man rüstet einfach mit in-offiziellen Repositories nach (und kann sich wieder sonstwas installieren), oder man wartet mehrere Monate auf das offizielle Update der Distribution -- was im übrigen kein Märchen ist.
Im übrigen erhält man dan solche Kommentare von Entwicklern: "wxWidgets just got to version 2.6.3 some days ago, and it's the recomended version for aMule, [...] As usual, my reply to "I have this or that problem" that seem related to wxWidgets, if you're not using 2.6.3 or CVS version of it, will be "update". So... update."
Tja, wxWidget ist aber auch die Anti-GUI-Bib aus Distributionssicht: Selbst minor releases machen Programme kaputt, mit Unicode ist inkompatibel zu ohne unicode... Ich kann von der Verwendung nur abraten, weil man dann genau solche Probleme bei der Verteilung von Software bekommt.
"Davon abgesehen ist es heutzutage wirklich ein Kinderspiel, Software zu installieren unter Verwendung des Paketmanagements der Distribution. Synaptic und Adept zeigen schon für Debian, wie es gehen kann. Für die anderen Distributionen gibt es garantiert auch genug Lösungen."
Dann erkläre mir doch einmal bitte, wie Du lokal ein Programm mit Synaptic installierst...
also man kann jetzt neben den üblchen rpm,deb,tgz und noch ein paar paketen
das bsd-portsystem und auch autopackage verwenden. die meiste software lässt sich ausserdem mittels unzip/tarx vzf und einfach im homdeirectory installieren (realplayer, enemys territory, acrobat reader, etc) ganz ohne paketsystem. Das mit dem Abhängigkeiten automatisch auflösen wird gar nie funktionieren da die paketierung viel zu verschieden ist und versionskonflikte doch ein bisschen "tricky" sind. Auch gentoo produziert nur mist bei den abhängigkeiten sobald man an den compile-flags rumspielt.
lg
Erik
Gentoo war doch eh eine Versuchsprojekt für die Clerasilfraktion, oder den krankhaften
Kompiliervorgangsbeobachter.
Küss die Hand
In gentoo lässt muss man mit sehr viele mühe die ganzen unsinnigen patches wieder raus machen
wer "originalverpackte" software will (ohne patches vom distributor) sollte slackware nehmen...
Full Ack!
Küss die Hand
Mann mann, denkt doch mal nach vorm schreiben.
Wo ist Open Source besser umgesetzt? Wenn ich Gentoo auf Platform XYZ Gentoo einsetzen möchte, dann brauche ich einfach nur neu zu compilieren - Sourcecode reicht! Bei welcher anderen Distribution kann ich aus sonst etwas lauffähiges aus dem SourceCode generieren?
M$ weiß schon warum sie Daniel Robbins, den Gentoo Gründer und Papst gegen gutes Gehalt aus dem Verkehr gezogen haben.
Zu fähig der Mann...
Gentoo != LFS
joo.. genau. ich geniesse es, den Compiliervorgang zu beobachten, endlich mal Prozessorlast.
Noch nie TV geschaut, da laufen auf den Monitoren auch immer Programme im Hintergrund, ne also :)
PS. das Ubuntu bei mir hat sich leider tot-ge-get-apt
oder tot-ge-dpkg
oder totgea-ptituded
weiss immer noch nicht, was ich da verwenden soll.
Irgendwelche halbinstallierten Programme, die aber alles blocken und mit den obengenannten Tools nicht zu reparieren sind.. Danke
Uhm, entweder diese Programme deinstallieren (falls das möglich ist), oder "dpkg --configure -a" ausführen. Ohne genauere Informatioen ist es relativ schwer eine Problemlösung zu finden.
das dpkg --configure, da bin ich schlussendlich auch gelandet, zuerst hab ich aber noch was im /var/cache/dpkg/irgendwo gelöscht, betreffend der packete... Danach ging mal was.. immerhin (ich weiss.. keine gute Lösung)
Schuld war ein freeze bei einem update im X. Danach waren unter anderem kghostview und libtiff4 ssh openssh-server nicht mehr update-fähig mit apt-get.
Aber das rauszufinden war enorm schwer, da mir gar nicht klar wurde, welche Applikation das reparieren sollte.
das Problem fing an, als dri mit Savage aktiviert werden sollte, was übrigens auch funktionierte. Es bringt Vorteile. Wer's nicht will, der muss ja nicht.
Wenn man keine Ahnung hat, einfach mal die Fresse halten!
Warum beschleicht mich das Gefühl, dass es dein Standardsatz ist: "Ich weiss nicht!"?
Küss die Hand
1. ich schreib schweizer-halbhochdeutsch. Merkst du das nicht?
2. Schleichgefühl.. muss jeder den Spezialisten raushängen lassen?
3. anklagelose Sprache, Provokationen bringen dich und mich nicht weiter. Die lautesten Prediger sind meistens die ungläubigsten.
schön, dass Du Dir fremde Sätze merken kannst. Ich hoffe aber, Du kannst auch eigene formen und seien es nur schweizer-halbhochdeutsche.
Warum kann Gentoo wegen zeroinstall einpacken? Weil es eine flexible Distribution ist und eine der ersten, die ZeroInstall im Paketmanager hatte? Oder weil man jetzt kein Paketmanagement mehr braucht?
Ja, ich weiss, man muss es ja nicht installieren. Und ich finde den Ansatz trotzdem wichtig. Das macht die Nachteile, wenn man es einsetzt, aber dennoch nicht wett und man sollte sie nicht vergessen. Davon abgesehen ist es heutzutage wirklich ein Kinderspiel, Software zu installieren unter Verwendung des Paketmanagements der Distribution. Synaptic und Adept zeigen schon für Debian, wie es gehen kann. Für die anderen Distributionen gibt es garantiert auch genug Lösungen.
lg
Erik
zu mehr als zum Ausprobieren taugen ZeroInstall und vergleichbare Techniken nicht, weil sie ein eigenes Paketmanagement parallel zu dem des Systems aufbauen. Das Ergebnis sind verkonfigurierte und kaputtinstallierte Systeme, wie wir sie von MS-Windows ("setup.exe" + Benutzereinstellungen) kennen. Immerhin kann man das Homeverzeichnis komplett löschen und das Zeug so wieder restlos entsorgen.
Für Entwickler ist es auch keine Option. Pakete, die ZeroInstall problemlos auf einem anderen System unterbringt, kann auch alien konvertieren. Das einzige, was es diesem voraus hat ist das automatische Auflösen von Abhängigkeiten -- wobei ich nicht glaube, dass die problematischsten Abhängigkeiten (z.B. von der Kernel- oder der X-*Konfiguration*) automatisch aufgelöst werden können. Das endet wiederum in einem kaputtkonfigurierten System.
Letztendlich muss der Admin über seine Maschine Bescheid wissen, das kann ihm keine Software abnehmen.
Gar nicht, denn (1) ist es wohl nicht Deine Aufgabe, und (2) leistet das auch das Paketsystem der Distribution nicht: Wie will die denn verhindern, daß Anwender "mal eben" Sourcecode aus dem Netz laden und sich damit den Trojaner frisch für ihr System kompilieren?
Wie vollziehe ich auf einem solchen System eine ABI-Transition, wie sie schon häufiger vonnöten war?
Am besten garnicht, weil man damit Software kaputt macht, die sich der Anwender veilleicht gekauft hat! Was ja durchaus vorkommen kann. Solange darauf keine Rücksicht genommmen wird, ist Linux nicht für Heim-Anwender geeignet, und man sollte anfangen, das offen zuzugeben statt den Leuten etwas vorzumachen.
Natürlich hat es auch seine Vorteile, Pakete für die Distribution zu bauen, wenn es möglich ist. Aber man sollte sehen, daß es einerseits nicht Aufgabe der Anwendungsentwickler sein kann, das zu tun; es aber andererseits für sie durchaus sinnvoll ist, distributions-unabhängige Binärpakete zum Download zur Verfügung stellen.
Oder soll jedes Entwickler-Team gleich eine ganze LiveCD produzieren -- so wie es die Amorok getan hat --, nur damit die neuste Version sofort von einer breiten Basis zur Verfügung steht?
Die Nachteile einer Lösung wie ZeroInstall sind durchaus klar. Aber Du solltest vielleicht auch mal die Nachteile der gegenwärtigen Lösung betrachten: den Zeitverlust bei hunderttausenden von Anwendern, die langsame Verbreitung neuer Versionen und Informationen, die ausufernden Kosten, etc.
Weil heutzutage User == Administrator? Zeroinstall richtet sich doch nicht nur an den Heimanwender.
> (2) leistet das auch das Paketsystem der Distribution nicht
Natürlich. Sie bietet die Infrastruktur, die Software aus sicheren Quellen heraus zu installieren und die Konfiguration auch ans System anzupassen.
> : Wie will die denn verhindern, daß Anwender "mal eben" Sourcecode aus dem Netz laden
> und sich damit den Trojaner frisch für ihr System kompilieren?
aptitude purge gcc
> Am besten garnicht
Ach und Du meinst, die Distributionen vollziehen ABI-Changes, weil es ihnen Spaß macht?
> die sich der Anwender veilleicht gekauft hat
Meinen Hinweis auf die LSB hast Du auch gelesen?
> distributions-unabhängige Binärpakete zum Download zur Verfügung stellen.
Herzlich willkommen bei der LSB.
> den Zeitverlust bei hunderttausenden von Anwendern
aptitude install
Schneller gehts nicht.
lg
Erik
Lautet nicht die goldene Regel: Anwender, die an fremden (Firmen-)Rechnern sitzen, sollte keine Software installieren wollen, und wenn sie es wollen, sollten sie den Admin bitten müssen, es zu tun?
Wenn ein Admin seinen Anwendern die Installation per ZeroInstall erlaubt, wird er dafür gute Gründe haben. Und um das klar zu machen: Mir geht es um Heimanwender und ihre Probleme.
aptitude purge gcc
Viele Skripte dürften sich nicht vom Fehlen des GCCs beeindrucken lassen.
Die LSB ist im übrigen ein zahnloser Tiger, wenn die Distributionen den vollen Zugang zum Endanwender haben, und die Entwickler von Anwendungssoftware sich vollständig auf die Distributionen verlassen.
aptitude install Schneller gehts nicht.
Wohl kaum. Die Heim-Anwender werden wohl durchschnittlich mehrere Monate warten dürfen bis sich die nächste Version 2.0 von Firefox in den offiziellen Repositories wiederfindet. Bis dahin haben die Jungs auf dem Schulhof einen jungen Linux-Anwender wohl schon mehrfach ausgelacht -- es ist keine Überraschung, daß man Gentoo nachsagt, so viele junge Nutzer zu haben.
> dafür gute Gründe haben
"Gute Gründe" sind doch nur relativ anhand des Wissens des Administrators festlegbar. Sein Wissen bildet sich aus seiner Erfahrung und Erfahrung sammelt er durch die Informationen. Informationen die, wie bei diesem Beitrag, sehr einseitig ausfallen können. Deshalb wies ich auf ein paar Nachteile hin.
> Mir geht es um Heimanwender und ihre Probleme.
In Ordnung. Dann erkläre mir bitte mal, inwiefern sich folgende Sachverhalte hinsichtlich der Einfachheit der Installation eines Heimanwenders (Anwender und Administrator in Personalunion) ansich voneinander unterscheiden:
0install: - Anwender besucht www.tollesprogramm.org
- Anwender klickt auf "Download"
- Anwender klickt auf "Paket für Tollesprogramm"
- Anwender wählt "Öffnen mit Zeroinstall-Injector..." aus
- Anwender lässt Tollesprogramm im Userspace installieren
deb/rpm: - Anwender besucht www.tollesprogramm.org
- Anwender klickt auf "Download"
- Anwender liest: "Pakete für MeineDistri installieren Sie mit ..."
- Anwender öffnet Rootshell oder Paketverwaltungsprogramm
- Anwender sucht gegebenenfalls und installiert dann Tollesprogramm
> Viele Skripte dürften sich nicht vom Fehlen des GCCs beeindrucken lassen.
Außerdem war das nur ein Beispiel, das für die Aussage "ohne Build-Umgebung kein Anwendungsselberbauen" stehen sollte.
Skripte sind keine Userspaceanwendungen. Und Userspaceanwendungen bringen in der Regel keinen eigenen Compiler mit.
> Die LSB ist im übrigen ein zahnloser Tiger
Und woran machst Du das fest? Die Distribution verbürgt sich mit dem dazugehörigen Zertifikat dafür, sich an die Bedingungen der LSB-Umgebung zu halten.
> die Entwickler von Anwendungssoftware sich vollständig auf die Distributionen verlassen
Das müssen sie eben nicht, das ist ja der Punkt. LSB == "such Dir irgendeine aus". Die Distribution, die dann nicht damit arbeitet, obwohl sie zertifiziert ist, hat ein Problem.
> Die Heim-Anwender werden wohl durchschnittlich mehrere Monate warten dürfen
Ich bitte Dich. Das ist doch ein Märchen.
> es ist keine Überraschung, daß man Gentoo nachsagt, so viele junge Nutzer zu haben
Weil?
lg
Erik
>- Anwender klickt auf "Download"
>- Anwender liest: "Pakete für MeineDistri installieren Sie mit ..."
>- Anwender öffnet Rootshell oder Paketverwaltungsprogramm
>- Anwender sucht gegebenenfalls und installiert dann Tollesprogramm
tolles-programm braucht libA,B,C in den Versionen X,Y,Z
Anwender trägt in sources.list ein:
deb tolles-programm-repository apt-macht-das-schon
Anwender freut sich.
Beim dist-upgrade in einem Monat ist sein System durch viele solche Einträge (die wirklich alles im System installieren können was sie wollen) total zerschossen.
klik:
Anwender hat eine .cmg Datei, in der alle benötigten Abhängigkeiten enthalten sind. Das System bleibt vor Veränderungen durch externe Pakete verschont.
Ist es das? Mal ganz davon abgesehen, dass man sein System, um eben nichts deinstalliert zu bekommen, auch per "upgrade" aktualisieren kann, frage ich mich, ob die Leute bei Distributionen Langeweile haben. Was genau kann Zeroinstall an der Tatsache, daß Abhängigkeiten sich in stetiger Entwicklung befinden, ändern? Wie sieht ein Zeroinstallcache nach einem Jahr aus? Wie nach drei? Nach fünf? Sauberere Abhängigkeiten kann man nicht mal eben "herzaubern", nur, weil man nicht mehr deb oder rpm heißt.
> klik:
Stimmt, Klik war hier aber nicht das Thema. ;)
lg
Erik
Die Gefahr besteht nun mal. Wieso muss jedes kleine GUI-Programm wie ein fester Bestandteil der Distribution behandelt werden, wenn es auch einfacher und eben auch sicherer geht (weil nicht mit root-rechten installiert)?
>Stimmt, Klik war hier aber nicht das Thema.;)
Ob es nun klik, 0install, oder das offizielle tar.gz Archiv von mozilla-firefox ist, in allen Fällen erhält man doch am Ende ein fat-binary, dass die meisten Bibliotheken einfach selber mitbringt.
Die Installation ansich ist doch nur dann ein Thema, wenn ich Fremdquellen einbeziehe, so, wie es verstärkt auftritt, wenn One-Klick-Ansätze wie eben Zeroinstall benutzt werden. Es geht aber auch um die damit einhergehende Gefahr der installierten Binaries. Du brauchst keine Rootrechte, um Dein Home vollständig gelöscht zu bekommen, Du brauchst auch keine, um einen Socket auf einem höheren Port lauschen zu lassen und viele Exploits lassen sich erst lokal ausnutzen. Wenn der Nutzer die Software dank der "Download and Klickinstall"-Lastigkeit erstmal aufs lokale System geholt hat, ist eine Hürde schon mal genommen. Ich verteufle Zeroinstall auch nicht ansich, mein Ursprungsartikel wollte auf die Schattenseiten dessen hinweisen, die, wie ich finde, wichtig sind.
lg
Erik
Achso, der Debian Server ist also noch nie gehackt worden? Oder der GNOME Server? Vielleicht trifft es morgen den KDE Server?
Das obige Argument ist blödsinnig, auch wenn es jeder wiederholt. In der Praxis haben wir allen Heim-Anwender beigebracht, wie sie Quelltexte installieren können, ohne ihnen beigebracht zu haben, wie man Malware im Quelltext erkennt!
Mit einem simplen "make install" kann man sich Python oder Perl Skripte ins System installieren, die alles dürfen, oder man redet Anwendern inoffizielle Repositories ein, wie dieses hier. Woran soll man erkennen, daß die Pakete nicht gehackt sind?
Offizielle Binary-Pakete von der Homepage der Anwendung oder Sourceforge sind da genauso sicher oder unsicher.
> Achso, der Debian Server ist also noch nie gehackt worden?
Natürlich gibt es keine absolute Sicherheit, deshalb sprach ich auch nie davon. Aber man kann Risiken zumindest minimieren und das Paradigma des Verzichtes auf Fremdquellen bei der Softwareinstallation gehört dazu. Wenn ich mir überall im Internet One-Klick-Binaries holen kann, steigt auch das potentielle Sicherheitsrisiko, das willst Du doch nicht bestreiten?
Ist er, aber wie Du der entsprechenden Meldung entnehmen kannst, waren die Paketarchive nicht betroffen. Davon abgesehen argumentierst Du an dem Punkt etwas unsinnig.
> Woran soll man erkennen, daß die Pakete nicht gehackt sind?
Offizielle Paketarchive der Distributoren bieten zumindest mehr Sicherheitsfeatures als die meisten Projektseiten.
> Offizielle Binary-Pakete von der Homepage der Anwendung oder Sourceforge
Auch das habe ich nie bestritten.
lg
Erik
Doch, natürlich will ich das: Das "potentielle Sicherheitsrisiko" hängt vom Verhalten und den Wünschen des Anwenders ab. Die bloße Existenz von One-Klick-Binaries ändert dessen Verhalten und dessen Wünsche nicht!
Im Gegenteil: Wer Firefox 2.0 installieren will, sobald es da ist, wird alle Quellen nutzen, die dann zur Verfügung stehen. Je schwieriger die Installation von der Mozilla Homepage wird, desto eher wird ein solcher Anwender in-offizielle Repositories nutzen, die möglicherweise gehackte Firefox-Binaries liefern.
Oder als Gedanken-Experiment: Nimm an, alle Windows-Nutzer steigen morgen auf Linux um. Sie werden vielleicht ein Jahr brauchen um sich zu akklimatisieren, aber auch dann werden manche Leute einer Anleitung irgendeiner Internet-Seite Folge leisten, wenn sie das angebotene Spiel haben wollen. Auch, wenn da steht: "Öffnen Sie ein Terminal und tippen sie 'sudo make install' und geben sie ihr Passwort ein."
Das würde spätestens bei der Überprüfung der GPG-Signatur auffallen, welche diverse Paketmanager standardmäßig durchführen und bei fehlerhafter Signatur den Installationsvorgang abbrechen.
Das ist schon klar, aber ein Paket muss ja nicht unbedingt aus Böse-Quelle-tm kommen, um was am System kaputt zu machen, es kann auch einfach schlecht gemacht sein (z.B. sich nicht an konventionen halten), einen Fehler im installations-shell-skript haben, etc.
Wenn ich im Paketsystem nur offizielle Quellen hab, dann brauch ich mich auch nicht um Konflikte zwischen offiziellen und externen Paketen sorgen.
>Ich verteufle Zeroinstall auch nicht ansich, mein Ursprungsartikel wollte auf die Schattenseiten dessen hinweisen, die, wie ich finde, wichtig sind.
Ok, ich seh ja auch die Vorteile, alles aus einer Quelle zu haben und möglichst aufzuteilen (zB Fehler in einer lib für viele installierte Programme fixen). Aber mit dem alles-aus-einer-Hand-Prinzip wird man halt niemals alle existierenden Anwendungen erreichen, und deswegen sehe ich schon einen Bedarf für die Grenzziehung zwischen dem eigentlichen System und den wichtigen Bibliotheken und Tools auf der einen Seite und den unmengen an Desktop-Anwendungen die eigentlich kein fester Bestandteil der Distribution mehr sind auf der anderen.
Wie genau die Lösung dafür aussieht, das ist die große Herausforderung für Desktop-Linux.
lg
Erik
-----
Ja -- warum machen wir's dann nicht einfach dazu?
Immerhin deckt klik (zumindest teilweise) denselben "Markt" ab wie 0install und autopackage.
lg
Erik
>Ich bitte Dich. Das ist doch ein Märchen.
Dass Debian viele Benutzer an (k)ubuntu verliert, weil man dort zumindest jedes halbe Jahr aktuelle Pakete bekommt, ist vermutlich auch ein Märchen.
lg
Erik
Absolut. Und weil Deine Aufzählung der Nachteile genauso einseitig war -- schließlich hast Du weder auf die Nachteile der Distributionslösung hingewiesen, noch deutlich gemacht, daß sich Deine Hinweise an System-Administratoren richten --, habe ich noch ein, zwei Punkte aus Sicht eines Heimanwenders hinterfragt. ;-)
Wie ich schon zu Anfang geschrieben habe:
"Aber Du solltest vielleicht auch mal die Nachteile der gegenwärtigen Lösung betrachten: den Zeitverlust bei hunderttausenden von Anwendern, die langsame Verbreitung neuer Versionen und Informationen, die ausufernden Kosten, etc."
Wobei ich im übrigen nicht behauptet haben, daß ZeroInstall hier eine Lösung wäre.
Der wesentliche Punkt ist, daß sich Open Source Entwickler zu häufig auf die Distributionen verlassen, wenn es um das Auslieferen ihrer Software an den Heim-Anwender geht. Somit ist auch die LSB für den Heim-Anwender wenige relevant: Wen kümmert es, eine Anwendung nach LSB installieren zu können, wenn es keine solchen Anwendungen gibt?
Deine Darstellung von Installationen unter PRM/DEB trifft übrigens nur im Idealfall zu. Realistische Beispiele:
Mit anderen Worten: Entweder man verrennt sich in komische Problem mit RPM/DEB Paketen und verschwendet damit seine Zeit, oder man rüstet einfach mit in-offiziellen Repositories nach (und kann sich wieder sonstwas installieren), oder man wartet mehrere Monate auf das offizielle Update der Distribution -- was im übrigen kein Märchen ist.
Im übrigen erhält man dan solche Kommentare von Entwicklern: "wxWidgets just got to version 2.6.3 some days ago, and it's the recomended version for aMule, [...] As usual, my reply to "I have this or that problem" that seem related to wxWidgets, if you're not using 2.6.3 or CVS version of it, will be "update". So... update."
Bringt exakt gar nichts. Jeder Kriminelle mit Hirn für 50 cent wird Binaries bereitstellen.
Dann erkläre mir doch einmal bitte, wie Du lokal ein Programm mit Synaptic installierst...
das bsd-portsystem und auch autopackage verwenden. die meiste software lässt sich ausserdem mittels unzip/tarx vzf und einfach im homdeirectory installieren (realplayer, enemys territory, acrobat reader, etc) ganz ohne paketsystem.
Das mit dem Abhängigkeiten automatisch auflösen wird gar nie funktionieren da die paketierung viel zu verschieden ist und versionskonflikte doch ein bisschen "tricky" sind. Auch gentoo produziert nur mist bei den abhängigkeiten sobald man an den compile-flags rumspielt.