I have Mathematica installed on a Mac running Snow Leopard and would
occasionally like to use it from another machine.
I know how to use ssh and tunneling of X11.
I know that MathKernel is the CLI on Mac.
But is it possible to run an X11 enabled Mathematica front end on Mac
OS X and thereby getting it to display remotely?
I think the problem is that the ./Mathematica program in Contents/
MacOS can't use X11, but I hope there is some undocumented or hidden
feature.
I will appreciate any help you can give!
Thanks!
..Per
> But is it possible to run an X11 enabled Mathematica front end on Mac
> OS X and thereby getting it to display remotely?
Hi,
the Mac front end actually runs on Aqua (Mac OS X graphical interface)
not X11 (a Unix or Linux graphical interface). However, as X11 is
also part of Mac OS, it would make sense to make a Mac/X11 front end,
but only Wolfram Reasearch can do that and they certainly have more
important things to do.
Here we see a strong limitation of Mac OS X Aqua, as opposed to linux
X11 : no Aqua application can run remotely (the Mac is indeed a
personal computer).
Would Mac OS X server help here ?
However, you can
- use screen sharing or
- create a virtual linux machine on the Mac, install Mathematica for
Linux and run it remotely with X11.
X11 tunneling is performed with ssh -X or ssh -Y. What about privacy
of X11 ?
I would really appreciate if this discussion was followed up by unix
geeks !
I have not heard that there is such a frontend for MacOS, but that
doesn't necessarily mean it isn't there. On the other hand I think you
probably will be happier to use something like vnc, which does give
remote access to the graphical user interface of the operating system,
so you could use other programs as well. Of course you can also tunnel a
vnc connection through ssh. If both ends run MacOS there might be even
more optimized protocol for remote access, but that I don't know. I have
found a german website that suggests that a vnc server and client is
built in, but I don't know for sure. I think if you search the web for
something like "remote desktop mac" you should find a lot of
information. Even if you are new to the topic, I think it will be easier
to set up and maybe even work better than an X11 connection would.
hth,
albert
I would guess that the front ends shares a lot of code. I recall to
have read that the front end on all platforms is buildt with the Qt
lib. So, it would make sense NOT to remove the X11 part from the Mac
OS X/Aqua front end. Still maybe they have, I just can't see why? I
just hoped for some way of telling the Mac OS X front end to use X11
rather than Aqua.
>
> Here we see a strong limitation of Mac OS X Aqua, as opposed to linux
> X11 : no Aqua application can run remotely (the Mac is indeed a
> personal computer).
>
> Would Mac OS X server help here ?
>
> However, you can
> - use screen sharing or
screen sharing is just such a waste of bandwidth when all I want is a
Notebook front end :-)
> - create a virtual linux machine on the Mac, install Mathematica for
> Linux and run it remotely with X11.
Hm, I wonder if my Mathematica license is tied to the Mac or whether
it could be installed on a linux box too -- whithout the two instances
running at the same time?
>
> X11 tunneling is performed with ssh -X or ssh -Y. What about privacy
> of X11 ?
If you tunnel through ssh, you're safe. Also you tell X11 which hosts
can connect to it using the xhost command.
>
> I would really appreciate if this discussion was followed up by unix
> geeks !
What do you want to know?
Regards,
Per
MacOS X supports screen sharing via VNC. Just enable the screen sharing
setting in Network Sharing in the System Preferences, and either run a
VNC client on the far end or if the far end is another Mac then you use
the normal mechanism which, I believe, is in iChat.
Cheers
You can use the "Screen Sharing.app" and it is in YourHardDrive/System/Library/CoreServices folder.
J=E1nos
On 23 sep, 10:23, "perda...@gmail.com" <perda...@gmail.com> wrote:
> screen sharing is just such a waste of bandwidth when all I want is a
> Notebook front end :-)
I agree. Screen sharing is a very unefficient way to use the
network. Typically, it will only work smoothly within a local
network.
Moreover, screen sharinf is also a waste of your time : if you do not
have total control on the remote machine, you will have problems.
Indeed, screen sharing will not work if somebody else is using the
screen or if there is no screen or if the screen is locked.
Inversely, if you keep the remote screen unlocked at all times, then
you will have a security problem on the remote machine !
Nothing compares with X11 for remote work, essentially because the
graphical server is LOCAL.
> I wonder if my Mathematica license is tied to the Mac or whether
> it could be installed on a linux box too -- whithout the two instances running at the same time?
Unfortunately, the licence is exclusive for one system. 4 systems are
supported : Mac, Linux, Windows, Unix (like Sun). For historical and
commercial reasons, Mac and linux are separate from Unix. You can
switch from one system to another, at no charge with Premier service.
With normal licence, you will need to pay. With student or home
licence, probably, you will need to buy a new licence.
For what you intend to do, linux seems better. You can install linux
on a virtual machine on the Mac. Hopefully, Wolfram Research will
lend you a licence for trial.
I would suggest to try it practically. Few years ago I started to use
this approach (over 64kb/s line from home) instead of connecting to
remote kernel. From practical side
advantages were obvious.
Thought your theoretical considerations seems logical and in principle
right, my
personal practical expierence is different: 1)stability,2) you can run
long jobs
over night with you notebook turned off. 3) later can connect to the same
screen from different place (mobility).
Complete control over remote server is also not required. In these case
just put Xvnc executables in /home/YourAccount/bin folders and somehow
adjust config files.
Because I have quite large expierence using both methods (remote kernel
and Xvnc) for quite a long time on different machines (for Xvnc I use only
linux boxes), now I use ONLY Xvnc approach.
On Oct 16, 6:17 pm, Arturas Acus <Arturas.A...@tfai.vu.lt> wrote:
> I do not agree. Xvnc servers are smart enough that for practical purposes
> you do not feel any difference. You even can live rotate 3d graphics
> remotely.
> Xvnc servers compress data and they send only differences over what
> had changed. Also You can adjust quality, compression level and resolutio=
n
> according to
> your needs. Security is also not a problem because you can easily tunel
> it over ssh.
Right.
>
> I would suggest to try it practically. Few years ago I started to use
> this approach (over 64kb/s line from home) instead of connecting to
> remote kernel. From practical side
> advantages were obvious.
>
This is exactly what I have done (again - to check my point). Screen
sharing from Mac (macbook pro with Mac OS X.6) to Mac (macbook with
10.4) over the network. The server was on ADSL line so that I only
had a small outcoming speed < 2 Mbit/s. Display was a bit sluggish
but acceptable. There is a few second lag when moving windows.
It is possible to see any user's screen or the login screen.
However, in spite of setting sleep preferences to as little as
possible, after some time, the server screen may become black, which
corresponds to a locked white screen on the client side. Unlocking
may be achieved by typing on the server keyboard, which requires
physical access. I think that I managed to unlock also by running ssh
but I am not sure. This is cumbersome to check. There may be a bug
in Mac screen sharing or sleep preferences.
As far as I remember, vnc with a linux server (Fedora 7) may also
require physical access, in particular, if the server screen is locked
or if I log out. Thus, if I want to vnc my linux server, then I must
leave the screen unlocked, which is a security issue : somebody can
simply use the machine while I am away !
My conclusion so far is that establishing a vnc connection often
requires physical access to server and badly interferes with server
screen security or energy saving systems.
Moreover, if somebody else is using the server (unique) screen,
obviously, you cannot work, as opposed to ssh -Y that does not use
server screen.
Cheers.