Le projet NixOS a sorti le 30 décembre 2014 une version de sa distribution Linux, la 14.12 ou « Caterpillar » de son petit nom. Cette distribution, « The Purely Functional Linux Distribution », est fondée sur le système de paquets Nix et la collection de paquets Nixpkgs. Nix et Nixpkgs sont utilisables avec d'autres systèmes : Linux, OS X, voire FreeBSD.
Nix permet de gérer son système « sans effets de bord », ce qui permet notamment : des mises à jours réversibles, l'installation de paquets sans droits root, le déploiement distribué, les mélanges de paquets sources et binaires.
Sommaire
- L'écosystème Nix
- Développer avec nix, ou pourquoi je ne peux plus m'en passer
- Nouveautés dans l'écosystème nix
- Outils autour de Nix
- Dans les entrailles de Nix
L'écosystème Nix
Nix permet d'utiliser des paquets binaires, ainsi que des paquets sources, comme sous Gentoo ou Arch. Comme presque tous les systèmes de gestion de paquets, il permet la gestion des dépendances entre paquets. Ses principes de fonctionnement originaux lui permettent d'implémenter de façon sûre des fonctionnalités souvent peu stables ou absentes des autres gestionnaires de paquets. Il s'agit de la poursuite par la communauté du travail commencé par Eelco Dolstra dans sa thèse à la Technische Universiteit de Delft.
Nixos est une distribution Linux utilisant nix comme système de paquets. Elle permet des mises à jour du système réversibles : si une nouvelle version d'un paquet, du système ou de sa configuration pose problème, on peut revenir à une version précédente en une commande. Elle utilise également le langage nix pour la configuration du système, ce qui permet d'intégrer la configuration entre les différents services, mais aussi d'automatiser le redémarrage des services en fonction des changements de configuration.
L'écosystème nix va au-delà d'une simple distribution : nixops permet d'orchestrer des réseaux de machines (physiques ou virtuelles), de façon plus simple et plus fiable que les systèmes classiques tel que salt ou puppet. hydra est un système de construction continue : il s'agit d'un programme qui construit en permanence un ensemble de paquets dont on vient lui soumettre de nouvelles versions. Les paquets à construire sont spécifiés dans le langage nix.
Développer avec nix, ou pourquoi je ne peux plus m'en passer
Sus au HACKING.txt
La plupart des projets libres contiennent un fichier HACKING.txt qui indique comment créer un environnement adapté pour le développement du projet. Il faut installer la bonne version du compilateur (parfois avec le patch idoine), les bonnes bibliothèques (elles-même compilées avec les bonnes options par le bon compilateur), puis configurer le projet en fonction de l'environnement (remplacer Makefile.win95 par Makefile.posix suivant le système que l'on utilise).
En plus de ce fichier, il y a généralement une part de savoir implicite comme, par exemple, « évidemment, si tu utilise nginx au lieu de apache comme serveur web derrière un reverse proxy, il faut utiliser le correctif posté le 30/02/2003 sur le forum bulgare par BabaYaga17 et l'adapter de manière triviale à ton cas ».
nix permet de regrouper ces savoirs dans un fichier default.nix, qui indique dans quel environnement un projet est développé. Ce fichier est le même qui sera par la suite utilisé pour créer le paquet à installer. La commande nix-shell permet de se placer dans l'environnement dans lequel le paquet sera construit, qui constitue donc un environnement de développement adapté.
Par exemple nix-shell donne la bonne version de Python et des dépendances.
On peut également utiliser nix-shell pour lancer un shell où certains paquets sont localement installés. Une fois sortis du shell, il n'y a plus trace du paquet dans l'environnement «principal»
$ nix-shell -p rustc
these paths will be fetched (64.72 MiB download, 230.03 MiB unpacked):
/nix/store/fhy54j59x9mcxn9rjgi6j7w2q6xr769n-rustc-0.12.0
/nix/store/q4kb35wfj35893z8qddlil98yc1akkgc-stdenv
fetching path `/nix/store/fhy54j59x9mcxn9rjgi6j7w2q6xr769n-rustc-0.12.0'...
fetching path `/nix/store/q4kb35wfj35893z8qddlil98yc1akkgc-stdenv'...
[...]
$
On garde néanmoins une version du paquet «en cache» dans le /store/ nix. Ainsi, si l'on appelle à nouveau nix-shell avec le même argument, ou si l'on construit un paquet dépendant de celui qui est en cache, on n'aura pas à télécharger celui-ci à nouveau, ni à le reconstruire.
Le résultat : un méta-make
Là où le confort offert par nix-build et nix-shell apparaît, c'est lorsqu'on a besoin de modifier une bibliothèque dont dépend notre projet (ou tout outil utile à sa construction ou à son déploiement). Si tel est le cas, il suffit de modifier le default.nix pour indiquer de prendre la version locale de cette bibliothèque, comme indiqué ci-dessous.
todo exemple override
{src = /home/meredith/projet;}
ou
todo exemple override
{src = fetchgit {url = /home/meredith/projet; […];}
À partir de ce moment-là, nix-build agit comme un meta-make : toute modification dans le répertoire indiqué (dans l'exemple 1) ou tout commit dans le dépôt git (de l'exemple 2) provoque une recompilation de la bibliothèque, de ses dépendances inverses et du projet lui-même. On fait ainsi entre les projets ce que make fait pour les différents fichiers à l'intérieur d'un projet.
Nouveautés dans l'écosystème nix
La communauté nix continue de s'élargir : depuis la version précédente en avril 2014, de nouveaux contributeurs et contributrices l'ont rejoint et ont apporté leurs contributions sur l'un des dépôts. L'activité sur le canal irc://irc.freenode.net/nixos témoigne d'un gain de popularité avec une affluence de nouveaux utilisateurs. De même, le domaine http://www.haskell.org utilisera bientôt nixops pour orchestrer ses machines.
Du logiciel tout frais
Nixpkgs (et donc nixos) contient des versions récentes de la plupart des logiciels courants. En particulier, un système nixos 14.12 disposera de :
- Linux 3.14 (la version 4.0 est aussi disponible dans les mises à jour)
- Firefox 39 (via les mises à jour)
- Gnome 3.12
- KDE 4.14
- systemd 217
- etc.
Outils autour de Nix
Les outils autour de nix continuent de s'améliorer, en particulier ceux qui permettent d'utiliser le gestionnaire de paquets depuis la ligne de commande. Deux nouvelles surcouches autour de nix-env et nix-build font leur apparition pour les utilisateurs finaux : nox pour la recherche de paquets (et leur installation) et nix-build-view pour l'affichage de la construction des paquets.
Pour les contributeurs de nixpkgs, nox-review et nox-pr facilitent la vie.
nox
nox est une surcouche de nix-env. Cette application permet de rechercher des paquets et de les installer. La commande nox <motif> affiche une liste des paquets correspondants au motif et propose d'en sélectionner un ou plusieurs à installer.
Une commande nox --update devrait bientôt arriver et fournir une alternative plus conviviale à nix-env -u pour les mises à jour des profils utilisateurs, en permettant en particulier de voir pourquoi un paquet donné sera mis à jour.
nox est aussi nettement plus rapide que nix-env, car il garde un cache de l'ensemble des paquets disponibles.
nix-build-view en couleur
Voir l'outil nix-build-view utilisant les ncurses pour un affichage coloré.
upcast
upcast est une réécriture de nixops. Il s'agit, comme nixops, d'un outil permettant d'orchestrer un ensemble de machines (physiques ou virtuelles) par nix. On peut ainsi décrire dans un seul fichier toutes les machines et leurs relations. Par exemple, on peut définir que le serveur web de la machine A utilisera la machine B comme base de données.
Dans les entrailles de Nix
Luca Bruno alias Lethalman a posté sur son blog une série intitulée « nix pills » qui détaille, en anglais, le fonctionnement de nix. La série comporte 18 posts, depuis une présentation générale de nix, jusqu'au Pourquoi vous devriez l'essayer.
Aller plus loin
- Site officiel (1364 clics)
- Dépêche sur NixOS 14.04 (543 clics)
- NixCon 2015 Berlin en novembre (135 clics)
# Trés bon mais encore jeune.
Posté par Firwen (site web personnel) . Évalué à 10. Dernière modification le 28 juillet 2015 à 10:11.
Je m'amuse avec Nix depuis peu pour une évaluation/testing dans un environment HPC: le coté multi-utilisateur et les builds reproduisibles sont très séduisant dans ce domaine.
Les habitués de DLFP savent que je n'ai généralement pas les compliments facile, mais je dois bien avouer que je suis bluffé par certains aspects de Nix.
Nix est vraiment ce qui s'approche le plus d'un build systeme vraiment reproduisible. Je peux prendre mes nix-expressions, les copier d'une machine sous Debian à une machine sous RHEL7, Maegia, Ubuntu: je SAIS qu'elles vont compilées correctement et je SAIS que mon soft va tourner sans problème. La seule "variable" d'une plat-forme à l'autre étant la version kernel.
Ça n'a rien à voir de ce point de vue avec RPM ou Deb (qui ont leur propre avantages).
Leur approche pour avoir des installations multi-users "sure" est vraiment bien pensée.
La gestion des channels est simple et puissante, créer son propre channel est un jeu d'enfant.
Le nix shell est un vrai plaisir pour le development.
Cependant je mettrai quelques point noirs à Nix :
L'impossibilité "d'override" une derivation sans lancer la re-compilation de tout ce qui en dépend est chiante, TRES chiante. Je veux pouvoir updater la glibc ou openssl sans recompiler la moitié du monde. Je comprends parfaitement pourquoi mais la possibilité de définir une dérivation "pointer", invariable, qui sert d'intermédiaire serait vraiment la bienvenue.
La gestion des "plugins" ou "modules" est généralement assez pénible, principalement due à ce que j'ai écrit précédemment.
L'apprentissage du language en lui même peut être rebutante.
Le store path est bordélique et pas du tout auto-complétion friendly, au lieu d'utiliser une convention /nix/store/hash()-name, utiliser une convention /nix/store/name/hash ne leur aurait rien coûter.
[^] # Re: Trés bon mais encore jeune.
Posté par reno . Évalué à 1.
D'ailleurs à ce sujet là, je me demande vraiment pourquoi il y a NixOS ET GNU Guix.
Je sais bien que dans le monde Linux 'chacun fait ce qui lui plait' mais là coté dispersion des efforts ça parait quand même bizarre..
[^] # Re: Trés bon mais encore jeune.
Posté par Firwen (site web personnel) . Évalué à 6.
GNU Guix se veut GNU software centrique, avec un language d'extension en guile pour la création de paquet ( Scheme en gros ).
(mais (je (ne (suis (pas (forcement (convaincu (de (l (' (idée))))))))))
[^] # Re: Trés bon mais encore jeune.
Posté par reno . Évalué à 5.
Le coté centré sur GNU OK, ça peut être limitant, mais pour le Scheme même si je ne suis pas fana de la lisibilité des Lisp, je suis BIEN MOINS fan des 'language de configuration', je n'ai pas regardé celui de Nix mais tout ceux que j'ai rencontré sont bien pourris (Makefile et bien autre) alors peut-être que celui de Nix est l'exception mais bon, un Lisp pour faire un DSL ça paraît une bonne idée.
[^] # Re: Trés bon mais encore jeune.
Posté par Firwen (site web personnel) . Évalué à 3. Dernière modification le 29 juillet 2015 à 10:56.
C'est ton avis, et si tu as un background Scheme/Lisp, tu vois probablement les choses sous un autre angle.
Un langage de configuration / build se doit d'être accessible, lisible et facilement maintenable même par des néophytes.
Et malheureusement,à mon humble avis, Scheme ou Lisp ne le sont pas pas. La première réaction naturelle d'un développeur lambda devant un code en Scheme est similaire à celle qu'aurait Christine Boutin devant un concert du Hellfest: Une petite stupéfaction temporaire suivie d'une soudaine peur croissante :D
La toute relative popularité de "Guile" comme language de script en dit assez long à ce sujet.
[^] # Re: Trés bon mais encore jeune.
Posté par reno . Évalué à 3.
Je n'ai pas un background Scheme/Lisp, mais je me suis bien cassé les dents sur les langages de configurations 'classiques' qui semblent plus simples, mais qui ne tiennent pas la 'montée en charge'..
Mais tu as raison, le Lisp ça reste pénible à lire, dommage que les Lisp ne soient pas passé aux M-expressions ça aurait été un bon compromis..
[^] # Re: Trés bon mais encore jeune.
Posté par rpnpif . Évalué à 2.
La diversité dans le monde Linux est une force pas une faiblesse. C'est ce qui fait que chacun trouve chaussure à son pied. Pour moi, ce n'est pas bizarre mais, au contraire, c'est sensé.
Bien sûr, les projets fédérateurs comme Debian, Fedora ou d'autres sont aussi indispensables.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Trés bon mais encore jeune.
Posté par FredBezies . Évalué à -2.
Une force qui peut devenir une faiblesse si on pousse la diversité un peu trop loin.
Et ce sont les seuls qui souvent ont dépassés le cap des 5 ans d'existence. Combien de projets prometteurs sont morts avant cet age symbolique ?
Un libriste qui en a sa claque des puristes.
[^] # Re: Trés bon mais encore jeune.
Posté par Moonz . Évalué à 6. Dernière modification le 07 août 2015 à 10:40.
C’est peut-être parce que je me suis levé du pied gauche, mais ton commentaire me hérisse le poil.
Le libre ce n’est pas une organisation unifiée avec des objectifs explicites. C’est des amateurs sur leur temps libre qui s’amusent, des activistes qui veulent changer le monde, des entreprises qui croient que le libre leur permettra d’obtenir du logiciel de bonne qualité à moindre coût, des universitaires (ou autres actes de recherche non universitaires) qui l’utilisent comme canal de publication de leurs travaux, et sûrement d’autres profils auxquels je n’ai pas pensé.
La diversité que tu critiques, c’est généralement le fruit d’amateurs sur leur temps libre qui font ça pour s’amuser (et de chercheurs). Et ce n’est une faiblesse, au pire (et ça reste à démontrer) que du point de vue activiste « le logiciel libre doit Conquérir Le Monde ».
Ben tu sais quoi ? L’amateur se fiche de cet objectif. Son objectif c’est de s’amuser. Il n’a absolument aucune espèce de « devoir de mettre sa force de travail là où cela sera le plus utile à la Cause Sacrée du Logiciel Libre », comme tu le laisses sous-entendre très fort. Il ne te doit rien, il ne doit rien à qui que ce soit, et si ça l’amuse de créer une nième distribution, c’est une raison suffisante pour le faire, et je trouve franchement malsaine cette attitude qui revient à dévaloriser l’approche « logiciel libre comme un hobby »
Et c’est vrai qu’après tout, ça aurait été tellement plus utile que Linus bosse sur le Hurd au lieu de disperser tous ces précieux efforts dans un nième noyau libre, ’spa ?
[^] # Re: Trés bon mais encore jeune.
Posté par Ignatz Ledebur . Évalué à 2.
En fait, il a déjà déclaré que si BSD avait été libres à l'époque, il ne se serait probablement pas lancé dans le développement de
FreaxLinux. :)Je suis néanmoins d'accord avec toi, car je ne vois pas ce que les micro distros pour le plaisir retirent à qui que ce soit. Personne n'est obligé de les utiliser, et les grosses distros le sont précisément parce qu'elles ont de grosses communautés, c'est à dire déjà beaucoup de gens pour mettre la main à la pâte. Donc, sauf à considérer que neuf femmes enceinte font un bébé en un mois et à faire complètement abstraction du très long chemin d'intégration qu'il faut pour y avoir la main à des niveaux de développement aussi fondamentaux, ce type de reproches est effectivement assez curieux.
[^] # Re: Trés bon mais encore jeune.
Posté par FredBezies . Évalué à -1.
Ce n'est pas l'époque où les BSD libres étaient empétrées dans des procès sans fin ?
Les ressources sont infinies, c'est bien connu :)
Il est vrai qu'apporter un peu d'aide, c'est contre productif ! :)
Les distributions sont mono-blocs ? Il n'y a pas plusieurs couches ? Merdre alors.
Sinon, 95% des distributions pondues pour le plaisir, c'est une base connue avec une logithèque à peine modifiée et dans le meilleur des cas, un thème et un fond d'écran différents. Bref, un truc pondu en deux ou trois heures avec un outil à la RemasterSys.
Nix est intéressante, car elle propose des idées novatrices sur certains plans. Reste à savoir comment elle s'en sortira. Mieux que les MichuOS que j'ai décrit juste au-dessus.
Il y a sûrement un trop plein de distributions dans certains domaines. Une purge finira par arriver. C'est un mal nécessaire. Parfois, je regrette la Linux Kheops (fin des années 1990) que j'ai connu. Ou encore des projets comme Nasgaïa (vers 2004).
C'est la vie.
Un libriste qui en a sa claque des puristes.
[^] # Re: Trés bon mais encore jeune.
Posté par Ignatz Ledebur . Évalué à 5.
Non, mais comme je l'ai dit, neuf femmes enceintes ne font pas un bébé en un mois, il faut donc que les gens fonctionnent efficacement ensembles pour que la productivité soit accrue par l'arrivée d'une nouvelle personne. Or dans un cadre bénévole, ta seule rétribution est le plaisir que tu prends, si bien qu'il faut que la tâche dont tu t'occupes t'intéresse. D'où si par ex. tu as envie de t'occuper de la toolchain, tu te moques de savoir qu'on cherche du monde pour de la traduction ou le maintien de Gnome.
Je suis d'accord avec toi, mais ça fait plus d'une décennie que je suis sous Linux et le « encorunedistrokisérarien » j'ai l'impression d'avoir toujours connu. Ça fait partie de l'écosystème et c'est pas grave, car encore une fois rien n'indique que sans ça ces gens auraient contribué à autre chose. Or, que je sache, personne ne s'en prend aux informaticiens passant leur temps libre à faire du scrapbooking au lieu d'utiliser leurs compétences à coder du logiciel utile. ;)
[^] # Re: Trés bon mais encore jeune.
Posté par FredBezies . Évalué à 0.
Je n'ai jamais dit le contraire. Mais tout n'est pas du plus technique dans une distribution. La documentation ou le rapport de bug sont aussi importants que le "pissage de code".
Il n'y a pas que des bénévoles dans le libre, et heureusement :)
Dans le cas que tu cites, tu as déjà un bon niveau technique derrière, du genre bac+5 en informatique.
Sans oublier les modes dans ce domaine, comme en ce moment prendre une Archlinux ou une Manjaro pour proposer sa rolling release… En laissant tomber le projet quelques mois plus tard !
Et pourtant, cela reste un éparpillement des ressources. Que ce soit en terme de temps, de bande passante ou de dépots git / svn / mercurial.
Je suis d'accord. Mais il faut savoir faire le tri entre les projets apportant quelque chose, comme Nix, ou des distributions nous ayant quitté comme la Nasgaïa et les linux-kheops et le 350ème clone d'OS-X sur le plan de l'interface graphique.
Un libriste qui en a sa claque des puristes.
[^] # Re: Trés bon mais encore jeune.
Posté par Ignatz Ledebur . Évalué à 2.
Tout à fait, mais ici on parle des distros d'amateurs.
Pas vraiment, il suffit juste d'être rodé à LFS, qui est très bien foutu. Après savoir coder en C/C++ aide, mais c'est pas décisif.
Remplace faire du scrapbooking par voyager et mettre en ligne des tera-octets de photos pourries, c'est exactement pareil. Sans compter que les distros qui ne servent qu'à leurs auteurs vont générer un trafic insignifiant par rapport à celui des grosses distros.
Justement, si elles sont mortes c'est que le problème se résout tout seul, et il est bien possible que les gens qui y ont contribué aient acquis en pouvant travailler à des niveaux assez bas une compréhension de Linux les rendant de meilleurs contributeurs, ne serait-ce que sur les forums d'entre-aide. D'où ce n'est pas automatiquement du temps perdu pour tout le monde. Il faut àmha voir ces petites distros comme des aventures plutôt que comme des boutiques s'ajoutant dans un même quartier déjà saturé.
[^] # Re: Trés bon mais encore jeune.
Posté par FredBezies . Évalué à -1.
Qui sont parfois très bien ficelées. Ça peut arriver :D
Tellement peu au niveau du toolchain :D
Je préfère les distributions mécano un peu moins "roots", mais après chacun ses plaisirs ;)
Le problème vient de la multiplication des distros qui finit par manger une bande passante non négligeable.
Pas forcément. Elles ont voulu réinventer parfois la roue et se sont cassées les dents.
Cas qui doit être quand même plus rare. Mais restons optimistes…
Pas saturé… Qui déborde à mort serait plus adapté.
Un libriste qui en a sa claque des puristes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Trés bon mais encore jeune.
Posté par FredBezies . Évalué à -1.
C'est pratique pour s'épiler :D
Ai-je dit le contraire quelque part ?
Pas seulement. Il y a aussi une volonté constante - parfois couronnée de succès - de réinventer la roue. Mais on tombe dans le cas du proverbe : "La route de l'Enfer est pavée de bonnes intentions."
Tiens, on tombe dans le religieux, maintenant ? Je dis simplement - quel hérétique je suis - qu'il ne faut pas se disperser outre mesure. C'est tout. Et c'est sûrement un crime de lèse-"logiciel libre" que de le dire.
C'est tellement mieux de prendre des ressources, les utiliser dans son coin, au lieu de mutualiser les efforts… Tellement mieux ! :)
"nani gigantum humeris insidentes" => Des nains sur des épaules de géants, Bernard de Chartres repris par un illustre inconnu, Isaac Newton.
En clair l'amateur ne doit vraiment rien aux travaux des personnes qui l'ont précédés, vraiment ?
C'est vrai que les ressources sont infinies après tout… Ou pas :)
Pourquoi parler d'un noyau qui ne sortira finalisé qu'aux alentours des calendes grecques avec un peu de chance ?
Comme l'a précisé Linus Torvalds dans la biographie qui lui est rattaché : le principe du micro-noyau (comme GNU/Hurd), c'est très joli sur le papier, mais dans la réalité c'est une horreur à mettre au point.
Un libriste qui en a sa claque des puristes.
[^] # Re: Trés bon mais encore jeune.
Posté par Moonz . Évalué à 1.
« il ne faut pas » : au nom de quoi exactement ?
Les seules ressources qu’ils prennent c’est leur temps, qui leur appartenait déjà de base.
Les personnes qui l’ont précédé ont mis à disposition du public leurs travaux sous licence libre, c’est à dire explicitement sans aucune prétention à quelque forme rétribution que ce soit. Je confirme : ils ne leur doivent rien.
[^] # Re: Trés bon mais encore jeune.
Posté par FredBezies . Évalué à -1.
Si tu n'avais pas coupé la phrase, tu le saurais.
Sans oublier les espaces de stockage d'ISOs, parfois des dépots git pour les projets un peu plus sérieux.
Et sans les travaux qui les ont précédés, ils ne seraient rien. Et licence libre ne veut pas dire qu'on ne doit pas respecter les auteurs en question.
Merdre, serais-je un vieux con qui considère que les travaux antérieurs méritent d'être respectés et cités le cas échéant ?
Un libriste qui en a sa claque des puristes.
[^] # Re: Trés bon mais encore jeune.
Posté par Moonz . Évalué à 3. Dernière modification le 07 août 2015 à 18:12.
Ta phrase complète c’est il ne faut pas se disperser outre mesure.
Mettant de côté le caractère hautement débattable de « outre mesure », pourquoi est-ce que je ne devrai pas créer une nième distribution si ça m’amuse ? Qu’est-ce qui te rend légitime à décider de ce que je fais de mon temps libre ? La notion de gaspillage se réfère à un objectif ; une nième distribution est un gaspillage en vertu de quel objectif, et surtout, surtout, pourquoi te permets-tu de me juger sur un objectif qui n’est clairement pas le mien ? (mon objectif c’est le fun, objectif atteint, ce n’est donc pas du gaspillage). Je ne suis pas au boulot et tu n’es pas mon patron.
(je dis moi parce que je me met dans la peau d’un hobbyiste qui a publié la 1268456e distrib sur distrowatch)
Méritent oui. Doivent non.
Je respecte Linus et je suis reconnaissant pour son travail ; ça ne lui donne pas pour autant la moindre once de légitimité pour dicter ce que je dois faire de mon temps libre, et s’il trouve mon passe-temps totalement inutile et un gaspillage de mes ressources, tant pis pour lui.
Suis-je un vieux con qui considère que le sentiment d’appartenance à une communauté informelle n’est pas censé résulter en un lien de subordination ?
[^] # Re: Trés bon mais encore jeune.
Posté par FredBezies . Évalué à -2.
Voila.
Si tu veux perdre ton temps, c'est ton choix. Gaspiller la bande passante en général, bof, quoi.
L'objectif ? La démocratisation du libre avec des produits qui peuvent tenir la dragée haute au non-libre. La fête du slip, c'est tellement mieux au final :D
On vise plutôt dans les 1100 à 1200. Si on fait la somme des distributions indexées depuis 2002 par Distrowatch + celle en attente (à qui on peut rajouter 50% en comptant les distributions mortes durant leur période sur la liste d'attente), on arrive, selon les chiffres de la gazette du 3 août 2015 : 801 (indexées en 13 ans) + 262 (auxquelles on rajoute les 50% de distributions disparues avant d'être ajoutées soit 131) : 1194.
Subordination, non. Être un minimum responsable, pourquoi pas ?
Enfin, je dis cela, mais je dis rien après tout… :D
Un libriste qui en a sa claque des puristes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
# Avenir de Linux ?
Posté par Olivier . Évalué à 8.
Votre distribution me fait beaucoup penser au plan de Lennart Poettering pour l’avenir de Linux. Suivez-vous l’affaire ? Aidez-vous à œuvrer dans ce sens ? Ça avance ?
[^] # Re: Avenir de Linux ?
Posté par Yakulu . Évalué à 4.
Je suis de loin tout ça mais j'avais en effet lu cet article et des commentaires, notamment sur HN à ce sujet (1, 2).
Sans avoir à nouveau parcouru le billet en question, je relève que :
De plus, je ne suis pas sûr que ça ait beaucoup avancé depuis.
# upcast, une réécriture ?
Posté par Yakulu . Évalué à 3.
Est-ce vraiment une réécriture de NixOps ? Ce dernier me semble encore bien vivant, avec des contributeurs différents et pas forcément les mêmes objectifs. upcast a en effet l'air lié à Amazon Web Services alors que NixOps est agnostique. De plus NixOps se base sur NixOS, upcast semble davantage construit autour du gestionnaire de paquets Nix.
Dans la même veine, il y a un autre projet intéressant à suivre : disnix dont l'objectif est le déploiement de services par Nix et ses expressions dans un environnement distribué. La manuel est en ligne. Et il existe également disnixos, une extension de disnix qui se base sur NixOS et peut-être utilisé conjointement avec NixOps.
# Versions de distribution?
Posté par HeroCoder123 . Évalué à 1.
Salut, merci pour la dépêche.
A propos de la migration d'une version de NixOS a une autre:
- faut-il recompiler les logiciels tiers (non relies a NixOS)?
- les outils de la distribution sont-ils organises de la même façon que les autres logiciels (plusieurs versions dispo)?
- quel l'intérêt d'avoir des versions de NixOS plutôt qu'une sortie continue a la debian?
[^] # Re: Versions de distribution?
Posté par Yakulu . Évalué à 4.
Des personnes connaissant mieux NixOS que moi corrigeront ou complèteront sans doute.
Aucune idée. Mais si tu as fourni ta recette pour ton paquet; si une des dépendances a changé, oui, il le faudra surement. Note que :
À priori, ils sont fournis de la même manière que tout autre logiciel sous Nix, donc oui.
Debian est justement une distribution à versions stables. Certes il y a Testing et Sid, comme il y a le canal unstable de NixOS (utilisable à ce que j'en ai lu, plutôt comme Sid sous Debian que comme Experimental, avec la possibilité d'aisément revenir en arrière s'il y a casse).
L'intérêt est le même que pour les autres distributions qui choisissent de geler les versions des paquets à la sortie et de n'apporter plus que des mises à jour de sécurité : la stabilité de la version, moins de temps passé à mettre à jour, notamment ses configurations de logiciels. Le canal stable est semble-t-il surtout utilisé par ceux qui choisissent NixOS sur serveur. Pour information, voici la discussion qui a abouti à la création de versions stables.
[^] # Re: Versions de distribution?
Posté par HeroCoder123 . Évalué à 1.
Merci, la discussion est très intéressante… du coup j'ai plein d'autres questions! Je vais tester et lire la doc.
[^] # Re: Versions de distribution?
Posté par xcomcmdr . Évalué à 2.
Depuis quand Debian est une rolling release ?!
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Versions de distribution?
Posté par rpnpif . Évalué à 5.
Depuis Debian SID ?
Et partiellement encore avec la version stable suivi de «
apt-get dist-upgrade»[^] # Re: Versions de distribution?
Posté par xcomcmdr . Évalué à 0.
Ah. Ce n'est pourtant pas mentionné sur le site officiel. Et il y a des releases entre lesquelles il faut faire une mise à niveau, et un support LTS de 5 ans pour certaines.
Et quand on regarde la description de Debian Testing et Unstable, ce sont juste des étapes pour la prochaine release stable.
Bref, non, Debian n'est pas un projet centré autour d'une distribution rolling release. C'est juste qu'on peut utiliser Testing/Unstable comme tel (à ses risques et périls).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Versions de distribution?
Posté par rogo . Évalué à 7.
Oui, Unstable et Testing sont des étapes vers Stable, mais je ça me semble franchement abusif de réduire Debian à ses releases stables.
D'abord, contrairement à ce qui est écrit ci-dessus, les rolling releases sont bien mentionnées sur le site officiel : Les versions de Debian. Cette page recommande d'installer généralement "Stable", mais envisage l'installation des deux autres.
La FAQ est encore plus claire quand elle répond à la question « Quelle version de Debian (stable/testing/unstable) me convient le mieux ? » Ce qui confirme que "testing/unstable" ne sont pas juste des étapes pour la prochaine release stable mais sont explicitement envisagées pour une utilisation directe.
Donc Debian est aussi une distribution rolling release. Une preuve supplémentaire : comme pour "Stable", il y a une équipe dédiée à la sécurité de "Testing", avec un dépôt APT spécifique.
[^] # Re: Versions de distribution?
Posté par galbolle . Évalué à 3.
Ça n'est pas strictement nécessaire: si tu ne recompiles pas le logiciel tiers, la dérivation va vivre sa vie à côté de celles du système, et ses dépendances seront présentes en deux versions, l'une récente vue par le système et l'autre ancienne vue par ton logiciel tiers. Ensuite, si tu le recompiles, ton logiciel utilisera les mêmes versions des dites dépendances. La recompilation aura lieu par défaut si tu as installé ton logiciel tiers en passant par l'attribut 'environment.systemPackages' du fichier central de configuration '/etc/nixos/configuration.nix'. Si tu l'as installé avec la commande 'nix-env', alors elle n'aura lieu que si tu passes l'option '--leq' à 'nix-env -u' au moment de faire la mise à jour.
En règle générale, les paquets « application » ne sont présents dans nixpkgs qu'en une seule version, la plus récente, c'est aussi le cas pour les outils nix. En revanche, il est toujours possible de modifier les dérivations correspondantes pour installer d'anciennes versions, mais c'est périlleux: il faut qu'elles fonctionnent avec la version du langage de définition des paquets utilisée par le système.
Les versions servent à rythmer le développement: tous les 6 mois, on fait en sorte d'avoir quelque chose de propre. Du point de vue de l'utilisateur, en suivant le channel « unstable », c'est bien une sortie continue, comme avec debian.
[^] # Re: Versions de distribution?
Posté par HeroCoder123 . Évalué à 1.
Merci, d'après ce que je lis NixOS a l'air d'un très bon candidat pour gérer notre problématique: faire tourner simultanément plusieurs versions de logiciels plus ou moins récentes, sur un seul OS et gérer en interne le minimum de dépendances/compilations.
Les règles nix pointent vers les sources upstream, qu'en est-il de la pérennité de leur disponibilité, y a t-il un dépôt central? Sinon est-il possible de stocker en interne uniquement les sources utilises?
[^] # Re: Versions de distribution?
Posté par Firwen (site web personnel) . Évalué à 2.
Les "règles" s'appellent expression et ne sont rien d'autre qu'un dépots github, tu peux facilement le forker et le réutiliser à ta sauce. C'est actuellement ce que je fais.
Il n'y a que le "cache" qui est centrale, actuellement sur amazon S3/Cloudfront. Mais créer son propre cache est également relativement aisée :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.