Názory k článku Soumrak 32 bitů: podpora staré architektury je na ústupu

Na to sa mali vy**** už dávno, kto by preboha pchal modernú nabobtnanú distribúciu na Pentium 4 (pokiaľ viem tak je to najsilnejší 32bit) ?

Třeba já.
IBM Z60m, s procesorem T2300.
Naprosto luxusní mašina.
Není důvod se jí zbavovat.

Jo taky tu mám jeden záložní Dell s procesorem T2300
Na net a office naprosto stačí

Jo mimochodem ta K6 na obrázku nahoře už podporovaná není mnohem dýl, protože nemá CMOV
Leda si všechno překompilovat s kompatibilitou

To tam máte ten T2300 naletovaný jako BGA? Já jsem si ve svým kompu už dávno vyměnil Core za Core2 Duo (tedy 64bit). Podle wikipedie by měl být T2300 socket M, takže nejrychlejší socket M model je T7600G s odemčeným násobičem, běžícím na 3.16 GHz.

OT: kdyby někdo udělal adaptér na socket P, tak by tam možná běžel až Core2 Extreme (i když teda kdoví co všechno u toho dual penrynu na protokolové úrovni změnili)

Zlomovy byl Opteron od AMD, kterym donutili Intel akceptovat 64bit hardware.
Pentium 4 v jakekoliv podobe byl nejvetsi smejd Intelu vsech dob.

Intel Quark uz je mrtvy ... plus sam o sobe byl tak buggy ze bez specialne patchovane glibc jsi na tom stejne linux nerozjel :)

A jak zminili jini P4 prelom nikdy nebyly a prvni P4 s inteli implementaci AMD64 nebyly plne kompaktibilni s x86_64 ( a k tomu ani prilis efektivni)

To máš pravdu, ale kto by tam preboha pchal mainstreamovú linuxovú distribúciu?!?

Space aplikace? To je kravina. Tyto veci do kosmu nelitaji. Prilis vysoky stupen integrace a zadne stineni proti radiaci. To muze byt maximalne pro pozemni systemy. Je jen malo procesoru stinenych a certifikovanych svabu pro tyto aplikace.

Pro zajímavost, co už lítalo nebo lítá v kosmu:
http://cpushack.com/space-craft-cpu.html

Je tam mockrát zmíněn 386, ten má ještě rozumně nízkou integraci (a navíc ty projekty jsou někdy hodně staré).

Ale fakt to moc nesouvisí s desktopovými a serverovými distry :-)

...Pokud pomineme starý hardware, pak uživatelé buď používají starou architekturu ze zarputilosti nebo spíš omylem. Jsou zvyklí při stahování instalačního obrazu klikat na číslo 32, tak to dělají. Bez ohledu na to, že tak dávno činí zbytečně.....

ach jo, ja uz se do tohohle sveta fakt nehodim.

Mám starý Atom-ový noťas. Funguje, tak 32 potřebuju.

Je to opensource. Tak jakýpak problém že?

V našej firme sme od zákazníka dostali v lete ich starý server, aby sme im nainštalovali demo lekárskeho systému. SCSI 320 som ešte rozchodil, ale keď som zistil, že mám len 32bit procesor...
Posledná inštalácia na serveri v 32bitoch bola u nás v roku 2011. Je otázne, či by nám všetko fungovalo rovnako, keď máme niektoré boolean premenné uchované vo veľkých číslach... Budú sa unsigned long správať rovnako na 32 aj 64bit? Máme niekde v databáze už vyšiu hodnotu? hmmm

1. Pokud mate boolean uchovavane ve velkych cislech tak jste cunata!!! To neni minimalisticky system aby jste ospravedlnili pouzivani tehle hacku.
2. Pokud mas databazi kde neni abstrakce od specificke architektury tak jste cunata!!! Vetsina mainstreamovych DB to ma pravde z duvodu kompatibility zkrz ruzne platformy. Ptam se. Proc?
3. unsigned long mohou byt dokonce jinak implementovany zkrz ruzne operacni systemy na stejne architekture -viz 2
A vubec nechapu proc u dema lekarskeho systemu musite resit takove low level veci.

U specialnich embedded lekarskych systemu pokud se treba dodava tomograf nebo sono, tak se vzdy pouziva pecko od dodavatele a dodava se jako all in one kompletni reseni i s podporou. Nelze jinak.
U malych reseni jako zubni rentgen se musi soft dodrzet specifikace. Neexistuje pripad "dostali jsme od zakaznika server..." Uz takovy pristup k implementaci zakazek vzbuzuje jiste pochybnosti...

Péčko od dodavatele bych nechtěl vidět...

