Arch Linux ukončil podporu i686

Arch Linux dnešním dnem oficiálně ukončil podporu architektury i686. Koncem listopadu budou i686 balíčky odstraněny ze zrcadel. Uživatelům 32bitových systémů je doporučován přechod na komunitní Arch Linux 32.

8.11.2017 17:55 | Ladislav Hagara | Komunita

Komentáře

[Michal Kubeček]

Slovy klasika: "To zas bude dopisů…" :-)

[Max]

Celkem správný krok. Linux byl mezi prvními s 64bit podporou včetně aplikací. První 64bit CPU pro x86 byl někdy v roce 2003, což už je krásných 14 let. Multilib zůstává, takže provozovat 32bit app v 64bit systému nebude problém.
Kdo chce být dnes extra spořivý, jede stejně arm.
Každopádně by mně i tak zajímalo, kdo dnes kde/na čem provozuje 32bit a jaký má k tomu důvod? Skutečně mně to zajímá, nechtěl bych popichovat, mně nic nenapadá, ale to ještě neznamená, že se nějaký důvod nenajde.
Díky
Zdar Max

[Franta Hanzlík]

i686 Linuxů provozuji celkem dost. Některé mají dost málo RAM (512-2048 MB) - ale v pohodě zvládají, co potřebuji, některé běží jako LTSP terminály, na některých běží emulátor DOSu a v něm DOS appky, pár mašin běží jako servery v runlevel 3 a víc zdrojů nepotřebují...

Jak na tom pracuje zub času a některé odchází, tak nástupce už je často AMD64 Linux, ale ty 32-bitové mi počítám ještě chvíli vydrží. Jak řekl jeden velký myslitel - nechápu, že někdo potřebuje víc než 1MB operační paměti :)

[Harvie.CZ]

U toho LTSP to je problem no. Hlavne 64b ltsp image mely nakej problem a ruzne tam zlobil zvuk a obraz. Nakonec sem to vyresil 32b imagema, ktery fungovaly lip i v kombinaci s 64b ltsp serverem.

[Jendа]

kdo dnes kde/na čem provozuje 32bit

Asus EEE 1005HA s Atom N270 a donedávna nějaký Alix.

a jaký má k tomu důvod?

Že ten procesor je, eh, x86_32?

[Jendа]

A jo, to jsem zapomněl: brmbar je notebook s Celeron M a ještě existuje jeden server s Pentiem III.

[R]

Takmer vsetky PC, co pouzivam, maju 32-bitove CPU. P3 Celerony, notebooky Pentium M, netbook Celeron M.

Nastastie nepouzivam Arch. Dufam, ze v Debiane sa do tohoto "vylepsenia" nebudu hrnut s rovnakym nadsenim ako do implementacie systemd.

[tomo_tn]

IBM xserver 225 2x pentium4 xeon 3.05ghz 8GB ram NVidia 730GT DDr5 2GB ram HW raid z 128MB cache :)

Linux slackware desktop v ktorom bezi catia.

Dovod -- dostal som "to" zadarmo, trocha upgradol a vykonovo mi to v pohode stacsi. Kompilovanie sice trva ale nic nezvladnutelne.

[Michal Kubeček]

vykonovo mi to v pohode stacsi

Hlavně když vy tomu budete stačit příkonově. :-)

[little.owl]

[tomo_tn]

TDP je +- rovnake ako nove procesory, "len" ich tam je cca 8x menej :)

[Michal Kubeček]

TDP možná, klidová spotřeba ani omylem.

[R]

Tie Xeony nemaju 64b? Mame nejake stare servery HP ProLiant ML150 G2, kde su Xeony 3.00 GHz a tie su 64b.

[platYpus]

Nižší spotřeba RAM. Menší velikost binárek. Podpora starších strojů, zejména NTB. Arch nepoužívám, i když je to hezký systém (takže se tím netrápím ). Pouze jsem napsal své důvody, když jsi se ptal ...

[Franta Hanzlík]

Mně se taky líbil, hlavně jeho pěkně udělaná dokumentace (IMO). Ale pak přešel na systemd...

[boycottsystemd]

