Vlákno názorů ke zprávičce Rychlost WSL2 je podle nového testu dobrá od peci1 - A-ou... Pomale IO se mozna podarilo zrychlit, pokud...

A-ou... Pomale IO se mozna podarilo zrychlit, pokud se cte z nativniho filesystemu, ale pokud chcete cist z WSL nejakou Windowsi partition nebo z Windows tu "WSL partition", tak mate smulu... Podle reportu na githubu i hloupy git status muze trvat veky (nekdo hlasil pul dne, ale uz nevim, jak velky projekt mel).

Je něco takového častý use case? Účel WSL, jak ho vnímám já, není to, abych měl hromadu souborů, se kterými pracuju chvíli z Windows a chvíli z Linuxu. Vnímám WSL jako způsob, jak si z Windows spustit celý linuxový systém, aniž bych musel Windows vypínat – pak ale budu pracovat přímo v tom systému.

Vycetl jsem dva use-casy: programovani v IDE, ktere je lepsi poustet ve Windows (pres X forwarding by to asi slo taky, ale lidi to chteji takhle), a sdileni cache (treba maven cache muze byt docela velka a lidi ji nechteji mit na disku dvakrat). A pak taky rychle testovani kodu, jestli se zbuildi na win i linuxu - pak se hodi mit jeden adresar dostupny z obou systemu.

Zrovna Maven cache bych vůbec neřešil, disky jsou levné a pokud to chcete řešit, stačí občas promazat staré verze. To testování buildu je pochopitelnější, ale tak, jak chápu WSL, bych spíš přenesl celý nový kód před buildem. Navíc se mi nebudou míchat výsledky buildu z Windows a z Linuxu, naopak můžu využít nakešované výsledky předchozího běhu. Ale vlastně je to pořád to, co už jsem psal – chápu WSL jako rychlý způsob, jak přepínat mezi Windows a Linuxem, ne jako způsob, jak ve Windows spouštět linuxové aplikace.

Zrovna ta cache je na tenkém ledě. Fungovat to může, ale záleží na aplikaci. Na Windows a Linuxu máte různé modely oprávnění, různé přístup k case sensitivity, různé zamykání, různé timestampy, ... Rozbít se tu může ledacos.

BTW, u Gitu jsem viděl, co kombinace Windows a Linux zvládne. Stačí mít jinak nastavené řešení konců řádků (což je defaultní situace), pullnout na Windows a commitnout z Linuxu. S trochou nepozornosti commitnete změnu konců řádků.

Můj use case je používání základního software pro manipulaci s daty, pro který nejsou ve Windows adekvátní náhrady mimo různých pochybných freewarů nebo sharewarů, spouštění shell skriptů na datech z Windows šetří čas. Používám virtuální stroje, takže WSL 2 je pro mě nepoužitelné, i když Docker by se hodil, v současnosti to řeším docker-machine, ale výkon nic moc. Můj názor je, že lpění na Hyper-V je ze strany Microsoftu iracionální a neudržitelné.

"Používám virtuální stroje, takže WSL 2 je pro mě nepoužitelné"

No ja nevim. Mam spoustenej Debian ve WSL2 a KaliLinux ve Virtualboxu a oboje v pohode bezi...
Ostatne neni duvod aby to nebezelo. Virtualbox umi pouzivat Hyper-V hypervisor od verze 6.

No a ja v tom spoustim integracni python skripty, ktere se vyvijeji na windows a testuji se v linuxu, protoze vyuzivaji napr ansible.

WSL2 je fajn na Docker pretoze Docker pod Windows je dost pomaly hlavne kvoli zdielanemu filesystemu. Blbe je ze pod WSL2 vie pracovat iba VSCode (s pluginom) ktory bezi nativne vo WSL a len GUI ma vo Windows. Lepsie IDE na programovanie to nevedia a zas ich brzdi fileshare medzi WSL a Windows :-/