Posté par raphj .
Évalué à 5.
Dernière modification le 05 octobre 2020 à 19:16.
Mhm… un outil qui fournit des fonctionnalités habituelles d'un IDE risque d'être lent en réseau sans une architecture client / serveur comme celle qui est mentionnée dans ce lien. D'ailleurs, Emacs propose un système similaire.
D'ailleurs les binaires de VS Code ne sont pas libres non plus, mais on pourra utiliser https://github.com/VSCodium/vscodium/releases pour ça. Je crois d'ailleurs que l'extension présentée dans le lien n'est pas compatible avec VSCodium.
je t'avoue que je n'avais pas pensé à vérifier ces points là. Personnellement, j'utilise vim et mosh/tmux, donc Visual code (ou codium) n'est pas trop mon environnement.
C'est juste qu'ayant "trouvé" ce mode de fonctionnement, je me suis dit que ça pourrait intéresser certains devs/IT pour lesquels leurs collègues remontent des soucis avec x2go (ou VNC, ou RDP, ou autre protocole graphique à distance).
quant x2go est trop lent pour afficher une interface graphique de traitement de code, alors il y a peut être un problème avec cette "interface graphique de traitement de code", non ?
je ne suis pas en train de dire que x2go est la panacée, mais simplement que pour ce besoin c'est overkill, ça fait largement le job.
en tout cas aucun problème avec vim et son rc local long comme un bras
… peut être que emacs VStudio a un léger problème d'électron pas si libre ?
à mon boulot, on mixe x2go et VirtualGL. Et même ParaView n'est pas lent (bon, faut un bon GPU sur le serveur x2go).
Par contre, y'a un souci avec VSCode, pour qu'il fonctionne, il faut virer l'option qui permet à VirtualGL de bien fonctionner… Refusé ! C'est balot, non ?
Proverbe Alien : Sauvez la terre ? Mangez des humains !
Salut, dans mon labo on regarde à monter un serveur de virtu de postes de travail (x2go) avec un gros GPU partagé. Tu aurais des notes retour d'expé sur la mise en place de votre système ?
(ou un contact par email — laurent dot pointal arobase limsi dot fr).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Posté par Pierrick Bouvier .
Évalué à 1.
Dernière modification le 07 octobre 2020 à 09:53.
Je suis tout à fait d'accord avec toi.
En revanche, il y a des gens qui n'utilisent pas forcément un éditeur léger et/ou en terminal. Pour ma part, je ne fais que du vim/mosh/tmux, mais certains collègues utilisent uniquement vscode.
Posté par Psychofox (Mastodon) .
Évalué à 5.
Dernière modification le 06 octobre 2020 à 02:46.
Je ne suis pas sûr de comprendre l'intérêt…ça ressemble à une solution en recherche d'un problème.
Si j'ai un accès ssh à la machine, pourquoi utiliser une extension au lieu d'un auto sshfs par exemple ou gvfs?
Et puis si on utilise un ide, c'est qu'on veut éditer du code. Du coup celui-ci va finir dans un outil de gestion de version et à coup quasi sûr, décentralisé…du coup on bosse en local.
Posté par raphj .
Évalué à 2.
Dernière modification le 06 octobre 2020 à 12:57.
Un IDE va probablement essayer de lire une bonne partie de ton code source pour activer toutes ses fonctionnalités. Si le dépôt est gros, ça peut prendre du temps / demander beaucoup à ta connexion de le faire par SSH. Tu as intérêt à avoir une bonne connexion.
Et puis globalement il va certainement accéder aux fichiers en faisant la supposition qu'ils sont en local, ce qui peut ne pas être optimal.
Même un éditeur de texte simple peut galérer. Kate par exemple, s'il croit qu'il est en local, enregistre un fichier temporaire à côté de ton fichier à chaque frappe. À chaque frappe, tu envoies donc le contenu de ton fichier par SSH ! Pour avoir testé, ça ralentit un peu la saisie…
Imagine que ta machine perso est un vieux portable d'il y a 5 ans. Et que ta machine au boulot est un serveur avec 32 coeurs et 128go de ram. Non, tu ne veux pas utiliser ta machine perso pour indexer/construire ou faire quoique ce soit sur ton code (en dehors d'avoir une IHM pour l'éditer).
De deux, imagine que tu as un dépôt git assez gros, avec plusieurs dizaine de milliers de fichiers indexés. Bon courage pour bosser avec ça au dessus de sshfs. Je te dis ça, car c'est notamment ce que j'ai essayé avant de trouver ce mode "remote" de vscode. Et c'était la cata (pourtant, j'ai la fibre, et autre chose qu'un vieux portable à la maison).
Il y a donc un vrai intérêt à pouvoir bosser en distant "nativement" plutôt que monter un répertoire.
# Avec n'importe quel IDE / éditeur et sshfs
Posté par lolop (site web personnel) . Évalué à 2.
Sous les Unix ça doit le faire sans trop de problème.
Sous Windows faut tester (avec leur intégration récente WSL2).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Avec n'importe quel IDE / éditeur et sshfs
Posté par raphj . Évalué à 5. Dernière modification le 05 octobre 2020 à 19:16.
Mhm… un outil qui fournit des fonctionnalités habituelles d'un IDE risque d'être lent en réseau sans une architecture client / serveur comme celle qui est mentionnée dans ce lien. D'ailleurs, Emacs propose un système similaire.
Par contre attention, cette extension à Visual Studio Code n'est pas libre, elle est sous cette licence : https://code.visualstudio.com/preview-license
D'ailleurs les binaires de VS Code ne sont pas libres non plus, mais on pourra utiliser https://github.com/VSCodium/vscodium/releases pour ça. Je crois d'ailleurs que l'extension présentée dans le lien n'est pas compatible avec VSCodium.
[^] # Re: Avec n'importe quel IDE / éditeur et sshfs
Posté par Pierrick Bouvier . Évalué à 1.
Merci pour ces infos!
je t'avoue que je n'avais pas pensé à vérifier ces points là. Personnellement, j'utilise vim et mosh/tmux, donc Visual code (ou codium) n'est pas trop mon environnement.
C'est juste qu'ayant "trouvé" ce mode de fonctionnement, je me suis dit que ça pourrait intéresser certains devs/IT pour lesquels leurs collègues remontent des soucis avec x2go (ou VNC, ou RDP, ou autre protocole graphique à distance).
# x2go trop lent
Posté par bubar🦥 (Mastodon) . Évalué à 5.
quant x2go est trop lent pour afficher une interface graphique de traitement de code, alors il y a peut être un problème avec cette "interface graphique de traitement de code", non ?
je ne suis pas en train de dire que x2go est la panacée, mais simplement que pour ce besoin c'est overkill, ça fait largement le job.
en tout cas aucun problème avec vim et son rc local long comme un bras
… peut être que
emacsVStudio a un léger problème d'électron pas si libre ?[^] # Re: x2go trop lent
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 2.
à mon boulot, on mixe x2go et VirtualGL. Et même ParaView n'est pas lent (bon, faut un bon GPU sur le serveur x2go).
Par contre, y'a un souci avec VSCode, pour qu'il fonctionne, il faut virer l'option qui permet à VirtualGL de bien fonctionner… Refusé ! C'est balot, non ?
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: x2go trop lent
Posté par lolop (site web personnel) . Évalué à 2.
Salut, dans mon labo on regarde à monter un serveur de virtu de postes de travail (x2go) avec un gros GPU partagé. Tu aurais des notes retour d'expé sur la mise en place de votre système ?
(ou un contact par email — laurent dot pointal arobase limsi dot fr).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: x2go trop lent
Posté par Pierrick Bouvier . Évalué à 1. Dernière modification le 07 octobre 2020 à 09:53.
Je suis tout à fait d'accord avec toi.
En revanche, il y a des gens qui n'utilisent pas forcément un éditeur léger et/ou en terminal. Pour ma part, je ne fais que du vim/mosh/tmux, mais certains collègues utilisent uniquement vscode.
# l'intérêt?
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 06 octobre 2020 à 02:46.
Je ne suis pas sûr de comprendre l'intérêt…ça ressemble à une solution en recherche d'un problème.
Si j'ai un accès ssh à la machine, pourquoi utiliser une extension au lieu d'un auto sshfs par exemple ou gvfs?
Et puis si on utilise un ide, c'est qu'on veut éditer du code. Du coup celui-ci va finir dans un outil de gestion de version et à coup quasi sûr, décentralisé…du coup on bosse en local.
[^] # Re: l'intérêt?
Posté par blobmaster . Évalué à 2.
Parfois ton poste "local" est trop lent (un portable de flotte bureautique par exemple)
Pour compenser on te donne une grosse babasse mais distante.
Pour des raisons organisationnelles on peut se trouver dans ce genre de situation.
[^] # Re: l'intérêt?
Posté par raphj . Évalué à 2. Dernière modification le 06 octobre 2020 à 12:57.
Un IDE va probablement essayer de lire une bonne partie de ton code source pour activer toutes ses fonctionnalités. Si le dépôt est gros, ça peut prendre du temps / demander beaucoup à ta connexion de le faire par SSH. Tu as intérêt à avoir une bonne connexion.
Et puis globalement il va certainement accéder aux fichiers en faisant la supposition qu'ils sont en local, ce qui peut ne pas être optimal.
Même un éditeur de texte simple peut galérer. Kate par exemple, s'il croit qu'il est en local, enregistre un fichier temporaire à côté de ton fichier à chaque frappe. À chaque frappe, tu envoies donc le contenu de ton fichier par SSH ! Pour avoir testé, ça ralentit un peu la saisie…
[^] # Re: l'intérêt?
Posté par Pierrick Bouvier . Évalué à 2.
Oui et non.
Imagine que ta machine perso est un vieux portable d'il y a 5 ans. Et que ta machine au boulot est un serveur avec 32 coeurs et 128go de ram. Non, tu ne veux pas utiliser ta machine perso pour indexer/construire ou faire quoique ce soit sur ton code (en dehors d'avoir une IHM pour l'éditer).
De deux, imagine que tu as un dépôt git assez gros, avec plusieurs dizaine de milliers de fichiers indexés. Bon courage pour bosser avec ça au dessus de sshfs. Je te dis ça, car c'est notamment ce que j'ai essayé avant de trouver ce mode "remote" de vscode. Et c'était la cata (pourtant, j'ai la fibre, et autre chose qu'un vieux portable à la maison).
Il y a donc un vrai intérêt à pouvoir bosser en distant "nativement" plutôt que monter un répertoire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.