pulkomandy a écrit 1703 commentaires

Le système crée lui-même son propre bruit, avec les discussions sur les notes, les accusations de cabale, des gens qui chouinent sur des méchants qui moinsseraient à vue au lieu de se demander s’il n’y aurait pas une vraie raison à ces notes négatives, etc.

En fait c'est ça le plus gros problème. Du coup je propose qu'on supprime les journaux qui parlent des notes, puisqu'on sait très bien que les notes ne seront jamais supprimées de toutes façons et qu'elle n'ont aucun effet comme tu l'as très bien expliqué.

Sur la question d'une carte de type SunPCI: je ne vois pas vraiment de problème supplémentaires sur les machines actuelles par rapport à celles de Sun. Mais le résultat sera tout aussi boiteux qu'à l'époque.

La carte n'est pas 100% compatible avec un PC normal, il y a besoin de plein de patchs dans Windows ou DOS pour la faire fonctionner, et le système pour intégrer l'image du système PC sur la station SPARC fonctionne mal, il vaut mieux passer par le port VGA dédié de la carte SunPCI avec un deuxième écran ou un boîtier commutateur pour switcher entre les deux.

Donc, oui, c'est faisable, mais l'intégration avec le système hôte pose pas mal problème. Peut être que ça marcherait mieux pour un OS moderne (pas Windows 3.11), où les applications font moins d'accès direct au matériel et on a peut-être une chance de tout intercepter au niveau des drivers.

Mais est-ce que ça vaut vraiment la peine de faire tout ça?

Quand j'ai besoin de gérer des signaux sous Linux, je le fait plutôt à l'aide d'tn signalfd qui permet de récupérer les évènements via un descripteur de fichiers et de les faire rentrer dans ma boucle d'évènements avec tous les autres trucs que mon code doit traiter. Ça rend pour moi les choses beaucoup plus simples, mais le traitement un petit peu moins immédiat.

Mais si le code est architecturé comme il faut, ça se comptera au pire en centaines de millisecondes.

Il y a aussi les signaux entre SIGRTMIN et SIGRTMAX qui sont disponibles. Ça en fait une trentaine de plus sous Linux.

Les optimisations sont déjà possibles en activant la "link time optimisation". Dans ce cas, les fichiers .o générés à partir de chaque .c contiennent un dump de l'AST plutôt que du code assembleur généré. Et c'est le linker qui finit le travail.

Mais ça pose 2 problèmes:

• Par rapport aux "jumbo builds", on ne gagne pas de temps à re-parser les fichiers .h qui sont inclus plusieurs fois
• La phase de link prend beaucoup de temps (puisque c'est à ce moment qu'on fait "vraiment" la compilation dans ce cas). Et cette phase est relancée systématiquement à chaque compilation pour le moindre changement d'un seul fichier

Donc ce n'est pas utile pour un build rapide.

Une approche intéressante serait peut-être d'avoir un "serveur" de compilation, un outil qui reste chargé en mémoire et qui conserve des morceaux de code précompilés, et qui recompile les parties nécessaires dès qu'on enregistre une modification sur un fichier. Un mélange de make, gcc et ccache avec des morceaux de distcc dedans? Mais ça remet beaucoup de choses en question, et quand on en arrive là, il faut peut-être se demander si on ne devrait pas passer à de la compilation just-in-time?

Le problème sur la NES est un peu compliqué, en résumé:

• Sur la console originale, le port cartouche était sur le dessus et il n'y avait pas de protection contre la copie et pas de problème
• Sur la NES, les cartouches contiennent un composant de protection contre la copie
• Avec un port cartouche classique sur le dessus de la console, il serait facile pour un fabricant de cartouches pirates de fabriquer une cartouche dans laquelle on connecte une deuxième cartouche (originale). Ainsi, la puce de protection contre la copie de la cartouche originale est utilisée avec le jeu pirate
• Pour éviter ça, le port cartouche est caché dans la console et protégé avec une trappe et un mécanisme de charnière. Impossible d'insérer 2 cartouches connectées ensemble
• Ce mécanisme fait que la cartouche va légèrement forcer sur le connecteur dans la console et petit à petit, le déformer et rendre le contact moins efficace

