OpenSuse ist doch eher eine Art von beständig fortentwickeltem SLES-Entwicklungssnapshot, so z.B. OpenSuse 11.1 für SLES 11 bzw. SLED 11. Die Prioritäten sind hier ähnliche wie bei Fedora und RedHat.
Du vergißt das LTS von Canonical - ähem: Ubuntu.
Du meinst wahrscheinlich, dass sich die großen Distributoren vorher ein wenig absprechen sollten, damit z.B. alle Distros zu gegebener Zeit nicht nur zufällig mit einem längerfristig unterstützten Kernel 2.6.27 herauskommen.
Hat der kleine Mark Shuttleworth ja den großen Playern im Enterprise Bereich - RedHat und Novell - auch schon vorgeschlagen (wohl, um mit seinem Long Term Support Angebot von deren Maintenance zu profitieren) - ist aber bislang (warum wohl?) gescheitert.
Dazu noch ein Distro-Cross-Paketinstallationstool, um etwa Debian-/Ubuntu-Software unter OpenSuse und Fedora und die OpenSuse-Buildservice-Software unter Ubuntu und Fedora nutzen zu können, mit einem Klick versteht sich.
Tools und Ansätze dazu gibt es ja schon zuhauf. Mir fällt z.B. spontan der FHS oder autopackage ein.
Die Tatsache, das die Jungs vom LSB inzwischen sowohl Testwerkzeuge als auch einen eigenen (openSUSE) Buildservice anbieten, zeigt in meinen Augen, dass sich da nichts tun wird, solange "die großen 5" - auch um sich von der Konkurrenz abzuheben - nicht an einem Strang ziehen. Und da in der Open Source Welt jeder Guru irgendwann zum Gott wird und seinen Arbeitgeber mit Argumenten zu überzeugen weiß warum sein Paketmanager/Compiler/Webserver/Mailserver/... besser ist als der der anderen, wird sich daran wohl auch nichts ändern. Ich persönlich finde das aber auch nicht so schlimm: schließlich belebt Wettbewerb das Geschäft. Wenn alle Distributionen z.B. nur noch .deb Pakete verwenden würden, gäbe es mit einem Schlag nicht nur weniger Entwickler, die sich mit Paketmanagement auskennen (nein: nicht alle RPM Entwickler werden apt-Entwickler) - der Innovationsdruck, der von einem speziellen RPM oder Slackware-Feature ausgeht, würde auch die weitere Entwicklung von dep-Paketen bremsen.
"Warum soll ich das implementieren? Damit geht doch bestimmt was kaputt! Das will/braucht doch keiner!" Hat bestimmt fast jeder schon gehört... Nun stellen wir Anwender uns mal vor, es würde keine Alternative (zu Microsoft?) geben. Wo wären dann all unsere schönen Argumente?
Du vergißt das LTS von Canonical - ähem: Ubuntu.
Du meinst wahrscheinlich, dass sich die großen Distributoren vorher ein wenig absprechen sollten, damit z.B. alle Distros zu gegebener Zeit nicht nur zufällig mit einem längerfristig unterstützten Kernel 2.6.27 herauskommen.
Hat der kleine Mark Shuttleworth ja den großen Playern im Enterprise Bereich - RedHat und Novell - auch schon vorgeschlagen (wohl, um mit seinem Long Term Support Angebot von deren Maintenance zu profitieren) - ist aber bislang (warum wohl?) gescheitert.
Dazu noch ein Distro-Cross-Paketinstallationstool, um etwa Debian-/Ubuntu-Software unter OpenSuse und Fedora und die OpenSuse-Buildservice-Software unter Ubuntu und Fedora nutzen zu können, mit einem Klick versteht sich.
Tools und Ansätze dazu gibt es ja schon zuhauf. Mir fällt z.B. spontan der FHS oder autopackage ein.
Die Tatsache, das die Jungs vom LSB inzwischen sowohl Testwerkzeuge als auch einen eigenen (openSUSE) Buildservice anbieten, zeigt in meinen Augen, dass sich da nichts tun wird, solange "die großen 5" - auch um sich von der Konkurrenz abzuheben - nicht an einem Strang ziehen. Und da in der Open Source Welt jeder Guru irgendwann zum Gott wird und seinen Arbeitgeber mit Argumenten zu überzeugen weiß warum sein Paketmanager/Compiler/Webserver/Mailserver/... besser ist als der der anderen, wird sich daran wohl auch nichts ändern. Ich persönlich finde das aber auch nicht so schlimm: schließlich belebt Wettbewerb das Geschäft. Wenn alle Distributionen z.B. nur noch .deb Pakete verwenden würden, gäbe es mit einem Schlag nicht nur weniger Entwickler, die sich mit Paketmanagement auskennen (nein: nicht alle RPM Entwickler werden apt-Entwickler) - der Innovationsdruck, der von einem speziellen RPM oder Slackware-Feature ausgeht, würde auch die weitere Entwicklung von dep-Paketen bremsen.
"Warum soll ich das implementieren? Damit geht doch bestimmt was kaputt! Das will/braucht doch keiner!" Hat bestimmt fast jeder schon gehört... Nun stellen wir Anwender uns mal vor, es würde keine Alternative (zu Microsoft?) geben. Wo wären dann all unsere schönen Argumente?