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.
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.
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.
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.
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.
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.
J'arrive à vivre avec EPEL qui fait tout ce que tu aimes dans
les repos Debian.
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 ).
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.
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.
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.
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.
Les changements de version Debian sont simples.
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.
A long-running problem in Debian is that several of our core teams are severely under-staffed.
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.
par contre aucuns de nos serveurs CentOS 5 n'a été migré en 6
ou en 7.
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 ) ?
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 ).
Par exemple, ansible tourne par dessus funcd, ou supporte d'entrer dans une zone, un lxc, ou un chroot.
Et j'ai un bout de code qui le fait marcher par dessus salt, modulo le dernier bug que je doit corriger ( je sais pas si c'est du coté de salt ou du coté d'ansible, mais la ligne de commande shell que ansible utilise coince avec salt )
Tu es pas obligé. Tu as comme dit "ansible-pull", ou tu peux utiliser mon role de bastion ( https://github.com/OSAS/ansible-role-ansible_bastion ), ou tu commites via git et ça déclenche la mise à jour sélective depuis une machine central ( et idéalement mieux sécurisé ).
J'ai tenté de travailler sur un setup avec ansible-pull , mais j'ai encore le souci de distribution des secrets ( ie, comment je m'assure qu'un serveur compromis n'a pas d'accés au mot de passe des autres serveurs,
J'utilise assez souvent le cache des facts pour avoir une vue globale de mon infra, et ça utilise le fait d'avoir un seul serveur pour ça. Mais je pense que le partage des données en cache devrait être reglé par : https://github.com/ansible/ansible/pull/9804 ), j'ai juste pas tenté.
Ansible est un moteur d'execution de modules via ssh. Tu décrit un tache ( 'installer un paquet via yum' ), et tu lances la tache sur X machines décrit dans un fichier d'inventaire. C'est le mode le plus simple.
Ensuite, tu as "décrire plusieurs taches, et les lancer sur une ou plusieurs machines", ce qui est un playbook. La, tu peut soit faire de la convergence de configuration ( ie, relancer le playbook qui indique comment ton serveur doit être installé, et miser sur le fait que les taches soient idempotentes pour que ça marche ), soit faire de l'orchestration ( genre je prends 3 serveurs, je les retire de nagios et du load balancer, j'upgrade, je reboote, je remets dans nagios, le load balancer, et je passe aux 3 suivants ).
Et comme ansible est flexible, tu peux faire plus que du ssh. Par exemple, considerer que "chroot /foo" est une connexion à un os différent. Ou dans le cas de l'article, que lxc ou docker le soit. Et donc, tu peut preparer une arborescence pour usage futur. Genre pour usage dans une image docker. Ou comme j'ai tenté de le faire, pour une image ostree.
Moi, je crois que c'est un plan de Lennart Poettering pour diviser le monde des browsers libres afin d'imposer browserd pour unifier le monde du libre autour d'une seul implémentation.
La preuve la plus flagrante est qu'on ne trouve aucun lien avec systemd, ce qui prouve bien qu'ils ont un truc à cacher.
De ce qu'on m'a dit que c'est assez dépendant des équipes et de leur manager, y en a ou il y a du temps, d'autre pas. Je connais quelqu'un qui a fait du volontariat pour un événement, et Google a versé de l'argent parce qu'il a fait du volontariat. Je connais quelqu'un qui a codé sur un outil que Google n'utilise pas (ou du moins, pas pour leur serveur) de façon assez conséquente, sur son temps de travail.
Vu la croissance de la boite, c'est pas non plus surprenant que ça soit moins uniforme qu'on l'imagine, et le coté magique de Google, c'est aussi de faire croire que c'est radicalement différent d'une autre grosse boite. C'est peut être le cas sur d'autres choses, mais il y a sans doute aussi des trucs tout à fait terre à terre ou des machins qui ont changés depuis pour diverses raisons ( ou des gens qui ont mal compris ).
Ils ont lancé le service en 2010. Donc en ~3 ans, ils ont réalisé le même chiffre d'affaire que Red hat en plus de 15 ans.
Ou 5 fois plus qu'OVH en 2013, sur un segment similaire.
Alors c'est pas mon genre de défendre microsoft, mais ils ont des centres de recherches qui produisent des tonnes de trucs.
Par exemple, Leslie Lamport bosse chez eux, il a quasiment inventé Paxos et divers variantes, et ça, c'est utilisé à fond par Google ( parmi tant d'autres ).
De ce que je sais, y a pas mal de projets juste en france avec l'inria, et l'innovation, c'est pas juste "refaire un os pour telephone en java", ou "refaire un navigateur web"….
C'est pas un ou exclusif. Tu peux faire un procès et changer de FAI. Tout comme tu peux aller aux prud'hommes et changer de taf. Tu peux remplir un rapport de bug et changer de logiciel.
Autre cas d'usage, tu as la création de microservice, avec les promesses de "ça scale à mort si c'est bien fait, et ça mutualise les ressources", mais surtout "les gens vont pas avoir besoin d'avancer à la même vitesse" ( ie, une solution à des soucis qu'on peut qualifier de social ).
Tu as aussi les histoires de mutualisation, cad diviser tes machines sans avoir la lourdeur des VMs ( lourdeur dans le sens ou il faut gérer les serveurs même virtuels ). J'ai prévu quand j'aurais du temps de jouer avec openshift v3, une surcouche sur kubernetes, qui est lui même un système d'orchestration de containers pour faire de l’hébergement des projets sur lequel je bosse. L'idée de faire des rollbaks rapidement est à mon sens utile pour que les gens puissent pousser sans risque, le fait de pouvoir tester chez toi sur docker est aussi pas mal pour ça.
Donc bon, je me voit pas déployer tout ( loin de la ), mais y a des trucs ou ça peut se révéler pas mal.
Dans mon souvenir, l'usage de l'UTF8 dans tex/latex est toujours un peu tendu, mais j'imagine qu ça compte pas comme bug, mais comme évolution.
Des gens vont te dire que tex est pas facile à utiliser, mais vu le mépris qu'on a pour les gens qui veulent rendre les choses plus simples, j'imagine que ça ne compte pas comme bug non plus.
Les bureaux sont en région parisienne, à la défense ( tour Franklin, sauf erreur de ma part ), mais la boite est ouverte au télétravail (on peut citer Vincent Untz comme superstar bossant depuis Grenoble, par exemple, mais j'en connais d'autre).
Ceci dit, il y a des travaux sur le fait d'avoir la pile tcp/ip en userspace, et avoir des interpréteurs directement lancé à la place du kernel (notamment sur des VM, voir le projet Mirage, erlang on xen, etc).
Donc la question de la séparation kernelspace/userspace est en effet remis en cause. Après tout, pendant longtemps, on a eu les drivers graphiques en dehors du kernel. ( et on a encore des drivers en dehors pour l'USB, par exemple, ou les imprimantes ).
Le type ne dit pas que Linux va disparaître, le mec dit que
Linux va être approprié par RedHat.
ce qui prouve qu'il y a quand même toute une éducation à refaire.
Parce que d'une part, ça fait des années que Red hat contribue sur des tonnes de projets ( http://community.redhat.com/software/ ), ça fait des années que Red hat est dans le top des contributeurs kernels, et du système de base ( gcc, glibc, coreutils, etc ).
Donc si tout d'un coup, la personne s'en rends compte, c'est soit qu'il avait pas la moindre idée de comment c'était fait avant et donc, un manque d'éducation sur la chaine de production, un peu comme le fait qu'on ne sait pas d’où vient la bouffe ou nos chaussures. Ou le fait d'attribuer incorrectement l'origine uniquement au distributeur, auquel cas on peut se poser la question de l'impact de certaines distribs qui se positionnent comme "linux = nous" (je parle d'Ubuntu, pour être clair.. )
systemd est un choix stratégique pour, à priori, amener les
systèmes Linux vers une adoption plus importante dans le
contexte du desktop.
Le terme que tu cherches est peut être "intégration" plus que "adoption".
Ensuite, ouais, Gnome ne sa cache pas de vouloir s'intégrer dans la plateforme, et de s'appuyer sur les APIs existantes pour se focaliser sur les couches les plus hautes. La coopération entre projets libres, c'est aussi ça et Si KDE et GNOME délègue la gestion du suspend à un composant externe, ça fait toujours ça de moins comme code à dupliquer et à corriger 2 fois.
La liberté de bénéficier gratos du travail d'intégration des gens qui font le boulot bien sur. En fait, il a toujours la liberté, c'est juste que l'intégration lui plait pas, donc il doit la refaire. Et c'est plus gratos, faut investir de son temps.
Tu as le droit de te plaindre, mais ça veut pas dire que les gens vont pas te répondre. Le droit de râler s'applique aussi à tes propos, et si tu estimes ça chiant, fait preuve d'un peu d'empathie et dit toi qu'il y a des devs qui se prennent ça pour le moindre changement qu'ils font.
Et si tu te dit que ça n'apporte rien au débat, pose toi la question de savoir ce que redire ce qui a été dit 100 fois apporte aussi.
Alors je rajoute un bémol, il y a des nuances entre "ne fait rien du tout" et "mets tout son pognon dessus". Le desktop pour RH est entre les 2. Il y a un produit ( cf site web, chercher "RHEL Workstation" ), il y a des clients ( cf site web également, genre pixar ). Il y a des gens payés dessus ( cf les gens dont on trouve le nom dans les changelog et les gens payé sur gnome ).
Ensuite, ouais, y a pas besoin d'aller éplucher les rapports donnés à la SEC pour dire que c'est pas le produit qui ramène le plus de pognon ( et ça en ramène assez pour autofinancer l'équipe, d'après le chef de l'équipe Desktop chez eux que j'ai croisé au Guadec à Strasbourg ).
Donc ça pourrait trés bien être un truc sponso par RH et utile sur le desktop.
Le fait est que systemd offre des fonctions utiles pour le serveur:
- le fait de tuer de manière sure un service
- les limitations de ressources via cgroups
- la gestion des containers
- le fait de placer chaque service dans un environnement propre et répétable
- un système de HA rudimentaire (via la relance automatique, chose qu'on demande parfois à un opérateur humain de faire)
- l'activation par socket, ce qui permet de faire du "à la demande", et donc d'augmenter la densité des services par serveur
- l'isolation des services, pour une plus grande sécurité d'un service exposé sur le réseau (PrivatTmp, blacklist de syscall, etc )
C'est des fonctions qui répondent plus à des problématiques "serveur" que des problématiques 'desktop'.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. É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 Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. É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 Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. É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 Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. É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 Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. É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 Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. É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 Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. É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: Oubli…
Posté par Misc (site web personnel) . En réponse au journal Ansible ton conteneur !. Évalué à 4.
Sauf que salt-ssh ne fait que du ssh.
Ansible propose ça :
https://github.com/ansible/ansible/tree/devel/lib/ansible/runner/connection_plugins
Par exemple, ansible tourne par dessus funcd, ou supporte d'entrer dans une zone, un lxc, ou un chroot.
Et j'ai un bout de code qui le fait marcher par dessus salt, modulo le dernier bug que je doit corriger ( je sais pas si c'est du coté de salt ou du coté d'ansible, mais la ligne de commande shell que ansible utilise coince avec salt )
[^] # Re: Oubli…
Posté par Misc (site web personnel) . En réponse au journal Ansible ton conteneur !. Évalué à 4.
Tu es pas obligé. Tu as comme dit "ansible-pull", ou tu peux utiliser mon role de bastion ( https://github.com/OSAS/ansible-role-ansible_bastion ), ou tu commites via git et ça déclenche la mise à jour sélective depuis une machine central ( et idéalement mieux sécurisé ).
J'ai tenté de travailler sur un setup avec ansible-pull , mais j'ai encore le souci de distribution des secrets ( ie, comment je m'assure qu'un serveur compromis n'a pas d'accés au mot de passe des autres serveurs,
J'utilise assez souvent le cache des facts pour avoir une vue globale de mon infra, et ça utilise le fait d'avoir un seul serveur pour ça. Mais je pense que le partage des données en cache devrait être reglé par : https://github.com/ansible/ansible/pull/9804 ), j'ai juste pas tenté.
[^] # Re: Oubli…
Posté par Misc (site web personnel) . En réponse au journal Ansible ton conteneur !. Évalué à 6.
Ça depend ou tu situes ton spectre.
Ansible est un moteur d'execution de modules via ssh. Tu décrit un tache ( 'installer un paquet via yum' ), et tu lances la tache sur X machines décrit dans un fichier d'inventaire. C'est le mode le plus simple.
Ensuite, tu as "décrire plusieurs taches, et les lancer sur une ou plusieurs machines", ce qui est un playbook. La, tu peut soit faire de la convergence de configuration ( ie, relancer le playbook qui indique comment ton serveur doit être installé, et miser sur le fait que les taches soient idempotentes pour que ça marche ), soit faire de l'orchestration ( genre je prends 3 serveurs, je les retire de nagios et du load balancer, j'upgrade, je reboote, je remets dans nagios, le load balancer, et je passe aux 3 suivants ).
Et comme ansible est flexible, tu peux faire plus que du ssh. Par exemple, considerer que "chroot /foo" est une connexion à un os différent. Ou dans le cas de l'article, que lxc ou docker le soit. Et donc, tu peut preparer une arborescence pour usage futur. Genre pour usage dans une image docker. Ou comme j'ai tenté de le faire, pour une image ostree.
[^] # Re: Pour résumé / Point d'étape
Posté par Misc (site web personnel) . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 10.
Moi, je crois que c'est un plan de Lennart Poettering pour diviser le monde des browsers libres afin d'imposer browserd pour unifier le monde du libre autour d'une seul implémentation.
La preuve la plus flagrante est qu'on ne trouve aucun lien avec systemd, ce qui prouve bien qu'ils ont un truc à cacher.
[^] # Re: Je confirme
Posté par Misc (site web personnel) . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 6.
C'est pas parce que c'est un bug que tu va réussir à le déclencher à coup sur. C'est un bug, par définition, c'est un comportement inattendu :)
[^] # Re: C'est le jeu ma pauvre lucette!
Posté par Misc (site web personnel) . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 7.
Sans doute ça :
http://www.wired.com/2013/08/20-percent-time-will-never-die/
ou ça :
http://www.businessinsider.com/mayer-google-20-time-does-not-exist-2015-1
De ce qu'on m'a dit que c'est assez dépendant des équipes et de leur manager, y en a ou il y a du temps, d'autre pas. Je connais quelqu'un qui a fait du volontariat pour un événement, et Google a versé de l'argent parce qu'il a fait du volontariat. Je connais quelqu'un qui a codé sur un outil que Google n'utilise pas (ou du moins, pas pour leur serveur) de façon assez conséquente, sur son temps de travail.
Vu la croissance de la boite, c'est pas non plus surprenant que ça soit moins uniforme qu'on l'imagine, et le coté magique de Google, c'est aussi de faire croire que c'est radicalement différent d'une autre grosse boite. C'est peut être le cas sur d'autres choses, mais il y a sans doute aussi des trucs tout à fait terre à terre ou des machins qui ont changés depuis pour diverses raisons ( ou des gens qui ont mal compris ).
[^] # Re: TCPA/Palladium
Posté par Misc (site web personnel) . En réponse au journal parait que ca manque de troll. Évalué à 10.
Azure a fait 1 milliard de chiffres d'affaire en 2013.
http://www.journaldunet.com/solutions/cloud-computing/chiffre-d-affaires-azure-en-2013.shtml
Ils ont lancé le service en 2010. Donc en ~3 ans, ils ont réalisé le même chiffre d'affaire que Red hat en plus de 15 ans.
Ou 5 fois plus qu'OVH en 2013, sur un segment similaire.
Pour donner une comparaison de la croissance, l'Appstore d'Apple a fait ça en 2 ans ( http://www.macworld.com/article/1157957/app_store_market_share.html , ouvrture en 2008, chiffre d'affaire en en 2009 de 800 millions ).
Donc bon, pour une boite moribonde, ils ont visiblement réussi à faire un peu d'affaire, face à la concurrence de Amazon et d'une tonne d'acteurs.
[^] # Re: TCPA/Palladium
Posté par Misc (site web personnel) . En réponse au journal parait que ca manque de troll. Évalué à 10.
Alors c'est pas mon genre de défendre microsoft, mais ils ont des centres de recherches qui produisent des tonnes de trucs.
Par exemple, Leslie Lamport bosse chez eux, il a quasiment inventé Paxos et divers variantes, et ça, c'est utilisé à fond par Google ( parmi tant d'autres ).
De ce que je sais, y a pas mal de projets juste en france avec l'inria, et l'innovation, c'est pas juste "refaire un os pour telephone en java", ou "refaire un navigateur web"….
[^] # Re: Certes
Posté par Misc (site web personnel) . En réponse au journal L'autohébergement, c'est pas gagné. Évalué à 5.
C'est pas un ou exclusif. Tu peux faire un procès et changer de FAI. Tout comme tu peux aller aux prud'hommes et changer de taf. Tu peux remplir un rapport de bug et changer de logiciel.
[^] # Re: Des usages à cerner
Posté par Misc (site web personnel) . En réponse au journal Docker, la plateforme à la mode. Évalué à 4.
Alors parmi les cas d'usage, c'est deja le fait d'avoir un truc self contained à déployer. IE, ce que tu testes est exactement ce que tu déploies.
Ça, c'est globalement la théorie, la pratique est plus compliqué car la platforme est pas correctement isolé :
http://www.fewbytes.com/docker-selinux-and-the-myth-of-kernel-indipendence/
Autre cas d'usage, tu as la création de microservice, avec les promesses de "ça scale à mort si c'est bien fait, et ça mutualise les ressources", mais surtout "les gens vont pas avoir besoin d'avancer à la même vitesse" ( ie, une solution à des soucis qu'on peut qualifier de social ).
Tu as aussi les histoires de mutualisation, cad diviser tes machines sans avoir la lourdeur des VMs ( lourdeur dans le sens ou il faut gérer les serveurs même virtuels ). J'ai prévu quand j'aurais du temps de jouer avec openshift v3, une surcouche sur kubernetes, qui est lui même un système d'orchestration de containers pour faire de l’hébergement des projets sur lequel je bosse. L'idée de faire des rollbaks rapidement est à mon sens utile pour que les gens puissent pousser sans risque, le fait de pouvoir tester chez toi sur docker est aussi pas mal pour ça.
Donc bon, je me voit pas déployer tout ( loin de la ), mais y a des trucs ou ça peut se révéler pas mal.
[^] # Re: TU
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
Dans mon souvenir, l'usage de l'UTF8 dans tex/latex est toujours un peu tendu, mais j'imagine qu ça compte pas comme bug, mais comme évolution.
Des gens vont te dire que tex est pas facile à utiliser, mais vu le mépris qu'on a pour les gens qui veulent rendre les choses plus simples, j'imagine que ça ne compte pas comme bug non plus.
[^] # Re: Empire français
Posté par Misc (site web personnel) . En réponse au journal SUSE Linux se prépare à recruter 150 personnes !. Évalué à 2.
Les bureaux sont en région parisienne, à la défense ( tour Franklin, sauf erreur de ma part ), mais la boite est ouverte au télétravail (on peut citer Vincent Untz comme superstar bossant depuis Grenoble, par exemple, mais j'en connais d'autre).
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Ceci dit, il y a des travaux sur le fait d'avoir la pile tcp/ip en userspace, et avoir des interpréteurs directement lancé à la place du kernel (notamment sur des VM, voir le projet Mirage, erlang on xen, etc).
Donc la question de la séparation kernelspace/userspace est en effet remis en cause. Après tout, pendant longtemps, on a eu les drivers graphiques en dehors du kernel. ( et on a encore des drivers en dehors pour l'USB, par exemple, ou les imprimantes ).
[^] # Re: Z spotted
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
ce qui prouve qu'il y a quand même toute une éducation à refaire.
Parce que d'une part, ça fait des années que Red hat contribue sur des tonnes de projets ( http://community.redhat.com/software/ ), ça fait des années que Red hat est dans le top des contributeurs kernels, et du système de base ( gcc, glibc, coreutils, etc ).
Donc si tout d'un coup, la personne s'en rends compte, c'est soit qu'il avait pas la moindre idée de comment c'était fait avant et donc, un manque d'éducation sur la chaine de production, un peu comme le fait qu'on ne sait pas d’où vient la bouffe ou nos chaussures. Ou le fait d'attribuer incorrectement l'origine uniquement au distributeur, auquel cas on peut se poser la question de l'impact de certaines distribs qui se positionnent comme "linux = nous" (je parle d'Ubuntu, pour être clair.. )
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 7.
Le terme que tu cherches est peut être "intégration" plus que "adoption".
Ensuite, ouais, Gnome ne sa cache pas de vouloir s'intégrer dans la plateforme, et de s'appuyer sur les APIs existantes pour se focaliser sur les couches les plus hautes. La coopération entre projets libres, c'est aussi ça et Si KDE et GNOME délègue la gestion du suspend à un composant externe, ça fait toujours ça de moins comme code à dupliquer et à corriger 2 fois.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 4. Dernière modification le 28 février 2015 à 11:09.
La liberté de bénéficier gratos du travail d'intégration des gens qui font le boulot bien sur. En fait, il a toujours la liberté, c'est juste que l'intégration lui plait pas, donc il doit la refaire. Et c'est plus gratos, faut investir de son temps.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Tu as le droit de te plaindre, mais ça veut pas dire que les gens vont pas te répondre. Le droit de râler s'applique aussi à tes propos, et si tu estimes ça chiant, fait preuve d'un peu d'empathie et dit toi qu'il y a des devs qui se prennent ça pour le moindre changement qu'ils font.
Et si tu te dit que ça n'apporte rien au débat, pose toi la question de savoir ce que redire ce qui a été dit 100 fois apporte aussi.
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 7.
Alors je rajoute un bémol, il y a des nuances entre "ne fait rien du tout" et "mets tout son pognon dessus". Le desktop pour RH est entre les 2. Il y a un produit ( cf site web, chercher "RHEL Workstation" ), il y a des clients ( cf site web également, genre pixar ). Il y a des gens payés dessus ( cf les gens dont on trouve le nom dans les changelog et les gens payé sur gnome ).
Ensuite, ouais, y a pas besoin d'aller éplucher les rapports donnés à la SEC pour dire que c'est pas le produit qui ramène le plus de pognon ( et ça en ramène assez pour autofinancer l'équipe, d'après le chef de l'équipe Desktop chez eux que j'ai croisé au Guadec à Strasbourg ).
Donc ça pourrait trés bien être un truc sponso par RH et utile sur le desktop.
Le fait est que systemd offre des fonctions utiles pour le serveur:
- le fait de tuer de manière sure un service
- les limitations de ressources via cgroups
- la gestion des containers
- le fait de placer chaque service dans un environnement propre et répétable
- un système de HA rudimentaire (via la relance automatique, chose qu'on demande parfois à un opérateur humain de faire)
- l'activation par socket, ce qui permet de faire du "à la demande", et donc d'augmenter la densité des services par serveur
- l'isolation des services, pour une plus grande sécurité d'un service exposé sur le réseau (PrivatTmp, blacklist de syscall, etc )
C'est des fonctions qui répondent plus à des problématiques "serveur" que des problématiques 'desktop'.