L'équipe release Debian a annoncé que la sortie de Debian 8, aussi connue sous le nom de Jessie, était prévue pour le Samedi 25 Avril (debian-devel Jessie Release Date: 2015-04-25)
Debian est connue pour son support de nombreuses architectures, et de ce côté, quelques changements sont à prévoir. Le support de l'architecture sparc est abandonné du fait du manque d'implication des mainteneurs, de problèmes récurrents avec la toolchain et de problèmes de stabilité (LWN - Debian drops the SPARC architecture). Le support officiel des architectures kfreebsd-i386 et kfreebsd-amd64 est également abandonné, non pas à cause de systemd comme de vils trolls n'auraient tardé à le suggérer dans les commentaires, mais à cause du manque de mainteneurs et de la lenteur à corriger les bugs (Architecture Qualification). Les architectures arm64 et ppc64el font leur entrée parmi les architectures officiellement supportées par Debian.
Pour rappel, arm64 correspond au nom choisi par Linus Torvalds pour désigner les architectures ARM implémentant un jeu d'instruction 64 bits, désigné par ARMv8 ou Aarch64 par la ARM Foundation. Dans une de ses célèbres gueulantes, Linus Torvalds a argué que arm64 était un nom d'architecture plus clair que armv8/aarch64. Parmi les processeurs grand public gérant ce jeu d'instructions on trouve les Samsung Exynos 7 Octa (Galaxy Note 4, Galaxy S6) et les Apple A7 et A8 (iPhone 5S, iPhone 6).
Les processeurs supportant l'architecture ppc64el, désignant l'architecture POWER 64 bits configurée en mode little-endian, sont principalement les processeurs Power, présents dans une partie des serveurs IBM et le PowerPC G5, présent dans les Power Mac G5. Le founisseur de VMs Runabove (émanation d'OVH) propose des VM POWER8 a tarif accessible au grand public. L'architecture Power a bénéficié d'un regain d'attention avec la création de la OpenPOWER Foundation en 2013, amorcée par IBM et soutenue notamment par Google et Samsung. L'objectif principal de cette fondation est d'ouvrir le licensing des processeurs POWER de façon a permettre à de nouveaux acteurs de développer des serveurs basés sur l'architecture POWER, ce qui était auparavant le monopole d'IBM. Le fabriquant de cartes mères Tyan a d'ailleurs lancé la commercialisation de son premier serveur basé sur l'architecture POWER en 2015.
Pour terminer, les architectures amd64, armel, armhf, i386, mips, mipsel, powerpc et s390x restent de la partie.
Rapidement, du côté des logiciels, les environnements de bureaux mate et cinnamon ont été packagés. Pour les serveurs, on peut citer l'inclusion de needrestart, un script qui redémarre automatiquement les serveurs devant être redémarrés après une mise à jour et de la plateforme de conteneurisation Docker. Je laisse à la dépêche à venir de lister toutes les nouveautés plus précisément.
Et toi, nal, qu'en penses-tu ? Est qu'on s'en fout pas un peu de la sortie de Debian vu que Arch Linux est largement mieux ? Est-ce que ça vaut encore le coup de releaser des versions stables de Debian vu que tout le monde utilise Ubuntu qui s'appuie sur la sid ? Est-ce qu'on s'en fout pas un peu de toutes ces architectures ésotériques vu que tout le monde utilise du Intel de toutes façons ?
# Bon, tu l'as cherché mais on est vendredi
Posté par gnumdk (site web personnel) . Évalué à 10.
Ben cela dépend du point de vue:
Sur un serveur, ArchLinux est une aberration… Et de ce point de vu là on s'en fout pas vu que Debian est la distrib la plus utilisée dans ce domaine (Un troll en cache un autre). Enfin, de ce que je vois dans mes différents tafs depuis 11 ans, c'est 99% de Debian… Un peu de RedHat quand c'est obligé (Tina, Oracle, …)
Sur le desktop, ben ArchLinux bien sur… Enfin non en fait… Ça fait 6 mois que je fais le yoyo entre Arch/Fedora/Debian sid… J'ai encore craqué y'a pas longtemps à cause de Gnome 3.16 en repassant sous Arch… Après 1 semaine de plantages divers et varié de mon laptop, j'ai fini par remettre mon backup Debian sid… C'est certes moins à jour mais ça juste marche…
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Zenitram (site web personnel) . Évalué à 9.
Donc on sait que tu fais des petites boites avec des gens qui font des choix de coeur ;-).
Parce que quand ça grossit et qu'il y a une volonté de rationaliser, ben ça passe tout de suite 99% RHEL/CentOS (dépend si tu veux un support ou pas) et la chasse aux autres distro (pour avoir une gestion unique), et vu que tu n'as pas le choix sur certains projets (comme tu dis : Oracle …), ben c'est choisi comme distro de référence.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Frederic Bourgeois (site web personnel) . Évalué à 3.
Pas partout, c'est aussi Debian et Ubuntu/windows (sur les postes) dans de grosses structure.
Et Redhat/windows quand il y a obligation …
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par vlamy (site web personnel) . Évalué à 4.
Je crois qu'on parlait de serveur là pour le coup :)
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Frederic Bourgeois (site web personnel) . Évalué à 3.
Oui moi aussi je voulais dire serveurs Debian et postes Ubuntu/windows
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par hitmanu . Évalué à 2.
Et les petites structures, Windows Serveur et postes XP/Unbuntu (déjà vu).
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 10.
De ce que j'ai vu, y a de tout dans la nature. Debian est très présent mais aussi du Centos/RHEL, et je vois de temps en temps de l'opensuse. j'ai plus rarement vu du *bsd, mais il me parait aussi évident que je vais pas en croiser vu que je fait surtout du linux :)
Mais je pense que tu as d'autres raisons que "tu as pas le choix" pour prendre autre chose que Debian. Par exemple, j'ai eu des surprises chez un client ( genre, du matos acheté sans vérifier la compatibilité, et donc qui ne marchait pas sans devoir bidouillé et mettre le serveur à moité en testing ). À minima, les certifs hardwares évitent ça et même si dans mon cas, c'était 2 serveurs internes d'infra, ça aurait pu être 40 sur internet. Et autant, 2 à 3 ans de support sécu, c'est déjà bien, autant, je comprends que plus, c'est aussi pas mal ( dit-il en pensant au serveur VPN en RHEL 5 de son taf ).
Il y a aussi des différences technologiques parfois assez importantes. Si tu veux déployer un truc comme freeipa ( qui est de la bombe, ça déchire de déployer kerberos/ldap/etc via 1 commande ), ou les choses produites par des communautés ou RH est un gros ou le seul sponsor important comme openshift, kubernetes, les trucs autour de docker ( surtout que le dit docker a été viré de jessie ), Debian est pas forcément le choix le plus probant ( Ubuntu à la rigueur, mais ils poussent aussi pas mal leur stack en priorité, genre lxc, maas, juju ).
À contrario, si tu veux des trucs un peu exotiques ou spécifiques, Debian propose sans doute un paquet ( genre dans le monde scientifique, ou j'ai le sentiment qu'il y a une tonne de paquets, de part l'attachement des scientifiques à ses idéaux non commerciaux ).
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Frédéric-Emmanuel Picca . Évalué à 5.
docker sera dans jessie mais via jessie-backports pour fournir des versions plus à jour.
L'info est là https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781865
bonne journée
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 6.
J'ai en effet pas cherché, j'ai juste vu le mail de Florian.
J'utilise pas Debian pour docker et je pense que docker est pas sec, pour reprendre les termes consacrés, mais je regarde un peu les choses de loin, et de mon point de vue de packageur, je sais que c'est une plaie pour la securité sur le long terme, principalement à cause de go.
Donc il y a:
- besoin du compilo go, avec l'upstream qui pousse vers la derniére release du language ( donc ça implique de backporter aussi un compilo ). Que je sache, ça tourne pas encore avec gcc-go.
( ou plutot, ça tourne avec gcc 5.0 et quelques crashs )
sans doute besoin des dernières libs (pareil, backports). Peut être des snapshots git des dites libs.
et ça compile tout en statique, ce qui rends le tracking des soucis de sécu un chouia plus compliqué.
Et encore, docker est pas si problématique, car il suffit de voir kubernetes ou openshift origin ( qui embarque etcd et kubernetes ) pour se dire que ça va être assez vite relou quand un souci va arriver. Et il faut aussi rajouter les trucs comme flannel, les autres bouts de docker, etc, pour avoir un truc qui va servir à la prod.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par flan (site web personnel) . Évalué à 2.
Qu'est-ce donc que kubernetes ou openshift origin ?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 10.
Kubernetes est un gestionnaire de cluster de containeurs, projet initié par Google et soutenu par une paire d'autres boites.
Ça se base sur les archis de micro services, que je vais tenter d'expliquer vite fait.
L'idée, c'est de décrire une archi ( par exemple, une appli web ) sous forme de différents services qui tourne chacun dans un espace séparé et qui communique via une API défini. Par exemple, un site de e-commerce va avoir le serveur web, qui va parler à php-fpm ( un php en dehors du process du serveur web ), un composant qui va se charger de donner les résultats de recherche via une API REST, un composant qui va enregistrer le caddie ( via REST aussi ), etc.
Avec Kubernetes, chaque composant tourne dans un containeur docker, ce qui permet de faire les updates indépendamment du composant du reste de la stack ( modulo le fait que le composant respecte l'API ), ce qui permet aussi de gérer la charge indépendamment de chaque composant ( genre si tout d'un coup, y a plus de recherche, tu rajoutes plus de composant "recherche" et tu t'arranges pour que le code fasse du load balancing ), etc.
Donc Kubernetes, un master prends en entré un fichier json ou yaml qui décrit plusieurs containeurs docker, les groupes dans ce que le projet appelle un pod et se charge de repartir le pod sur une ou plusieurs machines, en reliant les containeurs entre eux pour communiquer, en relancant ce qui sont en panne pour que le service fonctionne, etc, etc.
C'est basé sur les architectures utilisé par les géants du web ( google, facebook, twitter ) pour leur infra web ou de traitement par lots ( ie, les batchs de job ). C'est encore en rapide développement, écrit en go.
Plus d'info sur :
http://kubernetes.io/
https://github.com/googlecloudplatform/kubernetes
http://kubernetesio.blogspot.ca/
Et une distrib qui embarque Kubernetes :
http://www.projectatomic.io/
Donc, ça, c'est Kubernetes.
Origin, c'est la version 3 de l'architecture d'openshift, un logiciel de PaaS ( Platform as a service ) de Red Hat. Tout comme kubernetes, c'est écrit en go, et ça s'interface devant Kubernetes, en rajoutant des APIs et des services pour être directement utilisable par un développeur pour faire du hosting. Par exemple, il y a une interface web, ça gére les utilisateurs, il y a un workflow pour construire les containeurs docker et les déployer à partir de git, etc etc.
Pour prendre l'exemple du site de ecommerce, tu peux avoir un déploiement du composant de recherche à chaque fois qu'un developpeur fait un commit. Le logiciel va recevoir une notification ( par exemple, via un post-commit git ), va prendre le code, le compiler ( dans un containeur prévu pour ), lancer les tests ( encore dans un containeurs ) et si c'est bon, le déployer automatiquement sur ton cluster. Tout ceci est bien sur configurable ( à terme ) pour par exemple ne déployer que sur 10% pour faire des tests, ou ne déployer qu'à la main, etc, etc.
C'est aussi en rapide développement, et pour faciliter le déploiement, ça embarque tout kubernetes. Ce qui me fait crier dans ma tête, mais bon, c'est vrai que du coup, ça va vite à tester.
Plus d'info :
http://www.openshift.org/#v3
https://ci.openshift.redhat.com/openshift-docs-master-testing/latest/welcome/index.html
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par flan (site web personnel) . Évalué à 2.
Ok, merci pour toutes ces infos ; ça commence à être plus clair comme ça.
Et go a l'air de te poser beaucoup de problèmes niveau sécu. J'imagine que c'est lié au besoin des dernières versions de chaque lib (je comprends le risque à utiliser le git directement) et à la compilation en statique, mais y a-t-il autre chose ?
Merci :)
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 3.
Théoriquement les gens se plaignent du fait que ça ne prenne pas en compte les mesures de sécurité comme ASLR et NX. Mais les devs du compilo disent que ç'est pas requis de part la présence d'autres protections ( https://groups.google.com/forum/#!msg/golang-nuts/Jd9tlNc6jUE/u1jlX12zVx8J ).
Mais l'histoire semble donner raison aux devs de golang, vu qu'il y a pas non plus l'air d'avoir tant de souci que l'ASLR bloquerais sur les softs en go pour le moment.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par jolitorax . Évalué à 7.
Debian offre les aussi la possibilité d'installer un chroot de n'importe quelle version de Debian sur le même serveur en une seule ligne de commande, ce qui est très pratique pour faire tourner de vieux programmes sur un serveur récent.
Les changements de version Debian sont simples. Nos serveurs Debian changent de version à chaque nouvelle Stable, par contre aucuns de nos serveurs CentOS 5 n'a été migré en 6 ou en 7.
Les dépôts sont très complets, ça évite les dépôts tiers de RedHat, souvent incompatibles entre eux qui deviennent un véritable casse-tête à gérer, surtout les dépôts des projets amont dont l'empaquetage ne respecte bien souvent pas les standards de la distribution.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 04 avril 2015 à 12:59.
Plus simple que RHEL? en quoi?
Mais le sujet n'est pas la : simple ou pas, tu dois te taper tous les tests de non regression quand même.
Encore heureux : tu n'as pas le choix (fin de support).
Une comparaison basée sur un non choix (alors qu'en face tu as le choix), c'est un peu avoir la conclusion en premier et trouver un moyen d'y arriver ensuite…
Ce genre d'assertion ne donne pas confiance dans l'objectivité. La, je dirai que bon, avantage CentOS pour le coût, à partir de ce que tu annonces. Comme quoi on a la conclusion qu'on veut.
donc tu as la chance d'avoir ce que tu veux sur les dépots. Ce n'est pas le cas de tout le monde (déjà par le simple problème que ces dépots refusent certaines licences, genre les logiciels non libres).
J'arrive à vivre avec EPEL qui fait tout ce que tu aimes dans les repos Debian.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 9.
Les upgrades de versions majeurs sont non supportés. La solution est "tu réinstalles". Autant en Fedora, tu t'en tire avec fedup, autant rhel/centos, c'est niet.
C'est sur la roadmap d’après une présentation donnée lors du RH Summit l'année dernière ( https://rhsummit.files.wordpress.com/2014/04/cantrell_w_1650_migrating_and_upgrading_rhel.pdf ). Mais je miserais moins sur ça que sur les outils d'automatisations pour un redéploiement ( et encore, j'ai un serveur web à passer en 7, et j'ai la flemme ).
Et l'emphase de nos jours est plus sur la séparation OS de base/ applications ( comme les BSD, mais au dela du code et de la compilation ), et des systémes de mises à jour atomiques ( ostree et snappy, par exemple ), et les containers ( docker, rocket ). Ce qui permet de mettre à jour, revenir en arrière, et de faire ( via des architectures de micro services ) bouger les pièces indépendamment.
Voir par exemple les videos et slides de la conférence "New directions in operating systems" qui a eu lieu il y a 6 mois à Londres.
Sans que ça soit la catastrophe, y a quand même plus de trucs chez Debian que dans EPEL 7. Mais EPEL étant mis à jour indépendamment de la version stable de la distro, il y as aussi plus de flexibilité, et ça se ressent. Et j'ai personnellement toujours pas compris pourquoi y a pas plus de mises à jours autre que sécurité sur Debian ( ou qu'il faille attendre des mois pour que ça soit dispo au lieu de faire ça au fil de l'eau car l'effort serait sensiblement le même ).
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par jolitorax . Évalué à 3.
Il suffit de lire les releases notes et plus spécifiquement la partie 4, le plus souvent ça se résume à :
Nos serveurs restent quasi conforme à l'écosystème Debian, de fait on fait confiance à Debian pour ces tests et nous n'avons pas eu à s'en plaindre jusqu'à présent. On ne travaille ni pour une entreprise du CAC 40 ni ne gérons des sites avec des centaines de milliers de hits par jour, nos contraintes sont moindres.
Si les gens veulent du Linux supporté 10 ans et ne jamais faire évoluer le service, très pragmatiquement on leur propose du Centos (qui représente plus de la moitié de nos serveurs). On n'essaye pas de porter les spécificités de Debian (cycles de releases courts et gestion de la sécurité sur un panel très large de logiciels, par exemple) sur Redhat/Centos et réciproquement.
J'utilise non-free depuis la Debian Woody, j'en ai profité pour vérifier depuis quand le dépôt non-free fait partie de Debian; il a été introduit avec Bo (Debian 1.3) en 1998.
On l'utilise aussi et j'apprécie particulièrement l'effort qui a été fait depuis quelques années pour améliorer la qualité de ce dépôt. Avant ce n'était clairement pas la joie entre atrpms rpmfusion et epel. Par contre il y a les 15 jours d'epel-testing qui sont à prendre en compte pour la sécurité, si la correction de faille est livrée avec une nouvelle version. C'est un soucis assez proche de l'utilisation d'une Debian Testing.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 9. Dernière modification le 06 avril 2015 à 09:33.
Surtout que, lors de l'upgrade des différents logiciels installés, des notes de mises à jour spécifiques aux logiciels utilisés sont affichés: typiquement pour le passage d'Apache 2.2 de Wheezy à la version 2.4 de Jessie, j'ai été avertis des changements importants de valeurs par défaut et de la nouvelle gestion des configurations. C'est quand même vachement utile: plutôt que de devoir faire des tests sur tout, tu sais exactement quels mises à jour a pu avoir un impact sur ton serveur, pour quel logiciel et la configuration incriminée.
Je ris bien en lisant LinuxFR à propos de Debian: soit les gens veulent une rolling release pour leur Desktop et disent que Debian est trop lent, soit les gens ne veulent pas faire de sysadmin et trouvent Debian bien trop rapide xD J'ai l'impression qu'il doit y avoir beaucoup plus d'utilisateurs de Debian qui sont juste satisfait et qui ne le crient pas sur tous les toits.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 7.
Y a mock, y a docker, y a lxc pour faire ça sur les distros RH like, et je suis globalement sur qu'il y a partout le même genre de trucs, ne serait ce que pour permettre une compilation propre. Un chroot en soit est sans doute une solution pour certains problèmes, mais pour lancer des serveurs, tu as souvent besoin de plus d'isolation ( parce qu'un chroot de base, ça bloque pas les signaux ni rien d'autres ), et parfois, tu as des soucis de communication userspace/kernelspace, etc etc.
Malgré ce qu'on croit, l'userspace est pas 100% indépendant du kernel http://www.fewbytes.com/docker-selinux-and-the-myth-of-kernel-indipendence/
Je rajouterais aussi que dire "on peut faire tourner des vieux trucs avec une ligne de commande", c'est aussi juste se voiler la face quant au manque de compatibilité abyssal des distributions linux d'une version à une autre, surtout quand on compare à des choses comme solaris ou netbsd.
Sauf quand tout d'un coup, apache change sa config et faut tout refaire. Ou que d'un coup, dovecot a dit "je change tout". Ou qu'on passe à systemd ( ce que perso, j'ai pas trouvé compliqué, mais comme tant de gens ont raler sur le sujet, je suppose que tout le monde partage pas cette avis ). Ou ce genre de détails qu'on a tendance à ranger dans la case "facile".
( attention, opinion non populaire devant )
Les gens ont aussi un manque de recul critique sur la question de la mise à jours de distribution. La principal raison de vouloir ça, c'est pour palier à la difficulté de mise en place de façon répétable d'un système. C'est souvent manuel et non documenté, et donc chiant.
En pratique, tu as plein de raison de réinstaller qui existe.
Ton serveur tombe en panne et prends feu ? Tu va devoir réinstaller.
Tu veux déplacer les machines sur un DC à 500 km ? Tu réinstalles le système à l'identique sur une nouvelle bécane et tu bouges l'ancienne sans avoir un downtime de 24 à 48h sur les services.
Tu veux un serveur de QA comme la prod ? Tu fait une installation à l'identique.
Et tu veux un upgrade ? Tu installes en changeant juste la distro de base, et tu corriges ce qui casses, sur autre chose que la prod.
Mais tout ça, ça implique d'automatiser l'installation et le déploiement, et la plupart des gens sont encore à faire les choses à la main, par manque de temps (ce qui est soit du bullshit, soit le signe d'un taf ou les gens sont toujours en mode pompier ce qui est un autre souci à régler du coté de la hiérarchie), par manque de compétence ou par ignorance.
Et donc, pour palier à ça, on se retrouve à celebrer la possibilité de faire des upgrades, au lieu d'oublier que c'est un contournement datant d'un temps ou l'automatisation était de la science fiction.
Bien sur, tout automatiser est relou. Faut commencer directement par ça ( sinon, tu te retrouves à oublier des choses, faut avoir du temps à faire le travail ( ce qui est parfois pas une mince affaire ), et soyons franc, tout les softs ne s'y prêtent pas.
Mais voila, ça reste couteux en ressources. Le DPL dit d'ailleurs dans une interview ( http://www.itwire.com/business-it-news/open-source/67512-surviving-systemd-lucas-nussbaum-satisfied-with-init-system-outcome ) :
Et je pense que "supporter un upgrade path presque parfait de stable à stable" rentre dans la catégorie des choses qui prennent du temps aux équipes cores, tout comme "supporter des tas d'archis", ou "avoir des milliers d'alternatives". On peut pas éviter la complexité, et je ne dit pas que ça n'apporte pas rien. Encore une fois, même si ça reste un workaround, ça corrige un souci pour une partie des utilisateurs.
La solution traditionnelle dans le logiciel libre, c'est de tenter de recruter plus de gens. Dire non, c'est super mal vu ( suffit de voir les réactions vis à vis de gnome ). Mais la solution traditionnel pour le reste du monde, c'est juste de faire moins.
Mais tu reçois encore des updates de sécurité dessus donc c'est pas un si gros souci ( mais je reconnais que c'est relou d'avoir des vieux trucs à gérer ). Et pour rebondir sur la solution d'utiliser un chroot, il se passe quoi si tu as un vieux bash ou un vieux openssl dans le chroot ( que tu va pas mettre à jour, si la distro est plus maintenu ) ?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par totof2000 . Évalué à 2.
En quoi dans ce cas Redhat peut-il être un avantage à Debian ?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 5.
J'ai pas utilisé le mot "avantage" dans mon texte, donc je vois pas ou tu va trouver que j'aurais pu dire ça.
Mon texte est la pour nuancer le fait que "les upgrades c'est trop génial", parce que c'est un contournement pour le souci de ne pas vouloir faire la maintenance longtemps et parce que le déploiement de logiciel est trop compliqué.
On mets à jour parce qu'on a pas le choix, et on upgrade parce tout réinstaller prends trop de temps.
Le 1 est une conséquence de plusieurs facteurs sociaux dans le libre:
- on célèbre les gens qui font des nouveaux trucs, pas ceux qui font marcher ce qui existe déjà.
- on s'excite sur les nouveautés pour montrer notre status de geek alpha ( "ouais, je fait tourner la version git de tel truc" )
Donc du coup, on trouve pas assez de bénévole pour faire la maintenance et les backports, par rapport à trouver des gens qui poussent sans arrêt des nouveaux trucs ( et encore, Debian est une des distros qui arrivent à trouver le plus de monde pour ça ).
Et le 2, bah, j'ai écrit tout mon commentaire sur pourquoi c'est pas une fatalité, et pourquoi le monde a évolué. Si tu va bien le lire, tu verra même que je nuance en disant que ça résouds des soucis et qu'il y a des raisons valables en pratique ( archi déjà en place, pas le temps d'améliorer, etc, etc ), mais qu'un hack reste un hack, et qu'on arrive aussi à ne pas avoir besoin d'upgrade de version majeur.
Ensuite, si tu veux vraiment aller sur ce terrain, c'est pas l'absence qui va être un avantage en soit, mais les conséquences de cette absence, à savoir que ça libere des ressources de ne pas supporter l'upgrade. Et donc qu'on peut avoir ce temps libre mis ailleurs. Genre un packageur avec moins de bugs sur l'upgrade, car sans obligation de le supporter, peut prendre plus de paquets, ou corriger d'autres bugs, par exemple.
Et la, on en reviens sur les débats de rolling releases, etc, etc, etc.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par ZeroHeure . Évalué à 2.
Je suis entièrement d'accord.
C'est le même problème sur le desktop, à la nuance près que ça concerne tout le monde et pas que le libre. Il y a quelques années j'avais publié un journal sur ce thème là. Allez je mets le lien, ça fait du bien à mon égo : http://linuxfr.org/users/andrianarivony/journaux/je-suis-un-lambda
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par jolitorax . Évalué à 1.
mock semble très axé sur la compilation, mais j'irais creuser car avoir un équivalent de debootstrap sur Centos intéresserais vraiment. Ici on ne recherche pas l'isolation, on a des machines virtuelles pour ce genre de cas, mais plutôt de pouvoir faire tourner des vieux binaires avec de la puissance de calcul. La sécurité n'est pas l'objectif pour ce cas d'usage, ce qui répond à ta dernière question.
Que chacun dans son coin fasse ses tests de mises à jour pour des paquets bateaux lors des changements de versions de la distribution, je trouve ça dommage. Pour reprendre l'exemple d'apache, que ce soit Debian ou Centos, si je réinstalle, je vais devoir faire un script qui bascule mes anciennes conf apache 2.2 en 2.4, mon voisin va lui aussi refaire son script chez lui et le voisin de mon voisin aussi. Si c'est une chose qui peut être prise en charge et mutualisée par une ou des distributions, tant mieux et je trouve que ça fait partie des choses qui justifie une distribution.
D'autant plus que Debian avec testing et sid le fait déjà. D'ailleurs étant en Debian testing chez moi, je suis passé de l'init classique à systemd avec de rares soucis que les mises à jour ont peu à peu réglés, sans intervention de ma part. Le changement de version a déjà été scripté et testé par Debian, pourquoi d'un coup ne plus vouloir l'utiliser.
Ça ne m'empêche pas de pouvoir réinstaller mes serveurs automatiquement en grande majorité et de virtualiser ce qui peut l'être.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 2.
C'est pas tant la securité que "j'ai mon script d'init qui fait un killall mondemonamoid" et ça fuite hors du chroot. C'est déjà arrivé sur une ferme de compilation d'une distro francaise, avec sshd.
Mais pourquoi s’arrêter à la distribution et pas faire ça upstream ? Si tu as un truc de migration de la configuration de apache, pas de raison que le distributeur garde ça.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par gnumdk (site web personnel) . Évalué à 5.
14275 personnes, tu considères que c'est une petite boite?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par X345 . Évalué à 1.
Des noms, des noms, des noms…
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par gnumdk (site web personnel) . Évalué à 2.
Je n'ai pas le droit de divulguer cette information… Alors je sais que du coup ça fait moins crédible mais c'est pourtant le cas…
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Sylvain Briole (site web personnel) . Évalué à 1.
Je pense au moins à LiMux (base Ubuntu), qui d'après Wikipedia concerne 18000 machines.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par LeXa1979 . Évalué à 1.
c'est le chiffre de 2013 ça…
L'acacia acajou de l'académie acoustique est acquitté de ses acrobaties. Tout le reste prend "acc".
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par gnumdk (site web personnel) . Évalué à 3.
Hmm, tu parles de quoi?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par LeXa1979 . Évalué à 1.
des 14275 personnes pardi :)
L'acacia acajou de l'académie acoustique est acquitté de ses acrobaties. Tout le reste prend "acc".
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Adrien . Évalué à 5. Dernière modification le 03 avril 2015 à 14:57.
Je nuancerais ton propos quand même. On peut rationaliser, vouloir une seule distribution Linux… et choisir Debian.
C'est ce qu'on fait : debian est la distribution de choix pour serveur mais aussi les postes clients Linux. Il y a quelques execptions avec deux CentOS entre autres.
Par contre, on peut être considérés comme petite structure : un peu plus de 110 personnes, et effectivement c'est en partie un choix de cœur : je dirais « s'adapter aux compétences locales » ;-)
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Sacha Trémoureux (site web personnel) . Évalué à 10. Dernière modification le 03 avril 2015 à 15:42.
J'interviens dans diverses structures plus ou moins grandes et j'ai vu un peu de tout jusqu'à présent quelque soit la taille du SI.
En tout cas loin des chiffres 90/10 vu plus haut, dans un sens comme de l'autre.
En tout cas la sortie d'une Debian stable est toujours un mini-événement vu que c'est pas quotidien. :)
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Zenitram (site web personnel) . Évalué à -6.
C'est surtout que ça doit être un événement "he les gars, le compte à rebours a commencé, dans 1 an il faut qu'on ai tout migré sinon on est à poil, oui c'est Debian qui décide de quand on migre, pas nous, et tant pis de refaire le boulot de validation même si on a installé et validé que il y a 1 mois" (avec CentOS, tu en as pour 5-7 ans, moins stressant)
Chacun son adrénaline et plaisir sans doute, du coup mini-événement oui sans doute.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Adrien . Évalué à 7.
Si tu te bases sur Debian, l'avantage c'est que tu peux voir venir. Ça fait un moment de Jessie est en période de freeze… et le freeze a été annoncé très en amont ! Donc normalement tu peux t'organiser un minimum.
Et puis maintenant il y a le projet de Debian LTS, qui est intéressant pour ceux qui veulent une version plus longue :
https://wiki.debian.org/fr/LTS
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par claudex . Évalué à 10.
Quand on voit le niveau de financement on peut se demander s'il y aura une suite au projet.
« 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
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Kioob (site web personnel) . Évalué à 8.
Pour moi c'est avant tout une grosse erreur de communication pour la Debian Squeeze LTS : le projet a été lancé alors que celle-ci arrivait au terme de son support en «old-stable». Du coup la majorité des personnes concernées avaient migré depuis longtemps.
J'ose espérer que pour la Debian Wheezy LTS ils communiqueront dès la sortie de Jessie. Avoir 5 ans de suivi, c'est quand même appréciable chez certains clients.
alf.life
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 2.
De manière amusante, il faut aussi que le financement augmente à la hauteur du nombre de paquet qui arrivent dans la distro. Si il y a 20% en plus à chaque release, ça implique d'avoir 20% de choses en plus à faire ( à la louche ), ce qui implique donc de réussir à suivre la cadence.
Perso, si j'étais eux, je commencerais par fixer un groupe restreint de paquets pour être supporté. Ensuite, revoir le groupe à chaque release, avec la possibilité pour les gens (qui payent pour le projet) de donner leur avis sur la liste de paquets.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Kioob (site web personnel) . Évalué à 2.
C'est déjà en partie le cas: il est demandé à chaque sponsor de fournir la liste des paquets utilisés sur son parc, afin de mieux cibler les besoins.
De plus, certains paquets ne sont pas pris en charge par la LTS.
alf.life
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par woprandi . Évalué à 0.
Si c'est des serveurs en LAN ce n'est pas obligatoire.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . Évalué à 2.
Parce que jamais aucun employé ne va être mécontent, et parce que les bécanes vérolés qui servent de passerelles n'existent pas ?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Marotte ⛧ . Évalué à 5.
SLES possède également quelques parts de marché dans ce secteur me semble-t-il.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par totof2000 . Évalué à 2.
Tu ne sais pas de quoi tu parles.
je suis actuellement dans une boite ou 99% du parc est sous ubuntu. Il y a quelques centos. Pas grand chose. Je travaillais il y a quelques années dans un autre service de cette grosse boite. Effectivement, il y avait majoritairement du redhat, mais il commence à y avoir de plus en plus d'ubuntu. Donc dire que c'est 99% de redhat/centos est absolument faux.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 04 avril 2015 à 18:00.
C'était provocateur.
Ubuntu n'est pas Debian.
Avec Ubuntu, tu as 3 ans pour faire l'update, 3x plus de temps, c'est déjà moins l'upstream qui décide pour toi quand tu dois migrer (et en bonus, tu peux sauter une version pour pas t'embéter, donc tu fais un gain supplémentaire en gestion si tu n'as pas besoin de la dernière version tout le temps)
Je note que tu n'as pas parlé de Debian, sujet de ce à quoi je répondais principalement si on enlève la partie provocatrice (mais meme sans provocation, c'est quand même dans énormément de boites CentOS/RHEL même si on trouvera toujours des gens pour dire "pas moi").
Ha tiens, je l'avais presque oublié ce "Tu ne sais pas de quoi tu parles" quand je ne suis pas dans tes idées. Pour l'attaque perso, disons que je ne trouve pas que les attaques de personnes trouvant systemd trop nul et horrible alors que toutes les distros y passent parce que tout le monde le demande en fait soit très pertinentes, ils ont sortis un truc chez Devuan ou toujours si peu de monde intéressé en pratique statistiques? Et dire qu'ubuntu passe à systemd, il va falloir changer ce 99% d'Ubuntu… (tu as cherché, tu n'avais pas besoin de balancer cette phrase pour parler d'un cas dans ta boite).
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Kioob (site web personnel) . Évalué à 1.
Je suis d'accord avec toi, mais Debian LTS existe maintenant. Je te l'accorde c'est encore jeune, et pas parfait, mais pour ma part je suis très satisfait de leur travail.
On a donc maintenant un cycle proche des Ubuntu LTS : 2 ans en stable, 1 an en oldstable puis 2 ans en lts. Soit un total de 5 ans.
Comme tu l'indiques, certains de mes clients en profitent pour passer directement de la Debian 6 à la Debian 8.
alf.life
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par totof2000 . Évalué à 9.
Je sais, mais dire que 99% des boites sont sous Redhat est tout simplement faux. C'est sur ce point que je te dis que tu ne sais pas de quoi tu parles.
La dessus je suis entièrement d'accord avec toi, et c'est ce qui a poussé la boite ou j'étais à passer de Full Debian à Ubuntu. Mais ça ne remets pas en cause que tes statistiques sorties de ton chapeau sont fausses. De ce fait, ça me permet de mettre en doute beaucoup d'arguments que tu pousses ici.
Non, j'ai simplement relevé un argument fallacieux, tout comme toi tu te permets de le faire lorsque quelqu'un dit un truc que tu considères fallacieux ou inexact. La rigueur des arguments ce n'estpas que pour les autres. Je suis d'accord avec toi sur le fait que dans de nombreuses boites c'est du Redhat/CentOS. Mais la proportion n'est pas aussi forte que tu le dis pour Redhat/centos. Et comme indiqué par ailleurs, on trove de tout. Et enfin, dans de grosses boites qui ont été habituées à gérer du Solaris, de l'AIX et du HP-UX, avoir deux distributions Linux ne pose pas de gros problèmes dans la mesure ou il est plus facile de passer de Debian/Ubuntu à CentOS/Redhat, que depasser de Solarisà AIX par exemple.
Si tu as des statistiques fiables sur la part des Redhat/CentOS dans les entreprises, je veux bien les voir. Mais surtout ne fais pas ce que tu reproches aux autres de faire.
Je te dis que tu ne sais pas de quoi tu parles quand tes propos ne reflètent pas la réalité (en tout cas quand j'ai le sentiment que tes propos ne reflètent pas la réalité), et c'est également provocateur. Je sais ce que tu voulais dire, mais je ne peux laiusser passer ce que toi-même tu ne laisses pas passer dans d'autres discussions en prenant les autres de haut (lorsque par exemple quelqu'un parle de "moins démocratique" quue tu transformes en "dictature"), ou d'autres interprétations que tu fais des propos des autres. C'est de bonne guerre non ?
Aucun rapport : tu me parles de 99% de centos alors que ce chiffre est absolument faux. Même si c'est provocateur c'est faux. J'en déduis que tu ne sais pas de quoi tu parles. Est-ce que tu peux me citer tes sources ?
Aucun rapport avec la discussion initiale, je ne relèverai pas. Je te dirai juste qu'on verra le jour venu. Il est fort possible qu'à ce moment je change de métier (il n'y a pas que l'admin dans la vie).
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par NumOpen . Évalué à 2.
Linux MINT, c'est très bien pour un ordinateur de bureau. J'ai essayé Red Hat puis Mandriva puis Ubuntu. J'utilise Linux MINT depuis depuis 4 ans, c'est parfait.
# Power et little endian
Posté par Dabowl_75 . Évalué à 2.
Il n'y a que le POWER8 qui soit bi-endianess parmi les puces POWER.
Exemple : les POWER7 / POWER7+ ne le sont pas.
Pourquoi le POWER8 permet le mode little-endian ? Faciliter le portage d'appli Linux x86 vers Linux Power.
Car ce n'est un secret pour personne, bigblue cherche à imposer son architecture comme étant une vraie alternative au traditionnel x86.
Tu peux développer ?
Je me pose cette question depuis que ubuntu existe ; on est en 2015 et debian est toujours là. Je te laisse en tirer les conclusions.
Il faut encore attendre un peu pour voir si le pari de bigblue s'avère payant ou non.
Je t'invite tout de même à consulter ces slides sur ce que propose "l'alternance" :
https://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/61ad9cf2-c6a3-4d2c-b779-61ff0266d32a/page/1cb956e8-4160-4bea-a956-e51490c2b920/attachment/cb2d4737-e8f5-4f96-9a74-71573b34b96d/media/VUG%20Why%20POWER8%20is%20the%20platform%20of%20choice%20for%20Linux%20v1.4%20CLEAN.pdf
Bien évidemment, il ne faut pas prendre pour argent comptant tout ce qui est écrit car un fournisseur annonce toujours que ses produits sont les meilleurs.
Mais là où je suis, on commence à se demander si Linux sur power8 ne nous permettrait de réaliser de réelles économies d'échelles.
En effet, il n'est pas rare de voir se multiplier dans les datacenters des grilles pains/pizzas x86 avec beaucoup de core dormants, où le taux d'utilisation moyen est de 20-30% alors que sur Power on oscille plutôt dans les 80% car on consolide plus et plus facilement.
[^] # Re: Power et little endian
Posté par X345 . Évalué à 4.
Je n'ai pas eu de serveurs POWER entre les mains à l'exception de VMs Runabove (POWER8), donc je ne remets pas ton expérience en cause.
Cependant, d'après Wikipedia, ils semblent que les POWER7 implémentent le jeu d'instructions PowerISA 2.06. Et d'après la documentation PowerISA 2.06, il semblerait que les POWER7 permettent d'adresser la mémoire en big/little endian, voir les sections Book I.1.9 "Storage Addressing" et Book II.1.6.5 "Endianness". Bon après, c'est juste des informations théoriques, je ne sais pas comment ça marche en pratique.
Oui, on est bien d'accord sur ta dernière remarque. D'ailleurs il y a du bon gros Vendredi dans les slides que tu as linké, merci :P :
Pour y'a quand même des points forts, notamment au niveau de la bande passante mémoire (65Go/s sur un Xeon et 200-400 Go/s sur un POWER8). Peut-être que le SMT à 8 threads/cœur apporte également un gain sur certaines workload.
Personnellement, je suis pas rassuré de voir le marché mondial des processeurs serveurs aux mains d'une seule boite, donc les alternatives m'intéressent. Mais faut quand même reconnaître que les générations actuelles de Xeon sont très performants…
Ça chauffe pas tant que ça un Xeon de nos jours donc grille pain ça semble exagéré quand même. Surtout en face de POWER cadencés à 4+ Ghz, ça doit être autre chose le refroidissement.
C'est quoi les fonctionnalités des POWER qui permettent de consolider mieux que sur du Intel (c'est une vrai question, j'en sais rien) ?
[^] # Re: Power et little endian
Posté par Dabowl_75 . Évalué à 2.
ben ce n'est plus un problème de processeur mais un problème d'appli.
Et dans les deux cas j'ai envie de croire que le p8 s'en sortira mieux.
Appli monothread ==> gros cache L3 et L4 & fréquence élevée, donc de grandes chance que ce soit plus performant
Appli multithread ==> 96 threads sur p8, donc plus de slot disponible pour la montée en charge (à condition que l'appli "scale" bien…)
L'autre avantage, c'est de pouvoir consolider un plus grand nombre de VM, donc meilleure densité.
Ok pour l'adjectif peu adapté, mais ce que je voulais dire c'est que je préfère moins de serveurs mais mieux utilisés, plutôt que beaucoup et qui ne font rien…parce qu'à la fin, niveau consommation, espace m², ça finit par être contre-productif.
l'hyperviseur proprio qui permet d'exploiter le fractionnement de cpu en timeslice.
Contrairement à l'x86, c'est fait en hard car le power a trois niveau d'exécution :
mode hyperviseur / superviseur / utilisateur
Depuis le P7+, on fractionner jusqu'à 0,05, soit 5% d'un core.
Ce qui fait jusqu'à 20VM par core, en supposant que chacune dispose de 0,05 en dédié.
Bien sûr, on peut partager et surtout s'adapter à la charge de travail de chaque VM. C'est le mode shared + uncapped.
Exemple:
Je dispose de 2 core
VM1 ==> 0,2 uncapped jusqu'à 2,00
VM2 ==> 0,05 uncapped jusqu'à 1
Si tout le monde tape dans le pool en même temps, c'est la priorité la plus haute qui bénéficiera des ressources CPU.
Et ce n'est qu'un petit exemple.
Je te laisse imaginer ce qu'on peut faire quand on a plus de 100VM sur le châssis, avec des pool de cpu distinct pour gérer les problème de licence ou de type d'environnement (prod, homol..).
On arrive à un taux de consolidation et d'utilisation très élevés .
Ah et pour finir, les VM n'ont pas de limite en taille de mémoire, si ce n'est le châssis lui-même (mois ce que consomme l'hyperviseur of course).
On peut aussi compresser une partie de la mémoire, exemple j'alloue 100Go en physique à la VM et je lui applique un facteur de compression de 2, l'OS "montrera" 200Go aux applis.
C'est l'OS qui se chargera des swap de pages entre le pool compressé et non compressé.
L'algo de compression s'appuie sur un chipset embarqué dans le cpu (depuis p7+).
Bien sûr, la compression mémoire ne marche pas avec tous les type de workload, il faut prendre des mesures avant etc etc…chose que beaucoup ne font pas :-)
bref les exemples sont nombreux….
[^] # Re: Power et little endian
Posté par X345 . Évalué à 2.
Éventuellement un gros cache L3/L4 ça peut aider dans certains cas particuliers (genre bases de données et join). Pour la fréquence plus élevée, ça aidera inconditionnellement, mais c'est pas forcément bon pour le ratio performance/watt. À fréquence équivalente, je sais pas si du POWER fait mieux que de l'Intel. J'imagine qu'il faut benchmarker en fonction des applications pour voir ce qui se comporte le mieux.
Le POWER8 a 12 cœurs, ce qui signifie qu'a un instant donné 12 threads s'exécutent en même temps. Le Xeon en a 18, ce qui signifie qu'a un instant donné 18 threads s'exécutent en même temps.
Faut pas tomber dans le panneau de cette dénomination de "threads" processeurs et imaginer que 96 threads s'exécutent en même temps. Le 8 threads/cœur veut juste dire que chaque cœur a 8 jeux de registres et donc qu'un cœur peut switcher entre 8 threads sans faire d'accès mémoire. Mais à un instant donné, on a 1 thread par cœur qui s'exécute. Le SMT (Simultaneous MultiThreading) ou l'HyperThreading (HT) permet juste de (1) assurer que le pipeline des processeurs est bien rempli et (2) éviter la latence mémoire au moment d'un context switch.
Par exemple, en pratique, sur du Intel, l'HT (2 threads/cœur) amène un gain de 25% de performance au mieux. C'est souvent 10-15% voire même 0 sur des applications déjà optimisées.
Merci pour le reste de ton commentaire (slicing hardware des cœurs CPU, compression mémoire, hyperviseur), je connaissais pas du tout ça. Effectivement, ça fait pas mal de fonctionnalités utiles pour bien consolider, qu'on trouve pas sur du Intel.
[^] # Re: Power et little endian
Posté par Dabowl_75 . Évalué à 1.
Ce n'est pas ce que j'avais compris de l'article ci-dessous par exemple :
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Not+AIX/page/Understanding+Processor+Utilization+on+Power+Systems+-+AIX
Ni encore de celui-là (POWER7) :
http://www-03.ibm.com/systems/resources/pwrsysperf_SMT4OnP7.pdf
Bien sûr, 4 thread / core n'équivaut pas à 4 cores mais on peut s'en approcher pas mal selon les cas.
[^] # Re: Power et little endian
Posté par X345 . Évalué à 3.
J'ai pas lu complètement le premier article, mais le second explique exactement ce que je disais (utilisation du pipeline, latence mémoire).
Dans le deuxième article, ils revendiquent un facteur 1.5-2 au mieux, pas un facteur 4.
J'avais dit 1.15-1.25, on peut atteindre 2 sur une workload favorable (ils parlent de transaction donc des trucs qui font pas d'accès mémoire et qui restent en repos sur des verrous).
Mais vraiment, le SMT/HT ne vaut pas du tout un cœur physique. On essaye de nous faire croire ça en parlant de "threads" processeur, mais c'est du marketing.
[^] # Re: Power et little endian
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Enfin, c'est pas gagné ! L'hyperviseur propriétaire, j'aime pas du tout et le prix ? Pour prendre une vrai place, il faut que cela soit au même prix, IBM a toujours été hors de prix. Leur stratégie sur le libre n'a jamais été clair (cf l'affaire OpenOffice par exemple). A mon avis, ils jouent leur survis car même les banques ne doivent plus avoir envie de payer une fortune leurs bécanes.
Pour la virtualisation de milliers de VM, il y a une piste intéressante avec par exemple la machine Moonshot d'HP à base de processeur ARM. Entre l'ARM et le x86, cela va être dur de se maintenir sur un créneau généraliste…
http://www8.hp.com/us/en/products/servers/moonshot/index.html
[^] # Re: Power et little endian
Posté par X345 . Évalué à 3.
En fait, c'est pas si hors de prix que ça :
IBM Power System S822 - POWER8 2x10C 3.4Ghz 128GB RAM - $21,570
C'est environ 1.5x a 2x le prix d'une configuration Intel équivalente (encore que sur du Intel, ça va être compliqué de faire du 10 cœurs à 3.4Ghz, la fréquence sera surement un peu moindre). Reste que si sur ta workload, l'architecture POWER8 se comporte 2x mieux, ça revient moins cher. D'autant qu'on devrait voir apparaitre des solutions non-IBM à base de processeur POWER avec la fondation OpenPOWER.
Apparemment le processeurs ARM dans le Moonshot a des performances médiocres : http://www.anandtech.com/show/8357/exploring-the-low-end-and-micro-server-platforms/9
A voir comment ça évolue dans les années à venir.
[^] # Re: Power et little endian
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
On a joué dans le temps l'architecture Alpha car c'était très proche du PC en pratique. Cela aurait pu marcher si les offres s'étaient maintenu.
A plus de 20kE le ticket d'entrée, je doute que l'offre IBM aille bien loin… C'est pas avec ce genre de ticket qu'on maintient une architecture compétitive face à la puissance du x86. Cf la machine Itanium ou même Intel a du jeter l'éponge. Je crois bien plus à la carte ARM mais il faut effectivement que celle-ci monte encore un peu en puissance mais c'est bien ce qui se passe depuis quelques années…
[^] # Re: Power et little endian
Posté par X345 . Évalué à 3.
Encore une fois, tu emets des jugements péremptoires. Évidemment du Intel, c'est ce qu'il y a de plus compétitif en ce moment même.
20 k€, c'est pas le ticket d'entrée, c'est une machine dual-core avec 128Go de RAM. Le ticket d'entrée est à $6,000 chez IBM pour un POWER7+ 4C à 3.6 Ghz avec 8G de RAM. Oui, c'est toujours plus cher que du Intel, mais environ 1.5-2x toujours. Reste à voir ce que vaut l'architecture power sur ta workload. Je pense que faut vraiment éviter les jugements à l'emporte pièce style telle techno est mauvaise. Ça dépend du rapport prix/performance en fonction du domaine d'application.
Tyan a récemment proposé un serveur POWER avec un ticket d'entrée à $2,700 avec 4Go de RAM. On verra comment l'offre va se développer à l'avenir.
Pour ARM sur le serveur, ça fait des années qu'on en parle, mais jusqu'ici c'est pas très probant. On commence à avoir des puces puissantes dans les smartphones, elles vont bien finir par arriver dans les serveurs. D'autant que le ratio performance/consommation des puces ARM est quand même très bon.
En tous le fait que les architectures POWER (en 64 bits little endian) et ARM fassent leur entrée dans Debian montre qu'on risque d'entendre parler à l'avenir.
[^] # Re: Power et little endian
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai eu de l'Alpha, du POWER, de l'Itanium… et même du SPARC et du 68000 sous UNIX. A par l'Alpha, les autres ont toujours été trop cher pour un quelconque gain réel. Avec 15k€, j'ai une machine DELL avec 512Go RAM et c'est la RAM qui coûte cher sur ce genre de machine ! Via le marché public de la recherche, on a un DELL R630 avec 16Go RAM a moins de 1kE. Les gros acheteurs ont tous des marchés négociés s'ils ne sont pas trop mauvais.
Ma dernière machine exotique Itanium plantait lamentablement sur un bête 'modprobe 8021q', c'était sur la Suse officielle du constructeur… Ceci dis, je ne suis pas dans le domaine bancaire et Oracle n'a pas mis les pieds chez moi ;-) Le seul domaine ou nous utilisons les machines IBM, ce sont les supercalculateurs Blue Gene de l'IDRIS mais c'est un sacré boulot en terme de ressources humaines pour avoir un code performant dessus.
Concernant ARM, je suis d'accord avec toi, ça avance mais pas aussi vite qu'on pourrait l'espérer. L'embarqué est clairement encore la priorité…
[^] # Re: Power et little endian
Posté par X345 . Évalué à 3.
Ok, on parle de machines complète avec des processeurs ET de la RAM, pour comparer le coût des systèmes Intel/POWER. Et tu me parles de machines dont la majorité du coût est absorbé par la RAM. Ça nous indique quoi ?
Donc on compare les prix publics d'IBM avec les prix négociés chez Dell ? Au départ l'objectif, c'était de comparer le rapport prix/performance de l'architecture POWER vs Intel. Soit on compare le prix négociés chez Dell et chez IBM, soit on compare les prix publics chez Dell et chez IBM.
Donc ce genre de machines (R630, 16Go RAM) a un prix public aux alentours de 2700€ (avec un processeur 4C a 3.5Ghz). Donc ouais on est grosso modo dans un facteur 2 par rapport au POWER à $6000 (sachant que le POWER a des disques 15K contre 7.2K pour le dell, mais 8Go de RAM au lieu de 16, même nombre de cœurs, même fréquence).
Offre POWER Offre Dell
Après, je ne garantis pas que POWER soit avantageux, donc je partage plus ou moins ta conclusion. On a quand même un facteur 2 en prix. Faut le gagner en performance derrière. Mais dire que POWER a un mauvais rapport performance/prix et qu'ARM est bon, a priori, sans chiffres et sans rien, ça me semble carrément péremptoire. Enfin, vu les volumes qu'ils font, ce serait pas étonnant qu'Intel arrive à être plus compétitif.
[^] # Re: Power et little endian
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je crois qu'on est d'accord sur tout en pratique ;-) Je suis d'accord que l'architecture POWER est bien mais l'histoire montre cet argument ne suffit pas, surtout si le prix est d'un ordre de 2. Même Intel a du enterrer son Itanium, c'est pour dire. Mais cette guerre avec AMD fait que leur Xeon arrache désormais en puissance !!
Sinon, je parlais du prix marché DELL car quand on attaque ce genre de machine, on a souvent un marché. Je n'ai pas parlé de marché IBM car un, on n'en a pas et deux, dans nos derniers appels d'offre, IBM ne faisait pas de cadeaux ;-( Ceci dis, je suis curieux de voir ce que cela va donner car la réaction d'Intel est toujours intéressante.
[^] # Re: Power et little endian
Posté par Dabowl_75 . Évalué à 2.
Tu as le choix entre deux hyperviseurs :
PowerVM : Proprio mais qui tire au mieux les possibilité hardware car c'est un produit mûr
Sous PowerVM, tu peux faire tourner AIX, Linux, i(as400)
PowerKVM : le KVM que tout le monde connait mais porté sur POWER
Linux only
Le portage de KVM sur POWER nécessite du code bien spécifique car le cpu POWER intègre trois niveau d'exécution (mode hyperviseur, supervisieur, utilisateur)
Un contributeur powerKVM bien connu du monde Power : Benjamin Herrenschmidt
Un kernel guru ppc bien connu de ceux qui utilisaient linux sur mac ppc ;-)
[^] # Re: Power et little endian
Posté par Mikis . Évalué à 6.
WinXP aussi.
[^] # Re: Power et little endian
Posté par eingousef . Évalué à 3.
ouch
*splash!*
[^] # Re: Power et little endian
Posté par Adrien . Évalué à 10.
Tu compares Debian à Windows XP ? un vendredi ?
Tu va voir ta gueule à la récré !
[^] # Re: Power et little endian
Posté par xcomcmdr . Évalué à 3.
DOS aussi.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Power et little endian
Posté par gUI (Mastodon) . Évalué à 6.
Font chier ces indiens… tu m'étonnes que c'est les cowboys qui ont gagnés !!!
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Linus et ses choix
Posté par reynum (site web personnel) . Évalué à 2.
Ce qui n'est pas faux en soi.
Mais en coupant la poire en deux on aurait pu transformer armv8/aarch64 en un joli arm_arch64 qui était aussi clair bien que plus long.
Je ne répondrais RIEN à ce Troll beaucoup trop évident (de sagesse) !!! hahaha ! t'es bien embêté hein ? :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Linus et ses choix
Posté par xcomcmdr . Évalué à 10. Dernière modification le 03 avril 2015 à 16:20.
Non. Pas la peine de répéter que c'est une architecture alors que c'est un nom censé représenter une… architecture. Quel intérêt ?
Bref arm64 c'est parfait.
On dit pas x86arch_64, on dit x86_64 ou amd64. Ben là, c'est pareil.
C'était un message de la brigade anti répétition.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Linus et ses choix
Posté par Spyhawk . Évalué à 4.
C'est triste, ton avis sur le comique d'anti répétition…
[^] # Re: Linus et ses choix
Posté par _kaos_ . Évalué à -2.
Toi, tu n'as pas un clavier qui se blo
Matricule 23415
[^] # Re: Linus et ses choix
Posté par MTux . Évalué à 2.
Ben c'est histoire de dire tiens j'utilise Debian GNU/Linux en armv8/aarch64 :)
# Vivement qu'elle se pointe pour que sid reprenne son développement...
Posté par seb95 (site web personnel) . Évalué à 0.
Bien content qu'elle arrive cette stable, et ceci pour deux raisons.
- Tout d'abord virer arch de tout les pc de mon entourage, et mettre du debian stable comme avant soit avec du pinning sois sans!
- Et voir ma sid revenir a jour car par rapport a ma 0linux elle est carrément a la traine!
Pourquoi virer arch? simplement que j'ai cru comme un idiot que arch avec son système de mise a jour continue, allait me permettre de mettre a jour sans avoir a réinstaller au bout de deux ou trois ans. Résultat si pas de gros changement ça passe, si il y a de gros changement(merci kf5) ça casse pas mal. Pourtant je m’étais mis que du lts(firefox et kernel) mais en fin de compte pas mal de truc a faire a la manu(ça c'est normal) mais faut suivre les news pour etre au courant et quand la dernière mise a jour date c'est la cata.
Donc pour moi ça sera rien d'autre que debian sur les bureaux des personnes a qui j'installe, et ubuntu lts sur les portables.
Debian tu installe et tu oublie! C'est ça la stabilité selon debian, et maintenant je comprend ce formidable système. Stable selon debian, c'est:
- stabilité de l'archive, pas de nouveau programme ni programmes qui disparaissent.
- stabilité des fonctions, pas de perte ni d'ajout de fonction, ni dans le système ni dans les logiciels.
- stabilité de l'ensemble des logiciels(ou du moins ils essayent)
Et ça change tout par rapport aux autres distribution.
Apres le top ça serait que sid ne soit pas touché par le gel, car attendre aussi longtemps pour ceux qui aime etre a jour c'est pas facile, mais ça permet aussi de connaitre d'autres distribution(0linux notamment et NuTyX…)
Je ne dis pas non plus que arch c'est de la merde, c'est seulement qu'elle ne me convient pas/plus, chez les autres c'est trop le bordels si ils s'occupe de mettre a jour eux meme. Si je m'occupe de les faire, vu que je suis pas tout les jours chez eux et meme parfois plus de 6 mois ça fait tout de suite de tres grosses mises a jour et c'est souvent la cata…
# Le mois de sortie est t'il bien choisi?
Posté par seb95 (site web personnel) . Évalué à -3.
Je me pose cette question, car c'est aussi l'arrivée de la ubuntu 15.04, meme si c'est une version mineur d'ubuntu qui maintient maintenant c'est "versions mineurs" que 9mois, ça fera forcement de l'ombre pour debian.
Si elle sort avant, la sortie de debian sera vite oublié, et si elle sort apres, elle risque d'etre peu vu…
Je me trompe?
[^] # Re: Le mois de sortie est t'il bien choisi?
Posté par Anthony Jaguenaud . Évalué à 5.
Je pense que oui. Car les aficionados de l’une se moque de l’autre.
Personnellement, une distribution qui intègre des versions bêta pseudo stabilisés ne m’intéresse pas. Par contre une distribution qui pourra être utilisée pendant plusieurs années sans changement majeure, c’est un plus pour les habitudes de l’utilisateur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.