Munkám során a Windows Subsystem for Linux-ot ...

Linux

Lassan egy évtizede velünk van a Windows Subsystem for Linux (WSL). De ki használja élesben, termelésre?

( carlcolt | 2025. 05. 20., k – 10:44 )

Nem hasznalunk Windows-t, csak neha tesztelni virtualizalva.

( nagyjoco | 2025. 05. 20., k – 11:10 )

Munkában nem használom Otthon eljátszottam vele, jó játék volt.

( dirtydriver | 2025. 05. 20., k – 11:12 )

én használom de csak shadyben mert offical nem lehet :S devops meló van pár docker image fejlesztés de úgy kell megoldani, hogy dockert nem használhatsz localban, így marad a shady wsl meg a podman :D

( hunluki | 2025. 05. 20., k – 11:14 )

Amíg windows volt a céges gépen addig használtam de annak már sokadik éve.

( locsemege v | 2025. 05. 20., k – 11:31 )

Nem használom. Inkább letettem az asztalomra a céges windowsos gép mellé a natív linuxos gépemet. Így már a windows-os gépet is alig használom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( KoGa v | 2025. 05. 20., k – 12:10 )

Szerkesztve: 2025. 05. 20., k – 12:10

Kb. meg is halnék nélküle, a lehető leghasznosabb tool :) Persze ki lehetne váltani cloud shellel, vagy VM-el, de gam-ot, aws cli-t, meg python scripteket futtatgatni így a legegyszerűbb.

( K3cs1 | 2025. 05. 20., k – 12:10 )

[x] Használtam, amíg az előző projekten voltam.

Corporate, Win 10-es virtuális gépen Docker futtatása miatt: WSL2 Debiannal. Docker Desktop használta tiltott volt.

( zsirmo v | 2025. 05. 20., k – 12:13 )

en MAC-en vagyok, kollega hasznalja windowson, szokott is szopni vele, random hibak, nincs halozat, multkor valami perl modullal szopott

( doszy | 2025. 05. 20., k – 12:18 )

Használom, imádom. A multis környezethez ott a Windows, közben meg a WSL + VS Code kombóval marha jól lehet dolgozni.

( hunludvig v | 2025. 05. 20., k – 12:43 )

Define "termelésre". A prod rendszereink mind Linux-on futnak, de az anyacég szabályzata szerint csak Windows-t használhatunk Desktop-on. Nem mindenki használja, de ezzel le lehet vágni a build time-ot 20 percről 8-ra.

Nem az én asztalom. Nem hiszem, hogy az ügyfeleink tételesen fizetnének, ahol az egyik tétel a "hunludvig 8 órát optimalizálta X riportot, hogy 20ns-mal gyorsabban fusson" lenne. Megbízom a cégem embereiben, hogy amíg kapok fizetést addig a cég többet nyer a munkámon.

Szerintem egyáltalán nem volt kötekedő. A termelésre szó a production visszamagyarításának hangzik, ami alatt -- főleg, hogy neked alapvetően üzemeltetési / integrációs háttered van -- általában a szolgáltatásban közvetlenül részt vevő rendszereket szoktuk érteni. Én nem is nagyon hallottam ezt így magyarul, illetve ahol meg igen, leginkább ipari környezetben, ott kifejezetten a gyártósor és környékén üzemelő rendszereket értik alatta. Szerintem teljesen jogos kérdés, hogy a fejlesztő desktopját beleértjük-e, mert egyébként meg a "munkám soránból..." meg nyilván az következik, hogy igen. Lehet, hogy megint te vagy az egyedüli nem autista, de hogy miért lenne ez egy nyilvánvaló kötekedés, azt nem látom.

nincs semmi seggfajas. epp ma fejeztem be egy nagyobb projectet, pedig ho-ban keszult.

_mi_ elvezzuk a ho adta elonyoket, ertem hogy ez neked hianyzik, de hat ez van! :DDD

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nálunk a build rengeteg apró fájl keletkezésével jár, a Defender policy-ből konfigurálódik az anyavállalatnál így nem tudjuk beállítani, hogy ne nyálazza át ezeket a fájlokat. De ha beviszed a teljes fejlesztői környezetet WSL2 alá, akkor közel natív sebességet el lehet érni. IntelliJ és más JetBrains IDE-k szépen integrálodnak WSL2-vel. Win11 DevFS lenne hivatott segíteni ezen, de még nem láttam jól működni.

