Re: Guix as remote dev machine

[Brian Woodcox]

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://me@192.168.0.xxx 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, t@fullmeta.me 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