Vlákno názorů k článku
Windows Subsystem for Linux 2 oficialně v rámci Windows 10 update 2004
od K> - Trochu me mate, ze nejprv Mikrosoft 3 roky...
-
Osobně si myslím, že se MS dlouhodobě snaží naskočit do Docker/Kubernetes vlaku.
A pro Docker je pořeba mit CGroups a ty zrejme nejde nejak proste mapovat na windows native funkcionalitu.
Zapracovat do reseni linux kernel je zrejme snazsi, nez reimplementovat potrebnou funkcionalitu pro beh Dockeru. -
Korporace někdy zkusí jednodušší cestu a pro složitější se rozhodnou až podle výsledků. Taky někdy rozjedou obě cesty a jedna je hotová dřív, druhá později a konkurují si vlastnostmi. Důvodů může být prostě hodně.
Taky se za tu dobu změnilo prostředí. Počítače mají zase víc paměti, větší výkon a Hyper-V se využívá častěji. I to mohou být důvody pro změnu.
Každopádně je to normální vývoj. Nenormální by bylo nepřipustit si, že i změna od základu může být správnou volbou.
-
No, zrovna tady mi přijde druhá verze – s ohledem na technologie ke znovupoužití – jako jednodušší na implementaci než ta první…
Viděl bych to spíš tak, že si mysleli, že to zvládnou bez virtualizace a že ji považovali za zbytečnou překážku*. Tak implementovali pár kernelových volání, filesystém s jinou logikou apod. A ona spousta věcí začala fungovat.
Jenže to bylo málo, stále tam spousta věcí nefungovala. A kdyby tam nějak rozjeli Docker, mohla by to být spíše ostuda než vítězství – od Dockeru typicky čekáte, že všechno neběží nezávisle na prostředí, což by s WSL1 bylo jak kdy. Dockerová komunita by nejspíš nadávala na WSL 1, podobně jako kdysi webdevelopeři na IE. Docker na WSL 1 by byl poněkud podřadný. Z jistého pohledu Docker není první věc, co tam chcete rozjet. Je to spíše poslední věc, kterou můžete rozjet, až máte slušnou kompatibilitu na úrovni kernelu.
Jenže dodělání zbylých 20 % může být několikrát více práce než prvních 80 % funkcionality **. Nevím, kde přesně měli problém, ale představte si, že něco takového na Windows implementujete… Zlaté implementační chyby, ty prostě opravíte. Ale pak se vám tuhle jedna věc v /proc bude chovat mírně jinak, támhle jedna věc v /dev bude chovat jinak, a ne vždy bude oprava snadná – tady jsou věci blízké kernelu, který máte ale postavený místy úplně jinak. Anebo filesystém, který při pohledu z dálky dělá totéž, ale při pohledu z blízka má různé podstatné rozdíly – vizte třeba zamykání souborů na obou platformách nebo https://devblogs.microsoft.com/commandline/do-not-change-linux-files-using-windows-apps-and-tools/ . Opravit některé věci může znamenat dost překopat WSL. A když už to překopávali, evidentně se rozhodli opravdu zgruntu a nereimplementovat kolo.
*) Vyžaduje to AFAIK podporu VT-x nebo AMD-V a k tomu SLAT – to fyzický hardware asi dnes typicky má, ale problém může být uvnitř virtuálního stroje, protože vnořená virtualizace není samozřejmostí. Pokud si dobře vzpomínám, při zapnutém WSL2 jedou pod hypervizorem i samotné Windows, a vnořená virtualizace zde nefunguje. Takže jediná šance je snad využít backend z Hyper-V.
**) Nechci být dogmatický ohledně Paretova pravidla a osobně zde tipuju ještě větší (ne)poměr.
-
> protože vnořená virtualizace není samozřejmostí
Ano, dnes mi do VMWare přišla aktualizace, která by měla dovolovat běh pod Hyper-V, tedy současně s WSL2. Je samozřejmě otázka, jaké to bude mít na VMWare výkonnostní dopady.
Docker by měl na WIndows běžet, ale když jsem to zkoumal naposledy, měl řadu omezení.
Pro mě je zase v zásadě to, co implementuje WSL1 dostačující. Na nějaké to kompilování a pár skriptů není nějaká virtualizace potřeba. Takže bych byl rád, kdyby do budoucna zachovali i WSL1 (i třeba ve stavu, v jakém je teď).
-
Vzhledem k tomu, že aplikace běžící ve Wine byly pravděpodobně primárně určeny pro Windows, a teprve ve druhé řadě autoři možná někdy i řešili kompatibilitu s Wine, lze čekat, že aplikace pod Windows obvykle poběží lépe než ve Wine. Samozřejmě mohou existovat výjimky, hádám, že půjde spíše o staré aplikace netestované s aktuální verzí Windows…
-
Filip JirsákStříbrný podporovatelJe to normální vývoj. Pravděpodobně se ukázalo, že původní cesta je dál neprůchozí – je dobře, že to včas přepsali, než aby se snažili dál razit původní směr. Může to být chyba v původním rozhodnutí. Klidně se ale mohly překážky ukázat až později a objektivně nebylo možné je vidět hned na začátku. A také je klidně možné, že to na začátku měl být jen takový malý pokud, ale ukázalo se, že je o to větší zájem, že se s tím dají dělat věci, se kterými dříve nikdo nepočítal – až nakonec nezbylo než ten původní „prototyp“ zahodit a začít znovu a lépe.
-
Tenhle bug je oterveny uz hodne dlouho: https://github.com/microsoft/WSL/issues/3939
Ve WSL nefunguje mmap, tudiz nefunguje libdb4, tudiz nefunguje .rpm ani zadna .rpm based distribuce. (Krome SUSE ktery ma rpm nejako ohackovanty).
Jinak WSL s radosti pouzivam. Z WSL2 radost nemam Hyper-V mame v praci zakazany.