( Dolphy | 2025. 05. 20., k – 18:38 )

Elozo cegnel desktop-on Windows volt kotelezo. Kollega azzal kezdte, hogy tett ra egy VMWare-t benne Fedoraval. Ez annal eggyel jobb vagy gyorsabb?

És ez WSL2? Mert WSL1 az ilyen nálam is, meg mindenki másnál is. A WSL2 meg tetű:

$ dd if=/dev/zero of=testfile count=50 ibs=1M
50+0 records in
102400+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 18.5575 s, 2.8 MB/s

Szóval futtasd már le kérlek ezt úgy, hogy az /mnt/c/... bárhova írsz WSL2 alól. És viszont és akár WSL2 - WSL2 között.

https://iotguru.cloud

És mi a dd parancs eredménye nálad? Mert ha az 400 MBps, akkor írd meg a linkelt ticket-re, hogy zárható, de n+1 Microsoft mérnök esküdözik ott évek óta, hogy ez túl komplex és nem oldható meg, Windows kernel szintű problémák miatt, amelyek miatt a WSL2 I/O ótvar szar marad.

https://iotguru.cloud

Note:  To optimize for the fastest performance speed, store your project files in the Linux file system (i.e. \\wsl$\Ubuntu-18.04\home\<user name>\Project), not the Windows file system (i.e. C:\Users\<user name>\Project). If your files currently reside on Windows, we recommend copying them to the Linux file system. See the WSL documentation for more information about working with files.

meg wiki is van rola, szoval nem ertem a banatodat... https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.re…

mas helyeken erre annyit szokas mondani, h rosszul fogod :D
mint mondtam, windo'zintezobol masolgass ki-be, akkor nem lesz lassu...

mas helyeken erre annyit szokas mondani, h rosszul fogod :D

Ezzel továbbra is csak igazoltad, amit írtam, nem értem, mit rugózol, amikor mérhetően szarabb a WSL2 I/O, mint bármilyen más virtualizáció ugyanazon a gépen. Még az is sokkal gyorsabb, ha WSL1-ben NFS szervert konfigurálok fel, amit aztán WSL2-ben felcsatolok és azon keresztül írok az NTFS-re. Egyszerűen el van baszva a gyökerénél a WSL2 és annyira át kellene írni, hogy 6 éve nem írták át.

Ez nem a rosszul tartás esete, hanem egyszerűen szar, amire van n+1 workaround, amivel különböző használati esetekre van kevéssé szar megoldás, de attól még szar marad. Ha pedig WSL2 - WSL2 kommunikáció kell, az még szarabb, és még mindig létezik az a bug, ami miatt bekapcsolt Hyper-V feature mellett nincs rendes network WSL2-ben.

mint mondtam, windo'zintezobol masolgass ki-be, akkor nem lesz lassu...

Ezt a windo'zintezo-t tudom futtatni WSL2-ben script-ből meghívva? Tudod, vannak olyan esetek, amikor WSL2-ből kell kifelé másolni vagy onnan vissza, ráadásul nem manuálisan, hanem programmatically, mondjuk scriptet futtatva. Vagy több WSL2 instance fut, amelyek közös fájlrendszert szeretnének használni. Vagy a build egy része WSL2-ben futna, másik része Windows alatt, de a franc se akar szinkronban tartani két külön fájlrendszeren mindent is.

Röviden: objektíven mérhetően szarabb, mint más virtualizáció. És ezt nem tudod cáfolni, csak nyomod a bullshit-et.

https://iotguru.cloud

Ezt a windo'zintezo-t tudom futtatni WSL2-ben script-ből meghívva? > hat persze, bar en inkabb hivom meg a cp-t :)

dorsy@wsl64:~$ powershell.exe -Command cp D:\asdf/Windows.iso  '\\wsl$\Ubuntu\home\dorsy\'
dorsy@wsl64:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.2 LTS
Release:        24.04
Codename:       noble

worksforme, 400MB/s+ wsl2-bol. :)

mondom, rosszul fogod...

Kezdesz olyan lenni, mint a 2000-es évek elején a BIOS-sámán, aki úgy kompletten nem értette meg az Y2K problémát, de megoldotta.

