Journal [Rexp] Fini la bricole à base de ruban adhésif et de post-its

Posté par  . Licence CC By‑SA.
15
31
juil.
2021

Sommaire

Cher nour 'jal1,

En ce jour pluvieux d'été (y'a plus de saison maintenant, tu sais), je me suis dit que tant qu'à rester au chaud (comme d'hab' depuis quelques temps, oui, merci de me le rappeler), j'allais te compter mes dernières aventures.

Je sais, il n'y a pas grand chose de nouveau, que tu te dis déjà que ça va être triste à mourir d'ennui, que ça va être beaucoup de blablabla, et j'ai hésité à te raconter cette ensemble de petites choses à cause de ça.

Mais même si tu ferme un œil lors des parties peut-être un peu longues que tu connais déjà, l'objectif est de te montrer une solution complète pour résoudre les problèmes que j'avais, tout en réutilisant au maximum les bouts d'info glanés ici ou là (surtout ici, d'ailleurs), et ce en peu de temps au final.

Oui, tu lis bien, c'est un retour all-in-one que je m'apprête à te faire, parce que toi aussi, tu peux le faire, c'est pas si sorcier !

Allons-y, si tu veux bien.

C'est l'histoire d'un informaticien…

Introduction

Remerciements

Merci aux nombreux contributeurs de linuxfr qui ont, à leur manière, incité à ce retour d'expérience. Merci à l'équipe qui encourage à faire ce genre de retours. Et merci à ceux qui liront ce pavé de ne pas hésiter à me questionner, critiquer, proposer des pistes d'améliorations ou solutions alternatives (j'avoue très sincèrement ne pas avoir tenté de faire un comparatif).

Description du problème

…qui utilisait du scotch et des post-its. Enfin, c'est une façon de parler.

