Windows Subsystem for Linux přináší lepší propojení s Windows

https://blogs.technet.microsoft.com/windowsitpro/2016/10/18/microsoft-update-catalog-site-updated/

Windows update catalog je již možné použít v jakémkoliv prohlížeči, pověst nelhala - dočkali jsme se :-)

Nevím, jako někdo kdo spravuje WSUS nemám potřebu řešit katalog častěji než 2x do roka. A vyhledávání a procházení je tam řešeno krásně. Lze filtrovat i SQL dotazy.
Není žádný tajemstvím že 75% aktualizací má napsáno že pravděpodobně bude třeba restartovat. Z vlastní zkušenosti mám pocit že reálná potřeba je tak u 50%. Ale samozřejmě když instalujete více aktualizací najednou což je naprosto běžný stav, tak to restart chtít bude.

No, mam ako Windows programator niekolkorocnu skusenost vo firme, ktora je jednym z velkych hracov na dost podstatnom trhu, zamestnava 5ciferny pocet zamestnancov a ma snad aj 30 rocnu tradiciu. Relativne donedavna neboli ine platformy pre tuto firmu zaujimave, ale Mac to nejako zmenil (asi ked presli na Intel).

Je tu armada Windows-only programatorov, ktori maju dost pokrivene chapanie o svete okolo seba. V nasom niekolko miliard riadkov velkom codebase je uplne standardnym typom chyby tzv. "build error". T.j. ze sa nieco v MSVC (2015.2 btw) pri buildovani pokasle a vystupna binarka nejakym nedeterministickym sposobom, ktory nie je build stack schopny rozlisit, nezodpoveda vstupnym zdrojakom. Efekty sa mozu roznit od mystickych bugov, ktore na prvy druhy aj treti pohlad vyzeraju realne, cez spravanie, ktore napriek rovnakym verziam vsetkeho nejde reprodukovat na ziadnom inom stroji az po pady a bugy v prekladaci (za ten cas, co pouzivam MSVC som ho videl spadnut alebo vygenerovat bug / nekorektne spracovat standard compliant kod viac ako za 12 rokov, co sa hrajkam s prekladacmi okolo Linuxov). Proste to, ze MSVC funguje nedeterministicky a je nenulova (dokonca pri pouzivani diferencneho buildovania a/alebo paralelneho buildu v ramci jedneho projektu pomerne brutalne velka, radovo v jednotkach, niekedy az desiatkach %) sanca, ze prekladac skompiluje nefunkcnu binarku a programatori to beru ako fakt. Ani im to nevadi, vsetci len nadavaju na to, ze LLVM je rychlejsi a MSVC je pomaly hnoj. Namiesto toho aby videli 100% buildov prejst bez zahadnych neopakovatelnych chyb na strane toolchainu (co zabije priemerne 2 hodiny) by videli prekladac o 10% rychlejsi. Divna mentalita. Chapem, ze pri takom vnimani sveta je povazovany windows a jeho kompletny ekosystem za uplne spolahlivy, logicky, rozumny, spravny a vykonny.

Dalsim pomerne popularnym typom problemov su nedeterministicke runtime zlyhania. To su take, ktore neopravi ani kompletny rebuild zdrojakov (cca 2 hodky), kompletny wipeout build stromu a rekompilacia (o hodku viac) ale pomoze jedine fraza "Did you try turning it off and on again?". Literally som tym nedavno zabil skoro 2 dni, pretoze este nemam ten grif vediet, kedy aka nepravdepodobna akcia vyriesi aku nepravdepodobnu nahodnu chybu a doveroval som tomu, ze system nebude po troch dnoch uptimu nepevny. Bohuzial bol.

Tiez chapem, ze pre niekoho, kto je zvyknuty pracovat s API navrhnutym stylom - potrebujes novu ulohu, vytvor si na to thread (pretoze sa to inak aj tak spravit neda) moze povazovat glibc (resp. libc) za archaicke a navrhnute v 70. rokoch. Ono to tak navrhnute je, to nikto nepopiera. Toto API je ale opat aspon deterministicke a je hodne problematicke (ak nie uplne nemozne) nejakou uplne irelevantnou zalezitostou spravit z formalne spravneho kodu fakticky nekorektny program. Pri spravne kombinacii linkovania a pouzitych syscallov to na Windowse nie je problem (aj ked musim priznat, ze zmieneny typ linkovania sa uz asi standardne nepouziva).

