Vlákno názorů k článku
Mono míří do linuxových distribucí

Já bych se Monu vyhýbal jako čert kříži. Jako vývojář mám .NET poměrně rád, píše se v něm rychle a efektivně, ale na Linuxu stejně preferuju C++. Všichni víme, jakých podrazů je Microsoft schopen a je IMHO otázkou času, kdy přijde s patenty apod.

„Pokud se problém opravdu objeví, budeme jej řešit. Taková je naše politika,“ uzavřel vedoucí projektu Debian.

Ano, jenže to může být pozdě. Pokud bude Mono v defaultní instalaci, dá se očekávat, že vzroste podpora .NETu u vývojářů a Linux bude zaplaven spoustou nových aplikací. Že to budou zejména pitomosti od rádobyvývojářů, pro které C/C++ příliš komplikované a jejich umění spočívá především ve schopnosti slepit už hotové komponenty a naklikat GUI, teď pominu. Ale pokud se stane, že se v .NETu pro Linux začnou dělat i důležitější, hodnotné věci, pak bych se opravdu hodně bál toho, až si MS vzpomene, že Mono porušuje ty a ty patenty a je třeba ho z Linuxu odstranit.

Otázku bych položil takto: je z dlouhodobého hlediska přínosné riskovat výše uvedené výměnou za to, že se objeví víc aplikací? A budou ty aplikace za to stát? Moje odpověď je ne. Ale samozřejmě se můžu plést, křišťálovou kouli nemám.

Ja koule mam a rikam: „Mono ne.“

Samozřejmě, může se stát, že Linux získá nějaké výraznější postavení na desktopech a pak můžou s ohledem na MONO nastat dvě varianty. MS nebude Linux podporovat a nějakým způsobem zlikviduje MONO a tím vlastně i Moonlight, čímž zlikviduje šanci prosadit se na trhu webových RIA aplikací. MS začne své produkty dodávat také pro Linux, aby z tohoto trhu něco vytěžil a v tom případě ho nějaké MONO nemusí trápit, protože jak už bylo řečeno, MONO bude ještě dlouho (pokud ne vždy) minimálně o krok pozadu a když bude existovat oficiální .NET pro Linux, najde si více zájemců.

BTW: Jak je to s tou patentovou dohodou Novellu a MS, neměla by takové situaci předcházet? Přiznám se, že to nesleduju.

Nerozumím tomu, jaký je potenciální problém MONO a patentů. Je MONO nelegální? Nestraší se příliš Microsoftem? Ano, programování pod C++ je násobně těžší, než pod C# a delší. Výsledek C++ – dlouhý vývoj produktů, vysoká cena za vývoj, častěji padající aplikace co mají samé memory leaky. Ve Windows je C# jazyk číslo 1, navíc mám svobodu výběru jazyka. Musí splňovat snad akorát CTS. C# je jednodušší, moderní, má pěkný vzhled GUI (ne jako Java) a nějaké zpomalení v aplikaci není vidět. Lidé v Debianu prostě právní problém nevidí a asi to konzultovali s právníky, ne? Mě se zdá .NET dobrý a jeho výhody by určitě využily i jiné systémy. I když chápu, že Linux je na server a ne na desktop, i tak by předinstalované technologie pro vývoj snesl. Takže tady jde spíš o překonání Microsoftí fóbie a tedy svého vlastního strachu z neschopnosti, nic jiného.

Jaký je potenciální problém? Pořád stejný. Někdy se MS zachce a začne tvrdit, že se porušují jeho patenty. A že chce buď peníze a nebo odstranění kódu. Zažili jsme to mnohokrát, naposledy tuším s FAT32. A raději budu opatrný než abych se za pár let OPĚT spálil.

Zajímalo by mě, zda se živíte profesionálním vývojem aplikací nebo kde berete své zkušenosti. Mé konkrétní výhrady:

Hlášku „a nějaké zpomalení v aplikaci není vidět“ totiž může napsat jen někdo, kdo viděl .NET z dálky nebo dělá aplikace s náročností typu notepad. Například u nás jsme kritické kusy kódu museli ponechat v C++, protože pomalost C# byla neuvěřitelná (nemluvě o jiných problémech, např. obfuskace).

„V ++ častěji padající aplikace“ – není-li ošetřena výjimka, padají .NETové aplikace úplně stejně, akorát mají jiný dialog. Mohl bych uvést desítky .NETových aplikací, které padají. Narozdíl od memory leaků, které jsou pod .NETem skutečně vzácnější, je padavost aplikace pouze odrazem (ne)schopnosti autora. Nic víc.

