A Microsoft megnyitotta a Visual Studio Code forrását

Open Source

Áprilisban jelentette be a Microsoft ingyenes, keresztplatformos - Linux, OS X, Windows - forráskódszerkesztőjét, a Visual Studio Code-ot. Most pedig azt jelentette be, hogy a Visual Studio Code forrását elérhetővé tette a GitHub-on. Licence MIT licenc.

( mrceeka v | 2015. 11. 18., sze – 17:46 )

Meg az is vicces, amikor Visual Studioban megírod a .Net 5 kódot, majd Publish, amire egy Docker konténert küld egy Linuxos gépre...

Preview-ban pedig a .Net kódból Linuxon dependencia-mentes natív binárist fordít...

Üdv,
Marci

Oké, oké, de azért kijöhetne végre az MS egy desktop enterprise Linux-szal. Kerüljön pénzbe, na bumm. A Windows nem jó, a mai ingyenes vagy EL disztók pedig vagy ki tudja, hogy mit tartalmaznak (pl. Arch AUR-ok) vagy a disztró készítőnek perverziója az elavult csomagok szállítása (pl. Ubuntu 15.10-ben docker 1.6.x).

Először el kellene dönteni, hogy mit szeretnél csinálni. A Docker segítségével Linux-alapú konténereket kezelni, vagy Windowson szeretnél hasonló OS-virtualizációt.

Maga a OS-virtualizáció nem újkeletű dolog, kérdezz meg egy FreeBSD Jail felhasználót erről, vagy egy Solaris Containers adminisztrátort. Windowsra ugyanilyen régóta érhető el hasonló megoldás, pl. a Parallels Virtuozzo személyében, de régóta létezik a VMware ThinApp is és Windows 2016 TP3-tól a MS saját Containers megoldását is használhatod.

Az mindenesetre nem túl erős érv, hogy te darus csörlőt szeretnél a villás raklapemelő targoncára, és amiért nincs rá, ezért nem jó a targonca...

Ha mklink kapcsán az a bajod, hogy alapértelmezetten biztonsági okokból csak adminisztrátorok használhatják, akkor ezen könnyen lehet segíteni: http://superuser.com/questions/124679/how-do-i-create-a-link-in-windows…

Bár továbbra se látom, hogy ez a linkelés miért ennyire fontos...

Alapvetően Linux konténeresdi kell nekem. A Docker adott és kőbe van vésve, ehhez kell igazítanom az életet, és erre a Win nyilván nem alkalmas.

Az mklink csak egy apró kis szösszenet. A linkelt megoldás sajnos nem jó nekem, mert nem fogom mindenki gépén a policy-t állítgatni. De alapvetően megkerülhető, emiatt nem dobnám ki a Win-t. Csak bosszantóak az ilyen szösszenetek tucatjai.

De a kiindulási problémám nem is ez volt, hogy a Win jó-e nekem vagy nem, hanem csupán egy nem túl eredeti felvetés, hogy az MS végre kiadhatna egy EL disztrót, ha már ennyire tolja a Linuxot.

Már 7 éve dolgozom olyan környezetben, ahol mindenki admin a gépén, kérdés nélkül. Úgy, ahogy otthon is...
És ha jól érzékelem, sokkal kevesebb dolga van az IT-nak a Felhasználókkal és sokkal kevesebb baja van a Felhasználóknak.
Fáj belegondolni, hogy hány olyan hely van, ahol desktop korlátozásokkal teszi pokollá a maga és a Felhasználók életét az IT.

Üdv,
Marci

"És mindenki telepíthet amit akar" - már csak az hiányozna. Megvannak a megfelelő szabályzatok, be kell őket tartani.
"az IT meg tartja érte a hátát" - miért tenné, nem ő sértette meg a szabályzatot...
"Szuper hely lehet" - Egyetértek, szuper egy hely! Az például kifejezetten tetszik, hogy felnőttnek vannak tekintve a felhasználók, akiknek megvan a felelősségük azért, amit és ahogyan tesznek.

Üdv,
Marci

