Pas obligé d’utiliser Python, y’a d’autres langages !
J’ai peur qu’en voulant éviter de réinventer la roue, tu te retrouves avec un enrobage assez indigeste de technologies dans ton conteneur. Et mes recherches pour faire de l’IMAP en CLI sont pas super concluantes alors que 4-5 lignes de codes feraient assez rapidement le boulot.
Je proposais imap-cli pour uniquement la partie move. Mais j’ai conscience que ça commencerait à faire un assemblage un peu complexe de programmes.
Si tu as les compétences pour le faire, sortir Python te permettrait d’unifier un peu tout ton projet et de diminuer un peu les dépendances. Surtout si tu as déjà un script pour la gestion des pièces jointes.
Soit tu dégaines ton langage de prédilection ainsi qu’une librairie pour faire de l’IMAP et accéder à tous tes besoins plus facilement.
Soit tu trouves un truc déjà tout fait que tu peux appeler en ligne de commande depuis ton conteneur. P’tet un truc comme https://github.com/Gentux/imap-cli
Je suis d’accord avec toi sur la vitesse, ça sert quasiment à rien la majorité du temps. Mais Goffi ne semblait pas trop en parler ici.
L’Azerty a pas mal de défauts et si on dispose un peu de temps et d’envie pour changer de crémerie, c’est quand même jouable. Surtout des changements plus lights de layout qui peuvent s’apprendre vraiment rapidement.
Je suis passé en Bépo pendant mes études et suis depuis sur un point de non-retour depuis de nombreuses années. Il me faudrait pas mal de semaines pour revenir à de l’Azerty. J’installe juste le Bépo partout (il faut pouvoir se débrouiller dans certains environnements pro par contre…). Faire le switch pro/perso en cours de journée est effectivement une mauvaise idée et mieux vaut rester sur de l’Azerty dans ce cas.
Si votre proxy web est à la ramasse dans ses updates (OpenSSL / le trust-store), ça va effectivement se vautrer. J’ai dû bricoler des Ubuntu 14 à ce sujet (simplement supprimer le DST Root CA X3).
Et pourtant, rien de ce que tu décris.
Pas de réactions désobligeantes de fanboys / pro-systemd (ton vocabulaire).
Pas de descente en flamme. Pas de ligues.
Parce qu’en vrai on s’en fiche complètement de systemd 364j sur 365. Mais bon chacun ses vendettas hein.
Bah peut-être parce que ce genre de commentaires est justement un truc de réac’.
Sérieux je veux bien que tout le monde donne son avis, mais vous avez vu le niveau d’argumentation déployé ici ?
Y’a une nouvelle feature qu’est développée dans systemd, il me faut 4 lectures de l’article de blog pour comprendre les tenants et les aboutissants du truc. On voit bien que c’est une feature satellite à systemd qui donne simplement des outils supplémentaires. Je me trompe peut-être mais ça semble clairement pas viser le desktop.
Et là on se coltine sur Linuxfr le même genre de posts totalement inutiles depuis 2010 qui contient toutes les frustrations de l’OS dans une mixture imbuvable. C’est quoi l’intérêt de parler de PulseAudio ici ? Mais quel rapport ? oO La comparaison avec MacOS/Windows, juste wtf vous êtes complètement hors-sujets là ! Je passe le troll sur yes/true…
Si vous voulez répéter vos mêmes complaintes (parce que très honnêtement y’a moyen de trouver une checksum qui match en 10 ans…) amusez-vous à écrire un journal ça nous changera.
Tout est plus rapide pour les manipulations de fenêtres.
Même pour du full screen, c’est plus rapide de déplacer ça d’un écran / virtual desktop à l’autre. C’est fait pour le clavier de base, et même si on a des raccourcis claviers dans Gnome/KDE c’est moins cohérent dans l’ensemble.
Ensuite l’utilisation du tiling WM + des splits dans Emacs dans mon cas + du tmux sont assez complémentaires selon les usages.
Sauf second degré foireux (j’te connais pô, difficile à dire), je pense avoir bien compris le message. Le vocabulaire employé me fait bien rire (jaune) mais enjoy ta virilité générationnelle (pwah ça veut rien dire tout ça…).
T’as beau avoir la libsystemd installée par défaut dans l’image d’Ubuntu par exemple, y’a pas grand chose de prémâché pour le lancer correctement. Y’avait une image pour Centos par contre.
En vrai c’est pas la philosophie. Systemd n’apporte pas vraiment d’avantage dans un conteneur. Les images où tu souhaites maintenir plusieurs processus (déjà tu réfléchis à le séparer) tu vas utiliser des trucs un peu plus light comme supervisor.
Tout ce que tu décris est indépendant de la question de conteneur en fait. :D
Tu configures tes health-checks de la façon dont tu le souhaites avec ou sans conteneur.
Tu configures Docker (ou autre) comme tu préfères pour le réseau pour lui laisser ou non la main sur ça.
Le risque de plantage s’évalue après.
Bref, tout ça pour dire que c’est pas le choix de faire du conteneur qui va changer grand chose si tu as envie de garder complètement la main sur tes bases de données. Là où je veux en venir c’est que des conteneurs vont plutôt avoir tendance à t’ouvrir des portes sur la manière dont tu gères ton infrastructure plutôt que de t’en fermer. Pareil pour les raisons extra-techniques, t’es pas obligé de tout fusionner.
Tu vas pas spécialement avoir d’impact sur les performances et la disponibilité en fait.
On a de plus en plus tendance à rajouter cette couche horizontale de conteneurs sur les serveurs et pas spécialement en allant jusqu’à un Kubernetes. Certes, une base de données va pas bénéficier de tous les avantages que ça pourrait apporter mais clairement y’a vraiment aucun inconvénients à garder les mêmes types de briques même pour ce genre d’applications stateful. L’écosystème est suffisamment flexible pour ça.
Et pour le redimensionnement, ça dépend de l’infra. Rien n’empêche de gérer un cluster exactement de la même manière avec des docker[-compose] exec mysql au lieu de mysql dans des scripts.
# Aïe
Posté par Sacha Trémoureux (site web personnel) . En réponse au lien neocities : faire le web chouette à nouveau. Évalué à 5.
J’croyais que le vert sur noir était interdit par la convention de Genève.
[^] # Re: Le véhicule autonome du futur
Posté par Sacha Trémoureux (site web personnel) . En réponse au lien La voiture autonome s’invite sur les routes françaises. Évalué à 1.
Si on fait ça on va devoir rollback le cyclisme de compétition :\
[^] # Re: utiliser les APIs et les protocoles qui vont bien
Posté par Sacha Trémoureux (site web personnel) . En réponse au message Imprimer une pièce jointe automatiquement en cli. Évalué à 1.
Pas obligé d’utiliser Python, y’a d’autres langages !
J’ai peur qu’en voulant éviter de réinventer la roue, tu te retrouves avec un enrobage assez indigeste de technologies dans ton conteneur. Et mes recherches pour faire de l’IMAP en CLI sont pas super concluantes alors que 4-5 lignes de codes feraient assez rapidement le boulot.
[^] # Re: utiliser les APIs et les protocoles qui vont bien
Posté par Sacha Trémoureux (site web personnel) . En réponse au message Imprimer une pièce jointe automatiquement en cli. Évalué à 2.
Je proposais imap-cli pour uniquement la partie move. Mais j’ai conscience que ça commencerait à faire un assemblage un peu complexe de programmes.
Si tu as les compétences pour le faire, sortir Python te permettrait d’unifier un peu tout ton projet et de diminuer un peu les dépendances. Surtout si tu as déjà un script pour la gestion des pièces jointes.
[^] # Re: utiliser les APIs et les protocoles qui vont bien
Posté par Sacha Trémoureux (site web personnel) . En réponse au message Imprimer une pièce jointe automatiquement en cli. Évalué à 3.
Tu as deux solutions (qui me viennent en tête) :
[^] # Re: La disposition la plus courante dans ton pays
Posté par Sacha Trémoureux (site web personnel) . En réponse au message Retour d'expérience sur les dispositions de claviers ?. Évalué à 1.
Je suis d’accord avec toi sur la vitesse, ça sert quasiment à rien la majorité du temps. Mais Goffi ne semblait pas trop en parler ici.
L’Azerty a pas mal de défauts et si on dispose un peu de temps et d’envie pour changer de crémerie, c’est quand même jouable. Surtout des changements plus lights de layout qui peuvent s’apprendre vraiment rapidement.
Je suis passé en Bépo pendant mes études et suis depuis sur un point de non-retour depuis de nombreuses années. Il me faudrait pas mal de semaines pour revenir à de l’Azerty. J’installe juste le Bépo partout (il faut pouvoir se débrouiller dans certains environnements pro par contre…). Faire le switch pro/perso en cours de journée est effectivement une mauvaise idée et mieux vaut rester sur de l’Azerty dans ce cas.
# L’explication officielle
Posté par Sacha Trémoureux (site web personnel) . En réponse au journal Certificat expiré. Évalué à 6.
L’explication officielle est ici : https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
Si votre proxy web est à la ramasse dans ses updates (OpenSSL / le trust-store), ça va effectivement se vautrer. J’ai dû bricoler des Ubuntu 14 à ce sujet (simplement supprimer le DST Root CA X3).
[^] # Re: Linux devient Windows et macOS
Posté par Sacha Trémoureux (site web personnel) . En réponse au lien systemd portable services: parce que les conteneurs, c'est trop mainstream. Évalué à 2.
Et pourtant, rien de ce que tu décris.
Pas de réactions désobligeantes de fanboys / pro-systemd (ton vocabulaire).
Pas de descente en flamme. Pas de ligues.
Parce qu’en vrai on s’en fiche complètement de systemd 364j sur 365. Mais bon chacun ses vendettas hein.
[^] # Re: Linux devient Windows et macOS
Posté par Sacha Trémoureux (site web personnel) . En réponse au lien systemd portable services: parce que les conteneurs, c'est trop mainstream. Évalué à 2.
Y’a quasi aucun post sur Devuan depuis 3-4 ans.
[^] # Re: Linux devient Windows et macOS
Posté par Sacha Trémoureux (site web personnel) . En réponse au lien systemd portable services: parce que les conteneurs, c'est trop mainstream. Évalué à 10.
Bah peut-être parce que ce genre de commentaires est justement un truc de réac’.
Sérieux je veux bien que tout le monde donne son avis, mais vous avez vu le niveau d’argumentation déployé ici ?
Y’a une nouvelle feature qu’est développée dans systemd, il me faut 4 lectures de l’article de blog pour comprendre les tenants et les aboutissants du truc. On voit bien que c’est une feature satellite à systemd qui donne simplement des outils supplémentaires. Je me trompe peut-être mais ça semble clairement pas viser le desktop.
Et là on se coltine sur Linuxfr le même genre de posts totalement inutiles depuis 2010 qui contient toutes les frustrations de l’OS dans une mixture imbuvable. C’est quoi l’intérêt de parler de PulseAudio ici ? Mais quel rapport ? oO La comparaison avec MacOS/Windows, juste wtf vous êtes complètement hors-sujets là ! Je passe le troll sur yes/true…
Si vous voulez répéter vos mêmes complaintes (parce que très honnêtement y’a moyen de trouver une checksum qui match en 10 ans…) amusez-vous à écrire un journal ça nous changera.
[^] # Re: tout Ansible ?
Posté par Sacha Trémoureux (site web personnel) . En réponse au message Orchestrateur/ordonnanceur pour une équipe d'administrateurs systèmes. Évalué à 4.
Dans la même direction du tout Ansible, Jenkins peut faire le taf également en interface web. Son plugin Ansible est très très bien.
[^] # Re: Intérêt d'un tiling WM ?
Posté par Sacha Trémoureux (site web personnel) . En réponse au lien Passage au gestionnaire de fenêtres i3. Évalué à 2.
Tout est plus rapide pour les manipulations de fenêtres.
Même pour du full screen, c’est plus rapide de déplacer ça d’un écran / virtual desktop à l’autre. C’est fait pour le clavier de base, et même si on a des raccourcis claviers dans Gnome/KDE c’est moins cohérent dans l’ensemble.
Ensuite l’utilisation du tiling WM + des splits dans Emacs dans mon cas + du tmux sont assez complémentaires selon les usages.
[^] # Re: Un titre pareil...
Posté par Sacha Trémoureux (site web personnel) . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à 1.
Sauf second degré foireux (j’te connais pô, difficile à dire), je pense avoir bien compris le message. Le vocabulaire employé me fait bien rire (jaune) mais enjoy ta virilité générationnelle (pwah ça veut rien dire tout ça…).
[^] # Re: Un titre pareil...
Posté par Sacha Trémoureux (site web personnel) . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à -1.
P’tet, je sais plus.
Je répondais à
[^] # Re: Un titre pareil...
Posté par Sacha Trémoureux (site web personnel) . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à -3.
Pauvre choupinet tout fragile :(((
[^] # Re: Merci
Posté par Sacha Trémoureux (site web personnel) . En réponse au message VSFTP droits qui change avec import. Évalué à 1.
L’ennui c’est que si tu mets en marche des nouveaux trucs en FTP, tu vas pas dans le bon sens et tu te compliques la vie pour la bascule en SFTP.
[^] # Re: Machine virtuelle
Posté par Sacha Trémoureux (site web personnel) . En réponse au message image de rocky linux pour docker. Évalué à 2.
T’as beau avoir la libsystemd installée par défaut dans l’image d’Ubuntu par exemple, y’a pas grand chose de prémâché pour le lancer correctement. Y’avait une image pour Centos par contre.
En vrai c’est pas la philosophie. Systemd n’apporte pas vraiment d’avantage dans un conteneur. Les images où tu souhaites maintenir plusieurs processus (déjà tu réfléchis à le séparer) tu vas utiliser des trucs un peu plus light comme supervisor.
[^] # Re: Machine virtuelle
Posté par Sacha Trémoureux (site web personnel) . En réponse au message image de rocky linux pour docker. Évalué à 1.
Avec de la bonne volonté…
[^] # Re: Machine virtuelle
Posté par Sacha Trémoureux (site web personnel) . En réponse au message image de rocky linux pour docker. Évalué à 3.
Tu confonds les choses. Tu peux faire tourner une distribution dans un conteneur. Te manqueras juste le kernel.
[^] # Re: Un site super ici.
Posté par Sacha Trémoureux (site web personnel) . En réponse au lien Rallongeur d'url. Évalué à 6.
Je me suis permis d’encapsuler ton lien.
https://bit.ly/3wVv340
[^] # Re: Lien Linkedin mais intéressant ...
Posté par Sacha Trémoureux (site web personnel) . En réponse au lien Comment diviser par 7 le coût de ses serveurs ….. ou presque. Évalué à 2.
À méditer.
[^] # Re: Ce sera vite oublié
Posté par Sacha Trémoureux (site web personnel) . En réponse au journal Multiple démissions dans l'équipe du réseau IRC Freenode. Évalué à 10.
Alors qu’avec une bonne XEP… !
[^] # Re: docker, lecture seule avec volume externe
Posté par Sacha Trémoureux (site web personnel) . En réponse au message Sauvegarde mariadb dans docker . Évalué à 0.
Tout ce que tu décris est indépendant de la question de conteneur en fait. :D
Le risque de plantage s’évalue après.
Bref, tout ça pour dire que c’est pas le choix de faire du conteneur qui va changer grand chose si tu as envie de garder complètement la main sur tes bases de données. Là où je veux en venir c’est que des conteneurs vont plutôt avoir tendance à t’ouvrir des portes sur la manière dont tu gères ton infrastructure plutôt que de t’en fermer. Pareil pour les raisons extra-techniques, t’es pas obligé de tout fusionner.
[^] # Re: docker, lecture seule avec volume externe
Posté par Sacha Trémoureux (site web personnel) . En réponse au message Sauvegarde mariadb dans docker . Évalué à 0. Dernière modification le 11 mai 2021 à 13:24.
Tu vas pas spécialement avoir d’impact sur les performances et la disponibilité en fait.
On a de plus en plus tendance à rajouter cette couche horizontale de conteneurs sur les serveurs et pas spécialement en allant jusqu’à un Kubernetes. Certes, une base de données va pas bénéficier de tous les avantages que ça pourrait apporter mais clairement y’a vraiment aucun inconvénients à garder les mêmes types de briques même pour ce genre d’applications stateful. L’écosystème est suffisamment flexible pour ça.
Et pour le redimensionnement, ça dépend de l’infra. Rien n’empêche de gérer un cluster exactement de la même manière avec des
docker[-compose] exec mysql
au lieu demysql
dans des scripts.Finalement le conteneur est un non-sujet.
[^] # Re: docker, lecture seule avec volume externe
Posté par Sacha Trémoureux (site web personnel) . En réponse au message Sauvegarde mariadb dans docker . Évalué à 2.
Euh bah on des volumes pour les données.
Des bases de données dans Docker c’est de plus en plus courant, ça permet d’uniformiser les techniques de déploiement, même en production.