Il y a aussi le qwerty lafayette, ou encore le qwerty espagnol, qui est conçu en prenant en comptes les différentes langues utilisées en espagne (catalan, basque, …) et qui permet au final d'avoir tous les caractères nécessaires pour le Français.
C'est possible aussi, ça se fait par exemple pour python avec PyDev dans Eclipse. Il le fait pas en temps réel, mais lors de la sauvegarde des fichiers.
Peu importe les règles, l'important c'est d'avoir un outil de formatage automatique (ici il est configuré dans gitlab et dans nos scripts de build ("make format") et on ne peut pas merger un changement s'il n'est pas formaté).
On gagne énormément de temps sur les relectures de code (on peut se concentrer sur le fond puisqu'un robot a déjà pris en charge la forme) et aussi sur l'écriture (puisqu'on peut tout faire n'importe comment et ça sera reformaté à la fin).
La personne qui trie le courrier qui vient d'être posté doit lire seulement la dernière ligne: soit c'est un code postal et iel envoie le truc dans le centre de tri correspondant. Soit c'est un pays, et iel transfère au centre de tri international du pays en question (qui doit lui utiliser l'avant-dernière ligne, ce qui est un peu plus compliqué, mais ça reste tout à fait raisonnable).
Ensuite, une fois arrivé dans la bonne ville, on a besoin en priorité de la première ligne pour savoir dans quelle rue et numéro apporter la lettre.
Et il n'y a que le facteur à la fin de la chaîne qui a besoin des autres informations, a priori pour seulement un petit nombre de lettres à trier à chaque adresse.
Si le "Rue Machin, 1337" était rangé au milieu de l'adresse comme tu le proposes, le tri et la distribution du courrier seraient plus complexes.
C'est donc une structure de données plutôt bien optimisée, rendant facile d'accès, non pas les informations les plus importantes ou les plus générales, mais celles auxquelles il y a besoin d'un accès rapide pour un grand nombre d'éléments.
Les propriétés des matériaux semblent aussi un frein majeur, refaire un tuyau d'aspirateur, par exemple semble non trivial … Ce ne sont que quelques exemple pour illustrer que le pb est complexe et ne peut probablement pas se faire si simplement.
Dans ce cas précis, j'imagine qu'on peut acheter un ou deux mètres de tuyau flexible, puis imprimer une pièce permettant de l'adapter sur un modèle d'aspirateur donné?
Il y a aussi d'autres possibilités, par exemple utiliser l'impression 3D pour faire un moule qui va servir à fabriquer une pièce dans un autre matériau. On peut par exemple imprimer une pièce en 3D, la recouvrir de céramique, faire fondre et évacuer le plastique, et enfin couler du métal dans le moule obtenu. Mais on est déjà dans quelque chose de plus ambitieux que juste une impression 3D. Et c'est certainement pas du tout rentable économiquement dans la plupart des cas.
Après c'est un site communautaire, il faut surtout trouver des gens pour remplir les différentes catégories, ou même traduire les pages anglaises en français.
Mais c'est pas mal de travail de réaliser ce genre de guide. Il faut prendre des photos à chaque étape (et vérifier qu'elles ne sont pas floues, avec des reflets, etc). Il faut à peu près savoir ce qu'on fait pour mettre les étapes dans l'ordre (et donc documenter un premier démontage/remontage c'est compliqué, c'est plus simple si on l'a déjà fait une fois de documenter quand on le refait).
Je crois que maintenant on trouve plutôt des tutos vidéo, ce qui est peut-être plus facile à réaliser: on peut installer une caméra au-dessus du plan de travail, la laisser filmer, et se concentrer sur le démontage/remontage. Et ensuite, monter la vidéo en enlevant les parties ou on bataille pendant 30 minutes à essayer d'enlever un cache en plastique sans le casser :)
Ça suppose qu'il existe une norme qui va bien. Sinon, les options sont:
Prendre un truc surdimensionné (genre une norme aéronautique pour une moto) et tes joints vont coûter 10 fois le prix de ce qu'il y a besoin
Publier des spécifications super détaillées sur toutes les contraintes (température, pression, …) et tu ne pourra jamais savoir si le joint que tu as choisi est compatible.
Et encore, ça suppose que le fabricant de la moto sache quelles sont les contraintes qui doivent être respectées. C'est possible que ça soit plutôt "on a pris tel modèle de tel fournisseur, on l'a testé, ça fonctionne".
Je suis d'accord. Les appareils seraient vendus plus chers, mais seraient aussi plus robustes. Écologiquement c'est indéniablement intéressant. Et même économiquement, en sachant que de nombreuses matières premières devraient finir par se raréfier, je pense que c'est intéressant.
C'est pas certain…
Ça coûte cher de relancer la production des pièces pour un ancien modèle après quelques années. Donc les fabricants, s'ils sont obligés d'avoir des pièces pour 10 ans, vont plutôt fabriquer énormément de pièces supplémentaires lors de la production initiale (avec les même défauts que les pièces d'origine, donc). Ils vont ensuite stocker ces pièces, ce qui prend de la place et coûte donc de l'argent (entretien d'un entrepôt, chauffage de cet entrepôt pour éviter les dégâts à cause du gel ou de l'humidité, etc).
À la fin de la période de garantie il restera des pièces invendues, qui seront probablement détruites (gaspillage de matière première et d'énergie).
Ce n'est donc pas rentable économiquement (sinon ce serait déjà fait), et c'est pas évident que ça soit rentable écologiquement dans ce cas.
Et donc les fabricants vont plutôt prendre la solution la plus simple: remplacer l'objet complet par un nouveau modèle équivalent. Ce qui n'est pas du tout intéressant ni écologiquement (tu aurais pu en racheter un d'occasion au lieu d'un neuf) ni économiquement (le fabricant doit te fournir au moins un deuxième appareil gratuit si le tien tombe en panne).
L'idéal serait plutôt de fabriquer tout le temps le même modèle pour conserver des pièces compatibles. Mais c'est pas sûr que les fabricants aient envie de faire ça (c'est difficile de revendre le même modèle tout le temps).
Cela dit, on arrive à un point ou les nouvelles "fonctionnalités" font fuir les utilisateurs (robot cuisiniers équipé du wifi, télévisions affichant des publicités lors du démarrage) et peut-être que les produits d'occasion n'ayant pas ces inconvénients vont finir par devenir plus chers que les neufs?
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é.
[^] # Re: Alternatives
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien QWERTY-fr (une disposition qwerty avec un accès facile aux symboles français). Évalué à 3.
Il y a aussi le qwerty lafayette, ou encore le qwerty espagnol, qui est conçu en prenant en comptes les différentes langues utilisées en espagne (catalan, basque, …) et qui permet au final d'avoir tous les caractères nécessaires pour le Français.
À quand un standard Européen?
[^] # Re: Python black
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 3.
C'est possible aussi, ça se fait par exemple pour python avec PyDev dans Eclipse. Il le fait pas en temps réel, mais lors de la sauvegarde des fichiers.
# format automatique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Quelles seraient les meilleures règles de formatage de code ?. Évalué à 3.
Peu importe les règles, l'important c'est d'avoir un outil de formatage automatique (ici il est configuré dans gitlab et dans nos scripts de build ("make format") et on ne peut pas merger un changement s'il n'est pas formaté).
On gagne énormément de temps sur les relectures de code (on peut se concentrer sur le fond puisqu'un robot a déjà pris en charge la forme) et aussi sur l'écriture (puisqu'on peut tout faire n'importe comment et ça sera reformaté à la fin).
[^] # Re: dates et adresses
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Des concepteurs qui ont éteint trop tôt leur cerveau. Évalué à 0.
Pour les adresses ça me semble plutôt malin.
Quand tu postes une lettre:
La personne qui trie le courrier qui vient d'être posté doit lire seulement la dernière ligne: soit c'est un code postal et iel envoie le truc dans le centre de tri correspondant. Soit c'est un pays, et iel transfère au centre de tri international du pays en question (qui doit lui utiliser l'avant-dernière ligne, ce qui est un peu plus compliqué, mais ça reste tout à fait raisonnable).
Ensuite, une fois arrivé dans la bonne ville, on a besoin en priorité de la première ligne pour savoir dans quelle rue et numéro apporter la lettre.
Et il n'y a que le facteur à la fin de la chaîne qui a besoin des autres informations, a priori pour seulement un petit nombre de lettres à trier à chaque adresse.
Si le "Rue Machin, 1337" était rangé au milieu de l'adresse comme tu le proposes, le tri et la distribution du courrier seraient plus complexes.
C'est donc une structure de données plutôt bien optimisée, rendant facile d'accès, non pas les informations les plus importantes ou les plus générales, mais celles auxquelles il y a besoin d'un accès rapide pour un grand nombre d'éléments.
[^] # Re: Assez complexe en général
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal À la recherche des pièces détachées. Comment mieux (p)réparer notre futur, en réparant nos appareils. Évalué à 2. Dernière modification le 29 novembre 2021 à 13:41.
Dans ce cas précis, j'imagine qu'on peut acheter un ou deux mètres de tuyau flexible, puis imprimer une pièce permettant de l'adapter sur un modèle d'aspirateur donné?
Il y a aussi d'autres possibilités, par exemple utiliser l'impression 3D pour faire un moule qui va servir à fabriquer une pièce dans un autre matériau. On peut par exemple imprimer une pièce en 3D, la recouvrir de céramique, faire fondre et évacuer le plastique, et enfin couler du métal dans le moule obtenu. Mais on est déjà dans quelque chose de plus ambitieux que juste une impression 3D. Et c'est certainement pas du tout rentable économiquement dans la plupart des cas.
[^] # Re: Ce n'est pas de la pub : ifixit ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal À la recherche des pièces détachées. Comment mieux (p)réparer notre futur, en réparant nos appareils. Évalué à 2.
Il y a une section pour les machines à coudre mais il n'y a qu'ine dizaine de modèles référencés (et uniquement en anglais): https://fr.ifixit.com/Device/Sewing_Machine
Après c'est un site communautaire, il faut surtout trouver des gens pour remplir les différentes catégories, ou même traduire les pages anglaises en français.
Mais c'est pas mal de travail de réaliser ce genre de guide. Il faut prendre des photos à chaque étape (et vérifier qu'elles ne sont pas floues, avec des reflets, etc). Il faut à peu près savoir ce qu'on fait pour mettre les étapes dans l'ordre (et donc documenter un premier démontage/remontage c'est compliqué, c'est plus simple si on l'a déjà fait une fois de documenter quand on le refait).
Je crois que maintenant on trouve plutôt des tutos vidéo, ce qui est peut-être plus facile à réaliser: on peut installer une caméra au-dessus du plan de travail, la laisser filmer, et se concentrer sur le démontage/remontage. Et ensuite, monter la vidéo en enlevant les parties ou on bataille pendant 30 minutes à essayer d'enlever un cache en plastique sans le casser :)
[^] # Re: La logistique est un métier complexe
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal À la recherche des pièces détachées. Comment mieux (p)réparer notre futur, en réparant nos appareils. Évalué à 4.
Ça suppose qu'il existe une norme qui va bien. Sinon, les options sont:
Et encore, ça suppose que le fabricant de la moto sache quelles sont les contraintes qui doivent être respectées. C'est possible que ça soit plutôt "on a pris tel modèle de tel fournisseur, on l'a testé, ça fonctionne".
[^] # Re: S'attaquer à la source du problème
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal À la recherche des pièces détachées. Comment mieux (p)réparer notre futur, en réparant nos appareils. Évalué à 6.
C'est pas certain…
Ça coûte cher de relancer la production des pièces pour un ancien modèle après quelques années. Donc les fabricants, s'ils sont obligés d'avoir des pièces pour 10 ans, vont plutôt fabriquer énormément de pièces supplémentaires lors de la production initiale (avec les même défauts que les pièces d'origine, donc). Ils vont ensuite stocker ces pièces, ce qui prend de la place et coûte donc de l'argent (entretien d'un entrepôt, chauffage de cet entrepôt pour éviter les dégâts à cause du gel ou de l'humidité, etc).
À la fin de la période de garantie il restera des pièces invendues, qui seront probablement détruites (gaspillage de matière première et d'énergie).
Ce n'est donc pas rentable économiquement (sinon ce serait déjà fait), et c'est pas évident que ça soit rentable écologiquement dans ce cas.
Et donc les fabricants vont plutôt prendre la solution la plus simple: remplacer l'objet complet par un nouveau modèle équivalent. Ce qui n'est pas du tout intéressant ni écologiquement (tu aurais pu en racheter un d'occasion au lieu d'un neuf) ni économiquement (le fabricant doit te fournir au moins un deuxième appareil gratuit si le tien tombe en panne).
L'idéal serait plutôt de fabriquer tout le temps le même modèle pour conserver des pièces compatibles. Mais c'est pas sûr que les fabricants aient envie de faire ça (c'est difficile de revendre le même modèle tout le temps).
Cela dit, on arrive à un point ou les nouvelles "fonctionnalités" font fuir les utilisateurs (robot cuisiniers équipé du wifi, télévisions affichant des publicités lors du démarrage) et peut-être que les produits d'occasion n'ayant pas ces inconvénients vont finir par devenir plus chers que les neufs?
[^] # Re: re: Python: Please stop screwing over Linux distros
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Python: Please stop screwing over Linux distros. Évalué à 5.
Il est occupé à écrire un navigateur web en ce moment.
[^] # 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é.