A Microsoft megnyitotta a CoreCLR forrását

Microsoft, Windows

A Microsoft bejelentette, hogy több hónapos előkészítés után végül megnyitotta a CoreCLR - a .NET execution engine a .NET Core-ban - forrását. A redmondi cég a legújabb trendnek megfelelően a kódot nem a saját, nyílt forrású projekteket egybegyűjtő platformján, a CodePlex-en, hanem a GitHub-on tette elérhetővé. A választott licenc az MIT licenc.

Részletek a bejelentésben.

( mekflaj | 2015. 02. 04., sze – 08:35 )

Kíváncsi lennék mi van a hatterben.
Mostanában az MS nagyon "open source" irányt vett.

Az uj vezerigazgato csak egy tenyezo a sok kozul. A .NET kodnyitasa mogott egeszen mas allt.

A MS az elmult kb 15-20 ev alatt minden lehetseges modot megragadott hogy novelje a befolyasat es egy egypolusu informatikat hozzon letre ahol ok diktaljak a felteteleket. Eppen ezert a meglevo befolyasukat arra hasznaltak hogy olyan technologiakkal arasszak el az embereket amelyek tovabb novelik az MS fuggoseguket azaltal hogy kevesbe vagy egyaltalan nem kompatibilisek ekvivalens technologiakkal. (vendor lock-in)

A gond az volt hogy ez onmagaban egy dominoszeru sema volt a maga fuggosegi csapdaival. Pl. IE --> IIS, IIS --> Windows (Server), MSSQL --> Windows (Server), IE --> Windows, MS Office binaris formatumok --> MS Office, .NET --> Windows (Mono nem 100% kompatibilis). Ez volt a helyzet nagyjabol a mult evtized kozepeig. Aztan ekozben megjelent egy Firefox nevu bongeszo ami kepes volt normalisan megjeleniteni az IIS altal generalt gagyi CSS meg HTML fajlokat is es emellett a szabvanyosakat is. Ahogy a FF terjedt ugy egyre tobb szabvanyos webszerver es CMS tudott tert nyerni majd amikor elertek egy kritikus tomeget az IE beleesett a sajat csapdajaba, mivel keptelen volt normalisan megnyitni nehany szabvanyos oldalt. Ezzel parhuzamosan pedig az OOO is felnott korba lepett es elkezdte dontogetni a MS Office fellegvarait. Mindezek mellett pedig minnel tobb befolyashoz jutottak annal jobban ingereltek a partnereiket es versenytarsaikat is, ebbol fakadoan egyre tobb jogi problemaik akadtak. Lasd peldaul EB trosztellenes perek. (Azt azert itt megjegyeznem hogy ezek is sokat segitettek az OOO es FF eloretoreseben). Minel tobb eroforrast fektettek bele a sajat monoplatform torekveseikbe annal inkabb kezdett visszautni es egyre tobbe kerult. Az is vilagossa valt hogy az opensource model hosszutavon sokkal eletkepesebb, egyre szimpatikusabb lett a nagyobb tomegek szamara is igy egyre inkabb nem lehetett figyelmen kivul hagyni.

Amit most csinalnak az evekkel ezelott is varhato volt egyebkent. Latvan a zart kodu UNIX-ok kihalasat es a fenti folyamatokat, elobb utobb fontolora kellet venniuk hogy valamit lepni kell. Akar reszben vagy akar gyokeresen at kell szervezniuk termekertekesitesi modelljuket hogy kepesek legyenek a piacon maradni. Ezzel pedig egy paradigma valtason is at kell esniuk hogy a celjaikon is valtoztassanak, a monoplatform vilaguralom eroltetese helyett nyitottabba valni es keresztplatformra helyezni a hangsulyt.

Az en meglatasom szerint a .NET nyitasa mogott pedig az all hogy maga a technologia intenziven fejlodik es meg volna a potencialja is hogy komoly kihivoja legyen a Java-nak csak hat az eredeti viziokban a cross-platform, mint cel nem szerepelt. Ebben a kategoriban pedig a .NET-tel szemben a Java hasit. A mobilplatformon peldaul soha nem tudta igazan megvetni a labat az MS, az Android reszesedese valahol 80% korul van ahol a Java ugyanugy szinte uralkodik, mig a .NET csak a Mono-ban tud megnyilvanulni ami elegge bugos, befejezetlen es aminek a fejlesztese kodnyitas nelkul soha nem lesz kepes lepest tartani a .NET-tel. Beleoltek egy halom penzt a fejlesztesebe, beleertve raepulo termekeket is, viszont keptelenek betorni veluk a mobil piacra.

