En plus, Dans la vraie vie, les postes bureautique d'entreprises (qui sont la plupart du temps sous windows) sont des postes nominatifs et les gens ne se déloguent que très rarement. (ce qui est d'ailleurs une gageure pour la proximité ;)).
Poste que tu rends lorsque tu quittes la boite.
La plupart des cas où tu as le cas de "vrai" multi-utilisateur, c'est quand tu es sur des pcs partagé (client X léger, poste internet, poste métier spécifiques etc…).
Ensuite oui il doit certainement avoir quelques entreprises qui ont tous leurs postes qui sont en libre service, et aucune place attitré (de façon hiérarchique ou simplement par convention).
Mais même là, tu vas utiliser la capacité multi utilisateur de linux pour avoir plusieurs sessions utilisateur en même temps, et tu ne vas sans doute pas te délogguer pour autant.
Bref, encore une fois, La capacité de pouvoir killer les process d'un utilisateur qui se déloggue est intéressante, mais en inversant la règle du défaut tout simplement.
Et si une banque estime que c'est plus mieux pour la sécurité, ben ils l'activeront tout simplement.
Vu les politiques de mots de passes que ces **** activent, ils sont tout à fait capables d'activer cela si ils estiment que c'est intéressant pour eux.
Dans les autres cas d'utilisation de linux, c'est plutôt contre productif amha.
Je confirme, j'avais lancé une simulation pour un TP de ma fac, et sur mon pc perso c'était pas assez puissant.
Ca a duré une semaine sur les 7 machines dispo de la fac -chacune 4 fois plus puissantes que mon pc- :)
Ben le sysadmin de la fac l'a remarqué et me l'a gentiment laissé, parce que j'avais bien mis la bonne priorité qui permettait à tout le monde de travaillait sans gêner :)
AHAHA mdr.
Non mais sérieusement, tu as lu le cas d'usage de Lennart ?
Pour ceux qui veulent pas lire le lien, je vais résumer :
"imaginez un employée d'une banque (réseau sécurisé pour le sieur) qui lance un spam bot contre son grès (il aurait visité un site "méchant" et paf un exploit dans le browser et paf spambot… [Sur un réseau bureautique "sécurisé" avec controle des ports et proxy…sisi puisque Lennart le dit ].
Ou alors un employé qui a quitté l'entreprise et a laissé un programme tourner. Ben avec systemd le spam bot serait mort dès que l'employé aurait fermé sa session et l'entreprise serait sauvée.".
Je ne sais pas si je dois expliquer en quoi c'est complètement éloigné de la vraie vie, ou juste continuer à rire.
Réussir, dans la même phase, comparer les runlevel à une ouverture/fermeture de session utilisateur, et expliquer, par cet exemple, que les sysadmins "vocaux contre systemd" sont des idiots finis qui ne comprennent rien au fonctionnemnt du runlevel sysinit.
Et juste après expliquer que sysvinit c'est "tout dans inittab"…
Merci, tu m'a bien fait marrer :).
Si toi tu m'explique que je suis un con, je le prends comme un compliment là :)
En cas de vol avéré , sans qu'il y ait une faute du porteur de la carte (noter le code pin collé sur la carte par exemple :D ), les débits non voulus, et effectués avant l'opposition sont censé être remboursés avec une franchise.
Après l'opposition aucun débit n'est censé être possible, donc ils sont intégralement remboursé.
ben pour une banque de particulier, le HNO ça serait plutôt pendant les heures de travail…
Pour une banque d'entreprise , le HNO c'est hors heures de travail.
Je n’ai jamais vu le moindre sysadmin capable de prédire cela avec sysvinit,
Moi j'en ai vu un certains nombres.
c’est même spécifiquement la raison pour laquelle tout sysadmin sain d’esprit rebootait le serveur au moins une fois lorsqu’il modifiait la séquence de démarrage,
Ils sont bizarres les sysadmins que tu as connu.
Parce qu’avec sysvinit, ce n’est pas parce que le script d’init était lancé et renvoyait un code retour OK (voire un bel OK vert à l’écran) que le service était vraiment lancé ou n’avait pas planté après coup.
Avec systemd non plus. C'est le problème de dvp du scrip de démarrage ou du fichier de définition du service.
Et pour avoir fait les deux, les deux se comportent exactement de la même manière. Si tu merde dans ton fichier, ben ton fichier fera de la merde. Systemd n'est pas plus omniscient et ne devine pas que tu as "oneshot" mais en réalité ça voulait dire "fork", tout comme sysinit ne devine pas que quand tu lance /prefix/toto en réalité tu voulais le lancer avec start-stop-daemon ….
Pour le reste des hommes de pailles (vu que tu réponds à des arguments que tu as posé, et que personnes à soulevé, c'est la définition stricto sensus), je te laisse à ton dialogue intérieur.
marrant comment tu as du mal à lire et change les propos des gens…
Il a dit qu'il l'utilisait plus fréquemment avec un parc de 1K qu'avec un parc de 1 machines.
Il n'a pas dit qu'il l'utilisait comme outil de gestion de parc.
Mais bon comme faire des hommes de pailles semblent être le jeu favoris de certains …
Non, ce n'est pas un discours marketing, si tu n'es pas capable d'aller lire la doc pour comprendre que systemd est aussi un gestionnaire de session qui remplacera les daubes genre ksmserver et gnome-session, c'est que tu n'as rien compris…
Mais bien sur: c'est sur que
harmonise, améliore, simplifie et par conséquent fiabilise un gros pan du système Linux.
Sont des arguments techniques d'une profondeur rare.
Et je vois pas pourquoi tu parles de ksmserver ou gnome-session, sachant qu'on en a jamais parlé, et que ce que tu cites ne s'appliquait pas dessus.
Une chose est sur, c'est que systemd ne permet pas à ses défenseurs de lire correctement les posts auxquels ils répondent (et pourtant j'avais fait une belle citation itou itou).
1 chances sur 8 qu'un processus (lequel?) bloque l'extinction pendant 1m30, le délais maximum
1m30 ? petit joueur. Sur des tests au boulot, il attendait un certain service plus de 10 min. Et bien entendu plus la main pour killer ledit process car il a coupé ssh avant et t'as pas de terminal pour pouvoir le faire une fois le process d'extinction lancé.
Je te retourne la question, démarrer tmux/screen via systemd est si problématique que ca?
Oui, tu introduis des workflow différents suivant les machines que tu utilise. En plus ce n'est absolument pas intuitif, et il faut avoir les autorisations de le faire.
Bref, c'est une grosse régression par rapport à lancer simplement ton programme dans un shell, comme on fait depuis plus de 30 ans.
La prochaine solution ça sera quoi "le lancer par une connexion ssh c'est si problématique que ça ?"
C'est quand même génial. Systemd introduit un workaround pour pas avoir à gérer un faux problème.
Conclusion, une tonnes de personnes sur linuxfr propose un workaround pour travailler avec workaround de systemd.
Et ensuite ils viennent demander si c'est "si compliqué de faire comme ça".
Et les mêmes t'expliquent que systemd "fluidifie, harmonise et simplifie" :D
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" …
Ce que je vois c'est surtout le cote moralisateur de vos explications
tu iras dire ça à la gamine qui a perdu sa mère parce que son père l'a frappé bourré et la buté ?
Oui je fais du pathos, mais l'alcool est une drogue dure, et un tueur, à la fois direct (ie la personne concerné , par le biais de multiples maladies, ou simplement par un défaut de réflexion ayant amené les gens à faire des conneries fatales), et indirect (sur les autres, par les actions dudit bourré).
Considéré que l'alcool est anodin c'est vraiment refuser de voir les faits.
Comme son nom l'indique, systemd est bien plus qu'un système d'init. Il harmonise, améliore, simplifie et par conséquent fiabilise un gros pan du système Linux.
On a pas besoin de discours marketing sur un site technique…
Étant donné que son rôle est de gérer les services et tout un tas d'autres choses
Non, pas "tout un tas d'autres choses", non définis, et complètement abstraite.
je ne trouve pas anormal qu'il puisse effectuer des actions sur des processus et service, tout comme le kernel peut le faire.
Tu remarqueras que j'ai jamais dit qu'il ne pouvait pas faire des actions sur les processus. J'ai parlé de ce choix précis et qu'il outrepassait ses fonctions, pour des raisons argumentées…
Et comparer systemd au kernel, c'est pour le lol ?
Quelqu'un s'amuse à comparer le moteur au système de transmission , sous prétexte que c'est dans une voiture ?
Après le problème ici c'est qu'un paramètre par défaut est modifié et casse des programmes.
Surtout que le paramètre par défaut n'a pas lieu d'être, car devrait être activé au cas par cas, en attendant la résolution réelle du problème.
est-ce que l'usage de tmux/screen est un cas d'usage de la majorité des utilisateurs ? Je ne pense pas.
Merci d'arrêter de penser ce qui est bon pour les autres, et de décider tout seul qui constitue la majorité, ou ce que devrais faire ou ne pas faire ladite majoritée.
Le but de linux est que chaque utilisateur puisse faire ce dont il a besoin. Pas de devoir suivre/respecter certaines contraintes parce que WhiteCat ou Lennart ou Tartenpion à décidé que la "majoritée" ne devait pas lancer de commandes en nohup sans d'abord demander à son sysadmin de désactiver des paramètres obscurs dans le système d'init…
La question que pose ce paramètre est : "Est ce que cacher les problèmes et ne pas s'en occuper est une bonne solution ?".
La réponse, pour n'importe qui de technique, et j'espère que linuxfr reste un site où on peut parler technique, serait "non".
Personnellement j'ai utilisé plusieurs fois screen qui était indispensable (Mining Ethereum ou serveur Minecraft par exemple). Mais pour le reste des serveurs que je peux être amené à administrer (dans le cadre de mon taf), j'aime autant que le paramètre par défaut soit le meilleur, et que pour mes cas spécifiques d'utilisation je change le paramètre KillUserProcess à no.
Cool pour toi. Surtout sachant que l'utilisation du terme "meilleur" ne veut rien dire dans ce cas. (Pourquoi un cas d'utilisation serait "meilleur" que l'autre ? )
Et sachant que dans la vrai vie, les utilisateurs n'ont pas tous les pouvoirs root, et peuvent avoir besoin de cette fonctionnalités … de base. Et que si tu en as besoin au cas par cas… Ben faut pas oublier la modif…
Ps : c'est sur qu'on sent que le mining c'est trop dans le cadre du taff… Et que si c'est ta seule utilisation de screen, ça en dit long sur ce que tu peux être à "amené à administrer dans le cadre de ton taff". (Non pas que ce soit bien ou pas, juste ne vient pas expliquer aux gens qui font autre chose que toi comment ils doivent travailler, et pourquoi ton "je modifie les trucs un à un quand je sais que j'en aurais besoin" ne rentre pas dans un cadre un poil plus industriel/sous charge etc…)
?
C'est le taff du kernel de gérer les processus et de les contrôler.
J'avoue que j'ai un peu du mal à comprendre l'humour de la réponse.
Systemd est un système d'initialisation/de démarrage.
Considérer que c'est normal, et même intéressant, qu'il kill les process que l'utilisateur a lancé de son propre chef, car il considère que la session est finie et donc il sait mieux que l'utilisateur ce qui doit être fait est une pente savonneuse.
Je peux le comprendre dans le cadre d'un "workaround" (moi même je me suis déjà amusé à killer les multiples démons de kde une fois un programme utilisant kde étant arrêté)
Mais là on applique un workaround de façon globale, sans aucune réflexion.
Méthode windows quoi "on a un problème, on reboot plutôt qu'essayer de résoudre le problème".
Qu'il le permette, c'est très bien. Qu'il soit mis par défaut, c'est contre productif.
Je suis un fervent partisan du "dans une faute, les torts sont souvent partagés".
Je n'ai donc aucun problème pour que l'on considère que j'ai peut être merdé sur la com, et c'est sans doute une partie de la situation.
Par contre j'ai un problème quand on m'explique que tous les problèmes ne peuvent venir que de moi, et surtout pas de mon interlocuteur, qui utilise pourtant moultes technique de rhétorique pour empêcher toute discussion sereine.
Ensuite je n'ai traité personnes de cons à ma connaissance.
Enfin, je te montrais que même si tu souhaitais le considéré comme une opinion critique, cela n'expliquait en rien son message, et ne le rendait pas plus pertinent.
Bref, quel que soit comment tu veux lire mon message, cela n'expliquait pas son ton et ne rendait pas plus pertinent son message.
le contenu du message était plutôt du 2, alors que j'avais bien compris le sens… (donc finalement aucune de tes conclusions ne s'applique).
2nd degré toussa. On est pas obligé d'être toujours super sérieux non plus.
Mais surtout, je n'introduis pas un ton moralisateur style "y'a des gens qui meurent ailleurs alors TG"
Les impôts servent ? Encore heureux qu'ils servent un minimum. Il y aurait eu une révolution depuis longtemps sinon
Par contre le début de la discussion avec le "TG" implicite sur le fait que non c'est pas "gratuit" (vu que tu veux partir sur du pertinent) malgré le fait que tu paie tes impôts, empêche toute discussion.
Et le fait qu'il assène des affirmations aussi creuse (mais bien plus sérieuse) ne semble gêner personne.
"Sur 1000€ d'impots il y en a 900 qui sont bien utilisés".
Vraiment ? et comment il le sait ? Dans quel domaine?
Bref, à mon sens un message non pertinent car
- ne correspond absolument pas au message auquel il répond (il a pas dit en quoi c'était normal de payer un ticket modérateur en plus de ses impots par exemple)
- un ton inapproprié
- des arguments creux.
Ensuite comme tout le monde, je peux me tromper, avoir mal compris etc…
Par contre je n'utiliserais pas l'argument que "il y en a qui meurent ailleurs alors …"
Dans les deux cas, l'entreprise ne reverse à l'état qu'une portion de ce qu'elles ont touché de la TVA, et pas toute la TVA perçue.
Elles retirent bien la TVA qu'elles ont déjà payé de la TVA qu'elle ont reçu.
Il y a une, et une seule, personne qui paie tout plein pot. C'est le consommateur final, qui lui ne peut "retirer" la partie la TVA sur sa revente d'occasion. Et c'est bien dommage car sa valeur ajoutée est négative (dépréciation du bien), ça voudrais dire que l'on pourrait gagner des sous par la TVA :D
tu as du mal avec les mots dis moi.
Il dit c'est gratos, je dis non, mais c'est pas très cher.
Je met même un smiley pour indiquer le ton léger du message.
Et tu pars à nouveau dans un délire.
Je t'ai fais quelque chose pour que tu veuilles reprendre mes messages et surtout sans être capable du moindre second degré ?
Peut être que si tu me le disais directement, on pourrait repartir sur des bases saines et avoir une discussion calme et intéressantes plutôt que tes piques?
Il y a de l'humanitaire pas qu'en afrique.
Il y en a pour aider les migrants, en europe de l'est (http://www.msf.fr/pays/ukraine), etc…
Ensuite je peux très bien comprendre que l'on ait pas envie de faire de l'humanitaire.
Mais de toute façon, où que l'on ailles, tu auras toujours des pathologies spécifiques. Par exemple statistiquement il y a plus de trauma en montagne l'hiver qu'à la campagne.
[^] # 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é à 7.
En plus, Dans la vraie vie, les postes bureautique d'entreprises (qui sont la plupart du temps sous windows) sont des postes nominatifs et les gens ne se déloguent que très rarement. (ce qui est d'ailleurs une gageure pour la proximité ;)).
Poste que tu rends lorsque tu quittes la boite.
La plupart des cas où tu as le cas de "vrai" multi-utilisateur, c'est quand tu es sur des pcs partagé (client X léger, poste internet, poste métier spécifiques etc…).
Ensuite oui il doit certainement avoir quelques entreprises qui ont tous leurs postes qui sont en libre service, et aucune place attitré (de façon hiérarchique ou simplement par convention).
Mais même là, tu vas utiliser la capacité multi utilisateur de linux pour avoir plusieurs sessions utilisateur en même temps, et tu ne vas sans doute pas te délogguer pour autant.
Bref, encore une fois, La capacité de pouvoir killer les process d'un utilisateur qui se déloggue est intéressante, mais en inversant la règle du défaut tout simplement.
Et si une banque estime que c'est plus mieux pour la sécurité, ben ils l'activeront tout simplement.
Vu les politiques de mots de passes que ces **** activent, ils sont tout à fait capables d'activer cela si ils estiment que c'est intéressant pour eux.
Dans les autres cas d'utilisation de linux, c'est plutôt contre productif amha.
[^] # 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é à 6.
Je confirme, j'avais lancé une simulation pour un TP de ma fac, et sur mon pc perso c'était pas assez puissant.
Ca a duré une semaine sur les 7 machines dispo de la fac -chacune 4 fois plus puissantes que mon pc- :)
Ben le sysadmin de la fac l'a remarqué et me l'a gentiment laissé, parce que j'avais bien mis la bonne priorité qui permettait à tout le monde de travaillait sans gêner :)
[^] # 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é à 4.
AHAHA mdr.
Non mais sérieusement, tu as lu le cas d'usage de Lennart ?
Pour ceux qui veulent pas lire le lien, je vais résumer :
"imaginez un employée d'une banque (réseau sécurisé pour le sieur) qui lance un spam bot contre son grès (il aurait visité un site "méchant" et paf un exploit dans le browser et paf spambot… [Sur un réseau bureautique "sécurisé" avec controle des ports et proxy…sisi puisque Lennart le dit ].
Ou alors un employé qui a quitté l'entreprise et a laissé un programme tourner. Ben avec systemd le spam bot serait mort dès que l'employé aurait fermé sa session et l'entreprise serait sauvée.".
Je ne sais pas si je dois expliquer en quoi c'est complètement éloigné de la vraie vie, ou juste continuer à rire.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par briaeros007 . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 9.
GG. Moi je dis respect.
Réussir, dans la même phase, comparer les runlevel à une ouverture/fermeture de session utilisateur, et expliquer, par cet exemple, que les sysadmins "vocaux contre systemd" sont des idiots finis qui ne comprennent rien au fonctionnemnt du runlevel sysinit.
Et juste après expliquer que sysvinit c'est "tout dans inittab"…
Merci, tu m'a bien fait marrer :).
Si toi tu m'explique que je suis un con, je le prends comme un compliment là :)
[^] # Re: FUD
Posté par briaeros007 . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 3.
tu as les assurances, mais tu as la loi aussi.
En cas de vol avéré , sans qu'il y ait une faute du porteur de la carte (noter le code pin collé sur la carte par exemple :D ), les débits non voulus, et effectués avant l'opposition sont censé être remboursés avec une franchise.
Après l'opposition aucun débit n'est censé être possible, donc ils sont intégralement remboursé.
[^] # Re: FUD
Posté par briaeros007 . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 2.
ben pour une banque de particulier, le HNO ça serait plutôt pendant les heures de travail…
Pour une banque d'entreprise , le HNO c'est hors heures de travail.
[^] # Re: systemd, le nouveau Multics
Posté par briaeros007 . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
tu as choisis quel distrib si ce n'est pas indiscret ?
J'ai la flemme de chercher, mais hammerfs de dragonfly il est enfin prêt ?
Dans mes souvenirs openbsd était quand même plus galère à installer/configurer que freebsd.
[^] # Re: systemd, le nouveau Multics
Posté par briaeros007 . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 5.
Moi j'en ai vu un certains nombres.
Ils sont bizarres les sysadmins que tu as connu.
Avec systemd non plus. C'est le problème de dvp du scrip de démarrage ou du fichier de définition du service.
Et pour avoir fait les deux, les deux se comportent exactement de la même manière. Si tu merde dans ton fichier, ben ton fichier fera de la merde. Systemd n'est pas plus omniscient et ne devine pas que tu as "oneshot" mais en réalité ça voulait dire "fork", tout comme sysinit ne devine pas que quand tu lance /prefix/toto en réalité tu voulais le lancer avec start-stop-daemon ….
Pour le reste des hommes de pailles (vu que tu réponds à des arguments que tu as posé, et que personnes à soulevé, c'est la définition stricto sensus), je te laisse à ton dialogue intérieur.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par briaeros007 . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 7.
marrant comment tu as du mal à lire et change les propos des gens…
Il a dit qu'il l'utilisait plus fréquemment avec un parc de 1K qu'avec un parc de 1 machines.
Il n'a pas dit qu'il l'utilisait comme outil de gestion de parc.
Mais bon comme faire des hommes de pailles semblent être le jeu favoris de certains …
[^] # 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é à 3.
Mais bien sur: c'est sur que
Sont des arguments techniques d'une profondeur rare.
Et je vois pas pourquoi tu parles de ksmserver ou gnome-session, sachant qu'on en a jamais parlé, et que ce que tu cites ne s'appliquait pas dessus.
Une chose est sur, c'est que systemd ne permet pas à ses défenseurs de lire correctement les posts auxquels ils répondent (et pourtant j'avais fait une belle citation itou itou).
[^] # 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é à 7.
1m30 ? petit joueur. Sur des tests au boulot, il attendait un certain service plus de 10 min. Et bien entendu plus la main pour killer ledit process car il a coupé ssh avant et t'as pas de terminal pour pouvoir le faire une fois le process d'extinction lancé.
[^] # 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é à 9.
Oui, tu introduis des workflow différents suivant les machines que tu utilise. En plus ce n'est absolument pas intuitif, et il faut avoir les autorisations de le faire.
Bref, c'est une grosse régression par rapport à lancer simplement ton programme dans un shell, comme on fait depuis plus de 30 ans.
La prochaine solution ça sera quoi "le lancer par une connexion ssh c'est si problématique que ça ?"
C'est quand même génial. Systemd introduit un workaround pour pas avoir à gérer un faux problème.
Conclusion, une tonnes de personnes sur linuxfr propose un workaround pour travailler avec workaround de systemd.
Et ensuite ils viennent demander si c'est "si compliqué de faire comme ça".
Et les mêmes t'expliquent que systemd "fluidifie, harmonise et simplifie" :D
[^] # 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" …
[^] # Re: Du genre troublant
Posté par briaeros007 . En réponse à la dépêche Son et lumière à l’hôtel. Évalué à 9.
tu iras dire ça à la gamine qui a perdu sa mère parce que son père l'a frappé bourré et la buté ?
Oui je fais du pathos, mais l'alcool est une drogue dure, et un tueur, à la fois direct (ie la personne concerné , par le biais de multiples maladies, ou simplement par un défaut de réflexion ayant amené les gens à faire des conneries fatales), et indirect (sur les autres, par les actions dudit bourré).
Considéré que l'alcool est anodin c'est vraiment refuser de voir les faits.
[^] # 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é à 3.
la simplification du process et de l'administration dans toute sa splendeur :'( (pour reprendre les avantages de systemd pronés par whitecat ;) )
[^] # 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é à 3.
On a pas besoin de discours marketing sur un site technique…
Non, pas "tout un tas d'autres choses", non définis, et complètement abstraite.
Tu remarqueras que j'ai jamais dit qu'il ne pouvait pas faire des actions sur les processus. J'ai parlé de ce choix précis et qu'il outrepassait ses fonctions, pour des raisons argumentées…
Et comparer systemd au kernel, c'est pour le lol ?
Quelqu'un s'amuse à comparer le moteur au système de transmission , sous prétexte que c'est dans une voiture ?
Surtout que le paramètre par défaut n'a pas lieu d'être, car devrait être activé au cas par cas, en attendant la résolution réelle du problème.
Merci d'arrêter de penser ce qui est bon pour les autres, et de décider tout seul qui constitue la majorité, ou ce que devrais faire ou ne pas faire ladite majoritée.
Le but de linux est que chaque utilisateur puisse faire ce dont il a besoin. Pas de devoir suivre/respecter certaines contraintes parce que WhiteCat ou Lennart ou Tartenpion à décidé que la "majoritée" ne devait pas lancer de commandes en nohup sans d'abord demander à son sysadmin de désactiver des paramètres obscurs dans le système d'init…
La question que pose ce paramètre est : "Est ce que cacher les problèmes et ne pas s'en occuper est une bonne solution ?".
La réponse, pour n'importe qui de technique, et j'espère que linuxfr reste un site où on peut parler technique, serait "non".
Cool pour toi. Surtout sachant que l'utilisation du terme "meilleur" ne veut rien dire dans ce cas. (Pourquoi un cas d'utilisation serait "meilleur" que l'autre ? )
Et sachant que dans la vrai vie, les utilisateurs n'ont pas tous les pouvoirs root, et peuvent avoir besoin de cette fonctionnalités … de base. Et que si tu en as besoin au cas par cas… Ben faut pas oublier la modif…
Ps : c'est sur qu'on sent que le mining c'est trop dans le cadre du taff… Et que si c'est ta seule utilisation de screen, ça en dit long sur ce que tu peux être à "amené à administrer dans le cadre de ton taff". (Non pas que ce soit bien ou pas, juste ne vient pas expliquer aux gens qui font autre chose que toi comment ils doivent travailler, et pourquoi ton "je modifie les trucs un à un quand je sais que j'en aurais besoin" ne rentre pas dans un cadre un poil plus industriel/sous charge etc…)
[^] # 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é à 5.
?
C'est le taff du kernel de gérer les processus et de les contrôler.
J'avoue que j'ai un peu du mal à comprendre l'humour de la réponse.
Systemd est un système d'initialisation/de démarrage.
Considérer que c'est normal, et même intéressant, qu'il kill les process que l'utilisateur a lancé de son propre chef, car il considère que la session est finie et donc il sait mieux que l'utilisateur ce qui doit être fait est une pente savonneuse.
Je peux le comprendre dans le cadre d'un "workaround" (moi même je me suis déjà amusé à killer les multiples démons de kde une fois un programme utilisant kde étant arrêté)
Mais là on applique un workaround de façon globale, sans aucune réflexion.
Méthode windows quoi "on a un problème, on reboot plutôt qu'essayer de résoudre le problème".
Qu'il le permette, c'est très bien. Qu'il soit mis par défaut, c'est contre productif.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par briaeros007 . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 7.
GG pour le coup de "attend que je t'explique comment te passer de tes outils, tu n'en as pas besoin"…
en tant que sysadmin et perso, j'utilise régulièrement nohup, screen, etc…
[^] # 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é à 3.
Encore heureux que le fonctionnement du programme soit géré par chaque programme …
Et commencer à considérer que le systemd est là pour faire le ménage dans le fonctionnement des programmes utilisateurs est… comment dire…
[^] # Re: .
Posté par briaeros007 . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 3.
Je suis un fervent partisan du "dans une faute, les torts sont souvent partagés".
Je n'ai donc aucun problème pour que l'on considère que j'ai peut être merdé sur la com, et c'est sans doute une partie de la situation.
Par contre j'ai un problème quand on m'explique que tous les problèmes ne peuvent venir que de moi, et surtout pas de mon interlocuteur, qui utilise pourtant moultes technique de rhétorique pour empêcher toute discussion sereine.
Ensuite je n'ai traité personnes de cons à ma connaissance.
Enfin, je te montrais que même si tu souhaitais le considéré comme une opinion critique, cela n'expliquait en rien son message, et ne le rendait pas plus pertinent.
Bref, quel que soit comment tu veux lire mon message, cela n'expliquait pas son ton et ne rendait pas plus pertinent son message.
[^] # Re: .
Posté par briaeros007 . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 1.
le contenu du message était plutôt du 2, alors que j'avais bien compris le sens… (donc finalement aucune de tes conclusions ne s'applique).
2nd degré toussa. On est pas obligé d'être toujours super sérieux non plus.
Mais surtout, je n'introduis pas un ton moralisateur style "y'a des gens qui meurent ailleurs alors TG"
Les impôts servent ? Encore heureux qu'ils servent un minimum. Il y aurait eu une révolution depuis longtemps sinon
Par contre le début de la discussion avec le "TG" implicite sur le fait que non c'est pas "gratuit" (vu que tu veux partir sur du pertinent) malgré le fait que tu paie tes impôts, empêche toute discussion.
Et le fait qu'il assène des affirmations aussi creuse (mais bien plus sérieuse) ne semble gêner personne.
"Sur 1000€ d'impots il y en a 900 qui sont bien utilisés".
Vraiment ? et comment il le sait ? Dans quel domaine?
Bref, à mon sens un message non pertinent car
- ne correspond absolument pas au message auquel il répond (il a pas dit en quoi c'était normal de payer un ticket modérateur en plus de ses impots par exemple)
- un ton inapproprié
- des arguments creux.
Ensuite comme tout le monde, je peux me tromper, avoir mal compris etc…
Par contre je n'utiliserais pas l'argument que "il y en a qui meurent ailleurs alors …"
[^] # Re: Juste milieu ?
Posté par briaeros007 . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 2.
Merci, c'est effectivement plus clair.
Dans les deux cas, l'entreprise ne reverse à l'état qu'une portion de ce qu'elles ont touché de la TVA, et pas toute la TVA perçue.
Elles retirent bien la TVA qu'elles ont déjà payé de la TVA qu'elle ont reçu.
Il y a une, et une seule, personne qui paie tout plein pot. C'est le consommateur final, qui lui ne peut "retirer" la partie la TVA sur sa revente d'occasion. Et c'est bien dommage car sa valeur ajoutée est négative (dépréciation du bien), ça voudrais dire que l'on pourrait gagner des sous par la TVA :D
[^] # Re: .
Posté par briaeros007 . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 0.
tu as du mal avec les mots dis moi.
Il dit c'est gratos, je dis non, mais c'est pas très cher.
Je met même un smiley pour indiquer le ton léger du message.
Et tu pars à nouveau dans un délire.
Je t'ai fais quelque chose pour que tu veuilles reprendre mes messages et surtout sans être capable du moindre second degré ?
Peut être que si tu me le disais directement, on pourrait repartir sur des bases saines et avoir une discussion calme et intéressantes plutôt que tes piques?
[^] # Re: Uber, Lebonrecel, Airbnb : pas de le l'économie collaborative
Posté par briaeros007 . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 2.
Il y a de l'humanitaire pas qu'en afrique.
Il y en a pour aider les migrants, en europe de l'est (http://www.msf.fr/pays/ukraine), etc…
Ensuite je peux très bien comprendre que l'on ait pas envie de faire de l'humanitaire.
Mais de toute façon, où que l'on ailles, tu auras toujours des pathologies spécifiques. Par exemple statistiquement il y a plus de trauma en montagne l'hiver qu'à la campagne.
[^] # Re: Juste milieu ?
Posté par briaeros007 . En réponse au journal Le Bon Coin, Airbnb, Uber : Les prochaines poules aux œufs d'or. Évalué à 2.
Si, et ça me désole tout autant.