Eerste beta van open source .NET-implementatie Mono

Novell heeft de eerste betaversie van het open-sourceproject Mono uitgebracht. Mono is een project waarbij geprobeerd wordt het .NET-platform te porten naar Linux en Unix-based besturingssystemen. De port is opgezet door softwarebedrijf Ximian, dat vorig jaar overgenomen werd door Novell. Sindsdien is het werk niet blijven liggen, maar werd het project onder de hoede van Novell verder gezet. Met Mono moet het voor software-ontwikkelaars mogelijk worden één applicatie te schrijven die op zowel Windows als Linux en Unix-platformen werkt, een belangrijk voordeel aangezien veel bedrijven verschillende systemen draaiend hebben. Microsoft zelf voorziet immers enkel in een framework voor Windows. Met behulp van de vrijgegeven specificaties van .NET wil Mono de andere platformen voor zijn rekening nemen. Deze eerste testversie werd oorspronkelijk eind 2003 verwacht maar moest uitgesteld worden. Als alles verder volgens planning gaat hoopt Novell een tweede betaversie klaar te hebben begin juni, om eind juni met een eerste stabiele versie te komen.

Reacties (62)

Ik vraag me af wat MS hier mee gaat doen? Ze kunnen alles en iedereen weer voor de rechter gaan slepen. Dat is het verleden van MS kennende wel gebruikelijk.

Wat mij slimmer lijkt is om het juist te gaan supporten. Dat hoeft niet verder te gaan dan je specs volledig open te maken.

Het wordt voor ontwikkelaars aantrekkelijker als de totale markt waarvoor ze ontwikkelen groter is. Op deze manier trek je Linux (en mac?) daar ook bij. MS heeft een goede reputatie bij ontwikkelaars dus als ze al hun marketing gewicht er in gooien dan komt het een flink eind. Daardoor kunnen ze namelijk wel elk ander cross-platform GUI gericht systeem de kop mee indrukken (lees: java). Dat is ook wel typisch MS.

Ik denk niet dat Microsoft er iets tegen gaat of wil doen. Ze hebben niet voor niets de specificaties vrijgegeven.
Microsoft wil met .NET bereiken dat zo ongeveer alles met elkaar kan communiceren. Weet men dit op Linux over te zetten dan is dat alleen maar gunstig voor Microsoft. Hoe populairder de .NET standaard wordt, hoe beter voor Microsoft, aangezien ze altijd een stapje voor zullen zijn op Linux. Mono zal altijd achter de feiten aanlopen aangezien het Microsoft is die de boel bepaald, maar tegelijkertijd zal Mono .NET helpen populair te worden op verschillende systemen. Het is zeg maar een win, win situatie.

Ik vraag me af wat MS hier mee gaat doen? Ze kunnen alles en iedereen weer voor de rechter gaan slepen. Dat is het verleden van MS kennende wel gebruikelijk.

Dat kunnen ze niet, zodra ze namelijk die rechtzaak winnen en .NET alleen geschikt is voor MS OS-en, dan maken ze misbruik van hun monopolie, en mogen ze waarschijnlijk .NET niet meer meeleveren en een schadeclaim gaan betalen. Dan zijn ze verder van huis, en weer een boel tegenstanders rijker.

Idd, microsoft is juist de laatste tijd vriendjes aan zijn met al zijn voormalige 'vijanden'. Ze moeten wel.

Mono werd trouwens ook genoemd in MSDN magazine .NET en daar waren ze er lovend over. Als microsoft er tegen zou zijn, zouden ze het niet promoten in MSDN magazine

Tevens betekent dit natuurlijk een groter draagvlak voor .Net en dat is alleen maar beter voor Microsoft.

MS heeft een goede reputatie bij ontwikkelaars

-1 generalisatie.

Ok iets genuanceerder:
MS heeft een ruime ervaring in het omgaan met onwikkelaars. Ze hebben eerder een aantal succesvolle ontwikkel omgevingen op de markt gezet, dus daarover hoor je weinig accuut sceptische reacties.

