Misc a écrit 6321 commentaires

ça veut rien dire, le QG européen de RH est à Munich aussi et que je sache, ça n'a pas eu d'impact.

C'est con, ça tombe pas vraiment au bon moment.

http://www.openworldforum.paris/fr/

30 octobre au 1er novembre

http://www.opencompute.org/community/events/summit/ocp-european-summit-30-31-october-2014

30 au 31 octobre

https://www.openstack.org/summit/openstack-paris-summit-2014/

3 au 7 novembre.

Sans préciser la sémantique que tu mets sur chaque fichier et repertoire, je suis pas sur de te répondre.

Ensuite, empecher, non, pas plus qu'il y a aucune raison technique qui fait qu'on ne puisse pas écrire les fichiers à l'envers. C'est juste qu'il y à un moment des choix à faire ( genre nommer les concepts, etc ). Le but est pas non plus de supporter toutes les syntaxes qu'une personne peut trouver, mais comme dit plus haut, tu peux le faire via les generateurs, c'est comme ça que le support de sysv est fait de nos jours. Le generateur est un soft qui va lire chaque fichier sysv init et faire une unité systemd à la volée dans /run lors du démarrage. Donc tu peux faire ta syntaxe et la convertire au format que systemd attends sans souci.

En fait, c'est assez simple.

Un des soucis non résolu de sysvinit etait le fait que tout etait dans /etc/init.d, marqué (dans les distributions rpms) comme fichier de configuration. Et donc, la moindre modif impliquait de perdre le nouveau fichier à l'update et donc de passer à coté de corrections de bugs ( parfois ).

Avec l'utilisation d'un fichier declaratif à la place d'un fichier qui est un script, on peut mettre au point un algo de fusion de 1 ou plusieurs fichiers servent à décrire une unité de ta configuration ( genre un service, etc, unité au sens large, pas au sens systemd )

Du coup, on peut faire la chose suivante. Dans un repertoire, tu as le fichier fourni par upstream ( distribution, etc ) et dans un autre, tu as le fichier modifié par l'admin. Tu peux faire ça en ecrasant le fichier ( cad toto.service dans les 2 ) et on prends que le fichier de l'admin. Ou on peut utiliser la drop-in configuration, cad faire un repertoire toto.service.d/ avec un fichier foo.conf qui contient un fragment du fichier, et on fusionne les 2 clés par clé, en donnant la priorité à la clé dans le repertoire pour l'admin. Par exemple, je veux rajouter PrivateTmp=yes sur un service, je peux, et de tel sorte que ça soit résistant à l'upgrade, visible ( cad via ls, ou juste via les commandes comme systemctl ) et "config management friendly" ( vu qu'il s'agit juste de déposer un fichier dans un repertoire ).

Du coup, tu as /etc/systemd/system , /usr/lib/systemd/system et /run/systemd/system/ . La section "Unit Load path" de la page de man systemd.unit(5) explique les régles de priorités.

Ils iront vers ce qui coutent le moins cher afin de garder des tarifs compétitifs, oui. Faut bien se rendre compte que kimsuft et dedibox sont pas cher grace à ça, et que une procédure judiciaire, ça coute en frais d'avocat et en temps perdu.

Tu confonds pas l'ile de man et les bahamas ?

En fait, l'inspiration est le format utilisé pour les fichiers .desktop ( http://standards.freedesktop.org/desktop-entry-spec/latest/ ), lui même inspiré du format de fichier .ini qu'on retrouve à beaucoup à l'époque de windows 3.11, et qui, d'aprés wikipedia, trouve ses origines dans windows 1.0.

C'est un format qui est nativement compris par pas mal de language ( python, perl, etc ), avec des implémentations matures, et facile à comprendre par la plupart des gens ( au contraire de json ou yaml qui requiert de comprendre la syntaxe un minimum ). Ceci dit, si ça ne te plait pas, tu peux toujours utiliser un generateur qui va convertir les unités d'un format de ton choix vers ce que systemd comprends.

Je suis sur que tes critiques seraient prises plus au sérieux sans l'usage de terme comme merdique, cochonneries et usine à gaz, et surtout avec un truc plus précis que "une syntaxe qui fait mal aux yeux", car je doute franchement que ça soit une description litéral de ce qui t'arrive. Je suis sur qu'on peut te mettre dans un ORM et vérifier qu'aucun centre de la douleur n'est activé par la syntaxe, et qu'il s'agit juste d'une métaphore, ce qui n'aide pas vraiment le propos de part son imprecision.

