Attachmate -> Mono, du bist gefeuert!

[MuLuNGuS]

mußte gerade an zurück in die zukunft 2 denken:

http://winfuture.de/news,63005.html

bitter für die entwickler, bitter für mono...mal sehen was aus "de icaza" wird.

[Exxtreme]

Der soll bei Google anheuern so wie Gosling auch. :D

Naja, ansonsten werde ich Mono nicht vermissen. Kenne echt kein ernsthaftes Programm, welches damit läuft.

[d2kx]

Banshee, Unity-Engine für Android

[RMC]

Kenne echt kein ernsthaftes Programm, welches damit läuft.

Du meinst, du kennst kein Programm das mit Mono entwickelt wurde?


Ahja, speaking of Unity...Die Unity 3D Engine setzt auf Mono.

[mapel110]

Kenne eine Firma nahe Osnabrück, die ihre Software auf Mono portiert. Ist allerdings nur ein 2-Mann-Betrieb.

[Exxtreme]

Du meinst, du kennst kein Programm das mit Mono entwickelt wurde?
Irgendwelche Spielzeug-Programme gibt es schon. Was ernsthafteres wie ein ausgewachsener Webserver ist mir nicht bekannt.

[Ganon]

Naja, da Gnome das ja mit aufgenommen hat, wird das schon irgendwer "am laufen halten", aber es stimmt schon, die Nachricht macht die Zukunft von Mono nicht gerade "sicherer".

[ESAD]

Naja, da Gnome das ja mit aufgenommen hat, wird das schon irgendwer "am laufen halten", aber es stimmt schon, die Nachricht macht die Zukunft von Mono nicht gerade "sicherer".

man müsste hald wissen wie viel interesse MS daran hat bis jetzt haben sie das projekt ja afaik auch unterstützt.

[sei laut]

Microsoft hat sich auch Patente ("geistige Vermögenswerte") von Novell 450 Millionen kosten lassen. Was da genau enthalten ist, ist noch spekulativ.

[PatkIllA]

Irgendwelche Spielzeug-Programme gibt es schon. Was ernsthafteres wie ein ausgewachsener Webserver ist mir nicht bekannt.
ist das Ziel nicht auch eher ein Programm zu entwicklen, dass sowohl unter mono als unter .NET läuft?

[Exxtreme]

ist das Ziel nicht auch eher ein Programm zu entwicklen, dass sowohl unter mono als unter .NET läuft?
MS .NET und Mono sind nicht zueinander kompatibel auch wenn sie einige Überschneidungen haben. Sprich, wenn man sich auf den kleinsten gemeinsamen Nenner konzentriert dann könnte man ein Programm schreiben, welches mit beiden Laufzeitumgebungen läuft. Und das schränkt dann schon ein. Deshalb wenn man sowas vor hat dann nimmt man gleich lieber die Java-VM. Da muss man nicht erstmal kleinste gemeinsame Nenner suchen. Und zweitens, die Java-VM hat sich schon sehr oft beweisen können, dass sie auch im Enterprise-Umfeld funktioniert. Bei Mono weiss ich das nicht. Denn mir ist wie schon geschrieben, keine ernsthaftere Anwendung bekannt.

Ich persönlich hatte ja recht viele Hoffnungen in Mono gehabt. Nur sind diese nicht erfüllt worden. Da sich die Macher recht schnell davon verabschiedeten windowsspezifisches Zeug im großen Stil einzubauen.

[PatkIllA]

Ich dachte jetzt, dass sie zumindest abseits der GUI-Frameworks von Forms und WPF doch recht kompatibel sind.
Wobei es ohne Gui auch schon ordentlich Einschränkungen gibt.

[Larucio]

Mono ist imho kein Verlust. Es gibt doch mehr als genug Programmiersprachen unter Linux/Unix. Java reicht auch aus.

[Exxtreme]

