Red Hat a annoncé, ce 5 mars 2015, la version 7.1 de Red Hat Enterprise Linux (RHEL), distribution commerciale destinée aux professionnels et aux entreprises.
Pour rappel, RHEL 7 est disponible depuis juin 2014 et apporte de nombreuses nouveautés, comme Docker et systemd, mais crée une rupture avec le passé en ne proposant plus d'installation sur un système x86 32 bits.
Vous trouverez en deuxième partie de cet article une sélection des changements apportés.
Sommaire
Prise en charge du matériel
Red Hat ajoute à son étendue d'architectures prises en charge la variante little endian des processeurs IBM POWER8. Toutefois, on remarquera une limitation assez importante : en effet, seule l'installation en tant que machine virtuelle dans un système Red Hat Enteprise Virtualization for Power est prise en charge par le support. Le code pour cette architecture est ppc64le.
Côté Intel, RHEL 7.1 permet d'utiliser les processeurs de la 5e génération Core (Broadwell), ainsi que les puces graphiques associées (pour la 2D et la 3D). Du coup, l'outil turbostat (inclus dans le paquet kernel-tools) a été mis à jour. Autre mise à jour pour les processeurs Intel, microcode_ctl passe de la version 0x17 à la version 0x1c.
AMD n'est pas en reste, RHEL 7.1 voit arriver l'accélération graphique matérielle sur les puces graphiques Hawaii (Radeon R9 290 et Radeon R9 290X).
Une nouvelle édition de RHEL fait son apparition : Red Hat Enterprise Linux for Real Time. Il s'agit en fait d'un noyau spécifique associé à des outils particuliers afin de répondre aux contraintes d'un système temps réel.
Installation et démarrage
Kdump est un outil qui, lors d'un crash du noyau, crée une image mémoire (vmcore). Cette image mémoire peut ensuite être analysée. Red Hat Enterprise Linux possède déjà kdump, mais sa configuration au moment de l'installation ne se fait qu'au moment du premier démarrage. Si vous effectuez une installation automatisée ou que vous n'installez pas le paquet firstboot, cela peut être problématique. Red Hat a donc déplacé la configuration de kdump plus tôt dans l'installation, qui possède maintenant son propre menu écran dans Anaconda.
Autre amélioration dans l'installation, côté réseau : il est maintenant possible de configurer un bridge (pont réseau) depuis le menu d'installation, ainsi que dans Kickstart. Red Hat détaille dans ses notes de version que tout cela est documenté dans le guide réseau (Networking Guide dans la langue de Shakespeare).
Si comme votre serviteur vous aviez l'habitude de jongler entre Ctrl+Alt+F1 et ses acolytes F2 à F6 lors d'une installation interactive pour voir les logs, vous allez être surpris : maintenant, ils sont dans des panneaux tmux ! Les deux raccourcis claviers Ctrl+Alt+F1 (interface texte) et Ctrl+Alt+F6 (interface graphique) sont toujours accessibles, mais pour lire les logs, il faudra utiliser les raccourcis par défaut de tmux, Ctrl+b X (où X est le numéro du panneau).
Il y a aussi du nouveau dans Kickstart ! Le système d'installation automatisée de Red Hat se voit ajouter de nombreuses modifications, en voici quelques-unes :
- il devient possible, grâce à l'option --profile= de la commande logvol, de spécifier un profil à un volume logique LVM ;
- toujours sur logvol, les options --size= et --percent= ne peuvent plus être utilisées ensemble ;
- l'option --autoscreenshot de autostep a été corrigée, et enregistre correctement une image de chaque écran dans /tmp/anaconda-screenshots une fois celui-ci quitté, image qu'on pourra retrouver sur le système installé dans /root/anaconda-screenshots ;
- il est maintenant possible, lors du renseignement d'un dépôt (avec la commande repo), de conserver ce dépôt sur le système installé via l'option --install ;
- pour les adeptes d'installation minimale, Red Hat ajoute l'option --nocore dans la section %packages, qui empêche d'installer les paquets du groupe @core (on se rappelle qu'il était déjà possible de ne pas installer les paquets du groupe @base via l'option --nobase).
Vous en avez assez de redémarrer après une mise à jour noyau ? Vous ne voulez pas souscrire au service d'Oracle ? N'ayez crainte, RHEL 7.1 introduit kpatch (détaillé dans la dépêche sur le noyau Linux 4.0) pour les systèmes x86_64 (mais c'est une avant-première technologique, sinon ce n'est pas drôle) !
Pour terminer cette partie sur l'installation, on peut aussi mentionner l'ajout d'une rubrique d'aide directement dans Anaconda, ainsi que l'amélioration de la génération d'entropie dans le cas de chiffrement du stockage via LUKS.
Stockage
Red Hat annonce que la gestion du cache LVM, déjà disponible dans RHEL 7, est maintenant pleinement prise en charge. Cette fonctionnalité permet de créer un volume logique sur un périphérique rapide, volume qui agira comme cache pour un périphérique plus lent. Le cas d'usage le plus typique serait l'utilisation d'un disque SSD comme cache pour un disque dur.
Toujours dans la prise en charge complète de technologies arrivées dans une version précédente, on notera aussi Parallel NFS (pNFS, abordé dans RHEL 6.4).
Même si RHEL 7 a XFS comme système de fichiers par défaut, Btrfs n'est pas totalement oublié, et proposé comme avant-première technologique dans RHEL 7.1. Toujours côté systèmes de fichiers (et avant-première technologique), on peut aussi tester OverlayFS (abordé dans la dépêche sur le noyau linux 3.18 et sur le noyau linux 3.19).
Vous voulez monter un périphérique bloc Ceph comme un disque classique, et pouvoir formater ce disque en XFS ou ext4 ? Avec RHEL 7.1, vous pouvez maintenant le faire, car le noyau comporte maintenant les modules libceph.ko et rbd.ko. Malheureusement, le module ceph.ko n'est pas pris en charge par le support.
Virtualisation et conteneurs
On démarre cette rubrique avec KVM, qui voit le nombre de processeurs passer à 240 par machine virtuelle. Bien entendu, les processeurs Intel mentionnés dans la rubrique sur le matériel sont aussi utilisables. Pour ceux qui souhaitent brancher des périphériques USB dans leurs machines virtuelles, il est maintenant possible d'ajouter un port USB 3 dans celles-ci (en avant-première technologique).
Pour les utilisateurs d'Hyper-V, les performances devraient s'améliorer, principalement dans le domaine du réseau. On remarquera aussi que le paquet hyperv-daemons comporte maintenant le démon hypervfcopyd : il s'agit d'une implémentation du service de copie de fichier d'un hôte Hyper-V 2012 R2 vers un invité Linux à travers le VMBUS.
RHEL 7.1 apporte de nouvelles fonctionnalités dans libguestfs, au travers d'outils aux noms explicites :
- virt-builder permet de créer des images de machines virtuelles.
- virt-customize est capable de personnaliser des images de machines virtuelles, comme par exemple installer des paquets, modifier des mots de passe, lancer des scripts ou éditer des fichiers de configuration.
- virt-diff montre les différences entre les systèmes de fichiers de deux machines virtuelles, et vous indique quels fichiers ont changé entre deux instantanés ;
- virt-log est là pour voir les fichiers de log présents dans une machine virtuelle, même pour le journal d'évènement d'un système Windows ;
- virt-v2v s'occupe de convertir une machine virtuelle vers KVM, pour le moment depuis Xen ou VMWare ESX.
Docker passe quant à lui en version 1.4.1 dans RHEL 7.1, apportant des améliorations (ENV, overlayfs) mais aussi des correctifs de sécurité (possibilité de traverser les systèmes de fichiers, ou d'élévation des privilège).
Avec RHEL 7.1 arrive aussi Kubernetes, qui gère l'orchestration des conteneurs. Un guide de démarrage rapide est disponible, ainsi qu'un centre de distribution de conteneurs.
Red Hat annonce aussi Red Hat Enterprise Linux Atomic Host, une version de RHEL spécialement conçue grâce aux outils du projet Atomic.
Vous utilisez encore LXC en association avec libvirt ? Mauvaise nouvelle : les paquets fournissant ces possibilités ont été rendus obsolètes (libvirt-daemon-driver-lxc, libvirt-daemon-lxc et libvirt-login-shell). Il n'y aura plus de mise à jour, et ils pourraient être supprimés dans une prochaine version.
Réseau
NetworkManager passe en version 1.0 sur RHEL 7.1 ! Cela apporte, entre autres, un découpage en plusieurs paquets selon certains type de réseau (Wi-Fi, Bluetooth, ADSL…) afin de n'installer que le juste nécessaire. On remarquera aussi un client DHCP embarqué, qui utilise moins de mémoire. Si par contre vous paramétrez votre réseau de manière statique, NetworkManager se contentera de démarrer et configurer l'interface, puis quittera. D'autres améliorations comportent les routes dans le cas de multiples interfaces, le bonding, IPv6 et l'utilisation en ligne de commande (via l'outil nmcli).
Sécurité
OpenSCAP, qui permet de mesurer la sécurité de ses systèmes, a été introduit par Red Hat à la sortie de RHEL 6.1 (et rétroporté ensuite dans RHEL 5). Pour autant, l'outil seul n'est pas suffisant, c'est pourquoi RHEL 7.1 inclut un paquet nommé scap-security-guide, qui apporte guides et mécanismes de validation.
SELinux voit sa policy modifiée : auparavant, les services qui ne disposaient pas de leur policy étaient étiquetés init_t, ils sont maintenant étiquetés unconfined_service_t
OpenSSH a été mis à jour en version 6.6.1p1, qui apporte entre autres :
- l'échange de clé en utilisant des courbes elliptiques Diffie-Hellman Curve25519, méthode est choisie par défaut si le client et le serveur la possèdent ;
- il est possible de générer une clé publique (hôte ou utilisateur) utilisant des courbes elliptiques de type Ed25519 ;
- un nouveau format de clé privée a été ajouté, utilisant la fonction de dérivation bcrypt ;
- un nouveau transport cipher a été ajouté, chacha20-poly1305@openssh.com, composé de ChaCha20 pour le stream cipher et de Poly1305 pour le message authentication code (MAC).
RHEL 7 utilise Libreswan comme brique de VPN IPSEC. Celui-ci a été mis à jour en version 3.12, qui contient notamment :
- de nouveaux algorithmes de chiffrement ;
- une amélioration de IKEv2 ;
- une amélioration dans le domaine des certificats intermédiaires, en IKEv1 et IKEv2 ;
- une meilleure interopérabilité avec OpenBSD, Cisco, et Android ;
- une meilleure prise en compte de systemd.
D'autres mises à jour concernent Trusted Network Connect (TNC) et GnuTLS (par exemple la compatibilité FIPS 140).
Authentification et interopérabilité
Mise en avant dans l'annonce de Red Hat, la gestion d'identité a été grandement améliorée. Cela passe par des apports pour l'administration (ipa-backup et ipa-restore permettent, comme leur nom l'indique, de sauvegarder et de restaurer IPA), mais aussi par l'ajout du mot de passe à usage unique pour forcer l'authentification à deux facteurs.
La gestion d'identité s'améliore aussi côté interopérabilité, en introduisant un greffon pour SSSD, qui peut maintenant accéder à un partage CIFS, tout comme le faisait Winbind auparavant.
SSSD dispose maintenant de sudo providers, en particulier pour utiliser sudo avec Microsoft Active Directory ou OpenLDAP, mais est aussi capable d'accéder à des GPO Active Directory. Du coup, des administrateurs Windows peuvent utiliser des GPO pour faire du contrôle d'accès sur des machines RHEL.
Environnement de bureau
Peu de choses de ce côté, si ce n'est que la version Desktop confirme le choix de Thunderbird comme client mail.
Développement
La nouveauté de RHEL 7.1 dans le domaine du développement, c'est l'arrivée d'OpenJDK8 ! Red Hat rappelle que cette nouvelle version de l'implémentation Java libre peut être installée en parallèle avec les autres, et qu'elle apporte de nombreuses améliorations, dont JDBC 4.2 et la prise en charge au niveau matériel d'AES.
L'outil snap a été retiré du paquet powerpc-utils, au profit de sosreport. Bien entendu, si vous développez pour la plateforme Little-Endian d'IBM Power8, vous pourrez utiliser GDB.
OProfile a été amélioré pour prendre en compte plus d'architectures matérielles, dont les Intel Atom C2XXX, les processeurs de la 5e génération Core, IBM POWER8, AppliedMicro X-Gene et ARM Cortex A57.
Aller plus loin
- Red Hat (213 clics)
- DLFP : Red Hat Enterprise Linux 7 (871 clics)
- DLFP : Red Hat Enterprise Linux 6.6 (103 clics)
- DLFP : Red Hat Enterprise Linux 5.11 (57 clics)
- Annonce de RHEL 7.1 (188 clics)
- Annonce de la version beta (22 clics)
- Notes de version (94 clics)
# LXC ?
Posté par MTux . Évalué à 5.
Bravo pour la dépêche, sacré boulot !
Ce passage :
Me laisse dubitatif. Red Hat se désintéresse de LXC ? Il faut dire que c'est de plus en plus le cas, seul Canonical semble continuer à miser dessus.
[^] # Re: LXC ?
Posté par Gandalf . Évalué à 1.
Docker utilise bien LXC, non ?
[^] # Re: LXC ?
Posté par matteli . Évalué à 2.
Plus depuis la version 0.9. Docker a sa propre librairie.
[^] # Re: LXC ?
Posté par jfmartin . Évalué à 1.
Il est tard donc j'ai pas la motivation de vérifier.
IIRC, LXC de libvirt n'utilise pas le projet LXC mais à sa propre implémentation de la gestion de conteneurs.
[^] # Re: LXC ?
Posté par benoar . Évalué à 2.
Oui, libvirt a son propre « driver », mais d'un point de vue extérieur, il a toujours l'air maintenu dans le projet libvirt. RedHat a-t-il des informations supplémentaires là-dessus ? Vu que libvirt est géré par RH, j'aimerais bien savoir ce qu'il en est de l'avenir de ce driver.
Je peux comprendre qu'avec Docker ça fasse un peu redondant, mais pour moi c'était une bonne alternative qui a quand même ses différences et ses atouts.
[^] # Re: LXC ?
Posté par jfmartin . Évalué à 2.
Merci pour la confirmation.
Je ne connais pas l'état du driver mais je pense qu'il devrait utiliser la bibliothèque fournis par LXC.
Dans un vidéo d'une conférence de l'année dernière, un développeur d'OpenVZ parlait de fusionner les deux projets.
Néanmoins les deux projets garderaient des outils séparer (lxc-* & vzctl *).
Donc ce serait sûrement intéressant que libvirt prenne la même direction.
[^] # Re: LXC ?
Posté par madhatter (site web personnel) . Évalué à 1.
Je ne crois pas que Red Hat se désintéresse de LXC.
Suite à une recherche sur le sujet, j'ai lu il y a quelques jours un message de Stephane Graber au sujet du support de LXD dans libvirt :
Pour ceux qui ne comprennent pas l'anglais, pour résumer, il dit que bien que rien ne s'oppose au développement d'un driver LXD pour libvirt, il pense que ce n'est pas une bonne idée dans la mesure où les conteneurs et les VM classiques se gèrent de façon trop différentes pour qu'une couche d'abstraction comme libvirt (orientée gestion de VM classiques) soit valable pour les conteneurs. Par exemple, tout ce qui concerne la gestion du matériel émulé pour les VM n'a pas lieu d'être pour les conteneurs. Il y aurait donc une grosse partie de l'API et par conséquent de la GUI associée (virt-manager par exemple) qui ne servirait à rien dans le cas des conteneurs. A l'inverse, il y a des choses spécifiques aux conteneurs (comme transférer une interface réseau, ou n'importe quel périphérique de l'hôte) qui n'existeraient pas ou qui seraient spécifiques et inutiles pour les VM.
Le but du projet LXD est justement de fournir une API pour la gestion des conteneurs (et de leurs hôtes) équivalente à ce que fait libvirt pour les VM.
Du coup, même si c'est effectivement plutôt Canonical qui pousse au cul pour LXC/LXD, cet abandon de support par Red Hat ne me fait pas pour autant penser qu'ils se désintéressent de LXC.
There is no spoon...
[^] # Re: LXC ?
Posté par benoar . Évalué à 2.
Mouai, je ne suis pas convaincu, je pense qu'il n'a pas beaucoup touché à libvirt-lxc pour dire ça.
Effectivement, et ça s'intègre quand même très bien au modèle libvirt.
Mais qui sont quand même présentent dans libvirt ! (bon, pas directement pour l'interface réseau, mais je ne vois pas de cas où ça a un intérêt vu les possibilités réseau de libvirt)
Franchement, il y a déjà à peu près tout ce dont il parle dans libvirt-lxc. C'est juste qu'ils veulent se différencier et faire un truc à part, bien intégré à OpenStack (déjà, ça devrait être signe que le NIH point son nez). Il faut lire l'annonce d'Ubuntu pour LXD http://www.ubuntu.com/cloud/tools/lxd pour voir comment ça sent le bullshit à 100 mètres.
Bah, je ne comprends pas du coup pourquoi ils laissent tomber ça dans RHEL, sachant que je n'ai pas vu de nouvelle upstream du projet libvirt. C'est assez étrange.
# RHEL 32-bits
Posté par microlinux (site web personnel) . Évalué à 2. Dernière modification le 13 mars 2015 à 08:09.
RHEL ne propose plus de version x86 32-bits. Pour info, le clone Springdale Linux propose une version 32-bits, bien cachée dans les dépôts. Et Johnny Hughes, mainteneur de CentOS, a annoncé une version 32-bits de la distribution après la sortie de CentOS 7.1.
Dyslexics have more fnu.
[^] # Re: RHEL 32-bits
Posté par koopa . Évalué à 0.
ça sera bien utile, car il y a encore beaucoup de logiciel qui ont besoin de l'architecture i386, en particulier wine32.
[^] # Re: RHEL 32-bits
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 13 mars 2015 à 10:28.
J'ai du mal à cerner le besoin d'une RHEL pour faire tourner wine32 (ou autre truc 32-bit), pas la même cible de ce que je connais (plutôt serveur avec du 64-bit de partout, même les intel Avoton sont en 64-bit, il faut descendre à du Via Nano pour avoir que du 32-bit sur des serveurs et ce genre de besoin passe de plus en plus en virtualisé donc 64-bit disponible pour pas cher quand même).
Quelqu'un pour me donner des exemples de cas pratiques où il prèfère du RH plutôt qu'une autre (Fedora, Debian, BSD…) et pourquoi il préfère RH? Même question sur la préférence 32-bit?
[^] # Re: RHEL 32-bits
Posté par Renault (site web personnel) . Évalué à 1.
Red-Hat ce sont aussi des postes utilisateurs en bureautique, pas que des serveurs de pointe.
[^] # Re: RHEL 32-bits
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 13 mars 2015 à 11:11.
Et il y a des postes bureautiques en 32-bit de nos jours, prêt à recevoir une distro de ce type (la version 7)?
(ça doit faire quelques années que je n'ai pas vu de CPU 32-bit sur un bureau, à part les Raspberry Pi et co, bien sûr, mais pas le même usage).
[^] # Re: RHEL 32-bits
Posté par Renault (site web personnel) . Évalué à 1.
Tu sais, chez certains grands comptes tu avais du Windows XP 32 bits l'année dernière sur des machines très récentes. Cela peut être pareil pour RHEL même si ça n'a pas d'intérêt réel.
Je suppose que si Red-Hat maintient le 32 bits, c'est que ça a son intérêt financier.
[^] # Re: RHEL 32-bits
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 13 mars 2015 à 11:23.
Justement, il ne le fait pas ;-) (voir le premier commentaire qui dit la même chose, voir la page de téléchargement de RHEL)
J'imagine que c'est parce qu'il n'y a pas son intérêt financier (pas assez de monde ayant du 32-bit ou voulant installer une nouvelle version en 32-bit).
D'où ma réaction : je fais remarquer que si il ne le fait pas, c'est sans doute pour une bonne raison, et demande de savoir quel usage serait pour une nouvelle version (donc validation obligatoire) qui serait testée en 32-bit (je me dis bêtement qu'une nouvelle version sera testée qu'avec une seule archi si c'est possible pour l'entreprise)
Tu réponds donc avec une raison de pourquoi il le fait (alors qu'il ne le fait pas, ce uqi invlaide ta réponse) alors que je demande pourquoi il le ferait (une explication qui montre qu'il a tort de ne pas le faire).
Machines récentes donc 64-bit possible. le WinXP 32-bit est historique j'imagine (flemme de valider la version 64-bit alors qu'il faut aussi valider Win8, uqi lui sera sans doute validé qu'en 64-bit)
[^] # Re: RHEL 32-bits
Posté par Renault (site web personnel) . Évalué à 2.
Oups pardon, je n'avais pas lu le premier commentaire de ce fil.
Je te rejoins donc.
[^] # Re: RHEL 32-bits
Posté par koopa . Évalué à 1.
RHEL n'a aucun intérêt financier à supporter le 32-bits car il ne cible que les serveurs. En revanche ses clones tel que CentOS sont très souvent utilisés sur des postes de bureautique et des stations de travail afin de bénéficier d'un système stable et maintenu pendant 10 ans.
Par exemple, sous CentOS 6.x 64 bits tu peux installer wine32 pour avoir accès à des centaines de milliers d'applications windows. En revanche, sous CentOS 7.0, il n'y a aucun paquet pour i386, donc adieu wine32 et ses applications. Mais heureusement, ça reviendra peut-être pour Centos 7.2.
[^] # Re: RHEL 32-bits
Posté par Zenitram (site web personnel) . Évalué à 4.
Mais la, tu parles d'un OS 64-bit avec support possible de logiciel 32-bit ou d'OS 32-bit?
Car ce n'est pas du tout la même chose (dans un cas, on compile les libs uniquement, et dans le second on compile tout et pas le droit de faire tourner de 64-bit).
Je comprend l'interêt du multi-lib (faire tourner un logiciel proprio que 32-bit), moins le 32-bit pur (vu que les CPU sont quasi tous, même de bureau, en 64-bit possible) et me pose la question d'un exemple concret d'utilité de nos jours (mettre une CentOS 7 sur un Via Nano? Est-ce que ça va exister encore longtemps face aux VM?)
[^] # Re: RHEL 32-bits
Posté par Prosper . Évalué à 6.
J'ai une centos 7 sous la main et je peux encore installer des bibliothèques xxxxxx.i686 .
[^] # Re: RHEL 32-bits
Posté par Antoine . Évalué à 4.
Heu, ça ne veut pas dire que le CPU n'est pas 64 bits. Juste que l'entreprise préfère continuer à mettre le système d'exploitation qu'elle a choisi il y a dix ans…
[^] # Re: RHEL 32-bits
Posté par lasher . Évalué à -1.
Non, mais ça veut dire que les binaires n'utilisent que la moitié des registres disponibles par cœur, que le mode d'adressage est toujours du 36 bits plutôt que 48 (ou je ne sais quelle plage d'adressage est utilisée pour du 64 bits), que les instructions AVX ne peuvent être utilisées, etc.
[^] # Re: RHEL 32-bits
Posté par Zenitram (site web personnel) . Évalué à 4.
Mais tu ne dis toujours pas pourquoi on ne pourrai pas installer une version 64 bit lors q'une changemetn de version de l'OS…
C'est la question posée.
Ce dont tu parles, on le sait (et surtout, ce n'est pas le sujet)
[^] # Re: RHEL 32-bits
Posté par lasher . Évalué à 3.
Oui, oups pardon.
La seule raison que je puisse voir, c'est que l'entreprise n'ait jamais pris le temps de requalifier les interactions entre OS 64 bits et leurs applis 32 bits (supposons-les dispo uniquement sous forme binaire), malgré la présence de bibliothèques de compatibilité. Du coup elles préfèrent avoir un « tout 32 bits ».
J'allais demander si les Atom d'Intel étaient toujours 32 bits, mais apparemment non. Donc même pour des processeurs de puissance « minimale » (ou avec des contraintes sur la conso), on est en 64 bits.
[^] # Re: RHEL 32-bits
Posté par microlinux (site web personnel) . Évalué à 2.
Parmi mes clients, j'ai pas mal de mairies, de médiathèques et d'écoles locales, qui disposent très souvent d'un parc matériel ancien mais en état de marche. Généralement ils sont contents de ne pas devoir réinvestir dans du nouveau matériel.
J'ai opté pour CentOS (un clone de RHEL) plutôt que Fedora/Debian à cause de la période de support pour les mises à jour de sécurité. 18 mois pour Fedora, 1 à 3 ans pour Debian et 10 ans pour RHEL et dérivées.
Sur un serveur du genre IBM X 225, on peut très bien faire tourner une Springdale Linux 7 32-bits, supportée jusqu'en 2024. Si c'est vraiment trop juste, je me base sur du CentOS 6.x 32-bits (EOL en 2020), parfois même du 5.x (EOL 2017) pour les très vieux coucous.
Dyslexics have more fnu.
# et ARM
Posté par ManuxFr (site web personnel) . Évalué à 1.
Toujours pas de support officiel de la plateforme ARM ?!
Je trouve étonnant le "retard" que prend la firme au chapeau rouge dans ce domaine…
[^] # Re: et ARM
Posté par Zenitram (site web personnel) . Évalué à 3.
ARM essaye de viser le milieu des serveurs, mais ça a plutôt créé des faillites, personne ne voit vraiment un business model viable autour de serveur ARM.
Donc c'est logique (tout comme l'arrêt du support x86 32-bit est logique, plus vraiment de serveurs pros, la cible de Red Hat, en 32-bit)
En attendant, pour jouer, il y a Fedora, soutenu par Red Hat.
[^] # Re: et ARM
Posté par Antoine . Évalué à 3.
Il y a encore qui essaient, comme AMD ou HP. Je suis d'accord que ça n'a pas l'air très prometteur…
[^] # Re: et ARM
Posté par claudex . Évalué à 4.
Je ne vois pas bien de quel retard tu parles, Fedora (la base des RHEL) tourne sur ARM. Le jour où les clients de RedHat demanderont ça, ça devrait pouvoir sortir assez vite.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.