benoar a écrit 4240 commentaires

Rien n'empêchait à Stallman et à la FSF d'ajouter des critères politiques dans la licence, ce n'est pas impossible. Bizarrement ils ne l'ont pas fait.

Comment ? J'écoute tes propositions.

Le combat politique est une fin, la GPL avec ses quatre libertés un moyen.

Premièrement, tu occultes tout le problème de la contradiction de la FSF et de Stallman sur l'usage des termes dans ce cas.

Tu édictes les termes qui seraient soi-disant contradictoires (utiliser des logiciels donnant les quatre libertés, et mener un combat politique sur la liberté logicielle), puis tu accuses les autres de les violer ? Tu serais un très bon juge sous l'inquisition !

Ce n'est pas logique, si le Logiciel Libre c'est plus que les 4 libertés, jamais la FSF et Stallman adopteraient une telle stratégie.

Ce n'est pas ta logique. Stallman dit qu'il veut la liberté logicielle, dont un prérequis est d'avoir les quatre libertés. Comment peux-tu renier ça en disant « ça n'est pas logique, il n'a pas le droit » ?!

Deuxièmement, ton discours rend la communication autour du Logiciel Libre délicat.

Oui c'est délicat, mais parce que des personnes qui ont voulu dénaturer ce combat qui était à l'origine politique ont voulu l'utiliser à tort ! Comment peux-tu retourner ainsi la charge ?

Utiliser un terme commun pour désigner des choses différentes, c'est le meilleur moyen d'avoir une communication difficile car créatrice de confusion.

Du coup Stallman passe son temps à expliquer la différence. Et c'est bien le seul ! Comment peux-tu l'accuser de tromper les gens alors ?!

Je ne comprends pas votre négationnisme (maintenant vu ton discours, c'est clairement avéré), à toi et Zenitram.

Ça sent effectivement assez mauvais ton truc. Pas dans le sens « on nous espionne », qui est peut-être une hypothèse un peu osée, mais dans le genre ya encore des neuneus qui font de l'inspection stateful et pètent le réseau sans se rendre compte de la merde qu'ils font.

Car quand tu dis « DPI », moi je vois seulement l'aspect aller tracker une connexion et de filtrer sur des critères à la con, en cassant bien sûr au passage TCP. Que ça soit à des buts d'espionnage, ou « seulement » d'un truc à la con genre protection anti-DDOS, etc. Mais oui, ils s'occupent de trucs qui ne les concerne pas (et ta modification du flow label montre bien qu'ils veulent vraiment tout casser et n'ont rien compris à IPv6).

D'ailleurs au passage, qu'ils s'attaquent à IPv6, je ne m'y attendait pas, et du coup du cassage du genre ça sent très mauvais pour le déploiement d'IPv6, qui pour moi doit être irréprochable niveau qualité de service, sinon ça ne sert strictement à rien (c-à-d que faire du filtrage stateful sur de l'IPv6, c'est du sabotage délibéré qui devrait être sévèrement puni).

Virt-manager est certes un peu trop léger, mais si on fait un petit effort pour apprendre à utiliser libvirt avec les bons outils (virsh, par exemple), c'est vraiment super puissant. Ça n'est pas pour rien que libvirt est là couche d'abstraction utilisée par toutes les solutions de virtualisation, à par Proxmox, qui continue de pouvoir faire « bande à part » grâce à ses qualités (de ce que j'entends ; je n'ai pas utilisé moi-même).

Moi c'est ça que j'adore avec git, c'est qu'il est vraiment fait selon la philosophie Unix que pourtant beaucoup remettent en cause aujourd'hui : ses morceaux sont des exécutables implémentés dans des langages différents (il y a du C, du shell, du perl, de ce que j'ai vu) et interagissent par fork + entrées/sorties standard (ou plus), dans des formats ouverts et documentés. La persistance est gérée par fichier (allez voir comment le "git rebase" gère une interruption — même un plantage — de son flow : il écrit une « todo-list » dans un fichier et la met à jour après chaque application de patch !), dans des formats encore une fois bien définis : ce sont les formats (de fichier et de protocole — cf. git-fast-import(1) par exemple) qui guident l'implémentation, plutôt que le code, selon une pratique voulue par Torvalds.

