Dans l'optique ou ça impliquerait une bascule sur un modèle de ''do-ocraty'' à autre chose plus basé sur les besoins des institutions genre l'UE avec du budget, une évolution plus raisonnable et stable de GTK est envisageable. D'autant que c'est une demande d'autres projets comme Gimp par exemple, pas le moindre, qui se voient un peu envoyer dans les cordes avec leurs besoin à eux avec des réponse style ''on a pas forcément les moyens de maintenir les trucs dont vous avez besoin quand on fait évoluer les APIs'', c'est clairement un besoin qui dépasse le cadre de Gnome.
Alors pour tester les IAs il vaut mieux bidouiller les énoncés du problèmes ou les garder secrets, on peut toujours soupçonner que si elles donnent la bonne réponse c'est pas tellement parce qu'elles l'ont inventées que plutôt parce que c'est une question classique et qu'elles ont "triché" en ayant déjà la question et la réponse dans leur corpus et qu'elles l'ont stockée.
Ce n'est pas forcément tant une question de possibilité de raisonnement que de connaissance empirique du monde. Les corpus de données comprennent probablement relativement peu d'information sur la pratique du roulage de cigarette et de la fumette, c'est pas tellement un truc qui s'apprend dans les livres. A partir de là, si la connaissance nécessaire n'est pas là, forcément le raisonnement n'est pas possible.
Une énigme mathématique demandant le même genre d'astuce pourrait montrer que la possibilité de "raisonnement" est là, et qu'elle n'est pas débloquée dans ce cas précis faute de connaissance. Un autre niveau serait de montrer que la connaissance est là, question roulage de clope (ce qui n'est pas impossible) mais que le lien avec le raisonnement formel n'est pas là parce que le logiciel est incapable de formaliser par lui même de manière à débloquer la capacité de raisonnement.
C'est la question de la compositionnalité des capacités "générique" qui vient après la démonstration de certaines capacités dans l'abstrait de manière indépendante. Mais sortir du cadre, oui les IAs ont quand même en soit démontré certaines possibilités de ce côté là.
C'est des choses qui sont étudiées actuellement, en cherchant les mots clés rapidement je trouve https://arxiv.org/pdf/2402.08674 ce papier qui a l'air de faire de la "pédagogie" d'IA pour chercher dans quel ordre leur faire apprendre des trucs pour débloquer de la compositions de connaissances.
Le fait que ce soit à base probabiliste ne nous donne pas vraiment d'informations sur la capacité à s'adapter facilement.
En particulier, pour calculer efficacement les probabilités dans un espace limité, avec un nombre de neurone contraint, il faut une forme de structuration de ces réseaux de neurones pour traîter l'information et en tirer des probabilités raisonnables. Cette structuration, pour fonctionner efficacement, ne doit-elle pas généraliser suffisamment pour s'adapter à d'autre problème ? La question n'est pas "proba ou pas" mais "comment ça généralise".
Exemple limite : un raisonnement mathématique. Prend un ensemble de démonstration mathématiques, à classer comme "correctes" ou "incorrecte", entraine le donc à discriminer le mathématiquement correct du mathématiquement incorrect. Les lois de la logiques ont des règles du jeu. Un réseau de neurone "séquentiel" peut en principe apprendre les différentes règles pertinentes, et classer leur application correcte ou pas, voire pointer directement les applications incorrectes.
Au cours de l'apprentissage, probabiliste, à force d'enquiller les démonstrations, il fait de moins en moins d'erreurs. C'est probabiliste. Une fois l'apprentissage terminé, on lui montre des démonstrations mathématiques, à classer en correctes et incorrectes. Dans le principe, il a "juste" à faire comme un correcteur humain, à vérifier pas à pas que les règles de la logiques sont respectées.
Sur ce principe, on part d'un apprentissage en mode probabiliste et on arrive à un résultat ou il n'y aura pas forcément d'erreurs … La question est, est-ce que ce résultat est crédible, et est-ce que la capacité à s'adapter très largement à une large classe de démonstration mathématique qu'il n'a pas vu n'est pas une preuve d'adaptation très importante ?
Tout ça pour dire que la dichotomie que tu fais n'en est pas forcément une, le mode "probabiliste" n'est pas incompatible avec l'adaptation (au contraire même, dans certains cas ça rend beaucoup plus robuste, c'est ce qui permet de généraliser et de discriminer petit à petit ce qui n'est pas important en en baissant petit à petit le poids). Alors qu'un raisonnement binaire sera impossible à généraliser si on sort un tantinet du cadre et sera inapplicable si on est pas pile poil dans le cadre déterminé à l'avance.
On peut dire Apprentissage automatique pour du plus générique, ça donne ''l'apprentissage automatique libre'', ça a l'avantage de rendre le terme ''apprentissage'' (crucial dans la problématique) explicite, mais on perd le grand public assez largement.
Et ça insiste plus sur le processus d'apprentissage que sur le résultat, alors que ''IA'' ce serait l'inverse, ça désigne le résultat qui tourne.
Y a-t-il un développeur qui soit capable de trouver tous les bugs ? Est-il compris dans l'ensemble des développeurs capables de se corriger eux même ? Quid des bugs créés par des non développeurs ? Est-il un non développeur lui même ?
Si ça se trouve ça se marierait bien avec une Wikibase, avec une édition des enquêtes en wiki façon Wikidata et SPARQL au lieux de SQL pour réviser son SPARQL.
C'est pas tout à fait le même niveau de généralité non ? Ici tu fixes un type pour A et B, Integer, on a au moins besoin de paramétrer la procédure, A et B sont dans les autres exemples des variables de types qu'on doit préciser lors de l'appel à la procédure.
Sinon question distinction, c'est très courant maintenant d'utiliser le mot clé "const" pour les variables immuables, il y a ça en C++ ou en javascript. Donc oui tu peux tenter de te distinguer mais ça va pas tellement être compris, o tempora, o maures.
Ah oui rien que ça, tu trolles naturellement ou tu te fais aider par une IA pour être aussi pertinent ? Tarte à la fraise (oui tu peux me la jeter au visage après) ?
Mon cerveau fait une syncope dès qu'il lit "en Rust une variable est une constante".
Une variable ne peut être affectée qu'une fois et ne plus changer de valeur. Par exemple un paramètre d'une fonction est affecté uniquement lors de l'appel de la fonction, et ne peut pas changer de valeur au cours de l'appel (il peut par contre devenir inaccessible).
Ce n'est pas vraiment contradictoire avec le fait d'être une variable, c'est comme en maths les paramètres de fonctions. Différents appels = différentes valeurs (variable), au cours d'un appel, ne change pas de valeur. Même principe que les variables déclarées "const" dans d'autres langages.
Et oui si tu fais une syncope rien qu'avec ça, formulation trollesque ou maladroite écartée, passe ton chemin ou évolue :p
Sans détails plus que ça c'est difficile d'évaluer l'ampleur de ce drâme !
On va laisser les gens travailler, déterminer les bouts de code essentiels, voir si c'est une si grosse partie de code que ça. Linux à sa propre lib de base, j'imagine qu'il la font évoluer aussi parfois tout le monde s'en fout.
Les communautés Rust et Linux vont aussi probablement être à l'écoute l'une de l'autre, on verra comment ils gèrent ce genre de contraintes, version ement, norme …
Comme le reste : le jeu en vaut-il la chandelle ? Quels sont les bénéfices, les problèmes (avérés) qui sont vraiment durs à résoudre en pratique, est-ce un vrai fardeau ou alors bof la vie normale de l'évolution d'un code de cette ampleur et pas tellement plus, les solutions trouvées …
On peut causer dans le vague et un certain purisme de propriétés attribuées au C longtemps, il a toujours sa sémantique qui permet de faire relativement n'importe quoi facilement sans contrôle ni garantie dans la balance. Il y a probablement un prix à payer pour mettre ce genre de garanties dans Linux. Mais vu que les devs qu'on ne peut pas soupçonner d'incompetences reconnaissent que ça cause des bugs qui sont un fardeau à traiter, un peu tout le temps, la question n'est pas vraiment de savoir si le C a une API qui a t'elle propriété …
C'est si le cout d'avoir ces garanties est si important que ça contrebalance les bénéfices, et si l'intégration est si compliquée que ça et si pénible à maintenir.
Oui il y aura des problèmes d'intégration logicielle, et des problèmes humains, surtout au début. Mais en vitesse de croisières, concrètement… Tu trouves du temps de debuggage contre quelques bonnes pratiques d'intégration et du versionnement des compilos Rust et un peu de dialogue entre les projets ? Linux n'est pas un programme si insignifiant que sa voie ne pèse pas dans la balance et que Rust leur dise "merde".
C'est un peu l'étape d'après, si l'implicite est "si tu peux pas mettre de l'eau dans ton vin on va pas pouvoir continuer à travailler ensemble". Mais effectivement ils ont déjà causé en privé donc on a pas tout l'histo et l'implicite sous la main.
Disons que si tu te définis par une manière agressive d'interagir avec les autres qui leur pose problème à eux, alors que toi ça te va très bien, il y a probablement du réglage à faire de ton côté. Tu trouves intolérable d'être heurté dans ta sensibilité et impensable de changer alors que tu l'exiges des autres pour interagir avec toi alors que du côté des autres heurtés dans leur sensibilité c'est à eux de changer, c'est pas symétrique du tout.
Dans un projet l'objectif commun c'est de faire avancer les choses :)
C'est pas une demande de sa part, en l'occurrence, mais un principe ? D'une manière générale, adopter les méthodes qu'on condamne par ailleurs c'est pas forcément aller dans la bonne direction.
Par exemple on n'a pas un langage bien défini avec des lib par dessus.
La lib rust utilise des fonction interne du compilo, par ce que des choses sont pas possible.
C'est pas un "hack", c'est juste que ces fonctions de la lib sont des primitives du langages, qui seront spécifiées comme à part entière du langage. L'implémentation, du coup, sera laissée libre au compilo et cette histoire de "fonction interne au compilo" n'a pas grand sens, c'est le cas de n'importe quel mot clé avec une sémantique donnée dans n'importe quel langage, c'est le compilo qui implémente la chose. Souvent la lib de base fait partie à part entière de la spec du langage, quand il y en a.
Il peut y avoir une nuance entre "le problème c'est toi" et "le problème, c'est ta réaction en l'occurrence". Le premier est essentialisant, potentiellement, si tu tombes sur quelqu'un de sensible (tout le monde peut l'être à un moment) et sur un moment de fragilité "bon, si le problème c'est moi, à quoi bon, je laisse tomber", alors que si c'est simplement une manière d'agir, c'est pas ce qui te définit en tant que personne et c'est modifiable.
[^] # Re: Pourquoi dire IA si on ne parle que des réseaux de neurones ?
Posté par thoasm . En réponse à la dépêche Une intelligence artificielle libre est-elle possible ?. Évalué à 2.
Ah mais j'en parle parce que ça ressort particulièrement des définitions que tu as sorties, de l'adaptation.
[^] # Re: Petit résumé sans IA
Posté par thoasm . En réponse au lien "Des prothèses qui ne trahissent pas", une proposition de réforme de la gouvernance de GNOME. Évalué à 4.
Dans l'optique ou ça impliquerait une bascule sur un modèle de ''do-ocraty'' à autre chose plus basé sur les besoins des institutions genre l'UE avec du budget, une évolution plus raisonnable et stable de GTK est envisageable. D'autant que c'est une demande d'autres projets comme Gimp par exemple, pas le moindre, qui se voient un peu envoyer dans les cordes avec leurs besoin à eux avec des réponse style ''on a pas forcément les moyens de maintenir les trucs dont vous avez besoin quand on fait évoluer les APIs'', c'est clairement un besoin qui dépasse le cadre de Gnome.
[^] # Re: Pourquoi dire IA si on ne parle que des réseaux de neurones ?
Posté par thoasm . En réponse à la dépêche Une intelligence artificielle libre est-elle possible ?. Évalué à 3.
Alors pour tester les IAs il vaut mieux bidouiller les énoncés du problèmes ou les garder secrets, on peut toujours soupçonner que si elles donnent la bonne réponse c'est pas tellement parce qu'elles l'ont inventées que plutôt parce que c'est une question classique et qu'elles ont "triché" en ayant déjà la question et la réponse dans leur corpus et qu'elles l'ont stockée.
[^] # Re: Pourquoi dire IA si on ne parle que des réseaux de neurones ?
Posté par thoasm . En réponse à la dépêche Une intelligence artificielle libre est-elle possible ?. Évalué à 3.
Ce n'est pas forcément tant une question de possibilité de raisonnement que de connaissance empirique du monde. Les corpus de données comprennent probablement relativement peu d'information sur la pratique du roulage de cigarette et de la fumette, c'est pas tellement un truc qui s'apprend dans les livres. A partir de là, si la connaissance nécessaire n'est pas là, forcément le raisonnement n'est pas possible.
Une énigme mathématique demandant le même genre d'astuce pourrait montrer que la possibilité de "raisonnement" est là, et qu'elle n'est pas débloquée dans ce cas précis faute de connaissance. Un autre niveau serait de montrer que la connaissance est là, question roulage de clope (ce qui n'est pas impossible) mais que le lien avec le raisonnement formel n'est pas là parce que le logiciel est incapable de formaliser par lui même de manière à débloquer la capacité de raisonnement.
C'est la question de la compositionnalité des capacités "générique" qui vient après la démonstration de certaines capacités dans l'abstrait de manière indépendante. Mais sortir du cadre, oui les IAs ont quand même en soit démontré certaines possibilités de ce côté là.
C'est des choses qui sont étudiées actuellement, en cherchant les mots clés rapidement je trouve https://arxiv.org/pdf/2402.08674 ce papier qui a l'air de faire de la "pédagogie" d'IA pour chercher dans quel ordre leur faire apprendre des trucs pour débloquer de la compositions de connaissances.
[^] # Re: Pourquoi dire IA si on ne parle que des réseaux de neurones ?
Posté par thoasm . En réponse à la dépêche Une intelligence artificielle libre est-elle possible ?. Évalué à 3.
Le fait que ce soit à base probabiliste ne nous donne pas vraiment d'informations sur la capacité à s'adapter facilement.
En particulier, pour calculer efficacement les probabilités dans un espace limité, avec un nombre de neurone contraint, il faut une forme de structuration de ces réseaux de neurones pour traîter l'information et en tirer des probabilités raisonnables. Cette structuration, pour fonctionner efficacement, ne doit-elle pas généraliser suffisamment pour s'adapter à d'autre problème ? La question n'est pas "proba ou pas" mais "comment ça généralise".
Exemple limite : un raisonnement mathématique. Prend un ensemble de démonstration mathématiques, à classer comme "correctes" ou "incorrecte", entraine le donc à discriminer le mathématiquement correct du mathématiquement incorrect. Les lois de la logiques ont des règles du jeu. Un réseau de neurone "séquentiel" peut en principe apprendre les différentes règles pertinentes, et classer leur application correcte ou pas, voire pointer directement les applications incorrectes.
Au cours de l'apprentissage, probabiliste, à force d'enquiller les démonstrations, il fait de moins en moins d'erreurs. C'est probabiliste. Une fois l'apprentissage terminé, on lui montre des démonstrations mathématiques, à classer en correctes et incorrectes. Dans le principe, il a "juste" à faire comme un correcteur humain, à vérifier pas à pas que les règles de la logiques sont respectées.
Sur ce principe, on part d'un apprentissage en mode probabiliste et on arrive à un résultat ou il n'y aura pas forcément d'erreurs … La question est, est-ce que ce résultat est crédible, et est-ce que la capacité à s'adapter très largement à une large classe de démonstration mathématique qu'il n'a pas vu n'est pas une preuve d'adaptation très importante ?
Tout ça pour dire que la dichotomie que tu fais n'en est pas forcément une, le mode "probabiliste" n'est pas incompatible avec l'adaptation (au contraire même, dans certains cas ça rend beaucoup plus robuste, c'est ce qui permet de généraliser et de discriminer petit à petit ce qui n'est pas important en en baissant petit à petit le poids). Alors qu'un raisonnement binaire sera impossible à généraliser si on sort un tantinet du cadre et sera inapplicable si on est pas pile poil dans le cadre déterminé à l'avance.
[^] # Re: Pourquoi dire IA si on ne parle que des réseaux de neurones ?
Posté par thoasm . En réponse à la dépêche Une intelligence artificielle libre est-elle possible ?. Évalué à 4.
On peut dire Apprentissage automatique pour du plus générique, ça donne ''l'apprentissage automatique libre'', ça a l'avantage de rendre le terme ''apprentissage'' (crucial dans la problématique) explicite, mais on perd le grand public assez largement.
Et ça insiste plus sur le processus d'apprentissage que sur le résultat, alors que ''IA'' ce serait l'inverse, ça désigne le résultat qui tourne.
[^] # Re: Clichés
Posté par thoasm . En réponse à la dépêche Programmer des démonstrations : une modeste invitation aux assistants de preuve. Évalué à 3.
Y a-t-il un développeur qui soit capable de trouver tous les bugs ? Est-il compris dans l'ensemble des développeurs capables de se corriger eux même ? Quid des bugs créés par des non développeurs ? Est-il un non développeur lui même ?
pars chercher un comprimé de paracétamol
[^] # Re: Après le point médian...
Posté par thoasm . 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. Dernière modification le 26 février 2025 à 19:08.
Et c'est raté, c'est un zéro Pointé.
[^] # Re: Copain de godot ?
Posté par thoasm . En réponse au lien The Museum of All Things. Évalué à 4.
Raté, ça a tourné un peu ailleurs aussi :)
L'autrice l'a annoncé sur bluesky par exemple https://bsky.app/profile/may.as/post/3lixmhyzfw22d et ça a un bon accueil.
[^] # Re: Après le point médian...
Posté par thoasm . 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é à 3.
Mais pas du tout Point d'exclamation
# Concept déclinable
Posté par thoasm . En réponse à la dépêche Réviser SQL en jouant au détective : SQLNoir. Évalué à 9.
Si ça se trouve ça se marierait bien avec une Wikibase, avec une édition des enquêtes en wiki façon Wikidata et SPARQL au lieux de SQL pour réviser son SPARQL.
https://www.wikibase.cloud/
Bonus : meta-enquête, qui a voulu brouiller les pistes en vandalisant les données de l'enquête ?
# Vidéo de démo / présentation
Posté par thoasm . En réponse au lien The Museum of All Things. Évalué à 3.
Posté sur un réseau social par l'autrice : https://bsky.app/profile/may.as/post/3lixmhyzfw22d
[^] # Re: Pour la complétude, j'ajoute le couple SPARK/Ada
Posté par thoasm . En réponse à la dépêche Programmer des démonstrations : une modeste invitation aux assistants de preuve. Évalué à 4.
C'est pas tout à fait le même niveau de généralité non ? Ici tu fixes un type pour A et B, Integer, on a au moins besoin de paramétrer la procédure, A et B sont dans les autres exemples des variables de types qu'on doit préciser lors de l'appel à la procédure.
[^] # Re: mode Brice on
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à -1.
Sinon question distinction, c'est très courant maintenant d'utiliser le mot clé "const" pour les variables immuables, il y a ça en C++ ou en javascript. Donc oui tu peux tenter de te distinguer mais ça va pas tellement être compris, o tempora, o maures.
[^] # Re: mode Brice on
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 0. Dernière modification le 25 février 2025 à 13:58.
Ah oui rien que ça, tu trolles naturellement ou tu te fais aider par une IA pour être aussi pertinent ? Tarte à la fraise (oui tu peux me la jeter au visage après) ?
[^] # Re: mode Brice on
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 3.
Une variable ne peut être affectée qu'une fois et ne plus changer de valeur. Par exemple un paramètre d'une fonction est affecté uniquement lors de l'appel de la fonction, et ne peut pas changer de valeur au cours de l'appel (il peut par contre devenir inaccessible).
Ce n'est pas vraiment contradictoire avec le fait d'être une variable, c'est comme en maths les paramètres de fonctions. Différents appels = différentes valeurs (variable), au cours d'un appel, ne change pas de valeur. Même principe que les variables déclarées "const" dans d'autres langages.
Et oui si tu fais une syncope rien qu'avec ça, formulation trollesque ou maladroite écartée, passe ton chemin ou évolue :p
[^] # Re: .
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 6.
Sans détails plus que ça c'est difficile d'évaluer l'ampleur de ce drâme !
On va laisser les gens travailler, déterminer les bouts de code essentiels, voir si c'est une si grosse partie de code que ça. Linux à sa propre lib de base, j'imagine qu'il la font évoluer aussi parfois tout le monde s'en fout.
Les communautés Rust et Linux vont aussi probablement être à l'écoute l'une de l'autre, on verra comment ils gèrent ce genre de contraintes, version ement, norme …
Comme le reste : le jeu en vaut-il la chandelle ? Quels sont les bénéfices, les problèmes (avérés) qui sont vraiment durs à résoudre en pratique, est-ce un vrai fardeau ou alors bof la vie normale de l'évolution d'un code de cette ampleur et pas tellement plus, les solutions trouvées …
On peut causer dans le vague et un certain purisme de propriétés attribuées au C longtemps, il a toujours sa sémantique qui permet de faire relativement n'importe quoi facilement sans contrôle ni garantie dans la balance. Il y a probablement un prix à payer pour mettre ce genre de garanties dans Linux. Mais vu que les devs qu'on ne peut pas soupçonner d'incompetences reconnaissent que ça cause des bugs qui sont un fardeau à traiter, un peu tout le temps, la question n'est pas vraiment de savoir si le C a une API qui a t'elle propriété …
C'est si le cout d'avoir ces garanties est si important que ça contrebalance les bénéfices, et si l'intégration est si compliquée que ça et si pénible à maintenir.
Oui il y aura des problèmes d'intégration logicielle, et des problèmes humains, surtout au début. Mais en vitesse de croisières, concrètement… Tu trouves du temps de debuggage contre quelques bonnes pratiques d'intégration et du versionnement des compilos Rust et un peu de dialogue entre les projets ? Linux n'est pas un programme si insignifiant que sa voie ne pèse pas dans la balance et que Rust leur dise "merde".
[^] # Re: Je n'ai pas noté pour 2 raisons, mas je pense qu'on peut en trouver d'autres.
Posté par thoasm . En réponse au lien « Et si 3 bulles financières américaines frappaient l'Europe ? ». Évalué à 6.
J'ai pertinenté parce que
[^] # Re: Et sinon
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 2.
C'est un peu l'étape d'après, si l'implicite est "si tu peux pas mettre de l'eau dans ton vin on va pas pouvoir continuer à travailler ensemble". Mais effectivement ils ont déjà causé en privé donc on a pas tout l'histo et l'implicite sous la main.
[^] # Re: Et sinon
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 1.
Disons que si tu te définis par une manière agressive d'interagir avec les autres qui leur pose problème à eux, alors que toi ça te va très bien, il y a probablement du réglage à faire de ton côté. Tu trouves intolérable d'être heurté dans ta sensibilité et impensable de changer alors que tu l'exiges des autres pour interagir avec toi alors que du côté des autres heurtés dans leur sensibilité c'est à eux de changer, c'est pas symétrique du tout.
Dans un projet l'objectif commun c'est de faire avancer les choses :)
[^] # Re: Et sinon
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 3.
C'est pas une demande de sa part, en l'occurrence, mais un principe ? D'une manière générale, adopter les méthodes qu'on condamne par ailleurs c'est pas forcément aller dans la bonne direction.
[^] # Re: .
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 6.
C'est pas un "hack", c'est juste que ces fonctions de la lib sont des primitives du langages, qui seront spécifiées comme à part entière du langage. L'implémentation, du coup, sera laissée libre au compilo et cette histoire de "fonction interne au compilo" n'a pas grand sens, c'est le cas de n'importe quel mot clé avec une sémantique donnée dans n'importe quel langage, c'est le compilo qui implémente la chose. Souvent la lib de base fait partie à part entière de la spec du langage, quand il y en a.
[^] # Re: Et sinon
Posté par thoasm . En réponse au journal Linus répond à la controverse sur R4L (Rust pour Linux). Évalué à 10.
Il peut y avoir une nuance entre "le problème c'est toi" et "le problème, c'est ta réaction en l'occurrence". Le premier est essentialisant, potentiellement, si tu tombes sur quelqu'un de sensible (tout le monde peut l'être à un moment) et sur un moment de fragilité "bon, si le problème c'est moi, à quoi bon, je laisse tomber", alors que si c'est simplement une manière d'agir, c'est pas ce qui te définit en tant que personne et c'est modifiable.
[^] # Re: Maintenant qu'on est vendredi...
Posté par thoasm . En réponse au journal Python à trou : trouve ton environnement. Évalué à 7.
Tu peux expérimenter avec des cgroups et des limites avec la commande systemd-run par exemple.
Lancer un shell avec max 50 sous-processus :
bash
systemd-run --scope -p TasksMax=50 --pty bash
[^] # Re: Mais sinon, Perl c'est pas lisible.
Posté par thoasm . En réponse au journal Python à trou : trouve ton environnement. Évalué à 5.
Trouve un casse tête prel pour comparer ?