Journal Je teste Nixos : Ă©pisode 1 l'installation

PostĂ© par (site web personnel) . Licence CC By‐SA.
Étiquettes :
49
11
juin
2026

Bonjour Nal,

Cela faisait fort longtemps que je n'avais pas testé de distribution.

Au début du millénaire, j'étais jeune, beau (je le suis toujours d'aprÚs ma maman) et surtout j'avais du temps libre : je testais alors Knoppix, Gentoo et une petite nouvelle Ubuntu qui restera ma distrib préférée avant que Canonical ne lent chie... l'anshi... la bousille en mettant des pubs dans le terminal et des logiciels privateurs pour les paquets.

Depuis je n'installais plus que Debian Stable sur toutes mes machines.

Intrigué par le choix de la DINUM de Nixos, j'ai profité de la récupération d'un vieux PC portable pour tester cette distribution.

Un clavier AZERTY en vaut deux

ArmĂ© (扊陀) d'un CD (ć‰Šé™€ă“ă“ăŸă§)d'une clef USB, je boote sur la distribution live... je lance l'installeur et PAF :

  1. impossible d'installer Nixos hors ligne ;
  2. l'Ă©tape de configuration du clavier se fait APRES la connexion, il faut donc taper son mot de passe WIFI en qwerty sur un clavier azerty comme en 1742 ?

J'ai failli arrĂȘtĂ© lĂ , mais heureusement le bureau du live (扊陀) cd (ć‰Šé™€ă“ă“ăŸă§)usb est KDE et on peut changer la disposition du clavier.

Toutefois un tel comportement n'est pas de bon augure : il n'y a que des stazuniens qui développent Nixos ?

Des chiffres et des lettres

La suite de l'installeur est par contre une trĂšs bonne surprise: la distribution propose le chiffrement du disque et la gestion de l'hibernation (via swap). Je ne savais pas que c'Ă©tait possible !

Victor boote

Je choisis un bureau KDE Plasma, je reboote et... Ça marche ! Wayland, pipewire, systemd... Je suis sĂ»r un vrai Linux moderne !

Je veux tester le son via mon casque audio pour ne pas réveiller bébé... et PAF !

Le bluetooth n'est pas activé, mal géré... J'ai pu le faire tomber en marche en:

  1. ajoutant hardware.bluetooth = { enable = true; powerOnBoot = true;} dans mon /etc/nixos/configuration.nix ;
  2. installant un paquet kdePackages.bluedevil pour avoir une IHM ;
  3. ajoutant un autre paquet kdePackages.bluez-qt parce que paquet bluedevil ne déclare pas la lib dont il a besoin...

Bref c'est mal foutu : personne n'aime les touffes bleues chez les développeurs de Nixos ?

Qui apt ?

Maintenant que j'ai un beau bureau prĂȘt pour le bureau, j'ai voulu tester LA friture n°1 de Nixos : la gestion des paquets modernes, agiles, rĂ©volutionnaires et... PAF !

  • la recherche de paquets en ligne de commande est une fonctionnalitĂ© expĂ©rimentale, la doc indique de taper une commande longue CMB nix --extra-experimental-features "nix-command flakes" search nixpkgs nomdupaquet : heureusement il est possible d'activer ces fritures dans /etc/nixos/configuration.nix ;
  • d'ailleurs tout se fait par modification de /etc/nixos/configuration.nix suivi d'un nixos-rebuild switch, mais par dĂ©faut l'Ă©diteur de texte est... heu ben c'est quoi dĂ©jĂ  ? vi ? non ? ed ? non plus ? ah nano... Mmh comment fait pour quitter dĂ©jĂ  ? Ah oui en coupant (CTRL-X) ! Quitte Ă  prendre un Ă©diteur non standard, j'aurais aimĂ© que Nixos choisisse micro qui a le bon goĂ»t d'avoir des raccourcis normaux.
  • d'aprĂšs les logs, lors des installations je vois que beaucoup de tĂ©lĂ©chargements sont fait directement depuis github : ce n'est pas trĂšs rassurant pour la souverainetĂ© (coucou la DINUM).

Je comprends l'intĂ©rĂȘt d'une configuration centralisĂ©e et reproductible, mais je ne suis pas sĂ»r d'en profiter plus que ça Ă  l'usage.

La suite numérique au prochain numéro

