Vous connaissez la raison majeure qui fait planter vos ordinateurs ?
La corruption. L'informatique, étrangement nous apprend beaucoup sur la corruption dans le monde réel et surtout sur les techniques mise en œuvre pour la camoufler.
On dit que la plupart de nos programmes sont fait dans un langage -le C- qui n'est pas intègre (relativement à la mémoire). Qu'il peut arriver que quand on essaie d'accéder à l'information à sa source, et bien on a pas le bon résultat...
Pourtant, c'est simple de faire du code qui n'a pas de problème de corruption mémoire : il suffit de n'utiliser que de l'allocation statique pré-allouée (kof kof, trop gros passera pas) :
int data[MAX_DATA_SIZE];
Et pour chaque opération de type
data[ (var: int) ] ou ((int )* data + (var : int ) ou tout homéomorphe
Vérifier systématiquement les bornes.
N'importe quel analyseur syntaxique peut faire ça les doigts dans le nez.
Comment, ces crétins d'informaticiens y ont pas pensé ? C'est comme ça qu'on est élevé en labo de physique expérimentale. Et les informaticiens nous regardent et disent : ah les scientifiques ces idéalistes qui vient dans un monde où le coût n'existe pas.
Sur le papier, j'ai raison, en embarqué critique l'allocation statique l'emporte comme bonne pratique.
MAIS, le prix à payer est que cette façon consomme plus d'une ressource : l'usage exclusif de la mémoire. De plus cet exemple déclenche une allocation mémoire.
La mémoire est à l'informatique ce que les ressources à la terre : finie.
C'est ainsi que l'informaticien invoqua la 8é plaie d’Égypte : malloc.
Le problème de la juste allocation de la mémoire n'est pas résolu : il est contourné.
Au lieu d'être de bon gros carré bien sûr un peu lourdaud qui squattent la mémoire comme mémé un banc publique les programmes sont priés de gonfler et se dégonfler comme une grenouille qui croasse. En plus si mémé est prédictible, on peut la voler donc, on la fait se déplacer de bancs en bancs aléatoirement (ASLR/propolice) merci openBSD pour vos idées à la con.
Vos scéances à déboguer les OOM killer (Out of memory killer) commencent par écouter la cacaphonie des croâssements qui se répondent en écho à travers les tuyaux des traitements parfois localement, parfois sur une foultitude d'ordis en même temps des allocations mémoires qui explosent. Ce foutu cloud.
On doit passer à travers l'équivalent de multiples couches de transactions opaques :
- déréférencement par la CPU des adresses mémoires
- gestion de la pile d'appel
- unboxing des variables dans les langages dynamiques
- gestionnaire de pool ou allocateur de slab pour les données noyaux
- mémoire virtuelle (mmap)
- base distribuée avec consensus,
- CopyOnWrite (mémoire présentée en lecture qui change de localisation à la première écriture créant un risque temporel de discrétance si mal isolée)
- caches ...
Derrière un POKE* se cache un pic.
* blague BASIC un peu grasse
Derrière chaque progrès une nouvelle indirection, déréférentiation, une nouvelle couche d'opacité.
L'informatique nous apprends un max sur la corruption.
Revenons à la corruption : pourquoi des gens en pouvoirs qui peuvent censurer l'information, voter la non transparence des revenus, la confidentialité des transactions se font-ils chier à rajouter un niveau en plus de complexité qui semble inutile ?
Parce que même les truands doivent pouvoir suivre leur comptabilité et qu'ils ne peuvent pas le faire dans des circuits (zone mémoire) qui sont utilisées par les autres programmes.
Je viens d'appeler l'OS et la MMU des truands, et c'est ce qu'ils sont : des menteux.
Ils font de la double compta prétendent vous renvoyer une adresse mémoire à pétaouchnock et vont la chercher dans un cache. Ils vous cachent une partie de la mémoire qu'ils se réservent. Prétendent que la valeur est inchangée depuis sa création sans vérifier qu'elle n'a pas mutée par accident (rowhammer : achetez des mémoires avec ECC pour les serveurs SVP) que le temps n'importe pas (race-condition)
L'OS et le bios sont comme le monde financier et banquier qui deale les ressources de manière opaque. Ils sont la racine du mal.
Epicure disait :
La nécessité est un mal nécessaire, mais il n'est pas nécessaire de vivre sous l'empire du mal
Cet écosystème branlant vient à la base d'un mode de pensée en informatique sur la programmation dite dynamique, où des algorithmes bienveillants font la magie de nous décharger des risques de conflits sociaux. Comme les banques privées et centrales et notre argent.
Parce que mes bons amis : nos CPU, nos logiciels, nos OS sont structurés autour des a priori de notre société.
On arrive pas à se mettre autour d'une table pour discuter entre adulte de comment partager une ressource/la mémoire ?
Pas grave : on met un arbitre au milieu dont le consensus est de dire que ses décisions magiques sont bénéfiques à l'intérêt général : un oracle illuminé de la foi des informaticiens/marchés sur sa justice qui entraîne une cascade de bruit dans la mécanique informatique, des tressauts de tuyauterie résultant dans des erreurs 500 que personne comprend. Alleluiah ! Mettons les allocations mémoires dans une blockchain pour éviter les problèmes et sacrifions 3 poulets.
Donc, parce que l'on a déterminé que nos entités financières pouvaient croâsser comme une allocation mémoire (bras de leviers & co) on a créé des effets de ballons pour pouvoir en détourner une partie.
Quand la grenouille se gonfle elle peut générer du revenu avec des taux inférieurs à l'inflation, on emprunte à la ressource globale
Stratégie de fourbe utilisée par les gestionnaires de pool : au lieu de demander 1 tu demandes N, et quand tu as trop de pression sur ton point de prêt de connexions tu étends la taille de ton pool par 2.
Cet avantage de bâtard des gestionnaires de pool n'existe à la base que parce que l'on fait de l'allocation dynamique. C'est ce qu'on appelle une cavalerie financière. Augmenter tes intérêts en ballonant avec un emprunt qui s'appuie sur un emprunt ...
Le malloc/mmap créé un coût à la transaction pour créer une zone mémoire, la rendre atomique, garantir son intégrité, les translations transparentes d'espaces, gérer les droits et priorités d'accès ...
L'argent est comme la mémoire informatique : il est nécessaire de la gérer parce que des codeurs l'utilise comme des PORCS (et je ne regarde pas que les développeurs java, python ou PHP) donc l'OS va segfaulter de manière opaque pour vous éviter l'inconvénient de devoir vous intéresser à cette partie chiante de l'informatique/vie économique. C'est le prix à payer mon bon monsieur, on segfault, et hop on relance un nœud kubernetes pour corriger.
Derrière votre compte en banque avec votre argent se cache la mécanique même de la corruption.
Si tout le monde se servait en même temps on verrait des conflits. Pour rendre ces conflits acceptables on a créé une abstraction pour les masquer qui se cachent derrière des réflexions de gourous mal digérés (Platon, oracle...) transformés en golem numériques qui arbitrent pour vous de manière opaque sans votre consentement. Tentez de retirez vos économies tous en même temps et vous entendrez le système financier segfaulter.
Et si Diogènes de Sinope avait raison ?Et si un monde sans malloc ni argent était meilleur ?