Itt ismét nem kifelé kommunikálsz a Windows fájlrendszerrel vagy másik WSL2 fájlrendszerrel egy WSL-ben futó process-ből, hanem egy WSL-en kívül futó process másol bele a vhdx fájlba, amiről már írtam sokadszorra, hogy az megy. A leírt példádban nem az történik, hogy a Linux futtatja a PowerShell-t, hanem indul a PowerShell background process a Windows oldalon és egy I/O proxy-n át megy a WSL2 konzol és a Windows oldal között. Szóval ez pont nem azt csinálja, amit gondolsz és nem az történik, amit írtam.

Nem rosszul fogom, hanem te használod ki a WSL2 featureset igen kis részét és abból interpolálsz, hogy akkor minden jó, holott n+1 Microsoft mérnök által el van ismerve, hogy ez hiba és keresik a megoldását is. Szóval továbbra is az a helyzet, hogy a WSL2 I/O performance igen gyér. Ismert hiba, több és évek óta nyitott hibajeggyel.

https://iotguru.cloud

Nem, én nem ezt kérdeztem, én ezt kérdezem: "Ezt a windo'zintezo-t tudom futtatni WSL2-ben script-ből meghívva? Tudod, vannak olyan esetek, amikor WSL2-ből kell kifelé másolni vagy onnan vissza, ráadásul nem manuálisan, hanem programmatically, mondjuk scriptet futtatva."

Ezt elegánsan nem értetted meg és adtál egy teljesen irreleváns példát, ahol indítasz egy PS-t a WSL2-n kívül (gondolom nem tudtad, hogy nem belül fut).

Rokonok lehettek Szabó Mihállyal: https://www.youtube.com/watch?v=dY5azgX9pHM

https://iotguru.cloud

meirt kene belul futnia? winen win toolokkal kezelgetjuk a filerendszert. akar wsl-bol, scriptbol meghivva ha kell. nem veletlen linkeltem fentebb, amit. :) es MS sem veletlen fejlesztette bele ezt a WSL-be. ertem en, hogy nem _akarod_ kihasznalni, amit a rendszer ad... akkor lassu lesz...
https://learn.microsoft.com/en-us/windows/wsl/filesystems#interoperabil…

meirt kene belul futnia?

Hm... miért is... ááá, megvan: mert az lenne a feladat. Tudod, ha PowerShell-t vagy bármilyen Windows-ban futó programot akarok futtatni, az megy WSL nélkül is, Windows alatt, gyönyörűen, mi faszé' kellene WSL-ből indítanom? Ugye a WSL azért van, hogy Linux programokat tudjak futtatni, amelyek seamless elérik a Windows által adott és biztosított erőforrásokat, beleértve a fájlrendszert is, hálózatot, eszközöket, perifériákat és egyebeket; mert az egésznek nincs sok értelme, ha a megfelelő teljesítmény eléréséhez másolgatnom kellene fájlokat, nem látok perifériákat, kurva lassan látok perifériákat, vagy át kellene írnom a vendor által Linux rendszerre megírt mindenféle script-et és programot, hogy azok tulajdonképpen ne Linux-on fussanak, hanem Windows alatt, mert akkor a WSL lényegi része veszik el ezzel.

Szóval még mindig ott tartunk, hogy van pár nyitott issue ezekkel a problémákkal kapcsolatban és ezek alapján:

a, mindenki hülye, beleértve Microsoft mérnököket is, akik elismerték a hibákat és dolgoznak a lehetséges javításokon,

b, te vagy hülye és nem érted a problémát vagy érted már, de most már kurva gáz lenne benyögnöd, hogy "bocsánat, tévedtem".

Szerintem az utóbbi, általában amikor mindenki szembe jön az autópályán, annak intő jelnek kellene lennie.

https://iotguru.cloud

megoldottam a file baszogtatasi problemadat fentebb. :) wsl-bol, scriptbol.
hogy neked a megoldas nem tetszik es az MS doksijaban leirtak sem, az nem az en saram. :)
"eszközöket, perifériákat és egyebeket;" > hyperv, virtualbox, vmware...
Linux rendszerre megírt mindenféle script-et és programot, > a wsl meg egy windows rendszeren fut...
nem kell mindent szognek nezni, mert epp kalapacs van a kezedben.

megoldottam a file baszogtatasi problemadat fentebb. :) wsl-bol, scriptbol.

Nem, nem oldottad meg.

