galbolle a écrit 135 commentaires

nixos sait faire des containers.

Sous nixos, sans être root, et sans (techniquement) installer faketime ;) :
$ nix-shell -p libfaketime --command "faketime '00:30:00' man"
gimme gimme gimme
Quelle page de manuel voulez-vous ?

La solution ici serait de faire un «override» local du paquet, comme expliqué ici. L'exemple qui est donné dans le manuel change la source du paquet (en l'occurence pour construire emacs à partir des sources locales). Pour patcher un fichier au moment de la construction du paquet, il faudrait utiliser un truc comme suit:

   environment.systemPackages = [
      (pkgs.xorgserver.overrideAttrs (oldAttrs: {
        patches = oldAttrs.patches ++ [ /path/to/mes/modifications/de_symbols_fr.patch ];
      }))
    ];

Malheureusement, ça va imposer des reconstructions de plein de chose (a minima, xorg lui-même), car nix ne sait pas à l'avance quelle seront les conséquences de ce changement dans un fichier des sources (seront-elles bénignes ou radicales), donc il considère qu'il doit reconstruire tout ce qui dépend de xorg.

Je ne suis pas sûr de comprendre exactement la question, mais les paquets python et perl sont des paquets comme les autres. Si tu indiques ce que tu cherches à faire, je pourrais certainement répondre plus précisément.

A propos de la migration d'une version de NixOS a une autre:
- faut-il recompiler les logiciels tiers (non relies a NixOS)?

Ç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.

• les outils de la distribution sont-ils organises de la même façon que les autres logiciels (plusieurs versions dispo)?

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.

• quel l'intérêt d'avoir des versions de NixOS plutôt qu'une sortie continue a la debian?

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.

Tout comme ces héros du service public qui à quelques un tiennent des services entiers, à côté d'une ribambelles de collègues disons moins efficaces …

Que dire de ces services entiers qui tiennent grâce à des collectifs, et qu'on cherche à casser par une vulgate individualiste articulée avec la dégradation de leurs conditions de travail? Il me semble en connaître quelques-uns.

Et les agents conversationnels?

Je parie que si on revient aux règles précédentes, il n'y aura plus de "grèves".
Bizarrement, quand on ne touchait pas leur truc, sans pour autant parler des deux points cités, pas de grève. Oups.

Certes, jusque-là ils n'avaient pas utilisé la grève, qui est un moyen d'action parmi d'autres. C'est aussi qu'on ne peut pas se mettre en grève tous les jours pendant 10 ans. Ils n'étaient pas inactifs pour autant, que ce soit par des manifestations ou des propositions. C'est d'ailleurs le refus d'examiner ces dernières qui est à l'origine du mouvement. Mais comme Yves Calvi n'en parlait pas jusque récemment, ça n'existait pas, c'est ça?

Mais bon, c'est encore plus se foutre de la gueule du monde que d'oser écrire que ces conditions sont
centrales dans les revendications des intermittents, mais ça doit être de l'art

Tu peux ne pas croire à la pertinence de leurs revendications, mais quand ces deux points sont mis en avant systématiquement dans leur communication, c'est par définition qu'ils sont « centraux dans leur revendications ».

