reno a écrit 3879 commentaires

Je n'ai pas dit que changer le code était simple, j'étais juste en désaccord avec le fait qu'avoir un analyseur réseau était forcément "par nature" unsafe.
C'est juste qu'au début la conception a été faite sans prendre en compte la sécurité (forcément c'est + simple) et plus le projet grandis plus c'est difficile de la rajouter et comme personne ne veut payé pour avoir des outils sécurisé..

Par nature (analyse de plus de 1500 protocoles et écoute du réseau), Wireshark est souvent concerné par des alertes sécurité.

Hum, par "nature" ça se discute: il ne serait pas possible de séparer le process qui écoute sur l'interface du process qui analyse le traffic et de sandboxer ce dernier?

Après, il faut que le process qui analyse le traffic communique avec l'IHM..

A ce sujet:

https://www.google.com/amp/s/arcan-fe.com/2017/12/24/crash-resilient-wayland-co

Après j'avoue que je ne comprends pas grand chose à Arcan et que je n'aime pas Lua..

Ah et puis, dans le genre bien pour avoir des utilisateurs, on peut se déclarer comme étant une distribution pour les utilisateurs normaux "we make an operating system and we make it easy for you do useful stuff with it" tout en installant la version alpha d'un environnement de bureau (KDE4.0) sans avertissement particulier, sympa pour les dev de KDE ET pour les utilisateurs!

Certes mais Wayland donne vraiment l'impression d'avoir été conçu pour l'embarqué avec des fonctionnalités minimales qui doivent ensuite être dupliquées dans chaque compositeur pour obtenir une API vraiment adaptée au desktop..

Qui dit implémentation multiples, dit bugs d'interopérabilité bien sûr..

A long terme, ça va se décanter, mais bon à très long terme, Wayland n'a même pas encore d'implémentation native "saine" d'export DISPLAY, ça passe principalement par X11 à l'heure actuelle..

En plus avec leur foutue insistance avec la décoration des fenêtres coté clients, ils sont (ont été?) vraiment lourd: on fait comment pour avoir une interface utilisateur "sure" à la Qubes OS en CSD (*)?

*: dans Qubes OS, on peut mettre les applications dans plusieurs "zones" et la couleur des bords des fenêtres indique la zone utilisée, ça évite qu'une application puisse se faire passer "visuellement" pour une application d'une autre zone.

Une fonctionnalité de base dans un IDE c'est "aller a la definition": pointer sur une fonction ou un #include puis faire Ctrl+Click a la souris et ça ouvre un onglet avec le fichier correspondant: indispensable dans les gros projets qui ont BEAUCOUP de fichier (les aller/retour éditeur->ag->éditeur deviennent rapidement très pénible).

Réaliser la même chose avec vim (soit en utilisant gvim+ctags, soit tmux+ctags) est probablement possible mais à chaque fois que j'ai essayé ça n'a pas bien marché (et j'y ai déjà passé plusieurs heures) alors que vscode le fait "de base".

Pour ce qui est de garder l'état, bah VScode aussi garde la liste des fichiers ouverts.

6- Savoir se défendre , malgré tout

J'ai été ceinture noire de judo 2ème dan: mon point de vue pour se défendre?

1) donner son portefeuille
La perte de quelque centaines d'Euros ne va rien changer à ta vie, alors qu'une mauvaise blessure si
(mon père me parlait d'un ami jujituska chauffeur de taxi qui est mort en voulant se défendre..)!

2) courir vite si 1) pas applicable

3) si 1) et 2) ne sont pas applicables, alors se défendre, en revenant à 2) si possible: si tu es coincé et que tu ne peux pas courir, se servir de son art martial pour se décoincer puis courir, pas continuer le combat parce que tu l'as commencé, enfin sauf si tu ne peux pas te sauver bien sûr..

