Donnez moi un NixOS à ronger

Posté par saltimbanque (site web personnel) le 02 avril 2025 à 14:09. Édité par Benoît Sibaud et palm123. Modéré par Ysabeau 🧶. Licence CC By‑SA.

Étiquettes :

avr.

2025

NixOS

Petit aperçu de Nix : il y a plusieurs articles sympas ici, la récente revue de Seb95, à cause de laquelle je suis passé sur cette distribution il y a quelques jours (et sachant que visiblement lui n’y est pas resté!, peut-être qu’il me lit haha), ou cette revue plus ancienne, donc j’essaierai de mettre en avant d’autres aspects.

Mini histoire à zapper

Dejà reprécisons - il faut remonter à 2003 pour que Eelco Dolstra développe le gestionnaire de paquets Nix, mais la distribution, elle, NixOS date de 2006. Il y a deux versions par an, nommée YY.MM, par ex. 13.05 pour version de mai 2013 - brillant.

Pour la suite j’écrirai simplement Nix pour désigner la distribution.

En 2010 un wiki démarre. En 2013, la distribution 13.05 passe de upstart à systemd et systemd-boot au démarrage (alors appelé gummiboot). La version 13.10 est la première version stable de NixOS.
On peut noter chez la concurrence, en 2014 le lancement du projet Atomic de Red Hat.
En 2016, le wiki Nix officiel est clos et un wiki non officiel démarre…
Fedora Silverblue apparait 2018 comme projet de distinct de « Atomic ». En 2019 Open Suse démarre le projet Micro OS.
Côté Nix, en 2020 ont été intégrés les Flakes (22.05). Un installateur graphique apparait en 2022, sur la 22.05.
En 2024, le wiki Nix officiel redémarre (mais le non-officiel demeure…).

Une distribution rétro-futuriste

Dans Nix, il n’y a pas de répertoire /bin, de /sbin, de /lib ou de /usr. Tout est gardé dans un /nix/store.

Enfin moi j’ai quand même un /usr/bin/env mais j’avoue ça fait peu, ou un /bin mais qui ne contient qu’un symlink pour bash. Mais bref

Dans le /nix/store on va retrouver nos hiérarchies habituelles, rangées dans des « dérivations ». Prenons firefox : je ne l’aurai pas directement dans /usr/bin mais dans le store voici comment ça se présente

$ ls -R /nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0
/nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0:
bin  lib  share

/nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0/bin:
firefox

/nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0/lib:
firefox  mozilla

/nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0/lib/firefox:
application.ini    defaults            firefox-bin   libgkcodecs.so        libmozavutil.so   libmozwayland.so   omni.ja        Throbber-small.gif
browser            dependentlibs.list  fonts         libipcclientcerts.so  libmozgtk.so      libxul.so          pingsender     vaapitest
crashreporter      distribution        glxtest       liblgpllibs.so        libmozsandbox.so  minidump-analyzer  platform.ini
crashreporter.ini  firefox             gmp-clearkey  libmozavcodec.so      libmozsqlite3.so  mozilla.cfg        removed-files

etc.
Pour le reste c’est plus standard.

$ ls /
bin  boot  dev  etc  home  lib  lib64  lost+found  nix  proc  root  run  srv  sys  tmp  usr  var

Déclaratif

La configuration, utilisateurs réseaux paquets services saucisson fromage, tout est déclaré dans un fichier /etc/nixos/configuration.nix.
Comme définir un point de montage pour un disque ou les règles du pare-feu, qui correspondraient à du /etc sur d’autres distributions, mais aussi par exemple créer un utilisateur - ce qui correspondrait plutôt à des commandes sur d’autres distributions, comme useradd.

Quand vous « compilez » le fichier /etc/nixos/configuration.nix, Nix va s’occuper tout seul des /etc/fstab, iptables (*), /etc/group, et ainsi de suite ; en général on précise que l’on « switche » vers ce nouvel OS et Nix redémarre les services avec la nouvelle config (à vous de savoir si redémarrer des services est suffisant, ou si pour prendre en compte les changements vous préférez redémarrer la session voire reboot).

(*nftables dispo)

Exemple fstab, au lieu d’éditer fstab je mets ça dans /etc/nixos/configuration.nix

 # FSTAB
  fileSystems."/home" = {
    device = "/dev/disk/by-uuid/220260f3-a7b2-4387-9a0b-9d17c604aa18";
    fsType = "ext4";
   options = [ # If you don't have this options attribute, it'll default to "defaults" 
     # boot options for fstab. Search up fstab mount options you can use
     "users" # Allows any user to mount and unmount
     "nofail" # Prevent system from failing if this drive doesn't mount     
   ];
  };

Ou encore ma fichue imprimante Samsung
Sous Debian, j’aurai peut-être ajouté un dépôt dans /etc/apt, j’aurai rafraichi puis installé un paquet. Sous Nix j’édite le fichier.

  # Enable CUPS to print documents.
  services.printing.enable = true;
  services.printing.drivers = [ pkgs.samsung-unified-linux-driver ];

