Archiv verlassen und diese Seite im Standarddesign anzeigen : Kümmer ihr euch um Free-Java Kompatibilität?
Hallo!
Ich habe gerade einen Artikel gelesen, indem es darum ging, dass die OSS-Gemeinde sich oft über SUN beschwert, sie sollte java endlich frei machen, aber selbst relativ wenig dazu beiträgt. (z.B. Apache welches relativ viel Zeit damit verbringt, bug-reports an sun zu senden).
Schön langsam kommen die freien JVMs in ein Standium, wo sie langsam brauchbar werden (die Klassen-Implementierungen, bei den Runtimes siehts leider noch etwas schlecht aus), wollte ich einmal fragen wies bei euren projekten aussieht?
peschmae
18-03-2005, 19:52
Ich hab abgestimmt obwohl sich die Zahl meiner Java-Projekte in letzter Zeit ziemlich exakt konstant null ist ;)
Aber das was ich vorher gemacht habe bzw. wenn ich was machen würde würde ich schon drauf schauen. :)
MfG Peschmä
Ich schaue manchmal, ob meine Projekte laufen. Wenn es klappt, dann ist gut. Wenn ich nach kurzem schauen nicht auf den Fehler komme, lasse ich es aber auch bleiben. Ich weiß, es ist inkonsequent, aber meine Projekte stehen meist unter der GPL. Da kann dann ja jemand weiterarbeiten. ;)
Erschüttert mich doch etwas.
40% ist es komplett egal. Anscheinend ist der Leidensdruck noch zu klein.
Das wird noch größer wenn Sun dann pleite ist oder aufgekauft wird...
aehm, was ist free java kompatibilität? wenn ich mich an den standard halte und meine app unter der jvm-referenz-implementierung läuft interessiert mich der rest eigentlich nicht viel.
normalerweise sollte es keine probleme (abgesehen von den beliebten threadsync-problemen) geben, wenn die jvm sich standardkonform verhalten. wenn nicht, sollte doch die jvm geändert werden und nicht die app. wozu gibts den sonst standards?
oder habe ich das alles vollkommen falsch verstanden?
-j
delmonico
20-03-2005, 00:19
Ich code kein Java. Wenn ichs machen würde, würde ich schon deshalb drauf achten, weil auf meinem freien Betriebssystem schlichtweg keine Sun-VM läuft ;)
" Ich habe gerade einen Artikel gelesen, indem es darum ging, dass die OSS-Gemeinde zwar immer SUN anmeckert, sie sollte java endlich frei machen, aber selbst relativ wenig dazu beiträgt."
Wieso auch? Java ist ein SUN-Produkt. Wenn sie es nicht freigeben wollen, schön für sie, dann will ich es nicht nutzen und werde auch keine Software in Java schreiben. Punkt. Ich find die Einstellung mancher Leute, es wäre Aufgabe der FreeSoftware-Entwickler, ständig irgendwelchen proprietären {Programmen,Protokollen,Sprachen} hinterherzulaufen, etwas merkwürdig.
Wenn sie es nicht freigeben wollen, schön für sie, dann will ich es nicht nutzen und werde auch keine Software in Java schreiben. Punkt. Ich find die Einstellung mancher Leute, es wäre Aufgabe der FreeSoftware-Entwickler, ständig irgendwelchen proprietären {Programmen,Protokollen,Sprachen} hinterherzulaufen, etwas merkwürdig.
Sehe ich ähnlich. Deswegen bevorzuge ich C#, wenn es um bytecode Sprachen geht, dass ist ein sauberer offener Standard.
Zur Frage. Ab und zu muß ich auch java programmieren (Uni), dann achte ich sehr darauf, dass meine Programme mit einer freien Java Implementierung arbeiten, schon alleine deswegen weil ich nichts anderes installiert habe. :)
bockionline
21-03-2005, 14:32
normalerweise sollte es keine probleme (abgesehen von den beliebten threadsync-problemen) geben, wenn die jvm sich standardkonform verhalten. wenn nicht, sollte doch die jvm geändert werden und nicht die app. wozu gibts den sonst standards?
Im Prinzip hast du Recht. Nur erzeugt man sich, glaube ich, mit der ganz starren Haltung ein "Henne-Ei-Problem". Wenn keine Programme (Übertreibung, natürlich) mit einem freien Java laufen, werden sich eher wenig Leute an der Entwicklung eines freien Java beteiligen, womit wiederum wenig daran gearbeitet wird, den Java-Standard zu 100% in einem freien Java umzusetzen.
Wenn man nun als Entwickler darauf achtet, daß ein selbstgeschriebenes Programm mit einem freien Java läuft, schafft man vielleicht Anreize, weitere Programme damit einzusetzen und deshalb ein wenig an dem freien Java mitzuarbeiten.
Sehe ich ähnlich. Deswegen bevorzuge ich C#, wenn es um bytecode Sprachen geht, dass ist ein sauberer offener Standard.
Ich nehme an du spielt dabei auf Mono an, wie man an deinem Bildchen unschwer erkennen kann
Ich halte Mono im großen Stil auch relativ gefährlich, da man derzeit APIs implementiert, welche teilweise von Microsoft nicht standardisiert wurden und somit auch nicht unter die fair-use Klausel fallen.
Natürlich kann man sagen, man schmeißt bei Problemen diese APIs einfach raus und ersetz sie durch freie, aber wenn die APIs da sind, werden die auch benutzt, zumal ein nicht kleiner Teil der Mono-Benutzer unter .NET angefangen haben zu programmieren.
Ich möchte mir nicht vorstellen, was es für Linux heißt wenn wichtige Software mit Mono läuft und MS klagt und gewinnt. Alle die dieses Mono einsetzen, verwenden es dann illegal - imho müssten ganze Server stillgelegt werden von den Desktops ganz zu schweigen!
Da ist Java meiner Meinung nach viel weiter. Ich kann Java wie folgt ausführen:
- Auf Mono mit ikvm.net
- mit GCJ kompilieren
- mit einer der freien JVMs ausführen
- mit den SUN/IBM/BEA dingern ausführen und das dann sauschnell (hat mono keine chance)
- als applet
- als webstart
Ich halte Mono im großen Stil auch relativ gefährlich, da man derzeit APIs implementiert, welche teilweise von Microsoft nicht standardisiert wurden und somit auch nicht unter die fair-use Klausel fallen.
In erster Linie geht es mir um C#, CLI und dann noch Gtk# und die ganzen anderen GNU/Linux und gnome APIs und da gibt es kein Problem.
Ja, MS hat nur einen Teil standardisiert, da du aber weiter unten wieder auf java kommst, was hat sun standardisiert? Mit C# und der CLI haben wir eine Basis auf einem offenen Standard, was haben wir bei Java?
Natürlich kann man sagen, man schmeißt bei Problemen diese APIs einfach raus und ersetz sie durch freie, aber wenn die APIs da sind, werden die auch benutzt, zumal ein nicht kleiner Teil der Mono-Benutzer unter .NET angefangen haben zu programmieren.
gleiches Problem bei java und allen anderen Frameworks auch. Wer sagt dir das MS Patente nicht auch Teile von Java abdecken, die Ideen dahinter sind ja nicht so verschieden? Was ist mit den sun Patenten und den ganzen anderen Softwarepatenten von anderen Unternehmen?
Es gibt ein ernstes Problem -> Softwarepatente, dass besteht aber überall.
Ich möchte mir nicht vorstellen, was es für Linux heißt wenn wichtige Software mit Mono läuft und MS klagt und gewinnt. Alle die dieses Mono einsetzen, verwenden es dann illegal - imho müssten ganze Server stillgelegt werden von den Desktops ganz zu schweigen!
Diese Klage kann gegen alles kommen. Mono, java, C++-APIs,...
Es geht hier um Patente und nicht um Urheberrecht, d.h. die Gefahr ist völlig losgelöst von einer speziellen Implementierung.
Ausserdem besteht ein großteil der GNU/Linux Programme aus C#, CLI, Gtk#, gst#,..
Und nicht aus ASP.Net oder ADO.Net, aber wie bereits gesagt, ist auch da das Risiko nicht wirklich höher.
Ich denke die Probleme hängen hier eher mit dem Feindbild MS in den Köpfen der Leute zusammen als dass es ein reelles Problem wäre. Zumindest ist es nicht größer wie bei anderen APIs und anderer Software.
Ich würde sogar einen Schritt weitergehen und MS in diesem Bereich als sehr Mono freundlich einschätzen. Warum?
Was hat MS, sie haben .Net und damit ihr Framework für windows. Sie wollen aber ganz klar einen Gegenpol zu java schaffen. Das funktioniert aber erst, wenn sie Plattformunabhängig sind und genau das verschafft ihnen Mono. Mit Mono wurde "ihr Framework" massentauglich (zumindest in manchen Bereichen).
Ich glaube sie wissen ihren Vorteil sehr wohl zu schätzen, dass es Mono gibt und das sie im Gegensatz zu java einen offenen Standard als Basis für alle geschaffen haben, und werden den sicher nicht aufgeben.
Bevor sie ihre Patente gegen Mono einsetzen werden sie diese sicher gegen Java einsetzen.
aber jedem das seine...
immerhin ein Punkt in dem wir uns einig sind. ;)
Wenn man nun als Entwickler darauf achtet, daß ein selbstgeschriebenes Programm mit einem freien Java läuft, schafft man vielleicht Anreize, weitere Programme damit einzusetzen und deshalb ein wenig an dem freien Java mitzuarbeiten.
nichts gegen einzuwenden. wenn mein standard-konformer code auf einer freien jvm läuft, bestens. wenn mein code wegen einer nicht spezifikationsgerechten implementierung seitens der jvm nicht läuft, ist mir das bugreports wert. was ich allerdings vehement ablehne: code nicht-standardkonform zu schreiben oder explizite ausnahmen für nicht-spezifikationstreue JVMs zu implementieren, nur damit die app auf auf einer freien JVM läuft. das ist IMHO der falsche weg und läuft dem sinn eines standards zuwider.
man braucht sich nur mal älteren c-code für unices anzusehen: ein verhau von #ifdefs damit der code von allen möglichen c-compiler-implmentierungen compiliert werden kann. das will ich in java nicht haben, man muss ja schliesslich aus fehlern lernen.
-j
nichts gegen einzuwenden. wenn mein standard-konformer code auf einer freien jvm läuft, bestens. wenn mein code wegen einer nicht spezifikationsgerechten implementierung seitens der jvm nicht läuft, ist mir das bugreports wert. was ich allerdings vehement ablehne: code nicht-standardkonform zu schreiben oder explizite ausnahmen für nicht-spezifikationstreue JVMs zu implementieren, nur damit die app auf auf einer freien JVM läuft.
Das ist ja eigentlich auch nicht das Problem. Das was implementiert ist funktioniert im Normalfall so wie es soll.
Es geht afaik eher darum:
- Das du von Anfang an mit einer freien-jvm entwickelst und dann z.B. merkst, dass lib X oder feature Y von lib X noch nicht implementiert ist und du es dann z.B. auf eine andere Art machst (es gibt ja oft mehrere Möglichkeiten etwas zu implementieren) und gleichzeitig das fehlen als wishlist-item meldest oder vielleicht sogar eine erste Implementierung lieferst (je nach deinem Wissensstand und deiner Zeit)
- Das du dein Programm von Anfang an mit einer freien jvm entwickelst oder zumindest testest und dir dadurch Fehler in bereits implementierten Funktionen auffallen, dass kann auch ein nicht ganz korrektes Verhalten im Vergleich zur sun Implementierung sein, und diesen Fehler dann meldest und/oder versuchst ihn zu beheben (je nach deinem Wissensstand und deiner Zeit)
anda_skoa
22-03-2005, 18:47
Ich hab mir bis vor kurzem eigentlich nicht so darum gekümmert, unter anderem auch, weil ich in letzter Zeit eher sehr wenig mit Java gemacht habe.
Hab dann anläßlich einer Diskussion über freie Java Implementierungen auf der debian-kde Mailingliste, in der einer der GNU Class Path Entwickler geschrieben hat, daß ohne Feedback schwer entscheidbar ist welche Sachen sie als nächstes angehen sollten, mir mal Kaffe+Classpath angesehen und ein paar meiner alten Projekte kompiliert
Mein damaliges Debian Woody hatte da nicht gerade die aktuellste Version drauf, aber mal abgesehen von Swing lies sich eines meiner größeren Projekte einwandfrei compilieren und in großen Teilen (dynamisches Classloading, etc) auch einwandfrei benutzen.
Werd jetzt mal sehen, wie lange ich auf meine neuen Unstable ohne JVM von Blackdown auskomme :)
Zur Sache mit C#: praktisch wie bei Java ist die Sprache ohne zugehörige Classlib/VM nicht sehr interessant.
Als Classlib+VM kommt hier ansich nur Mono in Frage, allerdings hat dieses Projekt ein sehr kurzsichtiges Marketing :(
Es wird zwar gleich am Anfang der Website darauf hingewiesen, daß Mono keinesfalls eine .Net Implementation ist, sondern Mono wie .Net eine Implementation des CLI Standards beinhaltet, aber jeder aus dem Umfeld des Projekts vermeidet es tunlichst, die Allgemeinheit oder Medien über ihren Irrtum aufzuklären, wenn sie wieder mal ".Net für Linux" schreiben.
Kurzfristig ist das nämlich eine feine Sache, man kann da mit bekannten Buzzwords punkten und man versucht ja auch in weiten Teilen .Net kompatibel zu sein, aber längerfristig nutzt das hauptsächlich dem Implementor der echten .Net Classlib, denn nur der ist immer kompatibel zu .Net (logischerweise da er .Net definiert)
Aber Amerikaner stehen nunmal leider auf "marketing over engineering" :D
Ciao,
_
Es wird zwar gleich am Anfang der Website darauf hingewiesen, daß Mono keinesfalls eine .Net Implementation ist, sondern Mono wie .Net eine Implementation des CLI Standards beinhaltet, aber jeder aus dem Umfeld des Projekts vermeidet es tunlichst, die Allgemeinheit oder Medien über ihren Irrtum aufzuklären, wenn sie wieder mal ".Net für Linux" schreiben.
Naja, das Marketing ist Novell sein Problem und mir als Anwender eigentlich relativ egal.
Die meisten in der windows Welt unterscheiden halt nicht groß und kennen nur .Net und denen sagt man dann halt das Mono eine Plattformunabhängige .Net implementierung ist. Darunter kann sich der windows-user was vorstellen und damit ist das Ziel erreicht. Wenn er sich dann mit Mono beschäftigt, dann wird er schon die Vor- und Nachteile kennen lernen.
Das ist ähnlich wie wenn man mit jemand das erstemal über GNU/Linux redet, dann wird GNU, Freie Software, Open Source und die ganze Philosophie auch meistens weg gelassen oder nur sehr verkürzt und bildlich dargestellt.
Für mich ist Mono mit der C# Implementierung, der CLI, GTk#, gst#,... ,ASP.NET, ADO.NET
Ein Framework für GNU/Linux mit dem ich sehr einfach und sehr schöne Programme für mein System schreiben kann, die ich für ein anderes GNU/Linux, BSD oder Unix System nicht extra neu kompilieren muß und die ich, wenn ich etwas aufpasse, sogar unter windows verwenden kann.
Mehr brauch ich nicht. Wenn in ASP.NET die letzten 3 Funktionen der MS Version noch nicht implementiert sind, dann ist mit das ziemlich egal, da ich sie eh nicht kenne ;)
Bei Java hat man das "Problem", dass es sun java für alle gängigen Plattformen gibt und die freien Implementierungen erst relativ spät gestartet sind.
Bei Mono sieht es anders aus. MS hat mit ihrer Implementierung keinen großen Vorsprung und man hat mit Novell eine Firma dahinter die die Entwicklung stark vorantreibt, zusätzlich hat man auf die Weiterentwicklung der CLI und C# Einfluß.
Wenn jetzt z.B. jemand Server Systeme mit windows und GNU/Linux hat, was wird er nehmen? Wenn es kein Mono geben würde, dann wäre die Entscheidung klar -> .Net. Durch Mono hat man aber auch die Option Mono/.Net. Dann kann man unter Mono entwickeln und die Programme dann unter Mono auf den GNU/Linux Systemen laufen lassen und unter windows .Net oder auch Mono verwenden.
MS hat dadurch auch nur Vorteile. Ihr .Net wird bekannt und erarbeitet sich einen Markt und Entwickler, die sicher auch .Net verwenden werden wenn sie nur für windows entwickelt.
Damit hat MS alles was sie imho wollen. "Ihre" Technologie als starken gegenpart zu Java und eine API für windows die auch dank Mono eine "besseren Ruf" bekommt und bekannt wird. Denn was liegt näher als .Net zu nehmen, wenn man vorher schon unter GNU/Linux oder anderen Unix Systemen mit Mono gearbeitet hat?
Und wir haben mit Mono eine schöne Technologie für Desktop und Server Anwendungen.
Ich schreibe schon wieder viel zu viel :D
Aber das ist zur Zeit einfach mein Thema ;)
Mal so ne Frage (hab mich bis jetzt noch nicht damit beschäftigt): Was muss ich mir eigentlich genau unter C# vorstellen? Wie ist die Sprache aufgebaut? Gibt es eine so schöne Doku wie für Java? Oder ist das ganze wieder einmal auf C aufgebaut und somit so schön "gebastelt" wie C++ (Nein - kein Java C++-Flame - aber C++ ist nun einmal weniger systematisch aufgebaut, man denke da nur an die mühsame OOP-Implementation...).
MfG Bischi
Mal so ne Frage (hab mich bis jetzt noch nicht damit beschäftigt): Was muss ich mir eigentlich genau unter C# vorstellen? Wie ist die Sprache aufgebaut? Gibt es eine so schöne Doku wie für Java? Oder ist das ganze wieder einmal auf C aufgebaut und somit so schön "gebastelt" wie C++ (Nein - kein Java C++-Flame - aber C++ ist nun einmal weniger systematisch aufgebaut, man denke da nur an die mühsame OOP-Implementation...).
C# ist eigentlich mehr Java als C oder C++.
Hier zwei Links die C# mit Java vergleichen:
http://www.25hoursaday.com/CsharpVsJava.html
http://genamics.com/developer/csharp_comparative.htm
oder ein Online-Buch zu C# wenn du dir etwas code ansehen willst:
http://www.galileocomputing.de/openbook/csharp/
Das meiste sollte einem java Programmierer ziemlich bekannt vorkommen.
Die Doku finde ich von monodoc eigentlich ganz gut (wobei es natürlich auch noch lücken gibt), da habe ich bisher immer alles gefunden was ich gesucht habe. MS wird sicher auch eine Doku haben, die habe ich mir aber noch nicht angesehen.
peschmae
23-03-2005, 07:18
Ich habe kürzlich (auf DFde war das glaubich) ein ganz simples C# Programm nach Java portiert.
Das beschränkte sich auf ersetzen von Ausgabemethoden durch system.out.println und abändern der Deklaration von Arrays. Der Rest war ziemlich genau gleich.
MfG Peschmä
anda_skoa
23-03-2005, 14:40
Naja, das Marketing ist Novell sein Problem und mir als Anwender eigentlich relativ egal.
Für dich als Entwickler, der den Unterschied kennt, wohl war.
Die meisten in der windows Welt unterscheiden halt nicht groß und kennen nur .Net und denen sagt man dann halt das Mono eine Plattformunabhängige .Net implementierung ist. Darunter kann sich der windows-user was vorstellen und damit ist das Ziel erreicht.
Genau das ist aber der Anfang vom Problem. Der weniger informierte, besonderes irgendwelche "Entscheider", sollten auf keinen Fall Mono als .Net Implementierun sehen.
Wenn er sich dann mit Mono beschäftigt, dann wird er schon die Vor- und Nachteile kennen lernen.
Wenn er sich damit beschäftigt wäre das kein Problem.
Die Teufelei ist die unwidersprochene Behauptung, Mono sei .Net nur crossplatform.
Dadurch erhalten Entwickler und Entscheider den falschen Eindruck, nämlich durch Entwicklung auf der .Net Plattform in Zukunft offen für andere Plattformen zu sein, was aber bekanntlich nicht der Fall ist.
Umgekehrt wäre das natürlich richtig, eine Software auf Mono Basis wird mit nahe 100% Wahrscheinlichkeit auch unter .Net laufen.
Durch die Unachtsamkeit im derzeitigen Monomarketing ensteht leider der Eindruck, daß das auch andersrum gilt. Dieser Eindruck hilft aber einzig und alleine nur Micosoft.
Die werden das tun, was sie bei Java schon versucht haben: ihre Plattform durch Classlibs zu erweitern, die nur sie zur Verfügung stellen können oder dürfen, aber durch die Inklusion in ihren SDK so aussehen lassen, als wären es Standardkomponenten.
Der weniger informierte Entwickler ist dann trotz seiner ursprüngliche Intention an eine Platform gebunden, bzw. hat einen großen bis enormen Aufwand seine Software davon wieder zu lösen.
Inwiefern es als Mono langfristig hilft wenn die einzige CLI Implementation die benutz wird die von .Net ist, ist mir ziemlich schleierhaft, aber vermutlich ist längerfristige Planung in den USA nicht so in.
Das ist ähnlich wie wenn man mit jemand das erstemal über GNU/Linux redet, dann wird GNU, Freie Software, Open Source und die ganze Philosophie auch meistens weg gelassen oder nur sehr verkürzt und bildlich dargestellt.
Das ist nicht vergleichbar, so sehr die Philosphie in diesne Fällen ansich wichtig wäre, macht sie für die Zielgruppe vielleicht keinen Unterschied.
Für die Zielgruppe Windowsentwickler in der Evaluierungsphase für eine neue Entwicklungsbasis hat der Unterschied zwischen "eine .Net Implementation" und "eine zu .Net ähnliche Implementation der EMCA CLI" sehr wohl eine Bedeutung.
Für mich ist Mono mit der C# Implementierung, der CLI, GTk#, gst#,... ,ASP.NET, ADO.NET
Wenn das korrekt ist, wäre das vermutlich eher angebracht als dieses derzeitige in die Falle locken.
Mehr brauch ich nicht. Wenn in ASP.NET die letzten 3 Funktionen der MS Version noch nicht implementiert sind, dann ist mit das ziemlich egal, da ich sie eh nicht kenne ;)
Wie gesagt bist du nicht gefährdet, weil du aus der anderen Richtung kommst.
Wenn jetzt z.B. jemand Server Systeme mit windows und GNU/Linux hat, was wird er nehmen?
Zu dem Zeitpunkt an dem diese Entscheidung zum Beispiel auf Grund eines Kundenwunsches ensteht, hat der .Net gebundene Hersteller diese Wahl nicht mehr.
Durch Mono hat man aber auch die Option Mono/.Net. Dann kann man unter Mono entwickeln und die Programme dann unter Mono auf den GNU/Linux Systemen laufen lassen und unter windows .Net oder auch Mono verwenden.
Vollkommen deiner Meinung.
Durch die Ungenauigkeiten im derzeitigen Mono Marketing existiert diese Alternative auf Dauer nur für Monobasierte Entwickler, nicht mehr für die blauäugig in die Falle getappten .Net basierten Entwickler unter Windows.
MS hat dadurch auch nur Vorteile.
Absolut!
Nur ist mir noch nicht klar, warum die Monoentwickler versuchem zum Schaden andere Plattformen Microsoft Vorteile zu verschaffen.
Ciao,
_
Absolut!
Nur ist mir noch nicht klar, warum die Monoentwickler versuchem zum Schaden andere Plattformen Microsoft Vorteile zu verschaffen.
Ich denke wir sind uns da im großen und ganzen ziemlich einig.
Den Schaden sehe ich aber nicht.
Meiner Meinung nach macht Novell zwei Sachen:
1. Sie bieten der Freien Softwareentwicklung ein neues und durchaus interessantes Werkzeug an, dass auch einem offenen Standard basiert. Das ist doch erstmal toll und damit sind wir zu 100% bedient.
2. Sie wollen auch Kunden auf dem MS Markt gewinnen, damit diese auch Mono anstelle von .Net nehmen und Novell damit Kunden bekommt. Das machen sie indem sie ihnen eine "Plattformunabhängige .Net Technologie" verkaufen. Das ziel von Novell ist aber nicht eine .Net/Mono Mischkultur sondern sie wollen natürlich nur Mono verkaufen und das erreichen sie mit dieser Strategie. Der Kunde hat schon was von .Net gehört und hört jetzt von einem plattformunabhängigen Mono und sagt toll, jetzt habe ich die Auswahl zwischen java, .Net und Mono, da er mehrere Plattformen bedienen will fällt .Net weg und mit etwas Glück (für Novell) wird er sich für Mono entscheiden.
Ein Schaden für Punkt 1 entsteht daraus in meinen Augen nicht.
anda_skoa
23-03-2005, 21:23
1. Sie bieten der Freien Softwareentwicklung ein neues und durchaus interessantes Werkzeug an, dass auch einem offenen Standard basiert. Das ist doch erstmal toll und damit sind wir zu 100% bedient.
Soweit ok
2. Sie wollen auch Kunden auf dem MS Markt gewinnen, damit diese auch Mono anstelle von .Net nehmen und Novell damit Kunden bekommt. Das machen sie indem sie ihnen eine "Plattformunabhängige .Net Technologie" verkaufen.
Indem sie ihnen vorgaukeln, Mono wäre .Net, nur halt nicht von Microsoft.
Das ziel von Novell ist aber nicht eine .Net/Mono Mischkultur sondern sie wollen natürlich nur Mono verkaufen und das erreichen sie mit dieser Strategie.
Sie erreichen damit das .Net eine gewisse Legitimation erhält, weil es ja eh mittels Mono von einem anderen Hersteller auf anderen Plattformen verfügbar ist.
Ist es aber nicht.
Der Kunde hat schon was von .Net gehört und hört jetzt von einem plattformunabhängigen Mono und sagt toll, jetzt habe ich die Auswahl zwischen java, .Net und Mono, da er mehrere Plattformen bedienen will fällt .Net weg und mit etwas Glück (für Novell) wird er sich für Mono entscheiden.
Da nichts gegen den Eindruck Mono == .Net unternommen wird, hat der Kunde aus seiner Sicht die Auswahl zwischen Java und .Net
Mono ist für ihn nur eine andere Implementierung von .Net, die er zum Beispiel derzeit nicht braucht, weil er eh unter Windows entwickelt.
Das seine ursprüngliche und von Mono geduldete Annahme, Mono == .Net, nicht der Wahrheit entspricht, sieht er erst, wenn es zu spät ist, wenn er .Net Technologien eingesetzt hat, die Mono nicht zur Verfügung stellen kann.
D.h. wenn seine Intention ansich war, seine Software oder einen Teil davon auf anderen Plattformen anbieten zu können, kann das jetzt vergessen.
Hätte er Java oder Mono genommen, hätte er diese Möglichkeit noch.
Nur wird ihm bewußt die Tatsache verschleiert, daß es eine Wahl zwischen drei Optionen ist.
Ein Schaden für Punkt 1 entsteht daraus in meinen Augen nicht.
Für Mono oder Monobasierte Entwickler entsteht auch kein Schaden, die können schließlich auch unter Windows entwickeln und vertreiben, der Schaden entsteht für die Plattformen != Windows, weil dort .Net nicht geht.
Es wäre für Mono vielleicht bishen weniger Marketing wenn sie diese Bauernfängerei nicht ausnutzen, aber sie wenigstens nicht stillschweigend den zukünftigen Windows Lock-In der .Net Entwickler hinnehmen.
Es wäre viel besser, wenn explizit klar gestellt werden würde, daß .Net Wissen auf Mono anwendbar ist und Mono die Entwickung für mehr als eine Plattform ermöglicht, während .Net das nicht tut.
Muss mich da anda_skoa leider anschließen.
Mono hat 70% seiner Popularität dem Umstand zu verdanken, dass sie als ".net für Linux" gehandelt werden - sonst wär in dien vielen Zeitschriften bei weitem nicht so viel drüber zu lesen gewesen.
Ich brauch mir nur angeblich seriöse Zeitschriften wie das Linux-Magazin ansehen und die Artikelzahl von Parrot mit der von Mono vergleichen.
Oder wenn man sich im Netz umschaut, tausende Berichte wie toll Mono nicht ist, weil da kann man mit VS.NET entwickeln und alles einfach rüberziehem und funtzt.
Ich bin wirklich der Meinung dass die GNU-Welt bessere Tools braucht (vor allem eine gut definierte, einheitliche API), aber ich bin doch etwas verunsichert dass es so abläuft wie eben jetzt.
Mono hat 70% seiner Popularität dem Umstand zu verdanken, dass sie als ".net für Linux" gehandelt werden - sonst wär in dien vielen Zeitschriften bei weitem nicht so viel drüber zu lesen gewesen.
sehe ich eigentlich nicht so. Für die popularität in der Free Software Community ist dieser Umstand wahrscheinlich sogar eher schädlich.
Und so populär ist Mono ausserhalb von der Free Software Community auch nicht.
O.T.: GTK+-2.0 sucks by design! Total über-synchronisiert ALLES, drum ists auch so langsam - Wahnsinn!
man darf nicht vergessen, dass Gtk+2 fast schon eine Neuentwicklung war, was da alles geändert wurde.
Seitdem gibt es von Release zu Release deutliche verbesserungen. In der nächsten Version werden einige Verbesserungen im Speicherverbrauch kommen und der komplette Desktop soll mit Cairo gerendert werden, d.h. ein Hardwarebeschleunigter Desktop!
Ich bin auf jedenfall schon darauf gespannt.
sehe ich eigentlich nicht so. Für die popularität in der Free Software Community ist dieser Umstand wahrscheinlich sogar eher schädlich.
Und so populär ist Mono ausserhalb von der Free Software Community auch nicht.
Sehe ich auch eher schädlich - ist wahrscheinlich falsch rübergekommen, sollte nur anda_skoa's statement noch untertreichen...
man darf nicht vergessen, dass Gtk+2 fast schon eine Neuentwicklung war, was da alles geändert wurde.
Seitdem gibt es von Release zu Release deutliche verbesserungen. In der nächsten Version werden einige Verbesserungen im Speicherverbrauch kommen und der
Naja, so lange Sie den Anspruch erheben, thread-safe zu sein sehe ich mehr oder weniger schwarz - das fox-toolkit (fox-toolkit.org) basiert rein auf X11 und outperformt GTK2 um den faktor 3-10.
komplette Desktop soll mit Cairo gerendert werden, d.h. ein Hardwarebeschleunigter Desktop!
Ich bin auf jedenfall schon darauf gespannt.
Naja, HW-beschleunigt ist X11 ja auch.
Naja, so lange Sie den Anspruch erheben, thread-safe zu sein sehe ich mehr oder weniger schwarz
wie kommst du darauf? Also mir ist es neu, dass Gtk+ thread-safe sein soll.
Naja, HW-beschleunigt ist X11 ja auch.
Was heißt X11 ist Hardwarebeschleunigt? Das hört sich so an, als ob alles was auf X11 läuft automatisch HW-beleunigung nutzt. Richtig ist das Grafikkartentreiber unter X11 zum Teil HW-beschleunigung ermöglichen. Es liegt dann aber an jedem Programm selber das zu nutzen oder nicht. Meistens sind das heute Spiele (z.B. tuxracer) die das nutzen. Ein Toolkit oder Desktop kenne ich nicht, dass wird jetzt mit Cairo aber möglich. Cairo soll mit der nächsten Gtk+ und Gnome Version implementiert sein und es erlauben den kompletten Desktop (alle Gtk+ aktivitäten)
mit HW-beschleunigung zu nutzen. Bei Qt plant man ja afaik auch nach der Qt4 release Cairo einzubauen.
Ich bin eher gespannt, was aus Cairo wird. Hat viel Potential, die API wird aber im Vergleich zu Java2D doch eher etwas "zusammengepfuscht".
Also ich weiß nicht was du mit der API hast.
Ich halte sowohl die Gtk+ als auch die Qt API für sehr gelungen und für mit das beste, was es derzeit auf dem Markt gibt. Klar ist Gtk+ etwas mehr "Gewöhnungsbedürftig", dass liegt aber eher an der Sprache als am Toolkit. Mit C++, C#, java oder Python ist die Gtk API auch schon viel freundlicher.
Wir sind mittlerweile aber wirklich sehr off-topic. ;)
Was heißt X11 ist Hardwarebeschleunigt? Das hört sich so an, als ob alles was auf X11 läuft automatisch HW-beleunigung nutzt
X11 ist Hardware-beschleunigt. Jede Linie die du zeichnest, (fast) jedes image das du blittest und was sonst noch alles, wird vom Grafikkarten-Treiber realisiert und nicht in Software-Schleifen (es sei denn du verwendest generische Treiber wie den vesafb-treiber).
Mit XRender sind sogar kompliziertere Sachen möglich, dabei werden die für den Treiber zu komplizierten Aufgaben, in mehrere einfache zerlegt.
Ein definitiv sehr grosser Nachteil von OpenGL unter Linux ist, dass es kein Render-To-Texture gibt, d.h. es muss das ganze backbuffering in pbuffer gemacht werden, wo wir enormen Speicherverbrauch und OpenGL-Context-Switches haben ;-)
Hoffentlich kommt bald RTT unter OGL...
Was du dir dabei sparst ist das Protokoll-Parsen und die Context-Switches.
Also eine Linie in X11 ist nicht weniger beschleunigt wie eine in OpenGL, drum nützt auch jedes Toolkit diese Beschleunigung aus ;-)
Also ich weiß nicht was du mit der API hast.
Hab die Cairo-API gemeint. Nichts desto trotz wünsch ich den Cairo-Jungs alles gute, ich hoffe das wird was gescheits ;-)
Noch was zur Mono-Publicity:
http://www.heise.de/newsticker/meldung/57935
oracle2025
29-03-2005, 13:52
Nochwas zum Thema Java, C#, etc.
Ich glaube schon, das es unbedingt nötig ist eine Programmiersprache zu haben, die die üblichen Schwächen von C/C++ ausräumt. (c-strings, array out of bounds, bufferoverflows, kein Garbage-Collection etc.)
Aber es muss nicht unbedingt Java bzw. C# sein. D ist nämlich auch ein vielversprechender Kandidat, den man immer dann verwenden kann wenn man eine kompilierte Sprache braucht:
http://www.digitalmars.com/d/ (Website anscheinend grad down)
http://c2.com/cgi/wiki?DeeLanguage
Es gibt neben dem DigitalMars D Compiler für Linux auch ein Frontend für die GNU Compiler Collection.
anda_skoa
29-03-2005, 15:24
die üblichen Schwächen von C/C++ ausräumt. (c-strings, array out of bounds, bufferoverflows, kein Garbage-Collection etc.)
Nunja, C und C++ sind ja nicht eine Sprache sondern zwei, haben also getrennte Schwächen.
So sind c-strings ein C Problem, array out of bounds praktisch auch bzw in C++ nur dann wenn man es sich explizit so aussucht.
Garbage Collection bzw das Nichtvorhanden sein ist keine Schwäche, sondern einfach eine Designentscheidung.
Garbage Collectors haben leider oft den Nachteil, daß sie schwer zu steuern sind
Ciao,
_
So sind c-strings ein C Problem, array out of bounds praktisch auch bzw in C++ nur dann wenn man es sich explizit so aussucht.
Gibts C++ Compiler die bounds-checks unterstützen?
Eine große Stärke bei Java finde ich ist, dass Exceptions relativ sicher abgefangen weden können. Bei C++ kann man oft nur mehr schnell irgendwelche Daten sichern und sich dann vertschüssn.
Garbage Collection bzw das Nichtvorhanden sein ist keine Schwäche, sondern einfach eine Designentscheidung.
Garbage Collectors haben leider oft den Nachteil, daß sie schwer zu steuern sind
Ich finde ein GC-Interface sollte definitv ins Bertriensystem übernommen werden!
Diese Mega(giga)-Byte großen Heap-Ungetüme bringen doch nur die ganzen Virtual-Memory Systeme zum kollabieren.
Würde das OS die Kontrolle über den GC und auch einen gemeinsamen Heap haben, wäre ein viel effizienteres Memory-Management möglich, da z.B. das OS feststellen könnte welche Speicherbereiche (Objecte) eher selten benützt werden, und diese könnten ausgelagert werden.
Derzeit ist der Heap einfach ein riesiger Bereich auf den nahezu wahlfrei zugegriffen wird, also nix mit effizientem Memory-Management :-(
Aber bis sich da ein Kompromiss zwischen den Kernel-Entwiclern finden lässt, vergeht wohl noch ein Weilchen ;-)
peschmae
29-03-2005, 19:28
Aber es muss nicht unbedingt Java bzw. C# sein. D ist nämlich auch ein vielversprechender Kandidat, den man immer dann verwenden kann wenn man eine kompilierte Sprache braucht:
Benutzt du D auch? Wenn ja für was? Wie stehts mit Qt/Gtk u.ä.? Oder ist das nur ein "vielversprechender Kandidat" (genau wie viele andere auch)?
Ich meine die Webseite tönt natürlich gut - aber das ist wohl bei allen anderen Sachen die für sich in Anspruch nehmen "besser" als C oder C++ zu sein auch so (mono, java, whatever).
MfG Peschmä
anda_skoa
29-03-2005, 23:00
Gibts C++ Compiler die bounds-checks unterstützen?
Alles eine Frage der verwendeten Datenstruktur.
Das Prinzip ist immer "kein Overhead wenn du ihn nicht willst, aber so viel du willst, wenn du willst" :)
Eine große Stärke bei Java finde ich ist, dass Exceptions relativ sicher abgefangen weden können. Bei C++ kann man oft nur mehr schnell irgendwelche Daten sichern und sich dann vertschüssn.
Du meinst hier Runtime Exceptions, richtig?
Ich finde ein GC-Interface sollte definitv ins Bertriensystem übernommen werden!
Solange er kontrolliertbar bleibt :)
Würde das OS die Kontrolle über den GC und auch einen gemeinsamen Heap haben, wäre ein viel effizienteres Memory-Management möglich, da z.B. das OS feststellen könnte welche Speicherbereiche (Objecte) eher selten benützt werden, und diese könnten ausgelagert werden.
Für das OS, bzw den Kernel ist alles ein Speicher, bzw. denkst du der Kernel wählt einfach per Zufall die Segmente zur Auslagerung aus?
Ich könnte mir aber vorstellen, dass es das Fragmentieren besser handhabbar macht, allerdings nur mit dem Overhead das dann bei jedem Speicherobjekt eine zusätzliche Kontrollstruktur angelegt werden muss, die angibt zu welchem Prozess das Objekt gehört und an welcher virtuellen Adresse das Objekt erwartet wird.
Ciao,
_
oracle2025
31-03-2005, 11:26
Benutzt du D auch? Wenn ja für was? Wie stehts mit Qt/Gtk u.ä.? Oder ist das nur ein "vielversprechender Kandidat" (genau wie viele andere auch)?
Ist nur ein vielversprechender Kandidat, ich benutze leider immer noch C++, weil das Toolkit meiner Wahl(fltk) ein C++ Toolkit ist.
Das offenbar ausgereifteste D Toolkit ist DUI (http://dui.sourceforge.net/), das auf GTK+ aufsetzt.
Jepp, D ist nur ein (minder) aussichtsreicher kandidat.
Für das OS, bzw den Kernel ist alles ein Speicher, bzw. denkst du der Kernel wählt einfach per Zufall die Segmente zur Auslagerung aus?
Ich könnte mir aber vorstellen, dass es das Fragmentieren besser handhabbar macht, allerdings nur mit dem Overhead das dann bei jedem Speicherobjekt eine zusätzliche Kontrollstruktur angelegt werden muss, die angibt zu welchem Prozess das Objekt gehört und an welcher virtuellen Adresse das Objekt erwartet w
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.