totof2000 a écrit 1947 commentaires

Le prix Pulitzer (de la fiction) propose de très nombreux mauvais romans quand même ; c'est très politisé et souvent sans intérêt (et c'est de pire en pire d'ailleurs).

Du dis de manière un peu plus directe ce ue je voulais sous-entendre. En fait ce sont plus les raisons ui font qu'il soit passé à côté qui me font penser qu'il n'est pas si mauvais que ça. Comme tu le dis, c'est très politisé et je pense que le roman doit bousculer les idées du "jury" - et qu'il doit le faire de manière plutôt bonne - qui fait qu'il ne l'ait pas eu.

il est tellement osé, perché, absolument beau et indigeste…qu'on lui a refusé le prix.

Ne l'ayant pas lu, je ne peux le dire, mais en fait ce que tu dis confirme mon intuition. Perso, le fait qu'il n'ait pas eu le prix aurait plus tendance à me le faire lire qu'autre chose.

Si j’implémente la communication entre les 2 threads via des messages IQ, est-ce que vous pensez que ça serait trop complexe  ?

Personnellement j'utiliserais des moyens de communication légers entre threads/processus, et je sortirais l'artillerie XML/XMPP par dessus pour la communication entre machines.

quand je vois qu'il a failli obtenir le Pulitzer pour L’Arc-en-ciel mais le jury a estimé que c'était « illisible », « surécrit » et « obscène »

… déjà s'il a "failli" avoir le Pulitzer poir l'Arc-en-ciel, c'est que c'est pas si mal que ça. Et d'un autre côté je me méfie des gens qui attribuent des bons points à telle ou telle oeuvre : on peut avoir un film, un livre, ou de la musque qui n'obtient pas le prix machintruc parce que le prix en question a ses propres filtres, mais ça n'en fait pas our autant des mauvaises oeuvres. La meilleure chose que tu puisses faire à mon avis c'est de te faire ton propre avis.

… mais pour un jeu, mettre du XMPP ça pourrait être lourd (je pense notamment aux étapes de serialisation/deserialisation XML).

Il ne faut pas oublier que XML, à la base, c'est un format commun pour que des applications qui tournent sur des systèmes avec format incompatibles puissent lire/écrire des docments - ou communiquer ensemble. LA tu es dans la communication inter-thread/inter-processus sur la même machine à priori, donc j'ai l'impression qu'un bon vieux format binaire que les threads et les processus pourront lire (via la même lib) fera l'affaire. Au pire voir s'il n'existe pas un bus local style dbus mais en plus léger qui pourrait faire l'affaire. A moins qu'a terme tu prévois de faire tourner tes processus sur des machines différentes (mais completement différentes en terme d'archi) et dans ce cas XML pourrait être utile..

C'est tout de même assez standard aujourd'hui.

