https://dusted.codes/can-we-trust-microsoft-with-open-source
Oh boy, what a week of .NET drama again. Not bored yet? Read on, but for this one you’ll need some stamina, because this one is different.
...
This is a bigger issue, an issue internally playing out at Microsoft right now as we speak.
(Megjegyzés, ez időközben már lefutott történet, pár éves.)
Zanzásítva:
- Microsoft beígért egy funkciót a Nyílt Forráskódú C# SDK-ban
- Mikor az elkészült, és frankón működött, hirtelen zárt kódúvá és fizetőssé tették
- Népharag
- Visszakoztak a népharag láttán, végül betartották az eredeti ígéretüket
- Népben ezek után felmerült, hogy oké, egyszer sikerült viszakozásra kényszeríteni, na de mi lesz a jövőben?
A HUP-os C# kollégákat kérdezem, így utólag mi lett ebből? Tudtok hasonlóról, ami ez után a 2021-es eset után történt, vagy tényleg megváltozott azóta a Microsoft és OSS párti lett frankón?
Írtak arról is, hogy erőszakkal próbálják terelni a fejlesztőket a VS-re, ebből lett valami?
Mennyire használható manapság a C# más, nem MS környezetekben (*)?
(*) - MonoDevelop már nincs, a Unity meg mostanában hajítja ki a .NET-et és vált natív kódra, úgy tudom (de ebben nem vagyok biztos, ezt ne vegyétek készpénznek, pont ezért kérdezem).
Hozzászólások
Szísárp helyett pájtont kell használni. :P
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ez a Hot Reload kivétel egy régi elhamarkodott hiba volt. Azóta sok minden változott.
Már nem erőlteti a VS-t annyira, de nyilván kiemelt termék. Miután megszüntette a Mac-en a VS, azóta a VS Code az a fejlesztő környezet, ami nagyon jól használható minden OS-en. Tényleg lelkiismeretesen fejlesztik.
Blazor-t és MAUI-t használok minden platformon (MAUI nem megy még Linuxon) és nem találtam még problémát. Hallottam már hogy vannak, de én nem találkoztam velük, ha bajom lesz majd kijavítom.
Én elégedett vagyok.
VS Code C#-hoz itt van az én extensions.json fájlom:
Nem vagyok C#-s, de dehogy lehet bennük megbízni. Nem is kérdés. Ezt a szeretjük az open-source mantrát csak azért nyomják, mert belátták, hogy a közelgő ARM-en, meg felhőben, szerveren ez kell, ha versenyképesek akarnak maradni, és ehhez muszáj részt venniük benne valamilyen szinten (Linux kernel és systemd fejlesztése, saját Linux disztró, Visual Studio Code, .NET Core, Powershell), egyébként gyűlölik, nem véletlen, hogy a Samba, Paragon-féle NTFS-drivert, Ntsync-et, stb. is másnak kellett implementálni, a Wine/Proton/DXVK projektről nem is beszélve. Ők mindig is a zárt forráskódon alapuló, fizetős monopóliumra mentek rá.
Meg amit még opensource-ol a MS, azok az értéktelen, muzeális szutykai, MS-DOS 1-2, Windows 3 számológép, GW-BASIC, stb.. Meg néhány Windows-specifikus egyéb (Windows számológép, Windows Terminal). Illetve a K8s kapcsán a Helm-et még ők jegyzik open-source-ként, nem tudom saját projekt-e vagy átvették.
Illetve a Windows-ba is másolgatnak opensource világból, de nem mindig nyitott kóddal, WSL-en kívül pl. Windowsban tiling, virtuális asztalok, winget, sudo, OS-be épített hypervisor, normális terminál, Notepad-ben unixos sorvégek és UTF-8 kezelése, stb.. Mindegy, tőlük már ez is szép teljesítmény, 10-20 éve még nem hittük volna, hogy ennyit is kitolnak.
Ezeket az SDK-kat is azért tolják ki open-source formájában, hogy ne csak Windowson tudjál arra való szoftvert fejleszteni, ez megint az ő érdekük. Nem szívjóságból. Rájöttek, hogy a fejlesztőknek egy jelentős hányada már nem Windowson fejleszt, őket próbálják így visszaszerezni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Rosszab vagy mint a Terminátorok. Azok is, ha megtudták, hogy John Connor melyik időben van, mentek és törtek zúztak idegből. A Te John Connor-od a Microsoft.
Szerintem őket bárki utálja, aki mögé lát a szemétségeiknek. Ha az megvigasztal egyébként az Apple-t jobban utálom, de a Facebook, Google, és Oracle is nagyon ott van a dobogóhoz közel, meg újabban az IBM és az általa felvásárolt Red Hat.
A MS csak annyiból speciális, hogy amiatt többet kell szívni. Az Apple miatt legalább nem állnak le repterek, bankok, stb., de ez csak azért van, mert kisebb a dominanciájuk, nem mintha az iPhone-ok nem lennének elég dominánsak. Bár a hülye trendek terjesztésében az Apple legalább olyan veszélyes.
Nvidia is nagy kedvenc, bár ők is most opensource-olnak, lásd új driver (NVK), de ők is eléggé botladoznak, nem nagyon értik még, hogy hogyan működik, mire jó ez az ópönszósz, lásd a git tárolójuk kezelése. Mindegy, majd belejönnek, mint ’lye gyerek a ‘rásba, utána meglesz hozzá a szemléletük.
Az a baj, hogy az open-source-t sokan félreértik, nem látják mire jó. Csak az ingyenes oldalát érzékelik, de ez torzít. Valójában az open-source ezeknek a nagy szoftvercégeknek is értékes, ingyen fejlesztői-tesztelői, patch-elői munkát kapnak vele, meg a közösség segít új funkciókat adni a szoftverhez, portolni más platformokra, ergó megnövelik az esélyét, hogy szabvánnyá válik a megoldás, stb.. A Google, Intel, stb., aki régebb óta benne van ebben, az jobban látja már. Ez nem az ajándékozásról szól, meg a nonprofitról. Csak sok cégben, fejlesztőben benne van ez a szemlélet, hogy ha opensource, akkor jajj, mi lesz, ellopják, hackerek feltörik.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Szerintem abból ered a folyamatos frusztrációd ezekkel a cégekkel kapcsolatban, hogy ahogyan ők nem értik (nem értették régebben) az open source lényegét, előnyeit, Te úgy nem érted a kapitalista, profitorientált, piaci, eredmény alapú működés lényegét. Pedig (sajnos) mindannyiunk napi életéhez kell a pénz, így ezt nem lehet kihagyni a képletből.
Régebben a szoftver volt "A termék". Kifejlesztették, eladták darabra. Ebbe a modellbe nem fér bele, hogy nyílt forrással dolgozzanak, mert ha mindenki hozzáfér a forráshoz, akkor a saját ötletek (amik pénzt érnek) és a beletett munka ellenértékének beszedhetősége erősen kérdőjeles lesz, mert a forrás birtokában mindenki tud gyártani magának működő verziót egy fillér kifizetése nélkül. Az, hogy ez jogilag megengedett-e nem számít, műszakilag megoldható könnyen, aztán tessék pereskedni (elsőre is, bizonyítani...).
A változást nem az hozta, hogy felismerték, mennyire jó az open source közösség majdnem végtelen fejlesztői és tesztelői kapacitása (azt addig is nagyon jól tudták, az MS felső vezetésébe sose sík hülyék kerültek be), hanem az hozta a változást a hozzáállásukban, hogy a szoftverről mint termékről váltanak folyamatosan szolgáltatás nyújtásra, mint bevételi forrásra, ahol már csak egy eszköz a szoftver. Így maga a szoftver már nem annyira lényeges, nem kell bele titkokat tenni a sikerhez, lehet szabványos amire van szabvány, láthatja más is a kódot, és így "igénybe vehető" az "ingyenes" fejlesztői és tesztelői bázis annak minden előnyével.
Az, hogy minek nyitják meg a forrását, rettentő sok dolgon múlik, nem csak elhatározás kérdése. Lehetnek jogi kötelezettségeik a forrás/működés titokban tartására, vagy akár olyan banális dolog is, hogy egy szörnyű tákolmány az egész, és úgy nem mutatnák meg, de melót (pénzt) már nem tennének a szépítésébe. Amit meg kinyitnak, az elsősorban érdekesség, semmint hasznos.
Az meg, hogy egy hiba miatt leáll a fél világ, ki kell mondani, hogy sajnos nem a MS és nem is a CrowdStrike hibája, bármennyire is szeretnénk 1-2 céggel elvitetni a balhét. Persze Ők, vagy valamelyikük rontott el valamit. De a leállások az adott cégek vezetésének hibái, ugyanis annyira elhiszik, hogy az IT-vel soha semmi nem történhet, hogy senkinek nincs terve arra, hogy ha ilyen történik, hogyan lehet az üzletfolytonosságot biztosítani.
Egy ABC-nél nem gond, ha bezár egy napra, de egy reptér ezt nem engedhetné meg magának, kellene lenni arra vonatkozó fejezetnek az üzletfolytonossági tervben, ami azzal foglalkozik, hogy mi van, ha az IT megáll.
Vagy ilyen kritikus helyeken akár lehetne egymástól független technológiákat használó, valami módon adat-szinkronizált rendszereket használni, ami az egyik technológia generális hibája esetén a másikon megy tovább. De ugye ez mind pénz, és azt szeretik megspórolni. Ha meg jön az EU és szabályoz, mindenki felháborodik, hogy a hülye EU miatt van a drágulás és nem lehet 5000 Ft-ért Londonba repülni...
A mondat első része szerintem nem igaz, mert ez a hiba ott is ütött, ahol készültek problémára, a kérdés inkább az, hogy erre a problémára készültek-e. Úgy tűnik, hogy nem. A kérdés ezek után az, hogy mire kell még készülni, amire eddig nem készültek.
Ez gyakorlatilag 2db IT-t jelent + a komplexitás, ami a kettő összekötésével jár. Akkor az most független lesz vagy sem?
Ez az eset szerintem azt mutatja, hogy a rendszerek működését, függőségeket még jobban ki kell elemezni.
Elég kifordult értékrendre vall azt gondolni, hogy fontosabb repülni, mint például egy kg kenyérhez jutni. Szerintem a lakosság ellátásának, az ABC-nek a működésképtelensége alapvető probléma, a reptér pedig ott rohadhat meg, ahol van, a lőtéri sánta kutyát nem érdekli, nem kell az életbenmaradáshoz.
A reptér nem kritikus hely, mint fentebb említettem. A kórház az, csak arról nem beszéltél.
Teljesen jogosan, mint ahogyan az ember orrára csapódó vizespalack kupak is az EU megbocsáthatatlan bűne, a visszaváltandó, veszteségnek kellemetlen, magunnkal cipeléshez megint csak kellemetlen flakon is az, valamint forrasszon ón-ezüst-réz ötvözettel életfogytiglan az a rohadék, aki kitalálta, hogy ez jó lesz az ón-ólom ötvözet helyett. Ezért is szorgalmazom az EU-ból történő mielőbbi kilépést, nem lenne végre orra csapódó vizes palack, palackvisszaváltós szopatás, illetve használhatatlan forraszanyagok.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Azert varjal, tavaly 200 ezer tonna cargo-forgalom ment at a repteren, nem tudjuk, ebbol mennyi kell az "eletbenmaradashoz".
A repülőtéren megy át jó pár, az ország működése szempontjából létfontosságú dolog. Például a paksi erőmű működéséhez szükséges alkatrészek is. A pápai reptérre érkezik például a paksi urán. Nem olyan egyszerű ám az, hogy egy repülőtér nem létfontosságú. Dehogynem. Az üzleti utak és a cargo az fontos, a turistautak kevésbé, bár az országnak jelentős bevétele származik a turizmusból.
> fontosabb repülni, mint például egy kg kenyérhez jutni
hat ahol mar kenyer sincs onnan el kell repulni qrvagyorsan jo messzire
> Mennyire használható manapság a C# más, nem MS környezetekben (*)?
mikor eloszor megjelent linuxra es/vagy mac-re a dotnet, nagyon belelkesultem, aztan hamar kiderult hogy igazabol semmire se hasznalhato kb a hello worldon kivul. nincs gui, nincs meg a legtobb sdk/framework, nincs kb semmi se hozza. es ugy tudom azota se sokat javult a helyzet. leginkabb egy parasztvakitas az egesz, hogy kibujhassanak a monopoliumvadak alol kb
ugyanez igaz a linuxos powershell-re is, ahhoz sincs szinte semmi modul/extension, anelkul meg kb egy bash csak mas szintaxissal. pedig milyen jo lett volna linux alol matatni vele az o365-ot...
milyen?
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Hát, nekem kellett mostanában Linux desktop-ról Powershell-ben Entra ID konfigot meg Exchange Online mailbox matatást csinálni, és legnagyobb meglepetésemre meg tudtam mindent csinálni...
Vannak dolgok, amik nincsenek kint az admin webes felületeken M365-ben, de PS modulok formájában elérhetőek, és itthon csak Linux desktop van, próbáltam elkerülni egy Windows VM beüzemelését csak ezért. Sikerült.
ez jo hir, akkor fejlesztettek. 4 eve meg nem lehetett vele exchange onlinet sehogy se kezelni, meg ad-t is csak valami nagyon minimal alap szinten.
A teljes backendunk Linuxon fut, szoval ezzel azert vitatkoznek :)
MS-nél? :) Vagy már nem ott dolgozol?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Hat, ugy 6 eve nem.
Trust no one.
Teljesen. Linux szerverrol hosztoljuk a Windows es macOS gepeken fejlesztett .NET kodot. Nyilvan mindig lesznek olyanok, amik nincsenek Linuxra, pl. WPF, amibol a W a Windows roviditese :)
Ha valami, akkor pont az ellenkezoje igaz ennek, mintha VS-rol terelnenek le mindenkit. Kisebb projektekre VS Code, VS for Mac cancelled, en is Ridert hasznalok VS helyett, stb.
Nem tudom, nem is nagyon erdekel. Szerintem a legkenyelmesebb okoszisztema, amiben valaha dolgoztam, a fizetes meg minden honapban pontosan jon. Ha valami bajom van a dotnettel az legfeljebb az, hogy nagyon keves valoban erdekes projekt indul benne. A mienk so-so, talan meg a jobbak kozul valo, de ha megnezed pl a Github toplistat, nagyresze dogunalom.
WPF Linuxra és másra:
Avalonia UI
WinUI Linuxra és másra:
Uno Platform: Build Cross-Platform .NET Apps Faster
Köszönöm a válaszokat!
Azért kérdeztem, mert meglepett, hogy megszűnt a MonoDevelop, és amikor rákerestem a miértre, ezt a cikket (is) kidobta a kereső, és elgondolkodtatott. Mivel pár éves, gondoltam mostanra már kiderült az aftermath.
Jogos. Úgy kellett volna feltenni a kérdést, hogy mennyire próbálják még elgáncsolni az OSS alternatívákat. Ha nem is támogatják, de aktívan nem harcolnak ellene, az már szerintem előrelépés.
Egyáltalán, létezik OSS alternatíva, vagy csak az MS cucca van? (Itt vegyük külön a fejlesztő és futtatási környezetet, előbbiből ha jól értem nincs, utóbbit nem tudom.)
Ha lényegében csak az MS cucca használható a gyakorlatban, az mennyire OSS? Egyáltalán, letölthetem a forrását és lefordíthatom magamnak Linux alatt, majd forkolhatok belőle?
Nekem is ez volt az érzésem. Ezért lennék kíváncsi olyanok véleményére, akiknek elsőkézből van tapasztaluk ezzel.
Ezzel semmit nem mondtál. A Linux szerverek futtatják a .NET kódot, vagy a kliensek? Ha a szerver, akkor milyen OSS futtatási környezetek állnak rendelkezésre? Vagy csak van Linux port a zárt kódú MS cuccból?
Nem vagyok képben, pont emiatt kérdeztem. Mac ezek szerint kuka, Linux kuka (MonoDevelop megszűnt), na de mi a különbség a VS és VS Code között, nem fizetős MS termék mindkettő? Nemcsak látszat versenyről van szó, ahogy arpi_esp utalt rá? Összeírnád pár szóban, mi a különbség, ha megkérlek? Melyik zárt-nyílt, melyik IDE-fordítókörnyezet-futtatókörnyezet, stb. Nem kell hosszan kifejteni, csak pár pontban egy laikusnak, hogy mi a különbség a VS és VS Code között.
Nyilván, mivel esetedben a munkáltatód fizeti a licenszdíjakat és vásárolja a szükséges szoftvereket. De tegyük fel, hogy otthonra, saját zsebből, saját projektekre szeretnéd használni, akkor mi lenne a helyzet?
Ha jol ertem a kerdest, akkor az MS cucca maga az OSS alternativa, de barki forkolhatja es buildelhet belole sajatot. SDK es runtime is.
Itt van minden ami kell hozza: https://github.com/dotnet/
A Linux szerverek futtatjak. Mi csak a Microsoft-fele OSS runtime-out hasznaljuk. Zart forraskodu dotnet runtime ha jol tudom, nincsen.
VS Code es Rider van mindkettore, miert kuka?
De amugy barmiben irhatsz C# kodot, siman buildelhetsz CLI-bol is.
A VS egy klasszikus IDE, a VS Code pedig egy szetpluginezheto text editor. Elobbinek van ingyenes verzioja, utobbinak csak ingyenes verzioja van.
Otthonra magamnak fizetem a Ridert, de hasznalhatnam a VS ingyenes verziojat is.
Hát ettől sajnos egyáltalán nem lettem okosabb, megpróbálom átfogalmazni a kérdést.
Vegyük például a WebAssembly-t, az is bájtkód és OSS, próbáljuk meg ahhoz hasonlítani.
- ott használhatok bármilyen IDE-t, van ugyan integráció, de nem kötelező (pl. írhatom vi-ban vagy emacs-ban is)
- azt fordíthatom simán IDE-től függetlenül (mondjuk Clang-al, Bynarien-el; az emscripten és WASI SDK-k pedig IDE-től függetlenül is simán elérhetők és telepíthetők)
- azt futtathatom számos alternatívával (pl. wasmint, wac, wasm3, wasmjit, stb.)
Vagy hasonlíthatjuk akár a Java-hoz is, szintén zenész:
- ott is használhatok bármilyen IDE-t, van ugyan integráció, de nem kötelező (Eclipse, NetBeans stb.)
- azt is fordíthatom simán IDE-től függetlenül (a JDK, a .jar fájlok IDE-től függetlenül is simán elérhetők és telepíthetők)
- azt is futtathatom számos alternatívával (Oracle JRE, IBM JRE stb.)
Ha jól értem, az utóbbiból, a futtatási környezetből csak az MS cucca létezik, azt használja mindenki, de az legalább OSS és multiplatform.
Az viszont továbbra is rejtély számomra, hogy az első kettő mennyire lehet MS független, és hogy mennyire szorosan vannak egymásba integrálva.
Használható a C# IDE nélkül, azaz telepíthető a fordító és az SDK attól függetlenül, különösebb szívás nélkül? (Amit a MonoDevelop is csinált, de az megszűnt, van helyette más, nem MS cucc? Nem IDE, hanem SDK és fordító)
Vagy ez is olyan, mint az ObjC, amit csak XCode IDE-vel érdemes használni, mert minden mással agyhalál (ott hiába van pl. Linux-os fordító, használhatatlan, mert a szükséges SDK-k (ott framework-ök) csakis Mac-en elérhetőek)?
Szóval ha ezen három szempont alapján próbáljuk összehasonlítani, akkor miként néz ki a C#/.NET infrastruktúra?
> Használható a C# IDE nélkül, azaz telepíthető a fordító és az SDK attól függetlenül, különösebb szívás nélkül?
persze. en is mcedit-ben irtam c# kodot, es cli-bol buildeltem le macosen. pont mint a java, ott sem az IDE fordit hanem a javac nevu cli tool.
ami az izgi kerdes inkabb c#-nal az a frameworkok/sdk-k/libek, hogy ezek mennyire openek, illetve egyaltalan ezek mekkora resze all rendelkezesre windowson kivul mas os-ekre. bar egy reszuk eleve winapi wrapper, ott nyilvan ez nem kerdes... ez amugy java-nal is felmerult anno, mikor 25 eve abban dolgoztam, hiaba multiplatform a java, sok lib nem megy minden OS-en.
Nyilván, de ott sem maga a fordító a lényeg, hanem az SDK (java-nál van többféle, de igazából ott meg a middleware-k a rákfene). Ezért mondtam, hogy vegyük szét három felé a dolgot:
- IDE (nem a szerkesztés a lényeg itt sem, hanem hogy milyen SDK-val érkezik. ObjC esetén például esélytelen XCode nélkül használni, mert nincsennek meg framework-ök és nib toolok annélkül),
- fordító (ezek szerint ez OSS és multiplatform C# esetén, de MS-only, nincs alternatív implementáció, csak a dotnet-es? És mi van az SDK-val?),
- futtatási környezet (ezek szerint ez is MS-only, nincs alternatíva, de ez önmagában legalább teljesen OSS és multiplatform ha jól értem).
Ami nekem nem világos, hogy a VS/VSCode/stb. által felrakott SDK más-e, mint amit külön letöltesz; létezik-e C#-hez egyáltalán alternatív SDK, és ha nem, csak az MS cucca van, akkor mekkora a különbség a fizetős és az OSS SDK között? Merthogy SDK-ban van különbség a zárt forráskódúhoz képest, erről szól a cikk.
Vagy hát legalábbis pár éve még biztos volt, innen indult az eredeti kérdésem, hogy most is van-e még, vagy esetleg teljesen OSS SDK-ra váltott az MS, és csak IDE-ből próbál hasznot húzni?
Ha még továbbra is van külön fizetős SDK, akkor az OSS párja mennyire van lemaradva és mennyire van karban tartva? Kell-e fizetős IDE-t vásárolni, hogy normális SDK funkcionalitást kapjunk?
> ObjC esetén például esélytelen XCode nélkül
miert? fel lehet rakni valami magikus paranccsal a frameworkoket anelkul is, nekem mar 1x sikerult :)
> fordító
passz, oszinten szolva baromira nem izgatott sose, de meglepodnek ha nem lenne ms-tol fuggetlen fordito is mar, akar LLVM-re
> Merthogy SDK-ban van különbség a zárt forráskódúhoz képest, erről szól a cikk.
gondolom arrol szol (nem olvastam) hogy van windozon a .Net runtime, ez gondolom closed source, meg van a dotnet-core ami multiplatform es elvileg opensource. utobbi viszont csak egy kis reszhalmaza az elobbinek.
> Kell-e fizetős IDE-t vásárolni, hogy normális SDK funkcionalitást kapjunk?
miert kene?
Az a mágikus parancs az "xcode-select --install" :-D Igen, fel lehet tenni az XCode-ot a szövegszerkesztője nélkül, de azt is csak Mac-en.
Te magad válaszoltad meg e kérdést: "utobbi viszont csak egy kis reszhalmaza az elobbinek." Na, engem pont az érdekelne, hogy a gyakorlatban mit is jelent ez a "kis részhalmaz".
Az egyértelmű, hogyha tényleg komolyan venné az OSS-t a Microsoft, akkor nem létezne "kis részhalmaz", hanem a zárt kódú .NET és az OSS dotnet egy és ugyanaz lenne. A cikk pont emiatt siránkozik, és ha jól értem, ebben nem történt változás azóta sem, mind a mai napig van fizetős SDK (ami az VS/VSCode/stb. IDE-vel érkezik) és OSS SDK (amit meg a github-ről tölthetsz le).
Persze lehet, hogy csak rosszul értem, és az MS megtáltosodott, és e kettő mára már bitre ugyanaz (fordító, SDK stb. szóval a fullos fordító környezet), ezért kérdezem a gyakorlott C# fejlesztőket, hogy van-e különbség, és ha igen, mi.
De melyik az a zart kodu .NET?
Kb. ez a timeline:
Mostmar igazabol nincs is "core", hanem .NET Core -> .NET.
Igen, ezt kérdeztem... "ezért kérdezem a gyakorlott C# fejlesztőket, hogy van-e különbség, és ha igen, mi."
És ez bitre azonos azzal, amit a githubról lehet letölteni, valamint bitre azonos azzal is, amit a fizetős környezetek szállítanak? Vagy azért van különbség?
Magyarán:
- Alice megveszi az egyik fizetős VS/VSCode/stb. IDE-ét, SDK-stul stb., és csinál benne mindenfélét, majd a forrást elküldi Bob-nak.
- Bob csóró, ezért neki csak a github-ról ingyé' letöltött dotnet van, semmi más. Le tudja-e Bob gond nélkül fordítani Alice forrását?
Kell-e bármi speciális kiegészítőt (lib-et, SDK-t, bármit) vásárolnia Bob-nak, vagy tényleg teljes értékű és bármihez elegendő a github-on található ingyenes környezet?
Igen, mert Alice is ugyanazt az SDK-t használja alapvetően. Az, hogy a Visual Studio IDE fizetős, az egy dolog - hát az IntelliJ IDEA is az, nem újdonság, hogy vannak fizetős IDE-k.
Mivel Visual Studio csak Windowsra van, ezért előfordulhat, hogy Alice használ Windows-only libraryket (WPF, MAUI, COM stb.), ezek nem része a crossplatform SDK-nak, az ilyen kódot tartalmazó cuccot Bob NEM fogja tudni lefodítani Linuxon.
Ha Bobnak van egy Windowsos gépe, akkor le tudja fordítani az ingyenes SDK-val is, hiszen a WPF, MAUI, COM stb. azok csak külön telepítendő library-k Alice számára és Bob is, nem az alap SDK részei.
https://github.com/dotnet/wpf
Ez egy .NET projektben egy sima külső függőség (Nuget csomag), úgy kell kb. elképzelni, mint a Java világban egy Maven függőséget. Csak éppen Windows-specifikus. Gondolj rájuk úgy, mint natív kódot tartalmazó, csak Windowson futó JAR-okra a Java világból. De ezek a dolgok is elérhető ingyenesen, csak éppen Windows-onlyk.
Olyan nem lesz, hogy Windows-only kódot Bob Linux alatt le tud fordítani, hiszen a Windows-specifikus library-k hiányozni fognak.
Hat hogy konkretan bitra ugyanaz a build van benne, azt nyilvan nem tudom, de nincs kulon fizetos meg ingyenes SDK.
Az SDK szempontjabol alapvetoen igen, ha mondjuk OS specifikus kod van benne (WMI, WPF, stb.), akkor persze lehet, hogy nem.
"a zárt kódú .NET és az OSS dotnet egy és ugyanaz lenne."
Felejtsük el a .net framework-öt, amit te zárt kódú .net-nek nevezel. Az egy sok éve meghaladt framework, új projekt nem nagyon indul benne, csak hibajavitást kap, új feature évek óta nincs hozzá. (de szerencsére, még jó sokáig támogatott lesz)
Helyette van - szintén sokéve - a .net core, ami teljesen nyilt forrású, mind fejlesztői oldalról, mind futtató oldalról.
A másik tévedés, hogy a visual studio fizetős lenne. Szerintem a usereinek 80%-a az ingyenes community edition-t használja, én is.
A forrása nem nyilt, akinek az kell, annak ott a vs code, mindenféle platformra.
Itt is. Irhatod akar notepadban is, tokmindegy, ezek csak text fajlok, utana `dotnet build` a terminalba, es keszen vagy, csak ez sokkal kenyelmetlenebb, mint egy tetszoleges IDE.
Itt is.
Fogalmam sincs. Elvi lehetoseg van ra, 4600 forkja van a runtime-nak Githubon, barki csinalhat sajatot, ha akar. Amugy a runtime opcionalis, fordithatsz olyan futtathato fajlt, amihez nem kell semmi, csak akkor a harom OS-re kulon build kell.
Nem ertem a kerdesed. Ha az abszolut minimumot kerdezed, akkor kell text editor, kell a dotnet SDK, meg kell egy terminal, amibe neha beirod, hogy dotnet build.
Nagyon, nagyon leegyszerűsítve: a cikk szerint ha letöltöd az OSS SDK-t és azzal dotnet build-elsz, meg ha felteszed a fizetős VS/VSCode/stb.-t és az azzal érkező fizetős SDK-t nézed, a kettő nagyon nem ugyanaz. Legalábbis egész biztos nem volt ugyanaz 3 éve. Most mi a helyzet ezzel?
Kell-e fizetős IDE-t vásárolni, hogy normális SDK funkcionalitást kapjunk?
Nem, nem kell. Az a fajta kettősség, hogy volt a .NET Framework (Windows-only, proprietary) és volt a .NET Core (open source, crossplaform), az már megszűnt.
Van a .NET, open source, minden platformra elérhető SDK-val. Ebben az SDK-ban a Windows-only funkcionalitások értelemszerűen nincsenek benne, csak az, ami minden támogatott platformon (Windows, Mac, Linux) működik. Például nincs benne Windowos ablakozó felület integráció, meg COM. De ugyanúgy van benne CLI fordító meg minden, pontosan ugyanolyan, mint egy JDK.
Ezt az open-source, minden platformra elérhető SDK-t letöltheted és telepítheted szabadon.
Aztán, hogy miben írod meg a kódot, legyen az vi/vim/VS/VSCode/Rider/notepad/emacs akármi, a build CLI-ből megy ugyanúgy.
Pontosan ugyanolyan a helyzet, mint a Javanál, csak a Javaban van Swing meg AWT UI, a .NET-ben meg nincs desktop UI library beépítve (mert nem támogatják a desktop UI-t, csak Windowson, arra külön Windows-only library van). De erre meg vannak crossplatform, open source megoldások is, pl. Avalonia UI.
Köszönöm, pontosan erre voltam kíváncsi.
Tehát ami a cikk frusztrációját adta, az teljesen megszűnt, és a fizetős is pont ugyanarra az ingyenes OSS kódra épül már. (Tehát a burzsuj Alice forrását a csoró Bob gond nélkül le tudja fordítani, akár másik platformon is, ez volt igazából a kérdésem. Az oké, hogy a WinUI csak Win alatt van.)
ps: Már csak az a kérdés, hogy ez így is marad-e, vagy megint meggondolja magát a Microsoft. Kis szerencsével marad így.
Mivel ezek a komponensek nyílt forráskódúak, maximum azt tudja csinálni, hogy a jövőbeni állapotot bezárja, de ami nyílt volt, az nyílt marad. Pontosan ugyanúgy, mint a Javanál.
Meg hát eleve az egész .NET platform fejlesztése Githubon zajlik, te is adhatsz be pull requestet, ha akarsz, nem kevés azon fejlesztők száma, akik hozzájárultak a .NET-hez, de nem Microsoft alkalmazottak.
Nyilván, itt nem is ez az aggasztó, hanem ha esetleg bezárnák, akkor mennyi ideig maradhat még működőképes a community által leforkolt dotnet.
Ugye mivel itt minden az MS kezében van, a bezárás után simán eszközölhetnek olyan pici .NET API változtatásokat, ami miatt a community dotnet nem lesz kompatíbilis és használhatatlanná válik, és csak a zárt VS .NET fog működni, ezt elég könnyen megléphetik.
Java-nál is fennáll ennek a veszélye (láttunk is próbálkozást a bezárásra), de ott nagyobb esély van arra, hogy más IT óriások szarrá perelnék az Oracle-t egy ilyen lépésért, mivel ott szerteágazóbb kezekben van az ökoszisztéma.
Imho elobb pusztul ki a Visual Studio, minthogy ujra zart legyen a dotnet, de ez mindegy is, mivel a zart forraskodu, .NET FW SDK is ingyen letoltheto volt.
Nem egeszen, a cikk valami egesz masrol beszel, ugye ott az volt a kerdes, hogy a hot reload bekeruljon-e az SDK-ba, vagy VS feature legyen belole. Bobnak, aki csak buildelni szeretne, ez tokmindegy. Ha Alice megirja a forraskodot, akar hasznal kozben hot reloadot a teszteleshez, akar nem, azt Bob attol meg le fogja tudni buildelni.
Ilyen ertelemben persze, a fizetos IDE faszabb, mint a text editor. A Rider is tud olyan feature-oket, amiket a Notepad mar nem tud, de ettol meg ha a Git repombol leszeded a kodot, egy Notepad + dotnet CLI kombovaltudsz rajta modositani es le tudod buildelni. Annyi, hogy nekem kenyelmesebb volt a fejlesztes.
A hot reload nem ahhoz kell, hogy a forraskodbol futtathato fajl legyen, hanem hogy ne kelljen baszakodni annyit fejlesztes kozben az ASP.NET app ujrainditgatasaval, de ez csak kenyelmi feature, sem a kodon, sem a futtathato fajlon nem latszik, hogy volt-e hasznalva fejlesztes kozben.
Nem a hot reload konkrétan a lényeg, lehetne akár XY funkció is.
Nincs itt semmi ellentmondas.
Van mondjuk a Riderben egy feature, hogy futas kozben kirajzolja az aszinkron hivasok kozotti grafot, mondhattam volna azt is. De ez IDE feature, ilyenek mindig is lesznek, minden programnyelvben, hogy nem a szabvanyos SDK, build tool, stb. csinalja, hanem a fizetos/nemfizetos IDE. A forraskodon viszont nem latszik, hogy hasznaltam-e ezt a feature-t, te ugyanugy le tudod buildelni a sajat gepeden, Rider nelkul.
Nem IDE, SDK, azt mondtátok, nincs az IDE egybegyógyítva vele, tehát ennek fizetős SDK feature-nek kellett volna lennie (ha nem viszakoztak volna). Nyilván az IDE az SDK-n túl is biztosít plusz funkciókat, de itt most nem ez a kérdés (mert IDE fetaure nem kerülhetett volna végül az OSS SDK-ba).
De mégegyszer, az, hogy maga a funkció mi is volt, ebből a szempontból tök lényegtelen, csak az a fontos, hogy ha nem azonos a kódbázis, más SDK van az IDE-ben és más, ami letölthető, akkor előfordul eltérés.
Ellenben ha a két SDK kódbázis azonos (mint ahogy most állítjátok, hogy az), akkor ez még elméletileg sem lehetséges, ami tök jó.
De nincs fizetos SDK, nem tud valami a resze lenni egy olyan dolognak, ami nincs.
IDE feature-t csináltak egy SDK feature-ből, csak azért, hogy fizetős lehessen, erről van szó.
És ilyenkor merül fel a kérdés, hogy a meglévő ingyenes SDK-ban lévő feature-ök közül menynit fognak átemelni Visual Studio-only feature-ré, hogy a fizetős szoftver felé tereljék az embereket?
De pont arról van szó, hogy egy olyan toolt, amit alapvetően az SDK-ba terveztek betenni (dotnet watch), csak a fizetős IDE részévé teszik, hogy tereljék a népet afelé, hogy fizessen.
Miközben hasonló hot reload azért van NodeJS-nél is, Spring Bootnál is (spring-boot-devtools) stb. Sehol nem az IDE része.
Én nem láttam a cikkben olyan felvetést, ami a forrás fordithatóságát/futtathatóságát feszegette volna oss/fizetős vonalon.
Sosem volt ilyen probléma a core kapcsán.
Egy fejlesztést támogató eszköz IDE-be vagy nem IDE-be kerülésén volt vita, de az is megoldódott sokéve.
Mert nem is ez volt a kérdés, mint ahogy a hot plug sem. A hot plugot csak egy példának hozta, de általánosságban beszélt mindvégig.
Azt is írja még, hogy
Na a közös kódbázisra hozás pont ezt a legnagyobb méregfogat húzta ki. (És nem számít, hogy a pull request konkrétan milyen funkciót valósít meg, csak az, hogy nincs külön repó már.)
Szerintem a .NET core (vagy mi a neve) bátran használható, azt nem tudják/akarják elérhetetlenné tenni. Viszont MS zárt technológiát nem használnék.
Programozunk C#-ot. Eredetileg VS-ben Windowson fejlesztett projektet sikerült Linuxon is elindítani viszonylag egyszerűen, de nem kevés munkával.
A C# technológia nagyjából egyenértékű a Javával. Javához szerintem sokkal több és jobb eszköz van, emiatt is Java párti vagyok. Például a C# alkalmazásunk profilozása nem tűnik triviálisnak Linuxon. Ezzel szemben Javához többféle ingyenes szabad szoftver is van, és régebben használtam drágább zárt szoftvereket is, amik nagyon kézre álltak a profil logok elemzéséhez. Az eszköztámogatás miatt szerintem ésszerűbb a Javát választani, én meg ugye abban dolgozok alapvetően, azért is a Javát választom, ha rajtam múlik.
en ugy emlexem anno a java konkurenciajanak szanta az MS a C#-t, de mivel nagyon sokaig windows only volt, vegul a java helyett a delphit sikerult levaltaniuk vele :)
Szerintem a Delphi a TP alapja miatt mar amugy is haldoklott addigra. A C++ Builder sem jott be a Borlandnak, nem terjedt el.
A strange game. The only winning move is not to play. How about a nice game of chess?
Vajon hihetünk a Microsoftnnak bármi kapcsán?