Visual C++ is toch een veel gebruikt product, en DirectX kan je toch ook wel geslaagd noemen.

JetBRAINS IntelliJ IDEA, CodeGuide, etc zijn toch veel gebruikte producten, en OpenGL kan je toch ook wel geslaagd noemen.

Niets anders dan Sun met het Java platform dat bijvoorbeeld door grootmachten als IBM en Oracle geadopteerd wordt.

Dit is redelijk positief voor Microsoft hoor. Software leveranciers die voor beide platformen ontwikkelen. De makers van Maya bv. En die nu terughoudend zijn tov .net omdat je dan voor Linux en Windows een zelfde programma gaat maken waarvan de code erg verschilt. Als beide met het .net platform ontwikkeld kunnen worden moet je de kosten van veel werk niet meer in rekening brengen in de afweging tussen de voordelen van .net en de prijs.

Ik heb gesproken met mensen binnen MS over Mono en ze juist heel erg blij met Mono.
Ik denk zelfs dat ze ook onderling goed contact hebben.

Voor mij is het gewoon een feest. Ik vind .NET heerlijk om mee te werken. Java vind ik ronduit bagger. Qua performance is Java nog steeds niet zo goed als .NET.

Ik heb verschillende dingen in Java gemaakt en voor mij was dat genoeg voor de rest van mijn leven.

Ik lees bijna alleen maar onzin hier

1) JAVA is niet meer traag, dit was vroeger zo. Tegenwoordig is er embedded JAVA en heb je toevallig wel eens de 3D desktop volledig JAVA gerendered gezien (Project looking glass)? Kom dan nog eens aan dat JAVA traag is.

2) Alhoewel JAVA nog steeds geinterpreteerd wordt, doet C# het niet veel anders. Alle talen worden eerst naar MSIL (MS Intermediate Language) vertaald en vervolgens door de JIT (Just in Time) compiler gecompileerd. Dit is praktisch hetzelfde als in JAVA, alleen heeft MS er nog een managed/unmanaged omgeving bijgebouwd.

3) Een krachtige .NET mogelijkheid is om de System.InteropServices te gebruiken. Dit houdt in dat je bestaande C, C++ en VB applicaties kunt integreren met managed .NET applicaties. Dat is op dit moment een major issue om over te stappen op .NET, omdat niet al het werk van de afgelopen 20 jaar wegggegooid hoeft te worden. Zelfs COM zooi kun je hergebruiken binnen .NET.

Mocht het MONO project slagen in de omzetting van de InteropServices namespace, dan voorzie ik een grote toekomst voor .NET op alle platformen. Zo niet dan blijven we met een "light" versie van .NET op andere systemen zitten en wordt het hoofddoel, compatibiliteit tussen beide systemen creeeren niet volledig gehaald.

2) Alhoewel JAVA nog steeds geinterpreteerd wordt, doet C# het niet veel anders. Alle talen worden eerst naar MSIL (MS Intermediate Language) vertaald en vervolgens door de JIT (Just in Time) compiler gecompileerd. Dit is praktisch hetzelfde als in JAVA, alleen heeft MS er nog een managed/unmanaged omgeving bijgebouwd.

Behalve dat een .NET-applicatie alleen de eerste keer dat hij op een bepaalde machine gedraaid wordt vertaald wordt. Na deze éénmalige actie hoeft er niets meer geinterpreteerd te worden en is er dus geen sprake meer van JIT.

Met Mono moet het voor software-ontwikkelaars mogelijk worden één applicatie te schrijven die op zowel Windows als Linux en Unix-platformen werkt, een belangrijk voordeel aangezien veel bedrijven verschillende systemen draaiend hebben.

Op mijn werk gebruiken we al een product waarmee je hetzelde kan, ik heb er b.v. applicaties mee ontwikkeld op een win2k machine die nu in op een AS/400 draaien, dezelfde applicatie zou zonder problemen onder Linux draaien.

Het tooltje heet overigens Java

