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.
En gros, la vidéo, s'appelle "Linux sucks" sucks, et elle explique, comment Lunduke manipule l'information pour faire de la politique d'extrême droite.
Peu être que j'aurais dû mettre un meilleur nom de lien.
La theory derrière, c'est que la plupart du temps, quand il parle d'agressions sexuelles, et de violence sexiste, c'est pour être plutôt progressiste.
Et que l'essentialiser à ces messages les plus malaisantes, en ne prenant pas en compte comment que son éducation, age et son autisme aurait pu lui faire dire des conneries,
C'est avoir une vision de lui très individualiste qui passe complétement à côté de comment les structure façonnes des idées, qui est au final un engagement féministe aussi engager qu'une réduction de 30% sur des serviettes hygiéniques.
Mais tkt, je connais la rhétorique que tu appliques, Brian Lunduke utilise la même pour dire que Hector Martin est trop bizarre, et trans pour être un bon leader pour Asahi Linux.
Parce que les idées des gents,(ou le code dans le cas de Hector Martin) on s'en fout, on va rester sur leur caricature, et se balancer tout un tas de stéréotype pour bien s'autoconvaincre qu'un personne est mauvaise.
En même temps, on parle d'une personne ou sur son site personnels, son dernier poste défend le boycott d'Israël (indirectement, il faut suivre ce lien).
C'est sûr qu'une personne bien pas politiser, qui parle que vaguement d'open-source, ça serait bien mieux, et je comprends que beaucoup de gents veulent ça.
Dans ce cas précis, a plus l'air d'être une option de build par default de la glibc qui a changé qui casse des vieux builds. (ou des projets qui utilisent DT_HASH).
En fait c’est aussi que les programmes utilisent plus souvent les nouvelles fonctions de la libc que lez nouveaux appels systèmes.
Ça, ce sont plus des problèmes de forward compatibilité, mais Windows n'est pas mieux que Linux, là-dessus, un programme fait pour windows 11, a peu de chances de marcher sous Windows 7. Mais je suppose que c'est prévu.
Après, on me dira que, ce n'est pas forcément uutils qui est directement concerné, mais ses dépendances, et potentiellement uutils n'utilise pas le code problématique des dépendances.
Reste qu'un projet en Rust utilisant des dépendances statiques, si l'on utilise l'une des versions concernées par ces failles, on ne peut pas réparer les problèmes de sécurité juste en fessant une update de la libc comme on le ferait avec un problème de dépendances dans GNU coreutils, mais on doit mettre à jour uutils lui-même.
La dernière console à disposer d'un matériel vraiment spécifique doit être la PS3 avec ses processeurs "cells"?
Et en même temps, pour les consoles de cette génération, RPCS3, supporte beaucoup plus de jeux que les émulateurs Xbox 360. (bon la Wii est à part, car elle est assez similaire à la Gamecube)
Ce qui n'invalide pas forcément ce que tu dis, je suppose qu'il y a juste plus de personne intéressée à faire un émulateur PS3 que Xbox 360.
La 1re Xbox a aussi mis plus de temps à être émulé correctement que la Gamecube/PS2, alors que c'est un x86.
Oui, et non, un peu plus haut, il dit que systemd est assez conservateur avec ses dépendances, qu'il utilise dlopen pour éviter les problèmes que tu pourrais avoir avec une lib statiquement linker. (ou dynamiquement à la compilation).
Dans la partie sur Rust ça parle effectivement d'espace disque, et de bibliothèque dynamique, mais combiner avec la réfection sur xz, et dlopen plus haut, tu peux voir comment cargo poserait problèmes avec une intégration dans systemd.
L'autre jour je devais compiler un projet CMake, et il a téléchargé pas mal de dépendance avec FetchContent_Declare et certaines dépendances avaient elle même des dépendances de cette façon
Oui, et moi, je connais des projects rust qui utilise cargo-audit et ont une CI qui fait particulièrement attention à quelles dépendances elles incluent.
Et quand tu regardes les failles de sécu dans les projects rust, des erreurs mémoire ou des races conditions t'en voient passer aussi.
Mais même si on regarde des gros projets (C++ pas C dalleur) comme on peut le voir ici : https://gist.github.com/flibitijibibo/b67910842ab95bb3decdf89d1502de88
Bah, on ne dépasse pas les 100 lignes de dépendances (qui effectivement preuves être biaisé, car ça n'inclue pas les dépendances statiques).
En Rust, un programme en CLI, en a facilement plus de 100, en GUI, on est plus dans les 400.
Je ne dis pas que ce n'est pas possible d'avoir un projet C qui va tirer une armée de dépendance à lui, ou qu'un project Rust seras forcément plein de dépendance peu connue qu'on ne sait pas d'où elle vienne.
Juste que par défaut, rajouter des dépendances en C, c'est pas aussi simple que rajouter une ligne dans cargo.toml, et il faut le faire soi-même, donc t'en évite beaucoup si t'en a pas vraiment besoins.
Au même titre que rajouter une CI asan/valgrind ça prend du temps, au même titre que rajouter un cargo-audit dans un runner gitlab/hub c'est chiant.
C’est mieux mais tu ne peux pas par exemple en C (comme dans quasiment tous les langages) décrire la propriété d’un pointeur dans l’API. Si tu me renvoi un pointeur, suis‑je celui qui doit le libérer ou non ?
Effectivement, généralement, ça fait partie de la Documentation/Convention de nommage, et c'est facile de se tromper.
Je suppose que ça fait aussi partie des choses que peuvent rapporter les binding Rust pour le code C, ça force à re-réfléchir la gestion des ownership dans les API C.
Est‑il plus facile de faire confiance en sa chaîne de dépendance en C ?
Oui, vu que tu rajoutes toi-même la majorité des dépendances dans le Makefile/Cmake, et donc t'a moins de dépendances surprises, que cargo t'a sortie, tu ne sais pas vraiment comment.
Que c'est chiant à faire, et donc tu vas éviter d'en rajouter, sauf si besoins. (ça peut paraitre comme négative, mais c'est aussi la raison pour laquelle je préfère le C au C++, C me force à utiliser des fonctions quand je n'ai pas besoins d'un objet)
Que tu utilises généralement des lib dynamique, et donc tu peux faire confiance à l'OS pour fixer les faille de sécurité pour toi.
Fait des ldd dans tes /bin, et tu auras rarement plus de 20/25 dépendances.
En Rust, t'en a rarement moins de 120.
Et s'il y a une faille de sécurité, t'est forcé de re-packager ton application vu que c'est du static.
En fait dans la réponse que tu as envoyée 2x, Greg KH explique que rust peu être un outil pour améliorer les API c.
Typiquement l'exemple du void *, qui est au final assez peu utiliser, car on lui préfère généralement un retour sur un pointeur d'un type définit, mais si on a une vielle API qui n'a jamais changé, alors on peut garder du code, moins sécure.
Et Rust met un coup de pied au cul pour améliorer les vielle API C, vers un meilleur C.
Et pour le débat C n'est pas sécure alors que Rust l'est, je dirai juste qu'il est aussi facile en C d'avoir un code sécure sans problème de gestion mémoire, qu'il est facile en Rust de comprendre et d'avoir confiance dans sa chaine de dépendance. (chose qui ne concerne pas le kernel, car il ne peut pas utiliser la plupart des lib rust, et on évite donc les problèmes de dépendances douteuses)
Effectivement, ceci dit de mémoire, les commentaires de phoronix, ont quand même tendances à être plus trollesque, et moins ouverts aux longs débat…
Par exemples, la dernière Foix que je suis allé voir un thread gcc vs clang, il me semble que les commentaires s'arrêtais à "gcc doit mourir" avec rarement de longue réponse explicative pour défendre une idée, comme on le trouve souvent sur linuxfr.
Ceci dit, en disant ça, je pense que j'ai un peu répondu à ma question, les commentaires de linuxfr, sont triés par réponse, ce qui crée plusieurs threads, et permet plus les débats.
Pour linuxfr "repère de vieux react", j'ai l'impression que généralement les journaux bien réactionnaires, pour défendre des idées d'extrêmes droites, sont rarement au-dessus de -20, donc il y a des react, mais ce sont pas eux qu'on entend le plus. (alors que les journaux bien à gauche tournent plus autours des -5/-10, mais arrive à être dans le positif des-fois)
Vieux con a la limite, on a encore toutes les news sur Window Maker. (et c'est très bien comme ça)
Oui, dalleur, la vidéo ne dit pas que les problèmes de l'Hyperloop sont insurmontables, mais que ce n'est pas pour demains, et que si ça arrive, ça seras en 1er surement pour du fret, et plus pour des petits groupes de gents, pas accessibles a tout le monde.
[^] # 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 (+0/-0).
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é à 2 (+1/-0).
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 (+1/-0).
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 (+4/-0).
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 (+1/-0).
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 (+2/-0).
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 (+4/-3).
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 (+13/-1). 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 (+4/-0).
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.
# 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é à 3 (+3/-1).
En gros, la vidéo, s'appelle "Linux sucks" sucks, et elle explique, comment Lunduke manipule l'information pour faire de la politique d'extrême droite.
Peu être que j'aurais dû mettre un meilleur nom de lien.
[^] # Re: Devient?
Posté par uso (site web personnel) . En réponse au lien « The Keynote Will NOT Go Forward » — lien-signets : Richard Stallman devient persona non grata. Évalué à 6 (+7/-2).
La theory derrière, c'est que la plupart du temps, quand il parle d'agressions sexuelles, et de violence sexiste, c'est pour être plutôt progressiste.
Et que l'essentialiser à ces messages les plus malaisantes, en ne prenant pas en compte comment que son éducation, age et son autisme aurait pu lui faire dire des conneries,
C'est avoir une vision de lui très individualiste qui passe complétement à côté de comment les structure façonnes des idées, qui est au final un engagement féministe aussi engager qu'une réduction de 30% sur des serviettes hygiéniques.
Mais tkt, je connais la rhétorique que tu appliques, Brian Lunduke utilise la même pour dire que Hector Martin est trop bizarre, et trans pour être un bon leader pour Asahi Linux.
Parce que les idées des gents,(ou le code dans le cas de Hector Martin) on s'en fout, on va rester sur leur caricature, et se balancer tout un tas de stéréotype pour bien s'autoconvaincre qu'un personne est mauvaise.
[^] # Re: Devient?
Posté par uso (site web personnel) . En réponse au lien « The Keynote Will NOT Go Forward » — lien-signets : Richard Stallman devient persona non grata. Évalué à 1 (+3/-3).
En même temps, on parle d'une personne ou sur son site personnels, son dernier poste défend le boycott d'Israël (indirectement, il faut suivre ce lien).
C'est sûr qu'une personne bien pas politiser, qui parle que vaguement d'open-source, ça serait bien mieux, et je comprends que beaucoup de gents veulent ça.
[^] # Re: Il y a aussi pas mal de choses fausses dans cet article :
Posté par uso (site web personnel) . En réponse au lien Convertir Linux en Windows. Évalué à 4 (+3/-0).
Pour le coup, il parle de ça :
https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash
Dans ce cas précis, a plus l'air d'être une option de build par default de la glibc qui a changé qui casse des vieux builds. (ou des projets qui utilisent DT_HASH).
Ça, ce sont plus des problèmes de forward compatibilité, mais Windows n'est pas mieux que Linux, là-dessus, un programme fait pour windows 11, a peu de chances de marcher sous Windows 7. Mais je suppose que c'est prévu.
[^] # Re: Il fait tiède
Posté par uso (site web personnel) . En réponse au lien ubuntu envisage de migrer les coreutils vers des équivalents en rust (uutils). Évalué à 1 (+1/-1). Dernière modification le 21 mars 2025 à 23:57.
Je me demandais ce que ça vaut, comparer à uutils.
Donc j'ai essayé de trouver les versions les plus récentes de uutils qui contient des failles de sécu.
Pour ce faire, j'ai checkout + cargo-audit les tags des versions de uutils.
Donc le 1ᵉʳ version de uutils apparemment, c'est 0.0.24 qui date du 2024-01-24, avec ces 2 rustsec:
https://rustsec.org/advisories/RUSTSEC-2024-0019
et
https://rustsec.org/advisories/RUSTSEC-2024-0006
si on remonte de 2 versions, on rajoute elle :
https://rustsec.org/advisories/RUSTSEC-2023-0070
si on remonte au 15, on rajoute elle : https://rustsec.org/advisories/RUSTSEC-2023-0070
Après, on me dira que, ce n'est pas forcément uutils qui est directement concerné, mais ses dépendances, et potentiellement uutils n'utilise pas le code problématique des dépendances.
Reste qu'un projet en Rust utilisant des dépendances statiques, si l'on utilise l'une des versions concernées par ces failles, on ne peut pas réparer les problèmes de sécurité juste en fessant une update de la libc comme on le ferait avec un problème de dépendances dans GNU coreutils, mais on doit mettre à jour uutils lui-même.
[^] # Re: Une vidéo intéressante sur le procédé
Posté par uso (site web personnel) . En réponse au journal Sonic Unleashed nativement sous Linux (et probablement de futurs jeux XBOX 360). Évalué à 1.
Et en même temps, pour les consoles de cette génération, RPCS3, supporte beaucoup plus de jeux que les émulateurs Xbox 360. (bon la Wii est à part, car elle est assez similaire à la Gamecube)
Ce qui n'invalide pas forcément ce que tu dis, je suppose qu'il y a juste plus de personne intéressée à faire un émulateur PS3 que Xbox 360.
La 1re Xbox a aussi mis plus de temps à être émulé correctement que la Gamecube/PS2, alors que c'est un x86.
[^] # Re: Un gpl killer? TAN !
Posté par uso (site web personnel) . En réponse au lien FYI: An appeals court may kill a GNU GPL software license. Évalué à 4.
Question conne, mais c'est vrai dans tous les pays ça ?
Parce que si il y a une chose que j'ai compris du droit, ce n'est que chaque pays à le sien.
[^] # Re: Après le point médian...
Posté par uso (site web personnel) . En réponse au lien Le Point applique les méthodes de l'extrême droite pour faire taire un contributeur de Wikipédia . Évalué à 4.
Seulement pour les personnes pointilleuses.
[^] # Re: mode Brice on
Posté par uso (site web personnel) . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 1.
Oui, et non, un peu plus haut, il dit que systemd est assez conservateur avec ses dépendances, qu'il utilise dlopen pour éviter les problèmes que tu pourrais avoir avec une lib statiquement linker. (ou dynamiquement à la compilation).
Dans la partie sur Rust ça parle effectivement d'espace disque, et de bibliothèque dynamique, mais combiner avec la réfection sur xz, et dlopen plus haut, tu peux voir comment cargo poserait problèmes avec une intégration dans systemd.
[^] # Re: mode Brice on
Posté par uso (site web personnel) . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 3.
Oui, et moi, je connais des projects rust qui utilise cargo-audit et ont une CI qui fait particulièrement attention à quelles dépendances elles incluent.
Et quand tu regardes les failles de sécu dans les projects rust, des erreurs mémoire ou des races conditions t'en voient passer aussi.
Mais même si on regarde des gros projets (C++ pas C dalleur) comme on peut le voir ici :
https://gist.github.com/flibitijibibo/b67910842ab95bb3decdf89d1502de88
Bah, on ne dépasse pas les 100 lignes de dépendances (qui effectivement preuves être biaisé, car ça n'inclue pas les dépendances statiques).
En Rust, un programme en CLI, en a facilement plus de 100, en GUI, on est plus dans les 400.
Je ne dis pas que ce n'est pas possible d'avoir un projet C qui va tirer une armée de dépendance à lui, ou qu'un project Rust seras forcément plein de dépendance peu connue qu'on ne sait pas d'où elle vienne.
Juste que par défaut, rajouter des dépendances en C, c'est pas aussi simple que rajouter une ligne dans cargo.toml, et il faut le faire soi-même, donc t'en évite beaucoup si t'en a pas vraiment besoins.
Au même titre que rajouter une CI asan/valgrind ça prend du temps, au même titre que rajouter un cargo-audit dans un runner gitlab/hub c'est chiant.
[^] # Re: mode Brice on
Posté par uso (site web personnel) . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 3.
Effectivement, généralement, ça fait partie de la Documentation/Convention de nommage, et c'est facile de se tromper.
Je suppose que ça fait aussi partie des choses que peuvent rapporter les binding Rust pour le code C, ça force à re-réfléchir la gestion des ownership dans les API C.
Oui, vu que tu rajoutes toi-même la majorité des dépendances dans le Makefile/Cmake, et donc t'a moins de dépendances surprises, que cargo t'a sortie, tu ne sais pas vraiment comment.
Que c'est chiant à faire, et donc tu vas éviter d'en rajouter, sauf si besoins. (ça peut paraitre comme négative, mais c'est aussi la raison pour laquelle je préfère le C au C++, C me force à utiliser des fonctions quand je n'ai pas besoins d'un objet)
Que tu utilises généralement des lib dynamique, et donc tu peux faire confiance à l'OS pour fixer les faille de sécurité pour toi.
Fait des ldd dans tes /bin, et tu auras rarement plus de 20/25 dépendances.
En Rust, t'en a rarement moins de 120.
Et s'il y a une faille de sécurité, t'est forcé de re-packager ton application vu que c'est du static.
C'est dalleur l'un des blocages qu'à systemd pour adopter rust: https://lwn.net/SubscriberLink/1008721/7c31808d76480012/
[^] # Re: mode Brice on
Posté par uso (site web personnel) . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 0.
En fait dans la réponse que tu as envoyée 2x, Greg KH explique que rust peu être un outil pour améliorer les API c.
Typiquement l'exemple du void *, qui est au final assez peu utiliser, car on lui préfère généralement un retour sur un pointeur d'un type définit, mais si on a une vielle API qui n'a jamais changé, alors on peut garder du code, moins sécure.
Et Rust met un coup de pied au cul pour améliorer les vielle API C, vers un meilleur C.
Et pour le débat C n'est pas sécure alors que Rust l'est, je dirai juste qu'il est aussi facile en C d'avoir un code sécure sans problème de gestion mémoire, qu'il est facile en Rust de comprendre et d'avoir confiance dans sa chaine de dépendance. (chose qui ne concerne pas le kernel, car il ne peut pas utiliser la plupart des lib rust, et on évite donc les problèmes de dépendances douteuses)
[^] # Re: Clair
Posté par uso (site web personnel) . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 5.
Effectivement, ceci dit de mémoire, les commentaires de phoronix, ont quand même tendances à être plus trollesque, et moins ouverts aux longs débat…
Par exemples, la dernière Foix que je suis allé voir un thread gcc vs clang, il me semble que les commentaires s'arrêtais à "gcc doit mourir" avec rarement de longue réponse explicative pour défendre une idée, comme on le trouve souvent sur linuxfr.
Ceci dit, en disant ça, je pense que j'ai un peu répondu à ma question, les commentaires de linuxfr, sont triés par réponse, ce qui crée plusieurs threads, et permet plus les débats.
Pour linuxfr "repère de vieux react", j'ai l'impression que généralement les journaux bien réactionnaires, pour défendre des idées d'extrêmes droites, sont rarement au-dessus de -20, donc il y a des react, mais ce sont pas eux qu'on entend le plus. (alors que les journaux bien à gauche tournent plus autours des -5/-10, mais arrive à être dans le positif des-fois)
Vieux con a la limite, on a encore toutes les news sur Window Maker. (et c'est très bien comme ça)
[^] # Re: Clair
Posté par uso (site web personnel) . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 0.
Un peu HS, mais si quelqu'un aurait posté ce commentaire ici, il ne se serait surement pas fait censurer, mais bien moinsser.
À votre avis, c'est due à quoi la différence de qualité entre linuxfr, et phoronix ?
La différence culturelle entre les États-Unis, et la France, la manière dont linuxfr est structuré avec ces pertinantage/mojnsage ou autres choses ?
[^] # Re: Clair
Posté par uso (site web personnel) . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 10.
Tu peux aussi rajoute le fait, que quelques postes plus haut, des mainteneurs disent avoir parlé en privé avec Linus.
Je suppose que ça à du pas mal discuter avant de répondre en public.
[^] # Re: Musk et l'hyperloop (mes sources)
Posté par uso (site web personnel) . En réponse au lien Ils nous mentent. Évalué à 2.
Oui, dalleur, la vidéo ne dit pas que les problèmes de l'Hyperloop sont insurmontables, mais que ce n'est pas pour demains, et que si ça arrive, ça seras en 1er surement pour du fret, et plus pour des petits groupes de gents, pas accessibles a tout le monde.