On peut même se retrouver à configuration de manière abstraite… En effet, imaginons que je configure le pare-feu : quel pare-feu suis-je en train de configurer?

networking.firewall.allowedTCPPorts = [ 80 443 ];

La documentation vous apprendra que par défaut, Nix passe par iptables pour implémenter les règles que vous précisez. Avec la directive ci-dessous, les mêmes règles seraient implémentées en se basant sur nftables.

networking.nftables.enable

Immuable

Est-ce que NixOS est immuable? On pourrait dire, comme Distro Watch, non, car on peut en réalité écrire sur la totalité du système de fichier. L’immuabilité est plutôt fonctionnelle - au sens où on ne lance pas de commande, on édite un fichier /etc/nixos/configuration.nix (que l’on peut scinder, au besoin), qui donnera toujours le même résultat. (spoil cf quand même plus bas : channel).

Retour arrière

Après construction du système, au démarrage, vous aurez le choix d’amorcer (booter) sur chaque version de l'OS que vous avez construite. On peut démarrer sur une ancienne version. Un peu comme démarrer sur une ancienne version du noyau mais appliqué à tout.

Multi-utilisateurs

Vous pouvez avoir plusieurs versions d’un paquet installées en même temps, en fonction des utilisateurs. Certainement très utile… et pas testé chez moi.

En somme

Cette page décrit bien les logiques différentes entre Nix et un système basé sur Debian pour quelques opérations courantes.

Bon clairement si le besoin c’est installer firefox et qu’on doit éditer un fichier /etc puis rebuild le système, on ne ressent pas particulièrement d’avantage à utiliser Nix vs un autre système (mais en cas de souci, vous serez bien content d’avoir le rollback…)

À noter cela dit que l’installation de paquets n’est pas vraiment plus longue. Rebâtir le système n’est pas vraiment plus long qu’un apt-get ou équivalent. Ce qui m’étonne le plus c’est que par défaut il n’y a pas de commande pour chercher des paquets (… ??!!! …bon il y a le site officiel et on peut par exemple installer nix-search-cli) .
On peut bien sûr utiliser des Flatpak si on active cette option. Par défaut si on installe GNOME, cela vient d’ailleurs avec gnome-software qui n’inclut que les Flatpak. Au moins c’est un Gnome Software léger, ça change ahem ahem…
Pour les AppImage j’en parle plus bas

Donc l’usage pour installer une application graphique ne changera pas vraiment la vie. À noter tout de même que le dépôt est particulièrement large.

