staging.inyokaproject.org

Silmaril schrieb:

Also jetzt haben mir 2 Leute versichert, dass .Net-Programme auch prinzipell auf Linux laufen. Das hab ich eigentlich auch nie bestritten. Aber warum sieht man denn eigentlich keines davon? Vielleicht weil .Net/Mono doch nicht so superduper betriebsystemübergreifend ist? Eigentlich auch egal warum, aber die Tatsache bleibt, das man mit Mono praktisch null .Net-Anwendungen zum laufen bringt.

Praktisch funktioniert das Perfekt, sonst wäre Mono irrelevant. .Net und Mono sind bytecode kompatibel und solange man keine Betriebssystem spezifischen Sachen nutzt laufen die auf beiden VMs. Davon wird gerade bei Bibliotheken auch gebrauch gemacht.

Und wenn man behauptet, dass man bei C++ später bei der Portierung mit Cygwin rumfummeln müsste, hat man mal ganz so nebenbei einfach Qt ausgeklammert 😉

Man kann Visual Studio nutzen... Es ist trotzdem ein riesen Aufwand im Vergleich zu Linux.

Das Mono und vor allem Mono-Programme vernünftig auf MacOS laufen, hab ich bei meinen Versuchen vor jetzt auch schon wieder eineinhalb Jahren nicht feststellen können. F-Spot z.B wollte nicht ohne Fehlermeldungen starten und stürzte bei der Bedienung. Außerdem: Warum eigentlich eine betriebsystemübergreifende Plattform verwenden, wenn sie eh nicht hilft? Banshee zum Beispiel ist für MacOS noch Beta und für Windows sogar noch experimentiel. Obwohl ja auf beiden Mono ja verfügbar ist.

Eine Anekdote von vor anderthalb Jahren ist in etwa so interessant für diese Diskussion wie die Rentensituation vor dem letzten Krieg wenn man über die Probleme des Generationenvertrags diskutiert.

Banshee nutzt ja auch Visual Notifications, sowas kann man unter OS X und Windows nicht machen, dementsprechend muss man dafür sorgen dass sich die Anwendung unter diesen Platformen anders verhält.

Wenn man so argumentiert kann ich dir auch beweisen das Python nicht platformunabhängig ist.

Die Platformunabhängigkeit, obwohl nett zu haben, ist aber erstmal irrelevant. C# ist eine gute angenehme Sprache mit einem großen Ecosystem und mit sehr guten Anbindungen an die für Gnome Anwendungen relevanten Bibliotheken.

Damit bekomm ich eine schnellere Entwicklungszeit als wenn ich mich mit C beschäftige und muss mich nicht mit irgendwelchen grausamen APIs herumschlagen wie ich es bei Python machen müsste.

burli schrieb:

Was wohl oft daran liegt, dass man von Windows Programme nur fertige Installer bekommt. Ich habe gerade mal nach den Sourcen für Paint.NET gesucht. Mal schauen, ob man das irgendwie zum Laufen bekommt. Sieht aber eher schlecht aus. Die meisten .NET Programme werden einfach für .NET geschrieben und nicht auf Kompatibilität geachtet. 100% identisch ist Mono halt doch nicht

Es gab mal einen Beitrag dazu im Planeten vor längerem Paint Mono… Paint.NET für Linux. Fazit:

Paint Mono ist SEHR langsam, brauchbar zeichnen lässt sich selbst auf leistungsstarken Rechner damit nicht.

Kannst das ja mal testen ob sich da was gebessert hat.

Übrigens, es gibt genug Windows-Benutzer die NET ablehnen und das garantiert nicht weil sie Microsoft-Produkte ablehnen oder wegen irgendwelcher Patente. Wenn NET so toll wäre, wäre es nicht in der Windows-Welt so umstritten.

der_alex1980 schrieb:

Ich glaube zwar keinem Benchmark, den ich nicht selbst gefälscht habe, aber so langsam scheint Mono allgemein nicht zu sein:

Mono vs. Python 3

Mono vs. CPython

Mono vs. Perl

Mono vs. Java (hier schneidet Java besser ab)

Dass Python oder Perl schlechter abschneiden ist logisch. Beides sind interpretierte Sprachen, Java und Mono haben einen Jit. Außerdem ist Python dynamisch typisiert (Duck Typing). Das bremst zusätzlich.

Bei den Vergleichen sind vor allem die Vergleiche bei den Codezeilen interessant. Bei Python braucht man nur einen Bruchteil an Codezeilen. Bei reverse-complement braucht C++ 2275 Zeilen, C 1867, Java 592 und Python 322 Zeilen. C# braucht 1099. Und da liegt der eigentliche Vorteil von C#, Python oder Java gegenüber C und C++. Weniger Programmcode. Und weniger Programmcode bedeutet weniger Entwicklungszeit und weniger Fehlerquellen. Wobei C# und Java hier noch nicht so starke Vorteile haben. Hier ist eindeutig Python im Vorteil.