hogy neked a megoldas nem tetszik es az MS doksijaban leirtak sem, az nem az en saram. :)

Nem a megoldás nem tetszik. Teljesen jó megoldás. Az nem tetszik, hogy nem ezekre a problémákra megoldás, hanem teljesen más problémákat old meg. Az általam felsorolt problémák mindegyike confirmed open issue, amelyek jelentős részén aktívan dolgoznak, egy kisebb részén kevésbé aktívan dolgoznak, de elismerték a hibákat. Csak magamat tudom ismételni: vagy a WSL fejlesztőcsapat a hülye vagy te. Innen nézve erős tippem van, de a te oldaladról még azzal küzdesz, hogy a problémát se találtad el, amit meg akarsz oldani.

"eszközöket, perifériákat és egyebeket;" > hyperv, virtualbox, vmware...

Jóreggelt, innen kezdtük (Fedora VirtualBox-ban futtatva), hogy a WSL2 bizonyos dolgokban lassabb, mint amiket most felsoroltál. A végén még bebizonyítod véletlenül azt az állítást, amivel vitázol. Akarsz még valamit hozzátenni?

nem kell mindent szognek nezni, mert epp kalapacs van a kezedben.

De te épp ezt teszed. Van n+1 probléma, és ezekre jössz egy - azaz egy - olyan megoldással, amelyik nem oldja meg ezeket a problémákat. Hogy azért, mert fel se fogod a problémákat vagy azért, mert már hozzászólásokkal korábban kényelmetlen lett volna beismerni, hogy tévedtél, azt csak te tudhatod.

https://iotguru.cloud

itt te vagy az, aki nem akarja megoldani a problemakat. csak sirsz, h lassssuuuuu :)
de menjunk vissza egy lepest, amit linux rendszerre irtak meg, te meg wsl-ben futtatod, az miert is kene a windozos host FS-re irkaljon... ugyebar. :) irkaljon csak maga ala, azt meg a win ugyis eleri, szinten gyorsan. job's done. :) lasd tobbek kozt a fent becitalt visual studio wiki...

itt te vagy az, aki nem akarja megoldani a problemakat. csak sirsz, h lassssuuuuu :)

Oké, akkor megyünk tovább azzal, hogy szerinted mindenki hülye, beleértve a WSL architect-et, a WSL core contributor-ok jelentős részét és a híresebb neveket a panaszkodó felhasználók közül. Mindenki hülye, egytől-egyig, csak te nem, te tudod a megoldást a problémákra.

Na, itt van az a pont, amikor nincs értelme tovább reszelni veled ezt a kérdéskört.

https://iotguru.cloud

a wsl egy tool. valamire jo, sot, akar gyorsabb, mint nativan a linux, valamire meg kevesbe, valamire meg egyaltalan nem valo. arra meg hasznalunk mas toolt. (peldaul akar wsl scriptbol windowsos executablet, virtualizaciot...) ugyanez igaz az osszes toolra :) ezt kellene belasd, es ha problemad van, arra megoldast/alkalmas toolt keresni. siras helyett ajanlom, boldogabb lesz az eleted tole. (ha mar szemelyeskedunk)

aha, nem. WSL2-ben konkretan a tied az egesz linux ABI. FYI. nem csak valami reverse engineer-elt subsetje a winnek ami igy-ugy mukodik ezzel-azzal.
windo'z alatt meg van virtualbox, vmware, hyperv... :) szoval meh. ne mondjuk mar, h azon nem lehet ugyanugy virtualizalni :)

"aha, nem. WSL2-ben konkretan a tied az egesz linux ABI."

Akárcsak Xen vagy KVM esetében Linuxokon. 

FYI

WSL1 -> Wine csak itt működik a gpu gyorsított grafika, video is. Alkalmazásközpontú annak minden előnyővel.

WSL2 -> Xen mindent tud amit a WSL2, plusz működik normálisan a PCI passthrough ami WSL2-nél elérhetetlen álom kategória. GUI appok úgy futnak mintha natív környezetben lennének WSL2-nél laggggggzanak. 

Semmi ... -> KVM. ilyen technológia csak Linuxszon van, Windowson semmi hasonló nem létezik. PCI passthrough tökéletes. Teljesítménye érezhetően jobb a WSL2-höz képest, de még a Xent is meghaladja kissé. Teljes Windows kompatibilitás natív sebességgel, GPU gyorsítást is beleértve. 