„programování pod C++ je násobně těžší … tedy svého vlastního strachu z neschopnosti,“. Rozumím. Takže ten, kdo umí C++ a má proti na použití několikanásobně snazšímu C# výhrady, se bojí vlastní neschopnosti. Úžasné myšlenky.

Stejný patentový problém má Java, nebo nakonec i kernel Linuxu. Podobně jako MS neuplatňuje své patenty na .NET, neuplatňuje Sun patenty spojené s Javou, a další (IBM, HP) patenty spojené s kernelem Linuxu. Kritické kusy kódu jste museli nechat v C++? A umíte u vás používat unmanaged C#? .NET aplikace NEPADAJÍ stejně jako C/C++ aplikace. Když se něco podělá, dojde k výjimce. C/C++ aplikace nejčastěji tiše vyhnije, a začne se chovat podivně. Pak případně spadne na chybu přístupu k paměti na adrese 0:0×0e apod. Rozdíl je to větší než velký.

Ten zásadní rozdíl je v tom, že ani Sun, ani HP a ani IBM netvrdí, že Linux je pro ně hrozba a nesnaží se jej soustavně patenty vydírat.

Už vám někdo řekl, že unmanaged C# trpí stejnými problémy jako C++ a navíc ještě má problémy způsobené GC?

Linux je hrozba pro řadu společností. Třeba pro Sun, HP a IBM. Jejich HW na profi unixech lze v řadě případů nahradit Intelem, a jejich OS Linuxem. Vztah těch společností k Linuxu je tedy nutně podivným způsobem obojetný. Posílit Linux tak, aby to uškodilo MS, ale zároveň ne tak moc, aby to poškodilo nás :) Unmanaged C# má některé problémy společné se C++. Ovšem nikdo vás nenutí psát v unmanaged C# celou aplikaci. To se vyplatí nejvýš pro pár řádků toho kritického kódu. Ty si pak holt musíte dobře pohlídat.

Jak tu už padlo, opensource komunitě je ze všech zmíněných společností jedině Microsoft silně nepřátelský. A očekávám-li pro Linux komunitu od někoho problémy, tak v prvé řadě (spíš by bylo přesnější) výhradně od Microsoftu.

Samozřejmě, že umíme unmanaged C#. Ale také umíme počítat. Pokud je velký projekt v C++, přepisuje (zvláště v GUI části) do C# a ukazuje se, kde má C# slabiny, pak je logické to nechat funkční a odladěné v C++, než to přepisovat do unmanaged C# a doufat, že to bude rychlostně podobné C++.

.NET aplikace padají úplně stejně jako C/C++. Zhruba 90% pádu C aplikací je výjimka ACCESS_VIOLATION (typicky při dereferenci vadného ukazatele), u C++ je to o něco méně, protože tak 20% zabírají pády na Pure virtual function call. Jde o můj odhad z aplikací, které používám.

Ale hlavně – aplikace jde v takovém případě komplet na držku – prostě okamžitě končí. Co se děje u neodchycené výjimky u C#? Úplně to samé, aplikace jde na držku, okamžitě končí. Akorát ten chybový dialog je jiný, standardně obsahuje stacktrace. Je-li programátor prase, je opravdu úplně jedno, co za prostředí použije, protože neodchycená výjimka prostě vede k ukončení aplikace vždy. Rozdíl pro BFU je menší než malý. Aplikace se okamžitě nekorektně ukončila, chybové hlášce stejně nerozumí a stacktrace je mu k ničemu.

To by me zajimalo, ktere prase vytvori pure vf call..(dereferenci vadneho ukazatele vyrobim snaze) Toho lze afaik dosahnout jen volanim pure virtual funkce z konstruktoru tridy, kde jeste neni definovana.

Navic si nejsem jisty tim vasim tvrzenim o aplikaci jdouci na drzku, treba winform aplikace v urcitych pripadech (pravda, neprilis deterministickych) umi chybu odchytit, a dat moznost ‚ignore‘ .. coz mozna ale funguje jen s nainstalovanym vyvojovym prostredim, jinde jsem to nezkousel.

Které prase? Libovolné, který použije pointer ukazující na již zrušenou instanci třídy s PVF. A stane se to nejen praseti, bohatě stačí zaplést se trochu s COMem z vícevlákenné aplikace a nestačíte se divit. Ostatně ne nadarmo ty PVF call vídám i u software renomovaných firem.