Wat curry zegt is al absoluut waar (behalve misschien dat "niet vooruit te branden", java 1.4.x doet niet zo opvallend veel onder voor de sandbox van .NET), maar wat belangrijker is, is dat je voor Java afhankelijk bent van Sun en naar welke platforms zij hun JVM porten. Ja, je kunt ook zelf een JVM schrijven, maar als je nu toch al Mono hebt (wat op meerdere platforms compiled, C, isn't it lovely) ligt het natuurlijk voor de hand je bij de monopolie-volgende massa aan te sluiten.

Vaak had de wereld er beter uit kunnen zien als we met z'n allen zus of zo hadden gedaan, maar zolang Microsoft marktleider blijft, kun je maar beter zorgen dat je omgeving conformeerd, dan dat je zuiver puristisch en ideologisch alle overeenkomst uit de weg gaat.

zolang Microsoft marktleider blijft, kun je maar beter zorgen dat je omgeving conformeerd

Je moet eens in de 'echte wereld' gaan kijken wat er allemaal in Java draait (Vooral server-side), MS gaat er een flinke klus aan hebben om Java op de server voorbij te streven.

Ja en in Auto's draaien meer Linux derivaten dan Windows CE distribs, maar ik denk ook niet dat dat de hoofdzakelijke doelmarkt is. Volgens mij gaat het voor Mono vooral om desktop applicatie portability.

Op Servers kan Java het bijvoorbeeld nog niet winnen van native-code, maar betekend dat dan dat Java volkomen kansloos, danwel zinloos is?

Je moet eens in de 'echte wereld' gaan kijken wat er allemaal in Java draait (Vooral server-side)

Ga jij eens in de nog echtere wereld kijken hoe _VEEL_ in C wordt geprogrammeerd. Of wat dacht je van de hele hordes die nog in COBOL zitten te ploeteren?
Ik vind Java een geweldig platform om tijdens je opleiding te leren OO proggen, daarnaast zijn er vrij weinig toepassingen waarvoor Java de beste keus is.

En de JDK van IBM dan? En jikes dan? En gcj dan?


maar wat belangrijker is, is dat je voor .NET afhankelijk bent van Microsoft en naar welke platforms zij hun runtime porten. Ja, je kunt ook zelf een runtime schrijven, maar als je nu toch al Java hebt ligt het natuurlijk voor de hand je bij de massa aan te sluiten.

Is gcj een hele VM joh? Ik dacht dat het een compiler was, maar dat zal ik wel verkeerd begrepen hebben. Volgens mij is de JDK van IBM ook niet open source en volgens mij gaat dat ook niet gebeuren, omdat - staat me zoiets bij, maar is al wel weer een tijdje terug - Sun's licenties dat niet toestaat.

Mono is nu wel opensource en ik denk niet dat er primair naar serverland werd gekeken toen ze daaraan begonnen, maar naar het voorspelde "click here to download" gehalte van .NET gebaseerde tooltje, speeltjes en andere prut.

Kleine kanttekening over dominantie; M$ heeft ruzie gekregen met Sun (paar jaar terug) omdat de M$-VM naast de gespecificeerde instructies nog wat extra's bevatte en dat M$ er in slaagde het web te overspoelen met bytecode-only appletjes met die extra instructies. Die meuk draaide dus niet op de Sun-VM en dat zou nog geen probleem zijn, ware het niet dat M$ nou eenmaal zo'n gigantische invloed op de webwereld uit kan oefenen. Zo ook kunnen ze dat natuurlijk met .NET meuk.

Begrijp me niet verkeerd; ik ben zeker geen .NET idolaat, maar alles heeft zo z'n beperkingen, zo ook .NET en zo ook Java. Ik zie alleen het probleem niet van het poorten van .NET en waarom dat per se alleen maar Java zou mogen zijn.

Op mijn werk gebruiken we al een product waarmee je hetzelde kan, ik heb er b.v. applicaties mee ontwikkeld op een win2k machine die nu in op een AS/400 draaien, dezelfde applicatie zou zonder problemen onder Linux draaien.

Het tooltje heet overigens Java

Goh wat grappig, helaas is Java een proprietary techniek waarbij je vast zit aan een inferieure taal waarvan op geen platform een implementatie is die enigszins vooruit te branden is. Bij .NET kun je 21 (of wellicht ondertussen al meer) talen kiezen afhankelijk van je benodigdheden, achtergrond en kennisniveau, en heb je zelfs J# mocht je om de een of andere reden Java echt een mooie taal vinden.

Als jij een development team onder je hoede krijgt met 2 VB devvers, 1 Java developer, 3 COBOL-experts en 2 C++-goeroe's weet ik wel dat je je project in .NET in de helft van de tijd werkend afhebt dan dat je met Java een half-operationeel prototype kunt afleveren.

jaja, Java is zwaar inferieur. Daarom heeft MS zo'n beetje alles ervan gejat om vervolgens in C# te stoppen.

Eerlijk is eerlijk... Java zuigt echt als het om het bouwen van GUI-/client-applicaties gaat. Maar voor web-apps is Java echt beter.

Dan moet je die luitjes de keuze geven, change skill set or move..

het maakt niet uit of je nu graag in c# , java of whatever programeert, het gaat erom dat applicaties interopereerbaar zijn, portable en makkelijk aan te passen. .net legt een basis hiervoor en mono wil platform onafhankelijk hiermee verder gaan.

Goh wat grappig, helaas is Java een proprietary techniek waarbij je vast zit aan een inferieure taal waarvan op geen platform een implementatie is die enigszins vooruit te branden is.

Het enige waar Java niet snel in is is floating-point berekeningen, en dat komt omdat het op een platform onafhankelijke manier moet gebeuren. Voor de rest is 't net zo snel zo niet sneller (ivm runtime optimalisatie) als native code.

Bij .NET kun je 21 (of wellicht ondertussen al meer) talen kiezen afhankelijk van je benodigdheden, achtergrond en kennisniveau, en heb je zelfs J# mocht je om de een of andere reden Java echt een mooie taal vinden.

Voor Java zijn er een stuk of 189
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

Als jij een development team onder je hoede krijgt met 2 VB devvers, 1 Java developer, 3 COBOL-experts en 2 C++-goeroe's weet ik wel dat je je project in .NET in de helft van de tijd werkend afhebt dan dat je met Java een half-operationeel prototype kunt afleveren.

Ja, en 25 % v/d code in VB, 12,5 % in J# , 37,5 % in COBOL en 25% in C# , dat gaat ff lekker onderhoudbare code opleveren, om 't nog maar niet te hebben over QA.

Als jij een development team onder je hoede krijgt met 2 VB devvers, 1 Java developer, 3 COBOL-experts en 2 C++-goeroe's weet ik wel dat je je project in .NET in de helft van de tijd werkend afhebt dan dat je met Java een half-operationeel prototype kunt afleveren.

Dat lijjkt mij een ramp. Je java developer ontwikkeld een stukje code. Laten we zeggen je frontend. Daarna gaat hij weg en helaas, je Cobol experts snappen geen bal van de java code en kunnen deze code dus niet meer updaten. Uiteindelijk wil je toch gewoon dat een project in 1 taal wordt geschreven. Wel is het handig dat je een stuk code die door een andere groep programmeurs is geschreven in een andere taal gewoon in je programma kan hangen. Maar in één project met meerdere talen gaan werken. Ik niet dus. Dan zoek ik liever programmeurs die wat beter zijn en wel meerdere talen beheersen.

Goh wat grappig, helaas is Java een proprietary techniek

Java mag dan wel proprietary zijn, maar de beslissingen worden wel door een vrij grote community genomen,
www.jcp.org, waar allerlei grote bedrijven in zitten, die dus mee kunnen beslissen.
Hoe dat bij MS geregeld is weet ik niet, maar 't lijkt me niet dat hun aanpak "minder proprietair" is.
Overigens zijn de specs van de JVM al jaren geleden vrijgegeven en hebben allerlei grote platformbouwers een eigen JVM ontwikkeld, MS levert nog steeds alleen een MS-VM voor .NET

waarbij je vast zit aan een inferieure taal

Dat jij de taal maar niks vindt, maakt de taal nog niet inferieur. Vermeng meningen niet met feiten, of onderbouw je feiten. Ik vindt C en C++ inferieure talen, omdat ze je dwingen over allerlei dingen na te denken die de VM of de compiler wmb prima kan oplossen...

waarvan op geen platform een implementatie is die enigszins vooruit te branden is.

Wanneer heb jij voor het laatst een java-applicatie gebouwd?
Ja, het is trager dan C++, maar niet zo traag als jij suggereert, dan kan je gewoon niet met Java overweg... Maar performance is allang niet meer standaard de belangrijkste drijfveer achter een beslissing voor je ontwikkelplatform, als het dat al ooit geweest is. En ja, tuurlijk zijn er projecten waar het wel belangrijk is, daar kies je dan ook niet direct voor java of weeg je het veel strenger mee in je keuze.
En het performanceverlies is deels te wijten aan voordelen van Java die helaas ten koste van de performance moesten gaan. Dingen als boundschecks, geen malloc-achtige grapjes etc. Maar dat heeft niet alleen nadelen, ook voordelen als je ziet hoeveel buffer-overflow-bugs er in allerlei stukken software zaten waar de performance niet voorop staat of zou moeten staan (IIS bijvoorbeeld).

Bij .NET kun je 21 (of wellicht ondertussen al meer) talen kiezen afhankelijk van je benodigdheden, achtergrond en kennisniveau, en heb je zelfs J# mocht je om de een of andere reden Java echt een mooie taal vinden.

En hoe is dat precies een voordeel, dat je uit tig talen uiteindelijk toch aanbevolen wordt C# te kiezen?
In mijn optiek is het geen voordeel om meerdere keuzen te hebben op hetzelfde platform, hooguit een gunstige bijkomstigheid, ook geen nadeel als er maar één taal beschikbaar is...

Als jij een development team onder je hoede krijgt met 2 VB devvers, 1 Java developer, 3 COBOL-experts en 2 C++-goeroe's weet ik wel dat je je project in .NET in de helft van de tijd werkend afhebt dan dat je met Java een half-operationeel prototype kunt afleveren.

Ik denk dat ik dan een ander team zou willen
Dat je code een allegaartje van VB, J#, Cobol en C++ wordt lijkt me totaal onwenselijk, tenzij je de boel dusdanig kunt opdelen dat ze ook daadwerkelijk gescheiden modules of onderdelen programmeren.
Stel je voor dat er een bug gevonden wordt waarbij een VB-er, C++-er en een Cobol-er moeten samenwerken om hem te traceren, terwijl die bug door één programmeur had kunnen worden getraceert als alles in één taal was geschreven (ongeacht of dat nou Java, C++, etc is)

Dat is het probleem niet wat ze hier mee proberen op te lossen.

Ze proberen hiermee op te lossen dat ook programmeurs die geen java kunnen maar wel met visual basic of c# kunnen programmeren ook makkelijker programma`s kunnen maken die onder windows en onder linux kunnen werken.

Tenminste dat lijkt mij zo

(...) programmeurs die geen java kunnen (...)

Ik weet niet wat jij onder programmeur verstaat, maar blijkbaar iets anders dan ik.

Een programmeur is iemand die kan programmeren, in welke taal hij dit doet is verder triviaal, een beetje programmeur kan zich elke taal vrij snel eigen maken (alhoewel het wel een tijdje zal duren voordat ie alle in's en out's kent), het is alleen een kwestie van andere syntax en api's aanleren.

En dat is dus onwaar, de syntax leer je misschien 'even' als je het over C-verwanten hebt. Maar dat geld niet voor het weten van de ins en outs van een API, zoals iemand anders al zei.

Veel dingen zoals string manipulatie etc. zullen niet veel anders zijn maar als ik me goed herinner hebben Java en C# (EDIT: .NET dus, niet C# ) een verschillende kijk op threads, om maar een voorbeeld te geven.

Daar neemt een werkgever vaak geen genoegen mee. Hij heeft geen zin om eerst flink in jou te investeren om je een andere taal te leren, waarna je fijn verder gaat shoppen naar banen (nu nog beter betaald, want je kent immers 2 courante programmeertalen). Hij wil zo snel mogelijk resultaten en die krijg je nu eenmaal het beste met de taal waarin je het meeste thuis bent.

Programmeer je C++, dan zijn er zat banen (bij wijze van spreken).
Programmeer je Java, dan zijn er zat andere banen (wederom bij wijze van spreken).

Daarnaast is de multithreading structuur in C# dusdanig anders dan in Java, dat je daar echt niet 1-2-3 in bent omgeschoold.

Hehe.
Ik wed dat jij nog nooit met Prolog hebt gewerkt.
Na 3 jaar ervaring met Java en C, kan het best zijn dat je zit te staren naar 3 regels Prolog en (zelfs na uitleg) niet snapt wat het doet.

Ter informatie; In Prolog is alles recursief. Geen loopjes, arrays, niets. Je moet recursie gebruiken om alles te definieren.
Het wordt voornamelijk gebruikt voor AI, chipknip achtige systemen en om informatica studenten te laten huilen
Prachtig spul, maar je moet je manier van denken helemaal omgooien voordat je er ook maar iets mee kan.

Wat is er dan mis aan "programmeurs die geen Java kunnen"? Hij zegt toch nergens dat programmeurs die geen Java kunnen geen programmeurs zijn? En er ZIJN programmeurs die geen Java kunnen hoor Je hebt verder hardstikke gelijk enzo, ik snap alleen niet waarom je zijn tekst aanhaalt.

Wat is er dan mis aan "programmeurs die geen Java kunnen"?

Wat ik bedoel dat het onzin is om de taal te kiezen aan de hand van wat de programmeur toevallig al kent, alle programmeurs kunnen java, misschien moeten ze zich er ff in verdiepen en de syntax leren e.d. maar dat wil niet zeggen dat ze het niet kunnen.

Je kiest de taal die het beste bij het op te lossen probleem past en als je die taal nog niet kent dan leer je 'm even.

Mjah, voordat je een API kent ben je wel ff bezig hoor... Pff

Mensen die maar één taal kunnen zijn IMHO geen programmeurs maar mensen die een kunstje hebben aangeleerd.

Bij alle informatica opleidingen krijg je eerst programmeren als vak en dan pas mag je practica in een voor de hand liggende taal uitvoeren.

Weet je wat Dijkstra&Hoare, OO etc is dan praten we verder.

Veel dingen zoals string manipulatie etc. zullen niet veel anders zijn maar als ik me goed herinner hebben Java en C# (EDIT: .NET dus, niet C# ) een verschillende kijk op threads, om maar een voorbeeld te geven.

De eerste taal die ik echt veel gebruikte was Java, daarna o.a. C en C++ gedaan, in alle talen multithreaded geprogrammeerd, met die talen heb ik allemaal multithreaded geproggelt, tegen verschillende API's (Java threads, pthreads, QT's thread model) ik heb het toen uiteraard niet lopen timen, maar meer dan een uur per API heeft het me niet gekost om een simpel multi-threaded proggeltje te schrijven, waarschijnlijk minder. 't zit 'm vooral in de documentatie, als die goed op orde is is 't zo gepiept, als je eerst nog het halve net af moet struinen op zoek naar de juiste docs, dan kan wat langer duren.