Ugyhogy fontolora kellet venniuk hogy vagy hagyjak a .NET-et elsullyedni (mindennel ami raeepul) a korabban bebukott technologiaikho hasonloan vagy iranyt valtanak es kiadjak a .NET-et olyan licensz alatt amivel a Mono kepes lesz erore kapni es a MS .NET-re epulo termekei eljuthatnak mas platformokra is.

Ma mar nem vilaguralom a celjuk hanem a hosszutavu tuleles. A belterjes technologiaik fokozatosan elszigetelik oket es ebbol probalnak kitorni.

Ilyen az amikor a fagyi visszanyal.

A masik dolog pedig amit szeretnek megjegyezni hogy ez soha nem kovetkezhetett volna be egy evtizedeken at tarto globalis, kitarto mozgalom nelkul. Ugyhogy ebben nekunk, opensource kozossegeknek is eleg nagy reszunk van.

Azért még ezt két megjegyezéssel kiegészíteném:

Lasd peldaul EB trosztellenes perek. (Azt azert itt megjegyeznem hogy ezek is sokat segitettek az OOO es FF eloretoreseben).

És messze nem csak azoknál. Azután, hogy meg kellett nyitniuk a protokolljaikat és már nem wireshark kimenetekből kellett a deveknek kompatibilis szervert varászolni, "hirtelen" (az előtte levő közel egy évtizedhez képest) jött a Samba4 és az OpenChange. Amivel gyakorlatilag a kisvállalatoknál levő Win Serverek bőségesen kiválthatók, így ez a piac nagyon veszélyeztetett lett. És ami azt illeti, szerintem az MS le is mondott róla - helyette állt rá az előfizetéses konstrukciókra (pl. O365). A nagyvállalatoknál egyelőre ez a veszély nem fenyeget, azon a szinten még tényleg nem konkurrencia az OSS replacement, így ott még marad a fejős tehén (lásd még: Enterspájz verzióra nem érvényes ingyenes első éves Win10...)

mig a .NET csak a Mono-ban tud megnyilvanulni ami elegge bugos, befejezetlen es aminek a fejlesztese kodnyitas nelkul soha nem lesz kepes lepest tartani a .NET-tel.

Őszintén szólva szerintem azzal sem. A .NET-et nagyon szépen ráépítették a Win API-ra és az összes Windows-os szolgáltatásra, és ezt a visszafelé kompatibilitás miatt meg is kell tartaniuk (emlékezz, milyen sajtót kaptak, amikor bejelentették, hogy már nem fejlesztik a Silverlight-ot és 8 év múlva kivezetik...). Ehelyett csinálhatnák (nem hiszem, hogy ezt tennék), hogy csinálnak egy .NET 5 "über-API"-t, ami rámegy arra, hogy az OS-ek közti különbségeket elfedje (triviális példa egész pontosan 1 darab megírt C#/.NET alkalmazás után: ProcessStartInfo és a felhasználóváltás. Mono alatt természetesen nem működik)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az elsore felvetesedre reagalva, az teny hogy sokat buktak minden tekintetben a trosztellenes pereken, en csak nehany peldat hoztam fel, ennyire nem akartam belemenni. Igy is eleg hosszura sikeredett. :)

Őszintén szólva szerintem azzal sem. A .NET-et nagyon szépen ráépítették a Win API-ra és az összes Windows-os szolgáltatásra, és ezt a visszafelé kompatibilitás miatt meg is kell tartaniuk...

Ezek muszakilag mind megoldhato dolgok. [naivitas_on]Az eredeti bejelentesukben elegge kihangsulyoztak a cross-platform iranti elkotelezettseguket.[naivitas_off] Habar az hogy pont X11 es MIT alatt adtak ki a kodokat az eleg sokat elarul a kodcserevel kapcsolatban. A masik tenyezo pedig hogy ha szorakoznak akkor a forkolas is egy lehetoseg. Tobb mint 100 .NET forkot lattam a kodnyitas ota, jo persze nyilvan tobbseguk pistike de ha akad koztuk egy-ket komoly fejlesztocsapat akkor sokat vihet elore.

Mindezektol fuggetlenul en tovabbra is azon a velemenyen vagyok hogy tojnak az elszigetelodestol es hogy aprankent remete've' zsugorodnak egy dinamikusan fejlodo piacon (fokent a mobil).

Koszonet rigidus a kimerito valaszert. Jo latni, hogy az evtizedeken at tarto open source nyomasnak azert vegulis van ereje. :-)

Mondjuk szerintem tovabbra sem szabad a "take open source for granted" kovetni. Ha nem lesz tovabbra is folyamatos nyomas ra az elkovetkezo evtizedekben, meg visszafordulhatnak a jovoben valamikor, ha a hatalmuk jelentos.

Jo latni, hogy az evtizedeken at tarto open source nyomasnak azert vegulis van ereje. :-)

