>> Das Problem der verschiedenen Linux-Distributionen >> ist, daß Linux nur der Kernel ist.
> Das ist das Standard-Ablenkungsmanöver. Kleiner Tipp: > Lies meinen Beitrag einfach nochmal und falls notwendig, > danach noch ein drittes mal. Ich verwende nicht Linux als Beispiel, > sondern KOffice. KOffice ist kein Kernel.
Du sprachst aber davon daß keine Distributionsübergreifenden Binärpakete vohanden wären. Und das hat sehr wohl etwas mit Linux zu tun. Linux ist nunmal nur der Kern und was außen herum gestrickt wird ist den Linuxentwicklern egal. Es hat überhaußt nichts mit Forken zu tun, wenn die Autoren von KOffice keine Lust haben für alle vorhandenen Distributionen Binärpakte heraus zu geben, wo es die Distributionen schon selber machen. Es ist ohne weiteres Möglich den Sourcecode auf nahezu jedem Linux zu kompilieren (nahezu deshalb, weil ich es nicht selber auf allen verfügbaren Distributionen ausprobiert habe), vorausgesetzt die Abhängigkeiten sind erfüllt. Dazu muß nichts am Code selbst geändert werden.
> Qt und kdelibs sind auch Komplettpakete. Und trotzdem > kann ich wegen der Fragmentierung, die durch ein > dezentrales OpenSource-Entwicklungsmodell provoziert > wird, keine generischen Pakete machen, selbst wenn ich > nur Qt und die kdelibs und nicht den Kernel einbinde. Hää? Entschuldige, was bitte willst du sagen? Welche Fragmentierung gibt es denn bei Qt und kdelibs? Egal auf welchem System du das kompilierst die Schnittstellen ist immer gleich und auch das verhalten ändert sich nur von Version zu Version und nicht von Platform zu Platform. Ansonsten wäre es ja völlig unsinnig zu versuchen Systemunabhängig zu Programmieren. Übringens kann man Qt nicht einfach so auf einem nichtgrafischen system kompilieren, da es auch hier abhängikeiten bint die erfüllt sein müssen. Es muß wenigstens eine X11 Umgebung da sein. (außer man verwendet das EmbeddetQt). Wenn du meinst daß es keine Distributionsübergreifenden Binärpakte gibt, und das dem OS-Entwicklunghsmodell zur last legst so ist das doch etwas daneben gegriffen. Du wirst kaum die selben Binärpakte unter Xenix und Solaris zum laufen bekommen, beide auf dem SystemV beruhen. Wo ist da das Closedsourceentwicklungsmodell besser? Inkampatibilitäten wird es überall geben. Das Kat nichts mit Open- oder Closed-Source zu tun. Von Qt und kdelibs exitieren keine Forks.
> Dieses "Linux ist nur ein Kernel"-Ablenkungsmanöver ist voll daneben. Du sprachst von Binärpakten, Abhängikeiten und Forks. Da war es völlig logisch an zu nehem du bezögest dich auf Ditributionen und damit auf die Unterschieden zwischen Ditributionen. Deren gemeinsamer Kern ist dabei nunmal Linux. Übrigens exitiert auch kein Linux-Fork.
>> Desweiteren wird durch Suns Lizenzpolitik bezüglich >> Java die Verbreitung von Java gehemmet.
> Ach ja? Ich weiß über die Verbreitung von Java nur Gutes. > Ich rede hier nicht von OpenBSD/Sparc, NetBSD/Alpha und > Linux/ARM, sondern den Standardplattformen Windows/x86, > Linux/x86, Mac OS X/ppc, Solaris/x86 und Solaris/Sparc.
Na toll und du erwartest ganz automatisch das es nurnoch "Windows/x86, Linux/x86, Mac OS X/ppc, Solaris/x86 und Solaris/Sparc" Systeme geben wird? Alle anderen schauen in die Röhe, sollen sie sich doch an den "Standard" halten, oder wie soll ich das verstehen? Aber Java ist ja so toll interportabel, man kann sich drei Pozessoren und vier Betriebssysteme aussuchen. Und was ist wenn nun Sun meint 2 Przessoren und drei Betriebssysteme würden reichen? Oder sie sagen sich ein Przessortyp reicht, immerhin wollen sie ihre Hardware verkaufen. Das sind die Probleme dich mit Java habe. Welchen Grund sollte es geben Java und nicht z.B. Perl ein zu setzen? Perl auf nahezu jedes System portiert und sicher genauso leistungsfähig wie Java (ja ich weiß es hat auch so mache schwächen und ist kein so toller Vergleich, aber .NET heran zu ziehen wäre auch nicht besser gewesen, oder?). Und wieviele Forks gibt es von Perl? Keine?
Es wäre sehr viel einfacher Portierungen für andere System zu schaffen wäre Java OS, denn bei vielen Systemen sind es nur Kleinigkeiten die angepasst werden müssen. Sun verlangt aber ein Arm und ein Bein, damit ein Programmierer am Javacode arbeiten darf. Welcher OS-Programmierer macht das gerne mit? Würdest du dich gerne für 10 Jahre verpflichten um eine Kleingkeit korrigieren, oder den Quellcode auf einem anderen Prozessor kompilieren zu dürfen?
Und zur Mozilla Geschichte mit Debian. Mozilla benutzt seinen Namen um inkompatible Forks zu verhindern und ist damit recht erfolgreich. (Nach dem Motto Fork meinet wegen, aber nicht mit unserem Namen.) Debian hielt sich nicht daran und wurde darauf hin gewiesen. An einer Lösung wird gearbeitet. Wo ist das Problem? Es handelt sich noch nicht mals um einen Fork vom Browser sondern nur um ein paar Patches, um die Zusammenarbeit mit der Distribution zu verbessern. Bei jeder neuen Browserversion geschah das erneut. Da gibt es keinen Fork.
Wenn man sich mehrer Opensourceprojekte ansieht erkennt man, daß die Wahrscheinlichkeit eines Forks immer kleiner wird je größer das Pojekt ist. (Beim XF86 haben die Maintrainer eine ganze Menge falsch machen müssen, bevor es zu einem Fork kam, welchen man zudem kaum als Fork bezeichnen kann, da das originale Proket so gut wie tot ist, man hat sozusagen indireckt die Maintrainer raus geschmissen)
Java ist ein riesiges Projeckt, welches wohl kaum durch einen Fork bedroht sein dürfte wäre es OS. Zudem könnte man es wunderbar durch die Namensgebung von Forks abgrenzen. Aber Sun will nur weiterhin schön Geld mit Java verdienen, und das ist ja auch nicht falsch, doch sollen sie es auch klar sagen. Suns jetziges Verhalten ist es, das mich ärgert. Sie erzählen einem davon alles sei frei, und jeder könne mitmachen, es gäbe keine Einschränkungen und sie würden an Java garkein Geld verdienen wollen, und so weiter und so fort. Schaut man aber genauer hin sieht man, daß Sun ganz ordentlich an Java verdient und sich gerne Optionen offen hält noch mehr Geld damit zu verdienen. Das hat für mich einen leicht bitteren Geschmack von Erpressung. Java halte ich zur Zeit unbrauchbar für Projekte, die über lange Zeiträume angelegt sind. Glücklicherweise entstehen ja eine ganze Anzahl von freien Implemetierungen, die aber noch eine Weile brauchen, bis sie voll einsetzbar sind. Noch stößt man zu schnell auf Lücken und Fehler, aber das kommt noch. Suns Java wird hoffendlich mit der Zeit immer unbedeutender.
Von allen ausgezählten Opensorce-Projekten gibt es keine doppelten unabhänigen Implemetationen (da es einfach nicht nötig ist), von Java gibt es sechs, von denen ich weiß. Was fügt Java denn nun mehr Schaden zu? Die Weigerung die Quellen offen zu legen und damit inkompatieble Reimplemetationen zu provozieren, oder die sehr geringe Gefahr einen Fork zu bekommen, wenn die Quellen offen wären? Zur Zeit muß ich ein Javaprogramm (sofern ich es wirklich interoprtabel haben will) auf möglichst vielen Virtuellen-Maschinen testen, das ist ein nicht geringer Aufwand den ich mir gerne sparen würde.
>> ist, daß Linux nur der Kernel ist.
> Das ist das Standard-Ablenkungsmanöver. Kleiner Tipp:
> Lies meinen Beitrag einfach nochmal und falls notwendig,
> danach noch ein drittes mal. Ich verwende nicht Linux als Beispiel,
> sondern KOffice. KOffice ist kein Kernel.
Du sprachst aber davon daß keine Distributionsübergreifenden Binärpakete vohanden wären. Und das hat sehr wohl etwas mit Linux zu tun. Linux ist nunmal nur der Kern und was außen herum gestrickt wird ist den Linuxentwicklern egal.
Es hat überhaußt nichts mit Forken zu tun, wenn die Autoren von KOffice keine Lust haben für alle vorhandenen Distributionen Binärpakte heraus zu geben, wo es die Distributionen schon selber machen. Es ist ohne weiteres Möglich den Sourcecode auf nahezu jedem Linux zu kompilieren (nahezu deshalb, weil ich es nicht selber auf allen verfügbaren Distributionen ausprobiert habe), vorausgesetzt die Abhängigkeiten sind erfüllt. Dazu muß nichts am Code selbst geändert werden.
> Qt und kdelibs sind auch Komplettpakete. Und trotzdem
> kann ich wegen der Fragmentierung, die durch ein
> dezentrales OpenSource-Entwicklungsmodell provoziert
> wird, keine generischen Pakete machen, selbst wenn ich
> nur Qt und die kdelibs und nicht den Kernel einbinde.
Hää? Entschuldige, was bitte willst du sagen? Welche Fragmentierung gibt es denn bei Qt und kdelibs? Egal auf welchem System du das kompilierst die Schnittstellen ist immer gleich und auch das verhalten ändert sich nur von Version zu Version und nicht von Platform zu Platform. Ansonsten wäre es ja völlig unsinnig zu versuchen Systemunabhängig zu Programmieren. Übringens kann man Qt nicht einfach so auf einem nichtgrafischen system kompilieren, da es auch hier abhängikeiten bint die erfüllt sein müssen. Es muß wenigstens eine X11 Umgebung da sein. (außer man verwendet das EmbeddetQt). Wenn du meinst daß es keine Distributionsübergreifenden Binärpakte gibt, und das dem OS-Entwicklunghsmodell zur last legst so ist das doch etwas daneben gegriffen. Du wirst kaum die selben Binärpakte unter Xenix und Solaris zum laufen bekommen, beide auf dem SystemV beruhen. Wo ist da das Closedsourceentwicklungsmodell besser? Inkampatibilitäten wird es überall geben. Das Kat nichts mit Open- oder Closed-Source zu tun. Von Qt und kdelibs exitieren keine Forks.
> Dieses "Linux ist nur ein Kernel"-Ablenkungsmanöver ist voll daneben.
Du sprachst von Binärpakten, Abhängikeiten und Forks. Da war es völlig logisch an zu nehem du bezögest dich auf Ditributionen und damit auf die Unterschieden zwischen Ditributionen. Deren gemeinsamer Kern ist dabei nunmal Linux. Übrigens exitiert auch kein Linux-Fork.
>> Desweiteren wird durch Suns Lizenzpolitik bezüglich
>> Java die Verbreitung von Java gehemmet.
> Ach ja? Ich weiß über die Verbreitung von Java nur Gutes.
> Ich rede hier nicht von OpenBSD/Sparc, NetBSD/Alpha und
> Linux/ARM, sondern den Standardplattformen Windows/x86,
> Linux/x86, Mac OS X/ppc, Solaris/x86 und Solaris/Sparc.
Na toll und du erwartest ganz automatisch das es nurnoch "Windows/x86, Linux/x86, Mac OS X/ppc, Solaris/x86 und Solaris/Sparc" Systeme geben wird? Alle anderen schauen in die Röhe, sollen sie sich doch an den "Standard" halten, oder wie soll ich das verstehen? Aber Java ist ja so toll interportabel, man kann sich drei Pozessoren und vier Betriebssysteme aussuchen.
Und was ist wenn nun Sun meint 2 Przessoren und drei Betriebssysteme würden reichen? Oder sie sagen sich ein Przessortyp reicht, immerhin wollen sie ihre Hardware verkaufen. Das sind die Probleme dich mit Java habe. Welchen Grund sollte es geben Java und nicht z.B. Perl ein zu setzen? Perl auf nahezu jedes System portiert und sicher genauso leistungsfähig wie Java (ja ich weiß es hat auch so mache schwächen und ist kein so toller Vergleich, aber .NET heran zu ziehen wäre auch nicht besser gewesen, oder?). Und wieviele Forks gibt es von Perl? Keine?
Es wäre sehr viel einfacher Portierungen für andere System zu schaffen wäre Java OS, denn bei vielen Systemen sind es nur Kleinigkeiten die angepasst werden müssen. Sun verlangt aber ein Arm und ein Bein, damit ein Programmierer am Javacode arbeiten darf. Welcher OS-Programmierer macht das gerne mit? Würdest du dich gerne für 10 Jahre verpflichten um eine Kleingkeit korrigieren, oder den Quellcode auf einem anderen Prozessor kompilieren zu dürfen?
Und zur Mozilla Geschichte mit Debian. Mozilla benutzt seinen Namen um inkompatible Forks zu verhindern und ist damit recht erfolgreich. (Nach dem Motto Fork meinet wegen, aber nicht mit unserem Namen.) Debian hielt sich nicht daran und wurde darauf hin gewiesen. An einer Lösung wird gearbeitet. Wo ist das Problem? Es handelt sich noch nicht mals um einen Fork vom Browser sondern nur um ein paar Patches, um die Zusammenarbeit mit der Distribution zu verbessern. Bei jeder neuen Browserversion geschah das erneut. Da gibt es keinen Fork.
Wenn man sich mehrer Opensourceprojekte ansieht erkennt man, daß die Wahrscheinlichkeit eines Forks immer kleiner wird je größer das Pojekt ist. (Beim XF86 haben die Maintrainer eine ganze Menge falsch machen müssen, bevor es zu einem Fork kam, welchen man zudem kaum als Fork bezeichnen kann, da das originale Proket so gut wie tot ist, man hat sozusagen indireckt die Maintrainer raus geschmissen)
Java ist ein riesiges Projeckt, welches wohl kaum durch einen Fork bedroht sein dürfte wäre es OS. Zudem könnte man es wunderbar durch die Namensgebung von Forks abgrenzen. Aber Sun will nur weiterhin schön Geld mit Java verdienen, und das ist ja auch nicht falsch, doch sollen sie es auch klar sagen.
Suns jetziges Verhalten ist es, das mich ärgert. Sie erzählen einem davon alles sei frei, und jeder könne mitmachen, es gäbe keine Einschränkungen und sie würden an Java garkein Geld verdienen wollen, und so weiter und so fort. Schaut man aber genauer hin sieht man, daß Sun ganz ordentlich an Java verdient und sich gerne Optionen offen hält noch mehr Geld damit zu verdienen. Das hat für mich einen leicht bitteren Geschmack von Erpressung.
Java halte ich zur Zeit unbrauchbar für Projekte, die über lange Zeiträume angelegt sind. Glücklicherweise entstehen ja eine ganze Anzahl von freien Implemetierungen, die aber noch eine Weile brauchen, bis sie voll einsetzbar sind. Noch stößt man zu schnell auf Lücken und Fehler, aber das kommt noch.
Suns Java wird hoffendlich mit der Zeit immer unbedeutender.
Von allen ausgezählten Opensorce-Projekten gibt es keine doppelten unabhänigen Implemetationen (da es einfach nicht nötig ist), von Java gibt es sechs, von denen ich weiß.
Was fügt Java denn nun mehr Schaden zu? Die Weigerung die Quellen offen zu legen und damit inkompatieble Reimplemetationen zu provozieren, oder die sehr geringe Gefahr einen Fork zu bekommen, wenn die Quellen offen wären?
Zur Zeit muß ich ein Javaprogramm (sofern ich es wirklich interoprtabel haben will) auf möglichst vielen Virtuellen-Maschinen testen, das ist ein nicht geringer Aufwand den ich mir gerne sparen würde.