[reactie op wouter veldmaat]
Tjee zeg, wat blazen we weer hoog van de toren ... die OO talen waarvan jij zon hoge pet op hebt zouden nooit mogelijk zijn geweest als echte ECHTE programmeurs niet miljoenen uren opcodes hadden liggen kloppen, en ASM regeltjes schrijven.

OO is mooi, OO is een techniek. Een echte programmeur kan heel goed nog nooit van OO gehoord hebben.

De C# programmeurs moeten zonder veel problemen over kunnen stappen naar java hoor, zoveel problemen mag dat niet opleveren.

Wat in java gemaakt wordt moet bij het draaien alsnog geïnterpreteerd worden door de virtuele machine (Java Runtime). (Daardoor is het zo langzaam, zoals Countess zei)

Wat de heren van Mono willen is een programma dat rechtstreeks kan draaien op Linux/Unix zonder tussenkomst van virtuele machines zoals Java.

En als je een windows programma, zonder meer kunt compileren onder Mono vind ik het heel knap dat ze zover gekomen zijn

maar java is niet altijd het beste, en zeker niet de snelste taal.

Correctie:

C# word ook niet direct gedraaid, maar Just In Time Interpreted. Word dus naar een lagere taal gecompiled, en delen worden definitief compiled naar binaire code (eenmalig t.o.v java)

