Názory k článku
Windows 10 aktualizují linuxové jádro pro WSL2 pomocí Windows Update

btw: nepouzivate nekdo v W10 reseni pro auto vyhledani&instalaci (windows) aktualizaci skriptovatelne? s W7 sem pouzival nejakej skript z MSDN(?), v W10 nechodi ani nejake jine co sem zkousel ale pak uz to neresil, tak jestli mate nekdo neco overene ;-) treba MS nekdy napadne dodelat: wu update && wu upgrade -y (kdyz uz se z GNU/Linuxu zacal ucit :)

Jsou na to PS příkazy.
Ale proč to, když se to dá ovládat nejvhodněji přes GPO?

ses si jistej ze prikazy? nebo powershell skripty? a mas to overene v praxi nebo jen teorie?

protoze GPO v dane situaci neni resenim.

Ahoj.

Ide to cez powershell.

Napr:
https://www.powershellgallery.com/packages/PSWindowsUpdate/2.1.1.2

v W10 wuauclt nefunguje, ale na tvem linku sem zahledl odkaz:
https://www.bobr.pw/en/it/windows/how-to-run-windows-10-update-from-the-command-line

kde je popis nastroje UsoClient, i kdyz ten popis neni asi uplne presne, tady je popsano lepe: https://www.urtech.ca/2018/11/usoclient-documentation-switches/

neni to idealni, nevim zda to bude fungovat, ale diky za nasmerovani, zkusim, hloupe je ze ten nastroj neda vedet co a zda dela, rovnou hodi prompt, takze na tom linku doporucuje pak pockat 40minut a doufat ze se to stacilo stahnout&nain­stalovat, asi je to MS tajnej nastroj ze nemuzou pridat verbose a vratit prompt az teprve akce dojede :-)

takze z pokusu, chova se to divne, parametr StartScan funguje ok, vyhleda aktualizace (nic nezobrazi, status lze sledovat v rucne pustenem GUI WindowsUpdate)... StartDownload nedela nic, StartInstall nedela nic, pro stazeni&install vypada ze zabere StartInteracti­veScan (ktere ackoliv nazev, nevypada interaktivne)... StartReboot nic nedela...

v prubehu stahovani&instlace se pusti proces wuauclt a po dokonceni a cekani na restart process po chvili zmizi, takze podle nej lze detekovat ze jakmile zmizi, tak to dojelo...

jinak opravdu je to trapne tajnej nastroj Microsoftu, neni k nemu zadna dokumentace, na technetu moderator napsal neco ve smyslu ze ten nastroj nema pouzivat nikdo mimo zamestnance MS (pokud sem pochopil "internal OS") , takze to rozhodne ma VELMI daleko k normalu (command line aktualizece) v GNU/Linuxu :-))

jste k tomu prvnimu *urtech* linku, 3rd nastroj SHUTDOWNWITHUPDATES neni potreba, pro finishupdate&res­tart staci nativni "shutdown -r -f -t 30"

ja nerozumiem dôvody prečo sú toľký ľudia "PAF" z tohoto WSL2... ako jo pre developerov a testerov pre testovanie softwaru ktorý vyvíjajú sa to zdá ako skvelá vec, ale celkovo bych z toho zas tak nejásal,... nie len že mnoho vecí tam stále nefunguje tak ako v reálnom Linuxe, a teda ani ten testing nie je úplne taký aký by mal byť, ale mimo testovania je to v podstate výrazne obmedzujúce a zbytočné, nemá to využitie... ako niektoré Linuxové aplikácie tam spustíte, nejaké ale zas nie. Výkonovo to voči virtuálke zas tak veľký rozdiel nie je... je to trocha rýchlejšie, ale nie o toľko aby sa to oplatilo. S WSL či WSL2 sú problémy, ktoré v reálnom Linuxe nie sú. Príkladom je aj to ako do teraz bolo potrebné riešiť aktualizáciu jadra. Myslím že fakt z toho byť PAF nie je dôvod.

