err404 a écrit 249 commentaires

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)

source:
https://en.wikipedia.org/wiki/Matrix_(protocol)

https://xkcd.com/806/

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)

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.

entre plusieurs utilisateurs

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

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.

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.

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

à 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 vais aller voir ce que donne http://vroom.im :p

Je ne parlais pas de remote, mais bien de ssh en localhost.

1. Je suis dans ma session graphique, j'ouvre un terminal
2. Dans ce terminal je lance un ssh err404@localhost
3. Une fois connecté par ssh en localhost je lance un tmux dedans.
4. 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.
5. 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.

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.

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.

ton raccourci est encore pire que le mien :p

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.

Tout à la fin de mon texte, j'indiquais:

Si vous avez une solution élégante, je suis preneur.

ff9097 a indiqué une solution, toi tu n'a pas lu mon texte jusqu au bout.

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.

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?

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é.

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 )