Die interessantere Frage ist doch, was Mono für Entwickler bringt und da wurden ja schon einige Punkte genannt. Einige gute Programmiersprachen, eine umfangreiche Klassenbibliothek und eine gute IDE.

Mich interessiert ja Boo. Eine Python ähnliche Sprache, aber wahlweise dynamisch oder statisch typisiert. Leider ein relativ kleines Projekt mit entsprechend wenig Dokumentation

Vegeta schrieb:

Es gab mal einen Beitrag dazu im Planeten vor längerem Paint Mono… Paint.NET für Linux. Fazit:

Paint Mono ist SEHR langsam, brauchbar zeichnen lässt sich selbst auf leistungsstarken Rechner damit nicht.

Kannst das ja mal testen ob sich da was gebessert hat.

Bei Gelegenheit. Wobei ich hier, wie weiter oben erwähnt, das Handycap einer relativ alten Mono Version habe. In Mono 2.8 und 2.10 gab es jeweils nochmal Performance Verbesserungen. Wenn man mit Mono arbeiten will müsste man fast zu openSuse oder RedHat wechseln. Selbst OSX und Windows werden besser bedient als Debian Systeme.

Übrigens, es gibt genug Windows-Benutzer die NET ablehnen und das garantiert nicht weil sie Microsoft-Produkte ablehnen oder wegen irgendwelcher Patente. Wenn NET so toll wäre, wäre es nicht in der Windows-Welt so umstritten.

Was oft daran liegt, dass man ein dickes Softwarepaket installieren muss, manchmal nur für ein kleines Popel Programm. Java ist als notwendiges Übel halbwegs aktzeptiert, aber NOCH so einen Klops installieren wollen viele halt nicht mehr.

Wobei ich nicht weiß, ob Vista oder Win7 .NET nicht inzwischen standardmäßig enthalten. Wie der_alex1980 schrieb, dem User ist die Programmiersprache eigentlich egal. Die eigentliche Hemmschwelle ist der Download einer dicken Runtime Umgebung. Und bei .NET war es anfangs ja noch schlimmer, weil man oft .NET 1.1 und .NET 2.0 parallel installieren musste. Wie es inzwischen ist weiß ich nicht

Silmaril schrieb:

Also jetzt haben mir 2 Leute versichert, dass .Net-Programme auch prinzipell auf Linux laufen. Das hab ich eigentlich auch nie bestritten. Aber warum sieht man denn eigentlich keines davon? Vielleicht weil .Net/Mono doch nicht so superduper betriebsystemübergreifend ist?

Du verwechselst Plattformunabhängigkeit mit Kompatibilität. .NET und Mono sind unterschiedliche Laufzeitumgebungen, die begrenzt kompatibel zueinander sind, genau wie die Oracle JRE und Kaffee begrenzt kompatibel zueinander sind.

Zum Thema Plattformunabhängigkeit habe ich schon auf der ersten Seite was geschrieben. Das Ziel von Mono ist nicht, möglichst plattformunabhängig zu sein, sondern eine gute Balance zwischen Plattformunabhängigkeit- und Integration zu bieten. Plattformunabhängiges Programmieren unter Mono erfordert etwas mehr Planung als beispielsweise unter Java (in .NET sogar noch mehr, da Mono nur eine Teilmenge von .NET ist), dafür macht es Mono dem Programmierer leichter betriebssystemspezifische Funktionalität zu nutzen, zum Beispiel D-BUS, die verschiedenen Indicator Systeme oder Adressbuch APIs, die es so gibt, ohne den ganzen Code mit #ifdef WIN32 , #elseif LINUX Makros zu vollzuspicken, wie man das unter C / C++ machen würde.

Banshee läuft (noch) nicht auf Windows, weil es eben vorwiegend für die Gnome Plattform entwickelt wurde und nicht, weil plattformübergreifendes Programmieren unter Mono nicht möglich wäre. Analoges gilt für .NET Programme, die nicht unter Mono laufen.

Ein Mono Programm, das auf Windows, Linux und Mac läuft ist zum Beispiel Pinta.

burli schrieb:

Wobei ich nicht weiß, ob Vista oder Win7 .NET nicht inzwischen standardmäßig enthalten.

Ich glaube, ab Vista ist .NET standardmäßig enthalten und ich behaupte mal, ein Großteil der Windowsanwender weiß gar nicht, ob ein Programm auf .NET läuft oder nicht.

ein e reicht

