One of the most annoying things I’ve had using the same machine for work and personal purposes is how the environments can get mixed up. Someone sends you a link on the corporate slack, you click the link and BOOM - it appears on the personal Google Chrome instance - which means I have to focus on the right Chrome window, then click the link so it goes to the proper browser. While I was trying to find solutions for this problem, someone pointed me to Qubes OS and it sounded too good to be true! True isolation between profiles, and even support for throwaway accounts! The downside was that all the instances were running on a Xen Hypervisor, which would be sub-optimal for my use case. Then I tried to run two X sessions simultaneously, and my screen would go crazy by switching beetween them. Also sound would stop working because the first Chrome instance would take the audio card hostage. Xephyr didn’t work as expected with my tiling window manager. I was almost giving up. Suddenly, I hear angels singing and a bright light comes over me realize that if X-Forwarding over SSH works, there must be a way to start X applications under different user accounts, while preserving hardware video acceleration and keeping the footprint low - but would those apps honor the separation between environments?

enter xhost

One of the things I’ve forgot from my shady past doing linux-based thin clients was the xhost tool. With a single command you can authorize a different user to open apps on an already-running X server. I then proceeded with creating a new unix account for work-related matters (we’re going to call it work for now). xhost +si:localuser:work We switch to the new user su - work To make things easier, just spawn a new terminal under the new user - anything that is started from this terminal is going to be owned by work user account. xterm & Almost everything works! If I spawn slack and google-chrome, links clicked on slack appear on the proper browser!

sound issues

Pulseaudio really really wants to own your sound card, and when you start chrome it starts pulseaudio's daemon automatically. One way to fix that is to make pulseaudio to communicate over TCP. First we make the daemon to listen for TCP connections: mkdir -p ~/.pulse && cp /etc/pulse/default.pa ~/.pulse/default.pa echo "load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1" >> ~/.pulse/default.pa Then we make the work user account to connect to this daemon: mkdir -p ~/.pulse && echo "default-server = 127.0.0.1" > ~/.pulse/client.conf

wrap-up

Make sure to add your work user to local hardware access groups like video if you plan to do videoconferencing :) Voilà!