Ça tombe bien l'usage du mot débauche a lui aussi évolué à travers les siècles pour ne plus avoir une connotation exclusivement sexuelle.
Personne ne se masturbe en consultant /r/earthporn. Enfin si il y'en a sûrement 1 ou 2 qui ont ce genre de délire parce qu'il y'a toujours quelqu'un pour avoir des idées plus tordues que les autres mais là on peut pas lutter.
Parce que, pour rappel, « porn » ça désigne des représentations très graphiques et concrètes d’actes sexuels. Ça n’est pas un suffixe qui veut dire « qui est agréable à voir ». Ça serait d’ailleurs bien que les différentes communautés sur reddit s’en rendent compte. Foodporn, unixporn, etc… Le jour où quelqu’un voudra faire un subreddit avec des photos d’enfants mignons, ils vont l’appeler /r/childporn ?
Ce n'est pas du tout lié ni limité à reddit. C'est tout simplement tombé dans le language commun dans les pays anglo-saxons et l'utilisation de porn en tant que suffixe est maintenant décorrélé de la signification et connotation sexuelle du mot seul. Alors certe parler de childporn serait très maladroit mais je pense que tout le monde en est conscient.
Je dis ça et je ne suis pas très fan de cet usage mais bon c'est l'évolution du language, tu ne peux pas y faire grand chose.
Quand je vois la difficulté qu'ont les appareils gps à donner des valeurs fiables en terme d'élevation pour des sorties à vélo, j'ai du mal à croire qu'on arrive à avoir des valeurs pertinentes en parapente. En tout cas quand je vois les parapentistes locaux qui font des figures avec des chutes assez rapides en toupie à mon avis le GPS serait perdu.
Ouais enfin le test en lien avec ce journal concerne des ssd dédiés à un usage desktop donc ce n'est pas hyper pertinent par rapport à une utilisation pro avec du matériel dédié à un usage i/o intensif.
967MB ça fait quand même beaucoup quand on compare aux roms de Devil Crush / Devil Crash qui font respectivement 205kB (pcengine) et 385kB (megadrive).
Posté par Psychofox (Mastodon) .
En réponse au journal Intuition.
Évalué à 6.
Dernière modification le 24 mai 2017 à 09:25.
Si il y'a une raison, c'est que la cause et la conséquence sont directes, pas indirectes. Et qu'avoir un peu de décence c'est d'arrêter de se plaindre et d'insulter quelqu'un qui vient de mourrir quand le désagrément sur soi est à des années lumières de ce qui l'a causé.
L'essence augmente ou baisse selon plein de raisons, y compris parfois des guerres mais rarement pour une seule raison. Ben non je ne m'en plains pas, c'est idiot de le faire. Et que la météo soit bonne ou mauvaise oui je garde souvent une pensée pour les conséquences que ça peut avoir en dehors de ma propre personne sans pour autant devoir sortir un mouchoir ni m'empêcher de me réjouïr du soleil (ou de la neige c'est selon). Tu sais on peut savoir vivre et s'exprimer sans faire des patacaisses de tout ce qui touche à notre propre personne ni se donner en spectacle.
Il y'a quand même à mon sens une grosse différence d'empathie entre savoir qu'il y'a des morts à chaque seconde et qu'on peut rien n'y faire et blâmer la personne en détresse et qui s'est donné la mort à l'instant parce que ça t'occasionne un petit contretemps dans la journée.
Il n'y a pas de mal à penser à soi mais là c'est de l'égoïsme crasseux et irrespectueux.
Les seuls chiant c'est ceux qui le font en dérangeant les autres.
Paradoxalement les gens à qui ça fait chier passent généralement un meilleur moment que dans la plupart de leurs autres trajets parce que pour une fois, ils se mettent à échanger entre eux.
Bon la dernière fois que c'est arrivé pour ma part c'était pas top parce que c'est arrivé à presque 2h du matin, que j'étais ivre , dans un wagon assez vide et dont les autres passagers étaient plus ou moins dans le même état de fatigue et d'ébriété et que j'ai fais les 30 derniers km à vélo, de nuit et avec de simples lumières d'appoint (heureusement essentiellement par des voies interdites à la circulation motorisée) pour rentrer à une heure décente et avoir assez de sommeil.
Mais les autres fois mis à part la tristesse d'une vie perdue c'était finalement des moments d'échanges avec les passagers. J'ai même lié deux amitiés durables suite à des cas similaires. Les plus chiants, ce ne sont pas ceux qui se suicident mais plutôt ceux qui passent leur temps à soupirer bruyemment et appeller chaque contact de leur téléphone pour se plaindre à haute voix de ce petit contretemps.
En 2017 l'argument du "transport de fichier" est irrecevable. À moins que tu copies à la main ton fichier depuis une clé usb ou que tu n'as aucun stockage externe/backup (mais là t'as bien d'autres problèmes que gérer un script).
Encore une fois, à vrai dire on s'en fout que tu utilises un script, que tu aies la flemme ou pas l'envie de passer à autre chose. C'est ton choix. Par contre prétendre que ta solution est meilleure parce que tu n'as rien à installer avant (alors que ton script va installer des trucs de toute manière, et que globalement c'est moins facilement maintenable) et que ça tienne en 1 seul fichier copié/collable, ce n'est pas convainquant comme raisons.
De plus, dans ce cas précis, je veux que le script plante dès qu'il y a le moindre problème rencontré, pour pouvoir le corriger immédiatement.
Le principe de l'idempotence,c'est justement de ne pas avoir ce besoin. Tu peux le lancer 1x ou 1000x et il n'y aura que ce qui a besoin d'être changé qui sera changé.
Et puis je veux qu'il m'affiche des messages sur son avancement.
C'est le cas des gestionnaire de config avec une verbosité qui peut être plus ou moins élevée.
Et puis dans certains cas, les sources d'où je prends mes logiciels ne permettent pas un download automatique de la toute dernière version, auquel cas il faut aller sur une page particulière et télécharger la dernière version d'un .deb pour qu'il puisse l'installer (ou alors parser une page web… youpi) [*]. Ça, Ansible ne sait pas le faire non plus à ma connaissance. Bon, aujourd'hui je n'ai ce cas que pour Go [https://golang.org/dl/], si quelqu'un a un lien pour downloader directement la dernière version je suis preneur.
J'imagine par ailleurs que si tu as besoin de la toute dernière version, c'est que tu as ce besoin à tout moment et donc que ça n'a donc plus rien à voir avec du postinstall.
Dans les outils de gestions de versions tu gères des dépendances.
Tu veux dire que chaque instruction qui tenait en une ligne tient maintenant en deux lignes ? Félicitations, tu as transformé les 750 premières lignes de mon script en 1500 lignes !
Bon ok, j'exagère un peu, mais tu vois l'idée :)
Je ne comprends pas, ça ne veut rien dire ton histoire de duplication de lignes.
Concernant la courbe d'apprentissage, ne t'inquiète pas, je connais ces outils, je sais ce qu'ils peuvent faire, je travaille quotidiennement avec…
Ben justement, tu n'as pas l'air très au fait des principes de base de leur fonctionnement.
Je peux alors lancer ./postinstall.sh vim pour exécuter ces 7 actions. Je ne connais pas de manière, avec Ansible, pour appeler 7 plays en une seule commande aussi simple, sauf à faire un playbook pour chaque programme, puis utiliser les rôles, etc etc. Donc au lieu d'un seul script, j'aurais plus de 50 petits fichiers…
Pourquoi voudrais-tu séparer les actions liées à vims des autres ? Si tu utilises un outil comme ansible, puppet, salt ou chief qui gèrent l'idempotence tu n'as pas besoin de faire ça justement.
Tu t'inventes des problèmes en utilisant justement une technique du paléolithique pour gérer ta bécane.
Tu utilises le pluriel, là c'est déjà mal parti pour qu'on se comprenne.
Que tu gère 1 ou 10 machine la complexité ne change pas.
ce script de postinstallation, je l'utilise une fois tous les 6 mois quand j'installe la version suivante d'Ubuntu.
Pourquoi aurais-tu besoin de faire ça ? Ta machine explose à chaque maj d'ubuntu ?
Ensuite je le lance occasionnellement (et partiellement, comme dans l'exemple de vim ci-dessus) pour rétablir des conf que j'ai un peu trop tripatouillées à la main.
En gros tu sais pas ce que tu fais ! Pourquoi ne versionnes-tu pas tes fichiers de conf ?
apt install git ansible && git clone && ansible-playbook installation.yml
Et vu que je ne me rappellerais jamais de cette commande en entier, utilisée une fois tous les 6 mois sur une machine vierge, il faudrait la mettre dans un script :)
Nan mais la c'est de la mauvaise foi crasse. Et quand bien-même tu mettrais cette ligne dans un .sh où est le problème ?
Ja favorise également un run en cron. Dans le passé, j'ai remarqué qu'en mode daemon, les run avaient tendance à se regrouper. Je me retrouvais donc avec plusieurs millier de run en quelques minutes, le master n'aimait pas trop
J'imagine que c'est le cas si on reboot régulièrement ses vm de façon groupées. J'essaye d'éviter ça en fait.¨
De plus, en cron, même si tu le kill (parce que tu kill si le run est pas fini au bout de X minutes, parce que oom, …), tu sais que l'agent sera de nouveau exécuté plus tard. En mode daemon, faut que tu le relance toi même.
Jamais trop eu ce genre de problèmes, avec 30 minutes d'intervalles entre les runs.
on souhaite une gestion des run via cron, et non via le daemon
Pourquoi justement ? Autant je vois l'intérêt pour quelqu'un utilisant puppet en "sans serveur", autant ce n'est pas le cas dans la doc publiée sur ta page perso. De mon expérience le daemon est fiable et avec la puppetdb (ou un outil de monitoring) tu es rapidement au courant si un agent est unresponsive.
Rien de nouveau sous le soleil, le developpeur d'une application a toujours pu avoir le choix de supporter ou pas tel device, telle marque, telle architecture et 'importe qui ayant un smartphone ou une tablette un peu vieille s'est retrouvé un jour devant l'impossibilité d'installer/metre à jour tout ou partie des applications du store du jour au lendemain avec la mention que sont appareil n'était plus compatible.
Ils ne doivent pas crouler sous les bug reports vu le peu de devices supportés (et comment ils sont supportés). Le téléphone qui peut pas téléphoner, c'est quand même pas très utile.
J'ajouterai que vouloir à tout prix tout faire tenir en 1 seul fichier, ce n'est pas forcément très pertinent. Oui c'était intéressant quand on faisait plein de trucs à la popogne, sans forcément avoir un accès réseau immédiat après l'installation histoire de pouvoir l'embarquer facilement dans une image iso ou une clé usb. Maintenant on a des moyens simples de mettre des trucs en ligne et d'y accéder facilement, même à la maison, que ce soit depuis un service cloud, un serveur git, ton nas ou que sais-je. On sait aussi maintenir une arborescence y gérer le versionning avec des outils à la fois centralisés et décentralisés (à nouveau, git).
PsychoFox, il faudrait que tu penses à être cohérent :)
dans le cas d'Ansible il n'y a justement même pas de client à installer. Il faut juste avoir ssh et pousser une clé.
Je ne peux pas parler pour Ansible ne l'utilisant pas mais dans le cas de puppet c'est utilisable en local sans avoir à mettre en place une infra client/serveur.
D'abord tu me dis qu'il n'y a pas besoin de client et qu'il suffit d'avoir SSH et pousser une clé (donc avoir un Ansible ailleurs), ensuite tu me dis d'installer Ansible (ou Puppet, ou autre, je m'en fous de la techno) pour lire le playbook (ou l'équivalent) localement.
Je suis cohérent mais tu mélanges 2 posts qui ne répondent pas aux même questions.
Ansible ne nécessite pas de client si tu l'utilises en mode serveur/client.
Si tu l'utilises en standalone tu as forcément besoin d'avoir quelque part un ansible qui va appliquer le playbook.
qui te prendra peut-être un dixième de tes 900 lignes
Alors là, carrément pas. Ce que j'ai appelé "helpers" dans mon script, donc l'équivalent des ça prend 175 lignes (tout compris). […] À vue de nez, un playbook Ansible équivalent ferait 150% à 200% de la taille de mon script.
Peut-être que Ansible n'est pas le bon example (je ne le connais pas assez) mais je n'y crois pas du tout. Exemple dans puppet que j'utilise tu as la directive de base qui tiens dans une ligne.
Exemple dans puppet :
package { 'vim' }
Par contre tu as effectivement pleins de trucs optionnels qui peuvent t'être utiles mais qui ne sont pas indispensables:
package { 'resource title':
name => # (namevar) The package name. This is the name that the...
provider => # (namevar) The specific backend to use for this `package...
ensure => # What state the package should be in. On...
adminfile => # A file containing package defaults for...
allow_virtual => # Specifies if virtual package names are allowed...
allowcdrom => # Tells apt to allow cdrom sources in the...
category => # A read-only parameter set by the...
configfiles => # Whether to keep or replace modified config files
description => # A read-only parameter set by the...
flavor => # OpenBSD supports 'flavors', which are further...
install_options => # An array of additional options to pass when...
instance => # A read-only parameter set by the...
package_settings => # Settings that can change the contents or...
platform => # A read-only parameter set by the...
reinstall_on_refresh => # Whether this resource should respond to refresh...
responsefile => # A file containing any necessary answers to...
root => # A read-only parameter set by the...
source => # Where to find the package file. This is only...
status => # A read-only parameter set by the...
uninstall_options => # An array of additional options to pass when...
vendor => # A read-only parameter set by the...
# ...plus any applicable metaparameters.
} Et si tu n'as besoin que d'une ou deux ça peut toujours tenir en 1 ligne :
package { 'vim': ensure => 'latest' }
Et si tu veux installer de multiples packages avec les mêmes options :
$mon_panier_garni_habituel = = [ 'vim', 'bash-completion', 'tmux', 'ssh', 'sshfs', 'keychain', 'sysstat', 'git' ]
package { $mon_panier_garni_habituel: ensure => 'latest' } Idem pour tout ce qui peut exister comme ressources (users, fichiers, services, etc).
Tu crois que tu peux gérer tout ça en moins de lignes avec ton script ? Bravo tu as réinventé et maintiens un énième outil de gestion de configuration. C'est tout à ton hônneur mais tu t'es forcément bien plus pris la tête qu'un utilisateur simple d'un de ces outils et au final je ne vois pas comment ton code peut être plus court en implémentant à la fois la mécanique derrière et la déclaration des ressources que tu gères, même si le language de ansible est plus verbeux (en terme de lignes) que celui de puppet pour des trucs basiques.
Et dès que tu as des trucs un peu gruik pas prévus d'origine par ton script, c'est à nouveau tout ça à recoder, retester, casser, etc.
Par ailleurs, je ne vois pas du tout comment, avec Ansible et en un seul fichier, je peux demander de déployer "tout ce qui concerne vim" (c'est à dire installer vim, vim-gnome, puis copier mon ancienne conf, puis mettre gvim comme éditeur par défaut par le biais de xdg-mime).
Je ne vois pas les difficultés. Dans les outils de gestions de versions tu gères des dépendances. Genre dans puppet avec les directives before ou require voir de simples flèches tu peux gérer les dépendances, avec notify tu mentionnes le nom du service qui doit être redémarré à chaque modification d'un fichier de conf. Je ne trouve pas ça hyper propre dès que la conf est grande mais il est possible d'avoir tout ou partie du contenu d'un fichier dans le code puppet. On peut même le faire avec des templates (inline_template) :
Dans lequel par exemple $header et $footer sont de simples variables et $content est un hash avec des clés/valeurs que tu paramètre avant. Ici à la place du Service qui est "notifié" tu peux utiliser une ressource Exec qui lancera une commande déclarée avant.
J'ai été sceptique aussi à une époque, puisqu'il y'a une petite courbe d'apprentissage du language utilisé et des ressources disponible et que j'avais aussi mes petits scripts maisons à une époque. Mais on y gagne finalement même à très court terme et ça scale très bien le jour où tu dois gérer des centaines voire milliers de serveurs/containers ce qui est mon cas maintenant.
Personne ne te demande de réécrire quoique ce soit ni de passer à ansible ou puppet. On t'explique juste que l'argument ça tient dans un script n'est pas valable.
On explique juste qu'à choisir si tu commençais maintenant tu aurais meilleur temps de partir sur un outil de gestion de conf qui te prendra peut-être un dixième de tes 900 lignes parce que toute la mécanique qui assure la gestion des erreurs, mais surtout d'idempotence, etc sont inclus dedans et partagés et testés par des millions de gens. Et que la lecture d'un playbook salt ou d'une recette puppet ou chief est bien plus lisible et compréhensible (et donc maintenable) que de naviguer dans un trilliards de fonctions, de structures de controles if/else et compagnie, etc.
[^] # Re: unixporn
Posté par Psychofox (Mastodon) . En réponse au journal Eolie, le petit frère de Lollypop. Évalué à 4.
Ça tombe bien l'usage du mot débauche a lui aussi évolué à travers les siècles pour ne plus avoir une connotation exclusivement sexuelle.
Personne ne se masturbe en consultant /r/earthporn. Enfin si il y'en a sûrement 1 ou 2 qui ont ce genre de délire parce qu'il y'a toujours quelqu'un pour avoir des idées plus tordues que les autres mais là on peut pas lutter.
[^] # Re: unixporn
Posté par Psychofox (Mastodon) . En réponse au journal Eolie, le petit frère de Lollypop. Évalué à 6.
Ce n'est pas du tout lié ni limité à reddit. C'est tout simplement tombé dans le language commun dans les pays anglo-saxons et l'utilisation de porn en tant que suffixe est maintenant décorrélé de la signification et connotation sexuelle du mot seul. Alors certe parler de childporn serait très maladroit mais je pense que tout le monde en est conscient.
Je dis ça et je ne suis pas très fan de cet usage mais bon c'est l'évolution du language, tu ne peux pas y faire grand chose.
[^] # Re: Et en version 3D?
Posté par Psychofox (Mastodon) . En réponse au journal Lecteur et exploitation de traces GPS en navigation. Évalué à 3.
Quand je vois la difficulté qu'ont les appareils gps à donner des valeurs fiables en terme d'élevation pour des sorties à vélo, j'ai du mal à croire qu'on arrive à avoir des valeurs pertinentes en parapente. En tout cas quand je vois les parapentistes locaux qui font des figures avec des chutes assez rapides en toupie à mon avis le GPS serait perdu.
[^] # Re: Et les disques avec un disque dedans ?
Posté par Psychofox (Mastodon) . En réponse au journal Endurance des SSD. Évalué à 4.
Ouais enfin le test en lien avec ce journal concerne des ssd dédiés à un usage desktop donc ce n'est pas hyper pertinent par rapport à une utilisation pro avec du matériel dédié à un usage i/o intensif.
# C'est pas la taille qui compte mais comment on s'en sert...
Posté par Psychofox (Mastodon) . En réponse au journal An unexpected Linux : reverse engineering. Évalué à 3.
967MB ça fait quand même beaucoup quand on compare aux roms de Devil Crush / Devil Crash qui font respectivement 205kB (pcengine) et 385kB (megadrive).
[^] # Re: Cynisme
Posté par Psychofox (Mastodon) . En réponse au journal Intuition. Évalué à 6. Dernière modification le 24 mai 2017 à 09:25.
Si il y'a une raison, c'est que la cause et la conséquence sont directes, pas indirectes. Et qu'avoir un peu de décence c'est d'arrêter de se plaindre et d'insulter quelqu'un qui vient de mourrir quand le désagrément sur soi est à des années lumières de ce qui l'a causé.
L'essence augmente ou baisse selon plein de raisons, y compris parfois des guerres mais rarement pour une seule raison. Ben non je ne m'en plains pas, c'est idiot de le faire. Et que la météo soit bonne ou mauvaise oui je garde souvent une pensée pour les conséquences que ça peut avoir en dehors de ma propre personne sans pour autant devoir sortir un mouchoir ni m'empêcher de me réjouïr du soleil (ou de la neige c'est selon). Tu sais on peut savoir vivre et s'exprimer sans faire des patacaisses de tout ce qui touche à notre propre personne ni se donner en spectacle.
[^] # Re: gnome-disks
Posté par Psychofox (Mastodon) . En réponse au journal HOW TO : Bench this SSD. Évalué à 6.
le vice.
# Nicky Hayden aussi
Posté par Psychofox (Mastodon) . En réponse au journal Moore a rejoint le "Saint". Évalué à 3.
Enfin pas d'un cancer cela-dit.
[^] # Re: Cynisme
Posté par Psychofox (Mastodon) . En réponse au journal Intuition. Évalué à 6.
Il y'a quand même à mon sens une grosse différence d'empathie entre savoir qu'il y'a des morts à chaque seconde et qu'on peut rien n'y faire et blâmer la personne en détresse et qui s'est donné la mort à l'instant parce que ça t'occasionne un petit contretemps dans la journée.
Il n'y a pas de mal à penser à soi mais là c'est de l'égoïsme crasseux et irrespectueux.
[^] # Re: Petit pas
Posté par Psychofox (Mastodon) . En réponse au journal Gnome et Logitech collaborent pour vous proposer des mises à jour de leur solution Unify. Évalué à 2.
Pour le bios il y'a des débuts avec coreboot. Au niveau du matos supporté c'est encore timide mais ça existe (purism, libreboot, pfsense, pcengine)
[^] # Re: Triste
Posté par Psychofox (Mastodon) . En réponse au journal Intuition. Évalué à 2.
ça c'est parce que t'es rien qu'un vieux ronchonchon hater.
[^] # Re: Triste
Posté par Psychofox (Mastodon) . En réponse au journal Intuition. Évalué à 2.
Paradoxalement les gens à qui ça fait chier passent généralement un meilleur moment que dans la plupart de leurs autres trajets parce que pour une fois, ils se mettent à échanger entre eux.
Bon la dernière fois que c'est arrivé pour ma part c'était pas top parce que c'est arrivé à presque 2h du matin, que j'étais ivre , dans un wagon assez vide et dont les autres passagers étaient plus ou moins dans le même état de fatigue et d'ébriété et que j'ai fais les 30 derniers km à vélo, de nuit et avec de simples lumières d'appoint (heureusement essentiellement par des voies interdites à la circulation motorisée) pour rentrer à une heure décente et avoir assez de sommeil.
Mais les autres fois mis à part la tristesse d'une vie perdue c'était finalement des moments d'échanges avec les passagers. J'ai même lié deux amitiés durables suite à des cas similaires. Les plus chiants, ce ne sont pas ceux qui se suicident mais plutôt ceux qui passent leur temps à soupirer bruyemment et appeller chaque contact de leur téléphone pour se plaindre à haute voix de ce petit contretemps.
[^] # Re: Explications
Posté par Psychofox (Mastodon) . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 4.
Oui. La première fois tu lances puppet "à la main" et il ajoute automatiquement son entrée cron.
[^] # Re: Devops
Posté par Psychofox (Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 2.
En 2017 l'argument du "transport de fichier" est irrecevable. À moins que tu copies à la main ton fichier depuis une clé usb ou que tu n'as aucun stockage externe/backup (mais là t'as bien d'autres problèmes que gérer un script).
Encore une fois, à vrai dire on s'en fout que tu utilises un script, que tu aies la flemme ou pas l'envie de passer à autre chose. C'est ton choix. Par contre prétendre que ta solution est meilleure parce que tu n'as rien à installer avant (alors que ton script va installer des trucs de toute manière, et que globalement c'est moins facilement maintenable) et que ça tienne en 1 seul fichier copié/collable, ce n'est pas convainquant comme raisons.
[^] # Re: Devops
Posté par Psychofox (Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 2. Dernière modification le 22 mai 2017 à 09:49.
Le principe de l'idempotence,c'est justement de ne pas avoir ce besoin. Tu peux le lancer 1x ou 1000x et il n'y aura que ce qui a besoin d'être changé qui sera changé.
C'est le cas des gestionnaire de config avec une verbosité qui peut être plus ou moins élevée.
https://launchpad.net/~longsleep/+archive/ubuntu/golang-backports
https://hub.docker.com/_/golang/
J'imagine par ailleurs que si tu as besoin de la toute dernière version, c'est que tu as ce besoin à tout moment et donc que ça n'a donc plus rien à voir avec du postinstall.
Je ne comprends pas, ça ne veut rien dire ton histoire de duplication de lignes.
Ben justement, tu n'as pas l'air très au fait des principes de base de leur fonctionnement.
[^] # Re: Devops
Posté par Psychofox (Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 2.
Pourquoi voudrais-tu séparer les actions liées à vims des autres ? Si tu utilises un outil comme ansible, puppet, salt ou chief qui gèrent l'idempotence tu n'as pas besoin de faire ça justement.
Tu t'inventes des problèmes en utilisant justement une technique du paléolithique pour gérer ta bécane.
Que tu gère 1 ou 10 machine la complexité ne change pas.
Pourquoi aurais-tu besoin de faire ça ? Ta machine explose à chaque maj d'ubuntu ?
En gros tu sais pas ce que tu fais ! Pourquoi ne versionnes-tu pas tes fichiers de conf ?
Nan mais la c'est de la mauvaise foi crasse. Et quand bien-même tu mettrais cette ligne dans un .sh où est le problème ?
[^] # Re: pourquoi ne pas faire conviance au daemon ?
Posté par Psychofox (Mastodon) . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 2.
J'imagine que c'est le cas si on reboot régulièrement ses vm de façon groupées. J'essaye d'éviter ça en fait.¨
Jamais trop eu ce genre de problèmes, avec 30 minutes d'intervalles entre les runs.
# pourquoi ne pas faire conviance au daemon ?
Posté par Psychofox (Mastodon) . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 3.
Pourquoi justement ? Autant je vois l'intérêt pour quelqu'un utilisant puppet en "sans serveur", autant ce n'est pas le cas dans la doc publiée sur ta page perso. De mon expérience le daemon est fiable et avec la puppetdb (ou un outil de monitoring) tu es rapidement au courant si un agent est unresponsive.
[^] # Re: Titre racoleur et où est le problème ?
Posté par Psychofox (Mastodon) . En réponse au journal Être root sur votre appareil Android va vous causer des soucis. Évalué à 3. Dernière modification le 22 mai 2017 à 08:05.
Rien de nouveau sous le soleil, le developpeur d'une application a toujours pu avoir le choix de supporter ou pas tel device, telle marque, telle architecture et 'importe qui ayant un smartphone ou une tablette un peu vieille s'est retrouvé un jour devant l'impossibilité d'installer/metre à jour tout ou partie des applications du store du jour au lendemain avec la mention que sont appareil n'était plus compatible.
[^] # Re: Conseil
Posté par Psychofox (Mastodon) . En réponse au journal L'équipe Ubuntu Desktop aimerait avoir vos commentaires. Évalué à 2.
Et KDE Neon que j'utilise actuellement. Pas trop compris l'existence des deux, surement un truc politique qui m'a échappé.
# Activités
Posté par Psychofox (Mastodon) . En réponse au journal Sortie de Replicant 6.0. Évalué à 4.
Ils ne doivent pas crouler sous les bug reports vu le peu de devices supportés (et comment ils sont supportés). Le téléphone qui peut pas téléphoner, c'est quand même pas très utile.
[^] # Re: Devops
Posté par Psychofox (Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 2. Dernière modification le 18 mai 2017 à 12:48.
J'ajouterai que vouloir à tout prix tout faire tenir en 1 seul fichier, ce n'est pas forcément très pertinent. Oui c'était intéressant quand on faisait plein de trucs à la popogne, sans forcément avoir un accès réseau immédiat après l'installation histoire de pouvoir l'embarquer facilement dans une image iso ou une clé usb. Maintenant on a des moyens simples de mettre des trucs en ligne et d'y accéder facilement, même à la maison, que ce soit depuis un service cloud, un serveur git, ton nas ou que sais-je. On sait aussi maintenir une arborescence y gérer le versionning avec des outils à la fois centralisés et décentralisés (à nouveau, git).
Je n'en ferai pas une obsession en tout cas.
[^] # Re: Devops
Posté par Psychofox (Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 2.
Je suis cohérent mais tu mélanges 2 posts qui ne répondent pas aux même questions.
Ansible ne nécessite pas de client si tu l'utilises en mode serveur/client.
Si tu l'utilises en standalone tu as forcément besoin d'avoir quelque part un ansible qui va appliquer le playbook.
Peut-être que Ansible n'est pas le bon example (je ne le connais pas assez) mais je n'y crois pas du tout. Exemple dans puppet que j'utilise tu as la directive de base qui tiens dans une ligne.
Exemple dans puppet :
package { 'vim' }
Par contre tu as effectivement pleins de trucs optionnels qui peuvent t'être utiles mais qui ne sont pas indispensables:
package { 'resource title':
name => # (namevar) The package name. This is the name that the...
provider => # (namevar) The specific backend to use for this `package...
ensure => # What state the package should be in. On...
adminfile => # A file containing package defaults for...
allow_virtual => # Specifies if virtual package names are allowed...
allowcdrom => # Tells apt to allow cdrom sources in the...
category => # A read-only parameter set by the...
configfiles => # Whether to keep or replace modified config files
description => # A read-only parameter set by the...
flavor => # OpenBSD supports 'flavors', which are further...
install_options => # An array of additional options to pass when...
instance => # A read-only parameter set by the...
package_settings => # Settings that can change the contents or...
platform => # A read-only parameter set by the...
reinstall_on_refresh => # Whether this resource should respond to refresh...
responsefile => # A file containing any necessary answers to...
root => # A read-only parameter set by the...
source => # Where to find the package file. This is only...
status => # A read-only parameter set by the...
uninstall_options => # An array of additional options to pass when...
vendor => # A read-only parameter set by the...
# ...plus any applicable metaparameters.
}
package { 'vim': ensure => 'latest' }
Et si tu veux installer de multiples packages avec les mêmes options :
$mon_panier_garni_habituel = = [ 'vim', 'bash-completion', 'tmux', 'ssh', 'sshfs', 'keychain', 'sysstat', 'git' ]
package { $mon_panier_garni_habituel: ensure => 'latest' }
Tu crois que tu peux gérer tout ça en moins de lignes avec ton script ? Bravo tu as réinventé et maintiens un énième outil de gestion de configuration. C'est tout à ton hônneur mais tu t'es forcément bien plus pris la tête qu'un utilisateur simple d'un de ces outils et au final je ne vois pas comment ton code peut être plus court en implémentant à la fois la mécanique derrière et la déclaration des ressources que tu gères, même si le language de ansible est plus verbeux (en terme de lignes) que celui de puppet pour des trucs basiques.
Et dès que tu as des trucs un peu gruik pas prévus d'origine par ton script, c'est à nouveau tout ça à recoder, retester, casser, etc.
Je ne vois pas les difficultés. Dans les outils de gestions de versions tu gères des dépendances. Genre dans puppet avec les directives before ou require voir de simples flèches tu peux gérer les dépendances, avec notify tu mentionnes le nom du service qui doit être redémarré à chaque modification d'un fichier de conf. Je ne trouve pas ça hyper propre dès que la conf est grande mais il est possible d'avoir tout ou partie du contenu d'un fichier dans le code puppet. On peut même le faire avec des templates (inline_template) :
Dans lequel par exemple $header et $footer sont de simples variables et $content est un hash avec des clés/valeurs que tu paramètre avant. Ici à la place du Service qui est "notifié" tu peux utiliser une ressource Exec qui lancera une commande déclarée avant.
J'ai été sceptique aussi à une époque, puisqu'il y'a une petite courbe d'apprentissage du language utilisé et des ressources disponible et que j'avais aussi mes petits scripts maisons à une époque. Mais on y gagne finalement même à très court terme et ça scale très bien le jour où tu dois gérer des centaines voire milliers de serveurs/containers ce qui est mon cas maintenant.
[^] # Re: Devops
Posté par Psychofox (Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 5. Dernière modification le 18 mai 2017 à 07:54.
Personne ne te demande de réécrire quoique ce soit ni de passer à ansible ou puppet. On t'explique juste que l'argument ça tient dans un script n'est pas valable.
On explique juste qu'à choisir si tu commençais maintenant tu aurais meilleur temps de partir sur un outil de gestion de conf qui te prendra peut-être un dixième de tes 900 lignes parce que toute la mécanique qui assure la gestion des erreurs, mais surtout d'idempotence, etc sont inclus dedans et partagés et testés par des millions de gens. Et que la lecture d'un playbook salt ou d'une recette puppet ou chief est bien plus lisible et compréhensible (et donc maintenable) que de naviguer dans un trilliards de fonctions, de structures de controles if/else et compagnie, etc.
[^] # Re: Quelques infos en plus
Posté par Psychofox (Mastodon) . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 3.
il y'a aussi salt, cfengine et quelques autres encore je crois dans le monde du libre.