Jsem si pomerne jist tim, ze existuje cela rada dobrych duvodu proc MS tlaci WSL do W10. Netusim jake jsou, nejake si sice umim predstavit, ale je to cista fantazie. WSL musi stat kopu penez, za tim musi byt hodne promysleny plan (ktery ale nemusi vyjit).

Microsoftu do hlavy nevidím, ale podle mě je ten plán velmi jednoduchý a není na něm nic zákeřného. Jde o cloudové aplikace. Microsoft dobře ví, že platformám jako je .NET fugujících na proprietárním Windows Server pomalu ale jistě odeznívá. Dneska jedou čistě cloudové systémy vyvíjené v Pythonu, Go, Rustu apod., které se z mnoha různých důvodů (dobrých či špatných) v praxi nasazují na Linuxové instance, a to včetně v Microsoftím vlastním Azuru. Microsoft chce vyjít vstříc vývojářům takových aplikací a nechat je kodit na Windows pomocí Microsoftských nástrojů jako VSCode, a přitom jim umožnit ladit a testovat přímo v Linuxovém prostředí pomocí WSL. Jistě si dobře uvědomují, že pokud to neudělají, nejpravděpodobnější výsledek bude, že tito vývojáři budou na laptopech a desktopech používat Linux a to tím spíš, že např právě zmíněný, oblíbený a objektivně vynikající VSode na Linuxu funguje nativně. K tomu MS pochopitelně nikoho nechce nabádat.

prave naopak, toto je jeden z hlavnich duvodu.

Nechci být hnusný i když to možná tak vyzní. Nikdo z toho PAF není. Skalní uživatelé Windows to mají na háku, a stejně tak bych to tipl u skalních userů Linuxu. A ten zbytek jsou jenom tupé ovce co se nechají ovlivňovat PR, reklamními kampaňmi, články a pohádkami o tom jak Microsoft miluje OpenSource. Za pár let (2-5)let se tam pak sejde management a vyhodnotí účinnost kampaně jestli se jim podařilo zaháčkovat dostatečné množství lidí či ne, a buď tam ta funkce zůstane nebo ji hodí přes palubu.

Skalní uživatelé Windows to mají na háku, a stejně tak bych to tipl u skalních userů Linuxu. A ten zbytek jsou jenom tupé ovce co se nechají ovlivňovat PR

Jsem přesvědčený, že existuje víc typů lidí, než skalní uživatelé <něčeho> a tupé ovce. Dokonce být skalním fanouškem <čehokoliv> se někdy považuje za tupost.

ano, byt skalnim fanouskem Windows se povazuje za tupost skoro vzdy ;-)

Souhlasím s názorem, že být skalním a nekritickým fanouškem čehokoli je projev tuposti: Windows, Linuxu nebo čokoládové bábovky.

jj, a byt skalnym fanusikom Linuxu na desktope nie je tupost, ale uchylka

Díky WSL jsem konečně mohl doma opustit linux a přejít na windows. Dual boot je k ničemu, to už mi přišli lepší dva samostatný stroje a normální virtualizace je zbytečná práce navíc, když se člověk musí starat o dva různý systémy. WSL nabízí provázanost s windows, které se jinak dosáhnout nedá.

Sice tomu ještě pár věcí chybí, ale není to nic závažného. Pokud ještě vychytaj těch pár much, tak přejdu na windows i na pracovním stroji, kde mám momentálně ubuntu.

a co je dnes ten hodne silny hw? :) Respektive co je ten slaby? A jak pc pouzivate? Jestli mam hw, na kterem nebezi pouzitelne win10, neumim si predstavit jak bych na takovem zeleze mohl seriozne jakkoliv pracovat na linux. Nedej boze si pustit obcas i nejakou hru. Ale na ssh konzoli na server to asi staci.

