lym a écrit 111 commentaires

Le langage Python, avec son écrasante popularité (premier au classement TIOBE), est vanté pour sa simplicité.

Pardon? D'aucuns et pas des manches trouvent le C++ (pour en rester aux langages objet) bien plus simple que Python qui est tout sauf un langage simple. Sauf à confondre simple et lisible (même pour le néophyte s'il est anglophone, mais de là à lui faire prendre le clavier…), à la limite!

Le C est incomparablement plus simple (niveau grammaire) à apprendre que Python et c'est souvent le cas dans les langages interprétés évolués pour ne pas avoir des performances trop altérées (on complexifie la grammaire pour maximiser ce qui tournera direct dans l'interpréteur/en natif).

Sinon, il y a la possibilité d'en rester (surtout pour ses scripts perso) au python de sa distribution et aux librairies quelle maintient qui s'installent d'un "apt install python-XXX".

Ma Debian 12 offre quand même 831 paquets à ce rayon.

Et en prime, même si cela n'évite pas un tri ajouté, les dépendances qui ont justifié un mainteneur ont des chances d'être maintenues dans le temps.

Plus de venv, ni même de pip… et moins de problèmes à mon sens.

Il est pourtant clair: Quand on commence à avoir besoin d'un foutoir de conteneurs pour faire coucher un truc codé quick&dirty reposant sur des dépendances tenant de l'alignement des planètes, avec ses semblables… Y'a un moment ou coller les machines les unes a côté des autres, chacune avec son applicatif et son environnement cornecul, n'est peut-être pas moins bête!

Un vélo utilisable pour moi c'est un vélo à 2 roues (certains cargo sont tricycles) car cela reste pas trop large et adapté aux infra existantes.

