Car c'est beau aussi la théorie mais il faut constater en pratique, les soucis de mémoire en C ce n'est pas juste de la théorie, c'est ce qu'on mesure en vrai malgré l'évolution des bonnes pratiques, de l'outillage, etc.
Si pour toi la pratique, c'est de regarder le nombre de failles de sécurité, sans se demander quel point ces programmes en questions sont utilisé, et à quels points il y a un enjeu a trouver des failles de sécurité dans les dits programme.
Dans ce cas, je rentre dans ton jeu :
Seul Open BSD est sécure.
Mais l'écosystème de C et C++ ce sont aussi des milliers de projets différents avec encore plus de développeurs derrière qu'on ne connaît pas.
Oui, mais concrètement, tu prends SDL, glib, glibc, openssl.
T'a le gros des dépendances utilisé, par la plupart des projets C.
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.
En C t'a souvent des libs à tout faire, et rien que SDL, t'a des htable, des threads, une gestion du filesystem.
glibc, ta queue.h de BSD, hsearch_r pour les htable et regex.h.
Ça fait, que tu te retrouves avec des projets comme FAudio qui ne se base que sur SDL, et même pas la libc (même si indirectement si).
En Rust pour avoir l'intégralité des fonctionnalités de SDL, tu vas avec 2/3 libs pour chaque élèvement.
Si tu considères que chaque libs maintenues pas une personne différente est un vecteur d'attaque pour des supply-chaines attaques, Rust est juste plus vulnérable.
Bref, des attaques par supply chain tu peux en avoir partout dans ces écosystèmes techniquement, le C n'apporte aucune garantie de ce côté.
Bof, c'est comme dire que Rust n'apporte pas de garantie sur la gestion de mémoire, car tu peu faire que du code unsafe.
Cargo pousse à utiliser beaucoup de lib, make/cmake pousse à rester conservateur sur le nombre de lib utilisé, quitte à recoder des choses que tu pourrais trouver en libs.
Ça rajoute des chances de rajouter ces bugs, mais enlevés des chances de tomber sur une lib corrompue.
Et les lib dynamique sont une garantie que si une lib casse, on n'a pas besoins de rebuild ton binaire pour fix ta faille de sécu.
ok, mais l'avantage des lib dynamique, ce n'est pas d'éviter les faille de sécurité au moment du build, c'est de les éviter après, quand t'a wget ou pacman -S ton binaire, et que tu n'as pas fait gaffe que dans les lib statique utilisé, t'en a une de cassée.
Avec une lib dynamique, bah une mise à jour de la lib va réparer le problème, avec une lib statique, il va falloir penser à mettre à jour tous tes binaires impactés. (et si c'est un package AUR, bah, il faut espérer qu'il y a eu une MAJ)
Et puis quand ta distribution ne package pas le logiciel dont tu as besoin, en C ou C++, tu te retrouves avec… ben rien du tout pour faire le suivi, il faut gérer ça soi-même. Et de mon expérience, ça arrive relativement souvent.
C'est vrai, mais c'est aussi la raison pour lesquels les projets C/C++ sont souvent plus conservateurs sur le nombre de libs, si t'est pas sûr que ta lib est distribué de partout, bah, tu vas devoir la build toi-même, et généralement, tu préfères éviter ça.
On voit qu'elle a travaillé sur Apple pour valve.
Si on regarde ces contributions, elle a aussi beaucoup travaillé sur FEX.
À se demander si valve n'a pas utilisé Asahi comme machine de tests pour leur casque VR.
parce que je ne pense pas que les utilisateurs steam Asahi soit assez nombreux pour justifier du temps de dev dessus, par contre, il y a assez d'utilisateurs pour avoir un certain nombre de retours utilisateurs sur FEX, et améliorer leur couche de compatibilité avant que le casque ne sorte.
Et un vieux projet en C, avec make, utilise des lib dynamique, donc mise-a-jour par les mainteneurs de ta distribution Linux, ce qui les rend très différents de PHP et ces lib statique.
Ça reste un problème avec les single-header librairies, mais vu qu'il faut les gérer soi-même, bah t'en utilise juste moins que des lib que tu rajoutes dans ton yaml, et qui te tire 15 dépendances, et reste une pratique moins courent que pkg-config --libs
Ce que tu ne comprends pas dans le propos, c'est que si tu prends un programme C donné et que tu le convertis en Rust
C'est absolument faux, tu convertis du code C en Rust, tu te retrouves avec du code Rust 100% unsafe.
Les pratique de codage de Rust et C sont différents, donc les algorithmes utilisés en C ne sont pas forcément simples à convertir en Rust safe.
Tu ne convertis pas un programme C en Rust, tu le recodes, avec des pratiques de codages différentes, et des dépendances en plus, beaucoup.
GNU coreutils, c'est principalement deux dépendances : glibc et GNUlib.
uutils, c'est ça : https://deps.rs/repo/github/uutils/coreutils
Si tu additionnes uu_core et coreutils, t'en a 14.
Et si tu prends uu_touch, tu en rajoutes une qui a elle-même 10 dépendances.
Sauf que les attaques par supply chain sont malgré tout bien plus rares et concernent aussi les applications C et C++.
Sauf que les attaques mémoire concernent aussi Rust…
Si les attaques par supply chaine sont rares, c'est aussi peu être, car C se repose sur moins de dépendances que du Rust ou JS.
XZ, ça a été un gros travaille d'ingénierie sociale pour choisir l'une des rares libs C utilisée un peu partout, et peu maintenues.
En Rust des lib comme XZ utilisé un peu partout, tu n'en as pas 10 comme en C, mais plus 300.
Aussi, entre une erreur mémoire dans un programme comme ls, qui de toutes manières demande d'avoir accès à ton ordi en physique pour être exploité, et un bout de code ajouté par une dépendance derrière ton dos, qui va te modifier sshd_config à l'init de ls si tu es en root.
Bah, je prends 30% de chances d'erreur mémoire à 0.5% de chances de supply chaine attaque.
Ma comparaison avec npm, c'est car cargo ressemble plus à npm que make, donc ma remarque, c'est que cargo ajoute aussi une surface d'attaque que make n'a pas.
Le nombre de vulnérabilités n'est pas forcément une valeur intéressante parce que la base d'utilisation de programme en C, et les enjeux a introduire des portes dérobées sont plus grandes que ceux pour leur équivalent en Rust.
En gros si libc/coreutils/curl devraient se voir remplacer par du rust, on va surement enlevé 29% de faille de sécurités lié à la mémoire, par contre le pourcentage de CVE lier à des attaque par supply chain, il va augmenter, mais vu que des coreutils qui utilise cargos pour build, ça reste quelques chose de marginal aujourd'hui, on ne peu pas prédire l'impact que ça auras.
Une lib dynamique packager par APT donc un mainteneur de ta distro (donc fix sur un apt update), c'est la même chose qu'une lib static tirer par une autre dépendance que tu as utilisé, et maintenue par 1/4 de personnes qui sait même pas que ça lib est utilisé sur ta distro ?
Parce que en Rust la majorité de tes dépendances sont statiques, et tu peux avoir plusieurs fois la même, mais a des versions diférents dans le même projet. (ce qui arrive à peu près jamais en C).
Et si ta dépendance casse, bah, tu gardes la faille tant que ton binaire n'a pas étais packager.
Aussi en C t'est en général beaucoup plus minimaliste qu'en rust sur les dépendances utilisées.
Car cargo est meilleur que make pour récupérer tes lib et faire en sorte que ça marche, sans rebuild la lib toi même si elle n'est pas packager partout.
Donc cargo est meilleur pour te prendre pleins de dépendances que tu sais même pas que tu les utilises, et qui sont maintenus par personnes.
C'est quand même 33% des failles de sécurité rapportées. Ce n'est pas un détail et je ne crois pas qu'une classe d'erreur passe devant en fait.
En même temps, la majorité de la base de ton Linux est en C/C++.
Vu que C/C++ son assez vulnérables aux erreurs mémoire, bah c'est la que les gents cherches les vulnérabilités.
Tu prends un autre langage beaucoup utiliser comme JavaScript, on a peu d'erreurs mémoire, mais une armée d'attaque par chaines de dépendances.
Rust (comme open BSD) restent pour l'instant assez niches (on n'a pas des curl/coreutils/libc utilisé partout en rust), Rust se retrouverait à la place de C, il y aurait surement moins d'erreurs mémoire, mais c'est aussi possible qu'il y ait plus d'erreurs par supply chaines.
Parce que cargo ressemble beaucoup plus à npm qu'à make.
Aussi, Rust est tellement vendu comme langage sécurisé par Default, que les développeurs preuves faire moins attentions aux failles de sécurité, en se cachant derrière ce faux sentiment de sécurité qu'offre le langage.
Pas vraiment d'accord, Hans Reiser aurait pu coder/maintenir sont filisystem depuis sa cellule, le monde de Linux serait surement mieux.
Après, on parle de quoi ? garder des personnes problématiques en position dominante ou juste dans un projet ?
Problématique lier à la position exercé ou non ?
Par contre 5mn à lire le site de l'auteur, et on peut voir à quel point il est problématique, mais ces lib single file, pour faire du jeu vidéo, ont l'air vraiment qualitatif.
Ton pote vient d'installer Windows Vista, et te monte tous les nouveaux effets graphiques, rien à foutre, toi t'a gnome 2 avec compiz, les fenêtres qui brulent, et le desktop cube !
Mais en général, "va voir dans le code", c'est pénible quand j'essaie d'utiliser le code de quelqu'un d'autre, qu'il n'y a aucune info sur ce que fait chaque fichier et dossier à part son nom, et que c'est écrit dans un langage de programmation que je ne connaìt pas.
Il n'y a pas longtemps, j'ai essayé d'intégrer kuroko a un projet perso, en tant que moteur de scripting.
Et si la doc explique comment appeler kuroko, pour intégrer tes struct C dans kuroko, c'est du gros RTFS, et peu être que ça aurais été plus simple avec une doc.
Mais maintenant que j'ai réussi à tout faire marcher comme je veux, est-ce qu'il n'est pas normal que mon syndrome de Stockholm, me force à dire que la documentation ne sert à rien, et à regarder avec mépris ce qui la demande ?
de la même manière que si on aime le fromage, on méprisse ce qui mange du kiri.
Et sinon pour revenir sur le sujet principal du lien, la pizza, la pizza historiquement, c'est le plat du pauvre, qui consiste à mettre les restes sur une pâte à pains, hors l'ananas, c'est un truc que l'on trouve pour pas cher dans un supermarché, ou t'a facilement une boite d'ananas en jus qui reste chez toi.
Alors que d'autre ingrédient comme la burrata ou le jambon à la truffe, eux, ne sont pas censés être dans la catégorie plat du pauvre.
Donc la truffe et la burrata, sont des trahisons bien plus grave que l'ananas à l'esprit de la pizza.
Non, la documentation, c'est chiant, ça ne sert à rien si tu peux aller dans le code directement.
C'est un peu plus dur en bouche que la documentation, mais on défend vraiment le babybel face à un bon vieux maroilles ici ?
Alors que l'ananas sur la pizza, c'est le petit plus qui est corolaire au noyau, mais pas directement à l'intérieur du fruit.
Oui et non, quand tu fais un nouveau projet, tu passes ton temps à le casser avant d'avoir une API stable.
La personne derrière le code, a clairement l'air d'être dans l'idée d'amélioré quitte à casser, ce qui ne va forcément pas plaire aux mainteneurs de xorg.
Je l'ai trouvé pas mal, il explique que le mec qui a fork est le plus gros contributeur de x11 de 2024, donc il a une certaine experiance avec X11.
Par contre, beaucoup de ses contributions ne sont pas forcément appréciées, car il a tendance à casser les choses, dont l'ABI.
À part la politique, il y avait une grosse friction entre la personne qui a fait le fork, et les gents derrière X11, c'est que la personne derrière le fork veut améliore X11, quitte à casser des choses, alors que la majorité des dev et mainteneur de X11, préfère essayer de garder un code stable.
Eh, pour "ne maîtrise pas les bases de C.", la PR est clairement faite par une personne qui n'est pas le codeur principal.
Pour le coup, j'ai aussi zieuté les commits, et il y a énormément de commits avec une seule ligne de code, qui pourrait être regroupé en un seul commit.
Ceci dit, en poussant un peu, il y a l'air d'avoir des commits plus conséquent.
Le fork est clairement fait par une personne réactionnaire, par contre pour le code, il a l'air de changer plains de truc, a un commit tree, qui a l'air un peu ma-tu-vue, mais je suis incapable de savoir s'il va réussir à faire quelques chose en quelques coups d'œils sur son code.
Le fait qu'il ait cassé les claviers peut être une preuve d'incompétence, comme juste l'un des symptômes du fait qu'il fasse un gros refactoring.
Pour le coup, les containers ça utilise beaucoup les cgroups, qui ne sont pas des appels système, mais un filesystem. (que tu manipules comme des fichiers)
Donc ce n'est pas que les appels systèmes qui peuvent poser problèmes.
Aussi les appelle système, c'est souvent juste des point d'entrées vers d'autre fonction du kernel, donc rarement le code même des appels système qui pose problèmes.
Après ça ne change pas grand-chose au raisonnement ceci dit.
Ceci dit, si on est sur un compte de point d'entrée sur les intel, t'a plusieurs milliers d'instructions, à côté de ça les 400 syscall de linux paraissent bien peu.
Surtout que ça inclut les getuid et autre, qui ont peu de chance de poser problèmes.
Si ce que tu veux faire tourner est non trivial (ex: ffmpeg) alors tu atteris au final avec une liste de system calls à permettre qui est pas mal longue, qui contient des trucs assez dangeureux, et tu te retrouves avec autant d'interfaces pour entrer dans ce gros spaghettis de code C qu'est le Kernel.
Alors que si tu fais de la virtualisation, alors tu atterris au final avec une liste d'instructions CPU à permettre qui est pas mal longue, qui contient des trucs assez dangereux, et tu te retrouves avec autant d'interfaces pour entrer dans ce gros spaghetti d'instruction set qu'est Intel.
Mail le TLDW, serait, que :
- Des palestiniens et israélien, il y en a beaucoup qui on immigrait partout dans le monde.
- Conflit colonial, ce qui touche différents affects, et est assez unique.
- Ça fait partie des luttes de la gauche depuis pas mal de temps.
Et tu peux rajouter à ça l'asymétrie de traitement que tu as dans les médias/compétition internationale entre la Russie et Israël. (par exemple l'eurovision)
Vous connaissez des influenceurs de droite sur Twitch ?
Bof, Sadoche, il n'est pas de gauche à ce que je sache.
Mais après des contenus politiques de droite sur Twitch, je n'en connais effectivement pas, mais peu être que si la gauche est présent sur twitch, c'est aussi, car elle répond à une demande, que l'on ne trouve pas dans les médias classiques.
L'ED a cnews, alors que le plus à gauche que tu peux voir à la TV, ça doit être quotidien, et ils passent beaucoup de temps à taper sur LFI, et à inviter le patron d'Amazon France venir faire ça pub, donc pas tant à gauche que ça.
Oui, quand je l'ai écrit, le nom, l'idée, c'était "si vous aimez encore Lunduke, regardez cette vidéo, pour voir à quel point ce mec est catastrophique".
Puis j'ai vu la note, relut, et comprit que ça pouvais aussi être lu comme :
"si vous ne faites pas partie de ces WOKE, LGBTQUIA+ d'extrem, extrem gauche, radical, regardez cette vidéo, de l'un des seules vidéastes à parler des vrais problèmes de GNU/Linux, et Wikipédia", donc j'ai mis le commentaire au-dessus pour essayer de donner un peu de contexte.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 1 (+0/-0).
Si pour toi la pratique, c'est de regarder le nombre de failles de sécurité, sans se demander quel point ces programmes en questions sont utilisé, et à quels points il y a un enjeu a trouver des failles de sécurité dans les dits programme.
Dans ce cas, je rentre dans ton jeu :
Seul Open BSD est sécure.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 0 (+0/-1).
Oui, mais concrètement, tu prends SDL, glib, glibc, openssl.
T'a le gros des dépendances utilisé, par la plupart des projets C.
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.
En C t'a souvent des libs à tout faire, et rien que SDL, t'a des htable, des threads, une gestion du filesystem.
glibc, ta queue.h de BSD, hsearch_r pour les htable et regex.h.
Ça fait, que tu te retrouves avec des projets comme FAudio qui ne se base que sur SDL, et même pas la libc (même si indirectement si).
En Rust pour avoir l'intégralité des fonctionnalités de SDL, tu vas avec 2/3 libs pour chaque élèvement.
Si tu considères que chaque libs maintenues pas une personne différente est un vecteur d'attaque pour des supply-chaines attaques, Rust est juste plus vulnérable.
Bof, c'est comme dire que Rust n'apporte pas de garantie sur la gestion de mémoire, car tu peu faire que du code unsafe.
Cargo pousse à utiliser beaucoup de lib,
make/cmakepousse à rester conservateur sur le nombre de lib utilisé, quitte à recoder des choses que tu pourrais trouver en libs.Ça rajoute des chances de rajouter ces bugs, mais enlevés des chances de tomber sur une lib corrompue.
Et les lib dynamique sont une garantie que si une lib casse, on n'a pas besoins de rebuild ton binaire pour fix ta faille de sécu.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 2 (+1/-0). Dernière modification le 14 novembre 2025 à 17:20.
ok, mais l'avantage des lib dynamique, ce n'est pas d'éviter les faille de sécurité au moment du build, c'est de les éviter après, quand t'a wget ou pacman -S ton binaire, et que tu n'as pas fait gaffe que dans les lib statique utilisé, t'en a une de cassée.
Avec une lib dynamique, bah une mise à jour de la lib va réparer le problème, avec une lib statique, il va falloir penser à mettre à jour tous tes binaires impactés. (et si c'est un package AUR, bah, il faut espérer qu'il y a eu une MAJ)
C'est vrai, mais c'est aussi la raison pour lesquels les projets C/C++ sont souvent plus conservateurs sur le nombre de libs, si t'est pas sûr que ta lib est distribué de partout, bah, tu vas devoir la build toi-même, et généralement, tu préfères éviter ça.
[^] # Re: Et son casque VR, sur SteamOS, en ARM, qui utulise FEX pour convertir le code x86 en ARM.
Posté par uso (site web personnel) . En réponse au lien Valve annonce son mini PC de jeu sous SteamOS / Linux / KDE. Évalué à 2 (+1/-0).
Dalleur quand on regarde le CV de Alyssa: https://rosenzweig.io/resume-en.pdf
On voit qu'elle a travaillé sur Apple pour valve.
Si on regarde ces contributions, elle a aussi beaucoup travaillé sur FEX.
À se demander si valve n'a pas utilisé Asahi comme machine de tests pour leur casque VR.
parce que je ne pense pas que les utilisateurs steam Asahi soit assez nombreux pour justifier du temps de dev dessus, par contre, il y a assez d'utilisateurs pour avoir un certain nombre de retours utilisateurs sur FEX, et améliorer leur couche de compatibilité avant que le casque ne sorte.
S'ils ont fait ça, je trouve ça très intelligent.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 0 (+0/-1).
Et un vieux projet en C, avec make, utilise des lib dynamique, donc mise-a-jour par les mainteneurs de ta distribution Linux, ce qui les rend très différents de PHP et ces lib statique.
Ça reste un problème avec les single-header librairies, mais vu qu'il faut les gérer soi-même, bah t'en utilise juste moins que des lib que tu rajoutes dans ton yaml, et qui te tire 15 dépendances, et reste une pratique moins courent que
pkg-config --libs[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 4 (+3/-0).
C'est absolument faux, tu convertis du code C en Rust, tu te retrouves avec du code Rust 100% unsafe.
Les pratique de codage de Rust et C sont différents, donc les algorithmes utilisés en C ne sont pas forcément simples à convertir en Rust safe.
Tu ne convertis pas un programme C en Rust, tu le recodes, avec des pratiques de codages différentes, et des dépendances en plus, beaucoup.
GNU coreutils, c'est principalement deux dépendances : glibc et GNUlib.
uutils, c'est ça : https://deps.rs/repo/github/uutils/coreutils
Si tu additionnes
uu_coreetcoreutils, t'en a 14.Et si tu prends
uu_touch, tu en rajoutes une qui a elle-même 10 dépendances.Sauf que les attaques mémoire concernent aussi Rust…
Si les attaques par supply chaine sont rares, c'est aussi peu être, car C se repose sur moins de dépendances que du Rust ou JS.
XZ, ça a été un gros travaille d'ingénierie sociale pour choisir l'une des rares libs C utilisée un peu partout, et peu maintenues.
En Rust des lib comme XZ utilisé un peu partout, tu n'en as pas 10 comme en C, mais plus 300.
Aussi, entre une erreur mémoire dans un programme comme
ls, qui de toutes manières demande d'avoir accès à ton ordi en physique pour être exploité, et un bout de code ajouté par une dépendance derrière ton dos, qui va te modifier sshd_config à l'init de ls si tu es en root.Bah, je prends 30% de chances d'erreur mémoire à 0.5% de chances de supply chaine attaque.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 2 (+3/-2).
Ma comparaison avec npm, c'est car cargo ressemble plus à npm que make, donc ma remarque, c'est que cargo ajoute aussi une surface d'attaque que make n'a pas.
Le nombre de vulnérabilités n'est pas forcément une valeur intéressante parce que la base d'utilisation de programme en C, et les enjeux a introduire des portes dérobées sont plus grandes que ceux pour leur équivalent en Rust.
En gros si libc/coreutils/curl devraient se voir remplacer par du rust, on va surement enlevé 29% de faille de sécurités lié à la mémoire, par contre le pourcentage de CVE lier à des attaque par supply chain, il va augmenter, mais vu que des coreutils qui utilise cargos pour build, ça reste quelques chose de marginal aujourd'hui, on ne peu pas prédire l'impact que ça auras.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 0 (+3/-4).
Une lib dynamique packager par APT donc un mainteneur de ta distro (donc fix sur un apt update), c'est la même chose qu'une lib static tirer par une autre dépendance que tu as utilisé, et maintenue par 1/4 de personnes qui sait même pas que ça lib est utilisé sur ta distro ?
Parce que en Rust la majorité de tes dépendances sont statiques, et tu peux avoir plusieurs fois la même, mais a des versions diférents dans le même projet. (ce qui arrive à peu près jamais en C).
Et si ta dépendance casse, bah, tu gardes la faille tant que ton binaire n'a pas étais packager.
Aussi en C t'est en général beaucoup plus minimaliste qu'en rust sur les dépendances utilisées.
Car cargo est meilleur que make pour récupérer tes lib et faire en sorte que ça marche, sans rebuild la lib toi même si elle n'est pas packager partout.
Donc cargo est meilleur pour te prendre pleins de dépendances que tu sais même pas que tu les utilises, et qui sont maintenus par personnes.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par uso (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 5 (+4/-0). Dernière modification le 13 novembre 2025 à 23:40.
En même temps, la majorité de la base de ton Linux est en C/C++.
Vu que C/C++ son assez vulnérables aux erreurs mémoire, bah c'est la que les gents cherches les vulnérabilités.
Tu prends un autre langage beaucoup utiliser comme JavaScript, on a peu d'erreurs mémoire, mais une armée d'attaque par chaines de dépendances.
Rust (comme open BSD) restent pour l'instant assez niches (on n'a pas des curl/coreutils/libc utilisé partout en rust), Rust se retrouverait à la place de C, il y aurait surement moins d'erreurs mémoire, mais c'est aussi possible qu'il y ait plus d'erreurs par supply chaines.
Parce que cargo ressemble beaucoup plus à npm qu'à make.
Aussi, Rust est tellement vendu comme langage sécurisé par Default, que les développeurs preuves faire moins attentions aux failles de sécurité, en se cachant derrière ce faux sentiment de sécurité qu'offre le langage.
# Et son casque VR, sur SteamOS, en ARM, qui utulise FEX pour convertir le code x86 en ARM.
Posté par uso (site web personnel) . En réponse au lien Valve annonce son mini PC de jeu sous SteamOS / Linux / KDE. Évalué à 5 (+4/-0).
https://www.gamingonlinux.com/2025/11/valve-reveal-the-new-steam-frame-steam-controller-and-steam-machine-with-steamos/
2026, l'année du desktop sous ARM/GNU/Arch Linux ?
# ceci dit.
Posté par uso (site web personnel) . En réponse au lien Fil Mastodon : comment la réforme de l’orthographe de 1990 a été massacrée . Évalué à 4.
Est-ce que la réforme de l'orthographe de 1990, c'est vraiment nos ognons ?
[^] # Re: Forks
Posté par uso (site web personnel) . En réponse au lien Question récurrente: "Firefox est mort pour moi – et je ne suis pas le seul à en avoir marre". Évalué à 1.
Pas vraiment d'accord, Hans Reiser aurait pu coder/maintenir sont filisystem depuis sa cellule, le monde de Linux serait surement mieux.
Après, on parle de quoi ? garder des personnes problématiques en position dominante ou juste dans un projet ?
Problématique lier à la position exercé ou non ?
Parce que sinon il y a 2/3 jours, je suis tombé sur ce projet https://git.coom.tech/drummyfish/raycastlib qui a l'air vachement sympas à utiliser.
Par contre 5mn à lire le site de l'auteur, et on peut voir à quel point il est problématique, mais ces lib single file, pour faire du jeu vidéo, ont l'air vraiment qualitatif.
[^] # Re: Forks
Posté par uso (site web personnel) . En réponse au lien Question récurrente: "Firefox est mort pour moi – et je ne suis pas le seul à en avoir marre". Évalué à 2.
C'est quoi qui semble manichéen ?
De mettre en avant un conflit d'intérêt ?
Ou de faire un site pour dire que brave, c'est le seul gentil browser, et tout les autres sont méchants ?
[^] # Re: Pas merci
Posté par uso (site web personnel) . En réponse à la dépêche Not so Common Desktop Environment (NsCDE), un paradigme différent. Évalué à 5.
Ton pote vient d'installer Windows Vista, et te monte tous les nouveaux effets graphiques, rien à foutre, toi t'a gnome 2 avec compiz, les fenêtres qui brulent, et le desktop cube !
[^] # Re: non, c'est l'inverse
Posté par uso (site web personnel) . En réponse au lien Is Documentation Like Pineapple on Pizza?. Évalué à 3. Dernière modification le 19 juin 2025 à 14:45.
Il n'y a pas longtemps, j'ai essayé d'intégrer kuroko a un projet perso, en tant que moteur de scripting.
Et si la doc explique comment appeler kuroko, pour intégrer tes struct C dans kuroko, c'est du gros RTFS, et peu être que ça aurais été plus simple avec une doc.
Mais maintenant que j'ai réussi à tout faire marcher comme je veux, est-ce qu'il n'est pas normal que mon syndrome de Stockholm, me force à dire que la documentation ne sert à rien, et à regarder avec mépris ce qui la demande ?
de la même manière que si on aime le fromage, on méprisse ce qui mange du kiri.
Et sinon pour revenir sur le sujet principal du lien, la pizza, la pizza historiquement, c'est le plat du pauvre, qui consiste à mettre les restes sur une pâte à pains, hors l'ananas, c'est un truc que l'on trouve pour pas cher dans un supermarché, ou t'a facilement une boite d'ananas en jus qui reste chez toi.
Alors que d'autre ingrédient comme la burrata ou le jambon à la truffe, eux, ne sont pas censés être dans la catégorie plat du pauvre.
Donc la truffe et la burrata, sont des trahisons bien plus grave que l'ananas à l'esprit de la pizza.
[^] # Re: non, c'est l'inverse
Posté par uso (site web personnel) . En réponse au lien Is Documentation Like Pineapple on Pizza?. Évalué à 1.
Non, la documentation, c'est chiant, ça ne sert à rien si tu peux aller dans le code directement.
C'est un peu plus dur en bouche que la documentation, mais on défend vraiment le babybel face à un bon vieux maroilles ici ?
Alors que l'ananas sur la pizza, c'est le petit plus qui est corolaire au noyau, mais pas directement à l'intérieur du fruit.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par uso (site web personnel) . En réponse au lien XLibre Xserver: Banned by Red Hat Developer Plans Revival of X11. Évalué à 1.
Oui et non, quand tu fais un nouveau projet, tu passes ton temps à le casser avant d'avoir une API stable.
La personne derrière le code, a clairement l'air d'être dans l'idée d'amélioré quitte à casser, ce qui ne va forcément pas plaire aux mainteneurs de xorg.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par uso (site web personnel) . En réponse au lien XLibre Xserver: Banned by Red Hat Developer Plans Revival of X11. Évalué à 1.
Il y a Brodie Robertson qui a fait une vidéo sur le fork: https://www.youtube.com/watch?v=iCU4W5Ab33c
Je l'ai trouvé pas mal, il explique que le mec qui a fork est le plus gros contributeur de x11 de 2024, donc il a une certaine experiance avec X11.
Par contre, beaucoup de ses contributions ne sont pas forcément appréciées, car il a tendance à casser les choses, dont l'ABI.
À part la politique, il y avait une grosse friction entre la personne qui a fait le fork, et les gents derrière X11, c'est que la personne derrière le fork veut améliore X11, quitte à casser des choses, alors que la majorité des dev et mainteneur de X11, préfère essayer de garder un code stable.
[^] # Re: containers
Posté par uso (site web personnel) . En réponse au journal Sécurité de linux. Évalué à 2.
Y'a un problème darling ?
le projet a l'air sympa.
[^] # Re: Zero bug original corrigé mais de nouveaux bugs
Posté par uso (site web personnel) . En réponse au lien XLibre Xserver: Banned by Red Hat Developer Plans Revival of X11. Évalué à 5.
Eh, pour "ne maîtrise pas les bases de C.", la PR est clairement faite par une personne qui n'est pas le codeur principal.
Pour le coup, j'ai aussi zieuté les commits, et il y a énormément de commits avec une seule ligne de code, qui pourrait être regroupé en un seul commit.
Ceci dit, en poussant un peu, il y a l'air d'avoir des commits plus conséquent.
Le fork est clairement fait par une personne réactionnaire, par contre pour le code, il a l'air de changer plains de truc, a un commit tree, qui a l'air un peu ma-tu-vue, mais je suis incapable de savoir s'il va réussir à faire quelques chose en quelques coups d'œils sur son code.
Le fait qu'il ait cassé les claviers peut être une preuve d'incompétence, comme juste l'un des symptômes du fait qu'il fasse un gros refactoring.
[^] # Re: containers
Posté par uso (site web personnel) . En réponse au journal Sécurité de linux. Évalué à 2.
Pour le coup, les containers ça utilise beaucoup les cgroups, qui ne sont pas des appels système, mais un filesystem. (que tu manipules comme des fichiers)
Donc ce n'est pas que les appels systèmes qui peuvent poser problèmes.
Aussi les appelle système, c'est souvent juste des point d'entrées vers d'autre fonction du kernel, donc rarement le code même des appels système qui pose problèmes.
Après ça ne change pas grand-chose au raisonnement ceci dit.
Ceci dit, si on est sur un compte de point d'entrée sur les intel, t'a plusieurs milliers d'instructions, à côté de ça les 400 syscall de linux paraissent bien peu.
Surtout que ça inclut les getuid et autre, qui ont peu de chance de poser problèmes.
[^] # Re: containers
Posté par uso (site web personnel) . En réponse au journal Sécurité de linux. Évalué à 3.
Alors que si tu fais de la virtualisation, alors tu atterris au final avec une liste d'instructions CPU à permettre qui est pas mal longue, qui contient des trucs assez dangereux, et tu te retrouves avec autant d'interfaces pour entrer dans ce gros spaghetti d'instruction set qu'est Intel.
[^] # Rust
Posté par uso (site web personnel) . En réponse au journal Sécurité de linux. Évalué à 2.
Rust Rust Rust Rust Rust Rust Rust Rust Rust Rust Rust.
Rust Rust Rust Rust !
Rust Rust Rust Rust Rust Rust Rust Rust.
Rust Rust ?
Rust Rust Rust.
Rust.
[^] # Re: La différence entre démocratie et totalitarisme
Posté par uso (site web personnel) . En réponse au lien Microsoft bloque les emails de ses employés contenant les mots « Palestine », « Gaza », « génocide ». Évalué à 10. Dernière modification le 24 mai 2025 à 22:41.
Si tu veux, cette vidéo l'explique pas mal :
https://www.youtube.com/watch?v=SMzWtsjauo0
Mail le TLDW, serait, que :
- Des palestiniens et israélien, il y en a beaucoup qui on immigrait partout dans le monde.
- Conflit colonial, ce qui touche différents affects, et est assez unique.
- Ça fait partie des luttes de la gauche depuis pas mal de temps.
Et tu peux rajouter à ça l'asymétrie de traitement que tu as dans les médias/compétition internationale entre la Russie et Israël. (par exemple l'eurovision)
Bof, Sadoche, il n'est pas de gauche à ce que je sache.
Mais après des contenus politiques de droite sur Twitch, je n'en connais effectivement pas, mais peu être que si la gauche est présent sur twitch, c'est aussi, car elle répond à une demande, que l'on ne trouve pas dans les médias classiques.
L'ED a cnews, alors que le plus à gauche que tu peux voir à la TV, ça doit être quotidien, et ils passent beaucoup de temps à taper sur LFI, et à inviter le patron d'Amazon France venir faire ça pub, donc pas tant à gauche que ça.
[^] # Re: eh le nom du lien est trompeur
Posté par uso (site web personnel) . En réponse au lien Vidéo un peu vieille pour ceux qui aime encore Bryan Lunduke (mais que j'ai découvert hier). Évalué à 5.
Oui, quand je l'ai écrit, le nom, l'idée, c'était "si vous aimez encore Lunduke, regardez cette vidéo, pour voir à quel point ce mec est catastrophique".
Puis j'ai vu la note, relut, et comprit que ça pouvais aussi être lu comme :
"si vous ne faites pas partie de ces WOKE, LGBTQUIA+ d'extrem, extrem gauche, radical, regardez cette vidéo, de l'un des seules vidéastes à parler des vrais problèmes de GNU/Linux, et Wikipédia", donc j'ai mis le commentaire au-dessus pour essayer de donner un peu de contexte.