Ku kvalite, resp. nekvalite opensource software-u, ktory je zadarmo, pretoze je nekvalitny. Nezamienajte nedostatok vlastnosti s nekvalitou kodu. Opensource software casto neobsahuje tolko vlastnosti ako komercny, pretoze ich casto jeho autor proste nepotreboval, ale po nahliadnuti do kodu, ktory pisalo niekolko titulovanych programatorov s prijmom nad pol miliona dolarov rocne si dovolim tvrdit, ze opensource je jedna z najkvalitnejsich veci, ktore in the wild chytite. V priemere, samozrejme existuju aj odpadne, zle navrhnute a naprogramovane OSS kusky. Ale closed source software nemusi vystavit svoju kozu na trhu, takze su tam perly pred zrakmi ludi uplne skryte. V niektorych pripadoch nie je problem najst kusy kodu s ktorymi by neuspel ani student 1. rocnika na VUTBR na predmete programovanie v jazyku C. Ciastocne je to dane tym, ze historicky bol (a v sucasnosti stale je) MSVC co sa tyka kvality prekladu odpad. Stale je v nom mozne skompilovat trivialne nednoduche kusy kodu, ktore vedu k nekorektne chovajucim sa programom. To by bolo fajn, keby tie trivialne jednoduche kusy kodu neboli bezne pouzivane, takze sa casto v kode nachadzaju casovane bomby. A len znalost chyb v MSVC umoznuje takymto bombam sa vyhnut. Ale tato zdanlivo beztrestna akceptacia hnojarskeho kodu viedla k tomu, ze si ludia na to zvykli a dokonca pozaduju aby ich hnojarsky kod niekedy slo skompilovat aj inde, aj ak je zjavne nesplnajuci ziaden standard pre jazyk.

Ciastocne je to ale dane aj tym, ze debugger ako taky je prakticky nepouzitelny na akykolvek sebevacsi projekt. Dodnes je VS 32-bitova aplikacia, takze staci projekt s 10timi trocha bachatejsimi kniznicami a VS v lepsom pripade vyhlasi, ze zdetekovalo nedostatok pamate (co na tom, ze stroj ma 32GB RAM a 26 je pocas debuggovacej session volne, NIE JE JEJ DOST). Clovek potom musi unloadnut vsetky pluginy, ktore robia VS pouzitelne a vypnut intellisense aby sa VS pocas debugovacej session nestrieskalo. S VS12 to tak dobre nebolo, to si sem tam pamat pocas debugovania nejakym indexovanim na pozadi vyzralo a po pol hodine lovenia bugu v tom najlepsom proste padlo. Ak uz debugger nespadne, tak sa sem-tam stane, ze sa rozhodne, ze ani na debug builde proste do nejakeho symbolu pri nejakom pohlade nemozno nahliadnut. Lebo medved. Pripadne sa rozhodne, ze ignoruje breakpointy, alebo vyparati nejaku inu zaujimavu vec.

Po tom vsetkom sa nedivim, ze kvalita codebase Windowsu je taka aka je, pretoze kvalita toolchainu postaveneho okolo MSVC je mizerna a Microsoft tuto mizernu sadu nastrojov pouziva na vyvoj svojho vlastneho systemu. Z toho nemoze vyjst nic rozumne, pretoze je v podstate nemozne seriozne debugovat akykolvek aspon trocha vacsi program, ktory sa rozhodne velmi vyznamne pokaslat. Ak su API vyssej urovne rovnako deterministicke ako API urovne najnizsej (ze sa napriec roznymi variaciami a/alebo systemami chovaju odlisne a dopredne zmeny su nepredvidatelne), tak sa nedivim, ze je bezne, ze update dnes rozbije aplikaciu zo vcera - napr. W10 SP1 rozbija Lync 2010 (pouzivam ho, pretoze ani 8jadier i7cky, ani 32GB RAM nestaci Skype4Business na to, aby pocas kompilacie vyrenderoval jeden riadok textu v case pod 30 sekund) a ani Microsoft Certified Engineer nevedia, co s tym. Da sa to "opravit" ale je to Windows 95 style hack skopci tento subor z tamtoho neupgradovaneho systemu tamto a pojde to.

