Sur le site de Fujitsu dans la catégorie "support" on trouve un guide de démontage complet de la machine, en français, et avec des photos. Cela explique probablement qu'il n'y a pas grand chose sur des sites comme ifixit: le travail est déjà fait!
J'ai également vu un forum de support auquel je viens de m'inscrire. Il est disponible en plusieurs langues et Fujitsu a l'air de répondre aux questions posées.
Je demanderai sur ce forum pour les questions qu'il me reste: pourquoi le "touchstick" n'est disponible sur aucun modèle de série, pourquoi je ne trouve pas de site vendant des pièces détachées (je suppose que les modèles auxquels je m'intéresse sont trop récents et encore sous garantie constructeur?), et est-ce qu'il est vraiment possible de commander une machine avec une configuration "sur mesure", le configurateur de Fujitsu n'ayant a priori pas de bouton pour commander quelque chose (à défaut je me contenterai d'une configuration "catalogue" mais je préfèrerais vraiment avoir un touchstick…)
Le plus dangereux (toute proportions gardées) c'est l'écran cathodique comme celui de l'Amstrad CPC, qui émet un petit peu de rayons X. Et il faut vraiment être collé à 2 ou 3 centimètres de l'écran pour que ce soit détectable (l'énergie décroit avec le carré de la distance)
Pour le reste, ne pas se coller le nez à l'écran (pour habituer les yeux à focaliser à différentes distances), ne pas passer la journée devant (c'est autant de temps passé à peu près sans activité physique).
Le rayonnement de l'écran c'est juste de la lumière visible, on en reçoit beaucoup plus dans les yeux en étant dehors par une journée ensoleillée (même en hiver). C'est plutôt dans cette situation là qu'il faut penser aux protections (lunettes de soleil), non?
Éventuellement baisser la luminosité de l'écran qui est probablement à son niveau maximum, parce que c'est plus impressionnant lors des démonstrations en magasin.
Personellement, si une entreprise me contacte en disant qu'ils veulent me payer même seulement quelques centaines d'euros par mois pour mon travail sur des projets opensource, je veux bien faire l'effort de monter une entreprise.
De plus, c'est probablement mutualisable (on peut créer une grosse entreprise et l'utiliser pour collecter les paiements pour de nombreux développeurs.
Mon problème sera plutôt que dans mon contrat de travail actuel, j'ai une clause d'exclusivité avec mon employeur, a priori ça m'empêche de faire ce genre de choses.
Je pourrais par contre en discuter avec mon employeur qui serait possiblement disposé à servir d'intemédiaire: me rémunérer pour travailler sur du logiciel libre, et refacturer ça à une ou plusieurs autres entreprises.
Enfin il y a le problème que la plupart des projets auxquels je contribue beaucoup ne sont pas les plus critiques pour les entreprises, mais c'est un autre sujet (et un peu un choix de ma part dans la situation actuelle)
Ça dépend des utilisations en fait. Cet article concerne principalement les "live cd" si je comprend bien. Et franchement, booter un CD sur une machine trop vieille pour booter autre chose, c'est moyennement intéressant, ça va probablement manger une grande partie de la RAM.
Pour ces vieilles machines on peut par exemple booter via un plop boot manager chargé depuis un cd, et de là, démarrer sur un système usb.
Pour les cd/dvd d'installation, c'est un autre sujet, et c'est pas idiot d'avoir un média en lecture seule dans ce cas. Cela dit, ça fait plusieurs années que j'utilise netboot.xyz pour ça (éventuellement démarré depuis un cd, mais souvent depuis une vieille clé usb de 256Mo que je réserve à cet usage) et que je peux installer à peu près n'importe quelle distribution sans avoir à créer un média spécifique à chaque fois.
Mais effectivement ça serait un point de départ possible pour en définir un.
Personellement je préfère le QWERTY espagnol (accents en touches mortes, et [{}] en atl gr) au QWERTY international ( {[]} en accès direct, accents en alt gr).
Comme je le disais dans mon message précédent, le clavier Espagnol fonctionne pour le castillan, mais aussi pour le catalan, le basque et le galicien. Ce qui fait déjà 4 langues. Il s'adapte sans problème au français, et probablement aussi au portugais et au breton.
Bon, il faut bien sûr faire des choix différents: utilisation de touches mortes pour tous les accents (aigu, grave, trema et circonflexe) ce qui permet d'utiliser seulement 4 touches pour avoir toutes les possibilités. Alors que par exemple sur le clavir azerty on a des touches pour é, à, è, ù, ça fait déjà 4 touches, on a pas encore les majuscules, et on est loin d'avoir toutes les possibilités d'accents. Et sur le qwerty-fr c'est… la majorité des touches du clavier qui sont utilisées pour taper divers accents.
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.
# Je me répond tout seul
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Cherche des informations sur les portables Fujitsu Lifebook. Évalué à 5.
Je continue à creuser le sujet.
Sur le site de Fujitsu dans la catégorie "support" on trouve un guide de démontage complet de la machine, en français, et avec des photos. Cela explique probablement qu'il n'y a pas grand chose sur des sites comme ifixit: le travail est déjà fait!
J'ai également vu un forum de support auquel je viens de m'inscrire. Il est disponible en plusieurs langues et Fujitsu a l'air de répondre aux questions posées.
Je demanderai sur ce forum pour les questions qu'il me reste: pourquoi le "touchstick" n'est disponible sur aucun modèle de série, pourquoi je ne trouve pas de site vendant des pièces détachées (je suppose que les modèles auxquels je m'intéresse sont trop récents et encore sous garantie constructeur?), et est-ce qu'il est vraiment possible de commander une machine avec une configuration "sur mesure", le configurateur de Fujitsu n'ayant a priori pas de bouton pour commander quelque chose (à défaut je me contenterai d'une configuration "catalogue" mais je préfèrerais vraiment avoir un touchstick…)
[^] # Re: La fonction du stage c'est l'apprentissage, rien de plus.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Sélection stagiaire développement. Évalué à 5.
Il semblerait que ce n'est plus le cas pour les logiciels, depuis… la semaine dernière!
https://www.village-justice.com/articles/propriete-intellectuelle-apercu-ordonnance-decembre-2021,41084.html
Cet article donne les liens vers les chapitres du code de la propriété intellectuelle qui traitent de ce sujet.
[^] # Re: C'est quoi "nocif" ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Écran pour enfants 4 ans. Évalué à 4.
Le plus dangereux (toute proportions gardées) c'est l'écran cathodique comme celui de l'Amstrad CPC, qui émet un petit peu de rayons X. Et il faut vraiment être collé à 2 ou 3 centimètres de l'écran pour que ce soit détectable (l'énergie décroit avec le carré de la distance)
Pour le reste, ne pas se coller le nez à l'écran (pour habituer les yeux à focaliser à différentes distances), ne pas passer la journée devant (c'est autant de temps passé à peu près sans activité physique).
Le rayonnement de l'écran c'est juste de la lumière visible, on en reçoit beaucoup plus dans les yeux en étant dehors par une journée ensoleillée (même en hiver). C'est plutôt dans cette situation là qu'il faut penser aux protections (lunettes de soleil), non?
Éventuellement baisser la luminosité de l'écran qui est probablement à son niveau maximum, parce que c'est plus impressionnant lors des démonstrations en magasin.
[^] # Re: Association
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Appel à une professionnalisation des mainteneurs. Évalué à 6.
Personellement, si une entreprise me contacte en disant qu'ils veulent me payer même seulement quelques centaines d'euros par mois pour mon travail sur des projets opensource, je veux bien faire l'effort de monter une entreprise.
De plus, c'est probablement mutualisable (on peut créer une grosse entreprise et l'utiliser pour collecter les paiements pour de nombreux développeurs.
Mon problème sera plutôt que dans mon contrat de travail actuel, j'ai une clause d'exclusivité avec mon employeur, a priori ça m'empêche de faire ce genre de choses.
Je pourrais par contre en discuter avec mon employeur qui serait possiblement disposé à servir d'intemédiaire: me rémunérer pour travailler sur du logiciel libre, et refacturer ça à une ou plusieurs autres entreprises.
Enfin il y a le problème que la plupart des projets auxquels je contribue beaucoup ne sont pas les plus critiques pour les entreprises, mais c'est un autre sujet (et un peu un choix de ma part dans la situation actuelle)
[^] # Re: Entièrement d'accord
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien L'heure de la retraite pour les images ISO des distributions ?. Évalué à 5.
Ça dépend des utilisations en fait. Cet article concerne principalement les "live cd" si je comprend bien. Et franchement, booter un CD sur une machine trop vieille pour booter autre chose, c'est moyennement intéressant, ça va probablement manger une grande partie de la RAM.
Pour ces vieilles machines on peut par exemple booter via un plop boot manager chargé depuis un cd, et de là, démarrer sur un système usb.
Pour les cd/dvd d'installation, c'est un autre sujet, et c'est pas idiot d'avoir un média en lecture seule dans ce cas. Cela dit, ça fait plusieurs années que j'utilise netboot.xyz pour ça (éventuellement démarré depuis un cd, mais souvent depuis une vieille clé usb de 256Mo que je réserve à cet usage) et que je peux installer à peu près n'importe quelle distribution sans avoir à créer un média spécifique à chaque fois.
[^] # 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é à 2.
ça n'en fait pas un standard pour autant :)
Mais effectivement ça serait un point de départ possible pour en définir un.
Personellement je préfère le QWERTY espagnol (accents en touches mortes, et [{}] en atl gr) au QWERTY international ( {[]} en accès direct, accents en alt gr).
[^] # 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é à 2.
Est-ce qu'on a au moins essayé?
Comme je le disais dans mon message précédent, le clavier Espagnol fonctionne pour le castillan, mais aussi pour le catalan, le basque et le galicien. Ce qui fait déjà 4 langues. Il s'adapte sans problème au français, et probablement aussi au portugais et au breton.
Bon, il faut bien sûr faire des choix différents: utilisation de touches mortes pour tous les accents (aigu, grave, trema et circonflexe) ce qui permet d'utiliser seulement 4 touches pour avoir toutes les possibilités. Alors que par exemple sur le clavir azerty on a des touches pour é, à, è, ù, ça fait déjà 4 touches, on a pas encore les majuscules, et on est loin d'avoir toutes les possibilités d'accents. Et sur le qwerty-fr c'est… la majorité des touches du clavier qui sont utilisées pour taper divers accents.
[^] # 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.