gnumdk a écrit 7486 commentaires

C'est qui Sulman, un mec qui compte chez FreeBSD? :p

Là ou je bossais avant, tu l'aurais eu dans le *** parce que ISO 14001 oblige, on coupait les PC le soir ;)

"l'enorme majorite des utilisateurs de linux" n'utilise ni trap ni nohup…

Parceque le bebe de monsieur systemd (pulseaudio) est une bouse ambulante qui laisse des process alors que tu
te delogues

Jamais vu ce comportement… T'es sur que tu ne confonds pas avec le pulseaudio lancé par GDM? (ça c'est débile par contre et je n'ai toujours pas compris pourquoi GNOME laisse comme ça)

Ah ok, moi je fais ça pour faire un nohup:
trap "" 1
firefox &

C'est quoi la différence?

Arrête, si tu lui dis que FreeBSD va avoir son launchd/systemd like, il va faire un malaise le mec ;)

Bon, non, il lui reste les autres BSD, ouf!

Oui, enfin pour le coup Canonical était là avant hein…

Cela n'est pas étonnant que vous vouliez résoudre ces problèmes si vous ne connaissez pas l'existence de
solution qui fonctionnent…

Non, je ne connaissais pas la notion de "controling terminal" mais par contre maintenant que je sais, j'ai cherché à savoir comment connaître le "controling terminal" d'un process… C'est finalement ce qu'affiche la commande suivante:

$ ps
PID TTY TIME CMD
17587 pts/7 00:00:00 bash
17590 pts/7 00:00:00 ps

Mon controling terminal est "pts/7"

Par contre, quand je fais un ps sur mon user, je vois que plein d'applications n'ont pas de "controling terminal" (?)… Donc en gros, ça veut dire quoi, que chaque application doit gérer ça dans son code?

Du coup même si on n'a pas systemd sur sa machine, on est touché par les modifications.

C'est du logiciel libre, les devs de ces programmes font ce qu'ils veulent… Si les modification ne plaisent pas, il suffit de forker…

Pas chez moi…

Je t'en parle parce que les devs KDE et GNOME veulent remplacer ksmserver et gnome-session par systemd.

Sur des tests au boulot, il attendait un certain service plus de 10 min.

C'est vrai, c'était tellement mieux avant, quand l'init était incapable de tuer le service et restait bloquer comme un con…

donne des consignes pour ne plus être compatible posix

setsid() fait parti de POSIX mais es tu vraiment sur que ne pas l'utiliser rend un programme non POSIX? C'est pas une interface système POSIX?

Ben si tu sais écrire un OS, tu le fais, bien à la mode Unix années 70 et tu arrêtes de faire chier ton monde non?

s/leur temps à écrire\/modifier\/comprendre des scripts d'init compliqués/faire de la merde/g

Ca tombe bien, on ne parle pas d'SSH ici…

C'est moins moche mais c'est toujours moche…

Reste à savoir pourquoi je n'ai pas eu d'avertissement sur la modification arbitraire de
/etc/systemd/logind.conf

Parce que dpkg ne met un warning que si le fichier a été modifié PAR L'ADMINISTRATEUR?

Les non barbus utilisent systemd et ne savent pas ce que c'est…

On a pas besoin de discours marketing sur un site technique…

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…

Hmm, tu gères un parc de 1000 machines avec nohup??? Tu me fais peur… Tu sais que y'a des outils adaptés pour la gestion de parc?

Seafile est ton sauveur…

A mon taf, une grosse structure (14 275 personnes), depuis l'arrivée de systemd avec Jessie, j'ai pu voir que les devs sont très contents de cette avancée, idem pour les intégrateurs… Ils peuvent facilement faire des "services" en quelques lignes alors qu'il auraient bien été incapables de faire la même chose avec sysVinit et encore mois proprement…

Donc pour moi, si ce projet survie, il restera anonyme…

Ca va faire du bien à KDE vu le nombre de fois que j'ai vu des enfants de kdeinit vivre après une fin de session…

Où tu as lu que cela concerne ta session SSH? C'est pas systemd (pour l'instant en tout cas) qui gère cela.

Testé sous ArchLinux, ça tue screen uniquement sur une session locale, pas via SSH…