S těmi výjimkami by to chtělo asi nějaký konkrétnější příklad. Dle mých zkušeností opravdu neodchycené výjimky vedou k ukončení aplikace bez ohledu na to, v jakém prostředí ty aplikace byly vytvořeny.

Pokud se nejedná o kritickou chybu, která by bránila další činnosti aplikace (např. při inicializaci, v konstruktoru hlavního formuláře, apod), tak lze výjimku ignorovat a případně pokračovat v práci(odzkoušeno pod .NET 2.0 bez vývojařských nástrojů). Pokud jde o MONO, tak tam jsem se k podobným výsledkům nedobral, ale možná je to moje chyba.

Ale taktéž si nejsem jistej, jak to přesně je.

Ale ale. ACCESS_VIOLATION je až NÁSLEDNÝ problém, když se C++ aplikace pokusí přistoupit mimo vlastní adresní prostor. Jenže ve spoustě případů se (úspěšně) pokusí o přístup někam do vlastního adresnímu prostoru, někde něco přepíše, a vy máte smůlu. V případě C# naopak nastane výjimka tam, kde dojde k chybě. Navíc odpadají problémy s pointery, hranicemi polí, neplatným přetypováním, buffer overflow, folklórem typu if (i=3), a řada dalších problémů. Programátoři dělají chyby, a tomu nelze nijak zabránit. Současný stav je SW průmyslu je havarijní. Aplikace psané v C/C++ mají hromady bugů, padají, a snad úplně všechno má bezpečnostní problémy (web servery, browsery, DB enginy, aplikační servery, kancelářské balíky, mailoví klienti, DNS servery, kernely, přehrávače multimédií, pluginy do browserů – vyberte si). Přitom jde typicky o buffer overflow/underflow, bound checking a další problémy, které v managed jazycích (C#, Java) prostě neexistují. Pro BFU je veliký rozdíl, jestli aplikace padá a je nebezpečná, nebo ne.

Nechcete doufám tvrdit, že aplikace v C# nebo Javě jsou bezpečné nebo nemají hromady bugů na rozdíl od aplikací v C++. Tyhle pohádky si nechte pro někoho, kdo nikdy neprogramoval. I ta slavná výjimka špatného přístupu do paměti většinou způsobí pád aplikace a je nebezpečná, stejně jako bugy v .NET.