Obcas se hrabu v nejakych Python scriptech. Bud to pisu primo na Linuxu v Emacsu anebo pouzivam PyCharm na windows. Zadna raketova veda to neni. Diky WSL si spustim bash, rpmbuild a vytvorim si balik primo na desktopu.

Nemusim se hlasit na jump host, a z nej pak na server, resit git push/pull a ani nemusim resit jak budu zase nazpatek kopirovat .rpm pres nekolik jump hostu.

WSL je rychlejsi nez Cygwin. A diky WSL muzu obejit vsechny prekazky, ktere vytvari nasi Linuxari a security.

Můžu se zeptat, proč nepoužíváte možnost ProxyJump ssh -J <první-jump>,<druhý-jump> <uživatel>@<host> ?

Zrovna když jsou věci propojené aspoň pomocí SSH, tak už se s tím dá poměrně slušně pracovat. Nějaké triky, které by se Vám mohly hodit jsem zadokumentoval v této veřejné orgpage i se screenshoty. Je tam docela velký fokus i na Windows, to by se Vám mohlo hodit:
https://www.orgpad.com/o/16854483-ee58-408d-80b4-b30fbd95c0dd

Dik za tip ale bohuzel to pouzit nemuzu. Z jump hostu se nehlasim pres ssh, ale jinym programem - takze tohle pouzit nemuzu. Navic ten jump host casto pridava dost neprijemne latence. Hyper-V/VirtualBox/Docker je taky zakazany. Primy pristup na servery je zakazany. Forwardovani klicu/portu je taky zakazany.

IMHO - schopnost prezit v korporatnim prostredi by se melo vyucovat na VS jako soft-skill. Aby absolveti nebyli prekvapeni, kdyz se stretnou s realitou.

Pro to co obcas praci programuju(jako admin): precist neco z DB a zavolat REST API (anebo obracene), preparsovat nejaky konfigurak a udelat v nem zmeny, vytahnout data z DB a vytvorit .xls ... Tak proto plati i v Pythonu "write once run everywhere". A kombinace PyCharm+WSL mi umoznuje normalne fungovat aniz by mi nekdo hazel klacky pod nohy.

Smiem vediet v akej oblasti pracujete? Lebo ak ste programator a potrebujete si nieco otestovat, tak je urcite lepsie si nahrat do virtualu linux s tou istou verziou jadra + distribuciou, na ktoru nasadzujete. Vsetko ostatne moze viest k problemom pri nasadeni pre zle otestovanie. A ak ste programator, a potrebujete testovat na WSL, tak mi z toho vychadza, ze nasadzujete na WSL pod windowsom. Je to tak? Ale po spoznani par 'programatorov' som rad ze su aj taky, co maju aspon snahu testovat pod systemom s rovnakym menom :) Kazdopade zasa pre programatora napr. webovych aplikacii nevidim jediny dovod ist na windows. Pre programatora pocitacovych hier nevidim dovod, naco by potrebovali WSL. Mozno ak robia nejaky multiplayer a ich server bezi na linuxe, ale opat by som to netestoval na WSL ale radsej na virtuale. Celkovo vobec nechapem zmysel takehoto riesenia. Alebo sa microsoft nasral, ze existuje wine na linuxe, a spravil si linux vo windowse? :D Za mna jediny dovod, pre ktory to robia je, ze postupne jadro windowsu prepnu na linuxove a hotovo.

Programátor fakt nejsem. Dělám sysadmina, takže na 80% práce mi stačí kvalitní terminál (přes WSL spouštím terminator) a ssh / git / ansible, zbytek udělám ve webovém prohlížeči. Bash i python v tom fungují normálně jako na jakémkoliv jiném linuxu, takže mě to nijak neomezuje. Kdybych musel řešit sítě, tak by mi na to WSL nestačilo, ale na to jsou ve firmě jiní.

Tak né že bych z toho byl zrovna paf, ale možnost pohodlně spustit rsync mě potěšila.