C'est tout pour aujourd'hui Nal, je te tiendrais au courant de la suite de mes aventures avec Nixos dans un autre journal !

++

  • # Rabbit hole

    PostĂ© par (Mastodon) . ÉvaluĂ© Ă  5 (+3/-0).

    Bienvenu dans le trou du lapin. Je ne sais pas si tu es complétement tombé dedans (je reconnais quelques grincements de dents que je me souviens avoir eu au début), mais une fois en chute libre, difficile de revenir à une distribution non déclarative. En tout cas c'est mon expérience.
    Surtout si on a Ă  gĂ©rer plusieurs machines, c'est tout de mĂȘme drĂŽlement chouette, comme paradigme. Moi je gĂšre ma machine, mon serveur Ă  la maison, le laptop de ma compagne, le fixe de ma mĂšre Ă  distance, et la configuration WSL du PC de mon boulot Ă  travers de home-manager (oui, je sais, mais j'ai pas le choix), tout Ă  partir d'un flake unique, et c'est super chouette :)

  • # Pas prĂȘt pour le desktop ?

    PostĂ© par (Mastodon) . ÉvaluĂ© Ă  5 (+2/-0). DerniĂšre modification le 11 juin 2026 Ă  10:05.

    Si j'ai bien compris l'intĂ©rĂȘt d'une telle distribution c'est plutĂŽt pour faire des VM facilement reproductibles, avec versionnement, gestion de conf etc. plutĂŽt que pour tous les jours non ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Pas prĂȘt pour le desktop ?

      PostĂ© par (Mastodon) . ÉvaluĂ© Ă  6 (+4/-0).

      Ça dĂ©pend de ce que tu appelles "tous les jours" ou "prĂȘt pour le desktop".

      Ce n'est pas fait (et n'a jamais prĂ©tendu ĂȘtre fait) pour que Mme ou M. Michu (ou leur fils Kevin) puisse administrer leur machine familiale facilement.

      C'est plutĂŽt fait pour :

      • comme tu dis, des VM reproductibles, serveurs, etc. Machines de tests ou de prod. Le mot clĂ© est "reproductible".

      • daily-driver pour un dĂ©veloppeur qui Ă  la fois aime bidouiller (rabbit-hole comme je disais plus haut), et Ă  la fois a envie de stabilitĂ© entre deux pĂ©riodes de bidouillage (snapshots des gĂ©nĂ©rations, gestion TRES fine des versions, rollback facile, etc). Moi j'ai mes crises de geekerie, et mes pĂ©riodes plutĂŽt longues oĂč je n'ai aucune envie de toucher Ă  mon OS. Je trouve satisfaction pour ces deux cas avec Nix.
        Petit ajout pour le dev : la gestion de différents environnements avec nix-shell, flakes, etc... Tellement bon :p

      • Des machines administrĂ©es. Entreprise, administration, ou famille Michu qui a dĂ©lĂ©guĂ© l'administration de ses machines Ă  un des membres qui s'y connait, Mireille Michu par exemple. Ou Jean-Pascal Michu, choisissez qui vous voulez.

      • [^] # Re: Pas prĂȘt pour le desktop ?

        PostĂ© par (site web personnel) . ÉvaluĂ© Ă  2 (+2/-2).

        Mireille Michu par exemple. Ou Jean-Pascal Michu, choisissez qui vous voulez

        moi dans la famille Michu, je choisis Dominique ou Sydney (qui parle bien Anglais), de l'intĂ©rĂȘt des prĂ©noms Ă©picĂšnes ;-) sinon, tu as quelques prĂ©noms bretons (celtes quoi, les Ă©cossais ayant des accointances Ă©tant aussi reprĂ©sentĂ©s) si tu as l'Ăąme rĂ©gionaliste : AĂ«lig, AnaĂ«l, Isabeau, LĂ©naĂŻck, Yannick (?!).

      • [^] # Re: Pas prĂȘt pour le desktop ?

        PostĂ© par . ÉvaluĂ© Ă  1 (+1/-0).

        Pour ceux qui trouve que /etc/configuration.nix c’est trop Ă©nervant: nix profile add nixpkgs#lenomdupackage

        Pourquoi quand j’ai installĂ© nixos, la configuration du clavier Ă©tait bien l’une des premiĂšres Ă©tapes, entre le fuseau horaire et les logiciels non libre ?

        • [^] # Re: Pas prĂȘt pour le desktop ?

          PostĂ© par (Mastodon) . ÉvaluĂ© Ă  5 (+3/-0).

          Pour ceux qui trouve que /etc/configuration.nix c’est trop Ă©nervant: nix profile add nixpkgs#lenomdupackage

          Alors ça, ça marche, mais à mon humble avis, c'est une trÚs mauvaise idée.

          En gros, c'est une sorte de sudo apt install bidule, sans le sudo (donc c'est seulement installé pour le profile, donc pour l'utilisateur).
          C'est une installation impérative, on perds tous les avantages de nixos : la reproductibilité, la centralité de la configuration, etc. Si quelque-chose casse, bon courage pour comprendre pourquoi et comment !
          Si on part comme ça, autant installer ubuntu et installer des trucs via flatpack ou je ne sais quel truc qu'ils ont maintenant sous ubuntu.

          Si le but c'est de tester un logiciel avant de décider si oui ou non on l'ajoute à sa configuration permanente, on peut faire nix-shell -p bidule, tester le logiciel depuis ce shell, et il disparait à la fermeture du terminal.

      • [^] # Re: Pas prĂȘt pour le desktop ?

        PostĂ© par . ÉvaluĂ© Ă  3 (+1/-0).

        qu'est ce qui garanti la reproductivitĂ© ? on peut garantir que c'est toujours la mĂȘme version de chaque paquet qui est installĂ© ?

        • [^] # Re: Pas prĂȘt pour le desktop ?

          PostĂ© par (Mastodon) . ÉvaluĂ© Ă  3 (+1/-0).

          Alors je ne suis pas un spécialiste, mais voilà ce que j'en ai compris :

          nixpkgs est un dépÎt git de définitions de packages. C'est du code, versionné.

          Du coup, quand tu "compiles" ta config Ă©crite en langage nix, cette "compilation" (en fait ça s'appelle "dĂ©rivation" dans le jargon) sera faite Ă  partir de deux facteurs, en gros. 1: ton code de configuration, 2: le commit prĂ©cis du dĂ©pĂŽt nixpkgs Ă  partir duquel tu as construit ton systĂšme. Donc si tu re-rĂ©unis ces deux facteurs Ă  l'identique (il existe des systĂšmes pour gĂ©rer finement ça, comme flake), tu auras exactement le mĂȘme rĂ©sultat, au bit prĂšs je crois.

          AprÚs, s'il y a des gurus NixOS pour me corriger, j'ai sans doute approximé à outrance.

          • [^] # Re: Pas prĂȘt pour le desktop ?

            PostĂ© par . ÉvaluĂ© Ă  3 (+2/-0).

            2 choses.
            Soit c'est reproductible, soit c'est conforme Ă  la version exacte.
            Le mode de base c'est reproductible fonctionnellement. Faire Ă  la version exact, n'a que peut d’intĂ©rĂȘt sauf sur un flake.nix ou un shell.nix pour avoir un environnement de dĂ©veloppement 100% conforme au prĂ©-requis.

            Le code suivant fait en sorte que hypridle est actif et toujours configuré avec ces options :
            services.hypridle = {
            enable = true;
            settings = {
            general = {
            lock_cmd = "pidof hyprlock || hyprlock";
            before_sleep_cmd = "pidof hyprlock || hyprlock";
            after_sleep_cmd = "hyprctl dispatch dpms on";
            };

             listener = [
 {
 timeout = 900;
 on-timeout = "pidof hyprlock || hyprlock";
 }
 {
 timeout = 930;
 on-timeout = "hyprctl dispatch dpms off";
 on-resume = "hyprctl dispatch dpms on";
 }
 ];
 };
 };

    • [^] # Re: Pas prĂȘt pour le desktop ?

      PostĂ© par (Mastodon) . ÉvaluĂ© Ă  4 (+6/-4).

      Ah, et petit ajout, au risque de se faire moinser, d'un truc que j'expĂ©rimente un peu ces temps ci : comme toute la conf est dans un dĂ©pĂŽt, dans un langage donnĂ© et documentĂ©, la possibilitĂ© de dĂ©lĂ©guer des tĂąches d'Ă©criture de module et de dĂ©bugguage, factorisation, implĂ©mentation, etc. dans son systĂšme Ă  un agent IA, tout en gardant la sĂ©curitĂ© de pouvoir fallback (entre les gĂ©nĂ©rations et entre les commits sur le dĂ©pĂŽt de la conf), je suis en train de tester ça disais je, et j'avoue ĂȘtre assez impressionnĂ©.

      • [^] # Re: Pas prĂȘt pour le desktop ?

        PostĂ© par (site web personnel) . ÉvaluĂ© Ă  4 (+3/-1).

        j'aurais plutÎt vu des typologies de distribution pour un poste selon son utilisation ( des spins dans le langage de Fedora, mais là plutÎt comme un ansible pour déployer et bénéficier de toute la conf' pour une activité donnée) :

        • Ă©quivalent de la clef AgrĂ©g avec plein de logiciels de Maths
        • la mĂȘme chose pour physicien et chimiste, voire data scientist
        • un PC gamer : soit orientĂ© RTS1 , soit FPS2 , soit petits jeux pour patienter entre deux rĂ©unions (on a bien dit pas pendant ! :p), soit jeux pour enfants (et grands nenfants)
        • une clĂ© rescue avec tous les outils, similairement une clĂ© admin sys/rĂ©seau pour diagnostiquer ce qui ne va pas (et sa dĂ©clinaison pentesting pour Ă©valuer ce qui peut ĂȘtre amĂ©liorĂ©)
        • bref, toutes les thĂ©matiques imaginables demandant un ensemble cohĂ©rent d'outils/logiciels, permettant de l'adapter au contexte (par exemple dans notre fablab il y aurait "rĂ©installer un portable robot thymio avec tout l'environnement scratch/python dĂ©jĂ  prĂȘt :D)

        1. RTS ou jeux de stratĂ©gie pour celleux qui aiment rĂ©flĂ©chir ↩

        2. FPS pour dĂ©gommer du monstre ↩

        • [^] # Re: Pas prĂȘt pour le desktop ?

          PostĂ© par . ÉvaluĂ© Ă  2 (+0/-0).

          Tout Ă  fait d'accord.

          L'audio :)

          "Si tous les cons volaient, il ferait nuit" F. Dard

        • [^] # Re: Pas prĂȘt pour le desktop ?

          PostĂ© par (Mastodon) . ÉvaluĂ© Ă  2 (+0/-0). DerniĂšre modification le 11 juin 2026 Ă  14:15.

          Oui, c'est un peu ce que j'ai fait avec mon setup familial : en fonction de l'host cible, ce ne sont pas les mĂȘmes modules qui sont sĂ©lectionnĂ©s. Que ce soit le desktop (KDE plasma vs i3 pour mon laptop), les outils CLI + les services pour le serveur, les outils CLI sans les services web, + des outils de dev spĂ©cifiques pour le home-manager du pc du boulot... Le tout avec des modules partagĂ©s avec tout ou partie des hĂŽtes (ex bluetooth, partagĂ© par tous sauf serveur et WSL).

          Je n'ai pas encore de profil PC gamer, mon fils n'a que 6 ans, mais ça va venir... Il a bien un module minecraft, mais activé sur ma session, pas la peine qu'il ait la sienne pour le moment :)

    • [^] # Re: Pas prĂȘt pour le desktop ?

      PostĂ© par (site web personnel) . ÉvaluĂ© Ă  8 (+5/-0).

      Je prĂ©fĂšre utiliser une mĂȘme distribution sur mes ordinateurs personnels, professionnels, sur le bureau, sous mon bureau, dans un datacentre, sur une machine physique, sur une machine virtuelle... Si ça pouvait aussi tourner sur mon tĂ©lĂ©phone, ma console et ma voiture, ce serait gĂ©nial :-)

      Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

    • [^] # Re: Pas prĂȘt pour le desktop ?

      PostĂ© par (site web personnel) . ÉvaluĂ© Ă  2 (+2/-2).

      J'en suis plutĂŽt content pour un usage de tous les jours sur un ordi fixe avec un peu de Nginx.

      Par rapport à Debian ça m'a permis d'avoir qqchose de trÚs trÚs stable mais un peu plus moderne. Je n'ai pas de "doute" dans les debugs à me dire "ah mais un fichier a du rester altéré lors de telle ou telle bidouille" -> parfois activer un nouveau truc est un peu relou, parfois trÚs simple, mais une fois activé c'est activé. Définitif.

      Par ex. activer un sous domaine avec renouvellement automatique des certificats ça prends 30 sec. (Effectivement chercher un paquet en ligne de commande c'est expérimental. Oui c'est n'imp).

      Les mises Ă  jours sont un peu lentes en temps machine (vieil ordi), mais triviales en temps homme.

      j'ai un peu galéré pour compil du Rust (il y a bcp trop de méthodo différentes sous NixOS pour établir un environnement de dév Rust), mais une fois que j'ai choisi mon outil c'était une affaire passée. Je dirai qu'aprÚs quelques mois parsemés de petites galÚres, on passe à du quasi 0 maintenance - attention à l'espace disque une fois de temps en temps, un peu comme avec du flatpak.

      Et oui j'ai un peu usĂ© l'IA plus rĂ©cemment, laquelle sait dĂ©bug NixOS Ă  merveille - comme c'est un monde Ă  part, documentĂ© mais parfois difficile d'accĂšs, la capacitĂ© d'outil de recherche de l'IA fait merveille et rend NixOS ultra simple (pour quand on a pas le temps de s'amuser Ă  trouver par soi mĂȘme parce qu'il y a une fichue Ă©chĂ©ance)

    • [^] # Re: Pas prĂȘt pour le desktop ?

      PostĂ© par . ÉvaluĂ© Ă  5 (+3/-0).

      Je "gÚre" un parc de plusieurs centaines d'ordis portables sous Ubuntu 24.04, et je dois dire que la promesse de NixOS permettrait de simplifier plein d'aspects, liés à la dérive qui s'opÚre avec le temps1 et les "petites modifs locales" occasionnelles.

      1. parfois provenant de mises Ă  jour depuis Ubuntu 16 -> 18 -> 20 -> 22 -> 24. ↩

  • # bloub

    PostĂ© par (courriel, site web personnel) . ÉvaluĂ© Ă  5 (+3/-0).

    La suite de l'installeur est par contre une trĂšs bonne surprise: la distribution propose le chiffrement du disque et la gestion de l'hibernation (via swap). Je ne savais pas que c'Ă©tait possible !

    J'ai ma swap sur LVM sur LUKS avec support de l'hibernation depuis des années sous Debian stable...
    Il y a peut ĂȘtre des subtilitĂ©s si on veut utiliser Secure Boot cela dit.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # DĂ©pendance Ă  GitHub

    PostĂ© par . ÉvaluĂ© Ă  7 (+7/-0).

    d'aprÚs les logs, lors des installations je vois que beaucoup de téléchargements sont fait directement depuis github : ce n'est pas trÚs rassurant pour la souveraineté (coucou la DINUM).

    NixOS repose effectivement beaucoup (trop) sur GitHub. AprĂšs, nous pourrions tout de mĂȘme relativiser...

    Pour vulgariser, lorsque tu installes ou modifies NixOS, nixos-rebuild réalise principalement 3 étapes:

    1. Lire ta configuration afin de gĂ©nĂ©rer une recette de build. On parle d'Ă©valuation, et cela peut ĂȘtre fait manuellement via la commande nix-instantiate qui gĂ©nĂšre des "derivations".
    2. Éxecuter la recette issue de l'Ă©valuation pour construire le script de dĂ©ploiement. On parle de build/realization et cela peut ĂȘtre fait manuellement via la commande nix-store --realize derivation.drv. Dans le cas de NixOS, lorsque tu buildes ta configuration, Nix construit un script (nommĂ© switch-to-configuration) qui a pour rĂŽle de modifier ton systeme Ă  chaud (Ă©crire dans /etc, installer le bootloader, ...).
    3. Executer le script switch-to-configuration pour installer ou mettre Ă  jour ton systĂšme.

    Seules les Ă©tapes 1. et 2. ont besoin d'Internet.

    Concernant l'étape 1., Nix a besoin du dépot nixpkgs qui contient les recettes de build des paquets NixOS. Ce dépot est hebergé sur GitHub et par défault, nixos-rebuild va donc récupérer les recettes de GitHub. Cependant, si tu clones ce dépot ailleurs, tu pourrais te passer de GitHub.

    Concernant l'étape 2., nixos-rebuild va d'abord chercher des binaires préconstruits (la magie de la transparence source/binary) sur cache.nixos.org. Cela t'évite de builder localement tous les paquets dont tu as besoin. Si le paquet dont tu as besoin n'existe pas dans le cache NixOS, alors il va le construire localement. Si les sources de ce paquet sont sur GitHub, alors Nix va récupérer ces sources depuis GitHub [1].
    Ce cache n'est pas hebergé sur GitHub, mais sur le S3 d'AWS :/
    Il serait possible de se passer de ce S3 en rebuildant tous les paquets nécessaires localement ou en ayant une CI qui construit ces paquets et les expose comme cache.nixos.org.

    En conclusion, par défaut, NixOS est effectivement fortement dépendant de services extra européens mais les outils existent pour s'en passer. Et à l'échelle d'un état, ce n'est pas insurmontable (des entreprises utilisant Nix le font déjà).

    [1] une idĂ©e pourrait ĂȘtre de fallback sur Softwre Heritage si GitHub n'est pas la, mais il n'y a rien de trĂšs concret cotĂ© Nix pour l'instant (Guix est plus avancĂ© sur ce sujet).

    • [^] # Re: DĂ©pendance Ă  GitHub

      PostĂ© par (Mastodon) . ÉvaluĂ© Ă  5 (+3/-0).

      En conclusion, par défaut, NixOS est effectivement fortement dépendant de services extra européens mais les outils existent pour s'en passer. Et à l'échelle d'un état, ce n'est pas insurmontable (des entreprises utilisant Nix le font déjà).

      Est-ce que l'on sait si Securix et Bureautix feront ça ? Ce sont les deux systÚmes développés par la DINUM si j'ai bien compris, basés sur Nix.

  • # Nina

    PostĂ© par (site web personnel) . ÉvaluĂ© Ă  4 (+2/-0).

    Utilitaire pour, entre autres, chercher des paquets en ligne de commande : https://discourse.nixos.org/t/nina-a-helper-that-makes-nixos-a-cozier-place-to-live-search-install-generations-services-flakes-multi-machine-management-etc/78070

    oui cela reste une recherche en ligne, mais au moins rester dans le terminal ...

  • # zero traca et zero blabla (j'abuse un peu ;-)

    PostĂ© par . ÉvaluĂ© Ă  6 (+5/-0).

    J'utilise tous les jours professionnellement et personnellement Nixos depuis 2023 je pense.
    Nixos seul, c'est bien. Nixos+home-manager c'est mieux.

    Installation facile, j'utilise du bluetooth sans pb toute la journée sur mon laptop.

    J'écoute de la musique pour travailler, toute la journée. Aucun problÚme non plus.

    Ma stack est un peu complexe : poste chiffré, Nitrokey pour déchiffrement du disque, pour le 2FA du login. Hyprland+hypridle+hyprlock. Si tu retire la clé, le lock screen est exécuté.

    Je dis pas que c'est facile tout le temps, mais lorsque c'est fait, ça marche trÚs bien.

    Pour les paquets, perso, j'utilise fortement : https://home-manager-options.extranix.com/?query=programs.git&release=release-25.11 et https://search.nixos.org/packages

    Je l'utilise pour mon poste perso, pro et qq vps.

    Autre trÚs trÚs gros avantage : agenix. Agenix permet de stocker dans un fichier age (donc chiffrement par une clé SSH) les secrets. Tu peux sans risque avoir tout ta conf dans un depot git, y compris un mot de passe ;-)

    Dispo Ă©galement sop, mais trop complexe pour mon usage (je partage pas de secret avec d'autres personnes).

    Autre projet sympas : https://github.com/elitak/nixos-infect
    ça permet de transformer n'importe quel vm/machine en nixos. Utilisé avec succÚs sur les VPS ovh et hetzner. Tu installes en debian et tu transformes en nixos. AprÚs tu pousses tes modules et tu gagnes ton temps :)

    J'abuse de nix-shell pour des tests et j'utilise un peu flake pour avoir un truc reproductible parfaitement (genre quand je veux tester une version exact de Postgresql en parallÚle de celui qui tourne déjà sur mon poste), mais j'en ai pas trop l'usage.

    Ajoute Ă  cela la nouvelle version tous les 6 mois et un changelog complet, pour tous les jours c'est trĂšs bien.

    A++

Envoyer un commentaire

Suivre le flux des commentaires

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