Re: Drafting a Guix blog post on the FHS container

[Ludovic Courtès]

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.

> 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

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

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

Actually you can use or get inspiration from this animated GIF if you
like:

  https://web.fdn.fr/~lcourtes/tmp/guix-shell-fhs.gif

> 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,
Ludo’.