nokomprendo a écrit 260 commentaires

Formidable. Mais personnellement, je n'ai aucune envie de gaspiller de l'électricité pendant 20 ans pour essayer de capter le TF1 des aliens de proxima du centaure.
Le sujet ici c'est le covid, et d'après wikipedia rosetta@home c'est aussi du proprio.

ta phrase initiale est fausse

Ma phrase était "c'est pas du tout open-source". Or quand tu lances BOINC avec des calculs, désolé mais tu lances bien du code en partie proprio.

J'ajouterai même que, actuellement, BOINC et FAH sont des systèmes de distribution de calculs proprio. Alors oui c'est mieux si le dispatcher est libre mais ça me parait tout de même assez dérisoire dans la chaine globale, voire même d'induire l'utilisateur novice en erreur, en lui laissant croire que "c'est libre". D'ailleurs le GUI de FAH est libre, pourquoi ne pas l'indiquer également ?

Ok, donc zsh, BOINC et FAH peuvent miner du bitcoin dans le dos de l'utilisateur mais seuls zsh et BOINC sont libres. Merci pour cette précision.

Donc ZSH est pas open-source non plus ?

Il dit qu'il voit pas le rapport.

Oui donc en fait c'est pas du tout open-source non plus et on peut donc tout autant y cacher un miner de bitcoin.

Je ne comprends vraiment pas l'intérêt de cette guéguerre de projets. Si on va par là, on peut préciser que FAH existait avant BOINC et que son but principal est de soigner le cancer et le covid, pas d'analyser des signaux extra-terrestres en espérant que ça va prouver l'ébullition des trous-noirs à boucle…

Pour finir sur une note positive, car après tout trolldi c'est demain, NixOS propose des services pour les deux projets : https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/services/computing

Peace on earth.

Merci pour les explications et pour tout le travail de packaging.
Je vais tester ça dès que j'aurais le temps. Si tu es d'accord, je reprendrai tes fichiers et explications pour les intégrer dans le dépôt git.

Merci pour ces infos.

Pour l'image docker, je trouve ça très pratique, et ça ne doit pas demander beaucoup de temps à maintenir.

Pour cachix, le service est assez jeune, même pour nix. Le ticket que tu mentionnes a été créé par un des développeurs pour voir s'il y a des gens intéressé par le support de guix. Peut-être qu'en relançant un peu le ticket, ça motiverait des gens pour l'implémenter.

J'ai utilisé deux versions de nixpkgs : la release 19.09 et la révision 1c92cdaf7414261b4a0e0753ca9383137e6fef06. Les paquets de la release 19.09 sont consultables facilement ici : https://nixos.org/nixos/packages.html?channel=nixos-19.09 (pour Boost c'est la version 1.67).

C'est une bonne idée de comparer avec Guix. Si tu as le temps de nous faire un retour, ce serait chouette.

Nixops crée la VM et l'intègre directement dans Virtualbox. Pour l'exemple donné dans l'article, j'ai vraiment juste tapé les 2 commandes nixops et la VM est apparue dans l'interface de Virtualbox comme on peut le voir sur la capture d'écran. Pour l'IP, il y a peut-être moyen de la fixer à partir du fichier Nix mais je n'en sais pas plus.
Nixops permet également de déployer vers des machines NixOS ou vers du Cloud (EC2, GCE, etc) : https://nixos.org/nixops/manual

Merci pour ce commentaire fort sympathique.
L'article est un peu long car l'idée était d'illustrer qu'on peut faire pas mal de choses assez facilement avec l'approche fonctionnelle de Nix/Guix. Maintenant, on n'est pas à un concours de l'article le plus long ou le plus commenté; le but est plutôt de partager des infos donc tous les articles qui vont dans ce sens sont intéressants.

Les dépendances "boost, openssl, websocketpp, zlib" sont obligatoires ?

Oui, ce sont des dépendances demandées par le framework cpprestsdk utilisé ici. Pour les trouver, il suffit de regarder la doc de cpprestsdk (ou son fichier de config). Au pire, la compilation échoue en indiquant la dépendance manquante mais c'est quand même mieux de regarder la doc…

