Ben d'un autre côté, laisser le problème apparent depuis toujours n'a pousse personne à corriger le problème.
Confère mon interrogation sur la définition dudit problème, plus bas
Alors du coup, tu proposes quoi pour corriger ce problème?
Prendre ses petites mains et allez ouvrir un bug-report, voir même de coder pour réparer ce problème qui te gênes dans les logiciel que tu utilises?
La on a solution qui résoud le problème correctement dans 99% des cas, avec un cas spécial simple pour les 2 programmes qui posent problème (screen et tmux).
Ah j'aime les stats sur linuxfr. On a une solution qui résoud un "problème*" (mais non quantifié par personne. Pourquoi 99% ? Pour moi c'est <0.01%. J'ai plus de sous process utilisé par systemd que par mon environnement graphique lorsque je le quitte...)
On a des cas avérés que cette solution ne convient pour certaines utilisations (et ça casse bien plus que "2 programmes", ça casse tout programme lancé par l'utilisateur dans une session systemd, et qui est amené à vivre après cette session.)
Et on vient nous expliquer, à grand renfort de chiffres complètement farfelus que c'est "la solution qu'il nous faut".
Pour revenir sur le "problèmes". Qui dit que c'est un problème ?
C'était peut être voulu de ne pas lancer à chaque début de session tel ou tel programme ? (je ne connais pas l'archi de kde)
Lorsqu'on utilise nohup, c'est pour des programmes n'ayant pas prévu de se détacher et de fonctionner un peu comme des daemons, et qui ne capturent pas le signal HUP.
Si kded et consors ne meurent pas, peut être qu'ils ont été prévu de fonctionner comme ça et que c'était voulu "by design" ?
Tu parles d'ailleurs des workstations, c'est rare qu'elles soient utilisés par 10 000 personnes différentes. Donc le plus souvent c'est pas vraiment un problème si les logiciels ont été prévus pour et sont bien codés.
Pour les stations libres services (style école, facs, ...) là je peux croire qu'ils veulent limiter l'impact, mais pourquoi prendre kde ou gnome dans ce cas ? :P
Et ça reste un mode de fonctionnement moins standard quand même. Donc utiliser ce mode de fonctionnement pour expliquer que "la solution qu'il nous faut" ...
[^] # Re: Bug ferme chez tmux
Posté par briaeros007 . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.
Confère mon interrogation sur la définition dudit problème, plus bas
Prendre ses petites mains et allez ouvrir un bug-report, voir même de coder pour réparer ce problème qui te gênes dans les logiciel que tu utilises?
Ah j'aime les stats sur linuxfr. On a une solution qui résoud un "problème*" (mais non quantifié par personne. Pourquoi 99% ? Pour moi c'est <0.01%. J'ai plus de sous process utilisé par systemd que par mon environnement graphique lorsque je le quitte...)
On a des cas avérés que cette solution ne convient pour certaines utilisations (et ça casse bien plus que "2 programmes", ça casse tout programme lancé par l'utilisateur dans une session systemd, et qui est amené à vivre après cette session.)
Et on vient nous expliquer, à grand renfort de chiffres complètement farfelus que c'est "la solution qu'il nous faut".
Pour revenir sur le "problèmes". Qui dit que c'est un problème ?
C'était peut être voulu de ne pas lancer à chaque début de session tel ou tel programme ? (je ne connais pas l'archi de kde)
Lorsqu'on utilise nohup, c'est pour des programmes n'ayant pas prévu de se détacher et de fonctionner un peu comme des daemons, et qui ne capturent pas le signal HUP.
Si kded et consors ne meurent pas, peut être qu'ils ont été prévu de fonctionner comme ça et que c'était voulu "by design" ?
Tu parles d'ailleurs des workstations, c'est rare qu'elles soient utilisés par 10 000 personnes différentes. Donc le plus souvent c'est pas vraiment un problème si les logiciels ont été prévus pour et sont bien codés.
Pour les stations libres services (style école, facs, ...) là je peux croire qu'ils veulent limiter l'impact, mais pourquoi prendre kde ou gnome dans ce cas ? :P
Et ça reste un mode de fonctionnement moins standard quand même. Donc utiliser ce mode de fonctionnement pour expliquer que "la solution qu'il nous faut" ...