Behove prostredi pro docker, pod windows. To je imho padny use case pro vyvojare. Vykon bude vyssi nez u reseni s "plnokrevnou" vm. Mj start je velmi rychly. Prakticky hned po nalogovani do windows (dobre 2, 3 sekundy trva nez vyskoci notifikace docker is running) otevru konzoli a jedu docker-compose, jako bych to udelal pod linuxem.

Imho nejsou uplne cilova skupina lidi co chteji pod windows vyvijet veci pro linux, ale jak uz nekdo zminoval, spis lidi co vyvijeji servisy treba v jave, pythonu, go apod. budou je provozovat na dockeru a z nejakeho duvodu chteji/museji zustat na tech windows.

Muj pripad. Na pracovnim desktopu jsem vyzkousel ruzny setup. Nativne windows s docker toolboxem. Funguje spolehlive ale docker je pomaly, overhead s virtualni masinou. Pak Nativne linux s windows virtualkou (proc windows - protoze skype, korporatni vpn, visio a podobne obstakly). Taky to nebylo idealni. Vratil jsem se k windows. Ted si hraju prave s wls2...

Já jsem z dockeru pro Windows celkem překvapený jak to funguje, ale rozhodně bych netvrdil, že to naběhne hned po startu. Trvá to snad věčnost. Nejvíc vtipné je že na firemním notebooku ten WSL nenainstaluju protože nemám admina takže smolik

A bavíme se opravdu o WSL2?

Na pc čistá instalace windows insider build 2004, docker edge 2.3.0.1 se zapnutou integrací WSL2. Hardware je i7 8700, 32 GB RAM, Samsung SSD 860EVO. S dockerem můžu pracovat skutečně malou chvíli po nabootování.

Na druhém stroji mám odladěné řešení s Docker Toolbox pod windows ("stabilní" verze všeho), které používá Virtualbox vm, na které běží celý docker. Funguje to spolehlivě, ale v té virtualizaci se ztrácí dost výkonu a desítky sekund čekám na boot vm.

To si třeba nemyslím. Ten, kdo je na Windows a chce se rozkoukat v příkazové řádce, tak nevolí Cygwin, ale začne se učit PowerShell. A přiznejme si, že PowerShell je o několik dekád modernější a mocnější nástroj, než jakýkoliv shell v Linuxu.

Není tak docela pravda, že by byl modernější než jakýkoli shell v Linuxu, např. PowerShell v Linuxu :) Ale vážně, v principu máte pravdu, jenom já bych šel ještě dál a řekl bych, že shell (jakýkoli) jako takový je katastrofa a anachronismus z hlediska bezpečnosti, udržovatelnosti, výkonu, uživatelské přívětivosti atd. U moderního OS má být primární formou interakce se systémem API, ne příkazy nebo nedej bože parsování textu, a tato API by se měla ovládat nějakým jednoduchým ale nedementním jazykem stylu Ruby, Python apod. Konkrétně v Linuxu by roli "shellu" (pokud se to tak dá nazvat) měl plnit dbus, a bash, zsh a jakýkoli jiný **sh by měl konečně patřit na smetiště.

"jiste"... kilometry PowerShell skriptu nahradi genialne pouziti nekolika GNU/NonGNU nastroju v GNU/Linuxu... aneb sila shellu v GNU/Linuxu je prave to ohromne mnozstvi dostupnych nastroju pro skoro cokoliv ktere se shell skriptem (vicemene) "poslepuji" dohromady...

BTW: jake ze "Jsou na to PS příkazy." na aktualizaci Windows?

v GNU/Linux v shellu pouziju snadno:
apt update -qq && apt upgrade -y && apt full-upgrade -y && apt --purge autoremove -y && apt clean
ktere provede:
1. vyhledani aktualizaci
2. provedeni "zakladni" stazeni a instalace aktualizaci
3. provedeni "rozsirene" stazeni a instlace aktualizaci
4. odinstalovani osirelejch balicku
5. smazani stazenych balicku z cache

@k3dAR