Non, en tout cas pas pour ceux qui ne font que très peu de vidéo (et j'en faiss partie).

Ne pas le connaitre est entendable mais fais partie du standard qu'une description ici n'est pas forcément des plus pertinente

Ce genre de commentaire pédant me donne envie de répondre assez sechement mais je m'abstiendrai par respect des autres utilisateurs.

Je sais, je pourrais (et j'irai certainement ) chercher sur internet ou demander à une IA … mais le journal aurait gagné en lisibilité à employer un terme acccessible au plus grand nombre plutôt que de supposer que tout le monde sait ce que c'est, ou à expliquer le terme dès le début.

D'un autre côté, vu leur taille, est-e qu'il est possible d'avoir un environnement de test qui simule tous les cas possibles et imaginables rencontrés sur un environnement de prod ? Je pense que ça doit être bien diffcicile. Et même si c'est faisable, il faut penser justement à tous ces cas possible et les simuler.

Autrement dit, des tests c'est bien, mais les tests ne sont pas la garantie absolue de ne jamais rencontrer de bugs. On réduit juste la probabilité de les rencontrer.

C'est clair … Puis penser qu'on va savoir maîtriser un BSD quelconque juste parce qu'on ait faire du Linux, et ensuitec conclure que BSD c'est le bordel, c'est un peu présomptueux je trouve. les BSD ont un tas d'avantages par rapport à Linux (notamment le fait que l'on a un ensemble kernel + userland cohérent), mais un de leurs "pont faibles" pour des personnes qui ne le connaissent pas, c'est que c'est moins "user frienly" d'une part, et d'autre part, beaucoup d'outils fait pour Linux ne tournent pas (ou mal) sous les xBSD : ce n'est pas la faute à BSD, c'est juste que les devs/éditeurs ne veulent plus faire de portable (on ralait de la même façon il y a 15-20 ans sur les softs Windows Only qui ne tournaient pas sous Linux).

On passe de protocoles standardisé (imap, etc … ) a des trucs specifiques au fournisseur de services. JE suis le seul que ça inquiete ?

Bof …. Quand on se pose pas de question par rapport à l'usage qu'on fait de sa machine avant d'installer un système, on en arrive là.

Pour ma part je prévois toujours d'installer FreeBSD sur mon PC portable (il faut que j'achete un ssd et que je prenne le temps de réorganiser mes données ), mais je garderai un Linux pour le jeu (steam) parce que je sais très bien qu'à la base FreeBSD ne le permet pas, même s'il existe un port pour ça.

Le titre devrait être plutôt "FreeBSD comme alternative au chaos Linux pour remplacer Windows"

Dans le fait qu'une grosse lib, a plus de chances d'avoir des bugs que plusieurs petites lib, et est plus chiant à maintenir, est-ce que ça un rapport avec les attaques par supply-chaines ? toujours pas.

Il y a quand même un petit avantage a avoir une lib qui fait beaucoup plutot que plusieurs petites libs qui font des petites choses : la confiance. Il est plus facile de faire confiance à une lib qui est maintenu par une équipe identifiée, même si cette lib fait plein de choses, que de faire confiance à un tas de petites libs éparpillées non ?

Si tu recodes coreutils, qui globalement n'est pas fait pour être utilisé en réseaux, et où la majorité des failles mémoire aussi graves soit elles seront difficilement exploitables, recoder en Rust pour de la sécurité, reste questionnable.

Bof .. Une elevation de privilege du à une erreur dez gestion de mémoire … c'est pas anodin non plus.

Et si on assume que Rust est plus vulnérable au supply-chain attaque, alors ça reste plutôt négatif en terme d'impact sécuritaire.

C'est là ou moi (et d'autres) ne sommes pas d'accord. Dans l'absolu Rust n'est pas plus vulnérables au supply chain attack que n'importe quelle autre langage. LA différence avec C c'est que Rust est plus ancien, et qu'on a pas encore un ecosysteme de libs matures permettant de faire aussi bien que C en terme d'attaque par supply chain. C'est de mon point de vue la seule différence aujourd'hui (mais je peux me tromper).

Bof …

En C t'a souvent des libs à tout faire, et rien que SDL, t'a des htable, des threads, une gestion du filesystem.

Nul doute qu'avec l'essor de Rust on en vienne à avoir ce même genre de lib à tout faire.

Tu peux rajouter des lib métier comme FFMpeg, json-c ou 2/3 autres.
Mais tu dépasses rarement la 10éne de libs.

Bof … pas convaincu : tu as une dizaine de lib directe mais des dépendances indirectes t'en a aussi. J'ai bien souvent été surpris des trucs qu'installait un apt-get pour un simple utilitaire en ligne de commande.

En fait, mis à part le fait que d'un côté il y a des tas de libs à tout faire qu'il n'y aap as de l'autre, je ne vois pas de grande différence entre les deux mondes : il y a des dépendances, et il est nécessaire de chaque côté d'e s'assurer que les dépendances utilisées soient fiables. Ensuite on se retrouve à gérer d'un côté des dépendances basées sur des libs dynamiques, et de l'autre des dépendances sur des libs statiques. L'un n'est pas mieux que l'autre.

À un moment donné faut arrêter de considérer la gestion mémoire comme le problème principal des failles de sécurité

A un moment donné il faut arrêter de prendre les gens de haut juste pour se la ramener et cesser de faire dire aux gens ce qu'ils n'ont pas dit. Ou ai-je dit que la gestion mémoire est le problème principal des failles de sécurité  ?

Oui c'en est une mais on peut faire des conneries dans tous les langages.

Oui mais si le compilo t'évite d'en faire ou te le signale c'est quand même un plus non négligeable. D'autant plus que la gestion mémoire n'est peut-être pas la cause principale des failles de sécurité (comme le démontre la faille de sudo-rs), mais ça reste quand même une grosse source de failles de sécu (30% => environs 1/3 c'est pas négligeable).

De plus ma question tient justement compte du fait que les failles de sécu ne sont pas la seule problématique lié à la sécurité et le fait de ne pas avoir tout à réécrire pourrait justement permettre de corriger ces problèmes sans pour autant en introduire de nouveaux (ou limiter l'introduction de nouveaux problèmes) en limitant la réécriture du code au strict nécessaire.

Le C n'évoluera jamais dans le sens de Rust parce que c'est un paradigme entier à revoir.

C'est justement pour avoir ce genre d'avis que je pose la question : la réponse aurait pu être donnée sans condescendance.

En revanche, les sanitizers et analyse syntaxique aident déjà énormément au développement et le reste est bien sûr d'assurer des tests de non regression massive.

Si c'était suffisant, on n'aurait pas 30% de problèmes de sécurité liés à la gestion mémoire, icrosoft ne s'intéresserait pas à Rust, et d'ailleurs Rust n'aurait pas pris. Si les devs s'intéressent à Rust c'est justement parce qu'il répond à un besoin.

Est-ce qu'il serait possiblede faire évoluer le C pour qu'il integre un système de contrôle de mémoire "à la rust", tout en gardant une certaine compatibilité avec le code actuellement écrit ? Est-ce qu'il y a des discussions/recherches/évolutions potentielles dans ce sens ? Est-ce que ça vaudrait le coup ?

Disons que …. même si c'est gênant, le jour ou Donald Trump décidera d'interdire l'accès aux services numériques américains d'une association qui le dérange

J'ai omis un élément dans ma phrase (un ctrl+z de trop quand j'ai voulu reformuler) :