Je možný porovnat i teploty CPU, spotřebu ? (Záleží na tom třeba při celodenním provozu v neklimatizované místnosti při letních vedrech)

[Pavel 'TIGER' Růžička]

Po zákaznících vozím staré Lenovo Ideapad S10e se 128GB SSD ... na diagnostiku, konfigurace a podobné věci je plně vyhovující. Netřeba 64bit. Nicméně ten krok plně chápu. Pořád je z čeho vybírat, není důvod k panice.

[R]

Pokial nezrusi podporu i386 Debian, tak je stale dobre... Inak uz len prechod na Windows 10 :D

[Pavel 'TIGER' Růžička]

Ses asi zbláznil, ne? V 10 každá výroční aktualizace rozdrbe nastavení systému. Takže 2x do roka jak debil musíš vypínat, co sis vypnul, odinstalovat, co sis odinstaloval ... atp. I kdyby Debian zrušil i386, pořád máme BSD.

[R]

Ked skonci Debian, tak sa na cele IT vyseriem a pojdem asi pestovat papriky... Ked vidim tie tzv. moderne javacsriptove sracky s pribalenym browserom ("aplikacie"), sukromne data uploadovane do nadnarodnych firiem a pod.

[Pavel 'TIGER' Růžička]

S tím mohu jen souhlasit, navíc je to všechno jen v alfa, či beta verzi. Nesmyslně se pořád dokola vymýšlí kolo ...

[pepe_]

Třeba   https://www.asus.com/cz/support/Download/30/39/0/167/UrYgCG9yU9Yf92Qy/29/   nepodpora VGA ve win10 a celé to jde do kopru.

[Kate]

Těch 32 bitů je docela dost, ale většinou v použití kde se Arch vážně nehodí :)

[Nicky726]

Tak posledních 32bitových počů jsem se zbavil v létě. Teď mi ještě zbývá jeden systém, který sice běží na 64bitovém poči, ale protože jsem ho přenášel z 32bitového, tak je tam holt i686 Arch.

[Kate]

Arch se dá na x86_64 konvertovat, i když to není úplně bez rizika.

[marfus]

Mám tři archové 32-bit instalace . Té nestarší je cca 9 let, upgrady po týdnu.. Ještě zkusím archlinux32, uvidíme. Jinak na starých mašinách už stejně migruju na *BSD ..

[unicode]

Ten progress tam podle mě je. Na webdev vůbec není špatný, ale na C++ mám radši KDevelop. Co mi chybí obecně u C++ IDE pod linuxem je dobrý debugger s disasm view (včetně krokování atd). V současnosti celkem trpím při ladění JIT kódu a někdy uteču do windows a udělám to radši ve VS.

KDevelop má na druhou stranu užásný syntax highlighting (hlavně proměnné), někomu nemusí sednout, ale já si to nemůžu vynachválit.

[unicode]

To patří k jiné zprávičce, sorry.

[kralyk z abclinuxu]

Co mi chybí obecně u C++ IDE pod linuxem je dobrý debugger s disasm view (včetně krokování atd). V současnosti celkem trpím při ladění JIT kódu a někdy uteču do windows a udělám to radši ve VS.

Zkoušel jsi QtCreator? Já ho teda už pár let nepoužívám, ale co vím, tak věci jako krokování v asm i zdrojáku atp. by měl umět...

[Andrej]

Pro některé notorické křiklouny by měla tahle "zprávička" viset jako upozornění přinejmenším u každého dotazu, který se týká volby distribuce. Už si živě představuju, jak se tu zas a znova objeví klasický vzorec "debaty" ve stylu:

BFU: Nainstaloval jsem si tuhle včera 32-bitové SuperDistro 1965.04 (z originální gramofonové desky) a nefunguje mi tam… [dlouhý výčet — pozn. red.]
Většina diskutujících: No, podívej, raději si nainstaluj hned od začátku 64-bitovou verzi, jinak budeš mít víc problémů než užitku. Není se čeho obávat; tohle nejsou Shitdows, kde 64-bitový systém znamenal problémy ještě asi tak do loňského jara; 64-bitový Linux funguje spolehlivě už přes 10 let. [Na platformách jiných než Intel 15 let. — pozn. red.]
Několik notorických křiklounů: Ne, ne, ne, rozumných rad si nevšímej, jen si tam klidně podle gusta nainstaluj 32-bitový systém, zkrátka jen tak, pro nic za nic, když se zrovna dneska na těch 64 bitů necítíš. [Jinými slovy: Jen klidně odboč do slepé uličky plné problémů, to mě nezajímá. — pozn. red.]

