plr a écrit 67 commentaires

Mea culpa!
Et en effet, c'est logique : on trouve des offres d'emploi/stage super intéressants proposés sur le site web de Thales parce que Thalès, lui, n'a sans doute pas eu le temps de finir le site web de son école! :-D

Je te remercie pour cette présentation digne d'une plaquette marketing (hé!ho! ne te vexes pas, je suis taquin de nature!). Je connais Thalès globalement mais pas dans son organisation interne. Je pense que le sujet ici abordé concerne essentiellement le grand public et industriel; je ne pense pas que Thales utilise le résultat pour ses applications défense et armement. D'ailleurs, on s'autorise (dans les milieux autorisés) à se poser la question de savoir s'il n'y aurait pas une peu de tirage de couverture à soi: à la limite, je m'en fiche, bien au contraire surtout si celà pousse les autres fondeurs à metttre plus de sécurité dans les uC et uP (micro-contrôleurs / micro-processeurs).

Ne me fais pas dire ce que je n'ai pas dit: oui, Thales a une vrai expertise dans le domaine de la sécurité. Mais, à mon goût, je trouve qu'il ne partage pas suffisamment avec les communautés open-source et que celà ne se voit pas à mon niveau (plus développement/intégration que recherche) avec des micro-processeurs qui sont ridiculement peu performants par rapport à ceux qu'utilisent Thales.
C'est d'autant plus vrai que tu cites l'ensemble des entités et lorsqu'on connait le nombre d'employés; je ne trouve pas de référence à un mail de thalesgroup ni dans le code source que j'ai de freertos, ni dans le linux "rt" que j'ai sous la main. Pourtant, il y a des offres d'emploi/stage avec demande de maîtrise des ces os là…
En comparaison, il y a un certain temps, les NXP, Freescale, TI, Atmel(Microchip), Intel, Microsoft (entre autres) étaient de très mauvais contributeurs, je te laisse aller voir leurs contributions, c'est colossal et je les remercie!

Je propose un lien direct avec des conseils très concrets sur la sécurisation de uC/uP, en échange, le lien qui est proposé (merci quand même, je ne vais pas cracher dans la soupe!) vers des publications où il faut décliner toute son identité pour accéder à une information dont on ne saura pas la pertinence par rapport à ma recherche: hélas, je n'ai pas l'autorisation de fournir ces informations.