Nevim jak je to lekarstvi, ale v jinych oborech si IT oddeleni dokaze navymyslet spoustu zajimavosti.
Predpokladam, ze to nebude system na vysetreni, ale neco na zpusob - od 95. do toho softu piseme karty a chceme vyzkouset novy system.
Add promenne - setkal jsem se se situaci kdy zakaznik v navrhu pozadoval sloupce s nazvy Sloupec1 - Sloupec10. Ze jeste nevi na co je pouzije, ale ze tam chce mit misto. Presvedcit ho, ze to jde udelat jinak neprichazelo v uvahu, protoze takhle te tabulce rozumi i on a jeho zakladni SQL mu staci.
Dalsi zakaznik zase pozadoval, aby se hodnoty ciselniku nebyly pres tabulku, ale aby se tam rozkopirovaly, protoze on neumi JOIN a cisla mu nic nerikaji. Na pripominku, ze db muze byt zbytecne velka a pri zmene nazvu bude problem argumentoval, ze nazvy se menit nikdy nebudou, maximalne se nejaky prida. A vlastne mel pravdu. Jeho db, jeho pozadavky, co chces delat. Takze jestli kdysi usoudili, ze nejaky boolean muze v budoucnu byt uint64, tak proste smula....

To uz je chyba realizace ze si nestanovi instalacni podminky. To plati jak pro stavbu, tak pro dodavky systemovych reseni. Ale co. Nebudu vysvetlovat "Kezmarok systems" jak ma podnikat...

Můj Atom-ový netbook by sice x86_64 umět měl ale víc než současné 2GB do něj dát nejde. Jestli se nepletu tak x86_64 architektura má větší spotřebu paměti.

S 2GB RAM na 64 bit celkem v pohodě funguju cca 3 roky. Je to celkem slušně použitelné. Ono spotřeba RAM 32 bit verzus 64 bit není až tak rozdílná. Bežně mám obsazenou RAM na cca 700 - 800 MB (Arch Linux 64bit LXQT, Firefox).

pletes, ten rozdil je minimalni .. a hlavni vyhody x86_64 nejsou jen v adresovani pameti

Nemáš nějaké konkrétní čísla? Možná je to je fakt jen blbý zvyk, ale zrovna kvůli RAM používám 32b systém na lowcostových VPS, kde mám typicky 1GB RAM.

[ivan@dell ~]$ free -m
total used free shared buff/cache available
Mem: 3899 589 2462 129 847 3002
Swap: 3836 0 3836
Tady je výpis obsazené paměti na 64bit Arch linuxu se spušteným terminálem a chromiem v XFCE. Je obsazeno 589 MB.

ohledne te velikosti, jak kdy:
https://www.ghacks.net/2016/01/03/32-bit-vs-64-bit-browsers-which-version-has-the-edge/

Co pamatuju, tak 64bit Linux system mi zabiral cca 30-40% vic RAM (tehdy nejaky Slackware 14.0).

Taky pokud člověk chce zpětnou kompatibilitu pro programy co nejsou 64bit (jmenovitě třeba steam), tak potřebuje i 32bit varianty knihoven, takže se pak musí do RAM načíst dvě varianty toho samýho.

Jenze vo tom to neni, kazda 64bit appka (i jen jeji binarka) je uz po kompilaci sama o sobe vyrazne vetsi nez ve 32bit variante. Mozna bys byl schopnej nastavovanim kompilatoru docilit stejny velikosti, jenze tim bys prozmenu docilil toho, ze ta appka v 64bitech pojede o pulku pomalejs nez ve 32.

Schvalne ju ... ted sem na widlich tak trebas totalcommander ... na disku 4 456 568 vs 8 832 648. V RAMeti 5 272k vs 8 388k.

A proč vlastně končí podpora 32bit arch, když je to celé pouze o parametru kompilátoru. Většina kódu je napsaná v C, nebo C++ (nezávisle na architektuře). Asi mají problém spustit kompilaci gcc --march=i386.
Při dnešních výkonech firemních datacenter je to zanedbatelný čas i náklady na kompilaci.
Takže všem gratuluji k tomuto rozhodnutí a také gratuluji k odůvodnění tohoto rozhodnutí.

ach, jak je ten svet jednoduchy! :-/

... vice na tn.cz

To mas easy, vyvojari sou patlalove (na root takovych chodi taky hromada) nemaj ani paru co jak kde funguje a pak to podle toho vypada - prekompilovat to casto jde jen na jejich vlastnim HW a nikde jinde, natoz spustit.

Natoz aby tusili (ci meli aspon paru) ze krome x86 existujou spousty dalsich architektur, klidne 8bitovych. A zcela bezne a ve velkym se pouzivaji.

Autor clanku se mezi ne muze smele zaradit hned svym prvnim argumentem ... 32bit tux umi samozrejme i na x86 adresovat mnohem vic nez 4GB RAM (a umej to i 32bit widle, a to i XP).