Je n'ai aucun problème avec leurs conditions précédentes. A condition que :
- Toutes les personnes dans le même cas (pas que ceux qui travaillent pour l'art, critère hors sujet)
aient les mêmes conditions.
- Que le régime soit équilibré.

Tu t'es renseigné un minimum avant de l'ouvrir? Ces conditions sont centrales dans les revendications des intermittents.

Tu as aussi des contenus qui appartiennent à plusieurs catégories, par exemple mon article sur Nix qui a servi ici d'exemple: 80% de ce que j'ai écrit est une présentation générale, dont je ne saurais pas donner la durée de vie a priori. Mais d'un autre côté, il y a 20% qui sont l'annonce des nouvelles versions des outils de l'écosystème, et ce sont elles qui font que la dépêche rentre dans le ton de linuxfr. Quand je ferai l'annonce de la version 14.10, je ferai certainement un autre partage, peut-être plutôt 40-60 pour ne pas répéter ce qui est dans la dépêche 14.04, mais en évoquant des choses que je n'ai pas eu la place de développer dans le premier article. C'est certainement le tout qui aura un sens cohérent, plus que chacune des parties. Ce tout aura des parties plus ou moins périssables, et à des dates différentes.

Pour résumé, c'est compliqué.

Effectivement, le «user2» c'est une bourde, ça devrait être suzanne partout. J'ai réécrit ces lignes au dernier moment pour que ce soit plus clair, et j'ai oublié des occurences. Si un modérateur passe par là, s/user2/suzanne/g.

Pour les outils, ta suggestion est effectivement raisonnable, je m'attendais à ce que ça marche comme ça aussi au début. Comme (semi-bonnes) raisons, je vois:

• c'est pas beaucoup plus simple d'apprendre "nix-env --list-profiles" que "ls -l /nix/var/nix/profiles/per-user/$USER" et le second permet de débugguer au cas où,
• personne n'a encore codé "nix-env --list-profiles".

Je vais développer les raisons qui me font penser, au-delà de « chacun voit midi à sa porte », que nix est une bonne base pour de tels paquets universels.

Quant à l'installateur universel, 2 approches possibles:
- […]
-des paquets "autonomes", c'est-à-dire pré-compilés en statique pour éviter les soucis avec les différentes versions de chaque
bibliothèque dans les différentes distros. Et là on perd les bienfaits des gestionnaires de paquets et de dépendance (parce qu'on décide > de les ignorer).

Nix donne de tels paquets « autonomes », sous forme de one-click-installs. Ces paquets ont des liens dynamiques, mais vers des bibliothèques dont le chemin est défini statiquement. Tu as ainsi les assurances des liens statiques, mais avec les avantages (notamment mémoire) des liens dynamiques. Nix garde également les traces des dépendances, et il pourrait avertir si on installe une mise à jour (de sécurité par exemple) d'une bibliothèque dont dépend un tel paquet.

Mais c'est plus facile à décrire en quelques lignes qu'à faire (et bonjour la batterie de tests pour les développeurs!!).

Nix apporte là aussi une réponse avec hydra. L'approche déclarative de nixos permet de décrire des tests unitaires qui parlent de « la machines obtenue en installant tels paquets, configurés de la façon suivante ». Ça fait certes une batterie de tests impressionante, mais on a un langage propre pour la décrire et une architecture pour la faire tourner.

Pour compléter, les paquets faits à partir de cabal, npm ou autres gestionnaires de paquets propres à un langage ont des processus de constructions très homogènes, ce qui fait que l'automatisation marche très bien. Pour AUR, les paquets sont beaucoup plus hétérogènes, et si la partie facile qui prend <5min / package pourrait s'automatiser ainsi, au total on ne gagnerait pas grand-chose, car il faudra repasser bien trop souvent derrière la moulinette.

C'est effectivement quelque chose de naturel à tenter. Après, il faut pouvoir assurer le suivi, et je pense que personne ne veut se retrouver responsable de dizaines de milliers de paquets hétérogènes.

Ici, on peine à gérer Gnome.

Pour la difficulté à avoir Gnome sous NixOS, c'est lié à la fois à Gnome et à NixOS. Gnome met plein de choses dans gconf, qui devient de fait un « système de fichiers » auxiliaire. Comme nix insiste pour fonctionner en séparant l'empreinte des différents paquets/versions sur le système de fichier, il faut réimplémenter pas mal de choses pour gnome.

Qu’est-ce qui fait obstacle à ce qu’il y ait enfin des installateurs universels sur Linux ?

À mon avis, les fonctionnalités qu'apporte nix par rapport aux gestionnaires de paquets des versions précédentes (notamment le fait de pouvoir installer des paquets sans accès root) en font un candidat pour implémenter ces «installateurs universels». Mais il reste beaucoup à faire pour ça, que ce soit du point de vue sécurité (dans le store, c'est «tout ou rien» pour l'instant) ou pour être accepté dans la communauté.

Il y a trois niveaux de réponse:

• de base, si l'on prend le firefox ou le kmail de nixpkgs, le fichier de configuration est dans $HOME, et nix en ignore l'existence. Du coup, l'installation de plusieurs versions en parallèle ou les retours en arrière peuvent être périlleux. En pratique, ça ne marche pas si mal;
• on peut écrire une expression nix qui crée un wrapper et qui permette de placer les valeurs de configuration dans une expression nix. C'est ce qui est fait dans nixos, mais pas (encore?) dans les paquets nixpkgs. À ce moment-là, le fichier de configuration est stocké dans le store nix pour chaque version du logiciel, et il est donc synchronisé avec la version du logiciel. Cette solution n'est pas adaptée quand les fichiers de configuration contiennent des données personnelles (c'est typiquement le cas pour un logiciel de mail), car il n'y a pas de gestion des droits à l'intérieur du store. Cette gestion des droits fait partie des choses à ajouter à nix;
• enfin, dans le cas des données qui ne sont pas des fichiers de conf (bases de données, dossiers contenant les mails dans le cas de kmail), un travail est en cours pour que nix aide aux migrations.

C'est plus sobre certes, mais ça donne les factorielles plutôt que la suite de fibonacci.

mémoïsation

Merci, je ne connaissais pas le terme.

Tu trouveras beaucoup plus de références avec l'anglais memoization.

Effectivement, il n'y a pas de « cache des résultats » (mémoïsation dans les termes de l'art), parce que savoir si c'est une bonne idée d'en faire un pour une fonction donnée est indécidable. Cependant, la version liste infinie qui est donnée est mémoïsée par le simple fait de produire une structure de données entière:

fibs :: [Int]
fibs = 0:1:(zipWith (+) fibs (tail fibs))

nthFib :: Int -> Int
nthFib n = fibs !! n

main :: IO ()
main = do
    putStrLn "entrez la valeur de 1000"
    mille <- readLn
    print (nthFib mille)

En plus, elle n'oblige pas à fixer 1000 à la compilation.

Je pensais plus à la 3107, mais elle est dans le même esprit. Les annotations de cette PEP sont plus générales que des types, mais il me semble que les types sont l'usage le plus immédiat.

Tout à fait, j'indiquais juste qu'il y a des avantages nets à implémenter ces fonctionnalités dans le système de paquets plutôt que dans le système de fichiers. L'exemple de nix indique que ces avantages sont réels, même s'il faudrait encore du travail pour les rendre compatible avec l'énorme acquis de debian, que ce soit en intégrant ces aspects dans apt 2.0, en passant debian sous nix, ou en popularisant nixos.

Nix ça ne fait qu'un seul logiciel où tu implémentes les rollbacks, et ça vient gratuitement avec ses autres fonctionnalités. Son rollback te permet aussi des choses que apt + (z|btr)fs ne permet pas, ne serait-ce que de redémarrer les services concernés au moment du rollback. Les upgrades sont aussi transactionnelles, contrairement à apt sur zfs: pas d'upgrade qui finit à moitié parce qu'un paquet a foiré son script post-inst. De même à tout instant, y compris pendant l'upgrade, l'état de ton système est cohérent (pas de bout de la libmachin-2.0 installés avec machind-1.0 qui tourne).

Je te suggère la lecture d'un excellent article qui justement explique quelles sont les dynamiques à l'œuvre et les réponses possibles.

C'est moi, ou il y a une petite contradiction à héberger une initiative sur «internet décentralisé» sur nsa.govgithub ? En termes de centralisation mercantile et inutile d'internet, github est quand même pas mal.

Je pense qu'il faisait référence aux fait que les femmes veuves touchent une partie de la retraite de leur mari défunts (2/3 si je me souviens bien) alors que l'inverse n'a pas d'équivalent ce qui est une discrimination évidente.

C'est bien sûr faux. À moins que tu ne fasses référence au fait que c'est généralement les retraité**e**s qui sont assez pauvres pour avoir le privilège d'être en-dessous des plafonds de ressources.