Je sais pas comment mesuré "plus dur". Par exemple, est ce que comptable est plus dur qu'ingénieur ? Est ce que pompier est plus dur ?

Je suis d'accord qu'il y a plein de métier mal payé et mal valorisé par rapport à ce que j'estime qu'il devrait être payé, mais y a aussi plein de cas ou ça marche. Par exemple, je pense qu'un consultant est mieux payé parce qu'il bouge sans arret par rapport à moi, pour ne citer qu'un exemple personnel. Qu'un commercial est mieux payé pour les mêmes raisons. Ensuite oui, je suis sur qu'un pompier qui risque sa vie gagne moins que moi, ou un soldat pour l'exemple ( même si je pense qu'un pompier est mieux payé qu'un flic qui fait la circulation ).

Mais le fait est qu'une partie du salaire, en plus de la rareté, viens aussi du taf lui même. En tant qu'ingé, je suis payé plus cher parce que je fait pas du 8h/17h, et un chef est payé plus cher pour se faire crier dessus.

Mais oui, on peut pas tout comparer directement, c'est une simplification mal venu de ma part.

Pour le frontend, y a packagekit. Pour les paquets, c'est plus dur. Je serait pour le fait de refaire le format spec ou celui de debian, mais c'est un autre débat.

Au dela de ça, des questions comme :

• est ce que va t'intégrer avec tel techno par defaut. Exemple, apparmor/selinux.

• est ce que tu va par défaut ne rien lancer ( ie, j'installe apache, et je doit penser à le lancer par défaut ) vs ne pas avoir à le faire.

• est ce que j'autorise le fait de mettre en bundle du code est autorisé ou pas, car ça va rendre la gestion de la sécurité plus compliqué

Des choix d'intégration, y en a plein qui sont fait et qui doivent être fait, avec plus ou moins d'impact. Le fait d'avoir ou pas tel systéme d'init est un de ces choix par exemple.

Et franchement, si les gens voulaient moins de diversité, ils passeraient pas de temps à faire des distributions. Il faut bien voir que dans l'état des choses, il y a besoin de plus de personne pour faire un systéme complet que pour faire un composant du systeme, et qu'il y a infiniment moins de systéme d'init que de distributions; Donc je ne peux que supposer que la demande en diversité au niveau des distributions Linux est plus grande qu'au niveau des inits, malgré les demandes à corps et à cris de certains, vu que ça ne débouche sur rien.

Je suis pas d'accord que le DIF soit uniquement pour une reconversion, le site du gouvernement n'en parle pas dans ces termes.

Ensuite, si tu estimes avoir droit à une formation (ce qui est quand même ce que je comprends du thread), tu as en effet le droit d'utiliser le DIF, le D voulant dire droit. La question ensuite est de savoir si les évolutions inhérentes à ton métier ( car bon, les métiers évoluent, certaines évoluent beaucoup plus que d'autres ) rentrent dedans ou pas.

E.g., le souci, c'est que tu voudrais puet être avoir droit à plus de formation que ce qu'on estime que tu as le droit d'avoir car tu t'estimes lésé d'avoir à utiliser ton DiF sur des trucs que tu voudrait pas forcément apprendre pour garder ta liberté.
Par exemple tu voudrais pouvoir avoir le droit à tes 5j sur RHEL 7 et tes 5 jours sur la patisserie.

Bien sur, il serait à ce moment la mal venu de rappeler l'inégalité salariale entre un ingénieur moyen et un métier moins payé, et rappeler aussi qu'avec le salaire, il y a des contraintes plus fortes ( pression, responsabilité pour ne citer que les plus flous, mais prises de risques physiques, déplacement tout les jours pour en citer d'autres ).

Du coup, si tu estimes que la situation est pas normal, c'est un peu tard pour corriger ça dans ton contrat, mais suffisament tot pour le prochain, et suffisament pour les contrats des autres. Donc tu peux inciter les gens à:
- demander plus d'argent
- mettre dans le contrat explicitement une clause de formation

Et si ça t'inmporte vraiment ( cad si tu es prêt à faire plus qu'un poste sur linuxfr ), tu peux soit aller dans un syndicat, ou faire de la communication autour du probléme.