BTW: Pocet tech patlalu si muzes spocitat podle minusu u tohodle postu

Pod to se mohu podepsat. Uz jen takovy hloupy vyvojar "it works on my computer" dokaze zpusobit paseku. Takhle mimochodem fungoval vyvoj Sybase. Vzdycky to nekdo na svem compu zkompiloval a pak chudak zakos resil cesty ke knihovnam, nedejboze unresolved symbols a spinave hacky typu LD_LIBRARY_PATH. O problemech na sparcu a powerpc radeji ani nemluvim.

Teorie o prekompilovani je pekna, pokud nenarazite na libku ktera ma hromadu hacku pro 32bitovou architekturu a linker je tak neskutecne volodroidsky nedodelany, ze neumoznuje natahovat libky podle subarchitektur( jako napr na intel MMX,SSE,SSE2 etc.) tak smula priteli. Uz jen na 32bitech jsi skoncil. Do 64bitu uz musi nekdo ten kod co dela treba dekompresi videa dostatecne abstraktne prepsat.
Dalsi veci je ze mate kus softu ktery by sice sel na 32bitu po premlouvani kompilovat, ale pouziva binarni blob pod NDA jez je 64bit only. Pripadne je k tomu i zdrojak, ale ten kod je od roku 1996 or prvni 64bitove implementace a to otestovany na uplne jine architekture.

Nooo x86. Pokud vezmeme PAE. Mne celkem necelych 4GB na proces (u linuxu je to snad nejak 3,5 tusim, ten to natahuju z pasek, musel bych se podivat:))) prijde docela malo. U nekterych aplikaci to uz nemusi stacit. Je sice fajn adresovat vic pameti, ale to omezeni na proces (ze zcela jasnych duvodu) je limitujici.

Na 8bitovych architekturach se nepouziva linux ale obycejne se zvazi jestli ma cenu dat tam vubec nejaky operacni system.

To bohužel není. Je tam hodně věcí, co se může rozbít a podpora některých technologií chybí...

Pro nás majitele starožitných počítačů (které fungují zatím skvěle) by byla zajímavější informace, jak se k odchodu od 32 bitů staví Debian. Gentoo předpokládám nemá s podporou 32 bitů moc problémů. A ve světě BSD bych předpokládal, že podpora zůstane u FreeBSD. Tuším, že OpenBSD a NetBSD se jen tak 32 bitů nevzdají (kdo má toustovač?).

Otazka nezni zda-li se vzdaji podpory 32bitu. Otazka zni zdali se vzdaji 32bitu na x86. Ty hromady embedded systemu budou 32bitu pravdepodobne naveky (definujme jako 10 let pro startupove gelouse a 15-20 let realne).

Otázka zní, jestli mezi ty embedded věci počítat třeba AMD Geode...

Dovolim si predikovat jeste delsi moralni zivotnost, minimalne pro MIPS, ARM, TriCore (druha otazka je, kdo/dokdy tam bude podporovat Linux)

Mam taky dojem ze TrueOS (povodne PCBSD) uz 32bit neriesia. U FreeBSD a OpenBSD sa toho asi tak nevzdaju. Podpora VAX bola z OpenBSD odstranena az v poslednej verzii a to je uz dost obstarozna platforma.

Asi se ptám zbytečně, ale co 32-i386 byt binárky na AMD64? Budou pro ně 32 knihovny dispozici ?

ano ... koukni na openSUSE:Leap .. ten system je stale multilib

Vážne Kali linux? Asi som pred týždňom sťahoval nejakého 32bit ducha z kali.org a následne aj update prebehol hladko až do konca...

Je to už posledná podporovaná verzia s 32-bit. Ďalšie budú iba 64-bit.

Mám mini-ITX desku s Atomem N270. Deska se napájí z externích 12V, spotřeba pár wattů, bez nutnosti shánět mini-ITX zdroj, v případě potřeby se to dá provozovat i v autě nebo na baterky. S gigabitovou kartou a velkým HDD je to ideální domácí server na data a přehrávání hudby/filmů, nevím čím novějším bych to nahradil.

Intel NUC s celeronem. V idle 5W, při zátěži 10W.

Z pohledu Debianisty postradam:

