>> ... die Auffassung verbreitet, dass Suns neue, freiere Lizenzierung von Java zu spät kommt Oh man, was ist das den fuer eine Argumentation. "Wir sind jetzt beleidigt weil SUN nicht alles sofort freigibt was wir wollen". Wer so dumm ist, wenn Java dann im vollen (notwendigen) Umfang frei ist, ein so ausgereiftes Produkt nicht zu integrieren, der hat einige Vorteile von OSS nicht kapiert. Kein Wunder das der Gnome-Desktop KDE Jahrhunderte hinterherhinkt (Subjektiver Eindruck, soll nicht als Ausgangspunkt fuer eine Gnome/KDE-Diskusion dienen ).
Zum Glück gibt es das Plattform (Win, MacOSX, Unix) übergreifende QT, dass kein .NET braucht. Man muss es zwar überall nochmals kompilieren, aber dies genügt ja nun einmal.
Was ist GNOME denn eigentlich? Ein Desktop? Ein Framework? HIGs? Eine Platform? Eine Sammlung von Programmen?
Wenn man es als Framework ansieht, steht das GObject Framework in Konkurrenz zu Mono mit all seinem Kram. Warum zwei konkurrierende Frameworks unter einen Namen packen?
Wenn man die HIGs in den Vordergrund rückt, ist die Diskussion sinnlos. Dann könnte auch KDE/Windows/OS X irgendwann GNOME werden.
Gnome ist doch eh nicht relevant, bzw. war es noch nie. Die Gnomeentwickler sollte endlich einsehen, dass KDE technisch und auch aus Endanwendersicht der bessere Weg ist.
Macht das Projekt endlich dicht, anstatt krampfhaft weiterzuentwickeln nur um sich noch was zu beiweisen, das wird doch sowieso nichts mehr, KDE hat gewonnen.
> Während die Befürworter einer Mono-Integration die drohenden Gefahren eines Untergangs des GNOME-Projekts, bei ausbleibender Integration bzw. Innovation, an die Wand malen ...
Genausogut kann man auch so argumentieren:
Während die Gegner einer Mono-Integration die drohenden Gefahren einer zunehmenden Abhängigkeit des GNOME-Projekts von Microsofts Wohlwollen an die Wand malen ...
Meine Meinung:
Mono ist nur ein Framework wie GTK, QT etc., Gnome ist dagegen ein komplettes Desktopsystem. Gnome sollte sich von Frameworks möglichst unabhängig machen. D.h. wenn man schon Mono haben will, dann möglichst nur über Bridges bzw über eine Meta-API, damit man Mono im Fall des Falles einfach ersetzen kann. So wie es wxWidgets macht. Das ist eine Meta-API für GTK, Win32 und OSX. Die können z.B. relativ problemlos die Win32-API durch die .NET-API ersetzen. Oder wenn sie wollen, auch auf Mono aufsetzen.
Die Stärke von Open Source liegt doch gerade darin, dass es _unabhängig_ von proprietären Lösungen ist. Mono ist eine _proprietäre_ Lösung, auch wenn sie Open Source ist. Weil sie nämlich viel zu sehr von .NET abhängig ist. Ein von .NET abgekoppeltes Mono dürfte es gegen Java und .NET sehr schwer haben zu überleben. Zumal Java sowieso Open Source wird.
ich kanns nichtmehr hoeren: '...ms-technik...' '...propitaerer mist...' '...patente...' '...rechtliche unsicherheit...' CLI und C# sind inzwischen beides von ISO herausgegebene Standards. Das heisst nicht nur das die MS Abhaengigkeit bloedsinn ist,sondern auch das patentargument nicht zieht, da sich jeder der bei ISO Dokumente zur Standardisierung einrecht verpflichtet diese unter fairen und nicht-diskriminierenden Bedingungen zu lizensieren...
Ich finde die Diskussion nicht ganz uninteressant.
Generell sollte man aber mal fragen, welchen Vorteil Bindings bringen.
Klar, der Programmierer kann die Sprache verwenden, die er mag oder die besser geeignet scheint. C/C++ ist da ja eigentlich Standard. Uber Python kann man streitet.
Interessant finde ich aber Java, genauer vielleicht ein freies Java wie classpath. Das wuerde dann besser zur Lizenz von Gnome passen. Falls Sun Java technisch funktioniert, ok, dann das halt auch wenns denn sein soll.
Doch der wirklich vorteil liegt doch wo anders. Java hat hunderte interessante packages, die das programmieren angenehm machen. Wenn ich nun eine kleine Anwendung schreibe, dann faellt unten Bytecode raus, der Portabel ist. Mit dem Gnome-Binding integiert sich das dann gut in den Gnome-Desktop.
der Vorteil davon: - Eine Anwendung, geschrieben in Java - Protabel, d.h. die Anwendung ist distributierbar fuer i386/x86_64/PPC etc. Systeme sie wuerde sogar auf MacOS mit Fink laufen. - Gute integration in den Desktop
Und nun das Kontra zu C/C++/Mono etc. - Welcher Entwickler entwickelt den die Anwendung fuer fink/i386/PPC etc? Wer macht die Portierung. Mono ist in meinen Augen nicht wirklich Portabel, es ist nur gerade mal In.
Ein Desktop sollte in meinen Augen zwei Bindings haben, eine Plattformspezifische nativ und einer per VM/Bytecode. Mit C/C++ und Java ist das in meinen Augen machbar.
Oh man, was ist das den fuer eine Argumentation. "Wir sind jetzt beleidigt weil SUN nicht alles sofort freigibt
was wir wollen". Wer so dumm ist, wenn Java dann im vollen (notwendigen) Umfang frei ist, ein so
ausgereiftes Produkt nicht zu integrieren, der hat einige Vorteile von OSS nicht kapiert.
Kein Wunder das der Gnome-Desktop KDE Jahrhunderte hinterherhinkt (Subjektiver Eindruck, soll nicht als
Ausgangspunkt fuer eine Gnome/KDE-Diskusion dienen
KDE soll ja nun auch mehr auf QT bauen als zuvor.
Wieso noch GNOME ???
Wenn man es als Framework ansieht, steht das GObject Framework in Konkurrenz zu Mono mit all seinem Kram. Warum zwei konkurrierende Frameworks unter einen Namen packen?
Wenn man die HIGs in den Vordergrund rückt, ist die Diskussion sinnlos. Dann könnte auch KDE/Windows/OS X irgendwann GNOME werden.
Die Gnomeentwickler sollte endlich einsehen, dass KDE technisch und auch aus Endanwendersicht der bessere Weg ist.
Macht das Projekt endlich dicht, anstatt krampfhaft weiterzuentwickeln nur um sich noch was zu beiweisen, das wird doch sowieso nichts mehr, KDE hat gewonnen.
Genausogut kann man auch so argumentieren:
Während die Gegner einer Mono-Integration die drohenden Gefahren einer zunehmenden Abhängigkeit des GNOME-Projekts von Microsofts Wohlwollen an die Wand malen ...
Meine Meinung:
Mono ist nur ein Framework wie GTK, QT etc., Gnome ist dagegen ein komplettes Desktopsystem. Gnome sollte sich von Frameworks möglichst unabhängig machen. D.h. wenn man schon Mono haben will, dann möglichst nur über Bridges bzw über eine Meta-API, damit man Mono im Fall des Falles einfach ersetzen kann. So wie es wxWidgets macht. Das ist eine Meta-API für GTK, Win32 und OSX. Die können z.B. relativ problemlos die Win32-API durch die .NET-API ersetzen. Oder wenn sie wollen, auch auf Mono aufsetzen.
Die Stärke von Open Source liegt doch gerade darin, dass es _unabhängig_ von proprietären Lösungen ist. Mono ist eine _proprietäre_ Lösung, auch wenn sie Open Source ist. Weil sie nämlich viel zu sehr von .NET abhängig ist. Ein von .NET abgekoppeltes Mono dürfte es gegen Java und .NET sehr schwer haben zu überleben. Zumal Java sowieso Open Source wird.
CLI und C# sind inzwischen beides von ISO herausgegebene Standards. Das heisst nicht nur das die MS Abhaengigkeit bloedsinn ist,sondern auch das patentargument nicht zieht, da sich jeder der bei ISO Dokumente zur Standardisierung einrecht verpflichtet diese unter fairen und nicht-diskriminierenden Bedingungen zu lizensieren...
Generell sollte man aber mal fragen, welchen Vorteil Bindings bringen.
Klar, der Programmierer kann die Sprache verwenden, die er mag oder die besser
geeignet scheint. C/C++ ist da ja eigentlich Standard. Uber Python kann man
streitet.
Interessant finde ich aber Java, genauer vielleicht ein freies Java wie classpath.
Das wuerde dann besser zur Lizenz von Gnome passen. Falls Sun Java technisch funktioniert,
ok, dann das halt auch wenns denn sein soll.
Doch der wirklich vorteil liegt doch wo anders. Java hat hunderte interessante packages,
die das programmieren angenehm machen. Wenn ich nun eine kleine Anwendung schreibe,
dann faellt unten Bytecode raus, der Portabel ist. Mit dem Gnome-Binding integiert sich
das dann gut in den Gnome-Desktop.
der Vorteil davon:
- Eine Anwendung, geschrieben in Java
- Protabel, d.h. die Anwendung ist distributierbar fuer i386/x86_64/PPC etc. Systeme
sie wuerde sogar auf MacOS mit Fink laufen.
- Gute integration in den Desktop
Und nun das Kontra zu C/C++/Mono etc.
- Welcher Entwickler entwickelt den die Anwendung fuer fink/i386/PPC etc? Wer macht
die Portierung. Mono ist in meinen Augen nicht wirklich Portabel, es ist nur gerade
mal In.
Ein Desktop sollte in meinen Augen zwei Bindings haben, eine Plattformspezifische nativ
und einer per VM/Bytecode. Mit C/C++ und Java ist das in meinen Augen machbar.
So gesehen sehe ich in Mono nicht viel Sinn.