LTS veut dire figé dans les versions pour longtemps. Ça veut dire s’assoir sur les nouveautés et c’est là que c’est genant vu la vitesse des évolutions dans la Smart home. Ça reviendrait à acter que jeedom ne bouge plus et se laisser torpiller par home assistant.
Mais bon, toujours pas de nouvelles officielles, pourtant c’est plus l’été
1 « J'aime »
Pourquoi y a t’il débat ?
Ceux qui sont en DIY (RPI avec une debian, VM, ou autre solution peuvent basculer sur une version LTS de debian, il « suffit » de changer les sources des dépôts et la maj des packages de sécurité est assurée jusqu’au 30 Juin 2024
j’ai cru aussi lire que le support du noyau en LTS était aussi assuré par des dev raspberry (mais ca ne me semble pas très clair. En tout cas, la derniere version date du 30/09/22)
Non, c’est le choix de la distribution qui fige les versions pas le fait de passer sur du LTS
Je ne vois pas en quoi basculer son OS sur une version LTS impacterai d’une quelconque manière le développement. Il n’y a aucun discours indiquant qu’il n’y aura pas de support de Bulleyes. Le seul discours que j’entends est plutôt de dire que ce n’est pas prêt … Du coup, le LTS prend tout son sens. dans l’attente que ce soit prêt, on bascule en LTS pour 6mois, 1 an, 18mois …
Pour les utilisateurs de box jeedom. Le discours est encore plus clair me semble-t’il, c’est Jeedom qui valide et gère les MAJ de sécurité. Si on décide de déléguer la gestion à un prestataire, on doit aussi lui faire confiance su la bonne gestion qu’il en fera, sinon, on bascule sur du DIY.
Question un brin provocatrice : La sécurtié étant assurée sur Buster jusqu’en Juin 2024, Quelle est la fonctionnalité présente dans bulleye et indispensable pour notre domotique qui n’est pas présente dans Buster
1 « J'aime »
Toi tu n’es pas dev et tu ne dois pas lire sur le forum tous les problèmes que ça engendre. Des dépendances python qui marchaient il y a un an et qui sont maintenant KO par exemple.
En LTS, tu n’es plus supporté par l’équipe officielle debian. C’est une sous équipe qui s’occupe de fournir le minimum. Car l’équipe principale est déjà assez a la suite. Donc bof.
LTS c’est fait pour les grosses structures qui veulent le maximum de stabilité. Pas une PME française qui est sur un marché concurrentiel avec un market ouvert aux tiers.
Si zigbee2mqtt a besoin d’une version de paquet non dispo en LTS tu t’assois dessus, pareil pour toutes libs. Et pendant que tu restes inerte faut pas t’étonner de voir tes clients de barrer ailleurs comme HA dont le plus gros argument est la vitesse d’évolution
À défendre le fait de pas bouger, j’ai l’impression de voir tellement de clients français qui gère leur IT comme nos administrations ‹ ne pas bouger a moins d’un être obliger ›
1 « J'aime »
Assez d’accord avec @lunarok sur le LTS, si je me base sur du Microsoft, dans les certifications ils conseillent les versions LTSC pour des automates (qui mettrait du Windows dans des automates ?!) et pour les distributeurs automatiques…
Par contre moins d’accord pour par exemple nodejs…
1 « J'aime »
Les packages python sont gérés par le gestionnaire pip, pas par debian. Idem pour NodeJS qui a son propre gestionnaire (npm ? ou yarn ? il y en a plusieurs) Et les erreurs de dépendances sont plutôt dues à des multiples plugins qui n’utilisent pas la même version, ou bien des versions incompatibles entre elles (j’ai eu le cas sur mon plugin)
Ce qui est effectivement lié à Debian c’est les versions de ces langages: python 2 ou 3 ? PHP 7.x ou PHP 8 ? Pour le coup, PHP7.3 est déjà en fin de vie alors que Buster est encore maintenue, on voit bien la limite du système… Que se passe-t-il si une faille critique est découverte dans PHP, corrigée en PHP7.4 et supérieur mais pas en PHP7.3 ?
On parle de sécurité. on ne parle par d’évolution fonctionnelle
je ne dis pas que le LTS est la solution qu’il faut rester sur bulleyes jusqu’au 30 Juin 2024.
Je dis juste qu’il n’est pas utile, en l’état, de gesticuler avec des arguments de cyberguerre et de faire peur à tout le monde, et que moyennant la confiance que l’on fait à l’équipe Jeedom ou la mise en place des bons paramétrages sur son debian, il n’y a pas de crainte à avoir (en tout cas pas sur ce sujet de rester sur Buster).
Dans ce cas ils doivent faire du rétro portage du patch, avec les inconvénients et les délais que c aentraine (la base de test étant moins importante)
Et ça garde des limites, log4j l’a bien montré dernièrement.
Bonjour,
Je me permets de déterrer cet ancien post, afin de savoir s’il y a du nouveau en ce qui concerne la prise en charge officielle de Debian 11 (Bullseye).
En jetant un œil sur le site de Jeedom, j’ai trouvé 2 informations qui semblent porter à confusion.
Ici https://doc.jeedom.com/fr_FR/compatibility/ , il est indiqué :
Jeedom ne prend en charge que Debian Stretch (non recommandé),Buster (en fin de vie) et Bullseye (recommandé). Toute autre version (Wheezy, Jessie…) ou distribution (Ubuntu…) n’est pas prise en charge par Jeedom.
Ici https://doc.jeedom.com/fr_FR/installation/rpi, il est indiqué :
Debian 10 (Buster) est la distribution officiellement supportée.
Alors, qu’en est-il exactement ?
Debian 11 (Bullseye) est-elle dorénavant officiellement supportée par Jeedom ?
Les principaux plugins (zwave, Blea, Zigbee, etc.) sont-ils bien fonctionnels sous Debian 11 (Bullseye) ?
A ce propos, l’un d’entre vous pourrait-il me fournir le lien URL relatif à la page où se trouve la liste des plugins fonctionnels/non fonctionnels sous Bullseye évoquée par Poumi au début de ce post ?
Je n’arrive pas à remettre la main dessus…
Merci d’avance pour votre retour.
Bonjour
La Doc est bonne pour tout système x86-64 c’est debian 11 (testé) par contre pour rpi nous n’avons testé que debian 10 mais je pense que ça marche dans soucis en debian 11.
1 « J'aime »
Parfait !
Merci.
2 « J'aime »
Bonjour,
Attention, nous sommes plusieurs à être passés sur Bullseye sur divers machines x86-64 et Raspberry.
Et nous avons remarqués une forte augmentation de la charge CPU avec le processus bluepy-helper
=> Cela n’est pas visible tout de suite, il part en couilles avec les jours.
@Idaho947 / @Madcow / @titof2375 et moi aussi, ont réalisés des tests. Le test d’Idaho947 met en évidence un cas particulier.
- sans antenne, pas d’augmentation de la charge
- dès qu’il y a une antenne, la charge monte petit à petit. Même sur une machine dédié à être une antenne BLEA.
Le redémarrage du demon mets en évidence le problème.
On a faire des retours sur ce fil :
Compatibilité Bullseye - Plugins / Protocole domotique - Communauté Jeedom
Le projet bluepy semble abandonné. Est-il possible : au rythme que Jeedom le désir, de revoir ce plugin pour une compatibilité avec Bullseye et envisager le remplacement de bluepy ?
Merci.
3 « J'aime »
Bonjour
Malheureusement ce plugin n’est pas de moi donc je peux pas te dire, le mieux serait d’ouvrir un ticket a jeedom sas.
1 « J'aime »
Bonjour,
Blea m’a bien rendu service en son temps, mais le temps passe et depuis que je suis passé en Bullseye je l’ai supprimé et remplacé par un esp. Pour ma part pas en Omg mais en Tasmota car j’avais déjà des tasmota en exploitation. Et depuis tout fonctionne très bien, j’ai même pu remettre en service des thermomètres qui ne fonctionnaient pas en Blea et reconnu immédiatement maintenant. Plus aucun souci.
1 « J'aime »
Je pense c’est le mieux les esp marche très bien en bluetooth et si c’est juste pour faire de la localisation les nouveaux bidule Shelly avec script sont top. En poussant on pourrait même connaître la pièce dans laquelle est la personne.
1 « J'aime »
Sauf que la clef sena a une portée bien plus grande et fiable que les esp.
Pour blea des tickets ont déjà été ouverts et sans réponse.
4 « J'aime »
Ben relance je peux rien te dire d’autre malheureusement j’ai aucun moyen de t’aider malheureusement sur ce plugin.
Je sais bien…
Cela ressemble à ce dont on parlait ici : Problème d'utilisation CPU avec bluepy-he+.
Et apparemment solutionné dans dans le code : Correctly process invalid IO by fsaris · Pull Request #446 · IanHarvey/bluepy · GitHub.
Mais j’imagine que le packet n’est pas mis à jour.
Depuis j’ai aussi abandonné BLEA. J’utilise soit des scripts que j’appelle chacun leur tour (mais il ne faut pas avoir trop d’équipements, c’est bien moins pratique), soit des ESP avec Open MQTT Gateway ou Tasmota.
1 « J'aime »
Je suis parti sur une solution antenne ESP sous Tasmota + antenne Linux/MacOs (blea2mqtt : lib noble), qui fonctionnent au final en passerelle. (une ébauche de plugin est en beta actuellement)
5 « J'aime »
Bonjour,
Je n’ai pas de ESP chez moi, alors je suis passé aussi en MQTT avec Theengs Gateway sous docker avec clef bluetooth :
1 « J'aime »