Ich dachte jetzt, dass sie zumindest abseits der GUI-Frameworks von Forms und WPF doch recht kompatibel sind.
Wobei es ohne Gui auch schon ordentlich Einschränkungen gibt.
WPF gibt es nicht für Mono und es ist auch nicht geplant, dass es reinkommt. Die haben mit Moonlight so eine Art Silverlight-Klon, welches so eine Spar-Version von WPF enthält. Und WinForms funktioniert in Mono so lala. GTK# ist nicht umsonst das Haupttoolkit dort.

Wo sie recht kompatibel sind sind die C#-Sprachfeatures und irgendwelche Server-Komponenten ala ASP.NET.

[foobi]

Das einzig "bittere" an dieser Geschichte ist, dass Novell erst übernommen werden musste, bis ihnen jemand klarmachen konnte dass man von einem toten Pferd irgendwann mal absteigen muss. Die meisten der sowieso schon wenigen bekannten Mono-basierten Programme, wie zB das erwähnte Banshee, wurden von Novell-Mitarbeiter oder mit Unterstützung Novells geschrieben. Wohl ein verzweifelter Versuch der eigenen Sprache irgendeine Praxisrelevanz zuzuschustern. Das wäre ungefähr so, als wenn ein Großteil aller Java-Programme von Sun entwickelt worden wäre.

[PatkIllA]

Das stumpfe Nachprogrammieren kann ich auch nicht nachvollziehen. Sowas wie ReactOS finde ich da irgendwie noch sinnloser. Oder warum Moonlight. Das Original hat sich (IMO zum Glück nicht durchgesetzt und stirbt hoffentlich zeitnah mit Flash aus)

[=Floi=]

java wäre aber heute nicht dort wo sie sind, wenn man schnell aufgegeben hätte. java gibt es seit 1995 und wirklich populär wurde es erst die letzten jahre, wo ram und rechenleistung in den hintergrund rückte.
Ich sehe da keinen nachteil, wenn der anfang einer neuen umgebung etwas holprig ist und man daran auch in schlechten zeiten festhällt.

ich mag es aber trotzdem nicht, weil nativer code noch immer wesentlich performanter ist. da kann man behaupten was man will, aber die praxis zeigt eben oft das gegenteil.

[Ganon]

ich mag es aber trotzdem nicht, weil nativer code noch immer wesentlich performanter ist

Und WESENTLICH unsicherer.

[Exxtreme]

java wäre aber heute nicht dort wo sie sind, wenn man schnell aufgegeben hätte. java gibt es seit 1995 und wirklich populär wurde es erst die letzten jahre, wo ram und rechenleistung in den hintergrund rückte.
Ich sehe da keinen nachteil, wenn der anfang einer neuen umgebung etwas holprig ist und man daran auch in schlechten zeiten festhällt.

ich mag es aber trotzdem nicht, weil nativer code noch immer wesentlich performanter ist. da kann man behaupten was man will, aber die praxis zeigt eben oft das gegenteil.
Java hat eigentlich nur ein Problem was die Startzeit angeht. Wenn die Chose mal laeuft dann ist Java nur bissl langsamer. Und was GUI angeht, Swing haben sie so weit verbessert, dass man eigentlich keine Unterschiede mehr merkt.

[Shink]

Kenne echt kein ernsthaftes Programm, welches damit läuft.
Was heißt für dich ernsthaft? Sims 3 verwendet z.B. Mono. Oder Second Life - wobei ich mir nicht sicher bin ob es das noch gibt.:freak:

Deshalb wenn man sowas vor hat dann nimmt man gleich lieber die Java-VM. Da muss man nicht erstmal kleinste gemeinsame Nenner suchen.
Die CIL ist genauso standardisiert wie die Java-VM und somit der kleinste gemeinsame Nenner. Wovon sprichst du?

Mono ist imho kein Verlust. Es gibt doch mehr als genug Programmiersprachen unter Linux/Unix. Java reicht auch aus.
Man kann Java in die CIL übersetzen aber C++, Visual Basic oder C# nicht in Java Bytecode. Wenn das kein Verlust ist weiß ich es auch nicht.

[Demirug]