C# is niet Java. Java is heeeel traag, heft een slechte garbage collection, etc. Dit zijn problemen die C# niet heeft.

Garbage collection is niet slecht in Java, dat was vroeger zo.

(beetje off-topic onderhand)

C# word ook niet direct gedraaid, maar Just In Time Interpreted. Word dus naar een lagere taal gecompiled, en delen worden definitief compiled naar binaire code (eenmalig t.o.v java)

Dit doet Java ook al een tijdje (sinds 1.3.1) , http://java.sun.com/products/hotspot/ , deze analyseert de code tijdens het runnen en veel gebruikte stukken worden omgezet native code.

Dat de syntax en structuur van de taal vrijwel hetzelfde is wil nog niet zeggen dat je zomaar kan overstappen, Java en .NET hebben tenslotte niet dezelfde class libraries.

Ik denk dat ze hopen, door zich aan MS te conformeren, mee te liften en zo beter van de grond te komen dan Java.

Persoonlijk zou ik dat erg jammer vinden, want ondanks dat Java niet de snelste is, is het wel the way to go...

Het is mijn inziens onzin te veronderstellen dat ze het doen om VB programeurs tegemoed te komen.

ja maar java draait op geen enkele van die machine's java draait op een VM

nu ja ik schrijf ook al een tijdje crossplatform programma's met pTK
En zo kun je nog wel wat voorbeelden aanhalen ...

