Le retard de la RHEL 5 s'explique principalement à cause de l'intégration de Xen, ce qui a forcé Red Hat à repousser son calendrier de fin 2006 à fin février, puis mi-mars. Il aura fallu au total plus de deux ans de développement pour y arriver, passant entre autres du noyau 2.6.9 au 2.6.18.
Parmi les nouveautés de cette nouvelle mouture, on trouvera :
- Intégration de Xen, la célèbre solution de virtualisation ;
- Une version intégrée de Red Hat Cluster Suite, permettant de construire des clusters haute disponibilité (HA);
- Support de l'iSCSI, un protocole permettant le transport de commandes SCSI sur un réseau TCP/IP ;
- Support d'InfiniBand, un bus système à haut débit qu'on pourrait mettre en concurrence avec PCI-Express ;
- SystemTap, un outil de diagnostic noyau ;
- Support des processeurs 64 bits quadri-coeurs ;
- Frysk, un outil pour monitorer et déboguer des applications
Aller plus loin
- Red Hat (28 clics)
- Red Hat Enterprise Linux (76 clics)
- Xen (4 clics)
- SystemTap (2 clics)
- Frysk (2 clics)
- Sources des logiciels (14 clics)
# Re:
Posté par IsNotGood . Évalué à 8.
Et AMD.
M'enfin, Red Hat a une tripotée de partenaires. Dont Oracle :-)
Notons que le nombre d'applis pour Redhat qui sont certifiées "explose". On est maintenant à près de 3000.
J'ai regardé le webcast de la sortie de RHEL 5. Il n'y a pas un mot sur le desktop !
Je ne parle pas du desktop en entreprise qui est peu abordé.
C'est serveur, virtualisation, serveur, virtualisation, serveur, développement, java, Jboss, Fedora, innovation, communauté du libre, Eclipse, virtualisation, déploiement, ouverture, souplesse, etc. Mais jamais desktop.
Je pensais qu'il y aurait un petit frémissement d'intérêt de ce côté de la part de Red Hat, ben nada. C'est que dédié entreprise. Ce n'est pas un reproche, c'est un constat.
> Le retard de la RHEL 5 s'explique principalement à cause de l'intégration de Xen
Je crois qu'il n'y a pas que ça pour expliquer le retard.
Red Hat a, semble-t-il au dernier moment, décidé d'ajouter la paravirtuaisation à RHEL 4 et que ce soit dispo à la sortie de RHEL 5 (NB : RHEL 4 est basé sur un 2.6.9 et doit resté compatible binaire et source). Enfin Red Hat a ajouté GFS pour RHEL 5 Advanced Plateforme. En général GFS sortait avec quelques semaines de retard. Il y a GFS 1 et GFS 2 (GFS 2 : considéré en preview au moment de la sortie de RHEL 5).
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Mais bonne nouvelle, on peut maintenant acheter du RHEL 5 desktop à l'unité (ce qui n'était pas le cas pour RHEL 4).
http://www.europe.redhat.com/rhel/desktop/compare/
Prix : de 80 $ à 219 $ par an (basic support).
Intéressant.
Pour 219 $ on a tout sauf quelques trucs pointus (cluster, gfs). Mais il y a les applis serveurs, virtualisation (nombre de guest illimité), développement, etc...
C'est limité à deux socket/cpu. Limité le mot est un peu fort. C'est utilisable avec un bi-quadruple-coeur.
Globalement les prix ont significativement baissé entre RHEL 4 et 5.
[^] # Re: Re:
Posté par Frédéric Mangeant (site web personnel) . Évalué à 2.
D'ailleurs dans RHN seules les 5 images ISO "Server" ont l'air d'être disponibles.
[^] # Re: Re:
Posté par ragoutoutou . Évalué à 3.
Le nom du canal est "Red Hat Enterprise Linux Desktop (v. 5 for 32-bit x86)" (pour le version 32bit)
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
[^] # Re: Re:
Posté par Jasi Kiban . Évalué à 1.
Ah non ! C'est différent, me dit-on. Microsoft, lui, vendait le même produit à des prix différents. Il suffisait juste de modifier des clés dans la base de registre pour transformer un "Windows NT Workstation" en "Windows NT Server".
http://www.virus.ldh.org/num_01/pages/page27.html
# fin de libpthreads
Posté par Corsaire . Évalué à 4.
Terminé les programmes développés par des fainéants qui comptaient sur des LD_ASSUME_KERNEL=2.4.18 à gogo et qui donnaient comme excuse quand on leur disait que c'était dépassé (même déconseillé) "Oui mais nous on se base sur la RedHat enterprise" quand on leur disait que leur merdasse refusait de marcher (pour Fedora depuis la FC5).
Oui j'en ai quelques exemples bien énervants.
[^] # Re: fin de libpthreads
Posté par IsNotGood . Évalué à 2.
Ben ils utilisent RHEL 4 pour encore 5 années. Autre choses, RHEL 5 offre de la virtualisation (et même de la paravirtualisation). Donc on peut faire tourner du RHEL 4 dans du RHEL 5 (sans compter la possibilité du chroot, ça marche pour linuxthread).
Pour RHEL 4 c'était et c'est :
- NPTL supporté
- linuxthread supporté mais obsolete
C'était annoncé à la sortie de RHEL 4 il y a plus de deux ans. On savait déjà qu'il n'y aurait pas linuxthread dans RHEL 5.
[^] # Re: fin de libpthreads
Posté par IsNotGood . Évalué à 2.
J'ai remis la main sur la release note de RHEL 4 :
[^] # Re: fin de libpthreads
Posté par Raphaël G. (site web personnel) . Évalué à 4.
(que je la comprenne par l'exemple)
ps : je refuse pas une explication historique et de ce que c'est un peu plus complète (a part linuxthreads ça pue et consort svp)
[^] # Re: fin de libpthreads
Posté par IsNotGood . Évalué à 3.
Linuxthread et NPTL se veulent conforme Posix. Donc il n'y a pas de grosses différences. La grosse différence au niveau programmation est dans la gestion des signaux.
[^] # Re: fin de libpthreads
Posté par Corsaire . Évalué à 2.
C'est moi qui leur ait appri il y quelque chose comme 2 mois quand nous avons passé certains postes en FC6 que cela faisait 2 ans que l'obsolescence était annoncée.
# Re:
Posté par IsNotGood . Évalué à 6.
http://www.linuxformat.co.uk/modules.php?op=modload&name(...)
Fait sur un double quadruple coeur.
Là n'est pas l'intérêt de l'article.
Point important. C'est Havoc qui avait lancé cette idée. Il y a le logiciel libre, il devrait y avoir l'entreprise libre ou du moins ouverte/transparente.
L'accord MS/Novell :
Marrant car dans le webcast RHEL5, Red Hat a deux ou trois fois indiqué qu'ils avaient beaucoup de développeurs Samba :-)
[^] # Re: Re:
Posté par yoplait . Évalué à 3.
Oui, disons plutôt « ouverte ». Parce que le logiciel, il est dit libre car il a été libéré des contraintes de la propriété intellectuelle [1], alors si on libère une entreprise des contraintes de la propriété tout court, on va encore se faire accuser de communisme, et j'avoue que là il y aura de quoi ;).
[1] Je sais, l'auteur conserve toujours tous ses droits, mais la branche, l'instance ou la version (je ne sais pas trop comment l'appeler) du logiciel copylefté restera à jamais libre des monopoles de représentation et de reproduction.
# Infiniband
Posté par olosta . Évalué à 6.
Disons que lorsque Infiniband a été crée il était peut-être sensé être en concurence avec PCI-Express mais aujourd'hui Infiniband est un type de réseau (comme ethernet).
Ce réseau a comme caractèristique d'avoir un haut débit (10Gb/s) et une très faible latence. Cela le rend très adapté comme réseau d'interconnect pour les clusters de calcul (des versions de MPI sachant l'utiliser existent).
Si il faut vraiment le mettre en concurence avec quelque chose on peut citer Myrinet, Quadrics ou NUMALink.
Et les cartes Infiniband sont en général des cartes PCI-Express.
Je me rend compte que la confusion vient probablement de wikipedia:fr, faudrait vraiment changer cet article pour qu'il ressemble plus a la version en.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Infiniband
Posté par olosta . Évalué à 2.
Mais j'ai l'impression que la techno a encore a faire ses preuves dans le domaine alors qu'en tant qu'interconnect pour le calcul elle est très reconnue.
[^] # Re: Infiniband
Posté par Matthieu . Évalué à 3.
[^] # Re: Infiniband
Posté par olosta . Évalué à 2.
Le truc c'est que l'IB est le plus souvent vendu comme une option de serveurs (HP, Dell, IBM...).
http://www.melrow.nl
http://search.ebay.com/search/search.dll?from=R40&satitl(...)
# Ca mere!
Posté par gnumdk (site web personnel) . Évalué à 4.
>SCSI sur un réseau TCP/IP ;
Et alors la je demande à tous les redhateux du coin, ca utilise openiscisi?
Parce que chez Hitachi, on a eu droit dernierement au beau discour: "oui, mais on connait que linux-iscsi (projet mort) et si debian n'utilise pas ca, on sera pas comment faire fonctionner notre matos"...
Et comme la boite ne supporte que RedHat, le passage de redhat à openiscsi pourrait me donner de bon argument pour qu'ils trouvent comment faire fonctionner leur matos sous Debian....
Voila, merci ;)
[^] # Re: Ca mere!
Posté par ccomb (site web personnel) . Évalué à 3.
[^] # Re: Ca mere!
Posté par gnumdk (site web personnel) . Évalué à 3.
Sauf que la, avec une baie WMS100, impossible de lancer le "discover".
[^] # Re: Ca mere!
Posté par ragoutoutou . Évalué à 5.
Oui, c'est un protocole transportant le scsi sur tcp/ip, donc contrairement à l'ATAOe, c'est implémentable avec une infrastructure réseau complexe.
Oui, mais ce n'est généralement pas intégré... il faut souvent recompiler...
[^] # Re: Ca mere!
Posté par P.-A. . Évalué à 1.
[^] # Re: Ca mere!
Posté par ragoutoutou . Évalué à 4.
iScsi, de son côté, permet de mettre des routeurs entre le san et le client.
En gros,
AoE bouffe moins de cpu
iSCSI est plus flexible
...
Et avec du hardware san iSCSI, l'os dialogue directement avec de vrais disques qui reçoivent les commandes scsi sans transformations.
# Un peu de com/marketing
Posté par IsNotGood . Évalué à 4.
http://www.redhat.com/videos/real_tech/
Novell :
http://www.novell.com/linux/demos/sles_main.swf
La forme est très différente.
# Demo Xen
Posté par hippolyte . Évalué à 3.
putain l'angoisse !!
[^] # Re: Demo Xen
Posté par IsNotGood . Évalué à 3.
[^] # Re: Demo Xen
Posté par hippolyte . Évalué à 2.
[^] # Re: Demo Xen
Posté par IsNotGood . Évalué à 1.
Sinon où est cette démo ?
[^] # Re: Demo Xen
Posté par hippolyte . Évalué à 2.
Ça n'était donc pas une "attaque" contre RH :-)
Je n'aurais pu avoir cette réaction à l'encontre de RH car une démo de leurs produits et Fédora, et là, pas besoin de s'enregistrer pour le télécharger ...
[^] # Re: Demo Xen
Posté par IsNotGood . Évalué à 2.
Je croyais que c'était une démo sur http://www.redhat.com/ (normal c'est une dépêche sur Red Hat).
Désolé.
# La doc est en ligne
Posté par IsNotGood . Évalué à 2.
On y trouve entre autres la note de mise à jour.
C'est aussi une excellente source d'information pour les utilisateurs de GNU/Linux et plus spécifiquement de Fedora.
Malheureusement la version française n'est pas en ligne et Red Hat semble être à la bourre (il n'y a pas de version pdf par exemple).
# CentOS est dispo aussi en beta
Posté par lezardbreton . Évalué à 5.
[^] # Re: CentOS est dispo aussi en beta
Posté par IsNotGood . Évalué à 4.
Mandriva, Ubuntu 6.10 utilise un 2.6.17, Slackware un 2.4.x.
Sinon Red Hat/Fedora utilise un nouvel ensemble (libata) pour ide/scsi. Développement de l'ensemble dirigé principalement par Alan Cox et maintenant en upstream (2.6.18?). A ma connaissance il n'y a que Red Hat et Fedora qui l'active par défaut. Les autres utilisent l'ancien système et attendent que Red Hat le débuggue et se fasse maudire par les utilisateurs avant qu'ils l'adoptent aussi...
Il y a peut-être des bugs pour toi, mais ça doit débloquer d'autres personnes. Le passage à libata (et son développement) n'a pas été faire pour rien et doit avoir des bénéfices. On ne fait pas d'omelette sans casser des oeufs, malheureusement.
> Quelqu'un aurait un indice pour que je puisse installer et booter sans perdre 3 minutes à chaque démarrage ?
Pas moi. Demande à Centos de corriger le bug :-)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211211
[^] # Re: CentOS est dispo aussi en beta
Posté par ZeroHeure (site web personnel) . Évalué à 1.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: CentOS est dispo aussi en beta
Posté par lezardbreton . Évalué à 2.
Je comprends mieux du coup.
Pour info, le bug est là : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391867
[^] # Re: CentOS est dispo aussi en beta
Posté par IsNotGood . Évalué à 1.
Pas sortie.
> , Debian Sid
Branche développement.
> Ubuntu 7.04.
Pas sortie.
> Ubuntu 6.10
???
Si je ne me trompe pas, Ubuntu 6.10 a un noyau 2.6.17 (sans libata).
# Mises à jour... Pire que Microsoft?
Posté par ragoutoutou . Évalué à 1.
Tout ça pour forcer la main des clients pour qu'ils achètent Rnh satellite...
[^] # Re: Mises à jour... Pire que Microsoft?
Posté par IsNotGood . Évalué à 3.
> Tout ça pour forcer la main des clients pour qu'ils achètent Rnh satellite...
Sans le moindre doute.
Tu devrais en faire une news (oublie de dire que tu peux downloader les paquets directement depuis http://rhn.redhat.com/).
> Pire que Microsoft?
Au fait, comment tu fais pour downloader un paquet MS ? Je n'ai pas trouvé.
> sous Redhat5, cette cochonnerie de yum est incapable de faire un --downloadonly
Non, il n'y a pas. Mais tu peux porter yum-utils pour RHEL5. Il y aura bientôt un RHEL Extras.
NB : Red Hat a changé sa politique de support. Avant Red Hat ne supportait pas tous les paquets fournis (il y avait quelques exceptions dont le populaire kernel-modules-unsupported). Maintenant tout est supporté (sauf ce qui est "technologie preview").
Pourquoi tu veux les paquets binaires ? Pourquoi cette éxigence ? Si de temps à autre tu veux un paquet binaire, direction => http://rhn.redhat.com/ .
Si tu les veux systématiquement, à part faire un truc qui n'est pas en accord avec le support de RedHat, je ne vois pas ce que tu veux faire.
NB : je n'ai pas dit que c'était illégal car il est tout à fait légal de copier une RHEL (sauf que Red Hat peut alors refuser de donner du support).
[^] # Re: Mises à jour... Pire que Microsoft?
Posté par ragoutoutou . Évalué à 3.
- Parceque RedHat Network n'est pas adapté aux besoins de l'entreprise pour laquelle je travaille, que pour certains éléments il est carrément contraire aux polices de sécurité, et qu'il faut tout de même une méthode de distribution des hotfixes convenable quand on a un grand parc de serveurs avec des environnements différents ainsi qu'une compartimentation réseau.
- Parceque Rhel5 est une baisse de fonctionnalités à ce niveau par rapport à RedHat4.
- Parceque le contrat de support entre redhat et la société pour laquelle je bosse est de plusieurs dizaines de millieurs d'euros, et vu le prix unitaire de la license, ce serait sympa de traiter les clients un peu mieux.
Paquet, non, hotfix oui... et c'est facilement automatisable (si on ne veut pas utiliser WSUS, WUS, ... )
[^] # Re: Mises à jour... Pire que Microsoft?
Posté par IsNotGood . Évalué à 1.
Mouaif. Mouaif car tu fais quoi avec "yum --downloadonly" ?
Tu utilises rhn, donc tu dépends de rhn. Tu peux tout autant aller sur http://rhn.redhat.com/ . Puis c'est pas sorcier de mettre en place un firewall qui ne laisse passer que le protocol rhn en sortant.
Donc je ne vois pas bien le rapport avec ton propos.
> - Parceque Rhel5 est une baisse de fonctionnalités à ce niveau par rapport à RedHat4.
Oui. Essaie d'installer yum-utils.
Le src.rpm de fc6 (doit probalement se "compiler" sans problème sur RHEL 5) :
http://fr2.rpmfind.net/linux/fedora/extras/6/SRPMS/yum-utils(...)
Tu trouveras sans difficulté la version "noarch.rpm" si tu ne veux pas compiler.
Notes que RHEL passe de up2date (qui sous RHEL4 ne savait communiquer qu'avec rhn) à yum. Donc il n'y a pas qu'une perte de fonctionnalité dans le passage de up2date à yum. Il y a aussi un gain évident pour le client (pas évident pour Red Hat).
> - Parceque le contrat de support entre redhat et la société pour laquelle je bosse est de plusieurs dizaines de millieurs d'euros, et vu le prix unitaire de la license, ce serait sympa de traiter les clients un peu mieux.
Certes. Mais as-tu contacté Red Hat avant de venir "gueuler" ici ? Si tu payes "plusieurs dizaines de millieurs d'euros" tu devrais faire ça en premier. C'est évident, c'est ce que j'aurai fait en premier (après évidemment avoir vérifier que RHEL 5 ne fournit pas la fonctionnalité) !
Je suis convaincu qu'il y aura yum-utils dans pas longtemps pour RHEL 5.
http://fedoraproject.org/wiki/EPEL.
Notes que c'est un projet sous le chapeau de Red Hat. Que ça fait partit de la "stratégie" RHEL. Si Red Hat voulais "embrigader" les utilisateurs de RHEL 5, il n'y aurait pas EPEL. Dis nous si Red Hat va interdire yum-utils dans EPEL.
Donc ton "Tout ça pour forcer la main des clients pour qu'ils achètent Rnh satellite..." je le trouve assez méprisant et basé sur presque rien.
[^] # Re: Mises à jour... Pire que Microsoft?
Posté par ragoutoutou . Évalué à 3.
Alimenter un workflow qui s'intègre dans les procédures de test et de validation pour alimenter une repository sur le lan.
opération manuelle, une opération automatisée est plus souhaitable pour notifier les paquets à faire valider et par qui, ainsi que de préparer les machines de test.
Ce n'est pas une question de firewall, c'est le fait d'enregistrer des machines internes sur un site web à l'aide d'un client qui peut recevoir des ordres depuis ledit site web. Le firewall filtre les protocoles, pas les contenus ou la pertinence des informations retournées via un protocole licite. De plus, ça passe de toutes façons via un proxy, pas de connexions directes au web autorisées...
C'est en cours, mais je ne vais pas me priver de dire ce que je pense sur les forums pour autant...
Maintenant, c'est vrai que quand on n'a pas des masses de serveurs et pas toute une série de contraintes administratives et sécuritaires, la disparition du "download only" ne doit pas être une grosse perte.
En attendant, le plugin rhn pour yum est assez intéressant à lire et à modifier...
[^] # Re: Mises à jour... Pire que Microsoft?
Posté par IsNotGood . Évalué à 2.
OK, mais un peu de réflexion avant la parole ne fait pas de mal :-)
> En attendant, le plugin rhn pour yum est assez intéressant à lire et à modifier...
C'est aussi pour ça qu'il faut prendre du logiciel libre :-)
Ce n'est pas facile à intégrer, mais si tu bosses souvent avec RHEL, je te conseille de t'abonner aux mailings beta (malheureusement la mailing beta de RHEL 5 n'a plus cours). Tu y seras en contact directement avec les développeurs de RHEL et ils sont assez réactifs à toute remarque d'un client. Non qu'ils répondent à tous les voeux, mais au moins tu sais de quoi il en retourne.
[^] # Re: Mises à jour... Pire que Microsoft?
Posté par ragoutoutou . Évalué à 2.
Oui, mais déjà une journée de perdue sur la validation de la plateforme à cause de ça... ça reste énervant... je trouve que mettre et up2date et yum dans rhes5 aurait été plus respectueux du client... Le client qui suit naïvement ce que RedHat offre et reprend est bon pour convertir tous ses scripts de déploiement.
[^] # Re: Mises à jour... Pire que Microsoft?
Posté par IsNotGood . Évalué à 2.
Argument "valide". La "mise à la poubelle" de up2date a été connue que depuis la beta1 de RHEL5.
[^] # Re: Mises à jour... Pire que Microsoft?
Posté par ragoutoutou . Évalué à 2.
Pour info, j'ai terminé les grandes lignes de mon script de téléchargement, il permet de télécharger tous les canaux rhn auquel un serveur rh5 est abonné, séquentiellement, avec contrôle des checksums (je vais envisager la vérification gpg), et sans retélécharger les fichiers déjà présents dans le miroir. Le script utilise les librairies de rhn et de yam.
Je vais en parler avec le tam de rh, et si ça ne pose pas problème, je le partagerai...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.