Rad sa necham poucit (uprimne), pretoze siroko daleko najlepsie, co sme napr. na hladanie memleakov nasli bol Visual Leak Detektor, ktory je oproti Valgrindu ako uboha detska hracka. Valgrind zasa na x64-rkovych widliach nefunguje. Bohuzial ani nastroje z anektovanych System Internals niekedy nefunguju uplne, alebo vobec.

Ale za tym, ze VC/VC++ je hnoj si stojim.

Takze suma sumarum sme sa dostali k tomu, ze microsoft ma uplne skvele vyvojove nastroje, len ich bud nikto nikde v realnom svete nevidel, alebo su uplne skvele na jeden konkretny ucel, ktory nikto nepotrebuje? :) Ale nastroje, ktore ludia realne potrebuju - prekladac na ktory sa da spolahnut a funkcny debugger / memleak detektor - ludom nedodali.

Chapem to tak spravne?

Detekcia memleakov bola vo VS12 uplne nepouzitelna, koniec koncov preto vznikol projekt VLD, co je v podstate to iste ako ste si urobili vy (instrumentaciou sa pretazia volania na alloc a dealloc a robi sa nad tym nejaky processing). Je to fajn, je to relativne rychle, ale tie fakt uplne najuchylnejsie chyby to nema sancu spozorovat. Ak sa bavime o veciach ako off-by-one, alebo strata referencie, tak VLD a ine na instrumentacii zalozene nastroje sice zistia, ze nejaky chunk pamate niekde zostal neuvolneny, ale chce to hodne usilia zistit, co tam tak asi bolo a kde sa to stalo (ofc, da sa ulozit stack trace v case alokacie, ale nie je mozne zistit akym sposobom sa na ten blok zabudlo, resp. aky je dovod jeho nedealokovania).

Valgrind je user-space zalezitost, pretoze pre vyvoj v Linuxovom kerneli platia nejake pomerne dost striktne pravidla a pouzivaju sa na to urcene nastroje (a imho plati pravidlo, ze userspace sa nema co zaujimat o dianie v kerneli. ten bud funguje tak, ako je popisane v dokumentacii API, alebo je to bug). Valgrind funguje stylom tenkeho virtualneho stroja, takze hookuje aj pamatove operacie a je schopny trackovat pouzivanie pointerov na blok pamate, takze okrem bodu vzniku pamatoveho bloku volanim alloc a jeho uvolnenia volanim dealloc vie napr. aj zistit, kedy sa stratila posledna referencia na blok pamate. Poskytuje to uroven informacii, ktoru asi poskytne maloco ine, ale je to uzasne pomale.

Konkretne ja som narazil na problem s nastrojom GFLAGS, ktory umoznoval menit flagy binarky. Ten fungoval spravne iba ak sa vpisal nazov binarky bez cesty. Ak sa uviedla cela (hoc spravna) cesta, nastroj nemal efekt ziaden a nevyhlasil ziadnu chybu.

Ja som tu cest mal viac krat. Na poli templatov viem o dvoch chybach plynucich z krutej a prachsprostej ignoracie klucovych aspektov 25 rokov stareho standardu, ktore vedu v prvom pripade k nevysvetlitelnemu padu aplikacie v runtime (na ten sme nenarazili, ale hodne casto sa uvadza ako priklad toho, ako zle je ten prekladac urobeny) a v druhom pripade ku skompilovaniu tak zjavne syntakticky nespravneho kodu (na co sme narazili a zabralo to 2 dni prace jedneho developera, ked si prekladac povedal, ze uz mu tie syntakticke chyby vadia), ze je to do neba volajuce. Afaik oba problemy (a tak tona dalsich na poli templatov) su este aj v poslednej iteracii VC pritomne a Microsoft ich nehodla opravit (pretoze to imho nevedia spravit bez toho aby polku kodu prekladaca zahodili a napisali nanovo).