En prime ça penche dans les virages, ce qui à la fois plus fun et est moins désagréable à vivre (pas d'accélérations latérales).

Je n'aime personnellement pas trop le concept du vélo couché même si je vois bien l'avantage aérodynamique sur longues distances et pas trop de relief (exit la "danseuse") pour 2 raisons principales:
-Visibilité surtout si trafic et des 2 côtés (cycliste couché plus près du sol et autres véhicules ou on est plus facilement masqué et c'est pas un petit drapeau en hauteur qui change grand chose).
-En cas d'accident, on est en prime avec les zones vitales (tronc/tête) pile à la hauteur qui va prendre de plein fouet. A vélo c'est les jambes.

Quand je dis à 2 roues, j'avoue que dans un registre opposé au SUC (version cycle du SUV) de l'article je pense qu'il y aurait un créneau intéressant pour une revisite du monocycle, version électrique, permise par les technos actuelles.

Il y aurait en effet la possibilité d'en faire des VAE monocycles gyrostabilisés (comme les gyroroues, mais avec un avantage réglementaire intéressant chez nous, cf la suite) pour les sortir du rayon "vélo de cirque" et les rendre accessibles à beaucoup plus de monde.

L'avantage principal, c'est le côté assisté qui les ferait tomber dans la catégorie VAE et non EPDM (donc, réglementairement, assurance spécifique obligatoire contrairement aux vélos!) avec l'avantage propre à ces derniers jusque là d'un encombrement minimal qui le rendrait intéressant pour une bonne partie de la clientèle trottinette électrique actuelle et une plus grande roue qui rends moins sensible à la moindre irrégularité de chaussée.

La raison pour laquelle ce n'est pas encore fait, à mon sens, c'est que l'intérêt est directement lié à la réglementation française… Et que l'on n'a plus beaucoup de fabricants de vélo nationaux pouvant viser un marché uniquement national.

Visiblement, waypipe ne s'utilise pas vraiment avec la même souplesse que le ssh -X (ou -XC pour avoir aussi la compression à la volée depuis des lustres).

De ce que j'en comprends, on préfixe d'un "waypipe" chaque commande/applicatif distant lancé via un ssh. Donc au lieu de tout qui passe dans un tunnel via une unique connexion initiale, on se retrouve a en faire une par commande/applicatif.

C'est certes mieux que rien, mais n'est-ce pas une verrue de transition appelée à disparaître tandis que toujours rien n'est fait au coeur de wayland pour simplement égaler l'ancêtre dénigré construit autour de l'usage réseau?!!

Niveau "usage en voie de disparition", je dirais que c'est le contraire:
-Entre le milieu des années 90 quand j'ai commencé ma vie professionnelle et la seconde moitié de la décennie 2000, j'ai eu 2 machines physiques sur mon bureau (une Sun pour le developpement, un PC windows pour mail/bureautique) puis un seul PC fixe Linux (usage dev replacant la Sun)+VM windows (bureautique).
-Ensuite, jusque mi décennie 2010, j'ai eu un PC fixe Linux pour le dev + laptop windows (bureautique+dev en télétravail sur le fixe au bureau via Cygwin/X).
-Depuis, c'est laptop windows et dev sur des VM sur serveurs Linux partagés maousse costauds, utilisées à travers du VNC ou du X11 selon les préférences utilisateurs (perso, je suis resté à X11 à travers ssh car chaque fenêtre s'intègre mieux au DE client qu'avoir deux DE disjoints).

=> Le cas d'usage distant s'est juste généralisé en une dizaine d'années et le coeur de wayland passe toujours outre! Comment dire…

Je ne voit pas ou est le mensonge à souligner que wayland n'est pas conçu avec un usage réseau en tête. Que des verrues de compatibilité/transition aient été ajoutées côté client, fort bien, mais cela ne résout pas le pb qui va se poser à terme quand X11 va fatalement tomber en désuétude, côté serveur et applicatif cette fois.

Passer a côté d'un usage réseau pré-existant actuellement, c'est quand même pas un coup de génie…

Faudrait que je demande à ma femme, c'est elle qui est chez Airbus, mais à chaque retour de vacances je l'entends pester de ne pas pouvoir prioriser ses lectures dans la tétrachiée de mails reçus comme elle l'entends: Il me semble qu'un simple classement par expéditeur est impossible…
En tout cas tout le monde regrette Outlook.

Pour le chauffage, je dirais que l'électrique a un seul avantage par rapport à un chauffage central c'est de pouvoir mieux gérer par pièces (y compris allumage ou non, par exemple à mi-saison on peut n'avoir besoin que de chauffer la SdB ce qui n'est pas vraiment possible avec un circuit eau-chaude global qui en laisse toujours un peu passer via les canalisations même radiateurs fermés).

Au delà, faut pas laisser trop tomber sous 15/16°C (sauf vacances ou c'est HG, à 7°C, mais même sur 1 semaine de vacances en février ça descend pas en dessous de 10°C) mais de toutes manières l'isolation n'étant pas si mauvaise il faudrait une journée sans chauffe par des températures très hivernales en grande banlieue parisienne pour y tomber et cela se justifie plus pour éviter des désordres (humidité…) qu'autre chose.

Pour le reste, la perte étant proportionnelle au différentiel intérieur/extérieur, j'avoue avoir du mal à comprendre le credo du "si on laisse tomber trop bas, on perds à la remontée ce qu'on a gagné à laisser baisser": Bin non! Laisser une consigne à 17 alors qu'on pourrait laisser tomber sur la pente naturelle un peu plus bas c'est des pertes en plus sur les heures ou on descend à cette consigne maintenue.

Pour en revenir à gérer par pièces, j'ai voulu garder cette spécificité. Surtout que j'avais immédiatement changé les "grille-pains" anciens présents et autres rayonnants (à mon sens, cela n'a sa place que pour une SdB de par sa capacité à vous chauffer à travers une paroi de douche… car s'il y a un ouvrant à peu près dans leur axe, on a l'inconvénient de cet avantage et cela chauffe en partie dehors!) bas de gamme.

Pas investi dans des modèles complexes niveau programmation, voulant gérer moi-même: Juste des inertie sèche avec une bonne régulation électronique intégrée et 6 ordres fabriqués en France, achetés en arrivage Brico-Dépot (alors entre 89 et 149€ selon les puissances).

Le but était de conserver cette régulation interne (+calibrée pour leur inertie, pour ce type de radiateurs!) et d'influer sur la consigne de l'extérieur avec le seul truc commun obligatoire: Le fil-pilote (FP), qui va permettre à partir d'une consigne de base dite "confort" de gérer au moins, par ordre d'offset à la baisse vs consigne locale confort, confort-1 ou -2 (2 ordres facultatifs mais présents sur des modèles pas trop anciens), éco (en général confort-3), hors-gel (7°C en fait) et off: 4 à 6 ordres donc.

A ce bon deal de "radiateurs cons" (vs les "intelligents" vendus une blinde avec souvent des gestions propriétaires cornecul en prime!) mais néanmoins qualitatifs, j'avais ajouté pour alors ~40€/radiateur des modules FP 6 ordres en radio zwave (comme souvent, les FP n'étaient hélas pas tirés jusqu'au tableau) tenant dans les boites d'encastrement des branchements.

Bref, in-fine, c'est très simple à gérer (essentiellement par planning optimisant les heures-creuses… et switch de planning présence/vacance et désormais jours rouges tempo selon l'occupation/tarifs énergétiques). Et si je dois remplacer un modèle, la commande restera identique aux autres.

Le reste est de l'adaptatif selon qui est présent (smartphone de qui réponds en BT, utilisant celui intégré au PI3B, plus fiable à l'usage que wifi très ciblé par les stratégies d'économie d'énergie des mobiles et suffisant en portée dans ma maison) et capteurs de mouvements pour certaines pièces servant aussi à l'alarme.

Cela laisse aussi la liberté de régler les consigne confort localement, selon la pièce/occupant (chambres), qui sera juste altérée sur les principes généraux ci-dessus. Et évite aussi de rajouter des composants de puissance (le FP est une entrée haute impédance), leurs bruits de relais ajoutés potentiels (chambres) + capteurs de T dans chaque pièce en régulant de dehors.

Ayant aussi un insert, les plannings chauffe se retrouvent invalidés quand il est utilisé et ensuite tant que la température n'est pas descendue sous un seuil (il a beaucoup de maçonnerie autour et restitue 6 à 10h après la fin de combustion selon la durée de fonctionnement).

Bref, rien de chiadé de ce côté chauffage (y'a pire ailleurs niveau cams IP par exemple). A l'usage c'est suffisant et a rapidement rentabilisé le matériel à comparer mes factures et celles de mes voisins (lotissement donc bcp de maisons similaires).

Niveau énergie, j'ai aussi un module compteur installé en tête de tableau qui inclus une commande de relais externe. Au delà d'avoir de belles courbes de conso permettant de valider ses stratégies d'optimisation des heures-creuses, cette commande (relais statique pour faible ampérage de commande adapté ici) est mise en série avec la commande du relais heures-creuses venant du compteur EDF.

L’intérêt étant qu'en plus du chauffage, la mise en route du ballon ECS en heures-creuses peut aussi être ou non activée.

Pratique, avec deux simples plannings normal/absence de pouvoir à la veille d'un retour de vacances remettre à distance le planning normal et d'avoir la maison à température et de l'eau chaude en arrivant.

Le webmail reste une solution de dépannage: Possibilités de tri/recherche limitées, archivage local même pas en rêve, aucune possibilité d’agréger plusieurs adresses des fournisseurs de son choix.

Voir dire qu'avoir construit un support graphique traversé par le réseau depuis les origines était mauvais tout en trouvant élégant de se retrouver avec un usage autour d'un navigateur faisant office de minitel moderne, cela manque à mon sens un peu de cohérence!

Des boites comme Airbus qui ont tout foutu chez Google côté bureautique et mail (sans permettre le smtp/imap et imposant le webmail) connaissent de gros problèmes induits par ces choix stupides: Des fonctionnalités de classement simple existant dans le plus basique des client mails sont absentes! Merci Enders…

Un RDP, au moins à chaque fois que j'en ai utilisé, tire un bureau complet… d'une machine distance ayant… un DE complet!

J'utilise pour ma part beaucoup le "ssh -X" pour un peu de dev/configuration sur des machines headless sur lesquelles un DE complet autant qu'inutile n'est pas installé.

Le combo xvfb/rxvt-unicode/nedit permettant de travailler relativement confortablement dans ce type de cadre sans devoir coller trop de mauvaise graisse sur une installation voulue minimale, n'a a mon sens pas de remplaçant avec Wayland. C'est ballot.

Au pire, je pourrais m'en passer. Mais je n'appellerais pas vraiment cela un progrès, plutôt une régression.

Pas que le gaming si je n'ai rien loupé: Les utilisateurs du "ssh -X …" ne sont pas des gamers et vont pleurer.

C'est pourtant bien pratique et évite de traîner des sessions distantes complètes (RDP/VNC) tout en s'intégrant nativement dans l'environnement graphique du client. Même face à un système headless/embarqué plus minimaliste, donc sans DE, le paquet X11 frame buffer (xvfb sur Debian&Co) permet de travailler en graphique plus confortablement sans alourdissement excessif (à condition d'éviter tout applicatif qui va tirer l'essentiel des dépendances d'un Gnome ou d'un KDE).

Des cas d'usage négligés (voir méprisés) depuis les origines par les développeurs de Wayland hélas!

Personnellement, j'ai du mal à voir le progrès d'un support graphique passant à côté du réseau. Encore plus à voir critiquer l'ancêtre quand on s'assied, à l'heure actuelle, là dessus.

Pas forcément un problème, si on a un proche/voisin qui passe tous les jours pour la gamelle et vérifier que tout va bien… et qu'ils ont de quoi s'abriter.
Y'a certains animaux assez casaniers/territoriaux qui sont bien plus perturbés par un changement d'environnement temporaire pour les vacances que rester, même seuls, chez eux.
Des chats vivant beaucoup dehors n'apprécient vraiment pas de se retrouver enfermés dans une loc de vacance par exemple. Et pire que des chiens, s'ils arrivent à profiter d'une négligence pour se tirer les retrouver peut être compliqué.

Pauvre bête!

Pour ma part, ayant démarré avec Domoticz pour gérer la baraque tout juste achetée il y a 7 ans et le gros consommateur que représente un chauffage tout électrique… j'avais rapidement étendu à l'alarme même si c'est normalement pas le même rayon.

L'avantage, c'est que les capteurs de mouvements qui peuvent servir à déterminer si une pièce est vide/occupée et adapter chauffage et autre en conséquence peuvent aussi servir à l'alarme.

Par contre, rien n'est dispo de base… mais ce soft domoticz était (et reste probablement, avec les ajouts de python et plugins depuis) le plus complet en matière de possibilités de script intégrée (blockly, pour des trucs simples en mode newbie que j'ai pas utilisé. Et surtout Lua, pour des choses plus chiadées).

J'ai donc codé le coeur de mon truc en Lua, de manière assez générique (utilisant un prefixage/convention de nommage selon le type de capteur et/ou localisation intérieure extérieure déterminant les poids de base, cf la suite, ce qui permet une intégration de nouveaux sans changer son code tant qu'on respecte la convention de nommage) et utilisant un système de poids additionnés sur une minute glissante.

Grossièrement, un capteur intérieur va avoir un poids déclenchant l'alarme longue (cf la suite) immédiatement et un capteur extérieur ce sera une fraction du seuil d'alarme courte (i.e. plusieurs déclenchements d'un même capteur et/ou de plusieurs requis pour que cela commence à sonner court, puis long si ca insiste).

Ce cumul est comparé à 2 seuils: Alarme courte déclenchant sirènes pour 5 secondes sans notifications (manière de signifier à un intrus n'ayant déclenché que des capteurs externes qu'il a été vu, sans emmerder le voisinage avec une sirène qui sonne longtemps sur le faux positif d'un chat qui passe). Puis alarme longue pour 5 minutes renouvelées au besoin.

Le but étant que cela s'arrête avant même qu'un volet/porte/fenêtre soit forcé, car ensuite en qq minutes c'est foutu donc sonner sur ouverture/capteur intérieur qui tilte insuffisant.

Au début, je n'avais que des capteurs réels (PIR, installés en intérieur et extérieur ou capteurs d'ouverture). J'ai depuis cumulé avec des caméras IP (modèles Dahua peu chers mais complets avec des sensi nocturnes bonnes, installés en extérieur et garage uniquement).

Pour les intégrer, domoticz permet un truc pas mal: La possibilité de faire des switchs/senseurs virtuels! L'intégration est alors aisée: On fait des PIR virtuels qui sont déclenchés quand les caméras génèrent des captures via leur motion intégré.

Ici c'est un service écrit en python (j'aime pas trop ce langage, mais la richesse des imports m'a permis de faire pas mal de choses que je ne détaillerais pas niveau traitement des captures, envois notifs/mails) qui surveille le FTP des caméras toutes les 5 secondes et "déclenche" les PIR virtuels via l'API HTTP/JSON fournie par Domoticz.

J'ai d'ailleurs d'autres services en python s'intégrant ainsi à Domoticz, pas écrits sous forme plugin (je les ai écrit avant que les plugins n'existent): Détection de qui est présent/absent via le BT des smartphones (permet de pallier aux oublis d'activation alarme des enfants en sortant, sachant qu'ils n'oublient jamais leurs téléphones!), filtrage (par décroché/raccroché) du spam téléphonique recyclant un vieux modem voix USB avec la fonctionnalité caller ID.

L'avantage des plugins, c'est que cela intègre les interactions sans devoir passer par l'API HTTP/JSON et la génération d'une page de cconfiguration directement intégrée à l'UI domoticz tandis que je gère mes fichier yml séparés.

Niveaux interactions externes, il y a le support https (via domaine no-ip+certif let's encrypt pour moi) pour l'interface… basique vs d'autres solutions mais efficace et fonctionnant bien même sur un mobile Android pas bien véloce. Permettant aussi de servir ses propres "custom pages" au besoin (mes services python cam IP et filtrage tél en génèrent d'assez simples via yattag par exemple: Assemblage des dernières captures cam permettant une levée de doute rapide et peu gourmande en bande passante, qui fonctionnera même sur un AP surchargé de loc de vacances au besoin d'un côté ; liste d'appelants+raison filtrage éventuel de l'autre) pour ajouter ce qui peut manquer.

=> Il faut se retrousser les manches, car au delà de l'intégration du matériel et gérer les protocoles de com courants en domotique + gestion des évènements associés et présentation (fixe+mobile) il n'y a pas grand chose (mais c'est déjà un gros morceau!)… mais les possibilités de script bien foutues/intégrées + API externes offrent une grande liberté permettant de faire des trucs qu'on ne trouverait pas dans le commerce: Une solution plus Geek que Michu.

Niveau script, j'ai appris à apprécier Lua car il est stable et me fout une paix royale (coucou Python!): Une seule ligne à modifier en 7 ans sur une MAJ domoticz qui incluait un upgrade de l'interpréteur Lua intégré. Les déclencheurs type time (toute les minutes) ou device (un changement d'état sur un interrupteur/capteur…) sont suffisants et l'interaction avec les états/séquenceur d'event bien foutue à partie de tables prise à l'appel/modifiée par le script/restituées en sortie pour déclencher les actions…

Au dessus de Lua, il y a un dérivé spécifique nommé dzVent: Arrivé après que j'ai écrit l'essentiel de mes besoins, pas utilisé mais apprécié de la majorité des utilisateurs.

Et Python (dispo en plus du reste niveau scripts depuis ~3ans, passage obligé pour les plugins): Je conseillerais pour ma part d'en rester à Lua/dzVent côté scripts (stabilité, quasi impossibilité de planter Domoticz avec une erreur dans un script ce qui n'est pas le cas de Python) plutôt que Python (sauf besoin plugin).

2 possibilités pour écrire les scripts: Intégrée à l'UI ou pas (fichier dans domoticz/script/lua par exemple, respectant la convention de nommage selon déclencheur time|device). Je conseille la seconde, car si par malheur un script plante Domoticz dans le 1er cas il est sauvegardé dans la BDD de domoticz. Pouvoir redémarrer n'est alors pas aussi simple que le faire après avoir bougé/renommé le fichier problématique car il faut éditer la BDD ou relancer domoticz manuellement, event system désactivé, pour pouvoir virer ou éditer le script problématique. Par contre, en cas de réinstallation complète, il faut penser à récupérer ses scripts en plus de la seule BDD.

C'est aussi la seule solution codée en C++ et (cross-)compilée native donc fatalement plus économe en ressources que des Jeedom/Home-Assistant… La seule vraie verrue qui m'emmerde (mais ce sera aussi le cas ailleurs), c'est la gestion zwave qui arrive: OpenZWave (librairie C++, la stable 2023.2 domoticz est la dernière à l'intégrer) étant abandonné/déprécié, il faut en passer par le genre de tas de merde "moderne" qui m'exaspère: zwavejs.

Que des mecs aient pu écrire un truc destiné à gérer du matériel (à travers une pseudo liaison série pour gérer le protocole radio derrière) en javascript, obligeant à traîner un interpréteur de plus, ses dépendances, pour conseiller en plus de coller cela en conteneur car satisfaire ces dépendances avec des OS variables tiens de l'alignement des planètes… puis interfacer cela en MQTT (un serveur à ajouter doublonnant l'event system intégré) à un auto-discovery côté domoticz.

Bonjour la prise de tête vs un truc intégré jusque là nativement.

Mon conseil pour qqun qui démarre: Partir sur du zigbee (même type de réseau radio maillé basse conso, même si en 2.4GHz plus chargé que le 868MHz, périphériques ayant un minimum d'intelligence via configuration), même s'il faut faire attention à ce qu'on achète car l'interopérabilité entre fabricants n'est pas au niveau de ce qu'imposait zwave (c'est moins cher, mais pas de process de certification assurant l'intéropérabilité en zigbee!). On a un plugin ZigbeeForDomoticz qui permet d'éviter MQTT&Co écrit en python et bien suivi.

Pour ce cas d'usage, un utilitaire léger (éventuellement électrique) fait le job. La Poste a limité ses VAE (bien foutus d'ailleurs) au courrier car au delà cela ne leur a sans doute pas paru réaliste.

Pas mieux… C'est un tricycle à pédale version SUV et plus vraiment un vélo avec la liberté offerte par une largeur/encombrement moindre, qui participent également à sa bonne tolérance globale (quoique certains en disent) sur la route (du moment qu'on roule correctement et à sa place) et en stationnement : Allez sur un trottoir, les regards vont changer devant ces rickshaw à assistance électrique.

Même sur une piste cyclable avec les dimensions faites pour des… cycles… ce tricycle ne pourra pas avoir sa place: Le meilleur moyen de se faire jeter par les cyclistes et les automobilistes?

Et d'accord aussi sur le pb des panneaux: Aucun intérêt et avec les vibrations du tape cul il est probable que leur durée de vie rende l'affaire aussi peu écologique que fort coûteuse.

Là c'est surtout une forêt pour cacher sa compagne des crocodiles qui rôdent

ENFIN!

C'est à se demander comment El Guido avait pu oublier le switch/case si commun (à commencer par le C… présent même dans la plupart des shell sauf peut-être le ash de busybox!). Et pour faire genre "c'est pas exactement cela", on ajoute de la confusion en faisant les originaux et l'appeler autrement! Penser à ceux qui switchent (ah ah!) régulièrement de langage? N'y pensez pas!

Ca rappelle le "syndrome Java", ces multiples évolutions qui auraient pu être évitées, ce qui amena au bout de 10 ans chaque applicatif codé dans ce language à traîner sa JVM et dépendances car a force de modif/rajouts sur des choses mal pensées au départ cela devient mission impossible. Avec un énorme gâchis et la désuétude à la clef.

Allez, encore quelques versions et, pour les cerveaux procéduraux comme moi qui peinent à penser objet, on trouvera peut-être un simple équivalent des variables statiques du C (qui resteront un des gros trucs qui me manquent régulièrement) et dans devoir tricher (via un nomFonction.dict) ;o)

