Lass es mich nochmals zusammenfassen, um den Rahmen nicht zu sprengen.
Ich halte deine Idee eines doppelten Paketsystems für technisch nicht sinnvoll und einen Rückschritt zur derzeitigen Verfahrensweise, Pakete in die Distributionen zu integrieren. Man muss keinen technischen Unsinn umsetzen, nur weil es auf einem anderen verbreiteten System vorgemacht wird. Und man muss ihn erst recht nicht umsetzen, um die Unflexibilität von Umsteigern zu fördern.
Ansätze wie http://backports.debian.org/ oder http://mozilla.debian.net/ (um nur zwei Beispiele zu nennen) welche sich sauber in die Distribution integrieren, halte ich für weitaus sinnvoller.
Deine Idee ist auch nicht neu, es gab und gibt dazu zahlreiche Projekte, keines davon hat sich in den letzten 10 Jahren durchgesetzt: Autopackage, klik, PortableLinuxApps, Zero Install, Listaller
Ich halte deine Idee eines doppelten Paketsystems für technisch nicht sinnvoll und einen Rückschritt zur derzeitigen Verfahrensweise, Pakete in die Distributionen zu integrieren. Man muss keinen technischen Unsinn umsetzen, nur weil es auf einem anderen verbreiteten System vorgemacht wird. Und man muss ihn erst recht nicht umsetzen, um die Unflexibilität von Umsteigern zu fördern.
Gut das ist Dein Standpunkt. Meiner ist das wir ein System brauchen das es auf allen Desktopdistributionen erlaubt das jeder normale Anwender einfach an aktuelle Programmversionen kommt. Und das ohne das er sich groß durch diverse Anleitungen, Foren, Mailinglisten & Co. wühlen muss. Und das ist auf die von mir beschriebene Weise noch am einfachsten und effizientesten umsetzbar und das ohne das neue Programmversionen für jede Distribution neu paketiert werden müssen. Auch kommt es nicht zu Problemen mit den bestehenden Dateisystemen der Distributionen, da das zusätzliche distributionsübergreifende Paketsystem seine Pakete, Bibliotheken etc. unter /opt/apps/... installeirt und auch das nur dann wenn die nötigen Abhängigkeiten nicht bereits im System vorhanden sind.
Ansätze wie http://backports.debian.org/ oder http://mozilla.debian.net/ (um nur zwei Beispiele zu nennen) welche sich sauber in die Distribution integrieren, halte ich für weitaus sinnvoller.
Ja kenne ich, aber ist ein gigantischer Aufwand da distributionsspezifisch. Darüber hinaus harkt es oft an der Geschwindigkeit mit der Programme eingebunden werden und so manches wird gar nicht erst in aktuelleren Versionen eingebunden.
Deine Idee ist auch nicht neu, es gab und gibt dazu zahlreiche Projekte, keines davon hat sich in den letzten 10 Jahren durchgesetzt: Autopackage, klik, PortableLinuxApps, Zero Install, Listaller
Die von dir genannten Ansätze sind alle nicht das was ich als Ansatz skizziert habe. Ich kenne sie alle und habe sie freilich auch alle ausprobiert, nur um dann immer wieder festzustellen das es im Einzelnen andere Ansätze sind.
Aber ich sehe schon das wir da wohl diametral entgegengesetzte Standpunkte vertreten.
Glücklicherweise setzen sich im FOSS-Umfeld dank der dort herrschenden Bedingungen, hauptsächlich innovative und technisch sinnvolle Lösungen durch welche langfristig wartbar sind. Jetzt ist es an dir zu überlegen, warum sich von den zahlreichen (oben genannten) Projekten welche zusammen mit deiner Idee allesamt das selbe Ziel und ähnliche Konzepte verfolgen oder verfolgten, keines durchsetzen konnte.
Ein paralleles Paketsystem kann kein Problem lösen, welches das distributionseigene nicht bereits lösen könnte. Ein paralleles Paketsystem müsste beispielsweise zu jeder Version jeder Distribution den genauen Namen des Paketes jeder einzelnen Anwendung und Bibliothek kennen und zusätzlich müsste es jedes einzelne Paketsystem in jeder eingesetzen Version kennen, um überhaupt in der Lage zu sein die Versionsstände ermitteln und ggf. zusätzliche Systempakete nachinstallieren zu können. Wenn es sich aber so tiel ins System jeder Distribution integrieren muss, dann ist es nur noch ein sehr kleiner Schritt, die zusätzlichen Pakete direkt ins System zu integrieren. Das Zweitsystem ist damit bereits wieder Geschichte, bevor es geboren wurde. Ein zusätzliches Paketsystem löst deshalb keine Probleme, sondern schafft neue indem es die Komplexität erhöht und die Wartbarkeit verringert.
Ansätze wie http://backports.debian.org/ oder http://mozilla.debian.net/ (um nur zwei Beispiele zu nennen) welche sich sauber in die Distribution integrieren, halte ich für weitaus sinnvoller.
Ja kenne ich, aber ist ein gigantischer Aufwand da distributionsspezifisch. Darüber hinaus harkt es oft an der Geschwindigkeit mit der Programme eingebunden werden und so manches wird gar nicht erst in aktuelleren Versionen eingebunden.
Die Pakete sind bereits in Debian SID enthalten, bei zahlreichen Paketen beschränkt sich der Aufwand lediglich auf das Neukompilieren und Paketieren für Stable. Beides zusammen ist mit einem einzelnen Befehl (debuild) erledigt. Der komplette Vorgang besteht aus dem Herunterladen des Quellpaketes aus SID, das Anpassen der Versionsnummer (local-part) und das Neukompilieren+Paketieren, jeder Schritt ist mit einem Befehl erledigt. Der imense Aufwand der mit einem Zweitpaketsystem einhergehen würde, ist nicht ansatzweise vergleichbar.
Bei einem Teil der Pakete sind geringe Anpassungen notwendig oder es müssen weitere Pakete (zumeinst Libraries) ebenfalls für stable gebaut werden. Der Aufwand ist nach wie vor geringer als bei einem Zweitpaketsystem, bei dem jede Abhängigkeit zusätzlich zur Verfügung gestellt werden muss.
Bei einem weiteren Teil der Pakete wären die Abhängigkeiten oder Änderungen so umfangreich, dass eine Portierung unter vernünftigen Gesichtspunkten nicht sinvoll erscheint. Ebenso wie es nicht sinnvoll wäre, über ein Zweitpaketsystem ein Großteil des Systems auszutausschen bzw. parallel zu instalieren.
Linux ist ein System zum Mitmachen und keines um sich ausschließlich berieseln zu lassen. Jeder, auch du bist herzlich dazu eingeladen, von dieser Möglichkeit gebrauch zu machen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 07. Mai 2012 um 19:42.
Es gibt Distributionen (Moon OS), die vieles komplett anders machen, aber das ist immer mit Verrenkungen verbunden und wird wohl kaum "Mainstream".
Warum denkt eigentlich keiner an Virtualisierung?
Vorausgesetzt, die Ressourcen sind vorhanden, ist es doch inzwischen ein Leichtes, bei unbedingt notwendigem Einsatz einer bestimmten "ganz neuen" Applikation eben ein minimal eingerichtetes aktuelles System für diese Applikationin einer VM zu installieren. Komfortabel geht das mit VirtualBox, Vmware Player/Server oder Redhats Virtual Machine Manager mit Qemu/KVM.
Damit bleibt das Hautsystem sauber, und das Ziel ist trotzdem erreicht. Mit dem Nebeneffekt, die neueste oder eine andere Distri gleich mal durchtesten zu können.
und man kann auch gleich noch viel mehr Systeme pflegen (oder vergammeln lassen) pro Anwendung pflegt man nicht nur diese sondern auch die Libs den Kernel und wenn das nicht reicht auch noch eine eigene Virtualisierung denn zumindest Qemu lässt sich ja wunderbar parallel zu den anderen betreiben.
Lass es mich nochmals zusammenfassen, um den Rahmen nicht zu sprengen.
Ich halte deine Idee eines doppelten Paketsystems für technisch nicht sinnvoll und einen Rückschritt zur derzeitigen Verfahrensweise, Pakete in die Distributionen zu integrieren. Man muss keinen technischen Unsinn umsetzen, nur weil es auf einem anderen verbreiteten System vorgemacht wird. Und man muss ihn erst recht nicht umsetzen, um die Unflexibilität von Umsteigern zu fördern.
Ansätze wie http://backports.debian.org/ oder http://mozilla.debian.net/ (um nur zwei Beispiele zu nennen) welche sich sauber in die Distribution integrieren, halte ich für weitaus sinnvoller.
Deine Idee ist auch nicht neu, es gab und gibt dazu zahlreiche Projekte, keines davon hat sich in den letzten 10 Jahren durchgesetzt: Autopackage, klik, PortableLinuxApps, Zero Install, Listaller
Gut das ist Dein Standpunkt. Meiner ist das wir ein System brauchen das es auf allen Desktopdistributionen erlaubt das jeder normale Anwender einfach an aktuelle Programmversionen kommt. Und das ohne das er sich groß durch diverse Anleitungen, Foren, Mailinglisten & Co. wühlen muss. Und das ist auf die von mir beschriebene Weise noch am einfachsten und effizientesten umsetzbar und das ohne das neue Programmversionen für jede Distribution neu paketiert werden müssen. Auch kommt es nicht zu Problemen mit den bestehenden Dateisystemen der Distributionen, da das zusätzliche distributionsübergreifende Paketsystem seine Pakete, Bibliotheken etc. unter /opt/apps/... installeirt und auch das nur dann wenn die nötigen Abhängigkeiten nicht bereits im System vorhanden sind.
Ja kenne ich, aber ist ein gigantischer Aufwand da distributionsspezifisch. Darüber hinaus harkt es oft an der Geschwindigkeit mit der Programme eingebunden werden und so manches wird gar nicht erst in aktuelleren Versionen eingebunden.
Die von dir genannten Ansätze sind alle nicht das was ich als Ansatz skizziert habe. Ich kenne sie alle und habe sie freilich auch alle ausprobiert, nur um dann immer wieder festzustellen das es im Einzelnen andere Ansätze sind.
Aber ich sehe schon das wir da wohl diametral entgegengesetzte Standpunkte vertreten.
Glücklicherweise setzen sich im FOSS-Umfeld dank der dort herrschenden Bedingungen, hauptsächlich innovative und technisch sinnvolle Lösungen durch welche langfristig wartbar sind. Jetzt ist es an dir zu überlegen, warum sich von den zahlreichen (oben genannten) Projekten welche zusammen mit deiner Idee allesamt das selbe Ziel und ähnliche Konzepte verfolgen oder verfolgten, keines durchsetzen konnte.
Ein paralleles Paketsystem kann kein Problem lösen, welches das distributionseigene nicht bereits lösen könnte. Ein paralleles Paketsystem müsste beispielsweise zu jeder Version jeder Distribution den genauen Namen des Paketes jeder einzelnen Anwendung und Bibliothek kennen und zusätzlich müsste es jedes einzelne Paketsystem in jeder eingesetzen Version kennen, um überhaupt in der Lage zu sein die Versionsstände ermitteln und ggf. zusätzliche Systempakete nachinstallieren zu können. Wenn es sich aber so tiel ins System jeder Distribution integrieren muss, dann ist es nur noch ein sehr kleiner Schritt, die zusätzlichen Pakete direkt ins System zu integrieren. Das Zweitsystem ist damit bereits wieder Geschichte, bevor es geboren wurde.
Ein zusätzliches Paketsystem löst deshalb keine Probleme, sondern schafft neue indem es die Komplexität erhöht und die Wartbarkeit verringert.
Die Pakete sind bereits in Debian SID enthalten, bei zahlreichen Paketen beschränkt sich der Aufwand lediglich auf das Neukompilieren und Paketieren für Stable. Beides zusammen ist mit einem einzelnen Befehl (debuild) erledigt. Der komplette Vorgang besteht aus dem Herunterladen des Quellpaketes aus SID, das Anpassen der Versionsnummer (local-part) und das Neukompilieren+Paketieren, jeder Schritt ist mit einem Befehl erledigt. Der imense Aufwand der mit einem Zweitpaketsystem einhergehen würde, ist nicht ansatzweise vergleichbar.
Bei einem Teil der Pakete sind geringe Anpassungen notwendig oder es müssen weitere Pakete (zumeinst Libraries) ebenfalls für stable gebaut werden. Der Aufwand ist nach wie vor geringer als bei einem Zweitpaketsystem, bei dem jede Abhängigkeit zusätzlich zur Verfügung gestellt werden muss.
Bei einem weiteren Teil der Pakete wären die Abhängigkeiten oder Änderungen so umfangreich, dass eine Portierung unter vernünftigen Gesichtspunkten nicht sinvoll erscheint. Ebenso wie es nicht sinnvoll wäre, über ein Zweitpaketsystem ein Großteil des Systems auszutausschen bzw. parallel zu instalieren.
Linux ist ein System zum Mitmachen und keines um sich ausschließlich berieseln zu lassen. Jeder, auch du bist herzlich dazu eingeladen, von dieser Möglichkeit gebrauch zu machen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 07. Mai 2012 um 19:42.Volle Zustimmung.
Es gibt Distributionen (Moon OS), die vieles komplett anders machen, aber das ist immer mit Verrenkungen verbunden und wird wohl kaum "Mainstream".
Warum denkt eigentlich keiner an Virtualisierung?
Vorausgesetzt, die Ressourcen sind vorhanden, ist es doch inzwischen ein Leichtes, bei unbedingt notwendigem Einsatz einer bestimmten "ganz neuen" Applikation eben ein minimal eingerichtetes aktuelles System für diese Applikationin einer VM zu installieren. Komfortabel geht das mit VirtualBox, Vmware Player/Server oder Redhats Virtual Machine Manager mit Qemu/KVM.
Damit bleibt das Hautsystem sauber, und das Ziel ist trotzdem erreicht.
Mit dem Nebeneffekt, die neueste oder eine andere Distri gleich mal durchtesten zu können.
und man kann auch gleich noch viel mehr Systeme pflegen (oder vergammeln lassen) pro Anwendung pflegt man nicht nur diese sondern auch die Libs den Kernel und wenn das nicht reicht auch noch eine eigene Virtualisierung denn zumindest Qemu lässt sich ja wunderbar parallel zu den anderen betreiben.