Ça ferait une quinzaine de jours pour 256 octets, donc (en supposant que c'est linéaire)? C'est pas si long que ça, l'attaque ne se fait pas forcément en temps réel, mais peut être utilisée sur des données préalablement interceptées. Au bout de 15 jours je pense que certaines informations seront toujours valables et intéressantes.
Il n'y a pas vraiment une personne qui connaît tous les jeux derrière cette page. C'est généré à partir d'un projet Github (https://github.com/opengaming/osgameclones/) et c'est en ligne depuis quelques années. Et plein de gens (joueurs, développeurs de jeux, archivistes en herbe des internets, …) contribuent pour ajouter des jeux à la liste. Ça aurait pu trouver sa place sur wikidata ou quelque chose dans le même genre, peut être.
Les définitions de ce qui est "open source" et de ce qui est, ou pas, un "clone" sont en effet prises avec un sens assez large (mais je void qu'il y a maintenant des tags pour indiquer "remake", "clone", ou "similar").
Est-ce que XWiki pourrait remplacer Confluence, et sinon, qu'est-ce qui lui manque? Ça a l'air assez similaire mais j'ai peu utilisé Confluence et pas du tout XWiki pour l'instant.
Impossible de glisser les items dans la liste comme il est demandé: sur mon téléphone, la page scrolle en même temps…
Je regarderai demain depuis un ordinateur
On peut arrêter de parler de censure pour n'importe quoi? Facebook n'est pas un service public. Ils peuvent très bien décider ce qu'ils font apparaître sur leur site web ou pas.
Qu'ils fassent leur modération et leur sélection n'importe comment (de façon opaque et arbitraire), soit. Mais ce n'est pas de la censure.
Il y a la bitbox avec un CPU ARM à environ 130MHz (ça change en fonction du mode vidéo choisi) et des capacités graphiques quelque part entre l'Atari VCS 2600 et la MegaCD (beaucoup de choses étant faites en logiciel dans la bitbox, elle peut donc se programmer de plein de façons différentes selon les besoins).
Le matériel est relativement simple (il n'y a pas grand chose sur la carte à part le CPU et les connecteurs audio/video/usb) mais pas évident à assembler soi même si on a pas l'habitude de manipuler un fer à souder (composants montés en surface et de petite taille).
Le projet semble ne plus trop évoluer ces derniers temps. Peut être que je me remettrai un jour à programmer des choses pour la bitbox.
Oui, je n'ai pas précisé mais ce message était dans un esprit de "il faut connaîtreses ennemis". C'est pas parce que c'est pas libre qu'il n'y a que des mauvaises idées dedans, et, à défaut de pouvoir réutiliser le code, on peut au moins récupérer les idées.
Enfin bref, je ne comprend pas que ça ne soit pas une fonctionnalité par défaut de n'importe quel navigateur et qu'il soit nécessaire de jongler avec des outils comme youtube-dl ou des extensions.
Le navigateur web Vivaldi a un menu clic droit->enregistrer la vidéo (comme pour les images dans les autres navigateurs). Pourquoi faire simple quand on peut faire compliqué?
Difficile de voir ce à quoi la lettre fait références pour ces 3 vidéos, il est question d'un "exhibit A" mais je ne vois pas de lien ou de pièce jointe.
C'est mal connaître le travail que font les gens de CentOS, sans support de RedHat, pour arriver à tout compiler. Plusieurs mois de travail à chaque nouvelle version de RedHat.
Donc, certes, Microsoft a publié seulement une petite partie de son code, et RedHat a publié seulement une grande partie de son code. Mais le principe est le même, et d'un point de vue légal et droits de distribution, c'est pareil.
La question est juste: combien de temps avant que Microsoft ne rattrape RedHat? On a vu avec une récente fuite du code de Windows XP que des gens étaient capables de le recompiler sans trop de problèmes. Peut être que c'est moins loin qu'on le pense pour les versions suivantes…
Tu ne peux pas comparer le marché des navigateurs en 2004, où Microsoft avait abandonné le développement d'Internet Explorer et que Firefox n'avait pas vraiment de concurrents
Ça m'étonne toujours le silence sur Safari dans ces discussions (apparu en 2003, version Windows de 2007 à 2012). Pourtant il a aussi bien fait bouger les choses.
La compression c'est tout le contraire du bas niveau. C'est justement un truc purement algorithmique et indépendant du matériel.
Si le problème était résolu, on aurait un algo super efficace de la mort qui tue et il serait implémenté par le premier disque dur/ssd/carte sd venue (qui ne voudrait pas faire x2 sur sa capacité de stockage affichée?). A priori ce n'est pas le cas.
En télécom, on utilise la compression (et ça fait partie de la formation, en tout cas y'a 10 ans quand j'étais étudiant?) mais on a des problématiques qui font qu'on ne peut pas forcément atteindre les limites théoriques: contraintes de temps réel, de limitations matérielles (taille de la mémoire disponible) et de latence. En gros, on ne peut pas attendre d'avoir 4Go de données à envoyer pour les compresser de façon optimale, on est obligés de traiter ça en flux au fur et à mesure que les données arrivent.
Après, oui, y'a plein de cas ou il n'y a pas besoin de compression à proprement parler (ça peut être suffisant d'utiliser un format approprié pour les données, ou il y aura déjà peu de redondance), ou alors, on peut utiliser un algorithme existant qui fonctionnera très bien pour les besoins identifiés. Ou bien on peut tomber sur des cas tordus, par exemple dans Haiku on a un gestionnaire de paquets qui a besoin de faire des accès aléatoires au contenu du paquet. Actuellement l'approche utilisée est de découper le paquet en blocs de 4K et de compresser chaque bloc séparément, et c'est pas hyper efficace. Y'a probablement mieux comme algo de compression qui permet de décompresser une partie aléatoire du flux (sans décompresser tout ce qu'il y a avant), non? Des suggestions?
Un des gros problème d'Apple que j'ai pu rencontrer est sa gestion du maintien d'une connexion permanente qui nécessite un serveur de push et des contorsions complexes pour passer par dessus les barrières mises en place par cet écosystème privateur.
Le problème est lié à l'utilisation de connexions persistantes TCP en général sur les terminaux mobiles.
En gros, avoir une connection TCP qui reste ouverte en permanence, ça oblige à envoyer des données et à rester tout le temps à l'écoute, ça empêche l'appareil de se mettre en veille, et donc ça vide la batterie.
Le problème est le même avec n'importe quel OS.
La solution proposée (aussi bien pour Apple que Android) ce sont effectivement les "push notifications" qui évitent d'avoir une connexion ouverte en permanence pour chaque application. La XSF se penche sur le sujet, a priori le point d'entrée est https://xmpp.org/extensions/xep-0286.html avec des liens vers plusieurs autres XEP donnant les bonnes pratiques pour un client fonctionnant sur ce type de réseau.
Prenons-en quelques unes qui rentrent dans le sujet:
- Manger du poulet augmente les importations de pétrole brut
- La production d'énergie nucléaire augmente le risque de mort par noyade dans une piscine
- Stocker de l'uranium dans les centrales nucléaires augmente le nombre de doctorats en mathématiques
(et inversement, bien sûr, puisque la corrélation n'implique pas la causation, ni dans un sens, ni dans l'autre)
Çadépend des endroits. Chez moi il y a des heures creuses la nuit (de 4h à 7h, je crois) mais aussi dans l'après-midi (14h30-16h30).
C'est ajusté en fonction de la consommation électrique locale, le but étant de lisser la consommation sur la journée.
Il est possible pour enedis (ou edf, j'ai du mal à suivre qui fait quoi) de changer les horaires et techniquement ils pourraient le faire de façon dynamique, le compteur électrique signale le passage en heures creuses et les appareils ménagers le détectent pour se déclencher.
C'est donc envisageable de le faire en fonction de la consommation effective plutôt que d'horaires fixes.
La compression consiste à supprimer ou réduire la redondance des données.
Ne pas stocker/transmettre 2 fois la même chose
Ne pas stocker/tranmettre ce qui n'a pasbesoin de l'être
On peut regarder du côté de la théorie de l'information et la façon dont on peut définir la quantité d'information présente dans une donnée quelconque, en étudiant la probabilité dechaque bit d'être un 0 ou un 1, en fonction des bits précédents et de toute autre connaissance du récepteur de la donnée. Ce qui donne une limite théorique à la réduction de taillle qu'on peut obtenir, si on atteint le fomat de compression idéal ou chaque bit a exactement une probabilité de 0.5 d'être un 0 ou un 1.
Euh, Zstd, développé par Facebook pour avoir un truc plus rapide et plus efficace que la zlib?
Alors oui si on regarde le web frontend, le desktop et les applis mobiles, en ce moment, c'est pas trop l'aspect privilégié. Mais ça ne veut pas dire que les compétences sont perdues, seulement qu'il y a des endroits ou ça n'est pas justifié/pas rentable de le faire.
Le logiciel embarqué a toujours des contraintes, mais pas forcément les mêmes. Pour gagner en durée de batterie sur un téléphone, il vaut mieux avoir des données moins compressées mais accessibles sans faire plein de calculs cpu pour les décoder, par exemple.
Pendant le mois de septembre 2020, près d'une vingtaine de nouvelles oeuvres de la demoscene dans les catégories <= 4Ko (je ne sais pas d'ou sort cette histoire de 5Ko, ça fonctionne par multiples de 2 bien sûr).
La page de LZSA donne une comparaison des différents outils souvent utilisés, en terme d'efficacité de la compression ainsi que du temps de décompression.
Dire que "cet art noble du hacker s'est perdu", ça me semble… quelque peu exagéré, au moins.
(ce ne sont pas forcément les algorithmes les plus efficaces en terme de taille économisée, il y a des compromis pour garder une vitesse de décompression acceptable y compris pour des CPUs peu performants).
[^] # Re: Un peu d'histoire à la Higgins et café du commerce, et du troll velu et méchant ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal COBOL : c'est dans les vieilles marmites.... Évalué à 5.
Depuis quand c'est un langage de programmation qui doit encadrer les stagiaires? C'est pas plutôt le rôle du maître de stage?
[^] # Re: Efficacité limitée
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Nouvelle faille découverte sur les CPU Intel via l'implémentation RAPL . Évalué à 3.
Ça ferait une quinzaine de jours pour 256 octets, donc (en supposant que c'est linéaire)? C'est pas si long que ça, l'attaque ne se fait pas forcément en temps réel, mais peut être utilisée sur des données préalablement interceptées. Au bout de 15 jours je pense que certaines informations seront toujours valables et intéressantes.
[^] # Re: bien
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Liste des clones de jeux connus. Évalué à 5.
Il n'y a pas vraiment une personne qui connaît tous les jeux derrière cette page. C'est généré à partir d'un projet Github (https://github.com/opengaming/osgameclones/) et c'est en ligne depuis quelques années. Et plein de gens (joueurs, développeurs de jeux, archivistes en herbe des internets, …) contribuent pour ajouter des jeux à la liste. Ça aurait pu trouver sa place sur wikidata ou quelque chose dans le même genre, peut être.
Les définitions de ce qui est "open source" et de ce qui est, ou pas, un "clone" sont en effet prises avec un sens assez large (mais je void qu'il y a maintenant des tags pour indiquer "remake", "clone", ou "similar").
[^] # Re: Précisions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Migration de Jira à Tuleap : nouvelle fonctionnalité. Évalué à 2.
Est-ce que XWiki pourrait remplacer Confluence, et sinon, qu'est-ce qui lui manque? Ça a l'air assez similaire mais j'ai peu utilisé Confluence et pas du tout XWiki pour l'instant.
# Glisser déposer sur téléphone
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Votez pour les choix graphiques de la prochaine version stable de Debian, Bullseye jusqu'au 09/11/20. Évalué à 2.
Impossible de glisser les items dans la liste comme il est demandé: sur mon téléphone, la page scrolle en même temps…
Je regarderai demain depuis un ordinateur
# Payback
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien vieux (2008) mais amusant : « Ma vraie histoire de Grand Theft Auto ». Évalué à 4.
Ça me rapelle qu'il existe un clone de GTA pour Amiga: Payback. Mais ça ne tourne pas sur un Amiga en configuration de base.
# Censure?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Nouveau cas de censure de Facebook: le journal en ligne Rapport de forces en est totalement évincé. Évalué à 8.
On peut arrêter de parler de censure pour n'importe quoi? Facebook n'est pas un service public. Ils peuvent très bien décider ce qu'ils font apparaître sur leur site web ou pas.
Qu'ils fassent leur modération et leur sélection n'importe comment (de façon opaque et arbitraire), soit. Mais ce n'est pas de la censure.
[^] # Re: Combien de bits?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Construisez et programmez votre console de jeux open source. Évalué à 5.
Il y a la bitbox avec un CPU ARM à environ 130MHz (ça change en fonction du mode vidéo choisi) et des capacités graphiques quelque part entre l'Atari VCS 2600 et la MegaCD (beaucoup de choses étant faites en logiciel dans la bitbox, elle peut donc se programmer de plein de façons différentes selon les besoins).
Le matériel est relativement simple (il n'y a pas grand chose sur la carte à part le CPU et les connecteurs audio/video/usb) mais pas évident à assembler soi même si on a pas l'habitude de manipuler un fer à souder (composants montés en surface et de petite taille).
Le projet semble ne plus trop évoluer ces derniers temps. Peut être que je me remettrai un jour à programmer des choses pour la bitbox.
[^] # Re: Alternatives ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 4. Dernière modification le 25 octobre 2020 à 23:17.
Oui, je n'ai pas précisé mais ce message était dans un esprit de "il faut connaîtreses ennemis". C'est pas parce que c'est pas libre qu'il n'y a que des mauvaises idées dedans, et, à défaut de pouvoir réutiliser le code, on peut au moins récupérer les idées.
Enfin bref, je ne comprend pas que ça ne soit pas une fonctionnalité par défaut de n'importe quel navigateur et qu'il soit nécessaire de jongler avec des outils comme youtube-dl ou des extensions.
[^] # Re: Alternatives ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 2.
Le navigateur web Vivaldi a un menu clic droit->enregistrer la vidéo (comme pour les images dans les autres navigateurs). Pourquoi faire simple quand on peut faire compliqué?
[^] # Re: N'ont-ils pas donné à la RIAA tout ce qu'il faut?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 4.
A priori, les tests unitaires utilisent des vidéos de test de ce type: https://www.youtube.com/watch?v=BaW_jenozKc et de même pour les exemples dans la documentation.
Difficile de voir ce à quoi la lettre fait références pour ces 3 vidéos, il est question d'un "exhibit A" mais je ne vois pas de lien ou de pièce jointe.
[^] # Re: Ras le bol de ces noms de langage de merde!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ras le bol de ces moteurs de merde!. Évalué à 4.
D'un autre côté… faire des trucs impossible à retrouver via un moteur de rechercqe, ça oblige les gens à savoir utiliser les URLs et les bookmarks :o)
[^] # Re: C'est foutu !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien No, Microsoft is not rebasing Windows to Linux. Évalué à 4.
C'est mal connaître le travail que font les gens de CentOS, sans support de RedHat, pour arriver à tout compiler. Plusieurs mois de travail à chaque nouvelle version de RedHat.
Donc, certes, Microsoft a publié seulement une petite partie de son code, et RedHat a publié seulement une grande partie de son code. Mais le principe est le même, et d'un point de vue légal et droits de distribution, c'est pareil.
La question est juste: combien de temps avant que Microsoft ne rattrape RedHat? On a vu avec une récente fuite du code de Windows XP que des gens étaient capables de le recompiler sans trop de problèmes. Peut être que c'est moins loin qu'on le pense pour les versions suivantes…
[^] # Re: Plus de Firefox pour moi
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Histoire des systèmes d’extensions de Firefox. Évalué à 3.
Ça m'étonne toujours le silence sur Safari dans ces discussions (apparu en 2003, version Windows de 2007 à 2012). Pourtant il a aussi bien fait bouger les choses.
[^] # Re: C'est foutu !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien No, Microsoft is not rebasing Windows to Linux. Évalué à 5.
D'ailleurs tout le monde sait que Wine n'existe pas, ce qui démontre bien que lancer les applications Windows sous Linux est impossible.
[^] # Re: Comment ça perdu?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 5.
La compression c'est tout le contraire du bas niveau. C'est justement un truc purement algorithmique et indépendant du matériel.
Si le problème était résolu, on aurait un algo super efficace de la mort qui tue et il serait implémenté par le premier disque dur/ssd/carte sd venue (qui ne voudrait pas faire x2 sur sa capacité de stockage affichée?). A priori ce n'est pas le cas.
En télécom, on utilise la compression (et ça fait partie de la formation, en tout cas y'a 10 ans quand j'étais étudiant?) mais on a des problématiques qui font qu'on ne peut pas forcément atteindre les limites théoriques: contraintes de temps réel, de limitations matérielles (taille de la mémoire disponible) et de latence. En gros, on ne peut pas attendre d'avoir 4Go de données à envoyer pour les compresser de façon optimale, on est obligés de traiter ça en flux au fur et à mesure que les données arrivent.
Après, oui, y'a plein de cas ou il n'y a pas besoin de compression à proprement parler (ça peut être suffisant d'utiliser un format approprié pour les données, ou il y aura déjà peu de redondance), ou alors, on peut utiliser un algorithme existant qui fonctionnera très bien pour les besoins identifiés. Ou bien on peut tomber sur des cas tordus, par exemple dans Haiku on a un gestionnaire de paquets qui a besoin de faire des accès aléatoires au contenu du paquet. Actuellement l'approche utilisée est de découper le paquet en blocs de 4K et de compresser chaque bloc séparément, et c'est pas hyper efficace. Y'a probablement mieux comme algo de compression qui permet de décompresser une partie aléatoire du flux (sans décompresser tout ce qu'il y a avant), non? Des suggestions?
[^] # Re: Et du coup, pour remplacer Whatsapp & autres
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche XMPP croque la pomme !. Évalué à 7.
Le problème est lié à l'utilisation de connexions persistantes TCP en général sur les terminaux mobiles.
En gros, avoir une connection TCP qui reste ouverte en permanence, ça oblige à envoyer des données et à rester tout le temps à l'écoute, ça empêche l'appareil de se mettre en veille, et donc ça vide la batterie.
Le problème est le même avec n'importe quel OS.
La solution proposée (aussi bien pour Apple que Android) ce sont effectivement les "push notifications" qui évitent d'avoir une connexion ouverte en permanence pour chaque application. La XSF se penche sur le sujet, a priori le point d'entrée est https://xmpp.org/extensions/xep-0286.html avec des liens vers plusieurs autres XEP donnant les bonnes pratiques pour un client fonctionnant sur ce type de réseau.
En particulier pour les push notifications: https://xmpp.org/extensions/xep-0357.html
[^] # Re: Divorce et margarine
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Manger du chocolat rapporte des prix Nobel. Évalué à 2.
Prenons-en quelques unes qui rentrent dans le sujet:
- Manger du poulet augmente les importations de pétrole brut
- La production d'énergie nucléaire augmente le risque de mort par noyade dans une piscine
- Stocker de l'uranium dans les centrales nucléaires augmente le nombre de doctorats en mathématiques
(et inversement, bien sûr, puisque la corrélation n'implique pas la causation, ni dans un sens, ni dans l'autre)
[^] # Re: Précision
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Énergies renouvelables - Une centrale solaire aussi puissante (2.2 GW) que 2 réacteurs nucléaires. Évalué à 3.
Çadépend des endroits. Chez moi il y a des heures creuses la nuit (de 4h à 7h, je crois) mais aussi dans l'après-midi (14h30-16h30).
C'est ajusté en fonction de la consommation électrique locale, le but étant de lisser la consommation sur la journée.
Il est possible pour enedis (ou edf, j'ai du mal à suivre qui fait quoi) de changer les horaires et techniquement ils pourraient le faire de façon dynamique, le compteur électrique signale le passage en heures creuses et les appareils ménagers le détectent pour se déclencher.
C'est donc envisageable de le faire en fonction de la consommation effective plutôt que d'horaires fixes.
[^] # Re: ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 10.
En tout cas il y a toujours autant de grincheux qui pensent que c'était mieux avant!
[^] # Re: Travaux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 2.
La compression consiste à supprimer ou réduire la redondance des données.
On peut regarder du côté de la théorie de l'information et la façon dont on peut définir la quantité d'information présente dans une donnée quelconque, en étudiant la probabilité dechaque bit d'être un 0 ou un 1, en fonction des bits précédents et de toute autre connaissance du récepteur de la donnée. Ce qui donne une limite théorique à la réduction de taillle qu'on peut obtenir, si on atteint le fomat de compression idéal ou chaque bit a exactement une probabilité de 0.5 d'être un 0 ou un 1.
[^] # Re: Comment ça perdu?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 2.
Euh, Zstd, développé par Facebook pour avoir un truc plus rapide et plus efficace que la zlib?
Alors oui si on regarde le web frontend, le desktop et les applis mobiles, en ce moment, c'est pas trop l'aspect privilégié. Mais ça ne veut pas dire que les compétences sont perdues, seulement qu'il y a des endroits ou ça n'est pas justifié/pas rentable de le faire.
Le logiciel embarqué a toujours des contraintes, mais pas forcément les mêmes. Pour gagner en durée de batterie sur un téléphone, il vaut mieux avoir des données moins compressées mais accessibles sans faire plein de calculs cpu pour les décoder, par exemple.
[^] # Re: ça n'avance pas tellement
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Darling, Lamulateur de MacOS X pour linux. Évalué à 5.
Ou peut-être que le code fonctionne parfaitement et qu'il n'y a pas besoin de faire de changements.
Personellement, voir des douzaines de commits par jour sur un projet ne me rassure pas quant à sa maturité et stabilité :)
# Comment ça perdu?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 10.
Pendant le mois de septembre 2020, près d'une vingtaine de nouvelles oeuvres de la demoscene dans les catégories <= 4Ko (je ne sais pas d'ou sort cette histoire de 5Ko, ça fonctionne par multiples de 2 bien sûr).
La page de LZSA donne une comparaison des différents outils souvent utilisés, en terme d'efficacité de la compression ainsi que du temps de décompression.
Dire que "cet art noble du hacker s'est perdu", ça me semble… quelque peu exagéré, au moins.
(ce ne sont pas forcément les algorithmes les plus efficaces en terme de taille économisée, il y a des compromis pour garder une vitesse de décompression acceptable y compris pour des CPUs peu performants).
# Ça peut arriver à tout le monde
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le câblage enterré innovant. Évalué à 10.
Il est enterré à -30cm de profondeur, ça peut arriver à tout le monde une erreur de signe sur ce genre de chose.