Názory k článku Ubuntu mění názor: nabídne omezenou podporu 32 bitů ve verzích 19.10 a 20.04 LTS
-
k3dARStříbrný podporovateluzivatele by nen&sral Steam, ale Ubuntu, je to videt napr. z tehle ankety kde z ~5000 hlasujiich, ~1/2 by presla na jine distro + ~1/4 by o tom uvazovala...
https://www.omgubuntu.co.uk/2019/06/steam-drop-ubuntu-support-switch-distro-poll -
Funguje kdyz tam namountujes /dev /sys /proc atd... viz treba https://wiki.gentoo.org/wiki/Steam#Chroot
-
Ondra Satai NekolaZlatý podporovatelProstě odsuneš hnuj do omezené oblasti, kde se o něj bude starat ten, kdo ho potřebuje.
-
Ondra Satai NekolaZlatý podporovatel
Ať to dělá ten, kdo to chce.
Tohle už dávno nemá v obecném systému co dělat.
-
No tak se zeptejte v pneuservisu, kolik stojí podkovy. A pokud je mají, zjistěte, kolik je plat u nich zaměstnanýho kováře, kolik podkov ročně řeší a kde na jeho plat berou... Protože pokud tam náhodou je (pravděpodobnost je stejná, jako že windows Update rok nic nerozbije), skládají se na něho ti, kdo ho nepotřebují.
Ať si koňáci podkovy řeší jak chtějí, já ocením jenom to, že neplatím něco, co nepoužívám.
-
"Prostě odsuneš hnuj do omezené oblasti, kde se o něj bude starat ten, kdo ho potřebuje."
Skvely napad! Takze jeste vcera byla desnym problemem pro podporu her tzv. roztristenost. Kdyz uz se to u klidnilo, tak ted jeste vyvojarum nakaz, ze si budou muset podrebne knihovny a ekosystem pro sve hry zaridit na Linuxu sami v kontejnerech. Jsem presvedcen, ze budou nadseni.
-
Ondra Satai NekolaZlatý podporovatel
Uprimne receno - jake to budou mit hraci/vyvojari her, mi skutecne zily nerve. To uz by mne mohl znervoznovat i nedostatek ledu pro hokejisty nebo chronicka zraneni pri hrani fotbalu.
-
Ondra Satai NekolaZlatý podporovatel
Tak to asi spatne chapes - nemam jakykoli zajem na tom, aby se hracum darilo dobre. Ale mam zajem na tom, aby se zbytecne nehromadil v systemech odpad.
-
k3dARStříbrný podporovatel
jestli v tvem systemu prekazi 32bit knihovna kterou nepotrebujes, tak proc ji mas nainstalovanou? ono totiz mit 32bit balicky v repositarich pro ty co je potrebujou "kupodivu" neznamena ze musej byt v tvojim zprasenem systemu ;-)
-
Ondra Satai NekolaZlatý podporovatel
Jenže dokud v systému/repu zůstává zastaralý bordel, tak se vždy najde nějaký lenoch, co na to bude hřešit.
-
k3dARStříbrný podporovatel
proc mas v systemu/repu zastaralej bordel? myslel sem ze je rec o aktualnich verzich (32bit) knihoven
-
k3dARStříbrný podporovatel
ne, 32bit knihovny pochazeji ze stejnych zdrojaku a jsou buildene stejnym nastrojem jako 64bit knihovny... ten bordel mas asi jinde :-)
-
To, ze spousta lidi potrebuje k zivotu 32bit aplikace je myslim jasny fakt. Dokonce v dnesni dobe je nemala rada lidi, kteri potrebuji dokonce 16bit aplikace (treba https://www.jezeksw.cz/stereo/ :) ).
A komunita okolo Linuxu pritom resi jak se legacy podpory zbavit. Na serverech to asi neni velky problem, ale Ubuntu cili na desktop. Prijde mi to, jako kdyby Skodovka rekla, ze uz bude delat jen TSI motory a zbytek zahodi, protoze motor bez turba je jako ... pocitac bez 64 bitu.
Linux ma i tak myslim dost male zastoupeni a nechapu proc si ho jeste zmensovat. Vlastne chapu, cele to je o emocich lidi "u kormidla". Pritom cest jak udelat "32bit legacy support" daleko cistsi cestou nez to ma Linux ci Windows existuje cela rada (Mac OS/X je jedna z inspiraci - fat binary).
-
Tak ono ani neni potreba pouzivat kontejnery. Staci vsechny potrebny knihovny zabalit do appimage https://appimage.org/
-
Appimage je kontejner úplně stejně jako docker, LXC, snap nebo flatpak. Běží ve svém vlastním jmenném prostoru s omezenými právy a kontrolou přes seccomp. Nástroj, který to v tomto případě nastavuje, je samotný spustitelný soubor appimage. Při spuštění vytvoří kontejner s vlastním jmenným prostorem pro soubory a vlastním mapováním užívatelů, nastaví bezpečnostní omezení, namountuje obsah zbytku appimagu do tohoto kontejneru a v něm pak spustí hlavní exáč. Dlouhou dobu jsem měl Appimage rád, vyrobil jsem i pár balíků, ale pak převládly nevýhody, konkrétně to, že na rozdíl od snapu a flatpaku Appimage negarantuje, že výsledný balík není závislý na distru.
-
To s tím nemá vůbec co dělat. Kontejner nepředpokládá žádný daemon, to je implementační detail. První generace LXC nepoužívala daemon, flatpak (pokud vím) žádný nemá, podman je z definice reimplementace dockeru bez daemonu. Snap používá snapd, ale ten je tam kvůli automatické aktualizaci balíků a různým správním funkcím, ne proto, že by to bez něj nešlo. Rootovská práva k tomu taky nejsou potřeba. Mimochodem existuje nepovinný daemon pro Appimage, který se stará o aktualizace, automatickou registraci položek do nabídky atd. Z koncepčního hlediska se Appimage ze všeho nejvíc podobá snapu, tam je taky každý balík jednoduše archív. Rozdíl je v tom, že snap všechny archívy automaticky a permanentně mountuje do /snap, kdežto Appimage je mountuje do /app jenom když se spustí (a jenom uvnitř kontejneru). U snapu to zajišťuje snapd pro celý OS, u Appimage na to má každý balík kód sám v sobě.
-
A co takhle trochu jiný pohled. Domnívám se, že zaříznout staré architektury by mohli výrobci mikroprocesorů spíš než vývojáři OS. Prosím, i386 má ještě řadu důležitých využití (včetně těch her). Ale proč musí i moderní CPU pořád mít real mode a virtual mode? Jediné, co to přináší, je, že je kvůli tomu procesor složitější, větší a dražší. Přitom to doopravdy už nikdo nepoužívá a pro případný provoz historického software je mnohem jednodušší a uživatelsky příjemnější použít emulátory jako Dosbox. Co kdyby se Intel a AMD dohodli a oznámili, že od příští generace budou jejich čipy podporovat už jenom protected mode (32bit) a long mode (64bit), a řekněme nekdy kolem roku 2025 by mohli i ten protected mode poslat do (|).
-
Celkove by se s tim dalo souhlasit (az na to ze se intel & amd dohodnou :) ), nicmene spousta legacy aplikaci komunikujici s nejakym dalsim zarizenim (medicina, CNC, ...) casto v dosboxu ani podobnych emulatorech/virtualech NEJEDE. Casto proto, ze kod je uzce svazany s tim HW.
Resenim by bylo, kdyby vyrobci CPU (nebo nekdo jiny) udelali emulator (binarni translator), ktery by nebezel pod zadnym OS, tudiz by umoznil delat vselijake prasarnicky s HW.
Dalsi problem je jak by se treba nabootovaly existujici closed-source OS bez UEFI na takovem pocitaci ? Typicky ruzne loadery v boot sektoru apod...
-
Binární translator dneska má každý čip od Intelu s jádrem P6 a jeho novějšími odvozeninami (tj. PPro, P II, P III a celé řady Core a Xeon) stejně jako všechny Ryzeny. Jde o to, že zatím musí emulovat i tyhle 16ti bitové instrukční sady, což, jak se ukazuje, není zas tak úplně jednoduché - na Pentiu Pro to fungovalo fakt mizerně a Intel musel vynaložit nemalé úsilí, aby to trochu optimalizoval pro Pentium II.
K těm OS bez UEFI... tady se to pořád zmiňuje, ale teď vážně, jaký closed source OS bez UEFI podpory se prosím konkrétně chystáte provozovat na high-end počítači zakoupeném řekněme v roce 2020?
A pro ty specializované aplikace, které stále vyžadují 16bitový režim a v ničem jiném nejedou to není žádný velký problém. Nikdo si totiž nejde koupit tuctový počítač, aby si pak stáhl a instaloval takový software. Dodávaly by se a používaly stejně jako dneska: s připraveným a dedikovaným hardware, založeným na Atom Pentiu nebo něčem podobném.
-
No myšlenka, že bych svěřil svůj život DOSBoxu, to už bych si mohl rovnou prohnat kulku hlavou. Nicméně by mě zajímalo kolik takových zařízení bude, já myslím že moc ne, tedy pokud pominu vsemozny lékařský software evidence napsaný ve FoxPro, nějaká historická sono zařízení, které by ale stejně měla být vyměněna za novější modely.
-
Ondra Satai NekolaZlatý podporovatel
Navíc bych čekal, že AMD i Intel budou další století dodávat pár "starých" modelů pro podobné použití (zastaralý proces odolný proti EM šumu, nasmlouvané dodávky na desítky let, žádné vychytávky... prostě to, co medical nebo aerospace rád draze zaplatí).
-
Binarnim translatorem jsem myslel SW reseni (qemu, vmware, sun wabi, FX!32) - to jen reakce na predchozi comment. Nevim jestli zpracovani mikrokodem ci ty dekodovaci bloky x86 lze nazvat translatorem. Toto reseni by mohlo docela snadno fungovat i u tech obskurnich aplikaci.
Treba na QNXu bezi hodne veci z teto sfery a UEFI pokud vim prislusne verze nejsou.
Medicinske veci jsem videl bezet ve Virtualboxu (slo tusim o nejake zarizeni na analyzu krve nebo tak neco). Nechci tu obhajovat zpetnou kompatibilitu jak to mozna vyzniva, ale tech zarizeni bude mnohem vice, nez si asi bezny clovek umi predstavit. Staci se projit v prumyslu, zdravotnictvi, nebo navstivit nejaky vyzkumak. Nicmene i tak primarni prusvih je casto absence ISA slotu, takze tam casto stejne konci ruzna stara PC ze sklepa apod.
Perlicka - nedavno mi volal jeden znamy a shanel se po Hercules monitoru - ma zarizeni (=asi pocitac?) na diagnostiku nejakych starych Porsche a monitor mu nekdo vyhodil jako "nepotrebny".
-
Hercules/MDA monitor už bude těžko k sehnání. Existují naštěstí převodníky na VGA, třeba MCE2VGA.
Zbavit běžná PC reálného režimu by nebylo špatné. Jen minimální firmware a zbytek by převzal operační systém.
Stejně tak by nebylo marné, aby grafické karty už nemusely být plně kompatibilní s VGA na úrovni registrů. Nějaké jednoduché univerzální API (miniVESABIOS ?) na vykreslování by ale být muselo - obraz je jaksi potřeba ještě před zavedením OS a před zavedením ovladačů operačního systému."PC ze sklepa" už jsem taky viděl v podnikovém nasazení. Prastarý docházkový systém připojený přes sériový port s obslužným software pro DOS. V tomhle případě by ale byl možný běh v DOSBOXu.
