Buoni motivi per mantenere i sistemi operativi desktop Microsoft Windows a 32 bit

Questa domanda è del 2012. Se stai leggendo questo nel 2019 o in seguito, la risposta è davvero: No. Nel 2019 non esiste alcun motivo valido per mantenere i sistemi operativi desktop a 32 bit.

Domanda originale di seguito:

Il software server è a 64 bit solo da un po 'di tempo (da Server 2008 R2 per Windows, anche prima per Exchange e Sharepoint) e persino Ubuntu ti sta allontanando dalle versioni a 32 bit per i loro sistemi operativi server.

Ma c'è qualche buon motivo quantificabile per mantenere un sistema operativo desktop a 32 bit? Stiamo preparando le nostre immagini di Windows 8 per i pochi (sfortunati?) Che saranno i primi ad adottare.

La maggior parte dei nostri computer desktop ha 4 GB o meno di RAM, ma mi piacerebbe non dovermi più preoccupare di supportare un sistema operativo a 32 bit.

Qualche motivo per cui dovrei?

• I 32 bit possono essere leggermente più veloci in alcuni casi d'uso: gli indirizzi più piccoli significano un codice visivamente più compatto, il che significa una maggiore efficienza della cache. Nei benchmark che ho visto, tale efficienza tende ad essere offuscata dalla maggiore efficienza computazionale a 64 bit in ambienti di calcolo pesante. Ma a 32 bit infatti di tanto in tanto vince su alcuni benchmark. YMMV. L'età del tuo software è importante, poiché le build più recenti sfruttano le cose a 64 bit che le build precedenti non lo fanno.

• Codice più compatto significa meno spazio su disco. Basta andare a scaricare gli ISO per il tuo sistema operativo preferito in versioni a 64 e 32 bit per vedere la differenza. Non è banale. È anche molto di più una volta decompresso i binari. Come sottolineato da OrangeDog : Gran parte di questo consumo di spazio deriva dal fatto che i sistemi operativi a 64 bit forniscono librerie a 32 bit oltre a quelle a 64 bit.

• Ottieni ancora una migliore compatibilità con i componenti e il software legacy a 32 bit. Ciò è particolarmente visibile nei sistemi che vengono compilati dinamicamente sul computer host ma che raccolgono contemporaneamente librerie binarie di terze parti. Il framework .NET di Microsoft ne è un ottimo esempio: mentre i programmi sono teoricamente indipendenti dall'architettura, ogni volta che si collega a un binario nativo si collega a un arco o all'altro. Molti sviluppatori non sanno nemmeno che ciò sta accadendo e forniscono componenti di produzione che non potranno essere eseguiti su sistemi a 64 bit senza alcune modifiche per istruire esplicitamente .NET a funzionare in modalità a 32 bit. Molte persone non sanno come farlo.

• Come sottolineato da Daniel B: lo sviluppo di Windows .NET su macchine a 64 bit ti lascia aperto a un'incoerenza frustrante in cui in determinate circostanze le eccezioni sono mascherate dal sistema operativo.

• Hardware legacy. Non è possibile eseguire un driver a 32 bit su un kernel a 64 bit.

Niente di tutto ciò si aggiunge a uno spettacolo per la maggior parte delle persone. Tuttavia, devi decidere come questi fattori influenzano il tuo ambiente.

L'unico motivo per cui riesco a pensare di mantenere un sistema operativo desktop a 32 bit è se usi vecchi programmi a 16 bit (es. DOS) e non hai la versione di Windows che supporta Windows Virtual PC.

(E anche allora installerei un sistema operativo a 64 bit e userei qualcosa come DOSbox).

Modifica: in realtà c'è un altro motivo: l'hardware che non riesce a gestire più di 4 GB di spazio di indirizzi. Ad esempio FireWire che prova a eseguire il DMA. O qualsiasi hardware (vecchio) senza driver a 64 bit.

