I’m not sure if this will help you or not. I screen share from OSX to a VM running Guix system on Unraid.
I have the following installed: tigervnc-server 1.12.0-0.b484c22 installed. xrandr 1.5.1 So I run the following command in a terminal window in Guix under my user: x0vncserver -display :1 —PasswordFile=/home/me/.vnc/passwd If you were to automate the above command, then you wouldn’t have to type it in all the time. For me since I’m using Unraid, I can just vnc into the VM and execute the command. So you probably already know this, but to remote into this from OSX, you would do the following: CMD-k while in the finder to connect to the server. Type in vnc://[email protected] and connect. Next. xrandr will list the display resolutions supported by Guix. In my case, I didn’t see 2560x1440 (Apple Cinema Display), so I did the following: xrandr —newmode “2560x1440” 312.25 2560 2752 3024 3488 1440 1443 1448 1493 -hsync +vsync xrandr —addmode Virtual-1 2560x1440 xrandr -s 2560x1440 Use full screen on mac to fill whole screen. Of course the above commands don’t stick. So you have to re-enter them every time. I would work this out myself, but I’m just too busy. Hope this helps. Please share back your solution, I hope the above helps you in some way. :) > On Mar 21, 2022, at 8:12 AM, [email protected] wrote: > Hi Guix. > > I'm trying to come up with a reasonable way to use my Guix machine sitting in > the attic as my remote development server. This presents several challenges. > Locally I would typically follow these steps: > 1. Create a project dir with guix.scm describing (possibly empty) package > 2. `guix shell` or start a container, with entire system if I need to e.g. > run a db > 3. start emacs from that shell or container forwarding to my main DISPLAY > > When attempting to do something similar remotely, you very quickly run into > issues. X forwarding to a Linux machine kinda works, but sadly on OSX, which > I have to use as a client, XQuartz X server implementation can't deal with hi > DPI and the end result is miserable. Then there're potential rendering issues > when your remote server doesn't even have a graphics card. We're sadly left > with ssh + terminal Emacs. However, just ssh and then follow the above steps > won't be enough. When your ssh session goes down, it'll take everything with > it. > > I hear you say `tmux`. I thought so too, but fresh `guix package -i tmux` > gives me `Incorrect locale LC_all, LC_CTYPE or LANG` when I try to run it. > Weird, seeing how this is attempted on Guix SD. No matter. Lets just go with > `screen`, which seems to work. Then follow the above steps. > > This sort of works and how I would imagine most people attempting this would > end up with. It leaves me itchy though. I mean, do I even need that `screen` > there when `emacs --daemon=name` exist? Latter will happily detach itself > from your tty and persist across ssh sessions. Problem of course is the 2nd > step above, which assumes we spawn a shell (possibly run a container, maybe > even the entire system). I wonder if there's a way to avoid the intermediate > `screen` or `tmux` completely. Way I understand it, `guix shell`, `guix shell > -c` and `guix system --container` are Unix processes. Could they be detached > or put under some group or smth? I mean, screen works ok, but I wonder. > > Thanks
