La connaissance de l'assembleur est bien un pré-requis car il donne vraiment une idée suffisamment précise du comportement du CPU
Pas vraiment. Les CPU modernes:
N'exécutent pas les instructions dans l'ordre,
Ont plus de registres en interne que ce qui est disponible dans le jeu d'instruction, et renomment/réassignent les registres à la volée,
Sont fabriqués par plusieurs fabricants implémentant le même jeu d'instruction, avec des nombre de cycles CPU par instruction pas forcément identiques,
Partagent les unités d'exécution entre plusieurs threads, donc on ne peut même pas savoir quelles ressources vont être disponibles,
De toutes façons, le problème est probablement la bande passante de la mémoire et rendre l'exécution du code sur le CPU plus rapide va juste faire que le CPU passe plus de temps à attendre au lieu d'exécuter du code.
Au final, l'assembleur est un langage de programmation comme un autre, il n'est même plus "proche du matériel". Donc autant choisir un langage plus confortable.
Bref on se mort la queue : si un CPU est si compliqué c'est aussi à force d'optimisations que les devs n'ont pas voulu faire parce que… "c'est trop compliqué un CPU".
Faire du code optimisé pour un modèle de CPU, une taille de cache fixe, une mémoire avec une bande passante bien déterminée: facile.
Faire du code optimisé dans tous les cas, y compris pour des CPU qui ne sont pas encore fabriqués: impossible.
Ces optimisations dans les CPU sont ce qui permet d'avoir du matériel moderne qui continue d'exécuter le code existant avec de meilleures performances. Je trouve ça mieux que de dire "ah on a rajouté 1Mo de mémoire cache dans le nouveau CPU, mais tu dois réécrire tout ton code pour l'exploiter, parce que c'est à toi de dire explicitement quelles variables il faut stocker dans le cache".
Le problème est simple: il vaut mieux optimiser le temps de travail des développeurs, plutôt que quelques cycles CPU. Et donc, ne pas avoir à réécrire tout le code à chaque nouvelle génération de CPU, c'est bien.
le compilo applique des optimisations génériques car il n'a pas le moindre début d'idée de ce que le code fait.
C'est faisable, on peut donner à gcc une trace d'exécution du code et recompiler une deuxième fois, et il va ajouter automatiquement les instructiosn de prédiction de branchement. Est-ce que des gens s'embêtent à le faire? Non, parce que même cette procédure entièrement automatisée n'a aucun intérêt économique dans la plupart des cas. Le temps passé par le développeur à mettre en place ça va coûter plus cher que les 0.1% de performance qu'on va pouvoir gagner. Sauf dans quelques cas particuliers où ces micro optimisations vont faire la différence entre "ça ne marche pas du tout" et "ça passe de justesse", ou là, le développeur peut être payé très cher pour passer du temps à ce genre de choses.
Et de toutes façons le problème de l'optimisation n'est même pas là la plupart du temps. Il y a des problèmes beaucoup plus bêtes de mauvais choix de structures de données, ou de mauvaise utilisation de structures de données. Par exemple, faire plusieurs fois de suite une recherche d'un objet dans une map, au lieu de le trouver une fois et de garder une référence. Là on peut avoir des gains de plusieurs dizaines de % de performances, et ça peut être intéressant d'y passer du temps.
Et pour faire ce genre de choses, c'est plus facile si on travaille avec un langage haut niveau ou au moins qui propose un bon choix de structures de données disponibles dans sa bibliothèque standard (C++ ou Python par exemple). Sinon, le coût de développer ne serait-ce qu'une hash map n'en vaut peut-être même pas la peine.
J'ai l'impression qu'on cadre beaucoup cette discussion comme si c'était (uniquement) un problème de compétence des développeurs. Je pense que ce n'est pas vraiment le cas, il y a plein d'autres choses qui rentrent en jeu.
La première, c'est que dans beaucoup de cas, les optimisations ne sont pas nécessaires ou pas prioritaires. Optimiser le code, concevoir l'architecture la plus efficace, ça prend du temps. Souvent, c'est plus important de livrer des nouvelles fonctionnalités très vite (avant les concurrents). Et en plus, on travaille avec des spécifications changeantes (les fameuses méthodes agiles), alors que pour faire de l'optimisation, il faut souvent pouvoir considérer un problème dans son intégralité pour bien déterminer la solution optimale. Si tu passes un mois à écrire la structure de donnée parfaite, mais que la semaine suivante, finalement ton programme doit faire autre chose, tu peux tout jeter et recommencer.
Il y a aussi une certaine tolérance des utilisateurs. C'est vrai en informatique mais aussi dans d'autres domaines. Par exemple, les téléphones mobiles modernes ont une latence plus importante que les anciens téléphones fixes à réseau par commutation de circuits. On s'est habitué, les usages ont évolué, et maintenant on arrive même à faire des visioconférences à plusieurs avec une latence encore plus importante. Il en va de même pour l'informatique, les gens développent une tolérance aux interfaces lentes et on peut se permettre d'être de pire en pire sans que ça fasse fuir tous les clients.
Du côté des développeurs, par contre, il y a quelques domaines où ça ne marche pas comme ça: le jeu vidéo, ou les systèmes embarqués/temps réel par exemple. Dans ces contextes là, il y a moins de problème pour passer du temps à optimiser les choses, il y a le budget pour, parce que sinon, le projet de marche pas.
Une solution serait de rendre les choses obligatoires. Pour la sécurité ça commence à se faire par exemple avec le Cyber Resilience Act qui va pousser les entreprises à assurer les mises à jour de sécurité. Du côté des performances, il pourrait y avoir des équivalents pour l'éco-conception (soit avec des obligations, soit avec un étiquettage/certification de type "nutri score"). En fait, c'est aussi déjà le cas dans certains domaines, les développeurs de frigo connectés sont très bons pour faire de l'électronique et du logiciel à basse consommation pour pouvoir afficher le score A++ en consommation d'énergie.
Au final, le problème ce n'est pas vraiment les développeurs, ce sont les clients qui ne veulent pas payer pour avoir des logiciels performants, ils préfèrent avoir un truc moins cher et livré plus tôt, et payer un peu plus de matériel. Là, une autre solution serait de rééquilibrer le coût du matériel (vraiment pas cher actuellement) et le coût du travail humain. Si les développeurs étaient payés moins cher, on pourrait leur faire passer du temps pour faire des économies sur le matériel. Ce n'est clairement pas l'équilibre actuel des choses.
Même sans avoir plus de clics sur inutile, si beaucoup de monde décide de ne pas regarder la vidéo, et qu'il y a donc très peu de pertinentage, le score se trouve négatif. Là ou un lien vers du texte aurait peut-être reçu beaucoup de votes positifs compensant les quelques votes négatifs systématiques.
Difficile à dire, car contrairement aux commentaires, on ne voit que la note finale.
Pour faire du Python, il faut comprendre le fonctionnement des types implicite (est-ce que c'est une string? est-ce que c'est un entier? comment on convertit entre les 2?), la gestion de la mémoire par références (si on a deux variables qui référencent le même objet, en modifier une va modifier l'autre), les exceptions, …
L'étude compare ces langages en dehors de leur environnement "naturel", dans un IDE web clé en main. Donc toute la partie venv, dépendances, portabilité ne pose pas problème (de la même façon que la compilation, édition de lien, etc en C++ n'est pas mise en jeu).
La conclusion est donc peut-être que le langage Python n'est pas plus simple à apprendre, mais que son environnement (facile à installer, avec des modules pour faire beaucoup de choses disponibles dans pip ou dans la bibliohèque standard) est son point fort qui rend le tout vraiment plus abordable.
Je crois que la traduction en Français s'est un peu fourvoyée. Le texte original ne parle pas de "spécialistes" et "non-spécialistes", mais de major et minor qui sont une spécificité des universités États-Uniennes.
En gros, ils ont retenu les cours de programmation s'adressant à des étudiants en informatique, mais pas ceux s'adressant uniquement à des étudiants dans un autre domaine, qui auraient tout de même des cours de programmation dans leur cursus. Pour ces derniers, Python est sur-représenté, et donc cela pourrait défavoriser Python, qui est plus volontiers mis entre les mains de personnes qui n'ont pas prévu de devenir informaticiens professionnels et sont peut-être moins intéressés et moins susceptibles de suivre chaque exercice jusqu'au bout.
il n’existe pas de liste exhaustive des structures « d’intérêt général » à ma connaissance ;
Oui c'est normal:
Pour l'utilité publique, il faut être reconnu d'utilité publique, il y a donc une procédure à suivre par l'association pour obtenir cette reconnaissance (et être ajoutée dans la liste).
Pour l'intérêt général, il n'y a pas de procédure de reconnaissance. Si l'association rentre dans les critères de l'article 200 du code des impôts (200 b ou 200 f bis, il me semble que les autres sections ne concernent pas les associations), c'est défiscalisable. En cas de doute, une association peut faire une procédure de rescrit fiscal, qui consiste à demander à l'administration si oui ou non elle répond aux critères. Cela évite une mauvaise surprise aux donateurs qui se rendraient compte que leurs dons ne sont finalement pas défiscalisables. Et la démarche est assez simple, il n'y a donc pas de raison de s'en priver.
La plupart des associations qui sollicitent des dons auprès du public vont donc faire cette démarche, afin de rassurer leurs donateurs à ce sujet.
En fait, il suffit que l'administration de réponde pas pendant 6 mois pour que ça soit considéré comme une réponse positive. Ils ne prennent donc ni la peine de répondre, ni de tenir une liste.
Itch.io est aussi concerné par la possible disparition prochaine du ccTLD .io. Ils ont donc fait, séparément, un mauvais choix de registrar (dont on parle dans cet incident-ci) et un mauvais choix de ccTLD, qui n'est pas lié au problème d'aujourd'hui, mais dont on reparlera peut-être plus tard.
Il y a plusieurs problèmes avec le choix de domaines de premier niveaux "rigolos" mais qui sont associés à des pays existants (ou qui ont existé).
Le .ga qui appartient au Gabon a été repris de force à l'entreprise qui en avait acquis les droits,
Le .tk (île de Tokelau à proximité de la nouvelle Zélande) est peut-être en train de suivre le même chemin,
Des domaines en .af (Afghanistan) ont été supprimés suite à un changement de régime de gouvernement,
Le .io va bientôt disparaître car les îles en question changent de statut (le domaine était sous le contrôle du Royaume-Uni),
Le .su (union soviétique) n'est pas tout à fait mort, et sert à héberger des choses avec peu de modération,
Le .yu (Yougoslavie) a été transféré par la force, avec un vol des serveurs dans les locaux de l'université qui hébergeait ce domaine pour les réinstaller dans un autre pays issu de l'éclatement.
Il faut donc se poser des questions sur la stabilité politique de son nom de domaine.
Choisir un domaine d'un autre pays, c'est aussi une forme de colonisation numérique: vous occupez l'espace attribué à quelqu'un d'autre sur Internet.
D'après la page wikipedia liée dans l'article: These levels define specific features that can be targeted by programmers to provide compile-time optimizations."
L'idée est donc de fournir une version du cpu sur lequel on va exécuter le code au compilateur. Ce dernier ne peut pas utiliser les bits cpuid parce qu'il n'a aucune idée si le code généré va tourner sur la même machine que le compilateur lui même.
L'option pour faire ça existe depuis très longtemps dans gcc (-march) et configure un ensemble d'instructions utilisables. On peut ensuite affiner avec des options supplémentaires (-msse2 par exemple pour activer l'utilisation sse2). On peut aussi utiliser -march=native pour dire au compilateur de détecter le cpu de la machine de compilation et d'optimiser pour ce dernier (si on est utilisateur de Gento par exemple).
Donc quel est le problème? Le problème est que les valeurs données à l'option -march sont assez arbitraires, souvent des noms de processeurs "représentatifs" (pentium, pentium3, k6, …). C'est difficile de s'y retrouver. Pouvoir dire "x86_64 v3" est plus précis et un fabricant de processeur peut clairement identifier si un processeur est compatible avec une telle spécification. Ce qui bien sûr n'empêche pas de proposer des options qui ne seront "de base" que dans les générations suivantes (ou peut-ètre jamais), et de fournir les bits cpuid pour tout ce qui peut être décidé à l'exécution (pas à la compilation).
Les choses fonctionnent comme ça pour les projets d'architecture (pour construire des gares, des aéroports, …). Dans ces cas là, les retombées en termes d'image et de prestige peuvent être justifiées. Et le financement aussi, une fois qu'un projet a été sélectionné et qu'il faut passer de la jolie maquette à la construction d'en vrai bâtiment, avec des plans détaillés et ainsi de suite.
Alors que pour un concours de graphistes, souvent, c'est la maquette qui se trouve directement mise en production.
Ça ne me dérange pas, j'ai posé la question parce que je savais que dans le cas des assistantes vocales comme Alexa ou Siri, ce sont les concepteurs des logiciels qui ont choisi de les féminiser, en supposant ou en mesurant que les gens étaient plus à l'aise pour donner des ordres à une entité féminine.
Je demandais simplement si Google avait fait la même chose pour Gemini, ou si c'est simplement une règle d'accord en Français où on est à peu près obligés de choisir un genre ou l'autre. Merci pour la réponse :)
Pourquoi Gemini est genré au féminin dans le titre de ce lien? C'est Google qui a choisi que c'était une entité féminine ou c'est juste parce qu'on dit "une IA" en Français?
Vous remarquerez que l'article ne parle pas de Mastodon, mais ne parle pas non plus des opinions politiques de gauche. Il n'y a que la droite et le centre.
Ce n'est pas incohérent pour un journal anglais, cela dit.
J'imagine que des gens ont vu "intelligence artificielle" dans le titre et n'ont pas été regarder plus loin?
Je précise au passage que le modèle de text to speech semble s'entraîner en local sur un gpu, ce qui permet au moins de se rendre compte de la consommation d'énergie nécessaire. Qui d'ailleurs est sûrement plus réduit que pour un "large language model" ou d'autres machins généralistes.
Ça donne aussi la recette hour fabriquer un deepfake audio à partir de n'importe quelle voix, comme toute autre technologie, les utilisations à des fins néfastes ne sont jamais loin, mais j'ai trouvé cette application intéressante
Entraînement de modèles de synthèse vocale à l'aide des voix enregistrées pour les jeux suivants (Space Quest 6, Leisure Suit Larry), permettant d'imiter la voix des acteurs ayant joué les personages
Extraction des textes du jeu et passage dans un moteur text-to-speech avec les voix générées ci-dessus
Portage du jeu vers un moteur plus récent avec quelques patchs sur le bytecode du jeu, ce qui permet de déclencher la lecture des clips sonores générés
Correction au passage de quelques bugs, en particulier des répliques qui n'étaient pas attribuées au bon personnage (peu gênant sur la version texte, mais immédiatement détectable avec la version vocale)
De ce que je vois la plupart des versions dérivées de Firefox ont juste des patchs assez triviaux (désactivation de la télémétrie, activation de fonctionnalités réservées aux développeurs, …)
ça me semble bien de commencer comme ça par un fork "vampire": récupérer le code de Mozilla et faire quelques changements simples pour qu'on passe pas 10 minutes à chaque installation oe Firefox à configurer tous ces trucs.
Une fois que c'est fait et que ça a grignoté un peu de ce qu'il reste de parts de marchés à Firefox, on verra pour les financements: donations, mécénat, campagen kickstarter, … pour développer de nouvelles choses (si tant est qu'il y aie encore besoin de ça, peut-être aussi que le web bénéficierait d'un environnement qui évolue moins vite, mais c'esùune autre histoire).
Récemment une (1) personne a réalisé un portage de Firefox pour Haiku. Je ne peux pas imaginer que une recompilation pour un OS déjà supporté soxt si compliquée que ça. Oui, c'est sûrement long à compiler, il faut de la patience, mais y'a pas besoin de commencer direct le projet en embauchant tout de suite une équipe de 80 personnes à plein temps?
Pendant ce temps, les gens utilisent Brave (développé par un illuminé aux opinions politiques douteuses) ou Vivaldi (basé sur chrome, pas open source) parce que l'interface utilisateur est mieux pensée. Et les libristes pleurent sur Mozilla sans rien faire pour que ça bouge.
Quel défaitisme. Bien sûr que c'est possible, à condition d'avoirune équipe motivée et qui a du temps. Il existe déjà de nombreux forks de Firefox dont certains depuis une assez longue durée. Ce n'est pas là la paryie compliquée (il y a juste à changr le nom et le logo).
Le problème #emait plutôt de monter une nouvelle structure juridique et organisationelle avec les garanties nécessaires (pas un truc piloté par un illuminé avec des propos douteux, ou une startup qui finit par se faire racheter par les requins de la finance).
Et si personne ne fait ça, franchement ça sert à quoi de faire du logiciel libre?
Comme le système GNU, cette version de DOS n'a pas de noyau. Il s'agit "uniquement" (c'est déjà un gros travail) d'un clone des commandes utilisables sous DOS (y compris le shell graphique et deux versions du BASIC).
C'est donc insuffisant pour se fabriquer une insallation de DOS entièrement libre.
Non mais qui croit encore que la FSF sert à quelque chose? C'est juste des vieux geeks barbus nostalgiques des années 70, quand tous les utilisateurs d'ordinateurs étaient des développeurs(ou éventuellement utilisatrices-développeuses).
Va voir plutôt du côté de la FSFE oude la Software Freedom Conservancy, et tu trouveras des vrais projets pour promouvoir le libre et faire avancer les choses. Je pense au livre Ada et Zangemann, au programme Outreachy pour former des développeurs et développeuses de logiciels libres, aux combats juridiques avec des fabricants de smart TV qui testent les limites de l'application de la license GPL, par exemple.
Le FORTRAN et l’ALGOL, bien qu’ayant été introduits dans les ordinateurs soviétiques dans les années 1960, ne commenceront à être vraiment utilisés qu’à partir des années 1970, époque à laquelle l’URSS abandonnera la production de ses propres ordinateurs.
Il me semble que l'URSS n'a pas abandonné la production, mais bien la conception de ses propres ordinateurs à cette époque. En plus des ordinateurs importés (ce qui n'était pas évident en raison de diverses restrictions et du manque de dollars en URSS pour acheter des produits étrangers), on trouvait donc des ordinateursconstruits sur place, mais réutilisant le jeu d'instructions ou plus tard les masques de circuits intégrés conçus ailleurs. Il était en effet plus simple d'obtenir ces informations (articles de recherche, documentation, ou éventuellement espionnage industriel) que d'obtenir les machines.
Ce choix n'est pas bête techniquement, il permet une certaine standardisation et facilite la collaboration avec les informaticiens d'autres pays en utilisant les mêmes langages de programmation par exemple.
On trouve des ordinateurs soviétiques utilisant par exemple le jeu d'instructions du PDP-11, ou des clones de mainframes de chez IBM.
Cela n'empêche pas l'union soviétique d'innover, par exempl.avec le langage de programmation graphique DRAKON utilisé pour les navettes bourane dans les annéees 80.
En plus oes articles de Ken, vous pouvez trouver sur youtube les vidéos de CuriousMarc, ils ont travaillé ensemble et avec d'autres personnes pour refaire fonctionner l'AGC, dumper les différentes versions du logiciel, et travaillé également sur l'électronique de radiocommunication permettant de transmettre son, image, et commandes à distance pour l'ordinateur lors des mission Apollo.
Là, ça tient un peu plus la route, même si cela me semble quasiment impossible (fais l'analogie avec les médocs ou tout autre produit breveté)
ah ben parlons en des brevets. Le deal est à peu près honnête quand c'est bien fait: dans un brevet, une entreprise consignetoutesles informations décrivantune invention. En échange, elle a l'exclusivité sur cette invention pendant 20 ans.
Ça marche assez bien pour les médicaments qui deviennent disponible sous forme de "génériques" fabriqués par d'autres entreprises après expiration de ce délai.
Ce système a été mis en place parce que sinon, les entreprises garderaient leurs inventions secrètes (ce que certaines choisissent d'ailleurs de faire, par exemple, la recette du coca cola, c'est un secret et pas un brevet).
Ce principe aurait pu s'appliquer au logiciel, mais pour des raisons diverses, c'est plutôt le mécanisme du droit d'auteur qui a été retenu à la place. Ce qui faisait sens à une époque ou les logiciels étaient diffusés sur bande magnétiques ou sur disquettes, mais peut-être moins maintenant. Mais bon, faut faire avec!
[^] # Re: Who's that guy ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software is Way Less Performant Today. Évalué à 8.
Pas vraiment. Les CPU modernes:
Au final, l'assembleur est un langage de programmation comme un autre, il n'est même plus "proche du matériel". Donc autant choisir un langage plus confortable.
Faire du code optimisé pour un modèle de CPU, une taille de cache fixe, une mémoire avec une bande passante bien déterminée: facile.
Faire du code optimisé dans tous les cas, y compris pour des CPU qui ne sont pas encore fabriqués: impossible.
Ces optimisations dans les CPU sont ce qui permet d'avoir du matériel moderne qui continue d'exécuter le code existant avec de meilleures performances. Je trouve ça mieux que de dire "ah on a rajouté 1Mo de mémoire cache dans le nouveau CPU, mais tu dois réécrire tout ton code pour l'exploiter, parce que c'est à toi de dire explicitement quelles variables il faut stocker dans le cache".
Le problème est simple: il vaut mieux optimiser le temps de travail des développeurs, plutôt que quelques cycles CPU. Et donc, ne pas avoir à réécrire tout le code à chaque nouvelle génération de CPU, c'est bien.
C'est faisable, on peut donner à gcc une trace d'exécution du code et recompiler une deuxième fois, et il va ajouter automatiquement les instructiosn de prédiction de branchement. Est-ce que des gens s'embêtent à le faire? Non, parce que même cette procédure entièrement automatisée n'a aucun intérêt économique dans la plupart des cas. Le temps passé par le développeur à mettre en place ça va coûter plus cher que les 0.1% de performance qu'on va pouvoir gagner. Sauf dans quelques cas particuliers où ces micro optimisations vont faire la différence entre "ça ne marche pas du tout" et "ça passe de justesse", ou là, le développeur peut être payé très cher pour passer du temps à ce genre de choses.
Et de toutes façons le problème de l'optimisation n'est même pas là la plupart du temps. Il y a des problèmes beaucoup plus bêtes de mauvais choix de structures de données, ou de mauvaise utilisation de structures de données. Par exemple, faire plusieurs fois de suite une recherche d'un objet dans une map, au lieu de le trouver une fois et de garder une référence. Là on peut avoir des gains de plusieurs dizaines de % de performances, et ça peut être intéressant d'y passer du temps.
Et pour faire ce genre de choses, c'est plus facile si on travaille avec un langage haut niveau ou au moins qui propose un bon choix de structures de données disponibles dans sa bibliothèque standard (C++ ou Python par exemple). Sinon, le coût de développer ne serait-ce qu'une hash map n'en vaut peut-être même pas la peine.
[^] # à qui la faute?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software is Way Less Performant Today. Évalué à 7.
J'ai l'impression qu'on cadre beaucoup cette discussion comme si c'était (uniquement) un problème de compétence des développeurs. Je pense que ce n'est pas vraiment le cas, il y a plein d'autres choses qui rentrent en jeu.
La première, c'est que dans beaucoup de cas, les optimisations ne sont pas nécessaires ou pas prioritaires. Optimiser le code, concevoir l'architecture la plus efficace, ça prend du temps. Souvent, c'est plus important de livrer des nouvelles fonctionnalités très vite (avant les concurrents). Et en plus, on travaille avec des spécifications changeantes (les fameuses méthodes agiles), alors que pour faire de l'optimisation, il faut souvent pouvoir considérer un problème dans son intégralité pour bien déterminer la solution optimale. Si tu passes un mois à écrire la structure de donnée parfaite, mais que la semaine suivante, finalement ton programme doit faire autre chose, tu peux tout jeter et recommencer.
Il y a aussi une certaine tolérance des utilisateurs. C'est vrai en informatique mais aussi dans d'autres domaines. Par exemple, les téléphones mobiles modernes ont une latence plus importante que les anciens téléphones fixes à réseau par commutation de circuits. On s'est habitué, les usages ont évolué, et maintenant on arrive même à faire des visioconférences à plusieurs avec une latence encore plus importante. Il en va de même pour l'informatique, les gens développent une tolérance aux interfaces lentes et on peut se permettre d'être de pire en pire sans que ça fasse fuir tous les clients.
Du côté des développeurs, par contre, il y a quelques domaines où ça ne marche pas comme ça: le jeu vidéo, ou les systèmes embarqués/temps réel par exemple. Dans ces contextes là, il y a moins de problème pour passer du temps à optimiser les choses, il y a le budget pour, parce que sinon, le projet de marche pas.
Une solution serait de rendre les choses obligatoires. Pour la sécurité ça commence à se faire par exemple avec le Cyber Resilience Act qui va pousser les entreprises à assurer les mises à jour de sécurité. Du côté des performances, il pourrait y avoir des équivalents pour l'éco-conception (soit avec des obligations, soit avec un étiquettage/certification de type "nutri score"). En fait, c'est aussi déjà le cas dans certains domaines, les développeurs de frigo connectés sont très bons pour faire de l'électronique et du logiciel à basse consommation pour pouvoir afficher le score A++ en consommation d'énergie.
Au final, le problème ce n'est pas vraiment les développeurs, ce sont les clients qui ne veulent pas payer pour avoir des logiciels performants, ils préfèrent avoir un truc moins cher et livré plus tôt, et payer un peu plus de matériel. Là, une autre solution serait de rééquilibrer le coût du matériel (vraiment pas cher actuellement) et le coût du travail humain. Si les développeurs étaient payés moins cher, on pourrait leur faire passer du temps pour faire des économies sur le matériel. Ce n'est clairement pas l'équilibre actuel des choses.
[^] # Re: Toute ressemblance ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien « DOGE » : la dernière pitrerie libertarienne d’Elon Musk . Évalué à 5.
Même sans avoir plus de clics sur inutile, si beaucoup de monde décide de ne pas regarder la vidéo, et qu'il y a donc très peu de pertinentage, le score se trouve négatif. Là ou un lien vers du texte aurait peut-être reçu beaucoup de votes positifs compensant les quelques votes négatifs systématiques.
Difficile à dire, car contrairement aux commentaires, on ne voit que la note finale.
[^] # Re: il n'y a pas que ça
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Apprendre la programmation en Python n'est pas plus facile qu'en Java ou en C++. Évalué à 3.
Pour faire du Python, il faut comprendre le fonctionnement des types implicite (est-ce que c'est une string? est-ce que c'est un entier? comment on convertit entre les 2?), la gestion de la mémoire par références (si on a deux variables qui référencent le même objet, en modifier une va modifier l'autre), les exceptions, …
L'étude compare ces langages en dehors de leur environnement "naturel", dans un IDE web clé en main. Donc toute la partie venv, dépendances, portabilité ne pose pas problème (de la même façon que la compilation, édition de lien, etc en C++ n'est pas mise en jeu).
La conclusion est donc peut-être que le langage Python n'est pas plus simple à apprendre, mais que son environnement (facile à installer, avec des modules pour faire beaucoup de choses disponibles dans pip ou dans la bibliohèque standard) est son point fort qui rend le tout vraiment plus abordable.
[^] # Re: my 2 cents
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Apprendre la programmation en Python n'est pas plus facile qu'en Java ou en C++. Évalué à 5.
Je crois que la traduction en Français s'est un peu fourvoyée. Le texte original ne parle pas de "spécialistes" et "non-spécialistes", mais de major et minor qui sont une spécificité des universités États-Uniennes.
En gros, ils ont retenu les cours de programmation s'adressant à des étudiants en informatique, mais pas ceux s'adressant uniquement à des étudiants dans un autre domaine, qui auraient tout de même des cours de programmation dans leur cursus. Pour ces derniers, Python est sur-représenté, et donc cela pourrait défavoriser Python, qui est plus volontiers mis entre les mains de personnes qui n'ont pas prévu de devenir informaticiens professionnels et sont peut-être moins intéressés et moins susceptibles de suivre chaque exercice jusqu'au bout.
# L'intérêt général
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Dons aux associations, épisode 13. Évalué à 3.
Oui c'est normal:
Pour l'utilité publique, il faut être reconnu d'utilité publique, il y a donc une procédure à suivre par l'association pour obtenir cette reconnaissance (et être ajoutée dans la liste).
Pour l'intérêt général, il n'y a pas de procédure de reconnaissance. Si l'association rentre dans les critères de l'article 200 du code des impôts (200 b ou 200 f bis, il me semble que les autres sections ne concernent pas les associations), c'est défiscalisable. En cas de doute, une association peut faire une procédure de rescrit fiscal, qui consiste à demander à l'administration si oui ou non elle répond aux critères. Cela évite une mauvaise surprise aux donateurs qui se rendraient compte que leurs dons ne sont finalement pas défiscalisables. Et la démarche est assez simple, il n'y a donc pas de raison de s'en priver.
La plupart des associations qui sollicitent des dons auprès du public vont donc faire cette démarche, afin de rassurer leurs donateurs à ce sujet.
En fait, il suffit que l'administration de réponde pas pendant 6 mois pour que ça soit considéré comme une réponse positive. Ils ne prennent donc ni la peine de répondre, ni de tenir une liste.
[^] # Re: Résumé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Un fabricant de figurines fait tomber itch.io. Évalué à 6.
Itch.io est aussi concerné par la possible disparition prochaine du ccTLD .io. Ils ont donc fait, séparément, un mauvais choix de registrar (dont on parle dans cet incident-ci) et un mauvais choix de ccTLD, qui n'est pas lié au problème d'aujourd'hui, mais dont on reparlera peut-être plus tard.
[^] # Re: Résumé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Un fabricant de figurines fait tomber itch.io. Évalué à 9.
Il y a plusieurs problèmes avec le choix de domaines de premier niveaux "rigolos" mais qui sont associés à des pays existants (ou qui ont existé).
Il faut donc se poser des questions sur la stabilité politique de son nom de domaine.
Choisir un domaine d'un autre pays, c'est aussi une forme de colonisation numérique: vous occupez l'espace attribué à quelqu'un d'autre sur Internet.
Au final, il vaut mieux consommer local!
[^] # Re: mouais
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Matrix vs XMPP. Évalué à 1.
Il semblerait que l'auteur est également un militant d'extrême droite.
[^] # Ou est le problème?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Linus Torvalds critique violemment les « niveaux » introduits pour l’architecture x86. Évalué à 5.
D'après la page wikipedia liée dans l'article: These levels define specific features that can be targeted by programmers to provide compile-time optimizations."
L'idée est donc de fournir une version du cpu sur lequel on va exécuter le code au compilateur. Ce dernier ne peut pas utiliser les bits cpuid parce qu'il n'a aucune idée si le code généré va tourner sur la même machine que le compilateur lui même.
L'option pour faire ça existe depuis très longtemps dans gcc (-march) et configure un ensemble d'instructions utilisables. On peut ensuite affiner avec des options supplémentaires (-msse2 par exemple pour activer l'utilisation sse2). On peut aussi utiliser -march=native pour dire au compilateur de détecter le cpu de la machine de compilation et d'optimiser pour ce dernier (si on est utilisateur de Gento par exemple).
Donc quel est le problème? Le problème est que les valeurs données à l'option -march sont assez arbitraires, souvent des noms de processeurs "représentatifs" (pentium, pentium3, k6, …). C'est difficile de s'y retrouver. Pouvoir dire "x86_64 v3" est plus précis et un fabricant de processeur peut clairement identifier si un processeur est compatible avec une telle spécification. Ce qui bien sûr n'empêche pas de proposer des options qui ne seront "de base" que dans les générations suivantes (ou peut-ètre jamais), et de fournir les bits cpuid pour tout ce qui peut être décidé à l'exécution (pas à la compilation).
[^] # Re: Facile
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La Nasa cherche à sauver un astronaute sur la Lune et met 45 000 $ sur la table. Évalué à 6.
Peut-être qu'on peut mettre les dromadaires dans un tube pressurisé et un peu régulé en température?
[^] # Re: Ah ces concours...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La Nasa cherche à sauver un astronaute sur la Lune et met 45 000 $ sur la table. Évalué à 5.
Les choses fonctionnent comme ça pour les projets d'architecture (pour construire des gares, des aéroports, …). Dans ces cas là, les retombées en termes d'image et de prestige peuvent être justifiées. Et le financement aussi, une fois qu'un projet a été sélectionné et qu'il faut passer de la jolie maquette à la construction d'en vrai bâtiment, avec des plans détaillés et ainsi de suite.
Alors que pour un concours de graphistes, souvent, c'est la maquette qui se trouve directement mise en production.
[^] # Re: Moi, je préfère le papier
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Vous utilisez des agendas ? Sous quelle forme ?. Évalué à 3.
Un stylo qui n'a plus d'encre ça peut arriver aussi. Mais l'autonomie est bien meilleure, c'est vrai.
[^] # Re: It's a girl
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Agacée" par des questions mal formulées, Gemini a supplié un étudiant d'aller se suicider . Évalué à 2.
Ça ne me dérange pas, j'ai posé la question parce que je savais que dans le cas des assistantes vocales comme Alexa ou Siri, ce sont les concepteurs des logiciels qui ont choisi de les féminiser, en supposant ou en mesurant que les gens étaient plus à l'aise pour donner des ordres à une entité féminine.
Je demandais simplement si Google avait fait la même chose pour Gemini, ou si c'est simplement une règle d'accord en Français où on est à peu près obligés de choisir un genre ou l'autre. Merci pour la réponse :)
# It's a girl
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Agacée" par des questions mal formulées, Gemini a supplié un étudiant d'aller se suicider . Évalué à 2.
Pourquoi Gemini est genré au féminin dans le titre de ce lien? C'est Google qui a choisi que c'était une entité féminine ou c'est juste parce qu'on dit "une IA" en Français?
[^] # Re: Éclatement
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien The exodus from X to Bluesky has happened . Évalué à 10.
Vous remarquerez que l'article ne parle pas de Mastodon, mais ne parle pas non plus des opinions politiques de gauche. Il n'y a que la droite et le centre.
Ce n'est pas incohérent pour un journal anglais, cela dit.
[^] # Re: Lien mort
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ajouter des voix générées par IA à Space Quest V. Évalué à 7.
J'imagine que des gens ont vu "intelligence artificielle" dans le titre et n'ont pas été regarder plus loin?
Je précise au passage que le modèle de text to speech semble s'entraîner en local sur un gpu, ce qui permet au moins de se rendre compte de la consommation d'énergie nécessaire. Qui d'ailleurs est sûrement plus réduit que pour un "large language model" ou d'autres machins généralistes.
Ça donne aussi la recette hour fabriquer un deepfake audio à partir de n'importe quelle voix, comme toute autre technologie, les utilisations à des fins néfastes ne sont jamais loin, mais j'ai trouvé cette application intéressante
[^] # Re: Lien mort
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ajouter des voix générées par IA à Space Quest V. Évalué à 5.
La wayback machine a eu le temps d'en faire un backup:
http://web.archive.org/web/20241112221046/https://github.com/cdb-boop/Space-Quest-V-Voice-Acting-Mod
petit résumé:
[^] # Re: C'est quel morceau?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La Fondation Mozilla se restructure et licencie 30% de son personnel . Évalué à 5.
ça me semble bien de commencer comme ça par un fork "vampire": récupérer le code de Mozilla et faire quelques changements simples pour qu'on passe pas 10 minutes à chaque installation oe Firefox à configurer tous ces trucs.
Une fois que c'est fait et que ça a grignoté un peu de ce qu'il reste de parts de marchés à Firefox, on verra pour les financements: donations, mécénat, campagen kickstarter, … pour développer de nouvelles choses (si tant est qu'il y aie encore besoin de ça, peut-être aussi que le web bénéficierait d'un environnement qui évolue moins vite, mais c'esùune autre histoire).
Récemment une (1) personne a réalisé un portage de Firefox pour Haiku. Je ne peux pas imaginer que une recompilation pour un OS déjà supporté soxt si compliquée que ça. Oui, c'est sûrement long à compiler, il faut de la patience, mais y'a pas besoin de commencer direct le projet en embauchant tout de suite une équipe de 80 personnes à plein temps?
Pendant ce temps, les gens utilisent Brave (développé par un illuminé aux opinions politiques douteuses) ou Vivaldi (basé sur chrome, pas open source) parce que l'interface utilisateur est mieux pensée. Et les libristes pleurent sur Mozilla sans rien faire pour que ça bouge.
[^] # Re: C'est quel morceau?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La Fondation Mozilla se restructure et licencie 30% de son personnel . Évalué à 2.
Quel défaitisme. Bien sûr que c'est possible, à condition d'avoirune équipe motivée et qui a du temps. Il existe déjà de nombreux forks de Firefox dont certains depuis une assez longue durée. Ce n'est pas là la paryie compliquée (il y a juste à changr le nom et le logo).
Le problème #emait plutôt de monter une nouvelle structure juridique et organisationelle avec les garanties nécessaires (pas un truc piloté par un illuminé avec des propos douteux, ou une startup qui finit par se faire racheter par les requins de la finance).
Et si personne ne fait ça, franchement ça sert à quoi de faire du logiciel libre?
# Il manque un truc
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien MSDOS-0. Évalué à 2.
Comme le système GNU, cette version de DOS n'a pas de noyau. Il s'agit "uniquement" (c'est déjà un gros travail) d'un clone des commandes utilisables sous DOS (y compris le shell graphique et deux versions du BASIC).
C'est donc insuffisant pour se fabriquer une insallation de DOS entièrement libre.
[^] # Re: Abandonner l'informatique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Se détacher des multinationales qui contrôlent les systèmes GNU/Linux ?. Évalué à 5.
Non mais qui croit encore que la FSF sert à quelque chose? C'est juste des vieux geeks barbus nostalgiques des années 70, quand tous les utilisateurs d'ordinateurs étaient des développeurs(ou éventuellement utilisatrices-développeuses).
Va voir plutôt du côté de la FSFE oude la Software Freedom Conservancy, et tu trouveras des vrais projets pour promouvoir le libre et faire avancer les choses. Je pense au livre Ada et Zangemann, au programme Outreachy pour former des développeurs et développeuses de logiciels libres, aux combats juridiques avec des fabricants de smart TV qui testent les limites de l'application de la license GPL, par exemple.
# Petits détails
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche La conquête de l’espace : une affaire féminine, deuxième partie les missions Apollo. Évalué à 3. Dernière modification le 24 octobre 2024 à 18:00.
Il me semble que l'URSS n'a pas abandonné la production, mais bien la conception de ses propres ordinateurs à cette époque. En plus des ordinateurs importés (ce qui n'était pas évident en raison de diverses restrictions et du manque de dollars en URSS pour acheter des produits étrangers), on trouvait donc des ordinateursconstruits sur place, mais réutilisant le jeu d'instructions ou plus tard les masques de circuits intégrés conçus ailleurs. Il était en effet plus simple d'obtenir ces informations (articles de recherche, documentation, ou éventuellement espionnage industriel) que d'obtenir les machines.
Ce choix n'est pas bête techniquement, il permet une certaine standardisation et facilite la collaboration avec les informaticiens d'autres pays en utilisant les mêmes langages de programmation par exemple.
On trouve des ordinateurs soviétiques utilisant par exemple le jeu d'instructions du PDP-11, ou des clones de mainframes de chez IBM.
Cela n'empêche pas l'union soviétique d'innover, par exempl.avec le langage de programmation graphique DRAKON utilisé pour les navettes bourane dans les annéees 80.
[^] # Re: L'electronique des missions Apollo
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche La conquête de l’espace : une affaire féminine, deuxième partie les missions Apollo. Évalué à 4.
En plus oes articles de Ken, vous pouvez trouver sur youtube les vidéos de CuriousMarc, ils ont travaillé ensemble et avec d'autres personnes pour refaire fonctionner l'AGC, dumper les différentes versions du logiciel, et travaillé également sur l'électronique de radiocommunication permettant de transmettre son, image, et commandes à distance pour l'ordinateur lors des mission Apollo.
Et ça ce n'est qu'un seul de leurs projets!
[^] # Re: cela peut même être une excellente chose
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Se détacher des multinationales qui contrôlent les systèmes GNU/Linux ?. Évalué à 4. Dernière modification le 24 octobre 2024 à 17:31.
ah ben parlons en des brevets. Le deal est à peu près honnête quand c'est bien fait: dans un brevet, une entreprise consignetoutesles informations décrivantune invention. En échange, elle a l'exclusivité sur cette invention pendant 20 ans.
Ça marche assez bien pour les médicaments qui deviennent disponible sous forme de "génériques" fabriqués par d'autres entreprises après expiration de ce délai.
Ce système a été mis en place parce que sinon, les entreprises garderaient leurs inventions secrètes (ce que certaines choisissent d'ailleurs de faire, par exemple, la recette du coca cola, c'est un secret et pas un brevet).
Ce principe aurait pu s'appliquer au logiciel, mais pour des raisons diverses, c'est plutôt le mécanisme du droit d'auteur qui a été retenu à la place. Ce qui faisait sens à une époque ou les logiciels étaient diffusés sur bande magnétiques ou sur disquettes, mais peut-être moins maintenant. Mais bon, faut faire avec!