Si on souhaite héberger des serveurs ou des services à la maison, l'ipv6 apporte le maximum de simplicité puisque chaque machine physique ou virtuelle aura la possibilité d'avoir une ip publique distincte et avec tous les ports disponibles.
Alors qu'en ipv4, on ne dispose en général que d'une seule ip publique, il faut donc faire du NAT, il faut aussi ajouter et configurer un reverse proxy SNI, et il y a souvent de nombreux ports qui sont réservés par la box de l'opérateur.
L'ipv4 reste pratique dans un vpn ou un réseau local, mais ça s'arrête là.
Les personnes qui n'aiment pas l'ipv6, c'est parce qu'elles continuent de penser que l'ipv6 est seulement une extension de l'ipv4.
ipv4 et ipv6 sont deux protocoles DIFFÉRENTS, il faut arrêter de vouloir calquer l'un sur lautre.
Si j'ai quelque chose à mettre à jour, je dois le faire dans le profil de référence, en executant firefox -P par exemple.
Parce que effectivement, toute modification du firefox isolé n'est que temporaire et n'affecte pas le profil de référence.
Chez moi, si je lance firefox sans argument ça va me lancer le firefox avec le profil de référence
je tiens à avoir mes préferences, mes mots de passes et mes marques pages disponibles, ainsi que les extensions comme ublock-origin.
si je créé des profils, d'une part ça oblige à des manipulations supplémentaires, mais je dois aussi importer mes mots de passes, mes préférences et mes marques pages… ensuite je dois détruire ce nouveau profil pour ne pas encombrer l'espace de stockage.
ma solution permet de bénéficier de tous les avantages d'un nouveau profil, mais qui est une copie temporaire de mon profil de référence.
je considère que si le moteur rencontre trop de résistance, c'est que la glace est en train de prendre, et qu'il vaut mieux cesser de le faire tourner au risque de déteriorer le matériel
en fait, un moteur à l'arrêt est en court circuit, ce qui est une méthode pour détecter son immobilisation.
pour les moteur pas à pas, je ne sais pas ce qu'il en est.
J'utilise Matrix, et donc les clients qui vont avec:
- riot (application sur android)
- https://riot.im/app (dans un vrai navigateur web, en html5+webrtc)
- revolt (application qui est en réalité un navigateur web)
ça supporte le son et la video, (y compris depuis le navigateur web)
ça permet d'avoir le contenu synchronisé depuis tous les clients (ce que xmpp/jabber ne faisait pas bien).
avec la possibilité d'être connecté depuis plusieurs clients et périphériques en même temps (ce que xmpp/jabber faisait déjà très bien)
et il existe aussi le client android "riot" qu'on trouve dans les dépots f-droid
avec riot, tu peux avoir des communication audio/vidéo, et tu peux aussi ajouter des canaux irc en plus des salons matrix.
il existe d'autres passerelles pour d'autres réseaux sociaux.
et si tu ne veux pas que riot scanne ton carnet d'adresse de ton telephone, tu lui refuse ça.
(tandis que "Signal" va se substituer aux sms, et va scanner ton carnet d'adresse sans te le demander, et il va annoncer à tous tes contacts que tu utilise "signal", du point de vue vie privée c'est inacceptable)
Minecraft est libre?
En plus, minecraft est fait en Java, le truc immonde qui bouffe un maximum de cpu pour afficher de la 3D (à moins que Java sache utiliser l'accélération matérielle, ce qui serait enfin une bonne chose)
Il existe Minetest qui est libre.
Minetest utilise OpenGL, un peu de CPU et une bonne carte graphique suffit.
hello de firefox semble limité à deux utilisateurs.
pour ma part, j'utilise vroom.im qui ne semble pas limité à seulement deux utilisateurs en même temps.
l'autre avantage de vroom.im, c'est que l'auteur documente toute la procedure pour qu'on puisse l'installer sur son propre serveur, ce qui n'est pas le cas de hello de firefox.
vroom.im n'a pas besoin de javascript externe pour fonctionner.
Sauf que justement, l'avantage de http://vroom.im c'est de ne pas dépendre de javascript externe, et c'est un avantage considérable.
Je l'ai testé, ça fonctionne bien, mais ça bouffe pas mal de cpu pour les vidéos. (mon téléphone chauffe terriblement avec vroom.im)
Pour le son, avec l'ordi c'est bon, mais avec le téléphone c'est un peu saccadé, je n'ai pas vraiment trouvé pourquoi.
Dans l'ensemble, vroom.im est vraiment pas mal, il y a même un pad intégré.
à base de WebRTC, avec vidéo, micro, partage d'écran, prise de note collaboratives,
En fait, du moment que ça utilise webrtc ET html5, il est possible d'y retrouver ces fonctionnalités, que ce soit avec Hello de firefox, ou http://opentokrtc.com, et plein d'autres encore.
dans tous les cas, on se dit, "cool, et si je m'installais mon propre serveur?" mais en fait, ces technologies innovantes ne sont pas facile à installer…
Personnellement j'ai une préférence pour Hello de firefox, mais à condition de ne pas avoir installé firefox ESR
Mais Hello de firefox veut absolument partager ma navigation web, alors que je veux simplement partager ma webcam et mon microphone, avec la possibilité de désactiver l'un ou l'autre à la demande.
Tous ces truc en WebRTC et Html5 sont bourrés de javascript, qui fait tu ne sais pas trop quoi…y compris Hello de Firefox.
Je ne parlais pas de remote, mais bien de ssh en localhost.
Je suis dans ma session graphique, j'ouvre un terminal
Dans ce terminal je lance un ssh err404@localhost
Une fois connecté par ssh en localhost je lance un tmux dedans.
Je referme la fenêtre de mon terminal, le ssh est coupé bien entendu, et le tmux est censé lui survivre car de toute façon je n'ai pas fermé ma session graphique.
Je ferme ma session graphique, que ce soit en douceur ou brutalement (j'ai testé les deux).
Avec le réglage de systemd à 'yes': le tmux est tué (et rien n'apparait dans syslog)
Avec le réglage de systemd à 'no': le tmux survit. (ce qui est le comportement attendu depuis 30 ans si j'ai bien cmpris)
Le comportement de systemd est le même si j'ouvre un terminal dans ma session graphique et que je lance tmux dans ce terminal.
Je ne m'en suis pas pris plein la gueule, du moins pas plus que systemd, et j'ai trouvé une solution au problème. (et je me suis bien marré toute la journée du vendredi, rassures-toi :D )
Reste à savoir pourquoi je n'ai pas eu d'avertissement sur la modification arbitraire de /etc/systemd/logind.conf (les avis sont mitigés la dessus)
j'ai passé la priorité de debconf à un niveau inférieur, on verra bien.
D'après ce que j'ai pu lire dans un autre commentaire, le fait que les packageurs de systemd pour debian soient revenus au comportement habituel qui consiste à ne pas tuer les processus daemonisés des utilisateurs à la fin de la session, prouve que j'avais raison de me fâcher. ou du moins que nous partageons le même point de vue.
L'important c'est de pouvoir intervenir librement dans les réglages, sans avoir à subir des généralités au prétexte que tout le monde fait dans un sens ou dans l'autre.
Je comprend tout à fait que les besoins (ou les envies) des uns diffères des autres.
Ah ah, surement pas.
Quand je tombe sur ce genre de question, je fais particulièrement attention.
Mais je te remercie d'avoir soulevé ce point.
Après vérification de mon Debconf, le niveau de priorité est réglé à 'high' ('high' is for rather important questions), donc pour les questions importantes, et, vu comment les devs de Systemd considèrent les utilisateurs, je n'étais pas près de voir s'afficher de question…
Je passe à 'medium', et j'espère bien avoir plus de retour sur les réglages par defaut de systemd la prochaine fois.
Ce sont des choses qui arrivent quand on cherche une solution le soir avant d'aller se coucher, si j'avais vu cette autre solution dès le début, j'aurais plutôt fais un journal qui donne directement cette solution plutôt que d'en arriver à quémander une solution.
Je n'avais pas lu le texte assez en détail, de la même façon que je ne lis pas systématiquement les changelog de tous les paquets que je mets à jour sur mon ordi perso parce que la plupart des autres paquets indiquent quand il y a un gros changement dans le comportement habituel.
j'avais d'autres réglages dans le fichier /etc/systemd/logind.conf (ceux qui concernent le comportement quand je rabat l'écran du portable) ils ont étés écrasés sans prévenir,
D'habitude il y a dpkg qui me dit que le fichier de conf qui sera installée est différent de celui qui est présent, et à ce moment, j'ai le choix entre installer la version du paquet, garder ma version, ou voir la différence etc.
Mais avec systemd, je n'ai pas avertissement, tout est écrasé silencieusement.
Effectivement il semble possible de modifier le comportement par defaut de systemd sans être obligé de recompiler ce dernier.
le fichier à modifier se trouve dans /etc/systemd/logind.conf
et il faut remplacer la ligne #KillUserProcesses=yes par KillUserProcesses=no
sans oublier de la decommenter bien entendu.
Vous croyez que c'est possible de demander à systemd de prende en compte le changement sans rebooter l'ordinateur?
but additional steps are necessary to allow intentionally long-running processes to survive logout
tiens, si ça se trouve la modification apportée ne suffira pas…
changer d'init?
alors tu va m'expliquer comment je peux me passer de dbus sur mon ordinateur de bureau.
parce que j'utilise Mate Desktop, et Mate dépend de dbus qui dépend de systemd…
sur mes serveur je n'utilise pas systemd parce que j'ai d'autres system d'init, mais sur mes serveurs je n'utilise pas d'environnement de bureau non plus…
Ce n'est pas un bug de Tmux, mais ça n'empêche pas que ça apparaissent dans leur rapport de bug.
Le rapport de bug est fermé justement parce que ça ne concerne pas tmux, mais bien systemd et leur choix arbitraire à la va-vite.
Vu sur le Web, mais je ne sais plus où:
My concern is that we have a little function, daemon(), that does a simple little procedure to make a daemon that has worked basically unchanged across multiple platforms for maybe, what, 30 years? Now to do the same thing we need to add 150 lines of new, Linux-only code AND a library dependency.
En gros, il existe une petite fonction, Daemon(), qui fonctionne de façon inchangée depuis 30 ans, simplement et sur des multiples plateformes. alors que pour obtenir la même chose aujourd'hui, il faudrai ajouter 150 lignes de code spécifique à Linux ET ajouter une dépendance à une bibliothèque.
Je crois que je vais laisser tomber Debian (que j'utilise depuis 1997 mais avec de moins en moins de satisfaction) et je vais aller voir du coté de Gentoo qui laisse plus de choix à l'utilisateur final. (je vais passer un peu de temps à compiler…)
c'est dommage, j'aimais bien le contrat social de Debian. je reviendrais peut-être à Debian un jour, il y a assez de distributions GNU/Linux pour avoir encore un peu de liberté.
# ipv6 et auto-hébergement
Posté par err404 (site web personnel) . En réponse au journal IPv6, cela en valait-il la peine ?. Évalué à 5. Dernière modification le 18 avril 2024 à 09:30.
Si on souhaite héberger des serveurs ou des services à la maison, l'ipv6 apporte le maximum de simplicité puisque chaque machine physique ou virtuelle aura la possibilité d'avoir une ip publique distincte et avec tous les ports disponibles.
Alors qu'en ipv4, on ne dispose en général que d'une seule ip publique, il faut donc faire du NAT, il faut aussi ajouter et configurer un reverse proxy SNI, et il y a souvent de nombreux ports qui sont réservés par la box de l'opérateur.
L'ipv4 reste pratique dans un vpn ou un réseau local, mais ça s'arrête là.
Les personnes qui n'aiment pas l'ipv6, c'est parce qu'elles continuent de penser que l'ipv6 est seulement une extension de l'ipv4.
ipv4 et ipv6 sont deux protocoles DIFFÉRENTS, il faut arrêter de vouloir calquer l'un sur lautre.
[^] # Re: Ha ?
Posté par err404 (site web personnel) . En réponse au journal firefox, nouvelle fenêtre dans une session isolée. Évalué à 3.
Si j'ai quelque chose à mettre à jour, je dois le faire dans le profil de référence, en executant
firefox -P
par exemple.Parce que effectivement, toute modification du firefox isolé n'est que temporaire et n'affecte pas le profil de référence.
Chez moi, si je lance firefox sans argument ça va me lancer le firefox avec le profil de référence
[^] # Re: Ha ?
Posté par err404 (site web personnel) . En réponse au journal firefox, nouvelle fenêtre dans une session isolée. Évalué à 2.
je tiens à avoir mes préferences, mes mots de passes et mes marques pages disponibles, ainsi que les extensions comme ublock-origin.
si je créé des profils, d'une part ça oblige à des manipulations supplémentaires, mais je dois aussi importer mes mots de passes, mes préférences et mes marques pages… ensuite je dois détruire ce nouveau profil pour ne pas encombrer l'espace de stockage.
ma solution permet de bénéficier de tous les avantages d'un nouveau profil, mais qui est une copie temporaire de mon profil de référence.
# un moteur à l'arrêt est en court circuit
Posté par err404 (site web personnel) . En réponse au message Remplacer le mécanisme d'entrainement d'une sorbetière.. Évalué à 2.
en fait, un moteur à l'arrêt est en court circuit, ce qui est une méthode pour détecter son immobilisation.
pour les moteur pas à pas, je ne sais pas ce qu'il en est.
# matrix, avec les clients riot, revolt etc.
Posté par err404 (site web personnel) . En réponse au journal La fin de Google+. Évalué à 3.
J'utilise Matrix, et donc les clients qui vont avec:
- riot (application sur android)
- https://riot.im/app (dans un vrai navigateur web, en html5+webrtc)
- revolt (application qui est en réalité un navigateur web)
ça supporte le son et la video, (y compris depuis le navigateur web)
ça permet d'avoir le contenu synchronisé depuis tous les clients (ce que xmpp/jabber ne faisait pas bien).
avec la possibilité d'être connecté depuis plusieurs clients et périphériques en même temps (ce que xmpp/jabber faisait déjà très bien)
source:
https://en.wikipedia.org/wiki/Matrix_(protocol)
# shibboleet
Posté par err404 (site web personnel) . En réponse au journal Un technicien Free a coupé ma fibre optique pour connecter un voisin.. Évalué à 10.
https://xkcd.com/806/
# matrix
Posté par err404 (site web personnel) . En réponse au message Une solution de communication vocale Linux/Windows/Android simple ?. Évalué à 2.
j'utilise matrix.
et pour ça il y a le client web "riot" qu'on trouve sur https://riot.im/app
et il existe aussi le client android "riot" qu'on trouve dans les dépots f-droid
avec riot, tu peux avoir des communication audio/vidéo, et tu peux aussi ajouter des canaux irc en plus des salons matrix.
il existe d'autres passerelles pour d'autres réseaux sociaux.
et si tu ne veux pas que riot scanne ton carnet d'adresse de ton telephone, tu lui refuse ça.
(tandis que "Signal" va se substituer aux sms, et va scanner ton carnet d'adresse sans te le demander, et il va annoncer à tous tes contacts que tu utilise "signal", du point de vue vie privée c'est inacceptable)
[^] # Re: Et les algorithmes d'auto organisation ?
Posté par err404 (site web personnel) . En réponse au journal Bulle d'idée attrapée : une expérience collaborativo-informatico-scientifique. Évalué à 1.
Minecraft est libre?
En plus, minecraft est fait en Java, le truc immonde qui bouffe un maximum de cpu pour afficher de la 3D (à moins que Java sache utiliser l'accélération matérielle, ce qui serait enfin une bonne chose)
Il existe Minetest qui est libre.
Minetest utilise OpenGL, un peu de CPU et une bonne carte graphique suffit.
# oui mais non
Posté par err404 (site web personnel) . En réponse au journal Firefox hello sera bronsonisé. Évalué à 10.
hello de firefox semble limité à deux utilisateurs.
pour ma part, j'utilise vroom.im qui ne semble pas limité à seulement deux utilisateurs en même temps.
l'autre avantage de vroom.im, c'est que l'auteur documente toute la procedure pour qu'on puisse l'installer sur son propre serveur, ce qui n'est pas le cas de hello de firefox.
vroom.im n'a pas besoin de javascript externe pour fonctionner.
hello de firefox était de toute façon instable
# GNU/Linux timeline
Posté par err404 (site web personnel) . En réponse au journal Debian a 23 ans. Évalué à 4.
https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg
https://fr.wikipedia.org/wiki/Distribution_GNU/Linux#Historique
On peut dire que Debian est à l'origine du plus grand nombre de distributions qui en dérivent, et finissent par ne plus y ressembler.
C'est rassurant de voir cette diversité, car ça permet de trouver une distribution et le support pour la plupart des goût et des besoins.
Il est même possible de se faire sa propre distribution, librement.
[^] # Re: distrowatch
Posté par err404 (site web personnel) . En réponse au journal Présentation de freeostorrent.fr. Évalué à 3.
si il y a des ISO officielles disponibles, il suffit de créer des liens vers les pages de télechargement de ces ISO, avec une description, etc.
[^] # Re: Vroooooom
Posté par err404 (site web personnel) . En réponse au journal La déception skype. Évalué à 2.
Sauf que justement, l'avantage de http://vroom.im c'est de ne pas dépendre de javascript externe, et c'est un avantage considérable.
Je l'ai testé, ça fonctionne bien, mais ça bouffe pas mal de cpu pour les vidéos. (mon téléphone chauffe terriblement avec vroom.im)
Pour le son, avec l'ordi c'est bon, mais avec le téléphone c'est un peu saccadé, je n'ai pas vraiment trouvé pourquoi.
Dans l'ensemble, vroom.im est vraiment pas mal, il y a même un pad intégré.
Merci Dani pour cette petite perle :p
[^] # Re: Vroooooom
Posté par err404 (site web personnel) . En réponse au journal La déception skype. Évalué à 4.
En fait, du moment que ça utilise webrtc ET html5, il est possible d'y retrouver ces fonctionnalités, que ce soit avec Hello de firefox, ou http://opentokrtc.com, et plein d'autres encore.
dans tous les cas, on se dit, "cool, et si je m'installais mon propre serveur?" mais en fait, ces technologies innovantes ne sont pas facile à installer…
Personnellement j'ai une préférence pour Hello de firefox, mais à condition de ne pas avoir installé firefox ESR
Mais Hello de firefox veut absolument partager ma navigation web, alors que je veux simplement partager ma webcam et mon microphone, avec la possibilité de désactiver l'un ou l'autre à la demande.
Tous ces truc en WebRTC et Html5 sont bourrés de javascript, qui fait tu ne sais pas trop quoi…y compris Hello de Firefox.
je vais aller voir ce que donne http://vroom.im :p
[^] # Re: Bug fermé chez tmux
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.
Je ne parlais pas de remote, mais bien de ssh en localhost.
Le comportement de systemd est le même si j'ouvre un terminal dans ma session graphique et que je lance tmux dans ce terminal.
[^] # Re: Bug ferme chez tmux
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.
pour avoir testé un ssh en localhost, ça ne fonctionne pas, le tmux est quand même killé à la fermeture de la session.
C'est pour ça que cette option dans /etc/systemd/logind.conf est importante.
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.
Je ne m'en suis pas pris plein la gueule, du moins pas plus que systemd, et j'ai trouvé une solution au problème. (et je me suis bien marré toute la journée du vendredi, rassures-toi :D )
Reste à savoir pourquoi je n'ai pas eu d'avertissement sur la modification arbitraire de /etc/systemd/logind.conf (les avis sont mitigés la dessus)
j'ai passé la priorité de debconf à un niveau inférieur, on verra bien.
D'après ce que j'ai pu lire dans un autre commentaire, le fait que les packageurs de systemd pour debian soient revenus au comportement habituel qui consiste à ne pas tuer les processus daemonisés des utilisateurs à la fin de la session, prouve que j'avais raison de me fâcher. ou du moins que nous partageons le même point de vue.
L'important c'est de pouvoir intervenir librement dans les réglages, sans avoir à subir des généralités au prétexte que tout le monde fait dans un sens ou dans l'autre.
Je comprend tout à fait que les besoins (ou les envies) des uns diffères des autres.
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à -5. Dernière modification le 03 juin 2016 à 22:37.
ton raccourci est encore pire que le mien :p
[^] # Re: Moi aussi je lis trop vite et de façon superficielle.
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à -5.
Ah ah, surement pas.
Quand je tombe sur ce genre de question, je fais particulièrement attention.
Mais je te remercie d'avoir soulevé ce point.
Après vérification de mon Debconf, le niveau de priorité est réglé à 'high' ('high' is for rather important questions), donc pour les questions importantes, et, vu comment les devs de Systemd considèrent les utilisateurs, je n'étais pas près de voir s'afficher de question…
Je passe à 'medium', et j'espère bien avoir plus de retour sur les réglages par defaut de systemd la prochaine fois.
[^] # Moi aussi je lis trop vite et de façon superficielle.
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Ce sont des choses qui arrivent quand on cherche une solution le soir avant d'aller se coucher, si j'avais vu cette autre solution dès le début, j'aurais plutôt fais un journal qui donne directement cette solution plutôt que d'en arriver à quémander une solution.
Je n'avais pas lu le texte assez en détail, de la même façon que je ne lis pas systématiquement les changelog de tous les paquets que je mets à jour sur mon ordi perso parce que la plupart des autres paquets indiquent quand il y a un gros changement dans le comportement habituel.
j'avais d'autres réglages dans le fichier /etc/systemd/logind.conf (ceux qui concernent le comportement quand je rabat l'écran du portable) ils ont étés écrasés sans prévenir,
D'habitude il y a dpkg qui me dit que le fichier de conf qui sera installée est différent de celui qui est présent, et à ce moment, j'ai le choix entre installer la version du paquet, garder ma version, ou voir la différence etc.
Mais avec systemd, je n'ai pas avertissement, tout est écrasé silencieusement.
[^] # Re: Depuis NEWS
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1. Dernière modification le 03 juin 2016 à 14:21.
Tout à la fin de mon texte, j'indiquais:
ff9097 a indiqué une solution, toi tu n'a pas lu mon texte jusqu au bout.
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
Je ne fais pas de la résistance au changement, mais j'aimerais que ce genre de changement soit mieux documenté lors de la mise à jour.
[^] # Re: Depuis NEWS
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4.
Merci ff9097 \o/
Effectivement il semble possible de modifier le comportement par defaut de systemd sans être obligé de recompiler ce dernier.
le fichier à modifier se trouve dans /etc/systemd/logind.conf
et il faut remplacer la ligne #KillUserProcesses=yes par KillUserProcesses=no
sans oublier de la decommenter bien entendu.
Vous croyez que c'est possible de demander à systemd de prende en compte le changement sans rebooter l'ordinateur?
tiens, si ça se trouve la modification apportée ne suffira pas…
[^] # Re: Bug fermé chez tmux
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
changer d'init?
alors tu va m'expliquer comment je peux me passer de dbus sur mon ordinateur de bureau.
parce que j'utilise Mate Desktop, et Mate dépend de dbus qui dépend de systemd…
sur mes serveur je n'utilise pas systemd parce que j'ai d'autres system d'init, mais sur mes serveurs je n'utilise pas d'environnement de bureau non plus…
[^] # Re: Bug ferme chez tmux
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4. Dernière modification le 03 juin 2016 à 02:40.
Ce n'est pas un bug de Tmux, mais ça n'empêche pas que ça apparaissent dans leur rapport de bug.
Le rapport de bug est fermé justement parce que ça ne concerne pas tmux, mais bien systemd et leur choix arbitraire à la va-vite.
Vu sur le Web, mais je ne sais plus où:
En gros, il existe une petite fonction, Daemon(), qui fonctionne de façon inchangée depuis 30 ans, simplement et sur des multiples plateformes. alors que pour obtenir la même chose aujourd'hui, il faudrai ajouter 150 lignes de code spécifique à Linux ET ajouter une dépendance à une bibliothèque.
Je crois que je vais laisser tomber Debian (que j'utilise depuis 1997 mais avec de moins en moins de satisfaction) et je vais aller voir du coté de Gentoo qui laisse plus de choix à l'utilisateur final. (je vais passer un peu de temps à compiler…)
c'est dommage, j'aimais bien le contrat social de Debian. je reviendrais peut-être à Debian un jour, il y a assez de distributions GNU/Linux pour avoir encore un peu de liberté.
[^] # Re: Bug fermé chez tmux
Posté par err404 (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 5. Dernière modification le 03 juin 2016 à 01:04.
Merci beaucoup.
Donc, si je comprend bien, je devrais lancer tmux avec la commande suivante:
systemd-run --scope --user tmux
sauf que ça me renvoit:
Failed to create bus connection: Operation not permitted
(c'est un tmux que je lance en tant que Root, c'est un comble :p )