Pour être dans le concret, quand dans une installation, j'ai plus d'un millier (petite installation) de uC allant du 8 bits au 32 bits tous reliés par des bus spécifiques (pas le droit d'en dire plus sur les distances et sur les medium), et que je souhaite améliorer la sécurité globale du système alors que j'ai une contrainte économique très forte (Thales n'est pas présent dans mon segment): redondance de micro-processeurs, redondance d'appareils, synchronisations des redondants, mise en place de canaris à bon escient dans des uC à très faible empreinte, surveillance, tracking des modifications de configuration de périphériques internes/appareils hardware (donc autant surveillance interne qu'externe, utilisation de certaines préconisations de SIL4), utilisation d'un "serveur tiers" pour la validation de certaines demandes d'autorisation, etc. Je trouve plus d'information constructive dans des petites sociétés et chez les fondeurs ce qui fait que je serais tenté de me tourner vers eux d'abord avant d'aller voir Thales, ce qui n'est pas forcément raisonnable (celà dépend du projet)
La contrainte économique fait que j'aurais souhaité que les uP de génération actuelle aient plus de blocs hardware dédiés sécurité (on commence à avoir AES presqu'en standard, il y en a d'autres qu'on est obligé de faire en sw alors que le coût en hw serait négligeable): je suis sûr que si les pratiques de sécurisation étaient plus partagées depuis un moment, on en bénéficierait tous car les fondeurs intègrent les blocs que les client demandent.

Conclusion: je suis frustré qu'à mon niveau (et je pense représenter un certain nombre d'ingénieurs en systèmes embarqués dans des petites structures qui déploient des myriades de capteurs en réseau), on ne puisse pas bénéficier des miettes de recherches qui ont été amorties depuis bien longtemps… Et encore plus lorsque tu vois la NSA avec SELinux (sans l'utiliser, ça m'a aidé à trouver des pistes d'améliorations sur un système)

Bien entendu, on peut entendre ce message; je le connais étant dans le monde de l'entreprise depuis un certain temps.
Mais il m'est incompréhensible. D'ailleurs, tu ne donnes pas ton avis là-dessus, tu fais juste un constat connu : j'aurais aimé lire ta prose plutôt que de voir d'autres moinsser ton commentaire, qui me semble être un bon départ de discussion.
Pour ma part, je n'arrive pas à accepter le message qui indique qu'on va être dans le monde "open-source" et ne rien communiquer, pas même un livret de bonnes pratiques.
Toute analogie ayant ses limites, ça me fait penser à un passant qui aide un aveugle un peu ignorant à traverser la route en lui disant quand traverser mais qui ne lui expliquera pas qu'il y avait un dispositif de guidage au sol devant le passage piéton et que la musique lui indique quand le feu est vert. OK, pourquoi pas, mais pourquoi je lui ferais confiance et je ne trouve pas ça fair-play.

Et je ne parle même pas de l'illusion de "sécurité" du "secret-défense" dans ce domaine (plus ou moins vrai); histoire vécue: c'est le PC qui est installé chez le client avec un dongle d'utilisation, toutes les communications en protocole propriétaire sécurisé, mais qui est ouvrable et qu'on peut récupérer/cloner/modifier toutes les données stockées, mots de passe (md5) y compris sans y laisser aucun indice à l'installateur… Ou de la récupération de documents confidentiels dans la poubelle commune à l'extérieur d'un bâtiment ultra-sécurisé (au XXe siècle)

D'où mon attentisme empreint d'espoir.

Le lien vers l'eBook est défectueux dans le journal. Il est ici: "Building your application with security in mind"

HS: j'ai sans doute dépassé la moitié de ma vie ici bas et je suis d'accord avec le fait d'adapter les usages pour les générations à venir. Merci donc pour cette réflexion intéressante que j'ai déjà eu par ailleurs pour une appli métier où il y avait la notion d'enregistrement.

Suite à ton entrée de journal, j'ai spontanément pensé à l'icône de "git commit" mais je trouve qu'il manque la notion d'action qu'on peut rajouter avec une flèche. Mais cela se rapproche des icônes "git push" qu'on peut trouver sur l'Internet, dont la notion est différente…

PS: on pourra se faire une crapette à 2 mais je préfère le tarot.

autre solution pour le comptage des lignes: utiliser cloc

Quelle est la marque du clavier? (ça me fait penser aux claviers de la marque Trust…)
Tu es sur quelle distribution?
Tu as essayé de changer le modèle de clavier (xkbmodel) avant de changer la disposition (xbklayout)?
une liste (non exhaustive?) ici

Je suis assez surpris par la taille de ton exécutable.

J'ai fait quelques interfaces graphiques plus complexes que celle que tu nous présentes pour des besoins en interne (IDE pour automatismes, interfaces de communication pyserial)).
J'en suis à maximum 20MB sans compter les ressources (images, programmes non liés statiquement).

• J'ai essayé sur mon PC en win7, python3.6.4, PyQt5.9, le programme fonctionne.
• J'ai essayé avec un .spec générique (que j'utilise): le programme fait 18 MB mais j'ai un message d'erreur "Failed to execute script tool" sans autre message, donc inutilisable, je ne comprends pas pourquoi et désolé, je ne vais pas avoir le temps de chercher…

sxtool.spec

# -*- mode: python -*-

block_cipher = None

a = Analysis(['sxtool.py'],
             pathex=[],
             binaries=[],
             datas=[],
             hiddenimports=[],
             hookspath=[],
             runtime_hooks=[],
             excludes=[],
             win_no_prefer_redirects=False,
             win_private_assemblies=False,
             cipher=block_cipher)
pyz = PYZ(a.pure, a.zipped_data,
             cipher=block_cipher)
exe = EXE(pyz,
          a.scripts,
          a.binaries,
          a.zipfiles,
          a.datas,
          name='sxtool',
          debug=False,
          strip=False,
          upx=True,
          console=False )

genInstaller.bat

set PATH=%PATH%;C:\Qt\Qt5.9.0\5.9\msvc2015_64\bin

del /Q dist\sxtool.exe
rmdir /S /Q __pycache__
rmdir /S /Q dist
rmdir /S /Q build

pyinstaller sxtool.spec
move dist\sxtool.exe .

Je viens de m'apercevoir que j'ai un projet perso que j'avais fait à l'arrache que je peux te partager (par mail) mais pas diffuser : il y a dedans l'enregistrement des préférences, du glisser/déposer de fichier, de l'appel à un programme tiers. Par contre, dans cette interface, pas de menus, pas d'ouverture de fichier xml, et sans commentaires parce que c'est suffisamment parlant pour moi, j'avais essayé de prototyper un modèle MVC… Ce serait vraiment que pour montrer une façon de faire (très très basique) d'une interface graphique avec création d'un éxecutable et génération du fichier d'installation… Si ça t'intéresse…

alors oui, entièrement d'accord pour la partie ARM.

Par contre, là où je ne suis pas d'accord avec toi, 16bits vs 32bits, si, si, je persiste, je signe, je prouve et je m'en félicite… euh, je m'emballe là, non? :D

Microcontrôleurs 16bits qui sont plus intéressants que les cortex 32bits: gamme des MSP430 chez TI, chez microchip, il y a les équivalents: ils intègrent des fonctions ADC/CAN/bus/etc plus adaptées que sur leur gamme ARM. On les utilise dans le comptage (eau, gaz, élec) par exemple, Linky étant une exception (ils utilisent un STM10 qui est un 32bits).
Pour des applications plus générales, je pense que les cortex sont intéressants. Dans une sous-partie de mon domaine (automates programmables), c'est une solution "batard" que les uC 32bits: trop chers/complexes pour des fonctions simples, pas assez de possibilités pour des fonctions plus évoluées.
Par exemple, on a des produits ou il doit y avoir une isolation électrique avec des bus d'échange donc 2 uC (au minimum), on va ajuster au minimum la puissance/taille/consommation/coût/complexité car sinon on multiplie par 2 ces critères là et ça ne passe pas le marketing.

Mais la discussion de la disparition des uC 8/16/32bits est un vieux loup de mer!

Je suis d'accord en grande partie avec Bruno car il précise bien que le C ne disparaîtra pas mais je trouve qu'il omet un grand pan de l'industrie.

Pour rajouter un élément à la réflexion, dire que le langage C va être remplacé sans y mettre plus de bémol peut indiquer un manque de connaissance du marché global et des applications du langage C.

Pour celà, je vous laisse regarder les parts de marché/volumes des microcontrôleurs(uC) 8/16bits vs 32bits et même l'ensemble des microcontrôleurs vs processeurs (x86, server, etc) pour comprendre que le C n'est pas prêt de disparaître: c'est actuellement environ 50% embarqué vs processeurs pour PC/serveurs.

Le prix d'un uC 8/16bits étant < 1$, on ne voit pas pourquoi mettre des uC ou processeurs dont le coût des composants est > 10/15$ (car il faut rajouter de la ram, le pmic, du stockage…); sur des volumes de >10k pièces, celà ne se justifie pas. De plus, même avec des uC 32bits, on réduit le coût du produit en réduisant les tailles des mémoires, dont exit les langages qui ne génèrent pas du code ultra-optimisé, et ceux qui ne peuvent permettre les certifications de sécurité (e.g. SIL)
Et pour ces raisons (mais pas que), le langage C est encore le plus rencontré dans l'embarqué: plus rapide à développer qu'en assembleur et le footprint est plus réduit qu'avec des langages plus "évolués" (je préfère utiliser les termes "adaptés"). Du temps de mes études (fin des années 90), on nous disait que les processeurs/langage Java allaient envoyer le C aux oubliettes… ok, pourquoi pas… :D

Dans la plupart des machines à laver (les entrées/milieux de gamme), ce sont encore des uC 8/16bits, dans les capteurs des 8/16bits, dans les compteurs du 16bits, etc.

Par contre, dans d'autres applications, je suis assez d'accord avec le constat, la meilleur indication que j'ai à mon échelle est que j'ai appris successivement le perl, le python (et bientôt go?) pour générer du code sur les plateformes non-embarquée; Que j'embarque du linux plus rapidement/facilement sur les plateformes embarquées qui font de l'agrégation de données avant de les envoyer vers des serveurs… euh… ha oui, drivers toujours en C ;-)

