Run Linux GUI applications directly on Windows

Na, azt hiszem, ez nagy dobás lesz:

The Windows Subsystem for Linux now includes a first preview of support for GUI applications! This means you can now run your favorite GUI editors, tools, and applications, to develop, test, build and run your Linux apps! Please view the video below for a demo:

https://blogs.windows.com/windows-insider/2021/04/21/announcing-windows…

Hozzászólások

Ezzel a Linux desktop sulykolással ment félre szerintem picit a Linux pályája.
Sosem értettem, miért cél az emberek megtérítése. Egyáltalán szükség van-e ilyen Linux desktop-ra.
Valaki megálmodott egy alternatív windowst. Miért? Pont az volt benne az érték, hogy más célkitűzések mentén fejlődött.

A Linux egy lehetőség.

Valójában ennek az inverze az, aminek értelme lenne.

Szerencsére egyre több az open megoldás a különböző problémákra. És fejlődnek is. Jó példa az Inkscape, de pl. ma már egy GIMP se ugyanaz a GIMP, mint húsz éve. És ezek a megoldások még mentesek a kényszerbloat-osodástól és a product-as-a-service approach-tól.

Itt mi a use case? A Linux-ra fordított programok elsöprő többsége Windows-ra is elérhető, mi értelme lenne Linux-os gui programot használni Windows alatt?

Gondolom annyi, hogy csak az elsöprő többsége és vannak, amelyek nem. Illetve a leírás szerint a cross-platform fejlesztéshez jó, tesztelhető a Linux build.

Egyébként most teszteltem, egy Gimp startup WSL2 Ubuntu 20.04 alól ~3 másodperc. A natív Windows Gimp build indulása (nálam) ~45 másodperc. Nem tudom, mit tekertek félre a fordításnál, de ez például jelentős különbség. A probléma az, hogy például a clipboard nem közös. A KMyMoney WSL2 Ubuntu 20.04 alól ~3 másodperc, a natív Windows build ~8 másodperc; és például érezhetően gyorsabb a sok tételt tartalmazó account listázása. Szóval azért lehet ennek haszna akkor is, ha van Windows build.

Pontosan az egyik legfőbb indok a Linux mellett. Ez a fajta pattogósság, főleg, ami sok kis fájllal dologzik, sciptek tömkelegét tölti be, annyival gyorsabb Linux alatt, hogy aki nem szokott hozzá, annak elsőre hihetetlen lesz. Főleg akkor számít sokat, ha valakinek gyengébb gépe van, hogy Windows nélkül mennyire szárnyra tud kapni, főleg, ha valami megfelelő, pehelysúlyúbb disztróval és grafikus felülettel használja valaki, ami nincs tele bloat sallangokkal.

A másik, hogy Linuxban mindent lehet testre szabni, hekkelni, amit pl. Windows alatt nem lehet (eleve nem ura a user a saját rendszerének), különböző filozófiájú WM-ek, keyboard driven workflow, tiling, shelles/CLI ökoszisztéma, ez annyival nagyobb hatékonyságot biztosít, mint a hagyományos egy megoldás mindenkinek desktop, hogy hihetetlen, csak aki nem próbálta még ki, az nem fogja elhinni.

Ennek a WSL-nek egyébként pont ez az egyetlen előnye, hiába lámaság, lehet 1-2 embert behúz majd a natív Linux világába, mikor látja, hogy dolgok mennyivel gyorsabban futnak, mennyivel hatékonyabbak. Egyfajta kóstolót kaphat olyan is, aki nem akart ismeretlen disztrókkal kísérletezni a gépén.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ez a fajta pattogósság, főleg, ami sok kis fájllal dologzik, sciptek tömkelegét tölti be, annyival gyorsabb Linux alatt, hogy aki nem szokott hozzá, annak elsőre hihetetlen lesz.

A Windows alapvetően a víruskereső húzza le ilyenkor, ha kikapcsolod az adott mappára a víruskeresést, akkor meg tud táltosodni, több ezer fájl másolásával és fordításával járó Maven build nagyjából ugyanannyi idő lesz, többször mértem.

A Gimp induláson azonban ez nem segít, ott más van elszabva, vélhetően egy cross-compile alkalmazás, sok platformidegen library használatával soha nem lesz annyira "pattogó", mint egy natív, ami mondjuk RDP-n át ad ablakot.