Conclusion: c'est la faute des DRM et de l'obsolescence programmée.

Quant à la question sur la disponibilité des consoles: il n'est pas très difficile même aujourd'hui de trouver des consoles compatibles avec les cartouches de la NES. Des composants compatibles (appelés "NES on a chip") sont toujours fabriqués. En fait, certains ajoutent des fonctionalités supplémentaires tout en restant compatibles avec les jeux existants. L'avenir est donc assuré :)

Il y a aussi The toaster project ou l'auteur s'est dit: "tiens, si j'essayais de fabriquer un grille-pain en partant de rien, en allant chercher les matériaux nécessaires dans des mines?"

La conclusion est qu'il faut avoir beaucoup de temps à perdre, même en trichant sur plusieurs étapes (par exemple, il utilise un four à micro-ondes pour l'une des étapes de fabrication).

L'informatique, ça s'apprend.

Je crois que je suis passé à l'école au bon moment (fin des années 90/début 2000) et j'ai appris les bases de l'informatique: les fichiers, le traitement de texte, un peu de tableur, et même à monter un site internet avec un éditeur wysiwyg et un client ftp. J'ai aussi appris à utiliser un fer à souder pour monter des circuits électroniques.

Quelques années avant, tout ça n'était pas enseigné à l'école ou au collège. Et quelques années après, je crois que ça a disparu, les gens pensant, apparament, que les enfants nés après 2800 ont toujours eu un téléhhone à la main et du coup ils sont capables de lire le code de la Matrice à l'oeuil nu. Et ben non, ça s'apprend et il faudrait remettre en place quelques cours d'informatique si on veut que les gens y comprennent quelque chose.

half-sunken ship

