lym a écrit 148 commentaires

man ascii est complet.
man utf8? ah bin là c'est du man classique, l'exhaustivité étant plus longue.

Les caractères spéciaux, c'est en effet pas forcément pratique en mots de passe (selon le clavier/langage de la machine utilisée) comme en nommage.

Les miens sont devenus grands, majorité depuis 2 mois, mais petits ils ont beaucoup apprécié Ri-Li sur PC en petit jeu simple…

Un autre jeu simple et ludique qui les faisait bien marrer, surtout que l'on y jouait à 2 en alternance, c'est Slingshot (canardage version assistance gravitationnelle ou l'on peut s'amuser… à progressivement trouver les trajectoires les + chiadées pour exploser l'autre!).

Après, en shoot-them-up version pas gore (paintball de minimoys dans des décors de maison/jardins…), en prime jouable sur réseau local quand ils ont eu leur PC: World Of Padman!

Je ne savais pas que CP/M avait besoin d'un boot-loader lui fournissant des services (ces fameuses "interruptions BIOS", pas vraiment au sens matériel mais du nom de l'instruction permettant de les appeler avec leur numéro, correspondant aux system-call actuels des boot sécurisés) pour tout, comme le DOS (tout ce qui tapait dans le matériel y passait: frappes clavier, gestion écran/stockage…).