Tutto ciò che eseguirà Windows 8 è già in grado di 64 bit, a meno che tu non abbia alcuni netbook Intel Atom di prima generazione (e ne dubito molto). Questa è l'unica cosa che mi viene in mente.

AMD ha rilasciato il suo primo Opteron a 64 bit nel 2003; e da allora praticamente tutti i processori che hanno realizzato sono stati a 64 bit.

Intel è stata un anno dopo, rilasciando il suo primo Xeon (Nocona) a 64 bit nel 2004 e espandendosi a quasi l'intera linea di prodotti entro il 2006. A parte i summenzionati chip Atom, ogni processore Intel oggi è a 64 bit.

Wikipedia ha un elenco di processori suddiviso se sei interessato alla storia antica .

Compatibilità con software / hardware antichi.

Se tutto funzionasse con x64, non mi preoccuperei di 32 bit.

Gli indirizzi di memoria in una macchina a 64 bit richiedono naturalmente 64 bit. Gli stessi indirizzi richiedono 32 bit in una macchina a 32 bit. In alcune circostanze piuttosto eccezionali, tale "aumento" del numero necessario di bit può fare la differenza tra buone prestazioni e scarse prestazioni su una macchina con memoria limitata.

Oltre a ciò, poiché è probabile che tu stia eseguendo software a 32 bit su una macchina che potrebbe comunque eseguire software a 64 bit e il supporto a 32 bit funziona abbastanza bene su macchine a 64 bit, le differenze sul lato hardware non cambiano il gioco. Occasionalmente troverai un dispositivo legacy che non ha un driver hardware a 64 bit, ma ora è molto raro a causa della disponibilità dei sistemi operativi a 64 bit per oltre un decennio.

Un punto da considerare è che molte vecchie applicazioni a 32 bit sono più vecchie in molti modi oltre la loro bit-ness. Sul lato del sistema operativo Windows, un'app a 32 bit potrebbe essere confusa se sta cercando file in "Programmi" che ora si trovano in "Programmi (x86)". Allo stesso modo, alcuni elementi del registro potrebbero richiedere attenzione manuale. Ancora una volta questa è più una funzione di applicazioni leggermente scritte male che ora hanno bisogno del tuo aiuto per "trovare" cose che "avrebbero funzionato" se la macchina fosse a 32 bit.

Molte persone non sanno che i programmi e le librerie a 64 bit occupano più memoria degli equivalenti a 32 bit.

Ad esempio, quando si utilizzano macchine virtuali a memoria insufficiente, è consigliabile utilizzare i sistemi operativi a 32 bit per massimizzare la disponibilità della memoria all'interno della VM.

Parlando di Ubuntu, abbiamo eseguito LTS 12.04 a 64 bit con LTSP ormai da alcune settimane.

L'unica seccatura che abbiamo incontrato per i beta tester iniziali è che i terminali LTSP che utilizziamo (Dell GX2xx) richiedono un kernel a 32 bit e quindi dobbiamo compilare un secondo kernel LTSP e mantenere il doppio dei pacchetti per le due architetture .

Essendo LTSP piuttosto un caso limite, penso che 64 bit sia abbastanza pronto per andare a meno che il tuo test particolare non mostri un difetto.

Anche se consiglierei personalmente di passare a 64 bit il più presto possibile e di mordere il proiettile prima piuttosto che dopo, non sarà senza impatto per il tuo team di supporto IT. Se la larghezza di banda del team di supporto è già ridotta al massimo (ovvero, è già a corto di personale), prenderei effettivamente in considerazione l'attesa.

Quindi, questa è una risposta che riguarda le risorse umane, non solo il software in / compatibilità.

Il lancio dovrebbe ovviamente essere pianificato con cura (preferibilmente graduale piuttosto che tutto in una volta). Ci saranno problemi "scoperti" che richiederanno ore per risolversi in base all'utente. Una volta identificati i problemi più comuni, le "istruzioni" possono guidare risoluzioni più rapide sia per le chiamate di supporto che per il self-service.

