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).
les autotools doivent être installés sur la machine…
sinon ./configure ne fonctionnera pas!
Où alors j'ai rien compris :(
Tu n'as effectivement pas compris. Les prérequis d'un configure sont très simples : un shell et les outils Unix de base. C'est d'ailleurs la raison de sa « lourdeur » : il fait tout avec ces prérequis très minimaux, ce qui est assez contraignant, et oblige à plein de contournements lourds en ressources.
De même, tu n'auras pas besoin des autotools tant que tu ne fais pas de modification du système de build lui-même : tu peux modifier les fichiers source et recompiler sans avoir les autotools. Un ajout de fichier ou de dépendance de bibliothèque, par contre, t'obligera à les avoir, et faire un coup d'autoreconf.
Mouarf, comment tu choisis tes passages ; à peu près l'ensemble de l'article critique le résultat qui contient un nombre assez énorme d'erreurs. La conclusion que tu cites est le début, sous forme d'encouragement, mais la suite dit :
Unfortunately, there are too many holes in the xhtml+CSS export at this time to make it really usable unless your document has almost unstyled paragraphs only. Some generated styles (overline?!?) are not present in the original document, it generates only paragraphs and tables losing the header or list semantics, the LibreOffice styles are not serialized in a CSS stylesheet (bug?) and more. This will help some individuals but I am not sure it will help EPUB publication chains, at least for now.
En gros, ça marche si ton document n'a pas de style.
Oui, le combat est politique : sans cette feature, il est difficile de s'héberger correctement (complexité de la gestion de TLS, complexité sur failover sans CDN, etc) avec des moyens raisonnables, sans être un « gros ». Étrangement, parmi ceux qui s'opposent dans ce rapport de bug à la résolution de ce problème par des entrées SRV avec des arguments plus ou moins valable, on trouve des ingénieurs de chez Google. Et Google finance Mozilla. Forcément, ça doit donner envie de laisser traîner la résolution…
Ah, je n'avais pas capté que tu trouvais ce log confus : il indique que le client se connectant à machine1, donc ton premier client SSH depuis ton poste au boulot, s'est déconnecté volontairement car la commande qu'il a lancé à l'intérieur (qui n'est pas un shell), c-à-d le ssh sur machine2, a quitté, pour quelque raison que ce soit. Dans ton cas, ce second SSH a dû faire un timeout et tu n'as pas de trace, mais du point de vue de machine1 ta session a été fermée volontairement parce que la commande à l'intérieur s'est terminée, c'est tout.
En ce qui concerne l'aide que ça pourra apporter à la police, si tu as un horodatage précis, ça pourra éventuellement aider à retracer en croisant avec d'autres sources précises comme des caméras de surveillance (expérience perso).
Tu peux regarder si tu trouve la durée du timeout dans sshd_config de machines.
ClientAliveInterval
Effectivement, mais pour ce paramètre il faudrait la conf de machine2… Pour le client, il faudrait voir la conf de machine1, en particulier ServerAliveInterval, qui n'est pas active par défaut.
De plus, si ce sont les paramètre du kernel uniquement qui sont concernés, ça dépend de plusieurs paramètres : tcp_keepalive_time qui est de 2h (début du test de transmission d'une connexion inactive), ou tcp_retries2 qui indique qu'une connexion « perdue » mettra environ 1000 s minimum avant d'être cassée de force. Du coup ça dépend de l'activité de cette connexion ; je suppose qu'une session X active dessus fait qu'elle était plutôt occupée, et que le keepalive ne compte donc pas vraiment.
Bon courage pour la suite des affaires en tous cas.
Oui, c'est clair que le monde du FPGA c'est pas la joie niveau ouverture. Je ne suis pas convaincu que l'arrivée d'un nouveau concurrent change quoi que ce soit, mais on peut toujours rêver.
# 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).
[^] # Re: Un nouveau standard ?
Posté par benoar . En réponse à la dépêche E.T. téléphone Meson. Évalué à 5.
Tu n'as effectivement pas compris. Les prérequis d'un configure sont très simples : un shell et les outils Unix de base. C'est d'ailleurs la raison de sa « lourdeur » : il fait tout avec ces prérequis très minimaux, ce qui est assez contraignant, et oblige à plein de contournements lourds en ressources.
De même, tu n'auras pas besoin des autotools tant que tu ne fais pas de modification du système de build lui-même : tu peux modifier les fichiers source et recompiler sans avoir les autotools. Un ajout de fichier ou de dépendance de bibliothèque, par contre, t'obligera à les avoir, et faire un coup d'autoreconf.
# C'est à Paris Saclay
Posté par benoar . En réponse au journal (relais) Poste à la fondation Inria pour travailler sur scikit-learn. Évalué à 10.
Pour ceux qui ne s'en doutaient pas, quand une annonce omet le lieu, c'est sous-entendu Paris (ici Saclay plus précisément).
Merci. Un provincial.
[^] # Re: Pourquoi réinventer la roue ?
Posté par benoar . En réponse à la dépêche Des fichiers EPUB avec LibreOffice 6.1 sans extension. Évalué à 3.
Mouarf, comment tu choisis tes passages ; à peu près l'ensemble de l'article critique le résultat qui contient un nombre assez énorme d'erreurs. La conclusion que tu cites est le début, sous forme d'encouragement, mais la suite dit :
En gros, ça marche si ton document n'a pas de style.
[^] # Re: www ou non
Posté par benoar . En réponse à la dépêche Évolution des hyperliens sur LinuxFr.org. Évalué à 4.
Oui, le combat est politique : sans cette feature, il est difficile de s'héberger correctement (complexité de la gestion de TLS, complexité sur failover sans CDN, etc) avec des moyens raisonnables, sans être un « gros ». Étrangement, parmi ceux qui s'opposent dans ce rapport de bug à la résolution de ce problème par des entrées SRV avec des arguments plus ou moins valable, on trouve des ingénieurs de chez Google. Et Google finance Mozilla. Forcément, ça doit donner envie de laisser traîner la résolution…
[^] # Re: Timeout
Posté par benoar . En réponse au journal Horodater un cambriolage avec des logs. Évalué à 4.
Ah, je n'avais pas capté que tu trouvais ce log confus : il indique que le client se connectant à machine1, donc ton premier client SSH depuis ton poste au boulot, s'est déconnecté volontairement car la commande qu'il a lancé à l'intérieur (qui n'est pas un shell), c-à-d le ssh sur machine2, a quitté, pour quelque raison que ce soit. Dans ton cas, ce second SSH a dû faire un timeout et tu n'as pas de trace, mais du point de vue de machine1 ta session a été fermée volontairement parce que la commande à l'intérieur s'est terminée, c'est tout.
En ce qui concerne l'aide que ça pourra apporter à la police, si tu as un horodatage précis, ça pourra éventuellement aider à retracer en croisant avec d'autres sources précises comme des caméras de surveillance (expérience perso).
[^] # Re: Timeout
Posté par benoar . En réponse au journal Horodater un cambriolage avec des logs. Évalué à 3.
Effectivement, mais pour ce paramètre il faudrait la conf de machine2… Pour le client, il faudrait voir la conf de machine1, en particulier ServerAliveInterval, qui n'est pas active par défaut.
De plus, si ce sont les paramètre du kernel uniquement qui sont concernés, ça dépend de plusieurs paramètres : tcp_keepalive_time qui est de 2h (début du test de transmission d'une connexion inactive), ou tcp_retries2 qui indique qu'une connexion « perdue » mettra environ 1000 s minimum avant d'être cassée de force. Du coup ça dépend de l'activité de cette connexion ; je suppose qu'une session X active dessus fait qu'elle était plutôt occupée, et que le keepalive ne compte donc pas vraiment.
Bon courage pour la suite des affaires en tous cas.
[^] # Re: Ouverture de la carte d'extension ?
Posté par benoar . En réponse au journal Risc-V est prêt pour le desktop™ !. Évalué à 4.
Oui, c'est clair que le monde du FPGA c'est pas la joie niveau ouverture. Je ne suis pas convaincu que l'arrivée d'un nouveau concurrent change quoi que ce soit, mais on peut toujours rêver.
Merci pour la confirmation en tous cas.