Die CDDL mag zwar nicht kompatibel zur GPL sein, sie ist aber eine von der FSF anerkannte OpenSource-Lizenz (http://www.opensource.org/licenses/cddl1.php).
Von papaschlumf am Fr, 27. Oktober 2006 um 12:25 #
Ich bin mit der CDDL auch zufrieden, wenn auch Apache oder BSD mir lieber wäre. GPL ist nicht Maß aller Dinge. Hoffentlich fangen jetzt die Distributionen an Suns Java mitzuliefern. Fuer unerfahrene Linux-Anwender ist einfach zu schwer Java von hand unter Linux zu installieren. Und nein ClassPath ist fuer ernsthaftes Arbeiten noch nicht ausgereift/kompatibel genug, die Jungs haben zwar echt gute Arbeit beim Neuerfinden des Rades geleistet - laeuft aber noch nicht ganz rund das Ding.
Dass die Java Plattform nun FOSS ist, hat die Vorteile:
1) die Bugs in den Tools der Plattform (wie Compiler, VM usw.) können nun von "jedem"(theoretisch, deshalb in Anführungszeichen) entfernt werden
und
2) die Java Plattform kann nun in allen Distros ohne Bedenken verteilt und natürlich eingesetzt werden.
Dies hier ist nicht eines der anvisierten Ziele: *) Jeder kann an Java (der Sprache) herumdoktern.
Geht zwar auch bald, doch SUN will eher die weitere Verbreitung und auch den vermehrten Einsatz und nicht die "Verfälschung" von Java.
Das beste ist nun: Man kann eine Art plattformunabhängiges Yast basteln(über verschiedene Unixe hinweg nutzbar), womit die Planung, das Deployment(was ist eigentlich das deutsche Wort dafür?) und das Monitoring von verschiedenen Unixen(auch den freien) mit einem Tool gelingt.
a) Nicht Plenken! b) Eine Textkonsole plus mein Lieblingseditor ist mir allemale lieber als YAST.
Jetzt 'mal ernsthaft: Mit welchem Werkzeug kannst Du sonst Dein Linux System grafisch so perfekt konfigurieren ?
a) Ich will das garnicht graphisch machen! b) Ich bezweifle das obige "perfekt". Jedes GUI ist gegenüber der textbasierten Konfiguration eine Einschränkung.
Administration ist die Kunst, einen Rechner/eine Applikation mit so wenig Aufwand wie nötig und soviel Effizienz und Effektivität wie möglich zu verwalten und dabei seine Kunden (= die Anwender) zufriedenzustellen.
Was man dafür verwendet bleibt natürlich jedem selbst überlassen. Ich schwöre auf eine Kombination aus Webmin, ssh und vi. Für die reine Installation nehm ich die Bordmittel der Distribution (ja, auch YaST) und ich bin mir auch nicht zu schade zu diesen Bordmitteln zu greifen wenns dort besonders einfach oder gut gelöst ist.
Für immer wiederkehrende Aufgaben hat ein gestandener Admin seine eigenen Skripte. Und bei denen nehm ich was mir sinnvoll erscheint. Kann Perl, awk oder sed oder eine Kombination aus allem sein. Wenn ich Zeit habe übertrage ich das eine oder andere in Perl.
Ich lege z. B. keine User per Hand an. Und auch kein Share für Samba, und auch keine Drucker, bin ich denn deppert?
Kleiner Tip: Zeige mal einem Admin, der seine Windows2003 Server über alles liebt die Vorteile von Linux, wenn er, statt seine Serveradminkonsole zu benutzen, nun auf einmal einen Texteditor nehmen MUSS. der lächelt dich an, und denkt, du willst ihn vergackeiern. Yast IST das beste grafische Frontend, weil es von jedem benutzt werden kann. Aber du MUSST es nicht. Administriere einfach mal ein Ubuntu 6.06, Red Hat Enterprise 5 unde SuSe Linux Enterprise 10. Dann sage mir, welche Distribution die besten grafischen Tools zur Unterstützung hat.
Yast ist ja anscheinend auch nichts für Leute wie Dich. Es ist ideal für Linux-Nutzer, die Linux benutzen wollen, aber leider keinen Plan davon haben, was denn z.B. "cfdisk" ist, aber trotzdem manchmal gerne ihre zweite Festplatte neu formatieren würden. Und, ei der Daus, da wird man doch in Yast fündig und ... es funktioniert! In diesem Sinne ist/war Yast ein gewaltiger Fortschritt.
Von Anonymer Feigling am Fr, 27. Oktober 2006 um 15:58 #
So ein platformunabhängiges YAST wie es dir vorschwebt, kann man auch jetzt schon, sofort, realisieren. Man nimmt einfach eine platformunabhängige Skriptsprache wie Ruby, Python oder auch perl und fängt an sowas zu machen. Für alle diese Sprachen gibt es auch platformunabhängige GUI-Toolkits.
Das ist nicht das Problem. Das Problem liegt im Backend. Auch GNU-CC ist ja überall kompilierbar. Es gab mal einen Port von YAST nach Debian, etwas, das weiter verfolgt werden sollte. Genauso wie LSB und die Integration von Konfigurationswerkzeugen in die Desktop-Environments.
Ursprünglich war geplant, daß die ersten Teile von Java noch diesen Monat OpenSource werden. Desweiteren war eigentlich geplant, daß auch diesen Monat JDK 6 rauskommt. Welch ein Zufall.
Desweiteren war geplant, daß das gesamte JDK erst Ende 2007 OpenSource wird.
Am Zeitplan hat sich aber einiges geändert.
Nun heißt es, daß die ersten Teile vom JDK im Dezember dieses Jahres OpenSource werden. Genauso hat sich aber auch das Erscheinen von JDK 6 auf Ende dieses Jahres verschoben. Welch ein Zufall.
Die Veröffentlichung des gesamten Javas unter OpenSource, hat sich hingegen stark nach vorne verschoben. Das wird nun im ersten Quartal 2007 sein. Möglichwerweise wird es dann aber doch eher auf das zweite Quartal verschoben. Im zweiten Quartal 2007 (vom 8. bis 11. Mai) findet die JavaONE 2007 statt. Welch ein Zufall.
Classpath ist die einzige vernünftige Lösung und Sun wird die freie Alternative nicht aufhalten können. Die API ist ja fast komplett geworden innerhalb kürzester Zeit.
Was jetzt fehlt sind eigentlich nur Leute, die Applikationen gegen die aktuelle Classpath-Version testen, z.B. http://developer.classpath.org/mediation/FreeSwingTestApps
Wenn man die Entwicklung kennt, dann wird in 2 Jahren von SUN mal was geöffnet, bis dahin ist aber Classpath längst debugged und performant genug.
Von M wie Meikel am Fr, 27. Oktober 2006 um 18:15 #
Classpath ist die einzige vernünftige Lösung und Sun wird die freie Alternative nicht aufhalten können. Die API ist ja fast komplett geworden innerhalb kürzester Zeit.
Hoho, Hurd ist ja auch in kürzester Zeit fast fertig geworden. Ist wohl eher so, dass Classpath schon seit Jahren vor sich hin dümpelt. Ab und zu gibt es mal hier und da einen Schritt nach vorne, aber den tun andere Implementierungen ja auch.
Wenn man die Entwicklung kennt, dann wird in 2 Jahren von SUN mal was geöffnet, bis dahin ist aber Classpath längst debugged und performant genug.
Ähnlich blöde Sprüche habe ich auch gehört, als Sun angekündigt hat, StarOffice frei zu geben. Aber irgendwie hat KOffice OpenOffice doch nicht so wirklich abhängen können.
Ähnlich blöde Sprüche habe ich auch gehört, als Sun angekündigt hat, StarOffice frei zu geben. Aber irgendwie hat KOffice OpenOffice doch nicht so wirklich abhängen können.;-)
Ich gebe Dir Recht, daß GNU Classpath nicht wird mithalten können, wenn Suns Java OpenSource wird.
Ich gebe Dir auch Recht, daß OpenOffice beliebter und stärker verbreitet ist als KOffice. Doch das kann sich ändern. Vor allem, da Qt4 nun als OpenSource für Linux/Unix, MacOSX und Windows existiert. Auch KOffice2 wird für all diese Plattformen erscheinen.
Ich denke, daß die Windows-Unterstützung sehr entscheidend für die Beliebtheit eines Programms. Gimp, OpenOffice, Firefox, Java,... die beliebtesten Linux-Programme laufen auf Windows, Linux und Mac.
Und wenn eine Datei von KOffice sich nicht mit OpenOffice öffnen läßt, kann man Leuten, wenn KOffice für Windows existiert, immer noch sagen, sie sollen es dort installieren, es sei ja kostenlos. Auch die Verbreitung über Zeitschriften-CDs und -DVDs ist entscheident. Auch hier können die Zeitschriften bisher den Windows-Nutzern nur OpenOffice und kein KOffice anbieten.
Aber das wird sich bals ändern. Und dann gibt es auch für OpenOffice aus dem OpenSource-Lager mehr Konkurrenz.
wie kommst du darauf? GNU Classpath hat natürlich das Ziel eines vollständigen Java und wird natürlich mit Sun mitziehen. JDK1.5 Kompatibilität ist bereits zu 92.95% erreicht: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath.html
Aber auch nur weil Redhat vor kurzem dort mal kräftig beigetragen hat, sonst würden dort keine Fortschritte zu sehen sein. CP braucht keine Sau, absolut verschwendete Entwicklerresourcen sind das, sonst nichts.
Ganz und gar nicht, mit Classpath bekommst du nämlich Java auf viele neue Plattformen und vor allem kannst du via GCJ nativ kompilieren. Das hat einiges für sich.
Wenn ich die Wahl zwischen Classpath und SUN Java Open habe, dann entscheide ich mich lieber für Classpath. Es ist übrigens nicht allein das Engagement von RedHat, was ja dafür spricht, dass man dem Projekt Zukunft zubilligt.
Guckst du hier http://www.object-refinery.com/classpath/mauve/statcvs/
Von high and dry am So, 29. Oktober 2006 um 04:35 #
Naja, Java-Programme mit GCJ nativ zu kompilieren bringt mehr nachteile als Vorteile. Native Eclipse-Version läuft kein bisschen schneller - dafür aber laufen einige Plugins nicht. Aus meiner Erfahrung muss ich leider sagen, dass ClassPath zur Zeit noch unbrauchbar ist. Die Classpath Entwickler leisten wirklich gute Arbeit aber Classpath und Suns Java trennen noch Welten. Selbst die JBoss-Software läuft noch nicht.
mit Classpath bekommst du nämlich Java auf viele neue Plattformen Suns Java ist für die wichtigsten Platformen verfügbar. Exotenkram interessiert mich und 99% der anderen Sunjavanutzer nicht die (Kaffee)bohne.
Wenn ich die Wahl zwischen Classpath und SUN Java Open habe, dann entscheide ich mich lieber für Classpath. Wenn ich die Wahl habe zwischen inkompatiblen, unfertigen Nachbau und dem Original dann wähle ich das Original.
Es ist übrigens nicht allein das Engagement von RedHat, ... Das ist mir ehrlich gesagt wurscht da ich CP eh nicht nutze. Mir kam nur in dem Zusammenhang eine Meldung in den Sinn wo sich RedHat in dem Projekt stark einbracht, iirc war es eine Meldung zu AWT das RedHat beisteuerte, was lange fehlte.
Mal sehen wie sich CP entwickelt. Wenn RedHat mitmischt hat CP eher eine Chance dass mal was daraus wird. Wenn CP 100% dem Standard entspricht ist ja nichts dagegen einzuwenden. CP macht nur Sinn wenn man unbedingt ein GPL-Lizenziertes Java haben will.
>>mit Classpath bekommst du nämlich Java auf viele neue Plattformen >Suns Java ist für die wichtigsten Platformen verfügbar. Exotenkram interessiert mich und 99% der anderen Sunjavanutzer nicht die (Kaffee)bohne.
Was willst Du damit sagen? Wenn Dich Exotenkram nicht interessiert, warum bist Du dann auf einer Linux-Seite?
Ironie beiseite: Selbst wenn die Zahlen stimmen, dann gibt es immer noch 1% für die das interessant ist. Also hat classpath durchaus seine Berechtigung.
Bekanntlich fing GNU/Linux auch mal als Exot an. Ja sogar MS/DOS und Windows war mal das Schicksal, Exot zu sein, beschieden. Sowas kann sich durchaus ändern. Übrigens gibt es immer noch genug Firmen, die mit Deiner Argumentation zu dem Schluß kommen, dass Treiber/Software/... für GNU/Linux (oder die BSDs) nicht notwendig seien - blöd, wenn man auf einmal auf der falschen Seite der beliebig gezogenen Grenze ist...
Von Verschwörungsdetektorinstitut am Fr, 27. Oktober 2006 um 17:43 #
If you are going to contribute source code to GNU Classpath we must make sure that you have not studied the source code of the JDK/JRE or decompiled any of its classes. Furthermore you must not have signed any non-disclosure agreements with Sun in regard with Java technology. The reason for this requirement is that we want to make sure that Sun or any other firm cannot rightfully claim that GNU Classpath infringes their copyright. You are therefore questioned about your experience with Sun's source code and agreements with the firm when you request the FSF copyright assignment.
Please note that being tainted does not mean you cannot help GNU Classpath at all. Here is a list of things you can do instead: * write Mauve test cases * write example applications demonstrating the usage of the API * writing/fixing helper programs (like japitools) and scripts * report bugs * help fixing the documentation * help in other Java-related Free software projects (e.g. virtual machine development, [WWW] GUMP)
Ich finds gut, dass Sun endlich Java freigibt.
s/FSF/OSI/
s/FSF/OSI/g
so geht das!
Dass die Java Plattform nun FOSS ist, hat die Vorteile:
1) die Bugs in den Tools der Plattform (wie Compiler, VM usw.) können nun von
"jedem"(theoretisch, deshalb in Anführungszeichen) entfernt werden
und
2) die Java Plattform kann nun in allen Distros ohne Bedenken
verteilt und natürlich eingesetzt werden.
Dies hier ist nicht eines der anvisierten Ziele:
*) Jeder kann an Java (der Sprache) herumdoktern.
Geht zwar auch bald, doch SUN will eher die weitere Verbreitung
und auch den vermehrten Einsatz und nicht die "Verfälschung"
von Java.
Das beste ist nun: Man kann eine Art plattformunabhängiges
Yast basteln(über verschiedene Unixe hinweg nutzbar), womit die
Planung, das Deployment(was ist eigentlich das deutsche Wort dafür?)
und das Monitoring von verschiedenen Unixen(auch den freien) mit
einem Tool gelingt.
Wenn schon ein plattformunabhängiges Tool bauen, dann bitte nicht auf YAST Basis, gibt besseres
Was gibt es denn besseres als YaST zum Beispiel ?
Jetzt 'mal ernsthaft: Mit welchem Werkzeug kannst Du sonst Dein Linux System grafisch so perfekt konfigurieren ?
Jetzt komme mir bitte nicht mit dem Spruch aus den 90ern: YaST überschreibt alle meine Konfigurationsdateien...
Dieser Spruch ist spätestens seit SUSE 9.3 Vegangenheit... ;)
Übrigens steht YaST unter der GPL...
a) Nicht Plenken!
b) Eine Textkonsole plus mein Lieblingseditor ist mir allemale lieber als YAST.
Jetzt 'mal ernsthaft: Mit welchem Werkzeug kannst Du sonst Dein Linux System grafisch so perfekt konfigurieren ?
a) Ich will das garnicht graphisch machen!
b) Ich bezweifle das obige "perfekt". Jedes GUI ist gegenüber der textbasierten Konfiguration eine Einschränkung.
Ja, ja, wieder so ein "Hardcore-user" der Briefe mit vim schreibt; ne mit vi, vim hat ja schon Weicheierkomfort.
> Ich will das garnicht graphisch machen!
Nun fang mal nicht an zu heulen! Keiner will Dir Dein "Expertentum" wegnehmen. Bastel Du mal schön mit Deiner Konsole rum, und laß andere ihrs machen.
Hörst Du das heimliche Rufen Deiner Konsole, < >?
Was man dafür verwendet bleibt natürlich jedem selbst überlassen. Ich schwöre auf eine Kombination aus Webmin, ssh und vi. Für die reine Installation nehm ich die Bordmittel der Distribution (ja, auch YaST) und ich bin mir auch nicht zu schade zu diesen Bordmitteln zu greifen wenns dort besonders einfach oder gut gelöst ist.
Für immer wiederkehrende Aufgaben hat ein gestandener Admin seine eigenen Skripte. Und bei denen nehm ich was mir sinnvoll erscheint. Kann Perl, awk oder sed oder eine Kombination aus allem sein. Wenn ich Zeit habe übertrage ich das eine oder andere in Perl.
Ich lege z. B. keine User per Hand an. Und auch kein Share für Samba, und auch keine Drucker, bin ich denn deppert?
Zeige mal einem Admin, der seine Windows2003 Server über alles liebt die Vorteile von Linux, wenn er, statt seine Serveradminkonsole zu benutzen, nun auf einmal einen Texteditor nehmen MUSS. der lächelt dich an, und denkt, du willst ihn vergackeiern.
Yast IST das beste grafische Frontend, weil es von jedem benutzt werden kann. Aber du MUSST es nicht.
Administriere einfach mal ein Ubuntu 6.06, Red Hat Enterprise 5 unde SuSe Linux Enterprise 10. Dann sage mir, welche Distribution die besten grafischen Tools zur Unterstützung hat.
Es ist ideal für Linux-Nutzer, die Linux benutzen wollen, aber leider keinen Plan davon haben, was denn z.B. "cfdisk" ist, aber trotzdem manchmal gerne ihre zweite Festplatte neu formatieren würden. Und, ei der Daus, da wird man doch in Yast fündig und ... es funktioniert!
In diesem Sinne ist/war Yast ein gewaltiger Fortschritt.
Desweiteren war eigentlich geplant, daß auch diesen Monat JDK 6 rauskommt.
Welch ein Zufall.
Desweiteren war geplant, daß das gesamte JDK erst Ende 2007 OpenSource wird.
Am Zeitplan hat sich aber einiges geändert.
Nun heißt es, daß die ersten Teile vom JDK im Dezember dieses Jahres OpenSource werden.
Genauso hat sich aber auch das Erscheinen von JDK 6 auf Ende dieses Jahres verschoben.
Welch ein Zufall.
Die Veröffentlichung des gesamten Javas unter OpenSource, hat sich hingegen stark nach vorne verschoben. Das wird nun im ersten Quartal 2007 sein.
Möglichwerweise wird es dann aber doch eher auf das zweite Quartal verschoben.
Im zweiten Quartal 2007 (vom 8. bis 11. Mai) findet die JavaONE 2007 statt.
Welch ein Zufall.
Ombra
Woher hat ProLinux denn diese Informationen?
Die stehen aber nicht im Artikel.
Ich denke mal, hier hat PL auf eigene Faus spekuliert.
Simon Phipps macht keinen Hehl daraus, daß er sowohl dioe CDDL als auch die GPLv3 gut findet.
Jedoch haben bei einer Abstimmung, unter 7% der Voter für die CDDL als Lizenz für Java gestimmt.
Hinzu kommt, daß er auch gute Kontakte zu den GNU Classpath Leuten pflegt und dadrauf hinwies, daß er nmit Dalibor Topic - was die GPLv3 angeht - zum großen Teil einer Meinung ist
Was jetzt fehlt sind eigentlich nur Leute, die Applikationen gegen die aktuelle Classpath-Version testen, z.B.
http://developer.classpath.org/mediation/FreeSwingTestApps
Wenn man die Entwicklung kennt, dann wird in 2 Jahren von SUN mal was geöffnet, bis dahin ist aber Classpath längst debugged und performant genug.
Hoho, Hurd ist ja auch in kürzester Zeit fast fertig geworden. Ist wohl eher so, dass Classpath schon seit Jahren vor sich hin dümpelt. Ab und zu gibt es mal hier und da einen Schritt nach vorne, aber den tun andere Implementierungen ja auch.
Wenn man die Entwicklung kennt, dann wird in 2 Jahren von SUN mal was geöffnet, bis dahin ist aber Classpath längst debugged und performant genug.
Ähnlich blöde Sprüche habe ich auch gehört, als Sun angekündigt hat, StarOffice frei zu geben. Aber irgendwie hat KOffice OpenOffice doch nicht so wirklich abhängen können.
Ich gebe Dir Recht, daß GNU Classpath nicht wird mithalten können, wenn Suns Java OpenSource wird.
Ich gebe Dir auch Recht, daß OpenOffice beliebter und stärker verbreitet ist als KOffice.
Doch das kann sich ändern. Vor allem, da Qt4 nun als OpenSource für Linux/Unix, MacOSX und Windows existiert.
Auch KOffice2 wird für all diese Plattformen erscheinen.
Ich denke, daß die Windows-Unterstützung sehr entscheidend für die Beliebtheit eines Programms.
Gimp, OpenOffice, Firefox, Java,... die beliebtesten Linux-Programme laufen auf Windows, Linux und Mac.
Und wenn eine Datei von KOffice sich nicht mit OpenOffice öffnen läßt, kann man Leuten, wenn KOffice für Windows existiert, immer noch sagen, sie sollen es dort installieren, es sei ja kostenlos.
Auch die Verbreitung über Zeitschriften-CDs und -DVDs ist entscheident. Auch hier können die Zeitschriften bisher den Windows-Nutzern nur OpenOffice und kein KOffice anbieten.
Aber das wird sich bals ändern. Und dann gibt es auch für OpenOffice aus dem OpenSource-Lager mehr Konkurrenz.
JDK1.5 Kompatibilität ist bereits zu 92.95% erreicht: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath.html
CP braucht keine Sau, absolut verschwendete Entwicklerresourcen sind das, sonst nichts.
Wenn ich die Wahl zwischen Classpath und SUN Java Open habe, dann entscheide ich mich lieber für Classpath. Es ist übrigens nicht allein das Engagement von RedHat, was ja dafür spricht, dass man dem Projekt Zukunft zubilligt.
Guckst du hier
http://www.object-refinery.com/classpath/mauve/statcvs/
Suns Java ist für die wichtigsten Platformen verfügbar. Exotenkram interessiert mich und 99% der anderen Sunjavanutzer nicht die (Kaffee)bohne.
Wenn ich die Wahl zwischen Classpath und SUN Java Open habe, dann entscheide ich mich lieber für Classpath.
Wenn ich die Wahl habe zwischen inkompatiblen, unfertigen Nachbau und dem Original dann wähle ich das Original.
Es ist übrigens nicht allein das Engagement von RedHat, ...
Das ist mir ehrlich gesagt wurscht da ich CP eh nicht nutze. Mir kam nur in dem Zusammenhang eine Meldung in den Sinn wo sich RedHat in dem Projekt stark einbracht, iirc war es eine Meldung zu AWT das RedHat beisteuerte, was lange fehlte.
Mal sehen wie sich CP entwickelt. Wenn RedHat mitmischt hat CP eher eine Chance dass mal was daraus wird. Wenn CP 100% dem Standard entspricht ist ja nichts dagegen einzuwenden. CP macht nur Sinn wenn man unbedingt ein GPL-Lizenziertes Java haben will.
>Suns Java ist für die wichtigsten Platformen verfügbar. Exotenkram interessiert mich und 99% der anderen Sunjavanutzer nicht die (Kaffee)bohne.
Was willst Du damit sagen? Wenn Dich Exotenkram nicht interessiert, warum bist Du dann auf einer Linux-Seite?
Ironie beiseite: Selbst wenn die Zahlen stimmen, dann gibt es immer noch 1% für die das interessant ist. Also hat classpath durchaus seine Berechtigung.
Bekanntlich fing GNU/Linux auch mal als Exot an. Ja sogar MS/DOS und Windows war mal das Schicksal, Exot zu sein, beschieden. Sowas kann sich durchaus ändern. Übrigens gibt es immer noch genug Firmen, die mit Deiner Argumentation zu dem Schluß kommen, dass Treiber/Software/... für GNU/Linux (oder die BSDs) nicht notwendig seien - blöd, wenn man auf einmal auf der falschen Seite der beliebig gezogenen Grenze ist...
Please note that being tainted does not mean you cannot help GNU Classpath at all. Here is a list of things you can do instead:
* write Mauve test cases
* write example applications demonstrating the usage of the API
* writing/fixing helper programs (like japitools) and scripts
* report bugs
* help fixing the documentation
* help in other Java-related Free software projects (e.g. virtual machine development, [WWW] GUMP)