Merci, je vais regarder. Ca a l'air intéressant et en plus il y a un gars en kilt trop classe qui pose une question à la fin.

C'est ce que permet apt-build.

Avec Guix/Nix, je peux écrire un simple fichier dans un projet perso pour définir complètement ses dépendances, sa construction, comment l'intégrer dans la logithèque, modifier n'importe quelle option au plus profond de la logithèque et en recalculant automatiquement et uniquement les paquets impactés, etc. puis l'installer comme un programme classique, en construire un environnement virtuel, une image docker, une vm… Je ne connais pas apt-build, ça permet vraiment de faire tout ça ?

Guix/nix font probablement toutes ces choses mieux (l'inverse serais dommage), ils ne les ont pas forcément inventé et les gens n'ont pas attendu nix pour proposer des solutions

On n'est pas à un concours pour le prix Nobel mais pour le coup, il me semble que oui : appliquer les principes de programmation fonctionnelle à la gestion de paquets n'avait jamais été fait avant les débuts de Nix en 2003. Mais je peux me tromper, si tu as des références à ce sujet, ça m'intéresse.

Le paradigme fonctionnel ne se résume pas à adopter un style déclaratif, il permet également de faire de la composition. Avec Guix/Nix, une description de paquet est en fait une fonction qui ajoute à l'environnement courant le soft correspondant. Cette fonction peut prendre des paramètres, par exemple les descriptions de paquet du compilateur ou des dépendances, des options de compilations à activer ou non, etc. Il est donc très facile de régler un paquet et de répercuter les modifications sur tout l'environnement logiciel, si besoin. Ou encore de prendre une description et d'en calculer un environnement/conteneur/vm minimal pour la faire tourner.

Il y a un intérêt à changer les choix de Debian pour tout ton système, pas d'intérêt d'avoir 3 fois la même version d'une librairie.

Peut-être que pour toi ça n'a pas d'intérêt mais perso j'utilise cette fonctionnalité tous les jours. Dans le domaine du HPC, c'est même indispensable et il y a différentes alternatives pour faire ça (environment modules, spack, guix/nix…)

D'ailleurs, je pense que NixOS ne permet pas directement ce que tu indiques : 3 compilations différentes d'une même version de libraire pour 3 logiciels consommateurs différents.

C'est expliqué ici pour nix : https://nokomprendo.gitlab.io/posts/tuto_fonctionnel_20/2018-04-28-README.html . Tu peux compiler autant de versions que tu veux, choisir les dépendances, le compilateur, les options de cmake, etc.

Sauf que ça n'a aucun intérêt car la 1.6.36 et la 1.6.37 sont compatibles au niveau ABI.

Aucun intérêt pour qui ? Perso, j'utilise régulièrement la lib OpenCV et il y a tellement d'options de compilation qu'il est très classique d'avoir à recompiler sa propre version, ou même ses versions, selon les besoins des différents projets. Il y a quelques années, la version d'OpenCV packagée dans Debian était compilée avec un BLAS générique; résultat un code C++ utilisant ce paquet était plus lent qu'un script python utilisant la version Pypi d'OpenCV (qui, elle, était compilée avec un BLAS optimisé). Donc oui, il y a bien un intérêt.

Le passage de stable vers unstable a mis trois plombe

Passer du canal stable au canal unstable, ça correspond à un dist-upgrade sous Debian. Ca fait longtemps que je n'ai pas fait de dist-upgrade mais je ne crois pas que ça se fasse en 5 min. Ceci dit le changement de canal sous Nixos prend essentiellement du temps de téléchargement et essentiellement la première fois qu'on utilise un canal. Switcher entre les canaux déjà installés est ensuite beaucoup plus rapide.

NixOS, c'est l'inverse d'ArchLinux, ne gardons rien de simple

Je suis d'accord que NixOS est assez compliqué à apprendre. Par contre, je ne suis pas du tout d'accord sur la comparaison avec ArchLinux, du moins pour du dev, où chaque update risque de casser les projets. Avec NixOS, tu peux fixer complètement l'environnement de chaque projet, les modifier, les rollbacker, les partager, etc et ça juste marche.

Il y a effectivement un malentendu. Dans ton exemple, gwenview est linké sur /lib64/libpng16.so.16, qui semble correspondre à la version 1.6.37. Du coup, tu auras un soucis si tu as également besoin de la version 1.6.36 ou même d'une version 1.6.37 compilée avec d'autres options.

Je cherchais justement un outils simple, avec hébergement gratuit pour les faibles trafics et qui permette d'avoir une page de reporting publique.

Pour répondre à la question sur l'intégration, il suffit de rajouter le code suivant dans le body de ses pages :

<script>
(function() {
    window.counter = 'https://<monlogin>.goatcounter.com/count'
    var script = document.createElement('script');
    script.async = 1;
    script.src = '//gc.zgo.at/count.js';
    var ins = document.getElementsByTagName('script')[0];
    ins.parentNode.insertBefore(script, ins)
})();
</script>

Pour compléter un peu la réponse, il y a un dossier /gnu/store où tout est installé, via le programme guix. Si un utilisateur installe un soft, guix crée un dossier dans le store et crée des liens symboliques pour l'utilisateur. Si ensuite un deuxième utilisateur installe également le soft, guix a juste à créer des liens sympoliques, pour ce deuxième utilisateur, vers le dossier déjà créé dans le store.

Le store n'est accessible que par guix ce qui permet d'avoir des paquets à la fois isolés et partagés. Une présentation intéressante à ce sujet : https://www.cbaines.net/projects/guix/fosdem-2018/presentation/

Perso, je trouve bien qu'il y ait 2 projets sur cette approche de la gestion de packages. Ce n'est pas une grosse fragmentation et ça permet d'apporter un peu de dynamique et d'idées différentes.

Historiquement, la motivation de Guix était d'utiliser un langage plus classique (scheme au lieu du langage nix) et d'avoir un système de base 100% libre (Nix propose des blobs binaires si on active l'option allowUnfree).
Aujourd'hui Guix semble attacher une grande importance à la reproductibilité, notamment avec Guix HPC et software heritage. De plus, Guix System utilise le système d'init GNU Sheperd et non Systemd.
Donc apparemment il y a quand même de quoi occuper deux projets distincts.

il y aura des présentations sur Guix :
https://guix.gnu.org/blog/2020/meet-guix-at-fosdem-2020/
https://discourse.nixos.org/t/fosdem-2020-in-bruxelles/5491

Guix et Nix ont une approche assez similaire et c'est surtout cette approche qui est intéressante, à mon avis.

Donc oui, ce serait bien de comparer régulièrement, pour voir quelles fonctionnalités sont disponibles ou non, et comment on peut utiliser une fonctionnalité donnée avec l'un et autre de ces 2 outils.

Perso, je suis partant pour donner un coup de main via des dépêches collaboratives, discussions préalables ou autres.

Merci beaucoup pour ce journal. En tant qu'utilisateur de Nix/NixOS, je suis très intéressé par l'approche de Guix mais je manque de temps pour m'y mettre sérieusement, donc j'attends la suite de tes articles avec impatience.

Il me semble que Nix possède aussi toutes les fonctionnalités que tu présentes ici, hormis peut-être la limitation des droits d'utilisation d'une application. Peux-tu nous en dire plus ou prévois-tu d'en parler dans tes prochains articles ?

Sinon, c'est du détail mais je crois que "GuixSD" s'appelle maintenant "Guix System".

Perso, je vois la chose dans l'autre sens : si on a les concepts de "fonction simple" et de "curryfication" alors on a gratuitement les fonctions à plusieurs paramètres et l'évaluation partielle.

En pratique dans Haskell, l'évaluation partielle n'est ni une killer feature ni une véritable source d'erreur (le compilateur, voire le linter, détecte facilement ce genre d'erreur). Par contre, si on fait un peu attention quand on définit nos fonctions, ça permet de simplifier un peu le code pour très peu d'effort.

Yes. C'est beau.

Pour les fonctions totales, je crois que Idris apporte quelques fonctionnalités intéressantes. Mais il faudra peut-être plus de 5 minutes pour comprendre le langage…