Virtualbox -> Virtualbox Linuxszon is, ugyanazt tudja mint Windowson. Remek type-2 virtualizációra. 

VMware -> WMware Linuszon is van.

Hyper-V -> Xen, ami szintén Type1 virtualizációs technológia és itt meg lehetne ismételni amit WSL2-nél írtam. Továbbá KVM ami teljesítményben és képességekben is jobb mint a Hyper-V és szintén le lehetne írni amit fent írtam KVM-nél. 

Egészen addig amíg Windowszon nem tudod GPU gyorsított grafikával virt guest környezetben elindítani a Starfieldet vagy Cp2k77-et gpu gyorsítással és natív sebességgel nem igaz az állítás, hogy ugyanúgy lehet Windowson virtualizálni mint Linuxszon.

Szomszédos témakör a Docker, ami de facto Linux-only terület.
Docker alapvetően Linux-alapú technológia, amely a Linux kernel funkcióira (cgroups, namespaces, seccomp) épül, így Linuxon natívan fut minimális overhead-del. Windows alatt is létezik Docker, de kevésbé népszerű, mert a fejlesztők többsége Linux konténereket használ, még Windows környezetben is, a nagyobb kompatibilitás, hordozhatóság és a Linux-dominált felhő-ökoszisztéma miatt. Windows alatt a Linux konténerek futtatásához a Docker Desktop egy Linux virtuális gépet ( WSL2 vagy Hyper-V valami) használ, ami egy extra virtualizációs réteget jelent, míg Linuxon erre nincs szükség. A Windows Server konténerek léteznek, de főként legacy Microsoft-alkalmazásokhoz használják, és kevésbé elterjedtek a licencek költségei és a nagyobb erőforrásigény miatt.

Így még ez sem megy úgy Windowszon mint Linuxszon. 

kevered a virtualizaciot, a wine-t es a wsl-t :) mind masra/masert jo.

Egészen addig amíg Windowszon nem tudod GPU gyorsított grafikával virt guest környezetben elindítani a Starfieldet vagy Cp2k77-et > miert tennel ilyet egy win hoston, mikor nativan tok jol fut? :D

jaes:
 

dorsy@wsl64:~$ glxgears
277 frames in 5.0 seconds = 55.260 FPS
X connection to :0 broken (explicit kill or server shutdown).
dorsy@wsl64:~$ glxinfo|head
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4

ilyen integraltsagot pl. egyik sem tud, foleg nem oob, az a baj: https://learn.microsoft.com/en-us/windows/wsl/filesystems#interoperabil…

jottel a wine-nal, ami kurvara nem hozza azt linux-win szinten, mint a wsl win-linux szinten. nagyon nem. :) aztan idekevertel XY virtualizaciot, aminek 0 koze van barmelyikhez == masra jo (nem veletlen nem tudsz wsl2-t hyperv-bol kezelgetni, hiaba van a kettonek kozos gyokere). ertem en, hogy ettol en vagyok a fasz. :)

Megköszönhetnéd, hogy nem csaptam le duplán a glxgears magaslabdát! 

Először is az a szánalmas eredmény már a 2000-es éve végén vérciki lett volna: https://ubuntuforums.org/archive/index.php/t-475203.html

de gondolom be volt kapcsolva a vsync. Szóval normális linuxon ez így működik:
vblank_mode=0 glxgears

Másrészt Starfield meg Cyberpunk 2077-tel egy forumoldalon említeni a glxgearst mint érvet! :facepalm: 

"jottel a wine-nal, ami kurvara nem hozza azt linux-win szinten, mint a wsl win-linux szinten. nagyon nem"

pontosan mit nem hoz? A Wine magasan a WSL1 felett áll. Lehet integetni a kondenzcsíknak az ablakodból! :-) 

Tisztában vagy egyáltalán a WSL1 és WSL2 közötti elég jelentős különbségekkel? A WSL1 rendszerhívásokat fordít hasonlóan a Wine-hoz. A WSL1 egész Linux disztribúciót kezel egyben, a wine az egyes alkalmazásokat állítja fókuszba. 

WSL2 egyébként pont virtualizált Linux, Hyper-V alapon, szóval igen, köze van hozzá.

