Moi aussi j'ai fais ce genre de trucs, mais il faut comprendre que c'est super dangereux
Evidemment que c'est super dangereux et que ce n'est pas un fonctionnement normal, mais ça arrive, et là tu es bien content de pouvoir agir en direct sur le serveur, surtout si le réseau est aussi en vrac au passage pour transférer ladite conf (et quand tu as toute la hiérarchie sur le dos, tu as l'impression de rejouer une mauvaise scène "couper le fil bleu ou rouge").
Ça t'arrive tellement souvent que le rapatrier, ça prend trop de temps ?
Ben quand l'équipe admin met en place plusieurs rebonds pour accéder à un serveur, çà peut vite devenir ca°°e-co°°°les.
Après dans l'idée générale de rendre le SI moins friable, plus carré, plus référencé, plus automatisés, avec des composants minimum (surface d'attaque réduite) je suis à 120% d'accord, mais encore faut il être le "maître des clefs".
Quand on débarque sur un SI "étranger" où on n'a jamais participé à sa création/évolution, et bien on s'adaptes à leurs habitudes.
Ou alors tu fais le TJW (Technical Justice Warrior :-) ) et tu te mets les internes à dos.
Par contre le serveur qui contrôle le cluster, m'étonnerait que tu vires le shell et VI dessus.
Les conteneurs c'est un peu un cas à part, c'est plus une "grosse commande/applicatione" qu'on ajoute au serveur hébergeur qu'un "serveur", donc oui, on peut les dépouiller de tout, limite réduit à init+process appli (on peut même aller plus loin et se dire qu'on peut virer le scheduler du kernel, vu qu'il y a une seule application qui tourne et est nécessaire).
Tous les directions informatiques ne sont pas au même niveau de compétence ou même niveau de technologie.
Des concepts qui marche pour l'un, ne marcheront pas pour les autres.
Et qui n'a jamais modifié un fichier de conf de prod en "live" pour débloquer le SI suite à un incident qui bloque tout et qui met en péril l'activité commerciale immédiate (bizarrement de votre chef direct jusqu'au DSI et le DG débarquent dans votre bureau) me jette la première pierre.
Spring a réussi, parce que c'était moins "lourd" à l'usage.
Entre une annotation devant la méthode qui l'utilise dans son fichier source dans son coin et un fichier externe (qui pouvait être commun entre plusieurs classes, pb de verrous quand il y a plusieurs dev par exemple…) ou je dois faire le mapping dans ma tête entre ce fichier de conf XML et le code source, et bien bizarrement, je préfère faire des annotations.
"grep -R @annotation *", c'est très très difficile comme syntaxe :-)
Un référentiel ou tu peux avoir a peu près confiance (modulo création/migration/destruction des quelques jours précédents dans une file d'attente de saisie manuelle/automatique) que toutes tes machines "actives" sont listées et que leur fonction est décrite (ça peut être un pauvre "serveur courriel" comme description).
Pas un référentiel a trou, parce qu'il n'est plus utilisé depuis sa mise en place ou sporadiquement avec des mise à jour à trou.
Quand je disais "notepad de base", c'est une galéjade, c'était pour dire qu'il n'y avais pas le dernier IDE/Text Editor/commande en ligne ou graphique avec tous les plugins "qui vont bien" à la mode ou qu'on maitrise du bout les yeux fermés et qu'il n'y aura pas les facilités qu'on a l'habitude d'utiliser à la maison ou quand on est dans une petite équipe indépendante.
Evidemment, que si on est réellement forcé de travailler avec un text editeur de base comme seul outil et aucune commande en ligne avancée, ça serait l'équivalent de creuser une tranchée à la cuillère, et pas grand monde l'accepterait, moi le premier.
Tu ne sais pas travailler avec du XML, va faire du JSON et du YAML (et du CSV).
Je me fous complètement du format des fichiers.
ça fait longtemps que je ne luttes plus sur ces questions quand j'arrive sur un projet déjà commencé ou les choix ont déjà été fait.
L'année dernière, j'ai travaillé sur un composant qui s'appuyait sur une API qui était binorme, SOAP et REST selons les appels.
ça fait longtemps maintenant, mais j'ai aussi travaillé sur une API XML pré-SOAP
Je n'ai rien contre le XML en soi, je dis que ça rajoute de la lourdeur au traitement/
Que ça soit pour les machines, le parsing n'est pas gratuit, le DOM en mémoire n'est pas gratuit, ou pour les humains, c'est plus "indigeste" de travailler avec.
Et qu'il y a une divergence entre ce que le XML devait apporter et l'utilisation concrète sur le terrain, ça devait nous faciliter la vie, je ne touve pas vraiment.
Je suis plus Java, c'est quand même bizarre que Spring ait eu autant de succès, alors qu'il ne fait pas plus que les anciens framework web+JEE+EJB avec leurs milliards de fichiers de conf XML.
Si les technos sont des plats, je n'aime pas le plat XML, et pourtant j'en mange quand il n'y a que ça, ce n'est pas pour autant que je dois dire que c'est "délicieux".
mais je ne comprends pas comment on peut accepter de travailler sans outil.
Sur les postes de travail, en général, tu peux installer un peu ce que tu veux (et pas toujours, je suis déjà tombé chez des clients qui ont une image standard du poste de W et tu n'es pas admin sur le poste de W pour installer de nouveaux outils, il faut trouver des versions "sans install").
Mais sur les serveurs, soit par "principe" de ne pas augmenter le nombre de technos/d'outils installés (moins d'éléments, moins de problèmes) ou parce que l'équipe administration ne veut pas s'écarter de la configuration standard de leur OS.
Surtout si les outils en questions ne font pas parti directement des dépôts éditeurs (dépôts tiers ou pire compilation des sources) et ne sont pas impliqués directement dans la "production" du SI (que l'outil de visualisation/édition soit là ou pas, ça ne changera rien au résultat produits par le SI).
Du coup, en général, si on peut faire du sftp/ftp sur les serveurs, ça crée une étape intermédiaire ou on rappatrie les fichiers sur le poste de W, c'est juste plus lourd.
Et oui, après plusieurs mois de bataille "politique" pour montrer le bien fondé de l'installation (inertie, résistance au changement, NIH,…), tu peux peut etre avoir les outils, mais le projet est déjà terminé.
De toute manière, c'est l'ipv6 la nouvelle norme, on va faire avec, hein, pas le choix de toute maniére :-)
C'est le côté "TINA" de la justification des 128bits qui me fait soulever un sourcil.
C'est un peu de l'uchronie, "et si on avait choisit du 64bits à l'époque (ce qui est déja 4 milliard de sous réseaux "ipv4")", et bien je pense qu'on aurait pas été à l'étroit, et on aurait quand même eu une densité d'adresse faible.
C'est de "l'esthétisme technique" pour une forme plus compacte et qui aurait rempli les mêmes fonctions.
Mais bon, ce n'est pas la mode de notre société, qui est "bigger", better", …" ("bigger" et "better", faut voir, ça dépend des cas, ça ne marche pas toujours) dés que ça ne va pas "assez vite".
Bref, je ne trouve pas que ipv6 était la solution la plus "élégante" au problème du manque d'adresse IP.
Les clefs SSH, et bien c'est bien le bordel à gérer quand tu n'as que quelques certificats et le nombre d'intervention dessus se compte maximum sur les doigts d'une main dans l'année (pas d'automatismes acquis, je me doutes qu'il y a des postes ou on bouffe assez régulièrement pour que ça deviennent des automatismes).
Mais bon là aussi, c'est la norme, on fait avec.
Donc pour les administrateurs réseaux en amont de ces "grossistes", ça sera plus simple car effectivement, il délègue l'effort de routage à ces "grossistes".
D'après l'exemple d'orange, Orange va avoir 2109 adresses à sa disposition (277 [~=1,5x1023] fois plus que toutes les adresses théoriques ipv4 !)
même 245 est 8192 fois plus gros que toutes les adresses théoriques ipv4.
ça veut dire que la densité des adresses va être très faible, donc une majorité des adresses ne sera jamais affectés, par contre on va se taper la manipulation des 16 octets (ou 32 caractères ascii en hexa [0-9A-F] + les 7 séparateurs ":")°°°.
On voit bien que dans ipv6,
- le protocole prévoit 2 plages 64 bits, une première plage en 264 bits pour le "routage général" vers des organisations, et 264 bits pour le routage interne de ladites organisation, c'est un routage en 2 temps.
- pouvoir identifier chaque serveur/poste client avec une IP unique (suppression du NAT et faciliter les statistiques/filtrage/sécurité en ayant du point à point "pur" et relié à l'origine du protocole à l'adresse MAC).
Pour le premier point, je n'ai rien contre le fait de sortir d'ipv4, mais 264 adresses (16 caractères ascii en hexa [0-9A-F] + les 3 séparateurs ":" ) auraient permis d'avoir un espace d'adressage très large (selon la philosophie ipv6, 2 plages de 32 bits, ou autre répartition exemple : 40+24) et in fine 2128 adresses, ça reste "overkill" °--°
Pour le second point, pour l'exemple typique d'un site web, qui mettrait un serveur web (apache/java/php/.net/votre techno préférée…) directement exposé sur le web (y compris sa vraie IP), sans passer par des couches réseaux (comme un firewall/reverse-proxy/IDS/..).
Donc en pratique, une organisation qui aurait 264 adresses internes (la partie droite des 128bits) , c'est "overkill" aussi, puisqu'elle va forcément mettre une translation entre les adresses internes et externes.
°°° Parce qu'il faut bien saisir cette pu*@n d'adresse à rallonge un jour ou l'autre dans le SI (au moins dans le DNS et dans la conf réseau du serveur, et si le réseau est un peu plus évolué, les plages d'adresses/ip/hostname dans le firewall, reverse-proxy, …) et il y aura des erreurs de saisies (cf. le point suivant sur les administrateurs "lambda" a qui ça va casser les pieds).
°--° IPV6 a sûrement des avantages pour les "backbones" qui ont a priori de meilleurs administrateurs réseaux que l'entreprise lambda, mais ça va bien emmerder tous les administrateurs réseaux "lambda" au quotidien.
Et justement, à l'époque, je n'avais pas aimé cette idée d'adresse MAC justement pour des questions de "flicage".
Du coup, avec 128bits c'est encore plus superfétatoire.
Par contre, on est paré pour l'internet intergalactique, reste plus qu'a inventer le warp drive(ou autre FTL) et la terraformation, une broutille ^
D'après wikipédia, L'objectif initial de XML est de faciliter l'échange automatisé de contenus complexes (arbres, texte riche…) entre systèmes d'informations hétérogènes (interopérabilité) .
Même pour ça, c'est mauvais, qui n'a pas eu à faire des transformations XSL enchaînées avec les "&" qui se transforment ou pas en "&" aux mauvais endroits me lance la première pierre.
j'ai beaucoup utilisé XML dans sa période "hype" au boulot entre 2000 et 2005, et en vrac les inconvénients majeurs :
1) un fichier xml ne peut pas se traiter en flux à cause de la balise "racine" (il faut construire l'arbre en mémoire, ou comptabiliser les noeuds avec SAX), alors que le CSV (certes format pourri antédiluvien) ou tout autre format "plat", je peux lire 1000 lignes un jour et reprendre à la 1001 le lendemain et la mémoire occupée est seulement la ligne courante.
Maintenant parlons de millions de lignes de données à passer dans un batch…
Ce n'est pas un bon format d'échange de données en masse.
Ces fichiers ne sont pas vraiment "parcourable" avec les outils standards linux (cf remarques dans les posts au dessus), et pour ceux qui feront la remarque "il y a des outils adaptés", oui, chez moi sur mon ordi, j'installe ce que je veux, en entreprise/client, on fait avec ce qu'il y a d'installé quand on n'est pas l'administrateur, et selon les versions OS et les outils installés, et bien vous risquez de n'avoir que du "notepad de base" niveau fonctionalités.
1bis) Quand vous devez mettre en relation plusieurs balises pour interpréter le fichier XML (rassembler des champs différents pour fabriquer une requête SQL par exemple), et bien là, il faut passer par DOM, et le fichier sera intégralement chargé en mémoire avec la création de tous les noeuds du DOM, et c'est très loin d'être gratuit.
Si en plus les fonctionnels ont pris un malin plaisir à éclater les données a l'opposé dans le fichier et que vous avez des données en masse, j'ai du monter une JVM à 16Go pour pouvoir échanger des fichiers de millions d'enregistrement.
2) il y a beaucoup trop de symboles spéciaux ("<,<!,>,&,…" contrairement au "\" des fichiers textes), du coup, comme je le disais plus haut, des transformations XSL sur XML en chaîne ne sont pas stables, et c'est parfait pour arracher les derniers cheveux qui vous restent sur la tête, parce qu'un caractère spécial sera transformé en entité et la série de transformation deviendra un fichier inutile (déjà vu des <root> [= ] )
et les <![CDATA[]]> qui rajoutent un bon paquet de merde.
C'est un format fragile rien que pour ça.
3) validation du schéma, maintenant on a json et yaml qui ont l'équivalent et ce sont des formats plus léger en taille et à la lecture, donc ce n'est plus un argument.
4) et puis surtout, il faut des outils prévus pour, là on a notepad++ chez le client, j'ai pu ajouter le plugin XML, mais sans plugin, c'est indigeste à la lecture et on peut facilement oublier une balise sans un analyseur de syntaxe.
Pour résumer, lourd, fragile, instable et il faut des outils spéciaux qui ne sont pas forcément installés chez le client.
J'en ai bouffé du XML, j'étais un "expert", et bien je ne veux même plus entendre parler de XML sur des nouveaux développement.
Je ne comprend pas bien cette remarque.
32bits seront toujours une table de routage plus petite que 128bits, à moins que je ne comprenne rien à l'arithmétique.
Même en ayant un préfixe de 80bits au niveau d'une organisation, l'organisation se contente des 48bits d'adresse MAC pour la table de routage interne, 48 > 32 a priori.
Si tu as fixé l'IP via MAC et que tu changes de carte réseau en IPv4, tu devras aussi aller rectifier le tir.
Sauf que c'est un choix de l'administrateur pour ipv4 d'associer une IP avec une adresse MAC dans sa gestion/configuration du réseau et des règles de flux.
Dans la norme ipv6, les derniers 48bits sont l'adresse MAC.
Donc 48 bits de "perdus" (c'est déjà un espace 65536 plus grand que l'espace des adresses ipv4).
Pour l'instant, rien de ce que j'ai pu lire donnait un avantage tellement important à ipv6 (en dehors de dépasser 232 adresses) pour accepter qu'il ne soit pas "human friendly".
Et je continue de penser que 264 adresses auraient été largement suffisant (ça fait ~2.63 milliards d'adresse par humain vivant sur terre, je sais bien que l'IoT est à la mode, mais il y avait largement la marge).
Et quand on passe sa journée à jongler entre les machines ça aide.
D'ailleurs, je n'ai pas compris le 128bits par rapport au 64bits.
En 64bits, on aurait eu 4 paquets hexa de 4 caractères, ABCD:EF01:2345:6789, ce qui reste jouable pour la mémoire humaine et on aurait eu ~1019 adresses, ~4 milliards de fois plus que maintenant.
Les adresses en ipv4 seraient restées en 0000:0000:127.0.0.1.
Mais non, il fallait aussi mettre l'adresse MAC de 48 bits (qu'on peut modifier à la volée sur pratiquement tous les OS) et on a eu 16 bits de sous domaine, donc 64bits qui ont une faible valeur ajoutée pour le routage, car la carte réseau réagit sur l'IP, et là son adresse MAC fait partie de l'IP.
Du coup, changement de carte réseau (si on reste dans la norme), soit l'IP du serveur change, soit on force l'adresse MAC de la carte réseau.
Et donc, je ne vois pas la faciliter de maintenance d'un réseau.
Surtout que l'argument utilisé est de pouvoir identifier exactement le device connecté (adresse MAC).
Et là je pose 2 questions:
- qui a déjà vu un SI ou tous les équipements étaient consolidés dans un référentiel unique et "A JOUR" ? (vu que c'est bien pour ça qu'on se paye 64 bits de plus dans la gueule).
- quid du changement de matériel (carte réseau en panne) et du spoofing "MAC" ?
Du coup, pour moi ipv6, c'est 2 blocs de 64bits (table de routage sur 64 bits sur les backbones), le premier pour déterminer l'organisation qui gère les 64bits suivants (16bits + 48 bits d'adresse MAC, table de routage sur 64bits interne)
et du coup, c'est impossible de retenir une adresse ipv6 peuplée (sans pouvoir utiliser les raccourcis ":" ::TOTO:TITI::…)
exemple: A9B7:EF01:85DE:123F:456:0A56:BC07:FE48
64bits : A9B7:EF01:85DE:123F
ipv4: 133.222.18.63 (85DE:123F)
Et tous ceux qui vont dire "et le DNS", avez vous jamais travaillé dans une entreprise ou la moindre demande "d'évolution/changement" est empilée jusqu'à ce que la pile d'incidents "prioritaire" (refaire la conf de la cafetière connecté de la direction ) soit épuisé, et vous vous trouvez pendant quelques jours à +oo à utiliser des IP numériques en attendant.
Et je pense que c'est un facteur carrément non négligeable de la "paresse des administrateurs" (ainsi que plus l'adresse IP est grande, plus grande est l'erreur de saisie).
D'ailleurs, ces "bulles" existent déjà, pour l'instant encore en pleine nature.
Nos élus (députés et sénateurs) mangent bio cuisinés par des grands chefs.
Pour le peuple (cantines), ils hésitent.
Dans certains grand restaurants, ils sont fournis par des paysans bio (qui devraient se faire casser les reins au vue des lois actuelles), mais comme les notables vont dans ces restaurants, ces paysans bénéficient d'une relative protection contre les ennuis administratifs.
Là ou paysan qui aurait la mauvaise idée de vendre sur les marchés ou sur le bord de la route se prendra amende sur amende pour non conformité à la législation.
Pareil en Chine, il y a des régions entières polluées, mais les hauts membres du parti sont fourni par des fermes bien isolées et "bio".
Et c'est pareil et historique pour toutes les élites sur la planète (interdiction de chasser, sauf pour le seigneur dans l'ancien régime).
Après, quand on regarde les oisillons, le plus faible ayant de moins en moins ou pas de nourriture finit par être mécaniquement éliminé.
La pollution sert aussi à l'élimination de la concurrence (des gènes).
Raison supplémentaire qu'in fine, c'est le "thought crime" (toujours 1984) qui est visé pour contrôler ses opposants (qui ne seront jamais aussi nombreux), et non pas la violation du copyright.
Quand je parle de centaines d'années, je parle du temps pour le "haut de la pyramide" soit décatie au point ou ils se croiront tellement invincibles qu'il ne penseront même plus à assurer leur quotidien (Idiocratie pour les "riches").
Pendant la période intérimaire, comme ils ne sont pas encore arrivé à ce point, il y aura des bulles géantes du style https://fr.wikipedia.org/wiki/Biosph%C3%A8re_II pour préserver de la "vraie nature".
Pour le vulgus pecum, ça va être beaucoup plus rapide, le prix des ressources va augmenter exponentiellement, il faudra tout acheter pour vivre (plus de potager personnel, plus d'eau propre, d'air "pur"***,…) un esclavage par les ressources et non pas par les chaînes.
*** en Chine, vu la pollution à la "Balde Runner", toutes les nouvelles constructions n'ont pas le même niveau de filtrage des particules, pour les "HLM", c'est 1 filtre, pour les appartements de luxe, c'est 3 systèmes de filtrage ou plus entre l'air extérieur ou intérieur.
Après, c'est l'idéal pour le commerce, on sera tous dans des bulles artificielles qu'il faudra entretenir à grand frais, et la division sociale se fera sur la qualité de sa bulle.
Quand on voit l'extension du copyright aux US (poussé par Disney entre autre), on se rapproche de la nouvelle "le droit de lire" https://www.gnu.org/philosophy/right-to-read.fr.html, on parle encore de contrôle de l'information, même si c'est de la fiction.
Ils s'en foutent du vol des données (autrement on serait pratiquement tous en prison pour violation de copyright et même les sites "pirates" payent l'hébergement).
Ce qui les intéressent les personnes au pouvoir (politique, économique, intellectuel,..) , c'est de rester au pouvoir, et donc de contrôler l'opinion par l'information (cf. 1984).
C'est plus simple de gagner à un jeux en trichant que par ses qualités propre (et même en étant très bon, la chance joue aussi, et la triche baisse drastiquement ce facteur chance de l'équation).
J'hésite entre me révolter et regarder tout ce beau gros tas de merde s'écrouler dans un bruit de pet gigantesque.
Pas mieux. Tu n'est pas le seul à penser comme ça.
L'inertie de la société est telle et l'accélération donnée par la concentration des pouvoirs (politiques/financiers/…) qui est mécaniquement émergent de la nature humaine à avoir le "meilleur statut social" fait qu'on voit mal l'intérêt à réagir/s'opposer vu qu'on profite nous mêmes du phénomène (confort + se nourrir à la fin de la journée).
La collusion de l'argent et de l'information est seulement une nouvelle forme "d'empire hydraulique" ( https://en.wikipedia.org/wiki/Hydraulic_empire ) et Georges Orwell n'avait pas totalement tord (il pensait Dictature 1.0) quand il a dit "If you want a vision of the future, imagine a boot stamping on a human face - forever."
Avec la "Dictature 2.0 et +" c'est un peu plus subtil (le désir de paraître et le consentement à la consommation), mais si la protection contre les révoltes devient quasi-parfait, on retournera vite dans la Dictature 1.0 avec les "Dieux de l'olympe" et les "inférieurs" écrasé par un "pied mécanique".
Les empires hydrauliques se sont effondrés à chaque fois avec seulement 2 scénarios :
- soit une puissance extérieure supprimait le pouvoir en place en venant envahir le territoire (du coup, à l'échelle de la planète, ça voudrait dire des E.T.)
- soit un effondrement de l'écosystème de l'emplacement géographique de cet empire (changement climatique majeur ou épuisement des ressources et là encore, à l'échelle de la planète, nulle part ou fuir).
Et ça peut durer des centaines d'années avant un effondrement total.
[^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon (site web personnel) . En réponse au sondage L'IPv6 prendra quand.... Évalué à 3. Dernière modification le 29 septembre 2018 à 10:45.
C'est vrai que je partais du principe que si on a une propulsion "FTL", la communication "FTL" existe, ce qui ne sera pas forcément vrai :-|
P.S.. Mais il y a en a qui y pense déjà à une échelle plus modeste du système solaire et des ondes radios.
https://fr.wikipedia.org/wiki/Internet_interplan%C3%A9taire
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 0.
Evidemment que c'est super dangereux et que ce n'est pas un fonctionnement normal, mais ça arrive, et là tu es bien content de pouvoir agir en direct sur le serveur, surtout si le réseau est aussi en vrac au passage pour transférer ladite conf (et quand tu as toute la hiérarchie sur le dos, tu as l'impression de rejouer une mauvaise scène "couper le fil bleu ou rouge").
Ben quand l'équipe admin met en place plusieurs rebonds pour accéder à un serveur, çà peut vite devenir ca°°e-co°°°les.
Après dans l'idée générale de rendre le SI moins friable, plus carré, plus référencé, plus automatisés, avec des composants minimum (surface d'attaque réduite) je suis à 120% d'accord, mais encore faut il être le "maître des clefs".
Quand on débarque sur un SI "étranger" où on n'a jamais participé à sa création/évolution, et bien on s'adaptes à leurs habitudes.
Ou alors tu fais le TJW (Technical Justice Warrior :-) ) et tu te mets les internes à dos.
[^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon (site web personnel) . En réponse au sondage L'IPv6 prendra quand.... Évalué à 0.
Tu fais partie des "chanceux" :-)
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 0.
Par contre le serveur qui contrôle le cluster, m'étonnerait que tu vires le shell et VI dessus.
Les conteneurs c'est un peu un cas à part, c'est plus une "grosse commande/applicatione" qu'on ajoute au serveur hébergeur qu'un "serveur", donc oui, on peut les dépouiller de tout, limite réduit à init+process appli (on peut même aller plus loin et se dire qu'on peut virer le scheduler du kernel, vu qu'il y a une seule application qui tourne et est nécessaire).
Tous les directions informatiques ne sont pas au même niveau de compétence ou même niveau de technologie.
Des concepts qui marche pour l'un, ne marcheront pas pour les autres.
Et qui n'a jamais modifié un fichier de conf de prod en "live" pour débloquer le SI suite à un incident qui bloque tout et qui met en péril l'activité commerciale immédiate (bizarrement de votre chef direct jusqu'au DSI et le DG débarquent dans votre bureau) me jette la première pierre.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 1.
Spring a réussi, parce que c'était moins "lourd" à l'usage.
Entre une annotation devant la méthode qui l'utilise dans son fichier source dans son coin et un fichier externe (qui pouvait être commun entre plusieurs classes, pb de verrous quand il y a plusieurs dev par exemple…) ou je dois faire le mapping dans ma tête entre ce fichier de conf XML et le code source, et bien bizarrement, je préfère faire des annotations.
"grep -R @annotation *", c'est très très difficile comme syntaxe :-)
[^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon (site web personnel) . En réponse au sondage L'IPv6 prendra quand.... Évalué à 0.
Un référentiel ou tu peux avoir a peu près confiance (modulo création/migration/destruction des quelques jours précédents dans une file d'attente de saisie manuelle/automatique) que toutes tes machines "actives" sont listées et que leur fonction est décrite (ça peut être un pauvre "serveur courriel" comme description).
Pas un référentiel a trou, parce qu'il n'est plus utilisé depuis sa mise en place ou sporadiquement avec des mise à jour à trou.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 0.
Quand je disais "notepad de base", c'est une galéjade, c'était pour dire qu'il n'y avais pas le dernier IDE/Text Editor/commande en ligne ou graphique avec tous les plugins "qui vont bien" à la mode ou qu'on maitrise du bout les yeux fermés et qu'il n'y aura pas les facilités qu'on a l'habitude d'utiliser à la maison ou quand on est dans une petite équipe indépendante.
Evidemment, que si on est réellement forcé de travailler avec un text editeur de base comme seul outil et aucune commande en ligne avancée, ça serait l'équivalent de creuser une tranchée à la cuillère, et pas grand monde l'accepterait, moi le premier.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 0.
Je me fous complètement du format des fichiers.
ça fait longtemps que je ne luttes plus sur ces questions quand j'arrive sur un projet déjà commencé ou les choix ont déjà été fait.
L'année dernière, j'ai travaillé sur un composant qui s'appuyait sur une API qui était binorme, SOAP et REST selons les appels.
ça fait longtemps maintenant, mais j'ai aussi travaillé sur une API XML pré-SOAP
Je n'ai rien contre le XML en soi, je dis que ça rajoute de la lourdeur au traitement/
Que ça soit pour les machines, le parsing n'est pas gratuit, le DOM en mémoire n'est pas gratuit, ou pour les humains, c'est plus "indigeste" de travailler avec.
Et qu'il y a une divergence entre ce que le XML devait apporter et l'utilisation concrète sur le terrain, ça devait nous faciliter la vie, je ne touve pas vraiment.
Je suis plus Java, c'est quand même bizarre que Spring ait eu autant de succès, alors qu'il ne fait pas plus que les anciens framework web+JEE+EJB avec leurs milliards de fichiers de conf XML.
Si les technos sont des plats, je n'aime pas le plat XML, et pourtant j'en mange quand il n'y a que ça, ce n'est pas pour autant que je dois dire que c'est "délicieux".
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 0.
Sur les postes de travail, en général, tu peux installer un peu ce que tu veux (et pas toujours, je suis déjà tombé chez des clients qui ont une image standard du poste de W et tu n'es pas admin sur le poste de W pour installer de nouveaux outils, il faut trouver des versions "sans install").
Mais sur les serveurs, soit par "principe" de ne pas augmenter le nombre de technos/d'outils installés (moins d'éléments, moins de problèmes) ou parce que l'équipe administration ne veut pas s'écarter de la configuration standard de leur OS.
Surtout si les outils en questions ne font pas parti directement des dépôts éditeurs (dépôts tiers ou pire compilation des sources) et ne sont pas impliqués directement dans la "production" du SI (que l'outil de visualisation/édition soit là ou pas, ça ne changera rien au résultat produits par le SI).
Du coup, en général, si on peut faire du sftp/ftp sur les serveurs, ça crée une étape intermédiaire ou on rappatrie les fichiers sur le poste de W, c'est juste plus lourd.
Et oui, après plusieurs mois de bataille "politique" pour montrer le bien fondé de l'installation (inertie, résistance au changement, NIH,…), tu peux peut etre avoir les outils, mais le projet est déjà terminé.
[^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon (site web personnel) . En réponse au sondage L'IPv6 prendra quand.... Évalué à 1.
De toute manière, c'est l'ipv6 la nouvelle norme, on va faire avec, hein, pas le choix de toute maniére :-)
C'est le côté "TINA" de la justification des 128bits qui me fait soulever un sourcil.
C'est un peu de l'uchronie, "et si on avait choisit du 64bits à l'époque (ce qui est déja 4 milliard de sous réseaux "ipv4")", et bien je pense qu'on aurait pas été à l'étroit, et on aurait quand même eu une densité d'adresse faible.
C'est de "l'esthétisme technique" pour une forme plus compacte et qui aurait rempli les mêmes fonctions.
Mais bon, ce n'est pas la mode de notre société, qui est "bigger", better", …" ("bigger" et "better", faut voir, ça dépend des cas, ça ne marche pas toujours) dés que ça ne va pas "assez vite".
Bref, je ne trouve pas que ipv6 était la solution la plus "élégante" au problème du manque d'adresse IP.
Les clefs SSH, et bien c'est bien le bordel à gérer quand tu n'as que quelques certificats et le nombre d'intervention dessus se compte maximum sur les doigts d'une main dans l'année (pas d'automatismes acquis, je me doutes qu'il y a des postes ou on bouffe assez régulièrement pour que ça deviennent des automatismes).
Mais bon là aussi, c'est la norme, on fait avec.
[^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon (site web personnel) . En réponse au sondage L'IPv6 prendra quand.... Évalué à -1.
Donc pour les administrateurs réseaux en amont de ces "grossistes", ça sera plus simple car effectivement, il délègue l'effort de routage à ces "grossistes".
D'après l'exemple d'orange, Orange va avoir 2109 adresses à sa disposition (277 [~=1,5x1023] fois plus que toutes les adresses théoriques ipv4 !)
même 245 est 8192 fois plus gros que toutes les adresses théoriques ipv4.
ça veut dire que la densité des adresses va être très faible, donc une majorité des adresses ne sera jamais affectés, par contre on va se taper la manipulation des 16 octets (ou 32 caractères ascii en hexa [0-9A-F] + les 7 séparateurs ":")°°°.
En s'étalant comme ça, on va avoir les mêmes problèmes que pour ipv4 ou des larges plages d'adresses ont été réservés au début, et maintenant, on bouche les trous https://xkcd.com/195/ (2006) et plus récent https://bl.ocks.org/vasturiano/8aceecba58f115c81853879a691fd94f
On voit bien que dans ipv6,
- le protocole prévoit 2 plages 64 bits, une première plage en 264 bits pour le "routage général" vers des organisations, et 264 bits pour le routage interne de ladites organisation, c'est un routage en 2 temps.
- pouvoir identifier chaque serveur/poste client avec une IP unique (suppression du NAT et faciliter les statistiques/filtrage/sécurité en ayant du point à point "pur" et relié à l'origine du protocole à l'adresse MAC).
Pour le premier point, je n'ai rien contre le fait de sortir d'ipv4, mais 264 adresses (16 caractères ascii en hexa [0-9A-F] + les 3 séparateurs ":" ) auraient permis d'avoir un espace d'adressage très large (selon la philosophie ipv6, 2 plages de 32 bits, ou autre répartition exemple : 40+24) et in fine 2128 adresses, ça reste "overkill" °--°
Pour le second point, pour l'exemple typique d'un site web, qui mettrait un serveur web (apache/java/php/.net/votre techno préférée…) directement exposé sur le web (y compris sa vraie IP), sans passer par des couches réseaux (comme un firewall/reverse-proxy/IDS/..).
Donc en pratique, une organisation qui aurait 264 adresses internes (la partie droite des 128bits) , c'est "overkill" aussi, puisqu'elle va forcément mettre une translation entre les adresses internes et externes.
°°° Parce qu'il faut bien saisir cette pu*@n d'adresse à rallonge un jour ou l'autre dans le SI (au moins dans le DNS et dans la conf réseau du serveur, et si le réseau est un peu plus évolué, les plages d'adresses/ip/hostname dans le firewall, reverse-proxy, …) et il y aura des erreurs de saisies (cf. le point suivant sur les administrateurs "lambda" a qui ça va casser les pieds).
°--° IPV6 a sûrement des avantages pour les "backbones" qui ont a priori de meilleurs administrateurs réseaux que l'entreprise lambda, mais ça va bien emmerder tous les administrateurs réseaux "lambda" au quotidien.
[^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon (site web personnel) . En réponse au sondage L'IPv6 prendra quand.... Évalué à 2.
Et justement, à l'époque, je n'avais pas aimé cette idée d'adresse MAC justement pour des questions de "flicage".
Du coup, avec 128bits c'est encore plus superfétatoire.
Par contre, on est paré pour l'internet intergalactique, reste plus qu'a inventer le warp drive(ou autre FTL) et la terraformation, une broutille ^
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par darkleon (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 7.
Même pour ça, c'est mauvais, qui n'a pas eu à faire des transformations XSL enchaînées avec les "&" qui se transforment ou pas en "&" aux mauvais endroits me lance la première pierre.
j'ai beaucoup utilisé XML dans sa période "hype" au boulot entre 2000 et 2005, et en vrac les inconvénients majeurs :
1) un fichier xml ne peut pas se traiter en flux à cause de la balise "racine" (il faut construire l'arbre en mémoire, ou comptabiliser les noeuds avec SAX), alors que le CSV (certes format pourri antédiluvien) ou tout autre format "plat", je peux lire 1000 lignes un jour et reprendre à la 1001 le lendemain et la mémoire occupée est seulement la ligne courante.
Maintenant parlons de millions de lignes de données à passer dans un batch…
Ce n'est pas un bon format d'échange de données en masse.
Ces fichiers ne sont pas vraiment "parcourable" avec les outils standards linux (cf remarques dans les posts au dessus), et pour ceux qui feront la remarque "il y a des outils adaptés", oui, chez moi sur mon ordi, j'installe ce que je veux, en entreprise/client, on fait avec ce qu'il y a d'installé quand on n'est pas l'administrateur, et selon les versions OS et les outils installés, et bien vous risquez de n'avoir que du "notepad de base" niveau fonctionalités.
1bis) Quand vous devez mettre en relation plusieurs balises pour interpréter le fichier XML (rassembler des champs différents pour fabriquer une requête SQL par exemple), et bien là, il faut passer par DOM, et le fichier sera intégralement chargé en mémoire avec la création de tous les noeuds du DOM, et c'est très loin d'être gratuit.
Si en plus les fonctionnels ont pris un malin plaisir à éclater les données a l'opposé dans le fichier et que vous avez des données en masse, j'ai du monter une JVM à 16Go pour pouvoir échanger des fichiers de millions d'enregistrement.
2) il y a beaucoup trop de symboles spéciaux ("<,<!,>,&,…" contrairement au "\" des fichiers textes), du coup, comme je le disais plus haut, des transformations XSL sur XML en chaîne ne sont pas stables, et c'est parfait pour arracher les derniers cheveux qui vous restent sur la tête, parce qu'un caractère spécial sera transformé en entité et la série de transformation deviendra un fichier inutile (déjà vu des <root> [= ] )
et les <![CDATA[]]> qui rajoutent un bon paquet de merde.
C'est un format fragile rien que pour ça.
3) validation du schéma, maintenant on a json et yaml qui ont l'équivalent et ce sont des formats plus léger en taille et à la lecture, donc ce n'est plus un argument.
4) et puis surtout, il faut des outils prévus pour, là on a notepad++ chez le client, j'ai pu ajouter le plugin XML, mais sans plugin, c'est indigeste à la lecture et on peut facilement oublier une balise sans un analyseur de syntaxe.
Pour résumer, lourd, fragile, instable et il faut des outils spéciaux qui ne sont pas forcément installés chez le client.
J'en ai bouffé du XML, j'étais un "expert", et bien je ne veux même plus entendre parler de XML sur des nouveaux développement.
[^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon (site web personnel) . En réponse au sondage L'IPv6 prendra quand.... Évalué à -2.
Je ne comprend pas bien cette remarque.
32bits seront toujours une table de routage plus petite que 128bits, à moins que je ne comprenne rien à l'arithmétique.
Même en ayant un préfixe de 80bits au niveau d'une organisation, l'organisation se contente des 48bits d'adresse MAC pour la table de routage interne, 48 > 32 a priori.
[^] # Re: C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon (site web personnel) . En réponse au sondage L'IPv6 prendra quand.... Évalué à 1.
Si tu as fixé l'IP via MAC et que tu changes de carte réseau en IPv4, tu devras aussi aller rectifier le tir.
Sauf que c'est un choix de l'administrateur pour ipv4 d'associer une IP avec une adresse MAC dans sa gestion/configuration du réseau et des règles de flux.
Dans la norme ipv6, les derniers 48bits sont l'adresse MAC.
Donc 48 bits de "perdus" (c'est déjà un espace 65536 plus grand que l'espace des adresses ipv4).
Pour l'instant, rien de ce que j'ai pu lire donnait un avantage tellement important à ipv6 (en dehors de dépasser 232 adresses) pour accepter qu'il ne soit pas "human friendly".
Et je continue de penser que 264 adresses auraient été largement suffisant (ça fait ~2.63 milliards d'adresse par humain vivant sur terre, je sais bien que l'IoT est à la mode, mais il y avait largement la marge).
# C'est plus facile de retenir une ipv4 de tête qu'une ipv6...
Posté par darkleon (site web personnel) . En réponse au sondage L'IPv6 prendra quand.... Évalué à 0.
Et quand on passe sa journée à jongler entre les machines ça aide.
D'ailleurs, je n'ai pas compris le 128bits par rapport au 64bits.
En 64bits, on aurait eu 4 paquets hexa de 4 caractères, ABCD:EF01:2345:6789, ce qui reste jouable pour la mémoire humaine et on aurait eu ~1019 adresses, ~4 milliards de fois plus que maintenant.
Les adresses en ipv4 seraient restées en 0000:0000:127.0.0.1.
Mais non, il fallait aussi mettre l'adresse MAC de 48 bits (qu'on peut modifier à la volée sur pratiquement tous les OS) et on a eu 16 bits de sous domaine, donc 64bits qui ont une faible valeur ajoutée pour le routage, car la carte réseau réagit sur l'IP, et là son adresse MAC fait partie de l'IP.
Du coup, changement de carte réseau (si on reste dans la norme), soit l'IP du serveur change, soit on force l'adresse MAC de la carte réseau.
Et donc, je ne vois pas la faciliter de maintenance d'un réseau.
Surtout que l'argument utilisé est de pouvoir identifier exactement le device connecté (adresse MAC).
Et là je pose 2 questions:
- qui a déjà vu un SI ou tous les équipements étaient consolidés dans un référentiel unique et "A JOUR" ? (vu que c'est bien pour ça qu'on se paye 64 bits de plus dans la gueule).
- quid du changement de matériel (carte réseau en panne) et du spoofing "MAC" ?
Du coup, pour moi ipv6, c'est 2 blocs de 64bits (table de routage sur 64 bits sur les backbones), le premier pour déterminer l'organisation qui gère les 64bits suivants (16bits + 48 bits d'adresse MAC, table de routage sur 64bits interne)
et du coup, c'est impossible de retenir une adresse ipv6 peuplée (sans pouvoir utiliser les raccourcis ":" ::TOTO:TITI::…)
exemple: A9B7:EF01:85DE:123F:456:0A56:BC07:FE48
64bits : A9B7:EF01:85DE:123F
ipv4: 133.222.18.63 (85DE:123F)
Et tous ceux qui vont dire "et le DNS", avez vous jamais travaillé dans une entreprise ou la moindre demande "d'évolution/changement" est empilée jusqu'à ce que la pile d'incidents "prioritaire" (refaire la conf de la cafetière connecté de la direction ) soit épuisé, et vous vous trouvez pendant quelques jours à +oo à utiliser des IP numériques en attendant.
Et je pense que c'est un facteur carrément non négligeable de la "paresse des administrateurs" (ainsi que plus l'adresse IP est grande, plus grande est l'erreur de saisie).
[^] # Re: Mais quand est-ce que ça va s'arrêter!
Posté par darkleon (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 3.
Dés la déclaration de 1795, cet article a été supprimé.
https://fr.wikipedia.org/wiki/D%C3%A9claration_des_droits_et_des_devoirs_de_l%27homme_et_du_citoyen_de_1795
Et la déclaration universelle des droits de l'homme n'en parle pas non plus.
Et quand on va sur le site gouvernemental https://www.legifrance.gouv.fr/Droit-francais/Constitution seul 1789 et 1954 sont cités.
Pas folles les guêpes, "une fois arrivées au pouvoir", elles ont enlevé l'article qui pouvait les en déposséder.
[^] # Re: Mais quand est-ce que ça va s'arrêter!
Posté par darkleon (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 4.
Pas forcément, un "réorientation" professionnelle vers du "consulting de luxe" (pseudo emploi super bien payé) peut être aussi une option.
C'est le pouvoir/influence qu'ils cherchent, et être élu n'est pas la seule voie.
[^] # Re: Mais quand est-ce que ça va s'arrêter!
Posté par darkleon (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 3.
Les politiques suivent le sens du vent qui les arrangent, pas la population.
[^] # Re: Mais quand est-ce que ça va s'arrêter!
Posté par darkleon (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 1.
D'ailleurs, ces "bulles" existent déjà, pour l'instant encore en pleine nature.
Nos élus (députés et sénateurs) mangent bio cuisinés par des grands chefs.
Pour le peuple (cantines), ils hésitent.
Dans certains grand restaurants, ils sont fournis par des paysans bio (qui devraient se faire casser les reins au vue des lois actuelles), mais comme les notables vont dans ces restaurants, ces paysans bénéficient d'une relative protection contre les ennuis administratifs.
Là ou paysan qui aurait la mauvaise idée de vendre sur les marchés ou sur le bord de la route se prendra amende sur amende pour non conformité à la législation.
Pareil en Chine, il y a des régions entières polluées, mais les hauts membres du parti sont fourni par des fermes bien isolées et "bio".
Et c'est pareil et historique pour toutes les élites sur la planète (interdiction de chasser, sauf pour le seigneur dans l'ancien régime).
Après, quand on regarde les oisillons, le plus faible ayant de moins en moins ou pas de nourriture finit par être mécaniquement éliminé.
La pollution sert aussi à l'élimination de la concurrence (des gènes).
[^] # Re: Pendant ce temps là...
Posté par darkleon (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 1.
Raison supplémentaire qu'in fine, c'est le "thought crime" (toujours 1984) qui est visé pour contrôler ses opposants (qui ne seront jamais aussi nombreux), et non pas la violation du copyright.
[^] # Re: Mais quand est-ce que ça va s'arrêter!
Posté par darkleon (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 2.
Quand je parle de centaines d'années, je parle du temps pour le "haut de la pyramide" soit décatie au point ou ils se croiront tellement invincibles qu'il ne penseront même plus à assurer leur quotidien (Idiocratie pour les "riches").
Pendant la période intérimaire, comme ils ne sont pas encore arrivé à ce point, il y aura des bulles géantes du style https://fr.wikipedia.org/wiki/Biosph%C3%A8re_II pour préserver de la "vraie nature".
Pour le vulgus pecum, ça va être beaucoup plus rapide, le prix des ressources va augmenter exponentiellement, il faudra tout acheter pour vivre (plus de potager personnel, plus d'eau propre, d'air "pur"***,…) un esclavage par les ressources et non pas par les chaînes.
*** en Chine, vu la pollution à la "Balde Runner", toutes les nouvelles constructions n'ont pas le même niveau de filtrage des particules, pour les "HLM", c'est 1 filtre, pour les appartements de luxe, c'est 3 systèmes de filtrage ou plus entre l'air extérieur ou intérieur.
Après, c'est l'idéal pour le commerce, on sera tous dans des bulles artificielles qu'il faudra entretenir à grand frais, et la division sociale se fera sur la qualité de sa bulle.
[^] # Re: Pendant ce temps là...
Posté par darkleon (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 6.
Quand on voit l'extension du copyright aux US (poussé par Disney entre autre), on se rapproche de la nouvelle "le droit de lire" https://www.gnu.org/philosophy/right-to-read.fr.html, on parle encore de contrôle de l'information, même si c'est de la fiction.
[^] # Re: Pendant ce temps là...
Posté par darkleon (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 6.
Ils s'en foutent du vol des données (autrement on serait pratiquement tous en prison pour violation de copyright et même les sites "pirates" payent l'hébergement).
Ce qui les intéressent les personnes au pouvoir (politique, économique, intellectuel,..) , c'est de rester au pouvoir, et donc de contrôler l'opinion par l'information (cf. 1984).
C'est plus simple de gagner à un jeux en trichant que par ses qualités propre (et même en étant très bon, la chance joue aussi, et la triche baisse drastiquement ce facteur chance de l'équation).
[^] # Re: Mais quand est-ce que ça va s'arrêter!
Posté par darkleon (site web personnel) . En réponse à la dépêche L’Internet libre et ouvert est en danger : vous pouvez arrêter ce désastre. Évalué à 5.
J'hésite entre me révolter et regarder tout ce beau gros tas de merde s'écrouler dans un bruit de pet gigantesque.
Pas mieux. Tu n'est pas le seul à penser comme ça.
L'inertie de la société est telle et l'accélération donnée par la concentration des pouvoirs (politiques/financiers/…) qui est mécaniquement émergent de la nature humaine à avoir le "meilleur statut social" fait qu'on voit mal l'intérêt à réagir/s'opposer vu qu'on profite nous mêmes du phénomène (confort + se nourrir à la fin de la journée).
La collusion de l'argent et de l'information est seulement une nouvelle forme "d'empire hydraulique" ( https://en.wikipedia.org/wiki/Hydraulic_empire ) et Georges Orwell n'avait pas totalement tord (il pensait Dictature 1.0) quand il a dit "If you want a vision of the future, imagine a boot stamping on a human face - forever."
Avec la "Dictature 2.0 et +" c'est un peu plus subtil (le désir de paraître et le consentement à la consommation), mais si la protection contre les révoltes devient quasi-parfait, on retournera vite dans la Dictature 1.0 avec les "Dieux de l'olympe" et les "inférieurs" écrasé par un "pied mécanique".
Les empires hydrauliques se sont effondrés à chaque fois avec seulement 2 scénarios :
- soit une puissance extérieure supprimait le pouvoir en place en venant envahir le territoire (du coup, à l'échelle de la planète, ça voudrait dire des E.T.)
- soit un effondrement de l'écosystème de l'emplacement géographique de cet empire (changement climatique majeur ou épuisement des ressources et là encore, à l'échelle de la planète, nulle part ou fuir).
Et ça peut durer des centaines d'années avant un effondrement total.