aneb sila shellu v GNU/Linuxu je prave to ohromne mnozstvi dostupnych nastroju pro skoro cokoliv ktere se shell skriptem (vicemene) "poslepuji" dohromady

Toto byla síla před čtyřiceti, třiceti, dvaceti roky a vůbec se netýká GNU a Linuxu, ty to jen převzaly. Dodnes je to šikovné, ale už jsou daleko pohodlnější a bezpečnější instrumentace. Pajpování textového výstupu je závislé na locales a na tom, že program v pajpě nezmění svůj výstup. Tento požadavek zase omezuje autory, aby šli dopředu. Autoři musejí udržovat výstup stejně pitomý, jako před lety a autoři alternativ často své výstupy doplňují o kompatibilní s nějakým starším nástrojem. Když chcete současně pracovat se stdout i stderr, tak je to na mašli. Nemluvě o tom, že není pevná konvence, co jde do stdout a do stderr (např. rozlišení chyb běhu samotného programu vs. chyby při zpracování dat). Je to prostě uhozené, PS vs. *sh je jako nebe a dudy. Jistě, naučit se PS je opravdu náročnější a nenajdete na to milion "kuchařek" jako pro unix(-like) systémy (a co člověk dnes najde na internetu za rady, jeden by plakal).

apt update -qq && apt upgrade -y && apt full-upgrade -y && apt --purge autoremove -y && apt clean

Když považujete za "výhodu" takovou chujovinu scriptovat. Mně přijde jednodušší, když se o to OS postará sám a já mu jen nastavím pravidla pomocí GPO (a to jedině, když cítím potřebu něco změnit).

sila vyuziti nastroju v shell scriptu je to i dnes a bude i zitra, tvuj ms-fan anti-postoj to rozhodne nezmeni ;-) na locale to nezalezi jendoduse:
LANG=C program | grep 'po celem svete stejnej vystup'

ale chapu ze tedy obhajujes ty kilometrove PS skripty i na malickosti ;-)

> Když považujete za "výhodu" takovou chujovinu scriptovat.
> Mně přijde jednodušší, když se o to OS postará sám
> a já mu jen nastavím pravidla pomocí GPO
> (a to jedině, když cítím potřebu něco změnit)

to je reseni pro tve omezene potreby, pro me GPO neni resenim, takze znovu, psal si ze na aktualizaci jsou "PS prikazy" je to tajne dostupne jen zamestnancum Microsoftu, ze nenapises jake? ;-)

pokud myslis tohle: http://woshub.com/pswindowsupdate-module/
tak to vyzaduje doinstalovani modulu, neni to v W10 out-of-box, je tedy neco tajneho jineho?

Souhlas. Trvání na tom, že shell, který neumí nic jiného, než (blbě) parsovat řádky ASCII textu bez jakéhokoli typování, formátování nebo kontroly chyb je jednou pro vždy nejlepší a že jakýkoli problém se nejlépe řeší pomocí sed/awk/grep je právě to skalní fanouškovství, o kterém tady byla řeč...

"Mně přijde jednodušší, když se o to OS postará sám a já mu jen nastavím pravidla pomocí GPO (a to jedině, když cítím potřebu něco změnit)."

Problém je, že ten systém toho dělá sám až příliš, a zřejmě to nelze za 100% ovlivnit a to ani přes GPO (typicky vynucování aktualizací, a zvláště vynucování aktualizací ovadačů). Nastavit to sice jde, ale v některých případech to systém ignoruje....
To je fatální problém.Je nepřijatelné, aby si to žilo svým životem.

Dost jsem se PowerShellem zabýval a opravdu jsem tím chtěl řešit reálné a palčivé problémy, ale v době, kdy jsem to potřeboval především (2015) byla situace kolem PowerShellu tristní a úkoly (v tomto případě audit oprávnění k souborům a mapping AD uživatelů na AD skupiny a diff mezi tím v čase) jsem jím nemohl _efektivně_ řešit. V shellu/ s typicky *nixovými nástroji je tohle otázka na jeden screen full, v Pythonu možná na víc, ale pořád neporovnatelně přirozenější a konzistentnější, než možná řešení v PowerShellu (tuším sotva 3.0) té doby.

