2PetitsVerres a écrit 3132 commentaires

A priori toutes les mémoires étaient des puces dédiées. Le processeur, c'était un ERC32, SPARC v7 pour le jeu d'instruction. C'était avant les LEON, pour répondre à aiolos dans l'autre commentaire. Et c'était Atmel qui le fabriquait, mais je ne sais pas où il était fabriqué.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Windows 95 a été lancé avant Windows 7…

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

En vrai je n'ai jamais eu de problème d'alignement "dans mon code", c'était vraiment une combinaison de facteur, et une "fonction" (?) écrite en assembleur qui appelait une instruction "incorrecte" par rapport aux arguments passés.

Dans le code écrit avec un language "normal", le compilateur devrait gérer ça pour moi (après, techniquement, il faut faire attention à la perfo, lire des choses non alignée peut être plus lent, sur certains architecture. Ca devient un compromis taille/vitesse)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Mais je doute qu'il ai un système de fichier, une gestion fine et configurable du multi-coeur, un shell complexe, une gestion de chargement de nouveaux programme

Exact. On n'a pas de système de fichier, et ce calculateur là n'est pas multi coeur, et c'est un monolithe (on n'a pas d'exécutable qu'on peut lancer)

La définition d'OS, c'est plutôt "vague", mais ici l'OS était responsable de

1. le scheduling des tâches. Y compris le passage de l'une à l'autre, … (c'est du multitâche, mais la fréquence et priorité des tâches était fixe)
2. la vérification du temps réel (watchdog, les taches sont bien démarrées et terminées à temps)
3. tout ce qui est initialisation des périphériques
4. je rentre aussi dans "OS" tout ce qui est gestion des traps et leur codes

Mais je ne peux pas uploader simplement un nouveau exécutable et lui dire "rajoute une tâche et lance cet exe".

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Sommaire

• Intro : La mémoire
• Possibilité 1: Le paramétrage.
• Possibilité 2: les free functions
• Possibilité 3 : Changer une fonction existante
• Interlude : Les tables de patch
• Possibilité 4 : Changer tout le logiciel

Encore un fois, c'est trop long ;-) (et je n'ai pas relu…)

Il y a plusieurs aspects, au moins l'aspect technique ("comment on peut changer une fonctionnalité du satellite") et l'aspect "stratégique" ("est-ce qu'on veut changer une fonctionnalité du satellite ou la corriger")

