Arch Linux termina oggi il supporto ai pacchetti i686

Arch Linux termina oggi il supporto ai pacchetti i686

Arch Linux non offrirà più, a partire dalla giornata di oggi, il supporto ai pacchetti compilati per architetture i686 e, pertanto, destinati ai processori a 32 bit. Il futuro è a 64 bit anche per il Pinguino

di pubblicata il , alle 16:01 nel canale Sistemi Operativi
Linux
 

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

20 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
AleLinuxBSD09 Novembre 2017, 20:34 #11
Il problema principale dato dall'abbandono del supporto delle architetture a 32bit non viene dal supporto ai 64bit da parte delle Cpu, ma al livello di memoria Ram.

I computer super obsoleti non soltanto hanno una limitata quantità di Ram, chiedendo in negozio, te la vendono a peso oro.

Che poi questa decisione fosse inevitabile, considerando la grande dispersione di risorse in ambito Linux, era scontato.

Considerando poi la micidiale combinazione costituita dall'avvento di Wayland, nonché di applicazioni videoludiche che fanno uso di recenti standard non supportati neanche da hardware relativamente recente, il cambio a 64bit rappresenta pure il minore dei mali.
s-y09 Novembre 2017, 21:01 #12
cmq sia la arch è sempre stata 'drastica' su questi aspetti. ad esempio non supportava già ai tempi gli i386 (da pentium pro a scendere), e non credo sia da prendere come esempio tipico del mondo pinguinesco
Phoenix Fire10 Novembre 2017, 09:44 #13
secondo me ha fatto bene, come detto da AleLinuxBSD, già le risorse mancano, se devo anche disperderle...
che poi come spiegato nell'articolo, non è che hanno "bloccato" la cosa, se la community vuole può continuare a svilupparseli lei, ma almeno io "distro" posso concentrare meglio le risorse
s-y10 Novembre 2017, 10:10 #14
si, avevano preannunciato la cosa con anticipo motivando proprio con la difficoltà a manutenere entrambe le versioni

tra l'altro come specificato la v 32 è stata 'comunityzzata', e la serietà degli arch user esperti dovrebbe garantire una buona qualità di release, anche se da capire come proseguirà la cosa
WarDuck10 Novembre 2017, 10:23 #15
Originariamente inviato da: fano
Alla fine se non ha applicazioni scritte col c*lo che necessitano di più di 4 GB solo loro per funzionare, 64 bit non serve mica a molto!
Anche .NET di default compila con "prefer 32 Bit" che su Windows 64 Bit funziona alla perfezione (con WoW64), su Linux visto che l'architettura "ibrida" 32 / 64 non sono stati capici a farlo Mono ignorava il flag ed andava sempre a 64 Bit.

Lo sapete sì che alla fine il risultato più "tangibile" di avere applicazioni a 64 Bit è che usano il doppio della RAM?


Avere uno spazio di indirizzamento più ampio non vuol dire solo poter usare più RAM, ma anche sfruttare più bit per l'algoritmo di randomizzazione degli indirizzi logici (ALSR).

Le applicazioni 64 bit sono tendenzialmente più sicure delle stesse compilate a 32 bit.

Inoltre in x86_64 hai a disposizione il doppio dei registri, con tutti i benefici di ciò.

Il fatto che le applicazioni 64 usino il doppio della RAM non è un assoluto: sono i puntatori ad occupare il doppio.

Motivo per cui hanno sviluppato l'ABI x32, per il supporto ai registri a 64 bit con indirizzi a 32 bit.
fano10 Novembre 2017, 11:18 #16
Sì ma il doppio dei registri non è un vantaggio dei 64 bit era x86 che faceva un po' schifo c'erano processori a 32 bit (tipo ARM e forse pure M68K!) che di registri ne avevano comunque 32 o 64... mica 8!

Diciamo pure che x86 è nato male cresciuto peggio e che x64 cerca di metterci delle pezze, ma è un po' un casino di architettura.

L'ABI 32x che io trovo una soluzione interessante per uso "desktop" sembra come al solito essere stata abbandonata su Linux almeno io non la vedo molto pubblicizzata... non me la sentirei sinceramente di usarla in produzione: già i driver sono pochi figuriamoci per la versione "esotica" 32x.

