Mosh est une application permettant d'ouvrir une session à distance et sécurisée sur une machine de type Unix.
À la différence du célèbre et incoutournable SSH, Mosh offre la possibilité de maintenir une session ouverte tout en étant connecté par intermittence (roaming IP), d'où son nom : Mobile Shell.
Ce dernier est une alternative au couple SSH+Screen.
Fonctionnement
Mosh utilise SSH pour se connecter sur l'hôte distant. Une fois la connexion établie, un processus mosh-server prend le relais sur un port UDP en ouvrant une nouvelle session sécurisée et ferme la session SSH. Le client communique alors directement avec mosh-server. Avantage de la solution ? Si le client change d'adresse IP et qu'il retente une connexion à travers SSH, mosh-server reprend le dialogue avec la nouvelle adresse IP.
Mosh utilise aussi une approche différente de SSH pour la gestion de l'affichage du terminal client. Mosh n'attend pas une réponse de l'hôte distant pour afficher ce qui a été saisi par l'utilisateur. Le client et le serveur possèdent chacun un instantané (snapshot) de l'écran à afficher. La solution de Mosh repose sur la synchronisation de ces deux états. Ce qui permet à l'utilisateur de réduire les impressions de latence si la qualité de sa connexion est mauvaise.
Autres points importants :
- Mosh n'a pas besoin des droits super-utilisateur pour s'exécuter.
- Mosh impose un environnement en UTF-8 et ne gère pas d'autres encodages.
- Mosh ne gère pas encore le X-forwarding, ni le Port-forwarding.
Aller plus loin
- Site officiel de Mosh (983 clics)
- Dépôt GIT du projet (98 clics)
# Mosh et SSH
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
En première page du site de mosh : Mosh is a replacement for SSH
C'est partiellement faux. Mosh utilise SSH pour la première connexion. Idem pour les droits root, mosh en a besoin et délègue cette partie à ssh… Bref, c'est un peu facile de mettre cela en avant !
Sinon, avec le forwarding, ca va être terrible ;-) L'idéal serait d'intégrer le proxy NX dans le forwarding X11…
Après le forwarding, un mode tunnel qui gère les routes et on est aux anges ;-)
[^] # Re: Mosh et SSH
Posté par reno . Évalué à 1.
Ouaip: Wayland est prévu pour le local, un VLC-like au dessus de Wayland devrait marcher correctement en LAN donc X devrait se focaliser sur le WAN (où Wayland serait très probablement très mauvais), donc X devrait se focaliser sur le WAN et intégrer NX.
M'enfin ce n'est pas nouveau: ça aurait été une bonne idée même avant que Wayland pointe le bout de son nez..
[^] # Re: Mosh et SSH
Posté par tripa . Évalué à 0.
Comme j'ai lu ailleurs sur le net en réponse au même commentaire: c'est un "replacement" au sens où tu vas remplacer tes "ssh host" par des "mosh host". La première page n'a pas pour vocation de rentrer trop profondément dans les détails techniques poilus.
# []
Posté par M . Évalué à 4.
Ce dernier est une alternative au couple SSH+Screen.
Et ca apporte quoi par rapport a cette solution ?
A part le "local echo" (qui me semble pas une super idée), je ne vois pas.
[^] # Re: []
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Mosh est fait pour les connexions de faible qualité (wifi, 3G, etc.). Il va beaucoup mieux se comporter que ssh sur les pertes de paquet et aura une latence plus faible. Pour ceux avec une connexion filaire, ssh+screen marche très bien et mosh n'apportera rien de plus.
[^] # Re: []
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Notre routeur (+firewall) a une tendance a couper les connexions… Si MOSH est plus robuste, tant mieux !
Sinon, MOSH utilise UDP et non TCP, pour la partie tunnel (forward…), cela peux être intéressant car le TCP dans TCP n'est pas toujours le top.
[^] # Re: []
Posté par nerbrume . Évalué à 3.
Au contraire, le "local echo", c'est vraiment le truc qui m'aurait bien servi dernierement. Quand le texte (et surtout, le curseur) mets entre 1/2s et 1s a s'afficher, on s'impatiente très vite. En meme temps, on apprends à faire attention à ce qu'on tape…
J'avais bien cherché a l'époque, notamment du coté des outils pour faire du multicast de commandes sur des serveurs, mais je n'avais rien trouvé de probant.
Maintenant, le top, ca serait de ne pas avoir besoin de mosh coté serveur, puisqu'on n'est pas toujours admin de la machine sur laquelle on se connecte.
[^] # Re: []
Posté par NilugeKiWi . Évalué à 4.
Justement, il n'y a pas besoin d'être administrateur de la machine serveur pour y utiliser mosh:
Le client mosh en gros fait
ssh machine 'mosh-server'
mosh-server se met à écouter sur un port udp, et ensuite le client mosh s'y connecte.
Tout se passe avec des process users normaux.
La seule limite va être le firewall entre le client et le serveur.
[^] # Re: []
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 1.
Mais c'est justement une énorme limite. Combien de pare-feux autorisent l'UDP ?
[^] # Re: []
Posté par Samuel Thibault (site web personnel) . Évalué à 3.
Il se trouve que le "local echo" est en train de petit à petit faire son chemin dans ssh. Petit à petit parce que cela prend le chemin "normal": extension de la couche tty, patch de readline et ssh pour l'utiliser. Au final c'est robuste, mais c'est long à mettre en place.
[^] # Re: []
Posté par M . Évalué à 2.
Au passage ca doit deja exister dans Putty.
# Je m'y suis mis depuis quelques jours
Posté par echarp (site web personnel, Mastodon) . Évalué à 10.
J'ai en permanence plusieurs sessions "screen" distantes sur des serveurs auxquels j'accède avec ssh.
Suis passé à mosh.
Il me semble avoir au moins les même fonctionnalités, mais en plus, il m'indique quand la connexion est tombée et depuis combien de temps. Parfois je vois que certains caractères ont été envoyés mais pas encore reçus (ça arrive quand la connexion est surchargée par ailleurs).
ET, j'ai l'impression que la session distante a un meilleur temps de réponse, presque équivalent à une console locale.
Pour l'instant, je +1 :)
[^] # Re: Je m'y suis mis depuis quelques jours
Posté par zebra3 . Évalué à 4.
Déjà, la news précise qu'il ne gère pas le X forwarding et le port forwarding. C'est dommage, c'est entre autres ce qui fait la supériorité de SSH.
Ensuite, je n'ai pas testé mais gère-t-il aussi les multiples fenêtres comme Screen ? Parce qu'en plus de la reprise de session, c'est une killer feature.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je m'y suis mis depuis quelques jours
Posté par ze_lionix (site web personnel) . Évalué à 1.
Déjà, la news précise qu'il ne gère pas le X forwarding et le port forwarding
En même temps tu forward souvent une application X sur ton smartphone ?
Fuse : j'en Use et Abuse !
[^] # Re: Je m'y suis mis depuis quelques jours
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Quel rapport avec un smartphone ? Une connexion micro-ondes longue portée, ce n'est pas seulement utilisé sur téléphone…
[^] # Re: Je m'y suis mis depuis quelques jours
Posté par ze_lionix (site web personnel) . Évalué à 1.
Ah pardon mais l'intérêt principal de mosh est de faciliter les terminaux distant depuis un téléphone mobile, d'où l’étymologie du nom précisé dans l'article d'ailleurs!
Si tu utilises un lien radio entre deux bâtiments et que tu en es rendu à l'utiliser parce-que ça coupe je pense qu'il est temps d'envisager de tirer un bon vieux lien physique ! :-D
Fuse : j'en Use et Abuse !
[^] # Re: Je m'y suis mis depuis quelques jours
Posté par Juke (site web personnel) . Évalué à 5.
Tu peux utiliser ton téléphone pour brancher ton pc portable.
[^] # Re: Je m'y suis mis depuis quelques jours
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Pas d'après la page d'accueil du projet, qui parle de mobilité, pas de téléphone.
[^] # Re: Je m'y suis mis depuis quelques jours
Posté par Juke (site web personnel) . Évalué à 3.
ça arrive. (bon pas en wifi par contre)
[^] # Re: Je m'y suis mis depuis quelques jours
Posté par echarp (site web personnel, Mastodon) . Évalué à 2.
Il permet de se connecter à screen, moi c'est ce dont j'ai besoin :)
# incompatible avec un proxy http
Posté par DerekSagan . Évalué à 6. Dernière modification le 17 avril 2012 à 08:54.
J'aime beaucoup UDP, mais partout (entreprises, etc.) où on ne peut établir une connexion SSH que sur le port 443 à travers un proxy HTTP, Mosh ne fonctionnera pas…
[^] # Re: incompatible avec un proxy http
Posté par neerd . Évalué à 10.
Oui et ça c'est mosh !
[^] # Re: incompatible avec un proxy http
Posté par navaati . Évalué à 1.
Ah wep, c'est un logiciel qui utilise Internet, nul !
[^] # Re: incompatible avec un proxy http
Posté par DerekSagan . Évalué à 5.
J'ai pas dis que c'était nul, je relève juste une limite d'utilisation. Perso j'adore UDP, je déteste le tout-TCP voire le tout TCP:80,443 mais je constate que dans beaucoup de cas je ne pourrais pas me servir de mosh.
[^] # Re: incompatible avec un proxy http
Posté par zebra3 . Évalué à 2.
Bah déjà, j'ai pas compris comment dire à mosh d'utiliser le port 443…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: incompatible avec un proxy http
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
-p 433, sauf qu'en fait non : mosh est lancé en tant qu'utilisateur et n'a donc pas le droit d'utiliser de port
[^] # Re: incompatible avec un proxy http
Posté par Juke (site web personnel) . Évalué à 1.
Ne peux tu pas le lancer en root ou autoriser l'utilisateur à ouvrir des
ports ?
[^] # Re: incompatible avec un proxy http
Posté par zebra3 . Évalué à 2.
Tu penses bien que j'ai essayé. D'après la man :
-p NUM, --port=NUM
Use a particular server-side UDP port, for example, if this is
the only port that is forwarded through a firewall to the
server. Otherwise, mosh will choose a port between 60000 and
61000.
Ça ne correspond pas à ce que je cherche : je veux me connecter à un serveur SSH qui écoute sur le port 443. Justement parce que bien souvent, le port 22 est filtré.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: incompatible avec un proxy http
Posté par DerekSagan . Évalué à 2.
Te fatigues pas trop, si le port TCP 22 est filtré, il y a peu de chance que l'UDP passe, ou alors le type qui administre le firewall est vraiment trop lol.
# Pas trop convaincu...
Posté par Octplane (site web personnel) . Évalué à 4.
Après l'avoir installé sur mon Mac au boulot et sur deux linux (un sur mon LAN, l'autre sur "internet"), j'arrive à me connecter sans souci sur le linux du boulot (et pour le coup, ça ne sert à rien vu que je suis sur un LAN ultra rapide, mais au moins, je sais que Mosh marche).
Sur le linux distant qui est à priori ouvert complètement, la connexion ne se fait pas et bloque mon terminal (control-C n'y fait rien, je suis obligé de tuer l'animal). Vu qu'il n'y a aucun feedback, je ne sais pas ce que j'ai mal fait et je suis triste.
Je n'utilise plus Mosh et la vie me paraît moins laide.
[^] # Re: Pas trop convaincu...
Posté par DerekSagan . Évalué à 2.
Un firewall peut-être…
[^] # Re: Pas trop convaincu...
Posté par Octplane (site web personnel) . Évalué à 1.
Ben non, justement…
# Bof
Posté par Stéphane Ascoët (site web personnel) . Évalué à -4.
La désynchronisation de l'affichage me fait peur. Au cas où il y a une différence, les dégâts pourraient être terribles.
Et vu qu'il exige l'UTF8, qui provoque des problèmes de claviers en raison de bugs dont tout le monde se fiche, présents dans le noyau Linux depuis des années, c'est pas pour moi!
[^] # Re: Bof
Posté par djabal . Évalué à 4.
Et tu as des liens vers ces bugs dont tout le monde se fiche ?
[^] # Re: caps lock led always off under Linux
Posté par Stéphane Ascoët (site web personnel) . Évalué à -8. Dernière modification le 17 avril 2012 à 15:26.
Ça fait l'objet d'une question/réponse dans /usr/share/doc/console-setup/FAQ.gz (point 2.3). Ça me tape tellement sur les nerfs que j'ai décidé de ne plus faire de nouvelle installations en UTF8…
http://old.nabble.com/Bug-514212%3A-console-setup%3A-on-UTF-8-console,-caps-lock-is-turned-into-a-shift-lock-td21848145.html
Avec ce voyant(led) du cadenas(caps lock) des majuscules inopérant, on peut faire de grosses erreurs, et les conséquences pourraient être dramatiques, j'espère qu'il n'y a pas ce genre de bétises dans les centrales nucléaires par exemple!
[^] # Re: caps lock led always off under Linux
Posté par Stéphane Ascoët (site web personnel) . Évalué à -8.
Après poursuite des recherches, il semblerait, d'après le bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514464 ce serait corrigé à partir du noyau 2.6.34. Est-ce que quelqu'un l'a et peut faire le test d'allumage/extinction de la led du cadenas dans une tty UTF8?
[^] # Re: caps lock led always off under Linux
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
Tu refuse d’utiliser Unicode juste parce que la diode de verrouillage majuscule ne fonctionne pas en console (ça fonctionne parfaitement sous X) ?
Ton clavier est tellement petit et mal foutu que tu ripe sur « CAPS_LOCK » quand tu tapes un A, un Q ou sur « TAB » ?
On devrait t’ériger en exemple de l’expression « jeter le bébé avec l’eau du bain ».
C’est effectivement un bug, mais vu le peu d’utilisation de cette touche (tu dois être la première personne que je croise qui ait essayé de l’utiliser en mode console sous Linux) et le nombre de cas ou son activation intempestive ne soit pas détectée à la première touche tapée sans dommages, il ne faut pas abuser quand même…
[^] # Re: caps lock led always off under Linux
Posté par Stéphane Ascoët (site web personnel) . Évalué à -4.
Et quand tu tapes des mots de passes et divers raccourcis ne s'affichant pas à l'écran? Que par ailleurs je ne regarde pas tout le temps en tapant…
[^] # Re: caps lock led always off under Linux
Posté par Samuel Thibault (site web personnel) . Évalué à 3.
Cf le bug mentionné dans une réponse: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514464 le patch est dans mm, et attend une review de Dmitry Torok. Il se trouve que ce n'est effectivement pas sa priorité, mais il faut lui dire combien c'est gênant: si personne ne se plaint, ça ne va pas le pousser.
[^] # Re: caps lock led always off under Linux
Posté par Stéphane Ascoët (site web personnel) . Évalué à -4.
Encore faut-il savoir comment le faire…
[^] # Re: caps lock led always off under Linux
Posté par Samuel Thibault (site web personnel) . Évalué à 3.
Ben c'est bête comme envoyer un mail à linux-kernel avec Dmitry en Cc, mentionnant le patch leds-route-kbd-leds-through-the-generic-leds-layer.patch
[^] # Re: Bof
Posté par Hobgoblins Master (Mastodon) . Évalué à 8.
[Source…]
J’utilise UTF-8 partout depuis des années, jamais eu de clavier qui se blo
[^] # Re: Bof
Posté par claudex . Évalué à 5.
Moi, c'est l'inverse, j'ai l'affichage qui se bloque en ssh mais pas le clavier (je ne le vois quand je récupère ma session screen).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bof
Posté par FantastIX . Évalué à 2.
Tu pourrais au moins terminer t
[^] # Re: Bof
Posté par fearan . Évalué à 0.
des liens non mais des bug j'en ai au moins un qui est bien lourd : konsole + bash je tape un caractère accentué je fais
L'autre soucis, mais ça, ça n'a rien a voir avec l'UTF-8, c'est que ma konsole se comporte mal si le prompt est sur 2 lignes.
je précise :
[589] $>konsole --version
Qt: 3.3.6
KDE: 3.5.4-25.el5.centos.1 Red Hat
Konsole: 1.6.4
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Bof
Posté par Faya . Évalué à 7.
Effectivement.
[^] # Re: Bof
Posté par fearan . Évalué à 0.
oups [backspace] ou retour arrière ;)
Bon j'ai au passage enfin réglé mon soucis de prompt sur 2 lignes ;) un soucis au niveau des changements de couleurs qu'il faut encadrer par des [ et ].
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Bof
Posté par zebra3 . Évalué à 4.
En même temps, tu utilises un environnement dont la dernière mise à jour date d'août 2008.
Si tu veux discuter de bug autours d'UTF8, faudrait au moins utiliser des versions encore maintenues.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bof
Posté par fearan . Évalué à 2.
ah si j'avais le choix de ma distrib, ce ne serait surement pas une centos, je bosse avec ce que l'on me donne…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Bof
Posté par CrEv (site web personnel) . Évalué à 2.
Nan mais c'est n'imp là…
UTF-8 ça date pas de 2008 quand même, il est même surtout hallucinant qu'en 2008 des bugs pourris existaient autour d'unicode.
Et je parle pas du non support d'unicode aujourd'hui…
Une bonne lecture sur le sujet : http://french.joelonsoftware.com/Articles/Unicode.html
[^] # Re: Bof
Posté par Kaane . Évalué à -7.
UTF-8 c'est bien pour l'affichage d'un texte non corrompu. Mais bon sur un texte avec des erreurs qui ont générées des caractères interdits ou pour une saisie interactive, c'est déjà nettement plus discutable. Ne serait-ce que d'avoir un système qui tolère les noms de fichiers en UTF-X c'est un bordel sans nom. Tiens question : sous un système comme mosh, qui est pur UTF-8 comment on fait pour effacer un fichier dont le nom est codé en UTF-16 (par exemple un fichier nommé en Coréen) ? Point bonus si tu sais dire comment éditer un fichier dont le nom en UTF-16 contient un caractère interdit en UTF-8.
Unicode c'est comme IPv6, sur le papier c'est génial, dans la pratique on s'en sort souvent mieux avec une approche plus traditionnelle.
[^] # Re: Bof
Posté par CrEv (site web personnel) . Évalué à 10.
Et c'est quoi l'approche traditionnelle ?
Ne pas permettre d'avoir autre chose que de l'ascii ?
Ton problème de rennomage c'est la même chose entre ISO-8859-1 et CP-1252 par exemple.
Ha oui, et comment tu gères le € sur un ISO-8859-1 ?
Et comment, dans ton approche traditionnelle, tu gères un fichier coréen ?
En fait, ça serait pas mal que tu indiques quelle est l'approche traditionnelle car je pense que beaucoup de personnes seraient intéressées ;-)
[^] # Re: Bof
Posté par Kaane . Évalué à 1.
Ton problème de rennomage c'est la même chose entre ISO-8859-1 et CP-1252 par exemple.
Non, les caractères posant problème en CP-1252 (i.e les caractères de 128 à 159) qui ne transcrivent pas en ISO-8859 peuvent être échappés facilement avec des antislash en code ou avec des caractères joker (? et * principalement) en shell. Le problème est nettement plus simple à traiter.
Ha oui, et comment tu gères le € sur un ISO-8859-1 ?
Tu ne le gères pas. Si tu as besoin du symbole € tu prends un autre charmap.
Et comment, dans ton approche traditionnelle, tu gères un fichier coréen ?
Le nom du fichier va être explosé en une suite de caractères (imprimables ou non) que je peux récupérer de la même façon que je récupères les noms de fichiers incorrects. En échappant ou en utilisant des jokers. C'est moche, mais ça marche.
[^] # Re: Bof
Posté par CrEv (site web personnel) . Évalué à 4.
Ha ok.
Donc dans ce cas, j'ai mon beau système de fichier en ISO-8859-1 (ben oui, pourquoi pas finalement) et au milieu un fichier qui porte un nom en ISO-8859-15.
Ha ben merde, comment je fais ?
Ben idem avec de l'utf-8 alors
A exécuter dans un navigateur qui comprend le js. Et hop, je viens d'écrire de l'unicode en ISO-8859-1. Alors, il est où le problème finalement ?
[^] # Re: Bof
Posté par Kaane . Évalué à -3.
et au milieu un fichier qui porte un nom en ISO-8859-15. Ha ben merde, comment je fais ?
Le symbole € ne s'affichera pas correctement. C'est tout. A la place tu verras le symbole monétaire international ¤, rien de bien méchant. Avec un clavier français, en faisant Alr Gr+e tu pourras éditer et modifier ce fichier sans même recourir aux jokers.
A exécuter dans un navigateur qui comprend le js. Et hop, je viens d'écrire de l'unicode en ISO-8859-1. Alors, il est où le problème finalement ?
Essaye de faire ca dans un shell, comme Mosh par exemple. Et regarde la gueule que fait ton interpreteur. Surtout que afficher des caractères c'est une chose, mais les interpreter s'en est une autre. De mémoire c'est quoi le code unicode de 국 par exemple ? Tu vas en avoir besoin pour accéder au fichier…
[^] # Re: Bof
Posté par DerekSagan . Évalué à 1.
Toi quand une ampoule grille chez toi, tu ne la changes pas, tu décrètes qu'il n'y a pas besoin de gérer l'obscurité…
Ben en ce qui me concerne tu fais ce que tu veux chez toi, mais perso je vais quand même continuer à changer les ampoules qui claquent et à utiliser UTF-8 partout.
[^] # Re: Bof
Posté par Kaane . Évalué à 3.
Toi quand une ampoule grille chez toi, tu ne la changes pas, tu décrètes qu'il n'y a pas besoin de gérer l'obscurité…
Excellente analogie. Félicitation.
Si tu veux faire une analogie aussi terre à terre on va plutôt dire :
Quand tu as du 220v chez toi, comment tu fais pour brancher un appareil 110v ?
a) Tu branches pas
b) Tu mets un gros transfo (conversion à la volée de la tension, avec probablement une limitation en puissance), mais sous Linux il n'existe pas de modules qui permette de convertir à la volée les noms de fichiers d'un encodage à l'autre.
c) Tu branches quand même et pis tant pis si ca claque.
Maintenant avec tous les moinssages que j'ai reçu, personne n'a répondu à la question : comment faire en UTF-8 pour ouvrir un fichier dont le nom est en UTF-16 et contient un caractère interdit en UTF-8.
A noter qu'en bête ANSI, les noms de fichiers UTF-8/UTF-16 et même CP1252 ou ISO sont accessibles aussi bien programatiquement que via le shell, moyennant des échapements et ou des jokers.
Ben en ce qui me concerne tu fais ce que tu veux chez toi, mais perso je vais quand même continuer à changer les ampoules qui claquent et à utiliser UTF-8 partout.
Ce que tu utilises chez toi fonctionnera toujours, si tu décides d'utiliser exclusivement IBM-1364 ca marchera. Le problème c'est ce que tu utilises chez les autres et ce que les autres utilisent chez toi. Si je t'envoie un fichier en ISO-8859-15, vu que tu utilses UTF-8 partout j'en déduis que tu ne l'ouvriras pas. Donc tu ne changeras pas non plus l'ampoule…
[^] # Re: Bof
Posté par DerekSagan . Évalué à 3.
Je ne comprends absolument pas cette obsession que tu as de vouloir mélanger dans le même filesystem des fichiers dont les noms son encodés différemment (je ne parle pas du contenu des fichiers bien sûr). Après tout, pourquoi pas, tu as peut-être tes raisons…
…mais de là à t'en servir d'argument pour justifier ton point initial, à savoir qu'UTF-8 utilisé pour la communication en shell ne fonctionne pas à cause de bugs noyau (je te cite) parce que la led num lock ne s'allume pas dans certains cas en console, t'as pas l'impression de tout mélanger façon quand on veut tuer UTF-8 on dit qu'il a la rage?
[^] # Re: Bof
Posté par Kaane . Évalué à 5.
Je ne comprends absolument pas cette obsession que tu as de vouloir mélanger dans le même filesystem des fichiers dont les noms son encodés différemment (je ne parle pas du contenu des fichiers bien sûr).
Le contenu des fichiers, on s'en fout. Si le programme qui est supposé ouvrir un fichier ne gère pas UTF-8, ben soit on ouvre avec un autre programme, soit on prend sur soi et on code un pacth. Sinon recode marche du feu de dieu dans la plupart des cas.
Par contre le shell lui c'est une autre paire de manche. Si le shell est en UTF-8, ca veut dire que tout un tas d'autres trucs doivent être en UTF-8, la locale le LANG moult parmètres pour less, perl, python, ruby etc. Sinon il va se passer de drôles de trucs à l'execution de certains scripts.
Mais bon ca c'est encore gérable.
Maintenant la bonne question est "mais pourquoi je parle tout le temps de koréen ?" et bien (un élément de réponse) est là :
http://code.google.com/p/msysgit/issues/detail?id=376
Il n'y a pas de moyen de connaitre l'encoding d'un nom de fichier - Aucun meta ne permet de le savoir, du moins pas sur les filesystems classiques. A partir de là pour pouvoir utiliser des programmes aussi courants que tar, git-clone, unzip, perl, python etc. il faut :
- soit se mettre d'accord avec le monde entier pour que tout le monde utilise exclusivement un encoding. Par exemple UTF-8, mais les asiatiques vont faire la gueule.
- Soit utiliser exclusivement les caractères ANSI dans tous les scripts/archives/backups/repo/sources etc.
Sinon tu prends le risques réel que ton programme fasse n'importe quoi. Supposons que ton make clean fasse un rm -r sur /home/toi/┌/obj et que ton parseur bute sur le ┌ qu'il interprete comme une terminaison (Je sais ca ne peux pas être le cas avec ce caractère là, c'est même pour ça que je l'ai choisi). Il va se passer quoi à ton avis ? Déjà ton make clean ne finira pas, et ensuite tu vas avoir plein de place libre sur ton ~….
Pour éviter ce genre de conneries, la seule bonne méthode pour l'instant, en attendant que UTF-8 conquiert le monde entier ou que de meta apparaissent dans les filesystems c'est
a) D'utiliser exclusivement les caractères ANSI dans le noms de fichier qui peuvent être exportés
b) De passer en locale C avant tout git-clone, unzip, ./script.sh etc. Et seulement si ca ne marche pas de repasser dans la locale présumée du truc mais en faisant très gaffe à ce qu'on fait.
Ah au fait, repasser en locale C est la bonne solution pour shooter un fichier dont le nom en UTF-16 qui contient des caractères UTF-8 invalides. Des fois que ca interresse quelqu'un…
Sauf que dans un shell UTF-8 pur, ben on peut pas repasser en locale C.
Autre problème, mosh utilise SSH pour se connecter à la machine distante. Sauf que en SSH il faut déclarer le type de terminal et également remaper un certain nombre de combinaisons de touches. A partir de là soit toute la chaine (emulateur terminal, serveur ssh, shell) est en UTF-8, soit je suis curieux de savoir ce qui va se passer quand je vais faire ctrl+H.
mais de là à t'en servir d'argument pour justifier ton point initial, à savoir qu'UTF-8 utilisé pour la communication en shell ne fonctionne pas à cause de bugs noyau (je te cite)
Ce n'est pas très grave pour la discussion en cours, mais ce n'est pas moi que tu vas citer.
parce que la led num lock ne s'allume pas dans certains cas en console,
Il ne s'agit pas de la led numlock, mais de la led capslock. Ou pour être exact à cause du local echo les caractères vont s'afficher en local comme si il s'agissait d'un caps lock mais être interpretés par mosh en bout de chaine comme si il s'agissait d'un shiftlock.
Par exemple si je tape 88 via le pavée numérique en capslock chez moi, je verais s'afficher 88 sur mon emulateur terminal, mais le shell recevra deux fois l'instruction "commande précédente". Ca peut faire des trucs très drôle. Par exemple tu penses avoir lancé un worker tomcat sur le port 8088 ? Perdu tu as réexecuté la commande 3 slots plus haut et tu es passé en mode insertion.
t'as pas l'impression de tout mélanger façon quand on veut tuer UTF-8 on dit qu'il a la rage?
Non, quand on veut tuer UTF-8 on le présente comme la solution absolue à tous les problèmes dans tous les cas et sur toutes les machines. Alors bien sur il y a des gens qui vont y croire, mais au bout du 15ème incident incompréhensible ils vont gentillement repasser leur machine en ISO/ANSI/C parceque ca marche. Et là miracle, même si ça affiche parfois n'importe quoi, ca ne casse pas tout de façon hyper chiante à debugguer.
UTF-8 est un bon format pour les documents avec des métas qui sont capables de signaler "je suis en UTF-8". mais pour les shells et les noms de fichiers, j'évite.
[^] # Re: Bof
Posté par DerekSagan . Évalué à 6. Dernière modification le 18 avril 2012 à 09:22.
Oui c'est pour ça qu'il ne faut en utiliser qu'un seul pour tous les fichiers d'un filesystem donné. Et tant qu'à en utiliser qu'un seul, UTF-8 n'est pas pire qu'ASCII-7.
Un bien bel exemple de ce qui se passe quand deux programmes écrivent des noms de fichiers dans le même filesystems avec des encodages différents.
Cela dit si ce n'était pas une image et que tu écrivais vraiment coréen, tu ne serais pas en train de mener un combat d'arrière garde pro ISO-8859, justement.
Les asiatiques sont censés faire la gueule d'avoir enfin un encodage qui permette de représenter tous les caractères dont ils peuvent avoir besoin et qui est interopérable et supporté par le monde occidental (celui qui considérait que 7 bits c'était assez) ?
Il y a sûrement quand même quelques asiatiques qui comme toi sont attachés à leurs anciens encodages qui leur font gagner quelques % d'espace disque sur le texte non compressé ou à pester (à juste titre) contre le fait que tous les logiciels qu'ils utilisent n'en sont pas au même stade de support d'UTF-8… mais globalement, UTF-8 c'est un progrès pour l'Asie…
Je reconnais qu'on pourrait utiliser GB18030 au lieu d'UTF-8, avec le même intérêt et les mêmes bonnes propriétés. Mais comme 80% des logiciels sont faits en Amérique du nord ou en Europe, ça n'a pas beaucoup de chance de se produire. Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? Parce que c'est plus sûr si tu ne veux pas foute le bordel chez les gens qui utilisent UTF-8 avec des séquences interdites (ah oui… mais eux on s'en fiche c'est leur faute ils n'ont qu'à pas utiliser UTF-8).
En fait ce n'est même pas ASCII-7 mais ASCII-7 sans certains caractères parce que sinon ça créera d'autres problèmes sur certains OS (genre / sous Unix, \ : * ? sous Windows, : sous MacOS9, ; sous VMS, et j'en oublie). Voire sans espaces aussi. Bref t'as droit à une soixantaine de caractères si tu veux pas être emmerdé, ça passerait dans de l'ASCII-6 en fait ;-)
C'est vraiment dur les noms de fichiers. Donc soit tu n'utilises que des lettres ASCII-7 des chiffres et des underscores, soit tu as un et un seul encodage pour tout ton filesystem et à chaque fois que tu as une interface (ftp, sftp, webdav, git clone, unzip) tu t'assures de ne pas injecter de la merde.
Mais le problème existait avant UTF-8.
Et si t'as déjà plein de merde sur ton filesystem, tu peux aussi essayer convmv (yum/apt-get install convmv) pour qu'il te nettoie les choses sans que tu aies à gesticuler avec des "LANG=C mv toto*foo toto_foo" fais à la main.
Mais fais attention, installer convmv pourrait être la première étape à convertir tout ton filesystem en noms en UTF-8, le Mal pourrait t'atteindre…
Là si je peux me permettre, tu confonds les effets de LANG sur le shell et sur les processus que tu lances. Si tu fixes LANG=C avant un git clone, tout va fonctionner car git clone ne t'enverra que de l'étatsunien en ascii7 qui ne donnera pas de bouton au shell (ni à ton émulateur de terminal) et git lui-même étant configuré en C et pas en C.UTF-8 créera les fichiers en conséquences. Avec toutes les limites que ça a (et que ça a déjà avec ton SSH à la place de Mosh), en particulier les commentaires de commit qui sont conventionnellement écris en UTF-8, mais tu t'en fous c'est pas le nom du fichier c'est son contenu.
Dit autrement ça marche indépendamment du shell.
Même raisonnement avec unzip (encore que de toute façon le format zip gère vraiment très mal l'encodage des noms de fichiers).
(bon j’arrête là parce qu'on est légèrement off topic quand même…)
[^] # Re: Bof
Posté par Kaane . Évalué à 1.
Oui c'est pour ça qu'il ne faut en utiliser qu'un seul pour tous les fichiers d'un filesystem donné. Et tant qu'à en utiliser qu'un seul, UTF-8 n'est pas pire qu'ASCII-7.
ASCII-7 (ou même ANSI complet sur toute la plage 32-255) va créer des erreurs d'affichage, UTF-8 va créer des erreurs d'execution. C'est largement pire.
Un bien bel exemple de ce qui se passe quand deux programmes écrivent des noms de fichiers dans le même filesystems avec des encodages différents.
Tu ne travailles qu'avec des gens en qui sont en pur UTF-8 ? Et eux-même ne travaillent qu'avec des gens qui sont en pur UTF-8 ? Parceque sinon tu prends le risque de mélanger les encodings à un moment ou à un autre. Rien que les sources du kernel linux ne passent pas un "make menuconfig" proprement. (Bon c'est juste moche, pas de dégats collatéraux - mais justement parceque les devs utilisent exclusivement ANSI dans le nommage des fichiers)
Les asiatiques sont censés faire la gueule d'avoir enfin un encodage qui permette de représenter tous les caractères dont ils peuvent avoir besoin et qui est interopérable et supporté par le monde occidental (celui qui considérait que 7 bits c'était assez) ?
Plutôt oui. Déjà si ils prennent un encoding ce sera UTF-16, pas UTF-8 sinon une grosse partie des caractères va se retrouver à occuper 4 octects au lieu de 2. Sur un ordinateur normal on s'en fout un peu (et encore, bonjour la gueule des bases de données) mais sur une solution embarquée ca ne passe juste pas.
Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
GB18030-2005 est justement la réponse de la Chine à UTF-8/UTF-16 qui reste compatible avec ASCII et l'ancien système GBK. Ils ont créé ce système à cause des nombreux problèmes que l'on peut rencontrer avec UTF-8 et UTF-16. Il couvre tout unicode (et largement même) donc rien n'empêche d'écrire en japonais avec GB18030-2005, mais il est peut rentable pour les caractères japonais ou corééns qui vont systématiquement se retrouver sur 4 octets.
De façon générale tout pays va chercher à faire un encoding qui
a) fait un mapping direct des caractères ASCII
b) dans la mesure du possible fait un mapping direct de l'ancienne norme en vigueur.
c) economise un maximum de place pour les caractères les plus utilisés dans le pays.
GB18030 est juste cela, un enconding qui respecte ASCII, GBK et qui essaye de mettre d'autres caractères dans les trous disponibles.
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? ….. Mais le problème existait avant UTF-8.
Non le problème n'éxistait pas avant UTF-X. Certes il y avait déjà des caractères illégaux dans les noms de fichier, mais un caractère illégal n'a rien à voir avec un caractère interdit. En ASCII je vais juste me dire "mais quel est le con qui a foutu un CR dans un nom de fichier", en UTF-8 ca va donner un truc du genre "le nom de fichier n'est pas décodable, on fait quoi ?".
La norme UTF-8 (qui fort heureusement n'est pas respectée dans ce cas) dit qu'il faut dropper la séquence - donc pour un filesystem je me retrouve avec un fichier invisible et innacessible complètement, du moins jusqu'à ce que je change ma locale.
C'est vraiment dur les noms de fichiers. Donc soit tu n'utilises que des lettres ASCII-7 des chiffres et des underscores, soit tu as un et un seul encodage pour tout ton filesystem et à chaque fois que tu as une interface (ftp, sftp, webdav, git clone, unzip) tu t'assures de ne pas injecter de la merde.
Et tu t'en assures comment ? Un collègue sous windows t'envoies un .rar, un vieux logiciel métier sur une babasse de dix ans d'age a son code prisonnier dans un tar.gz. Tu fais quoi ? Perso je repasse en locale C, tout autre aproche étant casse gueule.
Et si t'as déjà plein de merde sur ton filesystem, tu peux aussi essayer convmv (yum/apt-get install convmv) pour qu'il te nettoie les choses sans que tu aies à gesticuler avec des "LANG=C mv toto*foo toto_foo" fais à la main.
Oui, et là tu te rends compte que pour lancer la compilation/faire fonctionner l'ETL/linker/ecrire dans le log etc. tu dois te frapper 8500 à la mano et en éditer le contenu (prie pour qu'il n'y ait pas trop de binaires dans le lot). En plus convmv ca me sert principalement à réparer les anneries faites par une personne qui pensait gagner du temps en l'utilisant. convmv est en perl, ce qui veut dire qu'il faut régler les locales et autres charmap de ton interpreteur perl avant de lancer la moindre conversion. Et si tu as des fichiers de plusieurs origines dans plusieurs encodings il vaut mieux reconfigurer entre chaque lot.
Là si je peux me permettre, tu confonds les effets de LANG sur le shell et sur les processus que tu lances. Si tu fixes LANG=C avant un git clone, tout va fonctionner car git clone ne t'enverra que de l'étatsunien en ascii7 qui ne donnera pas de bouton au shell (ni à ton émulateur de terminal) et git lui-même étant configuré en C et pas en C.UTF-8 créera les fichiers en conséquences
Déjà c'est pas juste LANG, mais toute la locale que je repasse en C et ensuite même si j'en ai rien à fiche des commentaires de commit (alors que bon en vrai ca m'interresse un peu) GIT ne dispose pas de moyen de modifier le code source à l'intérieur du contenu. Donc les fichiers auront des noms propres, mais je vais devoir me rééditer tout le contenu à la mano pour reprendre les includes, les chemins, les libs etc. Et quand le dev original voudra synchroniser il va se retrouver avec une tonne de modifs complètement con et les deux lignes de correction de bugs vont passer à la trappe, noyées sous un flot de destruction de fichiers et de création de nouveau fichiers. Bref GIT ne servira à rien et sera même contre productif. Seule solution => ASCII/ANSI.
(et que ça a déjà avec ton SSH à la place de Mosh)
Si ton SSH est en pur UTF-8 oui. Mais le truc c'est que justement le pur UTF-8 en shell ca ne marche pas. Maintenant moyennant deux ou trois essai j'arriverai à caler ma locale sur celle du dev et quand je travaillerais sur ce repo je passerais dans cette locale. C'est ce que mosh ne permet pas.
(bon j’arrête là parce qu'on est légèrement off topic quand même…)
On est pas off-topic du tout. La question est "un shell pur UTF-8, bonne ou mauvaise idée". Pour moi c'est une très mauvaise idée, pour toutes les raisons exposées.
[^] # Re: Bof
Posté par DerekSagan . Évalué à 3.
C'est faux car tous les caractères qui prennent 4 octets en UTF-8 en prennent aussi 4 en UTF-16 (je détaille plus bas).
Mais ton paragraphe devient diablement drôle quand on le rapproche du suivant:
Ah oui, c'est une vraie différence. Au lieu d'avoir des caractères sur 4 octets on a… des caractères sur 4 octets.
Bon soyons constructif:
Il y a un tableau bien fait pour combattre tes préjugés ici (si ça t'intéresse vraiment):
http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings
Pour le comprendre il faut avoir à l'esprit que les langues asiatiques hors idéogrammes rares (rares = CJK extensions B et suivantes) sont toutes dans le BMP ( Il faut aussi noter une petite approximation, ce n'est pas "most Chinese characters" qui tient sur 2 octets mais bien sûr "most usual Chinese characters" (hors idéogrammes CJK extensions B et suivantes, qui sont rares mais très nombreux).
L'affectation des plans est ici:
http://en.wikipedia.org/wiki/Unicode_plane
http://en.wikipedia.org/wiki/CJK_Unified_Ideographs
Pour te donner une idée du surcoût indu que représente +50% sur le texte non compressé, dis-toi que Microsoft a décidé avec Windows 2000 de passer tout stockage de chaîne caractères en UTF-16 (enfin historiquement en UCS-2 sous le nom pompeux d'Unicode) infligeant donc il y a plus de 10 ans un +100% à tout le monde occidental dès que tu passes par leurs bibliothèques (et comment te dire que c'est une pratique courante voire prudente sous Windows…).
Et j'ai un scoop: on n'est pas morts d'un +100%.
Les asiatiques survivrons à +50% (et j'ose la plaisanterie: en plus c'est eux qui fabriquent les disques durs et la RAM!).
Tu n'aimes pas Microsoft, tu n'utilises pas leurs bibliothèques? Et bien je ne connais pas les choix techniques internes de tous les autres environnements de programmation mais devine ce qu'utilisent une String Java et une QString Qt comme format interne depuis des années ? Et oui là aussi on a pris +100% sans broncher.
[^] # Re: Bof
Posté par Kaane . Évalué à 1.
Il y a un tableau bien fait pour combattre tes préjugés ici (si ça t'intéresse vraiment):
C'est à dire que le seul "préjugé" que tu combats c'est de m'expliquer que les caractères asiatiques en UTF-8 sont codés sur 3 caractères et non 4.
Après tout le reste (non correspondance des mappings, problèmes de caractères interdits, problème du shift lock, soucis pour travailler avec le reste du monde etc.) tu ne l'évoques même pas.
De plus tu as l'air de penser que je suis anti UTF-8, alors que je suis anti UTF-8 dans un shell quand c'est la seule solution.
Pour finir (et juste pour info) le GB18030-2005 est utilisé par
- La Chine
- Le Tibet
- La Mongolie
- Partiellement la Thailande
Taiwan ne s'en sert pas à ma connaissance, mais c'est principalement pour bien montrer à la Chine qu'ils sont idépendants.
Après effectivement pour le Japon, la Corée, le Vietnam et partiellement la Thailande c'est de l'UTF-16 majoritairement pour les points unicode.
Les asiatiques survivrons à +50% (et j'ose la plaisanterie: en plus c'est eux qui fabriquent les disques durs et la RAM!).
Oui, si ca leur apporte quelque chose. UCS-2 apporte quelquechose à un occidental (et en plus il n'y a pas de caractères interdits en UCS-2) par rapport à ASCII ou ISO. Mais qu'apporte UTF-8 à un oriental par rapport à UTF-16 ?
[^] # Re: Bof
Posté par DerekSagan . Évalué à 1.
Ben si j'ai réussi ça, j'ai pas complètement perdu mon temps alors.
Parce que j'ai rien à dire dessus.
T'es contre l'utilisation d'UTF-8 partout et pour tout, donc t'es contre UTF-8. ;-)
UTF-8 c'est bon mangez-en.
Ben UCS-2 (ou UTF-16, parce que c'est pas loin d'être la même chose) apporte rien à un occidental par rapport à UTF-8 à part que ça prend plus de place en mémoire et sur les disques durs. (oui j'ai conscience d'alimenter un dialogue de sourds)
Et il y a des caractères interdits en UCS-2 (enfin des caractères réservés, qui justement rendent UTF-16 possible).
Sinon le fait de considérer que le Tibet et Taïwan ne font pas partie de la Chine n'est pas neutre politiquement, je suis sûr qu'à Pékin ce n'est pas ce qui se dit… ;-) Et c'est à Pékin qu'on écrit les normes. ;-)
[^] # Re: Bof
Posté par Kaane . Évalué à 0.
Parce que j'ai rien à dire dessus.
Dans ce cas tu es d'accord qu'un shell UTF-8 pur n'a de sens que si tout le monde utilise un shell UTF-8 pur depuis des années. Parceque sinon les problèmes évoqués sont pour le moins génant.
T'es contre l'utilisation d'UTF-8 partout et pour tout, donc t'es contre UTF-8. ;-)
Même avec le smiley, ca ne me fait pas trop rire. Comme tous les trucs qui deviennent des dogmes plutôt que des solutions techniques.
Ben UCS-2 (ou UTF-16, parce que c'est pas loin d'être la même chose) apporte rien à un occidental par rapport à UTF-8 à part que ça prend plus de place en mémoire et sur les disques durs. (oui j'ai conscience d'alimenter un dialogue de sourds)
UTF-16 et UCS-2 sont proches au niveau character map, mais au niveau du concept ca n'a rien à voir. En UCS-2 tout est sur deux octets et puis c'est tout. Alors que vache UTF-16 pour décoder une chaine il faut sortir la tronconneuse (et encore de gros efforts on été fait pour simplifier les boulot des devs par rapport aux premières versions, on est plus obligé de parser toute la chaine pour connaitre la valeur d'un caractère). Les high et les low surrogate c'est d'une lourdeur. Je veux extraire le 27ème caractère d'une chaine UCS-2, je fais un bon de 54 octets depuis le début la chaine. En UTF-8 ou 16….
Pas mal de programme utilisent UCS-2 en interne et n'utilisent UTF que pour le stockage et la lecture.
Et il y a des caractères interdits en UCS-2 (enfin des caractères réservés, qui justement rendent UTF-16 possible).
Non juste non utilisés pour faciliter le mapping. Mais tout à fait légaux, il ne correspondent juste pas à un glyphe.
Et c'est à Pékin qu'on écrit les normes. ;-)
Autant le Tibet d'accord, autant Taiwan les normes de Pekin….
[^] # Re: Bof
Posté par DerekSagan . Évalué à 1.
J'aime beaucoup ton plaidoyer pour UCS-2 et contre UTF-16, sachant que ça fait bien 4 ou 5 commentaires que tu fais en demandant UTF-16 au lieu d'UTF-8 pour le salut de l'Asie et que l'un de tes arguments contre UTF-8 en Asie était la longueur d'encodage des idéogrammes rares, lesquels sont simplement absents d'UCS-2.
Mélol!
[^] # Re: Bof
Posté par Kaane . Évalué à 0.
Bon c'est sans espoir apparament mais au cas ou :
a) Les asiatiques n'utiliseront pas UTF-X, et ils ne sont clairement pas fan d'unicode. L'unification des Han leur a filé des boutons. Les asiatiques veulent pouvoir faire la différence entre un signe avec une graphie chinoise et le même signe (au sens point unicode) avec uen graphie japonaise. Unicode ne permet pas cette distinction. Pour l'instant ils bricolent avec des polices différentes en fonction de l'encoding.
b) Si un jour les asiatiques venaient à utiliser un UTF-X de façon globale, (ce qui n'est clairement pas gagné) ca serait probablement plutôt UTF-16 pour des raisons de place gagné et de mapping 1-1 des anciens encodings.
c) Je me fous complètement que l'Asie utilise UTF-8/16 GB18030 ou tout autre encoding du moment que c'est à peu prêt cohérent. Quand je reçoit un document chinois de Chine, je sais qu'il va être en GB18030 et ca me va très bien.
d) Dans le cadre d'un shell ou du nommage des fichiers d'un FS, UCS-2 est un choix nettement plus intelligent que UTF-X. Certes certains caractères ne sont pas accessibles, mais au moins on a pas de caractères interdits dont on ne sait plus quoi foutre en cas de corruption de données. La plupart des programmes traitent d'ailleurs les chaines de caractères en UCS-2 en interne, parceque que c'est quand même nettement plus pratique.
e) Si mon opinion est que d'avoir un shell bloqué en UTF-8 ou UTF-16 est complètement con aujourd'hui (et probablement demain aussi, vu que la corruption de noms de fichiers peut toujours arriver même si la planête entière passe en UTF) Je n'ai rien contre UTF à l'intérieur d'un fichier. En fait du moment qu'un gentil meta m'indique l'encoding à utiliser je suis content.
[^] # Re: Bof
Posté par lolop (site web personnel) . Évalué à 3.
Pourtant, sur ce site, ils disent que ça fonctionne.
laurent@litchi:~$ echo "Héhé"Héhé
laurent@litchi:~$ konsole --version
Qt : 4.7.4
Plate-forme de développement de KDE : 4.7.4 (4.7.4)
Konsole : 2.7.4
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Trop bien !
Posté par kiki92 . Évalué à 2.
Je passe ma vie à mettre en veille ou rallumer mon laptop entre deux réunions, bureaux … Cet outil est juste indispensable !
[^] # Re: Trop bien !
Posté par Juke (site web personnel) . Évalué à 2.
Heu… L'outil a l'air sympa mais dans ton cas, que va t-il changé ?
[^] # Re: Trop bien !
Posté par DerekSagan . Évalué à 1.
Tu changes d'adresse IP quand tu passes en veille ?
[^] # Re: Trop bien !
Posté par Samuel Thibault (site web personnel) . Évalué à 4.
Entre deux réunions (wifi) et bureaux (filaire) et bâtiments (réseau), oui.
# Mobile IP
Posté par Samuel Thibault (site web personnel) . Évalué à 6.
Ce qui est triste, c'est que c'est une fonctionnalité que permettrait IPv6 en natif, s'il était plus poussé qu'actuellement: tu changes d'IP, pas de problème, SCTP (utilisé à la place de TCP) utilise la nouvelle IP à la place.
[^] # Re: Mobile IP
Posté par benoar . Évalué à 5.
Oui mais bon, malheureusement, tu rêves un peu trop.
Et tu as mélangé deux choses : la mobilité IPv6 et le multihoming dans SCTP, qui ont en gros le même but et font la même chose, mais à des niveaux différents. Bref, on aurait eu soit l'un, soit l'autre, ça aurait été, mais on n'en a finalement aucun des deux.
[^] # Re: Mobile IP
Posté par Samuel Thibault (site web personnel) . Évalué à 2.
Oups, je voulais dire multihoming, bien sûr, oui. Et oui, je sais bien qu'il ne faut pas rêver, ça n'a guère de chance d'aboutir.
# Couche de non-sécurité ??
Posté par Samuel Thibault (site web personnel) . Évalué à 9.
La partie cryptage des données sur UDP me paraît un peu légère.
L'article indique l'utilisation d'AES avec une clé secrète symétrique de 128bits.
L'implémentation est faite maison, car TLS ne supporte pas le roaming. Encore une implémentation à reviewer et débugguer.
Il n'y a apparemment pas de rekeying.
Je recommande donc très fortement de ne pas utiliser mosh pour des serveurs sensibles. Et notamment, surtout pas pour garder une même connexion sur une longue période (sic) vu qu'il n'y a pas de rekeying.
# Intéressant
Posté par mrr . Évalué à 2.
Apparemment, ça permettrai de rester connecté en cas de coupure temporaire de réseau ?
Dans ce cas là, ça risque d'être assez utile pour ceux qui se connectent depuis des points d'accès wifi foireux :-p
Envoyé depuis ma Debian avec Firefox
# Ça me parait bien violent Mosh
Posté par GouNiNi . Évalué à 0.
http://fr.wikipedia.org/wiki/Mosh
Les vidéos sur youtube à ce sujet valent le détours.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.