És amikor jön egy ellenőrzés akkor mind a 227 felhasználót odahívjuk, hogy mesélje el, hogy mi van a gépén és mért, ugye? Ne haragudj, de kicsit kami-kaze akciónak érzem ezt így. Szerintem az informatikában egy cégnél nincs demokrácia, mert az fejetlenséget szül. Kellenek szabályok, amiket a hüly..gyengébb felhasználóknak is és a hardcore usereknek is be kell tartani. Értem én hogy értelmes emberek ülnek ott, de ez szerintem akkor sem állapot.

"mind a 227 felhasználót odahívjuk, hogy mesélje el, hogy mi van a gépén" - erre való a központi szoftverleltár. És igen, a felhasználó felel azért, amit a gépre telepít a központilag biztosított szoftvereken túl.

"Kellenek szabályok, amiket a hüly..gyengébb felhasználóknak is és a hardcore usereknek is be kell tartani. " - Fent írtam, vannak szabályok és be kell őket tartani.

Szerintem eléggé végiggondolt rendszer üzemel itt, 100000+ felhasználó és jóval több IT eszköz kezelése nem mindennapi feladvány.
Ráadásul az alkalmazott megoldásokról sok mindent publikál a cég, szíves hasznosításra.
Innen kiindulva mindent megtalálsz:
Microsoft IT Showcase: How Microsoft does IT

Üdv,
Marci

Azért furcsálom ezt, mert akkor ezek szerint, ha bekaptok egy 0dayt, akkor esély sincs arra, hogy egyes korlátozások révén az ne szabaduljon el a belső hálózatban (pl. - stage 1 - böngésző exploit letölt egy egyedi trojan/worm/akármi binárist és ezek szerint az lokálisan simán futhat...)

Első kettőnél nem látom, hogy miért kell desktop, hacsak nem kifejezetten Linux desktop alkalmazásokkal és környezeteikkel bajlódsz. Ebben az esetben viszont érthetetlen a Windows hogyan jöhetne egyáltalán szóba, miért került a csizma az asztalra.

A harmadik esethez pedig felesleges, de legalábbis nem ideális a docker. Használj a Skype korlátozásához RBAC, RSBAC, Apparmor vagy SELinux szabályozást.

És bármit írnak és mondanak, ne hidd el, hogy a Docker biztonságos izolációra alkalmas.

> Első kettőnél nem látom, hogy miért kell desktop

Minden helyben el tud futni: mini tesztkörnyezet, fordító és környezete. Nyilván kérdés, hogy mi a szösznek ez nekem, amikor erre vannak a szerverek, de nekem így tetszik, hogy néhány git push/pull-t leszámítva totál offline is lehetek.

> ne hidd el, hogy a Docker biztonságos izolációra alkalmas.

Igen, tudom.

"Az MS-nek jó lenne, mert a Win olyan technikai akadályt állít elénk, hogy kénytelenek vagyunk ezrével Linux desktopra átmenni."

Ezt írtad. Ezek alapján ez olyan számomra, mintha egy faipari cégnek bejönne egy hegesztéssel kapcsolatos munkája és elkezdene a körfűrész gyártójánál panaszkodni, hogy nem lehet a körfűrésszel hegeszteni, ezért igazán tehetnének már valamit, ha más nem, kezdjenek már el hegesztő berendezéseket is gyártani... :)

Ami egyébként még működhetne is, ha több millió darab vásárlásáról van szó (nem ezer), csak nem egy random alkalmazottnak kell az internet egyik zugában ezzel próbálkoznia, hanem a cége vezetőjének a másik cég vezetőjénél.

De értem, hogy ez valamiféle wishful thinking volt, még ha meglehetősen furcsa is. :)

"ki tudja, hogy mit tartalmaznak (pl. Arch AUR-ok)"
-> megnézed az aur scriptet, hogy mit csinál
-> megnézed hogy mit honnan tölt le, aztán rájössz hogy a spotify, oracle sqldeveloper, skype és egyéb binárisok pont ugyanúgy "ki tudja mi a szar ez" dolgok mint windows-on a setup.exék

