X11 on MacOS X
I meant to reply to his post at the time, but I didn't. I've also had to look up the answers to some of these problems a few too many times, so here it is for my reference, and maybe the rest of the world's, in case they care.
Parallels Linux slow display, laggy mouse, cut and paste problems
Virtualizing a Linux display and raw input devices in Parallels is horribly slow. Let's face it, Parallels is for running Windows. They just don't care about Linux that much.
The way to deal with this is simply not to do it; hide your Parallels window entirely (Cmd-H) and just use the MacOS X11.App to display your Linux session. This solves pcolijn's problems of copy-and-paste, slow mouse cursors, and inflexible key remapping (see xmodmap).
Parallels bridged networking causes X11 problems
Unfortunately using X11.App increases problems with Parallels' "bridged" networking mode. As you move your laptop around, the IP address of your X server keeps changing, which means that anything connected to it stops working. Sigh.
Solution: use "host-only" networking instead. Then go to System Preferences | Sharing | Internet. Share your connection from "Airport" or "Ethernet", whichever you're connected to. Check all the checkboxes. Click Start.
This way, MacOS will allow outgoing connections from your Parallels session, masquerading them through a single IP.
Do not attempt to use Parallels' "shared" network mode, which is supposed to do the same thing, but is subtly different. The problem with that mode is it allocates an IP subnet for its sharing automatically every time you start Parallels; if you use more than one VM, things hop around and you can't hard-code your IP address, which makes it hard to ssh from MacOS into your VM, and hard to set your DISPLAY variable in Linux.
Linux can't accept incoming connections with Parallels Host-only networking
Computers outside your Mac can't connect to your Linux system this way. You might consider this an advantage, ie. you don't need to set up a firewall in every virtual machine. But sometimes you want other machines to connect in... and you still want the non-IP-hopping advantage of the host-only networking mode.
Solution: create a second virtual network interface in Parallels, and use bridged mode there. Connect to X11 with the host-only network, but connect into the system using the bridged network.
MacOS X11's default window manager is stupid
The quartz-wm window manager that comes with X11.app is pretty, but annoying: most annoying is that no matter how many apps you open, you only see one big "X11" app icon on the happy bar, and it keeps getting confused about focus, and you (argh!!) can't switch between X11 windows easily using the keyboard.
Solution: use a real window manager hosted in your Linux system. I like ion2, which lets me do almost everything with the keyboard. To do this, create a .xinitrc in your Mac home directory with just these lines:
#!/bin/bash . ~/.profile exec ssh -Y my-linux-machines-ip ./.xsession-macos
Then create a .xsession-macos that does what you want, including starting the window manager.
Keybindings in MacOS X11 are stupid
Here's the xmodmap file I use with ion2.
clear mod1 clear mod2 add mod1 = Meta_L add mod2 = Meta_R
keycode 78 = plus keycode 74 = asterisk keycode 85 = slash keycode 80 = equal keycode 63 = Meta_L keycode 66 = Meta_R keycode 84 = Control_R KP_Enter</pre>
Load it from your .xsession-macos file. There's some kind of weird bug in the MacOS X11.App that means you need to do this twice, that is:xmodmap .mymodmap xmodmap .mymodmap
Otherwise nothing will happen.
gnome-settings-daemon and window managers can't start from Linux when displaying on MacOS
If you connect using "ssh -X my-linux-system", you might get an error like one of these (hi, Google!):>> Unable to redirect root window events for screen 0. >> Refusing to start due to encountered errors.
The application 'gnome-settings-daemon' lost its connection to the display localhost:10.0; most likely the X server was shut down or you killed/destroyed the application. The application 'metacity' lost its connection to the display localhost:10.0; most likely the X server was shut down or you killed/destroyed the application. Window manager warning: Screen 0 on display "localhost:10.0" already has a window manager</pre>
Solution: use "ssh -Y" instead of "ssh -X" (see the .xinitrc file contents above). Otherwise certain X11 features don't work. Argh. Stupid security people. In earlier ssh releases, "-X" did all the things the new "-Y" option does, but not anymore. This is supposedly for security reasons, but I find it hard to believe that someone with access to create X windows of any sort wouldn't be able to trick me one way or another.