Bon, OK, j'ai jamais vraiment appris Python autrement que sur le tas et j'aurais peut-être besoin d'un bon bouquin! Mais c'est quand même dommage de se retrouver à devoir mettre cela après tant de versions pour créer un bazar évitable.

J'ai pour mitiger les problèmes l'habitude de me limiter aux imports de la distro pour éviter les environnements cloisonnés (et le syndrome Java): L'interpréteur dans la version de la distro, les modules cohérents qui vont avec. Et si ça n'y est pas, au grand jamais de pip pour récupérer ce qui peut me manquer et gagner un peu de temps qui sera largement perdu sur la durée derrière avec potentiellement un import exotique à la maintenance future aléatoire (mon crédo : Ce qui a du succès, est suivi et dure, y'a toujours un mainteneur de la distro l'ayant intégré!) qu'il faudra revoir un jour, obligeant à se recoller des années après dans un truc qui marchait.

Mais j'ai un usage qu'on pourrait qualifier de super-bash, dans ce cadre c'est un compromis efficacité/emmerdes qui me parait pas mauvais!??

Debian continuant à proposer le x86 32bit, mon EeePC901 va sans doute passer de la 11 à la 12 un de ces jours.

Je ne l'utilise plus guère, mais c'était encore le cas jusqu'à il y a 3 ans quand ses lenteurs combinées au fait que certaines fenêtres ne sont même plus redimensionnables dans ses 600pix de hauteur, y compris sur des DE visant les ordinosaures, ont commencé à trop me faire ch…!

