nokomprendo a écrit 260 commentaires

Demat' Nal

C'est "Bonjour' nal" la blague. En breton, ça marche pas.

Et il y a une erreur de version dans le lien github : https://github.com/serge-sans-paille/pythran/tree/0.8.5

Bon d'accord, tu as raison, bravo.

Merci pour ton blog qui nous apprend que Microsoft fait des dons à l'open-source depuis au moins 3 ans. Personne n'était au courant.

Et merci de nous conseiller de lutter contre Microsoft en utilisant des distribs d'entreprises que MS peut racheter quand il veut. De la pure logique.

Parce que justement il n'y a pas d'entreprise derrière qui pourrait amener des conflits d'intéret. C'est surement aussi pour cela qu'Apple et Sony réutilisent du Freebsd (avec l'histoire des licences en plus).

Déjà Debian n'est pas DebConf 2017. Et ensuite, en quoi un don est-il un problème ? Si une boite fait de l'argent sur un outil open-source, c'est plutôt sympa qu'il donne quelque chose en contrepartie.
S'il y a quelque chose à reprocher à MS, c'est plutôt sa "gestion" de ses impots, ses "partenariats" avec l'éducation nationale, sa "politique commerciale" à Munich, etc… pas ses quelques dons à l'open-source.

Bah dans le fond il a raison quand même, il vaut mieux soutenir les éditeurs de distribution GNU/Linux que Microsoft, Apple ou Google :)

