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 totof2000 . Évalué à 4. Dernière modification le 13 juin 2021 à 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 Pinaraf . Évalué à 9. Dernière modification le 13 juin 2021 à 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 Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à -2.
Ou mauvaise distribution (c'est un logiciel, on est d'accord), changer de distribution.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Ca doit être Jeedom le problème ...
Posté par Jean-Baptiste Faure . Évalué à 10.
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 :
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ca doit être Jeedom le problème ...
Posté par Pinaraf . Évalué à 5.
Sur un périphérique actif, non.
Et pour que ce périphérique ne soit plus utilisé, avec KMS, c'est vraiment complexe.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ca doit être Jeedom le problème ...
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 2.
À priori certaines mises à jour peuvent même se faire sans redémarrer, avec le Kernel Live Patching. Je n'ai pas testé personnellement, donc je serais d'ailleurs intéressé d'avoir des retours si certains ont eu l'occasion de mettre ça en place.
[^] # Re: Ca doit être Jeedom le problème ...
Posté par xcomcmdr . Évalué à 2. Dernière modification le 14 juin 2021 à 09:25.
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 Flavien . Évalué à -2.
Oh mon dieu, tu viens de blasphémer🤣 Mais où est la police de la morale ?? Qu'on le moinsonne haut et cours 🤡
[^] # Re: Ca doit être Jeedom le problème ...
Posté par claudex . Évalué à 4.
J'ignorais qu'on pouvait utiliser le driver libre sous Windows.
« 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: Ca doit être Jeedom le problème ...
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 14 juin 2021 à 11:11.
Ce n'est pas le cas non plus sous linux.
[^] # Re: Ca doit être Jeedom le problème ...
Posté par xcomcmdr . Évalué à 2.
Ah bon ? Pas de redémarrage du serveur graphique ?
Windows ne le redémarre pas, même quand le pilote plante ou qu'il est désinstallé/mis à jour/installé.
"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 kowalsky . Évalué à 5.
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 Frank-N-Furter . Évalué à 8.
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 Joël . Évalué à 10. Dernière modification le 13 juin 2021 à 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 totof2000 . Évalué à -10. Dernière modification le 13 juin 2021 à 19:55.
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.
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).
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).
Ce sont loin d'être les seuls …
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.
Ca c'est un gros problème.
[^] # Re: Contradiction
Posté par GG (site web personnel) . Évalué à 9.
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.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Contradiction
Posté par totof2000 . Évalué à -5.
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 Graveen . Évalué à 10.
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 barmic 🦦 . Évalué à 5.
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).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Contradiction
Posté par Misc (site web personnel) . Évalué à 3.
Il y a surtout beaucoup plus de logiciels et le ratio packageurs/codeurs diminue. Il y a de plus en plus de languages et d'écosysteme (exemple, rust, go, node, zig, etc) qu'avant, donc plus de libs qui font la même chose dans des écosystémes différents).
Mais la taille des communautés des distributions ne grimpe pas autant, et donc il faut en effet trouver un moyen de transformer les codeurs en packageurs. Et c'est grosso modo ce que permet flatpak, docker, etc.
[^] # Re: Contradiction
Posté par Psychofox (Mastodon) . Évalué à 6.
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 Marc Quinton . Évalué à 3. Dernière modification le 14 juin 2021 à 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 groumly . Évalué à 8.
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 barmic 🦦 . Évalué à 6.
Ou toute bibliothèque qui est chargée par ton processus 1.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Contradiction
Posté par claudex . Évalué à 7.
Il y a
systemctl daemon-reexecpour ç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 barmic 🦦 . Évalué à 5.
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é ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Contradiction
Posté par Misc (site web personnel) . Évalué à 3.
Pas tant que ça en fait, systemd serialise son état, se relance et passe les FDs. Irssi fait pareil.
C'est utilisé à chaque boot pour que le systemd lancé depuis l'initrd passe la main à celui du système. Ensuite, le souci, c'est ce qui va arriver le jour le format de sérialisation va changer, mais je doute que ça arrive de si tôt (et je doute que quelqu'un se dise "je vais prendre un systemd v190 dans l'initrd pour un systeme avec systemd v345").
[^] # Re: Contradiction
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
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 :
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 claudex . Évalué à 5.
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 Benoît Sibaud (site web personnel) . Évalué à 10.
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 groumly . Évalué à 3.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Contradiction
Posté par jyes . Évalué à 3. Dernière modification le 14 juin 2021 à 10:38.
Commentaire supprimé car inutile, je n’avais pas vu celui de Bruno.
[^] # Re: Contradiction
Posté par Michaël (site web personnel) . Évalué à 7.
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 barmic 🦦 . Évalué à 5.
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 ?).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Contradiction
Posté par groumly . Évalué à 8. Dernière modification le 14 juin 2021 à 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 flan (site web personnel) . Évalué à 6.
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 Sytoka Modon (site web personnel) . Évalué à 9. Dernière modification le 14 juin 2021 à 08:10.
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 claudex . Évalué à 5. Dernière modification le 14 juin 2021 à 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 Donk . Évalué à 2.
Ou sinon, il y a checkinstall
[^] # Re: Contradiction
Posté par Michaël (site web personnel) . Évalué à 4.
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 installva 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 Sytoka Modon (site web personnel) . Évalué à 5.
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 barmic 🦦 . Évalué à 10.
Super journal qui dénonce grave, mais c'est quoi Jeedom ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# Mon petit avis sur la question
Posté par flagos . Évalué à 3.
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 claudex . Évalué à 7.
newgrppermet 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 Ronan BARZIC . Évalué à 3.
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 claudex . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 4.
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 totof2000 . Évalué à 1. Dernière modification le 14 juin 2021 à 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 Sytoka Modon (site web personnel) . Évalué à 4.
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 xcomcmdr . Évalué à 2.
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 totof2000 . Évalué à 1.
Pour la dernière partie, ça dépend du gestionnaire graphique et du gestionnaire de terminal.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.