le packaging c'est une autre problématique qui doit être géré par un autre outil.
Non. Le build est lié à la licence, car un bon système de build permet de respecter qu'on distribue bien les sources associées à tel binaire, et qu'on est capable de le reproduire dans un environnement donné. Pour l'installation, le linkage peut être dépendant de la manière dont sont installées les bibliothèques, et tu devras forcément introduire dans ton système à un moment où aller chercher tel fichier. Ces problématiques sont très liées, et limiter un outil de build à faire uniquement ça c'est dupliquer les efforts pour plus tard gérer les autres aspects.
Avoir un outils qui fait tout crée une usine à gaz.
C'est parce que builder, installer, reproduire et installer sont un ensemble de problèmes complexe. Les autotools sont éventuellement une usine à gaz pour la flexibilité dans certains choix, mais ils simplifient tout de même beaucoup l'ensemble de ces tâches, avec des paramètres par défaut plutôt bon qui font qu'on n'a pas forcément à toucher tout son paramétrage.
Tu peux aussi avoir une commande qui génère le rpm/msi/deb/autre
Si on avait un système de package (au sens « distribution Linux » du terme) universel, oui on pourrait, mais c'est un problème politique trop grand. Alors c'est l'inverse qui est arrivé : le packaging Debian (par exemple) d'un paquet déjà géré par autotools est fait en une ligne de procédure (et quelques lignes de description de données spécifiques au système de Debian).
c'est pour cela que dans certains departement/region, c'est "l'etat" qui finance le deploiement, puis qui loue les fibres aux differents operateurs.
Je ne connais aucun déploiement du genre : ce sont toujours des co-investissements public-privé, où le privé est souvent majoritaire. L'État en tant que « maître de l'infrastructure » est malheureusement un modèle oublié aujourd'hui.
c'est alors "l'etat" qui decide si un operateur ou un autre peut s'implanter.
Pour avoir essayé d'accéder (membre d'un FAI local) et vu la réalisation (membre de commission consultative) de ces RIP, au final, à force de croiser (certains) des élus que je qualifierai de corrompus et de déploiements taillés pour les gros du privé, je vois difficilement un moyen de faire avancer les choses « dans le bon sens », même si je salue le travail de toute la fédé là-dessus.
Ça fait plusieurs dizaines d'années que le déploiement d'infrastructure (et pas uniquement fibre) en France est poussé vers le privé par les politiques néolibérales, et les personnages politiques pour qui votent les gens ne remettent malheureusement pas en cause cette tendance. Les combats menés par la fédé sont bons, mais c'est du pipi de chat comparé à la puissance des ogres du privé soutenus par nos politiques. Quasiment aucun politique ne remet ça en cause, à par ceux qu'on qualifie à tort « d'extrêmes ».
En tous cas, ton Makefile « tout prêt », il ressemble vraiment beaucoup à ce que génère autoconf/automake.
Et bien sûr le système présenté ici, smk, oubli tous les autres aspects importants qui arriveront avec tout projet qui mature : gérer la distribution, l'installation (et la désinstallation), les licences des sources, la reproductibilité, etc.
Bref, intéressant comme essai pédagogique, mais assez inutile pour de la vraie production.
La GPLv2 a eu une faille non envisagée par Stallman à l'époque : la tivoïsation. Ce problème jugé non éthique par Stallman a été corrigé dans la GPLv3. Bizarrement la GPLv2 reste une licence acceptable pour la FSF et Stallman.
Puisque des connards ont utilisé la licence d'une manière non-envisagée par son créateur, il faudrait que ce dernier la renie ? Mais tu es malade !
C'est un cas très concret qui montre que la FSF comme Stallman pouvaient aller plus loin avec les licences que les 4 libertés pour défendre le mouvement mais que bizarrement cela n'est toujours pas un prérequis malgré tout ce qu'ils ont pu en dire sur le sujet.
Comment aurait-il pu « aller plus loin » ? (bis)
Et pourtant, la FSF n'a jamais condamné ces projets comme étant OpenSource et pas libre d'une part.
Mais WTF ? La FSF reprend des projets dont elle trouve l'orientation politique inadéquate, mais qui sont techniquement intéressants (et libres), et en propose une version qui reprend mieux ses objectifs. Qu'est-ce qui ne te va pas là-dedans ?!
Et d'autres part cela ne leur semble pas problématique de bâtir du Logiciel Libre (politique selon toi) à partir de logiciels considérés comme OpenSource.
Ces logiciels sont publiés sous une licence qui respecte les quatre libertés, et peuvent donc être utilisés à toute fin politique. Que leurs auteurs originaux ne le veuillent pas n'est pas un problème : la FSF fork et c'est tout. Encore une fois, quel est le problème ?!
C'est comme aller dans un magasin qui prône le bio produit localement et qui propose du bio provenant de Nestlé produit à l'autre bout du pays.
La production agricole n'a rien à voir avec le développement logiciel. Sinon je vais commencer à faire des analogies avec des voitures… Des développeurs diffusent leur logiciels sous une licence offrant les quatre libertés. Ils ne souhaitent pas défendre de but politique. D'autres continuent une version dont ils souhaitent promouvoir la liberté qu'apporte ces logiciels à leurs utilisateurs. Où est le problème ?! (bis repetita)
S'ils veulent plus que les 4 libertés, il faut que cela concerne tout ce qu'ils font et qu'ils promeuvent. Sinon c'est la preuve que c'est du marketing.
Et comment tu définis « plus » dans une licence ? Légalement parlant, on n'a pas besoin de plus. L'intention politique n'est pas traduisible dans un contrat.
Non, le problème est technique, pas politique.
Si tu dis ça, je pense que tu n'as pas compris.
Je te renvoie à la biographie de Stallman où très clairement la problématique à l'origine du Logiciel Libre était plus pratique que politique.
Oui, au début tu vois un problème et tu essayes de le résoudre, c'est pratique. Puis tu en rencontre d'autres, et tu croises d'autres personnes intéressées, et ça devient un mouvement. Qui devient politique. Et ?
Et le fait qu'ils n'ont jamais remis en cause que les 4 libertés suffisent pour faire du LL en est la preuve flagrante. Ce sont eux qui ont changé leur com'.
Et pourquoi les remettre en cause ?! Elles sont très bien ! Quel « changement » a-t-il eu lieu ?
Alors que si le libre politique avait un autre nom, ce serait de suite plus clair pour tout le monde.
Un mouvement politique ne se traduit pas dans une licence. (ad nauseum)
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.
Posté par benoar .
En réponse au journal Bug réseau chez Free.
Évalué à 4.
Dernière modification le 11 décembre 2018 à 15:47.
Ç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.
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.
[^] # Re: Une amélioration possible
Posté par benoar . En réponse au journal `smk`, un make sans Makefile. Évalué à 2.
Non. Le build est lié à la licence, car un bon système de build permet de respecter qu'on distribue bien les sources associées à tel binaire, et qu'on est capable de le reproduire dans un environnement donné. Pour l'installation, le linkage peut être dépendant de la manière dont sont installées les bibliothèques, et tu devras forcément introduire dans ton système à un moment où aller chercher tel fichier. Ces problématiques sont très liées, et limiter un outil de build à faire uniquement ça c'est dupliquer les efforts pour plus tard gérer les autres aspects.
C'est parce que builder, installer, reproduire et installer sont un ensemble de problèmes complexe. Les autotools sont éventuellement une usine à gaz pour la flexibilité dans certains choix, mais ils simplifient tout de même beaucoup l'ensemble de ces tâches, avec des paramètres par défaut plutôt bon qui font qu'on n'a pas forcément à toucher tout son paramétrage.
Si on avait un système de package (au sens « distribution Linux » du terme) universel, oui on pourrait, mais c'est un problème politique trop grand. Alors c'est l'inverse qui est arrivé : le packaging Debian (par exemple) d'un paquet déjà géré par autotools est fait en une ligne de procédure (et quelques lignes de description de données spécifiques au système de Debian).
[^] # Re: des pistes
Posté par benoar . En réponse au message Conditions d'accès aux réseaux fibres publics. Évalué à 4.
Je ne connais aucun déploiement du genre : ce sont toujours des co-investissements public-privé, où le privé est souvent majoritaire. L'État en tant que « maître de l'infrastructure » est malheureusement un modèle oublié aujourd'hui.
Ça c'est la théorie. Dans la pratique, le délégataire est souvent un des « gros » classiques (opérateur télécom ou BTP) et ne respecte que ce qui l'arrange. La liste des RIP de la fédé https://www.ffdn.org/wiki/doku.php?id=travaux:rip_et_ftth est bien jolie, mais personne n'arrive à accéder à quoi que ce soit. Même accéder simplement au document publics (!) est une gageure : https://www.ffdn.org/fr/article/2018-11-17/la-recherche-des-rip-ftth-acceder-aux-documents-administratifs-cest-plus-long-que.
Pour avoir essayé d'accéder (membre d'un FAI local) et vu la réalisation (membre de commission consultative) de ces RIP, au final, à force de croiser (certains) des élus que je qualifierai de corrompus et de déploiements taillés pour les gros du privé, je vois difficilement un moyen de faire avancer les choses « dans le bon sens », même si je salue le travail de toute la fédé là-dessus.
Ça fait plusieurs dizaines d'années que le déploiement d'infrastructure (et pas uniquement fibre) en France est poussé vers le privé par les politiques néolibérales, et les personnages politiques pour qui votent les gens ne remettent malheureusement pas en cause cette tendance. Les combats menés par la fédé sont bons, mais c'est du pipi de chat comparé à la puissance des ogres du privé soutenus par nos politiques. Quasiment aucun politique ne remet ça en cause, à par ceux qu'on qualifie à tort « d'extrêmes ».
[^] # Re: Une amélioration possible
Posté par benoar . En réponse au journal `smk`, un make sans Makefile. Évalué à 2.
Pour un argumentaire sur le fait que lister les fichiers, c'est bien, voir la doc d'automake :
https://www.gnu.org/software/automake/manual/html_node/Wildcards.html#Wildcards
En tous cas, ton Makefile « tout prêt », il ressemble vraiment beaucoup à ce que génère autoconf/automake.
Et bien sûr le système présenté ici, smk, oubli tous les autres aspects importants qui arriveront avec tout projet qui mature : gérer la distribution, l'installation (et la désinstallation), les licences des sources, la reproductibilité, etc.
Bref, intéressant comme essai pédagogique, mais assez inutile pour de la vraie production.
[^] # 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é à 2. Dernière modification le 11 décembre 2018 à 17:00.
Puisque des connards ont utilisé la licence d'une manière non-envisagée par son créateur, il faudrait que ce dernier la renie ? Mais tu es malade !
Comment aurait-il pu « aller plus loin » ? (bis)
Mais WTF ? La FSF reprend des projets dont elle trouve l'orientation politique inadéquate, mais qui sont techniquement intéressants (et libres), et en propose une version qui reprend mieux ses objectifs. Qu'est-ce qui ne te va pas là-dedans ?!
Ces logiciels sont publiés sous une licence qui respecte les quatre libertés, et peuvent donc être utilisés à toute fin politique. Que leurs auteurs originaux ne le veuillent pas n'est pas un problème : la FSF fork et c'est tout. Encore une fois, quel est le problème ?!
La production agricole n'a rien à voir avec le développement logiciel. Sinon je vais commencer à faire des analogies avec des voitures… Des développeurs diffusent leur logiciels sous une licence offrant les quatre libertés. Ils ne souhaitent pas défendre de but politique. D'autres continuent une version dont ils souhaitent promouvoir la liberté qu'apporte ces logiciels à leurs utilisateurs. Où est le problème ?! (bis repetita)
Et comment tu définis « plus » dans une licence ? Légalement parlant, on n'a pas besoin de plus. L'intention politique n'est pas traduisible dans un contrat.
Si tu dis ça, je pense que tu n'as pas compris.
Oui, au début tu vois un problème et tu essayes de le résoudre, c'est pratique. Puis tu en rencontre d'autres, et tu croises d'autres personnes intéressées, et ça devient un mouvement. Qui devient politique. Et ?
Et pourquoi les remettre en cause ?! Elles sont très bien ! Quel « changement » a-t-il eu lieu ?
Un mouvement politique ne se traduit pas dans une licence. (ad nauseum)
[^] # 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é à 2. Dernière modification le 11 décembre 2018 à 16:03.
Comment ? J'écoute tes propositions.
Le combat politique est une fin, la GPL avec ses quatre libertés un moyen.
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 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 » ?!
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 ?
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.
# Quelle daube
Posté par benoar . En réponse au journal Bug réseau chez Free. Évalué à 4. Dernière modification le 11 décembre 2018 à 15:47.
Ç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).
[^] # Re: un hyperviseur qui déchire
Posté par benoar . En réponse à la dépêche Proxmox VE 5.3 vient avec CephFS. Évalué à 3.
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).
[^] # Re: rebase
Posté par benoar . En réponse à la dépêche Nouvelles de Git : 2.20.0, Git Merge, etc.. Évalué à 10.
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).
[^] # 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.