lym a écrit 148 commentaires

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.

Le meilleur conseil à donner niveau auto-école, c'est d'envoyer vers celles qui font également moto-école même s'il s'agit de passer un permis auto.

La raison est qu'elle vont mettre plus l'accent sur une conduite attentive, voir défensive, que le respect aveugle de limites.

Je ne sais pas si c'est encore le cas, mais lors du permis moto avant la répression stupide que nous connaissons (i.e. on peut continuer à rouler n'importe comment, mais sous les limites, avec des risques en pratique infimes de se le voir reprocher), mon moniteur d'alors me disais "là dessus, les limitations de vitesse on s'en fout tant qu'on n'en est pas au double ; mais si je te vois aborder un carrefour avec visibilité réduite a une vitesse ne permettant pas un arrêt si quelqu'un déboule ou démarrer au vert sans vérifier autre chose que la couleur de ton feu, à un moment je vais te faire faire le tour du pâté de maison et t'attendre au tournant". Et pour jouer au con il était assez doué, cela passait souvent à qq cm, ce qui permet d'amorcer le développement d'un 6ème sens de la prévision de l'errement ou de l'exaction délibérée.

Cette moto-école avait alors les meilleurs résultats au permis de la région… et lors de l'examen, la consigne n'était pas vraiment le respect bête et discipliné des limites. Prendre instantanément plus de 150km/h pour m'extraire des projections d'une file de PL (me retrouvant hors de portée radio de la clio suiveuse) sous un grésil de février sitôt entré sur une voie rapide limitée à 110 n'avait pas vraiment été rédhibitoire, au contraire, avec en prime les remerciements d'être sorti au bon endroit en n'ayant pu entendre qu'un grésillement (la prochaine sortie était un peu loin, dans le doute il valait mieux sortir, quitte à revenir). Celui d'avant, hésitant et gênant un trafic qui lui collait alors dangereusement au cul, surtout à moto, fut par contre invité à revenir plus tard.

Quand on voit le niveau actuel, malgré le délire complet d'imposer 20h minimum et visiblement 40 en moyenne (correspondant aux minimas pour un brevet de pilote d'avion, quand même un peu plus difficile qu'apprendre à se servir d'un cerceau avec une gestion des problèmes/pannes… consistant à s'arrêter sur le bas côté), c'est vraiment à pleurer. Permis auto en 8h avant ces minimas pour ma part… et 12h en moto après, 8h n'ayant été que sur le carnet vu que j'étais largement prêt et qu'un créneau se débloquait sur empêchement d'un candidat inscrit pour l'après-midi même.

Pour conclure, jamais de débilophone au volant, pour ma part. On remarquera d'ailleurs que la remontée de mortalités à partir du milieu des années 90 qui avait mené à la répression actuelle, c'était lors de la démocratisation du GSM avec des opérateurs très attentifs à couvrir les axes routiers, ce qui dans l'industrie télécom nous faisait déjà penser que ce ne serait pas sans conséquence: On aurait alors dû siffler rapidement la fin de la récré en ne ciblant pas forcément le fait de faire n'importe quoi (vis à vis du code), mais surtout de le faire n'importe comment!

On a fait à peu près l'inverse, avec un accent surdimensionné sur les vitesses dont le contrôle s'automatisait facilement, ce qui amène désormais à peu près a l'inverse de ce qui aurait dû être fait: Continuer à faire n'importe comment, à condition de le faire lentement. Forcément, sauf à tendre vers 0km/h (plus de mouvement, plus de choc possible: Aussi imparable qu'absurde!), cette stratégie démontre actuellement ses limites et conforte au passage la théorie de l'homéostasie du risque.

C'est d'ailleurs sans doute car on a de plus en plus de gens tombés dans l'oisiveté permise par les régulateurs, cumulée à la perte de temps inutile qui vous amène moins vite vers le dodo (et le véhicule au parking, au lieu d'encombrer trop longuement les voies au bénéfice de leur saturation moyenne), qu'il y a un effet vase communicant très clair entre baisse des vitesses et hausse des accidents (généralement gravissimes) dus à l'endormissement au volant.

Vraiment le truc que j'utilise le moins possible, dans des circonstance de circulation très très fluide/prévisible, pour satisfaire un besoin limité dans le temps de détendre mon pied droit. A tel point que généralement je dois rechercher qq dizaines de secondes comment cela fonctionne, c'est dire…

Je ne comprends personnellement pas bien comment on peut défendre un dispositif qui va facilement multiplier par 2, en ne comptant que le temps nécessaire à un pieds plus aux commandes donc loin de la pire réalité liée à la distraction supplémentaire éventuellement permise, le temps de réaction… comme positivement lié à la sécurité routière!

