Guix as remote dev machine

Guix as remote dev machine

[t]

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

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

Re: Guix as remote dev machine

[t]

> tigervnc-server 1.12.0-0.b484c22 installed.
> xrandr 1.5.1

Dunno how I feel about VNC but this is certainly something to try. The one time I tried VNC in the past it felt extremely heavy and sluggish. This is something I'd probably use for Windows. I'll have to give it a go. Thank you for suggestion

Re: Guix as remote dev machine

[t]

I guess one more thing that maybe worth investigating is Emacs + TRAMP. I've some experience with TRAMP and it mostly works. Trouble again is with this 2nd step:

> 2. `guix shell` or start a container, with entire system if I need to 

Essentially TRAMP amounts to SSHing to your machine. But we want to be in that `guix shell` maybe even `guix shell -c` container, hell maybe even `guix system -c`. I can't even wrap my head around how that might work. TRAMP is basically talking to our SSHD started by current-system. I dunno but welcome suggestions, cause it'd be interesting to figure how that might work with TRAMP. Could be worth asking Emacs TRAMP mailing list, too.

Just thought I'd throw that idea out there, too. I would expect there to be a fair number of Emacs users among you.

Re: Guix as remote dev machine

[zimoun]

Hi,

On Mon, 21 Mar 2022 at 14:09, t@fullmeta.me wrote:

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

My workflow depends on my mood:

 1. run emacs --daemon on the server; then inside xterm from my laptop,
 connect via ssh and run emacsclient as tmux or screen would do.

 2. run emacs with TRAMP via ssh to connect from my laptop to the
 server.

 3. run all from my laptop and offload the Guix builds to the server.


Cheers,
simon

Re: Guix as remote dev machine

[david larsson]

On 2022-03-21 15:09, 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

Hello Mr t!

I suggest checking out: guix search xpra

Then the Arch linux wiki has pretty good usage tutorial that could most 
likely work for forwarding of individual application windows. Im 
uncertain how it works for full desktop forwarding on Guix.

Best regards and good luck,
David

Re: Guix as remote dev machine

[david larsson]

On 2022-04-30 13:07, david larsson wrote:
> On 2022-03-21 15:09, 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.

[..]

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

Reg. the HiDPI part of your issue: here is something that might be worth 
trying:

https://github.com/Xpra-org/xpra/issues/1933#issuecomment-856059101
https://github.com/Xpra-org/xpra/issues/1933#issuecomment-1014407069

Best regards,
David L