From: Mike Gerwitz <mtg@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: help-guix@gnu.org
Subject: Re: Running IceCat in a container
Date: Tue, 16 Jan 2018 21:25:19 -0500 [thread overview]
Message-ID: <87tvvlrzlc.fsf@gnu.org> (raw)
In-Reply-To: <877esh3gwd.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 16 Jan 2018 17:30:42 +0100")
[-- Attachment #1: Type: text/plain, Size: 2568 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
next prev parent reply other threads:[~2018-01-17 2:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-16 1:56 Running IceCat in a container Mike Gerwitz
2018-01-16 16:30 ` Ludovic Courtès
2018-01-17 2:25 ` Mike Gerwitz [this message]
2018-01-17 19:05 ` Mike Gerwitz
2018-01-17 23:20 ` Leo Famulari
2018-01-18 1:53 ` Mike Gerwitz
2018-01-25 14:34 ` Ludovic Courtès
2018-01-25 22:16 ` Ludovic Courtès
2018-01-26 3:52 ` Mike Gerwitz
2018-01-29 16:47 ` Ludovic Courtès
2018-01-30 2:19 ` Ricardo Wurmus
2018-01-30 17:21 ` Running code from packs in containers Ludovic Courtès
2018-03-19 17:42 ` Running IceCat in a container ng0
2018-01-29 16:48 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tvvlrzlc.fsf@gnu.org \
--to=mtg@gnu.org \
--cc=help-guix@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).