En effet, je trouve aussi mais je tempérerais car on ne connaît pas le besoin du client:

• si cet ingénieur n'est pas seul sur cette mission (poste non critique) et que l'ensemble des process de développement et d'intégration (versioning, build system, développement drivers,…) alors c'est une super expérience pour le candidat et le salaire est convenable.

• Si c'est critique (seul ou même 2), alors je ne comprends pas la stratégie du "client": le conseil serait embauche directe à un salaire plus haut à plus de 10 ans d'XP. Parce que le risque pour le client (et donc la société de prestation) est carrément élevé: à ce niveau de compétences multi-domaines (android, embarqué, appli pc?), les profils sont rares. Si c'est juste pour "essayer" de développer la boîte, un prestataire est un bon profil. le mieux serait un freelance compétent (en passant par la ssii par exemple)
  Etant moi-même dans le cas d'un poste équivalent et critique, mon salaire est de plus de 15% supérieur à cette fourchette en PME (j'ai en plus les communications industrielles)… par contre, déménagement oblige, car les opportunités dans ce domaine sont plus rares d'où des exigences de salaire plus fortes.

Je trouve que le contenu du poste est attirant!
Bonne recherche!

PS: la phrase: "systèmes Linux embarqués de fichiers racines (root file systems) type Yocto, OpenEmbedded, Buildroot, etc" n'a pas de sens; je comprends ce que vous voulez dire mais c'est un gloubi-boulga que vous devriez retravailler si vous voulez bien réussir à choisir un candidat compétent.
Par exemple: "Vous disposez d'une expérience et de connaissances solides des systèmes Linux embarqués. Vous maîtrisez au moins un build system du type OpenEmbedded (Yocto project), Buildroot, OpenWrt ou autre. La génération du système de fichiers que vous aurez en charge nécessite que vous maîtrisiez la création, la customization et le déployement des images. Vous maîtisez impérativement les contraintes temps-réel: connaissance de RTlinux, RTAI, Xenomai (ou autres RTOS) appreciée"

