De bonnes raisons de conserver les systèmes d'exploitation de bureau Microsoft Windows 32 bits

Beaucoup de gens ne savent pas que les programmes et bibliothèques 64 bits occupent plus de mémoire que leurs équivalents 32 bits.

Par exemple, lorsque vous utilisez des machines virtuelles à faible mémoire, il est conseillé d'utiliser des systèmes d'exploitation 32 bits pour maximiser la disponibilité de la mémoire à l'intérieur de cette VM.

En parlant d'Ubuntu, nous utilisons la version 64 bits 12.04 LTS sous LTSP depuis quelques semaines maintenant.

Le seul problème que nous avons rencontré pour les premiers bêta-testeurs est que les terminaux LTSP que nous utilisons (Dell GX2xx) nécessitent un noyau 32 bits et que nous devons donc compiler un deuxième noyau LTSP et maintenir deux fois plus de paquets pour les deux architectures.

LTSP étant un cas limite, je pense que le 64 bits est prêt à fonctionner, à moins que vos tests particuliers ne montrent un défaut.

Même si je vous recommande personnellement de passer à l'architecture 64 bits dès que possible et de vous y résoudre le plus tôt possible, cela ne sera pas sans conséquences pour votre équipe d'assistance informatique. Si la bande passante de l'équipe d'assistance est déjà sollicitée au maximum (c'est-à-dire si elle est déjà en sous-effectif), j'envisagerais d'attendre.

Il s'agit donc d'une réponse qui concerne les ressources humaines, et pas seulement l'intégration ou la compatibilité des logiciels.

Le déploiement doit bien sûr être soigneusement planifié (de préférence de manière progressive plutôt que d'un seul coup). Il y aura des problèmes "découverts" qui prendront des heures à résoudre sur une base par utilisateur. Une fois que les problèmes les plus courants auront été identifiés, des guides pratiques permettront de les résoudre plus rapidement, tant pour les appels d'assistance que pour le libre-service.

Je pense surtout (par exemple) à tous les problèmes d'(in)compatibilité 32 et 64 bits entre le système d'exploitation, un logiciel spécifique et le système d'exploitation associé. plugins Il existe de nombreux obstacles à l'utilisation de ces plugins, tels que l'installation de navigateurs 32 et 64 bits (et/ou de plusieurs navigateurs) sur un seul système d'exploitation 64 bits, les raccourcis pour "exécuter en tant qu'administrateur" et "exécuter en tant qu'utilisateur normal", les options pour un plugin 32 et 64 bits pour ces navigateurs (ou parfois limité aux plugins 32 bits qui ne fonctionnent que dans une seule version du navigateur) - tout cela casse les applications et les flux de travail construits sur ces plugins. (Par "plugins", j'entends tout ce qui va de Java à Flash, en passant par les lecteurs de PDF intégrés et les logiciels de conférence Web, qu'ils soient développés en interne ou largement disponibles, qu'ils soient commerciaux ou gratuits). Vous pouvez tenter de tester tous ces problèmes, mais il est difficile de prévoir si un utilisateur installera par inadvertance le plugin B avant le plugin A, ce qui provoquera un résultat différent de celui d'un autre utilisateur qui installe le plugin A avant le plugin B (en gros, il est toujours difficile de prévoir les dégâts que feront les utilisateurs lorsque leurs actions modifieront l'état du système).

La seule raison de conserver des versions 32 bits de... n'importe quoi... est de prendre en charge les applications et systèmes "hérités". Si vous pouvez tout faire fonctionner sur des OS 64 bits, estimez-vous heureux et passez à autre chose. Vous pourriez être comme certains pauvres SA qui sont dans un environnement d'entreprise pour une société non technologique, où le plan de migration de la base d'utilisateurs de XP à Windows 7 commence au troisième trimestre de 2014.

< pleure >

Bref, je ne sais pas si Shift + Del Je les laisserais probablement ignorés dans un coin de l'environnement, au cas où l'innommable se produirait et que vous auriez besoin d'une aide supplémentaire. Windows XP pour quelque chose. Arrêtez définitivement de prendre la peine de les maintenir, de les mettre à jour, de les tester ou quoi que ce soit d'autre, mais gardez-les à portée de main au cas où ils seraient nécessaires. Il est arrivé l'autre jour qu'un client veuille que j'assure le support d'un projet de Windows 2000 PoS, ce que j'ai pu faire, parce que je n'ai pas fait sauter tous mes Server 2000 images lorsque Server 2003 est sorti (et je le voulais vraiment aussi).

Même si vous priez et espérez que ce moment n'arrivera jamais, il est toujours agréable d'avoir ce genre de choses à portée de main "au cas où", et les coûts de conservation sont si insignifiants que je pense qu'il est insensé de ne pas le faire.

Ayant eu des problèmes considérables dus à des problèmes d'anciens logiciels, je peux seulement dire de s'assurer que tout que vous exécutez peut être exécuté sur un OS 64 bits. Si c'est le cas, vous n'avez aucune raison de ne pas migrer, en supposant que la licence n'est pas un facteur.

Dans mon cas, j'ai pu reconfigurer les systèmes de manière à ce que toutes les applications 32 bits puissent fonctionner sur une seule machine, permettant ainsi à toutes les autres stations de travail d'être en 64 bits. Finalement, j'ai même migré cette machine 32 bits vers une VM sur Virtualbox, fonctionnant sur un hôte Debian, principalement parce que la capacité était là et que je voulais réduire le nombre de boîtes.