Journal Linux et libre : retour 20 ans en arrière ?

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
-43
13
juin
2021

Je viens d'installer Jeedom sur Linux Ubuntu.

Passons le fait que j'ai du me battre avec la mise à jour MySQL => AppArmor (parce que lorsqu'on désinstalle MySQL sous Ubuntu, le gestionnaire de package ne défait pas correctement ce qu'il a fait à l'origine) - pour l'image du libre déjà c'est pas génial.

Le problème c'est qu'à la fin de l'installation de Jeedom j'ai le message suivant :


Installation finie. Un redémarrage devrait être effectué


Nan mais … sérieux. On est en 2021, et on est pas capable d'avoir un outil qui s'installe sans nécessiter de redémarrage ?

Oui je sais, c'est certainement le processus d'installation de Jeedom qui est pourri. PAr contre je constate que ce ne sont pas les seuls, de plus en plus de softs font pareil (alors qu'il n'y a pas de raison de le faire).

Je pestais il y a 20 ans parce qu'une installation sous Windows95 ou windows98 pouvait redemander pas mal de reboot, et je suis passé sous Linux, qui semblait plus robuste et qu ne nécessitait pas qu'on le relance dès qu'on faisait un truc dessus, mais là j'ai l'impression de revenir 20 ans en arrière …

  • # Ca doit être Jeedom le problème ...

    Posté par  . Évalué à 4 (+10/-7). Dernière modification le 13/06/21 à 17:22.

    Quand j'essaie d'ouvrir un compte sur leur market, je ne le peux pas … Je suis censé cocher une case que je ne vois pas.

    En plus je trouve qu'ils demandent beaucoup d'informations et chose qui m'a agacé", ils indiquent qu'ils utilisent des cookies, et que si on continue suir leur site c'est que ça ne nous dértange pas. Je ne pense pas que ce soit très RGPD …

    Ils sont plus ou moins "encensés" de partout mais perso, quand je vois ça, poiur un outil qui est censé gérer des trucs qui potentiellement lui donne accès à plein d'éléments de la vie privée (caméra, etc …), le niveau de confiance redescend un max.

    • [^] # Re: Ca doit être Jeedom le problème ...

      Posté par  . Évalué à 9 (+8/-1). Dernière modification le 13/06/21 à 17:51.

      Le seul cas où un redémarrage peut être vraiment requis, c'est un changement de pilote, et encore, uniquement sur un périphérique actif (passage du pilote libre au propriétaire pour une carte nVidia par exemple). Ou un changement de système de démarrage, mais installer une application ne doit pas impacter ça…
      Donc… Mauvais logiciel, changer le logiciel.

      • [^] # Re: Ca doit être Jeedom le problème ...

        Posté par  (site Web personnel) . Évalué à -2 (+2/-6).

        Ou mauvaise distribution (c'est un logiciel, on est d'accord), changer de distribution.

        Designeuse de masques pour sphéniscidés.

        • [^] # Re: Ca doit être Jeedom le problème ...

          Posté par  . Évalué à 10 (+12/-0).

          Pourquoi accuser la distribution alors que le logiciel n'est pas dans les dépôts ? La distribution, quelle qu'elle soit, n'y est pour rien si le script d'installation réclame un redémarrage :

          echo "/!\ IMPORTANT /!\ Le mot de passe root MySQL est ${MYSQL_ROOT_PASSWD}"
          echo "Installation finie. Un redémarrage devrait être effectué"

      • [^] # Re: Ca doit être Jeedom le problème ...

        Posté par  . Évalué à 5 (+6/-3).

        On peut changer un pilote (recharger un module) sans redémarrer. Le seul cas où un redémarrage est nécessaire c'est après une mise à jour du noyau.

      • [^] # Re: Ca doit être Jeedom le problème ...

        Posté par  . Évalué à 2 (+6/-6). Dernière modification le 14/06/21 à 09:25.

        Le seul cas où un redémarrage peut être vraiment requis, c'est un changement de pilote, et encore, uniquement sur un périphérique actif (passage du pilote libre au propriétaire pour une carte nVidia par exemple).

        Eh ben c'est dommage, car ce n'est plus le cas sous Windows depuis 2009. Va falloir se mettre à niveau sous Linux.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Ca doit être Jeedom le problème ...

        Posté par  . Évalué à 4 (+3/-1).

        Il peut y avoir des cas ou un reboot n'est pas nécessaire mais ce serait trop compliqué à expliquer pour un utilisateur non-technique.

        Rien qu'un truc tout bête comme changer une variable, tu ne vas pas faire un long message expliquant comment "recharger" toutes les consoles de tous tes utilisateurs, selon chaque distro, etc…

        • [^] # Re: Ca doit être Jeedom le problème ...

          Posté par  . Évalué à 7 (+5/-0).

          Il y a très longtemps je faisais du support sur du Windows, et très rapidement j'ai laissé tomber l'idée d'expliquer aux gens comment, lancer le task manager, chercher dans la liste des tâches nmlcndmsclls.exe, le sélectionner, cliquer sur terminer la tâche, confirmer. C'était plus rapide de redémarrer le pc. Au début, j'expliquais ça et pourquoi on le faisait, et rapidement j'ai compris que la plupart des gens n'en ont rien a fiche de ce genre de détails, et ce qu'ils veulent c'est pouvoir se remettre le plus vite possible a ce qu'ils font, qui il se trouve nécessite l'usage d'un ordinateur.

          Depending on the time of day, the French go either way.

  • # Contradiction

    Posté par  . Évalué à 10 (+25/-0). Dernière modification le 13/06/21 à 19:11.

    Ton message est contradictoire. D'abord tu dis "Oui je sais, c'est certainement le processus d'installation de Jeedom qui est pourri", et ensuite tu conclus par "je suis passé sous Linux, qui semblait plus robuste et qui ne nécessitait pas qu'on le relance dès qu'on faisait un truc dessus".

    Si tu sais que le processus d'installation de Jeedom est foireux, pourquoi ça ne te suffit pas?

    D'autant plus que leur processus d'installation (d’après ce que je comprends) n'est même pas intégré a Ubuntu ; si encore, c’était un logiciel que tu installais par les paquets officiels, t'aurais peut-être des raisons de te plaindre, mais là, j'arrive pas à voir…

    Linux est solide, et pour la plupart des distributions, le gestionnaire de paquets l'est aussi. A part pour des màjs du noyau ou des pilotes de périphériques, y'a pas besoin de rebooter. Pour les màjs de l'environnement graphique, y'a juste besoin de delogger puis se relogger (ce qui redémarre seulement l'environnement graphique). Pareil pour quand des nouveaux groupes sont ajoutés, où il faut quitter sa session et se relogger.

    En bref, comme tu l'as justement dit au début, c'est le processus d'install de Jeedom qui est pourri. Donc va te plaindre auprès d'eux.

    Expliquer que Linux était mieux avant n'a vraiment rien à voir.

    • [^] # Re: Contradiction

      Posté par  . Évalué à -10 (+2/-13). Dernière modification le 13/06/21 à 19:55.

      Ton message est contradictoire. D'abord tu dis "Oui je sais, c'est certainement le processus d'installation de Jeedom qui est pourri", et ensuite tu conclus par "je suis passé sous Linux, qui semblait plus robuste et qui ne nécessitait pas qu'on le relance dès qu'on faisait un truc dessus".

      Disons que c'était un gros reproche qu'on faisait à Windows à une époque pour promouvoir Linux. Sur Windows, ça a changé dans le bon sens. Sous Linux et le libre, on voit le contraire se passer.

      Linux est solide, et pour la plupart des distributions, le gestionnaire de paquets l'est aussi.

      Bof … Je dirais de moins en moins (le gestionnaire de paquet en lui même n'est pas forcément à blamer, mais ce qui l'utilisent ne sont pas forcément des plus rigoureux).

      D'autant plus que leur processus d'installation (d’après ce que je comprends) n'est même pas intégré a Ubuntu ; si encore, c’était un logiciel que tu installais par les paquets officiels, t'aurais peut-être des raisons de te plaindre, mais là, j'arrive pas à voir…

      Là ce n'est qu'un exemple, mais c'est une terdance que je constate de plus en plus sur les logiciels dit libres (j'ai içnstallé Ruby 3 via NVM, et il me disait que dans certains cas il fallait rebooter. Le problème est que certains gestionnaires de bureau ne sont pas capables de voir dynamiquement les changements de groupe d'un utilisateur, ou certaies modifications de variables d'environnement sans que tu te déconnectes/reconnectes à une nouvelle session, ce qui pour moi équivaut plus ou moins à un redémarrage).

      En bref, comme tu l'as justement dit au début, c'est le processus d'install de Jeedom qui est pourri. Donc va te plaindre auprès d'eux.

      Ce sont loin d'être les seuls …

      Expliquer que Linux était mieux avant n'a vraiment rien à voir.

      Ca a compêtement à voir : ce n'est pas tant le système qui pose problème mais la mentalité des gens qui développent dessus … C'était une mentalité qu'on trouvait essentiellement dans le développement des logiciels non libres qui s'étend un peu partout.

      Pareil pour quand des nouveaux groupes sont ajoutés, où il faut quitter sa session et se relogger.

      Ca c'est un gros problème.

      • [^] # Re: Contradiction

        Posté par  . Évalué à 8 (+6/-0).

        Là ce n'est qu'un exemple, mais c'est une terdance que je constate de plus en plus sur les logiciels dit libres (j'ai içnstallé Ruby 3 via NVM, et il me disait que dans certains cas il fallait rebooter.

        Si tu installes un paquet autrement que via le gestionnaire de paquet, comme ça se fait sous Windows, ne vient pas te plaindre que la suite se passe comme sous Windows.

        Si tu installes un paquet via le gestionnaire de paquet, tout se passe bien, parce que tout peut bien être pris en charge proprement par les différents mécanismes d'installations par le gestionnaire et celui qui à fait le paquet.

        • [^] # Re: Contradiction

          Posté par  . Évalué à -4 (+3/-8).

          Si tu installes un paquet autrement que via le gestionnaire de paquet, comme ça se fait sous Windows, ne vient pas te plaindre que la suite se passe comme sous Windows.

          J'évite au max de le faire, mais là je n'avais pas vraiment le choix, je n'ai pas vu de paquet jeedom sur ubuntu 20.04. D'ailleurs j'ai l'impression que les paquets tels que nous les connaissons vont disparaître au profit d'images docker, d'images VMs (telles que dispo pour Jeedom), ou d'autre trucs style flatpack ou snap. Pour être honnete ce n'est pas forcément pour me plaire (en tout cas pour le moment, car ces solutions réponde à certains besoins - le premier que je vois étant de court-circuiter les systèmes de package pour entre autre installer du pas libre sans se prendre la tête - enb en créant d'autres tels que la capacité disque utilisée par exemple mais d'autres journaux ont étalés ces inconvé"nients mieux que je le ferais).
          ).

          • [^] # Re: Contradiction

            Posté par  . Évalué à 10 (+11/-0).

            Ouais bon ca va, tu as 1 exemple de truc foireux et on a l'impression que tu es passé de initrc à systemd….

            Excessif, peu ouvert à la discussion, post à chaud quoi.

            En plus tu sais d'où ça vient… Redescend ! :D

          • [^] # Re: Contradiction

            Posté par  . Évalué à 4 (+5/-3).

            D'ailleurs j'ai l'impression que les paquets tels que nous les connaissons vont disparaître au profit d'images docker, d'images VMs (telles que dispo pour Jeedom), ou d'autre trucs style flatpack ou snap.

            Entre la création des paquets rpm/deb et aujourd'hui, le monde a un chouia changé. L'écosystème dans le quel ils tournent a beaucoup évolué, les usages ont drastiquement changé, les modèles d'attaques n'ont plus rien à voir, les sécurités disponibles non plus par ailleurs il y a une foule de tentative de manière de produire un paquet. Que des gestionnaires qui ont émergé il y a plus de 20 ans et qui n'ont évolués qu'à la marge depuis ne soient plus à la page de ce qui se fait n'est pas bien surprenant (et non les petits gestionnaires de paquets qui ont émergé en prenant en compte qu'une partie extrêmement limité du spectre de ce que l'on demande à un gestionnaire de paquets ne sont que des jouets qui n'ont un intérêt que parce que les gros du secteurs n'évoluent pas).

          • [^] # Re: Contradiction

            Posté par  . Évalué à 5 (+2/-0).

            T'es conscient que la construction d'image pour des containers se fait en partie via les gestionnaires de paquets embarqués dans les images de base ?

          • [^] # Re: Contradiction

            Posté par  . Évalué à 2 (+0/-0). Dernière modification le 14/06/21 à 17:22.

            voici de quoi te satisfaire : c'est basé sur Debian et Docker. Ca me semble intéressant en tout cas !

    • [^] # Re: Contradiction

      Posté par  . Évalué à 7 (+5/-0).

      A part pour des màjs du noyau ou des pilotes de périphériques, y'a pas besoin de rebooter.

      Et quand libssl, la libc ou quelconque autre librairie système un tant soit peu critique est mise à jour, comment tu t’assures que tous les processus existant qui en dépendent ont effectivement prit en compte le changement? Tu redémarres tous les processus un par un après avoir construit l’arbre de dépendances?

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: Contradiction

        Posté par  . Évalué à 5 (+3/-0).

        Ou toute bibliothèque qui est chargée par ton processus 1.

        • [^] # Re: Contradiction

          Posté par  . Évalué à 6 (+3/-0).

          Il y a systemctl daemon-reexec pour ça.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Contradiction

            Posté par  . Évalué à 3 (+1/-0).

            Merci je ne connaissais pas et je ne pensais pas que ce soit possible. Ça doit être un sacré enfer à implémenter. Après c'est la solution pour systemd qui bien que massivement utilisé n'est pas le seul utilisé ;)

          • [^] # Re: Contradiction

            Posté par  (site Web personnel) . Évalué à 6 (+3/-0).

            En théorie oui, en pratique c'est plus compliqué tout de même :

            Sur une Debian/Ubuntu, needrestart gère ça et fait un peu plus :

            /etc/needrestart/restart.d/dbus.service
            /etc/needrestart/restart.d/systemd-manager
            

            Le premier touche à NetworkManager.service systemd-logind.service systemd-journald.service display-manager.service dbus.service et systemd-manager.

            Le second fait effectivement juste un systemctl daemon-reexec.

            Pas de chance, sur une Ubuntu 18.04 LTS par exemple, ce qui est mis à jour le plus souvent, c'est le noyau, dbus et systemd, à vue de nez.

            • [^] # Re: Contradiction

              Posté par  . Évalué à 4 (+1/-0).

              Je ne comprends pas ta réponse. On parle du PID 1, c'est bien ce que fait daemon-reexec, tout ce que cite n'est pas le PID 1 (et peut être redémarré autrement).

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Contradiction

                Posté par  (site Web personnel) . Évalué à 9 (+6/-0).

                Le fil parlait de librairie système un tant soit peu critique, ce qui amène assez vite à dbus et systemd en général (et pas juste le PID 1). La théorie c'est "redémarrer les services et le PID 1 suffit en dehors des besoins du noyau lui-même", la pratique c'est "entre les bugs de systemd, l'adhérence de systemd à des API noyau et les dépendances de services, c'est parfois plus compliqué, même si needrestart aide pas mal" (et ça dépend des versions et des distributions en plus, mais si on peut espérer que ça va s'améliorer).

                • [^] # Re: Contradiction

                  Posté par  . Évalué à 2 (+0/-0).

                  Le fil parlait de librairie système un tant soit peu critique, ce qui amène assez vite à dbus et systemd en général (et pas juste le PID 1).

                  Mon point, c'est surtout que ça mène très vite a tout. Un environnement de bureau va très vite avoir des dépendances sur un peu tout.
                  Techniquement, oui, tu peux t'en sortir dans certain cas précis sans faire un reboot a proprement parler. Maintenant, redémarrer 80% des process qui tournent sur la machine (avec en prime le risque d'en rater un ou deux), y compris l'environnement de bureau (et donc envoyer ta session au tas), ou faire un reboot, j'ai du mal a voir la différence fondamentale.

                  Le problème du redémarrage, c'est pas tant le redémarrage en soit que l'interruption de service, le besoin de sauvegarder le travail en cours etc.

                  Alors après, oui, on peut faire une mise a jour sans rebooter, tant qu'on accepte que la mise a jour ne soit prise en compte que de manière partielle. Je suis pas convaincu que ça soit particulièrement utile.

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: Contradiction

        Posté par  . Évalué à 4 (+2/-0).

        Needrestart est ton ami.

      • [^] # Re: Contradiction

        Posté par  (site Web personnel) . Évalué à 2 (+1/-1). Dernière modification le 14/06/21 à 10:38.

        Commentaire supprimé car inutile, je n’avais pas vu celui de Bruno.

    • [^] # Re: Contradiction

      Posté par  . Évalué à 6 (+4/-0).

      Expliquer que Linux était mieux avant n'a vraiment rien à voir.

      En tout cas un truc qui est toujours aussi pourri qu'avant sous Linux c'est la distribution de logiciels. Manifestement c'est tellement compliqué de préparer ses paquets que des gens (Jeedom) décident d'utiliser une méthode qui est simple pour eux… (c'est loin d'être les seuls!)

      • [^] # Re: Contradiction

        Posté par  . Évalué à 3 (+1/-0).

        En tout cas un truc qui est toujours aussi pourri qu'avant sous Linux c'est la distribution de logiciels.

        J'ai pas l'impression que ce soit folichon sur desktop. Quand je vois que des utilisateurs MacOS passent par docker ou quand je me souviens (mais c'était il y a longtemps ça a peut être bien évolué) windows où tu as une série de SDK C++ d'installé en dépendance et pas vraiment de gestion des mises à jours centralisée. Pour ce dernier je ne sais pas si dans la pratique tout le monde s'est mis à massivement passer par le store (il n'y avait pas des limitations genre avoir une application universal ?).

        • [^] # Re: Contradiction

          Posté par  . Évalué à 6 (+4/-0). Dernière modification le 14/06/21 à 01:24.

          Docker sous Mac est pas particulièrement utilisé, sorti des développeurs qui s’en servent pour leur boulot.

          Le principal problème que docker résous pour des applis desktop Linux existe pas trop sous macOS. A savoir, le système est fiable, compat binaire, c’est facile de prédire ce qui va ou ne va pas être installé, c’est trivial d’embarquer des librairies tierces dans son bundle (où quoi que ce soit d’autre d’ailleurs), et y’a des apis systèmes faciles à utiliser pour stocker de la config etc à des endroits predictibles.
          J’imagine que c’est similaire sous Windows de nos jours.

          Alors, certes, il faut coder un peu pour le système, mais c’est pas particulièrement compliqué, clairement beaucoup moins que de se fader des paquets pour plusieurs versions de plusieurs distro.

          Perso, le seul cas d’utilisation que je lui ait trouvé, c’est pour pouvoir déployer une instance Jenkins principale toute configurée de a à z pour nos builds en moins de 5 minutes montre en main, et pour pouvoir mettre à jour Jenkins sans risquer de foutre en l’air les builds. Pas vraiment une utilisation desktop.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Contradiction

          Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

          Sous macOS, les gens utilisent Docker… pour développer les conteneurs qui seront mis en prod sur du Docker, certainement sur du Linux.
          Et si tu lis le journal, son auteur utilise Docker parce que c'est la techno qui est utilisée par les autres développeurs.

          Jusqu'à présent, je n'ai jamais vu la moindre appli desktop faite en Docker sur macOS.

      • [^] # Re: Contradiction

        Posté par  (site Web personnel) . Évalué à 7 (+5/-0). Dernière modification le 14/06/21 à 08:10.

        En tout cas un truc qui est toujours aussi pourri qu'avant sous Linux c'est la distribution de logiciels.

        Tu as essayé de faire un paquet Debian ?

        En gros, tu fais une archive tar compressé avec gzip qui comporte tous tes fichiers et tu mets cela dans une archive ar. Tu fais ton fichier de control dans lequel tu décris ce qu'il y a dans le paquet (ben il faut quand même lui donner un petit nom et une version à ce paquet). Ce fichier, tu le mets aussi dans l'archive ar.

        Et c'est tout…

        Bref, faire un paquet Debian pas super nickel prend 1h la première fois puis 5 min ensuite et c'est même carrément automatique par CI la semaine suivante. J'ai un script bash de quelques lignes qui fait cela tout bien. Ne pas faire de paquet, c'est juste ne pas être intéressé par la question…

        • [^] # Re: Contradiction

          Posté par  . Évalué à 5 (+2/-0). Dernière modification le 14/06/21 à 08:59.

          Je suis d'accord que faire un paquet pas super nickel est très rapide. Par contre, ce n'est pas du tout sur ce genre d'information qu'on tombe quand on cherche comment faire un paquet. Et quelqu'un qui regarde vite fait sans trop connaître va voir que ça va lui prendre deux jours d'avoir un truc fonctionnel.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Contradiction

          Posté par  . Évalué à 2 (+0/-0).

          Ou sinon, il y a checkinstall

        • [^] # Re: Contradiction

          Posté par  . Évalué à 5 (+3/-0).

          Tu as essayé de faire un paquet Debian ?

          Oui j'ai déjà fait ça plusieurs fois et écrits des paquets pour Debian & Ubuntu et essayer de distribuer un logiciel sous Linux c'est beaucoup de travail, même si on s'en tient à ces deux distributions. Et ce, même en tenant compte de tout le travail qu'a fait Ubuntu sur Launchpad, un site qui fait de la livraison continue sur des paquets Ubuntu (Debian). En fait mainteneur de paquet sous Linux ça demande des compétences spécifiques pour chaque distribution – outillage, flux de travail, etc…. et même si on a un soft qui s'installe par un classique ./configure ; make; make install va prendre des plombes de créer un paquet conforme et peut-être des mois de l'intégrer à la distribution. Je n'ose pas imaginer ce que ça donne dans le cas complexe. En comparaison FreeBSD et MacPorts par exemple sont des exemples de simplicité: quand on a écrit son soft, on prend la doc officielle et en une heure on a fini, une petite matinée si on n'est pas très réveillé, et si on veut distribuer ses softs en parallèle du repo principal, c'est très facile à faire (un jeu d'enfant à côté de créer son propre repo Debian par exemple).

          Faire un paquet à la oualou pour Linux est certainement possible mais si on veut distribuer son logiciel au maximum de personnes (je suppose que c'est ce qui intéresse les gens qui font JeeDom) c'est moins efficace que de faire un script shell à l'arrache qui va tant bien que mal essayer d'installer logiciel sur n'importe quelle distribution.

          Il y a plusieurs signes tangibles qui apportent de l'eau à mon moulin. Le premier est que ce point de vue n'est pas super original et que je ne fais que répéter ce que dit Linus Torvalds (il dit ça très souvent, il y a peut-être des références plus courtes :-) ). Le second est que toutes les communautés organisées autour d'un langage, que ce soit JavaScript, Python, OCaml, Lisp, Ruby, Go, Perl, Java, etc. ont toutes leur propre système de distribution de logiciel, pour partager facilement les nouveautés avec les autres: c'est bien que la façon “normale” ne les satisfait pas et probablement parceque c'est trop de travail quand on écrit un soft de l'empaqueter proprement pour toutes les distributions principales… Enfin le dernier point c'est que le cas de JeeDom n'est pas isolé: TeXlive, Mathematica, Jupyter, et plusieurs autres gros composants logiciels ne font pas des paquets pour toutes les distributions: le projet offre une méthode d'installation plus ou moins propre mais laisse à d'autre le travail d'empaqueter.

          • [^] # Re: Contradiction

            Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

            Il n'y a pas 50 solutions… Soit tu distribue en central avec des applications signées, soit tu distribues dans les HOME. Autre commutateur, soit tu mutualises les bibliothèques, soit tu embarques tout.

            La mode est de tout embarquer.

            Pourquoi ?

            Parce que la rétro compatibilité, tout le monde s'en fout de nos jours… Du coup, c'est un vrai bordel, on casse les API à chaque version, on numérote n'importe comment…

            Si les langages avaient été au bout de leur concept, elles auraient fait une installation compatible avec les .deb et les .rpm. La bonne question est pourquoi on ne peut facilement transformer un paquet d'un langage en un paquet de distribution ?

            Heureusement, le noyau Linux et la glibc sont très stable coté API.

  • # Dénonce grave

    Posté par  . Évalué à 10 (+20/-0).

    Super journal qui dénonce grave, mais c'est quoi Jeedom ?

  • # Regardons la cible...

    Posté par  (site Web personnel) . Évalué à 10 (+20/-0).

    Jeedom est un logiciel de domotique. Pas trop mal foutu (je sais, je l'utilise :p).

    L'idée est qu'il soit installable par un bidouilleur (le strict minimum quand on fait son installation domotique soi-même), pas qu'il faille une certification administrateur système linux pour son installation.

    Alors, oui, il y a bien des moyens, en général, de se passer d'un redémarrage. Mais cela reste un moyen simple pour s'assurer que tout fonctionne, et surtout, qu'il n'y aura pas de souci au prochain démarrage !

    Car oui, même si c'est censé tourner h24, les coupures de courant, ça existe, et si 6 mois après l'installation ça ne fonctionne pas tu fais quoi ? Tu cherches, et tu ne vas pas penser que c'est l'installation le problème car cela tourne depuis 6 mois sans problème.

    Si tu fais ton installation, que tu redémarres, et que tu vois que ça ne marche pas, tu te dis qu'il y a peut être un souci avec ton installation.

    Dans la mesure où Jeedom n'est pas intégré sous forme de paquet, c'est leur responsabilité de gérer le lancement au démarrage, et non celui des distributions. Donc oui, le redémarrage ne me parait pas déconnant, loin de là. Surtout quand on veut être sur qu'il redémarre sans aucun soucis.

    Et dans le cas de Jeedom, le problème classique est un problème de gestion de droit pour l'accès à des périphériques comme une clé Zigbee. Ca marche très bien quand tu le lances toi-même en root, mais pas au démarrage car l'utilisateur n'a "pas les droits suffisants".

  • # Mon petit avis sur la question

    Posté par  . Évalué à 3 (+2/-1).

    J'avais bosse un temps sur un soft de domotique, et j'avais rencontre le souci, je suppose qu'ils ont le meme.

    https://github.com/jeedom/core/blob/alpha/install/install.sh#L315

    On peut voir le script donne le group dialout a l'utilisateur qui va tourner le serveur, pour pouvoir communiquer sur le port serie avec le vrai monde. Pour que ce vraiment effectif, il fallait ensuite redémarrer. J'avais pas trouve d'astuces a l'epoque pour recharger les permissions a chaud.

    Du coup, je parierai bien une bière que le souci est lie a ca :-)

    Sinon perso moi ce qui me choque, c'est le script qui parle directement en francais. On est tout de meme en 2021, on est au courant qu'il y a un monde apres les frontieres :-)

    • [^] # Re: Mon petit avis sur la question

      Posté par  . Évalué à 6 (+3/-0).

      J'avais pas trouve d'astuces a l'epoque pour recharger les permissions a chaud.

      newgrp permet d'ajouter un groupe à un utilisateur.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Mon petit avis sur la question

        Posté par  . Évalué à 3 (+2/-0).

        Corrigez-moi si je me trompe, mais newgrp ne va être valide que pour le terminal dans laquelle la commande va être exécutée (et les nouveaux terminaux). Pas pour les terminaux déjà ouverts

        • [^] # Re: Mon petit avis sur la question

          Posté par  . Évalué à 3 (+0/-0).

          Tout à fait.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Mon petit avis sur la question

          Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

          Heureusement. C'est la base des processus UNIX. On ne touche pas aux processus voisins ou parent !

          Le véritable soucis est que la plupart des applications graphiques actuelles fonctionnent en variable globale. Ce n'est pas une avancée je trouve…

          Bilan, c'est impossible de changer de groupe primaire sur une gestionnaire de fichier graphique type Nautilus… On a beaucoup perdu avec cette généralisation des variables globales.

          • [^] # Re: Mon petit avis sur la question

            Posté par  . Évalué à 1 (+0/-0). Dernière modification le 14/06/21 à 22:04.

            Yep, et certains gestionnaires de terminaux te lancent un shell avec les options héritées de l'environnement de bureau qui n'ont pas pris en conmpte tes modifs. µDans ce cas il faut lancer un sous-shell (bash avec une option dont je me souviens plus pour qu'il aille tout relire si c'est du bash).

            • [^] # Re: Mon petit avis sur la question

              Posté par  (site Web personnel) . Évalué à 4 (+3/-1).

              Même le bureau ne dérive plus des variables du script X de lancement… Du coup, on ne peut plus facilement positionner des variables en ajoutant du script Bash bien placé.

              Tous les machins à la systemd sont à la fois bien dans un sens et mène dans un autre vers bien trop de variable globale (dbus…) et plus moyen de scripter son système, ce qui faisait la force des UNIX.

              • [^] # Re: Mon petit avis sur la question

                Posté par  . Évalué à 2 (+0/-0).

                Il suffit d'apprendre la nouvelle manière de faire ?
                Et les scripts sont toujours là ?

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Mon petit avis sur la question

          Posté par  . Évalué à 1 (+0/-0).

          Corrigez-moi si je me trompe, mais newgrp ne va être valide que pour le terminal dans laquelle la commande va être exécutée (et les nouveaux terminaux).

          Pour la dernière partie, ça dépend du gestionnaire graphique et du gestionnaire de terminal.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.