Super que tu tu aies trouvé une solution!
pour le démarrage, on dirait que l'init manager est systemd.
Comme je n'ai pas encore utilisé du systemd sur mes plateformes, je ne peux que t'aiguiller sur la recherche: créer un service dans /etc/systemd/system qui lancera un script où tu mettra tes commandes… Il y a des exemples un peu partout sur le net, et avec un peu de chance il y a déjà ce genre de questions sur le forum! ;-)

ou bien, de lancer la commande juste avant le lancement de ton application.

La trame de retour est nickel, on voit bien les premiers octets 0x01, 0x03, 0x04 (héhé, l'habitude du décodage en live de traffic uart!…)

En cherchant un peu sur le net, j'ai vu que tu n'étais pas le premier à qui celà est arrivé:
C language program reading UART loses characters

il faut "disabler" getty dans inittab… lis l'ensemble du post, ça devrait t'éclairer et peut-être résoudre le problème.

Avec le flush avant l'envoi idem.

Oui, c'est normal, ce n'est pas ça qui changera quelque chose, c'est juste histoire que le buffer soit propre.

tes oscillogrammes, sont bien pris entre le transceiver et la raspberry? ou sur la 485?… et oui, peut-être faut-il aller gratter du côté du sw…

dans ta config, j'ai l'impression que tu actives la parity (PARENB) alors que le commentaire dit le contraire…

En plus du flush à faire non pas après mais avant l'envoi de la trame (conseillé pour éviter que ton buffer soit pollué par d'anciennes trames ou autre), la question qui se pose est le temps de retournement de ton interface de communication:

digitalWrite (12, 0);

