Il est construit sur un modèle qui n'existe plus: un seul fil d'exécution, pas de mémoire cache, des instructions qui s'exécutent dans l'ordre ou elles sont présentes dans le programme, un ensemble de registres fixes. Aujourd'hui, un ordinateur ne fonctionne plus comme ça. Il y a plusieurs CPUs qui chacun peuvent exécuter plusieurs threads en parallèle, plusieurs niveaux de mémoire cache et de mémoire virtuelle, les instructions sont exécutées dans le désordre et même parfois exécutées avant d'être finalement annulées, et les registres visibles en assembleur n'existent pas vraiment, le processeur assigne ses registres internes dynamiquement en fonction des dépendances qu'il détecte entre les instructions.
Donc, non, le C n'est pas vraiment proche du comportement du matériel actuel. Il est proche du fonctionnement d'un ordinateur des années 70-80. Ça permet d'avoir un modèle simple à comprendre (mais approximatif) de ce qu'il se passe. Mais on pourrait prendre un autre modèle moins proche du PDP-11 et ça fonctionnerait bien aussi. Par exemple quand on programme en Smalltalk, on réfléchit en terme d'objets qui s'envoient des messages, et on peut très bien parler de performances dans ce contexte (combien d'objets sont créés/supprimés, combien de messages sont envoyés, etc). Ou par exemple si on fait du Haskell, on réfléchit en terme de fonctions, et les optimisations se font à un autre niveau (qu'est-ce qui peut être précalculé à la compilation?).
La difficulté de C++ (je prend cet exemple parce que je le connaît bien), c'est surtout qu'il y a plusieurs façons de penser qui sont mélangées dans un seul langage. À la fois c'est intéressant, parce que ça permet d'écrire du code à différent niveaux d'abstraction sans trop s'embêter. À la fois, on a vite fait de tomber dans un piège parce qu'on saute sans cesse d'une façon de penser à une autre (de la programmation objet, impérative, procédurale, ou même fonctionnelle).
C'est moins tordu et muins impressionnant, mais tout aussi efficace. Et une bonne raison pour interdire le caractère espace dans le code source, comme c'est proposé pour les autres caractères problématiques, afin d'éviter tout risque de confusion.
La NES et la SuperNES aussi, et la MegaDrive chez Sega. Je pense que la Nintendo 64 aussi mais je me trompe peut-être.
Pour la Game Boy et l'Atari Lynx il y a un BIOS de quelques centaines d'octets et qui ne peut pas être appelé par les jeux (il est là juste pour vérifier que la cartouche insérée est valide, et démarrer l'exécution du code).
Pour les consoles sans cartouches c'est effectivement plus compliqué.
Il y a l'approche du CDi qui est de fournir une API standardisée et d'interdire aux jeux d'accéder directement au matériel. Et d'avoir plusieurs implémentations incompatibles du matériel pour s'assurer que c'est bien le cas.
Mais même une console qui aurait un noyau Linux et laisserait chaque jeu démarrer son propre userspace, ça marcherait peut être pas si mal que ça, et ça ressemblerait finalement assez aux Snap et Flatpak, en moins compliqué. Bon, c'est déjà un peu passé de mode de distribuer des jeux sur supports physiques, cela dit…
On pourrait distribuer chaque jeu sur un support de stockage bootable contentant tout le code nécessaire, permettant à l'éditeur du jeu de choisir exactement ce qu'il inclut et de ne pas avoir de conflit entre les jeux.
Et on appellerait ça une console de jeux? ça serait simple et facile à utiliser.
On a pas le luxe chez Haiku d'être assez nombreux pour clairement séparer les deux. En théorie c'est le cas, les paquets pour les logiciels tiers sont gérés par Haikuports.
En pratique, les gens qui essaient de porter des logiciels trouvent des bugs dans le système et souvent finissent par les corriger eux-même. Et les gens qui développent l'OS veulent utiliser des logiciels ou bibliothèques qui ne sont pas encore packagées (ou pas dans la bonne version) et doivent le faire eux-même. Il y a donc une assez large intersection entre les deux équipes, et une seule association (Haiku inc) qui paie les serveurs et autres dépenses pour les deux projets.
Pour les applications natives, il n'y a pas vraiment besoin de passer par un "maintainer". Les développeurs d'applications sont aussi des utilisateurs de l'OS (ou même des développeurs de l'OS) et connaissent assez bien le système. Ce n'est pas très compliqué de distribuer un logiciel, soit sous forme d'un paquet hpkg, soit sous forme d'un simple fichier zip à décompresser.
Pour les applications portées, ça dépend, on a certains développeurs qui sont motivés pour faire les choses proprement, d'autres qui n'ont pas du tout envie de gérer des cas particuliers, et un peu de tout entre les deux.
Mais surtout, ce qui est important: on compte sur les utilisateurs pour se plaindre quand un logiciel est plus gros que l'installation de base de Haiku (quelques centaines de Mo).
Ça me rapelle qu'il y a un épisode sur Jocelyn Bell dans la série d'interviews Almost Famous du New York Times (vidéos en anglais), si jamais vous voulez en savoir un peu plus.
Snap + AppImage + Flatpak, c'est pas vraiment quasi-unique. Surtout que ça ne remplace pas les autres solutions, ça ne fait qu'en rajouter encore plus.
Chez Haiku (puisqu'on parle de nous, hein…), on aimerait bien que les développeurs d'applications distribuent eux-même leur travail et qu'on aie pas besoin de tout packager nous-mêmes.
Notre approche est la suivante:
- Une "distribution" standard du système, qui est la seule à avoir le droit d'utiliser la marque Haiku sans autres précision (d'autres distributions ont existé, par exemple Senryu, TiltOS, ou Discover Haiku)
- Une ABI et API stable. Actuellement c'est celle de BeOS, qui n'a pas bougé depuis 20 ans. Mais on est conscients que ce n'est pas réaliste car ça imposerait de tout compiler avec gcc2 et de n'utiliser aucune des nouvelles APIs ajoutées depuis,
- L'introduction de nouvelles APIs se fait d'abord dans des bibliothèques statiques etdans un namespace dédié. Les applications utilisant ces APIs embarquent donc une copie du code concerné, etne sont pas affectées par les mises à jour
- Pour les APIs stables utilisables en bibliothèques partagées, diverses astuces pour se garder des moyens de faire évoluer les choses: réservation d'espace dans la vtable et les champ de tous les objets C++, surcharge systématique de certaines méthodes pour pouvoir en modifier le comportement plus tard, versionning de symboles, ajout de bouchons permettant aux applications utilisant une fonction qui n'existe plus de continuer à fonctionner, etc.
- Fourniture d'une API qui couvre pas mal de besoins (graphique, réseau, multimédia, …) évitant ainsi la prolifération de bibliothèque faisant toutes un peu la même chose
Ça marche plutôt bien pour les applications natives. C'est plus compliqué pour les applications portées depuis Linux ou il y a souvent plein de dépendances vers diverses bibliothèques et des problèmes de compatibilité qui surviennent très régulièrement. Pas trop d'accord avec l'auteur de l'article pour dire que c'est définitivement réglé, donc…
En vrai, Kenwood s'en sort pas si mal, ce modèle de robot est vendu depuis 2007, et il reste encore du stock pour certaines pièces.
Et peut-être que les générations suivantes ne sont pas compatibles pour une bonne raison, par exemple une pièce qui vieillit mal et qui a été redessinée pour corriger le problème.
Sur le blender, à part le problème de fissures, il m'est arrivé une fois de mal verrouiller la pièce qui contient la lame (démontable pour pouvoir la nettoyer), résultat elle s'est détachée et tout le contenu du blender a fini sur mon plan de travail. C'est le genre de problème qu'il est bien de corriger.
Même chose sur ta machine à laver: si c'est tout le temps la même pièce qui casse, c'est mieux de ne pas garder cette pièce sur le modèle suivant.
Je suis surtout embêté parce qu'il y a l'air d'avoir des pièces qui sont peut-être compatibles (en tout cas sur les photos ça ressemble beaucoup), mais qui ne sont pas annoncées comme compatible. J'aurai pu apporter mon blender chez un distributeur de pièces pas trop loin de chez moi, mais il faudrait qu'il aie la pièce de rechange en stock pour vérifier si elle est éventuellement compatible. Et c'est là que en effet, un peu de standardisation ne ferait pas de mal.
Ça va me coûter plus cher en heures de travail pour faire un modèle 3D convenable qui s'adapte au support avec l'hélice du Blender. Et je ne suis pas convaincu que le résultat sera suffisament solide.
Et ça prend un peu de place, un blender d'une contenance de 1.5L, il faut une imprimante 3D assez grande.
Il ne s'agit pas d'un site officiel, c'est un revendeur de pièces comme il y en a plein d'autres, mais qui entretient la confusion avec un nom de domaine et un design de site web un peu trompeur. On peut le voir facilement en allant voir la page "about us".
J'ai trouvé un site officiel pour les pièces détachées (sous la marque DeLonghi qui a apparament racheté la marque Kenwood), mais seulement pour l'Australie et la Nouvelle Zélande
Pour rappel, une banane est radioactive aussi: environ 15 Becquerel par banane (à cause du potassium) source.
Boire un litre d'eau de la Garonne est donc à peu près aussi dangereux que de manger une banane.
C'est cohérent avec le graphique proposé par XKCD pour comparer l'exposition aux radiations dans différents cas.
Quelques rappels utiles:
- Utiliser un écran cathodique pendant 1 an est équivalent à manger 10 bananes,
- Habiter à proximité d'une centrale à charbon vous expose à 3 fois plus de radiations qu'une centrale nucléaire,
- Habiter dans un bâtiment en briques, béton ou pierre de taille pendant un an: équivalent à manger 70 bananes,
- Être un humain normalement constitué sans carence en potassium pendant un an: équivalent à manger 390 bananes.
Je n'ai pas fait le calcul du poids d'une banane déshydratée pour pouvoir comparer avec le kilogramme de carbone.
Il est aussi derrière fsfellowship (soi-disant un fork de la FSFE).
Il a spammé les mentors du Google Summer of Code en récupérant leurs emails sur la mailing list officielle (dont il a été banni) pour les inscrire de force sur une mailing list parallèle.
En tout cas il a l'air d'avoir des problèmes avec vraiment beaucoup de monde. Ce qui laisse penser que le problème est plutôt de son côté.
Si vous ne vous y connaissez pas en réseau, ces adresses étaient jusqu'à présent réservée pour une utilisation locale sur une machine. La plus connue étant 127.0.0.1, mais c'est possible d'en utiliser d'autres.
Si cette proposition est adoptée, les adresses à partir de 127.1.0.0 jusqu'a 127.1.255.255 deviendront des adresses tout à fait normales, routables sur internet.
Il y avait déjà eu des problèmes lors d'opérations similaires avec les adresses 1.x.x.x et 128.x.x.x (liens donnés en références dans le draft), qui étaient simplement réservées (sans utilisation définie) avant d'être finalement attribuées. Leur mise en service a nécessité de contacter des opérateurs télécoms ayant une configuration incorrecte, de mettre à jour des routeurs, ou encore de déployer un firmware mis à jour sur des modems ADSL qui utilisaient ces adresses en interne. Elles recevaient aussi du traffic de client HTTP mal programmés, et plein d'autres choses non identifiées.
Cela consiste principalement en fichiers pour l'impression 3D du boîtier. La borne fonctionne sous Android avec une Tinker Board ASUS. Pas de détails sur l'écran et la webcam utilisés, dans quelle mesure d'autres écrans seront-ils compatibles sans devoir modifier l'impression 3D?
La documentation explique aussi que l'application ne peut pas être mise à jour via le play store car la borne n'est pas associée à un compte Google. Elle n'est pas disponible sur F-Droid?
Guarín-Zapata was taught computer basics in high school — how to save, how to use file folders, how to navigate the terminal — which is knowledge many of his current students are coming in without.
Oui ben voilà: les gens qui ont eu une formation en informatique pendant leurs études ont appris ce que c'est qu'un dossier et comment ça s'utilise. Et puis à un moment quelqu'un s'est dit que ces cours ne servaient plus à rien et que les nouveaux étudiants allaient connaître ça instinctivement. Et c'était une erreur. Google n'a rien à voir là dedans, non?
Personnellement j'ai eu quelques cours d'informatique au collège (fichiers, dossiers, traitement de texte, etc). Sans quoi je n'aurai probablement pas vraiment compris tout seul comment ça marchait (bien que ayant déjà utilisé des ordinateurs avant ça). Et plus tard quand je suis arrivé en IUT informatique, une séance de travaux pratiques là dessus pour vérifier que si tout le monde était au point ou si des cours sur le sujet étaient nécessaires.
Il y a plusieurs choses qui devraient normalement être listées pour chaque bouton:
Un descripteur physique qui indique quelle moitié du corps (gauche, droite, les deux à la fois, ou n'importe laquelle) et quelle partie (il y a une énumération comprenant tous les doigts, orteils, yeux, oreilles, genoux, etc) doit être utilisée pour activer le bouton, ainsi qu'un "effort" (0 pour le bouton placé juste en dessous du doigt, puis ça augmente pour les boutons moins faciles à atteindre)
Un "usage" qui indique à quoi sert le bouton. Il y a des usages spécifiques pour "select" et "start" et une distinction entre "bouton" (activé avec le pouce) et "gachette" (activée avc l'index). Mais il y a aussi une longue liste d'usages plus spécifiques: différents types de clubs de golf, les contrôles pour piloter un char d'assaut, et plein d'autres
Enfin, si un bouton est identifiable par un symbole (A, B, X, Y ou autre, on a droit à tout Unicode) sur le contrôleur, il devrait y avoir un descripteur contenant la chaîne de caractères correspondante.
Malheureusement, la plupart des gamepads font plutôt quelque chose du genre "voici 15 boutons dans un ordre aléatoire" sans donner plus de détails.
La liste des "usages" possibles: https://usb.org/sites/default/files/hut1_22.pdf (mises à jour régulièrement, on peut voir sur le site usb.org la liste des nouveaux usages en cours de discussion, c'est tout aussi divertissant que la liste des emojis dans Unicode)
Le seul truc que je n'ai pas trouvé, c'est comment décrire la couleur des boutons. Ce qui est dommage parce que mon gamepad Gravis a juste des couleurs pour différencier les boutons, et pas de texte ou de symboles.
Je vais probablement réutiliser ces informations dans Haiku également. Par contre je trouve la liste de boutons disponibles dans SDL2 un peu limitée: http://wiki.libsdl.org/SDL_GameControllerButton (pas de bouton SELECT par exemple?)
C'est difficile de faire ça bien parce que la plupart des contrôleurs ne fournissent pas d'infos sur la position physique des boutons (alors que c'est possible dans l'USB HID). Donc il faut renseigner à la main ce genre de fichier pour avoir les infos nécessaires.
Dans les 3 premiers cas, on retrouve à peu près toujours les mêmes en tête de classement. La question c'est plutôt pourquoi Javascript est à ce point sous-évalué par TIOBE?
[^] # Re: mine is better
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Nothing better than C. Évalué à 5.
C non plus ne remplit plus ces critères pour les ordinateurs modernes: https://queue.acm.org/detail.cfm?id=3212479
Il est construit sur un modèle qui n'existe plus: un seul fil d'exécution, pas de mémoire cache, des instructions qui s'exécutent dans l'ordre ou elles sont présentes dans le programme, un ensemble de registres fixes. Aujourd'hui, un ordinateur ne fonctionne plus comme ça. Il y a plusieurs CPUs qui chacun peuvent exécuter plusieurs threads en parallèle, plusieurs niveaux de mémoire cache et de mémoire virtuelle, les instructions sont exécutées dans le désordre et même parfois exécutées avant d'être finalement annulées, et les registres visibles en assembleur n'existent pas vraiment, le processeur assigne ses registres internes dynamiquement en fonction des dépendances qu'il détecte entre les instructions.
Donc, non, le C n'est pas vraiment proche du comportement du matériel actuel. Il est proche du fonctionnement d'un ordinateur des années 70-80. Ça permet d'avoir un modèle simple à comprendre (mais approximatif) de ce qu'il se passe. Mais on pourrait prendre un autre modèle moins proche du PDP-11 et ça fonctionnerait bien aussi. Par exemple quand on programme en Smalltalk, on réfléchit en terme d'objets qui s'envoient des messages, et on peut très bien parler de performances dans ce contexte (combien d'objets sont créés/supprimés, combien de messages sont envoyés, etc). Ou par exemple si on fait du Haskell, on réfléchit en terme de fonctions, et les optimisations se font à un autre niveau (qu'est-ce qui peut être précalculé à la compilation?).
La difficulté de C++ (je prend cet exemple parce que je le connaît bien), c'est surtout qu'il y a plusieurs façons de penser qui sont mélangées dans un seul langage. À la fois c'est intéressant, parce que ça permet d'écrire du code à différent niveaux d'abstraction sans trop s'embêter. À la fois, on a vite fait de tomber dans un piège parce qu'on saute sans cesse d'une façon de penser à une autre (de la programmation objet, impérative, procédurale, ou même fonctionnelle).
# La même en ASCII
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Backdoor invisible à la revue de code avec les caractères spéciaux d'unicode. Évalué à 4.
Il existait déjà en 2013 une attaque utilisant… le caractère espace disponible en ASCII: https://www.tablix.org/~avian/blog/archives/2013/08/beware_of_long_lines_in_git/
C'est moins tordu et muins impressionnant, mais tout aussi efficace. Et une bonne raison pour interdire le caractère espace dans le code source, comme c'est proposé pour les autres caractères problématiques, afin d'éviter tout risque de confusion.
[^] # Re: Pour les jeux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 3.
La NES et la SuperNES aussi, et la MegaDrive chez Sega. Je pense que la Nintendo 64 aussi mais je me trompe peut-être.
Pour la Game Boy et l'Atari Lynx il y a un BIOS de quelques centaines d'octets et qui ne peut pas être appelé par les jeux (il est là juste pour vérifier que la cartouche insérée est valide, et démarrer l'exécution du code).
Pour les consoles sans cartouches c'est effectivement plus compliqué.
Il y a l'approche du CDi qui est de fournir une API standardisée et d'interdire aux jeux d'accéder directement au matériel. Et d'avoir plusieurs implémentations incompatibles du matériel pour s'assurer que c'est bien le cas.
Mais même une console qui aurait un noyau Linux et laisserait chaque jeu démarrer son propre userspace, ça marcherait peut être pas si mal que ça, et ça ressemblerait finalement assez aux Snap et Flatpak, en moins compliqué. Bon, c'est déjà un peu passé de mode de distribuer des jeux sur supports physiques, cela dit…
[^] # Re: Pour les jeux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 4.
On pourrait distribuer chaque jeu sur un support de stockage bootable contentant tout le code nécessaire, permettant à l'éditeur du jeu de choisir exactement ce qu'il inclut et de ne pas avoir de conflit entre les jeux.
Et on appellerait ça une console de jeux? ça serait simple et facile à utiliser.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 2.
On a pas le luxe chez Haiku d'être assez nombreux pour clairement séparer les deux. En théorie c'est le cas, les paquets pour les logiciels tiers sont gérés par Haikuports.
En pratique, les gens qui essaient de porter des logiciels trouvent des bugs dans le système et souvent finissent par les corriger eux-même. Et les gens qui développent l'OS veulent utiliser des logiciels ou bibliothèques qui ne sont pas encore packagées (ou pas dans la bonne version) et doivent le faire eux-même. Il y a donc une assez large intersection entre les deux équipes, et une seule association (Haiku inc) qui paie les serveurs et autres dépenses pour les deux projets.
Pour les applications natives, il n'y a pas vraiment besoin de passer par un "maintainer". Les développeurs d'applications sont aussi des utilisateurs de l'OS (ou même des développeurs de l'OS) et connaissent assez bien le système. Ce n'est pas très compliqué de distribuer un logiciel, soit sous forme d'un paquet hpkg, soit sous forme d'un simple fichier zip à décompresser.
Pour les applications portées, ça dépend, on a certains développeurs qui sont motivés pour faire les choses proprement, d'autres qui n'ont pas du tout envie de gérer des cas particuliers, et un peu de tout entre les deux.
Mais surtout, ce qui est important: on compte sur les utilisateurs pour se plaindre quand un logiciel est plus gros que l'installation de base de Haiku (quelques centaines de Mo).
[^] # Re: Scandale ? Je ne crois pas
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Unknown Pleasures : un pulsar iconique. Évalué à 7.
Ça me rapelle qu'il y a un épisode sur Jocelyn Bell dans la série d'interviews Almost Famous du New York Times (vidéos en anglais), si jamais vous voulez en savoir un peu plus.
[^] # Re: Mouais
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 6.
Snap + AppImage + Flatpak, c'est pas vraiment quasi-unique. Surtout que ça ne remplace pas les autres solutions, ça ne fait qu'en rajouter encore plus.
[^] # Re: Faites des paquets Debian pour vos applications
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 3.
Chez Haiku (puisqu'on parle de nous, hein…), on aimerait bien que les développeurs d'applications distribuent eux-même leur travail et qu'on aie pas besoin de tout packager nous-mêmes.
Notre approche est la suivante:
- Une "distribution" standard du système, qui est la seule à avoir le droit d'utiliser la marque Haiku sans autres précision (d'autres distributions ont existé, par exemple Senryu, TiltOS, ou Discover Haiku)
- Une ABI et API stable. Actuellement c'est celle de BeOS, qui n'a pas bougé depuis 20 ans. Mais on est conscients que ce n'est pas réaliste car ça imposerait de tout compiler avec gcc2 et de n'utiliser aucune des nouvelles APIs ajoutées depuis,
- L'introduction de nouvelles APIs se fait d'abord dans des bibliothèques statiques etdans un namespace dédié. Les applications utilisant ces APIs embarquent donc une copie du code concerné, etne sont pas affectées par les mises à jour
- Pour les APIs stables utilisables en bibliothèques partagées, diverses astuces pour se garder des moyens de faire évoluer les choses: réservation d'espace dans la vtable et les champ de tous les objets C++, surcharge systématique de certaines méthodes pour pouvoir en modifier le comportement plus tard, versionning de symboles, ajout de bouchons permettant aux applications utilisant une fonction qui n'existe plus de continuer à fonctionner, etc.
- Fourniture d'une API qui couvre pas mal de besoins (graphique, réseau, multimédia, …) évitant ainsi la prolifération de bibliothèque faisant toutes un peu la même chose
Ça marche plutôt bien pour les applications natives. C'est plus compliqué pour les applications portées depuis Linux ou il y a souvent plein de dépendances vers diverses bibliothèques et des problèmes de compatibilité qui surviennent très régulièrement. Pas trop d'accord avec l'auteur de l'article pour dire que c'est définitivement réglé, donc…
[^] # Re: Comme ça me rappel des galère
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal J'essaie de commander des pièces détachées pour du petit électroménager. Évalué à 6.
En vrai, Kenwood s'en sort pas si mal, ce modèle de robot est vendu depuis 2007, et il reste encore du stock pour certaines pièces.
Et peut-être que les générations suivantes ne sont pas compatibles pour une bonne raison, par exemple une pièce qui vieillit mal et qui a été redessinée pour corriger le problème.
Sur le blender, à part le problème de fissures, il m'est arrivé une fois de mal verrouiller la pièce qui contient la lame (démontable pour pouvoir la nettoyer), résultat elle s'est détachée et tout le contenu du blender a fini sur mon plan de travail. C'est le genre de problème qu'il est bien de corriger.
Même chose sur ta machine à laver: si c'est tout le temps la même pièce qui casse, c'est mieux de ne pas garder cette pièce sur le modèle suivant.
Je suis surtout embêté parce qu'il y a l'air d'avoir des pièces qui sont peut-être compatibles (en tout cas sur les photos ça ressemble beaucoup), mais qui ne sont pas annoncées comme compatible. J'aurai pu apporter mon blender chez un distributeur de pièces pas trop loin de chez moi, mais il faudrait qu'il aie la pièce de rechange en stock pour vérifier si elle est éventuellement compatible. Et c'est là que en effet, un peu de standardisation ne ferait pas de mal.
[^] # Re: Une belle impression 3D ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal J'essaie de commander des pièces détachées pour du petit électroménager. Évalué à 4. Dernière modification le 21 novembre 2021 à 17:36.
Ça va me coûter plus cher en heures de travail pour faire un modèle 3D convenable qui s'adapte au support avec l'hélice du Blender. Et je ne suis pas convaincu que le résultat sera suffisament solide.
Et ça prend un peu de place, un blender d'une contenance de 1.5L, il faut une imprimante 3D assez grande.
[^] # Re: Les pièces détachées Kenwood...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal J'essaie de commander des pièces détachées pour du petit électroménager. Évalué à 4.
Il ne s'agit pas d'un site officiel, c'est un revendeur de pièces comme il y en a plein d'autres, mais qui entretient la confusion avec un nom de domaine et un design de site web un peu trompeur. On peut le voir facilement en allant voir la page "about us".
J'ai trouvé un site officiel pour les pièces détachées (sous la marque DeLonghi qui a apparament racheté la marque Kenwood), mais seulement pour l'Australie et la Nouvelle Zélande
[^] # Re: Je m'insurge !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien HS du vendredi : à défaut de tartiflette, de la raclette. Évalué à 3.
Alors comment dire… la fin de la civilisation c'est plutôt par ici:
https://jesuisuncuisinier.fr/fr/pizza-aux-ravioles/
[^] # Re: Comparaison
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Rapport CRIIRAD (pdf) - Contamination chronique et persistante du milieu naturel en aval de Golfech . Évalué à 5. Dernière modification le 19 novembre 2021 à 22:09.
J'ai mal lu le graphique.
Toutes mes excuses aux bananes dont j'ai exagéré la radioactivité.
# Comparaison
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Rapport CRIIRAD (pdf) - Contamination chronique et persistante du milieu naturel en aval de Golfech . Évalué à 10.
Pour rappel, une banane est radioactive aussi: environ 15 Becquerel par banane (à cause du potassium) source.
Boire un litre d'eau de la Garonne est donc à peu près aussi dangereux que de manger une banane.
C'est cohérent avec le graphique proposé par XKCD pour comparer l'exposition aux radiations dans différents cas.
Quelques rappels utiles:
- Utiliser un écran cathodique pendant 1 an est équivalent à manger 10 bananes,
- Habiter à proximité d'une centrale à charbon vous expose à 3 fois plus de radiations qu'une centrale nucléaire,
- Habiter dans un bâtiment en briques, béton ou pierre de taille pendant un an: équivalent à manger 70 bananes,
- Être un humain normalement constitué sans carence en potassium pendant un an: équivalent à manger 390 bananes.
Je n'ai pas fait le calcul du poids d'une banane déshydratée pour pouvoir comparer avec le kilogramme de carbone.
# Vrai lien
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Rapport CRIIRAD (pdf) - Contamination chronique et persistante du milieu naturel en aval de Golfech . Évalué à 4.
Le vrai lien sans contamination par les trackers de Twitter et Facebook: http://www.criirad.org/installations-nucl/golfech/Rapport_CRIIRAD_N_20-35_Golfech_VF.pdf
[^] # Re: Qui est-ce ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Statement on Daniel Pocock. Évalué à 4.
Il est aussi derrière fsfellowship (soi-disant un fork de la FSFE).
Il a spammé les mentors du Google Summer of Code en récupérant leurs emails sur la mailing list officielle (dont il a été banni) pour les inscrire de force sur une mailing list parallèle.
En tout cas il a l'air d'avoir des problèmes avec vraiment beaucoup de monde. Ce qui laisse penser que le problème est plutôt de son côté.
# Qu'est-ce que ça va casser?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les adresses IP en 127.x.x.x bientôt routables sur Internet. Évalué à 8.
Si vous ne vous y connaissez pas en réseau, ces adresses étaient jusqu'à présent réservée pour une utilisation locale sur une machine. La plus connue étant 127.0.0.1, mais c'est possible d'en utiliser d'autres.
Par exemple la synchronisation d'un serveur NTP avec un récepteur GPS situé sur la même machine utilise des adresses en 127.127.x.x: https://gist.github.com/edro15/c3fbaaabfe31ecb799363ffab587f336
Si cette proposition est adoptée, les adresses à partir de 127.1.0.0 jusqu'a 127.1.255.255 deviendront des adresses tout à fait normales, routables sur internet.
Il y avait déjà eu des problèmes lors d'opérations similaires avec les adresses 1.x.x.x et 128.x.x.x (liens donnés en références dans le draft), qui étaient simplement réservées (sans utilisation définie) avant d'être finalement attribuées. Leur mise en service a nécessité de contacter des opérateurs télécoms ayant une configuration incorrecte, de mettre à jour des routeurs, ou encore de déployer un firmware mis à jour sur des modems ADSL qui utilisaient ces adresses en interne. Elles recevaient aussi du traffic de client HTTP mal programmés, et plein d'autres choses non identifiées.
# Étiquettes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les adresses IP en 127.x.x.x bientôt routables sur Internet. Évalué à 5.
Message pour la modération:
Étiquettes repérées lors de la rédaction de ce lien, qui peuvent probablement être fusionnées/masquées:
# Analyse
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La Borne passe sanitaire (BPS), le premier produit en open hardware de la Gendarmerie !. Évalué à 4.
Les fichiers sont disponibles sur github: https://github.com/GendarmerieNationale/Borne-Passe-Sanitaire
Cela consiste principalement en fichiers pour l'impression 3D du boîtier. La borne fonctionne sous Android avec une Tinker Board ASUS. Pas de détails sur l'écran et la webcam utilisés, dans quelle mesure d'autres écrans seront-ils compatibles sans devoir modifier l'impression 3D?
La documentation explique aussi que l'application ne peut pas être mise à jour via le play store car la borne n'est pas associée à un compte Google. Elle n'est pas disponible sur F-Droid?
# ça s'apprend
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La génération qui a grandi avec Google ne sait pas utiliser un système de fichiers. Évalué à 10.
Oui ben voilà: les gens qui ont eu une formation en informatique pendant leurs études ont appris ce que c'est qu'un dossier et comment ça s'utilise. Et puis à un moment quelqu'un s'est dit que ces cours ne servaient plus à rien et que les nouveaux étudiants allaient connaître ça instinctivement. Et c'était une erreur. Google n'a rien à voir là dedans, non?
Personnellement j'ai eu quelques cours d'informatique au collège (fichiers, dossiers, traitement de texte, etc). Sans quoi je n'aurai probablement pas vraiment compris tout seul comment ça marchait (bien que ayant déjà utilisé des ordinateurs avant ça). Et plus tard quand je suis arrivé en IUT informatique, une séance de travaux pratiques là dessus pour vérifier que si tout le monde était au point ou si des cours sur le sujet étaient nécessaires.
[^] # Re: Haiku
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 3.
Il y a plusieurs choses qui devraient normalement être listées pour chaque bouton:
Malheureusement, la plupart des gamepads font plutôt quelque chose du genre "voici 15 boutons dans un ordre aléatoire" sans donner plus de détails.
La liste des "usages" possibles: https://usb.org/sites/default/files/hut1_22.pdf (mises à jour régulièrement, on peut voir sur le site usb.org la liste des nouveaux usages en cours de discussion, c'est tout aussi divertissant que la liste des emojis dans Unicode)
La spécification USB HID et en particulier la section 6.2.3 pour les descripteurs physiques: https://usb.org/sites/default/files/hid1_11.pdf
Le seul truc que je n'ai pas trouvé, c'est comment décrire la couleur des boutons. Ce qui est dommage parce que mon gamepad Gravis a juste des couleurs pour différencier les boutons, et pas de texte ou de symboles.
[^] # Re: Haiku
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 4.
Pour le binding, SDL2 permet déjà de le faire mais il faut lui fournir ce fichier: https://github.com/gabomdq/SDL_GameControllerDB
Je vais probablement réutiliser ces informations dans Haiku également. Par contre je trouve la liste de boutons disponibles dans SDL2 un peu limitée: http://wiki.libsdl.org/SDL_GameControllerButton (pas de bouton SELECT par exemple?)
C'est difficile de faire ça bien parce que la plupart des contrôleurs ne fournissent pas d'infos sur la position physique des boutons (alors que c'est possible dans l'USB HID). Donc il faut renseigner à la main ce genre de fichier pour avoir les infos nécessaires.
[^] # Re: Lien cassé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 6.
En effet, erreur dans le lien, le projet se trouve ici: https://github.com/pulkomandy/avrstuff/tree/master/grip2hid
Je fais mes schémas et PCBs avec Kicad et la production est faite par Seeed Studio
[^] # Re: Cohérence ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Intégration continue - Travis, la stratégie commerciale défaillante ?. Évalué à 4.
On peut se logger sur gitlab.com avec un compte github (ainsi que d'autres fournisseurs openid). Donc c'est pas vraiment un problème.
[^] # Re: Bravo !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien [TIOBE] Python programming language number 1!. Évalué à 4.
Il y a d'autres approches, par exemple regarder le nombre de dépôts github ou le nombre de pull requests, ou encore le nombre de questions sur StackOverflow. On peut aussi essayer de regarder uniquement les projets qui changent de langage et écrivent un blog à ce sujet.
Dans les 3 premiers cas, on retrouve à peu près toujours les mêmes en tête de classement. La question c'est plutôt pourquoi Javascript est à ce point sous-évalué par TIOBE?