Il me semble (mais ça fait un petit moment que je n'ai pas relu ces livres…) que Atrus a essayé d'écrire une île avec un bateau déjà construit pour pouvoir facilement explorer l'océan autour.

Mais ça n'a pas fonctionné, et à la place, le bateau est étrangement fusionné avec la côte de l'île. Et ne peut pas servir à naviguer.

ça ne sera pas un TPM mais par exemple une carte à puces (accessible avec PC/SC) ou une Yubikey. Les outils et bibliothèques à utiliser ne sont pas les mêmes, ça serait trop facile :(

La commission ne se réunit que tous les 6 mois normalement. De là, 2 options possibles par exemple :

• La pétition atteint le nombre de signatures nécessaires et doit être examinée cette fois-ci,
• Le gouvernement organise une réunion spéciale de la commission pour classer la pétition à nouveau (mais ça va se voir qu'ils y mettent de la mauvaise volonté, non?)

Ça marche aussi pour les associations "d'intérêt général", qui doivent juste respecter quelques critères sans avoir besoin de démarches particulières. En cas de doute on peut demander à la préfecture de vérifier si une association est vraiment d'intérêt général, mais cette vérification n'est pas obligatoire.

On peut utiliser autre chose qu'UML, par exemple le langage SDL: https://en.wikipedia.org/wiki/Specification_and_Description_Language est plus adapté pour des processus qui s'échangent et réagissent à des messages.

On commence à avoir des retours un peu critiques sur Rust de gens qui l'ont suffisament utilisé pour voir où sont ses limites, et dans quels cas il vaut mieux choisir un autre langage. C'est plutôt bon signe pour la maturité du langage.

Je n'ai pas trouvé ça exagéré, l'auteur s'est volontairement placé dans une situation où il savait que Rust allait poser problème, pour voir comment un autre langage pouvait s'y prendre dans ce cas précis. ÇA ne remet pas en cause l'utilisation de Rust dans plein d'autres cas (tous ceux où il n'y a pas besoin d'écrire de code "unsafe", c'est à dire probablement une très grande partie du code, tout le monde n'écrit pas des allocateurs ramasse-miettes, des machines virtuelles ou des systèmes d'exploitation).

Il faut voir ce qu'on entend par "à proximité". À Toulouse il existe un réseau de chaleur alimenté entre autres par un incinérateur de déchets (et aussi des datacenters et d'autres choses). Il a été mis en place en 1965 et étendu plusieurs fois depuis.

La carte présentée ici: https://eneriance.fr/qui-sommes-nous/histoire-et-chiffres-cles/ montre qu'il dessert une grande partie de la ville. Donc il semblerait que "à proximité" ça se compte en kilomètres et que ça permet de couvrir une ville de taille respectable.

Et il y a une extension pour desservir d'autres quartiers de l'autre côté de la Garonne: https://www.toulouseenergiedurable.fr/plan-du-reseau-toulouse-energie-durable/

Mettre les incinérateurs de déchets parmi les énergies décarbonées me semble quand même un peu… exagéré? Brûler des déchets ça émet du CO2.

Oui, par défaut ce sont les cycles CPU, mais dans l'article je n'ai pas vu de précision sur ce qui est fait avec perf (et c'est un outil qui peut faire beaucoup d'autres choses).

Justement, ma question est de savoir précisément ce qui est mesuré avec perf. Dans la commande "time" on a droit à 3 mesures:

• Le temps "user": temps passé à exécuter du code utilisateur
• Le temps "system": temps passé à exécuter du code du noyau (appels système)
• Le temps "real": temps total de l'exécution

On peut soustraire les deux premiers au troisième pour avoir le temps passé à ne pas exécuter de code du processus concerné (autres tâches en cours d'exécution, attente sur les entrées-sorties, etc).

Avec le compteur "cycles" de perf, on mesure au mieux les deux premiers, mais pas le troisième. Et donc le temps passé à ne pas exécuter de code n'est pas identifié. Je n'ai pas trouvé dans l'article ni dans le dépôt git du benchmark si tu as regardé la commande "time" pour voir si le code passe surtout du temps à s'exécuter ou surtout du temps à attendre les entrées-sorties. Ça peut être pas mal de vérifier ça pour s'assurer qu'on optimise au bon endroit. Si le programme est limité par les entrées-sorties, les gains en utilisation CPU ne seront pas visibles sur le throughput ou le temps d'exécution total pour un test donné (mais ils seront visibles sur la charge CPU et la consommation électrique).

Pour mesurer le temps passé ailleurs que dans le code avec perf: par exemple, en utilisant les évènements "syscalls:sys_enter_" on peut profiler tous les endroits qui font des appels systèmes (ce qui est en général assez coûteux, ça se place quelque part entre un appel de fonction et un switch de contexte pour exécuter un autre processus). Les évènements "block:" peuvent aussi être utiles pour regarder les entrées-sorties sur disque. On s'éloigne vite du C++ pour entrer dans les détails de la programmation système UNIX, mais ça peut être intéressant.

Pour les claviers, c'est pour réduire les coûts. Jusqu'à il y a pas longtemps, les claviers de PC portables étaient encore avec le protocole PS/2. Ça gère mal la mise en veille, ça demande des broches d'entrée/sortie dédiées, etc. Ça a été remplacé par de l'i2c qui est relié sur le même bus que les capteurs de température (entre autres) et le protocole haut niveau utilisé est proche de celui de l'USB et donc beaucoup plus flexible (pour avoiredes commandes standardisées pour des LEDs RGB par exemple)

Pour les touchpads, l'utilisation du PS/2 était vraiment tordue pour gérer la rétrocompatibilité avec une souris classique et contourner les bugs des interfaces ps/2 des différents chipsets. Et en plus de ça, utiliser de l'i2c permet plus de liberté sur les infos retournées et un plus haut débit. Donc on peut faire du "vrai" multipoints, ou le touchpad remonte au driver la position de tous les doigts et laisse le système traiter ces infos directement. Au lieu de les convertir en évènements de défilement, etc pas du tout configurables dans le firmware du touchpad.

Alors oui, c'est pénible de devoir refaire un driver. Mais moins que de maintenir le driver pour les vieux trucs ps/2, à long terme.

Est-ce que les mesures faites avec perf prennent en compte uniquement le temps cpu utilisé? Il y a peut-être pas mal de performances à gagner sur les entrées/sorties, en particulier en utilisant de façon intelligente les buffers proposés par fstream. Mais pour ça il faut mesurer le temps "réel" et pas le temps "user". Il me semble que c'est faisable avec perf en changeant quelques options.

J'ai eu des gains très importants en creusant de ce côté sur un de mes projets, mais c'était sur un système embarqué avec du stockage eMMC et un système de fichier f2fs. Peut-être sur un PC portable, les IO sont beaucoup plus rapides?

(note: le lien est indiqué en français, mais il est en anglais)

Parce que, pour que cette image puisse s’afficher correctement, le nom du fichier doit être en caractère ASCII (latin 1), pas d’accents ou de fioritures dans ce genre.

Soit c'est en ASCII et on ne peut pas mettre d'accents. Soit c'est en Latin-1 (de son vrai nom ISO-8859-1) et on peut mettre les accents nécessaires pour les principales langues Européennes écrites avec l'alphabet latin.

Encore une étude qui fait des statistiques uniquement sur GitHub, mais qui présente ses résultats comme si c'était fait sur tout l'écosystème opensource?

J'en profite pour re-partager cette image extraite d'un livre sur la programmation Forth qui ne se privait pas de taper sur les développeurs BASIC et leur code spaghetti:

Oui, ça devenait trop compliqué sinon. Peut être en retournant un std::wstring_view?

Et ma version fait n'importe quoi si on demande un progress supérieur à 1 ou négatif ou…

Comme quoi l'implémentation proposée n'est probablement pas la plus bête.

Au passage j'ai découvert quelques trucs sur la gestion des chaînes de wchar_t que je ne manipule pas souvent:

• On ne peut pas faire un printf avec un %ls pour afficher un wchar_t, ou en tout cas ça fait des trucs bizarres avec le modificateur de longueur, un %.10ls n'affiche pas 10 caractères. Avec wprintf ça semble fonctionner.
• Il faut faire un setlocale, sinon le printf ou wprintf refuse d'afficher la chaîne. Je ne savais pas que printf pouvait retourner une erreur (en y réfléchissant ça semble logique, mais je m'étais pas posé la question).

Allez je tente une version sans conditions et sans boucles:

#include <locale.h>
#include <math.h>
#include <stdio.h>
#include <wchar.h>

static const wchar_t* const progressBar = L"🔵🔵🔵🔵🔵🔵🔵🔵🔵🔵⚪⚪⚪⚪⚪⚪⚪⚪⚪⚪";

void GetPercentageRounds(double progress)
{
    int intProgress = round(progress * 10);
    wprintf(L"%-.10ls (%lf)\n", &progressBar[10 - intProgress], progress);
}

int main () {
    setlocale(LC_ALL, "");

    for (double progress = 0; progress < 1; progress += 0.1)
        GetPercentageRounds(progress);
}

En théorie oui, mais en pratique pas vraiment.

Le préprocesseur C (cpp) est de plus en plus intégré avec la suite de la compilation. Par exemple in insère des directives permettant au compilateur de savoir à quelle ligne de quel fichier le code se trouvait avant le pré-processing, ce qui permet d'afficher des messages d'erreurs avec les bons noms de fichiers et numéros de lignes.

La plupart des langages de programmation n'apprécient pas trop de se retrouver avec des #file et des #line un peu partout dans le code.

Avec m4, ça fonctionne, mais la syntaxe de m4 fait que l'intégration avec autre chose peut vite être compliquée. On a vite fait de se retrouver avec une macro qui est remplacée à un endroit où on ne voulait pas. Et puis la syntaxe ne fait pas vraiment rêver de toutes façons.