Aplikace psané v managed prostředí (C#, Java a další) nemají problémy s pointery, hranicemi polí, neplatným přetypováním, buffer overflow a dalšími věcmi. Už jen tím jsou bezpečnější. Pochopitelně bugy existují i v managed prostředí. Do budoucna lze od managed prostředí očekávat další výrazné zvýšení spolehlivosti díky model checkingu a statické analýze kódu. V C/C++ takové radosti moc neužijete, protože řada konstrukcí má side effects (například strcpy v závislosti na parametrech může nejen zkopírovat string, ale také přepsat cokoliv jiného).

Buffer overflow? Hranice polí (až na off-by-one, který ale ani .NET nevyřeší)? Neplatné přetypování? strcpy? Člověče, vždyť vy do C++ strkáte problémy z C (ale musím uznat, že je tam často strkají i programátoři, kteří neumí v C++ programovat).

Statickou analýzu kódu a model checking pro C++ umí třeba moje oblíbené LLVM (které umí i další vychytávky často připisované jen pro .NET a Javu).

C++ je jak známo zpětně kompatibilní s C. V důsledku toho je v něm možné použít dlouhou řadu nebezpečných konstrukcí. Nakonec se podívejte, co jsem psal na začátku: „Aplikace psané v C/C++ mají hromady bugů, padají, a snad úplně všechno má bezpečnostní problémy (web servery, browsery, DB enginy, aplikační servery, kancelářské balíky, mailoví klienti, DNS servery, kernely, přehrávače multimédií, pluginy do browserů – vyberte si). Přitom jde typicky o buffer overflow/underflow, bound checking a další problémy, které v managed jazycích (C#, Java) prostě neexistují.“

Statická analýza kódu pod C/C++ těžko může vést k důkazu nějakých vlastností kódu. Je to spíš hraní na statickou analýzu. To právě proto, že velký počet konstrukcí má side effects. Příkladem budiž použití strcpy. V .NETu zkopírování stringu nemůže mít žádný side effect. Bu´d se zkopíruje string, nebo dojde k výjimce. Strcpy ale může v závislosti na parametrech vést k přepsání čehokoliv, a statická analýza se o tom vůbec nedozví. Obdobných konstrukcí lze vymyslet hromadu i v C++.

ty mas aktualne informacie :)

Nerozumím tomu, jaký je potenciální problém MONO a patentů.

Mono obsahuje patenty MS, které se MS rozhodl, že (momentálně) nebude uplatňovat. Otázkou je, jestli nebude chtít někdy svůj postoj změnit.

Výsledek C++ – dlouhý vývoj produktů, vysoká cena za vývoj, častěji padající aplikace co mají samé memory leaky

Vývoj produktů v C++ nemusí (a není) pomalejší než v C#, pokud se použije vhodný vývojový model (Scrum, test-driven development nebo jiný systém agilního programování), případně pro prototypování lze C++ kombinovat s Pythonem (opravdu dobré je pak využít Boost Python pro přechod z prototypu na samotnou aplikaci). Pomalejší je s neschopným (nezkušeným) senior programátorem nebo při zaučování programátorů-začátečníků, kteří jsou většinou zvyklí jen na C++ ze školy, kde se (ze mně nepochopitelných důvodů) naučí jen „klasický“ (C-like) přístup, anebo při znovuobjevování kola, kdy programátoři nejsou schopni (nebo spíš neumí) použít dostupné prostředky z běžných knihoven (STL, Boost). Padající aplikace a memory leaky jsou dány neschopností programátora, který není schopen ošetřit si práci s pointery, se kterými v C++ vůbec nemusí (a ani by neměl, pokud k tomu nemá extra důležitý důvod) přímo pracovat.

Vcelku s vámi souhlasím, nicméně budu velmi rád, když mi ukážete kus kódu (je jedno, zda pro Win či Lin), který využívá Win32 či POSIX API a nepracuje s pointery. To je utopie. Ohledně memory leaků má předřečník pravdu, v C/C++ se přihodí i zkušenějším, zatímco v C# díky garbage collectoru prakticky nemůže vzniknout.

http://www.ultimatepp.org/ Crossplatform, Win32 + X11, zkuste si najit pointry v examples a reference a spocitat je. U vetsiny GUI examplu je nenajdete vubec.

Zkuste prosím lépe číst a chápat psaný text. Psal jsem o Win32 či POSIX API.

To je vas problem, ze ho chcete nasilu pouzivat bez zapouzdreni a ztracem s tim cas. Ja ho muzu pouzivat bez pointru a bez toho ze bych resil co konkretne se uvnitr pouziva, jestli win32 nebo posix/x11, je mi to jedno.

Neměl jsem na mysli, že se úplně vzdá pointerů, to je samozřejmě nesmysl (bez nich nefunguje polymorfismus), ale že je nějak vhodně zabalí (třeba do shared_ptr z Boostu), aby se o ně nemusel starat (vzdá se tedy práce přímo s pointery, používá proxy objekty). Tím se velice účinně vyhne segfaultům i memory leakům. S voláním Céčkových funkcí může být problém, ale opět to lze vyřešit vhodným obalením anebo prostým operátorem *. Bohužel i zkušenější programátoři na tyto základní věci často kašlou a potom může dojít k rare condition, kterou netestovali, s následným memory leakem.

GC má na druhou stranu zásadní nevýhodu v tom, že nezaručuje čas volání destruktoru. Zkuste vytvořit fungující třídu pro zamykání mutexů, která hned po opuštění kritické sekce ten mutex automaticky odemkne (v C++ při opuštění scope díky stack unwind). Pokud se vám GC líbí, pro C++ existuje spousta knihoven, které to umí (klidně můžete přetížit new a cpát do GC všechno). Výhoda je v tom, že GC nemusíte používat.

Máte samozřejmě pravdu. Rozdíl však vnímám v tom, že v defaultním C# ani prase memory leaky neudělá, zatímco v defaultním C++ se jim prakticky nevyhne ani zkušeňák. Že se dají použít knihovny, které funkce GC suplují, je sice pravda, ale jak jsem psal – nejsou default, takže zdaleka ne vždy jsou použít. Ať už z technických, licenčních či politických důvodů.

Kdyz se na GUI programovani pouzije vhodny toolkit v C++ (treba Qt) tak je to taky rychle, schopne a multiplatformni. Tak proc pouzivat veci jako mono?

Trochu problém je v tom, že aplikace typu účetnictví, mzdy, evidence psích známek apod. píšou typicky autoři, kteří by například DB engine nebyli schopni napsat. Pro ty je C/C++ dost nevhodným nástrojem. Padající aplikace a resource leaks jsou přímým důsledkem toho, že C/C++ je náchylné na řadu chyb autorů. C# tyhle pasti nemá, a proto je výsledný kód lepší.

Resource leaks se nevyhnou ani C#, když je člověk patlal. Úplně nejlepší to je pod Win32, kde docházejí handly. ;)

Přesně tak. Pokud je programátor prase, tak dokáže prasit všude. V .NET a Javě to jde o dost hůř než v C++ (proto jsou tyto platformy tolik oblíbené mezi patlaly, při vývoji nemusí moc přemýšlet), ale jde to i tam.

Resource leaks v C#? V čistém managed C# asi těžko. Totéž u buffer overflow. Protože programátoři chyby dělají a dělat budou (jsou to jen lidé), musíme jim dát takové nástroje, kde napáchají méně škod. A když už se něco podělá, tak by to mělo skončit výjimkou, a ne tichým vyhnitím aplikace a jejím následným „divokým“ chováním.

To jste asi ještě neviděl, jak jsou někteří programátoři schopní psát programy, když se jim řekne, že GC se o paměť postará. Např. vytvořit statický vektor, do něho při vzniku nějaké třídy přidat odkaz na sebe a nikdy ho už neodebrat.

Google samozřejmě nesouhlasí. Garbage collector řeší proměnné typu „auto“ v C, to ale neznamená, že program nežere zdroje, které už nepotřebuje. A buffer overflow umožňuje i „hloupé“ C řešit poměrně snadno.

Memory a resource leaky jde udělat v c# nebo javě velmi jednoduše:

1. některé všechny zdroje jsou mimo managované prostředí (okna, soubory, sockety atd..) – stačí nějaký korektně neuzavřít a je to
2. nešikovně postavené vzájemné reference (např. událostí)

Pekny vzhled ne jako v jave – pan asi neslysel napr. o SWT že?

Přikláním se k tomuto názoru. Programoval jsem již v pár jazycích a i přes počáteční odpor k C# a NETu jsem velmi ocenil málo překážek vývoje a hlavně rychlost psaní kódu. Z praxe mi příjde, že si bere to nejlepší z C++ a Javy a některé šílenosti těchto jazyků ignoruje. Vůbec se nedivím, že Linux nemá na desktopu prozatím žádnou šanci.

Člověk chce hezké funkční programy. Jenže ty se samy nenapíší, a cesta přes C++ vede většinou do pekel dlouhého vývoje.

Snadnou cestu programátorům přinášejí frameworky, které jim poskytují takzvané již vyvinuté kolo. Pokud budou úžasní linuxovní Hardcore programátoři upřednostňovat náročný vývoj uživatelských aplikací v C++, C, či ještě lépe v asembleru :D tak než vyvinou kvalitní použitelný program, tak u konkurence mezitím vznikne o pár generací novější a lepší program, který sice bude o něco málo pomalejší, ale bude!

A vzpomeňte si na to co jste měli za počítač před 5 lety a vemte si jaký máte dnes. Výkon tak výrazně vzrostl, že se zabývat pomalým vývojem rychlých programů nemá cenu. Cena hardware jednoduše stále klesá, ale cena vývoje stále roste!

C, C++ jsou dobré, nutné jazyky, ALE ne na vývoj GUI aplikací! Uvědomte si kdy vznikly a k jakým účelům. C se hodí pro optimalizovaný zápis algoritmů, či na zpracování velmi náročných úkonů. C++ pro téměř to samé, ale spíše rozměrnější projekty. Psát v tom pak rozsáhle gui aplikace je zvrhlost, kvůli které je linux se softwarem, tam kde je!

jj, ted se zrovna snazim neco zmenit v jedny vicevlaknovy aplikaci v QT. A ono mi to pada. Autor ty aplikace to ladil tak dlouho, az to prestalo padat – tzn. nedostal to do stavu ze je ta aplikace logicky spravne, jen to nepada. Jakmile jsem do toho sahnul tak to zacalo padat, ale na uplne jinym miste nez kde jsem to zmenil. V tom je prave nestesti aplikaci napsanych v C/C++. Program vam spadne treba i nekolik vterin po tom co nastala logicka chyba. Dohledat a vyresit tu chybu se snazim uz asi mesic. Za tu dobu bych moh udelat spoustu jinych uzitecnych veci. I kdyz jsem patriot a v praci porad pouzivam nas projekt, tak musim uznat, ze konkurencni open-source projekty napsane v JAVE nas rychle dohaneji a nekde dokonce predhaneji.

To je přesně ono. Někde se něco přeplácne v paměti, a aplikace běží dál. Jenom se pak bude chovat tak nějak divně. Možná spadne později, možná jen bude dělat nesmysly.

Zkuste to spustit v LLVM nebo Valgrindu, na chybu přijdete velmi rychle ;)

