Re: Drafting a Guix blog post on the FHS container

[John Kehayias <john.kehayias@protonmail.com>]

Hi Ludo’ and Guixers,

Before I get to some quick responses, I wanted to share some FHS container examples I've been testing. I hope others can try as I did get a response on IRC that one didn't work as expected. I think it might be when needing to expose some of the host for things like hardware access.

First, let's dive right into a big one: the popular VSCodium editor. This is a freely licensed build of VS Code: <https://github.com/VSCodium/vscodium#why-does-this-exist>

This comes in AppImage format. Downloading it and making it executable (with a 'chmod +x') I can run it in a container as

--8<---------------cut here---------------start------------->8---
guix shell -CNF -D ungoogled-chromium gcc:lib \
     --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --share=$XAUTHORITY \
     --preserve='^DBUS_' --expose=/var/run/dbus \
     --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \
     -- ./VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage --appimage-extract-and-run
--8<---------------cut here---------------end--------------->8---

where the first line is a cheat I like to get lots of libraries often needed for graphical applications (development inputs of ungoogled-chromium) though it is a bit overkill if the AppImage does actually bundle everything (they don't!). Next line is for display on the host's X server, the one after for DBus communication, and lastly exposing some of the host hardware for rendering (perhaps can be disabled in VSCodium somehow?). This is what may need some tweaking for others, but I'm not sure.

Note that we can't run an AppImage with out the 'appimage-extract-and-run' as it will want to use fuse to mount the image which we can't do from the container. I have some more details on this and actually did get this to mount, though it wasn't visible from the container, in the coming blog post draft.

Another example is to get the latest nightly builds of Rust, via <https://rustup.rs/>

--8<---------------cut here---------------start------------->8---
$ mkdir ~/temphome

$ guix shell -NCF bash coreutils curl grep nss-certs gcc:lib gcc-toolchain pkg-config glib cairo atk pango@1.48.10 gdk-pixbuf gtk+ git --share=$HOME/temphome=$HOME

~/temphome [env]$ curl --proto '=https' --tlsv1.2 -sSf <https://sh.rustup.rs> | sh
--8<---------------cut here---------------end--------------->8---

where I first created a '~/temphome' directory to use as $HOME in the container and included a bunch of libraries for the next example.

Finally, we can build a Rust project of desktop widgets, <https://github.com/elkowar/eww>, following their directions <https://elkowar.github.io/eww/> Ultimately this uses just 'cargo build --release' and this builds after downloading all the needed libraries. It needs similar stuff from the host as the VSCodium example to get things to run and display, which I'll detail in the blog post.

Happy to try other examples and to hear feedback on these!

Now, back to the rest of the email.

On Tue, Dec 06, 2022 at 11:41 AM, Ludovic Courtès wrote:

> Hello!
>
> John Kehayias <john.kehayias@protonmail.com> skribis:
>
>> One question: what is appropriate or recommended for examples concerning things like
>> pre-built binaries? As an example, I had tested the FHS container by running the Siril
>> appimage, which has since been packaged for Guix (nice work!). There are ones that I
>> don't see that happening for anytime soon, like an Electron-based app. Something like
>> VSCodium is very popular, free (as in freedom and I believe the FSDG sense), but just
>> not something you can package fully from source due to JavaScript as I understand it. It
>> runs in the FHS container.
>
> A good example might be a free application not currently packaged in
> Guix, for example due to being full of JavaScript, or nightly builds as
> you wrote provided by an upstream project.
>

I used VSCodium above, though honestly I've only seen that it opens and seems to work fine. Open to other suggestions but that one will probably get some attention :)

>> Here is a current (rough!) draft. For the ease of plain text email I've exported from
>> the org source to text with some light edits:
>
> Note that the blog takes Markdown¹, but hopefully the Org-to-markdown
> export works well.
>
> ¹ <https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts>
>

Thanks, and I saw simon's email about this as well. I may have to tweak the Markdown a little, but should work easily enough.

> The post looks great to me!  I have minor suggestions below:
>

Thank you!

>> GNU Guix is different from most other GNU/Linux distributions and
>> perhaps nowhere is that more obvious than the organization of the
>> filesystem: Guix does not conform to the [File Hierarchy Standard]
>> (FHS). In practical terms, this means there is no global `/lib'
>
> It’s “Filesystem Hierarchy Standard”.
>
>> To that end, we've [recently added] a new option for Guix containers,
>> `--emulate-fhs' (or `-F'). This will set up an environment in the
>
> Perhaps s/Guix containers/`guix shell`/ and add a few words about what
> ‘guix shell --container’ does (you can link to the manual or blog post).
>
>> container that follows FHS expectations, so that libraries are visible
>> in `/lib' in the container, as an example. Additionally, for the more
>> technically-minded, the [`glibc' used in this container] will read from
>> a global cache in `/etc/ld.so.cache' contrary to the behavior in [Guix
>> otherwise].
>
> Since the ld.so.cache issue is more involved (compared to simply having
> /lib and /bin), maybe you can move it after the “ls /bin” example?
>
>> Contrast that with `/bin' on a Guix system:
>> ,----
>>  ls /bin -la
>> `----
>>
>> lrwxrwxrwx 1 root root 61 Dec 3 16:37 sh ->
>> /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/sh
>
> You can show ‘ls /lib’ too.  :-)
>

Thanks for all these corrections and tips! Sadly(?) no matter how many times I've written out FHS I still get it wrong sometimes.

> Actually you can use or get inspiration from this animated GIF if you
> like:
>
>   <https://web.fdn.fr/~lcourtes/tmp/guix-shell-fhs.gif>
>

Either I forgot to save this or wasn't able to access it before, and can't access it now.

>> useful. For example, there may be software that is free and conforms to
>> the FSDG Guix follows, yet is not feasible to be [packaged] by our
>
> s/FSDG/Free System Distribution Guidelines (FSDG)/
>

Thanks!
John