Je ne vois pas trop le rapport : Debian est tout autant une distribution GNU/Linux que Centos.
Microsoft donne de l'argent à la Debconf, et alors ? Cela va influencer le développement de Debian, genre le faire passer à systemd ? Oups, désolé pour le point systemd. Et pour cette même raison, il faut aussi arrêter d'utiliser Openssh (http://undeadly.org/cgi?action=article&sid=20150708134520) ?

Perso, je préfère celui-ci :

J’ai toujours eu une profonde aversion pour les communautarismes de tout poil et les idées « communautaires »

avec plus loin :

Très sincèrement, je pense qu’il y a un réel intérêt à soutenir directement ou indirectement les distributions Linux éditées par Red Hat, SUSE et Canonical

Ca fait vraiment : le communautarisme c'est pas bien alors soutenez la communauté redhat/suse/canonical…

Pareil. Je l'ai utilisé quelques années avant de changer car je n'en étais pas complètement satisfait. Et j'ai deux collègues dans le même cas. Si ça intéresse tant que ça le monde entier, n'hésitez pas à le lui dire également.

Justement non. Les utilisateurs peuvent installer sans sudo. Tout est stocké (sans duplication) dans le /nix/store en lecture seule donc pas de conflit possible. Le seul danger est qu'un utilisateur peut remplir le disque en installant plein de paquets différents.

Normalement tout fonctionne avec Nix 2 mais comme c'est assez nouveau, on a préféré mettre les commandes Nix 1 (les principes sont les mêmes).

Ceci dit NixOS 18.03 vient juste de sortir (https://nixos.org/nixos/manual/release-notes.html#sec-release-18.03), avec Nix 2. On va pouvoir testé tout ça à fond…

La prochaine version de Nixos est la 18.03 et non la 18.04 (même s'ils ne sont pas en avance pour la sortir…).
Et sinon, le logo n'est pas un peu gros ?

mais surtout ça se comporte comment si j'ai une classe B qui hérite de A une classe D qui hérite de D et 2 méthodes

A priori, c'est une ambiguïté que le programmeur doit résoudre. Apparemment c'est comme ça en Julia (qui utilise le multiple-dispatch) : https://docs.julialang.org/en/stable/manual/methods/#man-method-design-ambiguities-1. Et ça doit être pour cela que Herb Sutter conseille de conserver les méthodes redéfinies en membres de classe.

Ça n'a peut-être rien à voir mais il y a eu un problème similaire sur voidlinux l'année dernière. Apparemment, ça venait de glib : https://github.com/voidlinux/void-packages/issues/6375.

Honnêtement, je ne pense pas que nix/nixos soit interessant pour de l'utilisation pure et dure.

Par contre, pour de l'admin ou du dev c'est vraiment top. Par exemple, juste en ajoutant un default.nix à un projet, tu définis complètement son environnement logiciel (dépendances, compilation…). Du coup, cet environnement est facilement reproductible et tu peux aussi le déployer et le composer à d'autres environnements facilement.

Également, si tu développes dans plusieurs langages, tu as souvent pleins de gestionnaires différents à utiliser (npm, pip, gem…) en plus du gestionnaire système (apt, dnf, pacman…) sans compter des environnements virtuels (python-virtualenv…). L'écosystème Nix fournit tout ça en un outil, et peut combiner le tout. En exagérant, tu peux quasiment remplacer les gestionnaires systèmes (apt…), les gestionnaires "langage" (pip…), les environnements virtuels (python-virtualenv…) et même les conteneurs distants ou locaux (docker, flatpack…).

Et effectivement, tu peux aussi personnaliser les packages proposés (par exemple, si tu utilises opencv en C++, je te déconseille d'utiliser les versions packagées par les OS, cf vidéo 07).

Oui, c'est absolument ça : j'ai passé des heures à faire des vidéos sur nixos et haskell pour avoir 3 milliards de vues et m'acheter un palace sur une ile paradisiaque…

Plus sérieusement, je ne suis pas fan non plus des vidéos mais ça apporte un côté dynamique et "réel" (dans le sens où on voit vraiment que ça fonctionne). Pour le rythme, j'ai essayé de ne pas être trop lent pour éviter l'ennui et si ça va trop vite tu peux mettre en pause. De plus, toutes les vidéos sont accompagnées d'un résumé + codes sur github (https://github.com/nokomprendo/tuto_fonctionnel). Des blogs et des docs de 3 km difficiles à lire, il y a en déjà plein d'où l'idée de cette forme un peu différente.

Effectivement, je me rends compte que le pointeur est souvent mal placé, et le curseur aussi d'ailleurs. J'essaierai de faire attention dans les prochaines vidéos. Merci.

Merci pour vos commentaires. J'ai essayé de faire des vidéos "propres" mais il reste quand même quelques coquilles et passages pas très clairs.

Pour la question du partitionnement avec le fichier de config de nixos, je ne pense pas que ce soit possible, il me semble que c'est du montage uniquement. Par contre c'est peut-être possible avec nixops, il faudrait regarder dans la doc.

@Denis Bernard : Sérieusement, tu devrais arrêter avec tes messages. Non seulement, c'est de la philosophie de comptoir à 2 balles réchauffée plusieurs fois mais en plus ça n'a aucun rapport avec la dépêche. Quant à tes généralités méprisantes et infondées sur les enseignants et sur la presse, ce n'était vraiment pas nécessaire.

J'ai dû faire du fortran une fois dans ma vie pour modifier un programme et il m'a effectivement fallu un certain nombre de bières pour m'en remettre… Pour le générateur d'albums, il y a des appels à convert (imagemagick) via la fonction system pour redimensionner les photos. Donc que le générateur soit écrit en assembleur ou en Ruby interprété par un webservice hébergé sur Mars, ça ne changera pas grand chose…

Pour le GPL_torture, je suis impatient de tester également.

Ça me fait penser à un générateur d'albums photo que j'avais codé pour tester différents langages : https://github.com/nokomprendo/gen_album. C'est du code vieux et moche que j'aurais honte de relire aujourd'hui mais ça fonctionnait. Je ne l'avais pas codé en fortran cependant…

Mais bien sûr, les générateurs statiques comme Jekyll et autres ne sont pas capables de détecter les pages modifiées qu'il faut régénérer ni de mettre des liens entre les pages ou plusieurs billets par page. Et tant qu'on y est, ils n'autorisent que les voyelles dans les billets de blog ?

Salut. Je dois être idiot mais je trouve que ce que tu racontes n'a aucun sens. Juste un exemple :

Personnellement, je me suis mis au Fortran pour la seule nécessité de développer un moteur de blog statique. Il est capable de générer une centaine de pages HTML là où WordPress en génère une seule pour le même laps de temps. Et mon moteur de blog n'est pas hackable car il ne réside pas sur le site Web. Et je n'ai pas besoin d'ingurgiter une dose massive de SQL et PHP pour savoir comment marche le bousin. Tout ça par la seule grâce d'un langage compilé.

• WordPress n'est pas un générateur de pages statiques, donc ce n'est pas comparable. De plus, les systèmes dynamiques utilisent généralement un cache qui évite d'avoir à recréer les pages.
• Le temps de génération des pages statiques n'a pas beaucoup d'importance. Prendre une 1s ou 1mn pour la mise à jour quotidienne d'un blog, ça ne change vraiment rien. Et là aussi, les générateurs statiques modernes ne recalculent que les pages qui ont changé.
• La "grâce d'un langage compilé" n'a aucun sens ici. Personnellement, je génère des docs statiques avec sphinx qui produit également les diagrammes UML, les graphes, le code formaté et les équations inclus dans ces docs; l'interpréteur python qui est utilisé pour cela n'a jamais été un problème (par contre bon courage pour coder un outils équivalent en fortran).

Merci pour cette dépêche très intéressante. Deux petites remarques :

• Haskell est un super langage mais ce n'est pas non plus la solution merveilleuse à tous les problèmes du monde. Un lien intéressant sur les domaines d'application d'Haskell : https://github.com/Gabriel439/post-rfc/blob/master/sotu.md.

• Concernant Nix, on peut aussi l'utiliser indépendamment de stack/cabal, pour se faire très rapidement un environnement de développement, par exemple via un fichier shell.nix contenant :

with import <nixpkgs> {};
with pkgs; stdenv.mkDerivation {
    name = "my-haskell-env";
    buildInputs = [ 
       (haskell.packages.ghc802.ghcWithPackages (ps: with ps; [
            # liste des modules à installer
            split 
            parsec3
        ]))
    ];
}

C'est une autre implémentation de la bibliothèque C (c'est-à-dire du code différent de glibc pour implémenter les sockets, threads, math…). Normalement, il y a un standard qui définit les fonctions et structures que doit fournir une libc mais les différentes implémentations ne les respectent pas toujours complètement ou ajoutent parfois des fonctionnalités supplémentaires. Glibc est très répandu et les logiciels sont souvent développés pour cette libc mais du coup si un logiciel utilise une fonctionnalité de glibc qui n'est pas dans le standard alors le logiciel risque de ne pas compiler avec une autre libc.

Musl est supposée être plus moderne, légère et rapide (http://www.etalabs.net/compare_libcs.html) mais je n'ai pas encore testé la version musl de void donc je ne sais pas ce que ça donne au quotidien.

Je ne suis pas un expert non plus mais je crois que xbps est assez proche de pacman, tant au niveau des fonctionnalités (installation/suppression de paquets, résolution des dépendances, rolling release, checksum…) que de la description des paquets (patchs éventuels + fichiers de description contenant quelques variables et fonctions bash). Pour moi, la principale différence est le mode d'intégration dans les dépôts officiels (dépôt AUR + retour des utilisateurs pour arch, pull request directement sur github pour void).

Ceci dit, je ne sais pas si xbps est à l'origine de la création de void mais maintenant void a pas mal d'originalités qui justifient son existence (runit, musl, libressl, architectures i686/x86_64/arm6-7-8…).

Elle est légère de par certains choix techniques (runit, xbps, musl…) et le soin apporté à la création des paquets. Tous les paquets sont compilés avec des options d'optimisation et de hardening et les mainteneurs assez exigeants sur les paquets (choix des bonnes options, pas de dépendances inutiles, logs d'intégration continue…).
Maintenant, ce n'est pas la seule distribution "légère" et une gentoo compilée avec des options spécifiques à ton besoin le sera certainement plus.