Bref, on se fout de moi quand je dis que j'écris encore pas mal de shell pour des outils « sérieux », et j'étais bien content de voir (il y a déjà quelques années de cela) que git — qui est une référence pour moi et pour beaucoup d'autres, j'espère — l'utilise encore pas mal, même s'il est remplacé pour des raisons de performance seulement (et de portabilité, oui, mais ça je m'en fout).

Perso, je trouve que le plus honnête serait d'arrêter de travestir le libre comme ca, et si on veut autre chose que le libre, on le nomme et surtout on le définit.

Le mouvement du Logiciel Libre est né de Stallman, et ce dernier mène un combat politique. Il s'est traduit par une licence et la définition des quatre libertés qui, comme tout autre forme de contrat, ne peut pas définir un idéal politique : cela est plutôt réservé habituellement à des mouvements, des organisations. Ces quatre libertés ont plus tard été reprises par des personnes qui voulaient séparer plus clairement l'idéal politique des quatre libertés même : ils ont appelé ça Open Source. Alors certes, les quatre liberté n'ont jamais stricto sensu inclus une visée politique, mais la paternité de cette invention rappelle quand même beaucoup ce combat : c'est même cette évocation qui a incité (selon moi) les créateurs du mouvement Open Source, afin d'être « clair » quant à leur (non-)intention politique ! L'Open Source a été créé pour dire « les quatre libertés sans la politique » !

Alors qu'après on vienne dire qu'il faut que quand on parle de « Logiciel Libre » il ne faut pas du tout inclure la vue politique, je reste un peu coi. Je m'en fous un peu que des gens qui n'ont aucune conviction politique parlent de Logiciel Libre, qu'ils en fassent ou pas, par contre qu'on me dise que je n'ai pas le droit de dire que quand je parle de Logiciel Libre, j'y inclus une certaine vision politique, c'est fort de café. C'est même un peu du négationnisme selon moi, quand on veut absolument retirer toute origine politique à ce mouvement.

Fais de l'Open Source ou fait du Logiciel Libre, c'est comme tu veux, mais moi je fais du Logiciel Libre « politique », et on ne m'enlèvera pas ce mot.

C'est du « logiciel libre » stricto sensu parce qu'il respecte les quatre libertés, mais ce genre de développement est plutôt fait par des gens qui parlent d'Open Source, et c'est ainsi que je le décrirais.

Être plus honnête et gérer une communauté, ça c'est vraiment du « Logiciel Libre » pour moi.

Bref, il y a encore quelques jours un journal disait ici qu'il n'y avait pas vraiment de différence entre Open Source et LL, et bien cet exemple nous montre bien que si.

Ah, et ils sont européens, de Lituanie.

Ça ressemble beaucoup à ça je trouve :
https://www.8devices.com/products/carambola-2
Basé sur du Atheros (en MIPS24k), donc bien documenté, et les devs contribuent bien upstream.

Bon, c'est leur ancien modèle, depuis il y en a eu d'autres, genre basé sur du SoC chinois Realtek (proche de ton Mediatek) :
https://www.8devices.com/products/kinkan

Il y a aussi des trucs un peu plus gros, basé sur Qualcomm (beurk), etc :
https://www.8devices.com/products/

J'ai une adresse personnelle qui je sais vivra à long terme, et j'ai déjà contribué avec des adresses pro qui ont aujourd'hui disparu. Ma technique c'est de commiter avec l'adresse de celui qui a les droits patrimoniaux — donc l'adresse pro quand tu contribues sur ton temps de travail — et de mettre un mailmap (man git-shortlog(1)) pour avoir un lien vers mon adresse perso, qui comme elle est « long terme » est celle qui est la plus pertinente pour moi.

Le projet sur lequel j'ai fait ça c'est libvirt, qui est un projet assez majeur de Red Hat, et ils proposent d'inclure dans le AUTHORS l'adresse que tu considères canonique, donc dans mon cas mon adresse perso :
https://libvirt.org/git/?p=libvirt.git;a=blob;f=.mailmap;hb=HEAD
On voit dans ce cas ici que certains préfèrent l'inverse (être mentionnés par leur adresse pro même quand ils ont commité en perso), donc je ne sais pas s'il existe de règle générale, mais en tous cas j'ai choisi d'avoir la référence « finale » comme étant celle que je sais qui sera valable à plus long terme, même si je sais bien que les droits patrimoniaux ne me seront pas échu.

J'ai demandé directement à l'auteur, qui m'a gentiment redirigé vers l'endroit où il publie toutes ses présentations, dont celle-ci :
http://download.fsfe.org/presentations/20180926-mk-kernel-recipes-democracy.en.pdf

Par contre, il m'a prévenu que c'était essentiellement des images, et que l'important n'est pas dans les slides mais dans son discours… Du coup c'est un peu retour à la case départ, car la vidéo est sur Youtube. C'est dommage.

Effectivement, je n'accepte pas les cookies tiers. J'ai en plus CookieMonster, mais que j'avais laissé poser un cookie pour l'occasion. Ça n'a pas suffit.

Je n'ai pas envie d'aller plus loin, c'est ma limite. J'essaye du coup de faire changer la mentalité des sites qui requièrent ce genre d'intrusion. Dans un cas comme celui-ci, qui prétend défendre le libre et la démocratie, je trouve ça nécessaire de le signaler. Car je sais bien que dans d'autres cas, on me dira que c'est moi qui suit autiste, et je préfère donc laisser tomber.

Merci pour le travail de retranscription (si on peut dire) de ces conférences. J'ai cependant un problème avec SlideShare pour le partage des présentations, qui depuis quelques temps ne laisse même plus voir la présentation avec mon browser incluant Noscript, même après avoir « débloqué » pas mal de choses. Pourrait-on avoir un lien vers les PDF en direct ?

C'est particulièrement ironique pour la présentation Matthias Kirschner https://kernel-recipes.org/en/2018/talks/democracy-requires-free-software/ : effectivement, avec mes logiciels libres je n'arrive même pas à voir sa présentation…
Merci.

C'était effectivement l'avantage à l'époque, mais j'ai lu (je ne sais plus où…) qu'aujourd'hui en France, les raffineries produisaient tellement de diesel que c'est l'essence qui leur reste sur les bras…

Sachant que la taille moyenne d'une commande non-privilégiée est d'à-peu-près huit caractères :

  ls --indicator-style=none /bin /usr/bin | awk '{ print length($0) }' | sort | uniq -c | sort -n -k1,1
  cmdlen=8

Que le nombre classique de pipe enchaîné par un unixien lambda© peut monter raisonnablement à trois (donc quatre commandes) :

  history | awk '{ count[split($0, x, "|")] += 1 } END { for (i in count) print count[i] " " i }'
  nbcmd=4

Qu'une chaîne encodée en base64 a un taux de d'expansion de 33% (log(256,2)/log(64,2)) — donc nécessite 25% de caractères en moins en entrée — et qu'on peut wrapper à 8 caractère la commande base64, pour enchaîner des commandes aléatoires pipées on peut faire :

  dd if=/dev/urandom bs=$(( $cmdlen * $nbcmd * 3/4 )) count=1 | base64 -w 8 \
    | awk -vRS= '{ s=$1 ; for (i=2;i<=NF;i++) s = s " | " $i ; print s }' | sh

Même question statistique que ci-dessus.

Pour la pluie, c'est clair qu'il faut un peu s'équiper mais que c'est complètement faisable : je suis également étonné de l'étonnement des gens…

Je vélotaff en VAE régulièrement, dans une région pluvieuse de France, et j'ai « juste » un bon manteau style K-way mais qui respire bien, avec une capuche bien ajustée (ne pas prendre un truc trop large, qui en plus prendrait le vent), des protèges-pieds/tibias imperméables (même pas besoin d'un pantalon de pluie complet, encombrant), et un vélo avec de bons garde-boue. J'ai fait des grosses pluies sans trop de problème avec ça !

