qui permette de gerer ton propre jeu de miroir de rpm, d'imageopenstack ou docker ( et si quelqu'un pouvait coder le support des paquets Debian, ça serait chouette ).
Et je suis pas sur que faire un dépôt basé sur git pour mettre des images de 100 à 200m soit une riche idée :)
Moi, ce que je trouve bizarre, c'est qu'on perpétue le fait que les fonctionnaires soient différents et qu'on se dise dans notre esprit qu'ils sont une et une seule entité. Et qu'on fasse une différence privé publique si forte. Jamais tu n'as dans l'esprit des gens ou dans les discussions une opposition marqué entre 2 boites privés ou 2 administrations publiques. Mais les hommes politiques, à force de stigmatisation, ont réussi à ce qu'on généralise sur les fonctionnaires, alors qu'il y a comme partout ailleurs, de tout.
Je pense qu'il y a sans doute un lien entre ce qu'on voit grâce à l'explosion des réseaux sociaux, la peur de louper des choses ( https://en.wikipedia.org/wiki/Fear_of_missing_out ) et le comportement de la NSA. Il n'y a pas de raison que ça affecte les gens en dehors de la NSA et pas les gens à l'intérieur, surtout si une partie de leur role est justement de se tenir au courant.
À partir de la, et ayant les moyens et entouré de gens partageant le syndrome, n'ayant pas de garde fous ( tel que "j'ai un job à faire" et "je doit voir mes potes" ), j'imagine que ça a très bien pu se propager comme un feu de priarie dans la structure de l'agence.
En fait, au vue de la taille de la citation sur le premier et de la pub que le VP de Numergy se fait, je peux imaginer qu'il s'agit d'un client stratégique, et ça implique sans doute "payer pour du code".
Mais ensuite, il semble que l'intégration avec VMWare ne soit pas encore suffisamment fiable:
Et il n'est pas question de passion, d'esprit du libre, de
communauté et tout le toutim.
Il faut pourtant voir qu'un tarif plus bas permet d'avoir une debian LTS. Et avoir une debian LTS permet de garder leur business en vie d'une part, mais aussi de rendre Debian compétitive, d'augmenter le nombre de contribution et donc s'aligne aussi avec leur passion de Debian.
Je ne pense pas qu'on puisse facilement séparé les 2.
Centos tape dans la même durée de vie que RHEL sauf erreur de ma part ( peut être pas d'aprés ce que Zertinam dit ). Mais le reste encore correct, et en effet, Debian passe à la traine sans LTS par rapport aux restes des distribs traditionnellement vu comme serveurs.
Je pense que 3 ans, c'est suffisant pour moi en tant que particulier. Mais je sais aussi qu'il y a des gens avec des distribs comme RHEL 4 en production, du Solaris 8, etc, etc. SUr le coup, quand j'ai eu un appel téléphonique avec un client qui m'a dit avoir ça, j'ai pas percuté, mais Solaris 8 est sorti en 2000, Solaris 9 en 2002, et sont encore supporté ( plus ou moins pour Solaris 8, et plus très longtemps pour le 9 si je pige bien ce que Wikipedia me dit ).
Il faut aussi voir le timing des discussions. Fin 2011, Canonical passe le support LTS de 3 ans à 5 ans.
Avril 2012, Canonical sort sa LTS avec un support plus étendu que d'habitude, fait de la publicité, etc.
Un an, un an et demi passe, et je pense que l'effet des annonces commencent à se faire sentir par ci par la, à savoir que les gens commencent à réaliser que prendre une Ubuntu va permettre d'avoir un support plus long que Debian, que prendre Centos va aussi permettre d'avoir un support plus long que Debian. Pour certains, ils s'en foutent, pour d'autres, peut être pas.
La, je pense que les discussions privées sur un coin de table commence. L'idée trotte sans doute depuis longtemps, mais c'était pas si critique, Debian était dans la moyenne.
Donc on arrive à mi-2013, les gens discutent et quelques mois plus tard, organisation d'un meeting de la security team à Essen, allemagne. Et l'annonce de Debian LTS est faite en janvier 2014. Avance rapide au moins de Juin, Debian 6 est EOL, donc Debian-LTS arrive.
Debian LTS est la parce que les indépendants autour de Debian ont commencé à voir les demandes des clients, parce qu'ils ont aussi envie de voir le projet vivre et prospérer, et parce que les temps ont changés.
Je ne doute pas que le tarif de gros soit moins cher. Je pense que l'équipe de 10 admins windows, qui était un peu moins expérimenté que moi était à 200 ou 300€ par jour et par personne. Mais c'était aussi des gens qu'on avait pris quasiment à la sortie de l'école (aec un diplôme en physique, ce qui n'est pas un mal mais un chouia moins adapté au taf qu'un en informatique), formé 2/3 semaines et mis chez le client, de l'aveu même des personnes.
Mais sinon, oui, ils étaient en régie de la même façon que moi.
Les tarifs pratiqués pour les prestations varient quand même beaucoup.
ce qui est pas si cher en fait pour le nieau de compétences. J'étais facturé par feu ma boite à 800€/j en début de carrière, en régie en Alsace pendant 3 ans. Et quand je vois le tarif des consultants de nos jours, je me dit que soit l'inflation est passé par la, soit j'étais pas si cher que ça.
Ensuite, il faut voir que ça ne vise pas que les travailleurs français, et je pense aussi qu'ils font ça par passion donc sont sans doute prêt à faire une réduction de principe, ce qui explique le prix pas si haut que ça (ça, ou une déformation du à Paris).
Y a un certain nombre de trucs qui me laisse songeur
un peu partout.
D'abord, faire une liste privé pour que les boites puissent se retrouver entre elles, ça me parait un peu aller contre la transparence qu'on attends de Debian. Je comprends bien le fait de devoir offrir quelque chose en plus, mais ça fait très "mandrake club", et historiquement, ça n'a super bien marché. À coté, toutes les sociétés commerciales font ça aussi. Je pense qu'une condition pour que ça apporte de la valeur est d'avoir une communauté suffisamment grande et ç'est pas encore le cas. Donc personnelement, je commencerais pas par proposer ça.
Ensuite, le fait d'avoir le droit de soumettre ses propres tests cases me parait aussi curieux. Si le test case est utile à plusieurs personnes, pourquoi ne pas le donner à tous, et le mettre upstream ? Je pense aussi que l'offre ne dit pas clairement quel genre de test case je peux donner (genre, si je dit "voila mon test case, il faut lancer ce benchmark sur 30 machines", ça va être refusé ). Ou ce qui se passe en cas de problème avec le test case, etc, etc. Et il se passe quoi si je paye pas et que je donne un test case, il est pas pris en compte ?
Pareil, direct contact to LTS staff, c'est tendu. Est ce que ça veut dire que les gens qui vont faire le travail ne vont pas avoir leur email publié, ou si c'est le cas, il y a quoi comme avantage par rapport à juste regarder dans l'annuaire ?
Les gens peuvent aussi s'attendre à avoir un SLA, à ce que ça servent de support, etc. Au début, avec des gens qui connaissent le libre, pas de souci, mais si tu veux trouver 50 boites, ça risque de coincer tot ou tard.
J'imagine que je suis pas le premier à poser les questions, mais je vois pas de FAQ dans le site.
Ouais, mais la, on sort des APIs openstack. Que je sache, la localité des données n'est pas exposé par openstack de manière standard. Ensuite, bien sur, tu peux faire tout ce que tu veux à coté, mais le point, c'est que ç'est à coté :)
Pour docker, tu as tout le projet atomic ( http://atomicproject.io/ ). Et par exemple, geard pour l'orchestration, cockpit pour le management, et Red hat a aussi contribué pas mal sur Docker.
Ensuite, le but d'openstack, c'est pas "pour le proprio", même si la virtu sert pas mal à ça. C'est aussi parce que ça offre plus de souplesse. Par exemple, tu peux faire du self service. Tes devs gérent leur bécane et les rendent sans te faire chier. Ou tes environnement de tests/qa/preprod.
Sinon, tu a aussi (tout chaud ce matin, avant c'était proprio) le projet manageiq (http://manageiq.org/).
la, on tape en effet dans le logiciel spécialisé de gestion complète de ton infrastructure cloud. Et je dit bien cloud, et pas IaaS, vu que l'outil fait aussi l'automatisation, la gestion des stats, le cycle de vie complet. l'outil va s'interfacer avec vmware, RHEV, openstack et sans doute à terme d'autres, pour que tu puisses déployer.
Et pour parler de RHEV, son pendant communautaire est ovirt (http://ovirt.org); La, on est dans le concurent à VCenter.
La ou Openstack file des machines jetables sans gestion fine du stockage, de l'endroit ou se trouve chaque machine ou la migration à cahdu, Ovirt gére des systèmes qui ont pas pour vocation d'être jetable. Donc tu peux faire de la migration automatique, tu as un concept de datacenter, etc, etc.
Y a largement de quoi gérer tout un tas de trucs cloud et virtu.
Ce n'est pas que je n'aime pas la nouvelle méthode - c'est que
je ne la connais pas. Et j'ai beau chercher et ouvrir des
tickets chez RH je n'ai pas encore eu de réponses
satisfaisantes.
En plus SELinux c'est quand même pas évident à gérer et très
facile à casser (ce qui en langage hypervisuer veut dire plus
personne ne peut rien faire tant qu'on a pas rebooter la
machine en single user et passé SELinux en audit only).
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Les seuls fois ou tu va te bloquer avec selinux, c'est si tu bascules ton utilisateur dans un mode restreint sans prévoir un login root de secours et sans mettre selinux en permissive. Un peu comme basculer sur ldap sans te laisser un shell root ou ce genre de choses.
Enfin, les histoires de 7% à 15% , je pense que tu parles des audits, pas de selinux. Les 2 sont séparés ( ie, selinux peut tourner sans audit, auditd peut tourner sans selinux ), donc je suis pas sur du coup que tu testes vraiment ce que tu crois tester….
Je vois pas qui ferait ça ni dans quel intérêt. Des gens qui font des infras ultra complexes, ça existe à la pelle. On a tous croisé des usines à gaz et ce genre de choses, donc je vois pas pourquoi ça ne serait pas la vérité.
Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Le souci de Kaane, c'est qu'il monte ses propres architectures qui semble ultra complexes ( du moins, c'est l'impression que j'en retire des pavés et de ce que j'arrive à comprendre dans tout le mix qu'il fait ), qu'il fait des trucs relativement hors des clous ( la, nagios qui relance les services, avant, son histoire de réseau GRE à monter avant TCP/IP, etc ), et qu'ensuite, quand systemd fait la même chose (à savoir la gestion de processus) et que systemd est adopté, ça le bloque dans son architecture.
Mais systemd bloque pas quoi que ce soit, nagios peut parfaitement lancr tout ce qu'il veut soit via service ( et sudo ), soit via l'api DBUS de systemd qui est accessible à des non roots via une configuration standardisé ( vu que c'est le but de dbus ). Point bonus, tu peux contrôler ça via selinux ( ie, dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), ce qui renforce d'autant plus la sécurité et l'isolation qu'il semble vouloir.
Et en fait, l'API dbus est exactement fait pour ça, pour ne pas donner les droits roots mais pour avoir un accès fins aux données. Un project comme cockpit ( http://cockpit-project.org/ ) tire justement parti de ces APIs pour ne pas avoir besoin d'être root.
Je ne doute pas qu'il existe sans doute des vrais soucis, peut être que l'API ne donne pas les accès suffisamment finement pour ce qu'il veut, etc, mais la, les soucis semblent surtout être un mélange de dette technique et d'un manque de clarté dans l'explication du souci.
Je sais pas. Les cgroups sont orthogonaux à l'usage de ptrace. Ptrace sert juste à déterminer quel process doit être le process principal, du moins pour upstart. Mais tu peux t'en passer avec divers options, sauf erreur de ma part. Donc tu pourrais très bien imaginer que upstart se retrouve avec une option "kill cgroups", pour tuer tout les process, et avoir le support de "expect systemd", pour avoir la notification comme systemd, ou "expect pidfile", pour faire comme systemd également.
IE, la modularité est déjà la dans le code pour supporter divers choses à divers niveau, et sans remettre en cause le format.
Ensuite, le format est pourri ( difficilement parsable ), mais ça, c'est une autre histoire. Et je parle du code maintenant, pas de celui d'il y a 5 ans, et peut être que ça change tout aussi.
Les soucis de design n'étaient pas évident. Ni i impossible à corriger. Par exemple, le suivi de processus par cgroups auraient pu être mis dans upstart, le suivi avec ptrace aurait pu être refait ou abandonné. Mais Scott ne voulait pas.
Les parties manquantes dans le code (support ipv6, socket activation correct) aurait aussi pu se rajouter, avec un protocole d'activation mieux foutu.
Par contre, ce qui aurait été dur à corriger, c'est les soucis au niveau du design (genre le fait que les dépendances sont dans l'ordre inverse de ce que tu crois et que la logique interne avec les 'ou' a des résultats surprenants). Et ça, je pense qu'il fallait faire un gros usage avant de le voir.
Mir, je sais pas, mais upstart m'a intéressé. C'était une amélioration et un changement dans la gestion des processus, ça apportait des idées intéressantes ( le fait d'avoir une manière plus simple de lancer les services, le coté dynamique, le fait d'avoir une API haut niveau ).
Ensuite, l’exécution était défaillante, le CLA a bloqué des boites qui n'ont pas contribué, et Canonical n'a pas vraiment mis les moyens. Mais ça n'a pas empêché Fedora de le prendre en 2008, pour Fedora 9.
RHEL 6 aussi a adopté Upstart (bien qu'avec une intégration très light), mais je pense que c'est au cours des phases finales de RHEL 6 (cad en 2010, au vue du calendrier) que systemd a vu le jour. Le timing n'est à mon avis pas un hasard. Si je peux hasarder une rétrospective:
RHEL 6 sort en novembre 2010.
Systemd sort en avril 2010.
On peut donc supposer que l'idée de faire systemd est né fin 2009, le temps de faire un truc grosso modo potable pour la version 1, et de contacter des gens à gauche et à droite (Lennart a indiqué qu'il avait pris contact avec des mainteneurs d'autre distributions pour récolter les différentes pratiques et je pense que ça prends du temps).
On peut donc supposer que les équipes de RH ont regardé upstart plus en détail durant l'année 2009, et que ça a aboutit au fait que Lennart propose systemd. Il est aussi fort probable que ça soit la raison d'une intégration "light" au contraire d'Ubuntu.
Upstart est sorti en 2006, donc il a fallu 2/3 ans avant que des gens se penchent pour l'intégration ailleurs ( cad globalement après que la techno se soit montré assez viable pour la LTS en avril 2008, à vue de nez ).
Je sais qu'il y a eu des discussions pour prendre ça sur OpenSuse en voyant Fedora, et pareil pour Mandriva. Sauf que Mandriva a implosé en 2010, et que Suse n'a pas suivi, sans doute à cause de la sortie de systemd, et son intégration avec Fedora.
Mais voila, Upstart, sur son principe, a intéressé des gens. Le nokia n9, sorti en 2011, a upstart. On peut supposer que le choix d'upstart s'est fait 3 à 4 ans avant, ce qui montre bien le moment ou upstart a intéressé les gens. D'ailleurs, pareil pour Chromeos, toujours sur upstart, et qui a commencé en 2009 aussi.
Linus fait confiance aux divers lieutenants. Par exemple, pour le réseau, David Miller, qui est lui aussi membre de la conspiration au chapeau. J'ai pas réussi à trouver de listes des dit trusted lieutenants ( ce qui est ma foi un peu un manque de transparence ), mais je pense que Ingo Molnar est potentiellement dessus pour la partie RT , pareil, chapeau rouge ). Ou Al Viro.
Donc je pense que si ce qu'on dit est vrai ( à savoir que Linus ne regarde même pas les PR et merge direct ), Linus veille pas tant que ça. Mais bon, ça va, tant que la machine vger.kernel.org n'est pas sous la protection d'un firewall sous le controle de RH, on peut supposer que les gens sont libres.
déjà répondu:ils n'ont pas forcemment les moyens humains de le
faire
Alors, si Canonical a eu les moyens de faire son propre init ( et de continuer à faire son serveur d'affichage, son outil d'orchestration de serveur, son interface graphique et sa pile pour téléphone ), je pense qu'ils ont aussi les moyens de faire mieux, si ils le voulaient. Et Canonical est largement la plus petite des boites restantes à faire des distributions à destination du monde professionnel.
Donc, c'est quoi les moyens requis en terme d'ingénieur ?
2, 3 personnes à temps plein ? Plus, moins ?
[^] # Re: Isolation IO
Posté par Misc (site web personnel) . En réponse à la dépêche La folie Docker. Évalué à 3.
C'est pour ça qu'il aut utiliser systemd et les cgroups :p
( d'ailleurs, c'est ce qui est fait dans atomic : http://www.projectatomic.io/ )
[^] # Re: Docker vs LXC
Posté par Misc (site web personnel) . En réponse à la dépêche La folie Docker. Évalué à 2.
Tu peux aussi faire pareil via ansible et docker avec un connecteur spécial:
https://github.com/ansible/ansible/pull/7971
Le registry docker est relativement simple à faire tourner pourtant.
Tu peux aussi regardé du coté de crane et de pulp:
https://github.com/pulp/crane
https://github.com/pulp/pulp_docker
qui permette de gerer ton propre jeu de miroir de rpm, d'imageopenstack ou docker ( et si quelqu'un pouvait coder le support des paquets Debian, ça serait chouette ).
Et je suis pas sur que faire un dépôt basé sur git pour mettre des images de 100 à 200m soit une riche idée :)
[^] # Re: Fondateur qui recrute un CEO et devient CTO
Posté par Misc (site web personnel) . En réponse à la dépêche La folie Docker. Évalué à 2.
Tu parles de Canonical ?
[^] # Re: Ouf, la France n'est pas touchée par la faille !
Posté par Misc (site web personnel) . En réponse au journal Les Pays-Bas inventent le DDOS sur les services administratifs. Évalué à 10.
Moi, ce que je trouve bizarre, c'est qu'on perpétue le fait que les fonctionnaires soient différents et qu'on se dise dans notre esprit qu'ils sont une et une seule entité. Et qu'on fasse une différence privé publique si forte. Jamais tu n'as dans l'esprit des gens ou dans les discussions une opposition marqué entre 2 boites privés ou 2 administrations publiques. Mais les hommes politiques, à force de stigmatisation, ont réussi à ce qu'on généralise sur les fonctionnaires, alors qu'il y a comme partout ailleurs, de tout.
[^] # Re: Sémantique
Posté par Misc (site web personnel) . En réponse au journal Vous êtes tous des terroristes (potentiellement). Évalué à 4.
Je pense qu'il y a sans doute un lien entre ce qu'on voit grâce à l'explosion des réseaux sociaux, la peur de louper des choses ( https://en.wikipedia.org/wiki/Fear_of_missing_out ) et le comportement de la NSA. Il n'y a pas de raison que ça affecte les gens en dehors de la NSA et pas les gens à l'intérieur, surtout si une partie de leur role est justement de se tenir au courant.
À partir de la, et ayant les moyens et entouré de gens partageant le syndrome, n'ayant pas de garde fous ( tel que "j'ai un job à faire" et "je doit voir mes potes" ), j'imagine que ça a très bien pu se propager comme un feu de priarie dans la structure de l'agence.
[^] # Re: Durée de vie
Posté par Misc (site web personnel) . En réponse à la dépêche Support à long terme de Debian: une opportunité à ne pas manquer. Évalué à 2.
Sans vouloir trop pinailler et après avoir fouillé :
http://wiki.centos.org/About/Product
https://access.redhat.com/site/fr/support/policy/updates/errata
fin de centos 4 => 30/02/2012
fin de RHEL 4 => 28/02/2015
IE, tu peux payer pour avoir 3 ans de support en plus sur RHEL.
Mais je reconnais que c'est discutable.
[^] # Re: La vraie nouvelle du jour
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 2.
Donc ça serait pour Numergy que Canonical a adapté Openstack comme VMWare ( cad, avoir VMWare comme hyperviseur supporté ), cf
https://insights.ubuntu.com/2014/04/15/ubuntu-14-04-lts-the-cloud-platform-of-choice/
http://www.infoworld.com/d/virtualization/vmware-partners-canonical-extend-openstack-cloud-217458
En fait, au vue de la taille de la citation sur le premier et de la pub que le VP de Numergy se fait, je peux imaginer qu'il s'agit d'un client stratégique, et ça implique sans doute "payer pour du code".
Mais ensuite, il semble que l'intégration avec VMWare ne soit pas encore suffisamment fiable:
http://www.silicon.fr/cloud-numergy-ajoute-corde-openstack-arc-95094.html
[^] # Re: Tarif
Posté par Misc (site web personnel) . En réponse à la dépêche Support à long terme de Debian: une opportunité à ne pas manquer. Évalué à 8.
Il faut pourtant voir qu'un tarif plus bas permet d'avoir une debian LTS. Et avoir une debian LTS permet de garder leur business en vie d'une part, mais aussi de rendre Debian compétitive, d'augmenter le nombre de contribution et donc s'aligne aussi avec leur passion de Debian.
Je ne pense pas qu'on puisse facilement séparé les 2.
Comme j'ai déjà posté si souvent, la longévité de Debian est assez courte en comparaison d'autres OS. ( je me cite moi même https://linuxfr.org/nodes/97929/comments/1447718 ).
Centos tape dans la même durée de vie que RHEL sauf erreur de ma part ( peut être pas d'aprés ce que Zertinam dit ). Mais le reste encore correct, et en effet, Debian passe à la traine sans LTS par rapport aux restes des distribs traditionnellement vu comme serveurs.
Je pense que 3 ans, c'est suffisant pour moi en tant que particulier. Mais je sais aussi qu'il y a des gens avec des distribs comme RHEL 4 en production, du Solaris 8, etc, etc. SUr le coup, quand j'ai eu un appel téléphonique avec un client qui m'a dit avoir ça, j'ai pas percuté, mais Solaris 8 est sorti en 2000, Solaris 9 en 2002, et sont encore supporté ( plus ou moins pour Solaris 8, et plus très longtemps pour le 9 si je pige bien ce que Wikipedia me dit ).
Il faut aussi voir le timing des discussions. Fin 2011, Canonical passe le support LTS de 3 ans à 5 ans.
http://www.omgubuntu.co.uk/2011/10/ubuntu-12-04-lts-desktop-to-be-supported-for-five-years
Début 2012, RH annonce supporter RHEL pour 10 ans (http://www.theregister.co.uk/2012/01/31/redhat_rhel_more_life_support/).
Avril 2012, Canonical sort sa LTS avec un support plus étendu que d'habitude, fait de la publicité, etc.
Un an, un an et demi passe, et je pense que l'effet des annonces commencent à se faire sentir par ci par la, à savoir que les gens commencent à réaliser que prendre une Ubuntu va permettre d'avoir un support plus long que Debian, que prendre Centos va aussi permettre d'avoir un support plus long que Debian. Pour certains, ils s'en foutent, pour d'autres, peut être pas.
La, je pense que les discussions privées sur un coin de table commence. L'idée trotte sans doute depuis longtemps, mais c'était pas si critique, Debian était dans la moyenne.
Donc on arrive à mi-2013, les gens discutent et quelques mois plus tard, organisation d'un meeting de la security team à Essen, allemagne. Et l'annonce de Debian LTS est faite en janvier 2014. Avance rapide au moins de Juin, Debian 6 est EOL, donc Debian-LTS arrive.
Debian LTS est la parce que les indépendants autour de Debian ont commencé à voir les demandes des clients, parce qu'ils ont aussi envie de voir le projet vivre et prospérer, et parce que les temps ont changés.
[^] # Re: Tarif
Posté par Misc (site web personnel) . En réponse à la dépêche Support à long terme de Debian: une opportunité à ne pas manquer. Évalué à 2.
Je ne doute pas que le tarif de gros soit moins cher. Je pense que l'équipe de 10 admins windows, qui était un peu moins expérimenté que moi était à 200 ou 300€ par jour et par personne. Mais c'était aussi des gens qu'on avait pris quasiment à la sortie de l'école (aec un diplôme en physique, ce qui n'est pas un mal mais un chouia moins adapté au taf qu'un en informatique), formé 2/3 semaines et mis chez le client, de l'aveu même des personnes.
Mais sinon, oui, ils étaient en régie de la même façon que moi.
Les tarifs pratiqués pour les prestations varient quand même beaucoup.
[^] # Re: Tarif
Posté par Misc (site web personnel) . En réponse à la dépêche Support à long terme de Debian: une opportunité à ne pas manquer. Évalué à 4.
ce qui est pas si cher en fait pour le nieau de compétences. J'étais facturé par feu ma boite à 800€/j en début de carrière, en régie en Alsace pendant 3 ans. Et quand je vois le tarif des consultants de nos jours, je me dit que soit l'inflation est passé par la, soit j'étais pas si cher que ça.
Ensuite, il faut voir que ça ne vise pas que les travailleurs français, et je pense aussi qu'ils font ça par passion donc sont sans doute prêt à faire une réduction de principe, ce qui explique le prix pas si haut que ça (ça, ou une déformation du à Paris).
# Les chiffres me paraissent un chouia optimistes
Posté par Misc (site web personnel) . En réponse à la dépêche Support à long terme de Debian: une opportunité à ne pas manquer. Évalué à 10.
Y a un certain nombre de trucs qui me laisse songeur
un peu partout.
D'abord, faire une liste privé pour que les boites puissent se retrouver entre elles, ça me parait un peu aller contre la transparence qu'on attends de Debian. Je comprends bien le fait de devoir offrir quelque chose en plus, mais ça fait très "mandrake club", et historiquement, ça n'a super bien marché. À coté, toutes les sociétés commerciales font ça aussi. Je pense qu'une condition pour que ça apporte de la valeur est d'avoir une communauté suffisamment grande et ç'est pas encore le cas. Donc personnelement, je commencerais pas par proposer ça.
Ensuite, le fait d'avoir le droit de soumettre ses propres tests cases me parait aussi curieux. Si le test case est utile à plusieurs personnes, pourquoi ne pas le donner à tous, et le mettre upstream ? Je pense aussi que l'offre ne dit pas clairement quel genre de test case je peux donner (genre, si je dit "voila mon test case, il faut lancer ce benchmark sur 30 machines", ça va être refusé ). Ou ce qui se passe en cas de problème avec le test case, etc, etc. Et il se passe quoi si je paye pas et que je donne un test case, il est pas pris en compte ?
Pareil, direct contact to LTS staff, c'est tendu. Est ce que ça veut dire que les gens qui vont faire le travail ne vont pas avoir leur email publié, ou si c'est le cas, il y a quoi comme avantage par rapport à juste regarder dans l'annuaire ?
Les gens peuvent aussi s'attendre à avoir un SLA, à ce que ça servent de support, etc. Au début, avec des gens qui connaissent le libre, pas de souci, mais si tu veux trouver 50 boites, ça risque de coincer tot ou tard.
J'imagine que je suis pas le premier à poser les questions, mais je vois pas de FAQ dans le site.
[^] # Re: La vraie nouvelle du jour
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 2.
Ouais, mais la, on sort des APIs openstack. Que je sache, la localité des données n'est pas exposé par openstack de manière standard. Ensuite, bien sur, tu peux faire tout ce que tu veux à coté, mais le point, c'est que ç'est à coté :)
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 7.
Genre ça:
http://www.freedesktop.org/software/systemd/man/systemd-run.html
[^] # Re: La vraie nouvelle du jour
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 5.
Pour docker, tu as tout le projet atomic ( http://atomicproject.io/ ). Et par exemple, geard pour l'orchestration, cockpit pour le management, et Red hat a aussi contribué pas mal sur Docker.
Ensuite, le but d'openstack, c'est pas "pour le proprio", même si la virtu sert pas mal à ça. C'est aussi parce que ça offre plus de souplesse. Par exemple, tu peux faire du self service. Tes devs gérent leur bécane et les rendent sans te faire chier. Ou tes environnement de tests/qa/preprod.
Sinon, tu a aussi (tout chaud ce matin, avant c'était proprio) le projet manageiq (http://manageiq.org/).
la, on tape en effet dans le logiciel spécialisé de gestion complète de ton infrastructure cloud. Et je dit bien cloud, et pas IaaS, vu que l'outil fait aussi l'automatisation, la gestion des stats, le cycle de vie complet. l'outil va s'interfacer avec vmware, RHEV, openstack et sans doute à terme d'autres, pour que tu puisses déployer.
Et pour parler de RHEV, son pendant communautaire est ovirt (http://ovirt.org); La, on est dans le concurent à VCenter.
La ou Openstack file des machines jetables sans gestion fine du stockage, de l'endroit ou se trouve chaque machine ou la migration à cahdu, Ovirt gére des systèmes qui ont pas pour vocation d'être jetable. Donc tu peux faire de la migration automatique, tu as un concept de datacenter, etc, etc.
Y a largement de quoi gérer tout un tas de trucs cloud et virtu.
[^] # Re: La vraie nouvelle du jour
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 2.
Tu sais, c'est pas grave, tu peux pas aller vérifier le code sur le ne…. oups, on me dit que si /o\
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 1.
Que je récapitule. Tu as déjà migré tes services de prod en RHEL 7 sorti il y a une semaine, tu as déjà ouvert des tickets entre temps, mais par toi même, tu as pas trouvé les présentations comme
https://events.linuxfoundation.org/sites/events/files/slides/linuxcon.pdf
La doc officiel comme ça :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Resource_Management_and_Linux_Containers_Guide/sec-Modifying_Control_Groups.html
Ou les blogs comme
http://schnouki.net/posts/2013/12/19/resource-control-with-systemd/
Ou la doc de systemd comme :
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
Ensuite, peut être que j'ai mal compris la question, mais globalement, tu peux faire l'ajustement avec un bon vieux sudo et voila.
Sinon, c'est du dbus. Cad que la doc que je trouve sur developpez.com avec google me semble suffisante :
http://yoannsculo.developpez.com/tutoriels/linux/introduction-dbus/#LIV
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Les seuls fois ou tu va te bloquer avec selinux, c'est si tu bascules ton utilisateur dans un mode restreint sans prévoir un login root de secours et sans mettre selinux en permissive. Un peu comme basculer sur ldap sans te laisser un shell root ou ce genre de choses.
Enfin, les histoires de 7% à 15% , je pense que tu parles des audits, pas de selinux. Les 2 sont séparés ( ie, selinux peut tourner sans audit, auditd peut tourner sans selinux ), donc je suis pas sur du coup que tu testes vraiment ce que tu crois tester….
[^] # Re: Libre
Posté par Misc (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 3.
Sinon, y a softwarecollections.org pour les gens qui veulent du communautaire.
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 4.
Je vois pas qui ferait ça ni dans quel intérêt. Des gens qui font des infras ultra complexes, ça existe à la pelle. On a tous croisé des usines à gaz et ce genre de choses, donc je vois pas pourquoi ça ne serait pas la vérité.
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Le souci de Kaane, c'est qu'il monte ses propres architectures qui semble ultra complexes ( du moins, c'est l'impression que j'en retire des pavés et de ce que j'arrive à comprendre dans tout le mix qu'il fait ), qu'il fait des trucs relativement hors des clous ( la, nagios qui relance les services, avant, son histoire de réseau GRE à monter avant TCP/IP, etc ), et qu'ensuite, quand systemd fait la même chose (à savoir la gestion de processus) et que systemd est adopté, ça le bloque dans son architecture.
Mais systemd bloque pas quoi que ce soit, nagios peut parfaitement lancr tout ce qu'il veut soit via service ( et sudo ), soit via l'api DBUS de systemd qui est accessible à des non roots via une configuration standardisé ( vu que c'est le but de dbus ). Point bonus, tu peux contrôler ça via selinux ( ie, dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), ce qui renforce d'autant plus la sécurité et l'isolation qu'il semble vouloir.
Et en fait, l'API dbus est exactement fait pour ça, pour ne pas donner les droits roots mais pour avoir un accès fins aux données. Un project comme cockpit ( http://cockpit-project.org/ ) tire justement parti de ces APIs pour ne pas avoir besoin d'être root.
Je ne doute pas qu'il existe sans doute des vrais soucis, peut être que l'API ne donne pas les accès suffisamment finement pour ce qu'il veut, etc, mais la, les soucis semblent surtout être un mélange de dette technique et d'un manque de clarté dans l'explication du souci.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Je sais pas. Les cgroups sont orthogonaux à l'usage de ptrace. Ptrace sert juste à déterminer quel process doit être le process principal, du moins pour upstart. Mais tu peux t'en passer avec divers options, sauf erreur de ma part. Donc tu pourrais très bien imaginer que upstart se retrouve avec une option "kill cgroups", pour tuer tout les process, et avoir le support de "expect systemd", pour avoir la notification comme systemd, ou "expect pidfile", pour faire comme systemd également.
IE, la modularité est déjà la dans le code pour supporter divers choses à divers niveau, et sans remettre en cause le format.
Ensuite, le format est pourri ( difficilement parsable ), mais ça, c'est une autre histoire. Et je parle du code maintenant, pas de celui d'il y a 5 ans, et peut être que ça change tout aussi.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Les soucis de design n'étaient pas évident. Ni i impossible à corriger. Par exemple, le suivi de processus par cgroups auraient pu être mis dans upstart, le suivi avec ptrace aurait pu être refait ou abandonné. Mais Scott ne voulait pas.
Les parties manquantes dans le code (support ipv6, socket activation correct) aurait aussi pu se rajouter, avec un protocole d'activation mieux foutu.
Par contre, ce qui aurait été dur à corriger, c'est les soucis au niveau du design (genre le fait que les dépendances sont dans l'ordre inverse de ce que tu crois et que la logique interne avec les 'ou' a des résultats surprenants). Et ça, je pense qu'il fallait faire un gros usage avant de le voir.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 8.
Mir, je sais pas, mais upstart m'a intéressé. C'était une amélioration et un changement dans la gestion des processus, ça apportait des idées intéressantes ( le fait d'avoir une manière plus simple de lancer les services, le coté dynamique, le fait d'avoir une API haut niveau ).
Ensuite, l’exécution était défaillante, le CLA a bloqué des boites qui n'ont pas contribué, et Canonical n'a pas vraiment mis les moyens. Mais ça n'a pas empêché Fedora de le prendre en 2008, pour Fedora 9.
RHEL 6 aussi a adopté Upstart (bien qu'avec une intégration très light), mais je pense que c'est au cours des phases finales de RHEL 6 (cad en 2010, au vue du calendrier) que systemd a vu le jour. Le timing n'est à mon avis pas un hasard. Si je peux hasarder une rétrospective:
RHEL 6 sort en novembre 2010.
Systemd sort en avril 2010.
On peut donc supposer que l'idée de faire systemd est né fin 2009, le temps de faire un truc grosso modo potable pour la version 1, et de contacter des gens à gauche et à droite (Lennart a indiqué qu'il avait pris contact avec des mainteneurs d'autre distributions pour récolter les différentes pratiques et je pense que ça prends du temps).
On peut donc supposer que les équipes de RH ont regardé upstart plus en détail durant l'année 2009, et que ça a aboutit au fait que Lennart propose systemd. Il est aussi fort probable que ça soit la raison d'une intégration "light" au contraire d'Ubuntu.
Upstart est sorti en 2006, donc il a fallu 2/3 ans avant que des gens se penchent pour l'intégration ailleurs ( cad globalement après que la techno se soit montré assez viable pour la LTS en avril 2008, à vue de nez ).
Je sais qu'il y a eu des discussions pour prendre ça sur OpenSuse en voyant Fedora, et pareil pour Mandriva. Sauf que Mandriva a implosé en 2010, et que Suse n'a pas suivi, sans doute à cause de la sortie de systemd, et son intégration avec Fedora.
Mais voila, Upstart, sur son principe, a intéressé des gens. Le nokia n9, sorti en 2011, a upstart. On peut supposer que le choix d'upstart s'est fait 3 à 4 ans avant, ce qui montre bien le moment ou upstart a intéressé les gens. D'ailleurs, pareil pour Chromeos, toujours sur upstart, et qui a commencé en 2009 aussi.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Un simple truc comme ça:
Tu peux tenter aussi
Mais dans un cas plus proasaique, je suis pas sur que echo renvoie pas 1 si le tty disparait ( genre, tu tues sshd )
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Linus fait confiance aux divers lieutenants. Par exemple, pour le réseau, David Miller, qui est lui aussi membre de la conspiration au chapeau. J'ai pas réussi à trouver de listes des dit trusted lieutenants ( ce qui est ma foi un peu un manque de transparence ), mais je pense que Ingo Molnar est potentiellement dessus pour la partie RT , pareil, chapeau rouge ). Ou Al Viro.
Donc je pense que si ce qu'on dit est vrai ( à savoir que Linus ne regarde même pas les PR et merge direct ), Linus veille pas tant que ça. Mais bon, ça va, tant que la machine vger.kernel.org n'est pas sous la protection d'un firewall sous le controle de RH, on peut supposer que les gens sont libres.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 7.
Alors, si Canonical a eu les moyens de faire son propre init ( et de continuer à faire son serveur d'affichage, son outil d'orchestration de serveur, son interface graphique et sa pile pour téléphone ), je pense qu'ils ont aussi les moyens de faire mieux, si ils le voulaient. Et Canonical est largement la plus petite des boites restantes à faire des distributions à destination du monde professionnel.
Donc, c'est quoi les moyens requis en terme d'ingénieur ?
2, 3 personnes à temps plein ? Plus, moins ?