Piccolino81
Anmeldungsdatum: 14. Juli 2005
Beiträge: Zähle...
Wohnort: Freiburg i. Brsg.
|
Hallo zusammen, in den letzten Tagen habe ich mich ausgiebig mit dem VMWare-Image der BSD-Distribution PC-BSD beschäftigt: http://www.pcbsd.com/?p=download Sehr positiv fielen mir dabei die einzeln installierbaren PBI-Pakete auf: http://www.pbidir.com/ Man lädt einfach das gewünschte Programm in Form eines solchen PBI-Paketes herunter. Anschliessend wird durch einen Doppelklick darauf der enthaltene Installer gestartet, welcher das Paket dann samt benötigter Libraries (diese sind bereits in den einzelnen Paketen vorhanden) in ein Programm-Verzeichnis auf der Harddisk installiert. Also das BSD-Pendant zu gewöhnlichen Windoof-Setup-Programm - mit dem Vorteil, dass man mit viel wenigeren Klicks auskommt. Entscheidende Vorteile dabei sind: - Auch der unerfahrenste Benutzer ist so im stande ganz einfach gewünschte Software zu installieren ⇒ Benutzerfreundlichkeit - Komfortable PBI-Pakete-Update-Funktion (Pendant zu apt-get) ist dennoch vorhanden ⇒ Benutzerfreundlichkeit - Bei Nichtgefallen wird einfach mittels PBI-Manager das entsprechende Programm sauber und einfach entfernt ⇒ Benutzerfreundlichkeit - Das System bleibt bei einer PBI-Programm-Installation oder -Deinstallation unberührt ⇒ Stabilität Nun frage ich mich also, warum es bei LINUX nicht längst auch ein solch zuverlässiges Pakete-System gibt. Manch einer mag mir nun entgegnen, dass es ein solches in Form von http://klik.atekon.de/ oder http://autopackage.org/ geben mag. Okay, diese Lösungen sind schon ein sehr grosser Schritt in die gleiche Richtung. Doch warum wird das von so gut wie keiner der grösseren LINUX-Distribution "gelebt" - soll heissen, vorangetrieben und verbessert? Einige direkte Vorteile habe ich bereits aufgezählt. Das daraus resultierende Interesse der frustrierten Windoof-User, einen Blick auf LINUX zu werfen, würde meiner Meinung nach rapide Ansteigen. Eine weitere Konsequenz wäre doch auch, dass auch eine kleine Distribution sich aus einem schier grenzenlosen Programm-Pool bedienen könnte. Was denkt Ihr über das Thema?
Gruss Piccolino81
|
ralph_ubuntu
Anmeldungsdatum: 25. Januar 2005
Beiträge: 98
|
Vorweg: Ich habe PC-BSD noch nicht selber getestet. Ich kann also nur von dem ausgehen, was ich bisher über PBI gelesen habe. Piccolino81 hat geschrieben:
Entscheidende Vorteile dabei sind: - Auch der unerfahrenste Benutzer ist so im stande ganz einfach gewünschte Software zu installieren ⇒ Benutzerfreundlichkeit
Ich glaube du machst hier einen Fehler den viele machen. Es sind nicht die unerfahrenen Benutzer, sondern die Benutzer, die davon ausgehen, dass man überall Software auf die Art und Weise installieren muss wie unter Windows, die mit anderen Arten Software zu installieren eventuell Probleme haben. Verstehe mich nicht falsch, Software Installation bei Ubuntu kann sicherlich verbessert werden, aber es fällt mir schwer zu sehen, warum es einfacher sein sollte Pakete aus dem Internet herunterzuladen und diese dann per Hand zu installieren, als ein Program wie gnome-app-install zu verwenden, das thematisch geordnet die verfügbaren Programme auflistet, die dann durch das Setzen einen Häckchens und Drücken des Installieren Knopfes installiert werden können. Piccolino81 hat geschrieben:
- Komfortable PBI-Pakete-Update-Funktion (Pendant zu apt-get) ist dennoch vorhanden ⇒ Benutzerfreundlichkeit
Das klingt doch schonmal gut. Dass es hiermit Probleme geben könnte war eine meiner größten Sorgen. Wie sieht das denn im einzelnen aus? Muss man sich um die einzelnen Pakete selbst kümmern, oder geschieht das automatisch und zentral?
|
ryu
Anmeldungsdatum: 6. Juli 2005
Beiträge: 288
|
Es ist auch bei Ubuntu möglich Pakete aus dem Internet zu laden und per Klick zu installieren. Ich glaube, dass sich das Tool GDebi nennt, bin mir aber nicht sicher. Es nutzt nur keiner, weil er eben so komfortable Tools wie Synaptic oder apt-get hat. Edit: Das ganze war übringens schon immer möglich, auch vor Ubuntu Zeiten. Man konnte das Paket per wget laden und dann mit dpkg -i installieren. Ist nur genauso schwachsinnig.
|
Blattlaus
Anmeldungsdatum: 29. März 2006
Beiträge: 1399
|
Wo ist der Unterschied zu apt? Das einzige was ein bischen anders ist, ist die Tatsache, dass der User sich jedes Paket einzeln von der Homepage runterladen muss. Gut, die Programme lassen sich (angelich!) wunderbar einfach wieder entfernen, aber ob das die Nachteile aufwiegt wage ich zu bezweifeln. Der Nachteil ist , das alle abhängigkeiten pro Paket immer wieder mit verpackt werden, das führt zu furchtbar viel Overhead. Übrigens gibt es sowas schon durchaus für Linux: Statisch kompilierte Programm bei denen alle Libs mit in die Binaries einkompiliert sind. Diese Programm sind groß, hässlich und langsam.
|
Piccolino81
(Themenstarter)
Anmeldungsdatum: 14. Juli 2005
Beiträge: 184
Wohnort: Freiburg i. Brsg.
|
Hallo zusammen, zuerst einmal freut es mich, dass es in so kurzer Zeit schon so viele Meinungen zu dem Thema gibt. @Blattlaus Der Unterschied zu apt-get ist eindeutig - ein Paket pro Programm
> keine Abhängigkeiten ⇒ Pakete an beliebigen Orten downloadbar (so kann man einen Modem-User noch einfacher mit Paketen versorgen) ⇒ Programme lassen sich einfach wieder entfernen, da lediglich Daten in EINEM einzigen Verzeichnis davon liegen
Das mit dem Mehr-Aufwand, nur weil man die Pakete mit den Abhängigkeiten zusammen verpacken muss, sehe ich ein wenig anders. Ist es nicht eindeutig MEHR Aufwand, wenn der einzelne User (und das sind dann gleich tausende) im Spezialfall selbst versuchen muss die Abhängigkeiten eines gewünschten Programms aufzulösen, anstatt dass das der Entwickler oder Distributor EINMAL pro Paket macht???
Auch mit dem Argument der zu grossen und langsamen statisch kompilierten Programme bin ich nicht einverstanden. Zu gross? Bei ständig sich erhöhenden Speichermedien oder Internetbandbreiten? Zu langsam? Dazu sag ich nur "Moore's Law" - die Rechner werden doch eh immer schneller. Desweiteren müsste es doch dann am "schlechten" Verpacken liegen, dass das Programm nicht ordentlich läuft, oder??
@ryu Das mag ja stimmen, dass man einzelne Pakete installieren kann. Doch, wie sieht es aus, wenn die Abhängigkeiten nicht erfüllt sind? Also, vielleicht wurde es aus meinem Text noch nicht deutlich - in PC-BSD werden in den PBI-Paketen alle Abhängigkeiten bzw. Libraries mit eingepackt. Das eine Paket läuft dann auf jedem PC-BSD-System. Während Du mit einem DEB-Paket vielleicht noch das Problem mit den Abhängigkeiten hast - sofern eben nicht statisch kompiliert (siehe oben).
@ralph_ubuntu Du hast recht, dass es mit apt-get um einiges einfacher ist mehrere Programme gleichzeitig zu installieren. Doch wenn erst einmal das Problem der Abhängigkeiten gelöst ist - und das ist es bei den PBI-Paketen nun mal besser als bei DEB-Paketen - dann ist es auch kein unlösbares Problem ein Tool zu entwickeln, mit dem ich MEHRERE solcher PBI-Pakete bzw. Programme GLEICHZEITIG installieren könnte.
Und ja, das mit den Updates läuft automatisch und zentral ab - im PBI-Update-Tool. Was also das einfache Update mehrerer Programme angeht, so kann es vom Prinzip her mit apt-get mithalten.
Allgemeines Fazit: Was ist besser: 1 Entwickler hat viel Arbeit mit der "Verpackung" eines Programms inkl. Abhängigkeiten ⇐> 1000 User habens relativ leicht bei der Installation oder 1 Entwickler hat es relativ leicht ⇐> 1000 User haben viel Arbeit mit dem Auflösen von Abhängigkeiten
Gruss Piccolino81
|
Ubunux
Anmeldungsdatum: 12. Juni 2006
Beiträge: 16456
|
Piccolino81 hat geschrieben: 1 Entwickler hat es relativ leicht ⇐> 1000 User haben viel Arbeit mit dem Auflösen von Abhängigkeiten[/quote] Hallo, mit den richtigen Werkzeugen (aptitude, synaptic usw.) hatte ich äußerst selten Probleme beim Auflösen von Abhängigkeiten, dies erledigen nämlich diese Werkzeuge für mich. Wie schaut es denn bei den pbi-Paketen aus, angenommen Paket X braucht Paket Y, Paket A braucht auch Paket Y, wird das Paket dann quasi doppelt geschnürt und damit auch doppelt heruntergeladen? Gruß Ubunux
|
ralph_ubuntu
Anmeldungsdatum: 25. Januar 2005
Beiträge: 98
|
Piccolino81 hat geschrieben:
@ralph_ubuntu Du hast recht, dass es mit apt-get um einiges einfacher ist mehrere Programme gleichzeitig zu installieren. Doch wenn erst einmal das Problem der Abhängigkeiten gelöst ist - und das ist es bei den PBI-Paketen nun mal besser als bei DEB-Paketen - dann ist es auch kein unlösbares Problem ein Tool zu entwickeln, mit dem ich MEHRERE solcher PBI-Pakete bzw. Programme GLEICHZEITIG installieren könnte.
Da habe ich mich wohl falsch ausgedrückt. Ich gebe dir zwar recht, dass es mit apt einfacher ist mehere Programme gleichzeitig zu installieren, aber das war eigentlich nicht mein Punkt. Mein Punkt war, dass es mit soetwas wie gnome-app-install mindestens genauso einfach, wenn nicht einfacher ist, Programme zu installieren, wie mit einzelnen Installern, die man eigenhändig aus dem Netz herunterladen muss. Piccolino81 hat geschrieben:
Allgemeines Fazit: Was ist besser: 1 Entwickler hat viel Arbeit mit der "Verpackung" eines Programms inkl. Abhängigkeiten ⇐> 1000 User habens relativ leicht bei der Installation oder 1 Entwickler hat es relativ leicht ⇐> 1000 User haben viel Arbeit mit dem Auflösen von Abhängigkeiten
Gruss Piccolino81
Hier muss ich dir auch wieder widersprechen. ;-D Insbesondere frage ich mich, wie du darauf kommst die User hätten viel Arbeit mit dem Auflösen von Abhängigkeiten. Genaugenommen haben sie damit nämlich keinerlei Arbeit, das apt-get das ja automatisch macht. Oder verstehe ich dich da falsch?
|
adun
Anmeldungsdatum: 29. März 2005
Beiträge: 8606
|
Ich kann nicht erkennen was da einfacher sein soll, als beim Hinzufügen/Entfernen Dialog. Vll kannst du da nochmal genauer drauf eingehen.
|
berndix2
Anmeldungsdatum: 22. November 2004
Beiträge: 734
|
Ubunux hat geschrieben: Piccolino81 hat geschrieben: 1 Entwickler hat es relativ leicht ⇐> 1000 User haben viel Arbeit mit dem Auflösen von Abhängigkeiten[/quote] Hallo, mit den richtigen Werkzeugen (aptitude, synaptic usw.) hatte ich äußerst selten Probleme beim Auflösen von Abhängigkeiten, dies erledigen nämlich diese Werkzeuge für mich. Wie schaut es denn bei den pbi-Paketen aus, angenommen Paket X braucht Paket Y, Paket A braucht auch Paket Y, wird das Paket dann quasi doppelt geschnürt und damit auch doppelt heruntergeladen? Gruß Ubunux[/quote] Ja! Und? 😲 Mei ist mir das wurschd, ob eine lib, die vllt. 20 kb groß ist 10 mal herunter geladen wird. Das ist nichts im vgl. zu Spam! Gruß
|
Blattlaus
Anmeldungsdatum: 29. März 2006
Beiträge: 1399
|
Piccolino81 hat geschrieben: @Blattlaus Der Unterschied zu apt-get ist eindeutig - ein Paket pro Programm
> keine Abhängigkeiten
Doch, natürlich haben diese Programm abhängigkeiten. Allerdings wird jede benötigte Komponente einfach mit in den Pott gepackt. Beispiel: Du willst die Programm Foo, Bar und Knuddel installieren. Alle diese drei Programm brauchen die QT-Libaries. Unter PBI wären jetzt in jedem Paket 10MB an Libaries. Unter apt, würden die Libaries einmal mit runtergeladen, und im System gespeichert. Wenn man danach die anderen beiden Programm installiert, wird nur das Programm installiert und sonst nix...eben weil die Abhängigkeiten im System liegen. Piccolino81 hat geschrieben: > Pakete an beliebigen Orten downloadbar (so kann man einen Modem-User noch einfacher mit Paketen versorgen)
Ist auch mit apt kein Problem. Du sagst einfach auf dem schnell angebundenen Rechner "download only" und er wird alle benötigten Pakete runterladen. Die kannst du dann z.B. auf CD brenne und der ohne Internet kann sie auf sein System laden und einfach installieren. Piccolino81 hat geschrieben: > Programme lassen sich einfach wieder entfernen, da lediglich Daten in EINEM einzigen Verzeichnis davon liegen
Ich sehe da keinen Vorteil. Was interessiert es mich, wo die Daten landen? Ich hab einen Paketmanager, dem ich sagen "entferne das" und er löscht alle Dateien die dazu gehören. Ich muss nicht wissen was wohin gehört und ich will es auch garnicht. Piccolino81 hat geschrieben: Das mit dem Mehr-Aufwand, nur weil man die Pakete mit den Abhängigkeiten zusammen verpacken muss, sehe ich ein wenig anders. Ist es nicht eindeutig MEHR Aufwand, wenn der einzelne User (und das sind dann gleich tausende) im Spezialfall selbst versuchen muss die Abhängigkeiten eines gewünschten Programms aufzulösen, anstatt dass das der Entwickler oder Distributor EINMAL pro Paket macht???
Du hast das Konzept von apt nicht verstanden. Der Entwickler (genauer: der Maintainer, der die Pakete herstellt und packt) definiert für jedes Paket: Es braucht das und das und das um zu funktionieren und das Paketmanagment kümmert sich darum diese Abhängigkeiten zu erfüllen. Auch hier hat der User dadurch absolut keinen Aufwand damit. Er sagt dem Paketmanager "instaliier Firefox" und der Paketmanager löst selbstständig und ohne Usereingriff sämtliche abhängigkeiten auf. Piccolino81 hat geschrieben: Auch mit dem Argument der zu grossen und langsamen statisch kompilierten Programme bin ich nicht einverstanden. Zu gross? Bei ständig sich erhöhenden Speichermedien oder Internetbandbreiten? Zu langsam? Dazu sag ich nur "Moore's Law" - die Rechner werden doch eh immer schneller. Desweiteren müsste es doch dann am "schlechten" Verpacken liegen, dass das Programm nicht ordentlich läuft, oder??
Auch hier muss ich wiedersprechen. Programm werden ohnehin immer komplexer, größer und mächtiger. Schon aus dem Grund, weil sie sich immer mehr verteilen. Wenn man heutzutage ein Programm schreibt, entwickelt man keine Methode für den Dateizugriff mehr. Man benutzt eine fertige Libaries (die dann später wiederum eine abhängigkeite des Programm sein wird) um eine Datei zu lesen. Wenn dann nämlich später mal ein Fehler in Libary festgestellt wird, wird der Fehler nur in dieser einen Libary behoben und, tadaa, hunderte Programm die die Libary benutzen sind um einen Bug ärmer. Wenn Entwickler so denken würden wie du, würde sich jeder sein eigenes Süppchen kochen und alles jedes "from Scratch" neu entwickeln. Das würde zu nervigen Dingen führen: - Es gäbe viel weniger Software, weil der Aufwand eine zu schreiben viel größer wäre - Releases würden in größeren Abständen stattfinden - Mehr Bugs - Keine Kompatibilität. Du könntest nicht sagen, heute benutzt ich Xorg, morgen XGL und übermorgen wechsel ich von KDE zu Gnome...das ginge nicht. Piccolino81 hat geschrieben: @ryu Das mag ja stimmen, dass man einzelne Pakete installieren kann. Doch, wie sieht es aus, wenn die Abhängigkeiten nicht erfüllt sind? Also, vielleicht wurde es aus meinem Text noch nicht deutlich - in PC-BSD werden in den PBI-Paketen alle Abhängigkeiten bzw. Libraries mit eingepackt. Das eine Paket läuft dann auf jedem PC-BSD-System. Während Du mit einem DEB-Paket vielleicht noch das Problem mit den Abhängigkeiten hast - sofern eben nicht statisch kompiliert (siehe oben).
Nein, ein PBI-Paket läuft auch nur auf den Systemem mit denen es Binärkompatibel ist. Das ist nunmal so, wenn man Software nicht im Quelltext, sondern kompiliert ausliefert. Ein PBI-Paket für x86 würde auf einer Sparc vielleicht laufen, allerdings nicht wegen PBI, sondern weil das Betriebssystem da mehrer Abstrahierungeben zwischen gepackt hat...das hat nichts mit der Methode der Softwareverteilung zu tun. Piccolino81 hat geschrieben: @ralph_ubuntu Du hast recht, dass es mit apt-get um einiges einfacher ist mehrere Programme gleichzeitig zu installieren. Doch wenn erst einmal das Problem der Abhängigkeiten gelöst ist - und das ist es bei den PBI-Paketen nun mal besser als bei DEB-Paketen - dann ist es auch kein unlösbares Problem ein Tool zu entwickeln, mit dem ich MEHRERE solcher PBI-Pakete bzw. Programme GLEICHZEITIG installieren könnte.
Kein Problem, bei apt, kann man Metapakete definieren...das ist wirklich Kinderkram und kein Argument...sowas kann jedes Paketmanagment Piccolino81 hat geschrieben: Was ist besser: 1 Entwickler hat viel Arbeit mit der "Verpackung" eines Programms inkl. Abhängigkeiten ⇐> 1000 User habens relativ leicht bei der Installation oder 1 Entwickler hat es relativ leicht ⇐> 1000 User haben viel Arbeit mit dem Auflösen von Abhängigkeiten
Siehe mein Geschreibsel zum dritten Subquote. Der User hat nichts damit zu tun, das erledigt alles das Paketmanagment für ihn und er muss sich um nichts kümmern. \––- Übrigens, liege ich richtig mit der Vermutung, dass du noch ernsthaft Programmiert hast? Dann würdest du nämlich die Vorteile von Kapselung und Wiederverwendung von Code (=Libaries) einfach durchblicken. \––- Gut das ich den Posts vorher kopiert hatte. Als hätte ich gewusst, dass sich der Server mit 500 - Internal Error abmeldet 😐
|
Ubunux
Anmeldungsdatum: 12. Juni 2006
Beiträge: 16456
|
berndix2 hat geschrieben: Ja! Und? 😲 Mei ist mir das wurschd, ob eine lib, die vllt. 20 kb groß ist 10 mal herunter geladen wird. Das ist nichts im vgl. zu Spam!Gruß
Hallo, mag ja sein, daß es Dir wurschd ist weil Du eine DSL-Flatrate hast. Ich hab mir aber sagen lassen, daß es noch genügend Modem- u. ISDN-Benutzer gibt 😀 , die für jedes einzelne Byte bezahlen müssen, genau so verhält es sich bei DSL-Nutzern, die einen Volumentarif haben und bei Überschreitung des vereinbarten Volumens für das Mehrvolumen zur Kasse gebeten werden. Gruß Ubunux
|
berndix2
Anmeldungsdatum: 22. November 2004
Beiträge: 734
|
Blattlaus hat geschrieben: Piccolino81 hat geschrieben: @Blattlaus Der Unterschied zu apt-get ist eindeutig - ein Paket pro Programm
> keine Abhängigkeiten
Doch, natürlich haben diese Programm abhängigkeiten. Allerdings wird jede benötigte Komponente einfach mit in den Pott gepackt. Beispiel: Du willst die Programm Foo, Bar und Knuddel installieren. Alle diese drei Programm brauchen die QT-Libaries. Unter PBI wären jetzt in jedem Paket 10MB an Libaries. Unter apt, würden die Libaries einmal mit runtergeladen, und im System gespeichert. Wenn man danach die anderen beiden Programm installiert, wird nur das Programm installiert und sonst nix...eben weil die Abhängigkeiten im System liegen.
Ja genau, und deswegen kannst Du mit einem "Apt-System" auch nix anfangen, wenn Foo z.B. QT-Lib 3.0.0 (was auch in Deinem System installiert ist) benötigt, Bar und Knuddel allerdings auf QT-Lib 4.0 setzen. Hier ist PBI im Vorteil. 😛 Blattlaus hat geschrieben: Piccolino81 hat geschrieben: > Pakete an beliebigen Orten downloadbar (so kann man einen Modem-User noch einfacher mit Paketen versorgen)
Ist auch mit apt kein Problem. Du sagst einfach auf dem schnell angebundenen Rechner "download only" und er wird alle benötigten Pakete runterladen. Die kannst du dann z.B. auf CD brenne und der ohne Internet kann sie auf sein System laden und einfach installieren. Piccolino81 hat geschrieben: > Programme lassen sich einfach wieder entfernen, da lediglich Daten in EINEM einzigen Verzeichnis davon liegen
Ich sehe da keinen Vorteil. Was interessiert es mich, wo die Daten landen? Ich hab einen Paketmanager, dem ich sagen "entferne das" und er löscht alle Dateien die dazu gehören. Ich muss nicht wissen was wohin gehört und ich will es auch garnicht.
Wäre aber im Falle von PBI transparenter. So sehe ich die Applikation und die dazugehörigen libs mit einem einfachen cd und ls! Was PBI somit auch noch zulassen könnte ist, ich kenne PBI nicht, wäre aber dennoch denkbar das es funktioniert, dass jeder User in der Lage ist, spezielle SW nur für Ihn zu installieren, z.B. in /home/$USER/pbi. Ja ich weiß, das geht auch so, allerdings auch mit apt? 😉 Blattlaus hat geschrieben: Piccolino81 hat geschrieben: Das mit dem Mehr-Aufwand, nur weil man die Pakete mit den Abhängigkeiten zusammen verpacken muss, sehe ich ein wenig anders. Ist es nicht eindeutig MEHR Aufwand, wenn der einzelne User (und das sind dann gleich tausende) im Spezialfall selbst versuchen muss die Abhängigkeiten eines gewünschten Programms aufzulösen, anstatt dass das der Entwickler oder Distributor EINMAL pro Paket macht???
Du hast das Konzept von apt nicht verstanden. Der Entwickler (genauer: der Maintainer, der die Pakete herstellt und packt) definiert für jedes Paket: Es braucht das und das und das um zu funktionieren und das Paketmanagment kümmert sich darum diese Abhängigkeiten zu erfüllen. Auch hier hat der User dadurch absolut keinen Aufwand damit. Er sagt dem Paketmanager "instaliier Firefox" und der Paketmanager löst selbstständig und ohne Usereingriff sämtliche abhängigkeiten auf.
Und genau hier sehe ich die dicksten Probleme! Die Maintainer! Die belasten sich, indem sie allerhand Software von anderen in Pakete schnüren, die nur eine gewisse Anzahl von Linux Usern nutzen können, nämlich in unserem Fall, die Ubuntu-User und noch blöder kommts, wenn das Paket nur für eine spezielle Version z.B. Dapper ist. Wenn ich an den Aufwand denke wird mir übel. Was ist falsch daran, das Paketieren dem Software-Entwickler zu überlassen. Oft sieht man auf div. Projekt-Seiten: Download: Windows Exe, OSX DMG, Linux tar.gz. Ja wahnsinn! Selbercompilieren, während Mac-User und Windows-User es einfach haben. Was habe ich getan, dass ich selber kompilieren muss? apt, dpkg, rpm usw. ist alles schön und gut nur leider genügt es eben noch nicht! Gruß Bernd
|
Piccolino81
(Themenstarter)
Anmeldungsdatum: 14. Juli 2005
Beiträge: 184
Wohnort: Freiburg i. Brsg.
|
Hallo zusammen, die meisten von Euch (adun, ralph_ubuntu, Ubunux) übersehen, dass wenn es einmal Abhängigkeiten gibt, diese dann gleich von mehreren 1000 Usern gelöst werden müssen. Damit entsteht ein riesen Aufwand, der (in der Gesamtheit) dem Aufwand eines einzelnen Entwicklers bei weitem "überlegen" ist und damit nicht nur einige LINUX-Interessenten abschreckt, sondern schlicht und einfach im heutigen Zeitalter nicht mehr sein muss. Mir geht es dabei nur um Programme, die eben nicht in den einzelen Repositories auftauchen. Denn nur da könnt ihr ja eben nicht einfach apt-get, synaptic, gdebi, gnome-app-install, etc. verwenden. Klar, solange ihr diese feinen Tools verwenden könnt, habt ihr nur selten Probleme (da auch diese schlussendlich auf apt-get und damit die Repositories "aufsetzen"). Aber wie sieht es aus, wenn lib_xy eben grad nicht in den Repositories verfügbar ist!? Sagt mir jetzt bitte nicht, dass Ihr dann jedes Programm selbst kompilieren würdet. Denn jeder, der schon einmal ein grösseres Programm kompilieren wollte, stand dann vor dem Problem, die Abhängigkeiten erst einmal zu IDENTIFIZIEREN. Falls das nämlich kein Problem wäre, so hätte man das auch schon längst automatisieren können. Wobei dann wären wir vom Thema eher beim Ports-System von BSD oder Emerge bei Gentoo... anderes Thema. Ein weiterer entscheidender Vorteil könnte sein, dass man nicht in jeder Distribution ein anderes Paket-Verwaltungssystem bräuchte, sondern dass man endlich eine Art Standard hätte, an dem sehr viele LINUX-Distributionen profitieren könnten. @Ubunux Ja und nein! Dem jeweiligen Distributor des einzelnen Programm-Paketes ist es dann freigestellt, wie er die Library in sein Paket mit einbindet. Damit lädst Du unter Umständen zwar einzelne Libraries mehrfach runter, sie kämen sich aber nicht in die Quere. Und damit wären wir dann wieder beim Punkt Grösse bzw. Geschwindigkeit - siehe letzer Beitrag von mir!
@Blattlaus Du vermischt leider mehrere Punkte miteinander, weshalb auch ich Dir wieder entgegnen kann, dass ich nicht ganz einverstanden bin, mit dem was Du schreibst. Aber schön der Reihe nach: Solch elementare Libraries wie die der grafischen Darstellung von Programmen (QT, GTK, etc.) wäre - meiner Meinung nach - Aufgabe der LINUX-Distribution, diese mit zu liefern. Das mit dem Downloaden der Pakete und dem einfachen Installieren bei nem Modem-Freund stimmt so leider auch nicht ganz. Du müsstest vorher die CD so modifizieren, dass sie als Paketquelle eingebunden werden kann. Sorry, aber den Aufwand gäbe es bei PBI-Paketen schon mal nicht. Doppelklick auf das Paket (später vielleicht auch mehrere gleichzeitig) und schon wird es installiert. Das mit den Verzeichnissen könnte auch wieder ein grösseres Thema werden. Schon alleine wegen den vielen verschiedenen Verzeichnissen, die für Programm-ICONS verwendet werden. Doch, wie gesagt, das könnte ein eigenständiges Thema werden. Klar, laufen die PBIs nur auf einer bestimmten Auswahl an Distributionen, so wäre es dann auch bei den LINUX-Distributionen - keine Frage. Aber man würde die Distris durch die Arbeit an einem solchen Pakete-System und den daraus resultierenden Nutzen schon einmal enger "zusammen" bringen.
\––- Übrigens, liege ich richtig mit der Vermutung, dass du noch ernsthaft Programmiert hast? Dann würdest du nämlich die Vorteile von Kapselung und Wiederverwendung von Code (=Libaries) einfach durchblicken. \––-
Da liegst Du zum Glück falsch. Nun wären wir an dem Punkt angelangt, an dem ich Dir vorwerfe, dass Du zwei Sachen miteinander vermischt: - Ein Entwickler entwickelt ein Library ohne sich darum zu kümmern, wofür es verwendet wird - das war so und würde auch so bleiben - Ein Programm-Distributor würde sich dann wiederum den Libraries bedienen und gerade das zusammenpacken, was das grössere Programm, wie z.B. Firefox benötigt. Dein Argument, dass also jeder sein eigenes Süppchen kochen würde, wird damit hinfällig. Das Rad würde auch mit einem solchen Pakete-System nicht doppelt und dreifach erfunden - lediglich "verpackt". Doch da bleib ich bei der Überzeugung, dass es mehr Sinn macht, dem User damit entgegen zu kommen. Denn auch Du musst zugeben, dass das Kompilieren von Software einen manchmal ganz schön frustrieren kann - einen LINUX-Neuling schreckt das unter Umständen sofort ab. Gruss Piccolino81
|
ralph_ubuntu
Anmeldungsdatum: 25. Januar 2005
Beiträge: 98
|
Piccolino81 hat geschrieben:
Mir geht es dabei nur um Programme, die eben nicht in den einzelen Repositories auftauchen. Denn nur da könnt ihr ja eben nicht einfach apt-get, synaptic, gdebi, gnome-app-install, etc. verwenden. Klar, solange ihr diese feinen Tools verwenden könnt, habt ihr nur selten Probleme (da auch diese schlussendlich auf apt-get und damit die Repositories "aufsetzen"). Aber wie sieht es aus, wenn lib_xy eben grad nicht in den Repositories verfügbar ist!? Sagt mir jetzt bitte nicht, dass Ihr dann jedes Programm selbst kompilieren würdet. Denn jeder, der schon einmal ein grösseres Programm kompilieren wollte, stand dann vor dem Problem, die Abhängigkeiten erst einmal zu IDENTIFIZIEREN. Falls das nämlich kein Problem wäre, so hätte man das auch schon längst automatisieren können. Wobei dann wären wir vom Thema eher beim Ports-System von BSD oder Emerge bei Gentoo... anderes Thema.
Und schon wieder muss ich dir widersprechen. ;-D 1. gdebi ist ja gerade für Programme gedacht, die nicht in den repositories sind. Einfach das Paket runterladen, doppelklicken und das Program wird inklusive aller Abhängigkeiten installiert. 2. Wenn lib_xy nicht in den repositories ist, dann gibt es mehrere Möglichkeiten dies zu lösen. Zum einen kann derjenige, der das Programm zum Download anbietet dieses ja auch statisch kompilieren, das heißt, lib_xy einfach schon ins deb mitbeilegen. Problem gelöst. Oder er kann ein meta Packet schnüren, bei dem lib_xy eben schon dabei ist. Ich sehe also nachwievor nicht, was durch PBI hier gewonnen würde. Piccolino81 hat geschrieben:
Ein weiterer entscheidender Vorteil könnte sein, dass man nicht in jeder Distribution ein anderes Paket-Verwaltungssystem bräuchte, sondern dass man endlich eine Art Standard hätte, an dem sehr viele LINUX-Distributionen profitieren könnten.
Ich sehe nicht, wie PBI dieses Problem lösen könnte. Dinge wie die LSB scheinen mir da sehr viel sinnvoller, da sie den Realitäten, nämlich, dass es sehr viele unterschiedliche Distributionen gibt, weit eher Rechnung tragen als PBI.
|
Piccolino81
(Themenstarter)
Anmeldungsdatum: 14. Juli 2005
Beiträge: 184
Wohnort: Freiburg i. Brsg.
|
Hallo ralph_ubuntu,
Und schon wieder muss ich dir widersprechen. ;-D 1. gdebi ist ja gerade für Programme gedacht, die nicht in den repositories sind. Einfach das Paket runterladen, doppelklicken und das Program wird inklusive aller Abhängigkeiten installiert. 2. Wenn lib_xy nicht in den repositories ist, dann gibt es mehrere Möglichkeiten dies zu lösen. Zum einen kann derjenige, der das Programm zum Download anbietet dieses ja auch statisch kompilieren, das heißt, lib_xy einfach schon ins deb mitbeilegen. Problem gelöst. Oder er kann ein meta Packet schnüren, bei dem lib_xy eben schon dabei ist. Ich sehe also nachwievor nicht, was durch PBI hier gewonnen würde.
1. gdebi kann nur deshalb die Abhängigkeiten auflösen, weil es sich dem Paket-Verwaltungssystem apt-get bedient. Ergo: Wenn ein Paket nicht in den Repositories ist, kann auch nicht erfolgreich "aufgelöst" werden. 😕 2. Statisches Kompilieren entspricht ja - wie wir mittlerweile zusammen festgestellt haben - am ehesten einem PBI-Paket. Damit wäre die Arbeit schon beim Maintainer (dank berndix2 habe ich endlich das richtige Wort). Warum also kann man das nicht gleich für alle grösseren Programme so lösen? (siehe auch Beitrag von berndix2 !!)
Ich sehe nicht, wie PBI dieses Problem lösen könnte. Dinge wie die LSB scheinen mir da sehr viel sinnvoller, da sie den Realitäten, nämlich, dass es sehr viele unterschiedliche Distributionen gibt, weit eher Rechnung tragen als PBI.
Auszug aus Linux_Standard_Base
Im Laufe der Geschichte von Linux haben sich eine Reihe von verschiedenen Linux-Distributionen entwickelt, die in vielen Details unterschiedliche Ansätze verfolgten (z.B. Software-Paket-Format, Verzeichnisstruktur, Versionen der integrierten Softwarepakete, ... ).
Wir diskutieren hier nicht an der LSB vorbei, sondern befassen uns ja bereits mit zwei der dort enthaltenen Punkte! Wie schon weiter oben gesagt, die Geschichte mit den Verzeichnisstrukturen wäre ein eigenes Thema für sich... Lies Dir auch den Beitrag von berndix2 durch, dann verstehst Du vielleicht eher, worauf ich hinaus will. Denn er hat ein paar sehr wichtige Punkte (z.B. Programme, welche auf unterschiedlichen Library-Versionen basieren) genannt, die mir entgangen waren.
Gruss Piccolino81
|