La courbe d’apprentissage de NixOS est généralement considérée comme plus abrupte que celle de Debian ou YunoHost, en particulier pour les utilisateurs habitués aux distributions Linux traditionnelles.
Comparaison des courbes d’apprentissage
YunoHost
YunoHost est conçu pour être facile à prendre en main, avec une courbe d’apprentissage douce. Il offre une interface web conviviale pour la gestion du système et le déploiement d’applications, ce qui le rend accessible même aux utilisateurs moins expérimentés3. Son approche simplifiée de l’auto-hébergement permet une prise en main rapide.
Debian
Debian a une courbe d’apprentissage modérée. Bien qu’elle nécessite une certaine familiarité avec la ligne de commande, elle reste relativement accessible grâce à sa documentation abondante et sa grande communauté. De nombreux utilisateurs la considèrent comme un bon point de départ pour apprendre Linux.
NixOS
NixOS présente la courbe d’apprentissage la plus raide parmi les trois :
- Paradigme déclaratif : NixOS utilise une approche déclarative pour la configuration du système, ce qui diffère significativement des méthodes traditionnelles et nécessite un changement de mentalité.
- Langage Nix : L’apprentissage du langage Nix est nécessaire pour configurer et personnaliser le système, ce qui ajoute une couche de complexité.
- Gestion des paquets : Le système de gestion des paquets de NixOS est unique et peut être déroutant pour les nouveaux utilisateurs habitués à apt ou yum.
- Documentation moins abondante : Comparé à Debian, NixOS dispose d’une documentation moins étendue et d’une communauté plus restreinte, ce qui peut ralentir l’apprentissage.
En conclusion, bien que NixOS offre des avantages significatifs en termes de reproductibilité et de gestion de configuration, sa courbe d’apprentissage est plus abrupte que celle de Debian ou YunoHost. Il nécessite un investissement initial plus important en temps et en effort pour maîtriser ses concepts et son fonctionnement.
Pardonnez le hors-sujet mais je me permets de réitérer l’avis de Deuxfleurs sur l’usage des LLM dans un autre fil de discussion :
Ce n’est pas uniquement par luddisme que Deuxfleurs refuse certaines technologies. C’est par analyse de leurs externalités par rapport à leur intérêt.
L’IA (telle qu’on la définit aujourd’hui, c’est à dire les LLMs, pas les régressions linéaires) est un désastre environnemental et social avéré par plusieurs aspects. Son coût matériel alimente des guerres terribles comme celle du Congo ; comme dit dans Barbarie Numérique : « À chaque augmentation de la demande en métaux, la violence du conflit augmente d’un cran ». Leur entraînement est réalisé aux frais de la psyché de travaileureuses du Sud paupérisé⋅es (src). Dans la dynamique de productivisme actuelle, l’IA catalyse la déqualification du travail et paupérise pour le coup les populations du Nord. Sans compter ses conséquences sur la confiance.
[…]
Nous sommes fervent⋅es de l’expérimentation (cf. Garage) : mais nous n’utiliserons pour ce faire que les rebuts électroniques de la sur-consommation. L’IA ne tourne pas sans GPU Blackwell ou équivalent. […]
Pour résumer : dans une logique de sobriété, il n’est pas entendable de se lancer sur toutes les dernières innovations technologiques quand on voit leur impacts immédiats (et qu’importent leurs bénéfices prédits). Ça peut sembler passéiste ou réfractaire ; en réalité nous sommes technocritiques.
@elloh je ne veux pas te clouer au pilori, bien sûr. Sache seulement que ce n’est pas anodin pour une partie de notre communauté de promouvoir l’IA parmi les CHATONS (ne serait-ce qu’en partageant une réponse à une question). M’intéressant de près aux conséquences sociales et environnementales dramatiques que l’usage des LLM occasionne, je le vis personnellement très mal de les voir s’immiscer ici.
On aurait pu simplement répondre à ta question, ça aurait été plus concis et intéressant que les babillages à rallonge de nos amis robots : NixOS utilise son propre langage purement fonctionnel, qui s’immisce jusqu’à l’écriture des fichiers de config de tous les logiciels (pense nginx.conf). Il y a déjà une marche à franchir pour réussir à installer un système sous NixOS, et encore quelques unes pour organiser ses fichiers de configuration .nix en fabriquant soi-même ses modules Nix.
La documentation foisonne ces temps-ci, mais elle n’est pas bien ficelée (il y en a un peu partout).
Je recommande ce récit de l’apprentissage de NixOS : How to Learn Nix (Ouaaouuuh, un lien vers une ressource externe ! Écrite par un humain 
) Il éclaire à la fois sur « comment apprendre NixOS » et sur les difficultés rencontrées ce faisant.
Ok, je comprends ton point sur l’IA et ça me met mal quand je pèse ton discours.
Je vais y réfléchir.
Merci pour ton aide sur NixOs et ton lien que je vais prendre le temps de lire.
Je ne sais pas si je dis quelque chose de terrible, mais quels seraient les avantages à utiliser NixOS sur Debian et notamment YunoHost ? Et désavantage (une complète réécriture …) ? Est-ce que le jeu pourrait en valoir la chandelle ?
Merci pour votre bienveillance
Utiliser Nix sur un système autre, ça peut servir à créer un environnement parfaitement défini pour une tâche précise (un builder, de la cross-compilation…). Mais en tant que sysadmin, tu veux l’OS, parce qu’il t’apportera la reproductibilité de la cave au grenier. Le désavantage c’est la complexité.
Chez Deuxfleurs, tous nos OS sont installés à partir de la même recette. Ils ont les mêmes OS bit à bit à l’exception de leur hostname, IP, et ce genre de variables. Cf Deuxfleurs/nixcfg: Nix system configuration for Deuxfleurs clusters - Gitea: git with a cup of coffee
D’après cet article : Docker en production : le cas d'usage de Bearstech
La technologie Docker aurait de nombreux désavantages souvent plus fort que l’avantage de la conteneurisation (reproductibilité et de la facilité de déploiement).
Notamment :
- est-ce pertinent de confier l’environnement de prod à des développeurs ?
- Docker densifie considérablement l’utilisation des ressources (par exemple, un nginx par docker contre un nginx mutualisé …)
- des problèmes potentiels de sécurité sur les données
- conteneurisation rend les interactions réseaux plus complexes à gérer
Il préconise l’infrastructure as code
Donc après la lecture de cet article, j’ai compris mon besoin … Et mon titre de ce fils de discussion : Y a-t-il des chatons qui ont une infrastructure as code pour déployer des VMs, mutualiser des ressources de façon reproductible et versionnée ?
Avez-vous une solution que vous développez en commun sur ce genre de déploiement en production (infrastructure as code sur des VMs) pour certains ou tous les logiciels libres hébergés par les chatons ?
Dans le contexte d’infrastructure as code, NixOS tire-t-il son épingle du jeu ?
La densification des ressources, c’est aussi montré comme quelque chose de positif dans l’article. Plus de services pour une VM.
Tu parles d’IaC (Infra as Code) pour déployer des VMs, au niveau du « datacenter », ou pour l’intérieur de la VM ?
Pour déployer des VMs en IaC, chez OVH par exemple, il y a l’outil OpenTofu/Terraform qui fonctionne bien.
Chez Picasoft, on utilise Docker pour l’IaC dans les VMs et on trouve que les avantages l’emportent largement sur les inconvénients.
Toute infra est différente, et je n’ai pas connaissance d’autres projets de déploiement « en commun » que Yunohost.
Docker et NixOS, déjà cités, facilitent également le déploiement des services déjà packagés.
Mettre en commun de l’IaC, c’est pas seulement une question technique, ça pose plein de questions de gouvernance, c’est super compliqué en fait. Le code est la plupart du temps partagé autour d’une organisation : pour NixOS, c’est au niveau de l’organisation NixOS. Pour Yunohost, c’est au niveau de l’organisation YunoHost. Pour Docker, c’est le plus souvent au niveau de l’organisation du logiciel, mais rien n’empêche une autre organisation d’en proposer. Picasoft en propose par exemple, quand on n’aimait pas les originaux ou quand ils n’existaient pas.
L’utilisation de Docker dépend de l’architecture logicielle et du contexte ainsi que des besoins.
L’article que j’ai cité est globalement contre l’usage systématique de Docker mais ils disent aussi qu’ils l’ont mis en oeuvre très tôt et ont une longue expérience dessus. Ils affirment aussi qu’il faut évaluer les coûts au cas par cas.
Je n’ai plus tout l’article en tête mais j’imagine que quand ils parlent d’IaC ils parlent de la mise en place du cloud et des VMs (puisqu’ils parlent de mettre un nginx pour mutualiser les ressources lorsqu’il y a une ferme de logicielle qui utilise Nginx donc pas de Docker dans la VM).
Bearstech est une scop qui fait des clouds entre autres en IaC VM ou avec Docker. Pour la reproductibilité et la diminution des coûts ils doivent surement développer aussi des IaC Cloud.
Frama.Space ou Paheko (merci pour le lien @ppom ) sont des exemples de ce que notre projet pourrait avoir envie de mettre en place si on arrive à se former sur ce genre de solution et à en comprendre/maîtriser les aspects techniques.
Il faudra pour ça que notre team s’aggrandisse et accueille de nouvelles compétences.
Voici le lien vers l’article détaillant l’architecture de Frama.Space et le process de réflexion qui y a mené : L’infrastructure technique de Framaspace - Fiat Tux (merci @ppom)
Par ailleurs, j’ai vu qu’il y a un groupe de projets GIT sur framaspace · GitLab
J’ai pas tout lu dans l’article pour le moment et peut-être que la question que je me pose trouvera une solution quand je lirai tout.
Est-ce que Paheko a réutilisé du code de Frama.Space, est-ce que ce sont les mêmes briques quand c’est applicable ou chaque cloud sont personnalisés avec du scipting spécifique qu’on ne peut de toute façon pas mutualiser (je n’ai jamais fait ça).
Je note aussi que l’hébergement indiqué est en Finlande et en Allemagne. On est plus sur de la récup d’ordinateurs. C’est un cloud chez un hébergeur qui a pignon sur rue. Est-il soucieux de son impact environnemental (c’est une question qui me concerne mais à priori dans leur FAQ l’environnement ne les concerne pas si j’ai bien vu et ils mettent plutôt l’accent sur leur site sur leur compétitivité au niveau prix) ?
à voir. En tout cas, c’est cool de voir qu’il y a du partage d’infos sur les clouds mis en place par framasoft.
Y-a-t-il d’autres chatons qui ont eu ce genre de réflexion documentée ou qui ont un travail à partager sur ce genre de choses ?
Merci pour vos retours
Pour info :
- la version vidéo by Luc : Visite des coulisses techniques de Framaspace - Framatube (juin 2023)
- ma version condensée aux JRES : Framaspace, 10 000 instances Nextcloud pour les associations - Framatube (décembre 2024)
- L’article (plus long) de Luc publié pour les JRES : https://conf-ng.jres.org/2024/document_revision_1667.html?download (décembre 2024)
Alors Paheko n’a pas du tout réutilisé du code de Framaspace. C’est l’inverse : nous avons intégré Paheko dans Nextcloud, ce qui a nécéssité des modifications de notre côté du code Paheko (propre à Framaspace), mais aussi des modifications de Paheko (merci Bohwaz !) pour que ce dernier puisse fonctionner dans Framaspace.
Note que cette intégration « fonctionne » mais reste imparfaite, car notre architecture un peu complexe ne permet pas une utilisation « telle quelle » d’une installation standard de Paheko. Donc : il reste des bugs de Paheko-dans-Framaspace qui n’existent pas dans Paheko. Cependant, ça tend petit à petit à se lisser dans le temps.
Alors oui, on (Framasoft) accueille 2 millions de personnes par mois, et donc, non, on ne va pas les héberger sur un serveur sous l’évier de la cuisine.
On a une soixantaine de serveurs dédiés pour Framasoft (dont une quinzaine pour Framaspace). Autant te dire qu’il ne se passe pas un mois sans qu’on ait des disques qui pètent, un point réseau qui lâche, et on est bien content que, quand ça arrive un jeudi soir à 20h (on ne travaille pas les V/S/D pour la plupart d’entre nous), ce soit réparé avant le lundi soir, sinon on se ferait plus qu’insulter.
Sur la question écologique, j’ai déjà répondu 1000 fois à la question, mais la pédagogie, c’est la répétition, alors allons y une 1001eme fois 
Vu les caractéristiques de nos 60 serveurs, ça doit faire en gros entre 14 700 et 47 300 kWh /an.
Mais comme notre hébergeur utilise un mix énergétique « renouvelables » (principalement de l’hydroélectrique et de l’éolien), et pas/peu de clim, d’après mes calculs à la louche, on doit tourner entre 0,27 t et 0,85 t eq CO² /an.
Allez, disons qu’on retienne le max et je vous rajoute même une banane à 0,9 t eq CO² /an.
Pour info, sur un mix énergétique « standard », on serait à 11t eq CO²/an en France, et 65t eq CO² en Allemagne « charbonnée ».
Pour rappel, un⋅e français⋅e « moyen », c’est ~9,2 t eq CO2 / an en 2022 d’apres l’ADEME
Donc, extrapolation à la con : si Framasoft était 10 fois plus gros (en termes de serveurs), ces derniers émettraient en gros autant qu’un⋅e seul⋅e français⋅e.
Bon, tous ces chiffres, en fait ça veut rien dire : on ne tient pas compte du scope 3, notamment de la production et de l’acheminement du matériel, probablement dans des porte-containers bien dégueu. En rajoutant ça, on passe en gros (Institut La Louche inside) à 30t eq CO² .
Bon, tous ces chiffres, en fait ça veut rien dire : on ne tient pas compte du fait que je t’écris d’un PC portable, ni du fait que le salarié Hetzner vient bosser en berline Mercedes alors que moi je viens au taf en vélo (oui, j’aime les clichés 
).
Bon, tous ces chiffres, en fait ça veut rien dire : compter en équivalent CO² ça veut rien dire. Ca prend pas en compte que des gamins ont probablement creusés dans des mines en RDC pour extraire des métaux qui ont servis à produire nos serveurs, avec probablement quasi rien à bouffer (alors que moi j’ai mangé du chocolat aujourd’hui pour avoir l’énergie de travailler). Et ça, ça se compte pas en équivalent CO². C’est un peu sans fin, cette histoire. On va quand même rester sur l’équivalent CO² pour faire comme tout le monde.
Bref, je vous fais l’impact équivalent tonnes équivalent CO² de Framasoft à 50t eq CO² par an, si ça vous va ?
Soit 5 ou 6 français.
C’est beaucoup.
Pour info et comparaison : Wikimedia annonçaient 3 000 t eq CO² et Google 16 124 000 t eq CO² en 2022.
Ça va, on se sent pas morveux⋅ses.
Bon, tous ces chiffres, en fait ça veut rien dire : car on sert 2 millions de personnes par mois. probablement 5 à 6 millions par an.
Donc, ça nous fait « tomber » à 0,00001 t eq CO² par an par personne « servie ». Soit 10 grammes équivalent CO² par bénéficiaire par an.
Bon, tous ces chiffres, en fait ça veut rien dire : parce que sur ces 5 à 6 millions de personnes par an, on a par exemple :
- Framatalk qui permet à des gens d’éviter des déplacements en voiture (ou même avion)
- Framateam qui permet à des gens d’éviter de s’envoyer plein de mails
- Framaspace qui permet à 2000 assos dont une part très importante travaille sur des sujets environnementaux.
- etc
- etc
Bon, tous ces chiffres, en fait ça veut rien dire : parce qu’une partie de nos serveurs sont en réemplois ; qu’on est « 0 publicité » ; « 0 capitalisme » ; ~0 voiture pour l’équipe salariée (vélotaff, piedtaff, télétravail) ; et comme je l’ai dit, on outille un paquet d’acteur⋅ices de la « transition »
Ca ne fait pas baisser notre impact produit, mais on peut dire sans rougir qu’on participe passivement aux réflexions/solutions et non au jmenfoutisme environnemental.
Tout ça c’est de la grosse louche, hein. Mais c’est pour dire qu’un serveur de plus ou de moins à Framasoft, c’est pas tout à fait la même chose qu’un serveur de plus ou de moins chez Total Energies.
Je termine en citant la Loi de Goodhart : « lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure ».
[EDIT : typos]
Merci pour ces explications sur lesquelles j’ai appris bcp de choses.
Donc si je comprends l’indicateur environnemental c’est la tonne de CO2 et y en a pas d’autres officiellement ?
Aucune organisation mondiale pour introduire des mesures alternatives sur le sujet plus représentatives ? 
Encore merci pour tes explications.
C’est une excellente question, à laquelle je n’ai pas de réponse !
Je peux juste dire que c’est la plus courante, tout simplement parce que le GIEC pointe la grande importance du CO2 dans le dérèglement climatique.
Alors je suis à peu près persuadé que le GIEC a du le faire. Par exemple sur l’acidification des océans & co. Mais je n’ai pas creusé (et surtout, j’y connais pas grand chose 
)
Il y a de nombreux « impacts environnementaux ». Le dérèglement climatique en est un, et il a le bon goût de se mesurer grâce à la métrique scalaire sympa du « gramme équivalent CO2 émis dans l’atmosphère ». Mesurer par exemple l’empreinte minérale, c’est toute une autre histoire (cf. mon article de recherche sur le sujet).
J’ai regardé rapidement le fasicule que tu proposes.
L’auto hébergement a bien l’avantage non négligeable de s’affranchir des géants du web et sûrement sans nul doute de coûter moins cher, c’est vrai.
Mais si tu comptes le temps nécessaire à faire les mises à jour système, à installer les apps etc. Tu perds l’aspect financier car la main d’oeuvre, ça coûte cher. Outre le fait qu’il faut se former pour ça en plus et donc la motivation s’en mêle fortement. Sans compter que l’aspect sécurité de l’auto-hébergement est dépendant des mises à jour logiciels et système faite par l’admin et par le système utilisé.
Pour moi, la seule solution pour amener les gens à auto-héberger est de rendre la chose possible en quelques cliques … Les gens doivent juste avoir à cliquer pour acheter le matériel et cliquer pour installer le système qui propose des packs d’applications par défaut ou un pack personnalisé en fonction du matériel sélectionné (avec des questions pour évaluer la charge d’utilisation de chaque app pour garantir une bonne expérience utilisateur).
Il faut un yunohost encore plus simple :
- qui fait les mises à jour système de sécurité automatiquement
- qui se répare automatiquement dans les cas courants (récupération backup etc.) et avec une manip simple pour les autres cas en utilisant un système de sauvegarde dans la machine ou sur une autre partition du disque.
- qui ne propose que l’installation de logiciel entièrement pris en charge (et pas de choses bancales pour éviter du style, on met l’app à dispo mais on sait que ça marche pas ou que le support n’est pas pris en charge etc.). J’ai pris ces messages avec bcp de philosophie mais pour le type d’utilisateur que vous visez avec ce système, ces messages sont très certainement frustrant voir peut-être dans le pire des cas incompréhensibles (je me rends plus vraiment compte).
Je trouve que le travail effectué sur YunoHost est déjà gigantesque et il faut le saluer. Je pense que ça va dans le bon sens et le projet a encore une longue vie devant lui pour continuer à évoluer avec les bénévoles et l’argent du financement.
En tout cas, bravo à tous les contributeurs de ce projet.
Oui globalement on est d’accord. Même si le chemin parcouru est déjà super, YunoHost (et d’autres systèmes du même genre) ont encore énormément de marge de manœuvre pour rendre l’auto-hébergement plus abordable.
Salut @elloh
Le fascicule est incomplet. Il met l’accent sur les services essentiels avec nginx-proxy-manager qui contrôle les ports 80, 443 et Pi-Hole le port 53 (DNS) afin de facilement gérer ces protocoles Web.
Tu as raison, la sécurité est rattaché à la capacité de maintenir à jour son système… Pour faciliter cela, CopyLaRadio a mis au point une procédure de jumelage de sa clef SSH avec IPFS qui permet l’accès distant sans devoir modifier les règles de routage de sa Box Internet.
Ainsi relié à notre Toile de Confiance « UPlanet Origin », chacun profite des connaissances des autres membres de notre coopérative pour monter en compétence et faire partie de l’équipe de « co-administration en essaim ». A la demande, nous organisons des formations en visio…