Pod Windows už lze neoficiálně rozběhnout i Arch Linux

Roman Bořánek 16. 9. 2016

Asi vám neuniklo, že Microsoft do Windows s výroční aktualizací přidal Ubuntu, přesněji Windows Subsystem for Linux, který umožňuje spouštění linuxových programů. Teď se na GitHubu objevil projekt snažící se místo Ubuntu použít mocnější distribuci – Arch Linux.

Projekt alwsl (ArchLinux adapted for WSL) je sice v rané fázi vývoje, ale alespoň ukazuje, že takovému řešení nic zásadního nebrání a ve Windows by mělo být možné použít také balíčkové základny jiných distribucí. Pro nedočkavce už je k dispozici první batchfile, ale autor projektu doporučuje počkat na první seriózní vydání.

(Zdroj: Hacker News)

Našli jste v článku chybu?
  • 16. 9. 2016 8:54

    Jezdec (neregistrovaný) ---.opera-mini.net

    Nezlobte se na me ale tohle mi uz pripada opravdu ujete.... kdo by to proboha chtel delat...

  • 16. 9. 2016 9:04

    _ (neregistrovaný) 82.142.100.---

    Linuxaci co maji pocit, ze se tim zvysi povedomi a nasledne penetrace na desktopu :)

  • 16. 9. 2016 14:11

    Jarda_P

    Kdybys nemel silne omezenou fantazii, napadlo by te treba to, ze nekteri lide chteji do Widli dotlacit veci, ktere tam chybi. Widle jsou dost holy system a treba CLI utility maji dost katastrofalni.

  • 17. 9. 2016 10:28

    bflmpsvz (neregistrovaný) 80.250.8.---

    Widle jsou sracka a neni duvod je pouzivat...

  • 17. 9. 2016 10:57

    Jarda_P

    Jiste. A mozna, ze jednou se i probudis do realneho sveta. Pri trose stesti zatim proces srackovateni Linuxu nepkroci prilis daleko.

  • 18. 9. 2016 21:45

    MMN (neregistrovaný) ---.v6.elisa-mobile.fi

    Kdo by to proboha chtěl dělat? :-)

  • 16. 9. 2016 9:05

    PQK

    Chlape, úplně stejný typ lidí, co dělá WINE . ;-)

  • 17. 9. 2016 21:53

    Franta Kučera

    Wine má smysl, protože umožňuje nahradit proprietární systém svobodným.

  • 16. 9. 2016 10:57

    vlk (neregistrovaný) 165.225.72.---

    v praci z korporatnych dovodov nemam inu moznost nez mat na desktope wokna a cygwin alebo mingw stale neni to prave...

  • 17. 9. 2016 21:52

    Franta Kučera

    Pokud pracuješ v korporaci, která tě takhle omezuje, tak obvykle nemáš ani práva si instalovat na počítač jakýkoli další software. V takovém případě to bývá dané nějakou interní směrnicí nebo tím, že nemáš práva administrátora nebo obojím.

  • 18. 9. 2016 21:54

    rudiik (neregistrovaný) ---.pnet.sferianet.cz

    To nemusi byt az tak pravda. Korporat ma vetsinou dane podporovane/po­volene OS a jejich zakladni nastaveni v ramci nejake policy nebo standardu. To ale zdaleka nemusi znamenat, ze nejde nic dalsiho nainstalovat. Pouze mohou existovat blacklistovane aplikace po jejichz instalaci dostane uzivatel pres prsty - typicky P2P veci, IRC, ruzne remote udelatka typy TeamView a podobne.
    Osobne taky jedu na W10 s Cygwinem a na tohle se docela tesim, protoze Cygwin obcas ma podivne bugy.

  • 16. 9. 2016 13:42

    Atrament (neregistrovaný) ---.19-3.cable.virginm.net

    Někdo, kdo se nechce trápit s otřesným linuxovým desktopem, ale ocení jeho konzolové nástroje (bash, vim, git, ssh, mc, atd ...) v pohodlí Windows?

  • 16. 9. 2016 13:53

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

    Windows jsou pohodlne stejne jako postel v koncentraku...

  • 16. 9. 2016 15:45

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

    Ktery ti sou ve widlich ... knicemu.

    Mimochodem, vim existuje nativne pro widle, git dtto, ssh taky, mc se proti TC muze jit leda zahrabat(natoz ve widlich) ... atd.

  • 16. 9. 2016 19:17

    Atrament (neregistrovaný) ---.opera-mini.net

    Používám je denně a nějak jsem si nevšiml, že by mi byli k ničemu.

    O existenci nativních verzí samozřejmě vím, ale není lepší mit to pěkně z oficialniho repozitáře, snadno instalovatelné a updatovatelné pomocí správce balíčků?

  • 18. 9. 2016 1:29

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

    Bohužel linuxové nástroje mají na WSL spoustu omezení. Například ve všech aplikacích vidíte normální cesty, jen v těch pod WSL jsou cesty v unixovém formátu. Zobrazování funguje jen přes X11 server, což je řekněme GUI obdoba děrných štítků. Předpokládám že většina zařízení nejede, protože na Unixech jsou závislé na device files.

    Pokud chcete na Windows instalovat open source z repozitáře, stačí nainstalovat Chocolatey, a pak napsat choco install vim git win32-openssh mc, a je hotovo. Pro aktualizaci stačí spustit choco upgrade.
    https://chocolatey.org

  • 18. 9. 2016 16:58

    Mr. Cidermaster (neregistrovaný) ---.nc.res.rr.com

    Nebo lépe: cup all -y

  • 20. 9. 2016 16:32

    Atrament (neregistrovaný) ---.19-3.cable.virginm.net

    Kdepak, vyzkoušel jsem Chocolatey, ale to není alternativa k WSL, jde prostě jenom o balíčkovací systém pro Windows a to není to co potřebuju. Na WSL oceňuju, že je to komplet Linuxová příkazová řádka se vším všudy. Nepoužívám přes to žádné aplikace vyžadující Xka, a ani nic co by potřebovalo device files, takže se mně naštěstí žádná omezení které uvádíš netýkají.

  • 16. 9. 2016 16:30

    bez přezdívky

    Otřesný linuxový desktop mě pobavil. :-D KDE strčí hravě do kapsy všechny Windows, které kdy nabootovaly.

    Kdyby o otřesném linuxovém desktopu hovořil nějaký Apple fanatik, asi bych to s pousmáním chápal -- zvykl si na zlatou klec, která jaksi nic neumí a nedělá a tedy nic nezkazí, a použitelný desktop ho děsí. Ale mluvit o údajně otřesném linuxovém desktopu ve srovnání s žumpou zvanou Windows -- to je poněkud ujeté. Pohodlí Windows? :-D Jako fakt vážně?

    Inu, dobrý trolling, to se musí nechat. A ano, trolly bych správně neměl krmit.

  • 17. 9. 2016 11:01

    Jarda_P

    Linuxu chybi dlazdicky! Desktop, co nevypada jak zed v koupelne, neni hoden byt nazyvan desktopem.

  • 18. 9. 2016 23:33

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

    systemd-metrod ? ;-)

  • 18. 9. 2016 21:48

    MMN (neregistrovaný) ---.v6.elisa-mobile.fi

    Už mají Okna virtuální plochy nebo aktivity?

  • 19. 9. 2016 0:20

    Atrament (neregistrovaný) ---.19-3.cable.virginm.net

    Virtuální plochy jo, aktivity ne.

  • 19. 9. 2016 2:02

    J.T.S (neregistrovaný) ---.8-3.cable.virginm.net

    Virtuální plochy používám na Linuxu odjakživa , ale aktivity jsem dodnes nepochopil.

  • 19. 9. 2016 5:39

    Atrament (neregistrovaný) ---.19-3.cable.virginm.net

    Virtuální plochy pro mně přestaly být zajímavé v okamžiku kdy jsem si pořídil druhé LCD, do té doby jsem je taky používal. Aktivity jsem nepobral nikdy.

  • 16. 9. 2016 9:11

    Tom (neregistrovaný) ---.sonepar.cz

    A co třeba možnost provozovat na jednom stroji třeba DB server pod OS Linux,
    aplikační server pod OS Win.... Ve spoustě firem je heterogení prostředí...

  • 16. 9. 2016 9:47

    xyz (neregistrovaný) ---.cust.tlapnet.cz

    Ve spoustě firem je heterogení prostředí...

    Ale proč bych tam neměl nainstalovat rovnou Linux. Jaké jsou asi výhody Linuxu běžícího ve Win ?

    Asi takovéto: systém zabere několikrát více místa, je mnohem náročnější na systémové prostředky, tím pádem méně stabilní, bootování trvá déle, po aktualizacích je vyžadován restart (častější restarty), atd.

    Kdo asi na takovémto systému bude rozjíždět firemní aplikace, asi úplný blázen.

  • 16. 9. 2016 10:55

    Pavel Píša

    Z mého pohledu je to záchrana pro mnoho vývojářů. V několika firmách jsem před lety řešil kompilaci GCC a cross toolů pro různé embedded projekty (často ne-Linuxové) a bylo to vždy extrémní množství zbytečně vynaloženého času, pokud jsem to chtěl předvést/udělat tak, aby to mohli reprodukovat. Jednalo se o cílové architektury m68k, PowerPC, ARM.

    O řád lepší bylo připravit toolchain pro Cygwin nebo MSys canadian-crossem na Linuxu. Takové Sysgo, pokud vím, a další naivestovali hromadu času do úprav Linuxového jádra a build systému, aby bylo možné embedded řešení vyvíjet na Windows. Potíž totiž je, že v mnoha velkých firmách je tvrdá korporátní politika, která zakazuje vlastní instalaci OS na zaměstnanecké počítače a i pokud je to možné, tak se často bez proprietárních bezpečnostních řešení vůbec nedostanou na síť nebo to řeší připojením pracovních počítačů přes své soukromé mobilní datové služby.

    Co sleduji současný trend, tak již velké množství těch firem nabízejících podporu embedded Linux vývoje spíš "nativní" Windows řešení pro extrémní spotřebu času jak u nich tak u zákazníků vzdalo a řeší to (často předinstalovanými) Linuxovými virtuály pod Windows. Ale věřím, že řešení s WSL bude často pohodlnější a třeba se jednou přiblíží život embedded a mobilních vývojářů komfortem a trochu i výkonem práci pod GNU/Linuxem. Na druhou stranu mono specializovaných profesionálních nástrojů pro analýzu komunikací atd. existuje jen pro Windows. Takže někdy i nic jiného něž kombinace obou systémů je nutnost. A nebo si nástroje řešit vlastní cestou.

    Například na CAN máme teď díky našim aktivitám a pracem studentů analyzátor, který je v záznamu času příchodu zpráv přesnější a výkonnější než střední až možná i základní vyšší třída nástrojů s Windows only rozhraním. Ale další analýzu záznamu a filtrování si musíme řešit také sami, od jednoduchého grepu v příkazové řádce až po Qt aplikace. Takže pro mnoho firem je klikací Windows řešení rychlejší cesta. Když pak dojde na složitější věci, tak již stejně skriptování a klikání v proprietárním analyzátoru nestačí a je pak celkem jedno, kde se aplikace píše. Na Linuxu je to jednodušší třeba u CANu o to, že existuje jednotné API a není nutné integrovat knihovny několika odlišných dodavatelů CAN HW.

    Obecně tedy považuji WSL za velkou pomoc. Zároveň MS motivuje k analýze a poučení se z řešení před mnoha lety vyvinutými pro Linux. Například museli naimplementovat Futex (i když z pohledu RT a robust Futex je to spíš jen parodie) a API přidali i do WIN32. Až časem vymřou starší verze OS a knihovny tak postupně třeba i výkon takové základní funkce jako zamknutí mutexu a čekání na event bude ve Windows na rozumné úrovni. Analýza vývoje čekání na event je ve WIN32 API je mimochodem extrémně zajímavá tím kolik špatných řešení a optimalizací lze vymyslet. Celkem hezký základ z VMS, kvůli nárokům na inicializační syscally přidání lazy init, výsledkem náhodné padání aplikací až za běhu kvůli vyčerpání prostředků, přidání keyed event aby bylo možné napsat frontu pro čekání na uvolnění prostředků, atd atd. a pak přidání Futexu a možnost to řešit bez inicializačních syscallů úplně.

  • 16. 9. 2016 12:47

    mejla (neregistrovaný) ---.tmcz.cz

    Měl byste nějaké bližší informace o implementaci futexů ve Windows, dokumentaci Win API apod?

  • 16. 9. 2016 14:05

    Pavel Píša

    Funkce jsou ve WIN APi k dispozici od MSDN Windows 8, Windows Server 2012. Jedná se o WaitOnAddress, WakeByAddressSin­gle, WakeByAddressAll Windows 8 / 2012 Server. Podle dokumentace není vyřešené/nezmiňuje se priority inheritence, robustness, requeue, ani není jasné, jaké bude chování na sdílené paměti mezi procesy. Ale to poslední předpokládám, že kvůli WSL bude již řešené. Korektní RT priority asi v NT jádře vyřešit nelze, protože chybí základ. Ve WIN CE bylo dědění priorit řešené, jinde jsem to u MS neviděl.

    Mnou sesbírané poznatky a zajímavosti k tématu řešení synchronizace/se­rializace běhu procesů a vláken jsem se snažil mimo jiné předávat studentům v rámci předmětu Opensource programování http://rtime.felk.cvut.cz/osp/.

    Odkazy a poznámky viz Slide 14 přednášky se zamyšlením nad škálovatelností software obecně, která předvádí pár zajímavých problémů a řešení na úrovni Linuxového jádra a propojení se userspace.

    Vzhledem k tomu, že se minimálně ta více v anketách viditelná část studentů oborů Počítačové inženýrství a Softwarové inženýrství vyjádřila, že považují takováto témata za nehodná času lidí, kteří by měli příští operační systémy navrhovat a implementovat výkonné aplikace a softwarová řešení, tak předmět v budoucích programech není a je velmi nízká pravděpodobnost, že ještě někdy poběží

    Náhradou bude předmět Efektivní software, který budou učit kolegové, tak se jim snad bude se studenty vést lépe.

    Za sebe uvažuji, nabídnout svůj pohled a zkušenosti s danými oblastmi jako cyklus přednášek pro SUT nebo jinde i mimo mojí domovskou univerzitu, pokud se najdou zájemci, kterým by můj výklad vyhovoval.

  • 16. 9. 2016 19:01

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

    Dokumentace nezmiňuje implementační detaily, které se mohou lišit v dalších verzích, a na které nemáte (a nesmíte) spoléhat.
    https://blogs.msdn.microsoft.com/oldnewthing/20160826-00/?p=94185

  • 17. 9. 2016 0:16

    Pavel Píša

    Díky za doplnění odkazu. Myslím, že jsem i původně něco k WaitOnAddress četl z blogu Raymonda Chena, ale tento článek to myslím nebyl. Z popisu implementace mi pak trochu vstávají vlasy na hlavě, protože se tváří nejasně a lze interpretovat i tak, že hash table je v user-space. To pak využití mezi procesy zcela vylučuje. Linux překládá pro sdílené VMA adresu v jádře na "fyzickou" (typu inode + offset) a hashuje až podle této adresy. Takže buzení pak chodí nezávisle na procesu. Pro lokální futexy se řešilo zrychlení nedávno LWN: In pursuit of faster futexes

    Co se týče výčtu nedostatků, tak to opravdu není implementační detail. Ne jen implementace mutexů a WaitOnAddress ale celý současný návrh jádra Windows vylučuje jakékoliv uvažování o použití v řídicích aplikacích a kdekoliv, kde na časování záleží. MS sám jasně před chováním/kvalitou svého jádra varuje. The scheduler solves priority Inversion problem by randomly boosting the priority of the ready threads. Přitom návrh Futexu s vyřešením dědění priorit je opravdu ještě o řád vyšší level, než mít ochranu proti inverzi priorit vyřešenou pro WaitForSingle­Object, kde (také alespoň podle dokumentace MS) řešená zatím nemůže být a není.

    Obecně je zarážející, jak je neuvěřitelně nízká technologická úroveň mnoha řešení ve Windows (při inkasovaných a proinvestovaných částkách). Přitom start z VMS a drivery postavené na IORP byl dobrý. Celkově výsledný stav vyvrací MS i Vámi dříve často opakované teze o tom, že open-source komunita umí akorát kopírovat a vytvářet horší alternativy k řešením, do kterých inovativní firmy musely desetiletí investovat. Ve většině případech to nebyla pravda nikdy a dnes to již potvrzuje i samotný MS tím, že se snaží ke komunitnímu vývoji a modelu připojit. Pro technologický stav celkově nainstalované báze SW a systémů (kde se stále stále se značným zastoupení Windows musí počítat) by bylo velmi dobře, aby se každý vývojář ne jen MS zajímal o to, jak problémy řeší ostatní a v případě open-source je to tak jednoduché, že je ignorování opravdu ostuda.

  • 17. 9. 2016 21:04

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

    Ad To pak využití mezi procesy zcela vylučuje - ano, to je snad zjevné z dokumentace.

    Ad Linux překládá pro sdílené VMA adresu v jádře na "fyzickou" (typu inode + offset) a hashuje až podle této adresy - nemá moc smysl si z Win32 API vybrat thread synchronization funkci, a vyčítat jí, že není to interprocess synchronization. Windows mají řadu synchronizačních mechanismů různého určení. Třeba Critical Section Objects, které propadají na kernel space až pokud je třeba. Pak jsou tu (celkem nové) Slim Reader/Writer (SRW) Locks, condition variables, one-time initialization, interlocked variable access atd.
    https://msdn.microsoft.com/en-us/library/windows/desktop/ms681924(v=vs.85).aspx

    Ad celý současný návrh jádra Windows vylučuje jakékoliv uvažování o použití v řídicích aplikacích a kdekoliv, kde na časování záleží - Windows NT nejsou RTOS. Ovšem kernel Linuxu se svými gigantickými locky (svého času včetně BKL), overcommittingem a dalšími features na tom také není nic moc. Ve Windows můžete použít například RT extension IntervalZero RTX, nebo jsou tu Windows CE.

    Ad neuvěřitelně nízká technologická úroveň mnoha řešení ve Windows - nějaké konkrétní příklady? Zatím jste si akorát vybral jeden synchronizační mechanismus, a srovnáváte ho s úplně jiným mechanismem na Linuxu.

  • 18. 9. 2016 12:17

    Pavel Píša

    Nemyslím si, že implementace kritických sekcí (z pohledu POSIXu mutexů) je jedno okrajové primitivum. Předpokládám, že se shodneme, že v dnešní době je pro využití výkonu nutné implementovat mnoho algoritmů vícevláknově. Zamykání je pak většinou bohužel potřeba (*) a jeho rychlost a spolehlivost je kritická. Z měření a testů různých projektů, které nakonec kvůli uživatelům přidávají port pro Windows vyplývá, že WaitOnAddress má nejmenší overhead. Pro starší verze Windows pak vypadá nadějně NtWaitForKeyedEvent

    Proč KeyedEvent existují a obecně implementace kritických sekcí se několikrát zásadním způsobem ve Windows nepovedla si lze přečíst ve zápiscích Windows keyed events, critical sections, and new Vista synchronization features, zde LockLess Keyed Events nebo u Raimonda Chena <a href="">The history of Win32 critical sections so far. Na mě jeho vyjádření "Windows XP solved the problem of the dreaded "out of memory" exception" působí tak, že si je vědom toho, jak se MS sám ve vývoji a údržbě API topí. Přitom KeyedEvents bylo z bláta do louže, z pohledu determinizmu katastrofa, z pohledu složitosti další berlička s mnoha voláními do jádra, která jen zajišťuje to, že původní pomalá volání půjde použít bez padání aplikace

    Co se týče Linuxového jádra a RT, tak máte pravdu, že se v jádře nalézají konstrukce, které jsou ošklivé a z pohledu RT katastrofální. Například celý síťový stack, který je optimalizovaný na propustnost, ale struktury SKB se vymkly kontrole. V BSD se mi MBUFy zdají jednodušší a možná jsou i výkonnější. Ale základ jádra je napsaný celkem dobře a po aplikaci RT patchů je možné přes standardní POSIXové API jádra a drivery docílit odezev, které jsou obdivuhodné a na které Widows s nepreemptivním Dispatch Levelem nikdy mít nebude. I na tak slabém HW, jako je Rsapberry Pi 1 je možné docílit i při testování pod maximální a všestrannou zátěží odezev jádra, které za dlouhodobé ověřování nepřekročí 350 usec. Přitom třeba i s regulační smyčkou uzavřenou přes SPI jsme na 1 kHz neměli problémy. V jádře pak zpracování událostí buzenými vlákny zvládalo jakž takž i 20 kHz. To vše bez náhrady HAL alternativním jádrem OS, ještě k tomu uzavřeným, které pouští RT tasky mimo plánovač Windows a vlastně z Windows dělá jen paravirtualizovanou doménu pro nepodstatné úlohy a správu. O možnostech RT v Linuxu jsem takový úvodní článek pro Root před časem napsal GNU/Linux pro řízení a rychlost jeho odezvy. Jinak z toho, co pozoruji ve velkých firmám, tak je až děsivé, kam všude Linux firmy nasazují a jak často neexistují alternativy. Takže jsem letošní léto věnoval pomoci projektu RTEMS https://www.rtems.org/, který takovou alternativou pro určité ohraničené oblasti je. Například je strategickou volbou ESA a NASA pro mnoho vesmírných misí a po mnoho let je v nich již na specifické úkoly nasazovaný.

    (*) Co se týče paralelizace, tak kritické sekce jsou obecně problém a Linux již mnoho let používá tam, kde to lze, mechanizmy Read Copy Update (RCU), které přispívají k řádovému zvýšení propustnosti. RCU mechanismus je k dispozici i jako knihovny pro user-space http://liburcu.org/. Dohodlo se již MS s IBM na poskytnutí patentů k této technologii vyvinuté v rámci vývoje jádra Linux tak, aby konečně začalo nabízet tento mechanizmus i v rámci MS WIN a NT API?

    Jak je to s tím Futexem na WIndows, chodí alespoň ten ve WSL mezi procesy? Běží v této oblasti nějaký vývoj? Jsou někde pro WS k dispozici výstupy OpenGroup Operating System Tests? Našel jsem akorát výsledky LTP pro WSL (CommandLine-Documentation LTP_Results). Mimochodem, mohu nabídnout maličký ale celkem zajímavý kousek SW k otestování mutexů, conditional variables a semaforů mezi několika procesy. Někdo může vyzkoušet, jak to na WSL bude chodit.

  • 18. 9. 2016 19:39

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

    Ad v dnešní době je pro využití výkonu nutné implementovat mnoho algoritmů vícevláknově - to jistě ano. Proto nechápu, proč řešíte synchronizaci procesů a nikoliv threadů.

    Ad Z měření a testů různých projektů, které nakonec kvůli uživatelům přidávají port pro Windows vyplývá, že WaitOnAddress má nejmenší overhead - to mě zajímá. Máte k tomu nějaké zdroje, nejlépe týkající se srovnání výkonu Win32 sync primitiv? Mimochodem uvědomte si ale že každé z těch primitiv má jiné výhody a nevýhody. WaitOnAddress je rychlý, ale má to svou cenu jinde.
    Ad NtWaitForKeyedEvent - to je použité mimo jiné v SRW Locks

    Ad implementace kritických sekcí se několikrát zásadním způsobem ve Windows nepovedla - byla poplatná své době. Mimochodem v té době jste ještě na Linuxu neměli ani funkční threading, s tím že LinuxThreads za funkční opravdu nelze považovat. A z toho jak je threading do kernelu dopatlaný asi musí vstávat vlasy hrůzou každému. Nejpřiléhavější popis, který mě napadá, je refactoring kladivem, bruskou a lepicí páskou.

    Ad dreaded "out of memory" exception; z pohledu determinizmu katastrofa - a jako alternativu byste doporučil Linux, který "deterministicky" lže o úspěšné alokaci paměti (overcommitting), a když ta lež praskne, tak náhodně odstřeluje procesy (OOM Killer)? Většina OS má problém když dojde na OOM, ale zrovna Linux je na tom velmi špatně.
    Ad další berlička s mnoha voláními do jádra, která jen zajišťuje to, že původní pomalá volání půjde použít bez padání aplikace - se kterými mnoha voláními? Sám jste linkoval: CriticalSection API... similar to mutexes on pthreads in Linux, has a fast-path where no transition to kernelspace via a system call is needed. Critical Section Objects se časem zrychlily, ale problém je v tom, že vývojáři hrabali na nedokumentované části struktury. Kvůli tomu nezrychlily tak jak by mohly.

    Ad základ jádra je napsaný celkem dobře a po aplikaci RT patchů... - které jsou tuším nepodporované... Navíc píšete o 350us. S RTX se na Pentiu dostanete na worst-case 2-30us, podle HW. Plus RTX běží i pokud jádro NT z nějakého důvodu spadne.
    Ad RTX... bez náhrady HAL alternativním jádrem OS, ještě k tomu uzavřeným, které pouští RT tasky mimo plánovač Windows a vlastně z Windows dělá jen paravirtualizovanou doménu pro nepodstatné úlohy a správu - RTX HAL nenahrazuje, ale rozšiřuje. Všimněte si, že není potřeba změna jediného řádku zdrojáku NT, ani jeho nový překlad. NT tasky se pak používají pro úlohy, které nejsou časově kritické. Netvrdil bych že jsou "nepodstatné", nebo že jde jen o správu.

    Ad Linux již mnoho let používá tam, kde to lze, mechanizmy Read Copy Update (RCU), které přispívají k řádovému zvýšení propustnosti. RCU mechanismus je k dispozici i jako knihovny pro user-space http://liburcu.org/. Dohodlo se již MS s IBM na poskytnutí patentů k této technologii vyvinuté v rámci vývoje jádra Linux tak, aby konečně začalo nabízet tento mechanizmus i v rámci MS WIN a NT API? - lock-free synchronization techniques se ve Windows používají dlouho, například ve Vistě se zvyšoval počet míst kde jsou použity. Ohledně API: Win32 nabízí Interlocked Singly Linked Lists, pro C++ je tu Parallel Patterns Library, .NET má Concurrent Collections. O dohodě mezi MS a IBM nevím, ale nevylučuji že existuje.
    https://msdn.microsoft.com/en-us/library/ms684121%28VS.85%29.aspx
    https://msdn.microsoft.com/en-us/library/dd504870.aspx
    https://msdn.microsoft.com/en-us/library/dd460718(v=vs.110).aspx

    Ad s tím Futexem na WIndows, chodí alespoň ten ve WSL mezi procesy - pokud máte na mysli SRW Locks, tak ne. Ve Windows se používá multithreading. Na Unixech sice také zjistili že existují thready, a dokonce konečně existují použitelné implementace i mimo Solaris :), ale autoři kódu to asi ještě nepostřehli.
    Ad Běží v této oblasti nějaký vývoj - pochybuji, bylo by to jako vyvíjet podporu děrných štítků. Ale můžete použít events, mutexes, semaphores, timer objects, a samozřejmě Interlocked API.
    https://msdn.microsoft.com/en-us/library/windows/desktop/ms684122(v=vs.85).aspx

    Mimochodem produktivnější než ptát se mě, který se C/C++ vyhýbá jak může, je obrátit se na dokumentaci nebo knihu Windows Internals. Tohle je šesté vydání, sedmé bude vycházet teď na podzim. Okolo stran 180-210 se řeší synchronizace.
    http://materias.fi.uba.ar/7508/WI6/Windows%20Internals%20Part%201%20(6th%20Edition).pdf

  • 16. 9. 2016 10:54

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

    Jo, tovizejo ... a presne takhle se to dela ...

    Kdyz uz, tak se prekvapive provozuje nejaka virtualizacni platforma ... coz je ... prekvapko ... prakticky za 100% prave tux(vmware nevyjimaje), a na nem se poustej widle. Rozhodne se to nikdy nikde nedela opacne. A viz ty proc? Paac tux narozdil od widli nepada.

  • 16. 9. 2016 12:35

    _ (neregistrovaný) ---.cust.vodafone.cz

    Obcas je dobry vylezt z nory a rozhlednout se. Svet neni idealni a delaji se veci o kterych se ti ani nezda ...

  • 16. 9. 2016 13:07

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

    Sak takovejm rad nauctuju pekne vysokou fakturu za leceni jejich systemu ... jednoduse proto, ze to nefunguje a nikdy nebude.

  • 16. 9. 2016 17:13

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

    Hm. Mě nefungoval VMware ESXi, protože byly pořád problémy se síťovou konektivitou při zátěži. Ti co vystavují pěkně vysoké faktury s tím také nedokázali nijak pomoc. Od přechodu na Hyper-V nebyl nikdy problém. A to se od té doby řádově zvýšil počet hostů i guestů. Ale jinak to nefunguje a nikdy nebude... konkrétně vám :)

  • 19. 9. 2016 8:12

    BoBLO (neregistrovaný) ---.nafta.sk

    Moj ty Boze! Spolu s Michaelom Kocabom volam: "Tak to uz je moc! To je snad zlej sen!"

  • 19. 9. 2016 10:25

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

    To je zdejsi M$ maskot lulan, tomu se widle patchujou 3s, a bootujou za 1s. Restart je pak jedinej zpusob jak patchnout opice, a je to zcela vporadku ... ;D

    Jestli se chces vazne kralovsky pobavit, tak si pohraj s tim jejich XP modem ... to sou totiz defakto virtualni XPcka, a presne podle toho se to naprosto demente chova, a to co ti nejede jinde v tom stejne nezprovoznis. Napriklad pokud to mas v domene, tak to znamena, ze musis mit v domene i ty XPcka a chova se to jako dalsi PC ... vcetne nutnosti to administrovat ... lol. A samo neustale to pada a pada a pada, takze kdyz si nahodis vmware player, tak to jednak pobezi, druhak to nerezesere materskej system a zatreti to budou realny XPcka, takze na nich pobezi presne to co na XPckach.

    BTW: Uz sem mel v ruce asi 50 stroju, ktery byly po instalaci win10 zcela nefunkcni ... protoze nemeli sit. Ti curaci v M$ neumej integrovat drivery ani pro ty nejbeznejsi sitovky na trhu ... ani toho blbyho realteka kterej je vsude to proste nenajde. lol

    Nejmin 15 let se mi nestalo, ze by tux nenastartoval a nemel sit. A to vcetne vsemoznych obskurnich kousku HW, u kterych sem ani nedoufal, ze by to mohlo chodit.

  • 19. 9. 2016 12:14

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

    Ad tomu se widle patchujou 3s, a bootujou za 1s - tady si zase někdo vymýšlí

    Ad si pohraj s tim jejich XP modem - ten jsem nikdy nepoužíval. Navíc je určený pro Win7, ne Win8/10. To VHDX se dá použít v Hyper-V, a nevidím důvod, aby to padalo jinak nebo víc než ve VMware.

    Ad Uz sem mel v ruce asi 50 stroju; curaci v M$ neumej integrovat drivery ani pro ty nejbeznejsi sitovky na trhu - hmm, a co si třeba driver přidat na instalační média? Neumíte? Aha.

    Ad Nejmin 15 let se mi nestalo, ze by tux nenastartoval a nemel sit - zato já pravidelně řešil problémy s WiFi, které nikdy nefungovalo jak by mělo. Většinou vůbec, jindy po dlouhém přemlouvání (stahování, kompilace) a s hromadou problémů včetně tuhnutí systému.

  • 19. 9. 2016 16:40

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

    @ j

    Zrovna včera jsem známé na notebooku s win 10 řešil, že jí nešel zvuk. Na latopu přes fn - zaplý. Na liště ikonka - zaplý, ovladač hlasitosti byl na max, zařízení reproduktor - vybráno. Sranda. Takže vyhledat potíže - ono to občas od win7 pomůže a taky je to jednoduší než hledat na MS nějakou radu typu přeiinstaluj ovladač. No a jak to dopadlo? Dám vyhledat potíže a ejhle: zařízení -> sluchátka. Úplně něco jiného než ukazuje v nastavení. Ok, pár dementních otázek průvodce, ale pomohlo. Po restartu zase nastavené debilně na sluchátka. A víš co je sranda? V tom NTB nikdy sluchátka nebyly - Nikam ho nenosí a sluchátka nemá :-D To je výkon. Člověk by se i zasmál, resp. zasměje, ale jinak je to k pláči. Takové školácké a laciné chyby v OS . . . .

  • 19. 9. 2016 18:16

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

    Buď driver, nebo zdířka sluchátek. Ty zdířky typicky detekují vložení konektoru pomocí spínače. Je to mechanicky titěrné, a často to odchází, takže pak zařízení trvale chybě indikuje, že jsou připojena sluchátka. Ale v mlze je jasně vidět, že to není chyba driveru ani HW, ale OS :D

  • 19. 9. 2016 21:29

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

    konektor odchazi kdyz se casto pouziva, nikoliv kdyz uzivatel nema, nepouziva sluchatka a nikdy je do toho konektoru nezasunul
    ...
    kdo podle tebe muze za to ze se Windows chtej a (a beznym uzivatelum i automaticky) restartovat? OS nebo slot na ExpressCard?

  • 20. 9. 2016 11:32

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

    Ad konektor odchazi kdyz se casto pouziva, nikoliv kdyz uzivatel nema, nepouziva sluchatka a nikdy je do toho konektoru nezasunul - konektor častěji odchází, když se používá. Ve skutečnosti nevíte jestli ho uživatel (nebo jeho kolega, partner/ka, děcko) použil. Konektor samozřejmě může odejít i pokud se použije jen jednou, a otázka je, jestli je potřeba alespoň to jedno použití. Takže závěr je ten, že to může být driver nebo konektor, s tím že konektor jste nevyloučil. Chápu že vy máte předpřipravený závěr, který pak "vidíte v mlze". Já radši fakta, než abych věřil nesmyslům.

    Ad kdo podle tebe muze za to ze se Windows chtej... restartovat - a co si o tom myslíte vy?

  • 20. 9. 2016 16:03

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

    "Ve skutečnosti nevíte jestli ho uživatel"

    Vím, dotyčný NTB by totiž do nedávna můj a kupován byl nový. Takže
    "Chápu že vy máte předpřipravený závěr, který pak "vidíte v mlze". Já radši fakta, než abych věřil nesmyslům."
    e zase další <|> z té tvojí huby o věcech o kterých ho.no víš. Ale drze rýpat, to jo. Se divím, že radši nesedíš na podpoře MS a neradíš každému ať přeinstaluje drivery nebo rovnou OS.

  • 20. 9. 2016 16:13

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

    " Buď driver, nebo zdířka sluchátek. Ty zdířky typicky detekují vložení konektoru........ že jsou připojena sluchátka. Ale v mlze je jasně vidět, že to není chyba driveru ani HW, ale OS :D"

    Až na to, že to v nastavení ukazuje ty reproduktory, takže buď to správně identifikuje pokažený konektor jako sluchátka a debilně zobrazuje v nastavení, nebo debilně identifikuje konektor ( je teda ale chybný ) a správně zobrazuje v nastavení. V obou případech je to špatně. Na tom je hezky vidět, že logické myšlení a chápání psaného textu nezvládáš a v hlavě máš nas..no . . . To je přesně to, co předvádíš pořád. Link si najdeš (informaci) ale zpracovat ji a začlenit do problematiky nebo života tak, abys nebyl za debila, to už nedokážeš.

  • 20. 9. 2016 17:00

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

    No jasně, konektorem to být nemůže, protože notebook byl "do nedávna [váš] a kupován byl nový". To že to není konektorem prokážete buď tak že najdete jinou příčinu (klidně to může být ten driver, nebo i něco jiného), nebo tak že testem vyloučíte, že by to byl konektor. Problém jste sice podle všeho zatím nevyřešil, ale už víte, že já mám v hlavě nasráno, když upozorním, že to může být i konektor. To svědčí jednak o tom že nechápete ani triviality, a pak (což je zásadnější) o tom že jste nevychované vulgární hovado, jedním slovem lůza. Takže za mě: naučte se slušnosti, nebo jděte do hajzlu.

  • 20. 9. 2016 19:09

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

    "No jasně, konektorem to být nemůže, protože notebook byl "do nedávna [váš] a kupován byl nový". To že to není konektorem prokážete buď tak že najdete jinou příčinu "

    Jsi idiot? Já ti nenapsal že to není konektorem ale že vím, že se nepoužíval, protože jsem ten notebook měl skoro celou jeho dobu já. Jak jsem psal. Ani psanému textu nerozumíš, tak se nepouštěj do nějakých rozborů, vole. Samozřejmě že mě to s tím konektorem nenapadlo (protože ho nikdo nikdy na tom ntb nepoužíval) a ani jsem neveděl že takové chyby mohou vzniknout a samozřejmě že to vyzkouším nebo otestuju - a to proto, že neodsuzuji informace jenom proto, že je vyřkne nějaká <|> ale třídím je podle toho, jaké jsou a jakou mají hodnotu a začlením je do rozhodování. Tak jak ti to celou dobu píšu. Pak se po takových výlevech a 0 chápavosti a volovinách co třepeš nediv, že ti člověk nadává nebo píše sprostě, protože jinak absolutně nezapojuuješ tu palici ani trochu . . .

  • 20. 9. 2016 22:43

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

    Jste lůza a děláte z diskuse žumpu. Naučte se slušnosti, nebo běžte do hajzlu. S přátelským pozdravem, Lael

  • 21. 9. 2016 0:15

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

    No ty mě tak budeš poučovat, takové jelito . . .

  • 19. 9. 2016 12:15

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

    Ad "Tak to uz je moc! To je snad zlej sen!" - přesně to jsem si říkal, když jsme ten VMware řešili :)

  • 17. 9. 2016 21:56

    Franta Kučera

    Od toho máme virtualizaci. Kdybys náhodou potřeboval něco ve Windows, pustíš si je pod GNU/Linuxem přes KVM, VirtualBox, Xen…

  • 16. 9. 2016 11:01

    Brouk (neregistrovaný) ---.fe.bosch.de

    1) zavést kompatibilitu s konkurencí
    2) nabídnout (pokud možno co nejvíce stávajícím i novým klientům) VÝHODNOU / dotovanou cenu i při hostování konkurenčních služeb
    3) vydržet tak dlouho, abych získal dostatečně velkou skupinu klientů
    4) zavést "změny", které způsobí problémy pouze těm, kteří jsou ještě stále u konkurence
    5) nabídnou vlastní řešení stávájícím klientům
    6) GOTO 4 dokud nezlikviduji konkurenci

    Zatím jsme u bodu 1), ale pokud se to povede, bude to pekelná jízda.

  • 17. 9. 2016 22:01

    Franta Kučera

    MS tohle dělá pořád dokola, znovu a znovu… bohužel někteří jeho zákazníci jsou nepoučitelní. Asi masochisti. A bohužel to má i vedlejší negativní dopady na ty, kteří si od MS nic nekupují a nechtějí s ním mít nic společného :-(

  • 16. 9. 2016 15:35

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

    tiborek

  • 18. 9. 2016 11:10

    pjezek

    Osobně v tom jako archer moc potenciálu nevidím. Jediný, který mne napadá, je možnost proniknout snáze do wokenních nástrojů zevnitř, protože v kombinaci s virtualizací je možné téměř vše. Na straně Windows jsou patrné silné znaky deficitu systémového vývoje, což vede k otevírání se směrem k UNIX like prostředím. MS tím vlastně přiznává, že jeho cesta vedla stezkou hojnosti k poušti...

DigiZone.cz: Ultra HD v praxi a v Portugalsku

Ultra HD v praxi a v Portugalsku

Lupa.cz: Patička e-mailu závazná jako vlastnoruční podpis?

Patička e-mailu závazná jako vlastnoruční podpis?

Lupa.cz: Blíží se konec Wi-Fi sítí bez hesla?

Blíží se konec Wi-Fi sítí bez hesla?

Podnikatel.cz: Byla finanční manažerka, teď cvičí jógu

Byla finanční manažerka, teď cvičí jógu

Vitalia.cz: Test dětských svačinek: Tyhle ne!

Test dětských svačinek: Tyhle ne!

Vitalia.cz: Tradiční čínská medicína a rakovina

Tradiční čínská medicína a rakovina

Vitalia.cz: Antibakteriální mýdla nepomáhají, spíš škodí

Antibakteriální mýdla nepomáhají, spíš škodí

Lupa.cz: Další Češi si nechali vložit do těla čip

Další Češi si nechali vložit do těla čip

DigiZone.cz: Parlamentní listy: kde končí PR...

Parlamentní listy: kde končí PR...

Podnikatel.cz: Tyto pojmy k #EET byste měli znát

Tyto pojmy k #EET byste měli znát

Podnikatel.cz: Udělali jsme velkou chybu, napsal Čupr

Udělali jsme velkou chybu, napsal Čupr

Lupa.cz: Jak se prodává firma za miliardu?

Jak se prodává firma za miliardu?

DigiZone.cz: Digi Slovakia zařazuje stanice SPI

Digi Slovakia zařazuje stanice SPI

Vitalia.cz: 5 chyb, které děláme při skladování potravin

5 chyb, které děláme při skladování potravin

DigiZone.cz: Nova opět stahuje „milionáře“

Nova opět stahuje „milionáře“

Podnikatel.cz: ČSSZ posílá přehled o důchodovém kontě

ČSSZ posílá přehled o důchodovém kontě

Vitalia.cz: Tesco nabízí desítky tun jídla zdarma

Tesco nabízí desítky tun jídla zdarma

DigiZone.cz: Wimbledon na Nova Sport až do 2019

Wimbledon na Nova Sport až do 2019

DigiZone.cz: Numan Two: rozhlasový přijímač s CD

Numan Two: rozhlasový přijímač s CD

Vitalia.cz: Tohle jsou nejlepší česká piva podle odborníků

Tohle jsou nejlepší česká piva podle odborníků