Persze hogy van. :) Ha sok ember osszetartoan, szervezetten, kozos celokert kuzd, ugy mi "kis emberek" nagyon erosek tudunk lenni. Ez a mi hatalmunk: az osszetarto tobbseg, csak erre nem tanitanak az iskolaban. Talan nem is veletlenul, ha az emberek tomegmeretekben elhiszik hogy pici hasznavehetetlen senkik akik nem kepesek onalloan cselekedni akkor hatekonyabban lehet oket szipolyozni.

" IIS altal generalt gagyi CSS meg HTML fajlokat"

Az IIS által micsinált HTML fájlokat?

"viszont keptelenek betorni veluk a mobil piacra."

Unity3d nem kedveli ezt.

"Mono kepes lesz erore kapni"

Mondjuk szerintem a Mononak nem sok jelentősége lesz, ha tényleg megnyitják a .NET-et. Esetleg, mint beágyazott libraryként, ld. Unity3D.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Az IIS által micsinált HTML fájlokat?

IIS + ASP.NET. Mint mar mondtam fentebb elsiettem az elso kommentet, de nyilvan mindenki ertette mire gondoltam.

> Unity3d nem kedveli ezt.

Es a tobbi .NET alkalmazas? Ha dolgozol a Mono forraskodjaval napi szinten eszre fogod venni hogy meg mindig tele van throw new NotImplemented(); reszekkel. A Unity3D csapat nem keves energiat olt bele hogy implementalja azokat a hianyzo kodreszeket a Monoban es ovakodjon olyan nem implementalt reszeitol az API-nak melyek erintik az o projektjuket. Igy lett a Unity3D cross-platform, nem azert mert a Mono egyebkent 100%-ig az volna.

Egy masik pelda: irj egy egyszeru mobil alkalmazast a WPF lib-ek hasznalataval es vidd at Mono-ra. Csak hat nincsen WPF tamogatas (kiveve egy nagyon alfa verzios portot a Moonlightban). Es ha utana olvasol Miguel de Icaza szerint nem is lesz mivel tul osszetett feladat, valamint egyes reszei DX fuggoek is es nincs ra ember aki OpenGL-re portolna.

De van egy masik pelda a Mono mas reszeire is, probald meg az Orchard CMS-t Mono felett futtatni. Mar evek ota abbahagytak a tamogatasat es hivatalosan nem is fogjak tobbet, pont a fentebb irottak miatt: "tele van throw new NotImplemented(); reszekkel".

( rigidus | 2015. 02. 04., sze – 14:19 )

En szemely szerint a WPF-et varom mar nagyon hogy kiadjak.

( uid_17784 | 2015. 02. 04., sze – 21:35 )

Nem tudom, miert varnak vele.

Talan mert kliensoldalon ugyis Windowst hasznalnak a felhasznalok (azok, akiknek WPF-es front-end "jutott").

( turul16 v | 2015. 02. 05., cs – 10:47 )

Azt lehet tudni, hogy az MS mennyit keres a Visual Studion es tarsain ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A VS Professionallel minden szempontból ekvivalens Community Edition egy nagyon széles réteg számára ingyenes, azon például nem keres semmit. http://www.visualstudio.com/en-us/products/visual-studio-community-vs

Egyébként szép próbálkozás volt. ;)

szerk: ja, és a VS természetesen nem csak .NET fejlesztésre jó.

Talan masodik korben.
.NET ott szokott elverezni valasztaskor, hogy nem igazan cross-platfrom igy vendor lock-in...
Ezert a cegek jo resze windows desktopon fejlesztet Linuxra, Java appot.
Szeritem ez ilyen tipusu vasarlo lehet leginakbb a cel kozonseg.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Tegyük már hozzá: Az, hogy választhatsz X meg Y Linux disztro közül, ami tobbe-kevesbe ugyanazt csomagolja, csak mas formátumban, attol meg a ugyanugy vendor lock-in a Linux is, a választásnak csak az illúziója van meg.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem releváns. A szál ui. onnan indult, hogy ha te eldöntötted, hogy .NET alapokon építkezel, akkor még kódot sem írtál, de már csak egy platformból választhatsz. Más esetben a választás lehetősége megmarad. Anno migráltam egy - persze megfelelően megírt, tehát a platformfüggőség el volt különítve - JavaEE alkalmazást Linuxról Mac OS X-re. Még élek.
.NET-tel ezt meg lehet csinálni? Megtalálom ugyanazt a futtatókörnyezetet, ökoszisztémát?

( naszta v | 2015. 02. 10., k – 09:07 )

Szerintem ez a felhőről szól: így lesz PowerShell Linux-on és mehetnek a Windows-os/Azure-os management tool-ok enterprise Linux-okkal.
--
http://naszta.hu