Sieht mir sehr stark nach UnitedLinux aus. Damals wollte sich Mandrake noch nicht beteiligen und heute machen sie eine eigene Allianz. Hoffe nur, dass es diesmal besser wird.
Wie wollen sie eigentlich einen Standard schaffen und zwei verschiedene Paket-Systeme verwenden? Nur so. Eine Frage.
Sie wollen wie ich das verstehe keinen Standard schaffen. Den gibt es schon und der heist LSB 2.0. Dieser Zusammenschluß will eine gemeinsame "Grunddistribution" auf Basis der LSB erstellen, auf der dann die Hersteller ihre eigenen Distributionen aufbauen.
Sie wollen wie ich das verstehe keinen Standard schaffen. Den gibt es schon und der heist LSB 2.0. Dieser Zusammenschluß will eine gemeinsame "Grunddistribution" auf Basis der LSB erstellen, auf der dann die Hersteller ihre eigenen Distributionen aufbauen.
Berichtige mich aber ist Mandrake nicht irgendwan mal aus Redhat hervorgegangen, Progenie Debian basiert und Turbolinux sowie Connective verfolgten eigene Wege? Wen diee Distris eine gemeinsame Basis schaffen wollen müssen sie entweder etwas ganz neues schaffen oder alle ordnen sich dem System eines einzelnen unter.
Aber Schreck bei Seite. Es geht um eine gemeinsame Basis implementierung. Das muß noch lange nicht bedeuten das sie eine Basis schaffen wollen auf der alles aufbaut sondern bedeutet in meinen Augen viel mehr das sie versuchen die LSB 2.0 auf die selbe Weise in ihrer jeweiligen Distribution umzusetzen.
Ne, im ernst: Schön das es bei der Zusammenarbeit weitergeht, nach UnitedLinux sah es ja etwas düster aus. In sachen Verbund haben alle ja wohl auch gelernt, diesmal etwas weniger Steif, dann kann es auch nicht so fix brechen ;)
Wobei ich etwas überrascht bin das eine Debian Distrie dabei ist, bin gespannt wie das harmonisiert.
Von romantic gorilla am Mi, 17. November 2004 um 21:09 #
> Wobei ich etwas überrascht bin das eine Debian Distrie dabei ist, bin gespannt wie das harmonisiert.
meinst du das unterschiedliche paketformat? so wie ich das im vortrag von theodore ts'o (richtig geschrieben?) verstanden habe, setzt lsb zwar auf rpm, aber nur auf einen sehr kleinen gemeinsamen nenner daraus. simpel genug, um rpm-pakete "1:1" in deb-pakete umwandeln zu können. durch diesen kniff wäre dann garantiert, dass lsb-konforme rpms auch unter debian laufen.
Von Daniel Baumann am Mi, 17. November 2004 um 21:58 #
"theodore ts'o (richtig geschrieben?)"
ja.
"kleinen gemeinsamen nenner daraus. simpel genug, um rpm-pakete "1:1" in deb-pakete umwandeln zu können."
nein, um lsb konform zu sein, muss rpm oder ein vollstaendig rpm-kompatibler package-manager nachinstallierbar sein. alien zaehlt nicht (informationsverlust), bisher gibt es noch keinen 100%-igen wrapper fuer rpm nach $package_format und umgekehrt, weshalb die meisten distributionen die loesung vorziehene, zur lsb-konformitaet rpm optional nachinstallierbar zu machen (die denn kein rpm als default-format benutzen).
Debian wird da ausdrücklich mit erwähnt aber ich seh Debian garnicht als Partner. Hat Progeny soviel Einfluß auf die Debiandistri daß sie selbst garnicht Partner sein muß um die angestrebten Ziele zu erreichen oder gilt das ganze nur für Progenys Distri?
Von Extended Anonymous am Mi, 17. November 2004 um 16:25 #
Wie hoch sind denn die Chancen, das GUI Toolkits wie z,B. GTK+ 2.x in die LSB Spezifikation mit aufgenommen werden?
Momentan gibt es bezüglich GUI Librarys leider nur die ganzen X Librarys und OpenGL in der LSB 2.01 Spezifikation, aber wer will schon seine GUI mit den reinen X Librarys schreiben wenn es viel programmierfreundlichere Toolkits wie z.B. GTK+ 2.x gibt?.
imho wäre es schwachsinn ein Tookit in den Standard auzunehmen. Warum willst du Leute dazu "zwingen" ein bestimmtes Toolkit zu verwenden. Egal für welches Toolkit du dich entscheidest, du stößt damit immer einer großen Hacker Gemeinde vor den Kopf.
> GTK+ koennte man genauso 'sanft erzwingen' wie die LSB es bereits mit RPM getan hat.
Könnte man vielleicht machen, allerdings halte ich davon genauso wenig wie davon das RPM in dem Standard vorkommt. Ich denke der LSB wäre ein Erfolg, wenn man in Zukunft sicher wüßte wo man unabhängig von der Distribution eine config-Datei findet oder wo welche Programmdateien hininstalliert wurden. Ob dann jemand das Programm mit GTK+, Qt,... schreibt und ob er es letztlich in ein tar.gz mit einem install script, rpm oder deb Packet packt ist doch vollkommen egal und sollte auch nicht im LSB geregelt werden. Wenn man versucht solche Sachen vorzuschreiben verhindert man imho nur den Erfolg des LSB. Ich denke jeder lässt sich in einem breiten Konsens "vorschreiben" wo jetzt eine conf Datei hin kommt oder in welches Verzeichnis jetzt welche Programmteile kommen. Aber die wenigsten werden sich vorschreiben lassen wie sie ihre Programme einpacken und schon garnicht mit welchem Toolkit sie es schreiben.
Von Daniel Baumann am Mi, 17. November 2004 um 21:49 #
"allerdings halte ich davon genauso wenig wie davon das RPM in dem Standard vorkommt."
Es kommt vor, ist aber nicht zwingend da. Es muss dann nur $den_anderen_paketmanager nachinstallierbar sein. Selbiges kann man mit GTK ebenfalls machen.
"Ich denke der LSB wäre ein Erfolg, wenn man in Zukunft sicher wüßte wo man unabhängig von der Distribution eine config-Datei findet oder wo welche Programmdateien hininstalliert wurden."
Das tut sie bereits seit 1.x.
"Aber die wenigsten werden sich vorschreiben lassen wie sie ihre Programme einpacken und schon garnicht mit welchem Toolkit sie es schreiben."
Soll sie und will sie auch gar nicht (siehe oben).
Die LSB schreibt den Distributionen auch nicht vor, dass sie RPM als Standard-Paketformat verwenden müssen. LSB verlangt nur, dass die Möglichkeit bestehen muss RPM pakete zu installieren. Dieses soll den Aufwand für Softwarehersteller verringern, welche dann nicht mehr für jede Distrie ein neues Paket schnüren müssen und genau das ist ja das Ziel der LSB.
Wobei das mit den einheitlichen Paketformat schon mit dem favorisieren von RPM gründlich in die Hose ging da es zig verschiedene und untereinander nicht richtig kompatible RPM-Pakete gibt. Da hätte man lieber DEB mitsammt der strengen Vorschriften für dieses Paketformat nehmen sollen.
PS: Sie hätten dem Paketformat die Dateiendung *.lsb geben sollen, vieleicht währe dann endlich Schluß mit dem Genörgel um das Paketformat. Für ein Format mußten sie sich ja entscheiden um zu verhindern, dass weiterhin für jede Distribution ein eigenes Paket angeboten werden muß.
Was interessiert mich die Hacker Gemeinde. Ich will etwas für die 08/15 User die meine Software kaufen. Die Hacker sollen lieber nach FreeBSD flüchten anstatt weiter zu verhindern das Linux eine Desktopalternative zu windows wird.
Das war mal früher so, nenn mir doch jetzt nochmal eine Hand voll Kernel Hacker die nicht einfache Angestellete sind. Das ist ja das gute das Linux nicht mehr auf die angewiesen ist. Jeder ist austauschbar selbst Alan Cox.
Hacker heißt nicht, das man Arbeitslos auf der Straße sitzt. Nur weil ein Hacker jetzt für seine Arbeit von Firma X bezahlt wird, heißt es nicht das er kein Hacker mehr ist. Egal ob es Linux, die ganze GNU Software, KDE, Gnome,... um nur mal die großen Sachen zu nennen. Dazu kommen die vielen kleineren Tools und Programme die die täglich bewußt oder unbewußt nutzt. Das alles würde es ohne Hacker nicht mehr geben und auch nicht lange überleben. Lass mal SuSE oder RedHat mit ihren Handvoll Programmieren ein System wie GNU/Linux komplett in eigenregie pflegen und weiterentwickeln. Die halten das kein Jahr durch und sie sind Pleite.
Von Extended Anonymous am Do, 18. November 2004 um 01:50 #
> Warum willst du Leute dazu "zwingen" ein bestimmtes Toolkit zu verwenden.
Weil ich nicht will, das die Firmen ihre Anwendungen mit der häßlichen X-lib schreiben nur weil das der einzige gemeinsamme Nenner unter Linux darstellt.
Und GTK+ wäre hier IMHO eine gute Empfehlung, da es sehr leistungsfähig ist und im Gegensatz zu QT auch für arme Firmen ohne Geld verwendet werden kann, Und eine Option ist ja noch lange kein Zwang, wer will kann ja immer noch die X-Lib oder irgendetwas anderes nehmen,
> im Gegensatz zu QT auch für arme Firmen ohne Geld
Ohh, die "armen Firmen" die mit Linux Geld verdienen wollen aber nichts dafür zurückgeben oder wenigstens die Weiterentwicklung des verwendeten Toolkits finanziell unterstützen wollen?
Die üblichen Toolkits (gtk1, Qt, gtk2, openmotif,..) sind doch eh schon auf jedem brauchbaren Desktoprechner installiert. Was soll da eine Aufnahme in die LSB bringen? Wer einen Server betreibt, lässt das ganze X Zeugs eh weg, die anderen haben es so oder so auf der Festplatte.
Von Daniel Baumann am Mi, 17. November 2004 um 21:46 #
Mit deiner Argumentation braeuchte man ueberhaupt keine LSB. Im Prinzip ist ja eh alles vorhanden/nachinstallierbar auf den 'meisten' Desktoprechnern.
Die LSB hat die Motivation, sich eben genau nicht darauf zu verlassen, dass $foo und $bar in einer gewissen Umgebung vorhanden sind, sondern sie vorzuschreiben - nur so kann sich $entwickler darauf verlassen, dass eine sein Programm in moeglichst jeder (LSB-konformen) Umgebung garantiert laeuft.
Schwachsinn, die LSB soll nur dafür sorgen das das Programm auf allen LSB konformen Distributionen lauffähig (und installierbar) ist, um die Abhängigkeiten kümmert sich dann der Paketmanager. Wenn alles und jedes vorgeschrieben wird, dann platzen die Distributionen ja bald aus allen Nähten und keiner währe mehr bereit sich an die LSB zu halten.
Soviel braucht es nicht. Und was ist schlimm daran wenn jede Desktop LSB konforme Installation 5 GB belegt ? Platte kostet heute nichts. Es geht um Einfachheit für die Benutzer. Punkt aus fertig. Wenn du ein Crack sein willst nimm Slackware, aber versuche nicht die Millionen anderer Nutzer die einfach nicht konfigurieren/installieren wollen zu bevormunden. Die sind wichtiger, weil sie es evt. nicht schaffen zu installieren, währrend Du immer genug wissen hast um es zum laufen zu kriegen.
Die Linux Freaks müssen halt in Zukunft mehr Zeit aufwenden, Distributionen für sie zu optimieren ist meiner Ansicht völlig am Ziel vorbei.
Ich hab keine Ahnung was Du für Sorgen hast, aber ich bin weder ein Crack noch nehme ich so ein Zeug. ;)
Ich hab nur gesagt das der Paketmanager, yast, apt oder was auch immer die Abhängigkeiten auflösen soll und auch kann. Das gehört einfach nicht in eine LSB Spezifikation, was für den Desktop viel wichtiger ist sind Toolkit übergreifende Standards und darum kümmert sich freedesktop.org.
P.S.: Als Beweis dafür das ich kein (Slackware, Debian, Gentoo, LFS,...) Crack, Frickler, Möchtegern oder einfach nur Linux-Profi bin, ich benutze SuSE gerade weil es so schön einfach für mich ist und weil unter der KDE Oberefläche schon einen einigermassen einheitliches look and feel herscht.
Und bevor das jetzt hier ausufert: Natürlich hat er Recht damit, dass nur die Engine unter einer freien Lizenz stehen und die Grafiken, Level, Sounds, usw., die das eigentliche Spiel ausmachen, unfrei sind. Somst ist das Spiel nicht komplett.
Die (Engine) meinte ich auch. Und mit Hilfe der Ressourcen der Shareware-Version lässt sich das Spiel vervollständigen. Außerdem lässt sich die Engine, da Open Source, auf jede Plattform portieren. Die Ressourcen sind plattformunabhängig, so dass man im Endeffekt das komplette Spiel portieren kann.
Natürlich ist das Spiel nicht komplett. Die Level zählen für mich zu Grafiken etc. hinzu. Du kannst aber gerne eigene Level erstellen und diese verwenden. ;-)
Software im engeren Sinn bezeichnet nur das, was in Maschinensprache übersetzt wird, sei es vom Compiler oder vom Interpreter. Und damit ist Doom für mich Open-Source.
Wenn es ne Open-Source Telefonbuch-CD gibt, ist auch nur das Programm Open-Source, weil die Telefondaten eben nicht beliebig verwendet werden können. Da spielt z.B. der Datenschutz eine Rolle.
Weiterhin hätte ich dann zum riesigen Teil Closed-Source-Software auf der Platte, weil sich auch Musik auf meiner Platte befindet, von der nur ein extrem geringer Teil unter einer freien Lizenz wie der Creative Commons Lizenz steht.
Aber die Diskussion, was Software und was Werke sind, gab es schon zur Genüge auf der Debian-Mailingliste. Musik, Filme, Bilder etc. zählt für mich nicht als Software.
Du kannst dich nicht herausreden. Es geht nämlich in erster Linie um ein komplettes Spiel und nicht nur um die Software darum herum.
Das was Open Source ist ist nur eine Engine, die Doom Engine.
Das Spiel selbst heißt aber Doom und das ist nach wie vor nicht Open Source. Denn wenn es so wäre, dann könntest du mir jetzt eine Kopie des Spieles Doom zuschicken, das kannst du aber nicht, also laß es sein.
Mir ging es nicht um das komplette Spiel, sondern nur um die "Binaries", also die "Engine". Strenggenommen gibt es auch kein Doom 3 für Linux, sondern nur die Engine. Denn zum Spielen benötigt man die Spieledaten der Windows-Version.
Das kann ich auch so, da das komplette Spiel (inkl. Level) Shareware ist.
Das Bestreben wird von mir begrüßt und ich hoffe, daß bald Redhat/Fedora und Novell/Suse als neue Mitglieder begrüßt werden. Stutzig macht mich nur das Fehlen von IBM.
toll, da schließen sich ein paar Distributionen zusammen mit dem Ziel LSB 2.0 konform zu werde. Was ist daran so besonders. Diesen Standard gibt es schon mit oder ohne dieser Partnerschaft. Also kann sich doch jede Distribution (in ihrem eigenen Interesse) an diesen Standard halten. Wozu brauche ich da eine Partnerschaft? Das man sich gegenseitig dazu "zwingen" kann?
aber so wie ich es verstanden haben ist diese Basis nicht mehr oder weniger als der LSB. Wenn sich also einfach jede dieser Distribution an den LSB halten würde, dann hätten sie auch diese gleiche Basis.
Ja und genau deshalb bauen Sie jetzt zusammen ein Basissystem und teilen sich den Arbeitsaufwand durch vier. Ich find das ne gute Sache und hoffe, dass sich in Zukunft noch mehr Distributionen daran beteiligen eine stabile LSB konforme Basis zu warten und weiterzuentwickeln.
Ich wünschte mir ein zentrales Basissystem auf das alle Distributionen aufsetzen. Aufsetzen nicht in Form von gravierenden Änderungen sondern viel mehr von Anpassungen (Look & Feel) und evtl. eigenen Tools etc. Das wäre mal ein Fortschritt!
ein schöner Wunsch, der mit GNU/Linux aber wohl nie in erfüllung gehen wird. Die Ursache für diese Vielfalt liegt einfach schon in der Geschichte des Systems. Linus Torvalds hat nie mehr wie einen Kernel geschrieben. Das GNU Projekt hat bis heute noch keinen Kernel für ihr System der alltag tauglich ist. Da Linus weder Linux zu einem ganzen Betriebssystem ausgebaut hat noch Linux offiziell ins GNU System integriert hat und der Kernel des GNU Systems (Hurd) bis heute für den alltag nicht brauchbar ist, haben die Leute/Distributionen von Anfang an ihr System basierend auf GNU und Linux selber zusammenbauen müssen. Dabei entstand natürlich eine gewisse Heterogenität die man nachträglich nichtmehr rückgängig machen kann.
Wenn du ein zentrales Betriebssystem willst, dann wirst du wohl entweder ein *BSD nehmen müssen oder warten müssen bis das GNU(/HURD) System fertig ist.
Nun ich befürchte das selbst mit Hurd nichts dergleichen entstehen wird. Ganze einfach aus dem Grund das außer Debian und evtl. einigen neuen Distributionen keiner Hurd benutzen wird. Zu sehr ist alles schon auf den Linux-Kernel abgestimmt.
Würde ich nicht unbedingt sagen. Der Kernel ist doch in 90% aller Fälle total unwichtig. Was die Leute sehen und täglich verwenden ändert sich bei einem Kernel wechsel nicht und in dem Bereich wo der Kernel wirklich eine Rolle spielt denke ich könnte Hurd schon einige seine Vorteile ausspielen, so dass sich auch oder gerade in diesem Bereich ein wechsel lohnen könnte wenn Hurd jemals ein alltagfähiges Stadium erreicht. Aber ich denke mal das liegt wenn überhaupt noch in weiter Zukunft.
Mhh, also SUSE und co. sind wegen der erweiterten Features schon recht eng an den Kernel geschrieben. Ich glaube nicht das alle komfortfunktionen ohne Änderungen portiert werden könnten.
Wie wollen sie eigentlich einen Standard schaffen und zwei verschiedene Paket-Systeme verwenden? Nur so. Eine Frage.
Berichtige mich aber ist Mandrake nicht irgendwan mal aus Redhat hervorgegangen, Progenie Debian basiert und Turbolinux sowie Connective verfolgten eigene Wege? Wen diee Distris eine gemeinsame Basis schaffen wollen müssen sie entweder etwas ganz neues schaffen oder alle ordnen sich dem System eines einzelnen unter.
Aber Schreck bei Seite. Es geht um eine gemeinsame Basis implementierung. Das muß noch lange nicht bedeuten das sie eine Basis schaffen wollen auf der alles aufbaut sondern bedeutet in meinen Augen viel mehr das sie versuchen die LSB 2.0 auf die selbe Weise in ihrer jeweiligen Distribution umzusetzen.
Grüße
Sturmkind
Ne, im ernst: Schön das es bei der Zusammenarbeit weitergeht, nach UnitedLinux sah es ja etwas düster aus. In sachen Verbund haben alle ja wohl auch gelernt, diesmal etwas weniger Steif, dann kann es auch nicht so fix brechen ;)
Wobei ich etwas überrascht bin das eine Debian Distrie dabei ist, bin gespannt wie das harmonisiert.
Lest die mandrake FAQ die verlinkt ist, da steht etwas zu United Linux. Daher mein "light"
meinst du das unterschiedliche paketformat? so wie ich das im vortrag von theodore ts'o (richtig geschrieben?) verstanden habe, setzt lsb zwar auf rpm, aber nur auf einen sehr kleinen gemeinsamen nenner daraus. simpel genug, um rpm-pakete "1:1" in deb-pakete umwandeln zu können. durch diesen kniff wäre dann garantiert, dass lsb-konforme rpms auch unter debian laufen.
ja.
"kleinen gemeinsamen nenner daraus. simpel genug, um rpm-pakete "1:1" in deb-pakete umwandeln zu können."
nein, um lsb konform zu sein, muss rpm oder ein vollstaendig rpm-kompatibler package-manager nachinstallierbar sein. alien zaehlt nicht (informationsverlust), bisher gibt es noch keinen 100%-igen wrapper fuer rpm nach $package_format und umgekehrt, weshalb die meisten distributionen die loesung vorziehene, zur lsb-konformitaet rpm optional nachinstallierbar zu machen (die denn kein rpm als default-format benutzen).
Hat Progeny soviel Einfluß auf die Debiandistri daß sie selbst garnicht Partner sein muß um die angestrebten Ziele zu erreichen oder gilt das ganze nur für Progenys Distri?
LSB Spezifikation mit aufgenommen werden?
Momentan gibt es bezüglich GUI Librarys leider nur die ganzen X Librarys und OpenGL in der LSB 2.01 Spezifikation, aber wer will schon seine GUI mit den reinen X Librarys schreiben wenn
es viel programmierfreundlichere Toolkits wie z.B. GTK+ 2.x gibt?.
GTK+ koennte man genauso 'sanft erzwingen' wie die LSB es bereits mit RPM getan hat.
Könnte man vielleicht machen, allerdings halte ich davon genauso wenig wie davon das RPM in dem Standard vorkommt.
Ich denke der LSB wäre ein Erfolg, wenn man in Zukunft sicher wüßte wo man unabhängig von der Distribution eine config-Datei findet oder wo welche Programmdateien hininstalliert wurden.
Ob dann jemand das Programm mit GTK+, Qt,... schreibt und ob er es letztlich in ein tar.gz mit einem install script, rpm oder deb Packet packt ist doch vollkommen egal und sollte auch nicht im LSB geregelt werden.
Wenn man versucht solche Sachen vorzuschreiben verhindert man imho nur den Erfolg des LSB.
Ich denke jeder lässt sich in einem breiten Konsens "vorschreiben" wo jetzt eine conf Datei hin kommt oder in welches Verzeichnis jetzt welche Programmteile kommen. Aber die wenigsten werden sich vorschreiben lassen wie sie ihre Programme einpacken und schon garnicht mit welchem Toolkit sie es schreiben.
Es kommt vor, ist aber nicht zwingend da. Es muss dann nur $den_anderen_paketmanager nachinstallierbar sein. Selbiges kann man mit GTK ebenfalls machen.
"Ich denke der LSB wäre ein Erfolg, wenn man in Zukunft sicher wüßte wo man unabhängig von der Distribution eine config-Datei findet oder wo welche Programmdateien hininstalliert wurden."
Das tut sie bereits seit 1.x.
"Aber die wenigsten werden sich vorschreiben lassen wie sie ihre Programme einpacken und schon garnicht mit welchem Toolkit sie es schreiben."
Soll sie und will sie auch gar nicht (siehe oben).
LSB verlangt nur, dass die Möglichkeit bestehen muss RPM pakete zu installieren.
Dieses soll den Aufwand für Softwarehersteller verringern, welche dann nicht mehr für jede Distrie ein neues Paket schnüren müssen und genau das ist ja das Ziel der LSB.
Grüße
Sturmkind
Debian basierte LSB-Distributionen eingeschlossen!
PS: Sie hätten dem Paketformat die Dateiendung *.lsb geben sollen, vieleicht währe dann endlich Schluß mit dem Genörgel um das Paketformat.
Für ein Format mußten sie sich ja entscheiden um zu verhindern, dass weiterhin für jede Distribution ein eigenes Paket angeboten werden muß.
Die Hacker sollen lieber nach FreeBSD flüchten anstatt weiter zu verhindern das Linux eine Desktopalternative zu windows wird.
Ohne die Hacker gibt es die Software die du gerne als 08/15 User verwenden willst nicht.
Egal ob es Linux, die ganze GNU Software, KDE, Gnome,... um nur mal die großen Sachen zu nennen. Dazu kommen die vielen kleineren Tools und Programme die die täglich bewußt oder unbewußt nutzt. Das alles würde es ohne Hacker nicht mehr geben und auch nicht lange überleben. Lass mal SuSE oder RedHat mit ihren Handvoll Programmieren ein System wie GNU/Linux komplett in eigenregie pflegen und weiterentwickeln. Die halten das kein Jahr durch und sie sind Pleite.
Weil ich nicht will, das die Firmen ihre Anwendungen mit der häßlichen X-lib schreiben nur
weil das der einzige gemeinsamme Nenner unter Linux darstellt.
Und GTK+ wäre hier IMHO eine gute Empfehlung, da es sehr leistungsfähig ist und
im Gegensatz zu QT auch für arme Firmen ohne Geld verwendet werden kann,
Und eine Option ist ja noch lange kein Zwang, wer will kann ja immer noch die X-Lib oder irgendetwas anderes nehmen,
Ohh, die "armen Firmen" die mit Linux Geld verdienen wollen aber nichts dafür zurückgeben oder wenigstens die Weiterentwicklung des verwendeten Toolkits finanziell unterstützen wollen?
Die LSB hat die Motivation, sich eben genau nicht darauf zu verlassen, dass $foo und $bar in einer gewissen Umgebung vorhanden sind, sondern sie vorzuschreiben - nur so kann sich $entwickler darauf verlassen, dass eine sein Programm in moeglichst jeder (LSB-konformen) Umgebung garantiert laeuft.
Wenn alles und jedes vorgeschrieben wird, dann platzen die Distributionen ja bald aus allen Nähten und keiner währe mehr bereit sich an die LSB zu halten.
Platte kostet heute nichts. Es geht um Einfachheit für die Benutzer. Punkt aus fertig.
Wenn du ein Crack sein willst nimm Slackware, aber versuche nicht die Millionen anderer Nutzer die einfach nicht konfigurieren/installieren wollen zu bevormunden. Die sind wichtiger, weil sie es evt. nicht schaffen zu installieren, währrend Du immer genug wissen hast um es zum laufen zu kriegen.
Die Linux Freaks müssen halt in Zukunft mehr Zeit aufwenden, Distributionen für sie zu optimieren ist meiner Ansicht völlig am Ziel vorbei.
Ich hab nur gesagt das der Paketmanager, yast, apt oder was auch immer die Abhängigkeiten auflösen soll und auch kann.
Das gehört einfach nicht in eine LSB Spezifikation, was für den Desktop viel wichtiger ist sind Toolkit übergreifende Standards und darum kümmert sich freedesktop.org.
P.S.: Als Beweis dafür das ich kein (Slackware, Debian, Gentoo, LFS,...) Crack, Frickler, Möchtegern oder einfach nur Linux-Profi bin, ich benutze SuSE gerade weil es so schön einfach für mich ist und weil unter der KDE Oberefläche schon einen einigermassen einheitliches look and feel herscht.
Wobei ich jetzt nicht das programmieren meine.
Dann entwickle nicht für GNU/Linux, dass ist für alle das beste.
Er hat schon recht.
Natürlich hat er Recht damit, dass nur die Engine unter einer freien Lizenz stehen und die Grafiken, Level, Sounds, usw., die das eigentliche Spiel ausmachen, unfrei sind. Somst ist das Spiel nicht komplett.
Die (Engine) meinte ich auch. Und mit Hilfe der Ressourcen der Shareware-Version lässt sich das Spiel vervollständigen. Außerdem lässt sich die Engine, da Open Source, auf jede Plattform portieren. Die Ressourcen sind plattformunabhängig, so dass man im Endeffekt das komplette Spiel portieren kann.
Die Level zählen für mich zu Grafiken etc. hinzu.
Du kannst aber gerne eigene Level erstellen und diese verwenden. ;-)
Software im engeren Sinn bezeichnet nur das, was in Maschinensprache übersetzt wird, sei es vom Compiler oder vom Interpreter.
Und damit ist Doom für mich Open-Source.
Wenn es ne Open-Source Telefonbuch-CD gibt, ist auch nur das Programm Open-Source, weil die Telefondaten eben nicht beliebig verwendet werden können. Da spielt z.B. der Datenschutz eine Rolle.
Weiterhin hätte ich dann zum riesigen Teil Closed-Source-Software auf der Platte, weil sich auch Musik auf meiner Platte befindet, von der nur ein extrem geringer Teil unter einer freien Lizenz wie der Creative Commons Lizenz steht.
Aber die Diskussion, was Software und was Werke sind, gab es schon zur Genüge auf der Debian-Mailingliste. Musik, Filme, Bilder etc. zählt für mich nicht als Software.
Es geht nämlich in erster Linie um ein komplettes Spiel und nicht nur um die Software
darum herum.
Das was Open Source ist ist nur eine Engine, die Doom Engine.
Das Spiel selbst heißt aber Doom und das ist nach wie vor nicht Open Source.
Denn wenn es so wäre, dann könntest du mir jetzt eine Kopie des Spieles Doom zuschicken,
das kannst du aber nicht, also laß es sein.
Strenggenommen gibt es auch kein Doom 3 für Linux, sondern nur die Engine. Denn zum Spielen benötigt man die Spieledaten der Windows-Version.
Das kann ich auch so, da das komplette Spiel (inkl. Level) Shareware ist.
Was ist daran so besonders. Diesen Standard gibt es schon mit oder ohne dieser Partnerschaft. Also kann sich doch jede Distribution (in ihrem eigenen Interesse) an diesen Standard halten.
Wozu brauche ich da eine Partnerschaft? Das man sich gegenseitig dazu "zwingen" kann?
Sie wollen eine gemeinsame Basis schaffen auf denen die jeweiligen Distributionen aufbauen.
Ich find das ne gute Sache und hoffe, dass sich in Zukunft noch mehr Distributionen daran beteiligen eine stabile LSB konforme Basis zu warten und weiterzuentwickeln.
Grüße
Sturmkind
Die Ursache für diese Vielfalt liegt einfach schon in der Geschichte des Systems. Linus Torvalds hat nie mehr wie einen Kernel geschrieben. Das GNU Projekt hat bis heute noch keinen Kernel für ihr System der alltag tauglich ist. Da Linus weder Linux zu einem ganzen Betriebssystem ausgebaut hat noch Linux offiziell ins GNU System integriert hat und der Kernel des GNU Systems (Hurd) bis heute für den alltag nicht brauchbar ist, haben die Leute/Distributionen von Anfang an ihr System basierend auf GNU und Linux selber zusammenbauen müssen. Dabei entstand natürlich eine gewisse Heterogenität die man nachträglich nichtmehr rückgängig machen kann.
Wenn du ein zentrales Betriebssystem willst, dann wirst du wohl entweder ein *BSD nehmen müssen oder warten müssen bis das GNU(/HURD) System fertig ist.
Grüße
Sturmkind
Was die Leute sehen und täglich verwenden ändert sich bei einem Kernel wechsel nicht und in dem Bereich wo der Kernel wirklich eine Rolle spielt denke ich könnte Hurd schon einige seine Vorteile ausspielen, so dass sich auch oder gerade in diesem Bereich ein wechsel lohnen könnte wenn Hurd jemals ein alltagfähiges Stadium erreicht.
Aber ich denke mal das liegt wenn überhaupt noch in weiter Zukunft.