Java hat eigentlich nur ein Problem was die Startzeit angeht. Wenn die Chose mal laeuft dann ist Java nur bissl langsamer. Und was GUI angeht, Swing haben sie so weit verbessert, dass man eigentlich keine Unterschiede mehr merkt.

Die managed Umgebungen (Java-VM und CLR/CLS) sind zum Teil schon etwas langsamer. Das kommt aber im Wesentlichen durch die zusätzlichen Sicherheitschecks die man in nativen Systemen entweder für die gleichen Laufzeitkosten selbst einbauen muss oder man geht eben das Risiko ein.

Für 24/7 Serversysteme würde ich heute auf diesen zusätzlichen Sicherheitslayer nur sehr ungerne verzichten. Zudem neigen managed Heaps auf Dauer weniger zum fragmentieren als native was verhindert das im Dauerbetrieb alles immer langsamer wird und am Ende vielleicht sogar ausfällt weil kein Addressraum/Swapfile mehr da ist.

Für Desktop Anwendungen kann man ja prinzipiell aus einer managed Anwendung eine weitgehend native erzeugen. Ich kenne entsprechende Projekte wo der CIL Bytecode nach LLVM übersetzt und dann kompiliert wird.

[Ganon]

Für 24/7 Serversysteme würde ich heute auf diesen zusätzlichen Sicherheitslayer nur sehr ungerne verzichten.

Wäre mal interessant zu wissen, ob der Angriff bei Sony auch ein Bufferoverflow war... weiß da jemand was? Soll ja eine Lücke in einer alten Apache Version gewesen sein.

[Shink]

ich mag es aber trotzdem nicht, weil nativer code noch immer wesentlich performanter ist. da kann man behaupten was man will, aber die praxis zeigt eben oft das gegenteil.
Gut, dann schaffen wir halt einfach den ganzen nicht-nativen Krempel ab wenn du ihn nicht magst: Java, .NET, sämtliche Skriptsprachen (PHP, Python, Javascript etc), HTML, SQL...
Eigentlich ist nicht einmal der x86-Assemblercode nativ auf aktuellen CPUs.

[=Floi=]

sobald mal zwei+x java programme laufen gibt es entweder fehler in der gui oder es wird alles extrem langsam. die netzwerkkommunikation ist noch immer extrem schlecht.
startet mal zB azeurus und jdownloader.
native programme laufen auch am nächsten tag noch performant und haben einfach erheblich weniger probleme mit der netzwerkkommunikaion. Ein gegenseitiges behindern ist dort auch unbekannt.

[Exxtreme]

Was heißt für dich ernsthaft? Sims 3 verwendet z.B. Mono. Oder Second Life - wobei ich mir nicht sicher bin ob es das noch gibt.:freak:

Also so viel ich weiss ist Sims 3 keine Mono-Anwendung. Sie verwenden Teile davon glaub für Scripting. Das Gleiche gilt für Second Life.

Die CIL ist genauso standardisiert wie die Java-VM und somit der kleinste gemeinsame Nenner. Wovon sprichst du?


Die reine Infrastruktur ist das eine, die Klassenbibliotheken das andere.

[Demirug]

Also so viel ich weiss ist Sims 3 keine Mono-Anwendung. Sie verwenden Teile davon glaub für Scripting.

Ja und das hat sehr spezielle Gründe.

Die reine Infrastruktur ist das eine, die Klassenbibliotheken das andere.

Ein Teil davon ist genormt. Das was aber wirklich Arbeit spart nicht.

[Shink]

native programme laufen auch am nächsten tag noch performant und haben einfach erheblich weniger probleme mit der netzwerkkommunikaion. Ein gegenseitiges behindern ist dort auch unbekannt.
Ja, und genau deswegen wird es nie möglich sein hunderte performancekritische Java-Serverinstanzen auf einem Rechner jahrelang laufen zu lassen.
Wait...:D

Die reine Infrastruktur ist das eine, die Klassenbibliotheken das andere.
Und hast du auch Einwände gegen die .NET Infrastruktur?

[Exxtreme]