Debian n'y arrive pas à 100%, mais a de bon résultats quand même :
https://tests.reproducible-builds.org/debian/reproducible.html
Et Tails atteint même (je ne sais pas si c'est toujours le cas) la reproductibilité d'une ISO !
https://tails.boum.org/contribute/build/reproducible/

Et effectivement, une fois que tous les problèmes de reproductibilité seront corrigés (doux rêve), on pourra dire que re-builder depuis les sources est sans conséquence particulière pour le déterminisme du comportement du logiciel résultant. Mais garantir la reproductibilité dans le temps avec le flot de modifications qui arrive tout le temps, c'est difficile, et je pense qu'il y aura toujours quelques différences pour une plage étendue de logiciels.

Le rapport avec Yocto, c'est sur les changements de l'environnement de build justement, pas des sources : Yocto rebuild au moindre changement d'environnement d'un soft tout l'OS, ce qui donne des résultats binaires différents à chaque fois car ils ne se concentrent pas sur la reproductibilité. Leur ligne directrice est que les sources sont la racine de « raison », et qu'on doit pouvoir obtenir en gros la même chose, du moment qu'on track la moindre modification de l'environnement de build. Ça marche à peu près bien niveau résultat au sens du comportement du soft résultant, mais niveau reproductibilité des binaires c'est zéro. Et l'ironie, c'est qu'ils se basent sur la disponibilité des sources en lignes, en trackant par défaut les derniers git : niveau reproductibilité, faire comme ça en général c'est garanti que ça ne marche pas (les dépôts bougent, etc).

https://wiki.debian.org/ReproducibleBuilds

Les distros depuient toujours buildent des paquets binaires et assembles ces paquets dans une « distribution ». L'assemblage est fait bien après la compilation, et ce depuis toujours, avant même que les build reproductibles existent.

Yocto, par design d'ailleurs — il se dit un « créateur de distribution —, a un système qui veut essayer de tracker tout changement en re-faisant un build total au moindre changement de variable où que ce soit dans le projet. Du coup tout change tout le temps, point de vue binaire. L'intention peut paraître bonne, mais le résultat est pour moi catastrophique : plutôt que d'essayer de régler les problèmes de dépendances cachées (chose qu'on essaye de détecter par les builds reproductibles, entre autre), ils essayent de compartimenter un maximum les logiciels, avec les problèmes de practicité que ça amène, jusqu'à l'absurde : il faut reproduire aujourd'hui dans le système de Yocto l'équivalent de ce que fait déjà autotools ou les autres systèmes de build (détection de dépendance, chemins, etc). Introduire une modification dans ce système sans tout casser est quasi-impossible, du coup ici les gens préfèrent surtout ne rien toucher, ou alors font des gros hacks dégueux : bravo le résultat.

