Je sais pas si systemd y réponds, et si un outil d'orchestration plus classique, voir juste un makefile ferait pas l'affaire par contre.
Un script maitre marcherais, mais je pense que l'idée est aussi d’intelligemment reprendre si ça s'arrête à un moment, ce qui est pas une chose qu'une simple exécution à la suite ferait. Ensuite, peut être que c'est overkill, et qu'il faudrait donc un outil plus spécialisé.
C'est pas tant systemd en tant que tel que le fait que logind gére la session ( cad s'assure que les accés sont revoqués quand il y en a plus besoin, etc ). Ensuite la question est pourquoi logind a besoin de systemd, et pourquoi personne n'a fait ça avant.
Logind a besoin d'un système qui va gérer les sessions de manière fiable ( cad sans fuite de process hors de la session ), et il se trouve que c'est l'un des points fort de systemd, cad via les cgroups. À son tour, la gestion des cgroups, pour être propre, requiert d'avoir un seul process qui gére ça ( histoire que l'état ne change pas sous nez et avec des races conditions ). A son tour, la gestion des process requiert d'avoir un PID1 qui est au courant du fait qu'il y a des cgroups pour les process. Soit il gére ça lui même ( ce que fait systemd ), soit il fait faire ça par un autre process ( ce que upstart aurait fait ).
Les devs de systemd est que pour éviter les races conditions et la fiabilité, c'est plus simple de faire ça dans un seul processus que dans 2 ( vu qu'il y a des délais, potentiellement des communications asynchrones, du code pour communiquer entre les 2 processus, et du code dans le premier pour relancer le 2eme, avec le code du 2eme pour relancer ce qu'il lance lui même, etc ). Donc c'est comme ça qu'on se retrouve avec logind qui a besoin de systemd, et systemd qui se retrouve avec le pid 1.
Je suis sur qu'on aurait pu le faire avant, mais si les premiers trucs au sujet de X sans root date de 2008 ( https://airlied.livejournal.com/59521.html ) et qu'il a fallu 6 ans pour faire les derniers pas, peut être que c'était pas si simple à faire de manière propre.
C'est un peu un argument d'autorité. Ce n'est probablement pas
un très bon outil pour un grand parc, mais pour quelques
machines et un client mail un peu valable, c'est un outil de
notification assez satisfaisant. Sur un gros domaine, tu va
utiliser des outils de supervisions qui vont bien (et dans ce
cas là, tu peux utiliser logger(1)).
Ou juste utiliser cronie, qui loggue dans syslog si y a pas de MTA ( ce qui me semble pas déconnant d'un point de vue de l'unification, cad "tout va au même endroit pour les logs" ). C'est aussi un des points de journald, tu as tout dans le journal, tu as donc un endroit à traiter. Ensuite, tu rajoutes les notifications sur la base des entrées consolidés, plutôt que d'avoir la notif pour cron mais pas pour le reste, etc.
Bien que ça reste plus abscons que le dire à voix haute, je continue de penser que c'est plus lisible.
Primo, le nom du jour est clairement visible. C'est pas idéal vu que je continue à me planter entre Thursday et Tuesday, mais bon, je peux imaginer que c'est toujours mieux que 2.
Deuzio, ben 10:00/5, on voit aussi que c'est à 10h.
Trimo, 00/5, bien que ça soit pas forcement intuitif, ça reste plus simple de voir que le pas de 5 s'applique sur les minutes.
Sinon,
Par contre, s'il est possible gérer des dépendances entre les
jobs
Cad, les dépendances sur les jobs ? Activé un premier job quand le 2eme se termine ? Je suis pas sur que ça se fasse, mais c'était le concept d'upstart.
mais tu peux regarder Requires= et After= dans la doc de systemd, et tester ça ( une VM et hop ).
d'éviter qu'un script ne se lance tant qu'il est en cours
d’exécution
Le timer active un service, donc c'est de base. Mais je testerais ma théorie, car j'ai jamais fait.
de tuer une tâche qui prends trop de temps
C'est faisable, tu mets TimeoutStartSec= dans le service que le timer active. Et si il tourne encore après ce temps sans avoir signaler d'avoir fini, alors il se fait tuer ( et la tache rentre en failed ). Ceci dit, ç'est peut être pas aussi simple, il faut peut être aussi rajouter des choses avec SuccessExitStatus=
Le souci n'est pas le shell pour des scripts rapides. Je fait aussi beaucoup de shell, parce que c'est rapide de torcher un truc de façon incrémental.
Le souci, c'est dire que le shell est génial pour monter un gros truc alors que :
c'est lent ( faut assez souvent faire des forks, ce qui a un cout certes sans doute invisible sur nos machines surpuissante, sans doute plus quand tu veux démarrer vite une VM ou un containeur ), l'interpréteur bash est pas vraiment optimisé pour ça, même si il semble que dash s'en sorte mieux.
les primitives de traitement sont quand même loin de l'idéal sur autre chose que des lignes. IE, on oublie des structures de haut niveau ( alors que pour openrc, on voit qu'il y a clairement un semblant d'orientation objet avec le fait d'avoir une fonction start, une stop, etc, mais que le shell ne le permet pas ). C'est sur que pour de l'analyse de texte et des ones liners, ça passe. Pour enchainer des commandes que tu aurais taper à la main, ouais. Au dela, mhh bof.
qu'il y a une syntaxe un peu baroque ( test vs [ , < vs -lt, etc ) et surtout le besoin de compenser avec des commandes qui sont pas unifiés.
qu'il y a pas les features "modernes" comme un espace de nommage, ou les threads. Même les primitives unix sont pas la. Tu as vaguement les signaux, mais les sémaphores, tu oublies, Creation de fichier temporaire, y a toujours un maigre risque de race condition ( entre le moment ou le fichier est ouvert et le moment ou il est crée, même si en pratique, j'ai du mal à voir un cas ou ça importe ), etc. Les APIs posix, tu as en général pas accès ( et parfois, c'est distro dépendant, genre les sockets qui sont pas activés sur Debian ).
qu'il y a fort peu de libs de test, et que ça rentre pas dans les habitudes des gens qui font du bash ( je sais que c'est faisable, c'est juste que ça rentre pas dans les pratiques usuels )
l'outillage est assez pauvre. La ou des langages comme perl ou python offre divers débuggeurs, profileurs, analyseurs, bash offre un débuggeur qui est dans un état de maintenance, en dehors du projet principal et globalement, c'est tout ce qui existe d'à peu prés avancer ( ça, et set -x, et globalement, la plupart des langages de script le propose aussi, comme rappelé sur http://rigaux.org/language-study/scripting-language/ ).
Encore une fois, tu peux faire un truc qui marche sur un coin de table pendant 5 minutes, je le fait assez souvent. Tu peux même en faire plein. Et je suis sur que tu peux faire tout un tas de trucs.
Mais si tu veux faire un truc qui va tenir plus longtemps et plus gros, je pense ( tu as le droit de pas être d'accord ) que c'est mieux de faire autre chose que du shell ( ça veut pas dire que tu va pas faire de la merde en perl, en python, en C ou autre non plus ). Le système d'init d'une distribution est le seul exemple qui me vient en tête de gigantesque code linbre en shell ( le build system de Mandrake étant le deuxième, et les gros bouts d'openshift étant le 3eme ).
Ensuite, tu as le droit d'en faire, personne t'interdit si ça te va. J'ai aussi un collègue qui en fait tout le temps, il m'écoute pas, et il le vit très bien.
Roh, soit pas aigri, ça arrive de faire une erreur. C'est du shell, c'est rempli de surprise, c'est juste une raison de plus de pas l'utiliser.
La prochaine fois, c'est simple, je te conseille plutôt ce snippet
[ 1 -gt $(ps h -C vim | wc -l) ] && exit 1;
Déjà, ça corrige le souci que tu as eu. Ensuite, c'est plus lisible de faire 1 -gt, plutôt que le 2 qui va induire les gens en erreurs. Et il vaut mieux utiliser $( ), car tu peux les imbriquer sans souci.
Ensuite, la page de man de ps en francais semble être en retard ( et je pense que tout le monde ne parle pas anglais ).
Et j'ajouterais aussi que les options de ps sont non portables entre Linux et Freebsd, et je suis sur que le layout de /proc est aussi hautement dépendant du systéme.
Je veux pas faire mon chieur, mais ton script va du coup bloquer si quelqu'un d'autre lance un programme et lui fait se renommer pour matcher ton nom de script. C'est un peu naze d'un point de vue sécurité, ça me ferait chiez que mes backups via backup.sh soit bloqué parce qu'un utilisateur s'amuse à lancer un autre backup.sh qui plante ( ou qui tourne dans le vide pour me faire chier ).
Je suis d'accord, ça fait longtemps que le libre s'est profesionnalisé.
Quand je vois le tarif d'entrée de LinuxCon, de l'openstack summit à Paris ou de Pycon à Montreal ( cad dans les 600$ pour les 2 derniers ), je me dit que ç'est pas trés communauté friendly. Faut avoir une boite qui paye pour l'entrée, sinon, c'est pas possible.
Non, mais tu es serieux ? Tu penses vraiment que c'est redhat
qui pousse systemd ? C'est une blague ???
Non je le pense pas. Je tente juste de troller albert sur son sempiternel discours à base "tout ce que fait RH est pourri, tout ce ui est pas RH est génial" en rappelant que la réalité est vachement plus nuancé.
je pense que c'est plus une question d'intuitivité de la chose. La syntaxe de cron est simple pourles cas simples ( @hourly ), et vite imbittables pour les cas compliqués.
Exemple :
*/5 10 * * 2 /usr/local/bin/yourjob Ça fait quoi ?
L'auteur de wayland l'a commencé quand il etait chez RH. Et actuellement, les gens qui poussent wayland sur gnome sont aussi chez RH ( même si jasper st pierre est parti chez Endless ).
Je pense que tu es mal informé, mais c'est pas grave, tu peux quand même avoir une opinion sur une base non factuelle.
Je me suis retrouvé à devoir "forker" le projet (sur le site web
seulement), modifier mon .git/config pour ajouter mon remote,
pousser mes commits, retourner sur le site, et finalement faire
une demande de pull (on peut même pas faire une demande par
commits, mais pour tous les commits d'une branche donné. Uh?!).
Tu sais, y a des gens qui font du libre sur autre chose que leur temps libre :)
mais sinon, pour ce que je contribue ( en dehors de ce que je fait parce que j'aime ça et parce que ça me permet de financer mon dispendieux style de vie de playboy ), il y a le coté "résoudre ses problémes" et la prise d'autonomie que ça represente.
Et quand tu regardes la litérature sur le sujet, les gens citent souvent un livre de Daniel Pink qui explique que la motivation vient de 3 choses, L'autonomie ( autonomy ), le fait d'avoir un but ( purpose ) et l'expertise/maitrise ( mastery ). Et en effet, on retrouve plus ou moins ça dans les contributions au logiciel libre, d'une façon ou d'une autre.
Ensuite, le livre est assez récent, donc je ne saurait dire si c'est vrai ou pas, même si je reconnais que ça colle pas mal à mon expérience personnel.
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.
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.
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.
[^] # Re: en fait DEUX raccourcis clavier
Posté par Misc (site web personnel) . En réponse au sondage Pour éteindre/redémarrer mon ordinateur, j'utilise.... Évalué à 3.
Non, tu peux aussi utiliser H + alt, ça arrête le pc :p
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 3.
Je vois l'usage.
Je sais pas si systemd y réponds, et si un outil d'orchestration plus classique, voir juste un makefile ferait pas l'affaire par contre.
Un script maitre marcherais, mais je pense que l'idée est aussi d’intelligemment reprendre si ça s'arrête à un moment, ce qui est pas une chose qu'une simple exécution à la suite ferait. Ensuite, peut être que c'est overkill, et qu'il faudrait donc un outil plus spécialisé.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 10.
La réponse est sur https://hansdegoede.livejournal.com/14268.html
C'est pas tant systemd en tant que tel que le fait que logind gére la session ( cad s'assure que les accés sont revoqués quand il y en a plus besoin, etc ). Ensuite la question est pourquoi logind a besoin de systemd, et pourquoi personne n'a fait ça avant.
Logind a besoin d'un système qui va gérer les sessions de manière fiable ( cad sans fuite de process hors de la session ), et il se trouve que c'est l'un des points fort de systemd, cad via les cgroups. À son tour, la gestion des cgroups, pour être propre, requiert d'avoir un seul process qui gére ça ( histoire que l'état ne change pas sous nez et avec des races conditions ). A son tour, la gestion des process requiert d'avoir un PID1 qui est au courant du fait qu'il y a des cgroups pour les process. Soit il gére ça lui même ( ce que fait systemd ), soit il fait faire ça par un autre process ( ce que upstart aurait fait ).
Les devs de systemd est que pour éviter les races conditions et la fiabilité, c'est plus simple de faire ça dans un seul processus que dans 2 ( vu qu'il y a des délais, potentiellement des communications asynchrones, du code pour communiquer entre les 2 processus, et du code dans le premier pour relancer le 2eme, avec le code du 2eme pour relancer ce qu'il lance lui même, etc ). Donc c'est comme ça qu'on se retrouve avec logind qui a besoin de systemd, et systemd qui se retrouve avec le pid 1.
Je suis sur qu'on aurait pu le faire avant, mais si les premiers trucs au sujet de X sans root date de 2008 ( https://airlied.livejournal.com/59521.html ) et qu'il a fallu 6 ans pour faire les derniers pas, peut être que c'était pas si simple à faire de manière propre.
[^] # Re: Complément & commentaires
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 2.
Ou juste utiliser cronie, qui loggue dans syslog si y a pas de MTA ( ce qui me semble pas déconnant d'un point de vue de l'unification, cad "tout va au même endroit pour les logs" ). C'est aussi un des points de journald, tu as tout dans le journal, tu as donc un endroit à traiter. Ensuite, tu rajoutes les notifications sur la base des entrées consolidés, plutôt que d'avoir la notif pour cron mais pas pour le reste, etc.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 5.
Tue 10:00/5Bien que ça reste plus abscons que le dire à voix haute, je continue de penser que c'est plus lisible.
Primo, le nom du jour est clairement visible. C'est pas idéal vu que je continue à me planter entre Thursday et Tuesday, mais bon, je peux imaginer que c'est toujours mieux que 2.
Deuzio, ben 10:00/5, on voit aussi que c'est à 10h.
Trimo, 00/5, bien que ça soit pas forcement intuitif, ça reste plus simple de voir que le pas de 5 s'applique sur les minutes.
Sinon,
Cad, les dépendances sur les jobs ? Activé un premier job quand le 2eme se termine ? Je suis pas sur que ça se fasse, mais c'était le concept d'upstart.
mais tu peux regarder Requires= et After= dans la doc de systemd, et tester ça ( une VM et hop ).
Le timer active un service, donc c'est de base. Mais je testerais ma théorie, car j'ai jamais fait.
C'est faisable, tu mets TimeoutStartSec= dans le service que le timer active. Et si il tourne encore après ce temps sans avoir signaler d'avoir fini, alors il se fait tuer ( et la tache rentre en failed ). Ceci dit, ç'est peut être pas aussi simple, il faut peut être aussi rajouter des choses avec SuccessExitStatus=
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 10.
Le souci n'est pas le shell pour des scripts rapides. Je fait aussi beaucoup de shell, parce que c'est rapide de torcher un truc de façon incrémental.
Le souci, c'est dire que le shell est génial pour monter un gros truc alors que :
c'est lent ( faut assez souvent faire des forks, ce qui a un cout certes sans doute invisible sur nos machines surpuissante, sans doute plus quand tu veux démarrer vite une VM ou un containeur ), l'interpréteur bash est pas vraiment optimisé pour ça, même si il semble que dash s'en sorte mieux.
les primitives de traitement sont quand même loin de l'idéal sur autre chose que des lignes. IE, on oublie des structures de haut niveau ( alors que pour openrc, on voit qu'il y a clairement un semblant d'orientation objet avec le fait d'avoir une fonction start, une stop, etc, mais que le shell ne le permet pas ). C'est sur que pour de l'analyse de texte et des ones liners, ça passe. Pour enchainer des commandes que tu aurais taper à la main, ouais. Au dela, mhh bof.
qu'il y a une syntaxe un peu baroque ( test vs [ , < vs -lt, etc ) et surtout le besoin de compenser avec des commandes qui sont pas unifiés.
qu'il y a pas les features "modernes" comme un espace de nommage, ou les threads. Même les primitives unix sont pas la. Tu as vaguement les signaux, mais les sémaphores, tu oublies, Creation de fichier temporaire, y a toujours un maigre risque de race condition ( entre le moment ou le fichier est ouvert et le moment ou il est crée, même si en pratique, j'ai du mal à voir un cas ou ça importe ), etc. Les APIs posix, tu as en général pas accès ( et parfois, c'est distro dépendant, genre les sockets qui sont pas activés sur Debian ).
qu'il y a fort peu de libs de test, et que ça rentre pas dans les habitudes des gens qui font du bash ( je sais que c'est faisable, c'est juste que ça rentre pas dans les pratiques usuels )
l'outillage est assez pauvre. La ou des langages comme perl ou python offre divers débuggeurs, profileurs, analyseurs, bash offre un débuggeur qui est dans un état de maintenance, en dehors du projet principal et globalement, c'est tout ce qui existe d'à peu prés avancer ( ça, et set -x, et globalement, la plupart des langages de script le propose aussi, comme rappelé sur http://rigaux.org/language-study/scripting-language/ ).
Encore une fois, tu peux faire un truc qui marche sur un coin de table pendant 5 minutes, je le fait assez souvent. Tu peux même en faire plein. Et je suis sur que tu peux faire tout un tas de trucs.
Mais si tu veux faire un truc qui va tenir plus longtemps et plus gros, je pense ( tu as le droit de pas être d'accord ) que c'est mieux de faire autre chose que du shell ( ça veut pas dire que tu va pas faire de la merde en perl, en python, en C ou autre non plus ). Le système d'init d'une distribution est le seul exemple qui me vient en tête de gigantesque code linbre en shell ( le build system de Mandrake étant le deuxième, et les gros bouts d'openshift étant le 3eme ).
Ensuite, tu as le droit d'en faire, personne t'interdit si ça te va. J'ai aussi un collègue qui en fait tout le temps, il m'écoute pas, et il le vit très bien.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 5.
En effet, ça ne fait que renforcer mon point, c'est dur de faire du shell qui marche :)
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 4.
Roh, soit pas aigri, ça arrive de faire une erreur. C'est du shell, c'est rempli de surprise, c'est juste une raison de plus de pas l'utiliser.
La prochaine fois, c'est simple, je te conseille plutôt ce snippet
Déjà, ça corrige le souci que tu as eu. Ensuite, c'est plus lisible de faire 1 -gt, plutôt que le 2 qui va induire les gens en erreurs. Et il vaut mieux utiliser $( ), car tu peux les imbriquer sans souci.
[^] # Re: Intéressant tes critiques sur le shell
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 2.
Ensuite, la page de man de ps en francais semble être en retard ( et je pense que tout le monde ne parle pas anglais ).
Et j'ajouterais aussi que les options de ps sont non portables entre Linux et Freebsd, et je suis sur que le layout de /proc est aussi hautement dépendant du systéme.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 9.
Je veux pas faire mon chieur, mais ton script va du coup bloquer si quelqu'un d'autre lance un programme et lui fait se renommer pour matcher ton nom de script. C'est un peu naze d'un point de vue sécurité, ça me ferait chiez que mes backups via backup.sh soit bloqué parce qu'un utilisateur s'amuse à lancer un autre backup.sh qui plante ( ou qui tourne dans le vide pour me faire chier ).
Donc je confirme en effet "sans trop reflechir"
[^] # Re: En ce qui concerne tes interrogations métaphysiques...
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 9.
Je suis d'accord, ça fait longtemps que le libre s'est profesionnalisé.
Quand je vois le tarif d'entrée de LinuxCon, de l'openstack summit à Paris ou de Pycon à Montreal ( cad dans les 600$ pour les 2 derniers ), je me dit que ç'est pas trés communauté friendly. Faut avoir une boite qui paye pour l'entrée, sinon, c'est pas possible.
[^] # Re: Il a le mérite de bien vendre sa "came".
Posté par Misc (site web personnel) . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 3.
C'est rien, tu as loupé "systemd apporte l'apocalypse"
http://www.infoworld.com/d/data-center/systemd-harbinger-of-the-linux-apocalypse-248436?page=0,0
J'ai presque l'impression de voir une parodie de foxnews.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 7.
Non je le pense pas. Je tente juste de troller albert sur son sempiternel discours à base "tout ce que fait RH est pourri, tout ce ui est pas RH est génial" en rappelant que la réalité est vachement plus nuancé.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 8.
je pense que c'est plus une question d'intuitivité de la chose. La syntaxe de cron est simple pourles cas simples ( @hourly ), et vite imbittables pour les cas compliqués.
Exemple :
*/5 10 * * 2 /usr/local/bin/yourjob
( la réponse est dans
http://linuxfr.org/nodes/101472/comments/1527821 )
Il y a une courbe d'apprentissage assez raide quand même.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . En réponse au journal Sur systemd, btrfs & co. Évalué à 5.
L'auteur de wayland l'a commencé quand il etait chez RH. Et actuellement, les gens qui poussent wayland sur gnome sont aussi chez RH ( même si jasper st pierre est parti chez Endless ).
Je pense que tu es mal informé, mais c'est pas grave, tu peux quand même avoir une opinion sur une base non factuelle.
[^] # Re: Pour ma gueule, et je partage ensuite
Posté par Misc (site web personnel) . En réponse au journal Pourquoi je contribue ?. Évalué à 2.
Sinon, y a hub pour faire ça en cli
https://hub.github.com/
( et y a sans doute des paquets pour les distros )
[^] # Re: Pour le plaisir
Posté par Misc (site web personnel) . En réponse au journal Pourquoi je contribue ?. Évalué à 9.
ça commence par p et ça finit par ython.
# Et le temps pas libr e?
Posté par Misc (site web personnel) . En réponse au journal Pourquoi je contribue ?. Évalué à 6.
Tu sais, y a des gens qui font du libre sur autre chose que leur temps libre :)
mais sinon, pour ce que je contribue ( en dehors de ce que je fait parce que j'aime ça et parce que ça me permet de financer mon dispendieux style de vie de playboy ), il y a le coté "résoudre ses problémes" et la prise d'autonomie que ça represente.
Et quand tu regardes la litérature sur le sujet, les gens citent souvent un livre de Daniel Pink qui explique que la motivation vient de 3 choses, L'autonomie ( autonomy ), le fait d'avoir un but ( purpose ) et l'expertise/maitrise ( mastery ). Et en effet, on retrouve plus ou moins ça dans les contributions au logiciel libre, d'une façon ou d'une autre.
https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motivates_Us
Ensuite, le livre est assez récent, donc je ne saurait dire si c'est vrai ou pas, même si je reconnais que ça colle pas mal à mon expérience personnel.
[^] # Re: Interopérabilité
Posté par Misc (site web personnel) . En réponse au journal Munich ferait marche arrière. Évalué à 4.
ça veut rien dire, le QG européen de RH est à Munich aussi et que je sache, ça n'a pas eu d'impact.
# En même temps que l'OWF, juste avant l'openstack summit
Posté par Misc (site web personnel) . En réponse au journal Open Compute Project: Premier séminaire Européen en France, cocorico ?. Évalué à 2.
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.
[^] # Re: Par curiosité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd pour les administrateurs, partie 1 et 2. Évalué à 7.
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.
[^] # Re: Par curiosité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd pour les administrateurs, partie 1 et 2. Évalué à 10.
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.
[^] # Re: GlobeNet
Posté par Misc (site web personnel) . En réponse au journal Les serveurs situés à l'étranger et la loi. Évalué à 2.
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.
[^] # Re: Compétence de la justice française
Posté par Misc (site web personnel) . En réponse au journal Les serveurs situés à l'étranger et la loi. Évalué à 3.
Tu confonds pas l'ile de man et les bahamas ?
[^] # Re: Formation
Posté par Misc (site web personnel) . En réponse à la dépêche systemd pour les administrateurs, partie 1 et 2. Évalué à 10.
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.