=>Achat alors d'un Thinkpad X260 12.5" d'occase, vu que plus de netbooks plus petits sur le marché, hélas, sauf qq constructeurs chinois confidentiels (+tarif petite série et garantie en rêve!).

J'ai bien tenté quelques distro plus frugales susceptibles de lui donner une seconde jeunesse, mais entre ce qui est à la limite de l'utile et ce qui ne fonctionne pas après install… bin je vais probablement revenir sur un bookworm-mate (ou retenter xfce).

J'ai du Debian partout de toutes manières: Mon desktop, laptops en double boot, eepc… et même au boulot avec un VM sur le laptop car IT ne sait maintenir que du windows et sur les machines labo qu'on peut encore gérer nous mêmes.

Le succès vient sans doute du support mais, à la base, surtout au fait que cette distribution permet de mettre la même version pendant de nombreuse années (10 ans de support) sur un parc fatalement hétérogène vu la durée.
Cela impose le backport des CVE mais surtout, pour les nouveaux matériels, celui de leur support de noyaux actuels vers de très anciens avec des drivers model ayant pu beaucoup évoluer…

Le support intervient à mon sens en second, expliquant aussi tant de clones d'ailleurs parfois repris par des sociétés importantes ayant la masse justifiant d'y consacrer leurs propres équipes utilisant un clone: Alcatel a longtemps utilisé Scientific-Linux par exemple.