Opravím vás. „Na některé chyby se může přijít i velmi rychle ;)“

Psát v tom pak rozsáhle gui aplikace je zvrhlost, kvůli které je linux se softwarem, tam kde je!

Když se podívám na KDE 4.3 Beta, tak je tak na stejno (možná trochu před) Windows 7 a několik let za MacOS X, to při minimálních nákladech ve srovnáni s MS, takže díky bohu za C++ :)

Kdyby jenom to. MONO kopíruje vývoj .NETu ⇒ všichni, kdo Mono propagují, vlastně propagují závislost určování dalšího vývoje na firmě s velkým M. A jak známo, tato firma nemá nejmenší zájem, aby další vývoj určoval někdo jiný než ona sama. Jejím cílem je naopak infiltrovat co nejvíce koncového software na jiných platformách než na Windows tak, aby co nejvíce vývojářů bylo závislých na jejich plánech a technologiích, a ne obráceně. Zkrátka: překlopit vývojáře opensource na jejich vlastní platformu a udělat z nich závislé. Je to jenom a jenom o penězích pro M. Dále mě to nutí být závislý na .NET dokumentaci od MS a na způsobech, jakými tuto dokumentaci distribuuje. A také – sice to bude asi znít směšně, ale není to tak dávno, kdy byl Linux a jeho ekosystém označován touto firmou ústy Ballmera za rakovinu, na to se nesmí zapomínat. Tato firma není ani náhodou dobrotivý strýček, který by jakkoliv přál nezávislému vývoji. Jsem tedy za to, aby Mono bylo výhradně VOLITELNOU součástí. Kdo chce, ať jej má, je to svobodné rozhodnutí každého správce.