Und hast du auch Einwände gegen die .NET Infrastruktur?
Ich habe gar nichts dagegen. Nur sehe ich noch eine Bytecode-VM als recht überflüssig an wenn .NET von MS und Java alles abdecken was man so braucht.

Edit: Es fallen mir nur sehr wenige Szenarien ein wo Mono vielleicht nicht schlecht wäre. Z.B. wenn man mit VB.NET unter Linux programmieren will. Nur bleibt hier die Frage ob solche Sonderwünsche den Aufwand rechtfertigen. Der Markt hat entschieden, dass das nicht zu rechtfertigen ist. Also verschwindet Mono wenn sich nicht ein anderer Investor findet. Ich würde lachen wenn Oracle da einsteigt.

[puntarenas]

Auf Planet-Gnome konnte man einen Blogbeitrag lesen, der sich bemühte Mono etwas Positives für die FOSS-Community abzugewinnen. Das Argument mag ein wenig von Hinten durch die Brust ins Auge klingen, aber immerhin:
Nevertheless, Mono should exist, for at least one important reason: some developers write lots and lots of new code on Microsoft systems in C#. If those developers decide they want to abandon Microsoft platforms tomorrow and switch to GNU/Linux, we don't want them to change their minds and decide to stay with Microsoft merely because GNU/Linux lacks a C# implementation. Obviously, I'd support convincing those developers to learn another language system so they won't write more code in C#, but initially, the lack of Free Software C# implementation might impede their switch to Free Software.Mono Developers Losing Jobs Isn't Good (http://ebb.org/bkuhn/blog/2011/05/03/mono.html)

Mal sehen, wie sich Gnome in Zukunft zu Mono stellen wird, wenn der Rauch sich gelichtet hat. Immerhin haben sie Mono geadelt, indem sie die Bibliotheken und GTK# offiziell aufgenommen haben. Novell war sicherlich nicht ganz unbeteiligt daran und erhoffte sich etwas Rückenwind für die Mono-Strategie.

[Shink]

Ich würde lachen wenn Oracle da einsteigt.
Das wäre tatsächlich recht interessant.:freak:

Das Argument mag ein wenig von Hinten durch die Brust ins Auge klingen
Naja, ich finde C# durchaus eine nette Sprache die sich etwas schneller entwickelt als Java. Und da man Java-Code für die CLI compilieren kann und umgekehrt nicht... würde ich es gerne sehen dass aus Mono etwas wird.

Wenn ich z.B. mit Eclipse und Maven so gut C# entwickeln könnte wie Java dann würde ich es mir überlegen - es sind ja durchaus Vorteile da. Wenn allerdings nur Microsoft dahinter ist wird es wohl nie dazu kommen.

Früher hielt man im GTK-Umfeld große Stücke von Mono - die Zeiten sind anscheinend vorbei.:confused:

[Exxtreme]

Auf Planet-Gnome konnte man einen Blogbeitrag lesen, der sich bemühte Mono etwas Positives für die FOSS-Community abzugewinnen. Das Argument mag ein wenig von Hinten durch die Brust ins Auge klingen, aber immerhin:
Mono Developers Losing Jobs Isn't Good (http://ebb.org/bkuhn/blog/2011/05/03/mono.html)

Mal sehen, wie sich Gnome in Zukunft zu Mono stellen wird, wenn der Rauch sich gelichtet hat. Immerhin haben sie Mono geadelt, indem sie die Bibliotheken und GTK# offiziell aufgenommen haben. Novell war sicherlich nicht ganz unbeteiligt daran und erhoffte sich etwas Rückenwind für die Mono-Strategie.
Mono tut sich in der FOSS-Community sowieso recht schwer. Die haben schlicht Angst, dass MS die Patentkeule schwingt. Und solange MS keine schriftliche Erklärung bringt was erlaubt ist und was nicht wird sich das auch nicht ändern. Und da die Mono-Macher auch noch meinten alles nachprogrammieren zu müssen was MS so brachte machte das die Sache nicht einfacher.


Mono fehlte schlicht eine Nische, die es hätte füllen können. Sie haben es am Ende mit mobilen Frameworks ala Mono Touch versucht aber da war es wohl zu spät.