Bon, après, récemment ils ont l'air de changer un peu point de vue reproductibilité binaire : https://reproducible-builds.org/blog/posts/181/ (mais pas côté compartimentation débile).

Si tu n'as pas besoin de scalabilité, de haute disponibilité, de clusters répartis dans plusieurs datacenters,

D'où viennent ces besoins ? Tu n'en avais pas besoin avant. Qu'est-ce qui a changé depuis 10 ans, à part qu'on ressort ces mots sans savoir ce que ça veut dire ?

d'API pour tout gérer comme du code (infra/réseau compris),

Tu atteints le 100% bullshit : je n'ai jamais vu un déploiement SDN/NFV qui ait un sens et qui marche.

de HSM,

Un HSM dans le cloud… LOL. Tu gobe vraiment toutes ces conneries ? Mettre tes putains de secrets racine chez quelqu'un et espérer que c'est sécurisé parce qu'il y a écrit HSM dessus ? Mais merde, t'es l'admin d'un site collaboratif de libristes qui savent détecter le bullshit derrière tout le marketing ou pas ?

de IAAS ou de PAAS ou de SAAS ou les 3 (et d'autres *aaS d'ailleurs, cf Cloud_computing par exemple),

[:uxam]

de mutualiser fortement des coûts,

Tu le ressort direct de ton directeur financier ? « Mutualiser » ça fait plus consensuel que « pas trop cher » ? Balancé comme ça sans référence aux coûts de s'héberger soi-même ?