Principalmente, (ad esempio), sto pensando a tutti i problemi di compatibilità a 32 e 64 bit (in) tra il sistema operativo, un pacchetto software specifico e i plug-in associati, come avere entrambi i browser a 32 e 64 bit installati (e / o più browser) su un singolo sistema operativo a 64 bit, le scorciatoie per 'esegui come amministratore' vs 'esegui come utente normale', con opzioni sia per un 32 e plug-in a 64 bit per quei browser (o a volte forse limitato a soli plug-in a 32 bit che funzionano solo in una versione del browser), tutto ciò che interrompe le applicazioni e i flussi di lavoro basati su quei plug-in. (Per "plug-in" intendo qualsiasi cosa, da Java, da flash, da lettori pdf incorporati a software di web conferencing - sia interno che ampiamente disponibile, sia commerciale che gratuito.) Puoi provare a provare tutti questi problemi, ma è difficile prevedere se un utente installerà inavvertitamente il plug-in B prima del plug-in A, il che provoca un risultato diverso rispetto a un altro utente che installa il plug-in A prima del plug-in B (sostanzialmente

L'unico motivo per mantenere versioni a 32 bit di ... qualsiasi cosa ... è supportare applicazioni e sistemi "legacy". Se riesci a eseguire tutto su sistemi operativi a 64 bit, considera fortunato e vai avanti. Potresti essere come alcune povere SA che si trovano in un ambiente aziendale per una società non tecnologica, dove il piano per la migrazione dalla base utenti da XP a Windows 7 inizia nel terzo trimestre del 2014.

< piange >

Ad ogni modo, non so di Shift+ Del, e probabilmente li lascerei semplicemente ignorati in qualche angolo dell'ambiente, nel caso in cui succeda l'indicibile e ti ritrovi a aver bisogno Windows XPdi qualcosa. Sicuramente smetti di preoccuparti di mantenere, aggiornare, testare o altro su di essi, ma tienili in giro se mai fossero necessari. L'altro giorno è successo che un cliente voleva che supportassi alcuni Windows 2000PoS, cosa che potevo, perché non ho spazzato via tutte le mie Server 2000immagini quando Server 2003è uscito (e lo volevo davvero).

Per quanto preghi e speri che il tempo non arrivi mai, è sempre bello avere quella roba in giro "per ogni evenienza" e i costi per mantenerla sono così insignificanti, penso che sia sciocco non farlo.

Avendo avuto notevoli problemi a causa di problemi di software legacy, posso solo dire che tutto ciò che esegui può essere eseguito su un sistema operativo a 64 bit. In tal caso, non hai motivo di non migrare, supponendo che le licenze non siano un fattore.

Nel mio caso sono stato in grado di riconfigurare i sistemi in modo che tutte le applicazioni a 32 bit fossero in grado di funzionare su una sola macchina, consentendo a tutte le altre workstation di essere a 64 bit. Alla fine ho persino migrato quella macchina a 32 bit su una VM su Virtualbox, in esecuzione su un host Debian, principalmente perché la capacità era lì e volevo ridurre il conteggio delle scatole.

Tutte le macchine virtuali sopra e diverse non possono eseguire codice x64-bit se la CPU non supporta la virtualizzazione (ad es. Funzionalità VT-x).

Diverse CPU a 64 bit più economiche che mancano di VT-x, ecc. Sono comunque attraenti per i cluster "fatti in casa".

Da Wikipedia :

Intel non ha aggiunto il supporto di segmentazione alla sua implementazione x86-64 (Intel 64), rendendo impossibile la virtualizzazione solo software a 64 bit sulle CPU Intel, ma il supporto Intel VT-x rende possibile la virtualizzazione assistita da hardware a 64 bit sulla piattaforma Intel