L'UE forte et protectrice ressemble à une chimère, puisque l'architecture de l'UE vise au contraire à affaiblir les puissances publiques et leur retirer le moyen de protéger les populations.
Vision simpliste et reductrice. Le principe de base de l'UE est justement une perte de pouvoir au niveau national pour un gain de pouvoir au niveau supra-national. Et De ce coté la, l'UE fonctionne à merveille.
Tu fais de la mauvaise fois à tous tes paragraphes. Tes flugschreiber (oui l'allemand c'est plus classe que l'anglais) tu les as aussi dans tes paquets debian/rpm ou autre.
Quand on utilise une langue ( ou fait semblant ), c'est bien de la connaître un minimum et d'éviter Google Translate.
Blackbox se dit "blackbox" en Allemand. L'allemand est une langue précise et "flugschreiber" est réservé pour les boites noires des avions.
Non à quoi ? tu peux être en désaccord avec certains de mes propos, mais je doute que tu sois en désaccord sur la totalité si ce n'est juste par pur plaisir de contrariété.
Docker se base sur un dockerfile, ce qui te permet de reconstruire un docker très facilement. Toutes les images du docker hub sont reconstructibles facilement (tu clone le dépôt et tu build). Mettre à jour ou modifier une image est triviale. C'est le langage partagé par tous les linux : le shell.
Un docker container est une blackbox ( ou une boite noire si ça peut te faire plaisir ). C'est un gros ensemble binaire indivisible pas très différent d'une tarball de fichiers binaires. Tu peux certes créer ce blob à l'aide d'un script bash, mais ça reste la production d'un blob avec un contenu indivisible en lui même.
D'ailleurs, je te propose d'envoyer un gros script bash à ton sys-admin qui pip install la moitié d'internet, curl quelques binaires pré-compilés, installes des RPM depuis des repos non-trustés, et sed ses propres fichier de configuration. Tu lui dis "pas de soucis, c'est reproduisible, c'est un script linux bien connu, du SHELL, on peut déployer ça en production" et tu regardes sa réaction.
Je te conseil de courir vite également.
Ça te choque de faire quelque-chose comme ça ? C'est pourtant exactement ce que fait un bon paquet de DockerFile, et exactement ce que font un grand nombre d'utilisateur de Docker.
Maintenant ne me fait pas dire ce que je n'ai pas dit. Docker est un outil fantastique et une trés bonne technologie. Seulement ce n'est PAS un système de packaging.
C'est un système de shipping avec un système de snapshot (oui de l'anglais, encore ). Même son nom l'indique d'ailleurs.
Ça ne résous absolument pas les autres problématiques associés au packaging que j'ai listé précédemment ( tracabilité, update incrémentale, construction depuis les sources, versionning).
Les deux sont complémentaires et ça beaucoup de développeurs tentent à l'oublier.
Ça n'a rien de compliqué, ça ne te demande pas d'apprendre des choses démentes.
Je te conseil d'essayer de re-construire à chaque faille d'OpenSSL, ou chaque mise à jour de libc une infrastructure qui contient 500-600 containers docker en productions… Allez de préférence, avec des distributions différentes et des images différentes.
Et aprés tu compareras ça avec ce que tu peux faire avec un infra puppet ou ansible, et un packaging proprement fait.
Du coup peut être que flatpack sera mon eldorado ? ;-)
Flatpack ou Docker sont à mon sens des fausses solutions.
Ce que te donne flatpack ou Docker, c'est un environnent isolé où le développeur est roi: Il y installe ce qu'il veut, comme il veut… et l'utilisateur n'a pratiquement aucun contrôle sur ça.
L'avantage c'est que ça donne une flexibilité total au développeur, l’inconvénient c'est que ton "package" devient une blackbox avec une plétoire de dépendances dupliquées, trés souvent, qui ne sont pas à jour.
Shipper du flatpack, du docker revient à shipper un grossso modo blob binaire compilé statiquement dans un environment pseudo-isolé.
Prenons un exemple simple : Admettons que je télécharge Firefox, VLC, FreetuxTV et owncloud, et une bonne 15ene de logiciels en archive flapack…..
Et comme toujours, une faille OpenSSL arrive….. Il me faudra attendre que chaque développeur de chaque application dédaigne updater son propre blob….. c'est à dire probablement plus d'une semaine pour avoir un système "sur" à nouveau…. La où va le système centralisé actuel, ça prendrait quelques heures.
C'est le problème N°1 des containers ou des systèmes "tout en un" style .dmg sous OSX…. La duplication des dépendances.
Le monde du packaging est oui, en effet, le bordel. Mais ce n'est pas sans raisons…
Chaque package système a été crée pour résoudre un ou des problématiques précises, et souvent contradictoires.
RPM ou Deb sont clairement orienté "sys admin", ils ont été désigné pour le système et par le système :
- Ils compilent depuis les sources
- Autorisent l'ajout de "patch" home made pour gérer ton infrastructure, la recompilation meme du kernel lui meme…
- Supportent une résolution des dépendances complexes et sont fait pour des updates "smooth"
- Mettent un accent important sur la sécurité signature
- Integrent des choses comme
- le support de la documentation
- la gestion des symbols de debuggage
- la separation des headers / libs
Mais d'un autre coté :
- Ils demandent un apprentissage et un effort conséquent
- Ils sont peu ou pas du tout adaptés a la gestion des versions multiples
- Ils nécessitent les droits roots
- Ils ne sont pas fait pour du packaging quick & dirty ( deploiement de binaires )
Pour toute ces raisons, on a vu l’émergence de système packaging orienté "développeur" bien plus "quick & dirty" et souvent langage spécifique pour une meilleur intégration avec l’environnent de développement :
pip pour python, gem pour Ruby, cargo pour rust, mvn pour Java, npm pour node, cabal pour haskell, cpan pour perl, go get pour go …. Et j'en oublie….
L'avantage de ça, c'est que si ils sont en effet très "pratique" pour du développement et du déploiement rapide… car sont très bien intégrés avec leur langage respectif et demande un effort minimal pour packager une nouvelle app existante..
Le problème de ça c'est que ce sont bien souvent des cauchemars à administrer qui risque très certainement de causer plusieurs crises d’épilepsie a votre pauvre sysadmin.
Ils sont difficile à tracer car souvent installer en home-env
Certains ont une sécurité souvent douteuse (…pip)
Ils s’intègrent pas ou peu avec des softs en code natifs ou dans un langage concurrent
Le versionning est souvent partiel, ou même incomplet
ils necessitent tous leur propre repository…. souvent sous control externe.
La reproducibilité est souvent une catastrophe.
Maintenant qui blamer dans l'histoire ? Le sysadmin conservateur ou le developpeur avant-gardiste ?
Je dirai, aucun des deux. Chacun a ses cas d'utilisations et de très bonnes raisons de faire ce qu'il fait.
Ce qu'il faudrait c'est avant tout un peu de compréhension mutuel qui aiderait a ce que :
1- le developpeur comprenne que non, deployer un tool obscure à coup de pip en production n'est pas acceptable
2 - le sys admin comprenne que oui, utiliser un compilateur ou un package vieux datant de la premiere guerre mondiale, est souvent une grosse source d'emmerdes.
Et la solution sur le long terme pourrait venir de packaging système "hybride" comme Nix (http://nixos.org/) qui essaient de conjuguer le "moins-pire" des deux mondes.
J'y pense depuis des mois, et il faudrait que je rédige un article plus détaillé, parce que je suis assez ennuyé par tous ces systèmes de communication qui vantent un chiffrement de bout en bout, sans complexité pour l'utilisateur, et prétendent n'avoir aucun moyen de déchiffrer les communications, même si on leur demande très très fort.
Même si je tends à être d'accord avec toi sur le fait que la plupart des apps qui se vantent d'etre inviolable est du FUD, il y a une grosse difference entre une app possiblement sensible a une attaque MiM et une apps qui offre gentille-ment tout ton historique de conversation a une société commerciale X.
Par nature une apps comme Signal rends impossible le déchiffrement de tes conversations passées. Ce qui est déjà une amélioration majeure comparé à ton chat facebook qui stock toutes tes conversations en clair server side. ( Et les analyses au passage evidemment … )
De plus si oui théoriquement il est possible d'effectuer une attaque MiM sur une conversation Tox, Signal ou autre. Ce n'est pas quelque chose que tu peux appliquer à l’échelle d'un pays ou d'un continent sans que ca se voit…. quand c'est tout a fait faisable, voir trivial pour les SMS ou ton chat Facebook.
La sécurité n'est pas une notion absolue. La vrai sécurité requiert un certain pragmatisme où le mieux est déjà meilleur que le rien du tout.
```
Oui le problème n'est pas les méta-informations qui transitent par chez eux mais les informations & les méta-informations qui transitent par Google lorsque l'on UTILISE l'application Signal.
Elles ne transitent pas Google Cloud uniquement sur la version Android, principalement pour les vieilles versions.
Et si tu utilises Android, je pense que les meta-données de Signal devrait etre la derniere chose au sujet de Google que tu devrais te soucier. Car si tu as Signal, tu as les Google Apps, qui envoient bien bien bien plus que "quelques meta-donness".
L'avantage de Signal selon moi se tient en trois points :
La facilité d'utilisation, même pour une personne lamda.
L'encryption end-to-end qui te garantie que ni facebook, ni Google fait de l'analitics sur tes conversations.
Le code open source fait par des gens renommés qui savent ce qu'ils font. non par Kevin, crypto-expert improvisé en Javascript depuis hier.
On est bien d'accord que c'est Signal, Moxie Marlinspike et Open Whisper Systems qui choisissent d'utiliser Google Cloud Messaging et MapView.
Utiliser Google Cloud messaging, TCP/IP directement, SMS ou n'importe quel solution de messaging lambda importe peu. De nos jours n'importe quel channel de communication doit etre considéré comme radioactif et potentiellement espioné.
C'est le systeme de chiffrement et la maniere dont il designé qui compte. Et en ce qui concerne ca, Signal a pas grand chose à envier aux autres apps du genre.
Les spécifications du yaml sont pourtant assez simples et intuitives…
Sur ce point je ne suis pas vraiment d'accord.
YAML semble être simple au premier abord… mais il est tout sauf simple en pratique…. Écrire un parseur complet YAML n'a rien de trivial.
YAML a des notions comme les réferences, les tags, les documents imbriqués, les scalaires, le multi-ligne et plusieurs format d'encoding. Il supporte également les graphes cycliques que seul les formats style XML supportent.
Le spécification YAML fait plus de 70 pages….. Ceci à comparer à la demi-page de la grammaire du JSON.
YAML a rien de trivial. Son seul avantage a mes yeux est sa lisibilité due à ses choix faits pour l'indentation…. Ce même choix qui rend les documents YAML complexe un cauchemars à valider….
Je vais me faire des ennemis en disant ça, mais à mon humble avis : YAML n'est PAS un bon format de configuration…. Il tend juste à être plus "lisible" que XML et supporte les commentaires contrairement à JSON….
Je déteste YAML, bien que super puissant, je trouve ce format très peu pratique en modification.
Je ne sais jamais s'il faut indenter avec plus d'espace ou non, mettre un tiret ou non… Bref c'est la misère pour ma part.
[troll mode on]
YAML est le produit de quelqu'un qui s'est dit que d'associer la complexité inutile du XML, les opérateurs de Perl et l'indentation de Python serait une sacré bonne idée.
En tous cas, c'est toujours triste de lire ce type de mésententes. ;-(
J'appellerai pas ça un problème de mésententes, c'est surtout un problème classique de point de vue développeur vs packageur.
Le développeur veut pusher vers la dernière version de son software, et généralement sous-évalue l'importance de la rétro-compatibilité et le coté disruptifs de ses mise à jour
Le packageur ( ou l'admin ) se DOIT de fournir une rétro-compatibilité et des updates sans casse. Sous peine de voir la moitié de son département passer par son bureau avec des fourches à chaque update.
Pour être fait correctement, l'aspect déploiement et mise à jour d'un software doit être prise en compte dés le début de sa conception ( ABI, API publique, API privé, protocols, schéma DB,… ).
Si ce n'est pas le cas, ça vire très rapidement au désastre. Et dans le cas de owncloud ( et de beaucoup de softs en PHP au passage), ça n'a pas été le cas.
Yep, ils utilisent des produits qui ont une demi-vie trés courte ( moins de 12 heures ) et qui sont fait pour ne pas se fixer dans l'organisme.
Ceci dit, ce genre de scan ou un IRM, t'expose généralement à une dose de radioactivité bien supérieur à la dose qu'un travailleur dans le domaine nucléaire peut prendre en une année.
Mais étant donné qu'il n'y a pas de risque de contamination, et que l'exposition est de courte durée, c'est considéré comme "acceptable".
My 2 cents.
Correction: c'est largement supérieur à ce qu'un "Civil" peut prendre en une année. Pour un travailleur du nucléaire, c'est pratiquement son maximum autorisé.
C'est quoi la valeur par défaut d'un pointeur de fonction qui as du sens ? nullptr, ou une fonction au hasard ? Les deux cas n'ont pas de sens et sont dangereux, bref, avoir un pointeur "default-initialised" n'as pas de sens.
L'initialisation par défaut a du sens et c'est évident. Je sais que les programmeurs Haskell adore rappeler au autres à quel point leur langage est supérieur à la plèbe de ce monde car il n'autorise pas l'initialisation, mais la tu fais preuve d'un poil de mauvaise fois :)
Un dangling pointer va te causer des effets de bords alétoire, dépendant de la platforme et de l'initialisation de la mémoire. Dans le cas de l'utilisation d'un pointeur non initialisé, tu peux trés bien obtenir un programme qui marchera pendant 10 ans car ton pointeur utilise une région de mémoire qui est aléatoirement remplit de zero, et qui va segfaulter aleatoirement aprés dix ans car pour une raison X, ce segment de mémoire était différent ce jour là.
Dans le cas d'une initialisation forcée à null_ptr, tu auras un comportement déterministique ( qui segfaultera ) ce qui est déja bien plus "safe".
L'initialisation par défaut doit TOUJOURS être fait, sauf si trés bonne raison, point barre.
Ici mon seul contrat concernant le constructeur par défaut c'est le petit commentaire qui dit "black". C'est faible, et demain ce constructeur par défaut peut changer très facilement pour construire une autre couleur, sans doute le blanc, car pour les besoins de ce projet on fait plus du multiplicatif sur les couleurs que de l'additif, donc le blanc semble un meilleur choix par défaut.
Dans ce cas, ton problème est ton développeur qui trouve bon de changer le comportement par défaut d'une fonction sans changer l'API. Ce qui est idiotique et inacceptable dans tout code partagé. Le problème ce n'est pas l'initialisation par défaut, encore une fois.
C'est pas clair à quel point c'est du C++ ou à quel point c'est une extension au standard actuel.
C'est du pure C++ sauf erreur de ma part.
La syntaxe est tout de même vraiment répugnante.
Question de goût. Je trouve la syntaxe au contraire très clair pour du code templaté.
Par contre comme tout comme templaté assez poussé, je suis curieux de la taille des messages d'erreurs à la compilations
Avec d'autres langages, le pattern matching c'est extrêmement puissant, concis et clair et cela fait partie des outils qu'il me manque dramatiquement quand je fais du C++.
Je ne suis on ne peut plus d'accord. C'est au programme du comité de normalisation C++, donc espérons.
Il ne reste que des developpeurs .JS de nos jours. :P
[mode vendredi]
Ne leur donne pas d'idée malheureux !
Ou on va se retrouver avec une sortie JSON sur tous les coreutils sous peu.
Et un shell nodeJS à la place de bash.
Visiblement, il faut compter environ 100€ du ml pour la pose. Imaginons un village de n foyers, touts raccordés à la fibre, à 1km du NRA. Ça te fait 100k€ à amortir. Rien que pour payer les intérêts, il faut rentrer 2k€ par an, plus l'amortissement sur 20 ans (c'est long, 20 ans, rien ne te dit qu'il ne faudra pas installer une nouvelle techno d'ici là)
Si tu as un bled de 1000 pékins en pleine cambrousse avec 5 km de fibre à tirer, ça ne sera jamais rentable, c'est à peine si tu peux espérer couvrir les intérets de l'investissement.
J'aime bien ton raisonnement et ton pragmatisme, et je suis globalement d'accord avec toi sur le fait que oui ca ne sera jamais rentable pour les micro patelins.
Mais quelques points à prendre en compte dans les calculs:
1) L'état est l'état, et contrairement à toi ou à un investisseur privé. Il a accès à des crédits avec des taux bien inférieurs à 2% ( voir negatifs ).
C'est ce qu'a utilisé l'Estonie pour développer son réseau fibre à la campagne, ce qui en fait un des pays les mieux connecté au monde.
2) Il arrive assez souvent que même les petits patelins ont déjà un point fibre communale ( DSLAM, ecole, administration, ou grosse entreprise ) . Ce qui manque, c'est uniquement les derniers 100-500 metres de la boucle locale ( C'est le cas du village de mes parents par exemple, ou la fibre traverse la moitié du département )
Peut-être que ne pas opposer économie et assurer un service à la population serait le meilleur moyen d'assurer un service à la population?
C'est ta pensée, si tu aimes te revendiquer neoliberale Pas la mienne.
Ne pas s'opposer a l'économie quand elle assure un service à la population est le meilleur moyen d'assurer un service à la population.
On s'est relativement assez vite aperçu que filer gratos l'électricité au perdu dans sa montagne est faire travailler beaucoup de gens pour le plaisir d'un seul, et on a mis des limites à la bêtise, même pour l'électricité.
Fait est qu'en pratique même les villages de montagnes isolés sont raccordés au réseau.
Et puis bon, à l'époque on pouvait faire travailler les gens 50 heures/semaine pour pas cher (et ils mourraient tôt), chacun sa vision du service à la population sans doute.
Je ne commenterai même pas un argument aussi ridicule.
Ou alors on aurait un meilleur service pour 99% de la population en ayant dit plus tôt "stop" au couteux 1% qui veulent avoir le beurre et l'argent du beurre.
On a déja le meilleur ( ou un des meilleur ) réseau de distribution d’électricité en Europe ET on alimente les petits patelins.
De rien.
Et de perdre environ 4x sa valeur en bourse (donc dans la valorisation de ses actionnaires, en premier toi et moi), et ce n'est pas fini (quand on va comprendre le coût pour traiter le nucléaire…)
Nucléaire. Rien à voir avec le paté, ni avec RTE ou Engie.
EDF était déjà dans le top européen avant même d’être privatise.
Bref, l'économie ça n'est pas quelque chose d'absolument mystérieux. Si c'est rentable de poser la fibre chez toi (autrement dit, si ton abonnement correspond au coût du service qu'on te rend), tu vas avoir la fibre. Si ça n'est pas rentable, tu n'auras pas la fibre. Et demander à l'État, à la commune, ou à une boîte privée de te la poser quand même, c'est une faveur, ça n'est pas un droit.
L'Economie n'a rien de mystérieux mais il faut savoir ce qu'on veut: faire du fric ou assurer un service à la population de la meilleur facon possible.
Si on s’était poser la question de l’économie en France, au lieu justement de considérer l'accés à l’électricité comme un droit. On aurait à l'heure actuel des villages de 50 habitants toujours pas raccorder au réseau.
Hors ce n'est pas le cas… car on a fait les investissement qui fallait, quand il fallait…
Et au passage, ca n'a jamais empêcher EDF d'etre un des plus gros poids lourds dans le domaine de l’énergie au niveau européen
Ce que tu appelles "volonté collective", c'est de nationaliser les activités déficitaires et de privatiser les activités qui génèrent des bénéfices, c'est ce qu'on fait depuis 30 ans et qui explique en grande partie les abysses des déficits publics.
Ça n'a pas forcement a être déficitaire, c'est un investissement qui peut devenir même lucratif après une durée donnée. C'est le même modèle que les autoroutes à péages avant qu'on les privatisent et proche du modèle du réseau électrique.
On peut aussi faire payer les coûts réels aux gens qui veulent à la fois le haut débit et des voisins à 3 km. Ça n'a pas l'air juste, mais c'est un peu pareil que le parisien qui voudrait voir la voie lactée et respirer l'air des montagnes sans franchir le périph.
Il y a un juste milieu à tout, le petit vieux dans son village de 2500 habitants veut aussi la Fibre.
Ça serait en théorie rentable de lui mettre, mais il aura la Fibre probablement dans 30 ans avec le modèle actuel car aucun opérateur privé n'investira un péni pour lui si le ROI se fait après 20 ans.
C'est aussi une question de coûts, quand on veut de l'espace pas cher il faut accepter que d'autre choses soient plus chères quand c'est fait. Donc se plaindre gratuitement ne va pas changer la problématique financière, as-tu des propositions pour régler le problème?
Faire comme ça a été fait dans l'Ain avec réseau LIAin : le département (l'état) installe la Fibre et la loue à des opérateurs privé.
1) Ca juste marche, le réseau est neutre et de qualité.
2) Même les villages sont couverts. L'Ain a l'une des meilleurs couverture fibre départementale de France.
3) La concurrence entre service pro-vider est maintenu.
4) Ca développe les petits opérateurs locaux.
5) On evite une situation de monopole débile comme au Etats Unis ou un seul opérateur est disponible par secteur et défini les prix qu'il veut.
Mais pour ça il faut éviter de baisser son froc devant les FAIs et avoir un minimum de volonté politique, une qualité rare de nos jours.
[^] # Re: une Union Européenne forte et protectrice
Posté par Firwen (site web personnel) . En réponse au journal Pulse of Europe. Évalué à 4.
Vision simpliste et reductrice. Le principe de base de l'UE est justement une perte de pouvoir au niveau national pour un gain de pouvoir au niveau supra-national. Et De ce coté la, l'UE fonctionne à merveille.
[^] # Re: Droits fondamentaux...
Posté par Firwen (site web personnel) . En réponse au journal Pulse of Europe. Évalué à 1.
Je dois t'avouer que le "glissement authoritaire de l"UE" serait bien le dernier des glissements authoritaires qui m'inquiteraient a l'heure actuelle…
[^] # Re: A chaque clou son marteau
Posté par Firwen (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 3.
Je viens de passer 3 paragraphe à tenter de l'expliquer et j'ai la forte impression que tu ne veux pas écouter dans tous les cas.
Ceci dit, si tu es au FOSDEM, fait le moi savoir, je te paie un café et on pourra en discuter :)
[^] # Re: A chaque clou son marteau
Posté par Firwen (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 1. Dernière modification le 01 février 2017 à 15:50.
Quand on utilise une langue ( ou fait semblant ), c'est bien de la connaître un minimum et d'éviter Google Translate.
Blackbox se dit "blackbox" en Allemand. L'allemand est une langue précise et "flugschreiber" est réservé pour les boites noires des avions.
[^] # Re: A chaque clou son marteau
Posté par Firwen (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 9. Dernière modification le 01 février 2017 à 12:12.
Non à quoi ? tu peux être en désaccord avec certains de mes propos, mais je doute que tu sois en désaccord sur la totalité si ce n'est juste par pur plaisir de contrariété.
Un docker container est une blackbox ( ou une boite noire si ça peut te faire plaisir ). C'est un gros ensemble binaire indivisible pas très différent d'une tarball de fichiers binaires. Tu peux certes créer ce blob à l'aide d'un script bash, mais ça reste la production d'un blob avec un contenu indivisible en lui même.
D'ailleurs, je te propose d'envoyer un gros script bash à ton sys-admin qui pip install la moitié d'internet, curl quelques binaires pré-compilés, installes des RPM depuis des repos non-trustés, et sed ses propres fichier de configuration. Tu lui dis "pas de soucis, c'est reproduisible, c'est un script linux bien connu, du SHELL, on peut déployer ça en production" et tu regardes sa réaction.
Je te conseil de courir vite également.
Ça te choque de faire quelque-chose comme ça ? C'est pourtant exactement ce que fait un bon paquet de DockerFile, et exactement ce que font un grand nombre d'utilisateur de Docker.
Maintenant ne me fait pas dire ce que je n'ai pas dit. Docker est un outil fantastique et une trés bonne technologie. Seulement ce n'est PAS un système de packaging.
C'est un système de shipping avec un système de snapshot (oui de l'anglais, encore ). Même son nom l'indique d'ailleurs.
Ça ne résous absolument pas les autres problématiques associés au packaging que j'ai listé précédemment ( tracabilité, update incrémentale, construction depuis les sources, versionning).
Les deux sont complémentaires et ça beaucoup de développeurs tentent à l'oublier.
Je te conseil d'essayer de re-construire à chaque faille d'OpenSSL, ou chaque mise à jour de libc une infrastructure qui contient 500-600 containers docker en productions… Allez de préférence, avec des distributions différentes et des images différentes.
Et aprés tu compareras ça avec ce que tu peux faire avec un infra puppet ou ansible, et un packaging proprement fait.
Même RedHat propose maintenant des solutions qui tentent de "scanner" les containers dockers à la volée pour analyser les versions réellement utilisées en production… C'est peu dire si la bête n'est un example de transparence … ( http://www.infoworld.com/article/3089425/application-virtualization/red-hat-builds-linux-container-security-scanning-into-rhel.html )
[^] # Re: A chaque clou son marteau
Posté par Firwen (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 8. Dernière modification le 31 janvier 2017 à 10:55.
Flatpack ou Docker sont à mon sens des fausses solutions.
Ce que te donne flatpack ou Docker, c'est un environnent isolé où le développeur est roi: Il y installe ce qu'il veut, comme il veut… et l'utilisateur n'a pratiquement aucun contrôle sur ça.
L'avantage c'est que ça donne une flexibilité total au développeur, l’inconvénient c'est que ton "package" devient une blackbox avec une plétoire de dépendances dupliquées, trés souvent, qui ne sont pas à jour.
Shipper du flatpack, du docker revient à shipper un grossso modo blob binaire compilé statiquement dans un environment pseudo-isolé.
Prenons un exemple simple : Admettons que je télécharge Firefox, VLC, FreetuxTV et owncloud, et une bonne 15ene de logiciels en archive flapack…..
Et comme toujours, une faille OpenSSL arrive….. Il me faudra attendre que chaque développeur de chaque application dédaigne updater son propre blob….. c'est à dire probablement plus d'une semaine pour avoir un système "sur" à nouveau…. La où va le système centralisé actuel, ça prendrait quelques heures.
C'est le problème N°1 des containers ou des systèmes "tout en un" style .dmg sous OSX…. La duplication des dépendances.
# A chaque clou son marteau
Posté par Firwen (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 10.
Le monde du packaging est oui, en effet, le bordel. Mais ce n'est pas sans raisons…
Chaque package système a été crée pour résoudre un ou des problématiques précises, et souvent contradictoires.
RPM ou Deb sont clairement orienté "sys admin", ils ont été désigné pour le système et par le système :
- Ils compilent depuis les sources
- Autorisent l'ajout de "patch" home made pour gérer ton infrastructure, la recompilation meme du kernel lui meme…
- Supportent une résolution des dépendances complexes et sont fait pour des updates "smooth"
- Mettent un accent important sur la sécurité signature
- Integrent des choses comme
- le support de la documentation
- la gestion des symbols de debuggage
- la separation des headers / libs
Mais d'un autre coté :
- Ils demandent un apprentissage et un effort conséquent
- Ils sont peu ou pas du tout adaptés a la gestion des versions multiples
- Ils nécessitent les droits roots
- Ils ne sont pas fait pour du packaging quick & dirty ( deploiement de binaires )
Pour toute ces raisons, on a vu l’émergence de système packaging orienté "développeur" bien plus "quick & dirty" et souvent langage spécifique pour une meilleur intégration avec l’environnent de développement :
pip pour python, gem pour Ruby, cargo pour rust, mvn pour Java, npm pour node, cabal pour haskell, cpan pour perl, go get pour go …. Et j'en oublie….
L'avantage de ça, c'est que si ils sont en effet très "pratique" pour du développement et du déploiement rapide… car sont très bien intégrés avec leur langage respectif et demande un effort minimal pour packager une nouvelle app existante..
Le problème de ça c'est que ce sont bien souvent des cauchemars à administrer qui risque très certainement de causer plusieurs crises d’épilepsie a votre pauvre sysadmin.
Maintenant qui blamer dans l'histoire ? Le sysadmin conservateur ou le developpeur avant-gardiste ?
Je dirai, aucun des deux. Chacun a ses cas d'utilisations et de très bonnes raisons de faire ce qu'il fait.
Ce qu'il faudrait c'est avant tout un peu de compréhension mutuel qui aiderait a ce que :
1- le developpeur comprenne que non, deployer un tool obscure à coup de pip en production n'est pas acceptable
2 - le sys admin comprenne que oui, utiliser un compilateur ou un package vieux datant de la premiere guerre mondiale, est souvent une grosse source d'emmerdes.
Et la solution sur le long terme pourrait venir de packaging système "hybride" comme Nix (http://nixos.org/) qui essaient de conjuguer le "moins-pire" des deux mondes.
[^] # Re: D'accord
Posté par Firwen (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 5.
Même si je tends à être d'accord avec toi sur le fait que la plupart des apps qui se vantent d'etre inviolable est du FUD, il y a une grosse difference entre une app possiblement sensible a une attaque MiM et une apps qui offre gentille-ment tout ton historique de conversation a une société commerciale X.
Par nature une apps comme Signal rends impossible le déchiffrement de tes conversations passées. Ce qui est déjà une amélioration majeure comparé à ton chat facebook qui stock toutes tes conversations en clair server side. ( Et les analyses au passage evidemment … )
De plus si oui théoriquement il est possible d'effectuer une attaque MiM sur une conversation Tox, Signal ou autre. Ce n'est pas quelque chose que tu peux appliquer à l’échelle d'un pays ou d'un continent sans que ca se voit…. quand c'est tout a fait faisable, voir trivial pour les SMS ou ton chat Facebook.
La sécurité n'est pas une notion absolue. La vrai sécurité requiert un certain pragmatisme où le mieux est déjà meilleur que le rien du tout.
```
[^] # Re: D'accord
Posté par Firwen (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 2.
Elles ne transitent pas Google Cloud uniquement sur la version Android, principalement pour les vieilles versions.
Et si tu utilises Android, je pense que les meta-données de Signal devrait etre la derniere chose au sujet de Google que tu devrais te soucier. Car si tu as Signal, tu as les Google Apps, qui envoient bien bien bien plus que "quelques meta-donness".
L'avantage de Signal selon moi se tient en trois points :
[^] # Re: .
Posté par Firwen (site web personnel) . En réponse au journal WhatsApp, sa porte discrète du fond et les backdoors de Signal. Évalué à 1.
Utiliser Google Cloud messaging, TCP/IP directement, SMS ou n'importe quel solution de messaging lambda importe peu. De nos jours n'importe quel channel de communication doit etre considéré comme radioactif et potentiellement espioné.
C'est le systeme de chiffrement et la maniere dont il designé qui compte. Et en ce qui concerne ca, Signal a pas grand chose à envier aux autres apps du genre.
[^] # Re: YAML beurk
Posté par Firwen (site web personnel) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 10.
Sur ce point je ne suis pas vraiment d'accord.
YAML semble être simple au premier abord… mais il est tout sauf simple en pratique…. Écrire un parseur complet YAML n'a rien de trivial.
YAML a des notions comme les réferences, les tags, les documents imbriqués, les scalaires, le multi-ligne et plusieurs format d'encoding. Il supporte également les graphes cycliques que seul les formats style XML supportent.
Le spécification YAML fait plus de 70 pages….. Ceci à comparer à la demi-page de la grammaire du JSON.
YAML a rien de trivial. Son seul avantage a mes yeux est sa lisibilité due à ses choix faits pour l'indentation…. Ce même choix qui rend les documents YAML complexe un cauchemars à valider….
Je vais me faire des ennemis en disant ça, mais à mon humble avis : YAML n'est PAS un bon format de configuration…. Il tend juste à être plus "lisible" que XML et supporte les commentaires contrairement à JSON….
[^] # Re: YAML beurk
Posté par Firwen (site web personnel) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 8.
[troll mode on]
YAML est le produit de quelqu'un qui s'est dit que d'associer la complexité inutile du XML, les opérateurs de Perl et l'indentation de Python serait une sacré bonne idée.
[mode troll off]
[^] # Re: ça date un peu...
Posté par Firwen (site web personnel) . En réponse au journal Owncloud viré de Debian. Évalué à 10.
J'appellerai pas ça un problème de mésententes, c'est surtout un problème classique de point de vue développeur vs packageur.
Le développeur veut pusher vers la dernière version de son software, et généralement sous-évalue l'importance de la rétro-compatibilité et le coté disruptifs de ses mise à jour
Le packageur ( ou l'admin ) se DOIT de fournir une rétro-compatibilité et des updates sans casse. Sous peine de voir la moitié de son département passer par son bureau avec des fourches à chaque update.
Pour être fait correctement, l'aspect déploiement et mise à jour d'un software doit être prise en compte dés le début de sa conception ( ABI, API publique, API privé, protocols, schéma DB,… ).
Si ce n'est pas le cas, ça vire très rapidement au désastre. Et dans le cas de owncloud ( et de beaucoup de softs en PHP au passage), ça n'a pas été le cas.
[^] # Re: La durée de vie
Posté par Firwen (site web personnel) . En réponse au journal j'ai testé... devenir radioactif. Évalué à 7.
Toutafé merci
IRM-> scannerLe scanner est à rayon X, l'IRM a résonnance magnétique.
[^] # Re: La durée de vie
Posté par Firwen (site web personnel) . En réponse au journal j'ai testé... devenir radioactif. Évalué à 7. Dernière modification le 06 décembre 2016 à 12:03.
Yep, ils utilisent des produits qui ont une demi-vie trés courte ( moins de 12 heures ) et qui sont fait pour ne pas se fixer dans l'organisme.
Ceci dit, ce genre de scan ou un IRM, t'expose généralement à une dose de radioactivité bien supérieur à la dose qu'un travailleur dans le domaine nucléaire peut prendre en une année.
Mais étant donné qu'il n'y a pas de risque de contamination, et que l'exposition est de courte durée, c'est considéré comme "acceptable".
My 2 cents.
Correction: c'est largement supérieur à ce qu'un "Civil" peut prendre en une année. Pour un travailleur du nucléaire, c'est pratiquement son maximum autorisé.
[^] # Re: Pas uniquement string
Posté par Firwen (site web personnel) . En réponse au journal Switch, chaîne constante et c++. Évalué à 4.
L'initialisation par défaut a du sens et c'est évident. Je sais que les programmeurs Haskell adore rappeler au autres à quel point leur langage est supérieur à la plèbe de ce monde car il n'autorise pas l'initialisation, mais la tu fais preuve d'un poil de mauvaise fois :)
Un dangling pointer va te causer des effets de bords alétoire, dépendant de la platforme et de l'initialisation de la mémoire. Dans le cas de l'utilisation d'un pointeur non initialisé, tu peux trés bien obtenir un programme qui marchera pendant 10 ans car ton pointeur utilise une région de mémoire qui est aléatoirement remplit de zero, et qui va segfaulter aleatoirement aprés dix ans car pour une raison X, ce segment de mémoire était différent ce jour là.
Dans le cas d'une initialisation forcée à null_ptr, tu auras un comportement déterministique ( qui segfaultera ) ce qui est déja bien plus "safe".
L'initialisation par défaut doit TOUJOURS être fait, sauf si trés bonne raison, point barre.
Dans ce cas, ton problème est ton développeur qui trouve bon de changer le comportement par défaut d'une fonction sans changer l'API. Ce qui est idiotique et inacceptable dans tout code partagé. Le problème ce n'est pas l'initialisation par défaut, encore une fois.
[^] # Re: Pas uniquement string
Posté par Firwen (site web personnel) . En réponse au journal Switch, chaîne constante et c++. Évalué à 1.
C'est du pure C++ sauf erreur de ma part.
Question de goût. Je trouve la syntaxe au contraire très clair pour du code templaté.
Par contre comme tout comme templaté assez poussé, je suis curieux de la taille des messages d'erreurs à la compilations
Je ne suis on ne peut plus d'accord. C'est au programme du comité de normalisation C++, donc espérons.
# Pas uniquement string
Posté par Firwen (site web personnel) . En réponse au journal Switch, chaîne constante et c++. Évalué à 3. Dernière modification le 31 août 2016 à 17:15.
Ça a quelques années déja, mais Bjarne Stroustrup avait publié à l'époque une petite lib permettant de faire du pattern matching "à l'OCaml" en C++.
Donc j'imagine également du "switch/Case" avec des string. ( j'imagine car je n'ai jamais joué avec )
https://github.com/solodon4/Mach7
Si tu veux t'amuser avec.
[^] # Re: Pour qui?
Posté par Firwen (site web personnel) . En réponse au journal Microsoft: Powershell libéré. Évalué à 5. Dernière modification le 22 août 2016 à 00:04.
Que le dieu du Pipe et de la stderr du grand Nord nous protège, je vois déja le NPM-marcheur-blanc et son armée de zombie codé en JS nous envahir.
(désolé)
[^] # Re: Pour qui?
Posté par Firwen (site web personnel) . En réponse au journal Microsoft: Powershell libéré. Évalué à 2. Dernière modification le 21 août 2016 à 19:38.
[mode vendredi]
Ne leur donne pas d'idée malheureux !
Ou on va se retrouver avec une sortie JSON sur tous les coreutils sous peu.
Et un shell nodeJS à la place de bash.
[/mode vendredi]
[^] # Re: Difficile à lire
Posté par Firwen (site web personnel) . En réponse au journal Internet, 5G et chantage. Évalué à 3.
J'aime bien ton raisonnement et ton pragmatisme, et je suis globalement d'accord avec toi sur le fait que oui ca ne sera jamais rentable pour les micro patelins.
Mais quelques points à prendre en compte dans les calculs:
1) L'état est l'état, et contrairement à toi ou à un investisseur privé. Il a accès à des crédits avec des taux bien inférieurs à 2% ( voir negatifs ).
C'est ce qu'a utilisé l'Estonie pour développer son réseau fibre à la campagne, ce qui en fait un des pays les mieux connecté au monde.
2) Il arrive assez souvent que même les petits patelins ont déjà un point fibre communale ( DSLAM, ecole, administration, ou grosse entreprise ) . Ce qui manque, c'est uniquement les derniers 100-500 metres de la boucle locale ( C'est le cas du village de mes parents par exemple, ou la fibre traverse la moitié du département )
[^] # Re: Difficile à lire
Posté par Firwen (site web personnel) . En réponse au journal Internet, 5G et chantage. Évalué à 9.
C'est ta pensée, si tu aimes te revendiquer neoliberale Pas la mienne.
Ne pas s'opposer a l'économie quand elle assure un service à la population est le meilleur moyen d'assurer un service à la population.
Fait est qu'en pratique même les villages de montagnes isolés sont raccordés au réseau.
Je ne commenterai même pas un argument aussi ridicule.
On a déja le meilleur ( ou un des meilleur ) réseau de distribution d’électricité en Europe ET on alimente les petits patelins.
De rien.
Nucléaire. Rien à voir avec le paté, ni avec RTE ou Engie.
EDF était déjà dans le top européen avant même d’être privatise.
D'autres trolls ?
[^] # Re: Difficile à lire
Posté par Firwen (site web personnel) . En réponse au journal Internet, 5G et chantage. Évalué à 6.
Commentaire additionel.
L'Economie n'a rien de mystérieux mais il faut savoir ce qu'on veut: faire du fric ou assurer un service à la population de la meilleur facon possible.
Si on s’était poser la question de l’économie en France, au lieu justement de considérer l'accés à l’électricité comme un droit. On aurait à l'heure actuel des villages de 50 habitants toujours pas raccorder au réseau.
Hors ce n'est pas le cas… car on a fait les investissement qui fallait, quand il fallait…
Et au passage, ca n'a jamais empêcher EDF d'etre un des plus gros poids lourds dans le domaine de l’énergie au niveau européen
[^] # Re: Difficile à lire
Posté par Firwen (site web personnel) . En réponse au journal Internet, 5G et chantage. Évalué à 3.
Ça n'a pas forcement a être déficitaire, c'est un investissement qui peut devenir même lucratif après une durée donnée. C'est le même modèle que les autoroutes à péages avant qu'on les privatisent et proche du modèle du réseau électrique.
Il y a un juste milieu à tout, le petit vieux dans son village de 2500 habitants veut aussi la Fibre.
Ça serait en théorie rentable de lui mettre, mais il aura la Fibre probablement dans 30 ans avec le modèle actuel car aucun opérateur privé n'investira un péni pour lui si le ROI se fait après 20 ans.
[^] # Re: Difficile à lire
Posté par Firwen (site web personnel) . En réponse au journal Internet, 5G et chantage. Évalué à 10. Dernière modification le 11 juillet 2016 à 18:13.
Faire comme ça a été fait dans l'Ain avec réseau LIAin : le département (l'état) installe la Fibre et la loue à des opérateurs privé.
1) Ca juste marche, le réseau est neutre et de qualité.
2) Même les villages sont couverts. L'Ain a l'une des meilleurs couverture fibre départementale de France.
3) La concurrence entre service pro-vider est maintenu.
4) Ca développe les petits opérateurs locaux.
5) On evite une situation de monopole débile comme au Etats Unis ou un seul opérateur est disponible par secteur et défini les prix qu'il veut.
Mais pour ça il faut éviter de baisser son froc devant les FAIs et avoir un minimum de volonté politique, une qualité rare de nos jours.