Ou faire comme moi, répondre à des annonces sur des postes, passer les entretiens, et refuser de signer si on te file pas la clause que tu veux, histoire que ça rentre dans l'esprit des gens ( comprendre des recruteurs au sens large ) qu'il y a une demande pour ce genre de choses, et que le prochain qui demande ne soit qu'un parmi tant d'autres, et qu'on le regarde pas de travers. Tu peux même faire ça sur des jobs que tu aimes pas si tu es déja en poste ( genre postuler dans divers SSII ). Et si il te file la clause, demande plus de thunes. Et à la fin, tu peux toujours t'en sortir par un "mon patron m'a augmenté pour que je reste, donc je reste la ou je suis".

Techniquement, tes connaissances, tu les gardent pour toi, libre à toi de les utiliser ou pas pour ton taf.

Quand tu quittes la boite, elles sont encore avec toi, donc je pense pas que tu les donnes.

Si maintenant, ton souci, c'est que tu estimes ne pas être assez payer pour ça, pas de souci, mais dit le clairement, tu veux plus de sous. Y a rien de mal à ça, faut arreter de se sentir complexer à l'idée d'aller frontalement contre son patron sur le sujet.

Et si l'idée est que tu travailles trop, alors ça devient la même equation, cad que tu estimes que tu voudrait bosser moins pour la même paye, donc que tu veux une augmentation suivi d'une réduction du temps de travail.

Faut croire qu'il y a une bonne raison.

Mais oui, la conspiration du complexe militaro industrial de la NSA et de RH qui prends en otage les utilisateurs en rendant le code plus obscures afin de faciliter l'emergence de faille pour rajouter des GPS dans ton alimentation, ou un truc comme ça.

Fait un kickstarter et à toi le pognon. Au contraire de la pétition demandant à lennart d'arrêter de coder, avec quasiment personne qui a signé…

Je pense que Centos aurait suivi RHEL avec ou sans le fait d'avoir des salariés de RH, parce que c'est la raison d'être de la distribution.

Et je pense que si qui que ce soit de compétent et motivé l'aurait voulu, il aurait fait sa distro sans systemd, et les gens l'aurait suivi si il y avait vraiment un interet fort, et des avantages.

Comme c'est pas arrivé, soit les gens qui ralent sont pas prêt à mettre la main à la patte, soit ils sont pas assez nombreux.

Visiblement, le souci n'est pas de changer ou pas, vu que si les gens prennent une version récente, ils veulent du changement.

Non, mais centos 6 est encore maintenu.

Non, la procédure normale en sécurité est d'arrêter la machine
vérolée, et d'assurer la continuité de service à partir d'un
état que l'on sait sain. Pas de continuer avec une machine
potentiellement vérolée qu'on n'a pas audité.

Pas forcément. D'une part, arreter la machine va détuire les processes en cours et donc des informations potentiellement intéressante.

Ensuite, le but est aussi d'assurer la continuité du service si possible. Dans le cas d'une banque, la perte en réputation est tel que tu peux difficilement prendre le risque que la machine soit vérolé. Dans le cas de linuxfr et aux vues des réactions des gens icis, ils estiment que la continuité passe avant tout. C'est leur droit, et visiblement, entre couper tout linuxfr ou couper à minima et fouiller aprés, ils ont choisi.

Bien sur, tu peux faire un choix différent, mais c'est eux les admins et le concept de responsabilité fait qu'ils ont toute latitude dans le fait de choisir en ignorant ou pas tes arguments.

Perso, c'est pas forcément ce que je voudrais. Moi, j'aime bien avoir un truc intégré avec des gens qui vérifient et qui font pas n'importe quoi et n'importe comment. Je voit bien par exemple comment ça se passe sur les différentes applis android bourré de pub, etc.

Je peux comprendre que des gens veulent ça et je m'oppose pas à la techno ou à laisser le choix pour ceux qui ont moins bons gouts que moi, mais ça me dérange pas que ça ne soit pas déjà le cas, loin de la.

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/ )

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 :)

Tu parles de Canonical ?

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.

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.