Názory k článku
Game Porting Toolkit od Apple je vlastně Wine
-
-
To už dávno je. Spuštění Windows x86 app zavolá v pozadí Rosetta 2, ta převede binárku x86-->ARM a spustí ji, nyní už ARM verzi Windows app, s WINE pro ARM, který se postará o konverzi API Windows-->macOS. CrossOver a wine-crossover dále umí převádět ukazatele 32-->64bit, takže jde spustit 32bit Windows x86 app (nejprve ji Rosetta 2 převede na ARM, pak se pustí ve WINE pro ARM, ale v každém volání z app do systému převede ukazatele na 64bit, protože okolní OS už je 64bit only). Teď novinka je, že Apple přidal do macOS wrapper 3D API DirectX 12-->Metal a poslal patche do WINE, takže fungují i nové DX12-only hry, jako Diablo IV, Elden Ring a Cyberpunk 2077.
-
IMHO jsou dvě možnosti, jak to může fungovat:
a. Vývojář zkompiluje hru pro ARM, a emulaci x64 není potřeba řešit. Znamenalo by to ale, že půjde o nástroj jen pro vývojáře.
b. Vývojář použije binárku pro x64, stejně se emulace x64 již řeší…Podle odkázaného článku mi to přijde, že toolkit zkoušejí I koncoví uživatelé (ač je to spíše pro vývojáře), takže nejspíš ta druhá možnost tu bude. (V principu tu mohou být i obě možnosti…)
-
Měl jste někdo už Mac s Apple Silicon v ruce? Od CrossOver je verze WINE wine-crossover, která je napojená na Rosettu 2. Takže macOS automaticky převede x86 na ARM (Ahead-of-Time) a následně pustí nativní ARM kód. WINE pak řeší jen překlad API. Zprávička o Apple a CrossOver je o tom, že se Apple konečně zapojil a implementoval (beta verzi) překladače DirectX 12 na Metal. Doteď wine-crossover neuměl DirectX 12 a komunitní wine zas má problém běžet na ARM (wine-crossover navíc umí i 32bit x86 aplikace, protože překládá pointery on-the-fly).
-
Ono je to JEDNO, nebot M1 ani M2 nejsou moc vykone GPU, jesou to vykonne mobilni GPU, takze to poirazi kazda soucasna NVIDIA v nasobcich - tedy na hrani to nebude, ne jen ze to bude prekladat win api, jeste x86 instrukce a navrch nad slabym GPU - linux s nvidia kratou je uplne na jine urovni.
Na apple jsou nativni hry a dbre bezi jen ty hodne stare, nebo napsane primo pro ARM, coz jsou i mobilni hry, mnoho mobulnich her bezi na MacOS nativne, nebot je to kompatibilni ARM CPU - smerem z iphone na M1 a lepsi, opacne samozrejme ne ;-)
-
Sorry, nie. M1/M2 maju vyhodu, ze maju pristup k rychlej RAM SoC a nemusia robit transfery cez PCIe, ale tam to konci. To ich robi v niektorych benchmarkoch porovnatelnymi s 3060, obzvlast ked sa vezme do uvahy perf/watt, ale hrubou vypoctovou silou bez ohladu na spotrebu na nich nemaju.
No a zhodou okolnosti M1/M2 je mobil v laptope. Je to velmi pekny SoC, ale zase pozor na Jobsov RDS.
-
Ja nejsem moc Apple positive, tak me prosim odpustte pripadnou nepresnost, ci neznalost, ale mel jsem vzdycky za to, ze Apple minimalne ma Macu vyuzival Wine pro zajisteni kompatibility s Windows. Jen to moc neroztruboval do sveta. Pokud je tomu tak, pak moc nechapu ten udiv, ve ktery zpravicka vyzniva....
-
Apple právě nic nedělal. CrossOver je komerční firma, která se podílí na vývoji WINE. Patche do něj posílá se zpožděním asi rok, aby měli lidi důvod si koupit jejich komerční verzi. (Vzhledem k tomu, že Apple Silicon je tady už 2 roky, tak potřebné úpravy jsou i ve WINE zadarmo.)
Co se teď změnilo, Apple se zapojil a vytvořil překladač DirectX 12 --> Metal a poslal patche do WINE, aby tento překladač využíval. Díky tomu najednou začaly fungovat i moderní hry (DX12), protože předtím CrossOver/wine-crossover uměl maximálně DX11 a komunitní wine není pro macOS a Apple Silicon tak odladěný (včetně podpory DX12).
-
Wine D3D12 podporuje, pomocou VKD3D.
Akurat je mozne, ze na Apple to moc nefungovalo, kedze VKD3D bezi nad Vulkanom a na macOS je Vulkan emulovany pomocou MoltenVK a nebude mat tie spravne rozsirenia, ktore Linuxove ovladace maju a teda priama emulacia bude jednoduchsia, obzvlast, ked Apple prida do Metal API funkcnost, ktora je na emulaciu potrebna.
-
Apple má v Metal API všechnu funkčnost jeho GPU, ale vývojáři VKD3D/MoltenVK/WINE zatím nedělali/nechtěli dělat potřebné úpravy pro specifika dalšího OS a 3D API. To na sebe teď vzal Apple a udělal vlastní wrapper DX12-->Metal. Asi bylo jednodušší udělat ho od začátku, než upravovat cizí projekt - který je specificky pro Linux, takže by musel testovat úpravy, že nerozbily funkčnost v Linuxu (testování v takto roztříštěném OS je velmi náročné, v podstatě diskvalifikuje jeho podporu v mnoha aplikacích, které by "stačilo jen překompilovat"; např. většina her je v Unity a Unreal a přesto nemají nativní verzi pro Linux).
-
MoltenVK je limitovany tym, co mu Metal API ponukne. Ked su Mesa/AMD/Nvidia ochotni pridat do VK nove rozsirenie aby bolo mozne efektivne emulovat funkcnost D3D12 a Apple do Metal nie, tak MoltenVK s tym nic nespravi.
V praxi Apple rozbija binarnu kompatibilitu tempom, ze Linux moze len zavidiet. Mam plnu kniznicu titulov, ktore na aktualnom macOS nebezia (napr. preto, ze je to 32-bit aplikacia) a vyvojari hier novu binarku nevydaju.
Zaujimave je, ze linuxove verzie vydane v rovnakom case funguju. Vyvojari hier na Linuxe cielia na Steam runtime (ak predavaju cez Steam) alebo Ubuntu LTS (ak predavaju cez GoG). Nejaka roztriestenost je teda bezpredmetna. Ak niektora hra v Unity nema Linuxovu verziu, je to biznis rozhodnutie, nie technicke. Napriklad ked napr. Microsoft kupil Larian Studios, tak vtedy prestali vydavat Linux verzie.
-
32bit aplikace končí na všech ARM SoC na úrovni hardware. Na úrovni software 32bit podpora skončila i v x86 Linuxu - standardně už x86 linuxovou binárku nespustíte. Zůstává jen omezená podpora pro WINE, která bude brzy odstraněna, až WINE dokončí přechod na svou interní konverzi 32<-->64bit.
V posledních letech už Steam říká, že máme cílit na Windows a nechat to na Protonu, který je již velmi vyladěn. Naopak starší linuxové binárky mají problém, jak distribuce teď by default používají Wayland, který do kompatibility hodil vidle.
> Ak niektora hra v Unity nema Linuxovu verziu, je to biznis rozhodnutie, nie technicke.
Ano, technicky to není problém, když většina her je v enginech, které Linux umí. Ale když 5 % uživatelů tvoří 40-50 % bug reportů, tak mají vývojáři problém.
-
32bit aplikace končí na všech ARM SoC na úrovni hardware.
Ano, ja viem. Som vlastnikom pocitaca s M1 a viem, ze nevie 32-bit ani pre ARM binarky.
standardně už x86 linuxovou binárku nespustíte. Zůstává jen omezená podpora pro WINE, která bude brzy odstraněna, až WINE dokončí přechod na svou interní konverzi 32<-->64bit.
A toto mate odkial?
Standardne linuxove distribucie nemaju 32-bitovy instalator pre 32-bitove systemy. V 64-bitovych systemoch behaju 32-bit aplikacie velmi dobre, multiarch je tu s nami nejaky ten piatok a distribucie stale obsahuju vsetky kniznice, ktore na to treba. Dokonca tu prednedavnom bola spravicka, ze v jadre sa objavuje experimentalna novinka, umoznuje pri boote vypnut podporu pre 32-bit procesy... co znamena, v praxi budu by default este minimalne dekadu fungovat a potom este dalsiu dekadu bude deprecated, ale pouzitelne.
Ale když 5 % uživatelů tvoří 40-50 % bug reportů, tak mají vývojáři problém.
Ono to tvori 40-50% bug reportov vtedy, ked sa to odfakne. Keby to bolo tak odflaknute napr. pre Windows, tak by dane studio skrachovalo. Koniec koncov, stava sa aj to, a aj CDPR po spackanom starte Cyberpunku 2077 nebolo od toho daleko (boli v ochrane pred veritelmi)...
-
> Ano, ja viem. Som vlastnikom pocitaca s M1 a viem, ze nevie 32-bit ani pre ARM binarky.
Měl jsem na mysli i jádra Cortex, ne jen Apple.
> A toto mate odkial?
Např. "Ubuntu dropped support for 32bit applications a few years ago." z https://stackoverflow.com/questions/75793035/running-32bit-linux-ubuntu-application-on-64bit . I když je zapnutelná podpora 32bit (jak ale jako vývojář zajistím, aby uživatel dokázal nainstalovat podporu 32bitů? nějaký grafický instalátor pro běžné distribuce a jejich poslední verze?), tak ne všechny balíčky/knihovny mají 32bit verzi (např. musím zkopírovat verzi ze starší verze Ubuntu).
Můžete se ohánět, že používáte nějaké minoritní distro, kde tenhle problém není. Nicméně sám se výše oháníte "neroztříštěností linuxu", protože máme Ubuntu.
> Dokonca tu prednedavnom bola spravicka, ze v jadre sa objavuje experimentalna novinka, umoznuje pri boote vypnut podporu pre 32-bit procesy... co znamena, v praxi budu by default este minimalne dekadu fungovat
Ta zprávička byla o tom, že když je podpora 32bit aplikací už dávno broken, že není důvod nechávat otevřený "attack vector".
> Ono to tvori 40-50% bug reportov vtedy, ked sa to odfakne.
Nemyslím si, že vývojář, který si dá práci s podporou Linuxu, že ten kód odflákl (to mohl rovnou otestovat v Protonu a zaškrtnout ve Steamu, že funkčnost hry je ověřena autory hry - např. platí hodnocení atd.). A kdyby, tak by bug reporty nebyly o celý řád jinde.
> stava sa aj to, a aj CDPR po spackanom starte Cyberpunku 2077
Cyberpunk 2077 byl odfláklý jen pro 8-10 let staré počítače a konzole. Cokoli novějšího jelo bez problému. Půlka lidí tu hru dohrála, než vyšly první opravy.
-
Např. "Ubuntu dropped support for 32bit applications a few years ago."
Thanks to the huge amount of feedback this weekend from gamers, Ubuntu Studio, and the WINE community, we will change our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS.
We will put in place a community process to determine which 32-bit packages are needed to support legacy software, and can add to that list post-release if we miss something that is needed.
https://canonical.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
Takze zrovna hry tento problem nemaju.
Ta zprávička byla o tom, že když je podpora 32bit aplikací už dávno broken, že není důvod nechávat otevřený "attack vector".
A to ste ako dostali z povodneho oznamenia takyto vyznam?
Distributions would like to reduce their attack surface as much as possible but at the same time they have to cater to a wide variety of legacy software. One such avenue where distros have to strike a balance is the support for 32bit syscalls on a 64bit kernel. Ideally we'd have the ability to disable the the compat support at boot time. This would allow the decision whether it should be disabled/enabled can be delegated to system administrators.
Ako ste z toho porozumeli, je podpora 32-bit aplikacii je broken?
Nemyslím si, že vývojář, který si dá práci s podporou Linuxu, že ten kód odflákl (to mohl rovnou otestovat v Protonu a zaškrtnout ve Steamu, že funkčnost hry je ověřena autory hry - např. platí hodnocení atd.). A kdyby, tak by bug reporty nebyly o celý řád jinde.
No, mysliet si to nemusite, ale je to tak. Dokonca existuju aj tituly, ktorych linuxovy port dokonca ani nesiel spustit (mozno vyvojarovi na jeho pocitaci ano) bez prveho patchu.
Půlka lidí tu hru dohrála, než vyšly první opravy.
No vidite, a druha polovica frflala a chcela refund. Co bolo dost na to, aby to firmu skoro polozilo.
-
>> Thanks to the huge amount of feedback this weekend from gamers, Ubuntu Studio, and the WINE community, we will change our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS.
>> We will put in place a community process to determine which 32-bit packages are needed to support legacy software, and can add to that list post-release if we miss something that is needed.
>> https://canonical.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
> Takze zrovna hry tento problem nemaju.
Však jsem psal v předpředchozím příspěvku, že podpora 32 bitů už je jen pro WINE (a i pro ten brzo skončí, až WINE dokončí přechod na PE binárky). Bavíme-li se o nativních aplikacích/hrách, tak ty maj smůlu (opět ve starším příspěvku jsem psal, že Steam nyní již doporučuje distribuovat Windows hru a testovat v jeho Protonu).
> A to ste ako dostali z povodneho oznamenia takyto vyznam?
> Ako ste z toho porozumeli, je podpora 32-bit aplikacii je broken?To vím už z dřívějška. Obráceně, ten text neříká, že dosud všechny 32bit aplikace fungovaly.
> No, mysliet si to nemusite, ale je to tak. Dokonca existuju aj tituly, ktorych linuxovy port dokonca ani nesiel spustit (mozno vyvojarovi na jeho pocitaci ano) bez prveho patchu.
Ano, vývojářovi tu fungovalo, u pár kamarádů taky. Ale nikdo nemá na testování stovek distribucí a jejich posledních 10 verzí. Pro 2 % hráčů.
> No vidite, a druha polovica frflala a chcela refund. Co bolo dost na to, aby to firmu skoro polozilo.
Tak spousta lidí měla staré stroje. Vliv na to měla i pandemie a nedostatek grafických karet, předražené ceny a nedostatek nových konzolí. Samozřejmě měli vydání odložit, no tak se manažeři spálili a vývojáři mohli hru v klidu dokončit.
-
Však jsem psal v předpředchozím příspěvku, že podpora 32 bitů už je jen pro WINE (a i pro ten brzo skončí, až WINE dokončí přechod na PE binárky). Bavíme-li se o nativních aplikacích/hrách, tak ty maj smůlu (opět ve starším příspěvku jsem psal, že Steam nyní již doporučuje distribuovat Windows hru a testovat v jeho Protonu).
No prave to ste pisali nespravne, nie je to len pre wine. Je to pre legacy applications.
Wine prechodom na PE ziska to, ze bude fungovat aj bez multiarch balickov. Legacy nativne binarky stale budu potrebovat multiarch balicky, a stale bude urcita mnozina kniznic, ktore budu takto balickovane. Ano, mozno nejaka obskurna kniznica nebude, ale ak je obskurna, tak by mala byt pribalena k aplikacii tak ci tak.
To vím už z dřívějška. Obráceně, ten text neříká, že dosud všechny 32bit aplikace fungovaly.
Takze zase dalsi nespravny zaver?
Ale nikdo nemá na testování stovek distribucí a jejich posledních 10 verzí. Pro 2 % hráčů.
To ale nikto po nich nechce. Staci vediet zaklady -- napriklad ako skompilovat binarku "hygienicky", bez toho, aby sa na nej odrazila lokalna konfiguracia. Ale to zvycajne windows developeri nevedia, pre nich kompilacia znamena stlacit tlacidlo vo Visual Studio. Linker? Co je to? Nebodaj CI pipeline?
Samozřejmě měli vydání odložit, no tak se manažeři spálili a vývojáři mohli hru v klidu dokončit.
No a podobny pristup je aj k linuxovym portom a potom sa cuduju, ze maju hlasenych vela bugov.
-
> No prave to ste pisali nespravne, nie je to len pre wine. Je to pre legacy applications.
Pro vás to jsou všechno nové informace, které si teď náhodně googlíte. Ale já tu dobu zažil, vím ty diskuze a detaily. Šlo jen o staré Windows hry přes WINE.
> Wine prechodom na PE ziska to, ze bude fungovat aj bez multiarch balickov. Legacy nativne binarky stale budu potrebovat multiarch balicky, a stale bude urcita mnozina kniznic, ktore budu takto balickovane.
Viz výše. Když hlavním důvodem je WINE, tak až ten to brzo nebude potřebovat, tak důvod padá. To samozřejmě neznamená, že nebudou existovat specializované instalace Linuxu, kde nějaká specifická 32bit app bude podporována. Ale běžný uživatel bude muset psát příkazy do konzole, aby spustil starou 32bit app a doufat, že to bude fungovat (to je další problém Linuxu - věci se řeší psaním do konzole, není grafické klikátko jako ve Windows, kde by zaškrtl feature).
> Ano, mozno nejaka obskurna kniznica nebude, ale ak je obskurna, tak by mala byt pribalena k aplikacii tak ci tak.
Legacy aplikace už autoři nebudou přebalovat. A mimochodem v době vydání aplikace ta knihovna obskurní nebyla. To je jen důkaz roztříštěnosti Linuxu, že místo toho, aby se něco udělalo pořádně, tak se to zahodí a udělá se jiný projekt (knihovna).
> Takze zase dalsi nespravny zaver?
Ano, udělal jste si nesprávný závěr.
> To ale nikto po nich nechce. Staci vediet zaklady -- napriklad ako skompilovat binarku "hygienicky", bez toho, aby sa na nej odrazila lokalna konfiguracia. Ale to zvycajne windows developeri nevedia, pre nich kompilacia znamena stlacit tlacidlo vo Visual Studio. Linker? Co je to? Nebodaj CI pipeline?
Tady je vidět, že jste si to nikdy nezkusil. Standardně Linuxové vývojářské nástroje kompilují proti konkrétním minor verzím aktuálních knihoven v systému. Jako vývojář musím linkování editovat, aby bylo na majoritnější verze. Např. v systému je knihovna-1.2.3.so, tak já musím upravit linkování na knihovna-1.so, protože v budoucnu budou mít uživatele v systému jen knihovna-1.2.5.so a symlinky na ní knihovna-1.2.so a knihovna-1.so.
> No a podobny pristup je aj k linuxovym portom a potom sa cuduju, ze maju hlasenych vela bugov.
Testovat to na majoritních konfiguracích je furt o řád více času než pro ostatní OS. Pro 2 % hráčů.
-
Pro vás to jsou všechno nové informace, které si teď náhodně googlíte. Ale já tu dobu zažil, vím ty diskuze a detaily. Šlo jen o staré Windows hry přes WINE.
Vyzera to presne naopak. Sirite tu povesti a myty o roztriestenosti a binarnej nekompatibilite, stovkach distribucii a podobne hluposti. To vsetko sa da nachytat z diskusnych for, ale nie z praxe.
Ale běžný uživatel bude muset psát příkazy do konzole, aby spustil starou 32bit app a doufat, že to bude fungovat (to je další problém Linuxu - věci se řeší psaním do konzole, není grafické klikátko jako ve Windows, kde by zaškrtl feature).
Steam to riesi za pouzivatela; pokial to chce pouzivatel riesit vo svojej rezii, ma k dispozicii klikatka typu Synaptic.
Mimochodom, viete o tom, ze serverove Windows su by default bez GUI a vsetko sa riesi powershellom, alebo remote server managerom? Linux nema monopol na riesenie uloh v terminali.
A mimochodem v době vydání aplikace ta knihovna obskurní nebyla.
Ste si isti? Napr. libudev.so.0 (pouzivana mnohymi starsimi Unity projektami; problem s nou bol, ze nebola linkovana, ale dlopen()-nuta) sice obskurna nebola, ale to cislo verzie by ma mohlo kopnut, ze ju treba pribalit k binarke.
Standardně Linuxové vývojářské nástroje kompilují proti konkrétním minor verzím aktuálních knihoven v systému. Jako vývojář musím linkování editovat, aby bylo na majoritnější verze. Např. v systému je knihovna-1.2.3.so, tak já musím upravit linkování na knihovna-1.so, protože v budoucnu budou mít uživatele v systému jen knihovna-1.2.5.so a symlinky na ní knihovna-1.2.so a knihovna-1.so.
Ze vy netusite, co je to soname? Ked sa rypete v niecom, co nepoznate, je mi jasne ze to nemoze fungovat a pride vam to tazke. Napr. libpng 1.6 ma soname libpng16.so.16, linkuje sa voci tomuto nazvu, ale subor na disku ma nazov libpng16.so.16.37.0 (priklad z aktualneho Ubuntu LTS). Pokial dal niekto minor verziu do soname a nie ako postfix za soname, tak to je zase prejav toho, ze niekto robi nieco, co nevie.
A to ani nehovorim, ze produkcna binarka sa nema buildovat nahodnymi devtools na pocitaci vyvojara, ako ich instaloval as-needed pomocou apt/dnf. Ked uz, tak minimalne v kontajneri so zakladnou, minimalnou distribuciou (napr. ako to robi mock pre redhat distribucie), alebo mat pripraveny chroot len s potrebnymi nastrojmi a SDK v jasne definovanych verziach, tak, aby bol build opakovatelny.
No a teraz toto vysvetlite priemernemu windows game developerovi. Nie, nedokaze si vytvorit buildovaci chroot s verzionovanymi SDK a pochybujem, ze ma okolo seba niekoho, koho by sa spytal.
Ano, tu musim pochvalit ze Microsoft, Apple, autorov Steam runtime a linuxoveho flatpaku, ktori to so svojimi nastrojmi robia by default, zatial co klasicke linuxove distribucie pracuju s trocha inym konceptom. Nastastie, aj to sa uz meni, ale bude tazke vykorenit niektore zvyky, zvlast u ludi, ktori sa nad tym nikdy nezamysleli.
-
> Vyzera to presne naopak. Sirite tu povesti a myty o roztriestenosti a binarnej nekompatibilite, stovkach distribucii a podobne hluposti. To vsetko sa da nachytat z diskusnych for, ale nie z praxe.
Který z těch "mýtů" neplatí? Linux jsem často používal jako primární OS a i pro něj vyvíjel.
> Steam to riesi za pouzivatela; pokial to chce pouzivatel riesit vo svojej rezii, ma k dispozicii klikatka typu Synaptic.
Synaptic je z posledních Ubuntu už odstraněn (a proč mluvím o Ubuntu, to jsme si vysvětlili). Je třeba ho instalovat psaním do konzole.
> Mimochodom, viete o tom, ze serverove Windows su by default bez GUI a vsetko sa riesi powershellom, alebo remote server managerom? Linux nema monopol na riesenie uloh v terminali.
To je jen jedna z mnoha verzí serverových Windows, ta určená jen pro běh VM (aby Host OS měl co nejmenší režii).
> Ste si isti? Napr. libudev.so.0 (pouzivana mnohymi starsimi Unity projektami; problem s nou bol, ze nebola linkovana, ale dlopen()-nuta) sice obskurna nebola, ale to cislo verzie by ma mohlo kopnut, ze ju treba pribalit k binarke.
To tehdy těm vývojářům nikdo neřekl. A v tu dobu ta aplikace všem fungovala.
> Ze vy netusite, co je to soname? Ked sa rypete v niecom, co nepoznate, je mi jasne ze to nemoze fungovat a pride vam to tazke. Napr. libpng 1.6 ma soname libpng16.so.16, linkuje sa voci tomuto nazvu, ale subor na disku ma nazov libpng16.so.16.37.0 (priklad z aktualneho Ubuntu LTS). Pokial dal niekto minor verziu do soname a nie ako postfix za soname, tak to je zase prejav toho, ze niekto robi nieco, co nevie.
Jen další způsob, jak definovat obecnější název/verzi knihovny. Fungují oba dva a v obou případech musím editovat linkovací parametry a vědět/odhadnout, jaká starší verze knihovny mé aplikaci stačí. Vývojářská prostředí tuto databázi nemají, a tak to za mě automaticky neudělají.
> A to ani nehovorim, ze produkcna binarka sa nema buildovat nahodnymi devtools na pocitaci vyvojara, ako ich instaloval as-needed pomocou apt/dnf. Ked uz, tak minimalne v kontajneri so zakladnou, minimalnou distribuciou (napr. ako to robi mock pre redhat distribucie), alebo mat pripraveny chroot len s potrebnymi nastrojmi a SDK v jasne definovanych verziach, tak, aby bol build opakovatelny.
Bavíme-li se o starých aplikacích, tak v té době kontejnery neexistovaly. Můžeme se bavit o instalaci nejstarší podporované verze Linuxu do dualbootu nebo VM (jako primární OS byste ji nechtěl), ale i tak je to práce navíc (odlišnosti distribucí - novější verze jsou si podobnější, ale starší různější), která v jiných OS není. Proti tomu když vím, co moje aplikace potřebuje za verze knihoven, tak žádný dualboot/VM/kontejner nepotřebuju a můžu to říct linkeru.
> No a teraz toto vysvetlite priemernemu windows game developerovi. Nie, nedokaze si vytvorit buildovaci chroot s verzionovanymi SDK a pochybujem, ze ma okolo seba niekoho, koho by sa spytal.
Ano, je problém to vysvětlit 98 % procentům vývojářů, kteří používají primárně jiný OS.
> Ano, tu musim pochvalit ze Microsoft, Apple, autorov Steam runtime a linuxoveho flatpaku, ktori to so svojimi nastrojmi robia by default, zatial co klasicke linuxove distribucie pracuju s trocha inym konceptom. Nastastie, aj to sa uz meni, ale bude tazke vykorenit niektore zvyky, zvlast u ludi, ktori sa nad tym nikdy nezamysleli.
Ano, Linux svůj nesmyslný systém vzdal a teď jede podle systému ve Windows a macOS, kde si aplikace tahá všechno s sebou.