Et de mon point de vue, l’aïkido n'est pas un art martial (trop stylisé, dépend trop de la coopération de l'attaquant), le judo a peine plus (dépend trop d'avoir un kimono: avec beaucoup de mouvement en tenue "normale" tu te retrouve juste a déchirer le tee-shirt.. Et si tu essaye d’attraper la "garde" comme dans un combat de judo classique, ça va te faire tout drôle quand le gars en face te donne un coup de boule..).

Dans une société de plus en plus violente

Pas sur du tout que ça soit vrai ça!

Par contre tout les autres points, tout à fait d'accord: pratiquer un art "martial" est un très bon moyen de se maintenir en forme, dans une bonne ambiance et pas aussi violente qu'on le pense (en tout cas pas plus que de faire du football!)

CLion fait partie des IDE que j'ai essayé : pas terrible, indexation longue, lourd (ecran blanc pendant la compilation) et s'il trouve 7n fichier C++ qui ne fait pas partie du projet, il ne fournit plus aucune intelligence.
VS code, on peut lui fournir une arborescence pas un fichier cmake: quand il y a plusieurs cmake c'est + pratique.

Note que l'absence de TLB dans le ForwardCom (*) est quand même un peu "inquiétante" dans le sens de la compatibilité Linux, comme le x86 l'a montré la compatibilité logiciel est reine donc si le ForwardCom ou le Mill ne sont pas "bien" compatibles avec Linux alors ils sont morts, quelque soient leurs avantages..

*: comme d'ailleurs dans le Mill: https://en.wikipedia.org/wiki/Mill_architecture

Je comprend pas vraiment l'argument de la sécurité, en quoi le RISC-V apporterait ou non de la sécurité ?

Et bien l'ISA du CPU peut aider pour la détection de débordement entier comme le fait le MIPS mais pas le RISC-V, la détection de dépassement d'index de tableau, etc.
Si tu veux en savoir plus va lire le lien que j'avais donné.

Mais le seuil intérêt du RISC-V est d'avoir une ISA ouverte, l'ISA en elle même est juste un CPU "de base" qui n'apporte presque aucun progrès technique, dommage..

RISC-V c'est bien, mouis, c'est à peu de chose près un clone du MIPS, ISA qui ne date pas d'hier..
Et d'ailleurs MIPS va devenir opensource..

Le RISC-V n'apporte rien coté sécurité par exemple, un CPU comme https://forwardcom.info/ ça aurait quand même + d'intérêt.

Il y a une fille dans les contributeurs de Weboob (enfin au moins une je n'ai pas regardé bien attentivement), elle n'a pas dut recevoir le mémo comme quoi il fallait être choqué par ce projet.

? Euh, tu parles de quoi?

pourrais-tu en dire plus sur zig ?

J'ai envoyé le lien sur zig, mais voici un lien plus précis https://andrewkelley.me/post/intro-to-zig.html

c'était une blague ?

Il ne s'agit en aucun cas d'un langage "humoristique": son concepteur a arrêté son travail pour se consacrer à ce language..

De toute manière au niveau langage, un remplaçant du C ça serait plutôt Zig que Go (qui a un GC) ou Rust (qui est un langage très complexe qui concurrence plutôt le C++ que le C).

Il y a Jai qui devrait être intéressant aussi vu l'expertise de son concepteur mais bon ça il faut encore attendre pour avoir du concret.

Je ne la respecte pas et pour le moment on ne m'a rien dit mais bon si je me fais taper sur les doigts a cause de ça je la respecterai..

Je plussoie, dans mon travail on avait comme règle de codage que les membres commençaient par m_ puis ça a changé on ne devait plus utilisé m_ (merci Oncle Bob!) .. 15j plus tard j'ai perdu ~2h a ne pas trouver un bug d'une collègue qu'elle n'aurait pas faite si on avait gardé l'ancienne règle de codage (ou qui m'aurait crevé les yeux si elle avait fait l'erreur quand même)
--> perso: fuck, la nouvelle règle de codage (et oui, on a gardé la nouvelle règle même quand j'ai rapporté le problème).

Pour le futur peut-être mais ma boite a du mal à trouver des devs C++ alors que Rust pour trouver du travail..

L'aspect innovant de ce point n'est pas remis en cause, je pense.

Non, mais l'utilisabilité de la chose est par contre encore en question, j'attends de voir une API de GUI en Rust..

Tu retardes l'affaire des bibliothèque standard est morte depuis longtemps.

Pourquoi le Rust plutôt que le D ? Le Rust est plus bas niveau et ne nécessite pas de ramasse-miettes

Toi tu as lu, mon message un peu vite: fait une recherche sur DasBetterC, mais bien sûr si tu utilise D sans le ramasse miette tu as les mêmes problèmes que le C/C++ au niveau gestion mémoire.

il a un système d'abstraction beaucoup plus riche, avec des "sum types", […] avec des abstractions plus agréables à utiliser.

Hum, quelle est la différence entre un "sum type" et un "Variant record" en Ada?
Pour les abstractions plus agréable a utiliser, je n'en suis pas si sûr: visiblement faire un GUI en Rust ça a l'air bien pénible.
Et je pense quand même que Rust a un ramp-up important: quand je regarde un programme Ada j'ai l'impression de comprendre tout, quand je regarde un programme Rust ça fait "soupe de caractères" bon pas autant que le Perl mais pas loin..

Mouai, c'est un peu court pourquoi Rust plutôt qu'Ada ou D?

Franchement la maturité d'Ada par rapport à celle de Rust..
Et D est probablement beaucoup + facile comme transition depuis le C++ que Rust, il y a même un mode DasBetterC qui évite d'utiliser le GC (mais qui diminue la sécurité comme le C++ et empèche l'utilisation de certaines librairies).

Je ne pense pas qu'on puisse dire que c'est un problème ARM, c'est un problème de l'embarqué "non-PC".
Si tu utilise un MIPS, un PPC, un RISC-V ou autre, tu as exactement le même problème..

Quand on pense au nombre de téléphone Android non sécurisé c'est vraiment surprenant qu'il n'y ai pas encore eu un malware qui ai affecté des millions de téléphones..

Cmake est un méta système de build donc quand tu as un problème il faut regarder les Makefile et remonter.

Si tu as besoin de la portabilité OK, mais au travail on utilise CMake alors qu'on est cible seulement Linux et là rajouter une couche supplémentaire je pense que ça complique plus la vie qu'autre chose.
En ce moment, je suis en train d'essayer de comprendre pourquoi les cibles sont compilés dans un ordre différent d'une compilation à l'autre, je galère..

Certes construire un bon GNU Makefile demande pas mal d'effort mais en partant d'un Makefile 'modèle' on y arrive (enfin il faut quand même trouver le 'bon' modèle).

Pour ce qui est de la critique "Par exemple, si j'ajoute une option qui concerne l'édition des liens, celle-ci ne sera pas refaite par défaut." et bien ajouter une dépendance qui dis que si le Makefile est + récent que les target tu refais tout ne me parait pas compliqué.