Perso j'ai arrêté d'utiliser stow (je me suis fait un script Python custom à la place) car si par exemple un dossier n'existe pas il va faire un lien symbolique pour le dossier (au lieu de seulement les fichiers qu'il contient). Et si le logiciel utilisant ce dossier créer d'autres fichiers, ils se retrouvent dans ton dossier dotfiles et potentiellement dans ton dépôt Git si tu les commit par erreur.

L'idée est très bonne, mais je trouve dommage de faire un backup difficile à exploiter, alors que Borg permet de faire bien mieux (de mon point de vue) :

• Bases de données : Je préfère une commande de la forme pg_dumpall | borg create repo::archive -, ce qui permet de restaurer avec un simple borg extract --stdout repo::archive | psql dbname
• Fichiers de configuration : Pourquoi créer une archive et la sauvegarder alors que Borg est fait pour sauvegarder des fichiers ? Je pencherais plutôt pour borg create repo::archive *.conf. L'avantage ? Pouvoir extraire aussi simplement ces fichiers avec borg extract repo::archive filename destination, voire afficher directement le contenu avec borg extract repo::archive --stdout filename

Alors oui, ce que je propose n'est peut-être pas possible avec borgmatic (ne l'utilisant pas, je le connais mal), mais quitte à faire un script, autant en profiter pour faire un backup simple à exploiter. Pour la politique de rétention, Borg fait ça très bien tout seul avec la commande borg prune. Pour vérifier la cohérence, c'est borg check. Et pas besoin de fichier de configuration supplémentaire ni de fichier de backup temporaire :)

Le point important lorsqu'on utilise un dépôt qui contient plusieurs backups différents (ici bases de données et fichiers de configuration), c'est de bien les nommer, pour pouvoir utiliser le paramètre --prefix des commandes borg prune, borg list, borg check, borg delete, etc.).

L'idée est bonne, mais plusieurs choses me dérangent dans cet article.

• Syncthing est un très bon outil, mais il n'est pas du tout adapté pour faire de la sauvegarde.
• Devoir chiffrer et déchiffrer manuellement, c'est vraiment pas pratique. Et ça nécessite d'avoir les données en double sur la machine source (données réelles, et données chiffrées).
• À moins de désactiver la synchro automatique (si c'est possible), on risque de perdre sa “sauvegarde” en la supprimant de la machine source.
• Même s'il propose du versioning, sans déduplication, ça consomme vite beaucoup de place.
• Si la nouvelle “sauvegarde” est un fichier différent, il va uploader la totalité du fichier, ou il ne télécharge que les bouts qu'il ne connait pas déjà ?

Pour de la sauvegarde, je te conseillerais plutôt de regarder du coté d'outils faits pour ça, comme Borg ;)

De mon coté je reste sur vim (je suis perdu avec une GUI ^^), mais tous mes collègues sont passés sur VScode après un passage par ST, puis Atom.

De l'extérieur, ça donne l'impression qu'il y a un cheminement logique dans le choix des éditeurs de texte. Quel sera le remplacement de VScode ? :)

Comme dit dans les commentaires, il vaut mieux modifier son propre vimrc plutôt que le fichier defaults.vim qui sera écrasé à la prochaine mise à jour.

Les manpages disent ça à propos de mouse :

The mouse can be enabled for different modes:
        n   Normal mode
        v   Visual mode
        i   Insert mode
        c   Command-line mode
        h   all previous modes when editing a help file
        a   all previous modes
        r   for |hit-enter| and |more-prompt| prompt
    Normally you would enable the mouse in all four modes with:
        :set mouse=a
    When the mouse is not enabled, the GUI will still use the mouse for
    modeless selection.  This doesn't move the text cursor.

    See |mouse-using|.  Also see |'clipboard'|.

    Note: When enabling the mouse in a terminal, copy/paste will use the
    "* register if there is access to an X-server.  The xterm handling of
    the mouse buttons can still be used by keeping the shift key pressed.
    Also see the 'clipboard' option.

L'idée de ce contournement apparemment, c'est donc de désactiver le support souris sauf pour les prompt. Du coup le copier/coller (par exemple en mode insertion) fonctionne à travers le « relais » de l'émulateur de terminal. Mais ça ne nous aide pas à comprendre pourquoi depuis Debian 9 ça ne fonctionne plus. D'après ce que je comprends, vim ne peut plus accéder au clipboard Xorg ?

Les manpages font référence à Xorg, peut-on espérer un jour des adaptations pour copier-coller avec Wayland en ayant le mode souris activé ?

Est-ce bien compatible VI (et non VIM) ?

Perso, je ne comprend pas les gens qui retienne “:wq” quand on peut faire “:x” qui fait la même chose. (attention, “:w” ou ‘:q" tout seul, okay, mais les deux :s)

Hello,

Je partage les critiques sur Fail2ban, on en parle systématiquement pour la sécurisation d'un système mais il est assez perfectible. Il reste cependant simple d'accès et fait le job quand même, en gros je voudrais pouvoir m'en passer mais c'est ce qu'il y a encore de mieux.

La solution proposée me parait lourde à comprendre et mettre en place, ce sera source d'erreur pour une personne qui veut reprendre le sujet derrière. Je préfère utiliser un outil bien connu avec une doc abondante et des fichiers de conf bien identifiés qu'éparpiller des fichiers de conf (ou scripts) pour être plus pointu au niveau de la sécurisation. Avis perso of course.

Tcho !