[R]

Jeden notoricky kriklun: Vsetko je sracka a nefunguje, lebo je to stare viac ako 24 hodin. Nainstaluj si Arch, ten jediny funguje.

[Andrej]

Kdo a kde tvrdil něco takového? Myslím, že nikdo nikde. Jenom zase nějaký anonym fabuluje.

Nebo to měla být názorná ukázka, co znamená rčení o potrefené huse? Jo, to by mohlo být ono.

[Jendа]

Tento „argument“ lze použít též pro ukončení podpory ARM portů („Nainstaloval jsem si tuhle včera ARM SuperDistro 1965.04 a nejde nabootovat“).

[Andrej]

Kontext debaty je celkem bezesporu architektura Intel. O podpoře 32-bitových ARM tu nebyla řeč. Mobily už jsou sice dnes 64-bitové, ale 32-bitové ARM tu ještě dlouho budou.

Takže ne, můj argument (samozřejmě bez uvozovek) nelze použít na ARM.

[Pavel 'TIGER' Růžička]

To 32-bitové Intely tu budou také ještě dlouho, jen na nich nebude co spouštět. U toho 32-bitového ARMu bych si jeho životností nebyl tak jist, abych tvrdil, že tu bude ještě dlouho.

[Andrej]

Když tu definici 32-bitových ARM vezmu dostatečně zeširoka, tak v mých dronech budou ještě fakt hodně dlouho. Betaflight totiž nebude 64-bitový asi ani za uherský rok. Ono s takovými 192 kB RAM by to nemělo smysl. (A BLHeli letos přechází od 16 bitů na 32 bitů; jaká to sláva.)

Ale pravda je, že tohle s Linuxem nesouvisí až tolik.

[little.owl]

To 32-bitové Intely tu budou také ještě dlouho,

\ Nebudou, bude tu dlouho 32-bitovy kompatibilni mod.

[Jendа]

Takže se může stát, že si někdo omylem stáhne i686 verzi, ale ne, že si omylem stáhne arm64 verzi? V dobách Itania jsem tu několikrát zmatení mezi amd64 a ia64.

[k3dAR]

je "trochu" demagogie srovnavat(i kdyz s nadsazkou) "32bitove ~50let stare distro" a "64bitove ~5mesicu stare distro"
ono at se ti to libi nebo ne, pro vsechny BFU a pro naprostou vetsinu PowerUseru, bude duvodem proc NEnainstalovat 32bit distro jedine to ze NEni dostupne... nikoliv nejake technicke nedostatky 32bit... jasne ze pokud to CPU umoznuje (a to umoznuje skoro vsechny uz dlouho), muze nainstalovat 64bit, ale v podstate jedine co mu to prinese navic, ze 1% z nich si muze pustit ty ~3 programy co jsou jen v 64bit ano taky trochu s nadsazkou :) proste je zbytecne vnucovat ze 32bit je pro bezne pouziti jakkoliv problematicke a ano stejne tak se da rict ze je (vetsinou) zbytecne nepouzit 64bit... v podstate se da rict ze je to jedno ;)

[Andrej]

Ne všechno, co se dá říct, je nutně pravda. Tvrzení, že je jedno, zda si uživatel nainstaluje 32-bitové nebo 64-bitové distro, je v podstatě nesmysl. Ono to není jedno.

Možná nejdůležitější argument z pohledu BFU může být, že v 32-bitovém systému 64-bitové programy nespustím, zatímco naopak to bude fungovat bez problémů.

4 GB na proces je dost ošklivé omezení, přes které nejede vlak. Strojů s 4 GB RAM nebo méně už není mnoho, takže nutně přijde na řadu PAE — s limitem 64 GB, který je z dnešního pohledu taky hodně blízko. To je ale nakonec jedno, protože 4 GB na proces stejně všechno zkazí. (Na desktopu mám teď 128 GB, takže ani PAE už nepomůže. Pravda, není to BFU desktop.)