Ano, ten jazyk je skoro i elegantní a mocný, dejme tomu srovnatelný s Pythonem. Jenže v Pythonu apod. máte spoustu užitečných nástrojů/ modulů už nainstalovaných a většina funguje multiplatformě. U PowerShellu tohle teprve teď začíná náznakem nějak existovat. Hodně taky pomohlo, že má Windows aspoň možnost mít pořádný SSH klient a server. Některé věci se tím holt řeší jednodušeji.

V reálu ale PowerShell na jednořádkové příkazy moc používat nejde, to by si člověk dřív zničil ruce psaním. Spousta věcí s tím stále ještě není opravdu dobře integrovaná (právě třeba ten Windows Update) a na spoustě místech jsou nedodělky v ekosystému, které zbytečně věci zesložiťují. Věci, na které je v každé instalaci Pythonu minimálně deset let nějaký modul a pro užitek často stačí jeden řádek (třeba SimpleHTTPServer), tak tohle v PowerShellu ani dnes není a hackuje se to nějak přes C#, což zbytečně do celé věci zanáší složitost. Další věc je kultura, pod Windows je rozšířená kultura všechno naklikat nebo si někde zařídit nějakou centrální instanci s (ideálně dodatečně licencovaným) systémem, který mi zase zprostředkuje GUI. Pod Linuxem se v reálu skriptuje běžně a funguje to obyčejně od jednotek systémů (což se hodí na web serveru nějakého malého podniku) i do tisíců a víc. GPO pro tři počítače doma asi nastavovat nebudu. Další věc je, že Windows 10 Home ale i Pro nemůžu skutečně spravovat, ale jen usměrňovat. Opravdovou kontrolu např. nad telemetrií, reklamou, aplikacemi, restartem po aktualizaci apod. nemám - klidně mě opravte, pokud nemám pravdu.

Ano, běžná Linuxová distribuce taky není svatý grál konzistentního návrhu, protože žádný takový návrh není a v podstatě ani u _distribuce_ čehokoliv nemůže být. Ve Windows by jednotný, konzistentní záměr patrný být mohl, ale není. Přístupů je tam minimálně stejně tolik jako na Linuxu, ale na Linuxu si můžete přečíst ke všemu zdrojový kód, v posledních letech pomocí BPF (ftrace/ perf/ bcc/ bpftrace apod.) ověřit, že to i za běhu skutečně tak funguje a pokud ne, tak cokoliv změnit k obrazu svému nebo někoho zaplatit, aby to udělal.

Já "Linux" v podobě neplacených distribucí považuju spíš za jakýsi framework s referenční implementací (něco jako Ikea flatpack nábytek) než nějaký hotový produkt - počítám s tím, že nějakou práci evtl. budu muset investovat i když dosud to bylo spíše méně práce než údržba Windows předtím. RHEL a SLES apod. tam zase čekám, že když s něčím nemůžu pohnout, tak napíšu na support a tak do dne mám u většiny věcí aspoň návrh nějakého rozumného řešení problému. U Windows jsem se s tímto nesetkal, asi dělám něco špatně.

V neposlední řadě je momentálně pocitově víc vývoje kolem Linuxu, než kolem Windows. Možná žiju v bublině. I když se Microsoft dost snaží do Windows různě investovat, musí zohledňovat ekosystém kolem Linuxu - bariéry přechodu se obousměrně během posledních let zásadně snížily, takže je možné použít na problém správný nástroj a nemuset se rozhodnout předem a potom dělat všechno jedním nástrojem. Někdy je správné/ relativně lehké řešení zavést v kanceláři Active Directory a Windows stanice. Někdy je lepší nasadit web na Linuxu + Apache/ nginx a do výuky ve škole např. Chromebooky.

