La société qui en est à l'origine, NoMachine avait libéré en GPL la majorité du code en 2003, mais le serveur est resté propriétaire. Une implémentation libre du serveur existe depuis 2004 dans le projet FreeNX mais elle est écrite dans un mélange de Bash, d'expect et de C ce qui pour Google la rend difficile à maintenir.
Il y a quelques semaines, Google a donc sorti un nouveau serveur NX sous GPLv2, Neatx, majoritairement écrit en python.
Aller plus loin
- L'annonce sur le blog open source de Google (53 clics)
- La page du projet (93 clics)
- DLFP : l'annonce de la libération par NoMachine en 2003 (62 clics)
- FreeNX (28 clics)
- Présentation au format pdf du serveur Neatx (27 clics)
# Chrome OS
Posté par claudex . Évalué à 10.
« 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
# Ça pour une nouvelle ..
Posté par Skunnyk (site web personnel) . Évalué à 6.
J'espère que cela ne proposera pas trop de problèmes avec FreeNX et que les 2 pourront travailler ensemble pour avoir le meilleurs code possible (FreeNX fonctionnant déjà très bien même pour un usage 'pro').
La seule fonctionnalité qui me manquerait actuellement serait de pouvoir reprendre une session déjà ouverte en local (un peu comme RDP), mais je ne sais pas si c'est techniquement possible.
De plus j'avais entendu parlé/trollé d'une possible intégration de NX dans Xorg, est ce que cela est toujours d'actualité ? (si quelqu'un à des infos).
Ps: Apparement pour le moment il n'y a pas encore de release téléchargeable ? (uniquement le svn).
[^] # Re: Ça pour une nouvelle ..
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
C'est disponible dans la version propriétaire gratuite de NoMachine (type de connexion shadow), ça ne marche pas trop mal sur les dernières versions.
[^] # Re: Ça pour une nouvelle ..
Posté par dems . Évalué à 2.
[^] # Re: Ça pour une nouvelle ..
Posté par Skunnyk (site web personnel) . Évalué à 4.
Mais si vous avez la technique pour ce que je demande, n'hésitez pas à partager !
[^] # Re: Ça pour une nouvelle ..
Posté par Olivier (site web personnel) . Évalué à 8.
J'ai présenté une conférence sur la prise en main à distance l'année dernière. Les transparents sont ici : http://olivieraj.free.fr/fr/linux/information/prise_en_main_(...)
PDF : http://olivieraj.free.fr/fr/linux/information/prise_en_main_(...)
La partie sur x11vnc : http://olivieraj.free.fr/fr/linux/information/prise_en_main_(...)
En mode "xtightvnc" (lancé depuis le client), la prise en main sur une machine reliée à l'ADSL est assez fluide (80-90% de ce que l'on ressent sur une machine locale)
[^] # Re: Ça pour une nouvelle ..
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Ça pour une nouvelle ..
Posté par Olivier (site web personnel) . Évalué à 6.
C'est l'usage parfait pour, à distance, montrer quelque chose à l'utilisateur local.
Tant que le programme "x11vnc" est lancé, l'utilisateur à distance peut interagir
Sur ma passerelle Linux, les (rares) fois où j'ai besoin de lancer une application graphique à distance, je passe par un x11vnc. Le fait de fermer la session distante, puis d'y revenir plus tard, ne ferme pas les applications précédemment lancées (exactement comme un "screen" en ligne de commande).
Les inconvénients de x11vnc :
- il faut qu'un serveur X soit lancé : consommation de mémoire et de CPU
- si on veut avoir plusieurs personnes connectés sur la même machine, il faut à chaque fois un serveur X différent.
- ne peut pas fonctionner si personne n'a ouvert de session X: Si l'écran affiche uniquement un kdm/gdm/xdm/etc, alors la prise en main graphique à distance ne marche pas.
Conclusion : Cela ne fait pas du tout le même boulot que du NX. Mais pour une utilisation mono utilisateur, cela marche très bien.
[^] # Re: Ça pour une nouvelle ..
Posté par psychoslave__ (site web personnel) . Évalué à 6.
[^] # Re: Ça pour une nouvelle ..
Posté par phoenix (site web personnel) . Évalué à 3.
[^] # Re: Ça pour une nouvelle ..
Posté par patrick_g (site web personnel) . Évalué à 10.
Donc c'est presque que du Python.
[^] # Re: Ça pour une nouvelle ..
Posté par Jakie Kasperwsky . Évalué à 4.
Python + C est un concept d'avenir et plutôt intelligent. C'est quelque chose qui se fait de plus en plus dans le calcul scientifique notamment.
Écrire en C les parties qui ont des contraintes de performance et combiner l'utilisation de ces libraires dans du code en python.
Comme ça tu gagnes en lisibilité et tu ne perds presque rien en performance, parce que la partie python est essentiellement de la glue.
[^] # Re: Ça pour une nouvelle ..
Posté par Yakulu . Évalué à 2.
[^] # Re: Ça pour une nouvelle ..
Posté par VoixOff . Évalué à 10.
Voila voila.
[^] # Re: Ça pour une nouvelle ..
Posté par Octabrain . Évalué à 2.
[^] # Re: Ça pour une nouvelle ..
Posté par caouis . Évalué à 1.
Sinon j'ai était voir la page du projet et j'ai une petite question, quelle sont les différences avec Rpython (langage d'implémentation de Pypy ) ? est ce que le sous ensemble utilisable est plus clairement spécifié ?
[^] # Re: Ça pour une nouvelle ..
Posté par Frédéric COIFFIER . Évalué à 4.
http://mail.kde.org/pipermail/freenx-knx/2009-April/008111.h(...)
Certains développeurs ont eu exactement la même idée que Google, de leur côté :
http://mail.kde.org/pipermail/freenx-knx/2009-April/008115.h(...)
https://launchpad.net/tacix
[^] # Re: Ça pour une nouvelle ..
Posté par Panda Voyageur (site web personnel, Mastodon) . Évalué à 3.
Le point de départ de neatx était justement la branche freenx-redesign (le dev principal de freenx + 2-3 employés de google). Depuis, freenx est un peu mort (pas de nouvelles du dev depuis novembre), et ceux de Google ont donc continué "dans leur coin". Comme déjà cité, freenx est difficile à maintenir et à faire évoluer, et je vois neatx comme son successeur/remplaçant.
Ps: Apparement pour le moment il n'y a pas encore de release téléchargeable ? (uniquement le svn).
Il y a la 0.3.0 et la 0.3.1 mais elles sont déjà marquées "deprecated" ;)
# NX est…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
En fait, ce sont deux choses :
- un protocole de compression d'X11, très simple à utiliser avec un « proxy NX » qui encapsule et décapsule à chaque bout, à la ss -X ;
- un serveur overkill pour faire de la session à distance.
[^] # Re: NX est…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: NX est…
Posté par rictus (site web personnel) . Évalué à 8.
[^] # Re: NX est…
Posté par phoenix (site web personnel) . Évalué à 2.
[^] # Re: NX est…
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: NX est…
Posté par yellowiscool . Évalué à 1.
Envoyé depuis mon lapin.
[^] # Re: NX est…
Posté par nodens . Évalué à 3.
Rien à faire, on installe les paquets et ça tourne... Il y a même le shadowing de session locale qui marche (mais c'est pas aussi rapide et pratique que les sessions NX classique, surtout si on a des résolutions différentes entre les deux postes, ou si on utilise plusieurs écrans).
[^] # Re: NX est…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
[^] # Re: NX est…
Posté par rictus (site web personnel) . Évalué à 2.
A voir, si ça peut se scripter, mais ça correspond bien à ce que je souhaitais avoir (déporter de manière mieux compressée l'affichage de quelques fenêtres graphiques sans avoir à transporter un bureau entier, ni avoir à installer freenx trop usine à gaz pour moi).
[^] # Re: NX est…
Posté par TortuXm . Évalué à 4.
Par contre j'ai suivi bêtement les instructions que tu avais rédigées, et j'avais l'erreur
Warning: X connection failed with error 'No protocol specified'.à chaque fois que j'essayais de lancer une commande graphique.
J'ai donc remplacé
poste_distant$ xauth add poste_distant/unix:0 MIT-MAGIC-COOKIE-1 bba945268dab0548c74c32fcf483e703par
poste_distant$ xauth add poste_distant/unix:8 MIT-MAGIC-COOKIE-1 bba945268dab0548c74c32fcf483e703C'est-à-dire le port 8 au lieu de 0. Je pense qu'il doit s'agir d'une erreur dans ton tutorial, ou nos versions de nxproxy ne fonctionnent pas pareil.
Je vais essayer de faire un petit programme qui automatise tout ça pour avoir une version facile à mettre en oeuvre.
[^] # Re: NX est…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Une erreur ? Quelle erreur, mon tuto parle bien de :8… ;-)
Bon, sérieusement, merci, c'est corrigé.
[^] # Re: NX est…
Posté par TortuXm . Évalué à 2.
C'est fait à la main vite fait, si quelqu'un a des suggestions pour améliorer ça, n'hésitez pas !
Sur le poste distant, il faut avoir un fichier batch, je l'ai appelé setup_nx
#! /bin/sh
COOKIE=$(echo "$1" | sed s/HOSTNAME/$(hostname)/)
nxproxy -C link=adsl localhost:8 &
xauth add $COOKIE $2 $3 $4 $5
export DISPLAY=":8"
xterm
Sur le poste client, j'ai un fichier batch ssh_nx :
#! /bin/sh
COOKIE=$(xauth list | grep $(hostname) | sed s/$(hostname)/HOSTNAME/ | sed s/unix:0/unix:8/)
echo $COOKIE
nxproxy -S &
sleep 2
echo $COOKIE
ssh -f -R localhost:4008:localhost:4008 $1 "/chemin/setup_nx $COOKIE"
Les deux gros problèmes qui me restent sont :
× je dois tuer le processus ssh du client "à la main" à la fin de ma session
× je dois appeler xterm (ou un autre terminal graphique), parce que je n'ai pas trouvé de moyen simple de lancer des commandes et en même temps d'avoir un pseudo terminal.
Une option que je vois (qui résoudrait les deux problèmes) est de changer le shell de mon utilisateur, mais je n'aime pas cette option...
Si vous avez des suggestions, je suis preneur.
[^] # Re: NX est…
Posté par fred . Évalué à 2.
J'ai modifié le script proposé pour n'avoir besoin que d'un script coté local, ssh_nx :
#! /bin/sh
if [ $# -lt 2 ]; then
echo "Usage: $(basename $0) [compte@]machine commande"
echo "Exemple: $(basename $0) fred@mamachine xclock -update 1"
exit 1
fi
adresse=$1
shift
machineL=$(hostname)
machineD=$(echo $adresse | sed -e 's/^.*@//')
COOKIE=$(xauth list | grep $machineL | sed -e s/$machineL/$machineD/ -e s/unix:0/unix:8/)
echo "COOKIE='$COOKIE'"
nxproxy -S timeout=60 &
nxprocessL=$!
ssh -x -R localhost:4008:localhost:4008 $adresse " \
set -x -e ;
nxproxy -C link=adsl localhost:8 &
nxprocessD=\$! ;
xauth add $COOKIE ;
export DISPLAY=:8 ;
$* ;
kill -HUP \$nxprocessD ;
xauth remove $machineD:8 ;
rm -f /tmp/.X11-unix/X8
"
# au cas où
kill -HUP $nxprocessL 2>/dev/null
[^] # Re: NX est…
Posté par TortuXm . Évalué à 2.
Je n'avais pas pensé à mettre envoyer commandes à ssh...
# Et le client ?
Posté par GnunuX (site web personnel) . Évalué à -1.
[^] # Re: Et le client ?
Posté par eupalynos . Évalué à 9.
# Question et question
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Question subsidiaire : Google va-t'il pousser à l'intégration dans Xorg et dans ssh.
Autre question : NX peut faire proxy VNC ou RDP. C'est très pratique pour atteindre une machine à l'intérieur de son parc mais je ne sais pas faire "simplement" avec du proxy NX ! En gros, il est plus facile depuis chez soi en ADSL d'atteindre via un serveur ssh ou il y a NX son poste de boulot Windows (RDP) que son poste Linux (X) !
# Comparaison
Posté par XioNoX . Évalué à 3.
# Ne pas oublier xrdp !
Posté par William Steve Applegate (site web personnel) . Évalué à 2.
Au chapitre des problèmes, le serveur X11rdp est casse-pieds à compiler, la redirection du son ne marche pas à ma connaissance, et les environnements de bureau ne peuvent pas faire la différence avec un serveur X standard (les machines Windows détectent que la session tourne sous RDP et dégagent un certain nombre d'effets graphiques comme le fond d'écran pour accélérer l'affichage).
En revanche, pouvoir se connecter chez soi depuis n'importe quel PC sans installer de soft supplémentaire (un coup de mstsc, et zou !), c'est très appréciable...
Envoyé depuis mon PDP 11/70
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.