Mapping des zones sujettes à changement

[Vaasref]

Ce serait pas mal dans les includes ou dans un nouveau type de fichier, que l'on marque les plages des fichiers qui sont includes qui doivent rester les même.

La problématique c'est que si l'on veux vérifier l'intégrité du système si on checksum le tout bah ça va pas marcher puisque des variables auront changer.

Pourquoi vérifier l'intégrité ?

PARCE QUE L'ON EST DANS L'ESPACE ET QU'IL Y A DES CONNARDS DE RAYONS COSMIQUES. C'est donc une nécessite absolue.

On peut aussi trouver un moyen comme mettre la plage du fichier inclu statique et son checksum cmme ça ça permet de faire un checksum que de cette plague et on a pas besoin de traiter tout l'os avec un checksum qui prend en compte les trous.

[Yamakaky]

Là oui, y a un intérêt, même si on ne fait que détecter l'erreur, et que les données peuvent être modifiées impunément. En fait, l'idéal serait que DevCPU puisse regrouper les dat à un endroit, par exemple en utilisant une regex pour les labels.

[L3nn0x]

Hum, il faut alors avoir calculé le checksum avant, et prier qu'il soit pas modifié par un rayon cosmique. Mais c'est une bonne idée pour vérifier qu'il n'y a pas eu de dégâts. Faudra déterminer quand le faire, à quelle fréquence, ce qu'on vérifie etc.

[Vaasref]

On parle de probabilité, ya plus de risque que le reste soit touché que la fonction de verif', au pire on verif' la vérif' avec une verif' plus simple dédié à la vérification de vérif' exaustive. et plus petit sera cette seconde plus elle sera protégée. Si la seconde foire alors on peut toujours tenter une verif exaustive en unsafe.

Cela irait en addition avec une fonction de rescueOS rapide qui à l'activation viderait la SP, se stockerait dedans puis s'utilisant a partir de celle-ci, il ne ferait que copier l'intégralité de la disquette sur le DCPU et puisque la SP est à la fin il finirait par s'écraser. l'idée est de mettre sa boucle de copie a la fin du rescue et qu'il boucle tant qu'il n'est pas écrasé jusqu'a un point, si il l'est alors il init la sp à 0xFFFF et tout le reste puis lance l'OS nouvellement installé.

[Yamakaky]

Je pensait à autre chose : regrouper tous les trucs statiques au début et les dat à la fin. Du coup, la cksum prendrait en compte la fonction de vérif.

[Vaasref]

@Yamakaky : Bah je vois pas vraiment la différence avec ton premier comment. de toute façon la redondance est plus sure, donc si c'est pour dire qu'il n'y a pas besoin de vérifier la fonction de vérification indépendamment, moui, mais surtout il faut la mettre en double, car il est très improbable que les rayon atteigne les deux et encore plus qu'une fonction déconne et que l'autre ai l'air de marcher alors que non.

J'avais mal lu Faerie j'aurais pas fait la première partie de mon message sinon.

Si un condensat de checksum est en lui même endommagé alors c'est que le reste peu l'être et donc paf rescueOS

[L3nn0x]

Je propose d'intégrer la vérification de l'intégrité manuellement d'abord. Pas d'automatisation tant qu'on a pas de hardware vérifiant le niveau de radioactivité.

[Vaasref]

Ya pas que la radioactivité, les rayons cosmique ça en est pas tellement.

[L3nn0x]

Oui, mais j'appelle ça de la radioactivité parce qu'un rayon cosmique en est après tout.