WhiteCat a écrit 699 commentaires

C'est un secret pour personne que beaucoup d'entreprise n'ont pas toutes les CAL qu'il faut pour tous leurs serveurs. En fait beaucoup ne savent même pas qu'il en faut. Si elles savaient ce que devraient normalement payer, elles tireraient bien la tronche…

Ils se crackent comme des petits pains tu veux dire.

Moi je me demanderais plutot pourquoi elles ne passent pas a Linux si j'etais toi… Marrant non ?

Principalement parce qu'Office ne fonctionne pas sur Linux. Si c'était le cas, les parts de marché Windows en entreprise prendraient un sérieux coup.

L'Europe (enfin l'ESA) accumule surtout les succès retentissants ces dernières années: Herschel, Planck, Rosetta en astronomie par exemple. Sans compter toutes les autres missions.

Et les ATV.

En fait je parlais plutôt de la "Knowledge Base" plutôt que la doc en elle-même.

Par exemple cet article est accessible :
https://access.redhat.com/solutions/544423

Mais pas tous, comme ceux-là :
https://access.redhat.com/solutions/442103
https://access.redhat.com/solutions/890743

Le reste de l'article est également intéressant à lire…

Je suis du même avis que Zenitram, c'est du pur FUD.
J'ai juste l'impression que c'est un rageux parce que Red Hat gagne de l'argent grâce à des logiciels libres. Non seulement c'est permis par la licence mais en plus de ça, il sous-entend que Red Hat gagne de l'argent sur le dos des autres (qui écrivent les logiciels GPL gratuitement pour eux) sans réfléchir 2 secondes que Red Hat fait partis des plus gros contributeurs dans le logiciel libre.
Ensuite je vois pas trop en quoi RHEL ne respectent pas la licence. Autant que je sache, CentOS, Scientific Linux et même Oracle (!!) n'ont pas de problèmes pour redistribuer une "RHEL recompilée". Oracle qui EUX se font VRAIMENT de l'argent sur le dos de Red Hat par ailleurs…

Et puis bon, la 3ème phrase de l'article c'est quand même : "It’s no secret that CentOS was cutting into Red Hat’s revenue stream." Donc bon, le type il pousse pas très loin ses raisonnements visiblement.

Pour des paquets assez récents, Red Hat a un dépôt "Software Collections" pour ça.

Certes, j'imagine que si on recherche les performances maximales, CentOS 5 aujourd'hui n'est plus un bon choix pour du matériel récent. Ceci étant dit, Red Hat backporte un certain nombre de pilote. Ainsi, en 2012, la mise à jour 5.8 de RHEL a apporté le support du PCIe 3.0.

Mais dans le cas du CERN je ne pense pas que ce soit ce qu'ils cherchent pour tous les ordinateurs. Je pense qu'ils cherchent surtout un OS stable pour y développer et faire fonctionner leurs programmes. Et je ne pense pas que ça les intéresse de re-valider leurs programmes tous les 3 ans. Et s'ils veulent faire fonctionner leurs programmes sur du nouveau matériel sans re-validation, ils peuvent virtualiser leur CentOS 5 sur du CentOS 7 pour tirer profit du nouveau matos.

Tu as probablement raison mais en même temps comparer 2 distributions qui ont 6 ans d'écart c'est osé.