Au delà, peu d'intérêt à RH il faut bien le dire. Les endroits ou les utilisateurs peuvent installer leurs propres machines (labos R&D…), car ayant des besoins très spécifiques, on préfère largement des Debian (ou dérivés) aux RH pour des raisons telles qu'un gestionnaire de paquet ayant la complétion intégrée (quand rpm oblige à passer par un search, au moins la dernière fois que j'ai eu à en utiliser il y a déjà pas mal d'années)… ou tout simplement la richesse de contenu des dépôts: RH, en comparaison de Debian, est un désert qui vous oblige à jouer vous même au mainteneur… ou a bidouiller avec les dépots Fedora au risque d'avoir des gros pb.

Un meilleur compromis stabilité/noyau pas trop antédiluvien, aussi, permettant quand on fait des produits basés Linux une plus grande proximité hote/cible en développement, ce qui est toujours utile pour prototyper un petit truc pas trop lié au matériel.

Sacré projet, mais à mon sens irréalisable seul et il serait sans doute intéressant d'avoir au niveau des débouchés l'approche originale de sa définition.

Car certains débouchés sont inaccessibles à bien des processeurs modernes, par manque de déterminisme ou car ils sont pétris d'états indéfinis:

De ce point de vue, le PowerPC (même si, au milieu des derniers SoC Freescale/NXP, le coreNet gênait déjà un peu car son fonctionnement sans aucun contrôle/réglage tenait du secret d'état, contrairement a l'architecture de bus interne antérieure permettant de gérer très classiquement des priorités entre périfs et un parking-master) tombant en désuétude après une vingtaine d'années de développement et déverminage de ses itérations successives par l'industrie Télécoms laisse un vide pour les futures applications critiques (avionique en particulier).

