Re: Seeking best-practice for managing guix-defined VMs
Hello, Hartmut Goebel skribis: > I wonder about the best-practice for managing VMs built using `guix > system vm`. I’d recommend letting ‘guix system vm’ manage the stateless part of the VM, and if there’s any state, store it in a separate directory shared with the host with “--share”. > My idea is to have the system-configuration on the (foreign distro) host > and build and run VMs using `guix system vm`. Background is that for > some reasons I can not use GuixSD on the host, but wont to use guix for > managing the actual work-horses. > > * For specifying the parameters of the host-side of the VM-emulation, > and for starting the VM with the appropriate parameters, I can add a > wrapper shell-script. Is there a better way than a shell-script? > > * When updating the config, the currently running VM needs to be shut > down. What are good ways to handle this? How to notice, which is the > correct VM to shut down (this one's "predecissor")? ‘guix system’ won’t help you with that. You’ll have to do your own bookkeeping I guess. > * Over time, the store will fill up with `xxx-run-vm.sh` scripts. Will > these be garbage-collected? (I assume not.) What are good ways to keep > track of scripts and discard those no longer needed (and garbage-collect)? Like everything in /gnu/store, ‘guix gc’ will delete them if they are unused and unreachable. > * How to handle "secrets", which need to go into the machine? Obviously > it's not a good idea to have them in a system-declaration. OTO the VM's > disk gets discarded with the next system generation. Everything Guix manages ends up world-readable in /gnu/store. So you need an out-of-band channel for secrets, such as --share. > * Is using `guix system vm` the wrong approach at all? Should I better > use `vm-image` or `container`? I think ‘guix system vm’ is fine. The key is to clearly separate the stateless part (software deployment) from state (secrets, databases, etc. that your applications may need.) HTH, Ludo’.
Re: How can I use ()
Hi Alex, Alex ter Weele skribis: > Based on this, what I think I want to do is something like: > > ,enter-store-monad > (build (list (gexp->script "test" (backup-home "alex" > > And then run the resulting script file. However, doing such gives the > error: > > ERROR: In procedure string->utf8: > ERROR: In procedure string->utf8: Wrong type argument in position 1 > (expecting string): # ‘gexp->script’ returns a “monadic” value, so you need to “bind” it with ‘mlet’ or similar to actually access that value: (mlet %store-monad ((script (gexp->script …))) (built-derivations (list script))) Note that the whole result is again a monadic value. Alternately, instead of fiddling at the REPL, you could do: guix gc -R $(guix system build config.scm) | grep mcron then pick the right .drv from there, and run: guix build ….drv HTH! Ludo’.
Re: Guix and sel4
Hello, Paul Boddie skribis: > There was a remark about the Hurd in the previous thread. The one difference > I > tend to perceive between the Hurd and systems like L4Re and Genode is that > the > latter things tend to be demonstrated almost like embedded solutions - you > build a specific payload and that is your system - whereas the Hurd behaves > like the open-ended system we are familiar with from our desktop computers. I really like the work that has been put into Genode, it’s impressive. That said, I think GuixSD on GNU/Hurd is slowly but surely materializing thanks to Manolis and rennes, and like you write, GNU/Hurd is designed to be like GNU/Linux from the looks but with tons of goodies inside. :-) So I’d encourage you to give Manolis and rennes a hand. Ludo’.
Re: Running IceCat in a container
Hi Mike, Mike Gerwitz skribis: > I'm running IceCat in a container, with the goal of isolating it form > the rest of my system as much as possible without running a full > VM. Here's what I have so far: > > #+BEGIN_SRC sh > guix environment \ > --container \ > --network \ > -r "$gc_root" \ > --share=/tmp/.X11-unix/ \ > --expose=/etc/machine-id \ > --share=$HOME/.mozilla/ \ > --share=$HOME/.cache/mozilla/ \ > --share=$HOME/.Xauthority \ > --share=$HOME/Downloads/icecat-container/=$HOME/Downloads/ \ > --ad-hoc icecat coreutils > -- \ > env DISPLAY="$DISPLAY" icecat "$@" > #+END_SRC I’ve been dreaming of having it baked in into the shell (like Plash did; we could write a Bash or Guile-Bash extension) or something along these lines… > The most difficult problem I'm having is dealing with > fonts. Specifically, I want to share the system fonts > (/run/current-system/profile/share/fonts). The problem is, I can't just > expose that directory, because it symlinks into the store, and those > derivations don't exist within the container. > > - I do not want to expose all of /gnu. > - I can provide the fonts as inputs to the environment, but I do not > want to have to run fc-cache every time I start the container, > because that is very slow. Exposing the cache directory doesn't > help since the derivation used in the container ($GUIX_ENVIRONMENT) > always appears to be different than the font derivation used on my > system, and also by my user. > - I don't want to expose my user's entire ~/.guix-profile/. > > I'm making things difficult for myself because I want as little > shared/exposed with the container as possible. > > To complicate things further, for privacy, I don't want my user exposed > to the container via the name of my home directory; Guix creates that > automatically. I haven't yet looked at the code to see what exactly it > does. “guix environment -C” makes $PWD shared; if you do (cd /tmp; guix environment -C …), then /tmp is shared but not $HOME. > Is there a reasonable solution here? Should I create a separate user > entirely and then just share the entire home directory? I'm not sure > how that might impact X11 socket sharing, though. Can I maybe > pre-create an image, already having run fc-cache, and run that image as > a container (like one would with Docker?)? But that wouldn't solve my > user privacy issue. Perhaps you could define a package that simply runs “fc-cache” with the fonts it has as inputs, and then pass that to ‘guix environment’. But really, we should make a specific tool for this. Thoughts? Ludo’.
Re: Why is IceCat/GuixSD slower than Firefox/Debian on headless servers?
George myglc2 Clemmer skribis: > Running from a desktop to a headless server, and based on side-by-side > clicking, IceCat/GuixSD takes ~5x times as long as Mozilla/Debian to > respond to clicks. Further, Mozilla/Debian takes ~5x times as long as > Mozilla running on the desktop. The bottom line: IceCat/GuixSD is > unbearably slow. > > Has anyone else seen this? I use IceCat and Conkeror on GuixSD and they’re not unbearably slow. Ludo’.
Re: problem with Icecat in GuixSD 0.14.0
I see... I hope someone can send a detailed report to the original projects so as to help them fix it. ;) 2017-12-21T13:27:02+0100 Martin Castillo wrote: > I wasn't asking for help. I just wanted to say that it may be a problem > outside of guix.
Re: Why is IceCat/GuixSD slower than Firefox/Debian on headless servers?
> Running from a desktop to a headless server, and based on side-by-side > clicking, IceCat/GuixSD takes ~5x times as long as Mozilla/Debian to > respond to clicks. Further, Mozilla/Debian takes ~5x times as long as > Mozilla running on the desktop. The bottom line: IceCat/GuixSD is > unbearably slow. > > Has anyone else seen this? > > Is there a known IceCat/GuixSD performance problem? This sounds like an X11 protocol issue. Starting with Firefox 47, XRender support is disabled by default: https://www.reddit.com/r/firefox/comments/4nfmvp/ff_47_unbearable_slow_over_remote_x11/ Basically newer versions of Firefox stop using X11 correctly because Mozilla considers X11 "technical debt," and because X11 does not support some kinds of graphics acceleration. Back when Wayland development started the popular ideology became that no one needed or wanted remote graphics, if you want it use desktop forwarding like VNC, else tough luck. A lot of people bought into that and now we are seeing the results. Check the value of gfx.xrender.enabled in about:config and try turning it on/off to see if that changes the performance. It should come enabled in Firefox 45, and is probably disabled in the newer IceCat. If it is lack of XRender causing the problems, the more interesting question is why running Firefox 45 remotely is so much slower than running it on the desktop. You can try VNC forwarding to see if it is some other X11 issue. Make sure to get Firefox 45 on the desktop for a valid comparison. Vladimir
Re: Why is IceCat/GuixSD slower than Firefox/Debian on headless servers?
On 01/16/2018 at 11:56 Vladimir Sedach writes: >> Running from a desktop to a headless server, and based on side-by-side >> clicking, IceCat/GuixSD takes ~5x times as long as Mozilla/Debian to >> respond to clicks. Further, Mozilla/Debian takes ~5x times as long as >> Mozilla running on the desktop. The bottom line: IceCat/GuixSD is >> unbearably slow. >> >> Has anyone else seen this? >> >> Is there a known IceCat/GuixSD performance problem? > > This sounds like an X11 protocol issue. Starting with Firefox 47, > XRender support is disabled by default: > > https://www.reddit.com/r/firefox/comments/4nfmvp/ff_47_unbearable_slow_over_remote_x11/ > > Basically newer versions of Firefox stop using X11 correctly because > Mozilla considers X11 "technical debt," and because X11 does not support > some kinds of graphics acceleration. > > Back when Wayland development started the popular ideology became that > no one needed or wanted remote graphics, if you want it use desktop > forwarding like VNC, else tough luck. A lot of people bought into that > and now we are seeing the results. I'm not a VNC fan (sigh)... > Check the value of gfx.xrender.enabled in about:config and try turning > it on/off to see if that changes the performance. It should come enabled > in Firefox 45, and is probably disabled in the newer IceCat. Thank you, this was really helpful. gfx.xrender.enabled=false in IceCat/GuixSD. Enabling it made the IceCat/GuixSD performance about the same as Firefox/Debian (which comes w/ gfx.xrender.enabled=true). > If it is lack of XRender causing the problems, the more interesting > question is why running Firefox 45 remotely is so much slower than > running it on the desktop. OK, I tested some more. It look like I was exagerating about firefox remotely. It looks more like 1/2 as fast. ISTM that ... Firefox>GTK+>X11(3.4GHz)<--1000BaseT-->XQuartz>Quartz(2.7GHz)>GPU ... could be 1/2 as fast as ... Firefox>GTK+>Quartz(2.7GHz)>GPU WDYT? - George
Re: How to make XQuartz/MacOS <--> IceCat/GuixSD fast?
On 01/15/2018 at 13:29 George myglc2 Clemmer writes: > I want to speed up IceCat on my GuixSD headless server. I am using > XQuartz/MacOS over 1000BaseT to reach a server with 3.4GHz Intel E3-1240 > V3 CPU and SSD storage. ISTM this is about as fast as one can make a > headless server. But IceCat is unusably slow. [...] Update: As suggested by Vladimir Sedach[1], changing the IceCat/GuixSD about:config default gfx.xrender.enabled=false to true dramatically speeds this up the point I am no longer thinking of new hardware. Yeah! [1] http://lists.gnu.org/archive/html/help-guix/2018-01/msg00065.html
Re: Running IceCat in a container
On Tue, Jan 16, 2018 at 17:30:42 +0100, Ludovic Courtès wrote: > “guix environment -C” makes $PWD shared; if you do (cd /tmp; guix > environment -C …), then /tmp is shared but not $HOME. I am doing that (I made a ~/.empty so as not to expose /tmp contents), but that still creates the home dir (as documented): $ pwd && guix environment -C coreutils -- ls /home /tmp mikegerwitz >> Is there a reasonable solution here? Should I create a separate user >> entirely and then just share the entire home directory? I'm not sure >> how that might impact X11 socket sharing, though. Can I maybe >> pre-create an image, already having run fc-cache, and run that image as >> a container (like one would with Docker?)? But that wouldn't solve my >> user privacy issue. > > Perhaps you could define a package that simply runs “fc-cache” with the > fonts it has as inputs, and then pass that to ‘guix environment’. Oh, interesting; I wouldn't have thought of that. If there is a general solution/script, I think this needs to be considered---automatically including system fonts; any program that displays text needs a broad range of UTF-8/multi-lingual font support. If I were to containerize my shell, I'd have the same problem. > But really, we should make a specific tool for this. > > Thoughts? Yes, though I'd be curious how you'd approach it---each package requires certain paths be shared, and those paths would further depend on user privacy preferences, so need to be able to be overridden. Perhaps it'd be useful for those paths to be part of a package definition---the paths that a program creates/uses at runtime, and perhaps additional metadata associated with them, such as whether the path is necessary for its operation (will it break the program if it's ephemeral or read-only?). Something extensible for the future. Those directory metadata may have other uses that may make it worth adding, but I haven't given it much thought. For example, if a user wishes to purge a package from her system, she could opt to purge those paths from her home directory. Or maybe Guix could create a backup of user preferences such that a restoration would involve only a list of packages and a tarball of those directories. Might be useful for provisioning as well. Just some thoughts. I'm too new to Guix to provide much. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
Re: How to make XQuartz/MacOS <--> IceCat/GuixSD fast?
George myglc2 Clemmer writes: > I want to speed up IceCat on my GuixSD headless server. I am using > XQuartz/MacOS over 1000BaseT to reach a server with 3.4GHz Intel E3-1240 > V3 CPU and SSD storage. ISTM this is about as fast as one can make a > headless server. But IceCat is unusably slow. So I wonder ... > > Do you run IceCat remotely from a GuixSD desktop and get good > performance? If so, please tell me about your setup. > > Would Wayland make it faster? > > Would an upgrade to a CPU w/GPU make it faster? > > TIA - George For what it's worth, I have run Firefox in similar situations (not involving GuixSD), and I have always found it to be un-usably slow over a remote X connection. I never bothered to try to make it faster; I'm intrigued that you were able to make it better at all. You may also consider doing the following to speed things up: - Use compression (e.g., "ssh -C") (helps quite a bit in some cases) - Limit the color palette to the fewest colors possible (helps a little) -- Chris signature.asc Description: PGP signature
