Debian GNOME pour moi ;-P
Sinon Mint 19.1 a le plus joli thème pour XFCE, mais si je devais choisir, j'irais quand-même sur Debian malgré son XFCE vanilla (c'est juste que Debian n'a rien changé à l'upstream en dehors du fond d'écran).
Et voilà qui est fait: https://www.journalduhacker.net/s/evdfh2/neo_vim_et_devcontainer
J'utilise #!/usr/bin/env ...
dans tous mes scripts, ça simplifie la vie. Même pour les playbooks ansible #!/usr/bin/env ansible-playbook
et chmod +x
et ça roule.
Vachement sympa la dernière version de Roundcude. Je l'utilise depuis qu'elle était disponible en rc, je n'ai pas eu à m'en plaindre, au contraire.
Pareil ici, j'ai remplacé mes vieilles installs de SquirrelMail (mort hélas) par du Roundcube 1.4rc1 quand c'est sorti.
Waw, super article, le propos est très juste et ne fait dans la langue de bois. (Peut-être parce qu'il est écrit par un enseignant-chercheur.)
C'est effectivement pas trop son habitude la langue de bois cf. https://www.affordance.info/
Effectivement personne de raisonnable n'utilise Python comme un “langage système fiable et performant”.
On a d'autres languages pour ça.
Ça aurait été intéressant d'avoir quelques éléments de comparaison avec les autres outils/serveurs NTP.
Par exemple, si on veut juste un client systemd peut le gérer sans avoir besoin d'installer un paquet supplémentaire.
Si on veut serveur, l'outil habituel souvent déjà présent est ntpd.
Dans un cas où dans l'autre, quel intérêt a Chrony ?
En l'occurrence voilà ce que j'ai trouvé, en anglais : https://chrony.tuxfamily.org/comparison.html
Salute,
En ce qui me concerne je recommande Chrony :
- On a installé Chrony à la place de ntpd sur l'ensemble des serveurs il y a 2 ans, RAS
- Ton lien démontre que niveau fonctionnalité c'est le plus complet/abouti (ce qui ne veut pas dire qu'il faut nécessairement le choisir, c'est toujours en fonction des besoins)
- https://www.coreinfrastructure.org/blogs/securing-network-time/ (voir Chrony) démontre que niveau sécurité c'est le meilleur, c'est ce qui nous a amené à quitter ntpd
- https://unix.stackexchange.com/questions/504381/chrony-vs-systemd-timesyncd-what-are-the-differences-and-use-cases-as-ntp-cli résume bien les différences entre Chrony et systemd-timesyncd. Pour moi les plus importants : 1/ systemd-timesync ne peut pas faire serveur NTP (juste client) 2/ Il ne se synchronise que sur un seul serveur (focusing only on querying time from one remote server and synchronizing the local clock to it) ce que je trouve trop léger pour un serveur (multiples sources plus sûr)
- chronyc fait partie des merveilles que tout logiciel récent devrait proposer. Cette interface en ligne de commande permet de tester, vérifier que tout est ok, du beurre
- “The development is currently supported by Red Hat Software and it is now the default NTP implementation on their distributions”, un gage de qualité et de pérennité
Tcho !
Magnifique, ce matin je me demandais justement lequel installer (avec Friendica en plus dans la liste tout de même).
Ah je connaissais pas, mais ça à l'air sympa :o
Ça ne semble cependant pas trop difficile à implémenter, et visiblement il y a déjà des gens qui ont fait des plugins pour ça -> https://github.com/schnauzers/devcontainer :)
En fait en y relechissant je me rend compte que ce n'est peut-être pas la peine de faire plugin, suffit de lancer un conteneur avec un vim dedans, et de partager sa conf via un volume.
Ça m'a donné envie de retenter de passer à VIM une quatrième fois… (^_^‘)
Mais il faudrait que je me fasse un plugin pour reproduire le.comportement des “devcontainers” de VSCode.
Dommage que l'article soit payant. Je propose cette source qui cite le même article :
Bon, trois problèmes à cette analyse.
Premièrement, elle se base sur le concept de la « tragédie des communs » de Garrett Hardin, qui s'avère être bidon (un peu comme toutes les théories économique libérales), cf. https://lejournal.cnrs.fr/billets/la-tragedie-des-communs-etait-un-mythe. Du coup, il faudrait peut-être arrêter de baser nos sociétés, nos fonctionnements, etc. sur des théories qui ont fait la preuve de leur inexactitude et de leurs effets néfastes. Ce qui est paradoxal c'est que l'article enchaîne ensuite avec les travaux de Olstrom qui contredisent ceux de Hardin
Ce qui nous amène au deuxième problème, c'est qu'il fait, en plus d'une interprétation très personnelle, une application sélective des principes de Olstrom au domaine de l'open-source.
Troisièmement, le parallèle entre gestion du logiciel open-source et gestion d'un bien commun limité est tordu, et je me demande s'il tient vraiment… On passe du logiciel lui-même et sa communauté, à ses “clients” étant le bien commun, tout en gardant d'appliquer les principes de gestion de commune au logiciel qui pourtant du coup n'est plus l'objet “bien commun”…
Dans mon usage il est en passe de remplacer Python pour mes petits scripts.