Sous Panther, peut-on prendre le contrôle d'un utilisateur actif en
arrière-plan avec Timbuktu ou Remote Desktop ? (et en particulier
peut-on lancer une application et l'exploiter ?).
Corrolaire : la vitesse d'Airport-extrême permettrait-elle de travailler
"à distance" d'une part en réseau local et d'autre part via Internet
haut débit ? Où se situeraient les goulots d'étranglement voire les
incompatibilités ou impossibilités ?
L'idée serait d'installer sur un mac "rapide" gavé de RAM et d'espace
disque des applis gourmandes et de les exploiter depuis une machine à
performances modestes (portable voire PC puisque Timbuktu est
cross-plateforme). Est-ce impensable ?
Sous Panther, peut-on prendre le contrôle d'un utilisateur actif en arrière-plan avec Timbuktu ou Remote Desktop ? (et en particulier peut-on lancer une application et l'exploiter ?).
Avec Remote Desktop, pas testé, mais avec Timbuktu c'est pas possible. Timbuktu 6 n'est pas compatible Fast user switching, timbuktu 7 l'est mais ils disent bien :
Timbuktu Pro supports Fast User Switching on Mac OS X Panther. When you change users or log in as an additional user, all incoming and outgoing Timbuktu Pro connections are closed. You may immediately reconnect any Timbuktu Pro service.
Donc apparemment, quand tu te connectes via TB2 sur une machine sous Panther, tu ne peux prendre le contrôle que de l'utilisateur au premier plan, et si tu fermes la session le contrôle à distance cesse.
Corrolaire : la vitesse d'Airport-extrême permettrait-elle de travailler "à distance" d'une part en réseau local et d'autre part via Internet haut débit ?
Airport extrême en local : aucun problème, la vitesse est largement suffisante. En haut débit, ça fonctionne aussi avec une bonne vitesse (meilleure sous timbuktu que Remote desktop je trouve, bien que je n'ai pas essayé les dernières versions de remote desktop).
Où se situeraient les goulots d'étranglement voire les incompatibilités ou impossibilités ?
Les goulots d'étranglement sont surtout le débit ascendant de la connexion sur les deux machines (128 kbps sur du haut débit classique). En se connectant en noir et blanc ou en 256 couleurs tu es presque en vitesse réelle (comme si tu étais réellement devant la machine). Bien entendu faut pas compter utiliser un jeu en OpenGL avec un taux de rafraîchissement correct...
L'idée serait d'installer sur un mac "rapide" gavé de RAM et d'espace disque des applis gourmandes et de les exploiter depuis une machine à performances modestes (portable voire PC puisque Timbuktu est cross-plateforme). Est-ce impensable ?
C'est ce que plein de gens font déjà. Enormément de serveurs sont "headless" (sans écran) et on s'y connecte via timbuktu ou sous windows via le contrôle à distance. J'ai un 9600 qui tourne comme ça depuis des mois et que je contrôle en local ou via internet, je pourrais aussi le faire via un modem en réponse automatique par timbuktu, j'avais fait sur un IIsi qui faisait serveur mail (contrôle en appletalk).
-- le guide de la Mémoire vive : <http://gilles.aurejac.free.fr/ramguide> A floppy-based Mac Plus web server <http://aurejac.dyndns.org>
Gerald <Gerald@alussinan.org> wrote:
Sous Panther, peut-on prendre le contrôle d'un utilisateur actif en
arrière-plan avec Timbuktu ou Remote Desktop ? (et en particulier
peut-on lancer une application et l'exploiter ?).
Avec Remote Desktop, pas testé, mais avec Timbuktu c'est pas possible.
Timbuktu 6 n'est pas compatible Fast user switching, timbuktu 7 l'est
mais ils disent bien :
Timbuktu Pro supports Fast User Switching on Mac OS X Panther.
When you change users or log in as an additional user, all
incoming and outgoing Timbuktu Pro connections are closed. You
may immediately reconnect any Timbuktu Pro service.
Donc apparemment, quand tu te connectes via TB2 sur une machine sous
Panther, tu ne peux prendre le contrôle que de l'utilisateur au premier
plan, et si tu fermes la session le contrôle à distance cesse.
Corrolaire : la vitesse d'Airport-extrême permettrait-elle de travailler
"à distance" d'une part en réseau local et d'autre part via Internet
haut débit ?
Airport extrême en local : aucun problème, la vitesse est largement
suffisante.
En haut débit, ça fonctionne aussi avec une bonne vitesse (meilleure
sous timbuktu que Remote desktop je trouve, bien que je n'ai pas essayé
les dernières versions de remote desktop).
Où se situeraient les goulots d'étranglement voire les
incompatibilités ou impossibilités ?
Les goulots d'étranglement sont surtout le débit ascendant de la
connexion sur les deux machines (128 kbps sur du haut débit classique).
En se connectant en noir et blanc ou en 256 couleurs tu es presque en
vitesse réelle (comme si tu étais réellement devant la machine). Bien
entendu faut pas compter utiliser un jeu en OpenGL avec un taux de
rafraîchissement correct...
L'idée serait d'installer sur un mac "rapide" gavé de RAM et d'espace
disque des applis gourmandes et de les exploiter depuis une machine à
performances modestes (portable voire PC puisque Timbuktu est
cross-plateforme). Est-ce impensable ?
C'est ce que plein de gens font déjà. Enormément de serveurs sont
"headless" (sans écran) et on s'y connecte via timbuktu ou sous windows
via le contrôle à distance. J'ai un 9600 qui tourne comme ça depuis des
mois et que je contrôle en local ou via internet, je pourrais aussi le
faire via un modem en réponse automatique par timbuktu, j'avais fait sur
un IIsi qui faisait serveur mail (contrôle en appletalk).
--
le guide de la Mémoire vive : <http://gilles.aurejac.free.fr/ramguide>
A floppy-based Mac Plus web server <http://aurejac.dyndns.org>
Sous Panther, peut-on prendre le contrôle d'un utilisateur actif en arrière-plan avec Timbuktu ou Remote Desktop ? (et en particulier peut-on lancer une application et l'exploiter ?).
Avec Remote Desktop, pas testé, mais avec Timbuktu c'est pas possible. Timbuktu 6 n'est pas compatible Fast user switching, timbuktu 7 l'est mais ils disent bien :
Timbuktu Pro supports Fast User Switching on Mac OS X Panther. When you change users or log in as an additional user, all incoming and outgoing Timbuktu Pro connections are closed. You may immediately reconnect any Timbuktu Pro service.
Donc apparemment, quand tu te connectes via TB2 sur une machine sous Panther, tu ne peux prendre le contrôle que de l'utilisateur au premier plan, et si tu fermes la session le contrôle à distance cesse.
Corrolaire : la vitesse d'Airport-extrême permettrait-elle de travailler "à distance" d'une part en réseau local et d'autre part via Internet haut débit ?
Airport extrême en local : aucun problème, la vitesse est largement suffisante. En haut débit, ça fonctionne aussi avec une bonne vitesse (meilleure sous timbuktu que Remote desktop je trouve, bien que je n'ai pas essayé les dernières versions de remote desktop).
Où se situeraient les goulots d'étranglement voire les incompatibilités ou impossibilités ?
Les goulots d'étranglement sont surtout le débit ascendant de la connexion sur les deux machines (128 kbps sur du haut débit classique). En se connectant en noir et blanc ou en 256 couleurs tu es presque en vitesse réelle (comme si tu étais réellement devant la machine). Bien entendu faut pas compter utiliser un jeu en OpenGL avec un taux de rafraîchissement correct...
L'idée serait d'installer sur un mac "rapide" gavé de RAM et d'espace disque des applis gourmandes et de les exploiter depuis une machine à performances modestes (portable voire PC puisque Timbuktu est cross-plateforme). Est-ce impensable ?
C'est ce que plein de gens font déjà. Enormément de serveurs sont "headless" (sans écran) et on s'y connecte via timbuktu ou sous windows via le contrôle à distance. J'ai un 9600 qui tourne comme ça depuis des mois et que je contrôle en local ou via internet, je pourrais aussi le faire via un modem en réponse automatique par timbuktu, j'avais fait sur un IIsi qui faisait serveur mail (contrôle en appletalk).
-- le guide de la Mémoire vive : <http://gilles.aurejac.free.fr/ramguide> A floppy-based Mac Plus web server <http://aurejac.dyndns.org>
fra
Gilles Aurejac wrote:
En se connectant en noir et blanc ou en 256 couleurs tu es presque en vitesse réelle
C'est un réglage du logiciel ou faut changer le réglage du système ? -- Fra
Gilles Aurejac <gilles@alussinan.org> wrote:
En se connectant en noir et blanc ou en 256 couleurs tu es presque en
vitesse réelle
C'est un réglage du logiciel ou faut changer le réglage du système ?
--
Fra
C'est un réglage du logiciel ou faut changer le réglage du système ?
Logiciel, c'est mieux
Gerald
Gilles Aurejac wrote:
Donc apparemment, quand tu te connectes via TB2 sur une machine sous Panther, tu ne peux prendre le contrôle que de l'utilisateur au premier plan, et si tu fermes la session le contrôle à distance cesse.
J'en déduis que Timbuktu n'ouvre pas un "shell" véritable sur le serveur mais se contente d'un gros hack de l'interface utilisateur ! Berk ! peut mieux faire (mais ceci dit c'est peut-être dépendant du système qui, lui non plus, ne le permet en fait pas !) Pour Remote Desktop, sous réserve d'un miracle qui pourrait être décrit par quelqu'un qui l'utilise, je crois que la réponse est contenue dans le nom : dans sa description, Apple ne parle que d'un contrôle à distance du *finder* ! "L'administration" se bornant à quelques options de visualisations multiples et de copie/installation. Là encore, on ne "visualise" apparemment que ce qui est en avant-plan.
MacOSX Server offrirait-il quelques options de meilleur goût ? Ou y aurait-il des pistes du côté de X-11 ?
Cette histoire de FastUser Switching dans Panther est en effet beaucoup plus lourde de conséquences (qui ne sont encore que potentielles !) qu'un simple effet de "cube" qui garderait en mémoire l'état d'une configuration. Ce qui est vraiment important c'est que les utilisateurs *en arrière-plan* continuent de travailler comme si de rien n'était ou quasi ! En partage de fichier on accède sans problème à des utilisateurs non "connectés" et je ne comprends pas que si on peut lancer une appli en avant plan on ne le puisse pas en arrière-plan. Tiens : est-ce qu'un AppleScript "temporisé" se lancerait seul en arrière-plan ? Le courrier se relève-t-il en arrière plan ?
Je ne parle évidemment pas des cron et d'Unix CLI qui, si j'ai bien compris, le permettent et de manière sécurisée en plus !
C'est ce que plein de gens font déjà. Enormément de serveurs sont "headless" (sans écran) et on s'y connecte via timbuktu ou sous windows via le contrôle à distance.
Y compris pour lancer des applis et les utiliser ? (même au ralenti). J'imagine qu'il y a des limites : pourrait-on, par exemple, via AIrport en local ou pas, lancer un navigateur web à distance ? Les seules limites sont-elles bien :
- le débit et toutes ses conséquences sur l'affichage écran ou sur le temps réel (audio-images) - un seul user accessible à la fois (en avant-plan, donc) ?
Cette histoire de "mono-user" distant ne serait-elle pas là pour éviter qu'on puisse être plusieurs à utiliser un même logiciel protégé ? (par exemple par dongle).
-- Gérald
Gilles Aurejac <gilles@alussinan.org> wrote:
Donc apparemment, quand tu te connectes via TB2 sur une machine sous
Panther, tu ne peux prendre le contrôle que de l'utilisateur au premier
plan, et si tu fermes la session le contrôle à distance cesse.
J'en déduis que Timbuktu n'ouvre pas un "shell" véritable sur le serveur
mais se contente d'un gros hack de l'interface utilisateur ! Berk ! peut
mieux faire (mais ceci dit c'est peut-être dépendant du système qui, lui
non plus, ne le permet en fait pas !) Pour Remote Desktop, sous réserve
d'un miracle qui pourrait être décrit par quelqu'un qui l'utilise, je
crois que la réponse est contenue dans le nom : dans sa description,
Apple ne parle que d'un contrôle à distance du *finder* !
"L'administration" se bornant à quelques options de visualisations
multiples et de copie/installation. Là encore, on ne "visualise"
apparemment que ce qui est en avant-plan.
MacOSX Server offrirait-il quelques options de meilleur goût ? Ou y
aurait-il des pistes du côté de X-11 ?
Cette histoire de FastUser Switching dans Panther est en effet beaucoup
plus lourde de conséquences (qui ne sont encore que potentielles !)
qu'un simple effet de "cube" qui garderait en mémoire l'état d'une
configuration. Ce qui est vraiment important c'est que les utilisateurs
*en arrière-plan* continuent de travailler comme si de rien n'était ou
quasi ! En partage de fichier on accède sans problème à des utilisateurs
non "connectés" et je ne comprends pas que si on peut lancer une appli
en avant plan on ne le puisse pas en arrière-plan. Tiens : est-ce qu'un
AppleScript "temporisé" se lancerait seul en arrière-plan ? Le courrier
se relève-t-il en arrière plan ?
Je ne parle évidemment pas des cron et d'Unix CLI qui, si j'ai bien
compris, le permettent et de manière sécurisée en plus !
C'est ce que plein de gens font déjà. Enormément de serveurs sont
"headless" (sans écran) et on s'y connecte via timbuktu ou sous windows
via le contrôle à distance.
Y compris pour lancer des applis et les utiliser ? (même au ralenti).
J'imagine qu'il y a des limites : pourrait-on, par exemple, via AIrport
en local ou pas, lancer un navigateur web à distance ? Les seules
limites sont-elles bien :
- le débit et toutes ses conséquences sur l'affichage écran ou sur le
temps réel (audio-images)
- un seul user accessible à la fois (en avant-plan, donc) ?
Cette histoire de "mono-user" distant ne serait-elle pas là pour éviter
qu'on puisse être plusieurs à utiliser un même logiciel protégé ? (par
exemple par dongle).
Donc apparemment, quand tu te connectes via TB2 sur une machine sous Panther, tu ne peux prendre le contrôle que de l'utilisateur au premier plan, et si tu fermes la session le contrôle à distance cesse.
J'en déduis que Timbuktu n'ouvre pas un "shell" véritable sur le serveur mais se contente d'un gros hack de l'interface utilisateur ! Berk ! peut mieux faire (mais ceci dit c'est peut-être dépendant du système qui, lui non plus, ne le permet en fait pas !) Pour Remote Desktop, sous réserve d'un miracle qui pourrait être décrit par quelqu'un qui l'utilise, je crois que la réponse est contenue dans le nom : dans sa description, Apple ne parle que d'un contrôle à distance du *finder* ! "L'administration" se bornant à quelques options de visualisations multiples et de copie/installation. Là encore, on ne "visualise" apparemment que ce qui est en avant-plan.
MacOSX Server offrirait-il quelques options de meilleur goût ? Ou y aurait-il des pistes du côté de X-11 ?
Cette histoire de FastUser Switching dans Panther est en effet beaucoup plus lourde de conséquences (qui ne sont encore que potentielles !) qu'un simple effet de "cube" qui garderait en mémoire l'état d'une configuration. Ce qui est vraiment important c'est que les utilisateurs *en arrière-plan* continuent de travailler comme si de rien n'était ou quasi ! En partage de fichier on accède sans problème à des utilisateurs non "connectés" et je ne comprends pas que si on peut lancer une appli en avant plan on ne le puisse pas en arrière-plan. Tiens : est-ce qu'un AppleScript "temporisé" se lancerait seul en arrière-plan ? Le courrier se relève-t-il en arrière plan ?
Je ne parle évidemment pas des cron et d'Unix CLI qui, si j'ai bien compris, le permettent et de manière sécurisée en plus !
C'est ce que plein de gens font déjà. Enormément de serveurs sont "headless" (sans écran) et on s'y connecte via timbuktu ou sous windows via le contrôle à distance.
Y compris pour lancer des applis et les utiliser ? (même au ralenti). J'imagine qu'il y a des limites : pourrait-on, par exemple, via AIrport en local ou pas, lancer un navigateur web à distance ? Les seules limites sont-elles bien :
- le débit et toutes ses conséquences sur l'affichage écran ou sur le temps réel (audio-images) - un seul user accessible à la fois (en avant-plan, donc) ?
Cette histoire de "mono-user" distant ne serait-elle pas là pour éviter qu'on puisse être plusieurs à utiliser un même logiciel protégé ? (par exemple par dongle).
-- Gérald
fra
Jérôme Lebel wrote:
C'est un réglage du logiciel ou faut changer le réglage du système ?
Logiciel, c'est mieux
Ouaip. merci. -- Fra
Jérôme Lebel <jeromelebel@mac.com> wrote:
C'est un réglage du logiciel ou faut changer le réglage du système ?
C'est un réglage du logiciel ou faut changer le réglage du système ?
Logiciel, c'est mieux
Ouaip. merci. -- Fra
Schmurtz
J'en déduis que Timbuktu n'ouvre pas un "shell" véritable sur le serveur mais se contente d'un gros hack de l'interface utilisateur ! Berk ! peut mieux faire (mais ceci dit c'est peut-être dépendant du système qui, lui non plus, ne le permet en fait pas !)
C'est exactement son principe de fonctionnemnt : apporter une copie d'écran à distance.
MacOSX Server offrirait-il quelques options de meilleur goût ? Ou y aurait-il des pistes du côté de X-11 ?
Oui, mais uniquement avec les applications X-11, or les applications Cocoa ou Carbon ne sont pas compatibles avec X-11.
En partage de fichier on accède sans problème à des utilisateurs non "connectés" et je ne comprends pas que si on peut lancer une appli en avant plan on ne le puisse pas en arrière-plan.
Le partage de fichier n'a rien avoir avec l'ouverture à distance de sessions.
Tiens : est-ce qu'un AppleScript "temporisé" se lancerait seul en arrière-plan ?
Oui. La seule différence entree une session active est une session en arrière-plan est que la session en arrière plan n'a pas d'interface utilisateur accessible.
Le courrier se relève-t-il en arrière plan ?
Oui, sauf si ton client de messagerie a été écrit pour ne pas le faire.
C'est ce que plein de gens font déjà. Enormément de serveurs sont "headless" (sans écran) et on s'y connecte via timbuktu ou sous windows via le contrôle à distance.
Y compris pour lancer des applis et les utiliser ? (même au ralenti).
Les fonctionnement des applications n'est pas ralenti, c'est juste l'affichage qui à du mal à suivre.
J'imagine qu'il y a des limites : pourrait-on, par exemple, via AIrport en local ou pas, lancer un navigateur web à distance ? Les seules limites sont-elles bien :
- le débit et toutes ses conséquences sur l'affichage écran ou sur le temps réel (audio-images)
Ça c'est un problème de débit.
- un seul user accessible à la fois (en avant-plan, donc) ?
Ça c'est une limitation de MacOS X. On peut espérer qu'avec le temps, ça s'améliore
Cette histoire de "mono-user" distant ne serait-elle pas là pour éviter qu'on puisse être plusieurs à utiliser un même logiciel protégé ? (par exemple par dongle).
Non, c'est purement une non-implémentation de la fonction pour raison de coût et temps non disponible. C'est le résultat d'un choix d'une faible priorité pour le développement de cette fonction.
-- Schmurtz
J'en déduis que Timbuktu n'ouvre pas un "shell" véritable sur le serveur
mais se contente d'un gros hack de l'interface utilisateur ! Berk ! peut
mieux faire (mais ceci dit c'est peut-être dépendant du système qui, lui
non plus, ne le permet en fait pas !)
C'est exactement son principe de fonctionnemnt : apporter une copie
d'écran à distance.
MacOSX Server offrirait-il quelques options de meilleur goût ? Ou y
aurait-il des pistes du côté de X-11 ?
Oui, mais uniquement avec les applications X-11, or les applications
Cocoa ou Carbon ne sont pas compatibles avec X-11.
En partage de fichier on accède sans problème à des utilisateurs
non "connectés" et je ne comprends pas que si on peut lancer une appli
en avant plan on ne le puisse pas en arrière-plan.
Le partage de fichier n'a rien avoir avec l'ouverture à distance de
sessions.
Tiens : est-ce qu'un AppleScript "temporisé" se lancerait seul en
arrière-plan ?
Oui. La seule différence entree une session active est une session en
arrière-plan est que la session en arrière plan n'a pas d'interface
utilisateur accessible.
Le courrier se relève-t-il en arrière plan ?
Oui, sauf si ton client de messagerie a été écrit pour ne pas le faire.
C'est ce que plein de gens font déjà. Enormément de serveurs sont
"headless" (sans écran) et on s'y connecte via timbuktu ou sous windows
via le contrôle à distance.
Y compris pour lancer des applis et les utiliser ? (même au ralenti).
Les fonctionnement des applications n'est pas ralenti, c'est juste
l'affichage qui à du mal à suivre.
J'imagine qu'il y a des limites : pourrait-on, par exemple, via AIrport
en local ou pas, lancer un navigateur web à distance ? Les seules
limites sont-elles bien :
- le débit et toutes ses conséquences sur l'affichage écran ou sur le
temps réel (audio-images)
Ça c'est un problème de débit.
- un seul user accessible à la fois (en avant-plan, donc) ?
Ça c'est une limitation de MacOS X. On peut espérer qu'avec le temps, ça
s'améliore
Cette histoire de "mono-user" distant ne serait-elle pas là pour éviter
qu'on puisse être plusieurs à utiliser un même logiciel protégé ? (par
exemple par dongle).
Non, c'est purement une non-implémentation de la fonction pour raison de
coût et temps non disponible. C'est le résultat d'un choix d'une faible
priorité pour le développement de cette fonction.
J'en déduis que Timbuktu n'ouvre pas un "shell" véritable sur le serveur mais se contente d'un gros hack de l'interface utilisateur ! Berk ! peut mieux faire (mais ceci dit c'est peut-être dépendant du système qui, lui non plus, ne le permet en fait pas !)
C'est exactement son principe de fonctionnemnt : apporter une copie d'écran à distance.
MacOSX Server offrirait-il quelques options de meilleur goût ? Ou y aurait-il des pistes du côté de X-11 ?
Oui, mais uniquement avec les applications X-11, or les applications Cocoa ou Carbon ne sont pas compatibles avec X-11.
En partage de fichier on accède sans problème à des utilisateurs non "connectés" et je ne comprends pas que si on peut lancer une appli en avant plan on ne le puisse pas en arrière-plan.
Le partage de fichier n'a rien avoir avec l'ouverture à distance de sessions.
Tiens : est-ce qu'un AppleScript "temporisé" se lancerait seul en arrière-plan ?
Oui. La seule différence entree une session active est une session en arrière-plan est que la session en arrière plan n'a pas d'interface utilisateur accessible.
Le courrier se relève-t-il en arrière plan ?
Oui, sauf si ton client de messagerie a été écrit pour ne pas le faire.
C'est ce que plein de gens font déjà. Enormément de serveurs sont "headless" (sans écran) et on s'y connecte via timbuktu ou sous windows via le contrôle à distance.
Y compris pour lancer des applis et les utiliser ? (même au ralenti).
Les fonctionnement des applications n'est pas ralenti, c'est juste l'affichage qui à du mal à suivre.
J'imagine qu'il y a des limites : pourrait-on, par exemple, via AIrport en local ou pas, lancer un navigateur web à distance ? Les seules limites sont-elles bien :
- le débit et toutes ses conséquences sur l'affichage écran ou sur le temps réel (audio-images)
Ça c'est un problème de débit.
- un seul user accessible à la fois (en avant-plan, donc) ?
Ça c'est une limitation de MacOS X. On peut espérer qu'avec le temps, ça s'améliore
Cette histoire de "mono-user" distant ne serait-elle pas là pour éviter qu'on puisse être plusieurs à utiliser un même logiciel protégé ? (par exemple par dongle).
Non, c'est purement une non-implémentation de la fonction pour raison de coût et temps non disponible. C'est le résultat d'un choix d'une faible priorité pour le développement de cette fonction.
-- Schmurtz
Gerald
Xavier wrote:
Sur le réseau local du boulot, j'ai les deux (TBPro et ARD), effectivement TBPro est (un poil) plus rapide, plus fluide, surtout (backbone 100 Mb/s, switché)
Autre question : que se passe-t-il quand le "serveur" pris en charge par TBpro ou ARD se trouve "repris en main" en direct ? J'imagine que pour des utilisation pédagogiques ça doit marcher en tandem, mais sur les options essentielles genre "quitter la session", c'est au premier qui dégaine et qui clique ? comme au far-west ? :-)
Plus généralement, si une session est en cours sur le "serveur" pour l'utilisateur "X", comment se passe la prise en main à distance pour "utilisateur Y" : faut-il d'abord se connecter en tant que X, puis faire passer la session en arrière-plan au profit de Y ou a-t-on la possibilité d'accéder directement en Y ?
en tous cas merci pour tous ces renseignements, -- Gérald
Xavier <xavier@groumpf.org> wrote:
Sur le réseau local du boulot, j'ai les deux (TBPro et ARD),
effectivement TBPro est (un poil) plus rapide, plus fluide, surtout
(backbone 100 Mb/s, switché)
Autre question : que se passe-t-il quand le "serveur" pris en charge par
TBpro ou ARD se trouve "repris en main" en direct ? J'imagine que pour
des utilisation pédagogiques ça doit marcher en tandem, mais sur les
options essentielles genre "quitter la session", c'est au premier qui
dégaine et qui clique ? comme au far-west ? :-)
Plus généralement, si une session est en cours sur le "serveur" pour
l'utilisateur "X", comment se passe la prise en main à distance pour
"utilisateur Y" : faut-il d'abord se connecter en tant que X, puis faire
passer la session en arrière-plan au profit de Y ou a-t-on la
possibilité d'accéder directement en Y ?
en tous cas merci pour tous ces renseignements,
--
Gérald
Sur le réseau local du boulot, j'ai les deux (TBPro et ARD), effectivement TBPro est (un poil) plus rapide, plus fluide, surtout (backbone 100 Mb/s, switché)
Autre question : que se passe-t-il quand le "serveur" pris en charge par TBpro ou ARD se trouve "repris en main" en direct ? J'imagine que pour des utilisation pédagogiques ça doit marcher en tandem, mais sur les options essentielles genre "quitter la session", c'est au premier qui dégaine et qui clique ? comme au far-west ? :-)
Plus généralement, si une session est en cours sur le "serveur" pour l'utilisateur "X", comment se passe la prise en main à distance pour "utilisateur Y" : faut-il d'abord se connecter en tant que X, puis faire passer la session en arrière-plan au profit de Y ou a-t-on la possibilité d'accéder directement en Y ?
en tous cas merci pour tous ces renseignements, -- Gérald
Gerald
Schmurtz wrote:
[plein de choses intéressantes dont je le remercie]
- un seul user accessible à la fois (en avant-plan, donc) ?
Ça c'est une limitation de MacOS X. On peut espérer qu'avec le temps, ça s'améliore...
reconnais que c'est un point très important apporté avec Panther (le multi-sessions)
Non, c'est purement une non-implémentation de la fonction pour raison de coût et temps non disponible. C'est le résultat d'un choix d'une faible priorité pour le développement de cette fonction.
Ça reste un peu étonnant quand même car d'une part c'est un peu une conséquence logique de la filiation à Unix et d'autre part ça change considérablement la donne sur les perspectives d'utilisation "long terme" du matériel à une époque où de nombreuses familles et entreprises se retrouvent avec des environnements hétérogènes de plusieurs machines dont certaines très lentes mais parfaitement susceptible de servir de terminal !
Question subsidiaire : Windows le permet-il ou bien Panther a-t-il déjà quelques longueurs d'avance dans ce domaine qu'il suffirait de finaliser par un effort de développement et/ou une montée en puissance de X-11 ?
-- Gérald
Schmurtz <moi@ici.com> wrote:
[plein de choses intéressantes dont je le remercie]
- un seul user accessible à la fois (en avant-plan, donc) ?
Ça c'est une limitation de MacOS X. On peut espérer qu'avec le temps, ça
s'améliore...
reconnais que c'est un point très important apporté avec Panther (le
multi-sessions)
Non, c'est purement une non-implémentation de la fonction pour raison de
coût et temps non disponible. C'est le résultat d'un choix d'une faible
priorité pour le développement de cette fonction.
Ça reste un peu étonnant quand même car d'une part c'est un peu une
conséquence logique de la filiation à Unix et d'autre part ça change
considérablement la donne sur les perspectives d'utilisation "long
terme" du matériel à une époque où de nombreuses familles et entreprises
se retrouvent avec des environnements hétérogènes de plusieurs machines
dont certaines très lentes mais parfaitement susceptible de servir de
terminal !
Question subsidiaire : Windows le permet-il ou bien Panther a-t-il déjà
quelques longueurs d'avance dans ce domaine qu'il suffirait de finaliser
par un effort de développement et/ou une montée en puissance de X-11 ?
[plein de choses intéressantes dont je le remercie]
- un seul user accessible à la fois (en avant-plan, donc) ?
Ça c'est une limitation de MacOS X. On peut espérer qu'avec le temps, ça s'améliore...
reconnais que c'est un point très important apporté avec Panther (le multi-sessions)
Non, c'est purement une non-implémentation de la fonction pour raison de coût et temps non disponible. C'est le résultat d'un choix d'une faible priorité pour le développement de cette fonction.
Ça reste un peu étonnant quand même car d'une part c'est un peu une conséquence logique de la filiation à Unix et d'autre part ça change considérablement la donne sur les perspectives d'utilisation "long terme" du matériel à une époque où de nombreuses familles et entreprises se retrouvent avec des environnements hétérogènes de plusieurs machines dont certaines très lentes mais parfaitement susceptible de servir de terminal !
Question subsidiaire : Windows le permet-il ou bien Panther a-t-il déjà quelques longueurs d'avance dans ce domaine qu'il suffirait de finaliser par un effort de développement et/ou une montée en puissance de X-11 ?
J'en déduis que Timbuktu n'ouvre pas un "shell" véritable sur le serveur mais se contente d'un gros hack de l'interface utilisateur ! Berk ! peut mieux faire (mais ceci dit c'est peut-être dépendant du système qui, lui non plus, ne le permet en fait pas !) Pour Remote Desktop, sous réserve d'un miracle qui pourrait être décrit par quelqu'un qui l'utilise, je crois que la réponse est contenue dans le nom : dans sa description, Apple ne parle que d'un contrôle à distance du *finder* !
Je ne vois vraiment pas pourquoi l'implémentation de ces applications seraient différentes... Elles sont censé faire la même chose (pour la partie de controle d'un ordinateur à distance), donc elles utilisent les même moyen (il n'y en a pas 36.000).
Gerald <Gerald@alussinan.org> wrote:
J'en déduis que Timbuktu n'ouvre pas un "shell" véritable sur le serveur
mais se contente d'un gros hack de l'interface utilisateur ! Berk ! peut
mieux faire (mais ceci dit c'est peut-être dépendant du système qui, lui
non plus, ne le permet en fait pas !) Pour Remote Desktop, sous réserve
d'un miracle qui pourrait être décrit par quelqu'un qui l'utilise, je
crois que la réponse est contenue dans le nom : dans sa description,
Apple ne parle que d'un contrôle à distance du *finder* !
Je ne vois vraiment pas pourquoi l'implémentation de ces applications
seraient différentes... Elles sont censé faire la même chose (pour la
partie de controle d'un ordinateur à distance), donc elles utilisent les
même moyen (il n'y en a pas 36.000).
J'en déduis que Timbuktu n'ouvre pas un "shell" véritable sur le serveur mais se contente d'un gros hack de l'interface utilisateur ! Berk ! peut mieux faire (mais ceci dit c'est peut-être dépendant du système qui, lui non plus, ne le permet en fait pas !) Pour Remote Desktop, sous réserve d'un miracle qui pourrait être décrit par quelqu'un qui l'utilise, je crois que la réponse est contenue dans le nom : dans sa description, Apple ne parle que d'un contrôle à distance du *finder* !
Je ne vois vraiment pas pourquoi l'implémentation de ces applications seraient différentes... Elles sont censé faire la même chose (pour la partie de controle d'un ordinateur à distance), donc elles utilisent les même moyen (il n'y en a pas 36.000).