La stiamo valutando per Cosmos credo che a tendere sarà quella la "nostra" versione a 32 bit, supportare 8087, farli i "long" a mano scrivendo dentro 2 registri, menarsela a salvare tutto nello stack non ha molto senso quando processori 32 bit "puri" sono una nicchia della nicchia, magari avrà senso per particolari soluzioni embedded in cui sono usate m*rdate tipo "Galileo" o "Geode".
Yrbaf10 Novembre 2017, 12:47 #17
Per la precisione Arm (32bit) e M68K di registri generici ne hanno solo 16 (sempre meglio degli 8 di x86) e non 32 o più.

32 registri (limitandoci agli interi, visto che sopra non ho contato gli FP) li avevano/hanno MIPS (in realtà 1 è un registro fisso a zero), PowerPC, Power di IBM, Dec Alpha, Sun/Oracle Sparc e gli Arm quando operano nella modalità a 64 bit (quindi Arm come x86 vede un raddoppio dei registri passando in ABI64).

PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.
cdimauro11 Novembre 2017, 13:51 #18
Originariamente inviato da: Yrbaf
Non diciamo stupidate solo per muovere le dita.

Il futuro è a 64 bit ma 32 bit sono ancora sufficienti per una buona fetta delle applicazioni del presente e spesso le versioni a 64 bit se non sfruttano i 64 bit (o nel caso x86 i registri in più, cosa magari non vera in tutte le altre architetture a 64b) sono pure più lente della controparte 32b.

Sfruttare i registri in più di x64 è molto più semplice, nonché comune ed effettivamente usato, che sfruttare i 64 bit. Basta disassemblare un po' di applicazioni per rendersene conto.

Eseguibili IA-32/x86, con soli 8 registri a disposizione (in realtà 7, perché uno riservato allo stack), sono pieni di istruzioni PUSH e POP per salvare e ripristinare registri, a cui si aggiungono vagonate di istruzioni che referenziano locazioni nello stack.

Eseguibili per x86-64/x64, invece, presentano di gran lunga meno casi del genere, e un notevole sfruttamento degli 8 registri in più.

Applicazioni a 64 bit che girano più lentamente delle equivalenti a 32 bit ce ne possono essere, senz'altro, ma sono una minoranza. In genere un'applicazione a 64 bit gira il 10-15% più velocemente della stessa, ma a 32 bit.
La ram ormai sarà poco costosa (in config oltre 4GB) ma le cache di primo livello dei processori non sono cresciute così tanto (come gli altri livelli) rispetto a quando si era solo a 32b.

No, ma quelle L2 e, soprattutto, L3 sono cresciute molto, e quindi mitigano molto l'accresciuta dimensione del codice (in genere il codice x64 è del 20-25% più grande di quello x86) e il raddoppio della dimensione dei puntatori (che è il problema primario quando si passare a un'ISA a 64 bit).
Forse anche a livello di MMU c'è un carico maggiore nell'usare i 64b sempre anche quando non servono.

Sì, ed ed è sempre tutto legato alla maggior dimensione del codice e dei dati.
Senza contare che ci sono vecchie macchine che hanno il supporto a 64b ma la ram fisica limitata comunque a 3-4GB e obbligarle a passare alla versione a 64b dell'OS (che potrebbe girare) sarebbe forse solo una perdita di prestazioni e basta senza veri altri benefici.

Con 4GB in genere si va abbastanza bene con s.o. & applicazioni a 64 bit.

Ovviamente dipende anche da quante se ne fanno girare, e di che tipo.
Originariamente inviato da: WarDuck
Avere uno spazio di indirizzamento più ampio non vuol dire solo poter usare più RAM, ma anche sfruttare più bit per l'algoritmo di randomizzazione degli indirizzi logici (ALSR).

Le applicazioni 64 bit sono tendenzialmente più sicure delle stesse compilate a 32 bit.

Inoltre in x86_64 hai a disposizione il doppio dei registri, con tutti i benefici di ciò.

Il fatto che le applicazioni 64 usino il doppio della RAM non è un assoluto: sono i puntatori ad occupare il doppio.

Motivo per cui hanno sviluppato l'ABI x32, per il supporto ai registri a 64 bit con indirizzi a 32 bit.

*