Surtout que les petites incertitudes de dispositifs réglés en majorité sur une même vitesse (la limite, personne ne prenant un véhicule personnel pour trop perdre son temps, il y a le train et ses retards en voie de généralisation pour cela) amènent fatalement les un poil plus rapides à rattraper progressivement les un poil plus lents… et à se tasser dans des bouchons roulants que voient très bien ceux qui règlent encore leur allure plus librement.

En réalité, hors cas particuliers ou des limites se justifient (zone densément peuplée ou clairement à risque), le problème n'est-il pas pour certaines personnes d'avoir besoin de limites généralisées pour leur indiquer à quelle vitesse (maximale) rouler? J'aurais tendance à penser que si on a besoin de cela, on ferait mieux de s'abstenir de conduire. Mon côté vieux jeu qui a connu une autre époque sans doute? Ou randonneur qui sait très bien que marcher avec quelqu'un qui a un rythme différent du sien (au dessus comme en dessous d'ailleurs), c'est à la fin de la journée plus de fatigue et de risque de s'être tordu une cheville. Mieux vaut aller chacun à son rythme et faire quelques poses de regroupement/attente.

Le régulateur/limiteur n'est pas un progrès, mais une connerie.

Surtout en considérant d’où vient Rust :o)

Pas le seul surpris, donc! J'espère que cela ne cache pas le début d'une évolution fâcheuse (client lourd-> web app?).

Mais il semble que JS sorte de plus en plus de son cadre de langage dédié au web dynamique côté client (pendant de PHP côté serveur), poussé par la masse de développeurs web? L'autre exemple en tête qui m'attriste c'est pour le protocole domotique ZWave (l'unique mainteneur de la librairie C++ Open-Zwave ayant claqué la porte depuis bientôt 2 ans) et zwavejs ou la situation est pire (faute de devoir déjà intégrer l'interpréteur, comme Thunderbird, donc pb de dépendances complexes ajoutées réglées malpropre à coup de docker vs la simplicité d'une lib compilée dans l'applicatif qui l'utilise).

Surtout que si je suis assez peu confiant dans la capacité de Rust à remplacer le C dans le codage d'OS/modules/boot-loader, pour de l'applicatif réseau en frontal sur internet et en évolution rapide/constante il semble plus justifié de:
-Se lancer dans un langage nouveau/offrant moins de liberté… et objet, qui a toujours posé le pb de la fine maîtrise de la gestion mémoire/allocations,
-Accepter une petite baisse de perf contre la sécurité intrinsèque,
-Ne pas devoir se reposer sur des outils d'analyse de code, coûteux en ressources, si on veut les perf maximales du C ET la sécurité (ce qui se justifie plus pour du code qui va moins changer dans le temps, ce qui est à mon sens la raison pour laquelle Rust ne percera pas là ou les performances sont le critère premier, car elles ont un coût matériel ajouté évitable donc in-fine évité par l'industrie).

Mais la stratégie de Mozilla est parfois étrange.

Rassurant, peut-être, mais pour ma part j'ai vu trop de problèmes passer à travers des tests. A tel point que sur des cartes télécom/industrielles, ils ne sont plus guère passés qu'en prod et plutôt pour déceler des problèmes de fabrication que des boitiers DDR eux-mêmes.

De toutes manières, les problèmes n'ont plus guère de chance de passer à travers le nombre croissant de calibrations avec les générations de DDR. Donc cela va coincer dès l'init dun contrôleur DDR avec aucune chance de pouvoir lancer un memtest.

Et si l'init passe quand même, il y a plus de chance que le démarrage d'un OS complet stresse plus la DDR que dérouler un memtest. Avec soit des erreurs captées par l'ECC si présent… ou le florilège d'exceptions/comportement indéterminé pouvant résulter de problèmes de RAM.

De toutes manières, les temps de tests deviennent désormais prohibitifs avec les tailles de RAM installées. Le dernier test systématique (fait à chaque boot) que j'ai eu à écrire se contentait, de u-boot et exceptions ECC masquées, de faire une passe de lecture du pattern d'init du contrôleur DDR: Donc une passe de simple lecture ASM optimisée pour l'architecture (PowerPC et ses instructions avec incrément de l'adresse automatique) et les tailles de burst/ligne de cache. Pas de comparaison, rien, juste une lecture finale des compteurs d'erreurs ECC pour vérifier qu'il n'y en avait pas eu!

Et ça commencerait à se voir:
https://www.usinenouvelle.com/editorial/alerte-generale-sur-les-penuries-d-ingenieurs.N2043747