VCC je nastroj dobry na male, relativne dobre popisane kusy kodu, ktore funguju deterministicky. O nastrojoch na formalnu verifikaciu konkurentneho kodu nemam nejaky velmi silny prehlad ale vzhladom k tomu, ze na ziskanie urovne A1 je potrebne mat overenie korektnosti kodu na urovni matematickeho dokazu a este v case ked som koncil na vysokej skole tymto testom preslo jadro nejakeho RTOS na to zrejme nejake nastroje uz existuju. VCC moze byt unikatny v tom, ze sa nepozvracia, ked uvidi ten hnoj, ktorym je VC krmene. Na realne aplikacie, ktore ale pracuju v nekontrolovanom prostredi a nebodaj interaguju s pouzivatelom, kde uroven determinizmu limitne klesa k nule, alebo pocet deterministickych stavov k nekonecnu, je to nepouzitelne.

Rozumnejsi mi v tomto pride staticky analyzer postaveny okolo LLVM, ten ma ale ten "problem", ze LLVM ma k ISO standardu dost fasisticky pristup a odmietne prelozit akekolvek aj potencialne nevinne odpadky v zdrojakoch. To sa potom moze clovek dostat do stadia, ze aby vedel staticky analyzer nakrmit kodom, ho musi tak 3-4 mesiace postandardnovat a ked ma smolu, tak vysledok svojho usilia zasa neprelozi vo VS12. Ten ale zrejme nebude vediet analyzovat konkurentny pristup ku zdrojom (to sa IMHO ale v realnych desktopovych aplikaciach ani rozumne neda).

+ statickeho analyzera je ale v tom, ze odhali kopec detskych chyb, ktore su v kode nechane na to, aby sa prejavili. Pretoze bezna Win komercna aplikacia je proste dost dobra v kazdom pripade, ked cca robi to, co ma a nepada prilis casto (ak pada dost casto, tak sa do nej proste vstava nastroj na reportovanie chyb namiesto toho aby sa opravila, ak pada este viac, uz sa to riesi).

Chess vyzera byt zaujimavy ako hracicka, ale do realneho prostredia nenasaditelny (chodte presviedcat manazera, ze pouzijete na analyzu kodu nejaky nastroj, ktory nema ziaden release). Zo zvedavosti som si teda podla postupu v dokumentacii stiahol zdrojaky a pokusil sa to zbuildit. Vysledok je ten, ze to nenaslo nieco neviem co. Takze okrem toho, ze ten nastroj nemal ziaden release, je PITA ho asi aj len zbuildovat, tak by som sa ani nedivil, keby fungoval len na 32bitove aplikacie (ako cosi v dokumentacii naznacuje). = je to pekny research projekt, ktorych su tony, ale v realnom zivote je to totalne nepouzitelne. Navyse to vyzera tak, ze sa to uz nejakych 7 rokov ani nevyvija. Aby to clovek skompiloval, potrebuje bud pevne nervy pri konverzii projektov (pretoze stavim 20 euro na to, ze to bez problemov v ziadnom novsom VS loadnut nepojde), alebo vytiahnut 7 rokov stare IDE so 7 rokov zabugovanym prekladacom.

Tvrdit na zaklade tohto, ze vyvojove nastroje microsoftu su najlepsie na svete (alebo ako to bolo?) je dost... no kratkozrake.

Velkost v SLOC nie je podstatna, bavime sa o tom, ako velmi vela roznych kombinacii stavov moze vzniknut. Neocakavam, ze by to event driven hell komunikujuce s pouzivatelom bolo mozne tymto nastrojom podchytit a vymacknut z neho nejaky realny vystup, pretoze aplikacia sama je nedeterministicka.

Hm, mna google poslal na codeplex repozitar, kde nie je nic okrem suroveho downloadu niecoho, co neslo zbuildovat. Tym nasadit do produkcie bolo myslene zavisiet na tom vo vysledku, nie si to len tak pokusne pustit a pozret sa, co z toho mozno vypadne.

