Tu trouve même des fonts qui listent les sinogrammes, mais pas le hangeul de Coréen (qui n'a même pas 50 signes il me semble).
Oh non, beaucoup plus que ça en réalité. En ne réalisant que les jamo isolés modernes et en n’utilisant que le système de normalisation pour re-créer les caractères composés, tu peux réduire à 67 symboles hors ponctuation, mais dans ce cas tu perds presque toute l’optimisation pour la lecture qui est le but de la police mentionnée ici.
C'est là que je me dis que j'ai de la chance de plus faire dev.
En ce qui me concerne, c’est pas « de la chance ». C’est des points que j’aborde aux entretiens techniques d’embauche. On a une profession où on peut souvent se permettre de ne pas prendre n’importe quelle entreprise parce que c’est la seule à proposer du boulot, autant en profiter – et ça ne passe pas que par le salaire.
Je ne vois pas tellement le rapport entre l’open-source et la possibilité d’installer ses outils de dev sur son poste de travail pro ?
Je pense avoir vu à peu près toutes les situations en entreprise (du « ce projet ne fonctionne que dans une VM avec les outils dédiés et les chemins fixes, merci IBM » à « installez ce que vous voulez, vous êtes responsables de votre poste ») sans jamais que la notion d’open-source ne rentre en compte.
Idem pour le lien entre le télétravail et la liberté d’installer quelque chose sur son poste. D’ailleurs, l’entreprise la plus anti-télétravail que j’ai fait (avant le covid) nous laissait tous admins de nos postes sans la moindre forme de contrôle. Tout comme j’ai fait une entreprise avec 3 jours/semaine de télétravail mais impossibilité d’installer la moindre chose sans passer par l’IT.
Comment maintenir la cohérence dans une équipe de dév si chacun y va de sa propre collection de plugins ?
Opinion impopulaire : la cohérence des outils de dev dans une équipe ne devrait pas être un sujet. Chaque dev devrait pouvoir utiliser les outils avec lesquels il est le plus efficace et confortable, quels que soient ceux utilisés dans l’équipe. Un projet bien conçu devrait fonctionner sans problème quels que soient les outils et IDE utilisés ; d’ailleurs, de la diversité dans l’équipe de développement évite certains comportement nuisibles (chemins en dur, dépendance forte à un outil de développement particulier…).
Les outils projets par contre devraient être standards et cohérents au sein d’une équipe (par exemple : toujours utiliser NPM + Vue pour les projets JS front, Gradle + Spring Boot + PostgreSQL pour les projets back, etc).
J’espère avoir le temps de faire un billet plus détaillé sur ce point un de ces quatre.
Je rêve d'un réveil des techos qui se remettraient à écrire des billets simples sur des blogs simples dans un pur but de partage d'expérience. Malheureusement ça n'arrivera pas :(
C’est pas tellement qu’on ne peut pas donner pour une entreprise en réalité, mais que c’est tellement taxé que ça n’a pas d’intérêt pour l’entreprise. Exemple de source :
Attention toutefois à la taxation des dons : des droits de succession peuvent s’appliquer (60 % du montant, soit l’équivalent de dons entre frères et sœurs).
Le don sera aussi taxé à l’impôt sur les sociétés.
En France on ne peut pas donner « pour une entreprise commerciale » sans plus de précision, sauf cas spéciaux. Par contre, on peut donner pour un projet porté par une entreprise (dans ce cas précis, le documentaire sur les guet-apens visant les homosexuels porté par Mediapart). C’est principalement dû aux législations du don qui sont très différentes de celle de la vente, et je laisse les détails aux spécialistes.
Ça explique pourquoi des organes de presse (ici Mediapart, mais aussi d’autres indépendants comme Canard PC) ne peuvent pas recevoir les dons ponctuels de personnes qui voudraient les soutenir sans vouloir ou pouvoir prendre un abonnement complet.
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.
[^] # Re: il y a quand même un inconvénient
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Intel One Mono pour programmer sans fatigue. Évalué à 2.
Oh non, beaucoup plus que ça en réalité. En ne réalisant que les jamo isolés modernes et en n’utilisant que le système de normalisation pour re-créer les caractères composés, tu peux réduire à 67 symboles hors ponctuation, mais dans ce cas tu perds presque toute l’optimisation pour la lecture qui est le but de la police mentionnée ici.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Codium ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Visual Studio Code : un éditeur libre ou un piège pour les développeurs ?. Évalué à 7.
En ce qui me concerne, c’est pas « de la chance ». C’est des points que j’aborde aux entretiens techniques d’embauche. On a une profession où on peut souvent se permettre de ne pas prendre n’importe quelle entreprise parce que c’est la seule à proposer du boulot, autant en profiter – et ça ne passe pas que par le salaire.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Codium ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Visual Studio Code : un éditeur libre ou un piège pour les développeurs ?. Évalué à 4.
Oui, donc je confirme, ça n’a à peu près aucun rapport avec ce que je disais.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Rust
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Visual Studio Code : un éditeur libre ou un piège pour les développeurs ?. Évalué à 6. Dernière modification le 17 mai 2023 à 19:05.
La remarque est valable pour tous les langages qui évoluent, surtout ceux qui partent de loin. Pour ceux qui me viennent en tête : C++, Java, PHP…
Et les problèmes historiques ont la vie dure, cf les deux commentaires sur Java sous ce lien.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Codium ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Visual Studio Code : un éditeur libre ou un piège pour les développeurs ?. Évalué à 3.
Je ne vois pas tellement le rapport entre l’open-source et la possibilité d’installer ses outils de dev sur son poste de travail pro ?
Je pense avoir vu à peu près toutes les situations en entreprise (du « ce projet ne fonctionne que dans une VM avec les outils dédiés et les chemins fixes, merci IBM » à « installez ce que vous voulez, vous êtes responsables de votre poste ») sans jamais que la notion d’open-source ne rentre en compte.
Idem pour le lien entre le télétravail et la liberté d’installer quelque chose sur son poste. D’ailleurs, l’entreprise la plus anti-télétravail que j’ai fait (avant le covid) nous laissait tous admins de nos postes sans la moindre forme de contrôle. Tout comme j’ai fait une entreprise avec 3 jours/semaine de télétravail mais impossibilité d’installer la moindre chose sans passer par l’IT.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Codium ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Visual Studio Code : un éditeur libre ou un piège pour les développeurs ?. Évalué à 10. Dernière modification le 17 mai 2023 à 14:51.
Opinion impopulaire : la cohérence des outils de dev dans une équipe ne devrait pas être un sujet. Chaque dev devrait pouvoir utiliser les outils avec lesquels il est le plus efficace et confortable, quels que soient ceux utilisés dans l’équipe. Un projet bien conçu devrait fonctionner sans problème quels que soient les outils et IDE utilisés ; d’ailleurs, de la diversité dans l’équipe de développement évite certains comportement nuisibles (chemins en dur, dépendance forte à un outil de développement particulier…).
Les outils projets par contre devraient être standards et cohérents au sein d’une équipe (par exemple : toujours utiliser NPM + Vue pour les projets JS front, Gradle + Spring Boot + PostgreSQL pour les projets back, etc).
J’espère avoir le temps de faire un billet plus détaillé sur ce point un de ces quatre.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Translator 2: Judgment Day
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal À quel point votre projet open source doit-il être ouvert ?. Évalué à 5.
À ne pas confondre avec les steak holders, qui sont les personnes qui font cuire les pièces de viande lors d’un barbecue.
-->[]La connaissance libre : https://zestedesavoir.com
[^] # Re: Ouf
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien My 20 Year Career is Technical Debt or Deprecated. Évalué à 6. Dernière modification le 16 mai 2023 à 14:16.
On en trouve quelques-uns, même dans le monde francophone : https://zestedesavoir.com/billets/
(Et les journaux de ZdS, évidemment… mais le but c’était de montrer qu’il n’y a pas qu’ici qu’on voit encore ce genre de chose).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Merci
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Les biais du libriste : vouloir contribuer à ce qui nous tient à cœur. Évalué à 3.
C’est pas tellement qu’on ne peut pas donner pour une entreprise en réalité, mais que c’est tellement taxé que ça n’a pas d’intérêt pour l’entreprise. Exemple de source :
La connaissance libre : https://zestedesavoir.com
[^] # En France, on ne peut pas donner pour une entreprise sans raison particulière
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Les biais du libriste : vouloir contribuer à ce qui nous tient à cœur. Évalué à 9. Dernière modification le 15 mai 2023 à 17:30.
En France on ne peut pas donner « pour une entreprise commerciale » sans plus de précision, sauf cas spéciaux. Par contre, on peut donner pour un projet porté par une entreprise (dans ce cas précis, le documentaire sur les guet-apens visant les homosexuels porté par Mediapart). C’est principalement dû aux législations du don qui sont très différentes de celle de la vente, et je laisse les détails aux spécialistes.
Ça explique pourquoi des organes de presse (ici Mediapart, mais aussi d’autres indépendants comme Canard PC) ne peuvent pas recevoir les dons ponctuels de personnes qui voudraient les soutenir sans vouloir ou pouvoir prendre un abonnement complet.
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é à 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