Par ((très) mauvaise) habitude, je faisais mes sauvegardes à coup de tar, du ruban adhésif donc (oui, c'est un poil tiré par les cheveux), et mes mots de passe étaient notés sur des post-it (quand même pas, mais la situation était proche).

Chaque jour était rythmé par un doux "Allez, aujourd'hui, je me lance, ça m'a l'air jouable d'après les incantations que j'ai entendu des incantations de grands savants !"

Mais en fait, je n'en savais trop rien, et surtout ni trop quoi et ni comment. Et la journée se finissait donc inlassablement par le sempiternel "Ok, là, je crois que j'ai compris, je verrai ça demain…"2

Je savais que je faisais mal, mais c'est tout, et aucune idée de par où je voulais aborder le problème. Juste que je voulais le faire. Pas forcément super bien, au top du nec plus ultra de la modernitude, mais le faire.

Environnement

État des lieux du "parc" informatique : deux machines sous linux (un fixe et un laptop, en debian stable), et un NAS sous une forme d'unix propriétaire.

Bon, c'est homogène, donc ça ne va pas trop poser de problème. Tout ce petit monde est dans le même LAN avec IP fixes, ce qui rend les choses simples aussi. Peu de chances de se lancer et de tomber sur un hic aux 3/4 du chemin.

J'utiliserai le fait que le NAS soit un unix à un moment, mais ce n'est même pas vraiment utile au final3. Ça facilite les choses, c'est tout.

Contraintes

Face aux nombreuses solutions à disposition, parfois propriétaires, d'autres juste click-click, d'autres encore en version alpha, il y en avait trop pour décider quoi que ce soit (le revers de l'homogénéité, quelque part) donc j'ai inversé le problème. On pose les contraintes, et on regarde ce qu'il reste.

Je voulais :

  • que ce soit accessible en ligne de commande,
  • que ça soit facilement installable,
  • que la sauvegarde soit facilement automatisable et concerne seulement les données d'un utilisateur,
  • synchronisable entre machines (pour la gestion des mots de passe),
  • avec peu de configuration,
  • reposant sur des outils éprouvés,
  • avec un minimum de sécurité (plus qu'un tar.gz tout moisi basique, quoi),
  • de préférence open-source,
  • si possible partageant un socle commun, éventuellement déjà plus ou moins connu.

La "wish-list" est un peu longue, mais me semble raisonnable.

Pour le socle commun, je me suis dit que comme je connaissais déjà un petit peu ssh et gpg, se baser la dessus pour la sécurité serait pas mal (mais même si on n'a jamais utilisé, ça me semble abordable).

Du coup, j'ai retenu, plus ou moins à l'instinct :

Pour gopass, ce qui m'a attiré, c'est qu'il repose sur git pour la synchronisation.

Il n'est pas forcément nécessaire de connaître git, simplement savoir créer un compte et un nouveau projet privé sur gitlab (par exemple) peut suffir, l'usage de git est masqué.

Enfin, connaître peut-être utile quand même : je suis un peu sorti des clous et ai utilisé une fonctionnalité en beta, suite à une action un peu trop rapide, et ça m'a aidé à m'en sortir sans purger la configuration et refaire les quelques étapes pour revenir à l'endroit où j'ai raté une marche.

Message important

Le tout, c'est d'être calme, et d'y aller lentement, surtout si on ne connais pas bien ou qu'on appréhende un peu les outils barbares que sont ssh, gpg ou git. Pour gpg, il faut la version 2 pour gopass.

Ne pas hésiter à prendre des notes pour bien identifier quelle clef correspond à quoi (parce que oui, j'en ai généré un petit paquet en mode en veux-tu, en voilà). Ça, ça a été une de mes erreurs avec gopass, je me suis emmêlé les moufles4 entre les clefs pour les backups et pour les mots de passe et les machines associées, du coup, en cherchant à réparer le bazar, je me suis aventuré en beta.

Bref, faisez gaffe, en y allant molo, tout se passe tranquillou. Et puis c'est pas un terminal qui fait peur, hein ? (Hein ? gloups… Confiance ! ;) ).

La suite

Les deux sections suivantes n'ont pas d'ordre de dépendance. L'un fonctionne sans l'autre, et inversement.

J'ai fait les deux (trop) en même temps à cause du socle commun : j'ai choisi de séparer les clefs plus pour plus de flexibilité, et tant
qu'à faire d'en générer un bon petit lot, autant tout faire tant que c'est chaud.

Gestion des backups

Ici, l'installation est complètement basique : c'est dans les dépots.

Configuration

Il faut se munir d'une clef ssh et d'une clef gpg par machine.

Note : Le mot de passe de la clef gpg sera en clair dans les scripts d'automatisation s'il y en a un (d'où le pourquoi je souhaite vraiment plein de clefs de partout).

Donc par machine (la clef ssh c'est uniquement pour la connection au NAS, donc fait là ou je n'en avais pas déjà une à disposition) :

$ ssh-keygen -t ed25519
$ gpg --full-generate-key

Réponse aux petites questions basiques, et c'est tout5 pour les clefs ici.

J'ai déposé la clef publique ssh pour me connecter sans entrer de mot de passe au NAS :

client$ scp .ssh/maClef.pub monUserDeBackup@monNas:~/

puis :

nas$ mkdir -p .ssh
nas$ touch .ssh/authorized_keys
nas$ cat maClef.pub >> .ssh/authorized_keys
nas$ rm maClef.pub

et enfin pour vérifier que je me connecte bien (ici j'ai pas l'identité ssh par défaut, parce que je le vaut bien) :

client$ ssh -i .ssh/maClef monUserDeBackup@monNas

Comme je suis feignantinformaticien, j'ai modifié mon .ssh/config :

Host monNas
     Hostname monNas
     User monUserDeBackup
     IdentityFile ~/.ssh/maClef

Pour faire les bacups proprement dites, maintenant, j'ai pris les premiers scripts d'exemple proposés pour pouvoir faire une version full et une version incrémentale :

$ wget http://duplicity.nongnu.org/contrib/jwfull -O /tmp/full-backup.sh
$ wget http://duplicity.nongnu.org/contrib/jwincr -O /tmp/inc-backup.sh

La variable PASSPHRASE doit contenir le mot de passe associé à la clef gpg pour duplicity pour la machine courante (et vive les notes de quoi sert pourquoi).

Il faut modifier les lignes d'appel à duplicity pour inclure/exclure ce que l'on souhaite, créer les rapports que l'on souhaite, et après, "yapukà" tester les deux scripts, sur chaque machine.

Note : le script suppose que vous pouvez envoyer des mails, et je crois que c'est une vieille syntaxe, pour la commande mail. Enfin moi, je l'ai changée6.

Je les ai rangés une fois ok dans le .local/bin/ de l'utilisateur de chaque machine (il n'y en a qu'un utilisateur à backuper, et je ne veux rien
d'autre que ses données).

Automatisation

Maintenant que c'est manuel, il faut passer aux choses sérieuses pour ne plus y penser. Donc entre systemd, vu qu'on ma dit que je pouvais dire ok, systemd, pense à faire mes backups tous les jours.

Un petit lot de .config/systemd/user/full-backup.service,
.config/systemd/user/full-backup.timer,
.config/systemd/user/inc-backup.service et
.config/systemd/user/inc-backup.timer plus tard, et c'est
toto-matique partout7.

Et voilà !

C'était pas si dur, en fait.

Gestion des mots de passe

Il s'agit ici des mots de passe. Je voulais faire toujours avec la base commune, seul gpg est utilisé au final dans la configuration pour laquelle j'ai opté. Peut-être que j'aurais pu utiliser à nouveau mon NAS et ssh, mais pour quoi faire compliqué si git permet de faire le travail de synchro ?

C'est certes pas trop fait pour du binaire, et mieux vaut garder le projet privé par sécurité, mais ça ne me semble pas introduire de trou béant niveau sécurité. Cependant je ne suis pas un dieu dans ce domaine.

Installation

Il n'y a pas (encore) de paquet debian. Ou plutôt, il y en a un, qui s'appelle gopass, mais c'est pas la même chose :)

Donc, il faut faire un peu de choses à la main (y'a un .deb quand même, c'est pas si compliqué que ça) :

# apt-get install gnupg2 git rng-tools
$ git config --global gpg.program gpg2 # pas en root, hein !
$ wget https://github.com/gopasspw/gopass/releases/download/v1.12.7/gopass_1.12.7_linux_amd64.deb
# dpkg -i gopass_1.12.7_linux_amd64.deb

Etpicétout pour l'installation.

Configuration

J'ai un compte git sur gitlab, déjà configuré avec une clef pour y accéder (enfin, une par machine, quoi). Je ne crois pas que ça change quoi que ce soit de ne pas avoir un compte autant configuré. Mais bon, ça me fait une clef de plus dans le lot, de quoi finir par s'y perdre si on ne fait pas attention :)

Et hop, c'est parti pour une clef gpg par machine :

$ gpg --full-generate-key

Réponse aux petites questions basiques, et c'est presque tout pour gpg : j'ai aussi échangé les clefs publiques entre les machines.

Pour la création du projet git associé, je suis passé simplement par l'interface web, nouveau projet, et rien de particulier de plus.

Puis, sur une machine :

$ gopass setup --crypto gpg --storage gitfs # ici, avec la clef de cette machine
$ gopass recipients add 123456789 # ici, l'id de la clef GPG pour l'autre machine

Et sur l'autre machine, simplement :

$ gopass setup --crypto gpg --storage gitfs

Ajout, synchronisation

Pour de l'utilisation basique, il n'est pas nécessaire de connaître git, un ajout se fait simplement via :

$ gopass insert linuxfr.org/creds

par exemple pour ajouter le mot de passe associé à mon utilisateur linuxfr, ou bien :

$ gopass ls

pour lister les clefs, ou encore :

$ gopass show linuxfr.org/creds

pour afficher le secret associé à cette clef.

En général, la synchro se déclenche à l'ajout, et si je veux mettre à jour pour récupérer les nouveautés, un petit gopass sync fait l'affaire.

Petites touches finales

Pour la complétion avec zsh, je me suis contenté de suivre les instructions (ce n'est peut-être pas terrible d'aller dans /usr/share/zsh/, cependant) :

$ gopass completion zsh > ~/_gopass
$ sudo mv ~/_gopass /usr/share/zsh/vendor-completions/_gopass # mettre les bons droits, aussi
$ rm -i ${ZDOTDIR:-${HOME:?No ZDOTDIR or HOME}}/.zcompdump && compinit

Une petite vérification proposée me semble pertinente (Securing Your Editor), mais je n'ai rien eu à faire de particulier. Ça serait assez dommage de laisser un trou de sécurité comme ça, par oubli (lors de l'édition, le fichier temporaire est potentiellement enregistré en clair sur disque ! Un malheureux bug pourrait l'y laisser déchiffré, potentiellement
lisible…).

Il existe aussi une interface graphique, mais que je n'ai pas exploré au delà de l'installation.

Conclusion et reste à faire

Cependant, pour être vraiment complet, il y a encore des manques :

  • vérifier régulièrement les backups, c'est mieux,
  • externaliser le stockage physique (copie des backups full), c'est à faire,
  • prévoir un mécanisme de gestion des clefs privées de backup, c'est à faire aussi. Des backups chiffrées sans possibilité de les ouvrir, c'est un peu bof
  • je ne sais pas s'il ne vaudrait pas mieux un gitlab auto-hébergé quand-même pour les mots de passe

Peut-être pour une suite ?

Donc tu vois, 'nal, toi aussi, tu peux le faire, et c'était pas si long (pour moi) !

Alors plus d'excuse et merci d'avoir lu jusque là ;)

Pense à la tête de ton ami noob, quand tu lui racontera tout ça… Rien que cette idée devrait te motiver, non ?


  1. pour les doigts qui se lémangent, je lance d'ailleurs un petit commerce… 

  2. toute ressemblance avec une sensation de déjà vu ne serait que pure coïncidence, hein ? 

  3. par contre, ça me permet de se la péter grave face à un noob : T'as vu, mes données cryptées passent en chiffré sur mon LAN local, tout ça sans jamais taper mot de passe ! T'imagine le niveau de sécurité que ça apporte ? (ne pas oublier d'en faire vraiment énormément, de glisser des trucs à propos de la DGSI, voir de la NSA et/ou faire appel à extra-terrestre si c'est un noob complotiste). 

  4. je vous ai déjà dit pour mon petit commerce ? 

  5. ça, par contre, il ne faut absolument pas le dire au noob… Nous on fait de l'incantation magique dans une fenêtre où on écrit en vert sur fond noir, nous, môssieur 

  6. déjà que le noob bave, je rajoute une petite couche avec un Tu vois, maintenant, vu que j'ai mon nom de domaine, j'ai juste eu à créer de nouveaux comptes mails, et l'expéditeur, c'est le processus, et tout tombe dans la boite mail de vérification dédiée à la sauvegarde, comme ça, je sais en permanence si c'est ok. C'est mieux qu'un gmail, tu vois ?" (je zappe quand même la notion d'adresse "catchall", parce qu'en vrai, j'ai juste rien touché de particulier et qu'en fait j'ai été infoutu d'avoir mon propre serveur de mail à moi bien configuré dans une expérience précédente) 

  7. rien de magique dans les .service et .timer, tout a été expliqué dans l'épisode pointé précédent pas de moi 

  • # Heuuu...

    Posté par  . Évalué à 7.

    Et c'est quoi le problème que tu cherches à résoudre? J'ai l'impression que c'est une histoire de backups et de gestionnaire de mot de passes mais cela reste vague.

    • [^] # Re: Heuuu...

      Posté par  . Évalué à 3. Dernière modification le 31 juillet 2021 à 22:12.

      Alors effectivement, si tu cherche un problème technique, ça va être dur, il n'y en a pas.

      C'est plus un problème de choix que j'avais, et un retour sur la simplicité effective une fois le choix fait, par rapport à une complexité attendue plus importante, le but du journal.

      Je tenterai de faire plus clair une prochaine fois !

      Matricule 23415

      • [^] # Re: Heuuu...

        Posté par  . Évalué à 4.

        Non. Je veux dire que ce que tu cherches à faire n'est pas clair. Toi tu le sais mais tu ne le dit pas explicitement.

        Après avoir parcouru ton journal plusieurs fois, j'imagine que la réponse se trouve dans ce petit bout de phrase : «Par ((très) mauvaise) habitude, je faisais mes sauvegardes à coup de tar». J'imagine que l'on peut en déduire que ton but est de mettre en place un vrai système de sauvegarde. Cela semble se confirmer par la partie «Gestion des Backups» mais soudain on voit arriver la «Gestion des mots de passe» qui semble sortir de nulle part. S'agit t'il de tes mots de passes web, git ou alors des mots de passes gpg utilisés pour chiffrer tes sauvegardes? Au final, je pense que je finis par comprendre (et il est même possible que j'essaye gopass) mais c'est un peu comme regarder lire le tome 2 d'un livre sans avoir lu le tome 1.

        • [^] # Re: Heuuu...

          Posté par  . Évalué à 6.

          Je comprend tes remarques, merci.

          J'ai hésité à faire deux journaux, cela aurait probablement aidé à clarifier les choses (mes pseudo notes sont dans deux fichiers distincts, car ce sont bien deux choses différentes qui sont adressées : les sauvegardes d'un côté, et la gestion de secrets de l'autre).

          Matricule 23415

      • [^] # Re: Heuuu...

        Posté par  . Évalué à 3.

        Non. Je veux dire que ce que tu cherches à faire n'est pas clair. Toi tu le sais mais tu ne le dit pas explicitement.

        Après avoir parcouru ton journal plusieurs fois, j'imagine que la réponse se trouve dans ce petit bout de phrase : «Par ((très) mauvaise) habitude, je faisais mes sauvegardes à coup de tar». J'imagine que l'on peut en déduire que ton but est de mettre en place un vrai système de sauvegarde. Cela semble se confirmer par la partie «Gestion des Backups» mais soudain on voit arriver la «Gestion des mots de passe» qui semble sortir de nulle part. S'agit t'il de tes mots de passes web, git ou alors des mots de passes gpg utilisés pour chiffrer tes sauvegardes? Au final, je pense que je finis par comprendre (et il est même possible que j'essaye gopass) mais c'est un peu comme regarder lire le tome 2 d'un livre sans avoir lu le tome 1.

      • [^] # Re: Heuuu...

        Posté par  . Évalué à 5.

        Je suis d'accord que c'est très confus. D'une part tu ne dis pas clairement l'objectif et d'autres part tu enchaîne les étapes sans les expliquer.

        Tu ne décrit pas duplicity et ce qu'il t'apporte. Tu l'utilise avec ssh, mais c'est loin d'être la seule façon de faire et tu l'a choisi à la place de tar hors c'est ce qu'il utilise en interne.

        La partie génération de clef, tu ne dis pas à quoi servent chaque clef. Tu commence en expliquant que tu t'es tromper en voulant tout faire d'un coup, mais tu dis ensuite autant faire tout d'un coup et tu décrit comment tout faire d'un coup.

        En soit on comprend ce que tu dis et fais quand on connaît déjà tout ça. Donc je vois pas trop l'objectif du journal :

        • tu c'est pour parler à des connaisseurs inutile d'entrer dans les détails
        • si c'est pour aider quelqu'un qui ne connaît pas, séparer gestion des mots de passe et sauvegarde et décrire ce qu'on fait (et pourquoi) avant de le faire le semble nécessaire

        En tout cas c'est super si tu es satisfait de la solution que tu as mis en place et tes content que traîner dans le coin t'ai aidé. C'est génial de vouloir partager continue !

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Heuuu...

          Posté par  . Évalué à 3.

          Mon erreur a surtout été de vouloir tout faire d'un coup sans le faire de manière posée ;)

          Oui, c'est peut-être un peu soit trop court, soit trop long. Et comme indiqué au dessus, scinder en deux aurait peut-être en partie aidé à mieux cerner les objectifs.

          Matricule 23415

  • # Quel est le gain ?

    Posté par  . Évalué à 3.

    Si je comprends bien tu as automatisé un backup sur NAS. J'imagine bien le gain en matière de satisfaction d'avoir réalisé un truc qui fonctionne comme souhaité et comme prévu. Cependant quel est le gain, du point de vue sauvegarde, sur ta procédure précédente ? Si ton NAS brûle ou si ton logement est cambriolé, est-ce que cette nouvelle procédure change quelque chose à la sécurité de tes données ?

    • [^] # Re: Quel est le gain ?

      Posté par  . Évalué à 5.

      La "procédure" précédente étant une simple création d'un tar.gz (backup complet non chiffré du home à chaque fois, contre un mix entre complet et incrémental maintenant), je gagne sur les temps d'exécution il me semble, et l'automatisation aide à ce que ça se fasse à des moments où je n'ai pas l'usage des machines à priori (là je perd en ressources CPU à cause du chiffrement). Je n'ai pas spécialement mesuré pour le temps d'exécution car ce n'est pas comparable directement et ça n'est pas un critère important pour le moment (j'arrive encore à finir un backup full avant de me lancer dans l'un incrémental suivant :p).

      Ensuite, les points de sauvegardes sont beaucoup plus rapprochés, la perte maximale sans opération en échec est de l'ordre d'un jour en théorie. Précédemment, ça se comptait plus en mois vu ma flemme, pour tout ce qui n'est pas sur un git externe. Il y a un point de sauvegarde full suivi de 6 sauvegardes incrémentales (ça, c'est dans le job systemd que c'est configuré comme ça, rien n'empêche de faire autrement à priori).

      Concernant l'externalisation des sauvegardes, c'est statut quo par rapport à avant : c'est indiqué à la fin dans le reste à faire. Il faut que j'évalue le besoin et les ressources nécessaires. Je pense que seules les sauvegardes full (donc une semaine de perte maximum) sont utiles à conserver dans mon cas. Cela peut dépendre de la destination des sauvegardes externes. Ça, c'est pour le quoi, pour le ou, je ne suis pas encore fixé, même si ça peut impacter à la marge.

      En terme de perte (vol, incendie…), comme indiqué dans le reste à faire aussi, si je perd la clef de chiffrement, les backups ne servent à rien. Là dessus, j'ai juste des pistes d'idée, le plus simple étant de stocker la clef privée dans un autre endroit hors site que le stockage de la sauvegarde elle-même. Une adaptation possible est de ne chiffrer qu'entre le NAS et le stockage externe de la sauvegarde, si l'on souhaite la chiffrer.

      Comme souvent, tout est question d'évaluation personnelle, et d'un compromis entre l'acceptable et le contraignant.

      Voila !

      Matricule 23415

      • [^] # Re: Quel est le gain ?

        Posté par  . Évalué à 3. Dernière modification le 01 août 2021 à 17:12.

        Ok, merci. J'imagine que ce que tu nommes externalisation consiste à faire à peu près la même chose que sur le NAS mais sur un serveur externe quelque part dans les nuages. Est-ce la seule façon possible de se prémunir de la destruction ou du vol de ses machines ?

        • [^] # Re: Quel est le gain ?

          Posté par  . Évalué à 3. Dernière modification le 01 août 2021 à 17:49.

          Oui, et dans mon cas, je compte même faire plus simple : juste transférer les données du backup complet (pas de relecture/chiffrement).

          Je ne suis pas certain de comprendre la dernière question, cependant. Je ne cherche pas spécialement à m'en prémunir, je cherche juste un moyen de pouvoir reconstruire sans trop de pertes autres que matérielles si jamais ça arrivait. Le risque de panne d'un disque dur est bien plus grand, et est couvert aussi par la sauvegarde.

          Il faut voir cela comme une assurance : tu n'as pas envie d'avoir un accident, c'est juste "au cas où".

          Matricule 23415

          • [^] # Re: Quel est le gain ?

            Posté par  . Évalué à 3.

            Au cas où…

            pas de relecture/chiffrement

            pas de nouveau chiffrement, puisque ce qui est prévu d'être transféré est déjà chiffré.

            Matricule 23415

  • # pass…

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Je suis allé voir le dépôt de gopass, et à la lecture j'ai l'impression que c'est un frontal pour password-store Les gens qui connaissent et utilisent aussi ce dernier peuvent confirmer ? Si c'est le cas, ça simplifie la prise en main initiale en créant le dépôt et la clé de chiffrement.

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: pass…

      Posté par  . Évalué à 3. Dernière modification le 02 août 2021 à 05:29.

      Je n'ai pas creusé la question jusque là, mais il est possible qu'au moins historiquement, ça ait été le cas. La migration depuis pass est documentée il me semble.

      En tout cas, pass n'est pas (plus ?) une dépendance, mais clairement, on retrouve la même philosophie, voir syntaxe, oui. Si on regarde les projets de gopass, il y en a un don le thème est de ne reposer que sur des implémentations en go. Ça me laisse pour le moment dubitatif sur l'intérêt.

      Je n'ai pas "recréé" l'historique, mais ça a l'air de forker et réimplémenter sévèrement dans la communauté de ces password managers ;) C'est peut-être une vision erronée de ma part.

      Matricule 23415

      • [^] # Re: pass…

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        L'intérêt peut être juste anecdotique : se faire la main avec le langage, et si c'est facile rajouter deux ou trois fonctionnalités en sus ; comme les réimplémentations en Rust…
        Après, dans le cas présent, tant ça reste compatible ça me va.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: pass…

          Posté par  . Évalué à 2. Dernière modification le 03 août 2021 à 05:28.

          Tout à fait, en soi, un fork est relativement neutre et permet plus de diversité, tant que c'est interchangeable. La raison du choix d'un langage donné m'est amplement suffisante. Une simple réécriture peut mettre en évidence des bugs à priori non identifiés.

          Je serais bien triste s'il n'existait qu'une version de linux, qu'un window manager, etc. D'ailleurs, c'est dommage qu'on ne trouve qu'emacs comme éditeur sérieux, un peu plus de concurrence serait l'occasion de plus longs échanges sur cet outil indispensable, non ?

          sifflote -> []

          Matricule 23415

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.