[Ganon]

Wenn ich z.B. mit Eclipse und Maven so gut C# entwickeln könnte wie Java dann würde ich es mir überlegen - es sind ja durchaus Vorteile da.

Du kannst ja auf der JavaVM auch Jython, Scala oder Groovy nutzen. In Java 7 wird die Unterstützung ja weiter ausgebaut.

Aber wie du ja selbst sagst, Java hat extrem gute Frameworks und IDEs... das macht auch mit reinem Java vieles wieder wett...

Das Problem ist halt, dass man Java schlecht (bzw. kompliziert) in ein System "einbetten" kann, was sich mit JNA irgendwann ändert, vllt..

[Shink]

Du kannst ja auf der JavaVM auch Jython, Scala oder Groovy nutzen.
Aber eben kein C++, C# oder z.B. Fortran.

Ich verstehe nicht ganz warum man sich in der Welt der offenen Standards immer wieder auf wenige Sprachen beschränkt: Bisher sind C und Javascript die für mich sehr seltsamen Zwischensprachen in die z.B. C++-Compiler und Web-Toolkits seltsamerweise übersetzen und der Java-Bytecode ist ein weiterer prominenter Vertreter. Gut, das ist wenigstens eine richtige Zwischensprache aber eben eine hauptsächlich auf die Bedürfnisse von Java eingeht.

CLI als HTML5-Skriptsprache, CLI als (wahlweises?) Target vom Java-Compiler, CLI als GTK-Basis - das alles wäre ja prinzipiell kein Problem. Aber gut, hat halt nicht sollen sein.
GWT übersetzt meinen Java-Code in grässliches JavaScript, mein Browser das JavaScript in seinen eigenen Bytecode - und außerdem hat er noch seine eigene Sandbox für Plugins. Klar, das ist natürlich viel sinnvoller.

[Exxtreme]

Aber eben kein C++, C# oder z.B. Fortran.

Ich verstehe nicht ganz warum man sich in der Welt der offenen Standards immer wieder auf wenige Sprachen beschränkt: Bisher sind C und Javascript die für mich sehr seltsamen Zwischensprachen in die z.B. C++-Compiler und Web-Toolkits seltsamerweise übersetzen und der Java-Bytecode ist ein weiterer prominenter Vertreter. Gut, das ist wenigstens eine richtige Zwischensprache aber eben eine hauptsächlich auf die Bedürfnisse von Java eingeht.

CLI als HTML5-Skriptsprache, CLI als (wahlweises?) Target vom Java-Compiler, CLI als GTK-Basis - das alles wäre ja prinzipiell kein Problem. Aber gut, hat halt nicht sollen sein.
GWT übersetzt meinen Java-Code in grässliches JavaScript, mein Browser das JavaScript in seinen eigenen Bytecode - und außerdem hat er noch seine eigene Sandbox für Plugins. Klar, das ist natürlich viel sinnvoller.
Ich finde dein Posting irgendwie sehr wirr. :freak:

Im Grunde willst du eine Bytecode-Sprache für alles?

[Ganon]

Im Grunde willst du eine Bytecode-Sprache für alles?

http://www.llvm.org

:D

[Shink]

Im Grunde willst du eine Bytecode-Sprache für alles?
http://www.llvm.org

:D
Naja, die Unterscheidung LLVM-CLI/JVM kann ich ja noch halbwegs verstehen.

Dass wir heute - wie schon erwähnt - öfters Plain C oder JavaScript als Compile-Target haben weil man damit überall etwas daraus machen kann finde ich eben dämlich.

[Demirug]

Dass wir heute - wie schon erwähnt - öfters Plain C oder JavaScript als Compile-Target haben weil man damit überall etwas daraus machen kann finde ich eben dämlich.


So neu ist diese Entwicklung nun auch wieder nicht. Crosscompiler wurden schon immer eingesetzt. Wenn JavaScript kein so undankbares Target wäre hätte ich damit auch kein Problem. Es tut nur eben weh das eine Menge Information beim übersetzten von CIL nach JavaScript verloren geht welche dann die JavaScript VM durch Codeanalyse versucht wieder zu erzeugen.