To právě není příklad žádné "síly". APT je jistě dobrý nástroj, jenže je napsaný v C a na hony vzdálený oné pověstné "filozofii". Automatizaci volání podobných nástrojů zvládne každý vysokoúrovňový skriptový jazyk, a při troše štěstí umožní doopravdy odchytávat chyby, předávat data mezi jednotlivými kroky jako strukturované, typované objekty s přístupem zero-copy (a ne jenom jako oktety zkrz roury) a bez rovnáků na ohejbáky na rovnáky na ohejbáky na odfiltrování separátorů a znaků, jako ', ", ; a jiných. PowerShell je krok správným směrem, ale na to , co umí, mi připadá zbytečně složitý a překombinovaný.

PowerShell je krok správným směrem, ale na to , co umí, mi připadá zbytečně složitý a překombinovaný.

S tím bych dokázal souhlasit, ale nejsem v PS tak zkušený, abych posoudil, jestli je ta překombinovanost účelná. Pro k3dARa to bude asi těžko k uvěření, ale daleko víc znám i používám bash (i tcsh), přesto vím, že líp a bezpečněji a s větším potenciálem se mi pracuje s PowerShellem. Netrnu u něj hrůzou, co nepředpokládaného se mi v rouře objeví a nedokážu odchytit.

hlavni problem awk a podobnych nastroju v Linuxu je, ze neexistuje standardizovany zpusob pojmenovani sloupcu v lozich. Pracuje se s indexy sloupcu, coz je dost primitivni.

14. 6. 2020, 12:49 editováno autorem komentáře

Jo, myslite mnohdy natvrdo nastaveny pocet znaku na sloupec?

Dyt je to jasny. I stim directx. M$ se nemuze vyplatit dal delat vlastni kernel. A Windows 11 budou gui na linuxovym kernelu. hotvson.

Dokud se to bude WSL2 tykat pouze insider releasu, tak to nema valny vyznam, protoze tyhle releasy nejsou pro skutecne uzivatele Windows zajimave.

Chapu, ze je potreba nejprve vychytat mouchy, nez se to pusti do mezi normalni lidi, ale na hrani si v Insider releasech fakt nemam cas... Takze az to bude k dispozici pro bezneho uzivatele Winodws, tak mne to zacne zajimat.

JInak ale WSL2 vypada opravdu pouzitelne ... o tom zadna!!!

uz to je v public. a backportovano tusim od server 2016

Je a není ... aktualizace 2004 obsahuje WSL2, ale aktualizace na tuto verzi byly pozastaveny. Já stihl aktualizovat notebook i pracovní stanici než to pozastavili, žádný problém nemám, WSL2 funguje fajn. Pokud se k WSL2 chce někdo nyní dostat, tak aktualizace na 2004 neni úplně přímočará a musí se člověk poměrně dost snažit. Takže to public sice je, ale ... :-)

O backportu do Windows serveru 2016 ani 2019 jsem nic nenašel, máte k tomu nějaký zdroj ? Pokud vím tam podpora je pouze v non-LTS verzi Windows Serveru ve verzi 2004.

Vážně?
Když chci stáhnout instalačku, nabídne mi to (pouze) MediaCreation­Tool2004.exe
Takže instalační médium si teď už jiné nevytvoříte, pokud nejdete do nějakých archívů.
Ruční update tedy může udělat kdokoliv. Automatické updaty jsou jiná kategorie, tam to nikdy není pro všechny najednou.

Však jsem napsal, že to aktualizovat lze, ale není to úplně přímočaré, protože přes klasické aktualizace je to nyní pozastavené. Bylo mém sdělení něco nesrozumitelného, že jste napsal to samé jinými slovy jako protiargument ?

tak mozna musim to 2016 vzit zpet. to co tam mame (ja t o sleduju jen z vrtuliku) je wsl1. 2019 je ale uz wsl2