Ne connaissant pas ces fonctions, je ne peux pas te répondre sur le type/temps d'exécution de ces fonctions. Sont-elles synchrones/asynchrones?
Quel est le temps de retournement du transceiver?

avec un analyseur logique (ou oscillo), tu verrais les signaux et ce serait plus facile à débuggeur: tu verrais peut-être que ton signal de commande arrive au transceiver alors que ton équipement a déjà commencé à répondre…

Edit: à supprimer parce qu'en fait ton problème a été résolu dans le temps où j'écrivais ce post…

Dans l'exemple ici, l'objectif étant d'utiliser une variable (case mémoire) commune entre 2 fonctions, l'une pouvant interrompre l'autre; Dans un OS, on peut utiliser un
mutex

On pourrait simplifier à l'extrême et utiliser une implémentation qu'on pourrait appeler un "mutex matériel" comme tu le proposes (même si je ne suis pas entièrement d'accord pour des détails que je n'exposerait pas ici), mais "masquer des interruptions" est un mécanisme matériel qui peut être utilisé pour beaucoup plus de cas.

Je ne sais pas quelle est ta connaissance des micro-contrôleurs, processeurs, alors je vais simplifier pour ceux qui passent par là avec une connaissance limitée, ne te vexe pas alors si tu trouve ça trop simplifié! ;-)

Simplifié" à l'extrême, ne interruption, est un signal hardware ou software (appui sur un bouton, signal généré par un timer hardware, autre…) qui va faire que la cpu va interrompre l'exécution de la liste d'instructions en cours pour exécuter une fonction (listée dans la table des vecteurs d'interruption)
Si dans le cas ici, callback1 est une fonction appelée par la routine d'interruption, la cpu va interrompre l'exécution des instructions de la fonction main.
Masquer les interruptions permet d'empêcher l'exécution des routines d'interruptions (et donc de la fonction callback1) jusqu'à ce qu'on les réactive.

C'est comme l'histoire de 2 personnes (A et B) qui éditent un fichier partagé sur un disque partagé: si tu ne bloques pas B alors que A est en train de l'éditer, je te laisse imaginer les dégats.

Salut,

