Názory k článku
LibreOffice končí s 32bitovými verzemi pro Linux
-
Zprávička mluví o tom, že se nebudou poskytovat "oficiální" LibreOffice buildy přímo od TDF. Ty se už teď nabízejí jen pro x86_64 a i586 (k tomu navíc MacOS a Windows), takže z hlediska ARMu se nezmění vůbec nic, žádné oficiální buildy pro ARM (32-bitový ani 64-bitový) nejsou ani teď. Navíc má většina uživatelů LibreOffice stejně spíš jako distribuční balíček a je jen na distribuci, jestli ho bude nabízet dál a jak dlouho.
Jiná otázka je, jak to bude do budoucna, protože pokud vývojáři přestanou nabízet hotové binárky pro i586, dá se očekávat, že tuto architekturu nebudou ani testovat a nevšimnou si, když se něco rozbije jen na ní. A chyba specifická pro i586 pravděpodobně bude mít výrazně nižší prioritu než chyba týkající se i x86_64.
A ruku na srdce: opravdu je tolik uživatelů toužících provozovat LibreOffice (který patří i na x86_64 spíš k náročnějšímu software, ať už z hlediska zátěže CPU nebo spotřeby paměti) na ARMv7?
-
Jsou takoví, i když je jich málo. Znám osobně např. jednoho studenta, kterému se rozbil počítač, tak jsem mu (protože není zrovna bohatý) dal RPi, aby svoji ročníkovou práci úspěšně dopsal na něm. Ovšem teď s rýsující se perspektivou laptopů založených na ARM se primární podpora této architektury v LO stane velmi důležitá.
-
Nemam tu zkusenost. Vychazim z celkove zateze systemu jako celku a zadny vyrazny zlepseni jsem pred a po jsem nezaznamenal :( Podle me je to bud jen nafouknuta teorie, ci vysledky mereni za specifickych podminek ( podobne jako premrstene vykony malych reproduktorovych sestav). Nevim jak na serveru zpracovavajicim obrovske objemy dat, ale co jsem pozoroval na desktopech, zadny nadseni to ve me nevyvolalo...
-
To je většinou pravda (někdy je to méně, někdy naopak mnohem více) ale nesouvisí to jenom s tím, že to je 64bit. Intrukční sada x86 byla zastaralá a AMD64 přineslo řadu obrovských vylepšení, 64bit je jenom jedním z nich. Lví podíl na zvýšení výkonu mají ty ostatní: dvojnásobný počet registrů (16 GPR a 16 SIMD, proti 8 GPR, 8 SIMD a 8 FPU (x87) ve 32bitovém režimu), podpora relativního adresování prakticky bez penále, nové adresovací módy, širší externí sběrnice atd.
-
Právě proto vzniklo x32 ABI, jehož cílem bylo zpřístupnit většinu výhod (víc registrů, chytřejší adresování atd.) při zachování 32-bitového adresního prostoru (a tedy 32-bitových pointerů). Praxe ale ukázala, že zájem byl spíš jen verbální a AFAIK žádná významnější distribuce nezačala x32 build opravdu reaálně nabízet. Před pár měsíci se dokonce začalo diskutovat o tom, jestli podporu x32 z jádra nevyhodit úplně.
-
Tak zakladny tlak na prechod k 64bit bol koli adresacii pamati. Dnes desktop so 4GB ani nekupis, rozumne minimum je 8GB. Odrezanie 32bit podpory zase vsetko zjednodusi a tych par starosti co ti prinieslo zmiznu (ziadne dvojite kniznice, jedna pre 32bit apky druha pre 64bit atd.)
5. 6. 2019, 17:45 editováno autorem komentáře
-
GNU/Linux 32bit diky PAE podporuje RAM az 64GB
https://cs.wikipedia.org/wiki/Physical_Address_Extension -
Ano... teoreticky. Ale je mi líto každého, kdo by to zkusil opravdu použít. Jeden náš zákazník to před časem z holého nerozumu zkusil s "pouhými" 24 GB a nestačil se divit. Omezení userspace procesu na (obvykle) 3 GB také není žádné terno.
PAE je (byla) berlička, která umožní s trochou skřípění zubů využít 4 nebo 8 GB i bez přechodu na x86_64. Ale představa že když máme PAE, tak je do 64 GB všechno v pohodě, je zcestná.
-
Presne jak rika kolega K3dAR. Ja jsem takhle fungoval bez problemu nekolik let.
Co se tyce starosti, tak je tu samozrejme nutnost kompletni reinstalace systemu, a rebuildu vlastnich projektu, pripadne softu, ktery z nejakych duvodu nemam primo z repa - bylo-li to mozne.
Dalsim nemilym prekvapenim je napr. Wine. Protoze nektere casti Windows 64 bit jsou porad 32 bit, je nutne, aby to wine respektovalo. To si u tohoto projektu vyzaduje obtiznejsi kompilaci s pouzitim kontejneru. To jsem zamitl a tak se musim spokojit s ofiko vydanim. Prisel jsem tim hned o dve veci, ktere jsem vyuzival: Nektere starsi verze Wine uz nemohu pouzit a nemohu uz ani tezit z optimalizaci na vlastni sestavu.
Osobne, jsem presel na 64bit system vicemene z donuceni - prave kvuli takovym aplikacim, ktere uz nemaji 32bit verzi
-
Od té doby, co Wine přešlo na roční stabilní vydání, se mi víc osvědčuje zůstat u poslední oficiální stable větvě. Sice na tom třeba nejedou ty úplně nejposlednější hry, ale co funguje zase funguje mnohem líp. Jinak stojí za vyzkoušení PlayOnLinux, ten umí automaticky stáhnout doporučenou verzi Wine pro každou aplikaci.
-
No, jako vývojáři mi osobně přijde, že 8-bytové pointery jsou v drtivé většině případů zbytečně dlouhé a v řadě případů to je i netriviální plýtvání prostředky (hlavně v L1 a L2 cachích, řekl bych). Proto mi třeba x32 ABI přišlo jako zajímavý přístup.
Na druhou stranu chápu, že v 99% případů je to plýtvání příliš malé na to, aby se jen kvůli němu "podporovaly" další platformy, ať už x32 (které taky víceméně "umřelo") anebo staré 32-bit x86. Tedy ve smyslu, že projekty raději svou energii vloží jinam.
-
Ano, samozřejmě se v některých jazycích dá přizpůsobit, ale typicky to nepůjde tak snadno. Možná v C++ by to díky přetěžování nebylo extra náročné a nemuselo se moc kódu přepisovat.
Když jsem u toho, jeden čas jsem na 64-bit systému používal 32-bit Firefox, protože i přes tu režii natáhnutí dalších knihoven navíc mi znatelně poklesla spotřeba paměti. A samozřejmě jsem nezvažoval že si Firefox upravím aby byl v tomto směru efektivnější ;-)
