A Mono lesz az elsődleges fejlesztői platform Linuxra?

Címkék

Vajon tényleg a Microsoft .NET Framework, illetve ECMA szabvány alapján készült Mono lesz-e az elsődleges fejlesztői platform Linuxra? A kérdés érdekes. A válasz is bizonyára az lesz.Ez egyben azt is jelentheti, hogy az eddig leginkább használatos C nyelv a háttérbe szorulhat (C/C++ nyelvet fejlesztő létemre, alacsonyszintű alkalmazások elkészítésének kivételével nem szívesen hasznék szoftverfejlesztésre).

Ja, és ezek után további kérdéseket vethet fel a Java, J2EE, illetve Sun Java Desktop System alkalmazása is.

Egy biztos. A .NET egy kiváló keretrendszer bárki is alkotta (kéretik nem cikizni). Remélhetőleg a Mono is azzá válik majd egyszer. Én a béta változatát próbáltam UHU-Linux 1.0 alatt. Ugyanaz a program remekül működött Linux és Windows alatt egyaránt - újrafordítás nélkül. Persze aki ismeri a .NET Framework jellemzőit az bizonyára nem lepődött meg ezen.

A részleteket és talán a választ mindenki megtudhatja az O'Really ONLamp.com webhelyén. Én bízom a .NET minél szélesebb körű elterjedésében.

http://www.onlamp.com/pub/a/onlamp/2004/03/11/mono.html

Egyéb, a témához kapcsolódó webhelyek:

http://www.go-mono.com

http://msdn.microsoft.com/netframework/using/understanding/

(Azért írtam Anonymusként, mert néhány szemellenzős ember nem képes elviselni azt, hogy a Microsoftnak is lehet jó technológiája vagy terméke, melyre akár mások is alapozhatják a jövőjuket - lásd Mono. Nos, így legalább nem kell elszenvednem az állandó, kellemetlen és méltánytalan megjegyzéseket.)

Hozzászólások

Én egy igazi szemellenzős vagyok, és az a kérdésem, hogy miért kell egy flame gyanús dolgot elindítani egy hír-rovatban, aminek nincs semmilyen hírértéke? Én legalábbis nem találtam meg benne sehol a hírt. Egyébként tudtommal a jogokat a M$ birtokolja, nem hiszem, hogy ebből valaha is elsődleges fejlesztői platform lesz.

Nekem nagyon úgy tünik, hogy jogilag nem tisztázott a dolog. Ez veszélyes lehet, mert ez egy támadási felület. A M$ közvetve gyengítheti a open source-os társadalmat azzal, ha bepereli a Novellt, vagy bármely más céget, amelyik az ő védett technológiáját alkalmazza. Emiatt nem tetszik nekem az egész, egyébként semmi bajom a .NET-tel vagy a Mono-val, sem azokkal, akiknek ez a környzet tetszik.

Pontosan!

Ajanlanam figyelmebe mindenkinek a FAT esetet. A hosszu fileneveket tamogato VFAT kiegeszitest valamikor 1994 vagy 1995-ben szabadalmaztatta az MS. Most azaz kb 10 evvel kesobb dontott ugy, hogy licencdijat szed utana (egyenlore csak a flash-kartya gyartoktol... egyenlore.)

Ez egy klasszikus submarine-patent eset. Addig nem hangoztatja, hogy szabadalmaztatva van, amig a technologia/formatum/api/otlet/algoritmus el nem terjed az egesz iparban, es akkor hirtelen lecsap. Nyilvan valo, hogy most nem fogja piszkalni a Mono-t, mert akkor most azonnal leallitanak a projektet. Majd ha mar lesz egy-ket ra epulo nagyobb szabasu projekt, meg nehany ceg (Ximian, Novell, Redhat stb...) aki elkotelezte magat mellette, majd akkor. Es teheti ezt teljesen jogosan (bar nem etikusan, de sajnos jogosan).

Azt mar alig merem megemliteni, hogy a szoftver szabadalmak ugye az EU-ban meg nem teljesen lefutott meccs.

>hogy miért kell egy flame gyanús dolgot elindítani egy hír-rovatban, aminek nincs semmilyen hírértéke?

Sokszor nem csak a hir erteku dolgok kapnak helyet, hanem azok is amelyekrol elbeszelgetve (nem flamelve) olyanok is ralatast nyerhetnek a temara, akik korabban nem foglalkoztak vele, vagy abszolute nem halottak rola. Az meg, hogy flame lesz-e belole, vagy sem az csak a hozzaszolok intelligenciajan mulik.

Tedd le a csövet a fejed elől és kicsit nézz szét a világban, lehet hogy segíteni fog!

És ezzel nem azt mondom hogy használd azokat a programokat, csak ismerd meg, és utána döntsd el kell, vagy nem.

Nehany aprosag a problemakorhoz:

A .NET ket - altalam legfontosabbnak tartott - alapotlete a "felugyelt kod" es a Web services technologia integralasa.