--
arch,debian,openelec,android

Ez igaz. Az AUR-okkal csak az a gondom, hogy kissé kaotikusak néha, pacmanban ott van egy csomó izé. Win exe-ket és pl. Ubuntu repókat az eredeti szerzőtől szedem, bár nyilván ezt AUR-ral is meg lehet tenni. Ez persze nem biztosíték semmire, ez igaz. Ezért is jó lenne egy többé-kevésbé megbízható forrás. Meg valami finomhangolt, észrevehetetlen, biztonságos sandboxing :)

A nativ binaris (fuggosegek nelkul) feltetele a full aot - a .net native forditoja egyelore csak UWP (windows store) alkalmazasokat keszit es a forraskodja zart (es nem is valoszinu, hogy meg lesz nyitva - mivel a Visual C++ forditojukat hasznalja (C2) [1] [2] - az llilc forraskodja ugyan nyitott de meg tavol all a kesz verziotol.

Esetleg erre gondolsz?

https://github.com/dotnet/coreclr/blob/master/Documentation/botr/readyt…

[1] https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native
[2] https://channel9.msdn.com/Events/dotnetConf/2014/-NET-Native-Deep-Dive

Es itt pedig pull request formaban is lathato [3] - akarmi is legyen az a Microsoft.DotNet.ILCompiler komponens ami az IL->C++ atalakitast csinalja - ugy tunik clang-3.5 ami vegul elkesziti a binarist. [1] [2]

[1] https://github.com/dotnet/cli/blob/master/src/Microsoft.DotNet.Tools.Co…
[2] https://github.com/dotnet/cli/blob/master/src/Microsoft.DotNet.Tools.Co…

[3] https://github.com/dotnet/cli/pull/217

Úgy tűnik épp nem műkszik. :(

Note: the below is not currently working with the installers above - fix coming ASAP!

Finally, you can also try out native compilation on Windows and Linux. Note: at this point, only the helloworld and dotnetbot samples will work with native compilation.

https://github.com/dotnet/cli/blob/master/README.md

( mrceeka v | 2015. 11. 18., sze – 19:03 )

Remote GDB debugging távoli Linux gépekre Visual Studioból, mondjuk Raspberry PI-ra.

Üdv,
Marci

( mrceeka v | 2015. 11. 18., sze – 19:22 )

Fejlesztés MacOS-re Visual Studioban, partner által hosztolt távoli Mac toolchainnel.

Üdv,
Marci

( mrceeka v | 2015. 11. 18., sze – 19:29 )

Demo: saját vércukorszintjéből és pulzusából Azure Machine Learning-gel kalkulál egy stresszfaktort, melyet az Office 365 Graph API-val rávetíti a naptárára, megállapítva, hogy kivel találkozik épp, amikor a legstresszesebb, vagyis: ki a fő stresszforrás a számára...

Üdv,
Marci

(mielőtt kérded: cukorbeteg, eszköz méri folyton)

( mrceeka v | 2015. 11. 18., sze – 21:00 )

TypeScript kapcsán a Google-ös Angular csapattal való együttműködésről: "The things you discover doing open source: we're all just engineers. We all just love writing code. And when we first met with the Angular team it took us like 15 minutes to realize: 'Boy, we all speak the same language here!'"

Üdv,
Marci

Szerintem e nélkül is megtörténhet és ráadásul nincs is azzal semmi baj.
Előny, hogy nem kell céges politikával foglalkozni: mit mondunk el-mit nem stb.
Ott a forráskód, nyílt és szabad, ott a nyilvános roadmap a tervezett funkciókkal, semmi titkolózás.

A most épp fent lévő a videon 6:08:50-től: https://channel9.msdn.com/ (Ez a link csak a hozzászólás ideje környékén érvényes.)

Üdv,
Marci

( BaT | 2015. 11. 19., cs – 00:11 )

Ennek örömére megint felraktam, megjavítottak minden hibát amiket még áprilisban tapasztaltam, köztük a legidegesítőbbet is. Egyelőre marad. :)