Car ensuite le duo wintel, qui avait lâché ce fonctionnement (Linux n'en a jamais eu vraiment besoin, sauf récemment avec les services liés aux enclaves sécurisées justement) ayant fait le nid des virus dits de secteur de boot, a été prompt à le remettre avec les runtime services UEFI (sous ensemble des boot services complets, actifs avant le lancement de l'OS, destinés à pouvoir être appelés par l'OS) avec l'arrivée du secure boot (permettant de limiter les risques passés du concept!).

CP/M était d'ailleurs fourni avec mon Amstrad CPC6128 d'ado, qui n'avait pas de BIOS, même si je ne l'ai jamais utilisé pour ma part???

Pour avoir fait du vxWorks sur PowerPC brut de fonderie, on bootait sur une flash NOR sur bus parallèle en raw (pas de FS) et le boot-loader était limité peu ou prou à un fichier assembleur nommé rominit.S, de mémoire!

Bon, ça c’était au début. Bien entendu pour faire un produit commercial derrière on avait voulu un flash file system, même minimaliste, avec une partition active et une backup pour ne pas se planter sur un upgrade foireux (et un système de reset-loop-counter RAZ par une probation en toute fin de boot OS, tout l'applicatif et liens réseau de supervision lancés, qui assurait un swap de partition si ce RLC dépassait 3).

D'où une architecture plus classique de boot loader à 2 niveau avec un premier, non upgradable (en fait, des bugs processeur sur des trucs à initialiser très tôt nous avaient contraints à mettre un mécanisme d'upgrade en place, même si ce fut rare et avec des risques de briquer du matériel déployé) et commun aux 2 partitions, fut un héritier du rominit.S (inits minimales de base et contrôleur DDR) ajoutant la gestion du swap de partition et l'appel à un second niveau, il y en avait 1 binaire en face de chaque partition, incluant le gros des inits matérielles hors DDR et les trucs qui peuvent évoluer avec l'OS ou nécessiter des corrections de bug (reader de file-system utilisé etc…), ainsi qu'un support réseau basique pour le boot TFTP (en développement/fabrication, voir dépannage).

Bon, c'est clairement une simplicité qui se perds avec les mécanismes de boot sécurisés ou on rajoute bien des étages (tournant éventuellement sur des processeurs de service qui ne sont même pas les principaux, contenant les FW de gestion pré-boot, énergie etc) à la fusée qui décolle (ou pas!)…

J'ai longtemps eu un sshd ouvert sur l'extérieur et c'est visiblement une cible très recherchée depuis longtemps. Voir trop pour un outil comme fail2ban.

J'étais donc passé au port-knocking en choisissant une séquence simple et réalisable au besoin sans outil dédié (un triplet de ping uniques): Port/redirection toujours ouverte côté box, ainsi que celle concernant les ports utilisé en stimuli au knockd, ce dernier ouvrant juste le 22 sur la machine à la demande.

Puis Orange m'a un jour passé en IPv6 une nuit sans prévenir… et qq temps après, regardant les logs par hasard, je m'en apercoit car les tentatives de bruteforce ssh avaient repris!

Ce n'était pas qu'un pb de configuration de knockd: Il ne supporte pas IPv6… Et pas trouvé d'alternatives dans les dépôts Debian quand j'avais cherché.

La machine avec un sshd étant un PI qui héberge ma domotique déjà rendue accessible en https (via domaine no-ip et certificat let's encrypt) et ce dernier étant paradoxalement incomparablement moins visé que ssh (pas grand chose en dehors des robots d'indexation des moteurs de recherche qui lâchent l'affaire après lecture du robots.txt ou sur la page de login), ça a fini par un interrupteur virtuel sur la page domotique qui déclenche un script qui ouvre le 22 pour 1 minute sur demande, laissant le temps d’établir une connexion ssh externe.

AMHA, il n'y a guère le choix avec un serveur ssh: Le seul moyen d'avoir la paix c'est d'avoir un moyen adapté à sa situation pour l'ouvrir à la demande… C'est juste trop ciblé et même passer a l'authentification par clef ne résout aucunement la pollution de log et de son LAN par les tentatives.

On peut m’enchaîner les moins sur une opinion assez factuelle, mais les faits sont têtus et leurs conséquences de plus en plus difficiles à cacher, de la Suède (historiquement tolérante, le virage à 180° y est extrêmement brutal) à l’Irlande et la Hollande, sans parler de l'Allemagne malgré les puissants tabous liés à leur triste histoire ; pour bosser avec des polonais et des slovaques, je peux vous dire que tout sera fait pour que nos problèmes n'arrivent jamais chez eux et leur politiques ne pourront pas se confondre dans une compromission intéressée comme ici: Tout se règle de manière conflictuelle avec eux, même des broutilles, c'est leur façon de fonctionner. Les conséquences seraient extrêmement brutales, voir fatales.
L'alternative, c'est une société de pesant flicage pour tous (déjà amorcée) faute d'avoir eu le courage politique de cibler ceux qui posent problème: Du "vivre ensemble" au "fliqué ensemble" en qq sorte.

L'article n'est certes pas exempt de reproches, mais il y a des réalités qui dérangent et sont depuis longtemps prisonnières d'une certaine "bien pensance" distillée par certains élus plus intéressés par leur réélection future que les problèmes du pays: Le PS avait commencé dès les années 80, LFI a repris l'affaire… C'est simple mais quand j'entends le crédo du "vivre ensemble" dans la bouche d'un élu cela ne fait, avec 100% de réussite, que confirmer mes impressions antérieures (qui il préserve en campagne, les raout islamistes permis dans des gymnases/équipements municipaux mis à disposition): A-t'on eu besoin de clamer ces crédos "intégration" et "vivre ensemble" avec les vagues d'immigration précédentes (italiens, portugais, espagnols…)? Non, en qq années ce fut plié et pourtant ils avaient eu aussi leur dose de reproches et d'insultes, y compris leurs enfants à l'école.
Exemple le plus récent, on a mis combien de jour à voir sortir, suite à la descente des charmants garçons de Romans sur Isère qui ont tué un jeune de 16 ans et blessé plusieurs autres personnes, les raisons de leurs actes? Et c'est pas nouveau, ayant habité dans une charmante cité mes 20 premières années j'ai eu l'occasion de voir de très près bien des problèmes monter, hélas sans réaction politique autre que minimiser les problèmes et mettre au ban ceux qui les dénonçaient.
Personnellement, je pense que le pouvoir soigne la presse qui le lui rends bien. En premier lieu avec cet avantage fiscal réservé aux journalistes… Le truc totalement injustifié: Pourquoi cette profession plutôt qu'une autre? Posez vous la question…
Et en face? Bin c'est action=>réaction et comparé aux médias cités Atlantico est loin d'être le pire. Mais il est ici important de ne pas confondre cause et conséquence (et le sens de la flèche).
Il y a un moment ou il faut juste regarder les choses en face, même si cela déplaît. La réaction politique de coller de la prison ferme à l’extrême droite venue manifester est probablement une connerie majeure: On officialise vraiment un 2 poids 2 mesures qui va les alimenter tout en confortant les "tueurs de blancs". Et quand les seconds encouragés à redoubler d'effort vont s'y mettre, vers qui se tourneront les gens car ils se seront préparé à faire face? Il y a un moment ou ce sera "les ennemis de mes ennemis sont mes amis" qui primera…
Les dissolutions promises, comme toujours en pareil cas qqsoit le "bord", ne vont faire que compliquer les choses en invitant leurs activistes non à se ranger mais à passer à 100% dans l'action clandestine.
Et des signaux faibles croissant depuis au moins 10 ans montrent que, comme en Irlande, il y a des gens qui ne comptent pas se laisser faire: Le nombre d'armes de chasse "volées" dans les véhicules par exemple… qui le sont car on les y a laissé "négligemment".
Et quand ce sera le cas, c'est nos dirigeants de ces 3 à 4 dernières décennies qui en porteront la lourde responsabilité, avec ceux qui les auront suivi dans leur stupide aveuglement.

Je dirais même que le plus rentable est sans doute pour ceux qui consomment peu et n'y pensent pas!

Qqun qui chauffe/cuisine au gaz, même s'il a un ballon électrique qui sera probablement déjà sur les HC, va payer beaucoup moins cher sans même devoir changer ses habitudes: Tout bénéf sans même les emmerdes, contrairement à celui qui se chauffe électrique et aura besoin d'un mode de chauffage secondaire (poelle/insert… donc un investissement conséquent si pas déjà installé, s'emmerder à un approvisionnement/manutention et pour le bois c'est une contrainte pas anodine).

Je pense que le différentiel d'abonnement entre Tempo et un HP/HC classique voir base est pour eux rentabilisé très vite à la consommation. Et ne parlons pas du prix plancher du MWh acté à 70€ par Le Maire (qui nous explique, en évoquant juste la modération côté prix plafond, que ce sera "indolore" vs les ~40€ nucléaire actuel ou tombe le gros de notre production annuelle) qui arrivera pour 2026 et va faire plus mal côté kWh qu'abonnement.

Le seul truc potentiellement un peu chiant, c'est de ne plus avoir le choix des horaires HC: C'est obligatoirement 22h/6h en Tempo.

En particulier, ceux qui ont un abonnement HP/HC heures méridiennes (toujours 8h d'HC globales par 24h, mais fractionnées 5+3 avec 3h l'après midi), peuvent devoir faire un peu mieux leurs calculs selon leurs usages: Quand j'étais en appartement, les machines à laver étaient par exemple inenvisageables la nuit avec le bruit à l'essorage et j'étais content de pouvoir coller cela en HC de 14h à 17h… En maison, ca tourne la nuit sans générer de nuisances vers les chambres à l'étage ou un voisin du dessous.

Mais bon, ces formules heures méridiennes ne semblent plus proposées, Enedis devant être plus au taquet qu'avant en milieu d'après midi côté production/distribution. Elles ne concernent donc plus que d'anciens abonnements.

Idem: j'utilise la première API, en test depuis qq mois (passage Tempo en avril dernier), pour gérer automatiquement ma domotique (essentiellement, m'avertir et commuter un peu avant 22h, juste avant les premiers ordres, un planning jours rouges afin de limiter en gros le chauffage en heures pleines au sèche serviettes de la SdB… et renforcer le planning chauffe nocturne en heures creuses). Je ne suis strict que sur HP/Rouge (chauffage elec, là y'a intérêt à faire journée bois/insert!), en blanc ça sera du "best-effort" si je peux anticiper un truc la veille car le tarif reste assez intéressant pour pas se mettre trop la rate au court-bouillon.

C'est MAJ peu après 11h, vers 11h03, toujours avant 11h10 à l'exception notable du passage heure d'hiver récent ou ca a été fait en début d'a.m.

Mon script (Lua, j'utilise Domoticz) tente toutes les 10mn à partir de 11h si dernière MAJ date de plus de 12h, jusque 16h max… mais s'arrête en fait dès que couleur J1 != NON_DEFINI. A 11h c'est ainsi, à 11h10 on a TEMPO_(BLEU||BLANC||ROUGE) donc ca se limite à 2 essais normalement. Doit bien y avoir des quotas sur leur API…

Ceux qui ont un module téléinfo sur le compteur ont l'info plus tard, a 20h00. C'est sans doute l'info la plus fiable, même si aucun gag jusque là avec leur API http/json, mais le défaut c'est que si on veut anticiper un gros consommateur (Lave/sèche linge, charger son mixer VE…) a 20h c'est bien tard comparé à 11h!

Enedis a aussi son API qui donne accès dès 10h00, donc encore un peu plus tôt, mais il faut un compte/s'authentifier donc plus pénible à scripter… un peu dommage pour de l'info ouverte que l'on veut diffuser sans entraves.

J'en reste donc à la version EDF.

1) La syntaxe est simple et permet bcp de liberté, car il y a des fois ou cela sert, même si cela peut-être source d'erreurs. Et en python, ne pas avoir d'opérateur ternaire pour un language qui se veut lisible, quand on parle du non sujet des concours de C illisible, c'est ce que j'appelle un sacré manque. Et un manque total de cohérence pour vous.
On pourrait ajouter les solutions cornecul nécessaires en Python pour pallier à l’absence de variables static, quand on fait du procédural… Pénible. Comme a été pénible de se passer 2 décennies d'un switch/case!

2) Non. Mais écrire cela situe tout de suite a qui on a affaire.

3) Oui, mais c'est comparativement rare et les librairies système n'ont aucune chance d'être concernées. Les histoire d'ABI, c'est un simple pb de cohérence du système de build et pas de sources (sauf quand on se lie à des trucs non libres, genre gnu-efi bien obligé de se fader une rupture d'ABI en appelant des services BIOS à coups de wrapper basé sur des listes variables d'arguments, dont tu me diras qu'ils sont aussi source d'erreur car le précompilateur ne peut faire aucune vérification des arguments: OK, mais va dire merci à Intel/Microsoft/AMI/Insyde/Phoenix & co).

