Je me souviens
Everything here is my opinion. I do not speak for your employer.
October 2007
November 2007

2007-10-04 »

X11 on MacOS X

Some time ago pcolijn wrote that he'd given up on my suggestion that to get things done on MacOS, you should use a virtual Linux machine in Parallels.

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 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:

   . ~/.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.

Try Tailscale: mesh networking, centralized administration, WireGuard.

Why would you follow me on twitter? Use RSS.