Ce n'est pas encore trop visible, avec des délais de développement/certification dépassant 10 ans, mais c'est un problème qui inquiétait déjà il y a 4 ou 5 ans et même si je n'ai plus d'infos récentes, pourrait commencer à faire vraiment suer dans certains bureaux d'étude: Assez pour les motiver à étudier des approches différentes combinant potentiellement simplicité et performance?

C'est clairement un domaine ou on préférera voir un maximum d'optimisations gérées de manière visible par le compilo que de manière obscure dans le silicium.

Bon, je vais donc pouvoir me préparer à upgrader même si j'attends en général la .1, par précaution.

Par contre, si y'a des retours sur Cinnamon? Le mainteneur était de mémoire passé à KDE et, n'étant donc plus lui-même utilisateur, arrêté. J'espère que cela continue à tenir la route, ayant lâché Gnome (j'aime pas son espèce d'hybride PC/Tablette niveau environnement graphique, chose que Cinnamon corrige de mon point de vue) après sa version 2…

De même, je ne peux vivre sans X11 forwarding à travers SSH dès que je travaille sur une machine distante (y compris les PI headless, install minimales sans bureau, avec juste le X11 frame-buffer xvfb et un applicatif X choisi, cad ne tirant pas l'essentiel des dépendances de Gnome ou KDE pour un terminal graphique ou un éditeur!): Un cas d'usage qui n'était, sauf à ce que cela ait changé, pas couvert par Wayland qui me semble venir par défaut avec la 12…

Au pire je testerais dans une VM.

Ah… World Of Padman: Vraiment un jeu sympa, y compris chez soi en réseau, adapté aux jeunes enfants vu le côté paint-ball de nains dans des décors géants. Et qui se contente d'un matos frugal.
J'ai adoré ce jeu! A priori, après des années de pause, il semble aussi reprendre vie même si les serveurs n'ont jamais été vides.
A essayer pour ceux qui ne connaissent pas!

A un moment, c'était ma réponse à un numéro inconnu avec le ton du fonctionnaire blasé qui va bien…

Puis avec jusqu'à 10 appels/j, je suis passé à l'automatisation. Étant chez Sosh/Orange qui ne donne hélas pas accès au SIP pour téléphoner de son PC… et aussi faire un système de filtrage sur numéro appelant avec le simple raspberry qui gère déjà la baraque (domotique) sans matériel supplémentaire par exemple… J'ai dû recycler un modem 56K USB qui permet de récupérer l'info du numéro appelant via le RJ11 inutilisé chez moi (tout DECT via la base intégrée à la LB): Le truc que les moins de 30 ans ne peuvent pas connaître!

Le principe est assez simple: Filtrage d'un décroché/raccroché si le numéro ne revient pas au système de filtrage (un gros script python: Même si j'aime pas trop ce langage mal conçu de base donc manquant de stabilité avec les versions, il y a de quoi se simplifier la vie niveau modules évitant se devoir réinventer la roue pour s'interfacer au modem vu comme un serial-usb, au web, à la solution domotique et notifier par mail en absence : serial, request, beautifulsoup, smtplib, email…).

La réalisation l'est un peu moins: On se rends vite compte de l'étendue du problème et qu'un filtrage de numéro ou même de plages de numéros (l'ARCEP les alloue le plus souvent par tranches de 10k) ne va pas suffire. Ni même passer par l'interrogation d'un service externe (type doisjerepondre.fr, à réaliser via parsing de la page de réponse car pas d'API pour récupérer simplement la classification du numéro par le site, mais sur celui là on évite au moins les capcha).

Plusieurs choses simplifient néanmoins dans mon cas l'affaire:
1) La Livebox présente le numéro sur le RJ11 et l'associe à un nom si on utilise sa base DECT intégrée et qu'on l'a enregistré sur le téléphone. Laisser passer ses proches devient donc simple sans même gérer de whitelist.
2) L'ARCEP publie les plages d'allocation (fichier MAJNUM.xls sur leur site en open-data) et les lie à l'opérateur qui les détiens. Ainsi, ceux qui après qq semaines apparaissent générer 100% de spam téléphonique peuvent être filtrés par nom d'opérateur, toutes les plages de numéros qui leur sont allouées étant de facto blacklistées: Ils n'ont qu'a mieux choisir leur clientèle. On commence alors à retrouver le repos!
3) Bien entendu, ceci ne fonctionne pas quand l'opérateur est Orange/Free/Bouygues… On ne peut pas barrer un opérateur grand public complet, pourtant il y a des numéros à emmerde correspondant à des plages d'allocations réservées à des services VoIP sources d'emmerdes: Là, si doisjerepondre sort un seul numéro avec une mauvaise classification, la plage concernée se retrouve désormais automatiquement filtrée en totalité.