de ressources élastiques,

99% des workload entreprise « classique » tournent sur une putain de machine « standard » aujourd'hui. Quasiment personne n'a besoin de trucs élastiques. Ou plutôt : on tend vers avoir besoin de grosses resources parce qu'on a du cloud et que du coup les devs font des grosses daubes qui demandent des resources démesurées.

de facturation à l'usage

Pourquoi le modèle économique t'importe ? Cf. ci-dessus pour le prix.

ou d'avoir des clusters de tout type déjà disponibles (ElasticSearch, Kubernetes, MongoDB, MariaDB, etc.),

Les services de base de données ça existait déjà avant ; des containers, c'est une autre manière de dire que tu as besoin de resource de calcul. ElasticSearch, peut-être.

ou si tu as un budget / des ops / des ressources infinies pour tout faire,

Fausse dichotomie.

[…]

les applis non-cloud sont délaissées/vieillissantes en interne et/ou sans API,

Ça c'est effectivement une bonne remarque : les applis « classiques » non orientées cloud qui fonctionnaient très bien avant ont tendance à « prendre du retard », même si certains trucs façon clouds ne sont pas aussi bien, selon moi. Parmi les raisons qui mènent à ça, je pense que la détérioration du réseau dû à la fin d'IPv4 joue un rôle assez énorme, avec les réseaux internes de plus en plus pourris. C'est très dommage.

[…]

Et non ce n'est pas du vent ni des fonctionnalités que tu avais avant en interne.

Franchement, enlève le bullshit et regarde ce dont tu me parles au final : une machine avec une BDD et de la recherche dessus (sur la recherche, c'est clair que ça pêche), avec quelques applis métier dessus. Tu inventes après des besoins de « disponibilité » blah blah pour justifier le cloud, mais franchement quand tu regardes réellement ton besoin, je ne vois pas où le cloud est réellement très supérieur. Mais oui, je me rends compte que pour que tout le monde dise ça, c'est qu'on a perdu quelque-chose en interne : des gens et de la compétence. Je ne sais pas où ils/elles sont passés.

Si tu n'écris rien, normalement rien ne va être corrompu : je ne sais pas d'où tu as récupéré cette croyance…
Par contre, il se peut que des applications qui veulent faire des trucs « intelligents » dans ton dos veuillent écrire dessus : dans ce cas, tu peux éventuellement causer une corruption si tu enlèves la clé improprement.

Si tu as besoin d'un datacenter avec plein de fonctionnalités (ce qui est le cas d'une grosse administration), soit tu as ton propre datacenter, soit tu utilises un cloud américain car il n'y a pas d'alternative en Europe.

Mais c'est quoi ces putains de « fonctionnalités » ? Du vent. J'ai regardé ce que m'a cité pBpG : en gros, c'est externaliser des services que tu avais déjà avant en interne. Et magiquement, la compétence serait partie, et il faudrait mettre tout ça dans le cloud ? C'est une prophétie auto-réalisatrice ton truc.

Donc c'est de l'hébergement, avec un plus de l'externalisation de service. En gros, tu dis « pour mieux héberger vos services, externalisez-les ». Et on parlais ici des services des administrations : en gros, « ça ne sert à rien d'avoir des services en internes, externalisez-les ». Je peux comprendre que dans une optique logiciel privateur, ce n'est qu'un petit pas de plus vert la non-maîtrise, mais c'est bien d'expliciter (je trouve) que conseiller ainsi le Cloud, c'est dire « donnez-nous toute la maîtrise de vos systèmes d'information » : ça permet d'être plus clair sur les intentions.