Je had ook nog een project dat dotGNU heette, maar dat is totaal onbekend bij de grote (linux) massa. Wie weet hier meer over?
Projectpagina

Op zich doet mono het aardig op dit moment, alleen bij soap serialization van object graphs met cyclic references gaat het mis in mn testprogramma. Ach, het is beta 1 .

De compiler is verder in de windows install weggestopt achter een bash script dat niet werkt wanneer je geen bash voor windows hebt geinstalleerd, beetje raar. De compiler werkt op zich wel goed, hij heeft alleen nog steeds moeite met dit:

public interface IFoo
{
// other definitions

int GetHashCode();
}

en dan implementeer je dat in je class Foo.

Daarna gebruik je de interface IFoo om een Foo instance te benaderen en GetHashCode aan te roepen:

IFoo myFoo = GetMyFoo(); // returned IFoo instance
int hash = myFoo.GetHashCode();

De laatste regel compileert niet in mono, wel in csc, omdat GetHashCode ook in object zit. Naja casten naar (Foo) werkt wel. Toch een beetje raar dat de csc compiler het wel slikt.

Als dit iets is wat mono hoort te compileren, dan zou het wijs zijn om dit te melden in de bugs database van mono.

Als Applicaties developed op het .NET platform, door ze simple weg te compileren met een Mono compiler geport kunnen worden naar Linux, betekent dat in een klap duizende applicaties erbij voor de Linux platform.