Mais quid de paquets un peu plus complexes? Quand j’ai voulu installer nginx avec le TLS, j’ai eu une bonne surprise. J’imaginais une tannée du fait de devoir « passer par Nix » pour gérer tout ce qui est configuration et certificats. En effet plus question de lancer des commandes pour acquérir ou renouveler des certificats. Comment faire? Pour le coup la doc me l’a indiqué rapidement.

      security.acme.acceptTerms = true;
      security.acme.defaults.email = "mon@email.example.com";

          services.nginx = {
            enable = true;
              virtualHosts = {
                 "mon.domaine" = {
                     forceSSL = true;
                     enableACME = true;
                     root = "/var/www/mon.domaine";
              };

Et voilà! Nginx est installé, mon domaine pointe vers le bon dossier, le http redirige vers https, Nix acquiert les certificats (par défaut Let'sEncrypt mais se personnalise si on veut), et surtout Nix définit un systemd pour renouveler les certificats.

Et là on voit que Nix c’est un peu l’opposé d’une ditribution minimaliste comme Arch… Les points forts de Arch sont les points faibles de Nix et réciproquement…

À noter que /etc/nginx n’existe pas. Dans mon exemple ce sera nix/store/brxfza7n2hjy6n15ffdrb7wlr2fqygy8-nginx. conf…

$ systemctl status nginx
● nginx.service - Nginx Web Server
     Loaded: loaded (/etc/systemd/system/nginx.service; enabled; preset: ignored)
     Active: active (running) since Sat 2025-03-29 09:45:55 CET; 1 day 10h ago
 Invocation: 84e49760dcee4e5ea0a6baa79dd6ceb2
    Process: 35568 ExecReload=/nix/store/alqjcv381xp2wawjc919h1qr6p4q8gvj-nginx-1.26.3/bin/nginx -c /nix/store/brxfza7n2hjy6n15ffdrb7wlr2fqygy8-nginx.conf -t>
    Process: 35569 ExecReload=/nix/store/9m68vvhnsq5cpkskphgw84ikl9m6wjwp-coreutils-9.5/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)

Oui tout est dans le nix store, bah oui logique.

On voit aussi que cette distribution est aussi agréable qu’elle est

bien empaquetée
bien documentée (j’y reviens plus bas…)

Je nixifie tu nixifies

Définir des choses dans /etc/nixos en déclaratif plutôt que de taper des commandes ou éditer d’autres fichiers comme /etc/nginx, c’est ce qu’on appelle nixifier, qui vient du verbe galérer-de-ouf. Non je plaisante.

Cela veut dire que pour tout ce que vous pouvez faire avec les services, le paquet Nix doit proposer des options pour le faire dans /etc/nixos… Un peu effrayant au premier abord? Par ex. si je veux utiliser une fonction plus exotique de Nginx, alors la config Nix doit inclure un moyen de le spécifier, et doit inclure chaque option Nginx ??

En fait de nombreux services vont proposer d’ajouter des options « extra ». Par ex. si je veux utiliser la fonction Nginx « rate-limit » et que le paquet Nix n’a pas d’option pour ça… Eh bien je vais utiliser une directive « appendHttpConfig » qui va me permettre de directement écrire dans le nginx.conf. Comme cela je continue d’utiliser les avantages Nix, mais je peux profiter d’options non nixifiées.

     services.nginx = {
        enable = true;
    appendHttpConfig = " limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/m; " ;
          virtualHosts = {
             "mon.domaine" = {
                 forceSSL = true;
                 enableACME = true;
                 root = "/var/www/mon.domaine";
         extraConfig = "limit_req zone=mylimit;";
          };

On peut même avoir le besoin de générer un fichier /etc. Pas de souci, exemple avec fail2ban, on peut générer un fichier /etc/fail2ban/filter.d

    # Defines a filter 
    "fail2ban/filter.d/nginx-py.local".text = pkgs.lib.mkDefault (pkgs.lib.mkAfter ''
      [Definition]
failregex = ^.* \[error\] \d+#\d+: \*\d+ (\S+ )?\"\S+\" (failed|is not found) \(2\: No such file or directory\), client\: <HOST>, server\: \S*\, request: \"(GET|POST|HEAD) .*$
    '');
  };

Interdit !

Je ne vais pas rentrer dans le détail, car je suis encore débutant, mais on ne peut pas exécuter ce que l’on veut sous Nix.

$ touch holalal.sh
$ echo -e '#!/bin/sh \necho "toto"' >> holalal.sh
$ chmod +x holalal.sh
$ ./holalal.sh
bash: ./holalal.sh: Permission denied
$ bash holalal.sh 
toto

Appliqué aux AppImage, eh bien j’ai un peu galéré. Apparemment on lance $appimage-run . Pas de bol pour moi, ça ne passe pas. J’ai testé ~~deux~~ ~~trois~~ un million de trucs à l’aveuge pour le fun (extraire puis ajouter chmod+x, passer par exec, voire par du sudo oh la la pardonnez moi…) Comme Google n’était clairement pas mon ami, j’ai voulu tester d’empaqueter l’AppImage moi-même. C’était la bonne piste! Si j’étais familier avec Nix cela m’aurait pris 2s. Un petit fichier .nix de quelques lignes plus tard, je peux construire cette AppImage et cette fois la lancer.
Dans de nombreux cas vous trouverez l’ppImage déjà empaquetée.

Channel

Vous souvenez vous, Nix propose une version tous les 6 mois. Mais dites-moi… Comment met-on à jour si on lance pas de commande dans Nix et qu’on n’utilise que vi /etc/nixos/configuration.nix ?
Et là, voilà la vérité révélée : oui on utilise des commandes, et non Nix n’est pas que déclarative.
(cf par exemple https://nlewo.github.io/nixos-manual-sphinx/installation/upgrading.xml.html )

# nix-channel --add https://nixos.org/channels/*channel-name* nixos
# nixos-rebuild switch --upgrade

On peut également spécifier dans la config que l’on veut automatiquement passer sur les nouvelles versions. En attendant cela veut dire que deux fichiers /etc/nixos/configuration.nix ne correspondent pas forcément au même OS!

Note sur les channels : similairement à Debian, il y a un channel unstable si on veut passer en mode rolling.

Pour résoudre cette question des channels il y a les Flake. En gros l’idée est de préciser non seulement qu’un paquet est installé mais aussi quelle version.
https://nixos-and-flakes.thiscute.world/nixos-with-flakes/introduction-to-flakes#nix-flakes-and-classic-nix
Mais rien n’oblige à utiliser Flake.

2 wikis et 2000 manuels

Deux wikis : un wiki officiel, qui a été suspendu, car il n’était pas super à jour, du coup un wiki non officiel est apparu, puis ils ont remis le wiki officiel :O !!! du coup on a plein de manuels (utilisateur, dev, celui du gestionnaire de paquets Nix…) et deux wikis et on se retrouve à jongler.
On a l’impression d’avoir atteint le point où toute tentative d’améliorer ne fait qu’empirer. Je propose « Tools that need a manual to find the manual » ! …
Mes premières recherches sur Internet sont simplement désastreuses, je tombe sur plein de versions différentes. Et souvenez-vous que Nix est à la fois un langage, un gestionnaire, un builder, une distribution…
Peut-être que des sites pour répertorier , comme https://nixos.org/learn/ peuvent un peu aider…

xkcd

Mais à l’heure qu’il est, si Nix a un défaut c’est bien la documentation chaotique.

Et les autres bombes atomiques?

Fedora Silverblue propose aussi le retour arrière. Toutes les applications graphiques sont des Flatpak, et les applis dév utilisent le module Toolbox. Cf la présentation par Renault, plutôt historique puis pratique.
Silverblue semble avoir de larges défis à relever mais pourrait représenter l’avenir de Fedora.

Côté Open Suse atomic, il y a eu Micro OS (2019), puis Aeon d’abord basé dessus puis devenu projet indépendant pour offir GNOME. (En parallèle le projet Kalpa se développe pour le bureau KDE.) Vous pouvez lire cette revue par LWN. Sur Aeon la méthode préférée d’installation de paquets est encore Flatpak, mais il y a aussi Distrobox.

Voilà pour ce que je connais, cela mériterait bien plus!

# Vécu similaire

Posté par Andréas Livet le 02 avril 2025 à 17:51. Évalué à 6 (+5/-0).

Merci pour ce retour sur NixOS,
Il y a quelques mois j'étais passé sur mon vieux Dell Latitude E6520 (qui est encore ma bécane du quotidien) sous NixOS et j'ai vraiment pas mal galéré.
Je suis totalement fan de l'idée d'avoir tous les logiciels installés dans des "stores" individuels. Je pense que c'est LA solution pour gérer les différentes versions de logiciel, pour gérer les env de dev spécifiques, pour plein plein de choses en fait.
Par contre, c'est vrai que l'expérience avec le fichier de configuration est assez déroutante.

Les différentes cli de nix ont aussi un fonctionnement particulier et j'ai comme toi galère pour trouver les packages notamment, pareil pour la désinstallation c'est pas le même nom de package qu'il faut utiliser… Et puis il y a deux manières d'installer un package (via nix-env --install ou via nix-env -iA), bref c'est très déroutant.

Je te passe les heures passer à essayer de configurer une carte son défectueuse (bon je crois qu'il y avait un problème hardware aussi, mais pas que), la quasi impossibilité d'installer le driver nvidia pour ma vielle carte graphique, car plus compatible avec un kernel récent.

Là j'ai commencé à rentrer dans des configs assez poussées et j'ai tenté plein plein de choses, pour ne pas arriver à ce que je voulais : une sortie HDMI avec le son et la vidéo alors que j'y arrive sans aucun souci sur d'autres distos…

Et enfin, le truc qui m'a le plus dérouté c'est flake. Déjà il faut apprendre un langage de configuration de paquet, mais en plus il y a plusieurs manières de faire et flake est de ce que j'ai compris un choix un peu unilatéral du créateur… bref, ça sent le truc pas très concerté qui risque de diviser la communauté.

Quoiqu'il en soit, NixOS reste une distrib très novatrice mais encore un brin réservée à des personnes confirmés et voulant passer du temps à apprendre des nouveaux concepts.

Répondre
- [^] # Re: Vécu similaire
  
  Posté par saltimbanque (site web personnel) le 02 avril 2025 à 22:24. Évalué à 3 (+1/-0).
  
  J'imagine que Nix est condamnée à rester un poil élitiste. Editer un fichier conf dans une sorte de JSON bizarre… ça limite énormément le public.
  
  Flake, j'ai l'impression que la communauté l'adopte largement. Le problème est juste que cela rajoute encore une couche à apprendre…
  
  Répondre
  - [^] # Re: Vécu similaire
    
    Posté par Andréas Livet le 03 avril 2025 à 14:34. Évalué à 1 (+0/-0).
    
    Peut-être que NixOs a un avenir grand public avec une distro basée dessus qui automatiserai l'édition du fichier de config ?
    
    Oui c'est sur que flake a l'air d'être bien adopté, juste qu'entre temps ça fait assez bizarre d'avoir deux manières de faire la même chose.
    
    Répondre
  - [^] # Re: Vécu similaire
    
    Posté par abriotde (site web personnel, Mastodon) le 03 avril 2025 à 23:58. Évalué à 2 (+1/-0).
    
    Un poil élitiste, peut-être mais pas à disparaître. En fait le principe de Nix est celui que l’on retrouve dans la virtualisation ou l’on défini tout y compris dans un fichier (Infrastructure as Code). Et pour définir un OS, Nix à l’avantage d’être bien établi "documenté " et fonctionnel…
    
    Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
    
    Répondre
- [^] # Re: Vécu similaire
  
  Posté par Maderios le 22 avril 2025 à 13:12. Évalué à 2 (+0/-0).
  
  NixOS reste une distrib très novatrice
  
  …qui propose des paquets obsolètes
  Exemple: Calibre 7.21.0, soit 13 versions de retard par rapport à la dernière version 8.23.0
  
  Répondre
  - [^] # Re: Vécu similaire
    
    Posté par cluxter le 23 avril 2025 à 13:53. Évalué à 4 (+3/-0). Dernière modification le 23 avril 2025 à 13:54.
    
    1) NixOS n'est de loin pas moins à jour que Debian (pour reprendre la comparaison faite dans l'article), car une release majeure sort tous les 6 mois, contrairement à Debian qui sort tous les 2 ans.
    
    2) Le repo "unstable" de NixOS a la v8.2.100 de Calibre, soit seulement 1 version de retard, sachant que la dernière release qui est la v8.3.0 est sortie il y a 5 jours à peine.
    
    Il est beaucoup plus facile, propre et stable d'utiliser le repo "unstable" dans NixOS que dans Debian, et ce pour une raison simple : dans Debian, tout ce qui n'est pas dans la branche "stable" n'est pas censé être utilisé par les utilisateurs finaux, ce sont des branches de développement, pas d'utilisation.
    
    Dans NixOS, le repo "unstable" est à peu près tout aussi stable que la release "stable", car toutes les dépendances d'un paquet sont encapsulées dans ce paquet ; il n'y a donc pas de risque de se retrouver avec des bibliothèques incompatibles qui viendraient casser la stabilité du binaire. C'est tellement vrai qu'on peut utiliser un kernel du repo "unstable" et passer tout le reste en "stable", ou inversement. NixOS a une release "stable" qui sort tous les 6 mois pour permettre aux admin d'avoir une certaine stabilité et éviter des rolling releases façon ArchLinux. C'est assez logique car la philosophie de nix/NixOS c'est que tout soit le plus reproductible et stable possible. Mais ceux qui veulent une approche de type rolling release peuvent tout simplement tout basculer sur le repo "unstable", et ceux qui préfèrent une approche à la Debian peuvent rester sur le repo "stable".
    
    3) Il est très facile et rapide de soumettre un patch de mise à jour du paquet dans le repo "unstable" de NixOS qui sera vite pris en compte. En ce sens, le repo "unstable" de NixOS est plus proche du AUR de ArchLinux que de la branche "unstable" de Debian.
    
    J'utilise NixOS depuis environ 2 ans, et je fais le même reproche à cette distribution que tout le monde : le manque de documentation pédagogique, façon ArchLinux. Mais ils ont mis l'accent depuis environ 1 an sur l'amélioration de la doc justement, et c'est bien mieux qu'avant.
    
    Ce qui manque vraiment en fait, c'est un tuto qui nous prenne par la main et qui nous explique pas à pas comment nix et NixOS fonctionnent, en partant de zéro. C'est un paradigme complètement différent de ce qui existe ailleurs et donc on a besoin d'être formé.
    
    Pour ma part je ne reviendrai pas en arrière. Pouvoir passer d'une version à une autre de Python ou Node.js, tout en installant automatiquement tout l'environnement de dév quand on passe d'un projet à un autre, c'est absolument magique quand on fait du dév web/fullstack, du cloud, DevOps… C'était pas facile au début mais ça a changé ma vie, tout est tellement plus simple maintenant.
    
    Répondre
    - [^] # Re: Vécu similaire
      
      Posté par Maderios le 23 avril 2025 à 17:37. Évalué à 3 (+1/-0).
      
      dans Debian, tout ce qui n'est pas dans la branche "stable" n'est pas censé être utilisé par les utilisateurs finaux, ce sont des branches de développement, pas d'utilisation.
      
      C'est pour cette raison que j'ai quitté Debian pour utiliser Arch. NixOS semble effectivement intéressant mais, en tant qu'utilisateur de Arch, j'aurais du mal à me passer d'une vraie distribution rolling.
      
      Répondre
# Et bien je te lis!!!

Posté par seb95 (site web personnel) le 02 avril 2025 à 18:04. Évalué à 5 (+5/-1).

la récente revue de Seb95, à cause de laquelle je suis passé sur cette distribution il y a quelques jours (et sachant que visiblement lui n’y est pas resté!, peut-être qu’il me lit haha)

Et je te lis et je suis ravi de voir ce que je vois, bonne dépêches expliquant les qualités et les "défauts" de Nixos.

Je ne suis plus dessus, malgré que j'ai un œil dessus mais je suis actuellement avec une GLF-OS qui est basé dessus mais qui est une distribution où l'utilisateur n'a plus rien à faire sauf utiliser sa machine.

Mais je suis très content que mon journal de l'époque a pu faire sauter le pas.

Répondre
- [^] # Re: Et bien je te lis!!!
  
  Posté par saltimbanque (site web personnel) le 02 avril 2025 à 22:16. Évalué à 3 (+1/-0).
  
  Ah oui j'étais resté sur ton billet ou tu imaginais Arch, Gentoo ou OpenSuse, ça bouge vite! Des distribs basées sur Nix seront certainement un des moyens de la faire évoluer.
  
  En attendant je trouve qu'elle répond étrangement aux ambitions modernes malgré son âge avancé. Je redécouvre Linux.
  
  Répondre
- [^] # Re: Et bien je te lis!!!
  
  Posté par Zorro le 03 avril 2025 à 16:01. Évalué à 3 (+2/-0).
  
  Je connaissais pas ton blog, il est intéressant, bravo !
  Et il me donne envie d'essayer GLF-OS.
  Je trouve ça vraiment enthousiasmant qu'il y ait encore tant de tentatives d'essayer de nouveau modèle de constructions et de distributions Linux.
  
  Répondre
# quelques passages à éclaircir (typos et fautes)

Posté par orfenor le 02 avril 2025 à 19:06. Évalué à 5 (+3/-0). Dernière modification le 02 avril 2025 à 19:07.

Les problèmes sont en gras

Fedora Silverblue apparait 2018 comme projet de distinct de « Atomic ». En 2019 Open Suse démarre le projet Micro OS.
Côté Nix, en 2020 ont été intégrés les Flakes (22.05). Un installateur graphique apparait en 2022, sur la 22.05.
En 2024, le wiki Nix officiel redémarre (mais le nom officiel demeure…)

…

On peut même se retrouver à configuration de manière abstraite…

Répondre
# Pas immuable

Posté par mornik le 02 avril 2025 à 22:44. Évalué à 6 (+5/-0).

Nix n'est pas immuable. La preuve ? Les versions évoluent. Pour avoir de l'immuable, c'est flake qui t'oblige à préciser la version précise à installer. La différence est faible mais réelle. Des gens plus intelligent que moi l'explique mieux sur la toile.

J'utilise à titre pro et perso Nixos depuis 2 ans. Je suis incapable de revenir à une distribution classique.

home-manager est une killer feature, nix-shell aussi
Par contre c'est vrai que parfois c'est compliqué de trouver comment faire.
Il y a également quelques controverses sur le directoire de la distribution et la communauté pas toujours respectée. Je peux retrouver un blog qui en parle si besoin.

Répondre
# suckmore

Posté par devnewton 🍺 (site web personnel) le 03 avril 2025 à 09:13. Évalué à 3 (+0/-0).

Dans un monde où les technos de développement permettent de linker en statique ou de tout empaqueter dans un seul fichier, est-ce qu'une solution comme Nix n'est pas overkill ?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Répondre
- [^] # Re: suckmore
  
  Posté par mornik le 03 avril 2025 à 09:33. Évalué à 1 (+0/-0).
  
  Je pense pas.
  Un binaire peut-être linké en statique mais tu mets rarement la conf dans un binaire.
  
  Nix et Nixos te permettent de faire un "contexte".
  
  Par exemple, pour mon réseau local j'ai un grafana et plusieurs node prometheus. J'a
  
  J'ai une configuration firefox avec des extensions, des bookmarks, des moteurs de recherche :
  { config, lib, pkgs, … }:
  2 │ let
  3 │ nur = import (builtins.fetchTarball "https://github.com/nix-community/NUR/archive/master.tar.gz") {
  4 │ inherit pkgs;
  5 │ };
  6 │ in
  7 │ {
  8 │ programs.firefox = {
  9 │ enable = true ;
  10 │ profiles.default = {
  11 │ isDefault = true ;
  12 │ extensions = lib.mkIf config.programs.firefox.enable
  13 │ (with nur.repos.rycee.firefox-addons; [
  14 │ french-dictionary
  15 │ i-dont-care-about-cookies
  16 │ ublock-origin
  17 │ privacy-badger
  18 │ keepassxc-browser
  19 │ clearurls
  20 │ decentraleyes
  21 │ floccus
  22 │ ]);
  23 │ search = {
  24 │ force = true;
  25 │ default = "Google";
  26 │ engines = {
  27 │ "Nix Packages" = {
  28 │ urls = [{
  29 │ template = "https://search.nixos.org/packages";
  30 │ params = [
  31 │ { name = "type"; value = "packages"; }
  32 │ { name = "query"; value = "{searchTerms}"; }
  33 │ ];
  34 │ }];
  35 │ icon = "${pkgs.nixos-icons}/share/icons/hicolor/scalable/apps/nix-snowflake.svg";
  36 │ definedAliases = [ "@np" ];
  37 │ };
  38 │ "NixOS Wiki" = {
  39 │ urls = [{ template = "https://nixos.wiki/index.php?search={searchTerms}"; }];
  40 │ iconUpdateURL = "https://nixos.wiki/favicon.png";
  41 │ updateInterval = 24 * 60 * 60 * 1000;
  42 │ definedAliases = [ "@nw" ];
  43 │ };
  44 │ "Wikipedia (en)".metaData.alias = "@wiki";
  45 │ "Google".metaData.hidden = false;
  46 │ "Amazon.com".metaData.hidden = true;
  47 │ "Bing".metaData.hidden = true;
  48 │ "eBay".metaData.hidden = true;
  49 │ };
  50 │ };
  51 │
  52 │ bookmarks = [
  53 │ {
  
  Côté serveur, je vais faire un fichier nix, avec par exemple toute ma conf nginx. C'est à dire que je vais avoir dedans le fait de vouloir avoir nginx mais aussi les vhost. Le tout dans un git :
  config, pkgs, ... }: 2 │ 3 │ { 4 │ # Activation de nginx 5 │ services = { 6 │ nginx = { 7 │ enable = true; 8 │ 9 │ virtualHosts = { 10 │ "atlanticaweb.fr" = { 11 │ root = "/srv/www/mondomaine.fr"; 12 │ enableACME = true; 13 │ forceSSL = true; 14 │ }; 15 │ # Redirection www vers domaine nu 16 │ "www.mondomaine.fr" = { 17 │ enableACME = true; 18 │ forceSSL = true; 19 │ globalRedirect = "mondomaine.fr"; 20 │ }; 21 │ "git.atlanticaweb.fr" = { 22 │ enableACME = true; 23 │ forceSSL = true; 24 │ 25 │ locations."/" = { 26 │ proxyPass = "http://localhost:3001"; 27 │ proxyWebsockets = true; 28 │ extraConfig = '' 29 │ proxy_set_header Host $host; 30 │ proxy_set_header X-Real-IP $remote_addr; 31 │ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 32 │ proxy_set_header X-Forwarded-Proto $scheme; 33 │ ''; 34 │ }; 35 │ }; 36 │ "bookmark.mondomaine.fr" = { 37 │ enableACME = true; 38 │ forceSSL = true; 39 │ 40 │ locations."/" = { 41 │ proxyPass = "http://localhost:8080"; 42 │ proxyWebsockets = true; 43 │ extraConfig = '' 44 │ proxy_set_header Host $host; 45 │ proxy_set_header X-Real-IP $remote_addr; 46 │ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 47 │ proxy_set_header X-Forwarded-Proto $scheme; 48 │ ''; 49 │ }; 50 │ };
  
  Répondre
  - [^] # Re: suckmore
    
    Posté par mornik le 03 avril 2025 à 09:38. Évalué à 2 (+1/-0).
    Tu peux aussi créer un environnement de dev pour un projet. Par exemple :
    { pkgs ? import { } }:
```
pkgs.mkShell {
  # nativeBuildInputs is usually what you want -- tools you need to run
  nativeBuildInputs = with pkgs; [
    # go development
    go
    go-outline
    gopls
    gopkgs
    go-tools
    delve
  ];

  #hardeningDisable = [ "all" ];
}
```
    Ajoute en plus direnv et un fichier .envrc qui contient use_nix et quand tu entre dans le répertoire, il va te charger automatiquement le contexte go ci-dessus.
    
    Imagine ça avec ruby ou python ou le besoins d'une version particulière de ton compilateur et tu dispose d'un environnement dev aux petits oignons.
    
    Le plus dure c'est d'apprendre nix je trouve.
    Répondre
    - [^] # Re: suckmore
      
      Posté par devnewton 🍺 (site web personnel) le 03 avril 2025 à 14:37. Évalué à 2 (+0/-1).
      
      Imagine ça avec ruby ou python ou le besoins d'une version particulière de ton compilateur et tu dispose d'un environnement dev aux petits oignons.
      
      Justement je n'imagine pas : je fais du Go ou du Java, j'utilise la dernière version stable fournie par ma distribution et si j'ai des besoins particulier, je change des variables d'environnement. Bref j'utilise des technos et des méthodes KISS :-)
      
      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      
      Répondre
      - [^] # Re: suckmore
        
        Posté par saltimbanque (site web personnel) le 04 avril 2025 à 19:10. Évalué à 3 (+1/-0).
        
        Je ne sais pas si on peut dire que Nix est trop complexe techniquement par opposition au principe KISS.
        
        Quelque part c'est simple : tout changement est dans nix store, et l'OS va choisir quel nix store. Élémentaire.
        
        Car si je regarde les autres Linux cherchant à implémenter imputabilité, atomicité, reproductibilité, etc.., j'ai l'impression qu'on aboutit a qqchose de pire
        
        Répondre
# Interrogation sur les limitations d'exécution

Posté par barmic 🦦 le 03 avril 2025 à 16:49. Évalué à 2 (+0/-0).

Je ne vais pas rentrer dans le détail, car je suis encore débutant, mais on ne peut pas exécuter ce que l’on veut sous Nix.

Je ne connaissais pas cette limitation. Je crée presque perpétuellement des scripts. Du coup ajouter, même si c’est facile, me semble extrêmement pénible. Tu as un lien qui explique ça ?

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

Répondre
- [^] # Re: Interrogation sur les limitations d'exécution
  
  Posté par mornik le 04 avril 2025 à 10:13. Évalué à 4 (+3/-0).
  
  Tu peux exécuter ce que tu veux, du moment que tu le fais bien.
  pour un script bash :
  
  #!/bin/bash
  
  ça ça marche pas
  
  #!/usr/bin/env bash
  
  ça ça marche
  
  Répondre
  - [^] # Re: Interrogation sur les limitations d'exécution
    
    Posté par barmic 🦦 le 04 avril 2025 à 11:08. Évalué à 3 (+1/-0).
    
    Ah oui c’est juste une question de leur arborescence atypique. Rien de si bizarre là dedans
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    
    Répondre
- [^] # Re: Interrogation sur les limitations d'exécution
  
  Posté par François Chaix (site web personnel) le 07 avril 2025 à 22:28. Évalué à 2 (+1/-0).
  Tu peux aussi directement "nixifier" tes scripts dans ta configuration, système ou utilisateur (avec home-manager) :
```
{ pkgs, ... }:

let
  helloWorld = pkgs.writeShellScriptBin "helloWorld" ''
    echo Hello World
  '';

in {
  environment.systemPackages = [ helloWorld ];
}
```
  (Source)
  
  Il y a aussi les writers, que je n'ai pas la prétention de savoir expliquer avec précision, pour intégrer à peu près n'importe quel langage dans un script nix, un peu comme writeShellScriptBin pour bash.
  Voir cette vidéo (youtube) qui explique tout ça bien mieux que moi.
  
  La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.
  Répondre
  - [^] # Re: Interrogation sur les limitations d'exécution
    
    Posté par barmic 🦦 le 07 avril 2025 à 23:29. Évalué à 2 (+0/-0).
    
    Jamais de la vie. Si je dois me fader une surcouche pour un script qui à une durée de vie de tout juste quelques dizaines de minutes c'est un nogo pour moi. Si j'avais installé nix et que je découvrais ce genre de limitation (qui n'en sont pas en fait c'est juste qu'il faut écrire ces scripts de manière portable si j'ai bien compris), j'aurais arrêté ce que j'étais entrain de faire pour réinstaller ma debian de toujours et je ne serais plus jamais allé voir cette distrib'.
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    
    Répondre
    - [^] # Re: Interrogation sur les limitations d'exécution
      
      Posté par mornik le 08 avril 2025 à 16:51. Évalué à 2 (+1/-0).
      
      D'ailleurs c'est pas qqch de si étrange : https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my
      
      Répondre
    - [^] # Re: Interrogation sur les limitations d'exécution
      
      Posté par cluxter le 23 avril 2025 à 14:03. Évalué à 2 (+1/-0).
      Ce n'est valable que pour les scripts que tu souhaites intégrer au système d'une façon ou d'une autre.
      Si tu veux lancer un script à la main du genre :
      
      $ python hello.py
      
      ou
      
      $ ./hello.sh
      
      bah tu peux (encore heureux !).
      Répondre
# Correction orthographique

Posté par ElVirolo (site web personnel) le 04 avril 2025 à 11:08. Évalué à 3 (+1/-0).

s/Côté Nix, en 2020 ont été intégrés les Flakes (22.05). Un installateur graphique apparait en 2022, sur la 22.05.
En 2024, le wiki Nix officiel redémarre (mais le nom officiel demeure…)/
Côté Nix, en 2020 ont été intégrés les Flakes (22.05). Un installateur graphique apparaît en 2022, sur la 22.05.
En 2024, le wiki Nix officiel redémarre (mais le non-officiel demeure…).

Répondre
- [^] # Re: Correction orthographique
  
  Posté par Benoît Sibaud (site web personnel) le 04 avril 2025 à 11:48. Évalué à 4 (+1/-0).
  
  L'accent circonflexe sur apparaît n'est plus nécessaire depuis la réforme de l'orthographe de 1990.
  https://fr.wikipedia.org/wiki/Rectifications_orthographiques_du_fran%C3%A7ais_en_1990
  
  Répondre
  - [^] # Re: Correction orthographique
    
    Posté par ElVirolo (site web personnel) le 07 avril 2025 à 15:24. Évalué à 3 (+1/-0).
    
    Entendu, mais mon commentaire portait surtout sur « non-officiel » et sur le point à la fin de la phrase. Merci !
    
    Répondre
    - [^] # Re: Correction orthographique
      
      Posté par Benoît Sibaud (site web personnel) le 07 avril 2025 à 15:48. Évalué à 5 (+2/-0). Dernière modification le 07 avril 2025 à 15:49.
      
      Oumph : c’est mes yeux ou quoi ?
      ElVirolo : Je crois que ça doit être vos yeux!
      Oumph : Ah, ouais, c’est mes yeux, ouais !
      
      (Les Bronzés font du ski^Wweb)
      
      Répondre
      - [^] # Re: Correction orthographique
        
        Posté par ElVirolo (site web personnel) le 07 avril 2025 à 15:58. Évalué à 2 (+0/-0).
        
        Je serais bien mal placé pour te le reprocher ! Merci encore.
        
        Répondre
# Avis mitigé

Posté par Sacha Trémoureux (site web personnel) le 07 avril 2025 à 22:41. Évalué à 2 (+1/-0).

J’ai fait une tentative il y a quelques mois, j’en suis sorti assez mitigé.

J’adhère totalement à la philosophie et aux promesses : bossant avec du Ansible, Terraform, K8s… avoir un OS en déclaratif me semble une très bonne voie.

Mais pwah… j’étais peut-être pas dans un bon mood pour apprendre de nouvelles choses mais j’ai eu que des impressions négatives à la pratique. La documentation est attroce, je suis vraiment fâché avec la syntaxe, les histoires de Flakes qui est en experimental mais utilisé partout… C’est lent aussi pour rebuild (mais je dois rater un truc).

J’ai le feeling d’un outil des années 90 mais avec des objectifs bien modernes, au point que si je trouve un autre OS qui souhaite faire la même chose j’en serais ravi.

En attendant, réinstaller mes PC n’est vraiment pas si long en utilisant Chezmoi et arch-install donc j’ai pas assez d’incitation à insister. Et côté serveurs, y’a beaucoup d’outils pour s’en sortir surtout à l’ère du tout-conteneur.

En tout cas c’est chouette d’avoir des nouvelles choses, ça fait murir les idées et tout le monde y gagne.

Répondre

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.