- informaci o tom, ze aktualni bezici i386 system nemusi byt lamerina admina, ale historicka zalezitost; proste se to nainstalovalo pred mnoha lety a od te doby se to postupne upgraduje bez reinstalace
- informaci o multiarch instalacich
- a s tim volne souvisejici moznost migrace i386 -> amd64 byt podle neoficialniho postupu (http://www.ewan.cc/?q=node/90) - tady bych ocenil, kdyby bylo nejake distribucni reseni, tak trosku doufam, ze na tom nekdo pracuje

Mam EEE 901 s 2GB RAM a porad dobry notebook na dovolenou bez strachu kdybych ho tam zapomnel.

Mám něco podobného. Doufám, že alespoň Debian jako pracovní (nefrikulínská), univerzální distribuce zachová i386.

Ubuntu v 17.10 32bit normalne podporuje vsemi zpusoby, pouze jedinej prestane a to vydavat pripravene "Desktop 32bit ISO" vice viz: https://www.root.cz/clanky/ubuntu-konci-s-32bitovymi-instalacnimi-obrazy-pro-desktop/nazory/939581/

Pekny clanok a v podstate suhlasim. Najskor som mal namietky, ale ked som si ho precital este viac, doslo mi, ze hovori o beznych uzivateloch desktopov / serverov v IT prostredi.

Kde je miesto na 32-bitove verzie su napr. rozne embedded systemy, automatizacia.

Robime SCADA/MES systemy pre priemysel plus nejake male veci (embedded Win7). Odhliadnuc od tych embedded, vsetky nase aplikacie dnes bezia na 64-bitovom OS (Win, HPUX, dokonca OpenVMS, mame aj port pre Linux :)
Ale pokial nemam velku aplikaciu, snazim sa tam dat 32-bitove binarky (teraz hovorime o Win, pre ostatne platformy mame iba 64-bitove binarky)
vyhody:
- 10-15% rychlejsi kod
- lepsie vyuzitie pamate (inak povedane mensi narok na pamat pri tej istej uzivatelskej konfiguracii)
- ak sa nejaky proces zblazni (memory leak alebo chyba v aplikacii) tak padne po vyzrati 3GB RAM a je restartovany. Ak sa zblazni nieco 64-bitove, tak ide do kolien cely Windows

Binarky naseho systemu medzi sebou dokazu komunikovat cez TCP prip. zdielanu pamat (na tom istom stroji), pricom si rozumeju Win32/Win64/H­PUX64/OpenVMS67/Li­nux64 (dokonca aj ked HPUX je big endian), takze v pripade potreby mozem mat vsetky serverovske binarky na 32-bitoch s vynimkou 1-2 ktore potrebuju viac ako 3GB pamate.
Su aj pripady ked server binarky su 64-bitove ale klienti su stale na 32-bitovych.
Pekny den.

ps:
Nase systemy maju bezne uptime stovky dni az roky (v redundantnych aplikaciach sa jednotlive nody mozu restartovat napr. kvoli OS aktualizaciam, ale cely system bezi dlho .. najdlhsie beziaca aplikacia na OpenVMS mala pred par dnami 2165 dnovy uptime, to je cosi menej ako 6 rokov :) Preto riesime otazky stability mozno viac ako ini..

Jsem rad ze nekdo dela systemy, ktere oznazuji jako dobre navrzene. Ty widle embedded jsou v podstate jiny system a tezko snesou srovnani s pc bimbous.
Jeste k tem 32bitum vs 64bit. V zasade souhlasim, akorat s tou vyhradou ze pokud je to maly system na 64bitech, tak k 32bitove aplikaci se jeste musi navic dotahnout ty same libky ktere uz v systemu jsou nicmene tentokrate 32bitove verze. Pokud masina nema moc pameti tak to resis.

ps: je vysadou linuxaku ze sve zavazne problemy a zmeny konfiguraci(na­pr.disku, vymenu karty nebo pameti) resi resetem. My co jsme vychovani na "lepsich systemech", tak restart je vniman jako neco jen v nejhorsim pripdade a profesne take neco jako velmi ponizujiciho. Asi znas ten pripad kdy se o restartu diskutuje i mesic a mezitim se poti lidi jak to udelat bez nej:)

60% menšina na rootu doma pláče při pohledu na svého 10+ let starého miláčka...

Drobná oprava: věta "Uživatelé systému se zeleným chameleonem v logu tedy už vůbec nemají možnost starou architekturu používat." není tak úplně pravdivá, protože na rozdíl do Leapu Tumbleweed paradoxně stále nabízí i 32-bitovou verzi. Ale je veřejným tajemstvím, že je to spíš proto, že to funguje tak nějak setrvačností, a že jakmile se objeví nějaký závažnější problém, který se nikomu nebude chtít vyřešit, skončí také (jednou už k tomu nebylo tak úplně daleko).

Architektúra využívajúca 64 bitov je stavaná viac na spracovanie grafiky, videa, hudby a v oblasti serverov. Bežný človek 64-ku nevyužije naplno pre neho to bude zbytočný luxus. Z uvedených informácií vyplýva iba jediné - majú plán skonštruovať prvý 128 bitový počítač ideálne na lámanie hesiel.