Hlavní navigace

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

Sdílet

Roman Bořánek 21. 10. 2016

Ve vývojové verzi Windows 10 s číslem 14951, která je k dispozici v rámci insider preview, byl aktualizován Windows Subsystem for Linux. To je věc, která umožňuje spouštět ve Windows bash a další linuxové programy. Aktuálně se používá balíčková základna Ubuntu 16.04 LTS. V novém sestavení byla přidána nejžádanější vlastnost – mnohem lepší interoperabilita Linuxu a Windows.

Jde o možnost kombinovat binárky pro NT a Linux ze stejného shellu. Například můžete použít bash.exe pro navigaci v souborovém systému a spustit grafický editor pro NT z aktuálního adresáře. Dalším aspektem je možnost binárek pro NT a Linux přesměrovávat svůj vstup a výstup. Například můžete vyfiltrovat výstup z příkazu ve Windows pomocí linuxového příkazu grep, píše se na vývojovém blogu.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 21. 10. 2016 14:51

    Štefan (neregistrovaný) 159.50.252.---

    Hmm.. historie se opakuje.. kdysi stálo OpenVMS na počátku Win NT, dnes to vypadá na Win 10 + Linux konvergenci do nového OS.. Titanic se chytl stébla a s Heyerdahlem vyrazil za světlými zítřky

  • 21. 10. 2016 15:23

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Jistě, historie se opakuje. Windows NT měly od první verze POSIX subsystém, později známý jako Subsystem for UNIX, který se moc nepoužíval. Dneska mají místo toho Subsystem for Linux, protože klasické Unixy začínají být ohroženým druhem. Sice nikde nevidím Titanic, stéblo a Heyerdahla, ale to je technický detail :)

  • 21. 10. 2016 18:57

    NULL (neregistrovaný) ---.freepoint.cz

    Vitaj Leal, pokud nevidíš Titanic, já ti ho ukážu. Je to támhle dole, tam, jak bylo potřeba nasadit Linux subsystem, protože už to ve vývoji pomalu jinak nejde a klasická ignorace už se začínala i nevyplácet, obzvláště při pomyšlení na nástup IoT, kde embed Win udělal přimo díru do světa :-D
    Já jim to nezazlívám, aspoň že už se poučili. Ale pořád se na Wiin 10 a u MS celkem najde dost debilit. Třeba naposledy Skype :-D : Nabídne mi převyplněné přihlašovací jméno - OK, ale nemám kde zadat heslo a tak s tím, že vím, že budu zadávat heslo musím potvrdit a počkat, až mi nabídne input na heslo a pak to potvrdit znova - geniální - a takového jsou MS a jeho nástroje plné. Netvrdím, že neobsahují dobré funkce a nebo i unikátní, ale takových <> je ten jejich Win ekosystém plný a pak přijdeš z Lin. a první hledíš, pak se směješ, pak nadáváš a pak, až někdo napíše něco o Titanicu a PS-promo netuší proč, tak ti to nedá . . . :-D

    "Dneska mají místo toho Subsystem for Linux, protože klasické Unixy začínají být ohroženým druhem"

    U toho bych se pozastavil. Takže proto, že linux umírá, tak se najednou po 20 letech obezliček může MS přetrhnout, aby se aspoň přiblížil kompatibilitě? No nevím . . .

  • 21. 10. 2016 19:51

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Ad Titanic... Je to támhle dole, tam, jak bylo potřeba nasadit Linux subsystem - to máte na mysli libc? Jo, to je fakt věc na které budoucnost Windows stojí a padá :)

    Ad už to ve vývoji pomalu jinak nejde... obzvláště při pomyšlení na nástup IoT - jak podle vás souvisí podpora linuxových binárek na Windows desktopu s IoT? Mimochodem celý Internet-of-Trash založený převážně na Linuxu bude ještě velký bolehlav.
    https://www.root.cz/clanky/postrehy-z-bezpecnosti-lehce-napadnutelne-iot-zarizeni/

    Ad takových <> je ten jejich Win ekosystém plný a pak přijdeš z Lin. a první hledíš, pak se směješ, pak nadáváš - ovšem podobně uživatel Windows kritizuje nesmysly na Macu, nemluvě o Linuxu. Nebo myslíte že když se já začnu zajímat kde najdou dokumentaci platformy, a na Linuxu je odpovědí "všude různě po netu, a mimochodem záleží co si představujete pod slovem platforma, protože žádná standardní nebo zaručená sada funkcí neexistuje", tak mě to nepřipadá ujeté? Nebo že když se zeptám "jaké API mám zavolat abych zjistil jestli můj daemon běží, a případně ho spustil, a jaké API mám zavolat abych přidal uživatele nebo změnil IP adresu síťového interface", a odpověď je ve všech zmíněných případech "takové API vůbec nemáme", tak začnu skákat radostí? Práce na Linuxu se v podstatě skládá z WTF momentů. Jediný rozdíl mezi námi je v tom, že vám řada věcí přijde jako standard a ne WTF moment.

    Mimochodem "kvality" Linuxu jsou tak skvělé, že například Google u Androidu tvrdě opatchoval kernel, a nahradil všechno včetně libc, driverů a grafického stacku. A teď to vypadá, že Google pošle Linux do kytek úplně, protože staví OS určený pro desktop i embedded nasazení, kompatibilní s Androidem. Asi v Googlu už přišli na to, že mít ChromeOS na "desktop", Android na telefony a tablety a Linux na servery, s tím že překryv API je prakticky nulový, není úplně ideální situace.
    http://www.tomshardware.com/news/google-fuchsia-new-operating-system,32475.html

  • 21. 10. 2016 21:47

    kaliszad

    Laeli Ophire, mám k Vám docela respekt pro Vaše poměrně detailní znalosti Windows. Nemá cenu se hádat, kde je Windows lepší a kde zase GNU/ Linux resp. FreeBSD apod. Ono opravdu zajímavé technologie spíše vznikají na *BSD a právě i původně Solaris/ OpenSolaris a nyní Illumos třeba distribuce SmartOS, dokonce i takový Minix jsou torpédoborce v oblasti vývoje operačních systémů. Nejpoužitelnější na běžném spotřebitelském hardware je ale celkem jistě Windows, GNU/ Linux, dnes i FreeBSD apod. ale potom to jde strmě do hlubin.
    Je celkem zřejmé, že GNU/ Linux potřebuje jistou standardizaci hlavně ve vyšších vrstvách. Proto existuje LSB: https://wiki.linuxfoundation.org/lsb/start
    Jinak Linux API je ale natolik stabilní, že je to takový skoro-standard a jiní, např. Illumos, FreeBSD, Windows toto API implementují více či méně. Nemusí být skvělé, ale funguje to a je to dostatečně dobré na to, aby člověk nemusel každý den práce s takovým systémem proklínat.

    Windows jako operační systém je bohužel stále ještě příliš tlustý a zdá se, že hodně konceptů kolegové z Microsoftu prostě nepochopili. Hlavně co se týče různých obskurních chyb při úplně běžných úkonech, třeba hledání updatů, které skutečně může podle mých zkušeností i z minulého týdne klidně zabrat více jak 24 hodin bez úspěchu. Stejně různé volby, kdy ani admin není dostatečně admin, aby je mohl změnit apod.
    Něco jako připravení vlastního obrazu pro instalaci nebo integraci nějakého souboru do instalačky je poměrně problematický úkol nehledě na to, že ty instalačky musí nyní člověk stahovat buď přes torrent (http://mirror.corenoc.de/digitalrivercontent.net/) a nebo nějak přes web Microsoftu, který v některých případech jede jen s IE6 a AktiveX doplňkem, protože normální stránka je asi moc složitá (http://www.catalog.update.microsoft.com/Home.aspx). Přitom sám Microsoft IE6 několikrát oficiálně pohřbil. Dobře, je to složitější, ale princip je asi zřejmý. Proč tak složité mít jeden portál, přes který můžu distribuovat vše? Trial verze, plné verze, produkty pro firmy nebo studenty?
    To je prostě v open source světě jednodušší, tam obyčejně stačí jít na mirror nejbližší univerzity nebo je přímo link na stránce softwaru, který mě odkáže na nejvhodnější místo ke stažení.

    Android a další věci od Google jsou dobré i špatné zároveň. Uživatel je stavěn do role nesvéprávného a nemá přístup např. k root shellu na svém telefonu přes nějaký jenoduchý přepínač, přestože mu telefon patří a pokud připojím nějakou přenosnou BT klávesnici, tak bych mohl na cestě řešit i něco složitějšího. Pohodlné to není, ale takhle musím telefon rootnout...

    Moderní firmy si asi myslí, že uživatel idiot. Ano, často je to pravda, často je to tím, že firmy nejsou schopné něco udělat přímočaře (třeba ten jednotný portál pro stažení softwaru) a potom máte operační systém, kde je jeden dialog jak z 80. úplně mimo mísu v době dotykové a hned vedle ikony jak kráva protože jsme v době dotykové, ale na uživatele s myší nebo klávesnicí málokdo myslel. Asi je to nějaká doba hledání sama sebe či co...

    Že Google dělá spoustu práce "aby to nějak bylo", to je další téma na dlouhé rozčilování. V podstatě je to tím, že nejsou schopni zaujmout dostatek vývojářů a motivovat je natolik, aby dostali patche do mainline kernelu. Proto si hrají na svém písečku a potom máte telefony, které se realisticky nedají po výrobě podporovat, protože vrstva náplastí je tak silná, že ani skalpel zkušeného vývojáře nemůže efektivně vyoperovat zranitelnosti. Samozřejmě, nejen Google je na tom vinen, hlavně jde o to, že výrobci hardwaru často nepochopili, že podpora HW v softwaru je to, co jejich produkty prodá. Ne až tak to, že mají 100 MHz víc než konkurence.

  • 22. 10. 2016 1:27

    nobody (neregistrovaný) ---.pel.cz

    to je nejaky project krouzku programovanni prvniho stupne zakladni skoly?
    kde je nejakej catalog kdyz ma jit o catalog? nelze nic prochazet bez vyhledavani, nelze vyhledavat podle kriterii, ale dobre, kdyz se da hledat "po dokončení instalace bude pravděpodobně třeba restartovat počítač." tak je vysledku vice nez 1000 coz je maximum co to dokaze zobrazit... a pak at Lael tvrdi ze restartovat nechce skoro zadna :-D

  • 22. 10. 2016 13:18

    bez přezdívky

    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.

  • 23. 10. 2016 4:26

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Ad mám k Vám docela respekt pro Vaše poměrně detailní znalosti Windows - to mě těší. I za mě jsou znalosti a schopnosti hodné respektu, bez ohledu na to jestli s dotyčným souhlasím nebo ne.

    Ad Je celkem zřejmé, že GNU/ Linux potřebuje jistou standardizaci hlavně ve vyšších vrstvách. Proto existuje LSB - souhlas s potřebou standardizace Linuxu. Všimněte si, že když se MS drží standardu částečně, tak zdejší diskutéři "hlasitě" píší o mršení a/nebo ignorování standardů. LSB je ISO standard, který prakticky všechny distra ignorují. Před časem jsem to popsal takhle:
    Příkladem může být Linux Standard Base, kde má certifikaci na verzi 4.1 z roku 2011 má z rozšířených dister leda RHEL, a LSB verze 5 (na kterou má certifikaci jen jakýsi EulerOS) "pro jistotu" rozbíjí zpětnou kompatibilitu. Svět open source nepotřebuje žádnou konspiraci Microsoftu, žido-zednářů, včelařů a cyklistů. Různé skupiny tvořící svět open source se totiž chovají jako malé děti, které se na pískovišti domlátí po hlavách hrabičkami.
    https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb

    Ad Linux API je ale natolik stabilní, že je to takový skoro-standard - souhlas že se situace změnila. Místo toho aby se řešilo jestli je Linux kompatibilní s klasickými Unixy, tak se to řeší opačně.

    Ad API... nemusí být skvělé, ale funguje to a je to dostatečně dobré - pokud jde o glibc, tak jde o API koncepčně někdy ze sedmdesátých let, s minimálním rozvojem a poněkud strohou dokumentací. Ostatní API jsou volitelná, od těch prakticky nepoužitelných (X11) až po celkem pěkná (Qt), s různými úrovněmi funkcionality a dokumentace. Spousta funkcionality chybí, a považuji za absurdní, že například port Adobe Flashe (uvažte: plugin do browseru!) trval léta kvůli problémům s multimédii, a autoři mimo jiné museli upravovat kompilátor. Podobně absurdní je třeba to, že na Linuxu je cca dvacet let vytrvalým problémem tearing videa.

    Windows jako operační systém je bohužel stále ještě příliš tlustý - s Windows IoT, Windows Mobile, desktopovými a serverovými Windows mi přijde, že pokrývá co pokrývat má.
    Ad hledání updatů, které skutečně může podle mých zkušeností i z minulého týdne klidně zabrat více jak 24 hodin bez úspěchu - vím že to občas uživatelé hlásí, i když u mě se to nestává. Pokud jde o Win7, tak tam existuje patch na pomalé hledání patchů s vysokým využitím CPU.
    Ad připravení vlastního obrazu pro instalaci nebo integraci nějakého souboru do instalačky je poměrně problematický úkol - existuje kompletní dokumentace, je dostupná online
    Ad instalačky musí nyní člověk stahovat... - triviálně z webu MS: https://www.microsoft.com/software-download/
    Ad Catalog - ten je na ruční stahování updates, a jak už někdo psal, nově nevyžaduje ActiveX. Navíc ani i ta verze s ActiveX fungovala v MSIE na Win10, nevyžadovala MSIE 6.
    Ad To je prostě v open source světě jednodušší, tam obyčejně stačí jít na mirror nejbližší univerzity nebo je přímo link na stránce softwaru, který mě odkáže na nejvhodnější místo ke stažení - souhlas, protože ve světě open source není potřeba řešit licencování. Jenže ten SW má takové kvality, že ho uživatelé nějak nepoužívají, ani když je zdarma a snadno ke stažení. A nepoužívali ho ani když padaly CD a DVD s Linuxem z časopisů, o Linuxu se psalo snad i v časopisech pro ženy, a v IBM sprejovali na chodníky Love, Peace, Linux.

    Ad Android a další věci od Google jsou dobré i špatné zároveň. Uživatel je stavěn do role nesvéprávného - to je o cílové skupině, plus o zájmech výrobce. Cílovou skupinou pro smartphony jsou všichni od dětí, před farmáře, instalatéry, programátory a managery až po důchodce. Naprostá většina těch lidí chce smartphone používat stejně snadno, jako hloupý telefon, akorát na něm chce dělat daleko víc věcí než na tom hloupém telefonu. Tam kde vy čekáte otevřenost, API, dokumentaci, admin nástroje atd., tak cílová skupina očekává, že to celé bude prostě fungovat a nebude se nutné o nic starat. Apple ukázal, že přesně tohle lidé chtějí. Android to jen kopíruje.

    Ad hrají na svém písečku a potom máte telefony, které se realisticky nedají po výrobě podporovat, protože vrstva náplastí je tak silná, že ani skalpel zkušeného vývojáře nemůže efektivně vyoperovat zranitelnosti; výrobci hardwaru často nepochopili, že podpora HW v softwaru je to, co jejich produkty prodá - uživatele bezpečnost moc nezajímá, protože ji nerozumí a není vidět. Pokud už si o věci něco přečtou v novinách (čtěte: na zpravodajském webu, noviny už skoro nikdo nečte), tak si řeknou, že když je někdo bude chtít hacknout, tak s tím jako laici stejně nic neudělají. Kupodivu ani vypnutí služeb MMS kvůli Stagefright bugu lidi neprobudilo. Zřejmě se situace musí ještě o hodně zhoršit, než to začne docházet i laickému zákazníkovi.
    Telefony se dají po výrobě podporovat, ale zvolený vývojový/distri­buční model k tomu nemotivuje. Čínský výrobce objedná kasle a desky, a nechá na výsledné telefony nasadit Android, protože zdrojáky dostane zdarma. Jako "bonus" dodá nějaký nepoužitelný launcher, který napsal nejspíš nějaký student za týden. Produkt zabalí do krabice, ty krabice dostane zaplacené a předá je přepravě. Na tom zrealizuje zisk, a nic ho nenutí se starat o podporu. Google ho k tomu nenutí, protože si takový model vybral. Zákazník také ne, z důvodů které jsem popsal. Pak jsou tu i nějaké technické důvody, jak jste zmiňoval: radio layer a spousta driverů nejsou součástí Androidu, a musí to lepit třetí strany.

  • 23. 10. 2016 19:16

    ventYl

    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.

  • 23. 10. 2016 19:57

    Radek Miček (neregistrovaný) ---.net.upcbroadband.cz

    > 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.

    MS má jedny z nejlepších nástrojů pro vývoj a hledání chyb, bohužel řada z nich je buď málo známá nebo nejsou volně dostupné (někdy jsou dostupné pouze v rámci MS).

    Důvodem je, že Microsoft Research investuje velké prostředky do technologií pro vývoj SW.

  • 23. 10. 2016 20:45

    ventYl

    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.

  • 23. 10. 2016 21:08

    Radek Miček (neregistrovaný) ---.net.upcbroadband.cz

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

    To si myslí i tým za VC++ https://blogs.msdn.microsoft.com/vcblog/2015/09/25/rejuvenating-the-microsoft-cc-compiler/

    > pretoze siroko daleko najlepsie, co sme napr. na hladanie memleakov nasli bol Visual Leak Detektor

    Bohužel také neznám dobrou alternativu k Valgrindu na Windows.

  • 24. 10. 2016 10:58

    ventYl

    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?

  • 23. 10. 2016 21:31

    Martin Dráb (neregistrovaný) ---.net.upcbroadband.cz

    Detekci memory leaků jsem v MSVS nějakou dobu používal, ale nakonec jsem přešel k vlastnímu řešení (přesměrovní alokačních a dealokačních funkcí). Hlavně asi proto, že pro vyvíjení ovladačů mi to přišlo jako nejjednodušší řešení. Valgrind neznám, ale pochybuji, že by moje řešení bylo lepší (muselo by se na něm hodně zapracovat, ale vyšší sofistikovanost jsem nepotřeboval).

    Jaké nástroje od Sysinternals máte konkrétně na mysli? Je pravda, že třeba Process Monitor ne zrovna dobře funguje při logování bootu, ale jinak jsem moc problémy nezaznamenal.

    Ohledně nepoužitelnosti debuggeru: nepoužitelnost na větší projekty mi přijde spíše jako obecná vlastnost debuggeru, než že by za to vyloženě mohl debugger v MSVS.

    S "kvalitou" VC/C++ bych i souhlasil, měl jsem již také tu čest, dokonce dvakrát (obě věci jsou ji opraveny).

  • 24. 10. 2016 10:25

    ventYl

    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).

  • 23. 10. 2016 21:41

    Radek Miček (neregistrovaný) ---.net.upcbroadband.cz

    BTW, to vám asi nepomůže, ale měl jsem na mysli nástroje pro statickou analýzu kódu (např. uvnitř VS), formální verifikaci programů (např. VCC - https://www.microsoft.com/en-us/research/project/vcc-a-verifier-for-concurrent-c/), různé specializované ladící nástroje (např. CHESS - https://www.microsoft.com/en-us/research/project/chess-find-and-reproduce-heisenbugs-in-concurrent-programs/) nebo nástroje pro automatické generování testů (např. IntelliTest uvnitř VS - pouze pro .NET).

  • 24. 10. 2016 10:54

    ventYl

    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.

  • 24. 10. 2016 19:19

    Radek Miček (neregistrovaný) ---.net.upcbroadband.cz

    > VCC je nastroj dobry na male, relativne dobre popisane kusy kodu

    Právě, že VCC je dobré i na větší kusy kódu.

    > nastroje uz existuju

    K alternativám VCC - ano, existují, ale už jsou třeba mnohem dražší nebo zdarma, ale hůř použitelné a méně spolehlivé.

    > 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)

    Má release i instalační program - viz https://www.microsoft.com/en-us/download/details.aspx?id=52619

    Jinak CHESS se používá pro ladění - do produkce se nenasazuje.

    > ale v realnom zivote je to totalne nepouzitelne.

    Pro CLR je to použitelné dobře.

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

    To byl jen příklad. Ale zkuste najít jinou firmu, která má všechny vyjmenované nástroje.

  • 25. 10. 2016 10:43

    ventYl

    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.

  • 24. 10. 2016 13:33

    Karel (neregistrovaný) 93.90.162.---

    "T.j. ze sa nieco v MSVC (2015.2 btw) pri buildovani pokasle a vystupna binarka nejakym nedeterministickym sposobom"

    To jsme před pár lety také řešili. Když se pak zjistilo, že se to na některých počítačích nekazí, tak jsme pak už rychle došli na příčinu. Po výměně RAM to přestalo. MEMTEST nikdy nic podezřelého nehlásil, ale faktem je, že výměna RAM na build serveru problém vyřešila.

    "nedeterministicke runtime zlyhania." Na to existují debugovací nástroje. Velký SW bývá plný race conditions, nesprávné práci s pamětí atd. V bývalé firmě jsme měli dokonce skupinku lidí, co tohle cíleně vyhledávala. Měli dokonce hitparádu chyb. Myslím, že na prvním místě bylo volání swing metod mimo event dispatch thread. To shazovalo klienta poměrně spolehlivě. Na serveru tam na prvním místě také bylo něco s thready. A vše se to projevovalo tím, že vám to třebas po hodině najednou třikrát za sebou kleklo a pak to zase dva dny jelo. Takže držím palce, opravte si vaše programy. S miliardou řádků od tisíců autorů to bude trochu peklo, ale dá se.

    "Ciastocne je to ale dane aj tym, ze debugger ako taky je prakticky nepouzitelny na akykolvek sebevacsi projekt."

    Uf. Proč proboha? To zní spíš jako výmluva líného programátora, co něco dělat nebude, protože se mu nechce. Ale hájit to bude tím, že to nemá smysl. Případně ještě může jít o programátora, který neví co to je. Občas se stane, že si pod pojmem "debugger" člověk představí to interaktivní prostředí, kde jen mačká "další, další". Ale to tak není. Dnešní debuggery běží paralelně s programem a umožňují vám monitorovat co se děje, volání funkcí, alokaci paměti. Přičemž vás umí upozorňovat na věci, které váš program skrývá (výjimky, čtení z paměti, kam nebylo zapsáno) atd. Fakt, že můžete program kdykoliv zastavit a podívat se komplet na stav dat, je jen třešiňka na dortu. Spíše se hodí ho zastavit a podívat se, jaká vlastně běží vlákna, jaké jsou tam zámky apod. Debugger je při ladění větších programů prostě k nezaplacení. Viz odstavec výše o "nedeterministicke runtime zlyhania."

    "co na tom, ze stroj ma 32GB RAM a 26 je pocas debuggovacej session volne" - aha, možná zde je zakopaný pes. Otázka je, proč nespustíte 64bitový debugger? Je to pohodlnost, nechcete, nebo jen nevíte, že ho Visual Studio má?

  • 24. 10. 2016 14:31

    ventYl

    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).

  • 24. 10. 2016 20:26

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Ad 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 - pokud píšete, že chyba RAM musí "deterministicky" způsobit BSOD, tak je to doufám pokus o vtip. Pro ilustraci se koukněte na row hammer. Pokud do RAM zapisujete "správné" vzory, můžete "propsat" hodnotu nebo její část do přilehlých buněk, což je způsobené probémem s izolací buněk (resp. typicky řádků). Může se to stát cíleně, ale také blbou náhodou. Potom můžete pozorovat pěkný efekt: při "míchání dat" se vám nedeterministicky poškodí obsah paměti, ale pokud v ní máte relativně statický obsah (executable), tak se problém neprojeví. Podobné problémy (disturbance errors) můžete v některých případech pozorovat, i když je paměťový modul poškozený.
    https://en.wikipedia.org/wiki/Row_hammer

    Ad 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 - LOL. Chcete ukázku kódu, který nefunguje po nějaké době běhu OS?

    if (GetTickCount()>8640000­0) DoCrash();

    Nebo:

    HANDLE hFile;
    hFile = CreateFile(argv[1], GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NOR­MAL | FILE_FLAG_OVER­LAPPED, NULL);
    if ((DWORD64)hFile % 1024 == 0) DoCrash();

    Variací na tohle téma jistě vymyslíte spoustu, a pokud máte dost velký projekt, tak se v něm může snadno vyskytnout problém z podobné kategorie. Mimochodem po rebootu se vám nejspíš naskládají executables i data do paměti trochu jinak, a pokud máte problém s RAM, tak se věci mohou chovat jinak. Jinými slovy to co popisujete může mít řadu různých důvodů, a připisovat to automaticky chybě OS je nesmysl.

    Ad hladanim problemu, ktory skoncil stack tracom niekde v standardnej kniznici - předpokládám že víte, že pokud předáte knihovně například invalid pointer, tak aplikace spadne v knihovně, ale problém je u vás.

  • 26. 10. 2016 12:11

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Tohle by vás mohlo zajímat. Diskuse o chybách paměti, s velmi zajímavými čísly. Ve zkratce: k chybám paměti dochází daleko častěji, než byste si myslel. A pokud nemáte ECC paměti, tak to může vypadat přesně jako to popisujete.

  • 24. 10. 2016 19:19

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Většinu věcí už komentovali ostatní, takže jen krátce:

    Ad niekolko miliard riadkov velkom codebase - Windows 7 mají 40M SLOC, Office 2013 45M. Celkem by mě zajímalo, jaký projekt má SLOC miliardách. BTW psát takový projekt v C/C++ mi připadá jako dost velké šílenství. Z hlediska chybovosti i produktivity je velmi dobrý nápad psát minimálně high level věci v C# nebo Javě.

    Ad pri buildovani pokasle a vystupna binarka nejakym nedeterministickym sposobom... - to může mít řadu příčin. Někdo už zmiňoval RAM, což je dobrý tip. Ale může za tím být i disk nebo jiný HW, případně custom build tools.

    Ad nedeterministicke runtime zlyhania - závislost na user inputu, čase, náhodných hodnotách, externích datech, race conditions, a technicky vzato lze vyrobit závislost na konkrétním buildu (třeba na timestampu binárky). Problém HW. Že se to špatně hledá? A proč myslíte že vymysleli C# a Javu?

    Ad Toto API je ale opat aspon deterministicke - dáte nějaký příklad nedeterministického Windows API?

    Ad Nezamienajte nedostatok vlastnosti s nekvalitou kodu - v tomhle obecně vzato souhlas. Ovšem nezaměňujte kvalitu produktu s kvalitou kódu.

    Ad MSVC co sa tyka kvality prekladu odpad. Stale je v nom mozne skompilovat trivialne nednoduche kusy kodu, ktore vedu k nekorektne chovajucim sa programom - bezvadný C/C++ compiler podle všeho neexistuje.

    Ad debugger... nedostatok pamate - použijte 64-bit debugger. Mimochodem vždycky můžete použít vim a windbg.exe. Dostanete tak veškerý komfort, který mají unixoví vývojáři :)

    Ad Ak su API vyssej urovne rovnako deterministicke ako API urovne najnizsej - prosím nějaké konkrétní příklady neterministických API

    Ad W10 SP1 rozbija Lync 2010 - to má dokazovat co? Lync 2010 není podporovaný na Windows 10. Jestli vám přestane fungovat po změně nějaké knihovny, tak do nedokazuje vůbec nic o API. To byste ale jako programátor mohl vědět.
    Ad Da sa to "opravit" ale je to Windows 95 style hack skopci tento subor z tamtoho neupgradovaneho systemu tamto a pojde to - pokud jde o bug v nepodporovaném Lync 2010, tak je to celkem pochopitelný workaround.

  • 22. 10. 2016 15:08

    tm (neregistrovaný) ---.adsl.slovanet.sk

    Re fuchsia - RT-mikrojadro asi nikto na desktop a tablet nasadzovať nebude, aj keď uvidíme, po svete behá veľa bláznov :) Skôr by ste sa mali pýtať, ak je ten windows taký dokonalý, prečo google namiesto vývoja fuchsie nepoužil windows?

  • 22. 10. 2016 15:47

    NULL (neregistrovaný) ---.freepoint.cz

    Na to, proč nepoužili Windows se soudný člověk ptát nemusí :-D a Laelovi to stejně nedojde . . .

  • 23. 10. 2016 3:46

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Ad fuchsia RT-mikrojadro asi nikto na desktop a tablet nasadzovať nebude - proč ne? Google chce spojit ChromeOS a Android. V projektu je už vidět kompatibilita s Androidem. Mě to připadá jako zjevná cesta. I když zatraceně obtížná, protože MS na desktopu ještě nikdo nebyl schopný úspěšně konkurovat.

    Ad ak je ten windows taký dokonalý, prečo google namiesto vývoja fuchsie nepoužil windows - Google chce mít platformu pod kontrolou. Na Windows záleží na MS, jestli nastaví jako default vyhledávač Google, Bing, nebo cokoliv jiného. Podobně na Windows dodává MS svůj Store, a z prodaných aplikací má provizi on a ne Google. BTW podobně bych se mohl ptát já, proč došlo ke vzniku VMS, DOSu, AmigaOS, MacOS, Windows, Windows NT a řady dalších operačních systémů, když je podle vás Unix tak dokonalý :). MS dokonce měl nejrozšířenější Unix na x86 platformě, a zavrhnul ho ve prospěch Windows NT. Proč asi?

  • 23. 10. 2016 11:01

    Ondra Satai Nekola

    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.

  • 23. 10. 2016 14:34

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Ad Fuchsia ma byt, podle vseho, zamerena na IoT - podle čeho "všeho"? Z dokumentace:
    Magenta targets modern phones and modern personal computers with fast processors, non-trivial amounts of ram with arbitrary peripherals doing open ended computation. To je podle vás IoT?
    https://fuchsia.googlesource.com/magenta/+/HEAD/docs/mg_and_lk.md

  • 23. 10. 2016 11:31

    tm (neregistrovaný) ---.adsl.slovanet.sk

    Fuchsia - pretože komplexita moderných jadier nie je samoúčelná. Použiť jadro, ktoré toho vie málo, ale vysoko efektívne, má zmysel na jednoúčelovom zariadení, ale už menej na desktope/serveri, či na telefóne. Čoskoro začnete narážať na rôzne problémy, ktoré sú samozrejme riešiteľné, ale za chvíľu zístite, že máte jadro rovnako zložité, ako bolo to linuxové.

    Ad mať platformu pod kontrolou - súhlasím, že asi ide o primárny dôvod, ale pokiaľ si to myslíte aj vy, prečo fuchsiu o pár príspevkov vyššie uvádzate ako príklad toho, ako "linux nikto nechce"? ;)

  • 23. 10. 2016 14:41

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Jenže Fuchsia není (jen) LK mikrokernel, který nezná spoustu běžných konceptů. MacOS X je postavený na mikrokernelu Mach, který je z kategorie "jadro, ktoré toho vie málo, ale vysoko efektívne". Díky vyšší vrstvám je z něj ale systém, který běží na desktopech a telefonech. A jak už jsem linkoval výše, na stejnou kategorii zařízení podle všeho míří Fuchsia.
    https://www.root.cz/zpravicky/windows-subsystem-for-linux-prinasi-lepsi-propojeni-s-windows/893112/

  • 23. 10. 2016 14:45

    Radek Miček (neregistrovaný) ---.net.upcbroadband.cz

    > Použiť jadro, ktoré toho vie málo, ale vysoko efektívne, má zmysel na jednoúčelovom zariadení, ale už menej na desktope/serveri, či na telefóne.

    K tomu smyslu na serveru - viz unijádra https://en.wikipedia.org/wiki/Unikernel (jinak řečeno, řada lidí si myslí, že to určitý smysl má).

  • 23. 10. 2016 12:17

    kaliszad

    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.

  • 23. 10. 2016 16:10

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Gordon Letwin (OS/2 lead architect) to popisuje trochu jinak. MS licencoval kód od AT&T, protože společnost AT&T nesměla nabízet systém napřímo. Xenix byl tehdy nejrozšířenější UNIX. Nicméně MS ho odstřelil ve prospěch OS/2 (a později NT), když společnost AT&T po deregulaci mohla nabízet opět UNIX napřímo a vydala System V. MS chtěl do OS/2 zkombinovat úspěšný systém DOS s funkcionalitou kterou tehdy desktop nenabízel, což byl například multitasking a pokročilý memory management. A díky úspěchu Windows z toho nakonec po čase vyšly NT, kde byl nad kernelem subsystém pro Windows (Win32), DOS, UNIX (POSIX, Services for UNIX) a OS/2.
    https://groups.google.com/forum/?hl=en#!original/comp.os.ms-windows.misc/-iNeep60eVE/Xl5ddAtJENcJ

  • 23. 10. 2016 23:54

    nobody (neregistrovaný) ---.pel.cz

    Lael Ophir (neregistrovaný) ---.kmen.nat.pra­ha12.net Dnes 16:10
    MS chtěl [...] s funkcionalitou kterou tehdy desktop nenabízel, což byl například multitasking [...]

    co si to zas vymejslis za kraviny? Amiga Workbench nabizel preemtivni multitasking od roku 1985... NT v roce 1993 byl jednak pozdeji, druhak ho zvladal MNOHEM hure nez Amiga na MNOHEM slabsim HW...

  • 24. 10. 2016 19:20

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    Ovšem Amiga Workbench neměl memory protection, kterou měl i ten Xenix na 8086.

  • 25. 10. 2016 13:36

    nobody (neregistrovaný) ---.pel.cz

    @Lael Ophir (neregistrovaný) Ovšem Amiga Workbench neměl memory protection, kterou měl i ten Xenix na 8086.

    to sice nemela, ale presto crashovala mnohem mene nez Windows ktere prisli pozdeji a na mnohem vykonejsim hw meli mnohem horsi odezvy i multitasking ;)

  • 25. 10. 2016 18:22

    Lael Ophir (neregistrovaný) ---.kmen.nat.praha12.net

    S tou stabilitou asi máte asi pravdu, ale upřímně být stabilnější než "klasické" ne-NT Windows běžící na nejlevnějším HW nebylo až tak těžké, protože laťka byla nastavená poměrně nízko :)

    BTW proč se v češtině používá výraz nízko nastavená laťka? Nízko nastavená limbo stick znamená naopak vyšší obtížnost.
    https://upload.wikimedia.org/wikipedia/commons/e/e7/Folk_Music_%26_Limbo_Dance_C_IMG_2636.JPG

  • 26. 10. 2016 0:05

    klokan

    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.

  • 23. 10. 2016 19:18

    Lama (neregistrovaný) ---.pel.cz

    "...proč došlo ke vzniku VMS, DOSu, AmigaOS, MacOS, Windows, Windows NT a řady dalších operačních systémů, když je podle vás Unix tak dokonalý..." - asi si mysleli, že to uměj líp. Jenže se spletli a nechtěj si to přiznat ;-).

    "MS dokonce měl nejrozšířenější Unix na x86 platformě, a zavrhnul ho ve prospěch Windows NT. Proč asi?" - Dávat UNIX do Woken je jako dávat motor z Veyrona do Škodovky.. ;-). Prostě krom určité kompatibility to nemá jinak žádnou výhodu. Kdo chce UNIX, pořídí si originál UNIX a ne nějakou náhražku ;)

    Jinak mě fascinuje , jak někdo, kdo má na svědomí zhůvěřilost jako je W10, si dovoluje navážet se do ostatních systémů... Vy byste měli držet hubu a šoupat nohama.

    To, že jsou Wokna nerozšířenější na desktopu, je z podobného důvodu, jako je Android nejrozšířenější na šmatlafounech.

  • 22. 10. 2016 9:01

    klokan

    Nevím, co je na tom k nepochopení. Autor příspěvku netvrdí, že linux umírá. Naopak soudí, že na vymření je klasický Unix, tudíž Windows už nemá tak jako dříve subsystém na Unix, nýbrž na Linux, o jehož budoucnosti není pochyb.

  • 24. 10. 2016 10:40

    BobTheBuilder

    K tomu skypu: to dává smysl, když se nad tím zamyslíte: v okamžiku zadání jména nikdo neví, kdo bude přihlášení ověřovat. Je to lokální účet, nebo Microsoft account, nebo office365 nebo firemní ofice365 se SSO? A podle toho se možná budete přihlašovat heslem nebo certifikátem na kartě.

  • 21. 10. 2016 14:52

    GPL (neregistrovaný) 178.255.175.---

    Neni nutne s pridanim OS kodu pod GPL zverejnit vysledny kod celeho dila? Jak je to tady vubec s licenci?

  • 21. 10. 2016 15:10

    Peter Fodrek

    pod ktorou verziou GPL je bash?

    Vo verzii 3 je presne špecifikované, čo je to kompilát resp..súborné dielo napr. distribúcia. V prípade kompilátu môže mať každá časť svoju licenciu. Verzia 2 to nemá presne definované

  • 21. 10. 2016 15:59

    petmal (neregistrovaný) 24.114.69.---

    Oni patrně neprodávají kód ale binarky. GPL vás nenutí nic zveřejňovat pokud ke svému dílu přibalíte již skompilovany gpl kód. Data mezi vaší aplikaci a gpl aplikaci se můžou vyměňovat prostřednictvím pipe nebo souboru na FS. To pro gpl nepředstavuje problém.
    GPL zajímá pokud ten kód přímo zkopírujte do svého nebo linkujete knihovnu pod touto licencí.

  • 21. 10. 2016 18:40

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Ne tak uplne. Pokud dodavas produkt, ktery obsahuje GPL casti, tak k tem GPL castem ses povinen (na zadost) dodat zdrojaky. Je uplne jedno, jestli sis ty binarky vyrobil ty, nebo jestli si je nekde nasosal. To dodani muzes pochopitelne udelat treba odkazem na web tvurce te casti (pak bys ale mel uvest pochopitelne i informace o verzi).

    Proc myslis ze je u spousty produktu velmi peclive vyjmenovane ktere gpl knihovny pouzivaji - vcetne odkazu na jejich weby. A to presto, ze ten produkt jako takovy je uzavreny, a zdrojaky k nemu nedostanes.

  • 21. 10. 2016 22:07

    Sten (neregistrovaný) ---.net.upcbroadband.cz

    WSL (ta samotná vrstva) neobsahuje kód z Linuxu. K utilitám z Ubuntu je kód zveřejněn.

  • 22. 10. 2016 9:43

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Neblazni, to bys treba taky moh chtit, aby widle nacitaly RDNSS ...

  • 23. 10. 2016 13:55

    x (neregistrovaný) ---.net.upcbroadband.cz

    no tak treba ping funguje akorat je treba spustit jako admin :)