Ich erwarte aber nicht das sich an der Tatsache das JavaScript die Zielsprache für HTML Anwendungen ist sich noch irgendetwas ändern wird. Entsprechend kann man nur hoffen das JavaScript besser wird.

[Exxtreme]

Dass wir heute - wie schon erwähnt - öfters Plain C oder JavaScript als Compile-Target haben weil man damit überall etwas daraus machen kann finde ich eben dämlich.
Nun ja, wenn Firmen dazu bereit sind den Produktivitätsverlust, den sie dadurch erleiden zu bezahlen dann ist das eben so. Sie müssen damit rechnen, dass sie teurer sind als die Konkurrenz, die sich diesen Hickhack nicht gibt.

Edit: Wobei JavaScript wohl den Vorteil hat relativ konkurrenzlos zu sein.

[Demirug]

Nun ja, wenn Firmen dazu bereit sind den Produktivitätsverlust, den sie dadurch erleiden zu bezahlen dann ist das eben so. Sie müssen damit rechnen, dass sie teurer sind als die Konkurrenz, die sich diesen Hickhack nicht gibt.

Ab einer gewissen Projektgröße wird die Entwicklung und Wartung in JavaScript unheimlich teuer. Ab diesem Punkt steigt die Produktivität durch den Einsatz eines Crosscompilers.

[Shink]

Ich erwarte aber nicht das sich an der Tatsache das JavaScript die Zielsprache für HTML Anwendungen ist sich noch irgendetwas ändern wird.
Für mich ist das fast schon ein HTML5-Sargnagel.
Nicht dass ich JavaScript so dämlich finde (OK, ich geb's zu - das auch;D) aber was würde man schon verlieren würde man anbieten in Bytecode zu entwickeln? Der Code würde kleiner, performanter und besser zu debuggen.

Öhm... tut mir leid, ist arg OT inzwischen. Aber wenn jetzt Leute sagen Mono haben sie noch nie leiden können weil es nicht nativ läuft und nicht standardisiert ist dann will ich darauf hinweisen dass es noch schlechter geht:freak:. Dinge wie CLI als clientseitige Browsersprache waren ja tatsächlich in Gespräch.

[Shink]

Miguel de Icaza hat eine neue Firma mit Hauptaugenmerk Mono-Entwicklung gegründet: :smile:
http://tirania.org/blog/archive/2011/May-16.html

[Exxtreme]

Schau'mer mal ob er damit mehr Erfolg haben wird. Der wird halt gucken müssen, dass diese Firma Gewinn macht.

[Ganon]

Ja, die Entwickler müssen ja auch von irgendwas leben... braucht man halt schnell Geldgeber.

[Coda]

ich mag es aber trotzdem nicht, weil nativer code noch immer wesentlich performanter ist.
Nö.

[peanball]

Dinge wie CLI als clientseitige Browsersprache waren ja tatsächlich in Gespräch.
Das letzte mal als ich nachgeschaut hab nannte sich das auf der Java-Seite "Applets"...

[Shink]

Erazor;8736525']Das letzte mal als ich nachgeschaut hab nannte sich das auf der Java-Seite "Applets"...
Nun ja; Applets sind eher der "Vorgänger von Flash" und können - wie dieses auch - die Seite nicht ändern.

[Coda]

Soweit ich weiß können Applets sehr wohl das DOM manipulieren. Ist nur ziemlich unüblich.

[Shink]

Soweit ich weiß können Applets sehr wohl das DOM manipulieren.
Wusste ich gar nicht. Ein Methodenaufruf über Reflection liefert das Document-Object... wer hat sich denn das ausgedacht?:freak:

[Exxtreme]

Witzig ist, dass diese neuen Produkte dieser Firma kein Opensource mehr sein werden.

[Exxtreme]

http://lists.ximian.com/pipermail/mono-list/2011-July/047311.html

Es geht anscheinend doch weiter. Man hat fast alle entlassenen Mono-Entwickler von Suse übernommen.