Nem csak a víruskeresés, persze az is tud rajta lassítani. Hanem a Windowsnak a lemezvezérlős ütemezője is szarabb, mint Linuxon, meg az NTFS is egy ősi, szutyok lassú megoldás. Ezt nem venni észre nagy fájloknál, ahol szekvenciálisan még telíthető az a sávszél, amit a háttértár, lemezvezérlő, RAM cache tud, hanem sok kicsi fájlnál, apró fájlműveletnél, ahol a sok felesleges overhead begyűlik, ott lesz sokkoló a különbség.

Abban egyetértek, hogy a GIMP-nél az is belejátszik, hogy nem valami optimalizált alkalmazás, sok szutyok .py scriptet töltöget be, elég bloat monstrum, egyik platformra sincs igazán jól optimalizálva. Az is igaz, hogy ez a képszerkesztők műfaja ilyen, azokból, ami ilyen nagy tudású suite progi, az mind agyonbloatolt valami, kivétel nélkül, mindegy milyen platformra van.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Nem csak a víruskeresés, persze az is tud rajta lassítani. Hanem a Windowsnak a lemezvezérlős ütemezője is szarabb, mint Linuxon, meg az NTFS is egy ősi, szutyok lassú megoldás.

Ez miért nem jött ki, amikor sok ezer apró fájlból álló projektet fordítottam? A natív Linux, a WSL és a natív Windows teljesítménye között nem volt mérhető különbség, a hardver ugyanaz volt.

Abban egyetértek, hogy a GIMP-nél az is belejátszik, hogy nem valami optimalizált alkalmazás, sok szutyok .py scriptet töltöget be, elég bloat monstrum, egyik platformra sincs igazán jól optimalizálva.

Oké, de ez miért nem jön elő a natív Linux Gimp esetén?

Hát, én például a WSL/WSL2 kapcsán annak örültem, hogy ha bejön egy Windows only munka vagy valamelyik játék miatt épp Windows alatt vagyok, akkor ugyanaz a parancssor ott van, ahogy megszoktam és ugyanazok a scriptek futnak ugyanazokkal a programokkal, ahogy megszoktam és nem kell bajlódni a virtualizációval.

Az, hogy GUI is ki tud jönni a WSL-ből, az jelentősen nem befolyásolja ezt az én esetemben, de vannak esetek nálam is, amikor jól jön majd (és jelenleg úgy néz ki, hogy gyorsabb is, mint az adott alkalmazás natív Windows verziója).

Én most nagyjából azt látom, hogy alapvetően Ballmer volt az MS köcsög-irányzata, amióta nincs, azóta szignifikánsan kevésbé köcsögök, a WSL meg tud nekik pénzt hozni azáltal, hogy Windows-ra mennek át azok, akik határon billegnek, mert CLI intenzív dolgokat szeretnek a Linux-ban, de a hardverekkel, driverekkel és egyebekkel való birkózást nem szeretik desktop-on, pláne laptopon.

Én például az Elite Dangerous és a StarCraft II miatt használom a Windows-t, és azt vettem észre, hogy a WSL hiányosságai miatt keveset megyek át Linux alá: a work drive közös, a használt szoftverek (Chrome, Firefox, Android Studio, IntelliJ IDEA) mind képesek a cross-platform szinkronizálásra, a WSL miatt pedig ott van az a CLI, amit megszoktam.

Ki is próbálom. Ha tényleg olyan powerful, megúszok pár scp-zést a wines gépről.

Van amúgy natív OpenSSH, ahhoz nem is kell WSL:

PS C:> scp
usage: scp [-346BCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file]
[-J destination] [-l limit] [-o ssh_option] [-P port]
[-S program] source ... target

Most úgy működik, hogy van egy Pi, Raspbiannal, amire tolom a fájlokat WinSCP-vel, Putty ablakban fut a parancs, és vissza... Ha ezt az oda-visszát megúsznám, az lenne benefit.
Maguknak a command line tool-oknak van általában win-re fordított változata, csak scriptelni nem tudom őket.

Most úgy működik, hogy van egy Pi, Raspbiannal, amire tolom a fájlokat WinSCP-vel, Putty ablakban fut a parancs, és vissza...

Mint írtam, van natív OpenSSH, tehát teljesen felesleges a WinSCP és a Putty is.

Maguknak a command line tool-oknak van általában win-re fordított változata, csak scriptelni nem tudom őket.

