all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Chris Marusich <cmmarusich@gmail.com>
To: myglc2 <myglc2@gmail.com>, guix-devel@gnu.org
Subject: Re: Guix vs GuixSD
Date: Mon, 15 Feb 2016 01:05:55 +0000	[thread overview]
Message-ID: <CAEKzfHmT=1EbBNU=Jw922wnYm4DRu8U1CTf-x0V5sL864rGbLw@mail.gmail.com> (raw)
In-Reply-To: <87twla6cw0.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3753 bytes --]

Hi,

I think you're asking "What is the difference between Guix and GuixSD", and
you don't feel that the manual is clear enough about this. Is that right?
If so, how do you feel the manual could be improved?

I'm not yet a Guix/GuixSD expert, but in a nutshell, it seems to me that
the biggest difference between Guix and GuixSD is that by using GuixSD, you
gain many of Guix's benefits (reproducibility, easy rollback, etc.) at the
system level. If you use a non-GuixSD distribution, you can still enjoy the
benefits of using Guix as a package manager, but you'll be using something
else to manage the system itself (the installed bootloader, the installed
kernel, all the services that launch at system start, etc.). Most likely,
you will simply be missing out on all the nice features that GuixSD
provides.

For what it's worth, I think the current structure of the manual makes a
clear distinction between Guix the package manager and GuixSD the GNU
system:

https://www.gnu.org/software/guix/manual/guix.html

Section 7 is all about GuixSD. All other sections apply to GuixSD, too, in
the sense that they discuss the Guix package manager, which is used by
GuixSD. When necessary, the manual calls out the differences between doing
something on GuixSD vs. doing it on a non-GuixSD distribution. Again, if
you don't think this is clear enough, how do you think the manual can be
improved?

I see that you are hoping to convince others to use Guix/GuixSD instead of
alternatives. That's great! You might be interested in the following email
thread, in which Malcolm Cook discusses his efforts to make the case for
GNU Guix:

http://lists.gnu.org/archive/html/guix-devel/2016-02/msg00286.html

Good luck,
Chris



On Sun, Feb 14, 2016 at 4:22 PM myglc2 <myglc2@gmail.com> wrote:

> I hope to switch my home servers from Debian 8 to NixOS or GuixSD.  Once
> that is working, I hope to convince the system managers at work to
> install Nix or Guix.
>
> I started experimenting with Nix and NixOS 6 weeks ago. 3 weeks ago I
> switched my focus to Guix and installed guixSD on one of my servers.
>
> I found it difficult to determine exactly which parts of the volumminous
> (and tasty) Guix doc to read and how best to apply GuixSD. FWIW, I
> experienced the same difficulty with Nix/NixOS.
>
> To clarify my thoughts, I made a diagram (guix-ov) to illustrate Guix
> features that are important to me:
>
> 1) Auditable flow of free software from developer site to user
>    environment
>
> 2) Automated local package builds
>
> 3) Pre-built packages from Hydra
>
> 4) The potential of an identical Guix user environment everywhere
>
> I intended to show the differences between Guix and GuixSD. But frankly,
> looking at diagram guix-ov, they seem more alike than not. I think this
> contributed to my difficulty in figuring out GuixSD. So, made a second
> diagram (guix-ov2) that I think ...
>
> - shows clearly the difference and relationship between Guix and GuixSD
>
> - is more modular in appearance and easier to understand
>
> - is more descriptive of how the software works
>
> - is better aligned with the doc
>
> - illustrates the distinction between user and system environments
>
> In short, I think diagram guix-ov2 is a more informative way to explain
> the Guix-verse.
>
> I know guix-ov2 does not match the way Guix and GuixSD are currently
> described. But I believe that if you describe things this way it will be
> easier for new users to understand and apply Guix and GuixSD.
>
> Sidebar:
>
> At the moment, the GNU Guix web site focuses mostly on GuixSD. But to
> test drive Guix, a user must first decide what to download. Perhaps one
> of these diagrams (with suitable prettyfication) could help a user
> decide what to download.
>

[-- Attachment #2: Type: text/html, Size: 4822 bytes --]

  reply	other threads:[~2016-02-15  1:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-15  0:22 Guix vs GuixSD myglc2
2016-02-15  1:05 ` Chris Marusich [this message]
2016-02-15 17:37   ` myglc2
2016-02-16  3:26     ` Chris Marusich
2016-02-16  9:24       ` Jookia
2016-02-16  9:41         ` Chris Marusich
2016-03-05  1:59 ` myglc2
2016-03-06 13:53   ` Ludovic Courtès
2016-03-06 15:37     ` myglc2
2016-03-07  6:57   ` Chris Marusich
2016-03-07 22:53     ` myglc2
2016-03-08  7:34       ` Chris Marusich
2016-03-08 17:58         ` myglc2
2016-03-25 21:47           ` myglc2

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEKzfHmT=1EbBNU=Jw922wnYm4DRu8U1CTf-x0V5sL864rGbLw@mail.gmail.com' \
    --to=cmmarusich@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=myglc2@gmail.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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.