nokomprendo a écrit 163 commentaires

  • [^] # Re: Flatpak?

    Posté par  (site Web personnel) . En réponse au journal Sortie de ./play.it 2.11.4. Évalué à 5 (+3/-0).

    Tu te contredis. C'est justement parce qu'un navigateur a par défaut accès à tout et que c'est un point d'entrée central qu'il faut des mesures pour éviter des actions problématiques à tout bout de champ.

    Lis mon message. Je n'ai pas dis qu'un système de droits est inutile mais que celui de flapak ne convient pas à un navigateur : il faut gèrer les droits par site et par extension, donc à une granularité plus fine.

  • [^] # Re: Windows n'a pas à s'inquièter

    Posté par  (site Web personnel) . En réponse au journal Mieux que Santa Barbara : Munich revient aux logiciels libres. Évalué à 5 (+3/-0).

    Ce n'est pas vraiment ce qu'a l'air de dire ce reportage, d'une chaine allemande : https://youtu.be/duaYLW7LQvg?t=1070

  • [^] # Re: Flatpak?

    Posté par  (site Web personnel) . En réponse au journal Sortie de ./play.it 2.11.4. Évalué à 4 (+2/-0).

    Prenons un logiciel comme Firefox. C'est gros, il fait des tâches risquées en permanence, a des failles à colmater en permanence, etc. On n'est pas à l'abri d'avoir une faille ou un bogue dans Firefox qui permet de faire tout et n'importe quoi. Même si c'est libre.

    Dans un bac à sable, ses droits seront réduits au strict nécessaire et l'utilisateur aura un meilleur contrôle de ses accès.

    Et quels sont les droits strictement nécessaires à Firefox ? Et bien quasiment tous en fait : réseau, disque, webcam, microphone… Les navigateurs web c'est certainement le pire exemple pour justifier l'intérêt d'un bac à sable à-la-flatpak. D'ailleurs ils ont leur propre système de droits, pour de bonnes raisons.

    @mothsART si tu veux un conseil, fais tes propres tests…

  • [^] # Re: BOINC

    Posté par  (site Web personnel) . En réponse au journal covid19 et puissance de calcul disponible. Évalué à 2 (+1/-1).

    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.

  • [^] # Re: BOINC

    Posté par  (site Web personnel) . En réponse au journal covid19 et puissance de calcul disponible. Évalué à 2 (+1/-1).

    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 ?

  • [^] # Re: BOINC

    Posté par  (site Web personnel) . En réponse au journal covid19 et puissance de calcul disponible. Évalué à 1 (+0/-1).

    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.

  • [^] # Re: BOINC

    Posté par  (site Web personnel) . En réponse au journal covid19 et puissance de calcul disponible. Évalué à 1 (+0/-1).

    Donc ZSH est pas open-source non plus ?

    Il dit qu'il voit pas le rapport.

  • [^] # Re: BOINC

    Posté par  (site Web personnel) . En réponse au journal covid19 et puissance de calcul disponible. Évalué à -2 (+0/-4).

    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.

  • [^] # Re: Fixer une version

    Posté par  (site Web personnel) . En réponse à la dépêche Gestion de paquets et DevOps avec Nix, tour d’horizon sur un cas concret. Évalué à 2.

    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.

  • [^] # Re: Superbe dépêche et étonnement !

    Posté par  (site Web personnel) . En réponse à la dépêche Gestion de paquets et DevOps avec Nix, tour d’horizon sur un cas concret. Évalué à 2.

    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.

  • [^] # Re: Versions ?

    Posté par  (site Web personnel) . En réponse à la dépêche Gestion de paquets et DevOps avec Nix, tour d’horizon sur un cas concret. Évalué à 2.

    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.

  • [^] # Re: Déploiement de machine virtuelle ?

    Posté par  (site Web personnel) . En réponse à la dépêche Gestion de paquets et DevOps avec Nix, tour d’horizon sur un cas concret. Évalué à 4.

    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

  • [^] # Re: Superbe dépêche et étonnement !

    Posté par  (site Web personnel) . En réponse à la dépêche Gestion de paquets et DevOps avec Nix, tour d’horizon sur un cas concret. Évalué à 5.

    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.

  • [^] # Re: Sympa

    Posté par  (site Web personnel) . En réponse au journal Gestion de paquets et DevOps avec Nix, tour d'horizon sur un cas concret. Évalué à 2.

    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…

  • [^] # Re: Mal connaître sa distribution

    Posté par  (site Web personnel) . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 3.

    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.

  • [^] # Re: Mal connaître sa distribution

    Posté par  (site Web personnel) . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 1.

    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.

  • [^] # Re: Mal connaître sa distribution

    Posté par  (site Web personnel) . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 4.

    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.

  • [^] # Re: Mal connaître sa distribution

    Posté par  (site Web personnel) . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 5.

    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.

  • [^] # Re: Mal connaître sa distribution

    Posté par  (site Web personnel) . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 5.

    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.

  • [^] # Re: Mal connaître sa distribution

    Posté par  (site Web personnel) . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 4.

    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.

  • # Merci pour l'info.

    Posté par  (site Web personnel) . En réponse au journal GoatCounter 1.0 un Web analytique léger, libre et respectueux. Évalué à 4.

    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>
    
  • [^] # Re: La meilleure fonctionnalité du gestionnaire de paquets

    Posté par  (site Web personnel) . En réponse au journal Guix : un outil pour les remplacer tous. Évalué à 6.

    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/

  • [^] # Re: intéresssé mais

    Posté par  (site Web personnel) . En réponse au journal Guix : un outil pour les remplacer tous. Évalué à 7.

    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.

  • # Et si vous allez à FOSDEM 2020...

    Posté par  (site Web personnel) . En réponse au journal Guix : un outil pour les remplacer tous. Évalué à 10.

  • [^] # Re: Super initiative

    Posté par  (site Web personnel) . En réponse au journal Guix : un outil pour les remplacer tous. Évalué à 6.

    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.