Názory k článku
Windows Subsystem for Linux 2 oficialně v rámci Windows 10 update 2004

Trochu me mate, ze nejprv Mikrosoft 3 roky vyviji WSL jako prekladac systemovych volani, aby to zmenil ve druhe verzi na virtualizaci.

To je normalni vyvoj? 3 roky jednim smerem, a pak cele predelat? Mi prijde ze to muselo dat spoustu prace, ktera se zahodila. Nebo to spatne chapu?

To vis v linuxu se sily tristi do mnoha slepych vetvi.
No zato corporace ma tu vyhodu ze hodi vsechny sily na jednu vec.

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

Otázka je, jestli jde o vnořenou virtualizaci, nebo o kombinaci frontendu VMware s backendem Hyper-V…

Možná Docker ve WSL1 nějak funguje, ale otázka je, komu se to takto chce používat.

Přirovnání WSL 1 k Wine celkem sedí. Něco to umí a na něco to lze použít. Ale nechtěl bych to používat intenzivně…

Podporu virtualizacie museli urobit tak ci tak (azure, virtualpc)
Tak na co robit veci dva krat ;-)

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

Mě na tom štve, že je potřeba store, který na firemních zařízeních nebývá. Ano jde to obejít, ale proč to nejde nějak snadněji bez store? Taky škoda, že to bez admina nejde aktivovat.

Když jsem si konečně po letech váhání rozběhl ten slavný wsl1, tak příjde nová verze a přestane z důvodu nutnosti spouštět kernel pod hyperV fungovat :(

Zatím to ale vypadá že celý problém půjde jednoduše vyřešit jediným příkazem:

rm -rf /home/vitex/Vir­tualBox\ VMs/Windows\ 10/

Ehm, v clanku,na ktery reagujes, je navod.

Wsl1 nadale zustava, wsl2 update je nepovinny, pokud se updatuje,l na wsl2, stavajici instalace se zkonvertuji jednim prikazem.

Umeni cteni se stava vzacnym

a cetl jsi ty na co reagujes? on ma ve VirtualBoxu virtualizovane W10 v kterych pouziva WSL1, ses si jistej ze bude virtualizovane WSL2 fungovat ve virtualizovanejch W10? ;-)

Je na tom dobře funkční SSHFS?

SSHFS má na Windows i nativní port, který funguje ne nějak totálně bezproblémově, ale dostatečně dobře aby to v mém testování nepadalo. Spíš jsou tam nějaké chyby ve funkcionalitě a interpretaci cest atd., když ale spojení správně / tam, kam chcete navážete, tak by mělo držet. https://github.com/billziss-gh/sshfs-win
Technologicky se zdá, že to má poměrně vysokou úroveň a jako projekt je to vedené jistě někým, kdo ví, jak se profesionální a robustní software pro Windows píše.

Takze po vikendu testovani WSL2 to zase letelo ven.

Ma to BRUTALNI dopad na vykon VMware images.

Pouzivam na W10 dalsi W10 VMware image, ve kterem mam naisntalovane vselisjake potrhle VPNky k zakaznikum, kteryma si nechcu zasirat OS na baremetal.

No a po rozjeti WSL2 byl nejprve nutny update na player 15.5 aby to vubec jelo.
Vlastni beh W10 pod VMware ale brutalne zpomaleny, klepnuti na tlacitko start, system 2 sec premysli pak ukaze menu.

Takze to letelo zase ven, downgrade na WSL1 a W10 image zase jede jak z praku

ehm, takze diky za potvrzeni ;-)