Existuje argument, že browsery jsou víceprocesové, pročež jim limit 4 GB na jeden proces nebude vadit, pokud žádný z tabů nebude moc náročný. Ano, ale všechno jednou skončí, dřív nebo později.

Říkat novým uživatelům, že 32 bitů je v pohodě, je zkrátka špatně. Pokud chci nově zprovozněný stroj bez zásadních změn jenom aktualizovat a provozovat (dejme tomu) tři roky, 32 bitů není dobrý nápad. Dostupnost 32-bitového softwaru bude problém dřív než za 3 roky, jak naznačuje (nejen) tahle "zprávička", a 4 GB RAM na proces jsou problém už teď.

[k3dAR]

jiste ze v budoucnu to bude horsi, ale ze by za 3roky bylo rapidne vice app kompilovanych jen pro 64bit se nebojim, to je jako si vzpominam na diskuzi s jednim zapalencem/prukopnikem pred 20+ rokama co rikal, "IPV6 za par let nahradi IPV4 ktere zanikne" a jak to dopadlo asi vsichni vime

jak tech 128GB tak i >8GB RAM neni bezne pro BFU, casto maji 4GB nebo i 2GB RAM a ze by pro jejich kancelar/internet/media bylo nejakym limitem 4GB na proces take neni moc realne :)

takhle spravicka sice neco rika, ale Arch take neni moc pro BFU, ted nejcasteji (i kdyz se ti to nelibi a/nebo to popiras) nainstaluje *buntu/Mint, buntu sice zarizlo 32bit ale jenom Ubuntu-Desktop, jeho odnoze jsou stale dostupne v 32bit, balicky v 32bit a vsechny ostatni moznosti instalace (i kdyz ne vsechny jsou pravda pro BFU) take 32bit jdou (minimal, alternate, doinstalovani ubuntu-desktop z odnoz-desktop-32bit.iso)

muzu souhlasit s tim ze je dobre BFU vychovat v to ze 32bit jsou jiz zbytecne, v budoucnosti se s tim nepocita a je dobre je zacit ignorovat, coz je take v podstate jedinej duvod proc se 32bit zaclo zarezavat, nejsou to technicke problemy ktere ses tvaril ze je prioritni, na coz sem primarne reagoval BTW: mam 64bit na netbooku s Atomem a 2GB RAM a samozrejme to neni problem ani malo RAM pro 64bit, to jen aby to nevyznelo ze preferuju 32bit do 8GB RAM :)

[Michal Kubeček]

vzpominam na diskuzi s jednim zapalencem/prukopnikem pred 20+ rokama co rikal, "IPV6 za par let nahradi IPV4 ktere zanikne" a jak to dopadlo asi vsichni vime ;-)

To je spíš k pláči než k smíchu. Pokud bychom pod dojmem toho, že ještě v roce 2017 většina lidí bere IPv6 jako nějaký experiment pro pár bláznů nebo že ještě v roce 2017 každou chvíli slyším "mně ifconfig stačí, nepotřebuju se učit nějaké novoty", usoudili, že je jakýkoli pokrok nemá smysl, můžeme to rovnou zabalit. (Neodpustím si rýpnutí: do stejné škatulky řadím i to, že ještě v roce 2017 spousta lidí "pise cesky".)

jak tech 128GB tak i >8GB RAM neni bezne pro BFU, casto maji 4GB nebo i 2GB RAM a ze by pro jejich kancelar/internet/media bylo nejakym limitem 4GB na proces take neni moc realne

Přímo tady na ABCLinuxu můžete najít dotaz uživatele, který měl stroj s 2 GB paměti, spoustu volné a selhávalo mu přidání pravidla netfilteru na ENOMEM. A ano, kdyby měl 64-bitový systém, nestalo by se mu to. (On tam aspoň měl 32-bitový procesor, kdyby ten 32-bitový systém běhal na 64-bitovém procesoru "kvůli úspoře paměti", jak s oblibou radí místní "znalci", dodalo by to problému nádech absurdity.)