Ja sa nehadam o tom, ci nejaka firma nejake nastroje ma, to mi je celkom u prdele. Popravde zo zhora uvedenych dovodov je mi nejaky lock checker u prdele aj keby existoval a fungoval, CHESS by zasa zaujimavy byt mohol a niekedy ho mozno vyskusam. Ide mi o to, ze ak sa nemozem spolahnut na debugger a prekladac, tak to nastroj overujuci nejaku izolovanu triedu chyb na nejakom relativne specifickom type SW nezachrani.

s chybou RAM som sa uz stretol tiez, ta ale bola vzdy do istej miery deterministicka - napriklad pokus o kompletny rebuild Release skoncil modrou smrtou systemu. na mojom konkretnom pocitaci k nedeterministickym zlyhaniam prekladaca dochadza nahodne tiez a pritom za cele 3 roky, co ho prevadzkujem nehodil v produkcii jediny Blue Screen a mimo produkcie hodil jediny pocas updatu nvidia drivera (co bol dobre znamy pripad).

Toolchain postaveny okolo MSVC ma dobre znamu a pomerne casto dokumentovanu vlastnost a to tu, ze ak sa v jednom builde stretne paralelne buildovanie viacerych projektov (ktore je by default zapnute) s paralelnym buildovanim viacerych objektov v ramci projektu (ktore je asi defaultne vypnute, ale kazdy aspon trocha sane projekt to ma zapnute, inac by sa developeri vysledku nedozili) s diferencnym buildom, vysledok moze byt (a bude) sem-tam nedeterministicky nefunkcny (it is notorically known to fail). ludia pouzivajuci VC to proste beru ako fakt a nikomu to nevadi. je to nutne zlo potrebne prezit, aby bol buildovaci cas aspon vzdialene akceptovatelny. Akasi obet diablovi za to, ze je mozne veci dokoncit. AFAIK ak sa bud diferencny build alebo paralelne buildovanie objektov v ramci projektu vypne proces je relativne spolahlivy, ale este pomalsi ako normalne.

