Ich begrüße es sehr, dass Red Hat den Weg für MONO endlich aufgemacht hat. Somit steht MONO nichts mehr im Weg und GNOME kann endlich vollständig mit dem Produkt fusionieren, so dass es endlich core Bestandteil von GNOME werden kann. Somit werden hoffentlich bald auch vollwertige GNOME Anwendungen auf dem Markt kommen und GNOME soweit revolutionieren.
Leider nicht. Die meisten GTK+ und GNOME Programme die ich hier verwende haben einen pfaden Beigeschmak. Entweder funktionieren diese nicht richtig, neigen zu fehlern oder stürzen einfach nur so ab. Aber das Hauptproblem ist, dass die meisten Programme einfach unausgereift sind.
Die Qualität der Software hängt immer von der Programmierung ab. Ein Programmierer kann vielleicht mit Assembler ein besseres Programm erzeugen als ein anderer mit C#, aber das dauert auch sehr viel länger. Behauptung: Mit C# lassen sich gute Programme einfacher entwickeln als mit C oder C++. Sie sind ein wenig langsamer, aber aufgrund der Architektur sicherer (Was nicht bedeutet, dass man mit C/C++ keine sicheren Programme schreiben kann. Da bedeutet es einfach mehr Aufwand)
Von mir aus. :-) Ich bin gerne für Alternativen offen. Und Smalltalk wollte ich mir auch schon mal ansehen. Naja, das Lernen von Ruby wird mir vorläufig genug Arbeit geben. Wenn ich irgendwann mal zuviel Zeit haben sollte...
> Bitte nicht C und C++ in einen Topf werfen. > C++ ist streng genommen nur binderkompatibel zu C Trotzdem bleibt der Nachteil gegenüber C#: unmanaged Code.
> Im übrigen ist C++ genau wie C# auf der .Net Platform lauffähig. Ok, prinzipiell vielleicht schon. Nur dass managed C++ in Mono nicht unterstützt wird. Oder? Klärt mich bitte auf, wenn ich falsch liege. Ausserdem müsste "prinzipiell" sogar C unter .NET lauffähig sein.
Hab ich auch nicht behauptet. Ich meinte lediglich, dass eine höhere Programmiersprache die Entwicklung besserer Software erleichtert. Man kann Open Office auch in Assembler nachprogrammieren und es besser zu machen als das Original. Nur wird das keiner versuchen. Ich bin halt der Meinung, dass es langsam Zeit wird, auf managed Code umzusteigen, auch gerade in der Linuxwelt und auch gerade in systemnaher Programmierung. Es ist nur eine Frage der Zeit, bis der Performance-Unterschied zwischen einem GCC und dem MC (Monocompiler) minimal sein wird, oder zumindest nicht merklich spürbar.
> Und die Gleichung "Höhere Programmiersprache == Bessere Programme" kann ich überhaupt nicht leiden! Das ist nämlich irrsinn. > Die Regel (nicht Gleichung) lautet "höhere Programmiersprache -> leichter wartbare Programme". Denn letztendlich wird aller Quellcode in Binärcode übersetzt und das ist dann das Programm - völlig unabhängig von der Programmiersprache. Arbeite Dich mal in ein C-Programm ein, was aus einigen Dutzend Dateien mit je 10.000 Zeilen Code + Dutzende Headerdateine besteht. Da macht sich Objektorientierung bemerkbar - solche Programme sind leichter zu verstehen und damit findet man auch schneller Fehler.
> Trotzdem bleibt der Nachteil gegenüber C#: unmanaged Code.
ja bitte gib mir einne garbage collector,ich liebe overhead ;) schlaue allokatoren tuns auch...smart pointer tun ihr uebrigens,wer nich mit klarkommt kann weder in c++ noch in C# vernuempftig coden ;) ok in C# gibt es keinen segfaults,aber speicherluecken oder zu frueh/spaet geschlossene handles sind immernoch da...
zumal ich fuer ne sprache die mehr abstrahiert als C kein bloatVM brauche,das geht auch direkt zu native code. (gcj,ocaml,gcl,sbcl (ist keine vm!))
C ist ein Haufen Scheiße. C++ ist ein Haufen Scheiße mit nem Schleifchen drum. Nicht umsonst bedienen sich beliebte C++-Toolkits wie Qt mehr und mehr auch bei Konzepten anderer Sprachen.
Was meinst du überhaupt mit "schlauen Allokatoren"? Oder "Smart Pointern"? Für mich klingt das eher nach Sicherheitsnetzen, um schlechte Sprachen erträglich (und weniger fehleranfällig) zu machen.
Der Overhead eines Garbage-Collectors ist heutzutage nun wirklich vernachlässigbar, er beseitigt aber einige Bugs, die in C/C++-Programmen immer wieder auftreten.
Und der Vorteil einer VM liegt darin, daß man in gewissen Grenzen plattformunabhängig sein kann. Ohne das Binary neu zu compilieren. Das mag für C# jetzt nicht so sehr zutreffen wie für Java, aber immerhin. Wenn Mono jetzt noch ein bißchen mehr Wert darauf legen würde, kompatibel zu .NET zu sein, dann wäre es ja endlich auch mal brauchbar.
Und erzähl mir bitte nicht, daß gcj eine brauchbare Alternative für Java darstellt. Bis die das nicht ins kleinste Detail nachimplementiert haben ist das eben nicht so.
> C ist ein Haufen Scheiße. C++ ist ein Haufen Scheiße mit nem Schleifchen drum. > Nicht umsonst bedienen sich beliebte C++-Toolkits wie Qt mehr und mehr auch bei Konzepten anderer Sprachen.
Java und C# sind ein Haufen Scheisse. Nicht umsonst bedienen sich Java und .Net bei Konzepten die es unter dem eleganteren C++ schon seit Jahren gibt (z.B. Templates)
> Der Overhead eines Garbage-Collectors ist heutzutage nun wirklich vernachlässigbar, > er beseitigt aber einige Bugs, die in C/C++-Programmen immer wieder auftreten.
Ist der Garbage Collector nicht auch nur ein Sicherheitsnetz damit auch schlechte Programmierer einen Job finden? Ansonsten benutze ich unter C++ fast gar keine heap objects.
> wer nich mit klarkommt kann weder in c++ noch in C# vernuempftig coden
Irgendwie muss ich an die Zeit denken, als Programmierer noch echte Kerle waren: Echte Programmierer :-)
Aber mal im Ernst: Ich bin froh, dass ich C und C++ im Studium gelernt habe. Aber ich möchte managed Code wie in C# oder auch in Ruby nicht mehr missen. Wenn du das anders siehst, dann steht dir nichts im Wege, dich bis an dein Lebensende mit wilden Pointern und Stackoverflows zu beschäftigen
Ist das wirklich so? Ich bin zwar kein wirklicher C++ Programmierer, aber wenn man die Mono-Libraries alle in C++ verwenden koennte, wuerde es das doch wesentlich interessanter machen. Gaebe es dabei Geschwindigkeitseinbussen, d.H. wuerde das dann genau so schnell laufen wie ein C#-Programm, oder schneller?
KingArthur schrieb: Die Qualität der Software hängt immer von der Programmierung ab.
Entschuldige, wenn ich mich hier einmische, aber das ist nicht die ganze Wahrheit: Ein ''Hello World'-Programm nützt niemandem, selbst wenn die Qualität gut sein sollte. Zum Schreiben nützlicher Software braucht es heutzutage meist mehr als einen Programmierer, und da klappt es nicht. Es mangelt an Koordination und Zusammenarbeit. Das wird auch Mono nicht ändern. Vielleicht wird Mono die Situation sogar noch verschlimmern.
Ein Beispiel: Ich war mal auf der Suche nach einem Outliner -- eigentlich ein recht simples Programm. Da sind mir zwei Kandiaten entgegengekommen, die beide in GTK+ und Python geschrieben waren. Der eine hatte volle Desktopintegration, konnte aber sonst nichts besonderes. Der andere hatte zumindest eine Exportfunktion für Webpräsentationen, aber keine Integration in den Desktop. Beide hatten Webseiten, machen Werbung auf Freshmeat, und beide sind inzwischen auch mehr oder weniger tot. Ja, und mit beiden habe ich meine Zeit verschwendet und andere wird es wahrscheinlich ähnlich gehen.
Solchen Wahnsinn wird auch C# an sich nicht stoppen. Das wird allenfalls durch eine Integration von Mono/C# in GNOME erreicht, und das auch nur, weil Miguel de Icaza es schafft, die Leute mit seinen Ideen zu begeistern.
>Ein Programmierer kann vielleicht mit > Assembler ein besseres Programm erzeugen > als ein anderer mit C#, aber das dauert > auch sehr viel länger.
Nicht nur das: Er wird auch mehr Fehler machen und niemand außer ihm selbst wird den Code warten können. Von Portabilität wollen wir gar nicht erst reden
Komisch nur, dass das ganze Mono Zeugs auch im Bereich GUI bei mir gut funktioniert. Ich benutze Banshee, Tomboy, F-Spot und Beagle und alle diese Programme funktionieren einwandfrei.
Junge ich würde ne Pulle Sekt aufmachen, wenn Mono richtig laufen würde es wäre göttlich, dann bräuchte ich nur schnelle MonoDevelop anschmeißen und meine VisualStudio Projekte kurz durchrattern lassen.
Aber leider ist Mono bisher noch ne Krankheit. Nur weil ein paar Jungs wie du ein paar So Freeware Programe alle Winload mein erstes Programm benutzen, die unter Mono laufen, heißt das noch lange nicht, dass da auch richtige Software mit läuft.
Was du falsch machst, evtl mal ein Progrämmlein mit Mono erstellen.
Ich hab ca 5 Anwendungen hier, die unter Windows absolut stabil und zuverlässig laufen unter Mono funktioniert nicht eine der 5.
Es ist ja gut möglich, dass deine Anwendungen die extra um die Bugs von Mono drum herum gebaut sind gut funktionieren, aber das heißt nicht, dass Mono so funktioniert wie es das NET Framework unter Windows tut.
Das liegt wohl daran, dass du verschiedene windows API's verwendest. Mono ist kein 1:1 .Net für GNU/Linux! Mono ist ein Framework auf der Basis des ISO/ECMA Standards der CLI und C#. Windows.Forms, ADO.Net, ... sind "nur" Teil eines kompatibilitäts Stacks, der eine gewisse Durchlässigkeit windows -> GNU/Linux erlauben sollen (100% wird das nie werden). Wenn man cross-platform Programmieren will, dann sollte man Mono (ohne kompatibilitäts-stack) verwenden. Denn Mono ist im Gegensatz zu .Net ein cross-platform framework. Wenn man natürlich mit jedem möglichen windows-schnickschnack auf deren propprietären und _nicht_ plattformunabhängigen Framework programmiert, kann man nicht von einem anderen Framework erwarten, dass dieses zaubern kann und die proprietäre windows API 1:1 auf GNU Systeme abbildet.
>>>Das liegt wohl daran, dass du verschiedene windows API's verwendest.
Weisst du überhaupt was die Windows API ist? Genau solltest du seit .NET nicht mehr oft benötigen, siehe dazu z.B. MSDN:
""In Visual Basic 6.0, the Declare statement was used to call the Windows API in order to access functionality not provided by Visual Basic. In Visual Basic .NET, the need to access the Windows API is greatly diminished because much of the functionality of the Windows API is wrapped up in the .NET Framework.""
Außerdem, glaubst du, dass ich beim übersetzen unter Linux solche Funktionen nicht erkennen und umschreiben könnte, sind ja schließlich von mir geschrieben die Programme:-)
Irgendwie hab ich das Gefühl hier sind wieder lauter 1.Semestler unterwegs die wieder mit ihrem Halbwissen glänzen möchten
immer wieder schön wenn Leute ihre eigene Unwissenheit damit überdecken wollen indem sie andere beleidigen...
>Weisst du überhaupt was die Windows API ist? Genau solltest du seit .NET nicht mehr oft benötigen,
und was ist .Net? Eine API die es nur auf windows gibt und damit vielleicht nicht "die Windows API" aber sicher eine "windows API". Nur weil etwas auf einer VM(CLI) beruht ist es noch lange nicht Plattformunabhängig, auch auf einer VM(CLI) kann es APIs geben die nur auf einer Plattform wirkich 100% laufen und das ist nunmal so bei .NET.
Wenn du Plattformunabhängig programmieren willst, dann solltest du also APIs verwenden die es auch Plattformunabhängig gibt. Auf der Basis von C#/CLI gibt es da z.B. Mono. Jedes Programm, dass du unter windows mit der Mono/C# API schreibst, läuft garantiert auch problemlos unter GNU/Linux, da es da eben auch Mono gibt. Andersherum, wenn du unter GNU/Linux arbeitest, dann mußt du aufpassen, dass du keine GNU/Linux spezifische APIs verwendest, z.B. der ganze GNOME. Bereich. Du kannst unter windows, natürlich auch mit .Net arbeiten, wenn du aber willst, dass das ganze dann auch unter GNU/Linux läuft, dann solltest du aufpassen, dass du keine windows spezifische Sachen verwendest...
Zum einen kann ich Deine Meinung nicht teilen, zum anderen: Fehler in Programmen, seien sie konzeptueller oder handwerklicher Natur, sind in ihrer Ursache größtenteils beim Wirken der Programmierer zu suchen. Wie kann ein besseres (was bei Mono diskutabel sein mag) Werkzeug da helfen?
Ich sehe, da hat jemand noch nie Spaß mit Pointern bei C/C++ gehabt Allein schon der GC macht es einem möglich viele Fehlerquellen auszuschließen. Aber sowas ist ja böse, tztz. Wie kann man auch die Rechenleistung des Computers dazu benutzen den Speicher eben dieses Geräts zu verwalten, sowas ist ja irrsinnig. Los, lasst uns wieder treiber komplett selbst laden, IRQs per Hand zuweisen und sämtliche Erungenschaften der letzten 15 Jahre vergessen, es lebe die 70er Unix Ära.
Sorry Leute, aber ihr habt sie echt nimmer alle ..
> Wie kann ein besseres (was bei Mono > diskutabel sein mag) Werkzeug da helfen?
Wenn ich einen String in einer gut les- und verstehbaren Zeile manipulieren kann statt in fünf Zeilen mit kryptischen Low-Level-Funktionen, dann ist die Chance, Bugs und Sicherheitslücken einzubauen, bei zweiterem natürlich höher. Und erzähl mir nicht einem guten Programmierer passiert das nicht. Es passiert ständig bei aller möglichen Software, wie man bei Security-Warnungen überall beobachten kann. Oder hacken an Openssh, OpenOffice, Gnome, Linux-Kernel, Windows, [insert your favourite C/C++-based Software here] usw. nur Anfänger? Wohl kaum.
Mit gut getesteten IO- und String-Klassen z.B. können viele Buffer-Overflow-Fehler gar nicht erst auftreten, weil die Low-Level-Details hübsch gekapselt werden, so dass dem Anwendungsentwickler viele Fehler gar nicht mehr passieren können. Außerdem ist "abstrahierender" Code besser zu lesen und zu verstehen und damit besser zu warten. Und natürlich: Ohne passende Werkzeuge ist auch der beste Handwerker aufgeschmissen. Ich übertrage es mal aufs Häuser bauen: Niemand nimmt einzelne Backsteine und baut daraus einen Wolkenkratzer. Man nimmt größere Komponenten mit bekannten, getesteten Eigenschaften.
liebe mono entwickler, wenn ihr euch nicht strafbar machen wollt muesst ihr windows mit dot net verwenden. eure anwendungen werden aber zu 90% laufen, somit ist eine migration auf windwos immer noch billiger als auf eine andere programmiersprache / framework. oder xxxx $ lizenzgebuehren bezahlen, damit wir die die patentanwaltskosten und schmiergelder wieder reinbekommen.
oder soll man sich was anderes erwarten? ich wuerds freiwillig nicht riskieren, ausser der auftraggeber wuenscht es ausdruecklich
Die Fortsetzung dieser FUD-Kampagne ist nach dem in genau dieser Meldung beschriebenen Umstand zwecklos geworden.
Trotzdem: Mono ist die Implementation einer ECMA-Spezifikation und somit Gegenstand der ECMA-Patentrichtlinien, die der Implementation als Freie Software ebensowenig zuwiderlaufen wie der Verwendung im GNOME-Projekt.
das ist keine FUD Kampagne sondern meine persoenliche Meinung. das sich meine meinungen tw mit diversen Kampagnen unterschielicher Lager deckt mag sein, aber ich mach keine Meinungskampagne.
"wir werden daruf entsprechend reagieren wenns so weit ist" gibt keine technologische sicherheit.
patent problem entsteht, zeitraum X bis loesung, was ist waerend zeitraum X? meine apps idln dahin, oder wie? ist eine app von mir irgendwo im einsatz und ich stopp sie nicht, wed ich dann verklagt/abgemahnt wegen patentmissachtung? so versteh ich die problematik, aber event hab ich mir die Mono FAQ nicht gruendlich genug durchgelesen. oder ich bin zu wenig anwalt damit ich diese problematik verstehe.
gross ankuendigen das es keine probleme geben wird ist, mMn, ein bissl wenig, glaub ich erst wenn ichs gesehen hab.
steht in der meldung irgendwo das ich als entwickler deffinitiv nix zu befuerchten hab wenn ich mono verwend?
Wer ein Problem damit hat, dass Software theoretisch irgendwann mal im Hinblick auf Patente problematisch werden könnte und absolute Sicherheit haben will, der kann überhaupt keine Software benutzen und auch keine entwickeln.
Sorry, aber ich verstehe es einfach nicht. Was eine ECMA-Standardisierung im Hinblick auf bereits bestehende Patente bedeutet, ist bei der ECMA nachzulesen. Ansonsten gilt im Wesentlichen, dass man sich von denjenigen Dingen, die über den ECMA-standardisierten Teil hinausgehen, besser komplett fernhält.
Was den GNOME-bezogenen Teil von Mono angeht, ist das bereits der Fall. Darüber hinaus gibt es auch Bemühungen, die Windows Forms und weiteres zu implementieren. Das ist in der Tat problematisch und gefällt mir auch nicht, aber es gefährdet GNOME nicht.
Im Übrigen: GTK wird immer ein Toolkit mit *wirklich* vielen Sprachanbindungen bleiben und auch für GNOME-Bibliotheken wird es immer viele Sprachanbindungen geben. Niemand, der Anwendungen für GNOME entwickeln will, ist in irgendeiner Weise genötigt, C# oder andere .NET-bezogene Techniken zu nutzen.
so wie ich das seh (achtung, persoenliche meinung, keine kampagne) wird mono als plattformuebergreifendes dotNet angepriesen in wahrhei solls aber eine neue basis fuer gnome werden, (weil man mit C an den (entwickler resourcen) grenze angekommen ist?) und man den leuten den umstieg erleichtern will die dotnet gewohnt sind, und das eben mit C# leichter faellt als mit C und GTK.
wer funktionalitaet darueber hinaus verwendet tut das auf eigenes risiko. (hoffendlich bringt wenigstens der compiler entsprechende warnings bei verwendung von funktionen die nicht unbedenklich sind)
mir persoenlich ist das alles zu kompliziert und unklahr, einfach und transparent ist da gar nix. ein verlgeich zu anderen libs/frameworks die man verwenden kann hinkt da gewaltig.
waere schoen wenns da eine klare und uebersichtliche klarstellung geben wuerde die leuten wie mir einiges kurz und verstaendlich erklaehrt. die mono faq sind nicht geeignet meine bedenken zu zerstreuen bzw erklaehren die mir nicht wofuer ich mono einsetzen kann ohne mir gedanken zu machen ob ichs ausliefern darf, probleme bekommen koennt usw.
sollts so ein nachlese geben ueber einen url waer ich wirklich dankbar.
> wird mono als plattformuebergreifendes dotNet angepriesen
warum das so gemacht wird verstehe ich auch nicht wirklich, ist wohl eher marketing. technische gesehen kann man mono wohl nicht wirklich als .net implementation bezeichnen, da fehlen einfach noch zu viele komponenten. selbst wenn es mal viele andere .net komponenten gibt bleibt in den USA immer noch die patentfrage offen (in europa muss man sich zum glück keine sorgen um patentprobleme machen). selbst wenn es dadurch (implementierung von nicht standardisieren komponeten) für die internationale vermarktung von programmen uninteressant wird, so bleibt es immer noch eine alternative für kleine entwickler außerhalb der USA. selbst zur migration nach linux könnte es helfen, wenn (bestimmte) .net programme auch unter linux laufen, denn - ich schreibe es nochmals - in europa gibt es keine software-pateten weshalb man sich hier auch keine sorgen darum machen muss.
> in wahrhei solls aber eine neue basis fuer gnome werden
zur zeit sieht es so aus. aber ich denke nicht dass das auf gnome beschränkt bleiben wird. mono füllt eine lücke die bis heute da war: es bietet eine OS möglichkeit programme schneller und sicherer als in c/c++ zu entwickeln, und bietet dabei bessere performance als eine skripsprache.
> hoffendlich bringt wenigstens der compiler entsprechende warnings
warum sollte er das? es gibt unter linux auch genung andere rechtliche bedenkliche bibliotheken (z.b. so ziehmlich alles was mit mp3s oder verschlüsselten DVDs zu tun hat), trotzdem hab ich noch nie eine entsprechende warung von gcc gesehen. soetwas sehe ich nicht als mono spezifisches problem an, dieses existiert generell in der softwareentwicklung, egal ob des ich um eine mono bibliothek oder eine c-lib handelt.
> mir persoenlich ist das alles zu kompliziert und unklahr, einfach und transparent ist da gar nix. > ein verlgeich zu anderen libs/frameworks die man verwenden kann hinkt da gewaltig.
für mich das es klar (und so ist es auch im mono faq beschrieben). der standardisierte teil von .net ist rechtlich unbedenlich. alles andere sind libs die auf diesen aufbauen, und man muss sich wie bei jeder anderen lib informieren ob und wie man diese einsetzen darf. verwendest du z.b. gtk# brauchst du dir keine sorgen machen, stetzt du für deine gui winforms ein, dann könnte es probleme geben wenn du in den USA rechtlich greifbar bist. warum der verglich hinken soll verstehe ich nicht, aber vielleicht kannst du das ja noch genauer erklären ...
der vergleich hinkt fuer mich unter anderem desswegen weil andere libs nicht von haus aus sagen ok, riskieren wir mal eine patentverletzung und wenn wir geklagt werden sehen wir weiter.(ok, libdvdcss usw nehm ich mal aus, aber die verwend ich eher nie in projekten(bis dato))
das der compiler warnungen bringen soll war halb als witz gemeint, aber nur halb. wuerds zB bringen wenn ich eine fremd app hab und nicht die src durchgehen will, einmal compilieren und ich weis ob bedenkliche teile enthalten sind.
die einteilung in freie mono componenten und nicht freie mono componenten ist fuer ich nicht leicht ersichtlich. meiner ansicht nach fehlt da im bereich dokumentation einiges.
vorallem weil davon auszugehen ist das mono mit *yourpackagetool* install mono installiert wird, und einige leute sich nicht gedaken machen was da jetzt alles bedekenlos zu verwenden ist.
und wenn ich schon beim raunzen und fragen bin und es hier anscheinend leute gibt die es event wissen koennten:
warum nur rpm oder installer oder sourcen?
muss ich mir die vb und winforms usw mitdownloaden mit den sourcen und mitcompilieren
gibts nicht einfach ein paar archivpackete die ich mir mal nach ~/test entpack damit ich mono mal testen kann + anleitung fuer enviromentvariablen (event in zukunft auch unterschiedliche versionen davon fahren zu koennen)
wird mono ein lib abhaengikeits gnome gau? (die frage wird dann interessant wenn man mono apps zb tatsaechlich mal ausliefern will zb mit einer monoversion die mit der app getestet ist)
eine java installation erscheint mir ja da wie ein kinderspiel (nein das ist kein java vs mono flame, ich programmier nicht mal in java, nur persoenliche meinung)
> der vergleich hinkt fuer mich unter anderem desswegen weil andere libs nicht von haus aus sagen ok, riskieren wir mal > eine patentverletzung und wenn wir geklagt werden sehen wir weiter.(ok, libdvdcss usw nehm ich mal aus, aber die > verwend ich eher nie in projekten(bis dato))
und wo ist jetzt der unterschied zu mono? beim mono projekt riskieren das auch nur ein paar libs. verwendest/programmierst du eine GTK# app (wie z.b. fspot) brauchst du dir auch sicher keine sorgen um patente zu machen (jedenfalls nicht mehr als mit GTK+). einfach zu sagen betroffene nicht mono libs nehm ich einfach mal aus dem vergleich aus ist nicht sinnvoll.
> die einteilung in freie mono componenten und nicht freie mono componenten ist fuer ich nicht leicht ersichtlich.
hab den link nicht zur hand, aber irgendwo auf der mono seite gibt es einen grafik in der standardisierte komponeten, eigentwicklungen und nachbauten in unterschiedlichen farben gekennzeichnet werden. aber die betroffenen libs sind ja sowieso offensichtlich, praktisch alle windows spezifischen komponenten können zum problem werden (das gibt aber nicht hier in europa).
> vorallem weil davon auszugehen ist das mono mit *yourpackagetool* install mono installiert wird, und einige leute > sich nicht gedaken machen was da jetzt alles bedekenlos zu verwenden ist.
ich weiß nicht welche distributionen du verwendest, aber bei allen die ich in letzter zeit verwendet habe (debian, ubuntu, fedora), musste man rechtlich bedenkliche komponenten manuell nachinstallieren.
> warum nur rpm oder installer oder sourcen?
keine ahnung warum nur diese auf der HP sind (vermutlich weil der große unterstützer - novell - auch rpms verwendet), aber ubuntu hat z.b. eigene pakte die man einfach mit apt-get installieren kann.
> muss ich mir die vb und winforms usw mitdownloaden mit den sourcen und mitcompilieren
ich hab mono noch nicht selbst kompiliert, aber ich bin mir ziehmlich sicher dass das nicht notwendig ist.
> wird mono ein lib abhaengikeits gnome gau?
mono stellt dir eine plattform, und verschiedene komponeten (libs) zur verfügung. je nachdem welche libs du verwendest, wirst du abhängigkeiten haben. für eine konsolen app wirst du keine abhänigkeiten zu gnome brauchen. verwendest du GTK# für das GUI, dann hast du natürlich eine abhängigekeit zu GTK, verwendest du gnome spezifische funktionen, dann bekommst du eine abhängigkeit zu gnome ...
Jaja, G.W. alles Verschwöööörer hier. Sogar die Wikipedia ist Teil der Verschwörung!
"Die Erfolgsaussichten von Mono sind umstritten, da es Softwarepatente der Firma Microsoft berührt. Sollte Mono sich so verbreiten, dass es eine Gefahr für die Firma Microsoft wird, könnten Teile davon patentrechtlich verboten werden. Dieses Szenario trifft jedoch auch auf die alternativen Implementierungen von Java zu."
Sorry, aber meiner Meinung nach handeln die Gnome-Entwickler hier fahrlässig (es ist schon ein erheblicher Unterschied ob mein ein Patent wissentlich nach langer öffentlicher Debatte verletzt, oder ob man es unwissentlich trifft). Noch dazu kommt, dass mit der Unterstützung von .NET MS deutlich mehr geholfen ist als dem Linux-Anwender.
Yep! Das denke ich auch. Wenn M$ ohnehine nichts "feindliches" mit dot net vorhätte, dann könnten sie auch die Patente freigeben. Da sie es nicht tun... finger weg!
Irgendeine Distribution hat irgendein Softwarepaket neu aufgenommen. Und? Bei Suse gibt's Mono schon seit langem, war das damals eine eigene Nachricht wert?
Eins muss man Redhat lassen, ihre Marketingabteilung funktioniert sehr gut!
Das entscheidende ist, dass RedHat / Fedora bisher immer einen großen Bogen um Mono gemacht haben und die Verbreitung von Mono darunter gelitten hat. Die Tatsache, dass Mono nach nun mehreren Jahren doch von RedHat aufgenommen wird ist schon eine Nachricht wert, denn schließlich ergeben sich dadurch viele Fragen:
- Sieht RedHat keine Patentprobleme mehr, oder gibt es wirklich keine? - Wie wirkt sich das nun auf Mono und GNOME aus? - Wie stark wird RedHat selbst auf Mono setzen?
> [...] die Verbreitung von Mono darunter gelitten hat.
Ach, ich glaube, es geht gar nicht so sehr um die Verbreitung von Mono, sondern um die Unklarheit, die GNOME insgesamt betroffen hat.
> Sieht RedHat keine Patentprobleme mehr, oder gibt es > wirklich keine?
Das ist eine berechtigte Frage. Ebenso könnte man allerdings auch fragen: Hat RedHat jemals welche gesehen oder gab es andere Beweggründe?
> Wie wirkt sich das nun auf Mono und GNOME aus?
Es wird Mono-Anwendungen für GNOME geben. Dass GNOME an sich wirklich auf Mono setzen wird, bezweifle ich, aber es wird die Option für jedermann geben, die komplette Funktionalität der GNOME-Bibliotheken in Mono-Anwendungen zu benutzen und davon auszugehen, dass fast jeder GNOME-Anwender diese Anwendungen ausführen kann.
> Wie stark wird RedHat selbst auf Mono setzen?
RedHat hat eine Menge Geld in Java investiert und wird das nicht "wegwerfen". RedHat hat auch eine Menge Geld in GNOME investiert und wird das ebenfalls fortsetzen.
ok, da gebe ich Dir Recht. Die Unklarheit ist wirklich das Hauptproblem. Außerdem ist es immer der Beigeschmack von Microsoft, weshalb sich viele nicht an Mono trauen, oder es zumindest nur ungerne im Linux-Lager sehen.
RedHat hat bisher primär auf Java gesetzt. (Eclipse, GCJ usw.). Vielleicht war das der Grund, weshalb sie auf Mono verzichten wollten. Aber die Anwendungen für Mono zwingen sie gewissermaßen, dass sie Mono mitliefern. Ich persönlich hätte eigentlich nicht gedacht, dass Mono jetzt schon in Fedora zu finden sein wird, aber so kann man sich täuschen :)
Solange Mono weiterhin den Ruf hat, dass es eine Microsoft-Technologie implementiert und Microsoft jederzeit den Hahn zudrehen kann, wird Mono in GNOME-Kreisen immer etwas Probleme haben und sicher nie in Gnome Core einfließen. Aber warten wir mal ab. Diese Nachricht hat mich ja schließlich auch überrascht :)
> Solange Mono weiterhin den Ruf hat, dass es eine Microsoft-Technologie implementiert und Microsoft jederzeit den Hahn > zudrehen kann, wird Mono in GNOME-Kreisen immer etwas Probleme haben und sicher nie in Gnome Core einfließen.
ich denke nicht dass es große probleme durch den ruf geben wird. die leute die das entscheiden sollten das entsprechnde wissen haben, und nicht auf basis von foren-flames entscheiden. ich denke auch nicht dass es noch lange daueren wird bis mono (mit den enstprechenden bindings) eine offizelle komponente von gnome wird. mit redhat ist eigentlich der letzte große gnome-supporter und mono gegner "gefallen". wenn man auf gnome.org herumsurft wird mono öfters erwähnt, und das nicht negativ.
...Es geht um Fedora und nicht um RedHat. Es geht um Mono/C# vs. GCJ/Java und nicht um ein Softwarepaket. Es geht darum, welchen Weg Gnome/Linux geht/gehen-wird. Vergleichbar mit der Diskusion vor ca. 6 Jahren KDE vs. Gnome.
> Irgendeine Distribution hat irgendein Softwarepaket > neu aufgenommen.
Sorry, ganz so einfach ist es nicht.
Es ist nicht "irgendein" Softwarepaket. Es ist ein umfangreiches und vielversprechendes Softwarepaket, das in der Vergangenheit in einem Bereich, der Dich persönlich möglicherweise nicht besonders interessiert, für einiges an Unfrieden gesorgt hat, der jetzt möglicherweise wegfallen wird.
Ja, ich meine GNOME und ich weiß, dass Du KDE-Benutzer bist und dass KMail in den letzten Jahren keine einzige Sicherheitslücke hatte. Es muss Dich persönlich auch nicht mal ansatzweise interessieren - es geht halt darum, dass es vielleicht für andere doch nicht ganz so unwichtig ist.
> Bei Suse gibt's Mono schon seit langem, war das > damals eine eigene Nachricht wert?
Nein, war es nicht, das hatte damals aber auch wesentlich weniger Relevanz als Nachricht, weil es einfach keine Nachricht war, da es klar war.
Wenn Mono fester Bestandteil von Gnome wird, ist es Zeit zu Fluxbox oder anderen Alternativen zu wechseln! Sollten auch GTK-Programme verMONOt werden muss ich wohl oder über wieder zu QT-Alternativen wechseln...
> Wenn Mono fester Bestandteil von Gnome wird, ist es Zeit zu Fluxbox oder anderen Alternativen zu wechseln! > Sollten auch GTK-Programme verMONOt werden muss ich wohl oder über wieder zu QT-Alternativen wechseln...
Wieso "wohl oder übel"? Die sind doch eh moderner und leistungsfähiger, wenn ich das richtig sehe.
Mono ist nach meinen Erfahrungen (und der der Tester im Linux-Magazin) so buggy, dass die Entwickler von Beagle et. al. schon wahre Künstler der Fast-Hack-Programmierung sein müssen. Die würden auch mit Ook! was herausbringen ;-)
Mehr als einfache Konsolen-Anwendungen und einfache GUIs lassen sich mit Mono auch heute (und wohl auch die nächsten Jahre) nur sehr schwer machen. Was noch am besten funktioniert, ist die integrierte IKVM. Aber die bringt halt auch nicht ganz das von der SUN-JVM und macht deswegen auch nicht viel Spaß. Ausserdem, wer will in Java programmieren, wenn er eine .NET-Implementierung testet? Mit WIRKLICH viel gutem Willen und Vorsätzen (wer will nicht was mit ner coolen neuen freien Technologie machen?) hab ich das im Halbjahresrythmus immer mal wieder installiert und ausprobiert - und nach ein paar Tagen mit Kopfschütteln und dem Schwur "Die kriegen mich nicht noch einmal ..." deinstalliert.
"Miguel de Icaza hinterläßt grosse Sprüche und angefangene Frameworks ..."
Wers nicht glaubt, soll mal selbst probieren, damit etwas Größeres als einen Tausendzeiler gut hinzubekommen. Da muß man schon ein großer Masochist vor dem Herrn sein, wenn man das durchhält ohne Schreikrampf.
Ach ja, noch ein Wort zur hier oft in den Zeugenstand berufenen ECMA: Das ist keine Standardisierungs-Organisation, sondern eine Hure, die für Geld alles tut (Wikipedia diplomatischer: "Ecma International versteht sich als Organisation von der Industrie für die Industrie"). Schon seit Jahren ohne Reputation (falls überhaupt jemals) - was man als Standardisierer ja wohl dringend braucht. Zuerst ECMAScript (wenn ich höre, Flash bzw. ActionScript sein ja ECMA-zertifiziert und deswegen sei Flash ein Web-Standard so gut wie HTML oder CSS, wird mir schlecht), dann C# und weitere patentierte (!) Teile von .NET; als nächstes kommt jetzt dann das patentierte "Office Open XML" (richtig, M$ Antwort auf das freie ODF!) als ECMA-Standard!! Und dann wird wohl noch Windows Longhorn als OS zum (zum Glück nur ECMA-)Standard erhoben oder was? Ums mal Wikipedia sagen zu lassen: "Kritisch könnte man auch formulieren, Ecma stelle nicht so hohe Ansprüche, insbesondere an eine bereits vorhandene Verbreitung oder (politische) Unterstützung von eingereichten Standards."
Wer sich hinter solchen "Standards" versteckt, steht sehr sehr nackt da...
KDE mit QT - Gnome mit Mono? Mahlzeit! Ich nehm xcfe und sch* auf die großmäuligen Bullshiter: Ist doch immer das gleiche: Kaum stellt sich ne Firma hinter ein freies Produkt, kommt bald die häßliche Fratze durch: "Vergesst alles andere - wir sind die besten, die einzigen!". Siehe JBoss. Ellenbogen-Gesellschaft in der Community? Glückwunsch, nicht bestanden. "Die zwei grossen Linux-Desktops". Lach ich über - in fünf Jahren wird sich kaum noch wer dran erinnern. Wenn doch, ist es immer noch nix mit Linux aufm Desktop geworden bis dahin... Groß? Nö, fett! Und schrecklich, v.a. Gnome. Da geb ich Linus schon recht. Wenn sie gut wären, würde sich ja auch mal ein Mac- oder ein Windows-Benutzer nach dem "grossen" Dektop sehnen - hab ich noch nie beobachten können - verständlicherweise, wenn man ehrlich ist.
Welche Firma steht hinter Mono? Ach ja, Novell, nein dazu sag ich jetzt nichts mehr - das haben schon andere. Oder ist hier jemand, der meint, SuSE selbst (also nicht der Kernel oder das ein oder andere Programm) sei seit Version 8 besser geworden? Naja, irgendwozu muss Novell ja seine 500 000 000 $ von Onkel M$ ja benutzen. Naja, nun lassen wir Mono, Novell und Miguel mal wieder ihre Ruhe - von irgendwas muss er seine Kinder ja auch füttern ... für seine Programme würde ihm wohl kaum wer Geld geben, wenn sie nicht eh umsonst wären. Umsonst und kostenlos.
Die Qualität der Software hängt immer von der Programmierung ab.
Ein Programmierer kann vielleicht mit Assembler ein besseres Programm erzeugen als
ein anderer mit C#, aber das dauert auch sehr viel länger.
Behauptung:
Mit C# lassen sich gute Programme einfacher entwickeln als mit C oder C++.
Sie sind ein wenig langsamer, aber aufgrund der Architektur sicherer (Was nicht
bedeutet, dass man mit C/C++ keine sicheren Programme schreiben kann. Da bedeutet
es einfach mehr Aufwand)
Ich bin gerne für Alternativen offen. Und Smalltalk wollte ich mir auch schon mal ansehen.
Naja, das Lernen von Ruby wird mir vorläufig genug Arbeit geben. Wenn ich irgendwann mal zuviel Zeit haben sollte...
Im übrigen ist C++ genau wie C# auf der .Net Platform lauffähig.
> C++ ist streng genommen nur binderkompatibel zu C
Trotzdem bleibt der Nachteil gegenüber C#: unmanaged Code.
> Im übrigen ist C++ genau wie C# auf der .Net Platform lauffähig.
Ok, prinzipiell vielleicht schon. Nur dass managed C++ in Mono nicht unterstützt wird. Oder? Klärt mich bitte auf, wenn ich falsch liege.
Ausserdem müsste "prinzipiell" sogar C unter .NET lauffähig sein.
... oder vorteil! Das kann man drehen und wenden wie man will.
Und die Gleichung "Höhere Programmiersprache == Bessere Programme" kann ich überhaupt nicht leiden! Das ist nämlich irrsinn.
Man kann Open Office auch in Assembler nachprogrammieren und es besser zu machen als das Original. Nur wird das keiner versuchen. Ich bin halt der Meinung, dass es langsam Zeit wird, auf managed Code umzusteigen, auch gerade in der Linuxwelt und auch gerade in systemnaher Programmierung. Es ist nur eine Frage der Zeit, bis der Performance-Unterschied zwischen einem GCC und dem MC (Monocompiler) minimal sein wird, oder zumindest nicht merklich spürbar.
>
Die Regel (nicht Gleichung) lautet "höhere Programmiersprache -> leichter wartbare Programme". Denn letztendlich wird aller Quellcode in Binärcode übersetzt und das ist dann das Programm - völlig unabhängig von der Programmiersprache. Arbeite Dich mal in ein C-Programm ein, was aus einigen Dutzend Dateien mit je 10.000 Zeilen Code + Dutzende Headerdateine besteht. Da macht sich Objektorientierung bemerkbar - solche Programme sind leichter zu verstehen und damit findet man auch schneller Fehler.
ja bitte gib mir einne garbage collector,ich liebe overhead ;)
schlaue allokatoren tuns auch...smart pointer tun ihr uebrigens,wer nich mit klarkommt kann weder in c++ noch in C# vernuempftig coden ;)
ok in C# gibt es keinen segfaults,aber speicherluecken oder zu frueh/spaet geschlossene handles sind immernoch da...
zumal ich fuer ne sprache die mehr abstrahiert als C kein bloatVM brauche,das geht auch direkt zu native code. (gcj,ocaml,gcl,sbcl (ist keine vm!))
Was meinst du überhaupt mit "schlauen Allokatoren"? Oder "Smart Pointern"? Für mich klingt das eher nach Sicherheitsnetzen, um schlechte Sprachen erträglich (und weniger fehleranfällig) zu machen.
Der Overhead eines Garbage-Collectors ist heutzutage nun wirklich vernachlässigbar, er beseitigt aber einige Bugs, die in C/C++-Programmen immer wieder auftreten.
Und der Vorteil einer VM liegt darin, daß man in gewissen Grenzen plattformunabhängig sein kann. Ohne das Binary neu zu compilieren. Das mag für C# jetzt nicht so sehr zutreffen wie für Java, aber immerhin. Wenn Mono jetzt noch ein bißchen mehr Wert darauf legen würde, kompatibel zu .NET zu sein, dann wäre es ja endlich auch mal brauchbar.
Und erzähl mir bitte nicht, daß gcj eine brauchbare Alternative für Java darstellt. Bis die das nicht ins kleinste Detail nachimplementiert haben ist das eben nicht so.
Du hast ja eine gewählte Ausdrucksweise...
> Nicht umsonst bedienen sich beliebte C++-Toolkits wie Qt mehr und mehr auch bei Konzepten anderer Sprachen.
Java und C# sind ein Haufen Scheisse. Nicht umsonst bedienen sich Java und .Net bei Konzepten die es unter dem eleganteren C++ schon seit Jahren gibt (z.B. Templates)
> Der Overhead eines Garbage-Collectors ist heutzutage nun wirklich vernachlässigbar,
> er beseitigt aber einige Bugs, die in C/C++-Programmen immer wieder auftreten.
Ist der Garbage Collector nicht auch nur ein Sicherheitsnetz damit auch schlechte Programmierer einen Job finden?
Ansonsten benutze ich unter C++ fast gar keine heap objects.
Irgendwie muss ich an die Zeit denken, als Programmierer noch echte Kerle waren:
Echte Programmierer
:-)
Aber mal im Ernst: Ich bin froh, dass ich C und C++ im Studium gelernt habe. Aber ich
möchte managed Code wie in C# oder auch in Ruby nicht mehr missen.
Wenn du das anders siehst, dann steht dir nichts im Wege, dich bis an dein Lebensende
mit wilden Pointern und Stackoverflows zu beschäftigen
Ich bin zwar kein wirklicher C++ Programmierer, aber wenn man die Mono-Libraries alle in C++ verwenden koennte, wuerde es das doch wesentlich interessanter machen. Gaebe es dabei Geschwindigkeitseinbussen, d.H. wuerde das dann genau so schnell laufen wie ein C#-Programm, oder schneller?
Entschuldige, wenn ich mich hier einmische, aber das ist nicht die ganze Wahrheit: Ein ''Hello World'-Programm nützt niemandem, selbst wenn die Qualität gut sein sollte. Zum Schreiben nützlicher Software braucht es heutzutage meist mehr als einen Programmierer, und da klappt es nicht. Es mangelt an Koordination und Zusammenarbeit. Das wird auch Mono nicht ändern. Vielleicht wird Mono die Situation sogar noch verschlimmern.
Ein Beispiel: Ich war mal auf der Suche nach einem Outliner -- eigentlich ein recht simples Programm. Da sind mir zwei Kandiaten entgegengekommen, die beide in GTK+ und Python geschrieben waren. Der eine hatte volle Desktopintegration, konnte aber sonst nichts besonderes. Der andere hatte zumindest eine Exportfunktion für Webpräsentationen, aber keine Integration in den Desktop. Beide hatten Webseiten, machen Werbung auf Freshmeat, und beide sind inzwischen auch mehr oder weniger tot. Ja, und mit beiden habe ich meine Zeit verschwendet und andere wird es wahrscheinlich ähnlich gehen.
Solchen Wahnsinn wird auch C# an sich nicht stoppen. Das wird allenfalls durch eine Integration von Mono/C# in GNOME erreicht, und das auch nur, weil Miguel de Icaza es schafft, die Leute mit seinen Ideen zu begeistern.
> Assembler ein besseres Programm erzeugen
> als ein anderer mit C#, aber das dauert
> auch sehr viel länger.
Nicht nur das: Er wird auch mehr Fehler machen und niemand außer ihm selbst wird den Code warten können. Von Portabilität wollen wir gar nicht erst reden
Momentan ist Mono eher ne Krankheit:-)
Gerade im Bereich GUI kannst du das ganze Mono zeugs mometan vergessen.
Komisch nur, dass das ganze Mono Zeugs auch im Bereich GUI bei mir gut funktioniert. Ich benutze Banshee, Tomboy, F-Spot und Beagle und alle diese Programme funktionieren einwandfrei.
Was mache ich falsch?
Ganz einfach, Du benutzt Mono und das will Dein Vorredner nicht, deshalb erfindet er einfach irgendein Bashing gegen Mono.
Eine "Krankeit" ist nicht Mono, sondern die infantilen Erfindereien und Bashings in Internetforen.
Wenn den Leuten etwas nicht gefällt, dann sollen sie es einfach direkt sagen. Etwa so: "Ich finde Mono doof und deshalb sollst Du es nicht benutzen."
Bei mir laufen Mono-Anwendungen übrigens auch gut. Ja, auch solche mit GUI.
Aber leider ist Mono bisher noch ne Krankheit. Nur weil ein paar Jungs wie du ein paar So Freeware Programe alle Winload mein erstes Programm benutzen, die unter Mono laufen, heißt das noch lange nicht, dass da auch richtige Software mit läuft.
Ich hab ca 5 Anwendungen hier, die unter Windows absolut stabil und zuverlässig laufen unter Mono funktioniert nicht eine der 5.
Es ist ja gut möglich, dass deine Anwendungen die extra um die Bugs von Mono drum herum gebaut sind gut funktionieren, aber das heißt nicht, dass Mono so funktioniert wie es das NET Framework unter Windows tut.
Mono ist kein 1:1 .Net für GNU/Linux!
Mono ist ein Framework auf der Basis des ISO/ECMA Standards der CLI und C#.
Windows.Forms, ADO.Net, ... sind "nur" Teil eines kompatibilitäts Stacks, der eine gewisse Durchlässigkeit windows -> GNU/Linux erlauben sollen (100% wird das nie werden).
Wenn man cross-platform Programmieren will, dann sollte man Mono (ohne kompatibilitäts-stack) verwenden. Denn Mono ist im Gegensatz zu .Net ein cross-platform framework.
Wenn man natürlich mit jedem möglichen windows-schnickschnack auf deren propprietären und _nicht_ plattformunabhängigen Framework programmiert, kann man nicht von einem anderen Framework erwarten, dass dieses zaubern kann und die proprietäre windows API 1:1 auf GNU Systeme abbildet.
Weisst du überhaupt was die Windows API ist?
Genau solltest du seit .NET nicht mehr oft benötigen, siehe dazu z.B. MSDN:
""In Visual Basic 6.0, the Declare statement was used to call the Windows API in order to access functionality not provided by Visual Basic. In Visual Basic .NET, the need to access the Windows API is greatly diminished because much of the functionality of the Windows API is wrapped up in the .NET Framework.""
Außerdem, glaubst du, dass ich beim übersetzen unter Linux solche Funktionen nicht erkennen und umschreiben könnte, sind ja schließlich von mir geschrieben die Programme:-)
Irgendwie hab ich das Gefühl hier sind wieder lauter 1.Semestler unterwegs die wieder mit ihrem Halbwissen glänzen möchten
>Weisst du überhaupt was die Windows API ist?
Genau solltest du seit .NET nicht mehr oft benötigen,
und was ist .Net? Eine API die es nur auf windows gibt und damit vielleicht nicht "die Windows API" aber sicher eine "windows API".
Nur weil etwas auf einer VM(CLI) beruht ist es noch lange nicht Plattformunabhängig, auch auf einer VM(CLI) kann es APIs geben die nur auf einer Plattform wirkich 100% laufen und das ist nunmal so bei .NET.
Wenn du Plattformunabhängig programmieren willst, dann solltest du also APIs verwenden die es auch Plattformunabhängig gibt. Auf der Basis von C#/CLI gibt es da z.B. Mono. Jedes Programm, dass du unter windows mit der Mono/C# API schreibst, läuft garantiert auch problemlos unter GNU/Linux, da es da eben auch Mono gibt. Andersherum, wenn du unter GNU/Linux arbeitest, dann mußt du aufpassen, dass du keine GNU/Linux spezifische APIs verwendest, z.B. der ganze GNOME. Bereich.
Du kannst unter windows, natürlich auch mit .Net arbeiten, wenn du aber willst, dass das ganze dann auch unter GNU/Linux läuft, dann solltest du aufpassen, dass du keine windows spezifische Sachen verwendest...
Cheers,
Kris
Sorry Leute, aber ihr habt sie echt nimmer alle ..
> diskutabel sein mag) Werkzeug da helfen?
Wenn ich einen String in einer gut les- und verstehbaren Zeile manipulieren kann statt in fünf Zeilen mit kryptischen Low-Level-Funktionen, dann ist die Chance, Bugs und Sicherheitslücken einzubauen, bei zweiterem natürlich höher. Und erzähl mir nicht einem guten Programmierer passiert das nicht. Es passiert ständig bei aller möglichen Software, wie man bei Security-Warnungen überall beobachten kann.
Oder hacken an Openssh, OpenOffice, Gnome, Linux-Kernel, Windows, [insert your favourite C/C++-based Software here] usw. nur Anfänger? Wohl kaum.
Mit gut getesteten IO- und String-Klassen z.B. können viele Buffer-Overflow-Fehler gar nicht erst auftreten, weil die Low-Level-Details hübsch gekapselt werden, so dass dem Anwendungsentwickler viele Fehler gar nicht mehr passieren können.
Außerdem ist "abstrahierender" Code besser zu lesen und zu verstehen und damit besser zu warten.
Und natürlich: Ohne passende Werkzeuge ist auch der beste Handwerker aufgeschmissen.
Ich übertrage es mal aufs Häuser bauen:
Niemand nimmt einzelne Backsteine und baut daraus einen Wolkenkratzer. Man nimmt größere Komponenten mit bekannten, getesteten Eigenschaften.
eure anwendungen werden aber zu 90% laufen, somit ist eine migration auf windwos immer noch billiger als auf eine andere programmiersprache / framework.
oder xxxx $ lizenzgebuehren bezahlen, damit wir die die patentanwaltskosten und schmiergelder wieder reinbekommen.
oder soll man sich was anderes erwarten?
ich wuerds freiwillig nicht riskieren, ausser der auftraggeber wuenscht es ausdruecklich
Trotzdem: Mono ist die Implementation einer ECMA-Spezifikation und somit Gegenstand der ECMA-Patentrichtlinien, die der Implementation als Freie Software ebensowenig zuwiderlaufen wie der Verwendung im GNOME-Projekt.
das sich meine meinungen tw mit diversen Kampagnen unterschielicher Lager deckt mag sein, aber ich mach keine Meinungskampagne.
"wir werden daruf entsprechend reagieren wenns so weit ist" gibt keine technologische sicherheit.
patent problem entsteht, zeitraum X bis loesung, was ist waerend zeitraum X? meine apps idln dahin, oder wie?
ist eine app von mir irgendwo im einsatz und ich stopp sie nicht, wed ich dann verklagt/abgemahnt wegen patentmissachtung?
so versteh ich die problematik, aber event hab ich mir die Mono FAQ nicht gruendlich genug durchgelesen.
oder ich bin zu wenig anwalt damit ich diese problematik verstehe.
gross ankuendigen das es keine probleme geben wird ist, mMn, ein bissl wenig, glaub ich erst wenn ichs gesehen hab.
steht in der meldung irgendwo das ich als entwickler deffinitiv nix zu befuerchten hab wenn ich mono verwend?
Sorry, aber ich verstehe es einfach nicht. Was eine ECMA-Standardisierung im Hinblick auf bereits bestehende Patente bedeutet, ist bei der ECMA nachzulesen. Ansonsten gilt im Wesentlichen, dass man sich von denjenigen Dingen, die über den ECMA-standardisierten Teil hinausgehen, besser komplett fernhält.
Was den GNOME-bezogenen Teil von Mono angeht, ist das bereits der Fall. Darüber hinaus gibt es auch Bemühungen, die Windows Forms und weiteres zu implementieren. Das ist in der Tat problematisch und gefällt mir auch nicht, aber es gefährdet GNOME nicht.
Im Übrigen: GTK wird immer ein Toolkit mit *wirklich* vielen Sprachanbindungen bleiben und auch für GNOME-Bibliotheken wird es immer viele Sprachanbindungen geben. Niemand, der Anwendungen für GNOME entwickeln will, ist in irgendeiner Weise genötigt, C# oder andere .NET-bezogene Techniken zu nutzen.
tschuldigung
so wie ich das seh (achtung, persoenliche meinung, keine kampagne) wird mono als plattformuebergreifendes dotNet angepriesen
in wahrhei solls aber eine neue basis fuer gnome werden, (weil man mit C an den (entwickler resourcen) grenze angekommen ist?) und man den leuten den umstieg erleichtern will die dotnet gewohnt sind, und das eben mit C# leichter faellt als mit C und GTK.
wer funktionalitaet darueber hinaus verwendet tut das auf eigenes risiko.
(hoffendlich bringt wenigstens der compiler entsprechende warnings bei verwendung von funktionen die nicht unbedenklich sind)
mir persoenlich ist das alles zu kompliziert und unklahr, einfach und transparent ist da gar nix.
ein verlgeich zu anderen libs/frameworks die man verwenden kann hinkt da gewaltig.
waere schoen wenns da eine klare und uebersichtliche klarstellung geben wuerde die leuten wie mir einiges kurz und verstaendlich erklaehrt.
die mono faq sind nicht geeignet meine bedenken zu zerstreuen bzw erklaehren die mir nicht wofuer ich mono einsetzen kann ohne mir gedanken zu machen ob ichs ausliefern darf, probleme bekommen koennt usw.
sollts so ein nachlese geben ueber einen url waer ich wirklich dankbar.
warum das so gemacht wird verstehe ich auch nicht wirklich, ist wohl eher marketing. technische gesehen kann man mono wohl nicht wirklich als .net implementation bezeichnen, da fehlen einfach noch zu viele komponenten. selbst wenn es mal viele andere .net komponenten gibt bleibt in den USA immer noch die patentfrage offen (in europa muss man sich zum glück keine sorgen um patentprobleme machen). selbst wenn es dadurch (implementierung von nicht standardisieren komponeten) für die internationale vermarktung von programmen uninteressant wird, so bleibt es immer noch eine alternative für kleine entwickler außerhalb der USA. selbst zur migration nach linux könnte es helfen, wenn (bestimmte) .net programme auch unter linux laufen, denn - ich schreibe es nochmals - in europa gibt es keine software-pateten weshalb man sich hier auch keine sorgen darum machen muss.
> in wahrhei solls aber eine neue basis fuer gnome werden
zur zeit sieht es so aus. aber ich denke nicht dass das auf gnome beschränkt bleiben wird. mono füllt eine lücke die bis heute da war: es bietet eine OS möglichkeit programme schneller und sicherer als in c/c++ zu entwickeln, und bietet dabei bessere performance als eine skripsprache.
> hoffendlich bringt wenigstens der compiler entsprechende warnings
warum sollte er das? es gibt unter linux auch genung andere rechtliche bedenkliche bibliotheken (z.b. so ziehmlich alles was mit mp3s oder verschlüsselten DVDs zu tun hat), trotzdem hab ich noch nie eine entsprechende warung von gcc gesehen. soetwas sehe ich nicht als mono spezifisches problem an, dieses existiert generell in der softwareentwicklung, egal ob des ich um eine mono bibliothek oder eine c-lib handelt.
> mir persoenlich ist das alles zu kompliziert und unklahr, einfach und transparent ist da gar nix.
> ein verlgeich zu anderen libs/frameworks die man verwenden kann hinkt da gewaltig.
für mich das es klar (und so ist es auch im mono faq beschrieben). der standardisierte teil von .net ist rechtlich unbedenlich. alles andere sind libs die auf diesen aufbauen, und man muss sich wie bei jeder anderen lib informieren ob und wie man diese einsetzen darf. verwendest du z.b. gtk# brauchst du dir keine sorgen machen, stetzt du für deine gui winforms ein, dann könnte es probleme geben wenn du in den USA rechtlich greifbar bist.
warum der verglich hinken soll verstehe ich nicht, aber vielleicht kannst du das ja noch genauer erklären ...
das der compiler warnungen bringen soll war halb als witz gemeint, aber nur halb.
wuerds zB bringen wenn ich eine fremd app hab und nicht die src durchgehen will, einmal compilieren und ich weis ob bedenkliche teile enthalten sind.
die einteilung in freie mono componenten und nicht freie mono componenten ist fuer ich nicht leicht ersichtlich.
meiner ansicht nach fehlt da im bereich dokumentation einiges.
vorallem weil davon auszugehen ist das mono mit *yourpackagetool* install mono installiert wird, und einige leute sich nicht gedaken machen was da jetzt alles bedekenlos zu verwenden ist.
und wenn ich schon beim raunzen und fragen bin und es hier anscheinend leute gibt die es event wissen koennten:
warum nur rpm oder installer oder sourcen?
muss ich mir die vb und winforms usw mitdownloaden mit den sourcen und mitcompilieren
gibts nicht einfach ein paar archivpackete die ich mir mal nach ~/test entpack damit ich mono mal testen kann + anleitung fuer enviromentvariablen (event in zukunft auch unterschiedliche versionen davon fahren zu koennen)
wird mono ein lib abhaengikeits gnome gau?
(die frage wird dann interessant wenn man mono apps zb tatsaechlich mal ausliefern will zb mit einer monoversion die mit der app getestet ist)
eine java installation erscheint mir ja da wie ein kinderspiel (nein das ist kein java vs mono flame, ich programmier nicht mal in java, nur persoenliche meinung)
> eine patentverletzung und wenn wir geklagt werden sehen wir weiter.(ok, libdvdcss usw nehm ich mal aus, aber die
> verwend ich eher nie in projekten(bis dato))
und wo ist jetzt der unterschied zu mono?
beim mono projekt riskieren das auch nur ein paar libs. verwendest/programmierst du eine GTK# app (wie z.b. fspot) brauchst du dir auch sicher keine sorgen um patente zu machen (jedenfalls nicht mehr als mit GTK+). einfach zu sagen betroffene nicht mono libs nehm ich einfach mal aus dem vergleich aus ist nicht sinnvoll.
> die einteilung in freie mono componenten und nicht freie mono componenten ist fuer ich nicht leicht ersichtlich.
hab den link nicht zur hand, aber irgendwo auf der mono seite gibt es einen grafik in der standardisierte komponeten, eigentwicklungen und nachbauten in unterschiedlichen farben gekennzeichnet werden.
aber die betroffenen libs sind ja sowieso offensichtlich, praktisch alle windows spezifischen komponenten können zum problem werden (das gibt aber nicht hier in europa).
> vorallem weil davon auszugehen ist das mono mit *yourpackagetool* install mono installiert wird, und einige leute
> sich nicht gedaken machen was da jetzt alles bedekenlos zu verwenden ist.
ich weiß nicht welche distributionen du verwendest, aber bei allen die ich in letzter zeit verwendet habe (debian, ubuntu, fedora), musste man rechtlich bedenkliche komponenten manuell nachinstallieren.
> warum nur rpm oder installer oder sourcen?
keine ahnung warum nur diese auf der HP sind (vermutlich weil der große unterstützer - novell - auch rpms verwendet), aber ubuntu hat z.b. eigene pakte die man einfach mit apt-get installieren kann.
> muss ich mir die vb und winforms usw mitdownloaden mit den sourcen und mitcompilieren
ich hab mono noch nicht selbst kompiliert, aber ich bin mir ziehmlich sicher dass das nicht notwendig ist.
> wird mono ein lib abhaengikeits gnome gau?
mono stellt dir eine plattform, und verschiedene komponeten (libs) zur verfügung. je nachdem welche libs du verwendest, wirst du abhängigkeiten haben. für eine konsolen app wirst du keine abhänigkeiten zu gnome brauchen. verwendest du GTK# für das GUI, dann hast du natürlich eine abhängigekeit zu GTK, verwendest du gnome spezifische funktionen, dann bekommst du eine abhängigkeit zu gnome ...
"Die Erfolgsaussichten von Mono sind umstritten, da es Softwarepatente der Firma Microsoft berührt. Sollte Mono sich so verbreiten, dass es eine Gefahr für die Firma Microsoft wird, könnten Teile davon patentrechtlich verboten werden. Dieses Szenario trifft jedoch auch auf die alternativen Implementierungen von Java zu."
Sorry, aber meiner Meinung nach handeln die Gnome-Entwickler hier fahrlässig (es ist schon ein erheblicher Unterschied ob mein ein Patent wissentlich nach langer öffentlicher Debatte verletzt, oder ob man es unwissentlich trifft). Noch dazu kommt, dass mit der Unterstützung von .NET MS deutlich mehr geholfen ist als dem Linux-Anwender.
Und?
Bei Suse gibt's Mono schon seit langem, war das damals eine eigene Nachricht wert?
Eins muss man Redhat lassen, ihre Marketingabteilung funktioniert sehr gut!
- Sieht RedHat keine Patentprobleme mehr, oder gibt es wirklich keine?
- Wie wirkt sich das nun auf Mono und GNOME aus?
- Wie stark wird RedHat selbst auf Mono setzen?
Gruß
Mike
Ach, ich glaube, es geht gar nicht so sehr um die Verbreitung von Mono, sondern um die Unklarheit, die GNOME insgesamt betroffen hat.
> Sieht RedHat keine Patentprobleme mehr, oder gibt es
> wirklich keine?
Das ist eine berechtigte Frage. Ebenso könnte man allerdings auch fragen: Hat RedHat jemals welche gesehen oder gab es andere Beweggründe?
> Wie wirkt sich das nun auf Mono und GNOME aus?
Es wird Mono-Anwendungen für GNOME geben. Dass GNOME an sich wirklich auf Mono setzen wird, bezweifle ich, aber es wird die Option für jedermann geben, die komplette Funktionalität der GNOME-Bibliotheken in Mono-Anwendungen zu benutzen und davon auszugehen, dass fast jeder GNOME-Anwender diese Anwendungen ausführen kann.
> Wie stark wird RedHat selbst auf Mono setzen?
RedHat hat eine Menge Geld in Java investiert und wird das nicht "wegwerfen". RedHat hat auch eine Menge Geld in GNOME investiert und wird das ebenfalls fortsetzen.
ok, da gebe ich Dir Recht. Die Unklarheit ist wirklich das Hauptproblem. Außerdem ist es immer der Beigeschmack von Microsoft, weshalb sich viele nicht an Mono trauen, oder es zumindest nur ungerne im Linux-Lager sehen.
RedHat hat bisher primär auf Java gesetzt. (Eclipse, GCJ usw.). Vielleicht war das der Grund, weshalb sie auf Mono verzichten wollten. Aber die Anwendungen für Mono zwingen sie gewissermaßen, dass sie Mono mitliefern. Ich persönlich hätte eigentlich nicht gedacht, dass Mono jetzt schon in Fedora zu finden sein wird, aber so kann man sich täuschen :)
Solange Mono weiterhin den Ruf hat, dass es eine Microsoft-Technologie implementiert und Microsoft jederzeit den Hahn zudrehen kann, wird Mono in GNOME-Kreisen immer etwas Probleme haben und sicher nie in Gnome Core einfließen. Aber warten wir mal ab. Diese Nachricht hat mich ja schließlich auch überrascht :)
Gruß
Mike
> zudrehen kann, wird Mono in GNOME-Kreisen immer etwas Probleme haben und sicher nie in Gnome Core einfließen.
ich denke nicht dass es große probleme durch den ruf geben wird. die leute die das entscheiden sollten das entsprechnde wissen haben, und nicht auf basis von foren-flames entscheiden. ich denke auch nicht dass es noch lange daueren wird bis mono (mit den enstprechenden bindings) eine offizelle komponente von gnome wird. mit redhat ist eigentlich der letzte große gnome-supporter und mono gegner "gefallen". wenn man auf gnome.org herumsurft wird mono öfters erwähnt, und das nicht negativ.
> neu aufgenommen.
Sorry, ganz so einfach ist es nicht.
Es ist nicht "irgendein" Softwarepaket. Es ist ein umfangreiches und vielversprechendes Softwarepaket, das in der Vergangenheit in einem Bereich, der Dich persönlich möglicherweise nicht besonders interessiert, für einiges an Unfrieden gesorgt hat, der jetzt möglicherweise wegfallen wird.
Ja, ich meine GNOME und ich weiß, dass Du KDE-Benutzer bist und dass KMail in den letzten Jahren keine einzige Sicherheitslücke hatte. Es muss Dich persönlich auch nicht mal ansatzweise interessieren - es geht halt darum, dass es vielleicht für andere doch nicht ganz so unwichtig ist.
> Bei Suse gibt's Mono schon seit langem, war das
> damals eine eigene Nachricht wert?
Nein, war es nicht, das hatte damals aber auch wesentlich weniger Relevanz als Nachricht, weil es einfach keine Nachricht war, da es klar war.
Genausowenig wie ein Programm, das gtk verwendet, gleich ein Gnome-Programm ist, ist ein Mono-programm ein Gnome-Programm.
Warum mich mono also nicht interessieren sollte, nur weil ich KDE als *Desktop* einsetze, ist mir nicht ganz klar.
Aber scheinbar wird von manchen jeder Strohhalm genommen, um eine Gnome vs. KDE Diskussion anzuzetteln.
> Sollten auch GTK-Programme verMONOt werden muss ich wohl oder über wieder zu QT-Alternativen wechseln...
Wieso "wohl oder übel"? Die sind doch eh moderner und leistungsfähiger, wenn ich das richtig sehe.
--
(amaroK) now playing Alphaville - Big In Japan
xfce zb
Mono ist nach meinen Erfahrungen (und der der Tester im Linux-Magazin) so buggy, dass die Entwickler von Beagle et. al. schon wahre Künstler der Fast-Hack-Programmierung sein müssen. Die würden auch mit Ook! was herausbringen ;-)
Mehr als einfache Konsolen-Anwendungen und einfache GUIs lassen sich mit Mono auch heute (und wohl auch die nächsten Jahre) nur sehr schwer machen. Was noch am besten funktioniert, ist die integrierte IKVM. Aber die bringt halt auch nicht ganz das von der SUN-JVM und macht deswegen auch nicht viel Spaß. Ausserdem, wer will in Java programmieren, wenn er eine .NET-Implementierung testet?
Mit WIRKLICH viel gutem Willen und Vorsätzen (wer will nicht was mit ner coolen neuen freien Technologie machen?) hab ich das im Halbjahresrythmus immer mal wieder installiert und ausprobiert - und nach ein paar Tagen mit Kopfschütteln und dem Schwur "Die kriegen mich nicht noch einmal ..." deinstalliert.
"Miguel de Icaza hinterläßt grosse Sprüche und angefangene Frameworks ..."
Wers nicht glaubt, soll mal selbst probieren, damit etwas Größeres als einen Tausendzeiler gut hinzubekommen. Da muß man schon ein großer Masochist vor dem Herrn sein, wenn man das durchhält ohne Schreikrampf.
Ach ja, noch ein Wort zur hier oft in den Zeugenstand berufenen ECMA: Das ist keine Standardisierungs-Organisation, sondern eine Hure, die für Geld alles tut (Wikipedia diplomatischer: "Ecma International versteht sich als Organisation von der Industrie für die Industrie").
Schon seit Jahren ohne Reputation (falls überhaupt jemals) - was man als Standardisierer ja wohl dringend braucht. Zuerst ECMAScript (wenn ich höre, Flash bzw. ActionScript sein ja ECMA-zertifiziert und deswegen sei Flash ein Web-Standard so gut wie HTML oder CSS, wird mir schlecht), dann C# und weitere patentierte (!) Teile von .NET; als nächstes kommt jetzt dann das patentierte "Office Open XML" (richtig, M$ Antwort auf das freie ODF!) als ECMA-Standard!! Und dann wird wohl noch Windows Longhorn als OS zum (zum Glück nur ECMA-)Standard erhoben oder was?
Ums mal Wikipedia sagen zu lassen: "Kritisch könnte man auch formulieren, Ecma stelle nicht so hohe Ansprüche, insbesondere an eine bereits vorhandene Verbreitung oder (politische) Unterstützung von eingereichten Standards."
Wer sich hinter solchen "Standards" versteckt, steht sehr sehr nackt da...
KDE mit QT - Gnome mit Mono?
Mahlzeit!
Ich nehm xcfe und sch* auf die großmäuligen Bullshiter: Ist doch immer das gleiche: Kaum stellt sich ne Firma hinter ein freies Produkt, kommt bald die häßliche Fratze durch: "Vergesst alles andere - wir sind die besten, die einzigen!". Siehe JBoss. Ellenbogen-Gesellschaft in der Community? Glückwunsch, nicht bestanden.
"Die zwei grossen Linux-Desktops".
Lach ich über - in fünf Jahren wird sich kaum noch wer dran erinnern.
Wenn doch, ist es immer noch nix mit Linux aufm Desktop geworden bis dahin...
Groß? Nö, fett! Und schrecklich, v.a. Gnome. Da geb ich Linus schon recht. Wenn sie gut wären, würde sich ja auch mal ein Mac- oder ein Windows-Benutzer nach dem "grossen" Dektop sehnen - hab ich noch nie beobachten können - verständlicherweise, wenn man ehrlich ist.
Welche Firma steht hinter Mono?
Ach ja, Novell, nein dazu sag ich jetzt nichts mehr - das haben schon andere.
Oder ist hier jemand, der meint, SuSE selbst (also nicht der Kernel oder das ein oder andere Programm) sei seit Version 8 besser geworden?
Naja, irgendwozu muss Novell ja seine 500 000 000 $ von Onkel M$ ja benutzen.
Naja, nun lassen wir Mono, Novell und Miguel mal wieder ihre Ruhe - von irgendwas muss er seine Kinder ja auch füttern ... für seine Programme würde ihm wohl kaum wer Geld geben, wenn sie nicht eh umsonst wären.
Umsonst und kostenlos.
Sersn.