takhle spravicka sice neco rika, ale Arch take neni moc pro BFU

Pro pořádek: Arch není v tomto směru nějaký průkopník, jen další v řadě.

Ubuntu sice zarizlo 32bit ale jenom Ubuntu-Desktop, jeho odnoze jsou stale dostupne v 32bit, balicky v 32bit a vsechny ostatni moznosti instalace (i kdyz ne vsechny jsou pravda pro BFU) take 32bit jdou (minimal, alternate, doinstalovani ubuntu-desktop z odnoz-desktop-32bit.iso)

Takže na jednu stranu argumentujete BFU, na druhou nad tím, že zrovna ta možnost, která je pro ně primárně určená (a kterou většina z nich využije), je v rozporu s tím, co se snažíte tvrdit, mávnete rukou?

nejsou to technicke problemy ktere ses tvaril ze je prioritni

Jsou to primárně technické problémy. Právě ty technické problémy se promítají i do těch netechnických.

Ještě jeden důležitý úhel pohledu, který tu zatím nezazněl, a námět k zamyšlení:

• naprostá většina upstreamových vývojárů, ať už jádra nebo userspace, dnes žádný 32-bitový systém neprovozuje a software na něm během vývoje netestuje (a často na jejich existenci ani moc nemyslí)
• enterprise distribuce od roku 2014 (RHEL7, SLE12) nejsou vydávány (a tedy ani vyvíjeny a testovány) pro žádnou 32-bitovou architekturu; nebo jinak: nenajdete 32-bitovou enterprise distribuci s jádrem novějším než 3.0
• i ty distribuce, které ještě stále i586 (i686) vydávají, věnují testování této architektury podstatně méně prostředků než x86_64; např. v openQA se víceméně testuje jen jestli vůbec projde build, půjde to nainstalovat a nabootovat a pustí se pár základních testů
• totéž se dá říci o uživatelích testujících pre-release verze; i586 z nich testuje jen menšina a i ta se většinou primárně zaměří na x86_64

Řečeno bez obalu: nainstalováním 32-bitového systému se dnes v podstatě dobrovolně hlásíte do první linie distribuční QA, ať už si to uvědomuje nebo ne. Je to něco, co byste doporučil BFU?

[k3dAR]

že ještě v roce 2017 spousta lidí "pise cesky"

a nekteri dokonce chodi pesky

selhávalo mu přidání pravidla netfilteru na ENOMEM

to jiste potkava BFU 3x za den

Pro pořádek: Arch není v tomto směru nějaký průkopník, jen další v řadě.

Pro poradek: reagoval sem na: jak naznačuje (nejen) tahle "zprávička"

Takže na jednu stranu argumentujete BFU

Na druhou stranu, ja vsem BFU doporucuju Xubuntu ktere primarni moznost instalace z Live-Desktop v 32bit ma (tim nerikam ze doporucuju 32bit)

Jsou to primárně technické problémy

Provozuju 32bit Xubuntu v praxi a na zadne technicke problemy sem nenarazil a cast z meho pouziti jiste pokreje 99.999% pouziti BFU

[Michal Kubeček]

že ještě v roce 2017 spousta lidí "pise cesky"

a nekteri dokonce chodi pesky

To je snad něco trochu jiného. Chození pěšky by se dalo přirovnat k psaní rukou - a rukou "cesky" moc lidí psát nevídám.

selhávalo mu přidání pravidla netfilteru na ENOMEM

to jiste potkava BFU 3x za den

Možná ne, ale na tentýž problém (nedostatečná velikost adresního prostoru a zejména jeho části vyhrazené pro vmalloc()) může narazit i jinde.

Provozuju 32bit Xubuntu v praxi a na zadne technicke problemy sem nenarazil a cast z meho pouziti jiste pokreje 99.999% pouziti BFU

Já holt tolik drzosti, abych o sobě něco takového tvrdil, nemám. Naopak, běžně se setkávám s tím, že BFU dokážou odhalit problémy, na které problematiky znalý uživatel nemá šanci narazit, protože by ho něco takového nikdy nenapadlo udělat.

[little.owl]