http://de.wikipedia.org/wiki/Kaffe

Vegeta schrieb:

Ich habe noch nie ein schnelles Java-Programm gesehen, weswegen ich da sogar noch einen größeren Bogen rum mache. Leider gibts für JDownloader keine Alternative, der braucht auf meiner alten Kiste mit 1GB RAM ca. 5-10 Sekunden zum Starten und ist von der Bedienung sehr träge.

Schon mal was von pyLoad gehört? http://pyload.org/de:start

Vegeta schrieb:

burli schrieb:

Du kannst den Programmumfang und den damit einher gehenden Mehrkosten an Ressourcen aber nicht der Programmiersprache anlasten. Man kann mit Mono sicher ein zu deinem identischen Programm schreiben, das dann ähnlich schnell startet und nur unwesentlich mehr Speicher braucht als deins.

Das bezweifle ich, eben weil neben dem Programm die Runtime Library geladen werden muss. So was müssen herkömmliche Programme nicht.

Wenn dein Qt Programm unter Gnome startet und kein anderes Qt Programm gestartet ist müssen die Qt Libs auch erstmal geladen werden, und das dauert auch. Unter KDE ist das natürlich kein Problem.

Vegeta schrieb:

burli schrieb:

Ich finde, 2-3 Sekunden Startzeit ist absolut im Rahmen.

Da hat jeder andere Präferenzen. 😉 Der eine möchte ein kleines Programm was nur die nötigsten Funktionen besitzt, andere benutzen lieber eine überfrachtete Anwendung, kennt noch jemand ACDSee?

Ich glaube, viele unterliegen dem gleichen Fehler wie du und vergleichen Äpfel mit Birnen. Ja, dein Programm startet schneller als Tomboy, aber bring deinem Programm zum Beispiel mal Plugins bei, die geladen werden sollen, Syntaxprüfung, Verlinkung zwischen den Notizen, Hervorhebung von WikiWords, Synchronisation mit WebDav, UbuntuOne oder ähnlichem usw.

Also die genannten Funktionen ließen sich ohne sehr großen Aufwand einbauen, bis auf die Synchronisation, da müsste man erst schauen wie das im Detail funktioniert und ich bin mir sicher, dass mein Programm immer noch deutlich schneller laden würde. 😉

Das will ich sehen, wie man mal eben ein komplettes Plugin System implementiert.

BodomBeachTerror schrieb:

Schon mal was von pyLoad gehört? http://pyload.org/de:start

Kenne ich, die sind aber noch meilenweit von JDownloader entfernt und bei der Geschwindigkeit werden sie ihn wohl auch nie einholen.

Wenn dein Qt Programm unter Gnome startet und kein anderes Qt Programm gestartet ist müssen die Qt Libs auch erstmal geladen werden, und das dauert auch. Unter KDE ist das natürlich kein Problem.

Das ändert aber nichts daran, dass myNotes selbst beim Erststart nur mit minimaler Verzögerung startet und nicht wie Tomboy mehrere Sekunden braucht.

Das will ich sehen, wie man mal eben ein komplettes Plugin System implementiert.

Wieso müsste ich ein Plug-In-System implementieren, um die paar Features nachzurüsten? Es gibt ja gerade mal 6 Plug-ins um das Programm minimal aufzupeppen. Tomboy ist zwar vorinstalliert hat aber kaum Funktionen, man kann nicht mal Bilder einfügen in die Notizen und es stellt auch nur sehr begrenzte Textformatierungen zur Verfügung.

Vegeta schrieb:

BodomBeachTerror schrieb:

Das will ich sehen, wie man mal eben ein komplettes Plugin System implementiert.

Wieso müsste ich ein Plug-In-System implementieren, um die paar Features nachzurüsten? Es gibt ja gerade mal 6 Plug-ins um das Programm minimal aufzupeppen. Tomboy ist zwar vorinstalliert hat aber kaum Funktionen, man kann nicht mal Bilder einfügen in die Notizen und es stellt auch nur sehr begrenzte Textformatierungen zur Verfügung.

Naja, es ging ja darum, dass Tomboy auch Plugins beim Starten lädt. Natürlich kann man die Features von den Plugins einfach nachrüsten, aber das Feature von Tomboy ist eben das man auch Plugins entwickeln kann.

BodomBeachTerror schrieb:

Naja, es ging ja darum, dass Tomboy auch Plugins beim Starten lädt. Natürlich kann man die Features von den Plugins einfach nachrüsten, aber das Feature von Tomboy ist eben das man auch Plugins entwickeln kann.

Ja da hast du Recht, da habe ich mich missverständlich ausgedrückt. Ich meinte an der Stelle die fehlenden Features einbauen und damit nicht das Plug-In-System an sich.