barmic 🦦 a écrit 5783 commentaires

Les gens oublient que la voiture est une arme par destination.

On arrête pas une voiture avec une arme de poing. La voiture a parcouru plusieurs dizaines de mettres. Si la vie de l'agent était en jeux, il serait mort, mais en plus il a mis en danger toutes personnes se trouvant dans le coin qui aurait pu se retrouver sur le chemin de cette voiture.

Si les policiers doivent arrêter des véhicules en mouvements, il faut les équiper et les former pour ce n'est pas juste une question de droit à faire feu.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le pharmacien doit inscrire la vaccination dans le carnet de santé, de vaccination ou le dossier médical partagé de la personne vaccinée.

Source : Vaccin contre la grippe saisonnière

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça apprends au flic à utiliser une arme contre un civil.

Justement non et c'est l'un des problèmes. On leur apprend pas à se servir correctement de leurs équipements. Aligner la police avec les gendarmes pourquoi pas si on aligne aussi leur formation.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Parce qu'ils n'ont pas été inscrit dans ton carnet de santé ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne trouve pas. Il pose une hypothèse puis énonce des causes qui selon lui explique son hypothèse. Ça n'a rien de sérieux ni même d'intéressant, c'est un billet d'humeur.

Ça pourrait venir de r/dinosaure.

Qu'une analyse matérialiste puisse expliquer comment le financement et l'organisation de la production a des effets pervers sur ce qui est produit j'en suis sûr, mais là il n'y a rien de construit ou d'organisé.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Qu'est-ce que le NVK ? J'ai pas rapidement trouvé l'info dans le lien

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

D'où vient le nom ?

À mon humble avis si ce journal devient une dépêche, ça vaudrait le coup d'expliquer plutôt le lien avec Algoo (le lecteur habitué connaît déjà positivement) et d'avoir un petit disclaimer sur ta position dans Algoo. Ça n'est pas caché ici, mais c'est distillé dans l'ensemble, je trouve plus clair de l'annoncer de but en blanc au début.

En tout cas c'est cool comme annonce. J'en ai pas le besoin, mais je serais curieux de connaître le travail que c'est de s'assurer qu'on est pas blacklisté

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis toujours surpris quand on sent le besoin de dire que ce qui est interdit est interdit.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il explique que l'interface des OS largement n°1 & n°2 en part de marché sur bureau sont dominants alors que les interface qu'on peut trouver que dans le reste des ordinateurs sont confidentiels ?!

C'est louche

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oula faut pas titiller les défenseurs de KDE 1, ils ont une mauvaise fois dont on a plus l'habitude.

KDE 1 pouvait facilement (sans créer de nouveaux thèmes, sans chercher/créer des plugins,…) reproduire l'interface de Windows 95. Ça fait un peu moins de mal à ton égo ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il est moins proche que serenity, mais l'explorateur de fichier, les décorations de fenêtre, le menu "démarré" et la barre des tâches sont très inspirés. Vu la capture je dirais qu'ils se sont inspiré mais n'ont pas cherché à reproduire et ont donc fais des choses en plus et rendu les choses paramétrables.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

De prime abord, ce que réalise gron in.json (i.e. déplier le JSON pour que ce soit manipulable par les outils qui manipulent des lignes de texte brut) s'obtient aussi avec :

Non ça n'a pas grand chose à voir. gron permet de manipuler des lignes qui n'ont pas besoin de contexte et c'est en ça qu'ils permettent d'utiliser ensuite grep ou sed de manière fiable et simple.

Si tu veux un exemple, si j'ai ce json :

{
  "foo": 11,
  "elem": {
    "foo": 12,
    "bar": "foo"
  }
}

et que je cherche la valeur associée au champ foo de l'objet elem.

Avec jq le mieux c'est de rester entièrement en syntaxe jq .elem.foo.