Naopak, běžně se setkávám s tím, že BFU dokážou odhalit problémy, na které problematiky znalý uživatel nemá šanci narazit, protože by ho něco takového nikdy nenapadlo udělat.

To vysvetluje proc u poloviny nasich testeru z QA taemu mam pocit ze jsou mentalne retardovani ...

[k3dAR]

a vazne "psani cesky" nebylo neco jineho nez IPV6?
kde ze konkretne BFU muze narazit na nedostatecnou velikost adresniho prostoru u 32bit?
to neni o drzosti, ale o racionalni uvaze v kontextu narozdil od te tve offtopic

[Michal Kubeček]

a vazne "psani cesky" nebylo neco jineho nez IPV6?

Ani ne. Někdy v polovině 90. let se dalo celkem pochopit, že má někdo technické problémy psát pořádně česky nebo že se (bohužel oprávněně) bojí, že by mohla mít druhá strana problém si to přečíst. Ale v roce 2017? A s IPv6 je to přesně totéž - jen ten problém primárně není na úrovni koncových uživatelů, ale ISP a poskytovatelů služeb. Také už to dávno není o skutečných technických důvodech, ale o tom, že je někdo líný nebo že na to kašle.

kde ze konkretne BFU muze narazit na nedostatecnou velikost adresniho prostoru u 32bit?

Např. kdekoli, kde to ve výsledku povede na větší využití vmalloc(). Vzhledem k tomu, kde všude se vmalloc() používá, bych si na rozdíl od vás nedovolil mávnout rukou, že to přece BFU nemůže potřebovat.

to neni o drzosti, ale o racionalni uvaze v kontextu narozdil od te tve offtopic

Možná ne o drzosti, možná by výstižnější termín byl "nedostatek soudnosti". Právě proto, že ze zkušenosti vím, že tvořivost BFU dalece přesahuje meze mé představivosti, vám neřeknu zcela konkrétní příklad, který přímo povede na problém s i586, ale jen pro představu: napadlo by vás vzít image CD (plného, 650 MB) a rozeslat ji e-mailem všem ve firmě?

[Jendа]

ale jen pro představu: napadlo by vás vzít image CD (plného, 650 MB) a rozeslat ji e-mailem všem ve firmě

To není dobrý příklad, protože když poštovní server takovou zprávu odmítne, tak je to dobře. Když selže alokace paměti, tak to většinou dobře není.

[trekker.dk]

Otázka je, jestli se stalo zrovna to, že poštovní server tu zprávu odmítnul...

[trekker.dk]

A i kdyby jo, předmětem debaty není, jestli to je nebo není dobře, ale jestli by technicky zdatného uživatele (narozdíl od BFU) napadlo něco takového vůbec udělat.

[Michal Kubeček]

Kdyby stalo, tak bych už na tenhle šílený nápad nejspíš dávno spokojeně zapomněl. :-)

[trekker.dk]

Někdy v polovině 90. let se dalo celkem pochopit, že má někdo technické problémy psát pořádně česky nebo že se (bohužel oprávněně) bojí, že by mohla mít druhá strana problém si to přečíst. Ale v roce 2017?

V principu bych souhlasil, ale právě jsem se pokusil přes SSH z desktopu otevřít český text, který jsem na ten server nahrál přes SSH z notebooku. Na to, že všechny tři ty stroje mají pracovat v UTF-8, to moc dobře nedopadlo...

[kralyk z abclinuxu]

Tenhle problém bývá* způsoben tím, že ssh forwarduje locale proměnné (LC_*), ale když na cílovém stroji není nainstalován příslušný locale, použije se nějakej fallback, kterej nemusí bejt utf-8.

[k3dAR]

neboj, mam dostatek soudnosti ~15 let sem se staral o ~250 (za tu dobu samozrejme promenlivejch) uzivatelu vseho pohlavi a rozmezi 18 az ~70 veku, kdy sem chodil resit napr. i to ze se zacla chovat mys na obrazovce divne, tak sem prisel a otocil ji kabelem od sebe ve spojeni s moji schopnosti empatie mam myslim dostatecne povedomi o tom co, jak a proc BFU delaji
napadlo by me ze to nekdo udela, pred ~10lety sem resil ze pro BFU bylo potreba zvedat limit pro prilohy na email na 100MB, protoze nekdo posilal "nekomprimovanej TIFF" nicmene takove situace s 32bit na stanici nesouvisi... tedy ani s tim ze si me nepravem osocil ze sem drzej/nesoudnej ohldne potreb/chovani BFU