Vagy lövésed nincs a témáról, vagy tudatosan nem akarod érteni, mert a végén még kiderülne, hogy semmi nem volt igaz abból amit összehordtál. 

A Wine magasan a WSL1 felett áll. > kurvara latszik, hogy el sem olvastad a linket fentebb. majd ha a wine is ugyanugy integralja a win/linux toolokat, ahogyan egy wsl teszi, visszaterunk ra.
Starfield meg Cyberpunk 2077 > ezeket miert akarna barki is wsl-ben futtatni nativ helyett? :D tovabbra sem ertem a use case-t :)
WSL2 egyébként pont virtualizált Linux kernel, Hyper-V alapon > lasd fentebb miert nem lehet hyperv-bol kezelni a wsl instance-okat. az, hogy van kozos codebase, meg a hyperV-s virtualis halozat van alatta (felette?), az egy dolog. tudod, pont ugy, mint ahogy lassan 20 eve mondogatjak itt neha, hogy egy macbookon csak egy koszos BSD fut... :)

A WSL1 a Linux rendszerhívásokat fordítja le a Windows NT kernel API-jaira, hasonlóan ahhoz, ahogy a Wine a Windows API-hívásokat implementálja Unix rendszereken. A különbség az, hogy WSL1 egy teljes Linux disztribúció futtatását célozza, míg a Wine elsősorban egyes Windows-alkalmazások futtatására fókuszál. Mindkettő emuláció nélküli kompatibilitási réteg, de eltérő irányban és célból működnek.

Igen, hallottam már ezt az attól még nem az, mert nem úgy néz ki, mint egy VM érvelést. körülbelül olyan, mint amikor valaki szerint a macOS nem Unix, mert nem terminálban indítják. Ha már a macOS elemet is beemelted a vitába :)
A WSL2 ténylegesen Hyper-V virtualizációt használ egy teljes értékű Linux kernel futtatására, csak éppen nem a megszokott Hyper-V UI-n keresztül menedzselhető. Ez nem azt jelenti, hogy nem lehet Hyper-V-ből kezelni hanem azt, hogy a WSL saját vezérlési réteget használ a VM fölött.
Ha valami a Hyper-V infrastruktúrájára épül, az attól még nem szűnik meg VM-nek lenni, csak mert nem egy .vmcx fájlban lakik. 

Ez nem azt jelenti, hogy nem lehet Hyper-V-ből kezelni  > de, ez pontosan azt jelenti...

sot, a ketto egyutt, egymas mellett letezik. akar egyszerre egy hoston.
nekem az jon le, lovesed sincs a wsl architekturarol, es valoszinuleg nem hasznalod napi szinten :)

( bazso | 2025. 05. 20., k – 19:02 )

Közvetett módon, Rancher desktop alatt. Altatást nem mindig szereti, de amúgy jó cucc.

( kris | 2025. 05. 20., k – 19:09 )

Nálunk nincs, de nagyon jó lenne, mert mindenki magának telepít vagy winget-tel (vagy anélkül) windows-os Git-et meg hasonlókat, vagy Cygwin-nel, vagy ki tudja mivel mit.

Apró probléma, hogy az Office IT-n fogalma sincs senkinek mi WSL, a Security-n se sokaknak, uh. most felmérik. (A standard válasz az, hogy ha POSIX kell desktopon, kérj Mac-et... de én azt nem bírom, meg nem is kérhet bárki.)

Persze közvetlen business case-t nem lehet rá rakni, így aztán prioritása sincs, tehát elég nyögvenyelősen megy.

Ha sikerül elfogadttatnom, hogy a security engedélyezze és bárki akinek Windows-os desktop-ja van meg tudja kérni, hát az csúcs lesz.

Ha valakinek van tapasztalata nagyvállalati IT környezetben (>5000 desktop) való bevezetés kapcsán, (kérem) ne tartsa magában.

Ha valakinek van tapasztalata nagyvállalati IT környezetben (>5000 desktop) való bevezetés kapcsán, (kérem) ne tartsa magában.

Láttam rá példát, egyik nagy cégnél épp használom is a gépen, amit kaptam tőlük. Meg kell indokolni (mondjuk én azzal, hogy K8s CLI eszközök eléggé hiányosak natív Windows PS esetén), de aztán megy gond nélkül.

https://iotguru.cloud

( marcabru | 2025. 05. 21., sze – 05:08 )