Sur l'aspect stratégique, généralement l'idée c'est qu'on veut avoir la possibilité technique de changer quelque chose, mais qu'on espère ne jamais l'utiliser. Et si on peut, donc, on ne patche pas (du coup, ça veut dire qu'avant le lancement, on essaye de valider en profondeur tous les aspects, via de la simulation principalement)

Mais j'imagine que l'aspect technique est plus intéressant. Du coup, on avait plusieurs possibilités techniques qu'ils fallait valider au plus haut niveau, parce que même si on espérait ne jamais les utiliser (à cause de la stratégie), le logiciel est la seule chose qu'on peut changer une fois en vol.

Intro : La mémoire

Bon, en fait, les mémoires. Que ça soit le code ou les données, elles doivent forcément être en mémoire quelque part. Ou plusieurs endroits. Du coup, résumé (approximatif, c'était il y a longtemps) de ce qu'on avait :

• des ROM. Read only memory (en théorie, mais souvent des EEPROM, donc qu'on peut mettre en mode "écriture autorisée). Normalement même si on coupe l'alimentation en électricité, elles gardent leurs valeurs.
• des RAM. Pas read only. Potentiellement si on coupe le courant, elles perdent leur données (*)

Par contre, on n'avais pas une ROM et une RAM, mais plusieurs de chaque.

Chaque calculateur avait sa ROM (avec le binaire) et sa RAM (le binaire est copié au boot dedans, et les données calculées sont là). Ces deux là n'étaient accessible que par le calculateur en question (donc ROM1 <-> CPU1 <-> RAM1, et pareil pour le 2, pas d'accès croisés). La théorie c'est que les deux calculateurs ont le même binaire, mais rien n'oblige à le faire, on aurait pu avoir deux binaires complètement différent, par contre, on avait de la redondance froide, donc un seul calculateur allumé.

On avait aussi deux RAM appelées SGRAM (1 et 2) pour safe guard memory. Par défaut, pas grand chose dedans, sauf les données qui avaient besoin de survivre à un reboot. Là par contre les deux calculateurs pouvaient accéder aux deux SGRAM. Les données survivaient à un reboot (je ne sais plus si c'est parce qu'elles étaient tout le temps alimentées, ou si elles survivaient à un cycle off/on) C'est vraiment une ram par contre, certaines variables étaient directement dans cette RAM.

Et aussi une (ou deux?) SG ROM. Pareil, les deux calculateurs y ont accès. De mémoire, on avait rien dedans, sauf des tables de patch, à appliquer (ou non) au boot. Par défaut, on fait un logiciel parfait ( ;-) ) donc il n'y a pas de patch à appliquer, donc c'est vide.

Voila, en résumé : des mémoires "volatiles" et des mémoires permanentes, des mémoires spécifiques à un calculateur et des mémoires accessibles aux deux.

Reprenons les possibilités de changement de logiciel.

Possibilité 1: Le paramétrage.

Je ne sais pas si ça compte vraiment dans la catégorie "mise à jour logicielle", mais il y avait toute une série de paramètres qui sont modifiables par télécommande dédiée. Par exemple, si on a besoin du moment d'inertie du satellite pour contrôler la rotation, on le connaît plus ou moins au lancement (on a le plan du satellite, la masse de chaque élément, donc physique + maths --> J). Sauf que 1) peut être qu'on a une erreur (et on peut l'estimer quand le satellite est en vol si il ne se comporte pas comme attendu)

Et au cours de la vie du satellite, il va changer (quand on utilise les "thruster", on brule du carburant, donc la répartition de masse change, donc on peut vouloir le mettre à jour.

Donc dans la liste de tous les paramètres du satellite, certains doivent pouvoir être changés. Donc on va les classer en catégories : "ne changera jamais" (pi, par exemple, normalement, ça ne change pas), "on doit pouvoir le changer". Cette catégorie va elle même être redivisée, par exemple entre "c'est important d'avoir la bonne valeur" ou "c'est juste un nice to have". Parce que si c'est vraiment important, il faut que quand on reboot on ait la bonne valeur, pour les autres, on peut juste faire une update "quand le logiciel tourne".

En fonction de la catégorie, la valeur peut être simplement en ROM, dans la RAM (et potentiellement updatée par commande "jusqu'au prochain reboot"), en SGRAM (résiste au reboot)

Possibilité 2: les free functions

Evoqué dans mon texte initial, on avait 3 tâches périodiques (désactivées par défaut) qui ne faisait rien. En gros, ça ressemblait à

.free_function_1:
    noop
    noop
    noop
    noop
    noop
.free_function_end:
    noop

Et on vient rajouter une fonction… en écrivant ailleurs dans la mémoire, là où c'est libre. On choisit la mémoire qu'on veut (si on veut jusqu'au prochain reboot, c'est simple, on écrit en RAM. Si on veut que ça survive à un reboot, on le met dans les tables de patch en SGROM… faut que je décrive le mécanisme plus bas.

Donc pour activer une free fonction :

1. écrire le code (compilé) dans une zone de mémoire libre, à l'adresse 0x42 par exemple. Et à la fin du code de la fonction, on met un jump .free_function_end
2. vérifier qu'on a bien écrit correctement ce qu'on voulait à l'adresse 0x42 pour être sûr en dumpant la mémoire
3. changer (patcher) un des noop au début de la free_function pour faire un jump 0x42 (vérifier qu'on a bien écrit)
4. modifier le paramètre qui active la tâche de la free function (par défaut, elle n'est pas active)

Et voila.

Possibilité 3 : Changer une fonction existante

Imaginons qu'on a une fonction avec un bug. On veut la corriger. On pourrait venir l'écraser directement en mémoire, mais

• ça ne marche que si ne nouveau code rentre là
• si c'est une fonction critique et que le patch rate (et plus la fonction est longue, plus la possibilité est grande) c'est un peu la merde.

Du coup, la méthode ça serait plutôt similaire à ce qu'on fait pour la free fonction.

1. on écrit la version corrigée dans une zone libre
2. on vérifie
3. on remplace l'appel à la fonction original par un appel à celle qu'on vient d'écrire (au lieu de call addresse(function_originale), on fait call addresse(function_patchée).

Alternativement, si c'est une fonction qui est appelée à plusieurs endroit, on peut, à la place du point trois, venir modifier la première instruction de la fonction originale par un jump addresse(function_patchée)

Interlude : Les tables de patch

Les possibilités 2 et 3, ça marche très bien en RAM, donc pour la vie courante du logiciel, jusqu'au reboot. On pourrait faire aussi le même patch en ROM, mais

1. on ne veut pas mettre la ROM en mode écriture possible (radiations, erreurs, … et ce serait permanent) ; et
2. ça ne concernerait qu'un seul calculateur à la fois. Il faudrait donc rebooter sur l'autre si on voulait appliquer le même patch dans l'autre ROM

C'est là qu'interviennent les tables de patch en SGROM. Au boot du calculateur, il se passe plusieurs choses:

1. la ROM est copiée en RAM
2. quelque chose fait démarrer le logiciel à l'adresse 0xB00T (oui, T n'est pas un chiffre hexa… :-p)
3. la fonction de code "boot_logiciel()" de l'adresse 0xB00T démarre

Cette fonction va aller lire la table de patch. C'est un tableau de structure, quelque chose comme

struct table_de_patch {
    enum calculateur; // (aucun, CPU1, CPU2, BOTH)
    bitfield actif_in_mode;    // 0b xxxxx
    int start_addresse;
    int longeur;
    int data[];
}

(plutôt qu'un tableau, c'est probablement plutôt une linked list, vu que la taille doit varier, mais bon)

Pour chacun des éléments du tableau, au boot, on va regarder si on doit "patcher" la RAM qui vient d'être copiée depuis la rom. Si on est sur le bon calculateur (en fonction de l'enum), que le patch est censé être appliqué dans ce mode (plusieurs mode, c'est géré hors du logiciel, on commence à 2, à chaque anomalie grave ça augmente, si on arrive à 5, c'est grave.) alors le patch est appliqué.

Si je reprends l'exemple de la free function, plutôt que de l'appliquer en RAM directement, je peux mettre deux choses dans la table de patch :

1. le code que je mettais à l'adresse 0x42
2. le jump dans le code de la free function
3. je configure les deux pour être appliqué dans les modes 2, 3, 4 et sur les deux calculateurs.

Et voila, chaque fois que je reboot, la free fonction existe, même si je n'ai pas patché le "vrai" binaire, elle est rajoutée "automatiquement" par le code lui même.

Possibilité 4 : Changer tout le logiciel

Bon, préliminaires :

1. Non, la table de patch ne peut pas faire ça, on a pas assez de place.
2. C'est de la théorie, c'était possible, testé, mais pas documenté pour le client. La NASA le fait en vrai (pas sûr qu'ils le fasse comme nous)

Imaginons que je veux changer tout le code, entièrement, comment je fais ? En théorie, c'est simple : mon code tourne en RAM, je peux changer la ROM. Petit problème, ça prend du temps, si on reboote au milieu… le calculateur est mort pour toujours.

Solution ? Facile, j'ai 2 Mo de ROM, donc si "Logiciel Original" + "Nouveau Logiciel" <= 2Mo de ROM, je mets le logiciel là où j'ai la place dans la ROM. Et une fois que j'ai vérifier que c'est bien écrit, au lieu de booter à l'adresse 0xB00T je boot à l'adresse 0xNOUVEAU_B00T.

Sur les prédécesseurs de ce satellite en particulier, notre logiciel en ROM faisait moins de 1Mo, donc ça marchait. Sur ce projet en particulier, ça faisait un truc du genre 1,2Mo, donc non. Mais pas de problème, il "suffit" de ne pas avoir 2 logiciels, mais 3.

1. logiciel original : 1.2 Mo
2. logiciel avec "juste de quoi patcher et survivre dans l'espace" : moins de 2Mo - 1.2 Mo
3. logiciel final : 1.2 Mo

Adapter les tailles, si jamais le final est plus grand…

On applique deux fois la procédure de changement de logiciel. Et voila. Ca marche sur le banc de test. En vrai ça n'existe pas.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

C'était un OS développé en interne. Je pense que c'était le cas sur tous les satellites sur lesquels j'ai travaillé (plutôt dans l'industrie spatiale classique, des satellites bien chers, de plusieurs centaines de kilo à quelque tonnes. Dans le "new space", j'imagine qu'ils ont des choses un peu plus "cots" pour l'OS, mais je ne suis pas sûr)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Mon exemple, un peu détourné, était celui de la biométrie pour le passage à la cantine du collège de mon fils

Ok, je n'ai as d'enfant, et si j'ai été au collège (enfin, l'équivalent dans un autre pays) c'était il y a plus de 20 ans mais… pourquoi de la biométrie pour la cantine ? Juste pour la facturation ? On ne peut pas leur donner une carte ? Et pour rentrer dans l'école, il n'y a pas une carte ou quelque chose ? Et si ça, c'est sans biométrie, on ne peut pas juste utiliser la même méthode ?

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

En deux mille vingt-cinq, qpad nous présentait Typst

Quand je clique sur le lien, je vois 2023.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Le plus simple ce serait d'utiliser la base 12 partout et d'avoir un système métrique où les rapports entre unités serait de 12 partout (enfin, 10, si on l'écrit en base 12). Comme ça plein de diviseurs et les calculs facile, car 10 * un mètre = decamètre = 10 mètres (soit 12, en base 10, mais osef vu qu'on utilise toujours la base 12) !

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

cet accord […] établit un précédent obligeant les entreprises d’IA à rémunérer les titulaires de droits

Non, un autre acteur de l'IA (ou même Anthropic) pourrait décider de continuer un procès jusqu'à son terme dans une autre affaire. Là c'est surtout un argument en faveur d'ayants droits qui poursuiveraient, mais pas une obligation.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Attention, ce jounral n'est pas un jounral sur le cyclimse.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Autrement dit si vous etes un homme vous etes discriminé car a competance egale on va prendre la fille pour respecter le quota

1. Si deux ou plusieurs candidats ont des compétences égales, il y aura forcément un ou plusieurs candidats qui seront discriminés (négativement), par définition.
2. Est-ce que ta société vise à embaucher des femmes, où à avoir un effectif d'environ 50% de femmes et 50% d'hommes ? Si demain, il venait à y avoir une inversion du nombre d'hommes et de femmes, est-ce qu'elle continuerait à encourager à embaucher des femmes ? Si la réponse est non, ce ne sont pas les hommes qui sont discriminés, mais simplement le genre qui comprend le plus de membres dans votre effectifs
3. les grilles de salaires, c'est bien, et il n'y a aucune marge dans ces grilles ? S'il y a des marges, le rapport du CSE sur l'égalité salariale est plus intéressant que les grilles salariales.

Cela dit, même si ton commentaire (ou le mien) pose des questions intéressantes, il ne permet toujours pas de déduire si les LLM utilisés dans l'étude ont un biais qui est poussé par les politiques de DEI ou par autre chose (ou une combinaison)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

c'est sans doute aussi le reflet du DEI omniprésent en entreprise depuis 1 ou 2 décennies.

Ou que les entreprises embauchent plus des femmes ou des minorités parce que leur performance est meilleure, ou parce qu'ils sont payés moins chers, ou pour d'autres raison. C'est facile de dire "c'est à cause du DEI omniprésent", sans autre forme d'analyse des autres biais existants…

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Clairement, il faudrait rajouter une zone de commentaire pour pouvoir développer sa réponse. Sinon ça ne peut pas marcher.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Si tu fais sauter EDF, la police anti-terroriste va débarquer chez toi.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Je n'arrive pas à comprendre pourquoi on tend à imposer une dépense de moyens et d'énergie pour effectuer la moindre petite tâche

Bah moi je comprends bien qu'un vendeur d'énergie trouve un moyen de faire en sorte qu'on doive dépenser plus d'énergie. C'est comme quand Coca Cola trouve un moyen de te vendre plus de Coca Cola.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Pour arriver à ce résultat il faut de temps à autre rajouter une 61ème seconde (on a donc h:m:60 tout à fait légal, 2 fois par an), la seconde intercalaire.²

Pas nécessairement deux fois par an (ce n'est arrivé qu'une fois en 1972). C'était souvent une fois par an, maintenant plutôt 0. Et le système prévoit également :

1. d'en ajouter aussi fin mars ou septembre, si juin et décembre ne suffisent pas
2. d'en retirer, c'est à dire de passer de 23:59:58 à 00:00:00 directement, si nécessaire (ce n'est pas encore arrivé)

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Il fait tout, sauf éditeur de texte. CQFD.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Le problème de cette approche c’est quelle rend l’outil que t’es entrain de créé limité par design.

Tous les outils sont limités par design. Il n'existe pas aujourd'hui d'outil universel capable d'effectuer toutes les tâches, et si tu veux en créer un, bonne chance.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Alors on pourrait être tenté de considérer les devs Excel comme des abrutis infoutus de chercher "calendrier grégorien" sur Wikipédia. On n'aurait pas forcément tort.

On aurait raison. Enfin, abrutis je ne sais pas, mais infoutus de chercher sur wikipédia, c'est sûr. Pour un problème de calendrier, évidemment, vu que 2001 > 1985.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

et chouette histoire.

Non, c'est une outarde canepetière. La chouette a déjà été retrouvée, apparemment.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Les comptes « Premium » disposent d’un identifiant unique en base de données dit « id ».

Je ne vois pas l'intérêt de payer sept fois le prix d'un compte basique, si je n'ai même pas le droit à un identifiant universellement unique.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Ah oui d'accord. Mais c'est dommage /o\

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Qu'est-ce qui devient open source ? C'est l'API qui sera documentée et utilisable ? C'est le code utilisé par les serveurs qui sera publiée ? Le code des applications clients (comme celle de la poste) ?

Et tu n'aurais pas un lien ? (j'ai googlé au moins pendant 3 secondes et je n'ai pas trouvé de "bon" lien, du coup je repasse en mode paresseux ;-) )

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

Depuis quand on met des fonctionnalités dans un outils sans les vendre?

Difficile à dire précisément, mais j'imagine que "longtemps" est une réponse suffisamment précise. Par exemple, ici on peut voir qu'une petite boîte californienne qui vendait des mcu/cpu pas très importants il y a 40/50ans embarquait des instructions non documentées.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.