Avec le Self-support tu as la documentation en ligne aussi, c'est pas rien, des fois j'aurais bien aimé y avoir accès pour mes CentOS :-(

Des E div ~6,56

D'accord je vois, et oui je crois que je vais m'orienter vers ça. C'est simple à mettre en œuvre.

J'ai l'impression que AMD a de meilleurs pilotes libres mais que Nvidia en a de meilleurs propriétaires.

Oui c'est exactement ça.

Sauf que Nvidia a l'air de plus en plus contribuer au développement du pilote libre.

Certes on les voit un petit peu pointer leur nez maintenant, et c'est tant mieux et j'espère qu'ils vont fortement augmenter leur implication. Mais il faut relativiser, jusqu'à maintenant c'est très anecdotique. AMD et Intel contribue énormément plus à faire fonctionner leur matériel sur Linux.

Si je devais conseiller un constructeur :
- utilisation basique (web, vidéo, bureautique, etc.) : Intel ou AMD, avec un pilote libre.
- jeu vidéo léger : Intel ou AMD, avec un pilote libre.
- jeu vidéo plus lourd : AMD, avec un pilote libre.
- autres utilisations : à voir.

Le message d'avertissement d'1and1 aurait dû être plus clair. Quand ils parlent de ces numéros de versions, ce sont les versions "upstream" c-à-d celles que tu télécharges sur kernel.org et que tu compiles toi-même.
Mais comme l'a évoqué "M.Poil" ci-dessus, la plupart des distribution (et tout particulièrement Red Hat) backportent les patch de sécurité dans leur version antérieure qu'il package pour toi dans la distribution. Il est évident que le noyau 2.6.32 de RHEL 6 est truffé de patch de sécurité backporté. T'imagines sinon le nombre de faille qu'il y aurait dans le noyau RHEL ?!

Donc tu peux dormir sur tes 2 oreilles en faisant simplement tes "yum update" réguliers.

Oui, c'est bon, sa carte mère a bien un port PCI-E 16x.
Et en effet, je recommanderais également l'achat de la petite Radeon citée plus haut.

Cela dit, es-tu sûr que cela vient de la carte vidéo ? As-tu essayé avec une autre distribution ? Fedora 20 par exemple.

Autant je comprend pour VMS (pas forcément très utilisé), autant virer ce qu'il y a sur 90% des PC desktop, c'est hum… Ah oui : faire l'intégriste, se couper de ses utilisateurs potentiels.

Windows est peut-être utilisé sur 90 % des PC, mais OpenSSL n'est pas utilisé sur 90 % des PC.
Si on regarde la faille Heartbleed, on voit bien que ça touchait les serveurs Apache ou ngix tournant sur Linux ou *BSD.
Donc au final si ils virent tout le merdier spécifique à Windows, tant mieux. Franchement faire tourner un serveur Web Apache de prod sur Windows c'est pas sérieux…

Juste pour compléter concernant OpenGL 3.2 avec les R600/R700, il faut avoir une version 10.1 de Mesa.

Oui je me suis gouré.
noop c'est mieux pour les SSD.
Et deadline est bien pour les SGBD qui tournent sur HDD.

Je n'avais pas connaissance de cet utilitaire Red Hat, je regarderais demain au boulot.
Tu peux aussi utiliser hdparm pour un "benchmark" :
# hdparm -Tt /dev/sda

Sinon, assures toi que le TRIM est bien activé (option discard dans le fstab), et à mon avis mettre le IO-scheduler "deadline" aussi (d'ailleurs également recommandé pour les bases de données). Tu trouveras des infos pour activer ça ici par exemple :
https://wiki.archlinux.org/index.php/Solid_State_Drives

Les disques sont en RAID matériel ? Je prend le pari que tu aurais des perfs meilleures encore avec du soft-raid Linux.

Ok je vois ce que tu voulais dire.

Ça ne manquait pas du tout. CentOS existe depuis bientôt 10 ans.
Et maintenant que Red Hat soutien officiellement CentOS, c'est un gage de qualité supplémentaire pour tous les utilisateurs CentOS (et RHEL par effet de bord).

(qui s'en plaindra !)

Pas moi ! J'ai testé une fois le fameux Unbreakable kernel (pour faire de la virtualisation KVM), et ben j'ai regretté et je suis revenu à CentOS.

cela veut dire en gros que si on veut un quasi-clône de RHEL il est désormais mieux de choisir CentOS ?

Bah c'était déjà le cas avant. Si on voulait un quasi-clone de RHEL c'était soit CentOS soit Scientific Linux.

CentOS est 100% binaire compatible avec RHEL, en d'autres termes : bah c'est pareil ;)

On remarque d'ailleurs étonnamment dans le communiqué de presse de Red Hat qu'ils insistent à mort sur le fait que RHEL et CentOS sont clairement "différentes".

De quoi tu parles? la spécification de H264 est lisible

Oui c'est exactement ce que je viens dire… J'ai marqué "Je voulais souligner le fait lisible […] de H264".