PS: Pan Miguel de Icaza si může říkat o MONU co chce, může s Microsoftem spolupracovat a chválit jej jak chce, ale to nic nezmění na faktu, že tímto se Debian dostává do vleku komerčních zájmů největší SW firmy. Pro mě přínos tohoto člověka bohužel zatím končí jeho původní prací na Midnight Commanderu. Pochybuji, že by se MONO mohlo nějak výrazněji platformně odchýlit v koncepci např. rozšiřování jazyka samotného od toho, co diktuje MS. Koncepci jazyka si přes ECMA protlačil MS sám, takže s tím nejde stejně hnout a i kdyby šlo, MS nedopustí, aby to udělal někdo jiný než zase a jen on sám. Někdy je prostě lepší se nenechat zlákat něčí výkladní skříní, byť „by to blikalo sebelákavěji“, a raději zatnout zuby a pracovat na svém řešení s nástroji, které nemusejí být tak „hyper-advanced“ a pohodlné, ale jsou otevřené, šířené jako Svobodný software, takže pokud nejsem líný, mohu je kdykoliv ohnout tak, aby dělaly to, co potřebuji. Nakonec, je to jen otázka zvyku a kvalitních nástrojů vč. těch, které jsou uživatelsky přívětivé, je dost. A navíc mám výhody, které mi komerční systém nikdy přinést nemůže: dostupnost zdarma, navždy právo distribuovat zdarma dál, navždy právo upravovat zdrojový kód a šířit jeho mutace, právo ochrany před komerčním zneužitím formou uzavření a následného šíření modifikované verze.

Jedinou alternativou k Mono/.NET je dnes Java. Ovšem .NET na rozdíl od Javy stojí na ECMA a ISO standardech. A standardy jsou přece dobré. Tak kde je problém? Mono máte zdarma, a můžete ho upravovat a šířit.

„Komerční zneužití“ je naprostá blbost – když je něco zdarma, nemůžete to uzavřít a prodávat, protože to každý může mít zdarma. Když něco doděláte navíc k tomu zdarma, tak to samozřejmě neprodáte dráž, než jaká je tržní cena takové dodělávky (tedy vaší práce). Protože tu neupravenou verzi může mít každý zdarma.