WSL esetén igen, minden drive be lesz csatolva az /mnt/c/, /mnt/d, ..., alá, eléred a Windows fájlrendszerét Linux alól és eléred a Linux fájlrendszerét Windows alól.

Én baromi boldog voltam, amikor kijött a Docker Desktop WSL2-támogatásssal, mert elvileg lehetőségem lett arra, hogy valakinek odaadjak egy zip fájlt, kitömöríti, az adott könyvtárból indít egy docker-compose up-ot, és nem kell értenie, hogy működik. (És ugye a bindolt volume-ok hivatkozása ugyanaz a compose.yml-ban a Windowson WSL-lel és Linuxon is.)

Csak éppen használhatatlanul lassú. :(

Van egy SFTPNetDrive nevu progi winre, mostanaban azt hasznalom. SSHFS-hez hasonloan fel tudsz mountolni drive-okat, igy nincs szukseg WinSCP-re. (bar utobbi is eleg jol mukodik, ha csak masolni kell)

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Az hát. Én ezt az egész WSL, WSL2, linuxozzunk Windows alatt, best of both world baromságot nevetségesnek tartottam. Igen, jó a Linux, de aki tényleg élvezni akarja, az telepítse fel natívban. Üzenem nekik, hogy ráérnek később megköszönni. Ilyen félmegoldások, mint a WSL, valójában worst of both world típusú élményt adnak. Soydeveknek lehet jó, akik az idiotizmusnak olyan magas fokán állnak, hogy nem bírnak egy normális disztrót feltelepíteni, meg belakni, rendes workflow-t kialakítani rajta, de azok inkább foglalkozzanak mással.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Igen, jó a Linux, de aki tényleg élvezni akarja, az telepítse fel natívban. Üzenem nekik, hogy ráérnek később megköszönni.

Az a helyzet, hogy van sok dolog, ami nincs Linux alá, főleg játékok, illetve laptopok esetén főleg jól működő driverek nincsenek. Ez nálam azt jelenti például, hogy valamelyik kernel frissítéstől kezdve nem működött a sleep és egy darabig tudtam halogatni a kernel frissítést, aztán már nem. És azóta Linux alatt nincs sleep, mert lecsukom, elalszik, felnyitom, újraindult, fájlrendszer ellenőrzés, egyebek. Persze, tele van sírva vele n+1 fórum, a kernel fejlesztők vonogatják a vállukat, hogy sorry.

Ilyen félmegoldások, mint a WSL, valójában worst of both world típusú élményt adnak. Soydeveknek lehet jó, akik az idiotizmusnak olyan magas fokán állnak, hogy nem bírnak egy normális disztrót feltelepíteni, meg belakni, rendes workflow-t kialakítani rajta, de azok inkább foglalkozzanak mással.

Nem lehet, hogy az frusztrál, hogy a világ nem arra megy, amerre te személyesen szeretnéd?

Linuxra rengeteg probléma megoldására van program, ami ugyan van Windowsra is, csak azok jó része nem ingyenes.
Sokszor belefutottam már én is abba, hogy kellet valamire program, de csak fizetőst találtam, közben Linuxra meg volt három is ami ingyenes. 
Így viszont most már még több ingyenes programot lehet használni Win alatt, nem számít hogy az Linuxra lett készítve. 

Szóval Én örülök ennek, hasznos lesz!

Hátööö... :)

> gimp
Error spawning command line “dbus-launch --autolaunch=4af9d28d820b4587b7a36d2dce45c350 --binary-syntax --close-stderr”: Child process exited with code 1

(gimp:56): Pango-CRITICAL **: 09:55:29.317: pango_font_get_hb_font: assertion 'PANGO_IS_FONT (font)' failed
Segmentation fault

Én is segítek olvasni: "Egyébként most teszteltem, egy Gimp startup WSL2 Ubuntu 20.04 alól ~3 másodperc. A natív Windows Gimp build indulása (nálam) ~45 másodperc. Nem tudom, mit tekertek félre a fordításnál, de ez például jelentős különbség."

Ha indítottál egy X szervert (pl. egy VcXsrv-t) Windowson ez eddig is ment, ezért érdekelt, hogy oldották meg.

Ahja, csak azért az több sebből vérzett.

Lényegében futtatnak egy Linux virtuális gépet a háttérben amiben van X szerver, Wayland compositor, PulseAudio.

A WSL maga egy virtuális gép, akkor is, ha csak CLI-re használom, annyival több ez most, hogy nem kell X klienssel foglalkozni, benne van az RDP bridge.