[Michal Kubeček]

Tím spíš mne překvapuje, že i při tak bohatých zkušenostech pořád ještě věříte, že jste schopen předvídat cokoli, co je BFU schopen vymyslet (a zkusit).

[kralyk z abclinuxu]

kde ze konkretne BFU muze narazit na nedostatecnou velikost adresniho prostoru u 32bit?

Tak například při hraní her si to umím docela představit.

[kralyk z abclinuxu]

_{(Inb4 hráči her nejsou praví Skotové.)}

[little.owl]

Řečeno bez obalu: nainstalováním 32-bitového systému se dnes v podstatě dobrovolně hlásíte do první linie distribuční QA, ať už si to uvědomuje nebo ne. Je to něco, co byste doporučil BFU?

+1 Presne tak. Nam dodavatele vyvojovych SDK pro cross-compilaci dodavaji 32-bitove verze nastroju, ktere ale testuji jen na 64-bitovych instalacich s 32-bitovou kompatibilni vrstvou. Pokud to date na skutecne nativni 32-bit, zacnou se objevovat ruzne podivne problemy a odpoved je 'oficialne nepodporovano'.

[little.owl]

pred 20+ rokama co rikal, "IPV6 za par let nahradi IPV4 ktere zanikne" a jak to dopadlo asi vsichni vime

Infrastruktura ma dlouhou setrvacnost.

[BFU]

> Možná nejdůležitější argument z pohledu BFU může být, že v 32-bitovém systému 64-bitové programy nespustím, zatímco naopak to bude fungovat bez problémů.

Ne nutne, existuji standardni aarch64 systemy ktere podporu pro aarch32 nemaji, protoze to standard umoznuje.

[Andrej]

Já si samozřejmě kompiluju kernel bez podpory 32-bitových programů, protože žádné nepoužívám. Takže ano, ta možnost tu je a ušetří dokonce pár instrukcí při context-switchingu nebo při spouštění procesů.

Ale když si v tom Archu, který tady zrovna mám, nabootuju implicitní distribuční kernel (místo toho "mého"), podpora pro 32-bitové aplikace tam bude. Totéž ve Fedoře, SUSE, Ubuntu. Tohle asi hned tak nějaká distribuce ve svém standardním kernelu nezruší.

Ještě by se možná dalo pro úplnost vzpomenout na jediný systém, který měl 32-bitový kernel a možnost spouštět 64-bitové binárky. To byl Mac OS X velmi dávno. Ale prý to moc dobře nefunfovalo.

[Jendа]

Přinese mu to navíc větší výkon (víc širších registrů, povinné SSE2, přímý přístup kernelu k veškeré paměti), například u x264 je ten rozdíl dost zásadní.

[k3dAR]

na druhou stranu, je ten vykon videt u bezneho BFU usecase? ja mam treba na 5let stare i5-2520m+16GB+SSD 32bit system, nenarazil sem na to ze by mi schazel vykon ani kdyz pustim nekolik virtualu, nerikam ze nejsou aplikace a pouziti kdy to muze (a jiste je) sakra znat, ale jsou to situace u BFU? u tech filmu mozna, nevim si je poustim do FullHD (rozliseni LCD) na 7let stare ITX desce s Atom+ION2 nebo na RPi3, na obojim 32bit system

[Andrej]

Asi by to chtělo srovnat obojí nějakým benchmarkem. Je jistě fair dodat, že 32-bitové systémy jsou v některých algoritmech rychlejší než 64-bitové, protože v některých případech (zejména pokud jde o velikost pointerů) dovedou efektivněji využít řadič paměti; prostě toho po něm chtějí méně.

Jiná spousta algoritmů zase vyhraje na 64 bitech, protože sice mají větší pointery, ale ta spousta dalších registrů to nakonec vykompenzuje. Procesor počítá mnohem víc aritmetiky v registrech a přístupů do paměti je pak (na celkový počet instrukcí) méně.