Pri nedeterministickych runtime zlyhaniach nehovorim o veciach, ktore je mozne identifikovat a opravit, ale o obtiazne a/alebo vobec reprodukovatelnych chybach, ktore su izolovane v priestore a case a maju absurdne riesenie. Tuto minule som zabil 2 dni a zburcoval vychodne pobrezie USA hladanim problemu, ktory skoncil stack tracom niekde v standardnej kniznici (odpoved code ownera na stack trace bola WTF? This isn't our code). V ramci zufalosti som po pol dni pristupil k taktike nuklearneho holokaustu a z relevantnych veci ostali nedotknute len Windows a Visual Studio. Cerstvo boli stiahnute zdrojaky, prebuildovane a nanovo bolo stiahnute cele SDK. Na moje prekvapenie to nepomohlo. Potom som bez zmeny jedneho riadka, stahovania cohokolvek alebo rebuildu prosto rebootol masinu, ktora mala menej ako 4 dni uptime a problem sa zazracne vyriesil. Warm boot mam vypnuty, shutdown je u mna shutdown, nie suspend to disk. Pocas behu stroja sa cosi kdesi akosi pototo. Vzhladom k tomu, ze ta ista binarka pred rebootom nefungovala a po reboote ano, pripisujem toto nejakemu nedeterministickemu heisenbugu priamo vo Windowse / dynamickom linkeri / standardnej alebo nestandardnej kniznici ktora je s nasou aplikaciou linkovana. Tato zostala vyhnita v niecom, co sa medzi procesmi nezahadzuje a v tomto konkretnom pripade zinteragovala tak, ze to nedeterministicky zlyhalo. Bohuzial to nie je ojedinely pripad, ale stava sa to neprijemne casto. (Nedeterministicke zlyhanie prekladu este castejsie)

Debugger spustame 64bitovy, nasa aplikacia sa ako 32bitova ani nebuilduje. Dost pravdepodobne by sa v 32bitovom adresnom priestore nedokazala ani spustit. Nepouzitelnost debuggera na sebevacsie projekty tkvie v tom ze projekt, ktory ma ± 2 GB zdrojovych kodov, 50GB SDK a radovo 60GB velky build vyzerie 32bitovemu visual studiu vsetku volnu ram v momente pokusu o nacitanie PDB pre viac ako jeden projekt (ktorych je v solutione 200+). VS12 nam s tym padalo ako hnile hrusky (a ani MCE s ktorymi sme komunikovali si nejako nevsimli, ze im to zomrelo na OOM; az ked si dotycny chudak vsimol, ze vsetky coredumpy, ktore posiela maju presne 3GB a vygoogloval si ze VS je 32bitova app, doslo mu kde je arasid zakopany), VS15 uz ma toto "osetrene" tym, ze ak runtime zisti, ze sa blizi k limitu pamate, degraduje analyzu na nacitanie symbolov. To ma nuti mat kompletne vypnute vsetky nastroje vratane Intellisense, takze je pre mna VS len taky inteligentnejsi notepad s browserom build stromu, zalozkami, rychlym fulltextom a konzolou prekladaca + debuggera. Viem, ze debuggovacia infrastruktura vo Windowse je schopna kde-coho, problem je v tom, ze vo VS je z toho rozumny pristup len k malej casti, pripadne je to okriplene 3,5GB limitom na pamat a WinDbg (?) je uz takmer seda zona. V taky cas 9 z 10tich programatorov proste siahne po meritu tvrdenia "Successful debugging is just a matter of properly placed printfs", pretoze nemaju cas riesit co kde ako preco. Bohuzial pure konzolovy interface k debuggeru, ktory by obisiel nedostatky nadstavieb som nikde nenasiel aj keby som ho privital. Ktosi mi kedysi povedal, ze microsoftny debugger je zhnity trabant s nadupanym motorom V8 pod kapotou. Druhou castou si nie som isty a mozno je to pravda, ale s tou prvou bezvyhradne suhlasim.

Nad to, neviem ci je to sposobene nedostatkom pamate, nahodnym nedeterministkym zlyhanim, alebo cim inym, ale z casu na cas sa stane, ze debugger proste odmietne browsovat vnutornosti nejakeho symbolu. Je jedno, ci sa jedna o local, watch, argument. Nie je to deterministicke vzhladom na typ objektu, polohu, sposob vytvorenia. Samozrejme sa bavime o Debug builde bez optimalizacii, v Release builde je to ocakavatelne chovanie. Niekedy proste niektory konkretny symbol v niektorom konkretnom bode debuggingu nie je dostupny a nie je s tym mozne spravit nic ine ako cele VS zhodit a nabehnut znova (co je celkom super operacia, ak trvalo pol hodinu dostat sa do inkriminovaneho bodu pre nemoznost nastavit breakpoint priamo).

Fuchsia ma byt, podle vseho, zamerena na IoT a ne byt nahradou Androidu nebo ChromeOS. Cimz pada cela ta tva myslenkova konstrukce jak domek z karet.

Ne, MS zavrhnul Xenix ve prospěch DOSu a nebylo to, jak jste vtipně poznamenal proto, že by Xenix byl komerčně neúspěšný. Ono prostě DOS pro IBM byla ještě lepší partie. Windows NT vývoj započal až tehdy, když zjistili, že tím DOSem větší hráče v oblasti serverů prostě neuspokojí a že (můj dojem) upgradovat Xenix na již novější hardware by byl taky docela oříšek. Navíc licence AT&T byla stále dražší a dražší. Proto Windows NT.

To je jistě pravda, ale abychom byli fér, je nutné podotknout, že notorická nestabilita windows 9x byla způsobená především zpětnou kompatibilitou s 16ti bitovými aplikacemi a ovladači, které běžely bez memory protection a v kooperativním režimu. Takový přechod asi bezbolestně provést opravdu nejde, u Apple se o to pokoušeli celá léta s nechvalně známým projektem Copland, než to vzdali a místo toho koupili NeXT. U Atari byla podobná snaha jménem MultiTOS a ani to nebyla zrovna úspěšná implementace.