Si IBM avait sélectionné les deux zozos proposant le pire OS (DOS: non multitâche/multi-utilisateur…) possible pour l'architecture ouverte de son PC originel en 1981, peut-être étais-ce aussi pour ne pas tuer trop vite leur (B de) business de stations Unix (traversé depuis l'origine, plus de 10 ans avant et une éternité pour l'informatique à l'époque, par la pile réseau) dès qu'Intel sortirait un processeur avec une MMU (ce qui est mieux pour le multitâche) et que qqun se dirait que les slots d'extension pourraient héberger une carte réseau!
Le premier windows avec support réseau (3.11 for workgroups) a sonné l'arrivée de la carte réseau accessible et les débuts de Linux. Le temps que cela prenne vraiment de l'envergure (au tournant de ce siècle), IBM avait gagné 20 ans et les zozos fournisseur du tas de merde étaient faits milliardaires!

Pour des besoins très très simples (notification d'évènements…) d'IPC, ne pas oublier les signaux utilisateur (SIGUSR1 et 2)!

Quand dans ma domotique j'ai voulu faire en sorte que le système d'alarme perso scripté dessus fasse sonner une liste de téléphones mobiles, ayant par ailleurs codé un service (en python) faisant du filtrage d'appel (recyclant un vieux modem 56k usb branché sur le RJ11 de la Livebox alors inutilisé, tous les téléphones utilisant sa base DECT intégrée), j'avais commencé à vouloir utiliser des tubes nommés et même codé un prototype en python.

Puis n'étant pas un programmeur système (mais plutôt très bas niveau en C/ASM) et n'ayant pas anticipé que ce serait un peu "too much", surtout que le côté alarme/domotique était scripté en Lua et la gestion du modem/filtre appel ou serait ajouté le côté liste de numéro à appeler en cas d'alarme était de son côté écrite en Python… En relisant ce dernier je passe sur l'accrochage d'un handler SIGINT tout ce qu'il y a de plus commun… et eurêka, j'ai alors repensé aux signaux utilisateur et tout est devenu bien plus simple!

Côté Lua, un os.execute de 'pkill -10 -f "python.*phoneFilter.py"&'

Côté service Python (nommé phoneFilter.py), juste accrocher le handler gérant la liste d'appels si alarme (sigusr1_handler) sur le SIGUSR1 (signal 10): signal.signal(signal.SIGUSR1, sigusr1_handler)

Et mon machin à filtrer les pubeux (d'un décroché/raccroché immédiat via le modem, sur blacklist de numéros individuels, préfixes d'allocation ARCEP, voir toute plage de numéros alloués à des opérateurs de VoIP s'étant révélés au fil des mois 100% chiants… et si pas en blacklist locale ni connu dans l'annuaire DECT de la Livebox, qui a alors le bon goût de remplir un nom dans le Caller ID, beautifulsoup interroge 2 services en ligne pour récupérer une classification… et l'ajouter a une blacklist locale pour le coup suivant) s'est vu ajouter simplement très simplement une fonctionnalité.

0km/h, plus de mouvement, plus de chocs possibles. Le CQFD de notre "sécurité" routière… qui a commencé à taper sérieusement sur les vitesses à la fin des années 90, alors que les mortalités remontaient.

A cette époque, qu'est-ce qui arrivait de nouveau dans toutes les poches mais aussi derrière bien des volants? Le GSM…

Désormais c'est plus simplement des communications vocales (~0.8g/l d'alcoolémie selon des études d'alors, mais pas faites en France: Canada de mémoire. Soit un niveau délictuel côté bibine mais resté contraventionnel niveau "smart"-phone) mais internet et réseaux sociaux au volant (=> 1g dans chaque poche?), mais on va en remettre un coup sur les vitesses en cumulant avec prétexte de sobriété énergétique, comme en 1973?

Tout ce qui peut justifier la politique facile du radar et sa rentabilité est bienvenu. Les morts, au fond, l'état s'en fout!

"Sous prétexte que l'inscription est quasi-gratuite en fac de droit, de médecine, en prépa ou école d'ingé…"

C'est en effet pire que la situation présente en temps qu'employé, je dirais. On n'est même pas fichu de défalquer quelques trimestres obligatoires pour compenser des études supérieures niveau retraite, alors qu'on ne s'est pas vraiment roulé les pouces.

Il ne faut pas s'étonner que les études supérieures longues attirent moins un de ces jours. Surtout que niveau salaire, le rapport Q/P n'est globalement pas là. Sauf à aller faire x3 de l'autre côté de l'atlantique…

Si cela suffit, c'est que personne n'a encore pensé à descendre tout ce qui démarre en exposant la bannière, qui passe en clair:

~$ telnet localhost 22
Trying ::1…
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1

Oups! Même sur un 443 au lieu du 22, chez moi ils sont hélas plus malins.

On remarque que la controverse tourne toujours autour de Gnome3 et sa customisation… Une litanie depuis 10 ans. Heureusement qu'il y a eu Cinnamon (ou MATE qui tourne encore sur un EeePC901, enfin en Debian n'ayant pas fait de mauvaise graisse et abusé du SchNAPs et installée via NetInstall qui permet de conserver l'essentiel, restons réaliste!).

A lire les news de sortie Ubuntu, je me félicite d'être passé de la copie de plus en plus raturée à l'originale depuis 10 ans. La 10.04 avait été ma dernière Ubuntu…

Copier Windows avec un applicatif embarquant toutes ses dépendances pour éviter d'avoir à gérer proprement les versions n'est clairement pas un bon modèle: Gâchis côté disque, mémoire virtuelle, sont alors inévitables. Parler de Bug N°1 et finir dans les mêmes travers (jusque là logiquement évité dans un modèle de sources ouverts vs compatibilité binaire ou c'est forcément moins simple), ce n'est pas sans ironie.

Le seul cas ou je voie un intérêt à snap et autres, c'est quand la distribution retire un truc: VLC sur la dernière Debian est désormais compilé sans le support RTSP par exemple. Un problème de licence vu par le mainteneur Debian qui ne semble guère poser de pb au projet VLC. Ce protocole étant quasiment généralisé sur les cam IP, difficile de s'en passer.

Mais cela permet aussi de constater que la version snap n'est pas très stable dès qu'on essaie d'ouvrir plusieurs flux en parallèle. Visiblement, VLC n'est sur ce point pas vraiment un cas isolé.

Hors de question de partir sur une distro se basant de manière croissante sur ce genre de modèle pour ma part.

Apple a toujours tout fait pour être un écosystème captif pour l'utilisateur qui y mets le petit doigt. A une époque, on ne pouvait même pas mettre une barrette mémoire de PC pourtant physiquement identique dans un MAC sans se faire jeter au boot! La différence? Juste un format de SPD EEPROM non standard.

Crucial avait fini par en sortir avec des SPD flashées au format Apple pour que les clients arrêtent de se faire prendre pour des pommes à les payer plus du double chez Apple… Mais bon, à un moment, à cumuler sur ce type d'emmerdements on en est rendu à se dire qu'il y a quelques centaines de millions de couillons friqués changeant de débilophone tous les 1 ou 2 ans pour expliquer ce milliard.

Au final, ces quelques centaines de millions vs 8 milliards d'individus sur la planète sont bien un marché de niche :o)

En espérant que ce post-mortem soit au final donné, c'est toujours intéressant et ce serait la moindre des choses vu le temps que tu y a passé: Le bug d'un équipement/FW tombé en marche après un upgrade d'équipement ne m'étonnerait guère chez Orange. Ils semblent avoir vraiment des gros pb de ce côté, il n'y a qu'a avoir tenté d'utiliser leurs SMTP en direct (sans passer par un client lourd codé pour s'adapter à tout!) pour constater combien au hasard des load-balancing on se retrouve sur des trucs qui font tousser les configs lib ssl/tls par défaut de moins de 5 ans.

Pour ma part, avec une LB Play chez Sosh (celle utilisée auparavant en ADSL, qui n'avait jamais posé pb), c'est l'ONT qui coince après les coupures secteur: Il semble y avoir un pb assez fréquent qui fait que cela ne monte alors pas correctement si les deux démarrent ensemble quand l'alimentation est restaurée. Si la LB est démarrée avant l'ONT, cela semble OK à tous les coups (mais je n'ai pas fait une tétra-chiée d'essai non plus), sinon cela merde au moins 3 fois sur 4. Aucune possibilité d'accès à l'interface d'administration LB "pour voir" car le switch côté LAN ne semble en prime pas monter tant que le côté WAN ne monte pas (au démarrage, si on débranche l'ONT après un démarrage OK c'est bon).

C'est un peu emmerdant pour la domotique/alarme qui se retrouve à la merci d'une panne secteur en vacances, si celle-ci dépasse la durée permise par la batterie tampon (double voltage en sortie) alimentant box+ont (en 20V) et PI3/Domoticz (5V USB).

C'est au final très pénible, cet ONT. Prévoir une cage SFP sur les box pas trop anciennes aurait permis une meilleure intégration tant niveau matériel (place prise/esthétique, double alim…) que logicielle (la box a le contrôle du démarrage/configuration du SFP).