Anche se purtroppo è un'ABI che viene usata troppo poco.
Originariamente inviato da: fano
Diciamo pure che x86 è nato male cresciuto peggio e che x64 cerca di metterci delle pezze, ma è un po' un casino di architettura.

x64 è una pezza in tutti i sensi, perché il lavoro che hanno fatto lascia il tempo che trova.

Comunque il problema più grosso di x86/x64 è rappresentato dai decoder. Ma una volta che le istruzioni sono state tradotte in micro-op, il backend è poco influenzato dal "legacy".
L'ABI 32x che io trovo una soluzione interessante per uso "desktop" sembra come al solito essere stata abbandonata su Linux almeno io non la vedo molto pubblicizzata... non me la sentirei sinceramente di usarla in produzione: già i driver sono pochi figuriamoci per la versione "esotica" 32x.

Purtroppo è proprio questo il problema: la scarsa adozione. Aggiungiamoci pure che Microsoft ha completamente ignorato quest'ABI.

E' un vero peccato, perché oggi si potrebbero tranquillamente utilizzare applicazioni x32 e x64, a seconda dei casi, sfruttando il meglio delle due ABI.
La stiamo valutando per Cosmos credo che a tendere sarà quella la "nostra" versione a 32 bit, supportare 8087, farli i "long" a mano scrivendo dentro 2 registri, menarsela a salvare tutto nello stack non ha molto senso quando processori 32 bit "puri" sono una nicchia della nicchia, magari avrà senso per particolari soluzioni embedded in cui sono usate m*rdate tipo "Galileo" o "Geode".

Infatti i 32 bit "puri" (x86) hanno senso sostanzialmente solo in ambito embedded ormai.
Originariamente inviato da: Yrbaf
Per la precisione Arm (32bit) e M68K di registri generici ne hanno solo 16 (sempre meglio degli 8 di x86) e non 32 o più.

In realtà i 68K hanno 8 registri dati e 8 registri indirizzi. I registri, quindi, non sono "ortogonali" (utilizzabili indifferentemente).

Mentre in x64 (e x32) sono ortogonali.
PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.

Davvero molto interessante, grazie.
fano12 Novembre 2017, 13:26 #19
Originariamente inviato da: Yrbaf
PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.


.Net in realtà quando usato con "AnyCpu" si intende "Prefer 32 Bit" quindi se possibile il Jitter crea istruzioni a x86 proprio per il problema di non usare troppa memoria.
Non è x86 "puro" visto che hanno iniziato ad usare comunque SSE per operazioni floating point e vettoriali, ma non può nemmeno essere chiamato x32... è una via di mezzo.

Durante l'esecuzione le applicazioni .NET girano quindi o "nativamente" sulla CPU se l'OS è a 32 bit oppure usano WoW per girare a 32 bit su Windows 64, il Jitter può comunque decidere di ignorare il "consiglio" e far girare tutto a 64 bit se così desidera (su Linux 64 non c'è "LoL" quindi...), questo credo vale solo su x86 non so una CPU ARM64 può switchare tra 64 / 32 bit a runtime...

Questo può essere simile ai "compressed pointers" di Java: https://github.com/dotnet/coreclr/issues/555
cdimauro12 Novembre 2017, 19:31 #20
Originariamente inviato da: fano
.Net in realtà quando usato con "AnyCpu" si intende "Prefer 32 Bit" quindi se possibile il Jitter crea istruzioni a x86 proprio per il problema di non usare troppa memoria.
Non è x86 "puro" visto che hanno iniziato ad usare comunque SSE per operazioni floating point e vettoriali, ma non può nemmeno essere chiamato x32... è una via di mezzo.

Durante l'esecuzione le applicazioni .NET girano quindi o "nativamente" sulla CPU se l'OS è a 32 bit oppure usano WoW per girare a 32 bit su Windows 64, il Jitter può comunque decidere di ignorare il "consiglio" e far girare tutto a 64 bit se così desidera (su Linux 64 non c'è "LoL" quindi...), questo credo vale solo su x86 non so una CPU ARM64 può switchare tra 64 / 32 bit a runtime...

Questo può essere simile ai "compressed pointers" di Java: https://github.com/dotnet/coreclr/issues/555

E' un peccato che .NET non possa utilizzare direttamente x32 (quindi mantenendo i soli puntatori a 32 bit) con Windows a 64 bit: sarebbe la soluzione ideale.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^