Je n'ai regardé que cet aspect là, je n'ai pas regardé le reste… A moins que je ne me trompe sur le séquencement des tâches ne connaissant pas l'environnement, mais la fonction callback1 est appelée par la routine d'interruption (ISR).
Tes variables tapCounter et elapsedTime sont modifiées en même temps dans le main et dans l'interruption, ça fera un bug aléatoire en fonction de l'instant quand tombe ton interruption par rapport à l'exécution de ton main.
Dans l'embarqué, ce genre d'erreur ne pardonne pas (on appelle ça une erreur de débutant chez les vieux barbus de l'embarqué) mais c'est une erreur habituelle et même une inattention est vite arrivée!
Une petite explication pour ceux qui ne trouve pas celà évident au premier abord

Il faut toujours masquer les interruptions qui vont bien avant de modifier une variable partagée entre les fonctions appelées par le main et les fonctions appelées par les routines d'interruptions.
En généralisant, il faut toujours masquer les interruptions ou utiliser les services de l'os qui vont bien (sémaphores, mutex, ou autres) lorsqu'on modifie ou lorsqu'on accède à des variables partagées par des thread différents.
Un bug méchant mais qui ne semble pas évident au premier abord: sur un micro-contrôleur 8 bits, l'accès en lecture d'une variable 32 bits accédée en lecture simple par le main (même avec une variable 16 bits, ça bug aussi)

u32 variable;

interruption ()
{
    variable++
}

main
{
    while (true)
    {
        if (variable > 0x00010000UL)
        {
            masqueInterruptions()
            variable = 0
            restaureInterruptions()
        }
    }
}

est buguée (si! si! je l'ai eut testé)! Pourquoi?
Parce que la comparaison d'un 32 bits par un micro 8 bits se fait en plusieurs coups d'horloge (la connaissance de l'assembleur aidant pour lire le code généré). Il suffit (non pas d'un signe, un matin, même s'il est tout tranquille… ⁾ mais que l'interruption 'claque' en plein milieu de l'exécution de ces instructions, le test peut être faux et ta variable peut ne pas être remise à 0.

Il faut écrire la fonction main de la façon suivante:

main
{
   u32 temp32b;

    while (true)
    {
        masqueInterruptions()
        temp32b = variable
        restaureInterruptions()

        if (temp32b > 0x00010000UL)
        {
            masqueInterruptions()
            variable = 0
            restaureInterruptions()
        }
    }
}

Et même la fonction que je te propose peut être fausse si l'opération dans l'interruption est plus complexe et que le test dans la fonction main est aussi plus complexe. Dans ce genre de cas, il vaudrait mieux masquer les interruptions avant l'accès:

main
{
    while (true)
    {
        masqueInterruptions()
        if (variable > 0x00010000UL)
        {
            variable = 0
        }
        restaureInterruptions()
    }
}

Ce qui n'est pas sans pouvoir causer des problèmes de temps réel car on masque les interruptions trop longtemps. Mais c'est une autre histoire…

Je viens de voir qu'ils ont implémentés des fonctions noInterrupts() et interrupts() dans l'environnement arduino.

Pour moi, écrire du code, c'est de coucher par écrit une pensée visuelle que j'ai dans la tête.
Du code, c'est pour moi quelque chose d'extrèmement lent par rapport à l'algorithme que j'ai dans la tête qui n'est que visuel : des boîtes, des flèches, des cases, des diagrammes temporels…
Si je pouvais éviter la case écriture, ça m'irait bien!
Avec la souris, tu peux sélectionner des fragments de code de ligne, sélectionner des colonnes, copier, coller, dupliquer, déplacer du texte, ouvrir un fichier en le glissant-déposant.
Le code se répète plus souvent qu'on. Ne le pense: par exemple, je tape l'entièreté de la structure d'un Switch-case, motif qui se répète et je fais glisser les valeurs de la structure énumérés que j'ai copié juste en dessous. Et ensuite, je tape le contenu…

Mais à chacun sa façon d'optimiser sa vitesse d'écriture de code sans erreur !

En effet, c'est communément le cas. Mais je fonctionne différemment !
Je vais plus vite à copier-coller les noms de variables plutôt que de les retaper et de faire une erreur de nommage; à déplacer une ligne à la souris,
Ensuite, le temps de la réflexion laisse largement le temps d'attraper la souris: le mouvement de la main est un mouvement physique qui ne me prend pas de "temps de cerveau" contrairement à devoir taper des lettres sur un clavier qui nécessite de réfléchir à la combinaison à effectuer. Pendant que vous pensez à celà, moi, j'ai le temps de relire ce que j'ai écrit et donc de penser uniquement à l'algorithme plutôt qu'à des commandes qui font travailler la mémoire !

Ce qui est plus mauvais pour la santé, ce sont les souris, claviers, écrans et sièges fournis par l'employeur. Par exemple, je me suis acheté une souris qui me convenait pour le boulot (souris de gamer bien entendu!)
Et le pire, ce sont les applications qui ne sont pas ergonomiques qui sont sources de stress, mais c'est un autre sujet…

Mes langages: python, c, assembleur, perl

Pour l'instant, j'utilise à 95% Notepad++ pour des questions de vitesse et parce que je suis un ancien accro des fps/rpg donc utilisation de la souris pour tout:
- et même Notepad++ sur les fichiers d'une cible Linux (accessible via Samba: machine virtuelle/pc physique sur le résal)
- Visual Studio Code sur Linux (je commence)

Ce que je déteste: la lenteur et le clavier, c'est à dire:
- vi, vim, emacs, etc. (j'utilise nano sur les plateformes embarquées pour faire des tests, mais comme à la fin les modifications doivent être dans le GIT, j'évite les modifs sur la cible)
- Eclipse: c'est lent
- Atmel Studio, c'est devenu une usine à gaz qui est d'une lenteur et d'une lourdeur: j'essaye de tout faire passer par d'autres ports de debug plutôt que de passer par l'ide (en dernier recours)
- Code Composer Studio (basé sur Eclipse): que pour le debug avec la sonde dans les phases de prototypage. Même chez TI, on évitait de l'utiliser (dans les premières versions…)

Et les autres, sympathiques mais il n'ont pas réussi à tenir plus de 2 semaines sur mon PC:
- PyCharm: j'ai essayé mais c'était trop lent pour moi malgré l'interface très sympathique
- Atom, je ne sais plus pourquoi mais il m'a saoulé et je suis revenu à mon notepad++
- QtCreator: je n'utilise que le designer pour prototyper des GUI. J'avais fait un petit projet en C++, il était agréable, moi qui ne suis pas aussi à l'aise en C++ que dans les autres langages

Je passerais bien entièrement à Visual Studio Code pour l'édition…

Merci pour ton partage. Concernant ton paragraphe sur la clarté, j'émets des réserves et des désaccords.

la clarté: En lisant le texte d'un programme, il faut qu'il soit facile de comprendre l'intention des personnes qui l'ont écrit.

Je suis entièrement d'accord et j'irais même plus loin: un code source "beau" est plus facile à comprendre et vérifiable (relecture) que s'il suivait strictement les "règles" édictées par des normes, règles d'usages, etc.
"C'est véritablement utile puisque c'est joli." (Saint Exupéry - Le Petit Prince)

On dit qu'un programme a un bug (un défaut de fabrication) quand sa signification (pour l'ordinateur) ne correspond pas à l'intention de ses auteurs—une erreur a été faite pendant la transcription des idées dans le texte du programme.

Je pense que ta définition du bug est trop réductrice, incomplète et donc erronée. J'illustrerai ce point ci-dessous.

La clarté est un composant essentiel de la sûreté (éviter les comportements inattendus et dangereux).

C'est ton avis et celui-ci n'est pas objectif et ne correspond pas à la réalité de la production de code informatique: la clarté du langage est différente de la clarté du code produit.

Pour l'améliorer, certaines constructions des langages de programmation nous aident à exprimer notre intention, et les concepteurs et conceptrices de langages de programmation travaillent à concevoir des outils pour vérifier automatiquement que l'intention ainsi exprimée est cohérente avec le reste du texte du programme.

Non, les outils de vérification/normes/règles de codage n'ont généralement pas comme objectif d'améliorer la clarté du langage.
La réalité dans le monde des systèmes informatiques embarqués est tout autre: actuellement, je remarque que dans un bon nombre de cas, les bugs sont liés à des problèmes d'architectures, de "design", c'est à dire d'un malfonctionnement du cerveau du ou des personnes en charge de la cohérence d'un programme. Ensuite, des problèmes du non-respect du mode d'emploi des objets pilotés. Finalement assez peu de la transcription en elle-même: la faille WiFi WPA2 plaide en ma faveur!

1) Pour prendre 3 exemples:
- c'est l'histoire d'un architecte qui avait inversé le rôle de maître/esclave entre un producteur de données et d'un consommateur de données. Concrètement, celà donnait des trous et des désynchronisations de l'audio par rapport à la vidéo lors de l'affichage d'une vidéo (heureusement, la société a été rachetée, diluée, et avec ceci, la reconversion de ces personnes arrivés à leur niveau d'incompétence (principe de Peter): et oui, je suis frustré par ces personnes qui n'ont pas voulu écouter)
- ou encore plus proche, l'autoradio qui lit les AAC/MP3 dans ma voiture (Peugeot) interrompt la lecture avant la fin du fichier (et passe au fichier suivant) dès qu'il a envoyé la dernière trame au décodeur et pas dès que le dernier échantillon sonore a été réellement produit par le haut-parleur: en regardant le code, l'architecture, les tests, tu auras 100% de réussite aux vérifications et aucun bug trouvé! Pourtant mon vieux lecteur iPOD le fait correctement.
- Dans le domaine médical? Pourquoi le système de radiographie n'a-t-il pas pu démarrer le samedi quand je me suis présenté aux urgences et qu'il a fallu changer de service pour en trouver un qui accepte de démarrer? Je n'ai aucune preuve, mais je doute qu'il y ait un bug dans la transcription d'une idée

2) Le code est souvent écrit pour qu'il soit plus facilement vérifiable et contrôlé par des outils automatiques que pour la facilité de relecture: MISRA, SIL, PEP8 (ou autres règles rédigées par des personnes en manque de pouvoir). Ce qui donne du code illisible: i.e. immonde à relire et donc à vérifier la transcription. Finalement, la clarté du langage est dégradée par les normes et règles de production ce qui fait que beaucoup de code source passe les étapes de validation sans avoir été relu, compris et vérifié mais juste signé par un individu lambda. (pour le code d'Apple: qu'il n'ait pas été fait consciencieusement me surprendra moins que si on me dit qu'il n'y avait pas de relecture/peer review du code source!)

