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.
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
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.
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'é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…
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
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 !
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).
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.
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…).
Je trouve dommage que tu plonges dans la fausse dichotomie qui oblige à « tout accepter » à moins de vouloir revenir à l'âge de pierre. C'est un piège rhétorique classique il me semble. Ça a toujours été utilisé pour décrédibiliser le projet GNU, alors que le seul moyen à long terme d'y arriver est d'effectivement de refuser tout logiciel privateur.
Par contre, ceux qui sont étonnés de la migration vers Azure des administrations… comment s'en étonner quand ça fait 30 ans que MS pilonne les écoles et les administrations, qui le lui rendent bien financièrement parlant ? Ce n'est que la suite logique. L'ennemi n'a pas changé de camp…
Ce que nous disent benoar et d'autres c'est qu'ils aiment les autotools en tant que gestionnaire de paquet (en lieu et place de dpkg, rpm ou flatpack). Je veux signifier que c'est un usage totalement à la marge et que les gains apportés pour les usages conventionnels sont bien plus grands que l'inconvénient qu'ils voient sur l'usage qu'ils en font.
Je ne suis pas d'accord que ça soit un usage « totalement à la marge » : le projet GNU a établit des standards https://www.gnu.org/prep/standards/standards.html qui, lorsqu'ils sont suivis (en utilisant les autotools) permettent de correctement distribuer un travail (on parle de « distribution » dans la terminologie autotools pour désigner un tarball d'une version donnée d'un logiciel). Ça n'est pas non plus un gestionnaire de paquet complet : c'est un entre deux, mais c'est bien plus que simplement un système de build. Je l'avais décrit comme permettant de faire bien plus que juste compiler dans une présentation que j'avais faite http://dolka.fr/bazar/atelier_empaquetage_facon_GNU/atelier_empaquetage_facon_GNU.pres.html : ça permet de distribuer, d'informer de la licence, de faciliter la reproductibilité et la disponibilité des sources. Des choses qui sont plutôt l'apanage des système de gestion de paquet d'habitude (comme celui de Debian, qui couvre tous ces aspects également).
L'inconvénient que tu citais plus haut sur les perfs, je ne comprends pas : le configure n'est fait qu'une fois, après tu "make" quand tu changes un fichier et c'est très rapide.
Bien sûr, comme tout système qui se veut être le seul standard, d'autres sont venus le contredire, et les « distributions » au sens classique du terme (ensemble de logiciels intégrés avec un noyau) sont venu « uniformiser » ça ; bien sûr, on a eu plusieurs distributions…
Et dire que c'est juste « changer les habitudes » de quelques utilisateurs, oui, si tu veux… mais alors pourquoi a-t-on inventé les distributions pour englober / uniformiser ça ? Parce les utilisateurs ne veulent pas juste s'emmerder.
make ? le compilateur ? la bibliothèque standard du C ou C++ ? Ce n'est pas dans les outils de base de ma distribution.
Ça l'était à une époque. Et ma remarque était pour dire qu'en gros, si tu veux compiler un outil depuis les sources, bien sûr qu'il faut un compilateur, mais tu n'auras pas besoin de télécharger le dernier outil de build à la mode : tout ce qui est hors des outils que tu cites et qui sont historiquement considérés comme « standards » est superflu.
Bref, point de vue utilisateur du logiciel (depuis les sources, donc utilisateur avancé quand même), pas besoin même de « système de build » puisque du point de vue de celui qui exécute ./configure, autotools n'est pas nécessaire.
Comme dit Matthieu, le cas « utilisateur qui compile et modifie éventuellement » peut paraître étrange par rapport au dev qui veut modifier la procédure de build et plus, mais c'est une dichotomie qui valait à une certaine époque et que je trouve toujours bonne pour un paquet de projets aujourd'hui. La preuve par cette news elle-même : c'est encore un nouveau standard nécessaire pour compiler X projets. Autotools ne sera jamais nécessaire pour un développeur qui fait des modifications minimes.
Oui, c'est là que je l'ai vu. C'était juste pour présenter l'information directement ici, pour éviter à ceux qui ne cherchent pas en région parisienne d'avoir l'info direct (il me semble que c'est une des informations essentielles d'une annonce).
[^] # Re: Ha ouais, quand même...
Posté par benoar . En réponse au journal Une backdoor vient d’être trouvée dans un paquet npm connu. Évalué à 6.
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.
[^] # Re: Ha ouais, quand même...
Posté par benoar . En réponse au journal Une backdoor vient d’être trouvée dans un paquet npm connu. Évalué à 0.
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.
[^] # Re: Un peu comme ce que fait 8devices depuis des années ?
Posté par benoar . En réponse au journal Marre des boards ARM (ep 2) ?. Évalué à 3.
Ah, et ils sont européens, de Lituanie.
# Un peu comme ce que fait 8devices depuis des années ?
Posté par benoar . En réponse au journal Marre des boards ARM (ep 2) ?. Évalué à 4. Dernière modification le 28 novembre 2018 à 12:13.
Ç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/
# Mon utilisation, avec mailmap
Posté par benoar . En réponse au message Quelle adresse email utiliser sur un projet Libre dans le cadre du travail ?. Évalué à 5.
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.
[^] # Re: PDF des présentations ?
Posté par benoar . En réponse à la dépêche Les vidéos et présentations de Kernel Recipes 2018 sont disponibles. Évalué à 2.
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.
[^] # Re: PDF des présentations ?
Posté par benoar . En réponse à la dépêche Les vidéos et présentations de Kernel Recipes 2018 sont disponibles. Évalué à 5. Dernière modification le 31 octobre 2018 à 10:56.
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.
# PDF des présentations ?
Posté par benoar . En réponse à la dépêche Les vidéos et présentations de Kernel Recipes 2018 sont disponibles. Évalué à 4.
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.
[^] # Re: tu as de la chance
Posté par benoar . En réponse au journal [Aujourd'hui c'est vendredi] prix du carburant, association d'automobilistes. Évalué à 2.
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…
[^] # Re: Stats
Posté par benoar . En réponse au journal J'ai lancé une commande dans mon terminal, découvrez l'incroyable résultat. Évalué à 3.
Sachant que la taille moyenne d'une commande non-privilégiée est d'à-peu-près huit caractères :
Que le nombre classique de pipe enchaîné par un unixien lambda© peut monter raisonnablement à trois (donc quatre commandes) :
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 :
Même question statistique que ci-dessus.
[^] # Re: Les vrais écolos ?
Posté par benoar . En réponse au journal Le VAE n'est PAS un truc de fainéant. Évalué à 4.
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 !
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 4.
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).
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 2.
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).
[^] # Re: Maintenant, c'est clair
Posté par benoar . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 6. Dernière modification le 19 octobre 2018 à 10:29.
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 ?
Tu atteints le 100% bullshit : je n'ai jamais vu un déploiement SDN/NFV qui ait un sens et qui marche.
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 ?
[:uxam]
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 ?
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.
Pourquoi le modèle économique t'importe ? Cf. ci-dessus pour le prix.
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.
Fausse dichotomie.
[…]
Ç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.
[…]
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.
# Pas vraiment un risque si tu n'écris rien
Posté par benoar . En réponse au message fichier corrompu. Évalué à 3.
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.
[^] # Re: Maintenant, c'est clair
Posté par benoar . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 5.
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.
[^] # Re: Maintenant, c'est clair
Posté par benoar . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 6.
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.
[^] # Re: Maintenant, c'est clair
Posté par benoar . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 9. Dernière modification le 15 octobre 2018 à 09:59.
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.
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3.
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.
[^] # Re: Maintenant, c'est clair
Posté par benoar . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 7.
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…)
Donc c'était de l'ironie ? Désolé de pas t'avoir compris alors.
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…).
# Réaction liée
Posté par benoar . En réponse au journal Un développeur qui dénonce. Évalué à 2.
Une autre réaction d'un développeur français un peu connu, qui acquiesce :
http://fabiensanglard.net/bloated/index.php
[^] # Re: Maintenant, c'est clair
Posté par benoar . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 8.
Je trouve dommage que tu plonges dans la fausse dichotomie qui oblige à « tout accepter » à moins de vouloir revenir à l'âge de pierre. C'est un piège rhétorique classique il me semble. Ça a toujours été utilisé pour décrédibiliser le projet GNU, alors que le seul moyen à long terme d'y arriver est d'effectivement de refuser tout logiciel privateur.
Par contre, ceux qui sont étonnés de la migration vers Azure des administrations… comment s'en étonner quand ça fait 30 ans que MS pilonne les écoles et les administrations, qui le lui rendent bien financièrement parlant ? Ce n'est que la suite logique. L'ennemi n'a pas changé de camp…
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 5.
Je ne suis pas d'accord que ça soit un usage « totalement à la marge » : le projet GNU a établit des standards https://www.gnu.org/prep/standards/standards.html qui, lorsqu'ils sont suivis (en utilisant les autotools) permettent de correctement distribuer un travail (on parle de « distribution » dans la terminologie autotools pour désigner un tarball d'une version donnée d'un logiciel). Ça n'est pas non plus un gestionnaire de paquet complet : c'est un entre deux, mais c'est bien plus que simplement un système de build. Je l'avais décrit comme permettant de faire bien plus que juste compiler dans une présentation que j'avais faite http://dolka.fr/bazar/atelier_empaquetage_facon_GNU/atelier_empaquetage_facon_GNU.pres.html : ça permet de distribuer, d'informer de la licence, de faciliter la reproductibilité et la disponibilité des sources. Des choses qui sont plutôt l'apanage des système de gestion de paquet d'habitude (comme celui de Debian, qui couvre tous ces aspects également).
Voir également https://www.gnu.org/software/automake/manual/automake.html#Introducing-the-GNU-Build-System
L'inconvénient que tu citais plus haut sur les perfs, je ne comprends pas : le configure n'est fait qu'une fois, après tu "make" quand tu changes un fichier et c'est très rapide.
Bien sûr, comme tout système qui se veut être le seul standard, d'autres sont venus le contredire, et les « distributions » au sens classique du terme (ensemble de logiciels intégrés avec un noyau) sont venu « uniformiser » ça ; bien sûr, on a eu plusieurs distributions…
Et dire que c'est juste « changer les habitudes » de quelques utilisateurs, oui, si tu veux… mais alors pourquoi a-t-on inventé les distributions pour englober / uniformiser ça ? Parce les utilisateurs ne veulent pas juste s'emmerder.
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 6.
Ça l'était à une époque. Et ma remarque était pour dire qu'en gros, si tu veux compiler un outil depuis les sources, bien sûr qu'il faut un compilateur, mais tu n'auras pas besoin de télécharger le dernier outil de build à la mode : tout ce qui est hors des outils que tu cites et qui sont historiquement considérés comme « standards » est superflu.
Bref, point de vue utilisateur du logiciel (depuis les sources, donc utilisateur avancé quand même), pas besoin même de « système de build » puisque du point de vue de celui qui exécute ./configure, autotools n'est pas nécessaire.
Comme dit Matthieu, le cas « utilisateur qui compile et modifie éventuellement » peut paraître étrange par rapport au dev qui veut modifier la procédure de build et plus, mais c'est une dichotomie qui valait à une certaine époque et que je trouve toujours bonne pour un paquet de projets aujourd'hui. La preuve par cette news elle-même : c'est encore un nouveau standard nécessaire pour compiler X projets. Autotools ne sera jamais nécessaire pour un développeur qui fait des modifications minimes.
[^] # Re: C'est à Paris Saclay
Posté par benoar . En réponse au journal (relais) Poste à la fondation Inria pour travailler sur scikit-learn. Évalué à 10.
Oui, c'est là que je l'ai vu. C'était juste pour présenter l'information directement ici, pour éviter à ceux qui ne cherchent pas en région parisienne d'avoir l'info direct (il me semble que c'est une des informations essentielles d'une annonce).