Ebbol az elso a java tovabbvitele es hasonlo nepszerusegre szemithat. A masofik uj es multiplatform es w3c szabvanyokra epul. Tehat szerintem a utobbiban nagy lehetosegek vannak, de ehhez nem kell .net keretrendszer. Ragyogonan tud az ember irni python-ban egy olyan szolgaltatast emit .net-en irt programmal el lehet erni (koszonhetoen az XML alapu, SOAP, WSDL, UDDI szabvanyoknak tehat nem MS tulajdon meg ha reszt vett a fejlesztesben is). Tehat ez inkabb abban az iranyba viszi a dolgot, hogy mindegy miben irod a sw komonenseket azok tudjanak egymassal kommunikalni adatokat cserelni.

Azt gondolom, hogy ahogy a Javaban nem lehet megoldani ertelmesen minden feladatot igy majd C#-ban sem es "felugyelt kodon" futtatva sem lehet majd (kedvenc peldaim kozott a tobb millio FORTRAN soros tudomanyos muszaki problemak szerepelnek)

Azt se feledjuk, hogy a J2EE mogott is orisai tabor all es rengereg Java fejleszto termelodott ki az utobbi idoben. Es ezetk az emberek nem szeretnek nagyon ujjat tanulni, plane ha a meglevo eszkozokkel is elvezhetik az uj technologiak nyujotta elonyoket.

Jó ez a vita, de kevés szó esik a konkrétumokról.

A hírt olvasva úgy gondoltam, hogy közelebbrõl is

megnézem a Mono-t. Örömmel fedeztem fel a Mono

website-on a SuSE 9.0-ra való telepítõkészletet.

Letöltöttem tehát az rpm-eket az ftp-rôl instalált,

100%-ban up to date SuSE 9.0 rendszeremre.

Elõször is hamar kiderül, hogy a telepítõcsomagok

ütköznek, ui. három rpm csomag több (egymást kizáró)

változatban is megvan. Ezt könnyû javítani a felesleges

csomagok eltávolításával. Ha a maradékot installálom,

akkor a következõ hibaüzeneteket kapom:

error: Failed dependencies:

gtkhtml3.0 is needed by gtk-sharp-0.15-2.ximian.8.0

libgnomeprint22 is needed by gtk-sharp-0.15-2.ximian.8.0

libgnomeprintui22 is needed by gtk-sharp-0.15-2.ximian.8.0

libgal-a11y-2.0.so.5 is needed by gtk-sharp-0.15-2.ximian.8.0

gtkhtml3.0 is needed by monodoc-0.11-0.ximian.8.0

gtk-sharp >= 0.17 is needed by monodoc-0.11-0.ximian.8.0

A hiányzó csomagok a SuSE 9.0-ban nincsenek meg.

Hasonló nevû, vagy alacsonyabb verziószámú csomagok vannak,

de amit az rpm megkövetel, az nincs. Ha telepítõkészlet

közreadói egyszer is ellenõrizték, hogy valóban mûködik-e

a telepítés, akkor tudniuk kell, hogy nem mûködik.

A hibaüzenetekbõl látható, hogy csak a gtk-sharp és monodoc

csomagokat nem lehet telepíteni. A C# fordító és futtatórendszer

települ, és mûködik. Sajnos az ismerkedéshez éppen a monodoc

program volna a legfontosabb.

Nem tudom, pontosan mit nyujt a .NET. De azt igen, hogy m$ hasznalo kollegaim C#.net programjaval az en python programom kivaloan egyutt tud dolgozni, ugyan en COM interfeszt hasznaltam, (igaz, van .net is python-hoz, de ugy vettem ki, hogy meg nincs kesz, azzal nem mertem probat tenni)

Szoval a lenyeg, hogy nekem semmi keretrendszer meg miegymas nem kellett ahhoz, hogy 4-szer olyan gyorsan haladjak, mint a C#-os kollega.

Abban igaza van a cikk ironak, hogy C-ben nem szivesen tocskol. En 9 eve kezdtem C++-ban programozni, sok even keresztul irtam nagyon osszetett dolgokat, jatektol kezdve telko alkalmazason at mindenfelet.

Es most mar nem szivesen hasznalnam nagy alkalmazasra, ha nem muszaj, mert feleslegesen hosszu ido lekodolni egyszeru dolgokat. Lehetoleg python-t hasznalok, ami viszont egyaltalan nem jo mindenre. Vannak reszek, amiket tovabbra is gyorsra, vagy kisebb memoriaigenyure kell irni (mert python pazarol erosen)

De szerintem nincs, es nem is lesz olyan dolog, hogy elsodleges kornyezet.

Minden a temaban hozzaszolonak es erdeklodonek ajanlom a következő olvasmányt, mielot elragadtatjak magukat és ilyeneket jelentenek ki:

"... Microsoft betesz majd a Mono-nak és az összes implementornak, mint pl a vfat eseteben ..."

Doksik:

http://msdn.microsoft.com/net/ECMA/

http://www.go-mono.com/faq.html#msft

És a lényeg Mono szemszögből (idézet a FAQ-ból):

Question 41: Are you writing Mono from the ECMA specs?

Yes, we are writing them from the ECMA specs and the published materials in print about .NET.