4) Et le print et la division et les changements dans les librairies standards… Tu en devance certains à la relecture ou d'un pylint mais il reste combien de merdes tordues que tu vas te prendre, à l'execution, parfois des semaines après car tu passes pas souvent dans la branche de code concernée (et/ou pas facilement testable). Le problème de python, c'est comme souvent les loupés dans la définition initiale et plus un langage est riche plus on en aura.

5) Pour faire la boucle avec le sujet de l'article: S'il n'y avait pas ces problème omniprésents côté python, on n'aurait pas besoin de venv & co!

"Honnêtement, je suis assez surpris que tu puisses trouver le C simple à apprendre"

Il n'y a pourtant qu'a mesurer l'épaisseur d'ouvrages traitant du python à un K&R. Et comme avec tout langage capable de tout faire d'un boot loader à l'OS et son applicatif, forcément on est un peu moins à utiliser trop de dépendances évitables qui à mon sens peuvent vite devenir problématiques avec python (entre autres).

Le C est vraiment simplissime comparé à python niveau syntaxe, ce qui ne veut pas dire que coder un truc (à condition que ce soit possible dans les 2 langages) soit plus rapide/facile en C, surtout si une librairie évite de réinventer la roue. Par contre le lien perdu avec la donnée à traiter peut rendre les choses peu évidentes en python même dans de l'applicatif à mon sens. Puis si l'auteur de la dite librairie abandonne sa maintenance, vogue la (plus souvent les) galère(s) avec un langage qui n'a jamais brillé pour sa compatibilité ascendante (cf passage de python 2 à 3) et ne va donc pas permettre d'éviter des problèmes de moyen terme: On pensait avoir un truc de quelques milliers de lignes python à maintenir reposant sur des librairies maintenues… et on se retrouve à devoir maintenir des dizaines de milliers de lignes de code plus maintenu écrit par d'autres, refaire la partie que l'on utilisait from scratch voir continuer les cochonneries avec un wrapper sur une lib alternative maintenue (pour combien de temps?)…

… ce que sont les coroutines, une implémentation en C avec explications:
https://github.com/Rachid-Koucha/crtn

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!