Nakonec ale asi nejde o absolutní výkon. Stroj, který uvádíš, podle mě dá FullHD levou zadní a nejde o to, že by ten výkon byl jen tak tak těsně na hraně a že by každý koušek efektivity rozhodoval. Jde spíš o to, jak nemít omezení 4 GB na proces. Což bude BFU zajímat třeba u ripování BluRay a komprese (ne-li editace) videa.

[k3dAR]

tak je jiste z technickeho hlediska, navic z pohledu programatora (coz ja nejsem) je 64bit jedina volba, ja ale prvotne reagoval na tve (mejma slovama) "BFU ma zbytecne spoustu problemu s 32bit", pokud bys napsal (i kdyz je to pravdepodobne to co si chtel v principu rict) "je dobre tlacit/informovat BFU ze 32bit jim v budoucnu budou prinaset vice a vice problem a ze v naproste vetsine jejich pripadu k NEpouziti 64bit NEmaji zadny duvod" tak bych plne souhlasil, to je prave to proc chapu tyto kroky o ukonceni podporu 32bit ze strany distribuci...

[little.owl]

je ten vykon videt u bezneho BFU usecase?

Tusim ze u x264 prechod z 32-bit na 64-bit udela asi 15-20% navic, coz je uz v praxi videt.

[Andrej]

Další notoricky známý příklad kolem výkonu je třeba ZFS deduplikace. Ta snad ani na 32 bitech vůbec nejde. (Pravda, ZFS není BFU technologie, ale právě to je asi škoda, protože zrovna tohle by se pro BFU hodilo.)

Taky jde o to, že všechny přístupy k souborům (klidně i read()) jsou v moderních kernelech řešené pomocí mmap(). No a zatímco v 64-bitových systémech je(*) možné nechat v postatě všechny soubory, ke kterým se kdy přistupovalo, namapované napořád (== do konce uptime), kdyby je ještě někdy v budoucnu někdo chtěl, na i686 je to ošklivý problém, protože cokoliv nad (řádově) 512 MB se bude muset celkem často přemapovat. To je ošklivé pro velké videosoubory (což se týká BFU) a třeba i pro databáze (což se týká BFU o něco méně).

(*) stále ještě, většinou, pokud nechceme mmap()ovat třeba celé úložiště větší firmy a pokud shovívavě přehlédneme x68 adresní díru

[Jendа]

Při použití standardních 4KiB stránek sežere nammapování standardního dnešního desktopového harddisku (16 TB) asi 32 GB RAM na pagetables. Takže ne, není dobré nechat nammapované všechno co se kdy četlo.

[Andrej]

No, mému oblíbenému desktopu by to moc nevadilo. 32 GB je jenom čtvrtina RAM. Btrfs RAID5 tam má sice 25 TB, ale 16 TB dat tam ještě není ani náhodou, takže to asi nebudu zkoušet. (Natož abych to všechno četl během jednoho uptime.) Teoreticky, kdybych to všechno během uptime přečetl, by se to mmap()nout (a nechat v tabulkách) dalo. Máš ale naprostou pravdu, že vyplýtvat 32 GB jenom na stránkovací tabulky (místo na cache přímo těch dat) by bylo hloupé.

[kralyk z abclinuxu]

proste je zbytecne vnucovat ze 32bit je pro bezne pouziti jakkoliv problematicke a ano stejne tak se da rict ze je (vetsinou) zbytecne nepouzit 64bit... v podstate se da rict ze je to jedno ;)

Kromě zmiňovaného výkonu bych zmínil taky bezpečnost, konkrétně ASLR. AFAIK obejít ASLR je na 32 bitech mnohem snažší, protože toho prostoru pro randomizaci tam je prostě hrozně málo.

[kralyk z abclinuxu]

Zprávička mi přijde mírně bulvární v tom, že to zní, jako kdyby Arch najednou utnul podporu i686. Přitom tohle je pouze zakončení 9-měsiční doby, po kterou bylo jasné, že k tomu dojde. To mi přijde jako dostatečná doba se s tím vyrovnat (minimálně vzhledem k povaze distra, Arch koneckonců není žádný Debian).