Disons que …. même si c'est gênant, le jour ou Donald Trump décidera d'interdire l'accès aux services numériques américains d'une association ou d'une petite entreprise qui le dérange

Et pour Systemd, les gens qui disent ça sont toujours des gens qui ne l'utilisent pas vraiment. Parce que comparer systemd-timesyncd avec ntpd, ça prouve juste que tu n'as rien compris.

Oui c'est ça … je n'utilise pas systemd. J'aimerais bien ne pas l'utiliser justement. Au minimum j'aimerais bien virer les trucs qui entrent en conflit avec des alternatives qui me plaisent mieux et qui sont bien souvent plus completes : mais je ne peux pas, et c'est surtout ça qui me gène.

Disons que …. même si c'est gênant, le jour ou Donald Trump décidera d'interdire l'accès aux services numériques américains d'une association qui le dérange, l'impact sera moins important que s'il interdit l'accès aux organismes d'état, banques, telecom ou autres grosses entreprises sensibles du genre. Et il est capable de faire ce genre de choses pour tout un pays. Après dans le monde associatif il y a quand même des associations qu'on pourrait qualifier de "sensibles" telles que celles qui soccupent des tutelles ou des curatelles : ça pourrait gêner pas mal de monde.

Les entreprises ou administrations françaises continuent à pousser leurs données vers les fournisseurs clouds américains …

Il devrait être possible de remonter à l'origine de chaque ligne de code.

N'importe quoi …. Faut vraiment rien comprendre au code pour écrire ça. C'est comme s'il disait qu'il devrait être possible de remonter à l'origine de chaque note d'un morceau de musique, ou chaque accord, ou de chaque mot d'une phrase.

Une ligne de code ça ne représente rien en soi. Si j'écris du code faudrait que je puisse remonter à la source de ça ?

for( i=0; i<n, i++) {

ou

int x=0;

A une époque les PDF avec formulaire interactif ne s'ouvraient qu'avec adobe Acrobat Reader Je ne sais pas si les autres outils se sont adaptés. Mais dans l'absolu un PDF c'est quand même cesné être un document immuable non ? Ils devraient plutôt permettre de saisir les données avant de générer le PDF cible lorsque tu le télécharge).

Il est trop tard à mon avis …. Python va perdre du terrain sur pas mal de trucs au profit de go qui est bien plus facilement packageable, typé, plus rapide, gère nativement le parallelisme et la concurrence, et n'a pas besoin de cette saleté de virtualenv. En Ci/Cd c'est juste la copie d'un exécutable ou une installation via l'outil de build/packaging go là ou les devs python font souvent du copy dégueulasse vers leur image docker au lieu de packager proprement leur truc (un pip install est bien plus propre qu'un copy de mon point de vue, et rend le truc installable indépendamment du contexte docker ou autre).

Il n'y a vraiment pas besoin d'outils additionnels (uv, virtualenv, bibliothèques externes, etc.) pour réaliser l'équivalent en Python.

Si tu n'utilises pas de lib externe et que tu veux un truc one shot, effectivement c'est faisable. Python est plutôt bon pour faire du prototype rapide. Mais ès que tu commence à avoir des dépendances et que tu veux packager, tu arrives vite à l'enfer.

Gros par environnement virtuel. Si tu groupes plusieurs petits programmes dans un même venv, tu mutualises une partie de la charge en python. Tu n'as pas ce choix (même s'il n'est pas parfait) en Go il me semble ?

En go tu crée un utilitaire avec des sous commandes (exemple terraform init, terraform plan, terraform apply). On retrouve ce pattern également avec git, ou d'autres utilitaires python.

Perso pour faire du CI CD je prefere largement du go que du python (et pas que pour ça d'ailleurs, mais c'est un des trucs qui me gavent en python).

Au final ce qu'il faudrait c'est un langage de haut niveau compilable vers des petits exécutables pour des programmes courts (avec élagage des dépendances par exemple).

C'est aussi un truc auquel j'ai déjà rêvé..

Mais sinon awk c'est très bien aussi en effet pour de la manipulation de texte (et sed, et uniq, et sort, et wc, etc…)

Yes, ça évite souvent de sortir la massue pour écraser un moustique

Si on joue à qui a la plus grosse (taille), je pense que Python dépasse go haut la main. Tu as le python core + lib standard, tout ce que tu installes via pip et ton code à toi. Pas sûr que Python prenne moins de place pour le coup.