Mes conclusions sont:
- il y a, à notre époque, plus de problèmes dans le cerveau des concepteurs plutôt que dans la transcription des idées (dans le mien en premier!)
- La clarté du langage et du code source est régulièrement mise à mal par l'obligation de respecter des normes/règles de codage
- Les normes et règles de codage sont cependant indispensables pour réduire le nombre de bugs de transcription des idées au risque de dégrader la clarté.

D'où les questions: quels sont les liens entre la clarté d'un code source et celle du langage en lui-même? La clarté d'un code source peut-elle être forcée par le langage?

Tout ce blabla pour expliquer que vous avez besoin d'un développeur lambda, ça fait un peu tout much, non?
Parce que 750 au Toeic, c'est pour les développeurs, on demande toujours plus de 850/900 pour les postes stratégiques (architecture, management) sauf à vouloir minimiser le salaire.
Vous avez bien enrobé le tout derrière le mot "architecte" mais bon, c'est trop gros, ça ne passera pas!

Après ce poste, vous pourrez évoluer vers des postes de Chef de projet Logiciel ou des postes de management dans le domaine du logiciel.

Mais oui, mais bien sûr! C'est comme l'histoire du pot de miel et des mouches… L'annonce semblait crédible. Me suis déjà fait avoir au début de ma carrière par ce genre de promesses jamais tenues. Je conseille à ceux qui veulent devenir CdP de passer le PMP ou Prince2 mais de ne jamais, jamais croire à ce genre de promesses sauf si vous êtes incompétents techniquement et que c'est votre seule chance.