Szerkesztve: 2025. 05. 21., sze – 05:14

Használtam az előző munkahelyen. A mostanin (a windowsos mellé) kaptam Linuxos fejlesztő laptopot is, meg is illetődtem. A Windowsos meg olyan szinten le van védve, hogy azon ilyesmit meg se próbálok, max a git bash parancsai vannak.

( zrubi v | 2025. 05. 21., sze – 09:22 )

szerencsére fordítva van: a windows fut egy Linux-os (K)VM-ben - de csak ha nagyon kell ;)

ott aztán eshet-kellhet, ha baj van a lagutóbbi snapshotból visszajön, és szerencsétlenkedhet tovább.

 

a windows számomra  munkára alkalmatlan oprendszernek nevezett erőforráspazarló csilivili izé.

otthon játékra még okés, de a home verzióban nincsen is WSL, mondjuk nem is kell :D

 

szerintem.

zrubi.hu

( freeoli v | 2025. 05. 21., sze – 10:18 )

Volt már olyan, hogy nagyon windows környezetben kellett egy linux alkamatást futtatni és távolról. Ez akkor sokat segített, de egy virtualbox is segíthetett volna.

( Raynes v | 2025. 05. 21., sze – 12:27 )

Szerkesztve: 2025. 05. 21., sze – 12:34

Én nem használom, se munkában, se otthon, de nem tartom rossz dolognak. Gateway drog sokaknak, megnyitva az utat a natív bare metal Linux előtt. Meg esetleg 1-2 cégnél hasznos, ahol semmit nem engednek a gépre telepíteni, BIOS is lezárva, és kerülgetni kell a Windows hülyeségeit, korlátozásait, akkor még sokat segíthet a WSL.

Nekem csak nincs rá szükségem, hogy úgyis natív Linux megy állandóan. Van még 1-2 gépem, amin van elfekvőben Win10 Pro telepítés, de azokat se vettem elő már 1+ éve, és nem is fogom csak azért, hogy azon is linuxozzak, csak virtualizálva. Azok játékokra, meg legacy appok futtatására vannak tartva.

Az kimaradt itt a HUP-os témákból, hogy a MS megnyitotta a kódját a WSL-nek és a Github Copilot-nak is, nem csak az Edit-nek.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( the_manni | 2025. 05. 21., sze – 16:18 )

Ha muszáj vindózni, akkor gitbash, legjobb. Bevallom őszintén, egyszer rászántam majdnem egy napot, wsl2-t docker céljából próbáltam felrakni, de sehogy se sikerült. Úgy csinált mintha telepítené, reboot required, aztán reboot után megint nem volt... Nem tudtam megoldani.

( Honkydoo v | 2025. 05. 21., sze – 16:18 )

Én nagyon szerettem használni élesben termelésre, régebben.

Jelenleg nem használom, mert szerintem nincs rá lehetőség. Ha lenne, használnám most is!

 

Úgy tűnt anno, hogy sok dologra nem alkalmas, főleg ott ahol fizikai eszközt kell elérni. Viszont script írásra, egyéb szoftveres mágiára nagyon jó tool. :)

 

Egyébként a Kali-t jobban szeretem mint a Windows-t, de nem lehet minden tökéletes... Azzal célszerű dolgozni amit adnak...

A Windows-ban talán az Office családot szeretem egyedül, tudom sokan nem így vannak vele, de nagyon kényelmessé tudja tenni a csapatmunkát.

( zgabi | 2025. 05. 21., sze – 19:19 )

Nem használom, de volt rá példa a múltban, hogy használtam munkára.

( timi | 2025. 05. 22., cs – 16:15 )

Kimarad, hogy a WSL1-re vagy WSL2-re vonatkozik a kérdés. A kettő nagyon más. WSL1 úgy-ahogy a wine megfelelője a Windows világban. Mind a Wine, mind a WSL1 kompatibilitási réteg, amely rendszerhívásokat fordít. A wine főleg gpu gyorsított gui programoknál erősebb. 

Ezzel szemben a WSL2 emulációs technológiát használ. Ennek sok előnye és hátránya is van. Először a  linux guest(ek) mindig futnak, és elvesznek a gép erőforrásaiból. Persze wsl --shutdown parancs leállítja az összes futó WSL2 disztribúciót és a mögöttes virtuális gépet, így felszabadítja az erőforrásokat. Azonban a WSL2 gyorsan újraindulhat, és újra fogyasztja az erőforrásokat. Különösen ha több disztró van telepítve ami nálam gyakori ez probléma. 

