> ich würde ja nichts sagen, wenn das mal 1Jahr so wäre - aber - das geht seit 10Jahren jetzt so. >Eine heute gut funktionierende Distro kann in der nächsten Version wieder vollkommen neue Probleme aufwerfen.
Ich kann den Unmut teilweise schon verstehen. Oftmals sind es auch kleinere Fehler, die sich recht gut umgehen lassen aber nicht umsonst gibt es den Ausdruck "Death of a thousand paper cuts".
Das Problem ist dabei sehr tiefgründig (schätze ich) und liegt bei den Anwendern. Ein Großteil dieser will nämlich immer das allerneuste und beste haben. Die Distributionen kommen diesem Wunsch nach, sonst laufen die Nutzer weg. Schön zu sehen bei der Einführung von KDE 4. Eine Distribution hat als erstes KDE4 als KDE-Desktop eingeführt und alle anderen Distributionen sind nach gezogen. Oder man sieht es an den 6-Monat Zyklus beim Veröffentlichen, dem auch die meisten Distributionen folgen.
Das geht, weil aus der Entwicklung von Linux heraus die Anwender prinzipiell bereit sind auch mal etwas zu fummeln, dafür aber etwas bekommen, was es in der Form nirgends anders gibt. In letzter Zeit werden aber immer öfter Stimmen laut, die genau dieses Vorgehen anprangern (so wie du). Das liegt eben auch daran, dass Linux (genauer das ganze BS) langsam erwachsen wird und neue Nutzerschichten anspricht ... den gemeinen Menschen.
Von daher ist es nur noch eine Frage der Zeit, bis die Distributionen sich mehr und mehr dieser Wandlung anpassen.
Das Ganze muss dann aber nicht zwangsläufig im Gegensatz zur generellen open-source Taktik "Release often, release early" stehen.
>> Oftmals sind es auch kleinere Fehler Meistens ja... aber was nützt mirt ein kleiner Fehler in meinem Lieblings-Programm wenn ich keine alternative dazu finde? Damit ist es ein gewichtiges Problem. Aber - oftmals sind die probleme auch "offensichtlich" - sprich wenn der Entwickler/Distributor sein Paket auch nur 20min getestet hätte hätte ihm das auffallen müssen!
>> Ein Großteil dieser will nämlich immer das allerneuste und beste haben. Mit einer anderen System/Paket-Philosophie waere das unter GNU/Linux überhaupt GARKEIN Problem. Dann könnte eine Distro out-of-box stable-versionen beinhalten - und ein user könnte ohne "gefrickel" ein Programm xyz in neuer Fassung installieren... Damit würde es dann plötzlich auch langen alle 2-3Jahre eine neue Distro-version auf den markt zu werfen, und die Distributoren könnten sich stärker auf die Qualitaet konzentrieren...
>> Von daher ist es nur noch eine Frage der Zeit, bis die Distributionen sich mehr und mehr dieser Wandlung anpassen. Vor 10Jahren als KDE2 rauskam, dachte ich 5Jahre - bis dahin hönnte das System stabil sein, und Windows das wasser abgraben. Wenn Du mich heute fragst - würde ich sagen 5 Jahre, und Linux könnte Windows überholen - aber realstisch gesehen wird das wohl nie etwas - nicht weil gnu/linux technisch unterlegen ist, sondern weil es schlichtweg für den Desktop (insbesondere KDE) eine unzureichende Qualitätssicherung sowie (aus meiner sicht) unpassende philosophien (u.a. paketsystem, plasma/grafiktreiber usw..) hat.
>> unpassende philosophien (u.a. paketsystem, plasma/grafiktreiber usw..) hat.
Was ist deiner Meinung nach an dem Paketsystem denn "unpassend"?
Ich würde mich über ein Paketsystem bei Windows auch freuen. Ich fände es sehr praktisch wenn ich an einer einzigen Stelle immer über alle neue verfügbaren Versionen aller Installierten Programme informiert werden würde. Aktuell melden sich ja die Programme einzeln (aber nicht alle), dass es eine neue Version gibt. Dann muss ich diese auch noch manuell und einzeln aktualisieren.
Ich behaupte nicht dass die Paketsysteme der Weisheit letzter Schluss wären. Aber immerhin gibt es sie. Da gefällt mir Linux doch weitaus besser als Windows. Und einige meiner Windows-Freunde sehen das auch so.
Wie wäre es wenn man ein Distro-Übergreifendes "Paket-System" hernehmen würde (eventuell tar-basierend, oder wie-auch-immer) - welches weitesgehend "statisch" compiliert wär. Dazu einen Distro-unabängigen Paket-Manager - in welchen ich manuell definieren kann welche Programme ich wie updateninstallieren möchte. zb:
firefox: major-updates thunderbird: minor-updates vlc: garkeine updates pidgin: nur bis max version 2.8.x
Der Paket-manager schaut dann auf der Hersteller-Seite selbst nach, und bindet die neuen Programme entsprechend bei neuer Verfügbarkeit ein. Das ganze könnte Distro-Übergreifend eingerichtet werden. Die Programme werden in "irgend einer form" ohne übers ganze system zu streuen ins System eingebettet - zb:
/opt/package/program-1.2.3.tar
Vorteil: * Projekte brauchen nur ein statisches Paket für alle Distros zur verfügung stellen (jede major/minor-version) * Endanwender haben JEDERZEIT ohne risigen Aufwand die Möglichkeit ihre Programme zu aktualisieren - ohne das sie auf die neue $DISTRO-version setzen müssen * Wenn ein neues Programm (zb Kdevelop4.0.0)mir nicht gefaellt, kann ich das "einfachst" deinstallieren, und durch 3.6.12 oder was auch immer ersetzen. * Die Distro ist mnicht mehr dem Druck ausgeliefert jedes halbjahr eine neue Version zu bauen - sondern könnte sich mehr zeit für die Qualitätssicherung lassen.
Das könnte man im prinzip für sämtliche Desktop-Software umsetzen - dort wäre auch der größte Vorteil eines solchen Systems zu sehen. Im Prinzip könnte damm die Distro selbst nur ihr basis-System wie gehabt ausliefern, und schon einen grossteil an Programmen Out-Of-Box in diesem Zustand auslierfern - also im Grund saemtliche Software die man dadrüber dann verwalten könnte. Out-Of-Box dann halt so eingestellt das nur Minor-Updates eingepflegt werden.
>> Ich würde mich über ein Paketsystem bei Windows auch freuen. Und einige meiner Windows-Freunde sehen das auch so. So in der richtung wär das für Windows auch nicht schlecht - stimmt. Die Programme würden sich aber beim Hersteller selbst einklinken. Und nicht das die Liste von MS vorgegeben wird. Genau das ist imho das problem unter den derzeitigen Paket-Systemen unter GNU/Linux.
Ein Distro-Übergreifendes Paket-System wäre natürlich was feines. So würde sich jeder auf einer neuen Distribution gleich zurecht finden und die Software-Hersteller hätten weniger Arbeit, wenn sie ihre Software für Linux zur Verfügung stellen.
Aber unter Linux kann man so etwas eher schlecht "vorsetzen". Mal angenommen es gäbe ein Standard-Paket-System, was aber nicht in allen Belangen optimal ist (was ja keine Software ist). Nun setzen sich einige Entwickler zusammen und entwickeln - vorerst nur als ein Hobby-Projekt - eine Alternative. Ein System, was ihren Vorstellungen nach besser ist. Das entwickelt sich dann nach und nach weiter und wird immer ausgereifter, bis es schließlich auch in größeren Distributionen verwendet wird. Und schon hat man wieder ein zweites Paket-System mit ihren Vor- und Nachteilen jeweils. 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 wäre zum einen viel Arbeit für die Distributionen, und zudem müsste eines der beiden Paket-System ja auch an die gegebenheiten bzw. die Vorteile des anderen Paket-Systems angepasst werden. Vor allem bei letzterem gibt es bestimmt auch wieder unterschiedliche Meinungen, ob etwas denn nun wirklich ein Vor- oder ein Nachteil ist.
Es wäre natürlich schön wenn man ein System als Standard vorgeben würde, so wie freedesktop.org zum Beispiel auch Standards für die Desktop-Oberfläche definiert, woran dann gemeinsam entwickelt wird. Jedoch kann das oben genannte dann natürlich auch immer noch passieren.
Schlimmer finde ich da hingegen aber dass bei den einzelnen Distributionen die Dateien an ganz unterschiedlichen Plätzen abgelegt werden. Meistens sind es die Config-Dateien, welche man dann unter einer anderen Distribution in einem anderen Ordner vorfindet. Das macht es für die Software-Hersteller auch nicht leichter. So kann eine config-Datei unter OpenSuSE ganz woanders liegen als unter Fedora. Vor allem OpenSuSE ist mir da (viel) früher als stark aufgefallen, das da vieles an anderer Stelle liegt.
>> * Die Distro ist mnicht mehr dem Druck ausgeliefert jedes halbjahr eine neue Version zu bauen - >> sondern könnte sich mehr zeit für die Qualitätssicherung lassen.
Druck ist da natürlich auch dabei. Aber ich denke dass sich daran nichts ändern würde. Vor allem weil die meisten Distributionen bzw. Entwickler der Anwendungen ihre Release-Modell auch selbst für Sinvoll erachten. KDE, Gnome und Xorg sind von ihrem 6-Monate-Zyklus überzeugt, so wie der Linux-Kernel mit den 3 Monaten ganz gut fährt. Ich bin mir sicher dass die gängigen Distributionen aber am meisten darauf wert legen, immer eine aktuelle CD/DVD anbieten zu können, ohne dass der Anwender gleich nach der Installation hunderte von Paketen updaten muss.
Ich selbst bin mit dem Rolling-Release von Gentoo aber ganz glücklich, weil ich selbst entscheiden kann, wann ich welche Pakete bzw. Teile update.
>> So in der richtung wär das für Windows auch nicht schlecht - stimmt. Die Programme würden sich aber beim Hersteller >> selbst einklinken. Und nicht das die Liste von MS vorgegeben wird. >> Genau das ist imho das problem unter den derzeitigen Paket-Systemen unter GNU/Linux.
Etwas ähnliches gibt es ja heute schon. Man kann ja auch die Repositories bzw. Overlays (unter Gentoo) in das System mit Integrieren. Diese können ja auch beim Hersteller der Software liegen, womit er diese Verwalten kann. Was noch getan werden müsste, wäre dass das Repo dann auch bei der Installation von Anwendungen durch z.B. diesen 1-Click-Installation auf Nachfrage auch gleich mit eingerichtet wird. Außerdem müssten die Paket-Manager wohl noch auf viele Repos (je Anwendung eine) hin optimiert werden.
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
>> Ich bin mir sicher dass die gängigen Distributionen aber am meisten darauf wert legen, immer eine aktuelle CD/DVD anbieten zu können, ohne dass der Anwender gleich nach der Installation hunderte von Paketen updaten muss.
Warum muss die Quelle zwingend allein aus dem Web kommen? Warum bietet man nicht "installations-cds" - dann könnte das ganze auch direkt von der DISTRO-Cd eingebettet werden.
Presst Werbe-CDs - macht ne Zeitschrift: "GANZ NEU: VLC1.1 - KDE4.6 - Gnome3 - Installieren via Mausklick"
Damit wären zig tausende User Happy gewesen, udn wenn KDE4.1 nicht gefallen hätte - schitzt happens - deinstallier ichs wieder via Mausklick - ohne mir das System zu zerschiessen...
Aber ich schätze sowas wird nie kommen, genauso wie andere (imho) gute Ideen ebenfalls in der versenke verschwunden sind... (zb: http://elektra.g4ii.com/Why_Linux_Needs_to_be_Elektrified) - vielleicht kommts in 10Jahren irgentwann - wenn die Pulseaudio/Video-Treiber uind anderen Probleme halbwegs gelöst sind.... - und 20neue Dateisysteme und Bootmanager entwickelt wurden...
> ich würde ja nichts sagen, wenn das mal 1Jahr so wäre - aber - das geht seit 10Jahren jetzt so.
>Eine heute gut funktionierende Distro kann in der nächsten Version wieder vollkommen neue Probleme aufwerfen.
Ich kann den Unmut teilweise schon verstehen. Oftmals sind es auch kleinere Fehler, die sich recht gut umgehen lassen aber nicht umsonst gibt es den Ausdruck "Death of a thousand paper cuts".
Das Problem ist dabei sehr tiefgründig (schätze ich) und liegt bei den Anwendern. Ein Großteil dieser will nämlich immer das allerneuste und beste haben. Die Distributionen kommen diesem Wunsch nach, sonst laufen die Nutzer weg. Schön zu sehen bei der Einführung von KDE 4. Eine Distribution hat als erstes KDE4 als KDE-Desktop eingeführt und alle anderen Distributionen sind nach gezogen. Oder man sieht es an den 6-Monat Zyklus beim Veröffentlichen, dem auch die meisten Distributionen folgen.
Das geht, weil aus der Entwicklung von Linux heraus die Anwender prinzipiell bereit sind auch mal etwas zu fummeln, dafür aber etwas bekommen, was es in der Form nirgends anders gibt. In letzter Zeit werden aber immer öfter Stimmen laut, die genau dieses Vorgehen anprangern (so wie du). Das liegt eben auch daran, dass Linux (genauer das ganze BS) langsam erwachsen wird und neue Nutzerschichten anspricht ... den gemeinen Menschen.
Von daher ist es nur noch eine Frage der Zeit, bis die Distributionen sich mehr und mehr dieser Wandlung anpassen.
Das Ganze muss dann aber nicht zwangsläufig im Gegensatz zur generellen open-source Taktik "Release often, release early" stehen.
Gruß
>> Oftmals sind es auch kleinere Fehler
Meistens ja... aber was nützt mirt ein kleiner Fehler in meinem Lieblings-Programm wenn ich keine alternative dazu finde? Damit ist es ein gewichtiges Problem.
Aber - oftmals sind die probleme auch "offensichtlich" - sprich wenn der Entwickler/Distributor sein Paket auch nur 20min getestet hätte hätte ihm das auffallen müssen!
>> Ein Großteil dieser will nämlich immer das allerneuste und beste haben.
Mit einer anderen System/Paket-Philosophie waere das unter GNU/Linux überhaupt GARKEIN Problem. Dann könnte eine Distro out-of-box stable-versionen beinhalten - und ein user könnte ohne "gefrickel" ein Programm xyz in neuer Fassung installieren...
Damit würde es dann plötzlich auch langen alle 2-3Jahre eine neue Distro-version auf den markt zu werfen, und die Distributoren könnten sich stärker auf die Qualitaet konzentrieren...
>> Von daher ist es nur noch eine Frage der Zeit, bis die Distributionen sich mehr und mehr dieser Wandlung anpassen.
Vor 10Jahren als KDE2 rauskam, dachte ich 5Jahre - bis dahin hönnte das System stabil sein, und Windows das wasser abgraben. Wenn Du mich heute fragst - würde ich sagen 5 Jahre, und Linux könnte Windows überholen - aber realstisch gesehen wird das wohl nie etwas - nicht weil gnu/linux technisch unterlegen ist, sondern weil es schlichtweg für den Desktop (insbesondere KDE) eine unzureichende Qualitätssicherung sowie (aus meiner sicht) unpassende philosophien (u.a. paketsystem, plasma/grafiktreiber usw..) hat.
Das resultiert imho am Ende aus der Hobby-Entwicklung, die verständlicherweise nicht alles Stemmen kann...
http://linuxundich.de/de/ubuntu/bryan-lunduke-linux-still-sucks/
>> unpassende philosophien (u.a. paketsystem, plasma/grafiktreiber usw..) hat.
Was ist deiner Meinung nach an dem Paketsystem denn "unpassend"?
Ich würde mich über ein Paketsystem bei Windows auch freuen. Ich fände es sehr praktisch wenn ich an einer einzigen Stelle immer über alle neue verfügbaren Versionen aller Installierten Programme informiert werden würde. Aktuell melden sich ja die Programme einzeln (aber nicht alle), dass es eine neue Version gibt. Dann muss ich diese auch noch manuell und einzeln aktualisieren.
Ich behaupte nicht dass die Paketsysteme der Weisheit letzter Schluss wären. Aber immerhin gibt es sie. Da gefällt mir Linux doch weitaus besser als Windows. Und einige meiner Windows-Freunde sehen das auch so.
Wie wäre es wenn man ein Distro-Übergreifendes "Paket-System" hernehmen würde (eventuell tar-basierend, oder wie-auch-immer) - welches weitesgehend "statisch" compiliert wär. Dazu einen Distro-unabängigen Paket-Manager - in welchen ich manuell definieren kann welche Programme ich wie updateninstallieren möchte. zb:
firefox: major-updates
thunderbird: minor-updates
vlc: garkeine updates
pidgin: nur bis max version 2.8.x
Der Paket-manager schaut dann auf der Hersteller-Seite selbst nach, und bindet die neuen Programme entsprechend bei neuer Verfügbarkeit ein. Das ganze könnte Distro-Übergreifend eingerichtet werden. Die Programme werden in "irgend einer form" ohne übers ganze system zu streuen ins System eingebettet - zb:
/opt/package/program-1.2.3.tar
Vorteil:
* Projekte brauchen nur ein statisches Paket für alle Distros zur verfügung stellen (jede major/minor-version)
* Endanwender haben JEDERZEIT ohne risigen Aufwand die Möglichkeit ihre Programme zu aktualisieren - ohne das sie auf die neue $DISTRO-version setzen müssen
* Wenn ein neues Programm (zb Kdevelop4.0.0)mir nicht gefaellt, kann ich das "einfachst" deinstallieren, und durch 3.6.12 oder was auch immer ersetzen.
* Die Distro ist mnicht mehr dem Druck ausgeliefert jedes halbjahr eine neue Version zu bauen - sondern könnte sich mehr zeit für die Qualitätssicherung lassen.
Das könnte man im prinzip für sämtliche Desktop-Software umsetzen - dort wäre auch der größte Vorteil eines solchen Systems zu sehen. Im Prinzip könnte damm die Distro selbst nur ihr basis-System wie gehabt ausliefern, und schon einen grossteil an Programmen Out-Of-Box in diesem Zustand auslierfern - also im Grund saemtliche Software die man dadrüber dann verwalten könnte. Out-Of-Box dann halt so eingestellt das nur Minor-Updates eingepflegt werden.
>> Ich würde mich über ein Paketsystem bei Windows auch freuen. Und einige meiner Windows-Freunde sehen das auch so.
So in der richtung wär das für Windows auch nicht schlecht - stimmt. Die Programme würden sich aber beim Hersteller selbst einklinken. Und nicht das die Liste von MS vorgegeben wird. Genau das ist imho das problem unter den derzeitigen Paket-Systemen unter GNU/Linux.
Ein Distro-Übergreifendes Paket-System wäre natürlich was feines. So würde sich jeder auf einer neuen Distribution gleich zurecht finden und die Software-Hersteller hätten weniger Arbeit, wenn sie ihre Software für Linux zur Verfügung stellen.
Aber unter Linux kann man so etwas eher schlecht "vorsetzen". Mal angenommen es gäbe ein Standard-Paket-System, was aber nicht in allen Belangen optimal ist (was ja keine Software ist). Nun setzen sich einige Entwickler zusammen und entwickeln - vorerst nur als ein Hobby-Projekt - eine Alternative. Ein System, was ihren Vorstellungen nach besser ist. Das entwickelt sich dann nach und nach weiter und wird immer ausgereifter, bis es schließlich auch in größeren Distributionen verwendet wird. Und schon hat man wieder ein zweites Paket-System mit ihren Vor- und Nachteilen jeweils. 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 wäre zum einen viel Arbeit für die Distributionen, und zudem müsste eines der beiden Paket-System ja auch an die gegebenheiten bzw. die Vorteile des anderen Paket-Systems angepasst werden. Vor allem bei letzterem gibt es bestimmt auch wieder unterschiedliche Meinungen, ob etwas denn nun wirklich ein Vor- oder ein Nachteil ist.
Es wäre natürlich schön wenn man ein System als Standard vorgeben würde, so wie freedesktop.org zum Beispiel auch Standards für die Desktop-Oberfläche definiert, woran dann gemeinsam entwickelt wird. Jedoch kann das oben genannte dann natürlich auch immer noch passieren.
Schlimmer finde ich da hingegen aber dass bei den einzelnen Distributionen die Dateien an ganz unterschiedlichen Plätzen abgelegt werden. Meistens sind es die Config-Dateien, welche man dann unter einer anderen Distribution in einem anderen Ordner vorfindet. Das macht es für die Software-Hersteller auch nicht leichter. So kann eine config-Datei unter OpenSuSE ganz woanders liegen als unter Fedora. Vor allem OpenSuSE ist mir da (viel) früher als stark aufgefallen, das da vieles an anderer Stelle liegt.
>> * Die Distro ist mnicht mehr dem Druck ausgeliefert jedes halbjahr eine neue Version zu bauen -
>> sondern könnte sich mehr zeit für die Qualitätssicherung lassen.
Druck ist da natürlich auch dabei. Aber ich denke dass sich daran nichts ändern würde. Vor allem weil die meisten Distributionen bzw. Entwickler der Anwendungen ihre Release-Modell auch selbst für Sinvoll erachten. KDE, Gnome und Xorg sind von ihrem 6-Monate-Zyklus überzeugt, so wie der Linux-Kernel mit den 3 Monaten ganz gut fährt. Ich bin mir sicher dass die gängigen Distributionen aber am meisten darauf wert legen, immer eine aktuelle CD/DVD anbieten zu können, ohne dass der Anwender gleich nach der Installation hunderte von Paketen updaten muss.
Ich selbst bin mit dem Rolling-Release von Gentoo aber ganz glücklich, weil ich selbst entscheiden kann, wann ich welche Pakete bzw. Teile update.
>> So in der richtung wär das für Windows auch nicht schlecht - stimmt. Die Programme würden sich aber beim Hersteller
>> selbst einklinken. Und nicht das die Liste von MS vorgegeben wird.
>> Genau das ist imho das problem unter den derzeitigen Paket-Systemen unter GNU/Linux.
Etwas ähnliches gibt es ja heute schon. Man kann ja auch die Repositories bzw. Overlays (unter Gentoo) in das System mit Integrieren. Diese können ja auch beim Hersteller der Software liegen, womit er diese Verwalten kann. Was noch getan werden müsste, wäre dass das Repo dann auch bei der Installation von Anwendungen durch z.B. diesen 1-Click-Installation auf Nachfrage auch gleich mit eingerichtet wird. Außerdem müssten die Paket-Manager wohl noch auf viele Repos (je Anwendung eine) hin optimiert werden.
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
>> Ich bin mir sicher dass die gängigen Distributionen aber am meisten darauf wert legen, immer eine aktuelle CD/DVD anbieten zu können, ohne dass der Anwender gleich nach der Installation hunderte von Paketen updaten muss.
Warum muss die Quelle zwingend allein aus dem Web kommen?
Warum bietet man nicht "installations-cds" - dann könnte das ganze auch direkt von der DISTRO-Cd eingebettet werden.
Presst Werbe-CDs - macht ne Zeitschrift: "GANZ NEU: VLC1.1 - KDE4.6 - Gnome3 - Installieren via Mausklick"
Damit wären zig tausende User Happy gewesen, udn wenn KDE4.1 nicht gefallen hätte - schitzt happens - deinstallier ichs wieder via Mausklick - ohne mir das System zu zerschiessen...
Aber ich schätze sowas wird nie kommen, genauso wie andere (imho) gute Ideen ebenfalls in der versenke verschwunden sind...
(zb: http://elektra.g4ii.com/Why_Linux_Needs_to_be_Elektrified) - vielleicht kommts in 10Jahren irgentwann - wenn die Pulseaudio/Video-Treiber uind anderen Probleme halbwegs gelöst sind.... - und 20neue Dateisysteme und Bootmanager entwickelt wurden...