Malgré tout, il en reste qui passent au travers: Parfois certains filtrés rappellent avec 2 ou 3 numéros différents dans les 10s. Finissant souvent avec un numéro appartenant à un particulier ou un numéro de mobile, illustrant le problème croissant des lois accroissant les sanctions au démarchage abusif: Le spoofing de numéros téléphonique, hélas autorisé pour certains cas particuliers.

Quand le numéro présenté est visiblement usurpé (ce qui arrive de + en + dès l'appel initial), aucun filtrage ne fonctionne et l'identification certaine de l'emmerdeur n'est même pas possible. Sans loi encadrant encore plus la pratique et punissant les abus si gravement que ce serait la clef sous la porte assurée pour ces boites, il n'y aura pas de solution au problème. Il y aura juste adaptation du camp d'en face.

Je n'ai pour ma part pas d'hébergement 24/7 pour les proches, mais j'ai longtemps eu un simple serveur SSH accessible de l'extérieur pour mes propres besoins: Clairement, regarder les logs faisait peur… Fail2ban permettant de calmer l'affaire bien au delà des options intégrées au serveur.

Le port knock, avec une séquence bien choisie pouvant au pire se faire avec une simple commande ping (dispo sur toute machine, ma philo étant de pouvoir au besoin me connecter de toute machine de confiance sans outil spécifique avec juste ma tête de disponible, ce qui exclu donc également l'usage de clef ssh pour en rester aux user/pass), j'ai aussi utilisé… avant de passer IPV6: knockd ne le supporte pas!

Depuis, j'ai de la domotique avec un accès externe HTTPS (merci certbot/letsencrypt).

Depuis, j'avoue être assez surpris vs SSH: On voit certes passer des connections, mais juste les robots d'indexation lâchant l'affaire sur la page de connexion et/ou après lecture du robots.txt.

HTTPS semble donc au final assez peu attaqué comparé à SSH qui est un aimant à robots de bruteforce.

=> J'ouvre désormais au besoin le SSH via un bouton de l'interface domotique/HTTPS, accessible comme le reste après login et qui appelle un script ouvrant le port 22 pour 30s, laissant le temps d'établir une connexion si besoin d'administration distante/accès à mon LAN via tunnel/proxy socks.

Simple et pour le moment jamais mis en défaut.