Au fait, en dessous de 55k€/60k€ pour un architecte software, c'est de l'arnaque… Et à ce prix la, pour un poste comme ça, c'est 900 au Toeic minimum.
Autant dire que même en ne postulant pas, j'aurais pas envie de rencontrer le supérieur sauf à se marrer pour les annales!

PS: je ne suis pas vexé, je ne suis pas administrateur de systèmes informatiques, mais pour avoir vu des cas compliqués à gérer, je compatis avec eux!
Bon courage à tous ceux qui s'arrachent les cheveux actuellement!

Mais tout simplement parce que beaucoup de systèmes industriels/SCADA se basent sur du Windows et que tu ne dois jamais les arrêter à moins de bloquer une production, un process (entrepôt frigorifique, cuisson d'aliments, chimie), d'éteindre l'éclairage de la piste d'un aéroport, ou de modifier le comportement de centrifugeuses d'enrichissement d'uranium etc. ;-)
Et quand il y a des millions d'euros/des vies en jeu parce que ton système ne redémarre pas correctement, assez rapidement ou qui a un comportement légèrement différent, tu ne trouves personne qui veut prendre la "responsabilité" de faire une mise à jour. Le dicton "Tant que ça marche, on ne touche pas!" prend tout son sens.

Alors, oui, les systèmes n'ont pas toujours été installés avec des redondances ce qui peut être considéré comme une faute pour certains systèmes mais c'est comme ça!
Et même si les màj étaient totalement transparentes, tu ne déploies pas sans être sûr, ce qui peut prendre des jours/mois/années avant de le faire.

Il est très désagréable pour un responsable informatique (qui doit être disponible 24h/24 365jours/an) de se prendre une remarque comme tu l'exprimes (à juste titre ou non!) par des non-connaisseurs qui n'ont jamais vu de systèmes informatiques/process industriels autres que leur petit PC personnel.
Donc ça ne me surprend pas plus que ça que le ransomware basé sur cette faille continue de se diffuser.