Het Linux desktop acceptatie door de grote bedrijven wordt momenteel belet doordat er te weinig (commerciele desktop)applicaties zijn voor het Linux platform.

Als je mono met de juiste extenties bouwt
( http://bbs.archlinux.org/viewtopic.php?t=4229&highlight=mono ),
Zou je gewoon binaries moeten kunnen draaien die op windows zijn gemaakt, andersom ook.

Mono implementeert niet de windows-specifieke componenten, maar met een beetje hulp van wine, kan mono gewoon die dingen draaien.

Dat weet ik wel, maar winelib is natuurlijk geen structurele oplossing voor winforms (en op windows zal gtk# natuurlijk nooit doorbreken)

Ik vrees dat dat een beetje hopen op een wonder is. Probleemloos porten zal voorlopig er niet inzitten.
Ik wacht ook nog steeds op het moment dat ik Autocad in Linux kan gebruiken.
Dus ik hoop mee

Het Linux desktop acceptatie door de grote bedrijven wordt momenteel belet doordat er te weinig (commerciele desktop)applicaties zijn voor het Linux platform.

Dat is natuurljk onzin, er zijn genoeg applicaties voor linux voor bedrijven, wat je bedoeld is waarschijnlijk dat in-house ontwikkelde custom made win32 apps niet werken op linux (duh)
En tja, de strategie van microsoft is altijd geweest om een zon groot mogelijke incompatibiliteit in te bouwen in hun producten (zie ook de technieken die in longhorn komen), aangezien dit voor MS een van de pijlers is onder hun monopoliemacht zullen ze echt niet 180 graden gedraaid zijn (ik zie nergens een open implementatie van winforms ofzo)

maw:
in het verleden heeft men er bij microsft alles aan gedaan om de compatibiliteit van hun OS zo klein mogelijk te maken (met api's zoals direct3d, aanpassingen van standaarden, patenteren van futiele zaken en het tegengaan van open standaarden)

in longhorn zetten ze die strategie voort (winfs, xml verkachtigen, nog meer gebruik directx etc)

.net likt dus wel open maar je kunt er zeker van zijn dat men bij MS alles zal doen om afgeleide projecten als mono kapot te maken als deze te succesvol worden

[reactie op: Q-collective]
http://www.gnu.org/projects/dotgnu/

ik denk dat dit een zeer goede ontwikkeling is voor linux EN microsoft
linux krijgt er veel apps bij, kunnen ook .NET gebruiken en kunnen ontwikkelaars (dan wel fun programmeurs) ook met .NET "spelen" onder linux
microsoft wint omdat hun .NET breder wordt geaccepteerd, want ga me niet vertellen dat er geen ontwikkelaars onder linux werken
ik denk dat microsoft daarom ook die specs heeft vrijgegeven, zij hoeven het niet te ontwikkelen, wat geld uitspaart (niet dat ze het nodig hebben, maar toch) terwijl het wel breder wordt geaccepteerd

Het grote verschil tussen Java en .NET zit niet in de taal (syntax), de snelheid, of zelfs in de portability. Het grote verschil zit hem in dat Java slechts een taal is met een zeer gelimiteerde standaard API.
Alle extra's zijn door Sun overgelaten aan de bouwers van de omgevingen, waardoor een programmeur die IBM WebSphere kent, geen kant op kan in Bea's WebLogic, en al helemaal niet wijs wordt uit Netscape's IPlanet.
Microsoft heeft daarentegen met .NET een zeer grote API als standaard meegeleverd. Daarom draait mijn ASP.NET applicatie (ontwikkeld in Visual Studio met IIS) ook perfect met mod_mono onder Apache op een Debian/GNU Linux bak. En daarom draait een goed ontwikkelde .NET applicatie overal.

een belangrijke reden om tevens voor C# te kiezen boven java is dat het een standaard is waardoor microsoft de api's niet zomaar kan omgooien bij een volgende versie.. Iets wat in java wel kan aangezien sun het niet als een standaard heeft verklaard. Dit maakt het voor grootte projecten irritant want de kans bestaat dat software ontwopren in bv. java versie 1.3 niet per se draait in verise 1.4 en dat je je hele code moet langslopen....