A WSL2 nem kínál natív snapshot funkciót a Linux disztribúciókhoz, nem biztosít teljes értékű virtuális gépkezelést. 

A "csak" type-2 hipervizor a VirtualBox, de akkor kapcsolom be és ki amikor akarom. Sok disztró esetén sem fogyaszt sok erőforrást ha általában csak egy guest-et kapcsolok be. Kikapcsolva az összeset pedig semmit nem fogyasztanak, csak tárhelyet, ami belefér. A WSL2 nem kínál natív snapshot funkciót a Linux disztribúciókhoz, még a VirtualBox igen. Nehezen hiányolható funkció szintén. 

Azonban a WSL2 gyorsan újraindulhat, és újra fogyasztja az erőforrásokat. Különösen ha több disztró van telepítve ami nálam gyakori ez probléma. 

Valami használja akkor azokat a disztribúciókat. Nálam van ~20 telepítve, mert minden cég és/vagy projekt külön WSL, így könnyű kukáznom egyben az egészet, amikor már nem dolgozok nekik, de mindig csak az fut, amit használok és addig fut, amíg le nem állítom.

A WSL2 nem kínál natív snapshot funkciót a Linux disztribúciókhoz, nem biztosít teljes értékű virtuális gépkezelést.

A WSL1 se, mert az a Windows fájlrendszerében van, minden fájl NTFS-en jön létre, ezért például vicces dolog történik, amikor létrehoznál egy case sensitive fájt, amiből a WSL1 NTFS fájlt készít, ami case insensitive. Mit értesz snapshot alatt WSL1 esetén?

A WSL2 nem kínál natív snapshot funkciót a Linux disztribúciókhoz, még a VirtualBox igen.

Ki tudod exportálni tar-ba amúgy, nem snapshot, de arra jó, hogy mielőtt szétbaszod, legyen egy mentésed, amit vissza tudsz állítani.

https://iotguru.cloud

"A WSL1 se, mert az a Windows fájlrendszerében van, minden fájl NTFS-en jön létre, ezért például vicces dolog történik, amikor létrehoznál egy case sensitive fájt, amiből a WSL1 NTFS fájlt készít, ami case insensitive. Mit értesz snapshot alatt WSL1 esetén?"

Így van. De nem a WSL1-gyel állítottam szembe a WSL2-t hanem a VirtualBoxszal. VirtualBox tudja a snapshot funkciót, WSL 1 és 2 egyike sem tudja. Köszi a kiegészítést. 
A case sensitive probléma még egy pont ahol a WSL1 mint rendszerhívásokat fordító kompatibilitási megoldás gyengébben teljesít mint a wine linuxszon. Abból ritkán van probléma, hogy case sensitive Linux fájlrendszeren vannak a case insensitive windows alkalmazás állományai, hacsak valaki direkt nem trollkodik oda azonos nevű csak case-ben eltérő fájlokat. 

"Ki tudod exportálni tar-ba amúgy, nem snapshot, de arra jó, hogy mielőtt szétbaszod, legyen egy mentésed, amit vissza tudsz állítani."

Amikor még népszerű volt a VMware és legális ingyenes használatra még csak a VMware Player állt rendelkezésre, ami szintén nem tudott snapshot funkciót, már akkor felmerült ez a megoldás. A VMware is úgy látta, hogy ez olyan fontos feature amit célszerű kivenni az ingyenes termékükből és ami miatt sokan megfontolják a WMware Workstationért való fizetést. Playernél is le lehetett menteni az egész virtuális gépet backupba, de ha több állapotról kellett volna mentés, netán rendszeres mentésre is szükség volt, akkor sok hely, idő, kényelmetlenség. Az incremental mentéses snapshot nagyon praktikus képesség. VirtualBox tudja, WSL1 és 2 nem és semmi olyan más képességet nem nyújtanak ami miatt leváltanám bármelyik WSL-re a VirtualBoxot. 

( eff | 2025. 05. 23., p – 17:01 )

Még nem, de ha betiltjak ceges szinten a linuxot (security-re hivatkozva), valoszinuleg kenytelen leszek. Tippre be is fog zuhanni a termelekenyseg, ha at kell majd allni.