Bislang hat sich Sun gegen alle Versuche Java zu Open Source zu machen erfolgreich mit der Warnung vor inkompatiblen Forks widersetzt und seinem Haupt-Kritiker IBM einfach "Java-Neid" unterstellt. Diesen Argumenten hält Manes entgegen, dass die effektive Kontrolle der Java-Marke, ausschließlich ausgerichtet auf kompatible Versionen, völlig ausreichend wäre, um inkompatible Forks zu verhindern.
Der Aussage stimme ich zu 100% zu. Daß Sun es anders sieht, obwohl sie solche Argumente wie die von Manes schon des öfteren zu hören bekam, läßt so manchen an Suns Argumentation zweifeln. Noch immer meint Sun, daß sie bloß "inkompatible Java-Versionen" vermeiden wollen. Daß das jedoch nur ein vorgeschobener Grund von Sun ist, müßte nun jedoch wohl den meisten Menschen klar sein.
> Daß das jedoch nur ein vorgeschobener Grund von > Sun ist, müßte nun jedoch wohl den meisten > Menschen klar sein.
Mir ist es das nicht, könntest Du es vielleicht erklären? Es gibt doch genug Beispiele für Fragmentierung, klick doch einfach mal die dritte Meldung vor dieser hier an, dann wirst Du schon sehen, was ich meine:
"KOffice 1.4 kann als Quellcode von zahlreichen Mirror-Servern heruntergeladen werden. [...] Das Projekt selbst erstellt keine Binärpakete, bietet jedoch Pakete, die von Dritten erstellt wurden, zum Download an."
Und warum gibt es keine generischen Binärpakete? Wegen der Inkompatibilität. Die Entwickler würden bestimmt gerne generische Binärpakete anbieten, können es aber wegen der Fragmentierung nicht. Sun will eben nicht, dass dasselbe mit seinem Eigentum passiert.
Dies ist zu respektieren, schließlich ist es das Eigentum von Sun und nicht von irgendjemand anderem. Eigentümer sind nun mal berechtigt, über ihr Eigentum zu verfügen, damit muss man nicht einverstanden sein, es ändert aber nichts an den Eigentumsverhältnissen.
> Und warum gibt es keine generischen Binärpakete? Wegen der Inkompatibilität.
Das kann gut sein. Hat aber mit Java nichts zu tun.
Das Problem der verschiedenen Linux-Distributionen ist, daß Linux nur der Kernel ist. Und auch Linus Torvalds läßt viele Kernel-Modifikationen weiterhin den Namen "Linux" tragen.
Java hingegen ist ein Komplettpaket. Da ist die Virtuelle Maschine, und die Klassen und alles andere dabei. Sun kann auch wenn Java OpenSource wäre, bestimmen was sich "Java" nennen darf. Und das reicht völlig aus - wie auch Herr Manes meinte.
Hinzu kommt, daß dadurch, daß Java nicht OpenSource ist, gerade Projekte wie GNU Classpath entstanden sind. Womit durch Suns Lizenzpolitik genau das Gegenteil von dem entstanden ist, was Sun angeblich erreichen wollte.
Desweiteren wird durch Suns Lizenzpolitik bezüglich Java die Verbreitung von Java gehemmet. Es ist nun einmal nicht so leicht, in einer geschlossenen Gruppe Java auf andere Plattformen zu portieren. Es ist ja bekanntlich verboten, Zwischenschritte einer Portierung zu veröffentlichen.
Wäre Java OpenSource würde es z.B. schon längst ein Java für BeOS geben. Und was die Java-Versionen für Linux-ppc angeht, so sieht es dort seit einiger Zeit auch Mau aus. Zähl' mal die aktuell unterstützten Hardware-Plattformen von Blackdown (womit ich Java1.4 und Java5 meine). Fällt Dir was auf?
> Dies ist zu respektieren, schließlich ist es das Eigentum von Sun und nicht von irgendjemand > anderem. Eigentümer sind nun mal berechtigt, über ihr Eigentum zu verfügen, damit muss man > nicht einverstanden sein, es ändert aber nichts an den Eigentumsverhältnissen.
Was Sun mit seinem Eigentum macht ist eine Sache. Falsche Behauptungen in die Welt zu setzen, weshalb sie angeblich ihr Java nicht unter eine OpenSource Lizenz stellen, ist eine andere Sache.
> Das kann gut sein. Hat aber mit Java nichts zu tun.
Das sagt sich so leicht. Natürlich hat die konkrete Software namens "KOffice" nichts mit der konkreten Software namens "Java" zu tun. Trotzdem können beide sehr wohl ähnlichen Entwicklungen unterworfen sein, wenn sie ähnlichen Entwicklungsmodellen folgen!
> 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.
> Java hingegen ist ein Komplettpaket. Da ist die > Virtuelle Maschine, und die Klassen und alles andere > dabei.
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. Dieses "Linux ist nur ein Kernel"-Ablenkungsmanöver ist voll daneben.
> Sun kann auch wenn Java OpenSource wäre, bestimmen > was sich "Java" nennen darf. Und das reicht völlig > aus - wie auch Herr Manes meinte.
Was ausreicht, entscheidet immer noch der Eigentümer selbst und nicht irgendjemand anderes, der Ansprüche oder meinetwegen auch nur Wünsche an fremdem Eigentum anmeldet.
> Hinzu kommt, daß dadurch, daß Java nicht OpenSource > ist, gerade Projekte wie GNU Classpath entstanden > sind. Womit durch Suns Lizenzpolitik genau das > Gegenteil von dem entstanden ist, was Sun angeblich > erreichen wollte.
Dieses Argument ist richtig. Allerdings weiß jeder, dass Java und Classpath zweierlei sind, weil sie einen unterschiedlichen Ursprung haben. Wäre Java OpenSource, dann hätten inkompatible Ableger denselben Ursprung und selbst wenn auf dem Weg des Markenrechts eine Unterscheidung möglich wäre, hätte es eine anderes, geringeres Gewicht als die ganz klare Durchsage "Das hier ist von mir und alles andere ist nicht von mir, sondern Dein Problem".
Außerdem würden sowieso weitergehende Forderungen kommen, wenn Java denn OpenSource wäre. Wir hatten das Thema doch neulich schon: Mozilla ist OpenSource, aber nein, das reicht einer bekannten Distribution nicht, diese bekannte Distribution will Mozilla nicht nur verändern, was dank OpenSource kein Problem ist, sondern das Resultat auch noch Mozilla nennen und erhebt mahnend den Zeigefinger, wenn sie es nicht darf. Manchmal ist es notwendig, einfach eine unmissverständliche Grenze zu ziehen, weil sonst nicht klar ist, welche Forderungen vom Eigentümer definitiv nicht akzeptiert werden.
> 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.
> Es ist nun einmal nicht so leicht, in einer geschlossenen > Gruppe Java auf andere Plattformen zu portieren. Es ist ja > bekanntlich verboten, Zwischenschritte einer Portierung zu > veröffentlichen.
- Wie kommst Du darauf, dass eine Portierung auf andere Plattformen vom Eigentümer erwünscht ist? - Blackdown kriegt es hin für Linux - Apple kriegt es hin für Mac OS X - HP kriegt es hin für HP-UX und OpenVMS - innotek kriegt es hin für OS/2 - IBM kriegt es hin für Linux und AIX und weitere Systeme
Nur die OpenSource-Welt ist unzufrieden, weil es ihnen und nur ihnen nicht passt. Andere kommen bestens klar.
Ich frage mich wirklich, wieviele hochzufriedene Anwender auf Standardplattformen den paar lautstarken fingererhebenden Kritikern gegenüberstehen. Man kann auch einfach mal zur Kenntnis nehmen, dass man nicht so wichtig ist, das ist kein Beinbruch.
> Wäre Java OpenSource würde es z.B. schon längst > ein Java für BeOS geben.
Wie kommst Du darauf? Das ist eine mutige Behauptung. Am nähesten an einem Java-Port war BeOS, als Be Inc. noch lebte und sich dafür engagierte. Seitdem Be Inc. tot und BeOS der Community unterworfen ist, ist es viel weiter weg, das widerspricht doch der Logik. Außerdem ist BeOS unwichtig.
> Und was die Java-Versionen für Linux-ppc angeht, > so sieht es dort seit einiger Zeit auch Mau aus.
Wie kommst Du darauf, dass Java auf Linux/ppc überhaupt laufen soll? Es hieß niemals, aber auch wirklich niemals, dass Java überall läuft. Es hieß immer nur, dass es dort läuft, wo eine Laufzeitumgebung existiert.
> Zähl' mal die aktuell unterstützten Hardware- > Plattformen von Blackdown (womit ich Java1.4 und > Java5 meine).
Java für Linux/ppc bietet nicht Blackdown an, sondern IBM. IBM bezahlt dafür Geld an Sun und weiteres Geld für die eigene Portierungsarbeit. Es würde überhaupt keinen Unterschied machen, wenn Java OpenSource wäre. Auch wenn Java OpenSource wäre, würde die Portierung für Linux/ppc lange dauern, eventuell sogar noch länger. Durch OpenSource kommst Du nicht schneller zu einem Java für Linux/ppc!
> Fällt Dir was auf?
Ja, mir fällt auf, dass Du Java für Linux/ppc verlangst, als ob es Dir zustehen würde, obwohl das niemals der Deal war. Ursprünglich war es sogar so gedacht, dass der Hersteller jeder Plattform sein Java selbst portiert. Das wurde aufgeweicht, weil Microsoft Mist gebaut hat und es im Linux-Bereich so nicht geht, deswegen bietet Sun Java auch für Windows/x86 und Linux/x86 an.
Daraus jetzt die Forderung abzuleiten, es solle doch bitte jede Plattform bedient werden, ist völlig daneben. Selber portieren kannst Du jetzt schon, dafür brauchst Du keine OpenSource-Lizenz, sondern nur Menschliche Arbeitszeit, die Du auch bei OpenSource bräuchstest.
> Was Sun mit seinem Eigentum macht ist eine Sache. > Falsche Behauptungen in die Welt zu setzen, weshalb > sie angeblich ihr Java nicht unter eine OpenSource > Lizenz stellen, ist eine andere Sache.
Welche Behauptung soll angeblich falsch sein? Ich sehe hier nur falsche Behauptungen nach dem Motto "wenn es OpenSource wäre, wäre es viel portabler" (stimmt nicht, die Arbeit müsste genauso erledigt werden) und "viele Menschen leiden darunter, dass es nicht OpenSource ist" (stimmt nicht, die überwältigende Mehrheit ist hochzufrieden).
>> 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.
Ja, wo sind denn die KOffice-Forks? Ich sehe keine. Dass es nicht ein Binärpaket für alle Distributionen gibt, liegt ganz sicher nicht am Entwicklungsmodell von KOffice, sondern daran, dass die Linux-Distributoren ihre eigenen Süppchen kochen.
> 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. Dieses "Linux ist nur ein Kernel"-Ablenkungsmanöver ist voll daneben. Dass es kein generisches Binärpaket von Qt/X11, das auf allen Plattformen läuft, liegt also daran, dass Qt/X11 OpenSource ist? Ja dann dürften ClosedSource-Hersteller doch überhaupt kein Problem damit haben, Anwendungen für Linux zu schreiben. Da diese Anwendungen ClosedSource sind, laufen sie nach deiner Theorie ja überall.
Wo ist denn bitte das Problem, wenn ausschließlich offizielle Versionen von Sun den Logo und den Namen "Java" nutzen dürfen? Dann braucht auch nichts zusätzlich zertifiziert werden. Mögliche Forks gehen halt leer aus.
Weil das vermutlich zwar technisch machbar ist, aber vermutlich auch langsamer. Entweder ist das Paket native für eine Plattform, dann müssen es alle anderen emulieren oder gleich generischer Binärcode wie bei Java oder ähnlichen Technologien, die dann überall emuliert oder JIT kompiliert werden müssen.
Derzeit sind zwar in gewissen Grenzen beide Realisierungen im Einsatz, aber "echt native" wird doch von den meisten Benutzern bevorzugt.
Ich rede nicht von nativen oder nicht-nativen Paketen, sondern von den Binaries, die in den Paketen stecken. Und ferner rede ich nicht von unterschiedlichen Plattformen, deren Binaries auf anderen Plattformen "emuliert" werden müssten, sondern von einer einzigen Plattform, Linux/x86. KOffice, kompiliert auf einem x86-Mandriva-System, ist nicht binärkompatibel mit einem gleich alten x86-Fedora-System, obwohl sie dieselben kdelibs und dasselbe Qt drauf haben.
Provoziert wird das durch die Tatsache, dass sich jeder Distributor alles selbst kompiliert und anders konfiguriert. Das wäre bei Java genau dasselbe, es würde unter dem möglicherweise sogar gut gemeinten Argument der "besseren Integration" genauso gemacht werden, und fertig ist die Zersplitterung. Brauchen wir das wirklich auch für Java? Wer es braucht, soll es soch bitte selbst machen, und zwar nicht auf der Basis des Eigentums von anderen, sondern wirklich von Grund auf selbst.
Allerdings ist Binärkompatibilität hier in diesem Forum wirklich ein heikles Thema. Der Lösungsvorschlag lautet dann meistens, dass sich ja jeder alles selbst kompilieren könnte, wenn die Unternehmen ihr Eigentum unter die GPL stellen würden. Bloß ist das eben halt genau das, was Java nicht ist und nie sein soll. Das nimmt man entweder zur Kenntnis oder man lässt es bleiben und baut es sich selbst so nach, wie man es haben will.
Ein OpenSource-Java wäre einfach nicht zertifizierbar, die Tests einer Zertifizierung können nur mit Binaries durchgeführt werden, weil beim Endverbraucher ja auch Binaries am Werk sind. Also müsste statt Sun 1.5.0 und Blackdown 1.4.2 und Sun 1.4.2 jetzt jede einzelne Distribution einzeln zertifiziert werden, mit dem Ergebnis, dass man die weniger wichtigen Distributionen überhaupt nicht mehr zertifizieren kann.
Würde man versuchen, einen Quelltext und kein Binary zu zertifizieren, dann wäre der Ärger vorprogrammiert. Der eine Distributor kompiliert es mit dem GCC 3.2 und der andere mit dem GCC 4.0. Problem: wxWidgets funktioniert mit dem GCC 4.0 noch gar nicht, das könnte mit Java genauso sein. Also müsste man dann sagen, dieser Quelltext sei nur dann zertifiziert, wenn er mit dem GCC 3.2 kompiliert wird. Problem: GCC ist nicht gleich GCC, wenn eine Distribution einen gepatchten GCC drauf hat, dann kann auch ein Binary entstehen, das nicht funktioniert.
Man kann es drehen und wenden, wie man will: Die Interessen von Sun und die Interessen einer kleinen Minderheit von anderen Leuten passen nicht zusammen und sind unversöhnlich, es ist völlig müßig, immer wieder dasselbe von Sun zu fordern. Sun hat wichtigere Kunden und wird auf die aus der Sicht von Sun unwichtigen, die ja auch gar keine Kunden sind, definitiv keine Rücksicht nehmen. Die Forderungen sind sinnlos, wer sie weiter stellt, verschwendet Energie, die er auch darin investieren könnte, was eigenes zu machen.
Ich rede nicht von nativen oder nicht-nativen Paketen, sondern von den Binaries, die in den Paketen stecken
Soweit konnte ich dir schon folgen :)
Und ferner rede ich nicht von unterschiedlichen Plattformen
Da hatte ich wohl eine andere Interpretation von generisch, besonders im Kontext KOffice. Linux ist ja nur eine Plattform auf die KDE abzielt, somit wäre ein einzelnes Binary für mich nur dann generisch, wenn es auf allen Zielplattformen läuft. Sobald das nicht erfüllt ist, muß man ohnehin verschiedene Builds machen und ist dann mangels entsprechender Buildsystem auf Hilfe anderer angewiesen.
Das wäre bei Java genau dasselbe
Ich glaube das eher nicht. Die ABI ist immer gleich, die Programme meistens in einer einzigen JAR Datei. Ich hatte bei meinen Java Programmen bisher keine Probleme mit anderen JVMs auf der selben Plattform, am ehesten ist die Implementation von Sun die Schlechteste (unter Linux, auf Solaris sicher die Beste ;))
passen nicht zusammen und sind unversöhnlich
Wie ich schon im anderen Posting geschrieben habe halte ich das persönlich für eine Absicht von Seiten Suns. Wäre ihnen die Diskussion unangenehm oder lästig, würde nicht alle X Tage einer ihrer Chiefs entsprechend darüber Kommentare ablassen sondern einfach warte, bis der Publicity Hype daran abgeklungen ist.
> somit wäre ein einzelnes Binary für mich nur dann generisch, wenn es auf > allen Zielplattformen läuft.
Abstrakt gesehen kann man Deine Interpretation ohne weiteres gelten lassen. Die traurige Situation ist jedoch die, dass man schon von generisch sprechen muss, wenn ein Binary auf allen (schränken wir es ruhig etwas ein: allen aktuellen) Distributionen liefe. Aber das kann man vergessen.
> Ich hatte bei meinen Java Programmen bisher keine Probleme mit anderen JVMs auf > der selben Plattform
Ich hab zwei ausprobiert (eine war Sable), die schafften es nicht mal, kleine Javaprogramme auch nur zu starten. Mit der VM von Sun läuft alles problemlos.
wenn ein Binary auf allen (schränken wir es ruhig etwas ein: allen aktuellen) Distributionen liefe. Aber das kann man vergessen.
klar geht das, genaugenommen gibt es zwei Möglichkeiten (im Prinzip die gleichen wie bei Windows): 1. Du linkst dein Programm statisch. 2. du packst alle libs gegen die du gelinkt hast mit in dein Paket.
Beides ist aber sub-optimal (auch unter windows), gerade der Vorteil von freien Systemen ist ja, dass man nicht zig Versionen von einer lib braucht oder jeder sie selber mitbringen muß, sondern das man es einfach direkt für sein System gegen die vorhandenen libs linken kann. Dafür gibt es wieder zwei Möglichkieten: 1. Man hat ein OS von einem bestimmten Anbieter, dann übernimmt dieser für dich die Aufgabe und bietet dir fertige Pakete an 2. Du hast ein individuelles System, dann nimmst du dir das programm und linkst es selber gegen deine libs.
Eigentlich einen riesen Vorteil, man muß ihn nur nutzen indem man das System versteht und für seine eigene Software anwendet.
das ist die Theorie, die in der Praxis schon an den verschiedenen inkompatiblen gcc-Versionen scheitert, auf denen die verschiedenen Distris aufbauen. Die Praxis ist einfach die, dass ein Binary in 99% der Fälle auf Windows von 95[98] bis XP läuft. Unter Linux kannst Du das vergessen, G.W. hat das doch schon detailliert ausgeführt, warum dem so ist.
Ich stimme zu, daß es verschiedene Stufen von "generisch" gibt. Meine Interpretation war im Kontext des Beitrages, also KOffice Binärpakete. Mir ist in diesem Fall schon wichtig, daß es nicht nur auf Linux/x86 läuft, auch wenn das sicher die größte Gruppe der Benutzer sind.
Mit der VM von Sun läuft alles problemlos. Vermutlich hat sich das auch gebessert. Meine schlechten Erfahrungen kommen von der 1.3.1 Zeit, wo die Blackdown JVM der von Sun weit überlegen war, so daß ich doch den Eindruck hatte, die Sun VM ist künstlich verschlimmbessert worden. Die von Blackdown war auch meinen höchsten Anforderungen gewachsen.
SableVM hab ich noch nicht probiert, kann darüber also keine Aussage treffen.
> und die Interessen einer kleinen Minderheit von anderen Leuten
Wenn ein paar Millionen Nutzer eine kleine Minderheit sind, was ist denn dann Sun?!
Hi,
zu Deinem weiter oben angefuehrten Fork-Argument: Dass wir gerade mehrere javaehnliche Implementierungen der selben Sache haben (die aber in vielen Faellen wegen Suns Zicken auf diesem Gebiet noch nicht einmal dem Original ebenbuertig sein koennen), liegt doch genau an Suns Politik. Dass eine Offenlegung einen Fork moeglich macht, ist nicht von der Hand zu weisen (so what?!), das von Sun behauptete Gegenteil ist aber widerlegt! Und die Chance, dass ein erfolgreicher Fork wieder in eine gemeinsame Codebasis zurueckfliesst, ist eben auch nur mit FOSS moeglich. Im Falle von Linux (Kernel) gibt es schliesslich auch eine zentrale Linie, mit der jeder machen darf, was er will - dennoch koennte man eine (bei diesem Beispiel kernelspezifische) Anwendung genau fuer einen Vanilla-Kernel zertifizieren. Zu gewaehrleisten, dass die Zertifizierung auch mit distro-eigenen Kerneln noch ihre Gueltigkeit hat, laege dann in der Verantwortung der jeweiligen Distro.
> Ich rede nicht von nativen oder nicht-nativen Paketen, sondern von den Binaries, > die in den Paketen stecken. Und ferner rede ich nicht von unterschiedlichen > Plattformen, deren Binaries auf anderen Plattformen "emuliert" werden müssten, > sondern von einer einzigen Plattform, Linux/x86. KOffice, kompiliert auf einem > x86-Mandriva-System, ist nicht binärkompatibel mit einem gleich alten > x86-Fedora-System, obwohl sie dieselben kdelibs und dasselbe Qt drauf haben.
Das ist definitiv falsch! Kompiliere Koffice statisch (wird ein grosses Monster) und es wird auf allen aktuellen Distriebutionen laufen. Das Problem sind die dynamische Libs die vorausgesetzt werden, daher nur der Source Code. Eigentlich ganz einfach und durchaus normal.
"KOffice 1.4 kann als Quellcode von zahlreichen Mirror-Servern heruntergeladen werden. [...] Das Projekt selbst erstellt keine Binärpakete, bietet jedoch Pakete, die von Dritten erstellt wurden, zum Download an."
Und warum gibt es keine generischen Binärpakete? Wegen der Inkompatibilität. Die Entwickler würden bestimmt gerne generische Binärpakete anbieten, können es aber wegen der Fragmentierung nicht. Sun will eben nicht, dass dasselbe mit seinem Eigentum passier
Schonmal selber QT, KDE und KOffice gembaut ? Hast du überhaupt eine Ahnung wie viele Libs dynamisch gelinkt werden ? Wenn man generische Pakete bauen wollte, dann müsste man entweder alles statisch reinlinken, was die Pakete extrem groß machen würde, oder man lässt alles weg, was nicht für einen Minimalbetrieb notwendig ist. Das würde jedoch bedeuten, daß viele Funktionen brach liegen.
Es wäre jedoch durchaus machbar.
Was du aber nicht zu begreifen scheinst ist die Tatsache, daß Distributionen hunderte oder sogar tausende Programme aus zich Projekten beeinhalten, während Java nur ein Projekt wäre. Wenn die Zersplitterung wirklich so ein großes Problem wäre, dann gäbe es doch längst dutzende von inkompatiblen Apache Projekten, oder auch massenhaft Forks von KDE, Gnome ... Diese Projekte laufen unter Lizenzen, die es ermöglichen den Quellcode nach eigenem Ermessen zu verändern, aber trotzdem fließen Änderungen wieder zum Ursprünglichen Projekt zurück, da viele den Aufwand eines Forks nicht wirklich auf sich nehmen wollen nur weil sie ein paar Funktionen dazupacken wollen.
Jetzt haben wir aber auch Projekte, bei denen zwar der Quellcode offen liegt aber nicht verändert werden darf, womit Forks nicht möglich sind. Als gutes Beispiel hätten wir da QMail. Schonmal einen QMail Server aufgesetzt ? Es gibt massenhaft inkompatible Patches, die den Mailserver mit den Funktionen ausstatten, die er schon längt hätte, wenn der Hauptentwickler eine offenere Lizenz verwenden würde. Sowas nenne ich Zersplitterung. An QMail als solches wurde seit Jahren nichts mehr gemacht, und die ständige Patcherei geht einen auf den Keks. Also sucht man sich einen anderen Mailserver wie z.B. Postfix oder Exim.
Jetzt stelle man sich mal vor Sun würde Pleite gehen oder von jemandem aufgekauft werden, der mit der Java Plattform nichts am Hut hat und .NET vorzieht. Dann werden über kurz oder lang alle Java Projekte sterben. Ob es Sun passt oder nicht aber sie haben eine gewisse Verantwortung den Nutzern von Java gegenüber, und sollten Vorkehrungen treffen für den Fall der Fälle.
Trolltech hat z.B. einen Vertrag geschlossen, der es ermöglicht für den Fall einer Einstellung von QT die letzte freie Version unter eine BSD ähnlichen Lizenz zu stellen. Damit ist sichergestellt, daß die QT Lib den Nutzern und Entwicklern auch weiter zur Verfügung steht.
So nebenbei. Zur Zeit gibt es 3 Javaversionen. Die von Sun, die von IBM und die vom Blackdown Projekt. Wenn Sun eine freie Lizenz wählt, dann könnten die 3 Parteien zusammenarbeiten, statt sich gegenseitig auf die Füße zu treten.
Von Gabriel Welsche am Do, 23. Juni 2005 um 09:47 #
Jetzt stelle man sich mal vor Sun würde Pleite gehen oder von jemandem aufgekauft werden, der mit der Java Plattform nichts am Hut hat und .NET vorzieht. Dann werden über kurz oder lang alle Java Projekte sterben. Du vergisst die Macht und das Geld der Konzerne. IBM, BEA usw. haben ein sehr starkes Interesse, Ihre Produkte weiterzuentwickeln und vermarkten zu können (z.B. Rational-Palette, etc). Ergo: Das finanzielle Interesse ist derart gross, dass Java nicht sterben wird, auch wenn Sun Pleite geht.
Daß das jedoch nur ein vorgeschobener Grund von Sun ist
Dem stimme ich zu, allerdings aus anderen Überlegungen. Der immer wiederkehrende Ruf nach Freigabe hält den Namen Sun in den Medien, praktisch das Marketing Äquivalent zu einem "running gag".
Ich vermute Java ist für Sun praktisch nur mehr ein reines Marketingintrument, richtig einsetzen tun es hauptsächlich anderen (zb IBM)
Und wenn ich auch generell die Relizenzierung als Freie Software gut finden würde, das derzeitig meiner Meinung nach größere Problem, die restriktiven Distributionsauflagen, wäre auch zu lösen, ohne die Kontrolle über Quellen oder Entwicklung aufzugeben.
Aber Gott sei Dank wird ja darauf keine Beachtung gelenkt, weil die Diskussion scheinbar nur alles-oder-nichts kennt
> Der immer wiederkehrende Ruf nach Freigabe hält > den Namen Sun in den Medien, praktisch das > Marketing Äquivalent zu einem "running gag".
Unsinn. Diese ständigen Diskussionen schaden Sun, weil sie den Eindruck erwecken, dass Sun sein Eigentum nicht mehr unter Kontrolle hat, stattdessen stärken sie das Konkurrenzprodukt von Microsoft, weil da jeder weiß, das Microsoft seine Plattform voll unter Kontrolle hat, sich von niemandem reinreden lässt und die Plattform geradeaus führt und nicht in zig Verzweigungen.
> Ich vermute Java ist für Sun praktisch nur > mehr ein reines Marketingintrument, richtig > einsetzen tun es hauptsächlich anderen (zb IBM)
Aber selbstverständlich nutzt Sun Java auch selbst, bloß ist es dann auch wieder nicht recht, Stichwort OpenOffice.org. Es ist einfach "in", in der OpenSource-Welt gegen Sun zu sein. Sun kann es den Leuten nicht recht machen. Die Leute verlangen Dinge von Sun, die Sun nicht tun kann. Es gehört sich einfach so, dass man in der OpenSource-Welt gegen Sun ist.
> Und wenn ich auch generell die Relizenzierung > als Freie Software gut finden würde, das derzeitig > meiner Meinung nach größere Problem, die restriktiven > Distributionsauflagen, wäre auch zu lösen, ohne die > Kontrolle über Quellen oder Entwicklung aufzugeben.
Was sind denn das für restriktive Distributionsauflagen? Warum willst Du Java verteilen? Dafür gibt des die Webseiten java.com (für Konsumenten) und java.sun.com (für Entwickler). Du brauchst Java nicht zu verteilen, das erledigt Sun für Dich. Übrigens: Auf CDs darfst Du Java verbreiten, wenn auf der CD auch selbstentwickelte Java-Software drauf ist. Nur nicht einfach so zum Spaß, aber dafür gibt es die Downloadseiten von Sun.
Das einzige Argument, das ich verstehen könnte, besteht darin, dass die Downloads von Sun schwer zu installieren sind. An der Stelle ist es aber völlig daneben, mit dem Finger auf Sun zu zeigen. Es ist nicht Suns Schuld, dass es unmöglich ist, Software zu verpacken, dass sie auf mehreren Distributionen installierbar ist. Für Microsoft Windows ist das komischerweise kein Problem. Dieses private Problem der Distributoren sollten die Distributoren lösen, eine uneingeschränkte Distributionserlaubnis würde nur Symptome kaschieren.
Es ist nicht Suns Schuld, dass es unmöglich ist, Software zu verpacken, dass sie auf mehreren Distributionen installierbar ist. Für Microsoft Windows ist das komischerweise kein Problem.
hier verwechselst du leider Ursache und Wirkung. Es gibt sehr wohl, sehr einfache Installationsmechanismen für GNU/Linux oder auch *BSD Systeme. Es gibt nämlich was viel schöneres wie Binärkompartibilität und das ist "Quellcodekompatibilität". Zum Beispiel habe ich ein freies Java System gazn einfach installiert (apt-get install foo-java, emerge foo-java,...) das ist einfacher und besser als jede exe Datei. Das ist das gleiche wie das ewige gejammere bei den Treibern. Es gibt eine ganz einfache Art Treiber für Linux zu verfügung zu stellen. Man schreibt sie (oder gibt die Infos raus, damit dritte sie schreiben können) und commited sie dann in den aktuellen Linux-Zweig und schon kann jeder sein GNU/Linux System installieren und alles läuft out-of-the-box. Besser als jede exe Datei. Man muß nur bereit sein, sich an die Umwelt eines Systems anzupassen. Wenn man Software nach "windows-schema" für GNU/Linux anbieten will ist klar dass es komplizierter ist.
> Es gibt nämlich was viel schöneres wie Binärkompartibilität und das > ist "Quellcodekompatibilität".
Wozu wird hier eigentlich noch diskutiert? Wer ernsthaft denkt, die große Masse der Anwender ist mit Quellcodekompatibilität zufrieden, dem ist nicht mehr zu helfen.
> das ist einfacher und besser als jede exe Datei.
Das ist nur solange einfacher (wenn man das wohlwollenderweise als einfacher ansehen möchte), solange da auch jemand ein Paket oder einen Port gebaut hat. Ist Dir eigentlich bewusst, wieviele Mannjahre durch die Pakete/Ports für weit mehr als 100 Linuxdistris draufgehen? Jeder Ökonom schlägt da die Hände über dem Kopf zusammen. Stell Dir vor, die vielen Paketbauer hätten auf einmal Zeit, Software für Linux zu entwickeln, weil es Binärkompatibilität gibt.
> Das ist das gleiche wie das ewige gejammere bei den Treibern.
Das Thema hatten wir doch erst gestern oder vorgestern. Wenn Du es da noch nicht begriffen hast, wirst DU es auch jetzt nicht tun. Du wirst aber sehen, dass nicht alle HW-Hersteller bereit sein werden, sich in ihre Betriebsgeheimnisse schauen zu lassen. Ich weiß, die sind alle böse und profitgeil, aber es ist ihr gutes Recht. Fang doch ne Revolution an, da bist Du wenigstens beschäftigt.
> Man muß nur bereit sein, sich an die Umwelt eines Systems anzupassen.
Du überschätzt Dich/die Linuxwelt ganz gehörig. Warum sollten sich Hersteller an 90% des Marktes zu bedienen?
Jeder Ökonom schlägt da die Hände über dem Kopf zusammen.
jaja, was die Ökonomen einem alles so vorrechnen können... :))
Du wirst aber sehen, dass nicht alle HW-Hersteller bereit sein werden, sich in ihre Betriebsgeheimnisse schauen zu lassen.
ja, wie Intel vor ein paar Jahren. Da wollten sie auch keine Treiber Infos rausgeben wegen ihren tollen "Betriebsgeheimnissen". Das Ergebnis: die Leute haben sich die Hardware ganz genau angesehen um Treiber schreiben zu können. Die Folgen: Nachher war über die Technik viel mehr bekannt als jemals bekannt geworden wäre wenn Intel einfach die Infos für die Treiberentwicklung veröffentlicht hätte.
Du überschätzt Dich/die Linuxwelt ganz gehörig. Warum sollten sich Hersteller an 90% des Marktes zu bedienen?
Nein, mir geht es weder um mich noch um irgendeine "Linuxwelt" oder darum irgendjemand zu irgendetwas zu zwingen. Ich stelle nur fest, dass es ein alternativen Weg der Softwareentwicklung und Verteilung gibt -> Freie Software. Wenn man diesen Weg beschreitet, dann ist es auch nicht schwerer für die Systeme gute Software anzubieten. Genauso wie man sich auch auf die Windows, MacOS,... Art der Softwareentwicklung und Verteilung einstellen muß wenn man auf den Systemen optimal arbeiten will. Man kann sich weigern sich auf diese Arbeitsweise einzulassen, dann kann man sich aber nicht beschweren das die anderen Wege so kompliziert sind.
> jaja, was die Ökonomen einem alles so vorrechnen können...
Man muss kein Ökonom sein, um 100*1 und 1*1 rechnen zu können. Wenn Du das nicht kannst, ist Dir nicht zu helfen. Und dieses typische Misstrauen gegen Ökonomen hängt mir auch zum Halse raus. Würde man mal auf Ökonomen statt auf Ideologen und Gewerkschafter hören, wäre Deutschland jetzt nicht Schlusslicht in Europa.
> dann ist es auch nicht schwerer für die Systeme gute Software anzubieten.
Dann hast Du aber auch noch nie komplexere OpenSource-Software entwickelt. Was denkst Du, wie gut sich Fehler finden lassen, die ihre Ursache in den vielen Kombinationsmöglichkeiten aus mehreren Bibliotheken und deren vielfältigen Optionen haben. Von hardwarenaher Programmierung ganz zu schweigen. Wie kann man überhaupt auf die Idee kommen, es besser zu finden, wenn man hundert inkompatible Systeme hat als wenn es meinetwegen 100 kompatible gäbe. Das ist doch nichts weiter als Zweckideologie. Wären alle Distris kompatibel zueinander, dann würdest Du Dich jetzt über die inkompatiblen BSD-Spielarten beschweren.
>Es gibt nämlich was viel schöneres wie Binärkompartibilität und das >ist "Quellcodekompatibilität".
>Das ist das gleiche wie das ewige gejammere bei den Treibern. >Man schreibt sie (oder gibt die Infos raus, damit dritte sie schreiben >können) und commited sie dann in den aktuellen Linux-Zweig und schon >kann jeder sein GNU/Linux System installieren und alles läuft >out-of-the-box. Besser als jede exe Datei.
>Wenn man Software nach "windows-schema" für GNU/Linux anbieten will >ist klar dass es komplizierter ist.
Das hast Du schön auf den Punkt gebracht. Auf diese weise erhält man sogar eine bessere Platformunabhängigkeit als wenn man den Umweg über eine VM geht. Die dann eh nicht auf allen gewünschten Plattformen zur Verfügung steht.
Aber auf vernünftige Gegenargumente brauchst Du jetzt bei den "üblichen Verdächtigen" nicht mehr hoffen. Denn bei Wörtern wie "Quellcodekompatibilität" hört bei denen der Verstand auf.
Ach bist Du klug. Du entwickelst bestimmt jeden Tag Software... Stell Dir vor, unter Windows habe ich Binär- _und_ Quellcodekompatibilität. Und das mindestens von w98 bis wxp. Da habe ich die Freiheit, die eine oder andere Variante zu wählen. Unter Linux habe ich nur letzteres. Und weil die Linuxcommunity nicht in der Lage ist, auch ersteres sicherzustellen, wird die Quellcodekompatibilität plötzlich zum Dogma erhoben. Das ist an Stumpfsinn nicht mehr zu überbieten. So eine unfähige Konkurrenz, wie MS sie hat, hätten andere gern.
Aber selbstverständlich nutzt Sun Java auch selbst
Ich hab das vielleicht nicht gut formuliert. Selbstverständlich benutzt Sun selbst auch Java, auch als Produktbezeichnung (siehe JDS). Ich meinte, daß es bei IBM viel mehr Kernstück ihres Solutionbusiness ist, bei Sun steht als Verkaufargument immer Solaris an erster Stelle.
Liegt vermutlich auch daran, daß diese beiden Firmen nicht wirklich im selben Markt sind, also eher anderen Zielsetzungen haben.
Was sind denn das für restriktive Distributionsauflagen?
Ich glaube es ist zum Beispiel untersagt, die Sun VM auf dem selben Distributionsmedium zu habe wie eine andere JVM.
Warum willst Du Java verteilen?
Weniger Aufwand für die Benutzer, keine Notwendigkeit für Downloads, Vorinstallierung, etc.
Auf CDs darfst Du Java verbreiten, wenn auf der CD auch selbstentwickelte Java-Software drauf ist
Ist mir bekannt, nur widerspricht das aus meiner Sicht der Write-Once-Run-Anywhere Idee wenn ich auf einer CD mit meinem ansich plattformunabhängigen Programm JVM Pakete für alle Zielplattformen raufpacken muß. Ich sehen einen wesentlichen Vorteil von Java Programmen schon in der Tatsache, daß mehr oder weniger ein gut gebautes JAR ausreichend ist.
Ich müßte mich vielleicht mal im Detail mit den Lizenzbestimmungen beschäftigen, aber ich gehe davon aus daß es aus rechtlichen Gründen kein Sun JDK/JRE Paket im Debian Package Pool gibt (non-free; private apt Quelle wäre auch OK) und ich darum in die Steinzeit der Softwareinstallation mit manuellem Download und separater Installation zurückgeworfen werde.
Dieses private Problem der Distributoren sollten die Distributoren lösen
Absolut! Nur manchmal scheint das nicht gewünscht zu sein, IIRC gibt es ähnliche Probleme mit der Distributionslizenz von Acrobat Reader.
Python ist GPL und wird auch nicht geforked, es ist sogar das write once run anywhere besser umgesetzt als in JAVA (run once, debug anywhere). Und wenn Java wirklich frei währe, würde es auf JEDER Distribution standardmäßig mit dabei sein, und wäre ganz einfach mittels Paketmanager zu installieren. DAS würde JAVA ordentlich Rückenwind geben, und die Programmierer könnten sich darauf verlassen dass auf dem Zielsystem ein JAVA vorhanden ist, und sie somit nicht immer JAVA mitliefern müßten. Abgesehen davon würde ein VOLLSTÄNDIGES und KOMPATIBLES JAVA auf jede Architektur portiert werden, was ja momentan auch nicht der Fall ist.
Der Aussage stimme ich zu 100% zu.
Daß Sun es anders sieht, obwohl sie solche Argumente wie die von Manes schon des öfteren zu hören bekam, läßt so manchen an Suns Argumentation zweifeln.
Noch immer meint Sun, daß sie bloß "inkompatible Java-Versionen" vermeiden wollen.
Daß das jedoch nur ein vorgeschobener Grund von Sun ist, müßte nun jedoch wohl den meisten Menschen klar sein.
> Sun ist, müßte nun jedoch wohl den meisten
> Menschen klar sein.
Mir ist es das nicht, könntest Du es vielleicht erklären? Es gibt doch genug Beispiele für Fragmentierung, klick doch einfach mal die dritte Meldung vor dieser hier an, dann wirst Du schon sehen, was ich meine:
"KOffice 1.4 kann als Quellcode von zahlreichen Mirror-Servern heruntergeladen werden. [...] Das Projekt selbst erstellt keine Binärpakete, bietet jedoch Pakete, die von Dritten erstellt wurden, zum Download an."
Und warum gibt es keine generischen Binärpakete? Wegen der Inkompatibilität. Die Entwickler würden bestimmt gerne generische Binärpakete anbieten, können es aber wegen der Fragmentierung nicht. Sun will eben nicht, dass dasselbe mit seinem Eigentum passiert.
Dies ist zu respektieren, schließlich ist es das Eigentum von Sun und nicht von irgendjemand anderem. Eigentümer sind nun mal berechtigt, über ihr Eigentum zu verfügen, damit muss man nicht einverstanden sein, es ändert aber nichts an den Eigentumsverhältnissen.
Das kann gut sein. Hat aber mit Java nichts zu tun.
Das Problem der verschiedenen Linux-Distributionen ist, daß Linux nur der Kernel ist. Und auch Linus Torvalds läßt viele Kernel-Modifikationen weiterhin den Namen "Linux" tragen.
Java hingegen ist ein Komplettpaket. Da ist die Virtuelle Maschine, und die Klassen und alles andere dabei.
Sun kann auch wenn Java OpenSource wäre, bestimmen was sich "Java" nennen darf. Und das reicht völlig aus - wie auch Herr Manes meinte.
Hinzu kommt, daß dadurch, daß Java nicht OpenSource ist, gerade Projekte wie GNU Classpath entstanden sind. Womit durch Suns Lizenzpolitik genau das Gegenteil von dem entstanden ist, was Sun angeblich erreichen wollte.
Desweiteren wird durch Suns Lizenzpolitik bezüglich Java die Verbreitung von Java gehemmet. Es ist nun einmal nicht so leicht, in einer geschlossenen Gruppe Java auf andere Plattformen zu portieren. Es ist ja bekanntlich verboten, Zwischenschritte einer Portierung zu veröffentlichen.
Wäre Java OpenSource würde es z.B. schon längst ein Java für BeOS geben.
Und was die Java-Versionen für Linux-ppc angeht, so sieht es dort seit einiger Zeit auch Mau aus.
Zähl' mal die aktuell unterstützten Hardware-Plattformen von Blackdown (womit ich Java1.4 und Java5 meine). Fällt Dir was auf?
> Dies ist zu respektieren, schließlich ist es das Eigentum von Sun und nicht von irgendjemand
> anderem. Eigentümer sind nun mal berechtigt, über ihr Eigentum zu verfügen, damit muss man
> nicht einverstanden sein, es ändert aber nichts an den Eigentumsverhältnissen.
Was Sun mit seinem Eigentum macht ist eine Sache. Falsche Behauptungen in die Welt zu setzen, weshalb sie angeblich ihr Java nicht unter eine OpenSource Lizenz stellen, ist eine andere Sache.
Das sagt sich so leicht. Natürlich hat die konkrete Software namens "KOffice" nichts mit der konkreten Software namens "Java" zu tun. Trotzdem können beide sehr wohl ähnlichen Entwicklungen unterworfen sein, wenn sie ähnlichen Entwicklungsmodellen folgen!
> 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.
> Java hingegen ist ein Komplettpaket. Da ist die
> Virtuelle Maschine, und die Klassen und alles andere
> dabei.
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. Dieses "Linux ist nur ein Kernel"-Ablenkungsmanöver ist voll daneben.
> Sun kann auch wenn Java OpenSource wäre, bestimmen
> was sich "Java" nennen darf. Und das reicht völlig
> aus - wie auch Herr Manes meinte.
Was ausreicht, entscheidet immer noch der Eigentümer selbst und nicht irgendjemand anderes, der Ansprüche oder meinetwegen auch nur Wünsche an fremdem Eigentum anmeldet.
> Hinzu kommt, daß dadurch, daß Java nicht OpenSource
> ist, gerade Projekte wie GNU Classpath entstanden
> sind. Womit durch Suns Lizenzpolitik genau das
> Gegenteil von dem entstanden ist, was Sun angeblich
> erreichen wollte.
Dieses Argument ist richtig. Allerdings weiß jeder, dass Java und Classpath zweierlei sind, weil sie einen unterschiedlichen Ursprung haben. Wäre Java OpenSource, dann hätten inkompatible Ableger denselben Ursprung und selbst wenn auf dem Weg des Markenrechts eine Unterscheidung möglich wäre, hätte es eine anderes, geringeres Gewicht als die ganz klare Durchsage "Das hier ist von mir und alles andere ist nicht von mir, sondern Dein Problem".
Außerdem würden sowieso weitergehende Forderungen kommen, wenn Java denn OpenSource wäre. Wir hatten das Thema doch neulich schon: Mozilla ist OpenSource, aber nein, das reicht einer bekannten Distribution nicht, diese bekannte Distribution will Mozilla nicht nur verändern, was dank OpenSource kein Problem ist, sondern das Resultat auch noch Mozilla nennen und erhebt mahnend den Zeigefinger, wenn sie es nicht darf. Manchmal ist es notwendig, einfach eine unmissverständliche Grenze zu ziehen, weil sonst nicht klar ist, welche Forderungen vom Eigentümer definitiv nicht akzeptiert werden.
> 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.
> Es ist nun einmal nicht so leicht, in einer geschlossenen
> Gruppe Java auf andere Plattformen zu portieren. Es ist ja
> bekanntlich verboten, Zwischenschritte einer Portierung zu
> veröffentlichen.
- Wie kommst Du darauf, dass eine Portierung auf andere Plattformen vom Eigentümer erwünscht ist?
- Blackdown kriegt es hin für Linux
- Apple kriegt es hin für Mac OS X
- HP kriegt es hin für HP-UX und OpenVMS
- innotek kriegt es hin für OS/2
- IBM kriegt es hin für Linux und AIX und weitere Systeme
Nur die OpenSource-Welt ist unzufrieden, weil es ihnen und nur ihnen nicht passt. Andere kommen bestens klar.
Ich frage mich wirklich, wieviele hochzufriedene Anwender auf Standardplattformen den paar lautstarken fingererhebenden Kritikern gegenüberstehen. Man kann auch einfach mal zur Kenntnis nehmen, dass man nicht so wichtig ist, das ist kein Beinbruch.
> Wäre Java OpenSource würde es z.B. schon längst
> ein Java für BeOS geben.
Wie kommst Du darauf? Das ist eine mutige Behauptung. Am nähesten an einem Java-Port war BeOS, als Be Inc. noch lebte und sich dafür engagierte. Seitdem Be Inc. tot und BeOS der Community unterworfen ist, ist es viel weiter weg, das widerspricht doch der Logik. Außerdem ist BeOS unwichtig.
> Und was die Java-Versionen für Linux-ppc angeht,
> so sieht es dort seit einiger Zeit auch Mau aus.
Wie kommst Du darauf, dass Java auf Linux/ppc überhaupt laufen soll? Es hieß niemals, aber auch wirklich niemals, dass Java überall läuft. Es hieß immer nur, dass es dort läuft, wo eine Laufzeitumgebung existiert.
> Zähl' mal die aktuell unterstützten Hardware-
> Plattformen von Blackdown (womit ich Java1.4 und
> Java5 meine).
Java für Linux/ppc bietet nicht Blackdown an, sondern IBM. IBM bezahlt dafür Geld an Sun und weiteres Geld für die eigene Portierungsarbeit. Es würde überhaupt keinen Unterschied machen, wenn Java OpenSource wäre. Auch wenn Java OpenSource wäre, würde die Portierung für Linux/ppc lange dauern, eventuell sogar noch länger. Durch OpenSource kommst Du nicht schneller zu einem Java für Linux/ppc!
> Fällt Dir was auf?
Ja, mir fällt auf, dass Du Java für Linux/ppc verlangst, als ob es Dir zustehen würde, obwohl das niemals der Deal war. Ursprünglich war es sogar so gedacht, dass der Hersteller jeder Plattform sein Java selbst portiert. Das wurde aufgeweicht, weil Microsoft Mist gebaut hat und es im Linux-Bereich so nicht geht, deswegen bietet Sun Java auch für Windows/x86 und Linux/x86 an.
Daraus jetzt die Forderung abzuleiten, es solle doch bitte jede Plattform bedient werden, ist völlig daneben. Selber portieren kannst Du jetzt schon, dafür brauchst Du keine OpenSource-Lizenz, sondern nur Menschliche Arbeitszeit, die Du auch bei OpenSource bräuchstest.
> Was Sun mit seinem Eigentum macht ist eine Sache.
> Falsche Behauptungen in die Welt zu setzen, weshalb
> sie angeblich ihr Java nicht unter eine OpenSource
> Lizenz stellen, ist eine andere Sache.
Welche Behauptung soll angeblich falsch sein? Ich sehe hier nur falsche Behauptungen nach dem Motto "wenn es OpenSource wäre, wäre es viel portabler" (stimmt nicht, die Arbeit müsste genauso erledigt werden) und "viele Menschen leiden darunter, dass es nicht OpenSource ist" (stimmt nicht, die überwältigende Mehrheit ist hochzufrieden).
>> 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.
Dass es nicht ein Binärpaket für alle Distributionen gibt, liegt ganz sicher nicht am Entwicklungsmodell von KOffice, sondern daran, dass die Linux-Distributoren ihre eigenen Süppchen kochen.
> 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. Dieses "Linux ist nur ein Kernel"-Ablenkungsmanöver ist voll daneben.
Dass es kein generisches Binärpaket von Qt/X11, das auf allen Plattformen läuft, liegt also daran, dass Qt/X11 OpenSource ist? Ja dann dürften ClosedSource-Hersteller doch überhaupt kein Problem damit haben, Anwendungen für Linux zu schreiben. Da diese Anwendungen ClosedSource sind, laufen sie nach deiner Theorie ja überall.
Wo ist denn bitte das Problem, wenn ausschließlich offizielle Versionen von Sun den Logo und den Namen "Java" nutzen dürfen?
Dann braucht auch nichts zusätzlich zertifiziert werden. Mögliche Forks gehen halt leer aus.
Weil das vermutlich zwar technisch machbar ist, aber vermutlich auch langsamer.
Entweder ist das Paket native für eine Plattform, dann müssen es alle anderen emulieren oder gleich generischer Binärcode wie bei Java oder ähnlichen Technologien, die dann überall emuliert oder JIT kompiliert werden müssen.
Derzeit sind zwar in gewissen Grenzen beide Realisierungen im Einsatz, aber "echt native" wird doch von den meisten Benutzern bevorzugt.
Provoziert wird das durch die Tatsache, dass sich jeder Distributor alles selbst kompiliert und anders konfiguriert. Das wäre bei Java genau dasselbe, es würde unter dem möglicherweise sogar gut gemeinten Argument der "besseren Integration" genauso gemacht werden, und fertig ist die Zersplitterung. Brauchen wir das wirklich auch für Java? Wer es braucht, soll es soch bitte selbst machen, und zwar nicht auf der Basis des Eigentums von anderen, sondern wirklich von Grund auf selbst.
Allerdings ist Binärkompatibilität hier in diesem Forum wirklich ein heikles Thema. Der Lösungsvorschlag lautet dann meistens, dass sich ja jeder alles selbst kompilieren könnte, wenn die Unternehmen ihr Eigentum unter die GPL stellen würden. Bloß ist das eben halt genau das, was Java nicht ist und nie sein soll. Das nimmt man entweder zur Kenntnis oder man lässt es bleiben und baut es sich selbst so nach, wie man es haben will.
Ein OpenSource-Java wäre einfach nicht zertifizierbar, die Tests einer Zertifizierung können nur mit Binaries durchgeführt werden, weil beim Endverbraucher ja auch Binaries am Werk sind. Also müsste statt Sun 1.5.0 und Blackdown 1.4.2 und Sun 1.4.2 jetzt jede einzelne Distribution einzeln zertifiziert werden, mit dem Ergebnis, dass man die weniger wichtigen Distributionen überhaupt nicht mehr zertifizieren kann.
Würde man versuchen, einen Quelltext und kein Binary zu zertifizieren, dann wäre der Ärger vorprogrammiert. Der eine Distributor kompiliert es mit dem GCC 3.2 und der andere mit dem GCC 4.0. Problem: wxWidgets funktioniert mit dem GCC 4.0 noch gar nicht, das könnte mit Java genauso sein. Also müsste man dann sagen, dieser Quelltext sei nur dann zertifiziert, wenn er mit dem GCC 3.2 kompiliert wird. Problem: GCC ist nicht gleich GCC, wenn eine Distribution einen gepatchten GCC drauf hat, dann kann auch ein Binary entstehen, das nicht funktioniert.
Man kann es drehen und wenden, wie man will: Die Interessen von Sun und die Interessen einer kleinen Minderheit von anderen Leuten passen nicht zusammen und sind unversöhnlich, es ist völlig müßig, immer wieder dasselbe von Sun zu fordern. Sun hat wichtigere Kunden und wird auf die aus der Sicht von Sun unwichtigen, die ja auch gar keine Kunden sind, definitiv keine Rücksicht nehmen. Die Forderungen sind sinnlos, wer sie weiter stellt, verschwendet Energie, die er auch darin investieren könnte, was eigenes zu machen.
Soweit konnte ich dir schon folgen :)
Und ferner rede ich nicht von unterschiedlichen Plattformen
Da hatte ich wohl eine andere Interpretation von generisch, besonders im Kontext KOffice. Linux ist ja nur eine Plattform auf die KDE abzielt, somit wäre ein einzelnes Binary für mich nur dann generisch, wenn es auf allen Zielplattformen läuft.
Sobald das nicht erfüllt ist, muß man ohnehin verschiedene Builds machen und ist dann mangels entsprechender Buildsystem auf Hilfe anderer angewiesen.
Das wäre bei Java genau dasselbe
Ich glaube das eher nicht.
Die ABI ist immer gleich, die Programme meistens in einer einzigen JAR Datei.
Ich hatte bei meinen Java Programmen bisher keine Probleme mit anderen JVMs auf der selben Plattform, am ehesten ist die Implementation von Sun die Schlechteste (unter Linux, auf Solaris sicher die Beste ;))
passen nicht zusammen und sind unversöhnlich
Wie ich schon im anderen Posting geschrieben habe halte ich das persönlich für eine Absicht von Seiten Suns.
Wäre ihnen die Diskussion unangenehm oder lästig, würde nicht alle X Tage einer ihrer Chiefs entsprechend darüber Kommentare ablassen sondern einfach warte, bis der Publicity Hype daran abgeklungen ist.
> allen Zielplattformen läuft.
Abstrakt gesehen kann man Deine Interpretation ohne weiteres gelten lassen. Die traurige Situation ist jedoch die, dass man schon von generisch sprechen muss, wenn ein Binary auf allen (schränken wir es ruhig etwas ein: allen aktuellen) Distributionen liefe. Aber das kann man vergessen.
> Ich hatte bei meinen Java Programmen bisher keine Probleme mit anderen JVMs auf
> der selben Plattform
Ich hab zwei ausprobiert (eine war Sable), die schafften es nicht mal, kleine Javaprogramme auch nur zu starten. Mit der VM von Sun läuft alles problemlos.
klar geht das, genaugenommen gibt es zwei Möglichkeiten (im Prinzip die gleichen wie bei Windows):
1. Du linkst dein Programm statisch.
2. du packst alle libs gegen die du gelinkt hast mit in dein Paket.
Beides ist aber sub-optimal (auch unter windows), gerade der Vorteil von freien Systemen ist ja, dass man nicht zig Versionen von einer lib braucht oder jeder sie selber mitbringen muß, sondern das man es einfach direkt für sein System gegen die vorhandenen libs linken kann. Dafür gibt es wieder zwei Möglichkieten:
1. Man hat ein OS von einem bestimmten Anbieter, dann übernimmt dieser für dich die Aufgabe und bietet dir fertige Pakete an
2. Du hast ein individuelles System, dann nimmst du dir das programm und linkst es selber gegen deine libs.
Eigentlich einen riesen Vorteil, man muß ihn nur nutzen indem man das System versteht und für seine eigene Software anwendet.
Mit der VM von Sun läuft alles problemlos.
Vermutlich hat sich das auch gebessert.
Meine schlechten Erfahrungen kommen von der 1.3.1 Zeit, wo die Blackdown JVM der von Sun weit überlegen war, so daß ich doch den Eindruck hatte, die Sun VM ist künstlich verschlimmbessert worden.
Die von Blackdown war auch meinen höchsten Anforderungen gewachsen.
SableVM hab ich noch nicht probiert, kann darüber also keine Aussage treffen.
Wenn ein paar Millionen Nutzer eine kleine Minderheit sind, was ist denn dann Sun?!
Hi,
zu Deinem weiter oben angefuehrten Fork-Argument: Dass wir gerade mehrere javaehnliche Implementierungen der selben Sache haben (die aber in vielen Faellen wegen Suns Zicken auf diesem Gebiet noch nicht einmal dem Original ebenbuertig sein koennen), liegt doch genau an Suns Politik. Dass eine Offenlegung einen Fork moeglich macht, ist nicht von der Hand zu weisen (so what?!), das von Sun behauptete Gegenteil ist aber widerlegt!
Und die Chance, dass ein erfolgreicher Fork wieder in eine gemeinsame Codebasis zurueckfliesst, ist eben auch nur mit FOSS moeglich. Im Falle von Linux (Kernel) gibt es schliesslich auch eine zentrale Linie, mit der jeder machen darf, was er will - dennoch koennte man eine (bei diesem Beispiel kernelspezifische) Anwendung genau fuer einen Vanilla-Kernel zertifizieren. Zu gewaehrleisten, dass die Zertifizierung auch mit distro-eigenen Kerneln noch ihre Gueltigkeit hat, laege dann in der Verantwortung der jeweiligen Distro.
cu
Valentin Born
> die in den Paketen stecken. Und ferner rede ich nicht von unterschiedlichen
> Plattformen, deren Binaries auf anderen Plattformen "emuliert" werden müssten,
> sondern von einer einzigen Plattform, Linux/x86. KOffice, kompiliert auf einem
> x86-Mandriva-System, ist nicht binärkompatibel mit einem gleich alten
> x86-Fedora-System, obwohl sie dieselben kdelibs und dasselbe Qt drauf haben.
Das ist definitiv falsch! Kompiliere Koffice statisch (wird ein grosses Monster) und es wird auf allen aktuellen Distriebutionen laufen. Das Problem sind die dynamische Libs die vorausgesetzt werden, daher nur der Source Code. Eigentlich ganz einfach und durchaus normal.
Gruss HAL-9000
Und warum gibt es keine generischen Binärpakete? Wegen der Inkompatibilität. Die Entwickler würden bestimmt gerne generische Binärpakete anbieten, können es aber wegen der Fragmentierung nicht. Sun will eben nicht, dass dasselbe mit seinem Eigentum passier
Schonmal selber QT, KDE und KOffice gembaut ? Hast du überhaupt eine Ahnung wie viele Libs dynamisch gelinkt werden ?
Wenn man generische Pakete bauen wollte, dann müsste man entweder alles statisch reinlinken, was die Pakete extrem groß machen würde, oder man lässt alles weg, was nicht für einen Minimalbetrieb notwendig ist. Das würde jedoch bedeuten, daß viele Funktionen brach liegen.
Es wäre jedoch durchaus machbar.
Was du aber nicht zu begreifen scheinst ist die Tatsache, daß Distributionen hunderte oder sogar tausende Programme aus zich Projekten beeinhalten, während Java nur ein Projekt wäre. Wenn die Zersplitterung wirklich so ein großes Problem wäre, dann gäbe es doch längst dutzende von inkompatiblen Apache Projekten, oder auch massenhaft Forks von KDE, Gnome ...
Diese Projekte laufen unter Lizenzen, die es ermöglichen den Quellcode nach eigenem Ermessen zu verändern, aber trotzdem fließen Änderungen wieder zum Ursprünglichen Projekt zurück, da viele den Aufwand eines Forks nicht wirklich auf sich nehmen wollen nur weil sie ein paar Funktionen dazupacken wollen.
Jetzt haben wir aber auch Projekte, bei denen zwar der Quellcode offen liegt aber nicht verändert werden darf, womit Forks nicht möglich sind. Als gutes Beispiel hätten wir da QMail. Schonmal einen QMail Server aufgesetzt ? Es gibt massenhaft inkompatible Patches, die den Mailserver mit den Funktionen ausstatten, die er schon längt hätte, wenn der Hauptentwickler eine offenere Lizenz verwenden würde.
Sowas nenne ich Zersplitterung. An QMail als solches wurde seit Jahren nichts mehr gemacht, und die ständige Patcherei geht einen auf den Keks. Also sucht man sich einen anderen Mailserver wie z.B. Postfix oder Exim.
Jetzt stelle man sich mal vor Sun würde Pleite gehen oder von jemandem aufgekauft werden, der mit der Java Plattform nichts am Hut hat und .NET vorzieht. Dann werden über kurz oder lang alle Java Projekte sterben. Ob es Sun passt oder nicht aber sie haben eine gewisse Verantwortung den Nutzern von Java gegenüber, und sollten Vorkehrungen treffen für den Fall der Fälle.
Trolltech hat z.B. einen Vertrag geschlossen, der es ermöglicht für den Fall einer Einstellung von QT die letzte freie Version unter eine BSD ähnlichen Lizenz zu stellen. Damit ist sichergestellt, daß die QT Lib den Nutzern und Entwicklern auch weiter zur Verfügung steht.
So nebenbei. Zur Zeit gibt es 3 Javaversionen. Die von Sun, die von IBM und die vom Blackdown Projekt. Wenn Sun eine freie Lizenz wählt, dann könnten die 3 Parteien zusammenarbeiten, statt sich gegenseitig auf die Füße zu treten.
Du vergisst die Macht und das Geld der Konzerne. IBM, BEA usw. haben ein sehr starkes Interesse, Ihre Produkte weiterzuentwickeln und vermarkten zu können (z.B. Rational-Palette, etc). Ergo: Das finanzielle Interesse ist derart gross, dass Java nicht sterben wird, auch wenn Sun Pleite geht.
Dem stimme ich zu, allerdings aus anderen Überlegungen.
Der immer wiederkehrende Ruf nach Freigabe hält den Namen Sun in den Medien, praktisch das Marketing Äquivalent zu einem "running gag".
Ich vermute Java ist für Sun praktisch nur mehr ein reines Marketingintrument, richtig einsetzen tun es hauptsächlich anderen (zb IBM)
Und wenn ich auch generell die Relizenzierung als Freie Software gut finden würde, das derzeitig meiner Meinung nach größere Problem, die restriktiven Distributionsauflagen, wäre auch zu lösen, ohne die Kontrolle über Quellen oder Entwicklung aufzugeben.
Aber Gott sei Dank wird ja darauf keine Beachtung gelenkt, weil die Diskussion scheinbar nur alles-oder-nichts kennt
> den Namen Sun in den Medien, praktisch das
> Marketing Äquivalent zu einem "running gag".
Unsinn. Diese ständigen Diskussionen schaden Sun, weil sie den Eindruck erwecken, dass Sun sein Eigentum nicht mehr unter Kontrolle hat, stattdessen stärken sie das Konkurrenzprodukt von Microsoft, weil da jeder weiß, das Microsoft seine Plattform voll unter Kontrolle hat, sich von niemandem reinreden lässt und die Plattform geradeaus führt und nicht in zig Verzweigungen.
> Ich vermute Java ist für Sun praktisch nur
> mehr ein reines Marketingintrument, richtig
> einsetzen tun es hauptsächlich anderen (zb IBM)
Aber selbstverständlich nutzt Sun Java auch selbst, bloß ist es dann auch wieder nicht recht, Stichwort OpenOffice.org. Es ist einfach "in", in der OpenSource-Welt gegen Sun zu sein. Sun kann es den Leuten nicht recht machen. Die Leute verlangen Dinge von Sun, die Sun nicht tun kann. Es gehört sich einfach so, dass man in der OpenSource-Welt gegen Sun ist.
> Und wenn ich auch generell die Relizenzierung
> als Freie Software gut finden würde, das derzeitig
> meiner Meinung nach größere Problem, die restriktiven
> Distributionsauflagen, wäre auch zu lösen, ohne die
> Kontrolle über Quellen oder Entwicklung aufzugeben.
Was sind denn das für restriktive Distributionsauflagen? Warum willst Du Java verteilen? Dafür gibt des die Webseiten java.com (für Konsumenten) und java.sun.com (für Entwickler). Du brauchst Java nicht zu verteilen, das erledigt Sun für Dich. Übrigens: Auf CDs darfst Du Java verbreiten, wenn auf der CD auch selbstentwickelte Java-Software drauf ist. Nur nicht einfach so zum Spaß, aber dafür gibt es die Downloadseiten von Sun.
Das einzige Argument, das ich verstehen könnte, besteht darin, dass die Downloads von Sun schwer zu installieren sind. An der Stelle ist es aber völlig daneben, mit dem Finger auf Sun zu zeigen. Es ist nicht Suns Schuld, dass es unmöglich ist, Software zu verpacken, dass sie auf mehreren Distributionen installierbar ist. Für Microsoft Windows ist das komischerweise kein Problem. Dieses private Problem der Distributoren sollten die Distributoren lösen, eine uneingeschränkte Distributionserlaubnis würde nur Symptome kaschieren.
hier verwechselst du leider Ursache und Wirkung.
Es gibt sehr wohl, sehr einfache Installationsmechanismen für GNU/Linux oder auch *BSD Systeme.
Es gibt nämlich was viel schöneres wie Binärkompartibilität und das ist "Quellcodekompatibilität". Zum Beispiel habe ich ein freies Java System gazn einfach installiert (apt-get install foo-java, emerge foo-java,...) das ist einfacher und besser als jede exe Datei.
Das ist das gleiche wie das ewige gejammere bei den Treibern. Es gibt eine ganz einfache Art Treiber für Linux zu verfügung zu stellen. Man schreibt sie (oder gibt die Infos raus, damit dritte sie schreiben können) und commited sie dann in den aktuellen Linux-Zweig und schon kann jeder sein GNU/Linux System installieren und alles läuft out-of-the-box. Besser als jede exe Datei.
Man muß nur bereit sein, sich an die Umwelt eines Systems anzupassen. Wenn man Software nach "windows-schema" für GNU/Linux anbieten will ist klar dass es komplizierter ist.
> ist "Quellcodekompatibilität".
Wozu wird hier eigentlich noch diskutiert?
Wer ernsthaft denkt, die große Masse der Anwender ist mit Quellcodekompatibilität zufrieden, dem ist nicht mehr zu helfen.
> das ist einfacher und besser als jede exe Datei.
Das ist nur solange einfacher (wenn man das wohlwollenderweise als einfacher ansehen möchte), solange da auch jemand ein Paket oder einen Port gebaut hat. Ist Dir eigentlich bewusst, wieviele Mannjahre durch die Pakete/Ports für weit mehr als 100 Linuxdistris draufgehen? Jeder Ökonom schlägt da die Hände über dem Kopf zusammen. Stell Dir vor, die vielen Paketbauer hätten auf einmal Zeit, Software für Linux zu entwickeln, weil es Binärkompatibilität gibt.
> Das ist das gleiche wie das ewige gejammere bei den Treibern.
Das Thema hatten wir doch erst gestern oder vorgestern. Wenn Du es da noch nicht begriffen hast, wirst DU es auch jetzt nicht tun. Du wirst aber sehen, dass nicht alle HW-Hersteller bereit sein werden, sich in ihre Betriebsgeheimnisse schauen zu lassen. Ich weiß, die sind alle böse und profitgeil, aber es ist ihr gutes Recht. Fang doch ne Revolution an, da bist Du wenigstens beschäftigt.
> Man muß nur bereit sein, sich an die Umwelt eines Systems anzupassen.
Du überschätzt Dich/die Linuxwelt ganz gehörig. Warum sollten sich Hersteller an 90% des Marktes zu bedienen?
jaja, was die Ökonomen einem alles so vorrechnen können... :))
Du wirst aber sehen, dass nicht alle HW-Hersteller bereit sein werden, sich in ihre Betriebsgeheimnisse schauen zu lassen.
ja, wie Intel vor ein paar Jahren. Da wollten sie auch keine Treiber Infos rausgeben wegen ihren tollen "Betriebsgeheimnissen". Das Ergebnis: die Leute haben sich die Hardware ganz genau angesehen um Treiber schreiben zu können. Die Folgen: Nachher war über die Technik viel mehr bekannt als jemals bekannt geworden wäre wenn Intel einfach die Infos für die Treiberentwicklung veröffentlicht hätte.
Du überschätzt Dich/die Linuxwelt ganz gehörig. Warum sollten sich Hersteller an 90% des Marktes zu bedienen?
Nein, mir geht es weder um mich noch um irgendeine "Linuxwelt" oder darum irgendjemand zu irgendetwas zu zwingen. Ich stelle nur fest, dass es ein alternativen Weg der Softwareentwicklung und Verteilung gibt -> Freie Software. Wenn man diesen Weg beschreitet, dann ist es auch nicht schwerer für die Systeme gute Software anzubieten. Genauso wie man sich auch auf die Windows, MacOS,... Art der Softwareentwicklung und Verteilung einstellen muß wenn man auf den Systemen optimal arbeiten will.
Man kann sich weigern sich auf diese Arbeitsweise einzulassen, dann kann man sich aber nicht beschweren das die anderen Wege so kompliziert sind.
Man muss kein Ökonom sein, um 100*1 und 1*1 rechnen zu können. Wenn Du das nicht kannst, ist Dir nicht zu helfen. Und dieses typische Misstrauen gegen Ökonomen hängt mir auch zum Halse raus. Würde man mal auf Ökonomen statt auf Ideologen und Gewerkschafter hören, wäre Deutschland jetzt nicht Schlusslicht in Europa.
> dann ist es auch nicht schwerer für die Systeme gute Software anzubieten.
Dann hast Du aber auch noch nie komplexere OpenSource-Software entwickelt. Was denkst Du, wie gut sich Fehler finden lassen, die ihre Ursache in den vielen Kombinationsmöglichkeiten aus mehreren Bibliotheken und deren vielfältigen Optionen haben. Von hardwarenaher Programmierung ganz zu schweigen. Wie kann man überhaupt auf die Idee kommen, es besser zu finden, wenn man hundert inkompatible Systeme hat als wenn es meinetwegen 100 kompatible gäbe. Das ist doch nichts weiter als Zweckideologie. Wären alle Distris kompatibel zueinander, dann würdest Du Dich jetzt über die inkompatiblen BSD-Spielarten beschweren.
jetzt verwechselst du aber etwas, du bist doch der der sich über etwas beschwert und nicht ich...
>Das ist das gleiche wie das ewige gejammere bei den Treibern.
>Man schreibt sie (oder gibt die Infos raus, damit dritte sie schreiben >können) und commited sie dann in den aktuellen Linux-Zweig und schon >kann jeder sein GNU/Linux System installieren und alles läuft
>out-of-the-box. Besser als jede exe Datei.
>Wenn man Software nach "windows-schema" für GNU/Linux anbieten will >ist klar dass es komplizierter ist.
Das hast Du schön auf den Punkt gebracht. Auf diese weise erhält man sogar eine bessere Platformunabhängigkeit als wenn man den Umweg über eine VM geht. Die dann eh nicht auf allen gewünschten Plattformen zur Verfügung steht.
Aber auf vernünftige Gegenargumente brauchst Du jetzt bei den "üblichen Verdächtigen" nicht mehr hoffen.
Denn bei Wörtern wie "Quellcodekompatibilität" hört bei denen der Verstand auf.
Ach bist Du klug. Du entwickelst bestimmt jeden Tag Software...
Stell Dir vor, unter Windows habe ich Binär- _und_ Quellcodekompatibilität. Und das mindestens von w98 bis wxp. Da habe ich die Freiheit, die eine oder andere Variante zu wählen. Unter Linux habe ich nur letzteres. Und weil die Linuxcommunity nicht in der Lage ist, auch ersteres sicherzustellen, wird die Quellcodekompatibilität plötzlich zum Dogma erhoben. Das ist an Stumpfsinn nicht mehr zu überbieten. So eine unfähige Konkurrenz, wie MS sie hat, hätten andere gern.
Ich hab das vielleicht nicht gut formuliert.
Selbstverständlich benutzt Sun selbst auch Java, auch als Produktbezeichnung (siehe JDS).
Ich meinte, daß es bei IBM viel mehr Kernstück ihres Solutionbusiness ist, bei Sun steht als Verkaufargument immer Solaris an erster Stelle.
Liegt vermutlich auch daran, daß diese beiden Firmen nicht wirklich im selben Markt sind, also eher anderen Zielsetzungen haben.
Was sind denn das für restriktive Distributionsauflagen?
Ich glaube es ist zum Beispiel untersagt, die Sun VM auf dem selben Distributionsmedium zu habe wie eine andere JVM.
Warum willst Du Java verteilen?
Weniger Aufwand für die Benutzer, keine Notwendigkeit für Downloads, Vorinstallierung, etc.
Auf CDs darfst Du Java verbreiten, wenn auf der CD auch selbstentwickelte Java-Software drauf ist
Ist mir bekannt, nur widerspricht das aus meiner Sicht der Write-Once-Run-Anywhere Idee wenn ich auf einer CD mit meinem ansich plattformunabhängigen Programm JVM Pakete für alle Zielplattformen raufpacken muß.
Ich sehen einen wesentlichen Vorteil von Java Programmen schon in der Tatsache, daß mehr oder weniger ein gut gebautes JAR ausreichend ist.
Ich müßte mich vielleicht mal im Detail mit den Lizenzbestimmungen beschäftigen, aber ich gehe davon aus daß es aus rechtlichen Gründen kein Sun JDK/JRE Paket im Debian Package Pool gibt (non-free; private apt Quelle wäre auch OK) und ich darum in die Steinzeit der Softwareinstallation mit manuellem Download und separater Installation zurückgeworfen werde.
Dieses private Problem der Distributoren sollten die Distributoren lösen
Absolut! Nur manchmal scheint das nicht gewünscht zu sein, IIRC gibt es ähnliche Probleme mit der Distributionslizenz von Acrobat Reader.
Und wenn Java wirklich frei währe, würde es auf JEDER Distribution standardmäßig mit dabei sein, und wäre ganz einfach mittels Paketmanager zu installieren. DAS würde JAVA ordentlich Rückenwind geben, und die Programmierer könnten sich darauf verlassen dass auf dem Zielsystem ein JAVA vorhanden ist, und sie somit nicht immer JAVA mitliefern müßten.
Abgesehen davon würde ein VOLLSTÄNDIGES und KOMPATIBLES JAVA auf jede Architektur portiert werden, was ja momentan auch nicht der Fall ist.
Sun handelt meiner Meinung nach zu kurzsichtig.