dass das nicht wirklich frei sei. Damals war Qt "nur" GPL.
Jetzt ist das sogar LGPL.
Wenn sich die Gnome da mal nicht selbst widersprechen.
PS: Ich programmiere noch immer am liebsten in C++. Für Java oder C# sehe ich nicht wirklich einen Grund, denn Qt Programmierung in C++ ist elegant und man braucht lange nicht alle Features von C++. Wenn es aber mal darauf ankommt, stehen Die aber zur Verfügung. Und performanter ist das alle mal. Und wie sieht das in anderen Sprachen mit der Unterstützung von Mehrkernsystemen aus ? http://de.wikipedia.org/wiki/OpenMP
>>Damals war Qt "nur" GPL. Falsch, damals war Qt unter einer Lizenz die zwar einsicht in den Quellcode erlaubte, aber nicht dessen modifizierung. Und alle Teile des Mono Projekts stehen entweder unter X11, GPL oder LPGL.
Ich finde C++/Qt auch gut, aber realistisch gesehen sind Sprachen wie Java/Scala oder auch C# in einigen Dingen deutlich komfortabler als C++. Ein Garbage Collector ist schon nicht schlecht. Und Scopes sind kein Garbage Collector. Smart Pointer bieten eine Teillösung (allerdings funktionieren sie nicht bei zirkulären Referenzen). Was Multithreading angeht ist sowas wie das Actor-Model von Scala schon ein großer Fortschritt gegenüber C++. Und was Plattformunabhängigkeit angeht hat Java auch Vorteile, das Binary läuft halt überall.
Ich beginne gerade mit C++/Qt, finds genial. Ursprünglich hab ich mich nicht an C++ gewöhnen wollen, aber für Pascal/Delphi unter Linux gibts keine Software (ja, schon eine IDE, Lazarus, aber keine Softwaregrundlage - niemand proggrammiert damit mehr) - aber so unterschiedlich sind C++ und Pascal gar nicht. Qt ist halt zu lernen, aber das ist wie gesagt echt angenehm, ud dank QtCreator gibts auch eine echt gute IDE dafür.
Ich kann mich weder mit C# anfreunden (nur GTK bindings gut, qymono verwendet niemand, keine IDE, etc.), noch mit Java (kotz), und schon gar nicht mit reinem C. Es ist mir ein Greuel, dass GTK+GNOME in C programmiert sind, sowas WILL ich gar nicht lernen. C'/GTK+ bindings sind unter Monodevelop zwar easy zu nutzen - aber ehrlich: warten wir noch ein Jahr, dann ist KDE4 so stabil wie es 3.5.10 war, und dann kann sich GNOME und GTK echt schleichen.
Ich kann mich weder mit C# anfreunden (nur GTK bindings gut, qymono verwendet niemand, keine IDE, etc.), noch mit Java (kotz), und schon gar nicht mit reinem C. Es ist mir ein Greuel, dass GTK+GNOME in C programmiert sind, sowas WILL ich gar nicht lernen.
Welche Grundschüler haben wohl schon mit Delphi Programmiert?
QT ist wirklich angenehm zu programmieren! Schon mal selbst probiert?
Bei OSS (Open Source Software) ist es egal ob das Programm auf allen Platformen läuft, denn man kann es auf allen Plattformen compilieren. So etwas wie Bytecode von Java ist nur notwendig, wenn man den Quellcode unter Verschluss halten möchte.
"aber ehrlich: warten wir noch ein Jahr, dann ist KDE4 so stabil wie es 3.5.10 war, und dann kann sich GNOME und GTK echt schleichen."
es wird weiterhin leute geben die nicht alle paar irgendwas einen derartigen umbruch miterleben wollen... und weiterhin auch leute die auf bildschirmlange kontextmenüs und einstellungsdialoge verzichten können...
aber ehrlich: warten wir noch ein Jahr, dann ist KDE4 so stabil wie es 3.5.10 war, und dann kann sich GNOME und GTK echt schleichen.
LOL!!! Falls KDE 4 wirklich in einem Jahr stabil sein sollte (was ich sehr bezweifle!), wird das der Zeitpunkt sein, wo die neueste Bastelversion KDE 5.0 freigegeben und jeglicher Support für KDE 4 eingestellt wird - schließlich braucht man die knappen Ressourcen ja für Innovationen.
I have a dream that one day people will stop "GUI-Bashing". I have a dream that one day Gnome-, KDE-, Xfce-, Fluxbox- and LXDE-Users will coexist in peace and harmony. I have a dream, today.
Ursprünglich hab ich mich nicht an C++ gewöhnen wollen, aber für Pascal/Delphi unter Linux gibts keine Software (ja, schon eine IDE, Lazarus, aber keine Softwaregrundlage - niemand proggrammiert damit mehr)
Moment mal, Free Pascal ist nun wirklich alles andere als tot. Wenn man nicht gerade systemnah programmieren will, sehe ich keinen Grund C einzusetzen. Und was die Geschwindigkeit beim kompilieren und bei der Ausführung angeht kommt FP mit dem gcc ganz gut mit.
QT/C++ ist C++ mit Kuschelfaktor, so macht das auch Spass. Genauso wie c#, nur mit dem besseren toolkit. C++ ohne Seil ist dagegen gefährlich, hin und wieder semmelt der Laden ab.
OpenMP für die GUI? Was lässt sich da denn parallelisieren? Multithreading ist natürlich möglich und sollte auch genutzt werden, um die GUI nicht zu blockieren, ist aber in diesem Fall kein OpenMP-Thema. Wer OpenMP-ähnliche Anweisungen für Multithreading braucht, kann ja JOMP nehmen.
> OpenMP für die GUI? > Was lässt sich da denn parallelisieren? > Multithreading ist natürlich möglich und sollte auch genutzt werden, um die GUI nicht zu blockieren, > ist aber in diesem Fall kein OpenMP-Thema. Bei Client/Server Anwendungen mit GUI genügt es ja extra Threads zur Überwachung der Netzwerk Sockets zu haben. Mit signal/slot (in Qt) kann man das dann sehr effizient an das GUI geben.
Ich denke aber, dass es wesentlich effizienter ist EINE Programmiersprache RICHTIG zu können, als viele Programmiersprachen ein BISCHEN. Deshalb spricht für mich nichts gegen C++, erst Recht wenn wir dann doch zu OpenMP kommen. Warum sollen Client und Server in verschiedenen Programmiersprachen realisiert werden ?
> Bei Client/Server Anwendungen mit GUI genügt es ja extra Threads zur Überwachung der Netzwerk Sockets zu haben. Und dafür nimmt man nicht OpenMP. ;-)
> Ich denke aber, dass es wesentlich effizienter ist EINE Programmiersprache RICHTIG zu können, als viele Programmiersprachen ein BISCHEN. Programmierer sind meist Spezialisten auf einem bestimmten Gebiet und deshalb ist der Punkt hier irrelevant. Ich kenne jedenfalls keine Entwickler von GUI- oder Web-Anwendungen, die gleichzeitig Compiler entwerfen und/oder die Laufzeit von Algorithmen auf Parallelrechnern optimieren.
> Deshalb spricht für mich nichts gegen C++, erst Recht wenn wir dann doch zu OpenMP kommen. OpenMP ist nur eine Compiler-API und alles, was mit OpenMP geht, geht auch ohne. Wie ich schon geschrieben hab, gibts auch ne Möglichkeit, in Java Kommentare analog zu OpenMP zu verwenden, was dann in Java-Threads übersetzt wird.
> Warum sollen Client und Server in verschiedenen Programmiersprachen realisiert werden ? Weil man dann die für den jeweiligen Einsatzzweck geeignete Sprache verwenden kann.
> PS: Qt ist nicht "nur" GUI Wer benutzt denn Qt auf Parallelrechnern?
Gehen Sie zurück auf Los ... gehen Sie direkt dort hin und ziehen Sie keine 4000 DM ein ...
Das alles erinnert mich extrem an die QT / KDE Diskussion vor ein paar Jahren. Und wen interessiert das heute noch ?
Seid doch froh, dass es endlich eine vernünftige Programmiersprache und Entwicklungsumgebung für Linux gibt, ansonsten bleibt einen doch nur noch Oracle (formerly known as SUN, und da soll mir mal einer verraten in wie weit die besser sind als Microsoft) oder C++, und mal ehrlich, wer will denn heute noch C++ programmieren ?!?? Was glaubt Ihr denn, warum Miguel de Icaza das macht ? Ganz einfach, weil er das volle Elend der C(++) Entwicklung bei Gnome erlebt hat, und sieht wohin sowas führt.
Also wenn ich jemals was unter Linux entwickle, dann auf jeden Fall in C#, weil es einfach eine der angenehmsten Programmiersprachen zur Zeit auf dem Markt ist. Und die Windoof Entwickler, die man dadurch dazugewinnt, sind mit Sicherheit ein paar kleine Patentstreitigkeiten wert. Außerdem, wen soll MS denn verklagen ? Die Free Software Foundation ? Jeden Enduser einzeln ? Mono wird ja von Novell entwickelt, und die haben ja einen entsprechenden Vertrag mit MS abgeschlossen, der genau sowas verhindert.
Also, Fazit, bitte bitte endlich aufhören auf Mono rumzuhacken, wer kein Mono haben will kann sich ja Debian oder Fedora installieren und weiter XMMS und XTerm benutzen anstatt Banshee und Gnome-Do, aber ICH KANNS NICHT MEHR HÖREN !!!!!
Also wenn ich jemals was unter Linux entwickle, dann auf jeden Fall in C#, weil es einfach eine der angenehmsten Programmiersprachen zur Zeit auf dem Markt ist.
Von Anonymer Feigling am Fr, 3. Juli 2009 um 02:28 #
Nicht generell, schau dir mal die Benchmarks von SBCL an: ein wenig langsamer als Java (defür weniger Speicherverbrauch), schneller als C# und F# die beide statisch typisiert sind - im Gegensatz zu Common Lisp.
Such dochmal nach Benchmarks rund um Hotspot, gibt so viele statisch und nicht statisch typisierte Sprachen für die JVM, dass man schön vergleichen kann. Clojure z.B. ist praktisch genauso schnell wie Java. Nun hat Java vielleicht nicht die beste statische Typisierung, aber ich will eigentlich auch nur sagen, dass das Thema überwertet ist.
Angenehm. Da muss ich mal Lisp einwerfen. Interpretierend & inkrementell compilierend. dynamisch als auch statische Typisierung moeglich ... objektorientierte, funktionale, imperative Programmierung .... lambdas, closures, makros, ....
Von Christopher Roy Bratusek am Sa, 4. Juli 2009 um 20:21 #
>> Was jetzt? >> Common Lisp oder Scheme?
Rep.
>> Und warum?
Weil das viel besser klingt als Lisp (erinnert mich immer an Lipfinity, diesen Scheiss Mascara dessen Werbung mich immer so langweilt, als ob die Frauen da jetzt Torpedos stationieren würden, voll aufgebauscht.) und Mono (Mono = Einfalt). Und außerdem will man ja aus der Masse herausstechen und was können, wofür es nicht mal 'ne vollständige Dokumentation gibt ^_^;
Als nicht-lisp dann Python. Weils Idiotensicher ist.
die SUN war besser, denn sie hat uns Java als Community-Prozess und GPL-Code vermacht. Sie hat sich StarOffice gekauft und unter GPL gestellt. Sie hat Solaris unter CDDL gestellt (und dann GPL?). Mein Gott, sie hat sogar ihre CPU-Designs unter GPL gestellt.
Die SUN ist ein wichtiger Freund, den wir verloren haben.
Bei KDE/Qt haben sich die Fakten geändert, deshalb interessiert das heute Niemand mehr. Anfangs durfte man wegen der "non-commercial, do not modify" Qt-Lizenz keine KDE-Binaries vertreiben, weil man schlicht keine Lizenz dazu hatte, dies mit dem GPL-Code von KDE und seinen Libraries zu kombinieren. Zum Glück ist das lange her, dann wurde Qt/X11 unter GPL gestellt. Und zuletzt ja sogar unter LGPL und für Änderungen durch alle im Rahmen des Projektes selbst geöffnet.
Und zu C# gibt es genug Alternativen, die keinen Unsinn nach sich ziehen, wie etwa Vala.
Den Vertrag von Novell mit Microsoft kennst Du nicht gut genug. Der schützt nur Novell und nicht-kommerzielle openSUSE-Entwickler, die ihre Software in openSUSE veröffentlichen. Das reicht nicht besonders weit.
Zu Mono teile ich die Meinung, dass man sie machen lassen sollte. Ich sehe nicht, warum sie erfolgreicher werden sollten als die Java-Jungs. Es wird aus meiner Sicht aber Zeit, dass die C-Gemeinde um Gnome sich um die Attraktivität der Plattform bemüht.
Etwas wie Vala wäre ohne Mono nicht gekommen und da muss man Microsoft danken. Es hat nicht viel mit Mono zu tun, aber addressiert die Bedenken der C-Gemeinde gegen C++ mit einer modernen Sprache, die von C# inspiriert ist, aber wohl gesünder ist.
Selbst unter Windows habe ich keine .NET Programme gesehen, ausser als ich noch auf meinem Gaming-PC ATI hatte. Wieso sollte es gerade unter Linux plötzlich auch nur signifikant viele Mono-Programme geben?!
> Ich sehe nicht, warum sie erfolgreicher werden sollten als die Java-Jungs.
Warum siehst du das nicht ein? Hinter Mono steht eine aktive Entwicklung welche sich auch speziell auf den Linux Desktop konzentriert. Mono bietet sich den Entwicklern mit gut gewarteten und weiterentwickelten Bindings an, und wirbt um den Anwender mit interessanten "Beispielapplikationen".
Bei Java hat sich seit es OSS wurde in der Richtung nicht viel getan. Immer noch wenig attraktive Native Bindings, und eine Hand von Multiplattform Anwendungen welche sich nicht wirklich in den Linux Desktop integrieren.
> wie etwa Vala.
Mit Vala trägt man meine Meinung die Kirche ums Kreuz. Am entwickelt eine neue Sprache rund um eine über 10 Jahre alte Library, für einen Einzelnen Desktop. Es bügelt zwar einige Problem aus welche man unter C/gobject hat, hat aber nichts wirklich überzeugendes. Dass dieses Konzept bei Entwicklern ankommt sehe ich nicht. Die wenigsten werden sich "mal eben" eine neue Sprache aneignen nur um ein GUI für ein Desktop zu entwickeln. Projekte welche auf Vala aufbauen schneiden sich selbst eine Menge von potenziellen Entwicklern ab.
Weit aus mehr Sinn würde es meiner Meinung machen vorhandene Sprachen besser zu Unterstützen. Würde man mehr Wert saubere, aktuelle und gut Dokumentierte C++, Java und Python Bindings legen, wäre das für die Masse von potenziellen Entwicklern deutlich insteressanter.
Am entwickelt eine neue Sprache rund um eine über 10 Jahre alte Library
Was soll uns das denn sagen? GObject existiert seit 7 Jahren. .NET ist genauso alt. Andere Libraries (Qt z.B. 1991 begonnen) sind älter. Die Java-Class-Library ist 14 Jahre alt.
Am entwickelt eine neue Sprache rund um eine über 10 Jahre alte Library, für einen Einzelnen Desktop.
Vala ist plattformunabhängig und kann C-Bibliotheken binden.
Die wenigsten werden sich "mal eben" eine neue Sprache aneignen nur um ein GUI für ein Desktop zu entwickeln.
Da muss man nicht viel lernen. Wer C# oder auch Java kennt kann sich Vala innerhalb kürzester Zeit aneignen, lesen sowieso von Anfang an. Und das machen auch nicht wenige Entwickler, wenn man mal in die Mailingliste oder den IRC-Channel guckt.
Weit aus mehr Sinn würde es meiner Meinung machen vorhandene Sprachen besser zu Unterstützen.
Wird ja auch gemacht, Stichwort GObjectIntrospection.
Da muss man nicht viel lernen. Wer C# oder auch Java kennt kann sich Vala innerhalb kürzester Zeit aneignen, lesen sowieso von Anfang an. Und das machen auch nicht wenige Entwickler, wenn man mal in die Mailingliste oder den IRC-Channel guckt.
Hat Vala einen Garbage Collector? Sind Funktionen in Vala First-Class Objekte, daher kann ich eine Funktion an eine Methode übergeben und zurückgeben (das man das in C mit Funktionspointern kann, weiß ich, das meine ich aber nicht). Wie schauts mit Closures und Lamda-Funktionen aus? Gibt es immutable Datentypen? Wie schauts mit einer IDE/einem Debugger aus? Springt der Debugger an die richtige Stelle im Vala Code?
Automatische Speicherverwaltung über Reference Counting.
Sind Funktionen in Vala First-Class Objekte, daher kann ich eine Funktion an eine Methode übergeben und zurückgeben (das man das in C mit Funktionspointern kann, weiß ich, das meine ich aber nicht).
Ja, wie in C# sind das Delegates.
Wie schauts mit Closures und Lamda-Funktionen aus?
Lambdafunktionen gibt es, haben aber noch keine vollständige Closure-Funktionalität (Kontext wird nicht mit eingeschlossen). Das soll angeblich aber noch geplant sein.
Gibt es immutable Datentypen?
Strings sind beispielsweise immutable. Objekte kannst du immer immutable machen, indem du nur konstante Felder hast.
Wie schauts mit einer IDE/einem Debugger aus? Springt der Debugger an die richtige Stelle im Vala Code?
Da kann man gdb verwenden oder ein grafisches Frontend dafür wie Nemiver. Wenn man ein Programm mit der Option -g kompiliert, dann werden die Zeilennummern des Vala-Sourcecodes verwendet. Zu IDEs gibt es verschiedene Projekte (Integration in bestehende IDEs wie Anjuta, MonoDevelop oder Eclipse, gedit-Plugins oder ein eigene Vala-IDE) manche mehr, manche weniger weit fortgeschritten.
danke, dass ihr da übernommen habt. Das schockierende an den Nachfragen ist doch, dass die "Leute" irgendwie denken, dass C# ein Monopol auf neuartiges C hat.
Wer findet, dass C oder C++ nicht produktiv sind, oder obsolet, und nicht gleich auf Python wechselt, der kann jetzt halt Vala nehmen und weiter native Programme erstellen.
Da also - aus technischen Gründen - Mono nicht attraktiver als libwine ist, also garnicht, gehe ich davon aus, dass Nichts besonderes mehr dabei rauskommen dürfte.
Damit wurde die Mono-Gefahr gebannt, bevor sie richtig Fahrt aufnehmen konnte, und jetzt streiten wir uns halt nur noch darüber, und bald ist das vergessen.
Man darf dabei aber nicht vergessen, dass die Praxis sich längst anders entschieden hat. Wir zum Beispiel geben ja zu unseren Geräten auch Softwarebibliotheken zur Ansteuerung mit heraus. Was mit einer einfachen C++-API begann, gibt es inzwischen auch für C, .NET und Python.
Neulich im Gespräch mit unserem Produktmanagement wurde klar: In der Industrie wird C# als der "logische Nachfolger" für C und C++ angesehen. Java als Alternative wird praktisch nicht wahrgenommen.
Das kann man gut oder schlecht finden, aber man sollte es zur Kenntnis nehmen. Und wenn man für freie Betriebssysteme gern daran partizipieren möchte und sich nicht ins Abseits stellen, dann braucht man Mono, das ist doch völlig klar.
> ICH KANNS NICHT MEHR HÖREN !!!!! So ein wenig Freiheit, in der diverse Leute diverse Meinungen zum Besten geben ist schon scheiße was? Gut das da mal jemand zwischenschreit! Sry für OT aber der wollte raus.
Was da bisher an Mono-Anwendungen herausgekommen ist, hat z.B. im KDE-Bereich null Chance. Dort braucht niemand Mono, die "eigenen" KDE-Anwendungen sind durchweg gleichwertig oder meist sogar besser.
Was ist mit Beagle? Bei meinem letzten Test von Strigi, der allerdings schon einige Zeit zurückliegt, wurden viel weniger Formate unterstützt. Es hat schon nen Grund, dass openSUSE Kerry als Beagle-Frontend entwickelt hat.
Das mag sein. Kerry/Beagle sind aber so ressourcenfressend, dass ich unter openSuse die Installation nicht mehr erlaube. Beagle ist in dieser einen Hinsicht IMHO eine völlige "Fehlkonstruktion". Ubuntu und Debian verwenden Beagle deshalb erst gar nicht in der Standardinstallation. Jede noch so einfache, schnelle, ressourcensparende Desktopsuche a la BeOS oder auch Windows98 ist da vorzuziehen.
Naja, wenn sie nichts findet, weil sie z.B. KWord-Dokumente oder Ogg-Vorbis-Dateien gar nicht indizieren kann, kann man gleich auf eine solche Desktopsuche verzichten. Mit Beagle hatte ich übrigens kein Problem. Das indizierte auch nur, wenn der Rechner mal nix zu tun hatte und im Akkubetrieb schon mal gar nicht.
Jeder soll doch benutzen, was er möchte. Wo ist das Problem? Manchmal wird ja auch herumgemeckert, wenn man den VLC oder MPlayer unter Linux benutzt. Wo liegt - im Hinblick auf eine mögliche Patentverletzung - der Unterschied zwischen Mono-Software und einem nicht-kastrierten VLC oder MPlayer?
Sicher, Banshee kann Xmms immer noch nicht das Wasser reichen und xterm ist an Effektivität kaum zu überbieten. Mono hat halt noch einen weiten Weg vor sich.
> Ganz einfach, weil er das volle Elend der C(++) Entwicklung bei Gnome erlebt hat, und sieht wohin sowas führt.
Du kannst doch C nicht mit C++ gleichsetzen. Ausserdem tust du so als haette Icaza die Weissheit mit Leoffeln gefressen. Und das ist ganz sicher nicht der Fall denn dann haette er sich nicht ausgerechnet fuer eine MSFT Technologie entschieden.
Oder er ist einfach nur gekauft.
C++ zusammen mit Qt ist ungeschlagen fuer Desktops Apps. Da kann weder Java noch C#/Mono/.Net gegen anstinken.
> Und die Windoof Entwickler, die man dadurch dazugewinnt, sind mit Sicherheit ein paar kleine Patentstreitigkeiten wert. Auaua... das tut ja beim lesen weh!! Wie kann man so einen Schwachsinn erzaehlen!?!
Also bei Debian ist es nicht default drin, soweit sehe ich kein Probleme mit Patenklagen und so weiter. Zudem ist Debian ein freies Projekt und wenn man es verklagt kann man wenig gewinnen, eher nur verlieren.
Bei Ubuntu tut man es rein, weil man meint es sei keine Gefahr von MS zu befürchten. Passiert nichts: Alles in Butter. Passiert was: Mono fliegt sofort raus, Canonical wird vielleicht verklagt, verliert vielleicht vor Gericht und bekommt eine Milliardenstrafe. Canonical hat nicht die Mrd., geht in Konkurs, ist weg. Was ist dann passiert? Nichts, morgen tritt jemand anders (Projekt, Firma) an deren Stelle.
Was bedeutet das für mich? Nichts, es weiß nicht mal jemand, daß es mich gibt und daß ich Mono-Software habe (ätsch, stimmt gar nicht, hab gar keine Mono-Software). Juckt mich also auch alles nicht.
Jedem anderen geht es genauso. Also warum aufregen? Debian weiß, was es tut. Ubuntu weiß es auch.
Wenn, wie in deinem Beispiel Canonical verklagt wird wegen Mono, wird niemand kommen und das Projekt fortsetzen, weil niemand verklaght werden möchte. Die User@home interessierts nicht, da kann MS auch nicht viel machen. Aber wer bitte soll GNU/Linux anbieten, wenn Klagen über ihnen schweben? Und wenn zuviel zeuch in Mono geschrieben ist und sich etabliert hat, dann wirds eng, und dann wird sicher auch einiges pöhsartiges aus Redmond kommen.
Das Projekt "Ubuntu" als solches wird man vielleicht nicht direkt unter diesem Namen fortsetzen, aber es gibt unglaublich viele *Buntu-Nutzer. Irgendwelche davon werden ein neues Projekt starten und alles was da war übernehmen inklusive Launchpad (wenn es mal frei sein sollte) usw.; natürlich würde man die inkriminierten Teile auf Mono basierend weglassen. Linux wird wie jetzt weiterhin von Firmen (dann halt Oracle, Red Hat, IBM usw.) und freien Projekten (Debian, Gentoo usw.) angeboten. Wenn sehr viel Zeuch in Mono basierend geschrieben wurde ist der Impact natürlich da, weil man viel ersetzen muß. Aber es gibt genug Auswahl und daß Mono auf einmal die überwiegende Zahl der Applikationen umfasst ist nicht zu befürchten. Die Situation ist letztlich auch keine andere als im Fall SCO. Natürlich ist klar, daß bei steigender Verbreitung von Linux + Mono die Motivation in Redmond wächst dieses Druckmittel zu nutzen. Das gilt aber für die Situation mit und ohne Mono. Microsoft (und andere Firmen) hat ein riesiges Portfolio an Patenten, die müssen nicht zwangsläufig nur auf Mono abzielen, wenn sie denn diese Schiene nutzen möchten. Nichts und niemand ist heute vor Patentklagen sicher. Das hat mit der Patentgesetzgebung allgemein und zu tun und nichts speziell mit MS/Mono/Linux.
auch Ubuntu ist eine Einrichtung ohne Geld und Canonical besitzt es nicht, von daher ist es nicht mehr oder weniger sicher als Debian.
Debian hat sich vor längerer Zeit mal mehr um Patente gekümmert (siehe non-US). Sie sind aber inzwischen davon abgekommen, da es unrealistisch geworden ist, denn vom Kernel bis zu KDE gibt es Unmengen von Patenten, die unmöglich irgendjemand auf ihre Stichhaltigkeit überprüfen kann.
Daher lassen sie das andere machen.
Andere sind dann Redhat, denn die erlaubt sich traditionell diesen Luxus nicht. Da fliegt alles im Zweifel eher raus, besonders wenn es optional ist. Das war bei MP3 so und da geht es Mono auch nicht anders.
Ich glaube aufregen muss sich keiner. Niemand rechnet damit, dass Mono eine nennenswerte Anzahl von Applikationen erreichen wird. Und schon garnicht solche, die es nur 1x gibt, und diesen Zustand länger halten.
dann sind wir uns ja einig. Ich hab nachgegoogelt und laut wikepdia gehört Ubuntud er Ubuntu Foundation: http://de.wikipedia.org/wiki/Ubuntu_Foundation
Die haben also wohl 10 Millionen oder so, auch nicht wirklich spannend wenn man auf Geld aus ist.
Wenn man die angeht dann höchstens wegen Image oder weil man die Verbreitung unterbinden will (in den USA kriegt man das sicher hin, ausserhalb der USA sicher schwieriger).
Die einzige Firma, die auf Linux macht und WIRKLICH Knete hat ist IBM und die waren also nicht umsonst Zielscheibe von SCO.
Naja, mono taugt nun mal am besten für Flamewars - es kombiniert die uralten 'meine Programmiersprache ist die beste' Flamewars mit den 'nativer Code vs VM' Flamewares und heizt das ganze mit den 'alles, was von Microsoft kommt ist böse' Flamewars an, man geben einen Stallman dazu - viola, die perfekte Flamewar Suppe ist angerichtet. Die wollte PL eben noch ein paar Tage kochen lassen, bevor sie nachlegen
Letztlich gibt es viele GUI-Features die man aus rechtlichen Problemen nicht in Mono implementieren (werden) kann. Somit wird man wohl kaum eine Umgebung schaffen, in der man .Net-Programme (kommend von der Windows-Plattform) unter Linux wirklich laufen lassen kann. Am Ende versteht das aber der Benutzer nicht und beklagt sich, das Linux ja nicht richtig funktioniert.
Die ECMA 334 und ECMA 335 Specs stehen nun unter dem Microsoft Community Promise. ASP.NET, ADO.NET, Winforms sind nicht eingeschlossen. Icaza hat anscheinend schon angekündigt, die Mono-Pakete deshalb entsprechend aufzuteilen.
@hjb: Banshee wird zwar bald bei Ubuntu dabei sein, aber bisher ist es noch nicht dabei.
Ein oder zwei Jahre, dann liegt Canonical mit Microsoft genauso im Bett wie Novell es derzeit tut.
Hast du _konkrete_ Beispiele (und nicht nur irgendwelche wirtschaftlich interessante Supportverträge)?
Wo sollten sie sonst sein?
es heisst nicht umsonst Novell Suse?
Ubuntu: brought to you by Microsoft
Microsoft Operating System
Ubuntu 8.04
Damals war Qt "nur" GPL.
Jetzt ist das sogar LGPL.
Wenn sich die Gnome da mal nicht selbst widersprechen.
PS:
Ich programmiere noch immer am liebsten in C++.
Für Java oder C# sehe ich nicht wirklich einen Grund,
denn Qt Programmierung in C++ ist elegant und man braucht lange nicht alle Features von C++.
Wenn es aber mal darauf ankommt, stehen Die aber zur Verfügung.
Und performanter ist das alle mal.
Und wie sieht das in anderen Sprachen mit der Unterstützung von Mehrkernsystemen aus ?
http://de.wikipedia.org/wiki/OpenMP
Nur bei Web-Kram greife ich zu PHP.
Falsch, damals war Qt unter einer Lizenz die zwar einsicht in den Quellcode erlaubte, aber nicht dessen modifizierung.
Und alle Teile des Mono Projekts stehen entweder unter X11, GPL oder LPGL.
Ursprünglich hab ich mich nicht an C++ gewöhnen wollen, aber für Pascal/Delphi unter Linux gibts keine Software (ja, schon eine IDE, Lazarus, aber keine Softwaregrundlage - niemand proggrammiert damit mehr) - aber so unterschiedlich sind C++ und Pascal gar nicht. Qt ist halt zu lernen, aber das ist wie gesagt echt angenehm, ud dank QtCreator gibts auch eine echt gute IDE dafür.
Ich kann mich weder mit C# anfreunden (nur GTK bindings gut, qymono verwendet niemand, keine IDE, etc.), noch mit Java (kotz), und schon gar nicht mit reinem C.
Es ist mir ein Greuel, dass GTK+GNOME in C programmiert sind, sowas WILL ich gar nicht lernen.
C'/GTK+ bindings sind unter Monodevelop zwar easy zu nutzen - aber ehrlich: warten wir noch ein Jahr, dann ist KDE4 so stabil wie es 3.5.10 war, und dann kann sich GNOME und GTK echt schleichen.
Es ist mir ein Greuel, dass GTK+GNOME in C programmiert sind, sowas WILL ich gar nicht lernen.
Kannste auch in C++ programmieren.
...selten so viel Schwachsinn gelesen
Welche Grundschüler haben wohl schon mit Delphi Programmiert?
QT ist wirklich angenehm zu programmieren! Schon mal selbst probiert?
Bei OSS (Open Source Software) ist es egal ob das Programm auf allen Platformen läuft, denn man kann es auf allen Plattformen compilieren. So etwas wie Bytecode von Java ist nur notwendig, wenn man den Quellcode unter Verschluss halten möchte.
Also ich habe als Neunjähriger vor 17 Jahren mit Turbo Pascal Programmieren angefangen.
Da ist Programmieren wieder befriedigend und nach einer Weile kannst du gar nicht glauben, jemals C/C++ benutzt zu haben
es wird weiterhin leute geben die nicht alle paar irgendwas einen derartigen umbruch miterleben wollen... und weiterhin auch leute die auf bildschirmlange kontextmenüs und einstellungsdialoge verzichten können...
LOL!!!
Falls KDE 4 wirklich in einem Jahr stabil sein sollte (was ich sehr bezweifle!), wird das der Zeitpunkt sein, wo die neueste Bastelversion KDE 5.0 freigegeben und jeglicher Support für KDE 4 eingestellt wird - schließlich braucht man die knappen Ressourcen ja für Innovationen.
Die KDE ist innovativ - immerhin in diesem Punkt hast du recht.
I have a dream that one day Gnome-, KDE-, Xfce-, Fluxbox- and LXDE-Users will coexist in peace and harmony.
I have a dream, today.
Moment mal, Free Pascal ist nun wirklich alles andere als tot. Wenn man nicht gerade systemnah programmieren will, sehe ich keinen Grund C einzusetzen. Und was die Geschwindigkeit beim kompilieren und bei der Ausführung angeht kommt FP mit dem gcc ganz gut mit.
Wer OpenMP-ähnliche Anweisungen für Multithreading braucht, kann ja JOMP nehmen.
> Was lässt sich da denn parallelisieren?
> Multithreading ist natürlich möglich und sollte auch genutzt werden, um die GUI nicht zu blockieren,
> ist aber in diesem Fall kein OpenMP-Thema.
Bei Client/Server Anwendungen mit GUI genügt es ja extra Threads zur Überwachung der Netzwerk Sockets zu haben.
Mit signal/slot (in Qt) kann man das dann sehr effizient an das GUI geben.
Ich denke aber, dass es wesentlich effizienter ist EINE Programmiersprache RICHTIG zu können,
als viele Programmiersprachen ein BISCHEN.
Deshalb spricht für mich nichts gegen C++, erst Recht wenn wir dann doch zu OpenMP kommen.
Warum sollen Client und Server in verschiedenen Programmiersprachen realisiert werden ?
PS: Qt ist nicht "nur" GUI
Und dafür nimmt man nicht OpenMP. ;-)
> Ich denke aber, dass es wesentlich effizienter ist EINE Programmiersprache RICHTIG zu können, als viele Programmiersprachen ein BISCHEN.
Programmierer sind meist Spezialisten auf einem bestimmten Gebiet und deshalb ist der Punkt hier irrelevant. Ich kenne jedenfalls keine Entwickler von GUI- oder Web-Anwendungen, die gleichzeitig Compiler entwerfen und/oder die Laufzeit von Algorithmen auf Parallelrechnern optimieren.
> Deshalb spricht für mich nichts gegen C++, erst Recht wenn wir dann doch zu OpenMP kommen.
OpenMP ist nur eine Compiler-API und alles, was mit OpenMP geht, geht auch ohne. Wie ich schon geschrieben hab, gibts auch ne Möglichkeit, in Java Kommentare analog zu OpenMP zu verwenden, was dann in Java-Threads übersetzt wird.
> Warum sollen Client und Server in verschiedenen Programmiersprachen realisiert werden ?
Weil man dann die für den jeweiligen Einsatzzweck geeignete Sprache verwenden kann.
> PS: Qt ist nicht "nur" GUI
Wer benutzt denn Qt auf Parallelrechnern?
Für C# gibt's z.b. das FMACJ Parallelization Framework.
Das alles erinnert mich extrem an die QT / KDE Diskussion vor ein paar Jahren. Und wen interessiert das heute noch ?
Seid doch froh, dass es endlich eine vernünftige Programmiersprache und Entwicklungsumgebung für Linux gibt, ansonsten bleibt einen doch nur noch Oracle (formerly known as SUN, und da soll mir mal einer verraten in wie weit die besser sind als Microsoft) oder C++, und mal ehrlich, wer will denn heute noch C++ programmieren ?!?? Was glaubt Ihr denn, warum Miguel de Icaza das macht ? Ganz einfach, weil er das volle Elend der C(++) Entwicklung bei Gnome erlebt hat, und sieht wohin sowas führt.
Also wenn ich jemals was unter Linux entwickle, dann auf jeden Fall in C#, weil es einfach eine der angenehmsten Programmiersprachen zur Zeit auf dem Markt ist. Und die Windoof Entwickler, die man dadurch dazugewinnt, sind mit Sicherheit ein paar kleine Patentstreitigkeiten wert. Außerdem, wen soll MS denn verklagen ? Die Free Software Foundation ? Jeden Enduser einzeln ? Mono wird ja von Novell entwickelt, und die haben ja einen entsprechenden Vertrag mit MS abgeschlossen, der genau sowas verhindert.
Also, Fazit, bitte bitte endlich aufhören auf Mono rumzuhacken, wer kein Mono haben will kann sich ja Debian oder Fedora installieren und weiter XMMS und XTerm benutzen anstatt Banshee und Gnome-Do, aber ICH KANNS NICHT MEHR HÖREN !!!!!
Dachte das sei Scala.
Und MonoDevelop ist wirklich keine gute IDE. Und sowas gehört zu einer guten Programmierumgebung einfach dazu.
Aber Python ist halt nur ne dynamisch typisierte Skriptsprache.
Und MonoDevelop ist wirklich keine gute IDE. Und sowas gehört zu einer guten Programmierumgebung einfach dazu.
Für Scala benutzt man ja auch IntelliJ oder Eclipse.
Was eher eine Glaubensfrage als ein Problem ist.
Hast du einen Link zu belastbaren Benchmarks?
Da muss ich mal Lisp einwerfen.
Interpretierend & inkrementell compilierend.
dynamisch als auch statische Typisierung moeglich ...
objektorientierte, funktionale, imperative Programmierung .... lambdas, closures, makros, ....
einfach eine multi-paradigmen sprache ;)
Common Lisp oder Scheme?
Und warum?
>> Common Lisp oder Scheme?
Rep.
>> Und warum?
Weil das viel besser klingt als Lisp (erinnert mich immer an Lipfinity, diesen Scheiss Mascara dessen Werbung mich immer so langweilt, als ob die Frauen da jetzt Torpedos stationieren würden, voll aufgebauscht.) und Mono (Mono = Einfalt). Und außerdem will man ja aus der Masse herausstechen und was können, wofür es nicht mal 'ne vollständige Dokumentation gibt ^_^;
Als nicht-lisp dann Python. Weils Idiotensicher ist.
die SUN war besser, denn sie hat uns Java als Community-Prozess und GPL-Code vermacht. Sie hat sich StarOffice gekauft und unter GPL gestellt. Sie hat Solaris unter CDDL gestellt (und dann GPL?). Mein Gott, sie hat sogar ihre CPU-Designs unter GPL gestellt.
Die SUN ist ein wichtiger Freund, den wir verloren haben.
Bei KDE/Qt haben sich die Fakten geändert, deshalb interessiert das heute Niemand mehr. Anfangs durfte man wegen der "non-commercial, do not modify" Qt-Lizenz keine KDE-Binaries vertreiben, weil man schlicht keine Lizenz dazu hatte, dies mit dem GPL-Code von KDE und seinen Libraries zu kombinieren. Zum Glück ist das lange her, dann wurde Qt/X11 unter GPL gestellt. Und zuletzt ja sogar unter LGPL und für Änderungen durch alle im Rahmen des Projektes selbst geöffnet.
Und zu C# gibt es genug Alternativen, die keinen Unsinn nach sich ziehen, wie etwa Vala.
Den Vertrag von Novell mit Microsoft kennst Du nicht gut genug. Der schützt nur Novell und nicht-kommerzielle openSUSE-Entwickler, die ihre Software in openSUSE veröffentlichen. Das reicht nicht besonders weit.
Zu Mono teile ich die Meinung, dass man sie machen lassen sollte. Ich sehe nicht, warum sie erfolgreicher werden sollten als die Java-Jungs. Es wird aus meiner Sicht aber Zeit, dass die C-Gemeinde um Gnome sich um die Attraktivität der Plattform bemüht.
Etwas wie Vala wäre ohne Mono nicht gekommen und da muss man Microsoft danken. Es hat nicht viel mit Mono zu tun, aber addressiert die Bedenken der C-Gemeinde gegen C++ mit einer modernen Sprache, die von C# inspiriert ist, aber wohl gesünder ist.
Selbst unter Windows habe ich keine .NET Programme gesehen, ausser als ich noch auf meinem Gaming-PC ATI hatte. Wieso sollte es gerade unter Linux plötzlich auch nur signifikant viele Mono-Programme geben?!
Gruss,
Kay
Warum siehst du das nicht ein?
Hinter Mono steht eine aktive Entwicklung welche sich auch speziell auf den Linux Desktop konzentriert. Mono bietet sich den Entwicklern mit gut gewarteten und weiterentwickelten Bindings an, und wirbt um den Anwender mit interessanten "Beispielapplikationen".
Bei Java hat sich seit es OSS wurde in der Richtung nicht viel getan. Immer noch wenig attraktive Native Bindings, und eine Hand von Multiplattform Anwendungen welche sich nicht wirklich in den Linux Desktop integrieren.
> wie etwa Vala.
Mit Vala trägt man meine Meinung die Kirche ums Kreuz. Am entwickelt eine neue Sprache rund um eine über 10 Jahre alte Library, für einen Einzelnen Desktop. Es bügelt zwar einige Problem aus welche man unter C/gobject hat, hat aber nichts wirklich überzeugendes. Dass dieses Konzept bei Entwicklern ankommt sehe ich nicht. Die wenigsten werden sich "mal eben" eine neue Sprache aneignen nur um ein GUI für ein Desktop zu entwickeln. Projekte welche auf Vala aufbauen schneiden sich selbst eine Menge von potenziellen Entwicklern ab.
Weit aus mehr Sinn würde es meiner Meinung machen vorhandene Sprachen besser zu Unterstützen. Würde man mehr Wert saubere, aktuelle und gut Dokumentierte C++, Java und Python Bindings legen, wäre das für die Masse von potenziellen Entwicklern deutlich insteressanter.
Was soll uns das denn sagen? GObject existiert seit 7 Jahren. .NET ist genauso alt. Andere Libraries (Qt z.B. 1991 begonnen) sind älter. Die Java-Class-Library ist 14 Jahre alt.
Am entwickelt eine neue Sprache rund um eine über 10 Jahre alte Library, für einen Einzelnen Desktop.
Vala ist plattformunabhängig und kann C-Bibliotheken binden.
Die wenigsten werden sich "mal eben" eine neue Sprache aneignen nur um ein GUI für ein Desktop zu entwickeln.
Da muss man nicht viel lernen. Wer C# oder auch Java kennt kann sich Vala innerhalb kürzester Zeit aneignen, lesen sowieso von Anfang an. Und das machen auch nicht wenige Entwickler, wenn man mal in die Mailingliste oder den IRC-Channel guckt.
Weit aus mehr Sinn würde es meiner Meinung machen vorhandene Sprachen besser zu Unterstützen.
Wird ja auch gemacht, Stichwort GObjectIntrospection.
Hat Vala einen Garbage Collector? Sind Funktionen in Vala First-Class Objekte, daher kann ich eine Funktion an eine Methode übergeben und zurückgeben (das man das in C mit Funktionspointern kann, weiß ich, das meine ich aber nicht). Wie schauts mit Closures und Lamda-Funktionen aus? Gibt es immutable Datentypen? Wie schauts mit einer IDE/einem Debugger aus? Springt der Debugger an die richtige Stelle im Vala Code?
Automatische Speicherverwaltung über Reference Counting.
Sind Funktionen in Vala First-Class Objekte, daher kann ich eine Funktion an eine Methode übergeben und zurückgeben (das man das in C mit Funktionspointern kann, weiß ich, das meine ich aber nicht).
Ja, wie in C# sind das Delegates.
Wie schauts mit Closures und Lamda-Funktionen aus?
Lambdafunktionen gibt es, haben aber noch keine vollständige Closure-Funktionalität (Kontext wird nicht mit eingeschlossen). Das soll angeblich aber noch geplant sein.
Gibt es immutable Datentypen?
Strings sind beispielsweise immutable. Objekte kannst du immer immutable machen, indem du nur konstante Felder hast.
Wie schauts mit einer IDE/einem Debugger aus? Springt der Debugger an die richtige Stelle im Vala Code?
Da kann man gdb verwenden oder ein grafisches Frontend dafür wie Nemiver. Wenn man ein Programm mit der Option -g kompiliert, dann werden die Zeilennummern des Vala-Sourcecodes verwendet.
Zu IDEs gibt es verschiedene Projekte (Integration in bestehende IDEs wie Anjuta, MonoDevelop oder Eclipse, gedit-Plugins oder ein eigene Vala-IDE) manche mehr, manche weniger weit fortgeschritten.
danke, dass ihr da übernommen habt. Das schockierende an den Nachfragen ist doch, dass die "Leute" irgendwie denken, dass C# ein Monopol auf neuartiges C hat.
Wer findet, dass C oder C++ nicht produktiv sind, oder obsolet, und nicht gleich auf Python wechselt, der kann jetzt halt Vala nehmen und weiter native Programme erstellen.
Da also - aus technischen Gründen - Mono nicht attraktiver als libwine ist, also garnicht, gehe ich davon aus, dass Nichts besonderes mehr dabei rauskommen dürfte.
Damit wurde die Mono-Gefahr gebannt, bevor sie richtig Fahrt aufnehmen konnte, und jetzt streiten wir uns halt nur noch darüber, und bald ist das vergessen.
Gruss,
Kay
Neulich im Gespräch mit unserem Produktmanagement wurde klar: In der Industrie wird C# als der "logische Nachfolger" für C und C++ angesehen. Java als Alternative wird praktisch nicht wahrgenommen.
Das kann man gut oder schlecht finden, aber man sollte es zur Kenntnis nehmen. Und wenn man für freie Betriebssysteme gern daran partizipieren möchte und sich nicht ins Abseits stellen, dann braucht man Mono, das ist doch völlig klar.
lg
Erik
So ein wenig Freiheit, in der diverse Leute diverse Meinungen zum Besten geben ist schon scheiße was? Gut das da mal jemand zwischenschreit!
Sry für OT aber der wollte raus.
Dort braucht niemand Mono, die "eigenen" KDE-Anwendungen sind durchweg gleichwertig oder meist sogar besser.
Kerry/Beagle sind aber so ressourcenfressend, dass ich unter openSuse die Installation nicht mehr erlaube.
Beagle ist in dieser einen Hinsicht IMHO eine völlige "Fehlkonstruktion".
Ubuntu und Debian verwenden Beagle deshalb erst gar nicht in der Standardinstallation.
Jede noch so einfache, schnelle, ressourcensparende Desktopsuche a la BeOS oder auch Windows98 ist da vorzuziehen.
Mit Beagle hatte ich übrigens kein Problem. Das indizierte auch nur, wenn der Rechner mal nix zu tun hatte und im Akkubetrieb schon mal gar nicht.
Wow, was für billige Polemik.
Wo ist das Problem?
Manchmal wird ja auch herumgemeckert, wenn man den VLC oder MPlayer unter Linux benutzt.
Wo liegt - im Hinblick auf eine mögliche Patentverletzung - der Unterschied zwischen Mono-Software und einem nicht-kastrierten VLC oder MPlayer?
VERGLEICHE mal die Anwendungen, dann überleg nochmal, was ich wohl mit "Polemik" meinte.
Du kannst doch C nicht mit C++ gleichsetzen. Ausserdem tust du so als haette
Icaza die Weissheit mit Leoffeln gefressen. Und das ist ganz sicher nicht der
Fall denn dann haette er sich nicht ausgerechnet fuer eine MSFT Technologie
entschieden.
Oder er ist einfach nur gekauft.
C++ zusammen mit Qt ist ungeschlagen fuer Desktops Apps. Da kann weder Java
noch C#/Mono/.Net gegen anstinken.
> Und die Windoof Entwickler, die man dadurch dazugewinnt, sind mit Sicherheit ein paar kleine Patentstreitigkeiten wert.
Auaua... das tut ja beim lesen weh!! Wie kann man so einen Schwachsinn erzaehlen!?!
Der Omega13.
Wie? Gab es die bisher nicht?
>> Oracle (formerly known as SUN...
BITTE? Oracle war auch schon vorher als Oracle bekannt, bevor es SUN gekauft hat.
>> Was glaubt Ihr denn, warum Miguel de Icaza das macht ?
Fanboy? Warum soll mich das interessieren? Außer Microsoft hinterher rennen kann er doch nichts.
>> Also wenn ich jemals was unter Linux entwickle, dann auf jeden Fall in C#
Aha! Noch nicht mal unter Linux entwickelt, aber herumtönen von wegen "vernünftiger" Programmiersprache und Entwicklungsumgebung.
>> Also, Fazit, bitte bitte endlich aufhören auf Mono rumzuhacken
Warum? Mono ist einfach Mist, den man nicht braucht.
Hat windows berhaupt dotnet in der standardinstallation?
:-)
ja seit Vista!
Bei Ubuntu tut man es rein, weil man meint es sei keine Gefahr von MS zu befürchten. Passiert nichts: Alles in Butter. Passiert was: Mono fliegt sofort raus, Canonical wird vielleicht verklagt, verliert vielleicht vor Gericht und bekommt eine Milliardenstrafe. Canonical hat nicht die Mrd., geht in Konkurs, ist weg. Was ist dann passiert? Nichts, morgen tritt jemand anders (Projekt, Firma) an deren Stelle.
Was bedeutet das für mich? Nichts, es weiß nicht mal jemand, daß es mich gibt und daß ich Mono-Software habe (ätsch, stimmt gar nicht, hab gar keine Mono-Software). Juckt mich also auch alles nicht.
Jedem anderen geht es genauso. Also warum aufregen? Debian weiß, was es tut. Ubuntu weiß es auch.
So, ich entspann mich jetzt.
auch Ubuntu ist eine Einrichtung ohne Geld und Canonical besitzt es nicht, von daher ist es nicht mehr oder weniger sicher als Debian.
Debian hat sich vor längerer Zeit mal mehr um Patente gekümmert (siehe non-US). Sie sind aber inzwischen davon abgekommen, da es unrealistisch geworden ist, denn vom Kernel bis zu KDE gibt es Unmengen von Patenten, die unmöglich irgendjemand auf ihre Stichhaltigkeit überprüfen kann.
Daher lassen sie das andere machen.
Andere sind dann Redhat, denn die erlaubt sich traditionell diesen Luxus nicht. Da fliegt alles im Zweifel eher raus, besonders wenn es optional ist. Das war bei MP3 so und da geht es Mono auch nicht anders.
Ich glaube aufregen muss sich keiner. Niemand rechnet damit, dass Mono eine nennenswerte Anzahl von Applikationen erreichen wird. Und schon garnicht solche, die es nur 1x gibt, und diesen Zustand länger halten.
Gruss,
Kay
dann sind wir uns ja einig. Ich hab nachgegoogelt und laut wikepdia gehört Ubuntud er Ubuntu Foundation: http://de.wikipedia.org/wiki/Ubuntu_Foundation
Die haben also wohl 10 Millionen oder so, auch nicht wirklich spannend wenn man auf Geld aus ist.
Wenn man die angeht dann höchstens wegen Image oder weil man die Verbreitung unterbinden will (in den USA kriegt man das sicher hin, ausserhalb der USA sicher schwieriger).
Die einzige Firma, die auf Linux macht und WIRKLICH Knete hat ist IBM und die waren also nicht umsonst Zielscheibe von SCO.
Grüsse, Marc
Auf
http://www.pro-linux.de/news/2009/14376.html
schrieb ich u.a.
Desweiteren schreibt ein Debian-Entwickler, daß Debian nicht die default-Einsellungen ändert.
Naja, nun ist PL auch drauf gestoßen.
Letztlich gibt es viele GUI-Features die man aus rechtlichen Problemen nicht in Mono implementieren (werden) kann. Somit wird man wohl kaum eine Umgebung schaffen, in der man .Net-Programme (kommend von der Windows-Plattform) unter Linux wirklich laufen lassen kann. Am Ende versteht das aber der Benutzer nicht und beklagt sich, das Linux ja nicht richtig funktioniert.
http://www.heise.de/newsticker/Microsoft-Community-Promise-Kernbestandteile-
von-Mono-ohne-Patentansprueche--/meldung/141658
http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx
http://tirania.org/blog/archive/2009/Jul-06.html
Die ECMA 334 und ECMA 335 Specs stehen nun unter dem Microsoft Community Promise.
ASP.NET, ADO.NET, Winforms sind nicht eingeschlossen.
Icaza hat anscheinend schon angekündigt, die Mono-Pakete deshalb entsprechend aufzuteilen.