[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Drafting a Guix blog post on the FHS container
Re: Drafting a Guix blog post on the FHS container
Mon, 12 Dec 2022 06:33:35 +0000
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:
This comes in AppImage format. Downloading it and making it executable (with a
'chmod +x') I can run it in a container as
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 \
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
$ mkdir ~/temphome
$ guix shell -NCF bash coreutils curl grep nss-certs gcc:lib gcc-toolchain
pkg-config glib cairo atk firstname.lastname@example.org gdk-pixbuf gtk+ git
~/temphome [env]$ curl --proto '=https' --tlsv1.2 -sSf <https://sh.rustup.rs> |
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:
> John Kehayias <email@example.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
>> understand it. It
>> runs in the FHS container.
> A good example might be a free application not currently packaged in
> 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
>> 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:
>> 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
> 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 ->
> 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
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)/