Avec la montée en puissance de la virtualisation, des PC dans le cloud et l'annonce de Windows 365, la possibilité d'accéder à son ordinateur à distance suscite l'intérêt. Pourtant, les technologies utilisées sont loin d'être nouvelles. On peut d'ailleurs exploiter de telles solutions de bien des manières. Tour d'horizon.
Avec la généralisation du Personal Computer (PC) dans les années 80/90, chaque foyer a commencé à être équipé de son propre ordinateur. Une machine alors composée d'un écran, d'un clavier, d'une souris (à boule à l'époque) et de la fameuse unité centrale (UC). Une tour plus ou moins imposante contenant les composants.
Un ensemble qui paraît classique aujourd'hui, l'intégration étant allée plus loin avec les ordinateurs « tout-en-un », portables et autres smartphones : écran et UC sont alors « fusionnés ». Pourtant, le PC était une révolution à l'époque.
Car pendant longtemps, l'informatique s'est développée dans des centres de recherches et grandes entreprises, à travers les mainframes. Des ordinateurs qui pouvaient occuper une pièce entière et constituaient alors l'unité centrale. Près de 60 ans après les débuts du S/360 d'IBM, en 1964, ils existent toujours.
On y accédait à travers des terminaux spécifiques. C'est d'ailleurs de cette période que sont issues les consoles qui permettent de taper des lignes de commandes, toujours très utilisées par les développeurs et autres bidouilleurs.
Un opérateur et son terminal, face à un IBM S/360 Model 91 à la NASA, fin des années 60
L'informatique est comme l'Histoire : un cycle qui se reproduit
Assez ironiquement, l'évolution technologique nous a mené à reproduire une situation similaire à travers le « cloud ». La puissance informatique est à nouveau concentrée dans de très larges ordinateurs, organisés cette fois en datacenters et reliés (ensemble) au réseau Internet. On peut les utiliser pour héberger des données, effectuer de lourds calculs, et pourquoi pas y déporter un PC complet. C'est le principe de Windows 365 et de Shadow.
Des dispositifs que l'on peut reproduire de manière plus locale, à l'échelle d'une entreprise ou d'un foyer. L'ordinateur que l'on utilise peut ainsi être une sorte de coquille (presque) vide, permettant d'accéder à une machine plus puissante sur le réseau, potentiellement virtualisée. On accède alors à une console, à la manière des mainframes, via des outils tels que SSH... et pourquoi pas à l'interface de bureau complète, 3D incluse.
Pour cela, un simple logiciel ou un Raspberry Pi suffit parfois. On vous explique comment faire.
Shadow : un datacenter, un client léger et les périphériques habituellement connectés à un PC
La puissance à distance pour les nuls : RDP et Windows 10 Pro
L'accès au bureau à distance est proposé par une galaxie de solutions logicielles plus ou moins complètes, visant en général les entreprises et reposant parfois sur des protocoles propriétaires, comme TeamViewer. Mais il en existe bien d'autres comme AnyDesk, GoToMyPC, Splashtop et toute la galaxie de clients/serveurs VNC.
Ce dernier a par exemple été choisi par Scaleway pour sa location de Mac Mini M1, Jump Desktop pouvant être utilisé en tant que client pour accéder au son et à l'accélération 3D/Multimédia. Pour Azure Virtual Desktop et Windows 365, Microsoft a opté pour sa solution maison, exploitant le Remote Desktop Protocol (RDP) et les Remote Desktop Services (RDS) qui permettent de donner accès à votre machine à un tiers. L'ensemble est ainsi intégré autour d'un portail en ligne et du compte Microsoft. Une manière de faire spécifique, efficace.
Elle l'est d'ailleurs tout autant pour réaliser votre propre Windows 365 à la maison ou au bureau en utilisant la fonctionnalité prévue à cet effet dans Windows 10. Ce peut être pour demander à un proche ou à une entreprise de vous dépanner, mais aussi pour déporter l'accès à certaines machines physiques ou virtuelles.
Prenons un exemple plus concret et que vous pourriez mettre en œuvre. Il faut tout d'abord disposer d'une machine dont vous voulez partager l'accès. Seule contrainte : elle doit être un minimum performante pour que ce soit intéressant (4 cœurs CPU ou plus) et utiliser l'édition Professionnelle de Windows 10, seule à la proposer.
Dans notre cas, il s'agit d'une station de travail ThinkStation P620 de Lenovo équipée d'un Ryzen Threadripper Pro W3975WX. On pourrait faire de même avec un simple PC ou un serveur tel que le HPE ProLiant DL365 Gen10 Plus v2 que nous avons au labo. Nous l'utiliserons d'ailleurs plus loin avec un objectif un peu différent.
On donne comme nom « TRPro » à la machine sur le réseau, on créé un compte utilisateur puis on active l'accès distant dans les paramètres système. Nous avions consacré un guide complet à ces étapes :
Une fois ceci fait, toute machine du réseau local peut accéder au bureau de la station de travail après une authentification. Notez que si elle dispose d'une IPv6 et d'un accès Internet, n'importe quelle machine en ligne peut théoriquement y accéder. Par sécurité, Microsoft active néanmoins des règles dans son pare-feu natif pour l'empêcher. Il est bien entendu conseillé de relier tous les appareils au réseau via des câbles plutôt qu'en Wi-Fi.
Passons au client. Ici, on peut se contenter d'une machine minimale. Il lui faut simplement une partie graphique moderne lui permettant de gérer matériellement la plupart des codecs vidéo et proposer un affichage fluide. On parle alors de client léger (thin client).
Dans notre cas, il s'agit d'un mini PC HeroBox de Chuwi, des machines que l'on trouve aux alentours de 200 euros. Pour ce premier essai, elle fonctionne telle que livrée, sous Windows 10 (Famille), et se connecte à travers l'application Connexion bureau à distance intégrée au système. Cette dernière permet d'utiliser un ou deux écrans et de partager avec la machine des ressources locales : dossiers, imprimantes, périphériques, etc.
Avantage principal de cette solution : l'application est multiplateforme. Elle existe aussi en version UWP sur le Microsoft Store pour Windows 10, chez Apple sur le Mac App Store, pour iOS et sur le Play Store pour Android. Vous pouvez donc avoir une expérience similaire sur différents postes (nous parlerons de Linux un peu plus loin).
La configuration de la station de travail (à gauche), l'application d'accès sur le client léger (à droite)
La connexion est simple : on tape le nom de la machine distante du le réseau (TRPro), puis on est invité à s'identifier à travers le nom d'utilisateur et son mot de passe. Des confirmations sont demandées, après quoi on accède à la machine comme si elle était branchée directement aux moniteurs, avec un bon niveau de performances.
Comme nous l'avons évoqué dans notre test de Windows 365, cette méthode a néanmoins ses limites. En effet, on peut utiliser une carte graphique pour du calcul (via CUDA, OpenCL ou autre) mais pas lancer d'application 3D exploitant DirectX, seuls OpenGL/Vulkan peuvent être exploités. Les performances sont suffisantes pour des applications de rendu 3D avec un viewport par exemple, telles que Blender, 3DSMax, Maya, etc. Mais il est impensable d'utiliser ce dispositif pour du jeu vidéo, la compression étant trop forte dans de tels usages.
Pour la lecture de vidéos, dans cette configuration locale nous n'avons pas rencontré de soucis. Nous avons ainsi pu lancer du contenu YouTube en 1080p sur un écran en 2560x1080 pixels sans décalage du flux audio. Sur un second, nous avons lu une vidéo Netflix sans le moindre problème (10 à 18 Mb/s de bande passante occupés au total).
Il en va de même pour des outils de vidéoconférence, le partage des casque/micro en USB se faisant sans problème. Cela permet par exemple de placer la station de travail dans une pièce et d'y accéder depuis un autre. De quoi déporter le bruit et la chauffe, ou même permettre de s'y connecter depuis différents postes dans le cas d'une entreprise par exemple, de manière locale ou à distance (via une redirection de port, un VPN, etc.).
Simplifiez-vous la vie
Il y a quelques astuces pratiques à connaître. Si vous vous connectez souvent à différentes machines, vous pouvez épingler l'application de bureau à distance à la barre des tâches. D'un clic droit sur son icône vous aurez ainsi accès à la liste des derniers serveurs auxquels vous vous êtes connectés récemment pour y accéder plus rapidement.
À l'inverse, si vous vous connectez toujours à la même machine depuis un client léger, vous pouvez enregistrer les paramètres de connexion (comme dans la capture plus haut) pour générer un fichier ayant pour extension .rdp. Vous pourrez lancer une connexion d'un double-clic, ou même le placer dans le dossier Démarrage du menu Démarrer afin qu'il soit lancé dès que la machine arrive sous Windows. Elle affichera directement le bureau du PC distant.
Vous pouvez ouvrir ce dossier en exécutant (touche Windows + R) la commande shell:startup. Il suffit d'y déplacer le fichier .rdp. Il est également accessible à travers le chemin suivant :
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
La virtualisation, alliée de l'accès distant
Il y a un autre cas où il peut être intéressant de favoriser l'accès distant : celui de l'accès à des machines virtuelles (VM). Nous avons ainsi installé Proxmox Virtual Environment 7.0 sur le serveur HPE ProLiant DL365 Gen10 Plus v2 pour y créer plusieurs VM sous Windows 10/11 Pro avec l'accès bureau à distance activé.
On peut les lancer et y accéder selon les besoins (par exemple pour tester plusieurs versions du système). Elles peuvent aussi constituer différents postes utilisés en entreprise, avec la possibilité de faire évoluer à la volée leur niveau de performances selon les employés et leurs besoins.
On pourrait imaginer une installation similaire dans un cadre familial avec un serveur regroupant des machines virtuelles pouvant être lancées à travers des PC ultra-compacts placés dans plusieurs pièces, avec un niveau de performances (vCPU, stockage, mémoire) évoluant là aussi selon les besoins.
Et pourquoi pas du jeu, puisque même les GeForce de NVIDIA gèrent le passthrough désormais (il faut alors utiliser un autre outil d'accès distant, nous y reviendrons plus loin). Cela permet une certaine évolutivité dans le temps, tout en évitant d'avoir à acheter plusieurs machines classiques ou performantes.
De quoi « vendre » à votre moitié l'intérêt de monter un « Home Lab » à la maison ?
Thin client : une diversité de solutions
Il n'est pas nécessaire d'opter pour un PC sous Windows pour accéder à un serveur gérant un partage d'écran. Certains constructeurs fournissent des gammes de clients légers, comme Dell, HP ou encore Lenovo, mais il y a aussi des solutions plus spécialisées et multi-protocoles proposées par certaines sociétés.
Elles permettent de se connecter via RDP, des solutions Citrix ou autres, se reposant le plus souvent sur une distribution Linux avec une couche logicielle optimisée pour ces besoins. Elles prennent parfois la forme de « Zero client » qui n'ont aucun système embarqué, celui-ci se chargeant à la demande via le réseau et PXE.
On pense notamment à 10Zig, Chip PC ou NComputing, ce dernier proposant des clients légers basés sur des Raspberry Pi, comme son RX420(RDP) vendu aux alentours de 200 euros, qui se base sur un Raspberry Pi 4 sous Leaf/OS, gérant jusqu'à deux écrans, compatible avec Microsoft Azure Virtual Desktop (AVD), les Remote Desktop Services (RDS), Verde VDI et Remote PC Access ou encore vSpace Pro.
Un Raspberry Pi 4, un boîtier, un OS « maison » et hop : vous avez votre client léger multi-protocoles
D'autres se concentrent sur la vente d'une solution logicielle, comme WTware (de 40 à 15 euros par poste, dégressif selon le nombre de poste) ou ThinLinx qui est un peu plus raisonnable (de 5 à 15 dollars par poste selon le type de client léger utilisé). Dans les deux cas, des offres d'essais sont proposées.
Ce peut être une bonne occasion de réutiliser d'anciennes machines.
Créez votre propre client léger sous Linux
Ainsi, vous pouvez aussi le faire vous-même. Il suffit pour cela d'installer une distribution comme Debian, Solus, Ubuntu ou Raspberry Pi OS (Lite ou Desktop). Nous avons opté pour cette dernière en version Lite pour constater les limites d'un Raspberry Pi 4 dans un tel contexte et les éventuelles optimisations possibles.
Une fois le système installé et la machine connectée (clavier, souris, écran et réseau), on commence par les habituelles premières commandes pour changer le mot de passe par défaut, configurer le système selon nos besoins (langue, clavier, nom sur le réseau, accès SSH, etc.) et le mettre à jour :
sudo passwd
sudo raspi-config
sudo apt update && sudo apt full-upgrade && sudo apt autoremove
On installe ensuite les outils nécessaires. Ici on opte pour l'environnement de bureau LXDE (utilisé par défaut dans Raspberry Pi OS Desktop, mais avec de nombreuses applications préinstallées). Puis le client FreeRDP qui nous servira à nous connecter à la machine distante via le protocole RDP :
sudo apt install lxde freerdp2-x11
On peut alors vérifier que tout fonctionne en se connectant (CTRL+ALT+Entrée pour quitter le plein écran) :
xfreerdp /v:nom_machine /u:nom_utilisateur /p:mot_de_passe /f /floatbar:sticky:off,default:hidden,show:fullscreen /multimon /dynamic-resolution /bpp:32 /rfx /gfx:AVC420 /network:auto /sound:sys:alsa
Si tout va bien, on peut passer à l'étape suivante, qui consiste à créer un script global permettant de lancer la connexion à la machine distante au démarrage du système, comme s'il s'agissait de la machine locale :
echo xfreerdp /v:nom_machine /u:nom_utilisateur /p:mot_de_passe /f /floatbar:sticky:off,default:hidden,show:fullscreen /multimon /dynamic-resolution /bpp:32 /rfx /gfx:AVC420 /network:auto /sound:sys:alsa > freerdplaunch.sh
chmod +x freerdplaunch.sh
sudo mv freerdplaunch.sh /usr/bin/
On édite alors le fichier de configuration du gestionnaire de connexion, LightDM :
sudo nano /etc/lightdm/lightdm.conf
Dans la section [Seat:*] il faut décommenter trois lignes pour obtenir le résultat suivant (quittez avec CTRL+X) :
autologin-user=pi
autologin-user-timeout=0
display-setup-script=freerdplaunch.sh
Cela permet au Raspberry Pi de se connecter directement avec l'utilisateur Pi. Une fois LXDE lancé, le script sera automatiquement initialisé et vous devriez voir le bureau distant s'afficher. Vous pouvez bien entendu modifier les paramètres de FreeRDP pour ajouter des dossiers locaux partagé et autres périphériques USB par exemple.
Dernière étape de la procédure redémarrer le Raspberry Pi :
sudo reboot
Cette solution ne sera pas la plus performante, notamment lorsqu'il s'agit de lire du contenu multimédia. Nous avons ainsi systématiquement constaté des saccades avec des usages de type YouTube ou Netflix. Mais elle est de loin la moins coûteuse et la plus simple, largement suffisante pour un usage bureautique.
Pour disposer de fonctionnalités supplémentaires – et à moins d'opter pour des couches logicielles spécifiques comme SuperRDP chez NComputing – il est préférable de se tourner vers des clients légers disposant d'une partie graphique plus performante. Nous n'avons ainsi pas constaté le même phénomène sur le mini PC Chuwi.
Profiter de la carte graphique dans les jeux : à vous de choisir
Reste une possibilité que nous n'avons pas explorée : pouvoir jouer en exploitant la carte graphique du PC distant. Pour cela, il existe plusieurs possibilités, comme le Remote Play de Steam qui nécessite d'utiliser l'application côtés client et serveur, compatible avec Game Stream de NVIDIA. Mais lors de nos tests, nous avons relevé des pertes de performances pouvant être importantes.
Il existe d'autres alternatives comme Moonlight, un projet open source et multiplateforme qui se focalise uniquement sur les cartes de NVIDIA. AMD propose de son côté la fonctionnalité Link qui permet une diffusion entre deux machines équipées d'une partie graphique maison, ou une TV avec un appareil Android/iOS.
Au final, c'est Parsec qui semble toujours offrir le dispositif (Freemium) le plus simple et le plus complet. Le serveur doit être sous Windows 10 (Famille ou Pro), un compte est nécessaire, mais les performances sont bonnes, il existe des clients pour différentes plateformes et les GPU d'AMD et NVIDIA sont gérés. Vous pouvez inviter des gens à suivre ce que fait votre machine via un lien et une interface web, ou effectuer un partage complet via le client.
Seule « petite » contrainte : une souris doit être reliée au serveur pour voir le curseur s'afficher côté client.
Parsec propose de nombreuses options de performances, qualité, etc.
Commentaires (55)
#1
Merci pour cet article !
“Pour cela, il existe plusieurs possibilités, comme le Remote Play de Steam qui nécessite d’utiliser l’application côtés client et serveur, compatible avec Game Stream de NVIDIA. Mais lors de nos tests, nous avons relevé des pertes de performances pouvant être importantes.”
De quelle pertes de performances parlez-vous exactement et sur quel matériel avez-vous testé Remote Play ?
#2
Quand tu compares la performance native de la carte graphique avec celle obtenue lorsque l’accès distant est activé, tu peux avoir des écarts élevés (testé sur des GeForce, mais pas les dernières Ampere, ce qui ne devrait pas changer grand chose en pratique). C’est un peu le souci de la solution Steam historiquement (avec le fait que ce soit peu pratique vu que c’est pensé pour du partage de jeu plutôt que de bureau même si c’est possible en pratique). Je ferai des relevés sur la dernière génération à l’occasion
#3
Il y a 25 ans, si l’on m’avait dit que l’avenir était au Terminal X, je ne l’aurait pas cru ! Le monde est un éternel recommencement.
#4
Je reviens sur la mention de Parsec : Si on a pas d’accès direct a la machine sous Windows en remote desktop, comment on peut par exemple rentrer ses identifiants/se connecter ( Dans le cas par exemple d’un Windows 11 où il faudra obligatoirement un compte Microsoft ? )
#5
Il y a de vraies choses qui ne changent jamais, comme l’outrance dans la simplification ;) Sur le fond, j’adorerai que la structure des distributions Linux permette un partage aisé du bureau avec accélération matérielle sur une machine distante en multiplateformes. Mais c’est loin d’être le cas.
Parsec permet une “installation partagée” qui donne notamment accès à l’écran de connexion. Par contre Windows 11 n’impose pas de compte MS. C’est seulement le cas dans la version Famille (à voir ce comment ce sera implémenté en pratique), comme c’est déjà le cas en intégration sur W10.
#6
Merci pour ces précisions, je ne l’ai jamais remarqué pourtant j’y joue quasi quotidiennement et sur une carte “ancienne” (1080 TI), il y a quelques options disponibles de mémoire spécifiques aux cartes NVIDIA dans les options de l’hôte Remote Play. Je testerai à l’occasion Parsec.
J’espère qu’à l’usage c’est aussi simple qu’avec Remote Play parce que je trouve cette fonctionnalité géniale et assez bien intégrée dans Steam.
Dans un autre registre sous des distributions Linux dérivées de Debian ou Red Hat je trouve que Remmina est simple à utiliser et plutôt performant comme client RDP.
#7
léger HS: pour proxmox, la “console” de la VM, vous arrivez a avoir une résolution en full HD ?
J’ai un soft de lecture audio qui freeze quand je coupe la session RDP a cause du changement de résolution… :/
#8
Pour prendre la main sur un window via linux, j’utilise tout les jours rdesktop qui est un très bon client rdp léger et sans perte de latence.
#9
Oui c’est une alternative à FreeRDP (qui est un fork de rdesktop à l’origine), et il fallait bien en choisir l’un des deux. Note qu’il n’a plus de mainteneur depuis 2019 et qu’il n’y a pas eu de nouvelle version depuis la 1.9.0.
#10
Super article comme d’habitude.
Pourtant, je suis 100% contre ce phénomène de clients/serveurs.
J’ai bien testé Shadow et j’en retiens que ce genre de service est très cher et n’apporte rien que de multiplier les problèmes.
Idem pour l’industrie. Apres des années de clients légers qui ont finalement disparus car on les délaisse pour trouver un vrai PC, je ne suis pas sûr que notre service IT recommence avec ce concept.
Car la limite est bien présente.
Pourquoi configurer son poste, son poste virtuel, son poste « deporté » et subir les problèmes sur son client léger, sur son espace virtuel et sur le serveur ?
C’est trop lourd.
A la maison, j’ai recyclé mon vieux PC qui date de 2010 et ma femme est ravie car c’est une tour, ça marche bien. Et ça ne nous a coûté q’un ensemble écran, clavier, souris.
Mon PC est une bête de course pour la vidéo et le jeux vidéos et hors de question de deporter quoi que ce soit.
J’ai testé Shadow comme mis plus haut et c’est vraiment pas pour moi.
Installer en distants des mises à jour, des drivers, ne pas avoir accès par moment. Non vraiment c’est NON
#11
Ca c’est cool, je ne savais pas pour le coup !
Et pour l’obligation du compte MS sous Win10, rien a l’horizon pour l’instant ( Je tourne encore sur un 20H2 )
Mais du coup, y’aura pas de moyen d’outrepasser ca dans Windows 11 ? Ou du moins, sans trifouiller ?
#12
Pour le compte MS il faut juste ne pas connecter l’ordinateur au réseau pendant l’étape de configuration au 1er démarrage. C’est très idiot comme obligation on est d’accord.
#13
Comme dit, le dispositif est déjà en place sur Windows 10 sur les machines en intégration. On verra comment ce sera implémenté/contournable dans Windows 11. Mais demander des réponses avant la sortie de la version finale ne sert à rien : on ne peut pas y répondre.
Toutes les solutions présentées ici sont locales ;) On peut les implémenter via Internet, ou pas, selon ses besoins. Comme toujours : penser qu’un règle est plus valable qu’une autre n’a aucune pertinence. L’intérêt des solutions diversifiées est dans la capacité de choisir l’une ou l’autre selon le besoin
#14
Je m’étais intéressé à Shadow à ses débuts, mais en calculant vite faite, je me suis rendu compte que c’était beaucoup trop cher par rapport à avoir son propre ordinateur que je peux faire évoluer progressivement, en plus j’ai découvert Parsec qui fonctionne vraiment bien + OpenVPN pour la connexion à distance sécurisé.
Par contre, je me vois mal payer un abonnement Parsec mensuel pour accéder localement à ma propre machine
#15
Parsec est gratuit pour une utilisation sur ta propre machine (comme précisé dans l’article). Seules des fonctionnalités complémentaires sont payantes (mais elles ne sont pas nécessaire à l’accès distant.
#16
Oui, j’utilise la version gratuite, mais je parle pour avoir accès au double écran et au mode de couleur 4:4:4, qui sont les seul vrai avantage de l’abonnement pour mon usage
#17
Oui c’est toujours un équilibre difficile à trouver que de financer des applications qui demandent de grosses équipes et des centaines d’heure de travail, avec une base d’utilisateurs qui ne veulent pas toujours payer. Mais face à des solutions “tout en un” à la Shadow on est quand même bien contents d’avoir des alternatives multi-marques/plateformes. Mais le curseur n’est pas toujours simple à placer.
#18
Les limites du RDP?
Les avantages du RDP?
#19
Je ne faisais pas allusion à Linux, mais plutôt à Solaris que j’utilisais à l’époque. Et sur les mêmes TX, on pouvait aussi se connecter à des serveurs Windows, par Citrix. Bien sûr il n’y avait pas d’accélération 3D ; la Voodoo 1 était à peine sortie chez les PC, et il n’y avait pas d’affichage distant sur la SGI Indigo.
#20
Les pb remontés par wackyuseb existeront aussi en local, au final ça apporte beaucoup de complexités pour quasiment aucun avantage.
Question licence : Windows 10pro permet plusieurs connexions simultanées ? (De mémoire avec XP pro c’était une (ou deux ?) connexions à la fois, pour passer la limite il fallait acheter WIndows 2003 server)
Ça ce n’est pas une appli client serveur, c’est une appli client (mal codée) qui utilise une base de données distante :) Un client / serveur fait ses requêtes en local (càd sur le serveur), et se content d’envoyer le résultat au client.
Sinon 100% d’accord avec le reste du message :) Assez peu d’avantages et beaucoup d’emmerdes sur des trucs a priori banals.
#21
Au risque de me répéter, les avis péremptoires n’ont aucun intérêt. Il n’y a pas de bon ou de mauvais usage, seulement des besoins et des solutions plus ou moins adaptées. Certains voudront avoir autant de serveurs que de Raspberry Pi, d’autres voudront densifier dans un serveur unique, certains en profiteront pour aussi avoir des VM Windows avec accès bureau, etc.
Il y a des soucis dans toute approche. Avoir un PC par poste Windows plutôt que des VM n’est pas toujours l’approche la plus pertinente. Tout dépend du besoin. Et il ne faut jamais confondre nos besoins propres ou ceux de notre foyer/entreprise/expérience avec l’expression de généralités.
C’est un seul utilisateur à la fois par VM
#22
tu peux avoir le client le mieux réalisé qui soit, quand la requête utilisateur est “je veux tout les devis/contrats/documents depuis X années” ta réponse mettra 15 ans à arriver chez ton utilisateur en remote, aussi bien préparée soit-elle.
Et c’est pas une exception, ça s’appelle “un ERP”.
Sans compter qu’une connexion distante amène d’autres soucis qu’une simple baisse de débit : latence, gigue, perte de paquets… Il vaut mieux parfois privilégier la perte de ton écran de VM quelques instants que de voir une requête mal envoyée/reçue et foirer un enregistrement dans ton logiciel de compta.
Au taf on utilise les deux solutions : VPN ou rdp. les utilisateurs avec la fibre n’ont pas trop de soucis avec le vpn, les utilisateurs en adsl préfèrent de loin le rdp.
Le RDP apporte beaucoup d’avantages pour pas tant d’emmerdes que ça (sérieusement le paramétrage du RDP sur un serveur Windows c’est quelques clics pour activer et la sécurisation se fait via GPO du domaine).
#23
Salut,
j’utilise de temps en temps nomachine, que je trouve très pratique, vous l’avez testé ?
ou c’est basé sur une appli que vous avez testée ?
#24
Pour ce que ca vaut, moi je m’en sers chez moi, pour plusieurs raisons.
Déjà c’est le plus rapide que j’ai pu trouver, ensuite sur Linux en fonction des DE, certains protocoles de RDP passent mal (X2Go par exemple ne passe pas bien avec Plasma).
Perso, NoMachine basé sur le proto NX, j’approuve. C’est pas forcement évident à prendre en main, mais c’est super robuste.
#25
Freenx passe mal chez toi? Perso j’ai toujours utilisé ça.
Après il est vrais que derrière j’ai toujours utilisé un bureau léger sans effet 3D, donc pas du kde. (mate/xfce)
#26
Va voir la compatibility checklist de X2Go. Perso j’utilisais ca avant, pour accéder à mon NAS qui était en DE léger.
J’ai voulu le faire sur mon nouveau NAS qui est sur un DE lourd (Plasma), et c’est là que j’ai appris que X2Go a des soucis de compatibilité. Bien dommage d’ailleurs, parce que X2Go quand ca marche, c’est excellent
#27
En pro, je plussoie. Sans compter que déployer une appli pour 200 utilisateurs, quand ça se résume à snapshoter la VM, passer la màj et rebooter, c’est idéal.
Par contre, RDP a toujours ce bug en France: la touche Alt-Gr est mal gérée et parfois on ne peut plus faire @ ou | sur sa session. Il faut aller dans tous les RDP et faire un Alt-gr+ quelquechose, revenir sur sa session pour que ça se débloque.
Signalé x fois à Ms depuis 2007. Comme c’est intermittent, la réponse est “le client ne sait pas reproduire le problème”.
#28
Perso le problème du Alt Gr semble arriver plus souvent avec la console des VM HyperV. Switcher d’une VM au bureau me causait quasi tout le temps ce problème mais pas depuis une session rdp. Mais oui usant.
#29
Ouep je sais j’avais vu pour kde et tout bureau “grahique”.
D’un autre côté quelle idée de mettre un bureau du style de kde pour une utilisation à distance. :/
#30
Effectivement, les distro linux ne mettent pas forcément en place ce genre de chose. D’autre part:
#31
Bonjour à tous,
Nous utilisons la virtualisation des postes de travail depuis un peu plus de 10 ans.
Il s’agit de serveur avec KVM (libvirt/virt-manager) avec des scripts perso, nos terminaux sont des Nuc alléger (pas de SSD, et 2gb de RAM), l’os du nuc est un linux from scratch fait en Interne.
Le protocole est spice à la place du RDP (plus facile pour la gestion des IP et les USB).
Si nous avons eu beaucoup de septique au départ, la solution est finalement bien acceptée par les utilisateurs et la direction.
C’est super pratique, avec un sysprep, on réinstalle un poste en 5 min.
Niveau performance (100 postes virtuel), on ne voit pas la différence.
Gros gain en télétravail évidement.
Les coûts de licences Windows sont conséquentes, mais on y gagne sur la consommation électrique et la gestion du parc.
L’inconvénient majeur est l’accélération 3d.
#32
A distance la plupart du temps, pour les fonctions de pur NAS ; mais en direct de temps en temps, il a un écran dédié (bon, un 19” de merde qui traînait). Et il a un dual boot aussi.
#33
Oui mais du coup pourquoi mettre kde pour une faible utilisation en directe?
#34
Parce que j’aime bien.
Gnome c’est insupportable pour moi, Cinnamon je n’aime pas. Unity en son temps, n’en parlons même pas.
XFCE, pourquoi pas encore.
Disons que c’est aussi à la fois pour soutenir KDE, et pour harmoniser mes pratiques, chacun ses habitudes. J’aime bien kate, j’aime bien amarok, etc. Quand je bidouille dans les fichiers de config du DE, je trouve la structure de KDE bien mieux faite que les autres.
Alors oui je sais je pourrais installer mes softs aussi sur d’autres DE, mais ca installerait en même temps tout un tas de fichiers de framework qui ne serviraient à rien d’autre, ca alourdirait le bousin.
#35
ça je peux comprendre, mais quand il s’agit de prendre la main à distance clairement plus c’est léger mieux c’est d’où ma question. :)
Je dissocie les deux perso, un usage local d’un usage distant.
#36
Ouais mais c’est chiant, il faut gérer les mises à jour sur les deux, etc.
Sachant qu’en plus j’ai encore un windows là dessus pour ma copine, ca ferait 3 trucs à gérer, sans compter mes raspberry, mon laptop, celui de ma compagne, mon fixe, etc.
#37
Je rencontre se problème depuis Win8 je crois, y compris en local. J’ai jamais fait attention si j’avais un ou plusieurs RDP en cours à ce moment là… Si tu fermes tous les RDP avant de “corriger” le bug clavier, t’es foutu et il faut reboot ?
#38
Si tu fermes les RDP, je crois qu’il suffit d’en rouvrir un pour te débloquer … sauf si tu as un caractère avec Alt-Gr dans le mot de passe :)
Une utilisatrice avait cliqué sur le bouton “Affichage en 3D” de géoportail sur son client léger… Geoportail était alors inutilisable (bon, un vidage des cookies suffit bien sûr). Mais sinon, peu de 3D dans la plupart des entreprises. ET les graph 3D d’Excel passaient bien (la 3D d’openoffice, elle, était vachement gourmande)
#39
ça m’arrive aussi, alt + 064 est ton ami dans ce cas
#40
sinon essayer d’utiliser Ctrl ou Alt séparément, Alt Gr étant la combinaison des deux. J’ai l’impression que le bug de MS et de “désappuyer” la touche qu’il pense bloquée quand on fait Alt Gr et du coup des fois faire Alt ou Ctrl + 0 me donne le @.
#41
J’ai quelque poste qui ont de besoins spécifique (autocad, cartographie).
L’accélération 3d manque pour le travail de mes collèges.
Ducoup quelque poste normaux sont toujours présent.
Nous utilisons libreoffice mais aucun signalement sur un problème à ce niveau
#42
Si ca m’arrive à nouveau j’essaierai ça !
Quand mon ALT GR ne fonctionne plus, j’utilise CTRL+ALT.
#43
J’ai géré du TSE et du Citrix. Citrix pour 160 sites avec peu d’utilisateurs (1, 2) et des serveurs centralisés au siège, et des postes au siège. TSE pour 80 sites avec une bonne grosse 20aine d’employés chacun et donc un serveur local car les liens (ADSL) ne suffisaient pas.
Disons que quand c’est local, on s’en sort bien. Dès que ça devient distant et qu’il y a des impressions à faire, ou des messages vidéos diffusés par la direction générale on arrive dans des difficultés parfois épiques.
De même pour le partage de fichiers.
Quand on est dans la sphère microsoft, il y a plein de technos (branchcache, et des pilotes de pseudo imprimante) mais peu de prestataire les connaissent et si ça m’éclate de mettre ce genre de chose en place, mes collègues … moins… Sans compter que ces technos sont si peu mises en avant qu’on se demande si elles ne vont pas disparaître.
En tout cas, je trouve plus facile à gérer du citrix/TSE que l’utilisation de O365 (onedrive et sites sharepeoint synchronisés dans tous les sens, pas de pilotage de la synchro possible -> effet avalanche le matin pendant 45 minutes avec le lien ADSL saturé de téléchargement vers les serveurs Ms)
Je pense que pour des sites satellites, la session distante a encore de beaux atouts face au cloud en SAAS (bien sûr, une VM dans le cloud me va très bien aussi)
#44
Parsec vient visiblement d’être racheté par unity. Donc reste à voir ce que ça va donner dans le futur de ce côté là…
#45
Unity doit sans doute viser le même marché qui était celui de Parsec : les professionnels de la 3D et du JV avec des fonctions collaboratives. Leurs modèles sont d’ailleurs assez proche : outil grand public gratuit (open source dans le modèle d’Unity) avec une clientèle qui finance du côté de l’offre Pro. S’il y a du changement, je doute que ce soit dans le mauvais sens, mais on verra :)
#46
Je connais plutôt bien le sujet des ERP, vu que je suis architecte technique sur SAP. Tous les contrats depuis x années, c’est absolument instantané avec SAP S/4 HANA : le résultat est instantané (base de données en RAM + stockage par colonnes), la “limite” c’est le volume du résultat.
Si il y’a quelques mégas / giga de résultats il faut compter le temps de “downloader” le résultat, c’est rarement un pb car si ce volume de données est trop gros cela devient inexploitable côté utilisateur.
L’astuce est d’avoir une GUI suffisamment ergonomique pour que l’utilisateur ne soit pas tenter de tout mettre dans Excel pour faire lui-même ses requêtes. Un “drill down” dans ce cas marche parfaitement : tu affiches le total des contrats / devis / commandes, puis l’utilisateur est libre de choisir ses propres critères de sous-totaux (par secteur géographique / par type de produits / par années…) à chaque modif, c’est une requête qui ne renvoie que le résultat contenant les sous-totaux agrégés (donc 100% instantanée), Si à force de “forer” dans les données il arrive au niveau des documents unitaires il aura en naviguant défini involontairement des critères de recherche assez précis qui délimitent le volume de données (et donc affichage 100% instantané également)
Et comme je le disais sur le modèle client / serveur il n’y a qu’une requête du client et une réponse du serveur à chaque action, sur cet exemple de drill down en client / server il sera toujours plus rapide de ne télécharger que les données et de gérer le rendu en local, que de transporter l’image même très bien compressée) du résultat (diagramme camembert ou résultat tabulaire).
#47
Super Article. A distance ces logiciels sont utiles. Par contre en interne je préfère la technologie HDbaseT.
#48
Ah mais je ne doute pas qu’on puisse faire les choses bien, mais on peut aussi les faire très mal et on sait tous pertinemment qu’une fois les mauvaises habitudes prises dans une entreprise c’est cramé
Et puis je plaide coupable, notre ERP est développé en interne… Par une seule personne… Pour un effectif d’environ 150 utilisateurs. Oui c’est l’idée du siècle.
#49
à une époque (~ 10 ans :‘( ) j’avais une machine perso sous debian, et il m’arrivait de m’y connecter depuis un windows via RDP et ça fonctionnait très bien pour mes besoins de bricolage.
bon vu la machine (un athlon 64 même pas x2) avec 2go (peut-être 4 mais pas certain) de ram à travers une connexion ADSL, j’avoue ne jamais avoir essayé de la vidéo et encore moins du jeu.
mais pour pouvoir ouvrir des ports sur ma box c’était pratique
#50
Oui donc c’est ce que je pensais, l’ergo doit-être (un peu) pourrave, donc certains utilisateurs ont pris l’habitude de tout extraire pour ensuite agréger dans Excel.
HS : Ce genre d’ “ERP” peut assez facilement être connecté à un outil de BI.
#51
#52
C’est beau :) Et très rare …
Le problème, c’est les applis qui ont été créées (souvent avec des ORM ou équivalents) de cette façon: pour voir les produits commandés:
1-Le client télécharge la liste des commandes et
2-Pour chaque commande le client récupère la liste des lignes et
3-Pour chaque ligne il récupère les infos du produit
-> produit cartésien.
Dans ce cas, l’écroulement des perfs est énorme si le lien entre le client et le serveur a de la latence.
Et pour les petites applis, c’est souvent le cas…
#53
Oui je ne comprends pas toutes tes remarques, je ne suis qu’utilisateur de PC et avant de clients leger Citrix ou Suse.
De mon point de vue, il n’y a que des désavantages.
Même le service IT a abandonné quand ils ont du « faire un geste pour la planète » avec la réduction CO2, la facture électrique des serveurs, baisser la puissance calorifique des clims de la salle serveur, récupérer le Gaz des installations etc…
Remettre des serveurs ultra costaud pour faire du RDP alors qu’un PC portable c’est quasi rien en consommation d’énergie, j’avoue, je ne comprends pas l’intérêt. D’autant qu’on devient dépendant de l’accès internet obligatoire dans ce cas !?
Je prend le train ou l’avion, rien ne m’empêche de préparer des dossiers offline.
#54
je pinaille juste sur la partie “geste pour la planète” potentiellement foireux :
entre un client léger (imaginons 10w pour un pi + 30w pour un écran 24” (je compte large) ) et un serveur qui bouffe 600w quand 40 personnes sont connectées (là c’est du pur pifomètre)
et un portable (15-25w de proc +15-20w pour l’écran +5w pour le disque ou autres joyeusetés, je soupçonne que le portable du boulot tourne dans les 50⁄60 car c’est un modèle “pour joueur” à la base, mais des portables plus simples consomment probablement moins) et un gros NAS quand même (80w ? pifomètre aussi)
c’est pas aussi significatif, par contre en télétravail, la conso se fait chez les employés et pas dans les locaux de la boite, là c’est significatif
sans compter si les portables sont accompagnés d’écrans externes ou de disques ou …
si en plus on prend en compte que le client léger va réellement être arrêté hors des horaires de boulot, (donc conso zéro, et charge serveur diminuée donc conso diminuée aussi), alors que potentiellement le portable va peut-être rester allumé (consultation de mails perso à 21h par exemple, ou “flemme de tout relancer le lendemain”) ça peut encore changer les résultats de la conso totale
c’était juste pour dire que l’argument “pour la planète” peut dépendre de beaucoup de choses et n’est pas forcément à opposer à du RDP avec client léger + gros serveur ;)
#55
Densifier sera toujours plus efficace. Après c’est un savoir-faire et la part qui reste locale ou pas dépend du besoin. Comme dit plus haut, ce sera essentiel dans certains cas, désastreux pour d’autres.
Mais il ne faut pas croire qu’une techno est mauvaise parce qu’elle est parfois mal implémentée. Après tant que l’informatique jetable restera dans les mœurs, avec des coûts déportés, on sera tenté de penser que c’est un bon choix.