Avec gron tu va pouvoir ne pas apprendre une nouvelle syntaxe et utiliser awk comme awk '"json.elem.foo" == $1{sub(/;/,"");print $NF}' (oui c'est un cas où c'est bien plus compliqué, mais la syntaxe de jq peut devenir assez ésotérique et awk a plus d'usage que jq.

Il me semble que la plupart des autres commandes ne font rien d'autres que formater du json. Ce qui est loin de l'objectif de gron

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ou en traduisant quitte à ne pas garder le titre d'origine

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il y a quelques mois, c'était l'inverse, ils disaient ne pas voir à quoi elle (il ?) sert.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pardon j'ai oublié la ref…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La seule utilité que je vois aux objets, c'est de pouvoir injecter dans un même type (celui de l'objet) des types de données autrement incompatibles (distincts) pour pouvoir les mettre ensemble dans un conteneur homogène (liste, tableaux …).

Tu utilise pas un type somme pour ça ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Là tu me parles de jardiner dans la mémoire pour exploiter des failles de sécurité ou pour contourner le programme. Cela n'a pas grand chose à voir selon moi.

Les cas qui deviennent des problèmes de sécurité ne sont qu'une partie de ce que produit ce genre d'écriture. L'apprentissage du C passe nécessairement par l'explication de comment tu t'es créé des bugs en écrivant à côté de là où tu le souhaitais.

L'encapsulation c'est de ne pas exposer à un code appelant ses détails internes pour éviter un couplage fort dans le code, pas empêcher aux attaquants malveillant d'y accéder quand même avec tous les outils qu'ils ont à disposition.

Pas que, je le décrivais plus haut c'est garantir un invariant. Cette garantie n'est pas forcément binaire et tu parle de C++, mais python est un langage objet qui n'a que faire de l'encapsulation.

Après ça n'intéresse pas tout le monde et c'est assez logique que des développeurs qui apprécient leur langage qui ne le fait pas n'y trouvent pas un grand intérêt, mais c'est l'un des trucs que cherche à apporter la programmation orienté objet.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Écrire dans un mauvais endroit de la mémoire ça arrive facilement. Affirmer que ça n'arrive que parce que le développeur est un malade me semble être une façon de se cacher le problème. Soit c'est qu'il y a beaucoup de malade qui écrivent du C soit c'est un vrai sujet (j'ai regardé on est à plus de 300 CVE qui concernent des buffer overflow en 2023).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Après le C a ses propres faiblesses et n'est pas un langage parfait, loin s'en faut. Et il y a des langages mieux adaptées pour faire de la POO bien que le C permette de le faire raisonnablement bien.

Je réagis juste à l'assertion « la POO c'est bof, tu code bien en C c'est pareil ». Je pense que la POO a ses propres avantages (comme la programmation fonctionnel, impérative, logique, etc) et que c'est passer à côté de ce que tente d'apporter la POO que de cacher dans un « bien coder ». D'autant que bien coder en fonctionnel ou en POO peut être inversé, c'est pas simplement du bon sens. Quand tu utilise un modèle, comprendre ce qu'il tente d'apporter (et pourquoi) pour en voir les limites là où tu l'utilise ça me parait utile.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Après en C si tu as vraiment envie tu as toujours moyen de contourner ces limitations, mais là on tombe plus dans le programmeur qui veut faire n'importe quoi de manière pathologique qu'autre chose.

Oui enfin ça s'appelle un buffer overflow si je ne m'abuse, ça fait beaucoup de porteurs dans les locuteurs, non ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Au passage : MC/DC c'est seulement pour le niveau A de la DO178B (j'en ai fait 12 ans, c'est sur mes souvenirs). Pour niveau B et C la couverture complète suffit.

Le niveau B demande une couverture de décision ce qui est déjà au delà d'énormément de projets.
Le niveau C ne demande "que" une couverture de 100% des lignes.
À noter que les niveaux inférieurs sont fait pour de très faibles criticités (je le dis pour ceux qui lisent pas particulièrement pour toi).

À noter que même ça ne fait pas tout, Boeing a sorti de la qualité logiciel vraiment pas terrible (que ce soit pour le 737 max ou en aérospacial où la NASA a fini par faire leur propre audit de tout ce qu'a sorti Boeing).

Mais j'ai la faiblesse de partir du principe que les règles de codage sont respectées.

Oui enfin il existe des règles de codage pour empêcher les buffer overflow et il ne se passe pas plus de quelques jours sans qu'une nouvelle CVE en parle.

Et encore une fois, si tu as un code bien architecturé c'est facile à montrer en analyse statique du code (le seul accès à ta structure est effectivement via la fonction d'accès).

Il faut écrire une nouvelle règle pour chaque structure. C'est pas lourdingue ?

Encore une fois, les bouquins sur l'art de bien programmer en xxx ou avec le paradigme yyy sont aussi épais que ceux pour le C, donc je reste dubitatif sur le fait que ça facilite au final le boulot global d'écriture.

Pas sûr que cette métrique ai du sens.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est ce qu'on fait en avionique par exemple

Alors en avionique[^1] ils testent avec une couverture complète MC/DC, ça ne permet pas de garantir que tu ne fais pas de modification directe, mais ça assure que ce n'est pas grave si tu le fait. Avoir ça dans le langage permet de s'assurer de cette propriété bien plus facilement.

De la même façon que tu peut écrire un code multithread correct dans n'importe quel langage, mais que rust permet de s'assurer plus facilement que tu ne fais pas trop n'importe quoi.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis curieux de savoir s'il y a un moyen d'assurer l'encapsulation.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Quand on regarde la définition de haut niveau des objets : Ces objets ont un état interne et un comportement, qui leur permet d’interagir entre eux on voit très bien que c'est ce qu'on fait depuis toujours avec un langage fonctionnel (C pour ma part), en ayant une architecture/conception rigoureuse (et pas un plat de spaghetti).

Il me semble que tu ne peux pas garantir que l'état d'un objet (une structure j'imagine ?) soit cohérent. Si par exemple tu veut un objet qui représente une intervalle représenté par la valeur basse et la valeur haute (ouvert ou fermé ne change pas mon explication), tu aimerais pouvoir garantir que la borne basse est effectivement toujours plus petite que la borne haute. Ce genre d'invariant est garanti par l'immutabilité dans les langages fonctionnels et en objet par l'encapsulation (et tu vérifie à chaque modification que l'objet continue de respecter l'invariant). En C je ne vois pas comment tu fait. Ça n'est pas un sujet théorique.

Je peux complètement passer à côté de quelque chose au sujet de comment tu fais et tu pourra me rétorqué avec raison que des langages comme python cassent ce principe ce qui est vrai.

Alors certes un langage Objet facilitera ce travail, mais en théorie seulement quand je vois le nombre d'articles (et de bouquins) destinés à bien architecturer/concevoir les objets.

Ce n'est pas parce qu'il n'y a pas de silver bullet que tout est identique. Tout langage turing complet sera en mesure de produire une usine à gaz, est-ce que pour autant le shell, le C et l'haskell sont identique ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai du mal à ne pas raccrocher ça à :

Ceux qui ont pris tout le plat dans leur assiette, laissant les assiettes des autres vides, et qui ayant tout disent avec une bonne figure « Nous qui avons tout, nous sommes pour la paix ! », je sais ce que je dois leur crier à ceux-là : les premiers violents, les provocateurs, c’est vous !

Mais c'est bien sûr à René Dumont qu'il faut penser, il a théorisé tout ça dans les années 50-60.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll