Auf der einen Seite ist es ja ganz schön das Mono bald "fertig" ist... Aber ich befürchte wenn Ximian anfängt mono zu verwenden um Teile des GNOME Desktop zu entwickeln, dann springt SUN vom GNOME Zug ab.. da .NET der erklärte Gegener von Java ist ihrere Hauptsächlichen Einkunftsquelle...
Und IBM wird es wohl auch nicht soooo gerne sehen, schliesslich verdient auch IBM mit Java Lösungen sein Geld..
Ich mache mir auch etwas Sorgen um SUN hoffe aber, dass sie Java irgendwie "neben" Mono platzieren koennen. Java ist ja eh nicht geeignet um native GNOME/Gtk Anwendungen zu schreiben. Die Frage ist natuerlich, wozu _ist_ Java jetzt noch besser geeignet. Auf der anderen Seite ist Mono eigentlich auch gar nicht so fett also vielleicht kuemmert es SUN gar nicht wenn sie Mono und Java nebenher verwenden muessen. Beides hat ja sicher seine Vorzuege und wenn dann Teile des GNOME Desktops auf Mono laufen und dazu noch Java Anwendungen... Warum nicht. Zwingt SUN vielleicht etwas an der Performance zu schrauben. ;)
Davon abgesehen glaube ich aber auch nicht, dass in absehbarer Zeit zentrale Bestandteile des Desktops in Mono geschrieben werden.
Gut, aber SWT ist ja immer noch ein Unterschied zu direkter Unterstuetzung der Gtk und GNOME Libraries. Und in der Hinsicht gibt es momentan keine Plaene, oder doch?
Wenn GNOME auf Mono ausetzt, werde ich auf KDE umsteigen.
Das ist doch nicht schwer vorherzusagen, dass Microsoft irgendwann vom GNOME-Projekt Patentgebuehren verlangen wird, wahrscheinlich erst in ein paar Jahren, wenn man nicht mehr so leicht zurueck kann.
Ich faende es viel besser, wenn zukuenftige GNOME-Versionen auf Java aufsetzen wuerden. SUN ist naemlich nicht daran interessiert (anders als Microsoft) GNOME kaputt zu machen.
Nach zwei Jahren Säbelrasseln hat M$ immer noch kein kommerziell verwendbares ".net"-Produkt am Start. Selbst die neuen Windows-Server-Produkte heissen nicht mehr so, weil man den Begriff "aus Marketinggründen" jetzt plötztlich "für etwas Anderes" braucht.
Irgendwelche Vaporware als revolutionär neue Generation von Appliktationen zu präsentieren hat M$ ja schon häufiger (um nicht zu sagen regelmäßig) exerziert. Nur um [potentielle] Kunden vom Kauf bereits existierender gleichwertiger oder besserer Software abzuhalten, bis den Konkurrenten die [finanzielle] Puste ausging. Wo das nicht 100%ig funktionierte, hat man halt die Fremdfirmen aufgekauft. Jahre später hatte M$ dann jeweils auch halb- bzw. dreiviertel-wegs laufende Versionen der 'eigenen Innovationen' zur Verfügung.
Linux kann man nicht kaufen. Aber man kann versuchen, der Bewegung den Boden unter den Füßen zu entziehen: 1. 'Software-Patente' ("computerimplementierbare Erfindungen"): ein von einer Europaparlamentarierin Groß-Britanniens eingereichter "Gesetzesentwurf", der komischerweise fast identisch mit einem Dokument des US-amerikanischen Softwareproduzenten-Verbandes ist. (Details siehe z.Bsp. http://www.ffii.org/ ) 2. Statt [wie bisher] mit einem Riesenaufwand die eigene Vaporware selbst in etwas konkret Produktives umzuwandeln kann man jetzt hingehen und dutzende führender OSS-Entwickler in der Implementation und Erfüllung der M$'schen Werbeversprechen binden.
M$ macht es uns allen wieder einmal vor. In diesem Fall, wie man ein Projekt an die Konkurrenz 'outsourced' und ihr damit im selben Augenblick einen kräftigen Tritt 'in die Kronjuwelen' verpasst. Und dabei gewinnt M$ strategisch noch in weiterer Hinsicht: a) Kommunikation: ".net ist für alle da"; "MS macht jetzt auch Open Source"; "es gibt keinen Konflikt M$OSS"; "MS unterstützt OSS"; "OSS unterstützt MS" b) Finanzen: das Produkt wird nicht nur von der Konkurrenz entwickelt (was diese davon abhält eigenes zu entwickeln), sondern obendrein noch kostenlos!
Code-Module aus verschiedenen Programmiersprachen zu einem funktionsfähigen Ganzen zusammen zu bringen ist nun wahrlich nichts Neues. Jeder Linker kann das; vorausgesetzt der Programmierer kann richtig damit umgehen. Und wenn Icaza und Co. meinen, sie bräuchten unbedingt ein sprachübergreifendes API-Modell: muss man sich dann ausgerechnet an MS wenden, um sich sagen zu lassen, wie so etwas auszusehen hat?!
Wofür .NET? .NEt ist und bleibt Mist. Ich hab in grauer vorzeit mal unter win für Overnet es installiert, und bins nicht wieder los geworden...Reste finden sich bestimmt noch!
Mono ist einfach überflüssig. Na ja, nicht ganz, technisch gesehen ist das ganze ziemlich interessant. Aber bisher konnte mir Miguel de Icaza noch nicht klar machen, was der Vorteil von Mono ist. Eine freie Alternative zu .NET kann es nie werden, da sorgt MS schon für. Vielleicht wäre es besser gewesen an einer der freien Java-Implementierungen mitzuhelfen. Das wäre genauso interessant gewesen und hätte den Erfolg von Java noch weiter vorangetrieben. Aber die Java-Community kommt auch ohne Miguel gut aus
> Aber bisher konnte mir Miguel de Icaza noch nicht klar machen, was der > Vorteil von Mono ist.
Ja, klar, auf dich hat er ja auch nur gewartet. Miguel mag ja ein verwirrter Geist sein, aber er hat zumindest ein minimales Anforderungs-Level: Man muss lesen koennen um mit ihm zu kommunizieren.
Der Vorteil liegt wohl darin eine distributionsunabhängige Runtimeplattform zu haben. Windows.Form dürfte eigentlich das wichtiogste sein um kompatibilität zur Windowswelt herzustellen, da wird man auf Wine zurückgreifen, gibt da aber wohl Schwierigkeiten. Aus meiner Sicht ist die Lizenz von Mono problematisch. Es gefällt mir auch nicht, dass QT nicht unterstützt wird, was bei Ximian kaum verwundert. Doch für mich persönlich wäre das sehr wichtig. Es wird sicherlich noch eine Weile dauern, aber wenn Mono gelingt, wird das ein großer Wurf, egal ob die Kompatibilität zur MSWinwelt hergestellt wird. Sicherlich kann MS mit Patenten einige Sachen aussperren, aber soweit wird es hoffentlich nicht kommen.
Man kann über .Net denken was man will, meine Meinung ist: - C# ist eine konsequente Weiterentwicklung von C/C++ - C# steht in direkter Konkurrenz zu Java - Mono ist IMHO nicht .Net, sondern lediglich eine plattformunabhängige C#-Umgebung - Mit gtk# oder qt# kann man schon heute nette plattformunabhängige Programme entwickeln - Allein schon wegen der Marktmacht von M$ werden wir Softwareentwickler mittelfristig nicht mehr an .Net/C# vorbeikommen. (und dann macht Mono auf Linux erst recht Sinn !) - Wer behauptet, er programmiert lieder in C/C++, hat den Sinn von C# noch nicht verstanden - und last but not least: Wer behauptet, es gibt noch keine .Net-Programme, hat von professioneller Softwareentwicklung noch nie etwas gehört. Fast alle neu entwickelten Programme, die die Firmen bei uns Software-Häusern in Auftrag geber, werden in .Net/C+ entwickelt. (siehe auch Heise-Newsticker: Vor ein paar Tagen wurde dort berichtet, dass die Polizei NRW ihr neues Polizei-Auskunftssystem in Betrieb benommen hat. Dieses wurde in .Net entwickelt (natürlich von M$). Die Verwendung und Einbindung von/in Intranets mit klassischer Mittelware und Datenbanken ist in .Net nun mal sehr einfach.
Tschüß Ulf (P.S:: Bin wahrlich kein M$-Fan, aber man muss ab und zu den Situation auch ins Auge schauen)
"- Mono ist IMHO nicht .Net, sondern lediglich eine plattformunabhängige C#-Umgebung"
Naja .NET ist aber weit mehr als C# und einer der wichtigsten Punkte ist ja die Sprach-Unabhaengigkeit. So kann man z.B. schon Mono Programme in MonoBasic schreiben. Es ist also schon eher eine komplette .NET Implementierung.
Naja .NET ist aber weit mehr als C# und einer der wichtigsten Punkte ist ja die Sprach-Unabhaengigkeit. So kann man z.B. schon Mono Programme in MonoBasic schreiben. Es ist also schon eher eine komplette .NET Implementierung.
Kann man in Java auch :-) Der Java-Bytecode ist ja durchaus nicht java-spezifisch. Es gibt auch Compiler anderer Sprachen die Java-Bytecode erzeugen. Mal abgesehen davon, daß unter Umständen es wenig Sinn macht mehrere Sprachen zu mischen weil ja unterschiedliche Sprachen unterschiedliche Philosophien haben. Die zu mischen da kann nichts gutes bei herauskommen. Wenn gleich die Idee von Intentional Programming durchaus interessant ist, Algorithmen in einem sprachneutralen Syntaxbaum darzustellen.
Es ging ja jetzt nicht darum was Java kann, sondern was Mono ist (keine reine C# Entwicklungsumgebung ). Das Mischen der Sprachen finde ich auf alle Faelle sehr sehr wichtig. Es wird doch eh schon oft praktiziert ueber umstaendliche Bindings. Warum sollte man z.B. nicht ein Toolkit in C, eine Render-Engine in C++ und ein Interface dafuer in Basic schreiben (rein hypothetisches Beispiel).
Das Mischen der Sprachen finde ich auf alle Faelle sehr sehr wichtig. Es wird doch eh schon oft praktiziert ueber umstaendliche Bindings. Über dieses Feature kann man geteilter Meinung sein. Das mischen von Sprachen ist hier ja ohnehin etwas anders gemeint. Zum Beispiel das Du eine Klasse in C++ erstellen kannst und diese in C# benutzen kannst. Und das sehe ich eben als problematisch. Weil die Konzepte eben unterschiedlich sind und dabei viel Murks herumkommen kann.
Warum sollte man z.B. nicht ein Toolkit in C, eine Render-Engine in C++ und ein Interface dafuer in Basic schreiben (rein hypothetisches Beispiel). Das man das .NET - Toolkit sprachübergreifend verwenden kann ist eher eine Sache, daß es halt innerhalb von .NET allen Sprachen zur Verfügung gestellt wird. Bestehende (nicht .NET) Toolkits müssen weiterhin über Bindings angesprochen werden.
- Allein schon wegen der Marktmacht von M$ werden wir Softwareentwickler mittelfristig nicht mehr an .Net/C# vorbeikommen. (und dann macht Mono auf Linux erst recht Sinn !)
Ob du es glaubst oder nicht: es gibt bereiche, in denen denkt man erst garnicht über Microsoft-produkte nach, weil sie die anforderungen nicht erfüllen
>> Wer behauptet, es gibt noch keine .Net-Programme, hat von professioneller Softwareentwicklung noch nie etwas gehört. Fast alle neu entwickelten Programme, die die Firmen bei uns Software-Häusern in Auftrag geber, werden in .Net/C+ entwickelt. <<
IMHO Schwachsinn. Ich kenne ne ganze Menge Leute, die unter Windows entwickeln. Viele von denen haben sich auch schon ausgiebig mit .Net befasst. Aber größere Projekte entwickelt so gut wie Keiner damit. Warum? Weil es noch ziemlich buggy ist. Weil man ne ganze Menge Zeit braucht umd die neuen Sprachen so zu beherrschen wie die Alten. Weil viele der alten Softwarekomponenten entgegen den Versprechungen von M$ halt nicht so ohne weiteres wiederzuverwenden sind. Weil die Kunden nicht unbedingt ihre ganze Hardware-/Softwarelandschaft austauschen, nur damit .Net auf den Clients/Servern lauffähig ist. Weil es für den geplanten Zweck keinerlei Vorteile hat.
Bis sich .Net in der Breite durchsetzt werden noch einige Jährchen ins Land gehen.
Hier ein Beispiel für ein ziemlich grosses .net-Projekt(wenn auch vb.net) > 1'000'000Zeilen Code. www.evidencexp.com(wenn diese art Werbung nicht erwünscht ist, einfach post löschen.)
Das gescheiteste an dem C#-Net Geschwafel ist doch der eingebaute Garbage Collector. Das sollte sich durchaus auch unter C/C++ durchsetzen sowas zu nutzen... C/C++ ist ja bereits Plattformunabhängig und läuft auf mehr Plattformen als Java und C# zusammen. Richtig funktionsfähig ist doch .NET bis jetzt nur auf Windows und damit ist der Sinn der ganzen Aktion schon widerlegt.
Für verteilte Anwendungen braucht man bestimmt kein C# oder .NET. Es existieren schon lange Industriestandards wie CORBA mit denen sowas machbar ist. Für Interprozesscommunikation zwischen Prozessen auf einem Rechner, gibt es auch andere Möglichkeiten von COM, DCOP etc.
Da der Zwischencode lesbar ist und mit Scramblen das Message-Reflection nicht mehr funktioniert, wird das ganze im closed Source Bereich keine Chance haben. Es gab darüber auchmal einen interessanten Artikel in der iX...
>C/C++ ist ja bereits Plattformunabhängig und läuft auf mehr Plattformen als Java und C# zusammen<
Du vergleichst hier aber Äpfel mit Birnen. Bei C/C++ ist nur der ursprüngliche Quellcode einigermaßen portabel und das auch nicht vollständig. Ein Programm, dass sich auf Linux/x86er übersetzen lässt musss noch lange nicht auf Linux/Alpha laufen. Geschweige dem *BSD nativ, Solaris, AIX usw...
>Richtig funktionsfähig ist doch .NET bis jetzt nur auf Windows und damit ist der Sinn der ganzen Aktion schon widerlegt.<
Bis jetzt... Inwieweit es sich rentiert C#/VB/Mono Programme zu entwickeln muss sich erst noch zeigen. Aber IMHO hat auch Mono seine Daseinsberechtigung. Ob man es nutzt muss jeder selbst wissen...
Ich habe halt meine Befürchtungen das MS sich was einfallen lassen wird das einiges nur unter Windows richtig funktioniert. Letztlich stehen wir dann vor dem gleichen Problem wie heute, weil Spezifikationen nicht offen sind. Man wird sehen was mit Mono wird. Entweder wirds ein Flop oder nicht.
Wir haben doch nichts zu verlieren. Wenn MS Erweiterungen schreibt, die nur unter Windows unterstuetzt werden, dann stehen die eben nicht zur Verfuegung wenn man plattformunabhaengig mit .NET/Mono entwickeln moechte. Gaebe es Mono nicht, staenden diese genausowenig zur Verfuegung.
Das gescheiteste an dem C#-Net Geschwafel ist doch der eingebaute Garbage Collector. Das sollte sich durchaus auch unter C/C++ durchsetzen sowas zu nutzen...
Über denn Sinn einer GC kann man streiten. Es mag ganz hilfreich sein, daß der Programmierer sich nicht mehr um die Speicherverwaltung kümmern muss. Aber wenn ein Programmierer nicht mal seine Speicherverwaltung im Griff hat, dann soll er das programmieren sein lassen. :-)
GC hat nämlich auch entscheidene Nachteile. So ist der Speicherbedarf höher weil ja auch viele Objekte im Heap liegen die nicht mehr benötigt werden aber die der GC noch nicht weggeräumt hat. Desweiteren benötigt das auch Rechenresourcen. Der GC muss ja von Zeit zu Zeit schauen, ob Speicherbereiche freizugeben sind. Und das dauert. Abgesehen davon, daß Echtzeitanwendungen damit quasi nicht realisierbar sind weil man nicht genau sagen kann, wann der GC in Aktion tritt. Für eine Raketensteuerung wäre es beispielsweise fatal wenn eigentlich eine Flugbahnkorrektur vorgenommen werden müsste aber das Programm nicht rechtzeitig dazu kommt, weil der GC meint mal wieder seinen Dienst verrichten zu müssen.
In dem Zusammenhang sollte man vielleicht auch mal Objective-C erwähnen. Auch ein Nachfolger von C und ungefähr zur selben Zeit entstanden wie C++ mit Merkmalen einer modernen Sprache (und ohne GC). Dadurch das es Objective-C schon sehr lange gibt hat man auch nicht mit Kinderkrankheiten zu kämpfen. Und unter MacOS wird Objective-C sehr erfolgreich eingesetzt und kann seine Vorteile (dynamic-binding, Messages usw.) voll ausspielen.
Kann gar nicht verstehen, daß sich so eine Sprache wie C++ durchgesetzt hat. Ist nichtmal richtig objektorientiert (C++ ist ja letzlich nur ein C mit einer Sprungtabelle; ok vielleicht etwas krass ausgedrückt) sondern eher eine Krücke.
C/C++ ist ja bereits Plattformunabhängig und läuft auf mehr Plattformen als Java und C# zusammen. Richtig funktionsfähig ist doch .NET bis jetzt nur auf Windows und damit ist der Sinn der ganzen Aktion schon widerlegt.
Für die reine Sprache ist das richtig. Doch beschränken sich Programme ja selten auf ANSI-C. Problematischer sind meist die Bibliotheken und Toolkits die verwendet werden. Wenn dein C/C++ Programm eine GUI hat, dann wird es mit der plattformunabhängigkeit schon sehr viel schwieriger. Es gibt plattformübergreifene Toolkits ... das stimmt. Aber die beschränken sich meist auf die großen drei (Windows, MacOS, Linux).
> Kann gar nicht verstehen, daß sich so eine Sprache wie C++ durchgesetzt hat.
Was mich an C++ nervt ist dass die std libraries so ein Flickwerk sind. von std::string kann man nichts ableiten, auto_ptr funktioniert nicht mit den containern und so weiter. Das fällt zwar wenn man Qt nimmt nicht so ins Gewicht, aber wenn man z.B. versucht eine library zu bauen ist das schon nervig.
string ist selbst nur eine Instantiierung des basic_string Templates. Andererseits sehe ich jetzt keinen Grund, warum man nicht von basic_sring oder string ableiten könnte.
Container von auto_ptrs (falls du das gemeint hast) sind eine so schlechte Idee, daß die STL-Designer alles getan haben, um zu verhindern, daß solcher Code überhaupt compiliert werden kann. Smart Pointers sind dagegen möglich.
Die C++ std::string klasse und hat keinen virtuellen dtor, womit ein memory leak entsteht, wenn man eine eigene davon ableitet. Ist ein relativ häufiger Fehler und habe ich gestern erst wieder gesehen im KControl module: klilo.
Wie gut, daß ich klilo nicht verwende. Aber wahrscheinlich enthält Konqueror den gleichen Blödsinn ;-)
Daß basic_string keinen virtuellen Destruktor hat, liegt möglicherweise daran, daß die STL-Entwickler den Speicherplatz für eine vtable in basic_string sparen wollten. Viel Info habe ich dazu nicht gefunden.
Generell meine ich, daß die STL vielleicht nicht einfach ist (und sowieso zu spät kam), aber sie ist auf jeden Fall durchdacht und nicht das Produkt eines Erstsemesters mit einem üblen Hangover
Konqueror hat das Problem nicht da dort QString verwendet wird. Der Grund wieso der klilo Author std::string benutzt und nicht QString ist, damit das backend auch für GNOME programme benutzt werden kann.
Potentiell gefährdet sind eher GTKmm programme als Qt programme, da Qt nicht gut mit der stdc++ lib verknüpft ist. Es gibt z.B. keinen QString ctor ala QString( const std::string Str )
GTKmm Objekte arbeiten mit std::string, so dass der Author evtl dazu verleitet werden könnte seine eigene String Klasse zu implementieren. Andererseits ist es natürlich auch wieder eine schöne Sache dass GTKmm std::string unterstützt.
Sicher, der GC benötigt einiges an Overhead. Allerdings sind Bugs im Zusammenhang mit falschem Zugriff auf nicht allokierten Speicher oder auch die berüchtigten Speicher-Leaks mit die Hauptfehlerquellen bei C/C++ (mal von Zeigerfehlern abgesehen). Ich weiss nicht wie die Performance z.B. beim Böhm-GC aussieht, bzw. bei dem welcher C# nutzt. Allerdings soll die Geschwindigkeit schon recht beachtlich sein und Java um vielfaches übertreffen.
Jup. Bei der GUI und den ganzen Toolkits hört es auf. Naja, Java macht doch aber in diesem Bereich nicht so eine schlechte Figur? Eclipse z.B. finde ich ziemlich performant. Ob C# und .NET Framework da wirklich nun in die Bresche springen? Ich weiss nicht recht...
Sicher, der GC benötigt einiges an Overhead. Allerdings sind Bugs im Zusammenhang mit falschem Zugriff auf nicht allokierten Speicher oder auch die berüchtigten Speicher-Leaks mit die Hauptfehlerquellen bei C/C++ (mal von Zeigerfehlern abgesehen). Das ist aber ein Problem von C/C++ und nicht ein Problem fehlender Garbage-Collection. In Objective-C ist das wesentlich eleganter gelöst. Dort forderst Du mit einem retain Speicher für ein Objekt an und gibst es mit einem release zurück (wobei sichergestellt wird, daß mögliche Unterobjekte auch freigegeben werden). Ich sehe also den Vorteil eines im Hintergrund laufenden GC nicht. Die leichten Vorteile (man braucht kein release) wiegen die Nachteile (Geschwindigkeit) nicht auf.
Ich weiss nicht wie die Performance z.B. beim Böhm-GC aussieht, bzw. bei dem welcher C# nutzt. Allerdings soll die Geschwindigkeit schon recht beachtlich sein und Java um vielfaches übertreffen. Der GC ist ja nur ein Fakt, der die Geschwindigkeit beeinflusst. Viel hängt ja auch ab von der Qualität des verwendeten JIT's. Zudem wäre es mal interessant zu wissen, welche Geschwindigkeit da gemessen wurde. Bei Java hat man dann noch den Nachteil das das Standard-Toolkit für GUI's (nämlich Swing) alle Oberflächenelemente selbst zeichnet während .NET bestimmt (kann ich aber nicht zu 100% sagen) Native-Controls verwendet, weshalb Java-GUI's etwas behäbig erscheinen.
Ich weiß sowieso nicht, wie man auf die Idee kommen kann eine Sprache von einem Interpreter (oder wie es modern heißt: Virtual Machine) ausführen zu lassen. Die Zeiten sollten lange zurück liegen. An die Geschwindigkeit eines Native-Programms kommt man einfach nicht heran. Aus diesen Grund würde man das Native-Programm immer dem interpretierten Äquivalent vorziehen.
Das Problem mit der Plattformunabhängigkeit: Weder Java noch .NET sind derzeit wirklich plattformunabhängig und ich Frage mich auch nach dem Sinn einer plattformunabhängigkeit auf Binärebene. Quellcodeebene ist in den meisten Fällen ausreichen. Und das Package-Konzept von MacOS ermöglicht es sein Native-Programm plattformunabhängig auch auf Binärebene zur Verfügung gestellt. Nämlich einfach dadurch, dass der Loader die richtige Version des Programms automatisch auswählt. Und installieren muss man auch nix. Ist ohnehin eine Unart aus der Windows / Linux Welt. Bei MacOS ziehst Du dein Packages einfach nach Application und gut iss. Und wenn du es nicht mehr brauchst ist es ebenso leicht zu entfernen ohne das irgendwelche Registry-Einträge, verwaiste Verzeichnisse DDL's .so's oder etc's zurückbleiben. Weil diese schlicht und ergreifend nicht benötigt werden. Dynamic binding sei Dank. Das hinter MacOS ein Konzept steht wo man sich WIRKLICH Gedanken drüber gemacht hat, merkt man deutlich.
Jup. Bei der GUI und den ganzen Toolkits hört es auf. Naja, Java macht doch aber in diesem Bereich nicht so eine schlechte Figur? Eclipse z.B. finde ich ziemlich performant. Siehst und Eclipse verwendet statt Swing einfach SWT was letzlich nur Bindungen zu native-Controls der jeweiligen Plattform sind.
> Das gescheiteste an dem C#-Net Geschwafel ist doch der eingebaute Garbage Collector. Das sollte sich durchaus auch unter C/C++ durchsetzen sowas zu nutzen...
smart pointer sind die bessere alternative zu nem GC. gibt ne menge bei boost.org oder man kann ja immer noch auto_ptr nehmen.
Hm, kann mich ja auch irren aber ist nicht ein Grund für Gnome und somit die verwendung von GTK gewesen das man die Lizenztechnischen Probleme mit QT aus dem Weg gehen wollte?
Und jetzt soll eine API für Gnome verwendet werden die erst kürzlich von MS Patentiert wurde? Ist das denn gesichert das Gnome auf Mono aufsetzen wird oder wirds nur in betracht gezogen. Schließlich würde man ja ein nicht zu unterschätzendes Risiko eingehen.
Mono ist nur eine Moeglichkeit von vielen um GNOME Software zu schreiben. Ob jemals irgendwelche zentralen Bestandteile von GNOME auf diese Weise geschrieben werden steht noch in den Sternen. Allerdings gibt es auch einen riesigen Unterschied zwischen einer restriktiven Lizenz und _moeglichen_ Patentschwierigkeiten. Zumal die Bereiche die fuer Gtk# notwendig sind auf offenen Standards basieren und Patentschwierigkeiten nahezu auszuschliessen sind. Siehe dazu auch http://www.go-mono.com/faq.html#patents
Desweiteren enthält es einige Erweiterungen von MS.NET, die nicht standardisiert sind, sowie eigene Erweiterungen, um Linux/Unix bestmöglich zu unterstützen Ich finde das Kontraproduktiv, wenn die auch noch eigene Erweiterungen einbauen, um Linux besser zu unterstützen. Damit sind sie (Ximian) auf dem gleichen Level wie MS, die das gleiche halt für Windows machen. Was nützt die Plattformunabhängigkeit, wenn es wieder plattformspezifische Erweiterungen gibt?
Es geht hier nicht um plattformspezifische Erweiterungen sondern um Tools wie Gtk+ die aus der Unix Welt kommen aber (vor allem mit Mono) auch genausogut unter Windows oder sonstwo verwendet werden koennen.
Auf der einen Seite ist es ja ganz schön das Mono bald "fertig" ist...
Aber ich befürchte wenn Ximian anfängt mono zu verwenden um Teile des GNOME Desktop zu entwickeln, dann springt SUN vom GNOME Zug ab.. da .NET der erklärte Gegener von Java ist ihrere Hauptsächlichen Einkunftsquelle...
Und IBM wird es wohl auch nicht soooo gerne sehen, schliesslich verdient auch IBM mit Java Lösungen sein Geld..
Aber wir werden sehen was die Zukunft bringt..
Gruß
Waldgeist
Borland unterstützt schließlich auch beides.
Davon abgesehen glaube ich aber auch nicht, dass in absehbarer Zeit zentrale Bestandteile des Desktops in Mono geschrieben werden.
Eclipse fühlt sich IMHO schon recht Gtk-native an, bzw. ist GTK. Nur so als beispiel
Also SWT setzt zumindest auf gtk auf und wenn man eclipse mit gcj compiliert kann sich der Speed locker mit ner .NET Anwendung messen lassen...
Gruß
Waldgeist
Warum? Hast Du Aktien von denen?
> hoffe aber, dass sie Java irgendwie "neben" Mono platzieren koennen
Wozu?
> Java ist ja eh nicht geeignet um native GNOME/Gtk Anwendungen zu
> schreiben.
Im Vergleich zu was? Mono?
> Auf der anderen Seite ist Mono eigentlich auch gar nicht so fett
Im Vergleich zu was?
> also vielleicht kuemmert es SUN gar nicht wenn sie Mono und Java
> nebenher verwenden muessen.
SUN soll/koennte Mono verwenden?
Kann es sein, dass Du erstmal ein bisschen Hintergrundinformationen
sammeln moechtest?
KDE umsteigen.
Das ist doch nicht schwer vorherzusagen, dass
Microsoft irgendwann vom GNOME-Projekt
Patentgebuehren verlangen wird, wahrscheinlich
erst in ein paar Jahren, wenn man nicht
mehr so leicht zurueck kann.
Ich faende es viel besser, wenn
zukuenftige GNOME-Versionen auf Java
aufsetzen wuerden. SUN ist naemlich nicht
daran interessiert (anders als Microsoft)
GNOME kaputt zu machen.
> Microsoft irgendwann vom GNOME-Projekt
> Patentgebuehren verlangen wird,
Ist das hier die Zombie-Night?
"Wir haben zwar keine Substanz, sind jedoch durchaus in der Lage ein
paar Kinder zu erschrecken"
Leute, _lest_ die verf***** Doku.
verkuendet, dass seiner Meinung nach
Mono wegen Patenrechtsverletzung illegal
waere.
Irgendwelche Vaporware als revolutionär neue Generation von Appliktationen zu präsentieren hat M$ ja schon häufiger (um nicht zu sagen regelmäßig) exerziert. Nur um [potentielle] Kunden vom Kauf bereits existierender gleichwertiger oder besserer Software abzuhalten, bis den Konkurrenten die [finanzielle] Puste ausging. Wo das nicht 100%ig funktionierte, hat man halt die Fremdfirmen aufgekauft. Jahre später hatte M$ dann jeweils auch halb- bzw. dreiviertel-wegs laufende Versionen der 'eigenen Innovationen' zur Verfügung.
Linux kann man nicht kaufen. Aber man kann versuchen, der Bewegung den Boden unter den Füßen zu entziehen:
1. 'Software-Patente' ("computerimplementierbare Erfindungen"): ein von einer Europaparlamentarierin Groß-Britanniens eingereichter "Gesetzesentwurf", der komischerweise fast identisch mit einem Dokument des US-amerikanischen Softwareproduzenten-Verbandes ist. (Details siehe z.Bsp. http://www.ffii.org/ )
2. Statt [wie bisher] mit einem Riesenaufwand die eigene Vaporware selbst in etwas konkret Produktives umzuwandeln kann man jetzt hingehen und dutzende führender OSS-Entwickler in der Implementation und Erfüllung der M$'schen Werbeversprechen binden.
M$ macht es uns allen wieder einmal vor. In diesem Fall, wie man ein Projekt an die Konkurrenz 'outsourced' und ihr damit im selben Augenblick einen kräftigen Tritt 'in die Kronjuwelen' verpasst. Und dabei gewinnt M$ strategisch noch in weiterer Hinsicht:
a) Kommunikation: ".net ist für alle da"; "MS macht jetzt auch Open Source"; "es gibt keinen Konflikt M$OSS"; "MS unterstützt OSS"; "OSS unterstützt MS"
b) Finanzen: das Produkt wird nicht nur von der Konkurrenz entwickelt (was diese davon abhält eigenes zu entwickeln), sondern obendrein noch kostenlos!
Code-Module aus verschiedenen Programmiersprachen zu einem funktionsfähigen Ganzen zusammen zu bringen ist nun wahrlich nichts Neues. Jeder Linker kann das; vorausgesetzt der Programmierer kann richtig damit umgehen.
Und wenn Icaza und Co. meinen, sie bräuchten unbedingt ein sprachübergreifendes API-Modell: muss man sich dann ausgerechnet an MS wenden, um sich sagen zu lassen, wie so etwas auszusehen hat?!
.NEt ist und bleibt Mist.
Ich hab in grauer vorzeit mal unter win für Overnet es installiert, und bins nicht wieder los geworden...Reste finden sich bestimmt noch!
> Vorteil von Mono ist.
Ja, klar, auf dich hat er ja auch nur gewartet. Miguel mag ja ein
verwirrter Geist sein, aber er hat zumindest ein minimales
Anforderungs-Level: Man muss lesen koennen um mit ihm zu kommunizieren.
Es wird sicherlich noch eine Weile dauern, aber wenn Mono gelingt, wird das ein großer Wurf, egal ob die Kompatibilität zur MSWinwelt hergestellt wird.
Sicherlich kann MS mit Patenten einige Sachen aussperren, aber soweit wird es hoffentlich nicht kommen.
http://www.google.de/search?as_qdr=m3&q=.net++patent
http://qtcsharp.sourceforge.net/
- C# ist eine konsequente Weiterentwicklung von C/C++
- C# steht in direkter Konkurrenz zu Java
- Mono ist IMHO nicht .Net, sondern lediglich eine plattformunabhängige C#-Umgebung
- Mit gtk# oder qt# kann man schon heute nette plattformunabhängige Programme entwickeln
- Allein schon wegen der Marktmacht von M$ werden wir Softwareentwickler mittelfristig nicht mehr an .Net/C# vorbeikommen.
(und dann macht Mono auf Linux erst recht Sinn !)
- Wer behauptet, er programmiert lieder in C/C++, hat den Sinn von C# noch nicht verstanden
- und last but not least: Wer behauptet, es gibt noch keine .Net-Programme, hat von professioneller Softwareentwicklung noch
nie etwas gehört. Fast alle neu entwickelten Programme, die die Firmen bei uns Software-Häusern in Auftrag geber, werden in
.Net/C+ entwickelt. (siehe auch Heise-Newsticker: Vor ein paar Tagen wurde dort berichtet, dass die Polizei NRW ihr neues
Polizei-Auskunftssystem in Betrieb benommen hat. Dieses wurde in .Net entwickelt (natürlich von M$).
Die Verwendung und Einbindung von/in Intranets mit klassischer Mittelware und Datenbanken ist in .Net nun mal sehr einfach.
Tschüß
Ulf
(P.S:: Bin wahrlich kein M$-Fan, aber man muss ab und zu den Situation auch ins Auge schauen)
Naja .NET ist aber weit mehr als C# und einer der wichtigsten Punkte ist ja die Sprach-Unabhaengigkeit. So kann man z.B. schon Mono Programme in MonoBasic schreiben. Es ist also schon eher eine komplette .NET Implementierung.
Naja .NET ist aber weit mehr als C# und einer der wichtigsten Punkte ist ja die Sprach-Unabhaengigkeit. So kann man z.B. schon Mono Programme in MonoBasic schreiben. Es ist also schon eher eine komplette .NET Implementierung.
Kann man in Java auch :-)
Der Java-Bytecode ist ja durchaus nicht java-spezifisch. Es gibt auch Compiler anderer Sprachen die Java-Bytecode erzeugen.
Mal abgesehen davon, daß unter Umständen es wenig Sinn macht mehrere Sprachen zu mischen weil ja unterschiedliche Sprachen unterschiedliche Philosophien haben. Die zu mischen da kann nichts gutes bei herauskommen. Wenn gleich die Idee von Intentional Programming durchaus interessant ist, Algorithmen in einem sprachneutralen Syntaxbaum darzustellen.
Gruß
MichaelB
Das Mischen der Sprachen finde ich auf alle Faelle sehr sehr wichtig. Es wird doch eh schon oft praktiziert ueber umstaendliche Bindings. Warum sollte man z.B. nicht ein Toolkit in C, eine Render-Engine in C++ und ein Interface dafuer in Basic schreiben (rein hypothetisches Beispiel).
Das Mischen der Sprachen finde ich auf alle Faelle sehr sehr wichtig. Es wird doch eh schon oft praktiziert ueber umstaendliche Bindings.
Über dieses Feature kann man geteilter Meinung sein. Das mischen von Sprachen ist hier ja ohnehin etwas anders gemeint. Zum Beispiel das Du eine Klasse in C++ erstellen kannst und diese in C# benutzen kannst. Und das sehe ich eben als problematisch. Weil die Konzepte eben unterschiedlich sind und dabei viel Murks herumkommen kann.
Warum sollte man z.B. nicht ein Toolkit in C, eine Render-Engine in C++ und ein Interface dafuer in Basic schreiben (rein hypothetisches Beispiel).
Das man das .NET - Toolkit sprachübergreifend verwenden kann ist eher eine Sache, daß es halt innerhalb von .NET allen Sprachen zur Verfügung gestellt wird. Bestehende (nicht .NET) Toolkits müssen weiterhin über Bindings angesprochen werden.
Gruß
MichaelB
das ist ein vollkommen vertrottelter MS Marketing spruch den du da wiederkaust
(und dann macht Mono auf Linux erst recht Sinn !)
Ob du es glaubst oder nicht: es gibt bereiche, in denen denkt man erst garnicht über Microsoft-produkte nach, weil sie die anforderungen nicht erfüllen
IMHO Schwachsinn. Ich kenne ne ganze Menge Leute, die unter Windows entwickeln. Viele von denen haben sich auch schon ausgiebig mit .Net befasst. Aber größere Projekte entwickelt so gut wie Keiner damit. Warum? Weil es noch ziemlich buggy ist. Weil man ne ganze Menge Zeit braucht umd die neuen Sprachen so zu beherrschen wie die Alten. Weil viele der alten Softwarekomponenten entgegen den Versprechungen von M$ halt nicht so ohne weiteres wiederzuverwenden sind. Weil die Kunden nicht unbedingt ihre ganze Hardware-/Softwarelandschaft austauschen, nur damit .Net auf den Clients/Servern lauffähig ist. Weil es für den geplanten Zweck keinerlei Vorteile hat.
Bis sich .Net in der Breite durchsetzt werden noch einige Jährchen ins Land gehen.
www.evidencexp.com(wenn diese art Werbung nicht erwünscht ist, einfach post löschen.)
Also ich freue mich auf mono.
gruss
manuel
C/C++ ist ja bereits Plattformunabhängig und läuft auf mehr Plattformen als Java und C# zusammen. Richtig funktionsfähig ist doch .NET bis jetzt nur auf Windows und damit ist der Sinn der ganzen Aktion schon widerlegt.
Für verteilte Anwendungen braucht man bestimmt kein C# oder .NET. Es existieren schon lange Industriestandards wie CORBA mit denen sowas machbar ist. Für Interprozesscommunikation zwischen Prozessen auf einem Rechner, gibt es auch andere Möglichkeiten von COM, DCOP etc.
Da der Zwischencode lesbar ist und mit Scramblen das Message-Reflection nicht mehr funktioniert, wird das ganze im closed Source Bereich keine Chance haben. Es gab darüber auchmal einen interessanten Artikel in der iX...
Du vergleichst hier aber Äpfel mit Birnen. Bei C/C++ ist nur der ursprüngliche Quellcode einigermaßen portabel und das auch nicht vollständig. Ein Programm, dass sich auf Linux/x86er übersetzen lässt musss noch lange nicht auf Linux/Alpha laufen. Geschweige dem *BSD nativ, Solaris, AIX usw...
>Richtig funktionsfähig ist doch .NET bis jetzt nur auf Windows und damit ist der Sinn der ganzen Aktion schon widerlegt.<
Bis jetzt...
Inwieweit es sich rentiert C#/VB/Mono Programme zu entwickeln muss sich erst noch zeigen. Aber IMHO hat auch Mono seine Daseinsberechtigung.
Ob man es nutzt muss jeder selbst wissen...
mfg
Hans
Man wird sehen was mit Mono wird. Entweder wirds ein Flop oder nicht.
Das gescheiteste an dem C#-Net Geschwafel ist doch der eingebaute Garbage Collector. Das sollte sich durchaus auch unter C/C++ durchsetzen sowas zu nutzen...
Über denn Sinn einer GC kann man streiten. Es mag ganz hilfreich sein, daß der Programmierer sich nicht mehr um die Speicherverwaltung kümmern muss. Aber wenn ein Programmierer nicht mal seine Speicherverwaltung im Griff hat, dann soll er das programmieren sein lassen. :-)
GC hat nämlich auch entscheidene Nachteile. So ist der Speicherbedarf höher weil ja auch viele Objekte im Heap liegen die nicht mehr benötigt werden aber die der GC noch nicht weggeräumt hat. Desweiteren benötigt das auch Rechenresourcen. Der GC muss ja von Zeit zu Zeit schauen, ob Speicherbereiche freizugeben sind. Und das dauert. Abgesehen davon, daß Echtzeitanwendungen damit quasi nicht realisierbar sind weil man nicht genau sagen kann, wann der GC in Aktion tritt. Für eine Raketensteuerung wäre es beispielsweise fatal wenn eigentlich eine Flugbahnkorrektur vorgenommen werden müsste aber das Programm nicht rechtzeitig dazu kommt, weil der GC meint mal wieder seinen Dienst verrichten zu müssen.
In dem Zusammenhang sollte man vielleicht auch mal Objective-C erwähnen. Auch ein Nachfolger von C und ungefähr zur selben Zeit entstanden wie C++ mit Merkmalen einer modernen Sprache (und ohne GC). Dadurch das es Objective-C schon sehr lange gibt hat man auch nicht mit Kinderkrankheiten zu kämpfen. Und unter MacOS wird Objective-C sehr erfolgreich eingesetzt und kann seine Vorteile (dynamic-binding, Messages usw.) voll ausspielen.
Kann gar nicht verstehen, daß sich so eine Sprache wie C++ durchgesetzt hat. Ist nichtmal richtig objektorientiert (C++ ist ja letzlich nur ein C mit einer Sprungtabelle; ok vielleicht etwas krass ausgedrückt) sondern eher eine Krücke.
C/C++ ist ja bereits Plattformunabhängig und läuft auf mehr Plattformen als Java und C# zusammen. Richtig funktionsfähig ist doch .NET bis jetzt nur auf Windows und damit ist der Sinn der ganzen Aktion schon widerlegt.
Für die reine Sprache ist das richtig. Doch beschränken sich Programme ja selten auf ANSI-C. Problematischer sind meist die Bibliotheken und Toolkits die verwendet werden. Wenn dein C/C++ Programm eine GUI hat, dann wird es mit der plattformunabhängigkeit schon sehr viel schwieriger. Es gibt plattformübergreifene Toolkits ... das stimmt. Aber die beschränken sich meist auf die großen drei (Windows, MacOS, Linux).
Gruß
MichaelB
JVM `s gibts meistens auch nur für die grossen drei ;)
Marc
Was mich an C++ nervt ist dass die std libraries so ein Flickwerk sind. von std::string kann man nichts ableiten, auto_ptr funktioniert nicht mit den containern und so weiter. Das fällt zwar wenn man Qt nimmt nicht so ins Gewicht, aber wenn man z.B. versucht eine library zu bauen ist das schon nervig.
Marc
Container von auto_ptrs (falls du das gemeint hast) sind eine so schlechte Idee, daß die STL-Designer alles getan haben, um zu verhindern, daß solcher Code überhaupt compiliert werden kann. Smart Pointers sind dagegen möglich.
Marc
Daß basic_string keinen virtuellen Destruktor hat, liegt möglicherweise daran, daß die STL-Entwickler den Speicherplatz für eine vtable in basic_string sparen wollten. Viel Info habe ich dazu nicht gefunden.
Generell meine ich, daß die STL vielleicht nicht einfach ist (und sowieso zu spät kam), aber sie ist auf jeden Fall durchdacht und nicht das Produkt eines Erstsemesters mit einem üblen Hangover
Konqueror hat das Problem nicht da dort QString verwendet wird. Der Grund wieso der klilo Author std::string benutzt und nicht QString ist, damit das backend auch für GNOME programme benutzt werden kann.
Potentiell gefährdet sind eher GTKmm programme als Qt programme, da Qt nicht gut mit der stdc++ lib verknüpft ist. Es gibt z.B. keinen QString ctor ala
QString( const std::string Str )
GTKmm Objekte arbeiten mit std::string, so dass der Author evtl dazu verleitet werden könnte seine eigene String Klasse zu implementieren. Andererseits ist es natürlich auch wieder eine schöne Sache dass GTKmm std::string unterstützt.
Marc
Sicher, der GC benötigt einiges an Overhead. Allerdings sind Bugs im Zusammenhang mit falschem Zugriff auf nicht allokierten Speicher oder auch die berüchtigten Speicher-Leaks mit die Hauptfehlerquellen bei C/C++ (mal von Zeigerfehlern abgesehen). Ich weiss nicht wie die Performance z.B. beim Böhm-GC aussieht, bzw. bei dem welcher C# nutzt. Allerdings soll die Geschwindigkeit schon recht beachtlich sein und Java um vielfaches übertreffen.
Jup. Bei der GUI und den ganzen Toolkits hört es auf. Naja, Java macht doch aber in diesem Bereich nicht so eine schlechte Figur? Eclipse z.B. finde ich ziemlich performant. Ob C# und .NET Framework da wirklich nun in die Bresche springen? Ich weiss nicht recht...
Sicher, der GC benötigt einiges an Overhead. Allerdings sind Bugs im Zusammenhang mit falschem Zugriff auf nicht allokierten Speicher oder auch die berüchtigten Speicher-Leaks mit die Hauptfehlerquellen bei C/C++ (mal von Zeigerfehlern abgesehen).
Das ist aber ein Problem von C/C++ und nicht ein Problem fehlender Garbage-Collection.
In Objective-C ist das wesentlich eleganter gelöst. Dort forderst Du mit einem retain Speicher für ein Objekt an und gibst es mit einem release zurück (wobei sichergestellt wird, daß mögliche Unterobjekte auch freigegeben werden).
Ich sehe also den Vorteil eines im Hintergrund laufenden GC nicht. Die leichten Vorteile (man braucht kein release) wiegen die Nachteile (Geschwindigkeit) nicht auf.
Ich weiss nicht wie die Performance z.B. beim Böhm-GC aussieht, bzw. bei dem welcher C# nutzt. Allerdings soll die Geschwindigkeit schon recht beachtlich sein und Java um vielfaches übertreffen.
Der GC ist ja nur ein Fakt, der die Geschwindigkeit beeinflusst. Viel hängt ja auch ab von der Qualität des verwendeten JIT's.
Zudem wäre es mal interessant zu wissen, welche Geschwindigkeit da gemessen wurde.
Bei Java hat man dann noch den Nachteil das das Standard-Toolkit für GUI's (nämlich Swing) alle Oberflächenelemente selbst zeichnet während .NET bestimmt (kann ich aber nicht zu 100% sagen) Native-Controls verwendet, weshalb Java-GUI's etwas behäbig erscheinen.
Ich weiß sowieso nicht, wie man auf die Idee kommen kann eine Sprache von einem Interpreter (oder wie es modern heißt: Virtual Machine) ausführen zu lassen. Die Zeiten sollten lange zurück liegen. An die Geschwindigkeit eines Native-Programms kommt man einfach nicht heran. Aus diesen Grund würde man das Native-Programm immer dem interpretierten Äquivalent vorziehen.
Das Problem mit der Plattformunabhängigkeit:
Weder Java noch .NET sind derzeit wirklich plattformunabhängig und ich Frage mich auch nach dem Sinn einer plattformunabhängigkeit auf Binärebene.
Quellcodeebene ist in den meisten Fällen ausreichen. Und das Package-Konzept von MacOS ermöglicht es sein Native-Programm plattformunabhängig auch auf Binärebene zur Verfügung gestellt. Nämlich einfach dadurch, dass der Loader die richtige Version des Programms automatisch auswählt. Und installieren muss man auch nix. Ist ohnehin eine Unart aus der Windows / Linux Welt. Bei MacOS ziehst Du dein Packages einfach nach Application und gut iss. Und wenn du es nicht mehr brauchst ist es ebenso leicht zu entfernen ohne das irgendwelche Registry-Einträge, verwaiste Verzeichnisse DDL's .so's oder etc's zurückbleiben. Weil diese schlicht und ergreifend nicht benötigt werden. Dynamic binding sei Dank. Das hinter MacOS ein Konzept steht wo man sich WIRKLICH Gedanken drüber gemacht hat, merkt man deutlich.
Jup. Bei der GUI und den ganzen Toolkits hört es auf. Naja, Java macht doch aber in diesem Bereich nicht so eine schlechte Figur? Eclipse z.B. finde ich ziemlich performant.
Siehst und Eclipse verwendet statt Swing einfach SWT was letzlich nur Bindungen zu native-Controls der jeweiligen Plattform sind.
Gruß
MichaelB
smart pointer sind die bessere alternative zu nem GC. gibt ne menge bei boost.org oder man kann ja immer noch auto_ptr nehmen.
Marc
> noch nicht verstanden
Sehr geehrte Damen und Herren,
ich kuendige Ihnen hiermit die Sensation des Jahres an:
"Ulf reimplementiert System-API-Calls in C#"
> (P.S:: Bin wahrlich kein M$-Fan, aber man muss ab und zu den Situation
> auch ins Auge schauen)
Ja, so wird's sein. Wahrscheinlich ins Huehnerauge.
Hast Du dich, in irgendeiner signifikanten Weise, 'mal technisch mit
dotnet (sic!) auseinander gesetzt? Nein, der Spruch
"Meine Firma macht das jetzt so."
ist nicht relevant.
Und jetzt soll eine API für Gnome verwendet werden die erst kürzlich von MS Patentiert wurde? Ist das denn gesichert das Gnome auf Mono aufsetzen wird oder wirds nur in betracht gezogen. Schließlich würde man ja ein nicht zu unterschätzendes Risiko eingehen.
odoggy
Allerdings gibt es auch einen riesigen Unterschied zwischen einer restriktiven Lizenz und _moeglichen_ Patentschwierigkeiten. Zumal die Bereiche die fuer Gtk# notwendig sind auf offenen Standards basieren und Patentschwierigkeiten nahezu auszuschliessen sind. Siehe dazu auch
http://www.go-mono.com/faq.html#patents
Ich finde das Kontraproduktiv, wenn die auch noch eigene Erweiterungen einbauen, um Linux besser zu unterstützen. Damit sind sie (Ximian) auf dem gleichen Level wie MS, die das gleiche halt für Windows machen. Was nützt die Plattformunabhängigkeit, wenn es wieder plattformspezifische Erweiterungen gibt?