unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: "Thompson, David" <dthompson2@worcester.edu>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: "Yasuaki Kudo" <yasu@yasuaki.com>, Phil <phil@beadling.co.uk>,
	"Ludovic Courtès" <ludo@gnu.org>,
	"Benjamin Slade" <beoram@gmail.com>,
	"Olivier Dion" <olivier.dion@polymtl.ca>,
	help-guix <help-guix@gnu.org>
Subject: Re: Enterprise Guix Hosting?
Date: Tue, 30 Aug 2022 21:42:00 -0400	[thread overview]
Message-ID: <CAJ=RwfbO7cVg3i=ha51=HmdE9ZWWGc-H-kP9kNkVLcSGo5qBaQ@mail.gmail.com> (raw)
In-Reply-To: <87lerbxxfs.fsf@elephly.net>

Hi Ricardo,

On Fri, Aug 26, 2022 at 3:43 AM Ricardo Wurmus <rekado@elephly.net> wrote:
>
>
> Hi Yasu
>
> > Our idea is at the coop is that we want to develop software
> > development acceleration tools, and a major part would be
> > container-less software provisioning so that composition would not
> > mean more and more layers of technical debt...
>
> Don’t discount containers too soon.  Guix has “guix system container”,
> which spins up lightweight Guix System containers that share /gnu/store.
> You only need to set up a bridge interface on the host and create a
> network device pair and move one end into the container’s net namespace.

I thought for sure that 'guix system container' would be something
people would love, but it doesn't seem to get much use!  Having all
containers share the store eliminates several problems that come with
Docker's primitive layer approach.  When I realized all we had to do
was bind mount store items into the container I couldn't believe it
was so simple.

> You can do containers and compose them without layers upon layers of
> file system blobs.  The reasons why this is not commonly done on
> existing commercial platforms:
>
> - container images are often provided from different origins, so there
>   is no trust and thus no way to have them share the same files or
>   common packages
>
> - without reproducible builds trust cannot be established
>
> - container images are erroneously considered a requirement for
>   isolation, but it is not actually required to use them even in the
>   presence of an unshared mount namespace.

All true.  "Container" has come to mean the image more than the
execution environment, so Guix containers not being based on disk
images makes them not fit in.

> Using a shared /gnu/store as a big cache for all containers can be a
> real asset.  We can learn lessons from the HPC experience here.

What might have a positive impact is if Guix had an answer to 'docker
compose'.  Most of the pieces are there already.  Such a tool could be
combined with 'guix shell' so you could get all the tools needed for
local development *and* automatically start any necessary daemons,
like database servers, in isolated containers.

- Dave


  reply	other threads:[~2022-08-31  1:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 23:23 Enterprise Guix Hosting? Yasuaki Kudo
2022-07-30 14:36 ` Olivier Dion via
2022-07-30 16:20   ` Phil
2022-07-30 23:18     ` Yasuaki Kudo
2022-07-31  0:42       ` Benjamin Slade
2022-07-31 11:01         ` Phil
2022-08-09 20:37           ` Ludovic Courtès
2022-08-09 22:24             ` Yasuaki Kudo
2022-08-14  9:53             ` Phil
2022-08-14 22:03               ` Yasuaki Kudo
2022-08-15 20:50                 ` Phil
2022-08-25 18:37                   ` Olivier Dion via
2022-08-26  6:40                     ` Yasuaki Kudo
2022-10-12  9:55                     ` Ade Malsasa Akbar
2022-10-12 10:18                       ` Olivier Dion via
2022-08-26  7:24                 ` Ricardo Wurmus
2022-08-31  1:42                   ` Thompson, David [this message]
2022-08-31  6:33                     ` Ricardo Wurmus
2022-08-31 10:46                       ` [EXT] " Thompson, David
2022-08-31 11:42                         ` Olivier Dion via
2022-08-31 12:54                           ` Thompson, David
2022-09-05 19:38                         ` [EXT] " Ludovic Courtès
2023-01-23 15:34                           ` declarative containers (was Re: [EXT] Re: Enterprise Guix Hosting?) Giovanni Biscuolo
2023-01-23 16:48                             ` Przemysław Kamiński
2023-01-23 17:59                               ` Wojtek Kosior via
2022-09-05 19:42               ` Enterprise Guix Hosting? Ludovic Courtès
2022-10-07 11:03               ` zimoun
2022-10-08 16:23                 ` Phil
2022-10-10  7:58                   ` zimoun
2022-10-10 10:30                     ` (
2022-10-10 10:49                       ` zimoun
2022-10-10 19:35                     ` Phil

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='CAJ=RwfbO7cVg3i=ha51=HmdE9ZWWGc-H-kP9kNkVLcSGo5qBaQ@mail.gmail.com' \
    --to=dthompson2@worcester.edu \
    --cc=beoram@gmail.com \
    --cc=help-guix@gnu.org \
    --cc=ludo@gnu.org \
    --cc=olivier.dion@polymtl.ca \
    --cc=phil@beadling.co.uk \
    --cc=rekado@elephly.net \
    --cc=yasu@yasuaki.com \
    /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).