Se pose ensuite le problème de l'aligement précis, sur les trois axes.
C’est même pire que ça, c’est un problème d’alignement sur 5 ou 6 axes : avant-arrière, gauche-droite, haut-bas, mais aussi rotations en tangage (sur l’axe gauche-droite) et en lacet (sur l’axe haut-bas), sinon l’image pourra être partiellement floue et la mise au point sur tout le capteur impossible. Il n’y a que la rotation en roulis (selon l’axe avant-arrière) qui n’a pas besoin d’être très précise, parce qu’au pire l’appareil devra être un peu penché pour prendre une photo droite, mais ça n’impactera pas la qualité de l’image. D’ailleurs, les capteurs stabilisés de boitiers haut de gamme le sont sur 5 axes (on ne stabilise pas avant-arrière pour éviter de casser le focus).
En fonction de la taille du capteur, on perd juste du champ et on gagne au niveau aberrations, vignetage et distorsion.
En première approche, c’est bien le cas, pour des facteurs de crop faibles. Mais plus tu recadres, plus tu vas avoir des problèmes optiques en plus, en particulier :
Une optique inutilement lourde et encombrante pour son utilité ;
Des limites sur les optiques utilisables (impossibilité d’avoir des grands angles puisque tu recadres l’image) ;
Des problèmes de diffraction si les pixels du capteur sont trop petits (c’est déjà une limite sur les capteurs APS-C actuels ou les capteurs plein formats à haute définition : pour des pixels de 3.9 microns – 24 MPx en APS-C ou 45 en plein format – elle apparait à f/9 et devient visible vers f/11) ;
Ou tout simplement l’atteinte des limites de l’optique, dans le sens où même « parfaitement » mise au point, les défauts de l’optique font que l’image produite est un peu floue quand vue avec la résolution du capteur. C’est un problème classique des vieilles optiques montées sur des boitiers modernes. On considère souvent qu’un film 24x36 standard a un pouvoir de résolution à peu près équivalent à 12 Mpx, les optiques grand public étaient calculées dans ce sens. Or, le Raspberry Pi High Quality Camera a autant de pixels sur une surface 5x plus petite, c’est probable que ces optiques soient incapables de produire une image assez nette pour le pouvoir séparateur de pixels aussi petits.
Et une image floue, c’est irrécupérable, alors que le vignettage et les distorsions géométriques et chromatiques d’un couple (objectif, géométrie de capteur) sont bien connues, stables et se corrigent très bien1 en post-production.
La correction est automatiquement faite par tous les boitiers modernes lors de la production des JPG, au point que ça permet de détecter les testeurs qui ne connaissent pas leur boulot : c’est ceux qui s’extasient devant la perfection du rendu sans préciser s’ils sont allé vérifier le RAW non corrigé. Sisi, ça arrive, sur des sites très connus… ↩
On est d'accord sur l'intérêt technique du truc, c'est clair ! (tout comme je serais intéressé par un retrofit électrique d'une Ferrari).
Par contre je ne crois pas du tout à l'arrivée de capteurs plein format pas chers dans un futur proche, pour une simple question de taille : un capteur plein format, c'est énorme. 24 x 36 mm, ça fait 864 mm² juste pour la surface photosensible. Pour comparaison le GPU d'une GeForce 4090 fait 608,5 mm² et c'est déjà gigantesque. Même un "simple" capteur APS-C (qui ferait un remplaçant honnête même si pas identique, avec un facteur de crop de 1.5 au lieu du facteur 5 du montage présenté) monte déjà à 367 mm² de surface photosensible.
Le problème du monde de la photo, c'est que tu as un couplage très fort entre la taille de ton capteur, la monture, l'optique et les capacités de l'appareil obtenu. Ajoute à ça qu'on peut très bien bricoler de l'informatique, de l'électronique ou de la mécanique, mais beaucoup plus difficilement de l'optique (sauf usages très spécifiques, ou à accepter un rendu d'image de mauvais qualité). Et comme la plupart des appareils anciens sont conçus pour des pellicules 23x36 ou plus grand, les lois de la physique tendent à limiter ce genre de projet au bricolage "pour la démonstration".
Pour faire une analogie hors du monde le la photo, c'est comme si on avait monté un moteur et une batterie de voiture citadine électrique sur une Ferrari. Oui, techniquement ça roule encore, mais de façon très différente de l'usage pour lequel le véhicule a été prévenu. Il faut une vision très large de la chose pour prétendre que la Ferrari modifiée a été "réparée" ou "préservée".
Le bricolage est amusant, mais ça n'est ni "réparer" ni "préserver" l'appareil. Pourquoi ? Parce que le capteur est tellement différent (en taille) de la pellicule d'origine que les caractéristiques photographiques de l'appareil résultant n'ont absolument plus rien à voir avec le Leica M2,et donc l'usage n'est plus le même.
D'ailleurs l'auteur en fait mention dans son article, où il explique utiliser l'un des objectifs le plus grand-angle qui existe pour obtenir un rendu d'objectif à peu près standard.
Utiliser un capteur plein format résoudrait ce problème, mais en poserait beaucoup d'autres pour l'intégration et le prix.
"Loupe" pour le SEO car ça concerne les moteurs de recherche.
En fait je suis assez d'accord avec toi sur l'état actuel de gitmoji.dev. Il me semble que quand je l'ai utilisé il y a quelques années, la liste d'emojis proposée était moins énorme. Mais rien ne t'interdit de reprendre le concept avec une liste réduite et plus cohérente d'emojis.
Un autre avantage du truc : si tu veux mettre plusieurs emojis sur un même commit, c'est souvent un signe que ça devrait être plusieurs commits séparés.
Le "démon" de compilation qui tourne en arrière plan pour massivement augmenter le performances de build, c'est la solution qu'a choisi l'outil de build Gradle (Java et autres langages JVM) face aux énormes problème de performances de Maven (l'outil de build moderne historique dans le domaine – pas le premier mais avant c'était très manuel, par exemple avec Ant),en parallèle de caches et de build incrémental. Cf leur comparaison pour des détails : https://gradle.org/maven-vs-gradle/
Ça ne vient pas sans inconvénients : d'une part les problèmes classiques de caches; d'autre part le fait que (même avec Maven) plus grand monde ne comprends exactement ce qui est fait à la compilation du code.
Pour avoir longtemps fait le même genre de trajet à vélo (non électrique), je ne suis pas vraiment d’accord.
Il y a des « trottoirs partagés » avec assez de place pour que le partage se fasse bien.
Il y en a aussi d’autres qui sont tellement saturés ou avec des gens qui font tellement n’importe quoi que c’est, de fait, un trottoir bondé sur lequel tu peux au mieux rouler au pas. Et là l’effet n’est pas du tout le même, par exemple, en devant passer devant un hopital et une université aux heures de pointes, en période de vacances je gagnais environ 5 minutes le matin sur un trajet de 30. Sans parler du stress de devoir circuler sur cette fichue piste partagée qui borde la voie de tram, avec le tram qui te frôle (voie de tram inutilisable à vélo d’une part parce que c’est super dangereux, et d’autre part parce que toute cette section est en gazon).
En fait, on est très exactement dans le cas décrit par l’article :
ou, être un chemin partagé piéton et vélo, suffisamment large pour une cohabitation sans gène (rue entièrement piétonne)
Dans le cas que je décris, le chemin partagé n’est pas « suffisamment large », il fait à peine la largeur d’une piste cyclable 2 voies normale, et est bordé par un mur ou un grillage d’un côté, et par la voie de tram de l’autre, donc aucun déport possible. Ah, et la voie routière à cet endroit, c’est une autoroute urbaine, suicidaire à vélo (sans parler de l’impossibilité d’y entrer ou d’en sortir).
Sinon, un fallback en accès hors réseau, c’est très bien : ça permet d’accéder au matériel sans avoir à exposer un accès non sécurisé au matériel sur le réseau. Bon, c’est un peu plus pénible parce qu’il faut aller sur place, mais ça dépanne.
En fait, c’est probablement déjà en place sur tous les matériels de ta liste – sauf peut-être les AP Wifi et certains switches managés mal conçus.
Et encore, ça c’est l’explication simple. En réalité, plus aucun processeur x86 n’implémente ses instructions directement en dur dans le silicium mais via un microcode (plus proche du RISC) non utilisable directement par l’utilisateur et qui peut être patché. D’ailleurs, c’était l’un des problèmes des Intel Atom : certaines instructions x86 étaient codées en dur ou correspondant à des instructions microcodées efficaces sur les CPU standards, mais étaient microcodées avec de longues séries d’instructions inefficaces (mais peu consommatrices) sur les Atom, qui devenaient très mauvais dans certaines tâches bien précises. Inversement, nos CPU de bureau/serveur modernes ont des tonnes d’instructions vectorielles complexes très optimisées (et potentiellement très consommatrices, comme AVX512. On ajoute à ça les phénomènes de cache et surtout les pipelines internes aux CPU, les moteurs d’exécution dans le désordre et on peut avoir une efficacité globale supérieure à une instruction par cycle d’horloge.
Quoi qu’il en soit, parler de RISC ou de CISC aujourd’hui n’a plus vraiment de sens, sauf peut-être pour désigner la taille d’un jeu d’instruction précis. Surtout, ça n’a plus aucun lien avec la complexité réelle d’un CPU physique, ni avec son éventuelle efficacité énergétique.
Cela dit, aujourd’hui, dans les processeurs « à grande disponibilité » (ce qu’on trouve dans le matériel qu’on a chez soi, ou dans un fournisseur de cloud quelconque – et pas seulement l’un d’entre eux) on a encore souvent le choix entre du x86 très performant (surtout en terme de performance par cœur) mais consommateur (en terme de puissance par ~instruction), et de l’ARM plus efficace énergétiquement mais moins performant.
(La limite de temps d’édition est vraiment trop courte, et le message d’erreur vraiment pas terrible)
Pour les serveurs je pensais à ce test, ou à toutes les offres réellement disponibles, notamment les offres ARM chez Scaleway. Ça c’est les récentes, les anciennes – avec lesquelles Scaleway s’est lancé – étaient notoirement moins puissantes que du x86 type Intel Xeon (côté AMD il n’y avait pas encore d’EPYC et les Opteron étaient obsolètes). Amazon a aussi sorti un processeur pour serveur cloud orienté performances dont la seconde itération a des capacités comparables au x86 mais c’est du spécifique Amazon, je ne crois pas qu’on ait d’informations sur la consommation électrique – et on a encore moins d’analyse indépendante de ce point de vue.
Cela dit tu mets le doigt sur un détail important : historiquement, les CPU ARM sont surtout des CPU orientés consommation (très basse puissance, ou « performance » mais pour appareils mobiles donc avec une consommation tout de même assez réduite), et les CPU x86 sont orienté performance avec quelques gammes (Intel Atom/Avoton par exemple) qui étaient des brouettes qui se faisaient éclater dans tous les tests. C’est moins vrai aujourd’hui, en particulier avec l’arrivée d’ARM dans du matériel haute performance (serveurs – cf le processeur d’Amazon – ou les processeurs des Mac). Le fait qu’on trouve aussi une architecture type big.LITTLE (cœurs haute efficacité et haute performance au sein d’un même CPU) en ARM et en x86 complique encore plus la comparaison.
En terme d'efficacité énergétique pure, le x86(-64) est souvent assez mauvais comparé à d'autres architectures, surtout dars ses implémentations classiques (les gros CPU d'ordinateurs ou de serveurs avec les tonnes d'extensions du jeu d'instructions).
Mais en terme de puissance pure, on arrive à en faire des processeurs extrêmement puissants. Ajoute à ça que c'est un peu "le jeu d'instructions par défaut" pour les ordinateurs et serveurs, donc que la compatibilité est très bonne et que tu n'as pas de problème de cross-compilation pendant le développement (sauf si tu développes en langage compilé directement pour le processeur sur un Mac moderne), et ça explique pourquoi malgré tout on a encore énormément de serveurs, même cloud, en x86(-64). Même si on trouve du cloud en ARM assez facilement maintenant, tout comme des puces ARM franchement puissantes.
Pour Pepper & Carrot, les BD sont sous licence CC BY 4.0 qui autorise tout à fait la reprise sous une autre licence (ou même la reprise non-libre). Le point que tu soulèves aurait posé problème si ça avait été du CC BY-SA (licence par défaut sur linuxfr.org) à cause de la clause « Share Alike » qui oblige à repartager les œuvres dérivées sous la même licence ou compatible.
Pourtant je doute que 6 personnes aient cliqué sur pertinent sans même avoir lu l’article en lien.
Au risque de surprendre, je suis prêt à prendre le pari que si. En fait c’est même très possible que le sujet ait été pertinenté directement depuis la liste des liens, sans même ouvrir la page de liens.
Je ne sais pas pourquoi on a les liens pertinent / inutile sur les pages de listes (dépêches, journaux, liens…), en fait.
Ici, les gens qui ont planté leur OS sont ceux qui ont appliqué des « procédures de sécurité » complètement pétées, qui ont mené à la suppression ou au remplacement sauvage d’un composant essentiel du système. Au lire de l’article, j’ai l’impression que les deux sources principales qui ont mené à ces comportement sont une lecture paranoïaque des CVE et des métriques délirantes et hors-sol de gestion de la « sécurité » d’un parc informatique. En plus d’une méconnaissance crasse des principes de fonctionnement de sécurité de l’OS.
Par contre, qu’un OS – surtout aussi attaqué que celui-ci – se mette en protection s’il détecte des changements imprévus dans ses fichiers système ne me choque pas outre mesure.
La justification de Gemtext me conforte dans ce que je pensais : c’est complètement un projet d’ingénieur, qui part d’une considération technique (ici la simplicité d’implémentation) et pas d’un besoin fonctionnel. Ça ne le rends pas moins légitime, mais pour moi c’est un frein à son adoption à « grande » échelle.
Pour les textes littéraires, personnellement je rajouterais quand même au moins un mode d’emphase (et idéalement les deux, même si le gras est plus rare que l’italique), des notes en bas de page, une différenciation entre « saut de ligne » et « saut de paragraphe » et la possibilité d’avoir un « séparateur » (en général trois étoiles * * * centrées sur une ligne).
Le projet Gemini est intéressant d’un point de vue technique, mais je ne crois pas à son utilisabilité au quotidien. Le meilleur exemple est que l’article en lien utilise beaucoup de fonctionnalités qui ne sont pas disponibles dans Gemtext, en particulier : la mise en emphase (en gras et en italique) et les liens « embarqués dans un paragraphe » avec du texte alternatif – je suis gentil, je pars du principe que les smileys sont gérés comme des caractères et que les « blocs de citation » permettent le code « inline » qui est beaucoup utilisé dans l’article.
Je ne sais pas trop pourquoi Gemtext a été simplifié à ce point, au point d’en devenir inutilisable même pour un simple « texte bien conçu en-dehors de toute considération de style d’affichage », sachant que la simple gestion du protocole TLS (obligatoire) doit être beaucoup plus consommatrice en terme de ressources (CPU, RAM, réseau) que les deux points de mise en forme que je mentionne plus haut.
Bref, ça me semble être un projet d’ingénieur rigolo, mais qui par conception ne semble pas pouvoir aller plus loin.
C’est un résumé des problèmes posés par le Starship, qui est bien loin du rêve promis par les communiqués officiels et des déclarations grandiloquentes des zélotes de Musk. À peu près dans l’ordre :
Le problème du méthane et de son extraction, avec le cas particulier de Boca Chica (l’endroit où est installée la base de SpaceX au Texas) ;
Le comportement abject de SpaceX avec les habitants de Boca Chica (expropriation forcée des locaux sous de faux prétextes de « sécurité » pour installer les travailleurs de SpaceX dans les habitations des personnes qui habitaient là avant) ;
Le fait que SpaceX se torche avec les obligations de la FAA (l’organisme des USA qui gère les autorisations d’installation et de vols spatiaux, entre autres) et leur ment ouvertement ;
Les dégâts provoqués par le site de Boca Chica à l’environnement local, qui contient énormément d’espèces protégées (et la réalité est très éloignée à la fois des communiqués officiels de Musk et de la protection mise en place en Floride par la NASA) ;
Débunk des délires de Musk sur la colonisation de la galaxie (c’est absolument impossible, pour causes de lois de la physique, dans tous les futurs imaginables à l’échelle de centaines d’années) ;
Débunk des délires de Musk sur la colonisation martienne et sa terraformation ;
Débunk de l’usage « earth to earth » (un genre d’avion hypersonique) du Starship ;
Point sur le danger inhérent à un Starship habité (il n’a absolument aucun système de secours, ne peut pas en être équipé sans modifications profondes – parachutes ou tour de sauvetage –, n’est pas pilotable manuellement, ne plane pas, et son retour exige des manœuvres risquées sans grosse marge de sécurité) ;
Pourquoi la NASA a quand même choisi ce truc pour les missions lunaires ;
Pourquoi la proposition très récurrente de se servir d’un Starship pour « sauver / ramener Hubble » n’a aucun sens pratique.
[^] # Re: Ça n'est ni "réparer" ni "préserver"
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal de l'argentique en numérique. Évalué à 4. Dernière modification le 15 mai 2023 à 11:50.
C’est même pire que ça, c’est un problème d’alignement sur 5 ou 6 axes : avant-arrière, gauche-droite, haut-bas, mais aussi rotations en tangage (sur l’axe gauche-droite) et en lacet (sur l’axe haut-bas), sinon l’image pourra être partiellement floue et la mise au point sur tout le capteur impossible. Il n’y a que la rotation en roulis (selon l’axe avant-arrière) qui n’a pas besoin d’être très précise, parce qu’au pire l’appareil devra être un peu penché pour prendre une photo droite, mais ça n’impactera pas la qualité de l’image. D’ailleurs, les capteurs stabilisés de boitiers haut de gamme le sont sur 5 axes (on ne stabilise pas avant-arrière pour éviter de casser le focus).
En première approche, c’est bien le cas, pour des facteurs de crop faibles. Mais plus tu recadres, plus tu vas avoir des problèmes optiques en plus, en particulier :
Et une image floue, c’est irrécupérable, alors que le vignettage et les distorsions géométriques et chromatiques d’un couple (objectif, géométrie de capteur) sont bien connues, stables et se corrigent très bien1 en post-production.
La correction est automatiquement faite par tous les boitiers modernes lors de la production des JPG, au point que ça permet de détecter les testeurs qui ne connaissent pas leur boulot : c’est ceux qui s’extasient devant la perfection du rendu sans préciser s’ils sont allé vérifier le RAW non corrigé. Sisi, ça arrive, sur des sites très connus… ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: Ça n'est ni "réparer" ni "préserver"
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal de l'argentique en numérique. Évalué à 10.
On est d'accord sur l'intérêt technique du truc, c'est clair ! (tout comme je serais intéressé par un retrofit électrique d'une Ferrari).
Par contre je ne crois pas du tout à l'arrivée de capteurs plein format pas chers dans un futur proche, pour une simple question de taille : un capteur plein format, c'est énorme. 24 x 36 mm, ça fait 864 mm² juste pour la surface photosensible. Pour comparaison le GPU d'une GeForce 4090 fait 608,5 mm² et c'est déjà gigantesque. Même un "simple" capteur APS-C (qui ferait un remplaçant honnête même si pas identique, avec un facteur de crop de 1.5 au lieu du facteur 5 du montage présenté) monte déjà à 367 mm² de surface photosensible.
Le problème du monde de la photo, c'est que tu as un couplage très fort entre la taille de ton capteur, la monture, l'optique et les capacités de l'appareil obtenu. Ajoute à ça qu'on peut très bien bricoler de l'informatique, de l'électronique ou de la mécanique, mais beaucoup plus difficilement de l'optique (sauf usages très spécifiques, ou à accepter un rendu d'image de mauvais qualité). Et comme la plupart des appareils anciens sont conçus pour des pellicules 23x36 ou plus grand, les lois de la physique tendent à limiter ce genre de projet au bricolage "pour la démonstration".
La connaissance libre : https://zestedesavoir.com
[^] # Re: Ça n'est ni "réparer" ni "préserver"
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal de l'argentique en numérique. Évalué à 5.
Pour faire une analogie hors du monde le la photo, c'est comme si on avait monté un moteur et une batterie de voiture citadine électrique sur une Ferrari. Oui, techniquement ça roule encore, mais de façon très différente de l'usage pour lequel le véhicule a été prévenu. Il faut une vision très large de la chose pour prétendre que la Ferrari modifiée a été "réparée" ou "préservée".
La connaissance libre : https://zestedesavoir.com
# Ça n'est ni "réparer" ni "préserver"
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal de l'argentique en numérique. Évalué à 6.
Le bricolage est amusant, mais ça n'est ni "réparer" ni "préserver" l'appareil. Pourquoi ? Parce que le capteur est tellement différent (en taille) de la pellicule d'origine que les caractéristiques photographiques de l'appareil résultant n'ont absolument plus rien à voir avec le Leica M2,et donc l'usage n'est plus le même.
D'ailleurs l'auteur en fait mention dans son article, où il explique utiliser l'un des objectifs le plus grand-angle qui existe pour obtenir un rendu d'objectif à peu près standard.
Utiliser un capteur plein format résoudrait ce problème, mais en poserait beaucoup d'autres pour l'intégration et le prix.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Jamais pratiqué
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Des emojis dans votre historique Git (ou tout autre CVS) ?. Évalué à 4.
Effectivement j’ai oublié de préciser que c’est une forme de conventional commit. On faisait du copier/coller.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Minimaliste pas partout
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Voici Pulse, un navigateur web minimaliste basé sur Firefox. Évalué à 3.
Fait.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Minimaliste pas partout
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Voici Pulse, un navigateur web minimaliste basé sur Firefox. Évalué à 4.
"Loupe" pour le SEO car ça concerne les moteurs de recherche.
En fait je suis assez d'accord avec toi sur l'état actuel de gitmoji.dev. Il me semble que quand je l'ai utilisé il y a quelques années, la liste d'emojis proposée était moins énorme. Mais rien ne t'interdit de reprendre le concept avec une liste réduite et plus cohérente d'emojis.
Un autre avantage du truc : si tu veux mettre plusieurs emojis sur un même commit, c'est souvent un signe que ça devrait être plusieurs commits séparés.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Minimaliste pas partout
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Voici Pulse, un navigateur web minimaliste basé sur Firefox. Évalué à 10.
C’est pas des emojis au pif https://gitmoji.dev/ et en vrai c’est pas idiot dans les messages de commit. À l’usage, c’est pratique.
La connaissance libre : https://zestedesavoir.com
[^] # Re: compilateur ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Comment les "jumbo build" ont bavé dans les sources de Firefox. Évalué à 4.
Le "démon" de compilation qui tourne en arrière plan pour massivement augmenter le performances de build, c'est la solution qu'a choisi l'outil de build Gradle (Java et autres langages JVM) face aux énormes problème de performances de Maven (l'outil de build moderne historique dans le domaine – pas le premier mais avant c'était très manuel, par exemple avec Ant),en parallèle de caches et de build incrémental. Cf leur comparaison pour des détails : https://gradle.org/maven-vs-gradle/
Ça ne vient pas sans inconvénients : d'une part les problèmes classiques de caches; d'autre part le fait que (même avec Maven) plus grand monde ne comprends exactement ce qui est fait à la compilation du code.
La connaissance libre : https://zestedesavoir.com
# Le bon lien
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien un serveur web pour exécuter les modèles AI par Fabrice Bellard. Évalué à 6. Dernière modification le 05 mai 2023 à 10:18.
Le bon lien est https://bellard.org/ts_server/
Celui avec les
wwwprovoque une erreur de sécurité parce que le certificat n’est valide que pourbellard.org.La connaissance libre : https://zestedesavoir.com
[^] # Re: Séparation piéton / vélo
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Le top 10 des villes cyclables en France. Évalué à 9.
Pour avoir longtemps fait le même genre de trajet à vélo (non électrique), je ne suis pas vraiment d’accord.
Il y a des « trottoirs partagés » avec assez de place pour que le partage se fasse bien.
Il y en a aussi d’autres qui sont tellement saturés ou avec des gens qui font tellement n’importe quoi que c’est, de fait, un trottoir bondé sur lequel tu peux au mieux rouler au pas. Et là l’effet n’est pas du tout le même, par exemple, en devant passer devant un hopital et une université aux heures de pointes, en période de vacances je gagnais environ 5 minutes le matin sur un trajet de 30. Sans parler du stress de devoir circuler sur cette fichue piste partagée qui borde la voie de tram, avec le tram qui te frôle (voie de tram inutilisable à vélo d’une part parce que c’est super dangereux, et d’autre part parce que toute cette section est en gazon).
En fait, on est très exactement dans le cas décrit par l’article :
Dans le cas que je décris, le chemin partagé n’est pas « suffisamment large », il fait à peine la largeur d’une piste cyclable 2 voies normale, et est bordé par un mur ou un grillage d’un côté, et par la voie de tram de l’autre, donc aucun déport possible. Ah, et la voie routière à cet endroit, c’est une autoroute urbaine, suicidaire à vélo (sans parler de l’impossibilité d’y entrer ou d’en sortir).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Moué ben perso je pense que http devrait survivre !
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien RIP HTTP. Évalué à 6.
Sinon, un fallback en accès hors réseau, c’est très bien : ça permet d’accéder au matériel sans avoir à exposer un accès non sécurisé au matériel sur le réseau. Bon, c’est un peu plus pénible parce qu’il faut aller sur place, mais ça dépanne.
En fait, c’est probablement déjà en place sur tous les matériels de ta liste – sauf peut-être les AP Wifi et certains switches managés mal conçus.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Performance
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Une nouvelle carte à processeur RISC-V : la Star64. Évalué à 9.
Et encore, ça c’est l’explication simple. En réalité, plus aucun processeur x86 n’implémente ses instructions directement en dur dans le silicium mais via un microcode (plus proche du RISC) non utilisable directement par l’utilisateur et qui peut être patché. D’ailleurs, c’était l’un des problèmes des Intel Atom : certaines instructions x86 étaient codées en dur ou correspondant à des instructions microcodées efficaces sur les CPU standards, mais étaient microcodées avec de longues séries d’instructions inefficaces (mais peu consommatrices) sur les Atom, qui devenaient très mauvais dans certaines tâches bien précises. Inversement, nos CPU de bureau/serveur modernes ont des tonnes d’instructions vectorielles complexes très optimisées (et potentiellement très consommatrices, comme AVX512. On ajoute à ça les phénomènes de cache et surtout les pipelines internes aux CPU, les moteurs d’exécution dans le désordre et on peut avoir une efficacité globale supérieure à une instruction par cycle d’horloge.
Quoi qu’il en soit, parler de RISC ou de CISC aujourd’hui n’a plus vraiment de sens, sauf peut-être pour désigner la taille d’un jeu d’instruction précis. Surtout, ça n’a plus aucun lien avec la complexité réelle d’un CPU physique, ni avec son éventuelle efficacité énergétique.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Performance
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Une nouvelle carte à processeur RISC-V : la Star64. Évalué à 3.
Cela dit, aujourd’hui, dans les processeurs « à grande disponibilité » (ce qu’on trouve dans le matériel qu’on a chez soi, ou dans un fournisseur de cloud quelconque – et pas seulement l’un d’entre eux) on a encore souvent le choix entre du x86 très performant (surtout en terme de performance par cœur) mais consommateur (en terme de puissance par ~instruction), et de l’ARM plus efficace énergétiquement mais moins performant.
(La limite de temps d’édition est vraiment trop courte, et le message d’erreur vraiment pas terrible)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Performance
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Une nouvelle carte à processeur RISC-V : la Star64. Évalué à 6.
Pour les serveurs je pensais à ce test, ou à toutes les offres réellement disponibles, notamment les offres ARM chez Scaleway. Ça c’est les récentes, les anciennes – avec lesquelles Scaleway s’est lancé – étaient notoirement moins puissantes que du x86 type Intel Xeon (côté AMD il n’y avait pas encore d’EPYC et les Opteron étaient obsolètes). Amazon a aussi sorti un processeur pour serveur cloud orienté performances dont la seconde itération a des capacités comparables au x86 mais c’est du spécifique Amazon, je ne crois pas qu’on ait d’informations sur la consommation électrique – et on a encore moins d’analyse indépendante de ce point de vue.
Cela dit tu mets le doigt sur un détail important : historiquement, les CPU ARM sont surtout des CPU orientés consommation (très basse puissance, ou « performance » mais pour appareils mobiles donc avec une consommation tout de même assez réduite), et les CPU x86 sont orienté performance avec quelques gammes (Intel Atom/Avoton par exemple) qui étaient des brouettes qui se faisaient éclater dans tous les tests. C’est moins vrai aujourd’hui, en particulier avec l’arrivée d’ARM dans du matériel haute performance (serveurs – cf le processeur d’Amazon – ou les processeurs des Mac). Le fait qu’on trouve aussi une architecture type big.LITTLE (cœurs haute efficacité et haute performance au sein d’un même CPU) en ARM et en x86 complique encore plus la comparaison.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Performance
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Une nouvelle carte à processeur RISC-V : la Star64. Évalué à 7. Dernière modification le 01 mai 2023 à 11:54.
En terme d'efficacité énergétique pure, le x86(-64) est souvent assez mauvais comparé à d'autres architectures, surtout dars ses implémentations classiques (les gros CPU d'ordinateurs ou de serveurs avec les tonnes d'extensions du jeu d'instructions).
Mais en terme de puissance pure, on arrive à en faire des processeurs extrêmement puissants. Ajoute à ça que c'est un peu "le jeu d'instructions par défaut" pour les ordinateurs et serveurs, donc que la compatibilité est très bonne et que tu n'as pas de problème de cross-compilation pendant le développement (sauf si tu développes en langage compilé directement pour le processeur sur un Mac moderne), et ça explique pourquoi malgré tout on a encore énormément de serveurs, même cloud, en x86(-64). Même si on trouve du cloud en ARM assez facilement maintenant, tout comme des puces ARM franchement puissantes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Source pour "licencié"?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Wikimedia: 7% d'employés en moins depuis janvier. Évalué à 3. Dernière modification le 27 avril 2023 à 16:16.
Dont acte : https://linuxfr.org/suivi/supprimer-les-liens-pertinent-inutile-des-pages-de-liste-de-contenus-depeches-journaux-liens
La connaissance libre : https://zestedesavoir.com
[^] # Re: Licences
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Premier jeu online pour Nintendo NES : Super Tilt Bro.. Évalué à 9.
Pour Pepper & Carrot, les BD sont sous licence CC BY 4.0 qui autorise tout à fait la reprise sous une autre licence (ou même la reprise non-libre). Le point que tu soulèves aurait posé problème si ça avait été du CC BY-SA (licence par défaut sur linuxfr.org) à cause de la clause « Share Alike » qui oblige à repartager les œuvres dérivées sous la même licence ou compatible.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Source pour "licencié"?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Wikimedia: 7% d'employés en moins depuis janvier. Évalué à 4.
Au risque de surprendre, je suis prêt à prendre le pari que si. En fait c’est même très possible que le sujet ait été pertinenté directement depuis la liste des liens, sans même ouvrir la page de liens.
Je ne sais pas pourquoi on a les liens pertinent / inutile sur les pages de listes (dépêches, journaux, liens…), en fait.
La connaissance libre : https://zestedesavoir.com
[^] # Re: ... et surtout qui n'existe pas (encore)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Les réacteurs à sels fondus, une énergie nucléaire moins chère et surtout plus sûre. Évalué à 5.
SuperPhénix a ferme d’abord et avant tout pour des raisons politiques. Source : Rapport de commission d’enquête du Sénat, Henri Revol, 1998.
La connaissance libre : https://zestedesavoir.com
# « Mauvaise sécurité » plutôt que « Trop de sécurité »
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Trop de sécurité est pire que peu de sécurité (un nano problème qui amène à planter l'OS). Évalué à 6.
Ici, les gens qui ont planté leur OS sont ceux qui ont appliqué des « procédures de sécurité » complètement pétées, qui ont mené à la suppression ou au remplacement sauvage d’un composant essentiel du système. Au lire de l’article, j’ai l’impression que les deux sources principales qui ont mené à ces comportement sont une lecture paranoïaque des CVE et des métriques délirantes et hors-sol de gestion de la « sécurité » d’un parc informatique. En plus d’une méconnaissance crasse des principes de fonctionnement de sécurité de l’OS.
Par contre, qu’un OS – surtout aussi attaqué que celui-ci – se mette en protection s’il détecte des changements imprévus dans ses fichiers système ne me choque pas outre mesure.
La connaissance libre : https://zestedesavoir.com
# ... Wow. Ça faisait longtemps que j’avais pas vu un site pareil !
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien la double authentification par SMS deviendrait obsolete à cause du SIM-swapping ?. Évalué à 4.
Avec μBlock Origin d’activé :
(la popup n’arrive pas instantanément)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Ô ironie, quand tu nous tiens…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Décollage : ce blog vient d'être propulsé dans le Geminispace ! [présentation du projet Gemini]. Évalué à 3.
Merci pour ces détails !
La justification de Gemtext me conforte dans ce que je pensais : c’est complètement un projet d’ingénieur, qui part d’une considération technique (ici la simplicité d’implémentation) et pas d’un besoin fonctionnel. Ça ne le rends pas moins légitime, mais pour moi c’est un frein à son adoption à « grande » échelle.
Pour les textes littéraires, personnellement je rajouterais quand même au moins un mode d’emphase (et idéalement les deux, même si le gras est plus rare que l’italique), des notes en bas de page, une différenciation entre « saut de ligne » et « saut de paragraphe » et la possibilité d’avoir un « séparateur » (en général trois étoiles * * * centrées sur une ligne).
La connaissance libre : https://zestedesavoir.com
# Ô ironie, quand tu nous tiens…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Décollage : ce blog vient d'être propulsé dans le Geminispace ! [présentation du projet Gemini]. Évalué à 6.
Le projet Gemini est intéressant d’un point de vue technique, mais je ne crois pas à son utilisabilité au quotidien. Le meilleur exemple est que l’article en lien utilise beaucoup de fonctionnalités qui ne sont pas disponibles dans Gemtext, en particulier : la mise en emphase (en gras et en italique) et les liens « embarqués dans un paragraphe » avec du texte alternatif – je suis gentil, je pars du principe que les smileys sont gérés comme des caractères et que les « blocs de citation » permettent le code « inline » qui est beaucoup utilisé dans l’article.
Je ne sais pas trop pourquoi Gemtext a été simplifié à ce point, au point d’en devenir inutilisable même pour un simple « texte bien conçu en-dehors de toute considération de style d’affichage », sachant que la simple gestion du protocole TLS (obligatoire) doit être beaucoup plus consommatrice en terme de ressources (CPU, RAM, réseau) que les deux points de mise en forme que je mentionne plus haut.
Bref, ça me semble être un projet d’ingénieur rigolo, mais qui par conception ne semble pas pouvoir aller plus loin.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Vu passer, quid?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Magouilles et mensonges au pays du Starship (Stardust - La Chaîne Air & Espace - YouTube). Évalué à 10.
C’est un résumé des problèmes posés par le Starship, qui est bien loin du rêve promis par les communiqués officiels et des déclarations grandiloquentes des zélotes de Musk. À peu près dans l’ordre :
La connaissance libre : https://zestedesavoir.com