ich weiss nicht ob Du meinen Gedanken ganz nachvollzogen hast. Ich meine"vorerst" ein 2.PaketSystem - welches unabhängig von der Basis-Distro läuft. Dieses würde dann erstmal aus sicht der Distro als "normales" programm installiert (wie zb vim/mc). Über dieses 2.Paketsystem lassen sich dann Desktop-Programme installieren/aktualisieren/updates planen usw usf.
Dieses 2.Paketsystem verstreut dann nicht mehr Dateien über dieverse Ordner - hier wird ein "Standard-Archiv-System" geschaffem, wo idealerweise alle Dateien in einer File hinterlegt sind (ggf "mountbar" oder ähnlich). Möglichst einfach händelbar - so das das System Out-Of-Box ohne grosses lesen einer Howto für jeden intuvitiv selbsterklärend ist.
Wenn man das weiterdenkt könnte man im prinzip - wenn man das Performance-Technisch erschlagen bekommt - dadrüber auch ganze Desktop-Umegbungen wie KDE/Gnome/Xfce aktualisieren. Die Programme müssten damit "WEITESGEHEND" statisch kompiliert sein. Bei Siecherheitsproblemen wär es dann halt aufgabe von den VLC/KDE/BLA Projekt-Maintainern ihre Pakete zu aktualisieren. Speichertechnisch soltle das keine Rolle spielen, da man 1GB heutzutage hinterhergeschmissen bekommt.
>> Man kann weder von den Distributionen des alten Systems verlangen dass sie auf das neue System, noch von den anderen verlangen nun auf das alte System wechseln.
Das hat doch dann nur vorteile - der Distributor brauch sich zb nicht mehr um backports kümmern. Der Anwender kann flexibel seine Produkte aktualisieren, ohne auf den Distributor angewisen zu sein. Damit kann der Distributor letztlich sogar Programme auslagern, und muss sich selbst nicht mehr dadrum kümmern. Ein solches Paket-Tool könnte doch acuh Werkzeuge haben um das "fertige" Binary-Programm in eine standard-Umgeundg fest ins System einzubetten (inkl Program-Root-Verzeichnis). Und wenn eine $DISTRO das Paketsystem nicht verwenden will - lässt sies ebend, der anwender kann sich ggf selbst das System einrichten (wenn ers dann wünscht). - diejenigen die ein klassisches "Stabiles System" verwenden wollen, vberwenden entsprechendes System einfach nicht.
Für die Projekt-Entwickler (VLC/Kdevelop und Co) hat es den vorteil das sie Distro-Übergreifend ihre Programme zur Verfügung stellen jkönnen, und damit erheblich schneller ihre "tollen Programme" verbreiten können.
>> Ich selbst bin mit dem Rolling-Release von Gentoo aber ganz glücklich,
Ja, aber das ist ebend neben Arch die Ausnahme - und wer nicht alles manuell definieren will, sondern schnell ein System installieren will (für Lieschen Müller), der nimmt kein Gentoo. Ausserdem - wenn du mal PHP/MySQL compilierst, und später dann (aus welchen gruenden auch immer) MySQL deinstallierst und eine vorherige Version installierst - funktioniert PHP nicht mehr weil dort auf die falschen LIBS verwiesen wird - jedenfalls war das noch vor ca. 3Jahren bei Gentoo der Fall.
Aber ohne das ich jetzt die OPverlay-Technik im Detail kenne - im Grunde wär das ja ein "übergestülptes" Distroübergreifendes Paketsystem.
Also von zwei Paketsystemen auf einem System halte ich nicht viel. Da würde von vielen Leuten sehr schnell die Frage aufkommen, warum sich das nicht mit einem System machen lässt. Mir wären zwei Paketsysteme zu umständlich. Dann doch lieber ein Paketsystem, welches auch mit vielen Repos/Overlays (oder auch etwas ähnliches) zurecht kommt.
>> Ja, aber das ist ebend neben Arch die Ausnahme - und wer nicht alles manuell definieren will, sondern schnell ein System installieren will (für Lieschen Müller), der nimmt kein Gentoo.
War nun nicht so gemeint, dass jeder gleich Gentoo nehmen müsste. Das Rolling-Release-Prinzip lässt sich auch genauso gut bei binären Distributionen anwenden. Nur macht es kaum eine Distribution, warum auch immer.
>> Ausserdem - wenn du mal PHP/MySQL compilierst, und später dann (aus welchen gruenden auch immer) MySQL deinstallierst und eine vorherige Version installierst - funktioniert PHP nicht mehr weil dort auf die falschen LIBS verwiesen wird - jedenfalls war das noch vor ca. 3Jahren bei Gentoo der Fall.
Ja, früher gab es das Problem, dass wenn man ein Programm upgedatet hat, man auch alle anderen Programme (automatisch mit revdep-rebuild) an die neue Lib anpassen bzw. neu kompilieren musste. Wenn man das nicht gemacht hat, bekam man spätestens mit dem Start des entsprechenden Programms einen Fehler auf nicht mehr vorhandene Libs.
Aber heute ist das kein Problem mehr. Mit Portage 2.2 und dem "preserved-libs" Feature, werden die Libs der alten Programme so lange behalten, bis kein anderes Programm mehr davon abhängt. Also Sprich bis man die anderen Programme dann auch irgendwann aktualisiert hat. Dabei behält Portage aber nur die Libs auf der Festplatte, alles andere von der alten Version wird gelöscht. Sollte eine alte Lib nicht mehr benötigt werden, löscht Portage diese Lib dann automatisch. Man bekommt nach einem "emerge" dann auch einen Hinweis mit einer Liste, wie viele alte Libs auf dem System noch von welchen Programmen verwendet werden. Und mit dem neuen Feature der "Sets" kann man Portage veranlassen, all diese Programme zu aktualisieren (emerge -av @preserved-rebuild). Also diese Probleme sind schon seit 2008 Vergangenheit, zumindest mit der 2.2
>> Da würde von vielen Leuten sehr schnell die Frage aufkommen, warum sich das nicht mit einem System machen lässt.
Nur das jede Distro ihr eigenes System entwickelt, und damit selbst jedwede Version zur Verfügung stellen muss. Das kann verständlicherweise nicht jede Distro erledigen. Das würde dann in 5Jahren bei Debian6 die Frage aufwerfen, wozu jetzt noch VLC für Debian6 zur Verfügung stellen, wenn wir doch bei Debian8 angekommen sind. Wer updaten will kann sich kostenlos Debian8 installieren. Und ebend das würde man durch ein "unabhängiges" System unterbinden können. Damit könnten Programme langzeitstabil für 5-10 Jahre angeboten werden, so wie das unter Windows ebenfalls "weitesgehend" möglich ist. Wenn zum schluss 5% der Programme runterfallen - dann ist das an der Stelle dann halt Pech für diese... - es wäre auf jedenfall ein gefühlt grosser vorteil für den einfachen Enduser...
Das Paradebeispiel für statisch kompilierte Programme ist übrigens OpenOffice bzw. soffice. Siehe hierzu u.a..: http://www.little-idiot.de/linuxsolutionguide/doku-libraries.htm Ich zitiere: "$ whereis soffice soffice: /usr/bin/soffice $ ldd /usr/bin/soffice not a dynamic executable" Das, was Du forderst, gibt es also schon, ausgerechnet bei einem der wichtigsten Programme, die unter Linux gerne benutzt werden.
Mit Xmms könnte man ganz genauso verfahren. Was libxmms alles so an Libs bräuchte, ist im obigen Text auch aufgeführt.
Das gibt es bei wenigen "externen" Programmen... - und das ganze auch nicht schön eingebettet... Wenn Du das ganze mal KDevelop, oder php versuchst, wirst Du merken das das ganze nicht mehr ganz trivial für den Endanwneder wird...
LOL! Schön, dass du Anleitungen abtippen kannst. Die Schlussfolgerungen sind aber komplett falsch. /usr/bin/soffice ist ein Shell-Skript, das die Umgebung einrichtet. OpenOffice besteht aus zahlreichen Shared Libs.
Eine Frage an den Experten (vielleicht hast Du dieses Problem ja schon gelöst): Weißt Du, wie man Xmms kompilieren muß, damit er z.B. unter neuesten Distros wie Debian Squeeze funktioniert? Wenigstens gtk 1.2, glib 1.2 müßte man wohl selber in dieses Paket hineinpacken, da es mittlerweile in den meisten Distros fehlt. Nur, wie erstellt man ein solches, weitgehend "autarkes" Softwarepaket? Ich denke, dass war eine der latenten Fragen in diesem Thread, so von wegen Support für alte und älteste, aber liebgewonnene Linuxanwendungen.
Nimm Audacious, da gibt es sogar ein Xmms-Theme. Es macht einfach keinen Sinn, Software voller Bugs und Sicherheitslücken (bei Xmms sind es mittlerweile um die 30) paketieren zu wollen. Denn niemand wartet diese Software, niemand. Wenn Du gar nicht weiter weißt, dann nimm eine Distro wie Slackware 13.1 oder OpenSuse 11.2. Hier ist Xmms noch dabei, bei OpenSuse 11.2 allerdings nur über Packman. Aus OpenSuse 11.3 ist Xmms mittlerweile auch verschwunden. Es ist vorbei. Selbst die Xmms-Entwickler haben Xmms (als "Xmms1") schon vor langer Zeit aufgegeben.
>> Nimm Audacious, da gibt es sogar ein Xmms-Theme. Leider werden hier klassische Winamp-Themes mit unter falsch dargestellt. Die Default-Themes finde ich insbesondere bei "doppelter" Darstellungsgröße sehr unansehlich. Hier ein Winamp/XMMS-Theme das ich persönlich sehr angenehm empfinde, und auch dauerhaft weiter verwenden möchte: http://www.lingox.de/_ctx/xmms/
>>Es macht einfach keinen Sinn, Software voller Bugs und Sicherheitslücken (bei Xmms sind es mittlerweile um die 30) paketieren zu wollen. >>Es ist vorbei.
Das mag sein. Wenn eine Software aber weitesgehend LOKAL eingesetzt wird, und keine adequate Alternativen bestehen ist es aus Anwendersicht aber schon verständlich das User möglichst nicht auf ihre über ein Jahrzehnt liebgewonnene Software verzichten wollen. Drum finde ich solche Aussagen auch unpassend !
Und wenn schon 30bekannte Probleme existieren - warum, setzt sich nicht einer der alten Source-Entwickler mal 1-2 Wochenenden hin, und fixed die Probleme soweit es möglich ist. XMMS zeigt wunderbar das es immer noch hunderte/tausende Fans da draussen gibt, die diese Software wirklich mögen und genauso weiter verwenden wollen. Wenns nach mir geht die nächsten 50 Jahre - jedenfalls solang bis es etwas vergleichbares oder besseres gibt (subjektiv für mich empfunden. Und nein Amarok, Totem, Kaffeine Exaile und und und - mag ich ebend nicht). Für den Service dauerhaft die nächsten 10Jahre für alle neuen Ubuntu32/64, Debian32/64 und SuSE32/64-Versionen ein compilat erstellt zu bekommen (deb,src-deb,rpm, src-rpm) wär ich sogar durchaus bereit einen Betrag einer durchschnittlichen Desktop-Software zu bezahlen....
Alternativ wär ich genauso bereit dafür zu Zahlen das PLS (entfernte listen, zb Digital-Importet), doppelte darstellungsgröße der Skins sowie MOD/S3M-Unterstuetzung für QMMP nachgeliefert würde - dann wäre das eine alternative die auch duirchweg einsetzbar ist.
Ansich sollte man das Projekt forken und für 20eurs nen compilat anbieten....
Ich wette da hätte man über die jahre schnell mal 5.000eurs fürs "nichtstun" (ausser irgentwie die fucking srcen zu compilieren und paketieren) verdient ...
aber dann würde hier warscheinlich die leute hier alla ubuntu aufschreien, das man geld mit anderer leute arbeit verdient... dabei wären die zahlenden user am schluss happy das sie endlich für "2 mittagessen im jahr" ihr lieblingsprogramm wieder verwenden können....
Oha... die neue QMMP-Version 0.4.x hat alle von mir gewünschten Features :-) Ein Riesenlob an die Entwickler - ich bin die nächsten Jahre happy !!!! !!!!!
"Wenn eine Software aber weitesgehend LOKAL eingesetzt wird" Xmms kann Internet-Radiostationen empfangen, von daher besteht also die Möglichkeit eines Internetzugriffs.
"warum, setzt sich nicht einer der alten Source-Entwickler mal 1-2 Wochenenden hin, und fixed die Probleme soweit es möglich ist" Eine gute Frage.
IMO hilft nur das "Krachschlagen" innerhalb einer Distro. Bei Slackware hat das geklappt. Zuerst wurde Xmms entfernt und über ein Jahr später wieder in Slackware eingefügt:
Da P.V. allerdings meines Wissens vom Verkauf seiner offiziellen CDs und DVDs lebt, dürfte er, falls solche Käufer sich "beschwert" haben sollten, hier durchaus anders reagieren als andere Distros. Aber wie schon gesagt: Von meiner Seite ist das reine Spekulation.
Mittlerweile wurde auch wenigstens ein Xmms-Bug gefixt, der "Double Size"-Bug nämlich: "xap/xmms-1.2.11-i486-2.tgz: Patched to fix the doublesize option. Thanks to Patryk Krawaczynski, Keith Richie, and Catalin Tomozei for all sending in the same working patch. Honorable mentions to LukenShiro, misiu, and Willy Sudiarto Raharjo for proposing "XLIB_SKIP_ARGB_VISUALS=1 xmms" as another possible workaround for the problem." (siehe ChangeLog.txt aus Slackware 12.2)
Du hast oben geschrieben, dass Du u.a. gerne Winamp 2.x benutzt. Der letzte Test mit Winamp 2.x wurde zwar noch unter Wine 0.9.9 durchgeführt, aber vielleicht läuft Winamp 2.x ja reibungslos unter Deiner gerade benutzten Linux-Distro: http://appdb.winehq.org/objectManager.php?sClass=version&iId=5478
Hallo,
ich weiss nicht ob Du meinen Gedanken ganz nachvollzogen hast. Ich meine"vorerst" ein 2.PaketSystem - welches unabhängig von der Basis-Distro läuft. Dieses würde dann erstmal aus sicht der Distro als "normales" programm installiert (wie zb vim/mc). Über dieses 2.Paketsystem lassen sich dann Desktop-Programme installieren/aktualisieren/updates planen usw usf.
Dieses 2.Paketsystem verstreut dann nicht mehr Dateien über dieverse Ordner - hier wird ein "Standard-Archiv-System" geschaffem, wo idealerweise alle Dateien in einer File hinterlegt sind (ggf "mountbar" oder ähnlich). Möglichst einfach händelbar - so das das System Out-Of-Box ohne grosses lesen einer Howto für jeden intuvitiv selbsterklärend ist.
Wenn man das weiterdenkt könnte man im prinzip - wenn man das Performance-Technisch erschlagen bekommt - dadrüber auch ganze Desktop-Umegbungen wie KDE/Gnome/Xfce aktualisieren. Die Programme müssten damit "WEITESGEHEND" statisch kompiliert sein. Bei Siecherheitsproblemen wär es dann halt aufgabe von den VLC/KDE/BLA Projekt-Maintainern ihre Pakete zu aktualisieren. Speichertechnisch soltle das keine Rolle spielen, da man 1GB heutzutage hinterhergeschmissen bekommt.
==================================================
>> Man kann weder von den Distributionen des alten Systems verlangen dass sie auf das neue System, noch von den anderen verlangen nun auf das alte System wechseln.
Das hat doch dann nur vorteile - der Distributor brauch sich zb nicht mehr um backports kümmern. Der Anwender kann flexibel seine Produkte aktualisieren, ohne auf den Distributor angewisen zu sein. Damit kann der Distributor letztlich sogar Programme auslagern, und muss sich selbst nicht mehr dadrum kümmern. Ein solches Paket-Tool könnte doch acuh Werkzeuge haben um das "fertige" Binary-Programm in eine standard-Umgeundg fest ins System einzubetten (inkl Program-Root-Verzeichnis).
Und wenn eine $DISTRO das Paketsystem nicht verwenden will - lässt sies ebend, der anwender kann sich ggf selbst das System einrichten (wenn ers dann wünscht). - diejenigen die ein klassisches "Stabiles System" verwenden wollen, vberwenden entsprechendes System einfach nicht.
Für die Projekt-Entwickler (VLC/Kdevelop und Co) hat es den vorteil das sie Distro-Übergreifend ihre Programme zur Verfügung stellen jkönnen, und damit erheblich schneller ihre "tollen Programme" verbreiten können.
==================================================
>> Ich selbst bin mit dem Rolling-Release von Gentoo aber ganz glücklich,
Ja, aber das ist ebend neben Arch die Ausnahme - und wer nicht alles manuell definieren will, sondern schnell ein System installieren will (für Lieschen Müller), der nimmt kein Gentoo. Ausserdem - wenn du mal PHP/MySQL compilierst, und später dann (aus welchen gruenden auch immer) MySQL deinstallierst und eine vorherige Version installierst - funktioniert PHP nicht mehr weil dort auf die falschen LIBS verwiesen wird - jedenfalls war das noch vor ca. 3Jahren bei Gentoo der Fall.
Aber ohne das ich jetzt die OPverlay-Technik im Detail kenne - im Grunde wär das ja ein "übergestülptes" Distroübergreifendes Paketsystem.
===================================================
Gruß
Andre
Also von zwei Paketsystemen auf einem System halte ich nicht viel. Da würde von vielen Leuten sehr schnell die Frage aufkommen, warum sich das nicht mit einem System machen lässt. Mir wären zwei Paketsysteme zu umständlich. Dann doch lieber ein Paketsystem, welches auch mit vielen Repos/Overlays (oder auch etwas ähnliches) zurecht kommt.
>> Ja, aber das ist ebend neben Arch die Ausnahme - und wer nicht alles manuell definieren will, sondern schnell ein System installieren will (für Lieschen Müller), der nimmt kein Gentoo.
War nun nicht so gemeint, dass jeder gleich Gentoo nehmen müsste. Das Rolling-Release-Prinzip lässt sich auch genauso gut bei binären Distributionen anwenden. Nur macht es kaum eine Distribution, warum auch immer.
>> Ausserdem - wenn du mal PHP/MySQL compilierst, und später dann (aus welchen gruenden auch immer) MySQL deinstallierst und eine vorherige Version installierst - funktioniert PHP nicht mehr weil dort auf die falschen LIBS verwiesen wird - jedenfalls war das noch vor ca. 3Jahren bei Gentoo der Fall.
Ja, früher gab es das Problem, dass wenn man ein Programm upgedatet hat, man auch alle anderen Programme (automatisch mit revdep-rebuild) an die neue Lib anpassen bzw. neu kompilieren musste. Wenn man das nicht gemacht hat, bekam man spätestens mit dem Start des entsprechenden Programms einen Fehler auf nicht mehr vorhandene Libs.
Aber heute ist das kein Problem mehr. Mit Portage 2.2 und dem "preserved-libs" Feature, werden die Libs der alten Programme so lange behalten, bis kein anderes Programm mehr davon abhängt. Also Sprich bis man die anderen Programme dann auch irgendwann aktualisiert hat. Dabei behält Portage aber nur die Libs auf der Festplatte, alles andere von der alten Version wird gelöscht. Sollte eine alte Lib nicht mehr benötigt werden, löscht Portage diese Lib dann automatisch. Man bekommt nach einem "emerge" dann auch einen Hinweis mit einer Liste, wie viele alte Libs auf dem System noch von welchen Programmen verwendet werden. Und mit dem neuen Feature der "Sets" kann man Portage veranlassen, all diese Programme zu aktualisieren (emerge -av @preserved-rebuild). Also diese Probleme sind schon seit 2008 Vergangenheit, zumindest mit der 2.2
>> Da würde von vielen Leuten sehr schnell die Frage aufkommen, warum sich das nicht mit einem System machen lässt.
Nur das jede Distro ihr eigenes System entwickelt, und damit selbst jedwede Version zur Verfügung stellen muss. Das kann verständlicherweise nicht jede Distro erledigen. Das würde dann in 5Jahren bei Debian6 die Frage aufwerfen, wozu jetzt noch VLC für Debian6 zur Verfügung stellen, wenn wir doch bei Debian8 angekommen sind. Wer updaten will kann sich kostenlos Debian8 installieren. Und ebend das würde man durch ein "unabhängiges" System unterbinden können. Damit könnten Programme langzeitstabil für 5-10 Jahre angeboten werden, so wie das unter Windows ebenfalls "weitesgehend" möglich ist. Wenn zum schluss 5% der Programme runterfallen - dann ist das an der Stelle dann halt Pech für diese... - es wäre auf jedenfall ein gefühlt grosser vorteil für den einfachen Enduser...
Das Paradebeispiel für statisch kompilierte Programme ist übrigens OpenOffice bzw. soffice.
Siehe hierzu u.a..:
http://www.little-idiot.de/linuxsolutionguide/doku-libraries.htm
Ich zitiere:
"$ whereis soffice
soffice: /usr/bin/soffice
$ ldd /usr/bin/soffice
not a dynamic executable"
Das, was Du forderst, gibt es also schon, ausgerechnet bei einem der wichtigsten Programme, die unter Linux gerne benutzt werden.
Mit Xmms könnte man ganz genauso verfahren. Was libxmms alles so an Libs bräuchte, ist im obigen Text auch aufgeführt.
Das gibt es bei wenigen "externen" Programmen... - und das ganze auch nicht schön eingebettet...
Wenn Du das ganze mal KDevelop, oder php versuchst, wirst Du merken das das ganze nicht mehr ganz trivial für den Endanwneder wird...
LOL! Schön, dass du Anleitungen abtippen kannst. Die Schlussfolgerungen sind aber komplett falsch. /usr/bin/soffice ist ein Shell-Skript, das die Umgebung einrichtet. OpenOffice besteht aus zahlreichen Shared Libs.
Eine Frage an den Experten (vielleicht hast Du dieses Problem ja schon gelöst):
Weißt Du, wie man Xmms kompilieren muß, damit er z.B. unter neuesten Distros wie Debian Squeeze funktioniert?
Wenigstens gtk 1.2, glib 1.2 müßte man wohl selber in dieses Paket hineinpacken, da es mittlerweile in den meisten Distros fehlt.
Nur, wie erstellt man ein solches, weitgehend "autarkes" Softwarepaket?
Ich denke, dass war eine der latenten Fragen in diesem Thread, so von wegen Support für alte und älteste, aber liebgewonnene Linuxanwendungen.
Nimm Audacious, da gibt es sogar ein Xmms-Theme.
Es macht einfach keinen Sinn, Software voller Bugs und Sicherheitslücken (bei Xmms sind es mittlerweile um die 30) paketieren zu wollen.
Denn niemand wartet diese Software, niemand.
Wenn Du gar nicht weiter weißt, dann nimm eine Distro wie Slackware 13.1 oder OpenSuse 11.2. Hier ist Xmms noch dabei, bei OpenSuse 11.2 allerdings nur über Packman. Aus OpenSuse 11.3 ist Xmms mittlerweile auch verschwunden.
Es ist vorbei.
Selbst die Xmms-Entwickler haben Xmms (als "Xmms1") schon vor langer Zeit aufgegeben.
>> Nimm Audacious, da gibt es sogar ein Xmms-Theme.
Leider werden hier klassische Winamp-Themes mit unter falsch dargestellt. Die Default-Themes finde ich insbesondere bei "doppelter" Darstellungsgröße sehr unansehlich. Hier ein Winamp/XMMS-Theme das ich persönlich sehr angenehm empfinde, und auch dauerhaft weiter verwenden möchte: http://www.lingox.de/_ctx/xmms/
>>Es macht einfach keinen Sinn, Software voller Bugs und Sicherheitslücken (bei Xmms sind es mittlerweile um die 30) paketieren zu wollen.
>>Es ist vorbei.
Das mag sein. Wenn eine Software aber weitesgehend LOKAL eingesetzt wird, und keine adequate Alternativen bestehen ist es aus Anwendersicht aber schon verständlich das User möglichst nicht auf ihre über ein Jahrzehnt liebgewonnene Software verzichten wollen. Drum finde ich solche Aussagen auch unpassend !
Und wenn schon 30bekannte Probleme existieren - warum, setzt sich nicht einer der alten Source-Entwickler mal 1-2 Wochenenden hin, und fixed die Probleme soweit es möglich ist. XMMS zeigt wunderbar das es immer noch hunderte/tausende Fans da draussen gibt, die diese Software wirklich mögen und genauso weiter verwenden wollen. Wenns nach mir geht die nächsten 50 Jahre - jedenfalls solang bis es etwas vergleichbares oder besseres gibt (subjektiv für mich empfunden. Und nein Amarok, Totem, Kaffeine Exaile und und und - mag ich ebend nicht).
Für den Service dauerhaft die nächsten 10Jahre für alle neuen Ubuntu32/64, Debian32/64 und SuSE32/64-Versionen ein compilat erstellt zu bekommen (deb,src-deb,rpm, src-rpm) wär ich sogar durchaus bereit einen Betrag einer durchschnittlichen Desktop-Software zu bezahlen....
Alternativ wär ich genauso bereit dafür zu Zahlen das PLS (entfernte listen, zb Digital-Importet), doppelte darstellungsgröße der Skins sowie MOD/S3M-Unterstuetzung für QMMP nachgeliefert würde - dann wäre das eine alternative die auch duirchweg einsetzbar ist.
Ansich sollte man das Projekt forken und für 20eurs nen compilat anbieten....
Ich wette da hätte man über die jahre schnell mal 5.000eurs fürs "nichtstun" (ausser irgentwie die fucking srcen zu compilieren und paketieren) verdient ...
aber dann würde hier warscheinlich die leute hier alla ubuntu aufschreien, das man geld mit anderer leute arbeit verdient... dabei wären die zahlenden user am schluss happy das sie endlich für "2 mittagessen im jahr" ihr lieblingsprogramm wieder verwenden können....
Oha... die neue QMMP-Version 0.4.x hat alle von mir gewünschten Features
:-)
Ein Riesenlob an die Entwickler - ich bin die nächsten Jahre happy !!!! !!!!!
"Wenn eine Software aber weitesgehend LOKAL eingesetzt wird"
Xmms kann Internet-Radiostationen empfangen, von daher besteht also die Möglichkeit eines Internetzugriffs.
"warum, setzt sich nicht einer der alten Source-Entwickler mal 1-2 Wochenenden hin, und fixed die Probleme soweit es möglich ist"
Eine gute Frage.
IMO hilft nur das "Krachschlagen" innerhalb einer Distro.
Bei Slackware hat das geklappt. Zuerst wurde Xmms entfernt und über ein Jahr später wieder in Slackware eingefügt:
http://slackblogs.blogspot.com/2008/09/xmms-re-added.html
Über die Gründe kann ich nur mutmaßen.
Da P.V. allerdings meines Wissens vom Verkauf seiner offiziellen CDs und DVDs lebt, dürfte er, falls solche Käufer sich "beschwert" haben sollten, hier durchaus anders reagieren als andere Distros. Aber wie schon gesagt: Von meiner Seite ist das reine Spekulation.
Mittlerweile wurde auch wenigstens ein Xmms-Bug gefixt, der "Double Size"-Bug nämlich:
"xap/xmms-1.2.11-i486-2.tgz: Patched to fix the doublesize option. Thanks to Patryk Krawaczynski, Keith Richie, and Catalin Tomozei for all sending in the same working patch. Honorable mentions to LukenShiro, misiu, and Willy Sudiarto Raharjo for proposing "XLIB_SKIP_ARGB_VISUALS=1 xmms" as another possible workaround for the problem."
(siehe ChangeLog.txt aus Slackware 12.2)
Du hast oben geschrieben, dass Du u.a. gerne Winamp 2.x benutzt.
Der letzte Test mit Winamp 2.x wurde zwar noch unter Wine 0.9.9 durchgeführt, aber vielleicht läuft Winamp 2.x ja reibungslos unter Deiner gerade benutzten Linux-Distro:
http://appdb.winehq.org/objectManager.php?sClass=version&iId=5478
Danke - aber wie ich vorhin festgestellt hab ...
QMMP ist mit v0.4 eine vollwertige XMMS/Winamp2-Alternative geworden