Persönlich halte ich 5 Jahre für den Desktop für passend. Aber es muss auch Backports aktueller Programme geben. Darüber hinaus bringt es recht wenig nur einen 'Kernsatz' von Programmen über 5 Jahre zu unterstützen, sondern es braucht dann schon die gesamte Distribution.
Der Gedanken kommt bei mir daher, das es viele Leute gibt die nicht aller ein, zwei Jahre ihr System neu installieren, aber dennoch aktuelle Software haben wollen. Und das kann man auf genau diesen Weg erreichen. Aller wie viel Jahre es ein solches LTS-Release gibt und wie weit sich die einzelnen LTS-Releases überschneiden, darüber mag man sich streiten.
Das ist technisch oftmals nur eine begrenzte Zeit möglich, da die meiste Software nicht eigenständig lauffähig ist, sondern Abhängigkeiten zu Bibliotheken und anderen Programmen besitzt. Nach einer gewissen Zeit hat man dadurch das halbe System ausgetauscht. Da kann man es gleich regulär upgraden.
Jain und das zeigt ausgerechnet Windows. Den selbst wenn ich Heute ein Programm kaufe ist es in der Regel zu Windows XP kompatibel. Und Windows XP ist immerhin 2001 auf den Markt gekommen. Und ja es ist klar das bei Windows XP durch die Servicepacks im Laufe der Zeit einiges angepasst wurde, aber die Grundstruktur hat sich nicht groß verändert.
Mir ist dabei klar das die Entwicklung von Linux wesentlich dynamischer und 'stürmischer' als die von Windows ist. Deshalb wäre es evtl. gut die Entwicklung des Grundsystems von einen Distributionsübergreifenden 'Backport-System' zu trennen. Sprich man hat auf der einen Seite ein Grundsystem mit dem das System und die dazugehörigen Programme gepflegt werden und daneben ein weiteres Distributionsübergreifendes Paketsystem das z. B. unter /opt/apps installiert wird und bei Bedarf seine Abhängigkeiten unabhängig vom System mit installiert. Wenn alle neuen Programmversionen in das Distributionübergreifende Paketsystem könnte dann sogar erlauben mehrere Programmversionen nebeneinander zu installieren und freilich könnte man unterschiedliche Sicherheitsfunktionen einbauen, um das Grundsystem zu schützen, dabei wäre vieles bis hin zu Sandboxen denkbar. Auf diese Weise könnte man ein stabiles Grundsystem und aktuelle Anwendungen miteinander vereinen. Wem dann gut durchgeprüfte und stabile Programme wichtiger ist als Aktualität, der verwendet weiterhin die Pakete die von dem Grundsystem zur Verfügung gestellten Versionen. So ein System hätte in meinen Augen große Vorteile, zumal man bei dem 'Distributionsübergreifenden Packetsystem auch die Möglichkeit einbauen könnte kommerzielle Programme zu erwerben und somit eine einheitliche Basis dafür schaffen würde, die für jeden einfach zu bedienen ist.
Eine Distro kann nicht ihre Libs einfrieren, wenn der Upstream trotzdem neuere, nicht abwärtskompatible Versionen der Libs nutzt. Die Distro muss dann einfach mitziehen, ob sie will oder nicht.
Wichtiger wäre es, eine Distro zu haben, die so einflussreich ist, dass Upstream-Entwickler nicht mehr Upstream-Libs als target nehmen, und sie dan ständig updaten, sondern die Libs die mit dieser Distro ausgeliefert werden. D.h. eine Distro, die so einflussreich ist im Linux-Ökosystem, dass sie die unkontrollierte und unkoordinierte Weiterentwicklung der Libs etwas verlangsamen und koordinieren kann.
Das große Problem bei Linux ist dass niemand das Sagen hat und die ganze Entwicklung deswegen völlig chaotisch verläuft. Das Linux-Ökosystem braucht deswegen einen starken "benevolent dictator", der den Ton angibt und das Library-Chaos zügelt. Windows kann diese Jahrzehnte überbrückenden Abwärtskompatibilität nur deswegen erreichen, weil Microsoft das will und stark genug ist, das durchzusetzen, weil sie alle Libs selber kontrollieren.
Deswegen hoffe ich persönlich dass in der Linux-Welt Ubuntu "gewinnt" und dann aufhört, die grundlegenden Libs ständig zu aktualisieren. Dann, erst dann, wird es auch für andere Distris möglich sein und einen kundenfreundlicheren, mehr konservativen Kurs zu fahren auf das nervige cutting edge zu verzichten. Dann werden auch keine "Backports" mehr benötigt, weil die target-libs 5-10 Jahre eh immer die gleichen sind. Dann entfällt auch der job des "packagers", weil jeder Entwickler seine Pakete selber bauen kann. Usw. Der ewige Updatewahn muss endlich aufhören.
Die ganzen Probleme ergeben sich wirklich nur aus der fehlenden Koordination. Wie man bisher gesehen hat, ist die Koordination nicht durch Konsens machbar, weil die Distris sich auf gar nichts einigen können. Linux braucht eine Diktatur. Nicht nur auf Kernelebene, wo sich hervorragend zeigt wie nützlich ein Diktator sein kann, sondern auch auf Distri-Ebene. Mein Wunschdiktator ist der Shuttleworth.
auch wenn es dann wieder Idioten geben wird, die Linux und alles forken und im Endeffekt noch mehr Chaos herrscht. Andererseits: Es ist alles kostenlos und sogar mehr als das, also ist es schon bemerkenswert, dass es schon in der DERZEITIGEN FOrm so existiert. Das Problem ist halt: Es sind die Produkte aus DEM Hobby der Nerds. Und im Hobbysbereich probiert man eben immer neues und macht ungern das gleiche. Solange die Entwickler Hobbyentwickler sind, wird sich daran auch NIE etwas ändern, weil die sonst ihren Spaß daran verlieren würden (Managment, Dokumentation, Planung, Pflege alter Version, .. Nerds programmieren lieber einfach drauf los, schreiben neu, weiter drauf los nochmals alles neu).
Dein Ziel wird man nur erreichen, wenn sich der Kommerz das Linux-Ökosystem schnappt und daraus etwas eigenes, konsistentes baut, wie Apple es zuvor mit FreeBSD gemacht hat.
Debian ist schon DIE Referenz und friert alles ein. Im Upstream macht sich das NULL bemerkbar. Es sind eben Hobbyprogrammierer, die teilweise aus Egoismus programmieren: Aus eigenem Vergnügen und nur das, was Spaß macht. Pflege alter Version, Managment und Vorausplanung machen keinen Spaß.
> Debian ist schon DIE Referenz und friert alles ein.
Debian friert aber auch die Apps ein, und niemand kann jahrelang etwas updaten, und deswegen ist es immer veraltet und deswegen nutzt es niemand auf dem Desktop und deswegen ignoriert der app-stream debian als target weil es keine nutzer hat.
Debians ansatz mit dem einfrieren ist prinzipiell richtig, aber sie frieren _zuviel_ ein. Sie frieren alles ein und man muss dann um Backports betteln. Sie frieren sich zu Tode.
> Pflege alter Version, Managment und Vorausplanung machen keinen Spaß.
Ich würde gerne für ein Linux bezahlen, wo ich einmal eine neue "Version" des Grundsystems installiere, und dann 5-10 Jahre lang neue apps für dieses system-version bekomme ohne das System selber updaten zu müssen. Nach dem Motto "Shut up and take my money!". Aber niemand lässt mich dafür bezahlen.
Von Programmierer sind schuld am Sa, 5. Mai 2012 um 12:10 #
Debian friert aber auch die Apps ein, und niemand kann jahrelang etwas updaten, und deswegen ist es immer veraltet und deswegen nutzt es niemand auf dem Desktop und deswegen ignoriert der app-stream debian als target weil es keine nutzer hat.
Debians ansatz mit dem einfrieren ist prinzipiell richtig, aber sie frieren _zuviel_ ein. Sie frieren alles ein und man muss dann um Backports betteln. Sie frieren sich zu Tode.
Volle Zustimmung.
Debian sollte eine Unterscheidung zwischen Core System und Desktopanwendungen machen und diese unterschiedlich behandeln.
Von Programmierer sind schuld am Sa, 5. Mai 2012 um 12:08 #
Mein Wunschdiktator ist der Shuttleworth.
Bloß nicht! Ihm verdanken wie Unity und den Dreck mit den Buttons an der falschen Seite.
Und anstatt einen Diktator hätte ich hier lieber eine kleine demokratische Organisation, die das Grundsystem festlegt. Im Prinzip gibt's das auch schon in Form der LSB, nur bringt das halt nichts, wenn sich kein Open Source Programmierer daran halten will, weil er meint, als OSS Programmierer bräuchte er die LSB nicht.
Aber das mit dem "Programmierer wollen nur cutting edge" hast du schon richtig herauskristallisiert. Hier liegt das Problem.
Zum anderen kann man es aber auch verstehen. Als Programmierer will man deswegen die neuste API Funktion nutzen, weil man befürchten muss, dass die alte irgendwann Obsolete wird und dann macht man sich doppelte Arbeit, wenn man zuerst die alte nutzt um Rücksicht auf LTS Distributionen zu nehmen und dann später trotzdem das ganze Programm wieder an die neue API Funktionen anpassen muss.
Die eigentliche Lösung wäre also, die APIs und ganzen Libs selbst langzeitstabil zu machen, da sich aber in der Softwareentwicklung immer noch so viel ändert, gerade beim Desktop Environment und der Art und Weise wie GUIs erstellt werden, früher fest im Quellcode, heute mit CSS und HTML oder ähnliches, ist das kein Wunder.
Die eigentliche Frage wird also sein, ob es in 10 Jahren auch noch so große Umbrüche in der Art der Softwareentwicklung gibt wie heute, wenn man das verneinen kann, dann liegen langzeitstabile APIs für Desktopanwendungen im Bereich der Möglichkeit.
Nein, die Stärke von Linux ist die Vielfalt. Wir können ja wegen Euch Clowns auch sämtliche Birn, Pflaumen und nutzlosen anderen Bäumen abholzen. Apfelbäume reichen für alle aus.
Mir war klar, dass der Windows-Vergleich kommen wird und damit Dinge verglichen werden, die unterschiedlicher nicht sein könnten.
Meines Erachtens ging es bei dieser Diskussion um Distributionen. Mir ist jedoch keine Windows-Distribution, also eine Quelle wo ich alles sauber aufeinander abgestimmt aus einer Hand erhalten würde, bekannt.
Jede Windows-Software bringt ihre eigenen, zur Laufzeit benötigten Bibliotheken mit und installiert diese auf dem System, mit all den daraus resultierenden Nachteilen. Beispielsweise wird damit das Konzept der dynamisch gelinkten Libraries welche sich nur einmal im Speicher befinden müssen aber von zahlreichen Programmen gleichzeitig genutzt werden können ad absurdum geführt. An den Sicherheits-Albtraum, wenn sich die selbe verwundbare Bibliothek zigfach auf dem System befindet, erst garnicht zu denken.
Selbiges kannst du auch unter Linux bekommen, schau dir z.B. Google Earth an oder die vom Humble Indie Bundle veröffentlichten Spiele. Das Prinzip und die Nachteile sind die selben wie unter Windows. Sicher, man kann so vorgehen um eine Software möglichst unabhängig von der verwendeten Distribution zum Laufen zu bekommen und ohne den Quellcode rausrücken zu müssen. Ein erstrebenswertes Konzept für eine Distribution ist es jedoch nicht.
Eine Distribution kann so nicht vorgehen, denn dies würde in die Kategorie Pfusch fallen. Von einer Distribution wird zurecht erwartet, dass es die Software ins System integriert und nicht am System vorbei betreibt.
Und Windows XP ist immerhin 2001 auf den Markt gekommen. Und ja es ist klar das bei Windows XP durch die Servicepacks im Laufe der Zeit einiges angepasst wurde, aber die Grundstruktur hat sich nicht groß verändert.
Immer diese Mär. Bei der von dir genannten Windows-Version wurde der Support 2005 eingestellt. Seitdem sind keine Sicherheitsupdates mehr erhältlich und zahlreiche Software ist damit nicht mehr lauffähig.
Windows XP SP3 hat mit der ursprünglichen Windows XP-Version aus 2001 nicht mehr viel zu tun. Nicht umsonst ist es Voraussetzung um überhaupt noch Sicherheitsupdates vom Hersteller zu erhalten und wird von zahlreicher Software vorausgesetzt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Mai 2012 um 15:04.
Mir war klar, dass der Windows-Vergleich kommen wird und damit Dinge verglichen werden, die unterschiedlicher nicht sein könnten.
Das ist dem normalen Anwender letztendlich absolut egal! Und der normale Anwender stellt nun einmal die Masse der Anwender. Er will ein System das über lange Zeit funktioniert, ihm ermöglicht die Programme und Programmversionen die er installieren will auch einfach und bequem installieren zu können und darüber hinaus will er so wenig wie möglich mit den Systeminnereien, der Sicherheitsproblematik etc. zu tun haben. Und glaube mir das ist so, ich habe jeden Tag auf der Arbeit mit diesen Typ Anwender zu tun.
Meines Erachtens ging es bei dieser Diskussion um Distributionen. Mir ist jedoch keine Windows-Distribution, also eine Quelle wo ich alles sauber aufeinander abgestimmt aus einer Hand erhalten würde, bekannt.
Und soll man deshalb den Anspruch herunterschrauben? Will man auf dem Desktopmarkt vorankommen oder nicht? Mir kommt es des öfteren vor als wäre letzteres der Fall. Vorankommen wird man erst wenn man mehr standardisiert und vereinheitlicht und mehr auf die Wünsche und Bedürfnisse der normalen Anwender eingeht.
Jede Windows-Software bringt ihre eigenen, zur Laufzeit benötigten Bibliotheken mit und installiert diese auf dem System, mit all den daraus resultierenden Nachteilen. Beispielsweise wird damit das Konzept der dynamisch gelinkten Libraries welche sich nur einmal im Speicher befinden müssen aber von zahlreichen Programmen gleichzeitig genutzt werden können ad absurdum geführt. An den Sicherheits-Albtraum, wenn sich die selbe verwundbare Bibliothek zigfach auf dem System befindet, erst garnicht zu denken.
Selbiges kannst du auch unter Linux bekommen, schau dir z.B. Google Earth an oder die vom Humble Indie Bundle veröffentlichten Spiele. Das Prinzip und die Nachteile sind die selben wie unter Windows. Sicher, man kann so vorgehen um eine Software möglichst unabhängig von der verwendeten Distribution zum Laufen zu bekommen und ohne den Quellcode rausrücken zu müssen. Ein erstrebenswertes Konzept für eine Distribution ist es jedoch nicht.
Auch bei Windows gibt es die Möglichkeit Bibliotheken und andere Komponenten gemeinsam zu nutzen. Das das Konzept bei Windows nicht so häufig genutzt wird liegt wohl eher an den Gewohnheiten der Programmierer als daran das es nicht geht. Es gibt darüber hinaus wie Du sehr schön ausgeführt hast auch unter Linux Beispiele von statisch eingebundenen, aber das ist glücklicherweise eher selten. Aber es zeigt doch das es auch hier an den Programmierern liegt. An sich spricht das aber für meine Idee des 'Distributionsübergreifenden Paketsystems neben dem Paketsystem der Distribution', den das ermöglicht es auch auf recht alten Systemen aktuelle Software zu installieren ohne alle entsprechenden Abhängigkeiten erneut und erneut installieren zu müssen.
Eine Distribution kann so nicht vorgehen, denn dies würde in die Kategorie Pfusch fallen. Von einer Distribution wird zurecht erwartet, dass es die Software ins System integriert und nicht am System vorbei betreibt.
Eine Distribution kann wie nicht vorgehen? So wie ich es skizziert habe das die Distribution fünf Jahre Support bietet und darüber hinaus ein zweites Paketsystem das seine Pakete unter /opt/apps installiert (es wären auch benutzerspezifische Installationen unter ~/apps oder ~/.apps denkbar). Eine Alternative wäre das die Distribution praktisch den Unterbau und die Grafische Benutzeroberfläche liefert, die Anwendungsprogramme aber aus einen zentralen distributionsübergreifenden Repository kommen und dort immer aktuell verfügbar sind. Natürlich auch mit Fehlerbehebungen.
Immer diese Mär. Bei der von dir genannten Windows-Version wurde der Support 2005 eingestellt. Seitdem sind keine Sicherheitsupdates mehr erhältlich und zahlreiche Software ist damit nicht mehr lauffähig.
Windows XP SP3 hat mit der ursprünglichen Windows XP-Version aus 2001 nicht mehr viel zu tun. Nicht umsonst ist es Voraussetzung um überhaupt noch Sicherheitsupdates vom Hersteller zu erhalten und wird von zahlreicher Software vorausgesetzt.
Und ändert das etwas daran das selbst Heute noch die allermeiste Software die neu auf den Markt kommt auf einen aktuellen Windows (ja und Servicepacks gehören dazu) läuft? Ändert das etwas für den normalen Anwender? Es ist schön das Du es aus der Ebene der Nerds siehst, aber die breite Mehrheit der Anwender gehört nun einmal nicht dieser 'elitären' Gruppe an.
Das ist dem normalen Anwender letztendlich absolut egal! Und der normale Anwender stellt nun einmal die Masse der Anwender. Er will ein System das über lange Zeit funktioniert, ihm ermöglicht die Programme und Programmversionen die er installieren will auch einfach und bequem installieren zu können und darüber hinaus will er so wenig wie möglich mit den Systeminnereien, der Sicherheitsproblematik etc. zu tun haben. Und glaube mir das ist so, ich habe jeden Tag auf der Arbeit mit diesen Typ Anwender zu tun.
Dein sogenannter "normaler Anwender" möchte Windows einsetzen weil er Windows gewöhnt ist und ihm die Weitsicht fehlt, sich auf ein anderes System mit anderen Konzepten einzulassen. Dieser Anwender hat nichts in der Linux-Welt verloren, er soll sein Windows einsetzen und damit glücklich werden.
Jeder andere normale Anwender wird froh sein, dass er sich seine Software nicht aus mehr oder minder dubiosen Quellen zusammensuchen muss, dabei jedesmal die persönlichen Daten auf seinem Rechner potentiell gefährdet, sich unbekannten Risiken und Nebenwirkungen des Zusammenspiels unterschiedlicher Software aussetzt und die Software auch nicht mehr rückstandslos von seinem Rechner bekommt. Dieser Anwender ist froh, dass ihm seine Distribution die Arbeit abnimmt, er getestete und auf seine Umgebung optimal abgestimmte Software aus zentraler Quelle erhält, die er falls gewünscht auch wieder rückstandslos entfernen kann.
Und soll man deshalb den Anspruch herunterschrauben?
Das ist genau das wovon ich Rede. Ich bin nicht bereit meine Ansprüche auf das Windows-Niveau herunterzuschrauben!
Will man auf dem Desktopmarkt vorankommen oder nicht?
Linux ist bei mir schon vor 15 Jahren auf dem Desktop angekommen. Auf Windows-Systemen komme ich mir hingegen regelmäßig vor wie in die Steinzeit zurückversetzt. Und nein, ich bin nicht bereits Linux in die Steinzeit zurückzubomben, nur damit es dann auch von Steinzeitmenschen genutzt werden kann.
Wer Linux einsetzen möchte soll sich damit vertraut machen, dass es an entscheidenden Stellen anderen Konzepten folgt und darin die Stärke des Systems liegt. Wer einen Windows-Clone haben möchte ist hier falsch und soll besser dort bleiben wo er ist.
Auch bei Windows gibt es die Möglichkeit Bibliotheken und andere Komponenten gemeinsam zu nutzen. Das das Konzept bei Windows nicht so häufig genutzt wird liegt wohl eher an den Gewohnheiten der Programmierer als daran das es nicht geht.
Es liegt nicht an den Programmierern sondern an der Art der Softwareverteilung, das habe ich ausführlich in meinem letzten Kommentar erläutert.
Es gibt darüber hinaus wie Du sehr schön ausgeführt hast auch unter Linux Beispiele von statisch eingebundenen, aber das ist glücklicherweise eher selten. Aber es zeigt doch das es auch hier an den Programmierern liegt.
Es ist praktisch immer dann der Fall, wenn die Art der Softwareverteilung dem unter Windows üblichem Verfahren gleicht. Auch das habe ich in meinem letzten Kommentar ausführlich erläutert.
An sich spricht das aber für meine Idee des 'Distributionsübergreifenden Paketsystems neben dem Paketsystem der Distribution', den das ermöglicht es auch auf recht alten Systemen aktuelle Software zu installieren ohne alle entsprechenden Abhängigkeiten erneut und erneut installieren zu müssen.
Auf dem Desktopmarkt?? Überlegen wir doch mal kurz, was wird ein Desktopnutzer wohl als erstes upgraden wollen? Richtig, seine Desktopoberfläche, sei es nun KDE, Gnome oder Xfce. Mit den dazugehörigen Abhängigkeiten hat er dann auf seinem Desktoprechner weit mehr als 50% der installierten Pakete ausgetauscht...
Eine Distribution kann wie nicht vorgehen? So wie ich es skizziert habe das die Distribution fünf Jahre Support bietet und darüber hinaus ein zweites Paketsystem das seine Pakete unter /opt/apps installiert (es wären auch benutzerspezifische Installationen unter ~/apps oder ~/.apps denkbar).
Auf was soll sie 5 Jahre Support bieten, auf die Bash und ein paar Kommandozeilentools? Recht viel mehr wird nämlich nicht übrig bleiben, sobald der Nutzer auf die Idee kommt den Desktop upzugraden.
Eine Alternative wäre das die Distribution praktisch den Unterbau und die Grafische Benutzeroberfläche liefert, die Anwendungsprogramme aber aus einen zentralen distributionsübergreifenden Repository kommen und dort immer aktuell verfügbar sind.
Achja, wie viele Anwendungen setzt denn dein durchschnittlicher Linuxanwender ein, die nicht Teil eines Desktopsystems sind und deshalb unabhängig davon upgegraded werden können?
Nehmen wir doch mal ein 5 Jahre altes System her, das wurde mit KDE3 ausgeliefert. Was, wenn der Anwender jetzt ein aktuelles KMail haben möchte? Dumm gelaufen, das gibt es nur für KDE4. Und schon fällt dein wenig durchdachtes System auf die Nase.
Und ändert das etwas daran das selbst Heute noch die allermeiste Software die neu auf den Markt kommt auf einen aktuellen Windows (ja und Servicepacks gehören dazu) läuft? Ändert das etwas für den normalen Anwender?
Das scheint mir auf einen "fresst Scheisse, millionen Fliegen können nicht irren"-Vergleich hinauszulaufen.
Es ist schön das Du es aus der Ebene der Nerds siehst, aber die breite Mehrheit der Anwender gehört nun einmal nicht dieser 'elitären' Gruppe an.
Ich sehe es aus der Sichtweise eines langjährigen Linux-Nutzers der sich die Mühe gemacht hat die dahinterliegenden Konzepte zu verstehen und nicht aus der eines "ich will jetzt auch Linux haben, aber es muss genau so funktionieren wie Windows"-Nutzers.
Dein sogenannter "normaler Anwender" möchte Windows einsetzen weil er Windows gewöhnt ist und ihm die Weitsicht fehlt, sich auf ein anderes System mit anderen Konzepten einzulassen. Dieser Anwender hat nichts in der Linux-Welt verloren, er soll sein Windows einsetzen und damit glücklich werden.
Das kannst Du getrost abschreiben. Auch wenn das vielen nicht gefallen dürfte darf man das Ubuntu Linux zuschreiben. Den das wurde zwar oft aus der Community kritisiert weil es sich was Codebeiträge betrifft zurückhält, aber was die Bekanntheit von Linux bei der Allgemeinheit betrifft hat Ubuntu das geleistet was anderen Distributionen und der Community über Jahren nicht gelungen ist.
Jeder andere normale Anwender wird froh sein, dass er sich seine Software nicht aus mehr oder minder dubiosen Quellen zusammensuchen muss, dabei jedesmal die persönlichen Daten auf seinem Rechner potentiell gefährdet, sich unbekannten Risiken und Nebenwirkungen des Zusammenspiels unterschiedlicher Software aussetzt und die Software auch nicht mehr rückstandslos von seinem Rechner bekommt. Dieser Anwender ist froh, dass ihm seine Distribution die Arbeit abnimmt, er getestete und auf seine Umgebung optimal abgestimmte Software aus zentraler Quelle erhält, die er falls gewünscht auch wieder rückstandslos entfernen kann.
Das was Du hier nennst ist schön und gut. Doch was genau bringt es dem normalen Anwender wenn er die aktuelle Version z. B. von einen Browser haben will? Was bringt es ihm wenn Distributionen zwar Sicherheitslücken fixen, aber den nervigen Bug der das Programm in Teilen unbrauchbar macht wegen fehlender Sicherheitsrelevanz nicht? Linux muss wenn es sich im Desktopbereich ausbreiten will den Ansprüchen der Anwender anpassen und es besser machen als Windows. Was btw. die Rückstandslosigkeit betrifft ist das so eine Sache. Man muss dann nämlich doch wieder ins Terminal um alles weg zu bekommen. Ich rede von mit installierten Abhängigkeiten und von Konfigurationsdateien. Und genau das wollen die meisten Anwender nicht. Den da stimmen wir wohl überein, das Terminal ist für Leute die wissen was sie tun.
Das ist genau das wovon ich Rede. Ich bin nicht bereit meine Ansprüche auf das Windows-Niveau herunterzuschrauben!
Wo müsstest Du den bei den von mir skizzierten Modell Deine Ansprüche herunterschrauben? Dir würde doch ohne Probleme die Option offen stehen nur die vom Paketsystem der Distribution mitgelieferten Versionen zu nutzen, bei Bedarf ein tar.gz zu installieren oder ein Programm selbst zu kompilieren. Nur müssen würdest Du es nicht mehr..
Linux ist bei mir schon vor 15 Jahren auf dem Desktop angekommen. Auf Windows-Systemen komme ich mir hingegen regelmäßig vor wie in die Steinzeit zurückversetzt. Und nein, ich bin nicht bereits Linux in die Steinzeit zurückzubomben, nur damit es dann auch von Steinzeitmenschen genutzt werden kann.
Was genau führt den bei Dir dazu das Du Dich bei Windows auf dem Desktop in die Steinzeit zurückversetzt fühlst. Ich fühle mich zwar auch auf einen Linux Desktop (wobei für mich Gnome Shell und Unity keine Desktops sind) wohler, aber auch Windows hat in den letzten Jahren massive Fortschritte gemacht. Das was Du da von Dir gibst hört sich für mich wie fanatische Hasstiraden an die ganz ohne Argumente auskommen...
Wer Linux einsetzen möchte soll sich damit vertraut machen, dass es an entscheidenden Stellen anderen Konzepten folgt und darin die Stärke des Systems liegt. Wer einen Windows-Clone haben möchte ist hier falsch und soll besser dort bleiben wo er ist.
Wo ist den die Stärke darin den Anwender ohne jede Notwendigkeit einzuschränken, obwohl es dafür auch aus Sicherheits- und Stabilitätsgründen keinerlei Grund gibt? Du solltest Dich damit abfinden das Linux kein Nerd-Betriebssystem, nichts elitäres mehr ist. Dahingehend würde ich Dir eher OpenBSD oder NetBSD empfehlen.
Es liegt nicht an den Programmierern sondern an der Art der Softwareverteilung, das habe ich ausführlich in meinem letzten Kommentar erläutert.
Und liegt das an Windows oder an den Entwicklern der einzelnen Programme? Überlege doch mal was Du da schreibst! Microsoft hat doch keinen Einfluss darauf in welcher Form die einzelnen Anbieter ihre Software anbieten! Klar wäre auch mir ein zentrales System lieber, doch das dürfte in Windows bei den vielen Anbietern noch wesentlich schwieriger sein als bei Linux neben den einzelnen distributionsspezifischen Paketsystemen ein distributionsübergreifendes Paketsystem zu etablieren.
Es ist praktisch immer dann der Fall, wenn die Art der Softwareverteilung dem unter Windows üblichem Verfahren gleicht. Auch das habe ich in meinem letzten Kommentar ausführlich erläutert.
Und Du hast gelesen bzw. verstanden was ich mit 'distributionsübergreifenden Paketsystem' meine? Anscheinend nicht!
Auf dem Desktopmarkt?? Überlegen wir doch mal kurz, was wird ein Desktopnutzer wohl als erstes upgraden wollen? Richtig, seine Desktopoberfläche, sei es nun KDE, Gnome oder Xfce. Mit den dazugehörigen Abhängigkeiten hat er dann auf seinem Desktoprechner weit mehr als 50% der installierten Pakete ausgetauscht...
Und wieder nicht nachgedacht! Ich schrieb etwas von Anwendungsprogrammen. Dahingehend ist es sicher problematisch das die Desktops eben nicht nur aus der grafischen Oberfläche, dem nötigen Unterbau und einigen Basisprogrammen (z. B. Dateimanager, Konfigurationsprogrammen etc.) bestehen, sondern auch diverse andere Programme mit sich bringen. Doch auch diese kann man im Normalfall deinstallieren und wenn man die nötige Erfahrung hat neue Versionen installieren. Doch das ist für dem normalen Anwender recht schwierig und aufwändig. Eben das würde sich aber durch ein separates distributionsübergreifendes Paketsystem ändern. Aber offenbar bist Du ja nicht einmal bereit Dich auf die Idee einzulassen...
Auf was soll sie 5 Jahre Support bieten, auf die Bash und ein paar Kommandozeilentools? Recht viel mehr wird nämlich nicht übrig bleiben, sobald der Nutzer auf die Idee kommt den Desktop upzugraden.
Siehe oben, es geht nicht um den Desktop sondern höchstens um einzelne Anwendungsprogramme die der Desktop mit sich bringt. Sprich evtl. um eine neue Version von Thunderbird, Firefox oder GIMP. Aber irgendwie habe ich das Gefühl Du willst nicht verstehen...
Achja, wie viele Anwendungen setzt denn dein durchschnittlicher Linuxanwender ein, die nicht Teil eines Desktopsystems sind und deshalb unabhängig davon upgegraded werden können?
Auch hier offenbar nicht der Wille weiter zu denken. Wenn Du evtl. nochmal nachliest was ich geschrieben habe, dann wirst Du feststellen das ich von zwei Paketsystemen und unterschiedlichen Orten die Programme etc. abzuspeichern rede. In den weiter oben genannten Szenario hätte das bedeutet das Du eine ganz normale 5 Jahre lang unterstützte Distribution hättest bei der jeder ganz einfach aktuelle Software hinzu installieren kann. Beim zweiten genannten Szenario würde die Kerndistribution eben mit einigen Ausnahmen (z. B. Dateimanager oder Konfigurationsprogrammen) keine Programme beinhalten, aber über das zweite Paketsystem könnte jeder das was er will in der Version die er will installieren. Ubuntu würde dabei z. B. einen Zwischenweg gehen. Sprich die Programme im Kernbereich (main) würden fünf Jahre unterstützt, der Rest nicht. Aber das wäre auch kein Problem, da der Anwender über das zweite distributionsunabhängige Paketsystem neue Programmversionen bekommen könnte wenn er es wollte.
Nehmen wir doch mal ein 5 Jahre altes System her, das wurde mit KDE3 ausgeliefert. Was, wenn der Anwender jetzt ein aktuelles KMail haben möchte? Dumm gelaufen, das gibt es nur für KDE4. Und schon fällt dein wenig durchdachtes System auf die Nase.
Jain, fällt es nicht, da Du übersiehst das ich von zwei unterschiedlichen Paketsystemen mit unterschiedlichen Speicherorten ausgehe. Will jemand mit KDE3 das aktuelle KMail so können die nötigen Abhängigkeiten ebenfalls unter /opt/apps/... installiert werden. Sprich immer wenn eine neuere Version einer Komponente benötigt wird, ist es kein Problem sie parallel zu installieren. Sogar mehrere Versionen einer Bibliothek die untereinander nicht kompatibel sind wären möglich (das müsste unter Linux auch allgemein gehen, aber ich hatte es noch mit keinen Paketsystem zu tun das dahingehend wirklich gut umgesetzt ist). Klar kann man da Du KDE als Beispiel bringst noch anführen das die KDE-Komponenten wesentlich enger verzahnt sind als es bei Gnome 2.x der Fall war (bei Gnome 3 habe ich mich damit noch nicht beschäftigt). Aber ich denke auch die dadurch entstehenden Probleme wären zu meistern.
Das scheint mir auf einen "fresst Scheisse, millionen Fliegen können nicht irren"-Vergleich hinauszulaufen.
Für Dich ist der normale Anwender eine Fliege? Sorry das ist eine etwas arg engstirnige Sichtweise. Die meisten die Linux auf dem Desktop anwenden bzw. sich dafür interessieren wollen eine Alternative zu Windows. Eine Alternative bedeutet aber nicht das man sich erst jahrelang einarbeiten und durch unzählige kryptische Anleitungen etc. lesen muss.
Ich sehe es aus der Sichtweise eines langjährigen Linux-Nutzers der sich die Mühe gemacht hat die dahinterliegenden Konzepte zu verstehen und nicht aus der eines "ich will jetzt auch Linux haben, aber es muss genau so funktionieren wie Windows"-Nutzers.
Ich sehe das aus der Sichtweise eines ebenfalls langjährigen Linux-Nutzers (1995 habe ich meine ersten Gehversuche mit Linux gemacht, 1999 kam nur noch Linux zum Einsatz) der jedoch nicht den Kontakt zum normalen Anwender, seiner Sichtweise und seinen Ansprüchen verloren hat. Schon allein deshalb nicht da ich jeden Arbeitstag mit ihm zu tun habe.
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.
Von Programmierer sind schuld am Sa, 5. Mai 2012 um 11:56 #
Bei der meisten Software ist das möglich wenn die API bei einer Lib nicht komplett gebrochen wird, weil viele Programmierer oft nur einen kleinen Teil einer Lib nutzen der aus den Core Komponenten der API besteht, die sich über einen größeren Zeitraum kaum ändern. Die meisten Probleme aber entstehen allein dadurch, daß viel zu viele Programmierer in ihren Buildscripten neue Lib Versionen verlangen, obwohl sie gar nicht die neuen Funktionen dieser Lib einsetzen.
Sprich, wenn man in den Buildscripten die Prüfung der Versionsnummer auf genau die Version verändert, die die Software wirklich nutzt, dann lassen sich ca. 80 % der Programme compilieren, die ein compilieren verweigern, weil die Programmierer immer die neuste Lib fordern ohne es wirklich zu überprüfen.
Hier sollte man mal ansetzen. Programmierer sollten nicht ständig das neuste vom neusten fordern, sondern gucken, was ihre Software wirklich braucht und dann als Version den kleinsten gemeinsamen Nenner vorschreiben.
Damit könnte man beim Support der Pakete deutlich an Aufwand einsparen.
Ich habe eher gegenteilige Erfahrungen gemacht. Zumeist hat es einen Grund, warum eine bestimmte Version einer Library vorausgesetzt wird, z.B. weil diese eine Funktion aufweist welche genutzt wird oder ein Bug behoben wurde, welcher sich negativ auswirkt.
Persönlich halte ich 5 Jahre für den Desktop für passend. Aber es muss auch Backports aktueller Programme geben. Darüber hinaus bringt es recht wenig nur einen 'Kernsatz' von Programmen über 5 Jahre zu unterstützen, sondern es braucht dann schon die gesamte Distribution.
Der Gedanken kommt bei mir daher, das es viele Leute gibt die nicht aller ein, zwei Jahre ihr System neu installieren, aber dennoch aktuelle Software haben wollen. Und das kann man auf genau diesen Weg erreichen. Aller wie viel Jahre es ein solches LTS-Release gibt und wie weit sich die einzelnen LTS-Releases überschneiden, darüber mag man sich streiten.
Das ist technisch oftmals nur eine begrenzte Zeit möglich, da die meiste Software nicht eigenständig lauffähig ist, sondern Abhängigkeiten zu Bibliotheken und anderen Programmen besitzt. Nach einer gewissen Zeit hat man dadurch das halbe System ausgetauscht. Da kann man es gleich regulär upgraden.
Jain und das zeigt ausgerechnet Windows. Den selbst wenn ich Heute ein Programm kaufe ist es in der Regel zu Windows XP kompatibel. Und Windows XP ist immerhin 2001 auf den Markt gekommen. Und ja es ist klar das bei Windows XP durch die Servicepacks im Laufe der Zeit einiges angepasst wurde, aber die Grundstruktur hat sich nicht groß verändert.
Mir ist dabei klar das die Entwicklung von Linux wesentlich dynamischer und 'stürmischer' als die von Windows ist. Deshalb wäre es evtl. gut die Entwicklung des Grundsystems von einen Distributionsübergreifenden 'Backport-System' zu trennen. Sprich man hat auf der einen Seite ein Grundsystem mit dem das System und die dazugehörigen Programme gepflegt werden und daneben ein weiteres Distributionsübergreifendes Paketsystem das z. B. unter /opt/apps installiert wird und bei Bedarf seine Abhängigkeiten unabhängig vom System mit installiert. Wenn alle neuen Programmversionen in das Distributionübergreifende Paketsystem könnte dann sogar erlauben mehrere Programmversionen nebeneinander zu installieren und freilich könnte man unterschiedliche Sicherheitsfunktionen einbauen, um das Grundsystem zu schützen, dabei wäre vieles bis hin zu Sandboxen denkbar. Auf diese Weise könnte man ein stabiles Grundsystem und aktuelle Anwendungen miteinander vereinen. Wem dann gut durchgeprüfte und stabile Programme wichtiger ist als Aktualität, der verwendet weiterhin die Pakete die von dem Grundsystem zur Verfügung gestellten Versionen. So ein System hätte in meinen Augen große Vorteile, zumal man bei dem 'Distributionsübergreifenden Packetsystem auch die Möglichkeit einbauen könnte kommerzielle Programme zu erwerben und somit eine einheitliche Basis dafür schaffen würde, die für jeden einfach zu bedienen ist.
Eine Distro kann nicht ihre Libs einfrieren, wenn der Upstream trotzdem neuere, nicht abwärtskompatible Versionen der Libs nutzt. Die Distro muss dann einfach mitziehen, ob sie will oder nicht.
Wichtiger wäre es, eine Distro zu haben, die so einflussreich ist, dass Upstream-Entwickler nicht mehr Upstream-Libs als target nehmen, und sie dan ständig updaten, sondern die Libs die mit dieser Distro ausgeliefert werden. D.h. eine Distro, die so einflussreich ist im Linux-Ökosystem, dass sie die unkontrollierte und unkoordinierte Weiterentwicklung der Libs etwas verlangsamen und koordinieren kann.
Das große Problem bei Linux ist dass niemand das Sagen hat und die ganze Entwicklung deswegen völlig chaotisch verläuft. Das Linux-Ökosystem braucht deswegen einen starken "benevolent dictator", der den Ton angibt und das Library-Chaos zügelt. Windows kann diese Jahrzehnte überbrückenden Abwärtskompatibilität nur deswegen erreichen, weil Microsoft das will und stark genug ist, das durchzusetzen, weil sie alle Libs selber kontrollieren.
Deswegen hoffe ich persönlich dass in der Linux-Welt Ubuntu "gewinnt" und dann aufhört, die grundlegenden Libs ständig zu aktualisieren. Dann, erst dann, wird es auch für andere Distris möglich sein und einen kundenfreundlicheren, mehr konservativen Kurs zu fahren auf das nervige cutting edge zu verzichten. Dann werden auch keine "Backports" mehr benötigt, weil die target-libs 5-10 Jahre eh immer die gleichen sind. Dann entfällt auch der job des "packagers", weil jeder Entwickler seine Pakete selber bauen kann. Usw. Der ewige Updatewahn muss endlich aufhören.
Die ganzen Probleme ergeben sich wirklich nur aus der fehlenden Koordination. Wie man bisher gesehen hat, ist die Koordination nicht durch Konsens machbar, weil die Distris sich auf gar nichts einigen können. Linux braucht eine Diktatur. Nicht nur auf Kernelebene, wo sich hervorragend zeigt wie nützlich ein Diktator sein kann, sondern auch auf Distri-Ebene. Mein Wunschdiktator ist der Shuttleworth.
+1
auch wenn es dann wieder Idioten geben wird, die Linux und alles forken und im Endeffekt noch mehr Chaos herrscht.
Andererseits: Es ist alles kostenlos und sogar mehr als das, also ist es schon bemerkenswert, dass es schon in der DERZEITIGEN FOrm so existiert. Das Problem ist halt: Es sind die Produkte aus DEM Hobby der Nerds. Und im Hobbysbereich probiert man eben immer neues und macht ungern das gleiche. Solange die Entwickler Hobbyentwickler sind, wird sich daran auch NIE etwas ändern, weil die sonst ihren Spaß daran verlieren würden (Managment, Dokumentation, Planung, Pflege alter Version, .. Nerds programmieren lieber einfach drauf los, schreiben neu, weiter drauf los nochmals alles neu).
Dein Ziel wird man nur erreichen, wenn sich der Kommerz das Linux-Ökosystem schnappt und daraus etwas eigenes, konsistentes baut, wie Apple es zuvor mit FreeBSD gemacht hat.
Debian ist schon DIE Referenz und friert alles ein. Im Upstream macht sich das NULL bemerkbar. Es sind eben Hobbyprogrammierer, die teilweise aus Egoismus programmieren: Aus eigenem Vergnügen und nur das, was Spaß macht. Pflege alter Version, Managment und Vorausplanung machen keinen Spaß.
> Debian ist schon DIE Referenz und friert alles ein.
Debian friert aber auch die Apps ein, und niemand kann jahrelang etwas updaten, und deswegen ist es immer veraltet und deswegen nutzt es niemand auf dem Desktop und deswegen ignoriert der app-stream debian als target weil es keine nutzer hat.
Debians ansatz mit dem einfrieren ist prinzipiell richtig, aber sie frieren _zuviel_ ein. Sie frieren alles ein und man muss dann um Backports betteln. Sie frieren sich zu Tode.
> Pflege alter Version, Managment und Vorausplanung machen keinen Spaß.
Ich würde gerne für ein Linux bezahlen, wo ich einmal eine neue "Version" des Grundsystems installiere, und dann 5-10 Jahre lang neue apps für dieses system-version bekomme ohne das System selber updaten zu müssen. Nach dem Motto "Shut up and take my money!". Aber niemand lässt mich dafür bezahlen.
Volle Zustimmung.
Debian sollte eine Unterscheidung zwischen Core System und Desktopanwendungen machen und diese unterschiedlich behandeln.
Bloß nicht!
Ihm verdanken wie Unity und den Dreck mit den Buttons an der falschen Seite.
Und anstatt einen Diktator hätte ich hier lieber eine kleine demokratische Organisation, die das Grundsystem festlegt.
Im Prinzip gibt's das auch schon in Form der LSB, nur bringt das halt nichts, wenn sich kein Open Source Programmierer daran halten will, weil er meint, als OSS Programmierer bräuchte er die LSB nicht.
Aber das mit dem "Programmierer wollen nur cutting edge" hast du schon richtig herauskristallisiert.
Hier liegt das Problem.
Zum anderen kann man es aber auch verstehen.
Als Programmierer will man deswegen die neuste API Funktion nutzen, weil man befürchten muss, dass die alte irgendwann Obsolete wird und dann macht man sich doppelte Arbeit, wenn man zuerst die alte nutzt um Rücksicht auf LTS Distributionen zu nehmen und dann später trotzdem das ganze Programm wieder an die neue API Funktionen anpassen muss.
Die eigentliche Lösung wäre also, die APIs und ganzen Libs selbst langzeitstabil zu machen,
da sich aber in der Softwareentwicklung immer noch so viel ändert,
gerade beim Desktop Environment und der Art und Weise wie GUIs erstellt werden, früher fest im Quellcode, heute mit CSS und HTML oder ähnliches, ist das kein Wunder.
Die eigentliche Frage wird also sein, ob es in 10 Jahren auch noch so große Umbrüche in der Art der Softwareentwicklung gibt wie heute, wenn man das verneinen kann, dann liegen langzeitstabile APIs für Desktopanwendungen im Bereich der Möglichkeit.
-10
Nein, die Stärke von Linux ist die Vielfalt. Wir können ja wegen Euch Clowns auch sämtliche Birn, Pflaumen und nutzlosen anderen Bäumen abholzen. Apfelbäume reichen für alle aus.
Offenbar hat man dir ins Gehirn geschissen, denn ohne Beleidigung scheinst du deinen Beitrag nicht schreiben zu können.
Das sind mal wieder die nicht vorhandenen Sozialkompetenzen, die Linuxer haben.
Mit deinen Solzialkompetenzen kann es ja auch nicht so weit her sein, wenn du von einem auf alle schließt
Mir war klar, dass der Windows-Vergleich kommen wird und damit Dinge verglichen werden, die unterschiedlicher nicht sein könnten.
Meines Erachtens ging es bei dieser Diskussion um Distributionen. Mir ist jedoch keine Windows-Distribution, also eine Quelle wo ich alles sauber aufeinander abgestimmt aus einer Hand erhalten würde, bekannt.
Jede Windows-Software bringt ihre eigenen, zur Laufzeit benötigten Bibliotheken mit und installiert diese auf dem System, mit all den daraus resultierenden Nachteilen. Beispielsweise wird damit das Konzept der dynamisch gelinkten Libraries welche sich nur einmal im Speicher befinden müssen aber von zahlreichen Programmen gleichzeitig genutzt werden können ad absurdum geführt. An den Sicherheits-Albtraum, wenn sich die selbe verwundbare Bibliothek zigfach auf dem System befindet, erst garnicht zu denken.
Selbiges kannst du auch unter Linux bekommen, schau dir z.B. Google Earth an oder die vom Humble Indie Bundle veröffentlichten Spiele. Das Prinzip und die Nachteile sind die selben wie unter Windows. Sicher, man kann so vorgehen um eine Software möglichst unabhängig von der verwendeten Distribution zum Laufen zu bekommen und ohne den Quellcode rausrücken zu müssen. Ein erstrebenswertes Konzept für eine Distribution ist es jedoch nicht.
Eine Distribution kann so nicht vorgehen, denn dies würde in die Kategorie Pfusch fallen. Von einer Distribution wird zurecht erwartet, dass es die Software ins System integriert und nicht am System vorbei betreibt.
Immer diese Mär. Bei der von dir genannten Windows-Version wurde der Support 2005 eingestellt. Seitdem sind keine Sicherheitsupdates mehr erhältlich und zahlreiche Software ist damit nicht mehr lauffähig.
Windows XP SP3 hat mit der ursprünglichen Windows XP-Version aus 2001 nicht mehr viel zu tun. Nicht umsonst ist es Voraussetzung um überhaupt noch Sicherheitsupdates vom Hersteller zu erhalten und wird von zahlreicher Software vorausgesetzt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 05. Mai 2012 um 15:04.Mir war klar, dass der Windows-Vergleich kommen wird und damit Dinge verglichen werden, die unterschiedlicher nicht sein könnten.
Das ist dem normalen Anwender letztendlich absolut egal! Und der normale Anwender stellt nun einmal die Masse der Anwender. Er will ein System das über lange Zeit funktioniert, ihm ermöglicht die Programme und Programmversionen die er installieren will auch einfach und bequem installieren zu können und darüber hinaus will er so wenig wie möglich mit den Systeminnereien, der Sicherheitsproblematik etc. zu tun haben. Und glaube mir das ist so, ich habe jeden Tag auf der Arbeit mit diesen Typ Anwender zu tun.
Meines Erachtens ging es bei dieser Diskussion um Distributionen. Mir ist jedoch keine Windows-Distribution, also eine Quelle wo ich alles sauber aufeinander abgestimmt aus einer Hand erhalten würde, bekannt.
Und soll man deshalb den Anspruch herunterschrauben? Will man auf dem Desktopmarkt vorankommen oder nicht? Mir kommt es des öfteren vor als wäre letzteres der Fall. Vorankommen wird man erst wenn man mehr standardisiert und vereinheitlicht und mehr auf die Wünsche und Bedürfnisse der normalen Anwender eingeht.
Jede Windows-Software bringt ihre eigenen, zur Laufzeit benötigten Bibliotheken mit und installiert diese auf dem System, mit all den daraus resultierenden Nachteilen. Beispielsweise wird damit das Konzept der dynamisch gelinkten Libraries welche sich nur einmal im Speicher befinden müssen aber von zahlreichen Programmen gleichzeitig genutzt werden können ad absurdum geführt. An den Sicherheits-Albtraum, wenn sich die selbe verwundbare Bibliothek zigfach auf dem System befindet, erst garnicht zu denken.
Selbiges kannst du auch unter Linux bekommen, schau dir z.B. Google Earth an oder die vom Humble Indie Bundle veröffentlichten Spiele. Das Prinzip und die Nachteile sind die selben wie unter Windows. Sicher, man kann so vorgehen um eine Software möglichst unabhängig von der verwendeten Distribution zum Laufen zu bekommen und ohne den Quellcode rausrücken zu müssen. Ein erstrebenswertes Konzept für eine Distribution ist es jedoch nicht.
Auch bei Windows gibt es die Möglichkeit Bibliotheken und andere Komponenten gemeinsam zu nutzen. Das das Konzept bei Windows nicht so häufig genutzt wird liegt wohl eher an den Gewohnheiten der Programmierer als daran das es nicht geht. Es gibt darüber hinaus wie Du sehr schön ausgeführt hast auch unter Linux Beispiele von statisch eingebundenen, aber das ist glücklicherweise eher selten. Aber es zeigt doch das es auch hier an den Programmierern liegt. An sich spricht das aber für meine Idee des 'Distributionsübergreifenden Paketsystems neben dem Paketsystem der Distribution', den das ermöglicht es auch auf recht alten Systemen aktuelle Software zu installieren ohne alle entsprechenden Abhängigkeiten erneut und erneut installieren zu müssen.
Eine Distribution kann so nicht vorgehen, denn dies würde in die Kategorie Pfusch fallen. Von einer Distribution wird zurecht erwartet, dass es die Software ins System integriert und nicht am System vorbei betreibt.
Eine Distribution kann wie nicht vorgehen? So wie ich es skizziert habe das die Distribution fünf Jahre Support bietet und darüber hinaus ein zweites Paketsystem das seine Pakete unter /opt/apps installiert (es wären auch benutzerspezifische Installationen unter ~/apps oder ~/.apps denkbar). Eine Alternative wäre das die Distribution praktisch den Unterbau und die Grafische Benutzeroberfläche liefert, die Anwendungsprogramme aber aus einen zentralen distributionsübergreifenden Repository kommen und dort immer aktuell verfügbar sind. Natürlich auch mit Fehlerbehebungen.
Immer diese Mär. Bei der von dir genannten Windows-Version wurde der Support 2005 eingestellt. Seitdem sind keine Sicherheitsupdates mehr erhältlich und zahlreiche Software ist damit nicht mehr lauffähig.
Windows XP SP3 hat mit der ursprünglichen Windows XP-Version aus 2001 nicht mehr viel zu tun. Nicht umsonst ist es Voraussetzung um überhaupt noch Sicherheitsupdates vom Hersteller zu erhalten und wird von zahlreicher Software vorausgesetzt.
Und ändert das etwas daran das selbst Heute noch die allermeiste Software die neu auf den Markt kommt auf einen aktuellen Windows (ja und Servicepacks gehören dazu) läuft? Ändert das etwas für den normalen Anwender? Es ist schön das Du es aus der Ebene der Nerds siehst, aber die breite Mehrheit der Anwender gehört nun einmal nicht dieser 'elitären' Gruppe an.
Dein sogenannter "normaler Anwender" möchte Windows einsetzen weil er Windows gewöhnt ist und ihm die Weitsicht fehlt, sich auf ein anderes System mit anderen Konzepten einzulassen. Dieser Anwender hat nichts in der Linux-Welt verloren, er soll sein Windows einsetzen und damit glücklich werden.
Jeder andere normale Anwender wird froh sein, dass er sich seine Software nicht aus mehr oder minder dubiosen Quellen zusammensuchen muss, dabei jedesmal die persönlichen Daten auf seinem Rechner potentiell gefährdet, sich unbekannten Risiken und Nebenwirkungen des Zusammenspiels unterschiedlicher Software aussetzt und die Software auch nicht mehr rückstandslos von seinem Rechner bekommt. Dieser Anwender ist froh, dass ihm seine Distribution die Arbeit abnimmt, er getestete und auf seine Umgebung optimal abgestimmte Software aus zentraler Quelle erhält, die er falls gewünscht auch wieder rückstandslos entfernen kann.
Das ist genau das wovon ich Rede. Ich bin nicht bereit meine Ansprüche auf das Windows-Niveau herunterzuschrauben!
Linux ist bei mir schon vor 15 Jahren auf dem Desktop angekommen. Auf Windows-Systemen komme ich mir hingegen regelmäßig vor wie in die Steinzeit zurückversetzt. Und nein, ich bin nicht bereits Linux in die Steinzeit zurückzubomben, nur damit es dann auch von Steinzeitmenschen genutzt werden kann.
Wer Linux einsetzen möchte soll sich damit vertraut machen, dass es an entscheidenden Stellen anderen Konzepten folgt und darin die Stärke des Systems liegt. Wer einen Windows-Clone haben möchte ist hier falsch und soll besser dort bleiben wo er ist.
Es liegt nicht an den Programmierern sondern an der Art der Softwareverteilung, das habe ich ausführlich in meinem letzten Kommentar erläutert.
Es ist praktisch immer dann der Fall, wenn die Art der Softwareverteilung dem unter Windows üblichem Verfahren gleicht. Auch das habe ich in meinem letzten Kommentar ausführlich erläutert.
Auf dem Desktopmarkt?? Überlegen wir doch mal kurz, was wird ein Desktopnutzer wohl als erstes upgraden wollen? Richtig, seine Desktopoberfläche, sei es nun KDE, Gnome oder Xfce. Mit den dazugehörigen Abhängigkeiten hat er dann auf seinem Desktoprechner weit mehr als 50% der installierten Pakete ausgetauscht...
Auf was soll sie 5 Jahre Support bieten, auf die Bash und ein paar Kommandozeilentools? Recht viel mehr wird nämlich nicht übrig bleiben, sobald der Nutzer auf die Idee kommt den Desktop upzugraden.
Achja, wie viele Anwendungen setzt denn dein durchschnittlicher Linuxanwender ein, die nicht Teil eines Desktopsystems sind und deshalb unabhängig davon upgegraded werden können?
Nehmen wir doch mal ein 5 Jahre altes System her, das wurde mit KDE3 ausgeliefert. Was, wenn der Anwender jetzt ein aktuelles KMail haben möchte? Dumm gelaufen, das gibt es nur für KDE4. Und schon fällt dein wenig durchdachtes System auf die Nase.
Das scheint mir auf einen "fresst Scheisse, millionen Fliegen können nicht irren"-Vergleich hinauszulaufen.
Ich sehe es aus der Sichtweise eines langjährigen Linux-Nutzers der sich die Mühe gemacht hat die dahinterliegenden Konzepte zu verstehen und nicht aus der eines "ich will jetzt auch Linux haben, aber es muss genau so funktionieren wie Windows"-Nutzers.
Das kannst Du getrost abschreiben. Auch wenn das vielen nicht gefallen dürfte darf man das Ubuntu Linux zuschreiben. Den das wurde zwar oft aus der Community kritisiert weil es sich was Codebeiträge betrifft zurückhält, aber was die Bekanntheit von Linux bei der Allgemeinheit betrifft hat Ubuntu das geleistet was anderen Distributionen und der Community über Jahren nicht gelungen ist.
Das was Du hier nennst ist schön und gut. Doch was genau bringt es dem normalen Anwender wenn er die aktuelle Version z. B. von einen Browser haben will? Was bringt es ihm wenn Distributionen zwar Sicherheitslücken fixen, aber den nervigen Bug der das Programm in Teilen unbrauchbar macht wegen fehlender Sicherheitsrelevanz nicht? Linux muss wenn es sich im Desktopbereich ausbreiten will den Ansprüchen der Anwender anpassen und es besser machen als Windows. Was btw. die Rückstandslosigkeit betrifft ist das so eine Sache. Man muss dann nämlich doch wieder ins Terminal um alles weg zu bekommen. Ich rede von mit installierten Abhängigkeiten und von Konfigurationsdateien. Und genau das wollen die meisten Anwender nicht. Den da stimmen wir wohl überein, das Terminal ist für Leute die wissen was sie tun.
Wo müsstest Du den bei den von mir skizzierten Modell Deine Ansprüche herunterschrauben? Dir würde doch ohne Probleme die Option offen stehen nur die vom Paketsystem der Distribution mitgelieferten Versionen zu nutzen, bei Bedarf ein tar.gz zu installieren oder ein Programm selbst zu kompilieren. Nur müssen würdest Du es nicht mehr..
Was genau führt den bei Dir dazu das Du Dich bei Windows auf dem Desktop in die Steinzeit zurückversetzt fühlst. Ich fühle mich zwar auch auf einen Linux Desktop (wobei für mich Gnome Shell und Unity keine Desktops sind) wohler, aber auch Windows hat in den letzten Jahren massive Fortschritte gemacht. Das was Du da von Dir gibst hört sich für mich wie fanatische Hasstiraden an die ganz ohne Argumente auskommen...
Wo ist den die Stärke darin den Anwender ohne jede Notwendigkeit einzuschränken, obwohl es dafür auch aus Sicherheits- und Stabilitätsgründen keinerlei Grund gibt? Du solltest Dich damit abfinden das Linux kein Nerd-Betriebssystem, nichts elitäres mehr ist. Dahingehend würde ich Dir eher OpenBSD oder NetBSD empfehlen.
Und liegt das an Windows oder an den Entwicklern der einzelnen Programme? Überlege doch mal was Du da schreibst! Microsoft hat doch keinen Einfluss darauf in welcher Form die einzelnen Anbieter ihre Software anbieten! Klar wäre auch mir ein zentrales System lieber, doch das dürfte in Windows bei den vielen Anbietern noch wesentlich schwieriger sein als bei Linux neben den einzelnen distributionsspezifischen Paketsystemen ein distributionsübergreifendes Paketsystem zu etablieren.
Und Du hast gelesen bzw. verstanden was ich mit 'distributionsübergreifenden Paketsystem' meine? Anscheinend nicht!
Und wieder nicht nachgedacht! Ich schrieb etwas von Anwendungsprogrammen. Dahingehend ist es sicher problematisch das die Desktops eben nicht nur aus der grafischen Oberfläche, dem nötigen Unterbau und einigen Basisprogrammen (z. B. Dateimanager, Konfigurationsprogrammen etc.) bestehen, sondern auch diverse andere Programme mit sich bringen. Doch auch diese kann man im Normalfall deinstallieren und wenn man die nötige Erfahrung hat neue Versionen installieren. Doch das ist für dem normalen Anwender recht schwierig und aufwändig. Eben das würde sich aber durch ein separates distributionsübergreifendes Paketsystem ändern. Aber offenbar bist Du ja nicht einmal bereit Dich auf die Idee einzulassen...
Siehe oben, es geht nicht um den Desktop sondern höchstens um einzelne Anwendungsprogramme die der Desktop mit sich bringt. Sprich evtl. um eine neue Version von Thunderbird, Firefox oder GIMP. Aber irgendwie habe ich das Gefühl Du willst nicht verstehen...
Auch hier offenbar nicht der Wille weiter zu denken. Wenn Du evtl. nochmal nachliest was ich geschrieben habe, dann wirst Du feststellen das ich von zwei Paketsystemen und unterschiedlichen Orten die Programme etc. abzuspeichern rede. In den weiter oben genannten Szenario hätte das bedeutet das Du eine ganz normale 5 Jahre lang unterstützte Distribution hättest bei der jeder ganz einfach aktuelle Software hinzu installieren kann. Beim zweiten genannten Szenario würde die Kerndistribution eben mit einigen Ausnahmen (z. B. Dateimanager oder Konfigurationsprogrammen) keine Programme beinhalten, aber über das zweite Paketsystem könnte jeder das was er will in der Version die er will installieren. Ubuntu würde dabei z. B. einen Zwischenweg gehen. Sprich die Programme im Kernbereich (main) würden fünf Jahre unterstützt, der Rest nicht. Aber das wäre auch kein Problem, da der Anwender über das zweite distributionsunabhängige Paketsystem neue Programmversionen bekommen könnte wenn er es wollte.
Jain, fällt es nicht, da Du übersiehst das ich von zwei unterschiedlichen Paketsystemen mit unterschiedlichen Speicherorten ausgehe. Will jemand mit KDE3 das aktuelle KMail so können die nötigen Abhängigkeiten ebenfalls unter /opt/apps/... installiert werden. Sprich immer wenn eine neuere Version einer Komponente benötigt wird, ist es kein Problem sie parallel zu installieren. Sogar mehrere Versionen einer Bibliothek die untereinander nicht kompatibel sind wären möglich (das müsste unter Linux auch allgemein gehen, aber ich hatte es noch mit keinen Paketsystem zu tun das dahingehend wirklich gut umgesetzt ist). Klar kann man da Du KDE als Beispiel bringst noch anführen das die KDE-Komponenten wesentlich enger verzahnt sind als es bei Gnome 2.x der Fall war (bei Gnome 3 habe ich mich damit noch nicht beschäftigt). Aber ich denke auch die dadurch entstehenden Probleme wären zu meistern.
Für Dich ist der normale Anwender eine Fliege? Sorry das ist eine etwas arg engstirnige Sichtweise. Die meisten die Linux auf dem Desktop anwenden bzw. sich dafür interessieren wollen eine Alternative zu Windows. Eine Alternative bedeutet aber nicht das man sich erst jahrelang einarbeiten und durch unzählige kryptische Anleitungen etc. lesen muss.
Ich sehe das aus der Sichtweise eines ebenfalls langjährigen Linux-Nutzers (1995 habe ich meine ersten Gehversuche mit Linux gemacht, 1999 kam nur noch Linux zum Einsatz) der jedoch nicht den Kontakt zum normalen Anwender, seiner Sichtweise und seinen Ansprüchen verloren hat. Schon allein deshalb nicht da ich jeden Arbeitstag mit ihm zu tun habe.
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.
Bei der meisten Software ist das möglich wenn die API bei einer Lib nicht komplett gebrochen wird, weil viele Programmierer oft nur einen kleinen Teil einer Lib nutzen der aus den Core Komponenten der API besteht, die sich über einen größeren Zeitraum kaum ändern.
Die meisten Probleme aber entstehen allein dadurch, daß viel zu viele Programmierer in ihren Buildscripten neue Lib Versionen verlangen, obwohl sie gar nicht die neuen Funktionen dieser Lib einsetzen.
Sprich, wenn man in den Buildscripten die Prüfung der Versionsnummer auf genau die Version verändert, die die Software wirklich nutzt, dann lassen sich ca. 80 % der Programme compilieren, die ein compilieren verweigern, weil die Programmierer immer die neuste Lib fordern ohne es wirklich zu überprüfen.
Hier sollte man mal ansetzen.
Programmierer sollten nicht ständig das neuste vom neusten fordern, sondern gucken, was ihre Software wirklich braucht und dann als Version den kleinsten gemeinsamen Nenner vorschreiben.
Damit könnte man beim Support der Pakete deutlich an Aufwand einsparen.
Ich habe eher gegenteilige Erfahrungen gemacht. Zumeist hat es einen Grund, warum eine bestimmte Version einer Library vorausgesetzt wird, z.B. weil diese eine Funktion aufweist welche genutzt wird oder ein Bug behoben wurde, welcher sich negativ auswirkt.
Offenbar liest du nicht was ich geschrieben habe.
?!?