Il faut bien voir que 99% des services n'ont absolument pas besoin d haute disponibilité à la minute.

Merci, il faudrait le dire tellement haut et fort : il y a plein de pseudo-« génies » qui se tripotent la nouille en montant des setup haute-dispo blah blah (que ça soit du proprio ou du libre, hein), qui nécessitent des machines et des softs titanesques, qui passent des semaines à le configurer, et qu'il ne faut surtout pas toucher après sinon tout pète… et ça finit toujours par péter un jour, sans personne d'assez compétent pour le réparer (ou alors des consultants payés une blinde). Alors on passe à la prochaine techno à la mode…

Mais c'est un moyen d'attirer les financements, et comme de toutes façons aujourd'hui les financements humain et fournitures sont séparés (je parle toujours du public), bah au lieu d'embaucher quelqu'un qui se démerde un peu avec une Debian et du matos basique, t'es obligé d'acheter des bouses gigantesques et gérer la merde après.

Exemple, dans l'embarqué on génère très souvent des images entiers à base de buildroot et Yocto. Pour faire les choses bien on a une intégration continue sur le système avec nos changements. Résultat l'image doit être régénérée à chaque fois de 0 (cela signifie refaire le configure de centaines / milliers de paquets à chaque nouveau commit ou nouvelle livraison).

C'est marrant que tu me parles de Yocto, je me le tape tous les jours et je peux te le dire : Yocto n'a pas du tout la bonne approche. Rebuilder depuis les sources à chaque fois, sans reproductibilité binaire, ça n'est pas la bonne manière de faire. C'est même idiot. Voir comment font les distros classique pour comprendre pourquoi.

C'est comme ce que j'ai dit au-dessus à propos de ne pas avoir à relancer le configure à chaque make : ça serait débile.

C'est toujours facile de dire « faut pas faire ça » sans ne serait-ce que citer une solution. Et en l'occurrence sans dire « ok il n'y a pas de solution mais la moins pire serait… ».

Bah je sais pas, on nous balance le cloud comme si c'était une techno révolutionnaire qui changerait tout… comme dit Sytoka plus haut, s'héberger soi-même ça se fait depuis toujours. Certes, pas avec toutes les fonctionnalités avancées du could d'aujourd'hui, mais je ne vois pas en quoi ça serait un truc tellement difficile qu'on en serait obligé à passer uniquement par des américains. D'où le fait qu'Albert n'ait pas à citer de solution pour qu'on comprenne que quand même, ça n'est pas impossible de faire sans les US.

Ce qui me fait peur, c'est que justement on trouve ça aujourd'hui impossible de s'héberger, alors que c'était la norme avant ! Cela sous-entend que les mentalités ont bien été manipulées par les vendeurs de cloud pour qu'on ait oublié cette époque. (encore une fois, je comprends que c'est moins pratique que du cloud, mais de là à trouver ça impossible…)

La rhétorique c'est bien dire « il ne faut pas faire ça » sans proposer aucune solution, auquel cas je réponds « y a une solution c'est l'âge de pierre en gros ».

Donc c'était de l'ironie ? Désolé de pas t'avoir compris alors.

Et la non-rhétorique ça serait de dire par exemple « pourquoi pas OVH même si VMware ».

Je savais pas qu'OVH c'était vu VMWare… c'est triste.

Si je peux me permettre de dévier un peu, je trouve ça triste à quel point aujourd'hui on trouve qu'héberger et administrer des machines ça soit vu comme une tâche insurmontable partout : je vois effectivement que beaucoup de monde le constate, alors qu'on avait pas mal de connaissance avant.

Mon expérience perso dans un établissement public (anecdotique, certes) montre qu'une Debian bien configurée avec du libvirt/kvm plus quelques scripts maisons, avec un ingé qui se démerde un peu, ça tient tout seul, même sur du long terme (mon travail a survécu à l'arrivée et la fin d'un Openstack, qui devait être la panacée…).

Une autre réaction d'un développeur français un peu connu, qui acquiesce :
http://fabiensanglard.net/bloated/index.php