Guix vs GuixSD

Guix vs GuixSD

[myglc2]

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

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: guix-ov2.dot --]
[-- Type: application/octet-stream, Size: 1869 bytes --]

// Overview of Guix & GuixSD
digraph G {
	compound=true
	size="6,6"

	{ node [shape=box style = filled fillcolor="azure" color = transparent fontname = courier]
		packages [label = "Store"]
		system [label = "Stateful\nSystem\nEnvironment"]
		systemSD [label = "Guix\nSystem\nEnvironment"]
		GNULinux [label = "GNU/Linux \nDistribution"]
		user [label = "Guix User\nEnvironment"]
		userSD [label = "Guix User\nEnvironment"]
		packagesx [label = "Store"]
		substitutes [label = "Pre-built\nPackage"]
		pkgsource [label = "Package Source"]
		hydra [label = "Build Farm"]
		guix [image="./guix-artwork/website/static/base/img/Guix-package.png" label=""]
		guix2 [image="./guix-artwork/website/static/base/img/Guix-package.png" label=""]
		GuixSD [image="./guix-artwork/website/static/base/img/GuixSD-logo.png" label="" fillcolor="black"]
	}

	subgraph cluster_pkgsource {
		label = "Free Software\nDeveloper's Site"
		style = filled fillcolor= azure3 color = transparent
		fontname = courier
		pkgsource
	}

	subgraph cluster_hydra {
		label = "Guix  Hydra"
		style = filled fillcolor= azure3 color = transparent
		fontname = courier
		hydra -> substitutes [nodesep = .2]
	}

	subgraph cluster_guixSD {
		label = "Computer Running\nGuix + GuixSD"
		labelloc = "b"
		style = filled fillcolor= azure3 color = transparent
		fontname = courier
		{ rank=same guix2 ->  packagesx [ dir = none ]}
		guix2 -> systemSD -> GuixSD [ dir = none ]
		userSD -> guix2  [ dir = none ]
	}

	subgraph cluster_guix {
		label = "Computer Running\nGuix + GNU/Linux"
		labelloc = "b"
		style = filled fillcolor= azure3 color = transparent
		fontname = courier
		{ rank=same guix ->  packages [ dir = none ]}
		guix ->  system -> GNULinux [ dir = none ]
		user -> guix  [ dir = none ]
	}
		
	pkgsource -> hydra
	substitutes -> guix
	pkgsource -> guix
	substitutes -> guix2
	pkgsource -> guix2
}

[-- Attachment #3: guix-ov2.png --]
[-- Type: image/png, Size: 38176 bytes --]

[-- Attachment #4: guix-ov.dot --]
[-- Type: application/octet-stream, Size: 1613 bytes --]

// Overview of Guix & GuixSD
digraph G {
	compound=true
	size="6,6"

	{ node [shape=box style = filled fillcolor="azure" color = transparent fontname = courier]
		packages [label = "Store"]
		GNULinux [label = "GNU/Linux \nDistribution"]
		user [label = "Guix User\nEnvironment"]
		userSD [label = "Guix User\nEnvironment"]
		packagesx [label = "Store"]
		substitutes [label = "Pre-built\nPackage"]
		pkgsource [label = "Package Source"]
		hydra [label = "Build Farm"]
		guix [image="./guix-artwork/website/static/base/img/Guix-package.png" label=""]
		guixSD [image="./guix-artwork/website/static/base/img/GuixSD-package.png" label=""]
	}

	subgraph cluster_pkgsource {
		label = "Free Software\nDeveloper's Site"
		style = filled fillcolor= azure3 color = transparent
		fontname = courier
		pkgsource
	}

	subgraph cluster_hydra {
		label = "Guix  Hydra"
		style = filled fillcolor= azure3 color = transparent
		fontname = courier
		hydra -> substitutes [nodesep = .2]
	}

	subgraph cluster_guixSD {
		label = "Computer Running\nGuixSD"
		labelloc = "b"
		style = filled fillcolor= azure3 color = transparent
		fontname = courier
		{ rank=same guixSD ->  packagesx [ dir = none ]}
		userSD -> guixSD  [ dir = none ]
	}

	subgraph cluster_guix {
		label = "Computer Running\nGuix + GNU/Linux"
		labelloc = "b"
		style = filled fillcolor= azure3 color = transparent
		fontname = courier
		{ rank=same guix ->  packages [ dir = none ]}
		guix ->  GNULinux [ dir = none ]
		user -> guix  [ dir = none ]
	}
		
	pkgsource -> hydra
	substitutes -> guix
	pkgsource -> guix
	substitutes -> guixSD
	pkgsource -> guixSD
}

[-- Attachment #5: guix-ov.png --]
[-- Type: image/png, Size: 36443 bytes --]

Re: Guix vs GuixSD

[Chris Marusich]

[-- 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 --]

Re: Guix vs GuixSD

[myglc2]

Chris Marusich <cmmarusich@gmail.com> writes:
[...]
> 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?

No, the problem is at a higher level than the manual.

The current packaging of Guix within GuixSD obfuscates what is going on
and makes understanding the Guix-verse difficult.

I drew the diagrams: To illustrate and stimulate a discussion of this.

Do you have any thoughts about the diagrams?

Re: Guix vs GuixSD

[Chris Marusich]

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

(Apologies for top-posting; my mobile email client doesn't seem to let me
post in any other way...)

Regarding your diagrams, I guess the one that shows GuixSD using Guix makes
a little more sense to me than the one that shows GuixSD as a total
replacement for Guix. However, I'm not sure exactly how GuixSD uses Guix
when managing the system, so I will defer to the opinion of others on the
mailing list who know more about theses things than me.

It isn't clear to me what you want to know. Perhaps if you can ask a more
concrete question, it will be easier for the others to answer?

To reiterate what I said before: my current understanding is that Guix is a
functional package manager (with a lot of fantastic features) that you can
run anywhere. That's all, really. And GuixSD is a full GNU operating system
which currently uses Linux-Libre as its kernel, Guix as its package
manager, and Shepherd (formerly DMD) as its init system. Similar to a
GNU/Linux distribution, the GuixSD system comes with some extra "glue"
which makes all those separate components work together out of the box. But
the way that those components are glued together in GuixSD allows you to
enjoy certain benefits that you don't get with other systems (software
freedom, system configuration in guile, easy rollback of system upgrades,
etc). I don't yet know much about how GuixSD's "glue" is implemented, but I
think that's the gist of it.

On Mon, Feb 15, 2016, 09:37 myglc2 <myglc2@gmail.com> wrote:

> Chris Marusich <cmmarusich@gmail.com> writes:
> [...]
> > 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?
>
> No, the problem is at a higher level than the manual.
>
> The current packaging of Guix within GuixSD obfuscates what is going on
> and makes understanding the Guix-verse difficult.
>
> I drew the diagrams: To illustrate and stimulate a discussion of this.
>
> Do you have any thoughts about the diagrams?
>
>
>
>

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

Re: Guix vs GuixSD

[Jookia]

On Tue, Feb 16, 2016 at 03:26:01AM +0000, Chris Marusich wrote:
> (Apologies for top-posting; my mobile email client doesn't seem to let me
> post in any other way...)
>
> Regarding your diagrams, I guess the one that shows GuixSD using Guix makes
> a little more sense to me than the one that shows GuixSD as a total
> replacement for Guix. However, I'm not sure exactly how GuixSD uses Guix
> when managing the system, so I will defer to the opinion of others on the
> mailing list who know more about theses things than me.
>
> It isn't clear to me what you want to know. Perhaps if you can ask a more
> concrete question, it will be easier for the others to answer?
>
> To reiterate what I said before: my current understanding is that Guix is a
> functional package manager (with a lot of fantastic features) that you can
> run anywhere. That's all, really. And GuixSD is a full GNU operating system
> which currently uses Linux-Libre as its kernel, Guix as its package
> manager, and Shepherd (formerly DMD) as its init system. Similar to a
> GNU/Linux distribution, the GuixSD system comes with some extra "glue"
> which makes all those separate components work together out of the box. But
> the way that those components are glued together in GuixSD allows you to
> enjoy certain benefits that you don't get with other systems (software
> freedom, system configuration in guile, easy rollback of system upgrades,
> etc). I don't yet know much about how GuixSD's "glue" is implemented, but I
> think that's the gist of it.

I can see how this is confusing, after all, how would a package manager be used
to package things like an initramfs or SSH configuration? Well, the trick is
that GuixSD effectively 'packages' your os-configuration.

If we look at a Guix package we can see it takes a configuration of sources,
a build system, maybe some build phases and maybe some more things like patches.
From this a few derivations are built, which are basically things put in the
Guix store. These derivations include the patched source code and the final
binaries. Then Guix takes these final binary derivations and puts them in your
profile so you can use them if it's something you installed explicitly.

The key here is that Guix generates a lot of things, though most often this is
hidden by substitute downloads of the final binary unless you compile everything
yourself. How could you build an operating system out of this? Well, think of
the operating system as one giant package that Guix generates a ton of
derivations for then links them to your system's profile. So if you have SSH
running it'll make you a cool SSH configuration derivation then link that in.

"Why would you do this?" is probably your next question. Well, let's say you
update a ton of Guix packages and it breaks half way. This is okay since it
won't change your Guix profile until you actually have a working set of
packages and all their dependencies. You can also rollback in case the latest
version of your favourite browser Icecat breaks an add-on you absolutely need.

Now if we apply this to the operating system 'package', or derivation, you can
switch between all the things that make up your system in much the same way or
roll back. The switching here is done using 'guix system reconfigure' or at boot
through GRUB if the latest version of a system configuration, such as a Shepherd
service somehow kills your entire system. Guix also has support for installing
your os-configuration not just to your drive, but to a VM or a container.
Imagine looking online for Guix configurations to try in a VM then setting that
up as your main system configuration!

Perhaps I went a bit off topic there but I hope this give some understanding.
Jookia.

Re: Guix vs GuixSD

[Chris Marusich]

Jookia <166291@gmail.com> writes:

> Perhaps I went a bit off topic there but I hope this give some understanding.

Thank you for the explanation. That's more or less what I imagined was
going on with GuixSD.

Best regards,
Chris

Re: Guix vs GuixSD

[myglc2]

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

myglc2 <myglc2@gmail.com> writes: (paraphrased)

> I started experimenting with Nix and NixOS 6 weeks ago. 3 weeks ago I
> switched to guixSD. I found it difficult to determine exactly which
> parts of the volumminous (and tasty) Guix doc to read. To clarify my
> thoughts, I made diagrams of Guix and GuixSD. I intended to show the
> differences between Guix and GuixSD, but frankly, they seemed more
> alike than not.

+ 2.5 weeks ==> another diagram of the Guix-verse.

Comments?  Corrections?  TIA - George


[-- Attachment #2: guixvssd2.dot --]
[-- Type: application/octet-stream, Size: 3294 bytes --]

// GNU GuixSD vs Guix on Debian
digraph G {
	compound=true
	size="12,12"
	edge [fontname = helvetica]
	graph [fontname = helvetica]
	node  [fontname = helvetica]
	{ node [shape=box style = filled fillcolor="white" color = transparent]
		pkgsource [label = "Source"]
		substitutes [label = "Prebuilt\nPackage"]
	}
	// guixondeb cluster
	{ node [shape=box style = filled fillcolor=pink color = transparent]		
		dpkgs [label = "Debian packages" fillcolor=grey]
	}
	{ node [shape=box style ="filled,rounded" fillcolor=pink color = transparent]		
		guixd2 [label = "Guix build daemon"]
		debs [label = "Debian system services" fillcolor=grey]
	}
	{ node [shape=box style ="filled,rounded" fillcolor=lightblue color = transparent]		
		duser [label = "user"]
		guix [label="guix"]
	}
	{ node [shape=box style ="filled" fillcolor=lightblue color = transparent]		
		du1pkgs [label = "user packages"]
	}
	subgraph cluster_guixdeb {
		label = "GNU Guix Binary Install on Debian"
		labelloc = "t"
		style = filled fillcolor= azure2 color = transparent
		duser -> dpkgs  [ label = "/usr/bin" ]
		duser -> guix  [ label = " ~/.config/guix/latest  " ]
		duser -> du1pkgs  [ label = " ~/.guix-profile  " ]
		subgraph cluster_debstore {
			label = "Guix Store /gnu/store"
			labelloc = "b"
			style = filled fillcolor= tan color = transparent
			du1pkgs
			guix
		}
		{ rank=same debs -> guixd2 [style=invis] }
		du1pkgs -> guixd2  [dir = back ltail=cluster_debstore ]
	}
	guix -> guixd2 [label=rpc style=dotted]
	// source & hydra clusters
	subgraph cluster_pkgsource {
		label = "Developer"
		labelloc = "t"
		style = filled fillcolor= azure2 color = transparent
		pkgsource
	}
	subgraph cluster_hydra {
		label = "Guix Hydra"
		style = filled fillcolor= azure2 color = transparent
		substitutes
	}
	// guixSD cluster
	{ node [shape=box style = filled fillcolor=pink color = transparent]		
		spkgs [label = "system packages"]
	}
	{ node [shape=box style ="filled,rounded" fillcolor=pink color = transparent]		
		guixd [label = "Guix build daemon"]
		guixs [label = "Guix system services"]
	}
	{ node [shape=box style ="filled,rounded" fillcolor=lightblue color = transparent]		
		user [label = "user"]
		guix2 [label="guix"]
	}
	{ node [shape=box style ="filled" fillcolor=lightblue color = transparent]		
		u1pkgs [label = "user packages"]
	}
	subgraph cluster_guixSD {
		label = "GNU GuixSD Native Install"
		labelloc = "t"
		style = filled fillcolor= azure2 color = transparent
		user -> guix2 [ label = " ~/.config/guix/latest  " ]
		user -> u1pkgs  [ label = " ~/.guix-profile  " ]
		user -> spkgs [ label = " /run/current-system/profile  "]
		subgraph cluster_guixstore {
			label = "Guix Store /gnu/store"
			labelloc = "b"
			style = filled fillcolor= tan color = transparent
			guix2
			u1pkgs
			spkgs
//			{ rank=same guix2 -> u1pkgs -> spkgs }
		}
		u1pkgs -> guixd  [dir = back ltail=cluster_guixstore ]
		{ rank=same guixd -> guixs [style=invis] }
	}
	guix2 -> guixd [label=rpc style=dotted]
	// connections source & hydra & guix & guixSD
	pkgsource -> substitutes [lhead=cluster_hydra ltail=cluster_pkgsource]
	pkgsource -> guixd [ltail=cluster_pkgsource]
	substitutes -> guixd [ltail=cluster_hydra]
	pkgsource -> guixd2 [ltail=cluster_pkgsource]
	substitutes -> guixd2 [ltail=cluster_hydra]
}

[-- Attachment #3: guixvssd2.png --]
[-- Type: image/png, Size: 67849 bytes --]

Re: Guix vs GuixSD

[Ludovic Courtès]

myglc2 <myglc2@gmail.com> skribis:

> myglc2 <myglc2@gmail.com> writes: (paraphrased)
>
>> I started experimenting with Nix and NixOS 6 weeks ago. 3 weeks ago I
>> switched to guixSD. I found it difficult to determine exactly which
>> parts of the volumminous (and tasty) Guix doc to read. To clarify my
>> thoughts, I made diagrams of Guix and GuixSD. I intended to show the
>> differences between Guix and GuixSD, but frankly, they seemed more
>> alike than not.
>
> + 2.5 weeks ==> another diagram of the Guix-verse.
>
> Comments?  Corrections?  TIA - George

Overall I like the diagram!  It may help newcomers to have it.

That said, I don’t know where to put it!  It could go on the web site
and/or in the manual (under “Installation”?).  In both cases, I’d like
to have concrete ideas (aka. patches ;-)) showing how to do that.

Thoughts?  :-)

Thanks,
Ludo’.

Re: Guix vs GuixSD

[myglc2]

ludo@gnu.org (Ludovic Courtès) writes:

> myglc2 <myglc2@gmail.com> skribis:
>
>> myglc2 <myglc2@gmail.com> writes: (paraphrased)
>>
>>> I started experimenting with Nix and NixOS 6 weeks ago. 3 weeks ago I
>>> switched to guixSD. I found it difficult to determine exactly which
>>> parts of the volumminous (and tasty) Guix doc to read. To clarify my
>>> thoughts, I made diagrams of Guix and GuixSD. I intended to show the
>>> differences between Guix and GuixSD, but frankly, they seemed more
>>> alike than not.
>>
>> + 2.5 weeks ==> another diagram of the Guix-verse.
>>
>> Comments?  Corrections?  TIA - George
>
> Overall I like the diagram!  It may help newcomers to have it.
>
> That said, I don’t know where to put it!  It could go on the web site
> and/or in the manual (under “Installation”?).  In both cases, I’d like
> to have concrete ideas (aka. patches ;-)) showing how to do that.

Thanks. Happy to submit patches once we have a plan. How about:

manual: rework introduction & diagram to be consistent & put it there?

web site: a simplified version on the download page?

Re: Guix vs GuixSD

[Chris Marusich]

myglc2 <myglc2@gmail.com> writes:

Everyone loves pictures! Here are my thoughts about the graphic:

* What do the different colors mean? It is not clear to me what red,
  blue, and gray mean. I see that some of the boxes are grouped by
  color, but I don't see the pattern. The same question applies to the
  round corners vs. sharp corners. If there is no discernible pattern,
  maybe they should look more similar.

* Why is the "rpc" arrow drawn using dashed lines, but all other arrows
  are drawn using solid lines? I think you can just use solid lines in
  all cases to reduce cognitive noise.

* Guix Hydra: This graphic makes hydra look special. But can't this role
  be filled by anyone with a server who has built and published packages
  (e.g., with guix publish)?  Hydra is just the default place from which
  substitues are downloaded. Perhaps we can rename this to something
  like "substitutes publisher" to reflect the decentralized architecture
  of guix, which is one of its great features.

* Guix Hydra: consider replacing "prebuilt package" with "substitutes"
  or "binary substitutes", so that it matches the terminology used in
  other parts of the manual.

* Guix build daemon: consider calling this simply the "guix daemon".

* GNU Guix Binary Install on Debian: consider removing the word
  "binary". I don't think it adds any clarity here, especially because
  you can build Guix from source on Debian.

* GNU GuixSD Native Install: consider calling this the "GNU Guix System
  Distribution (GuixSD)" to match the terminology used in the manual. I
  don't think that using the word "native" adds any clarity here.

* GNU GuixSD Native Install: To make the commentary for the arrow
  pointing to "system packages" match the the commentary for the arrow
  in "GNU Guix Binary Install on Debian" pointing to "Debian packages,"
  consider using a specific common program name as the example. For
  instance, use "/usr/bin/sh" (or whatever the path is on Debian) and
  "/run/current-system/profile/bin/sh". Currently, the Debian example
  uses the "/usr/bin" directory, while the GuixSD example uses a
  conceptually different directory, so the comparison is not as clear as
  it could be.

* Consider replacing the single word "guix" with a phrase like "guix
  tools and packages", since the contents of ~/.config/guix/latest, if
  present, will be used for both command-line tools like "guix
  package" as well as for finding package definitions.

* One concept that is missing from this graphic is the idea that you can
  add your own custom package definitions via the GUIX_PACKAGE_PATH
  environment variable (or the --load-path option to commands such as
  "guix build"). Adding this concept to the graphic may help users more
  quickly realize the freedom they have for hooking up their own package
  definitions into the Guix system, which is not as easy to do using
  other package managers. What do you think? Can it be added without
  cluttering it up too much?

* Consider replacing "Debian" with "foreign distribution" to keep the
  graphic sufficiently generic.

* "Guix system services": consider renaming "Guix" to "GuixSD". Also, I
  wonder if including this box here will make people think that GuixSD
  services are basically the same as other services launched by init
  systems like systemd in distros like Debian on startup. Case in point:
  where does the "operating-system-etc-service" fit in? Does it have a
  Debian analogue? I'm not sure. Maybe this is OK as-is.

Thank you for taking the time to make a graphic to help explain things!

Chris

Re: Guix vs GuixSD

[myglc2]

Chris Marusich <cmmarusich@gmail.com> writes:

> myglc2 <myglc2@gmail.com> writes:
>
> Everyone loves pictures! Here are my thoughts about the graphic:
>
> * What do the different colors mean? It is not clear to me what red,
>   blue, and gray mean. I see that some of the boxes are grouped by
>   color, but I don't see the pattern.

- blue: "user scope" things over which the user has control.

- pink: "system scope" components controlled by the Guix admin.

- grey: "system scope" components controlled by Debian admin (who may
        be different from the Guix admin)

Note: To keep it simple I omitted the Debian apt package manager.

>   The same question applies to the round corners vs. sharp corners. If
>   there is no discernible pattern, maybe they should look more
>   similar.

- square: built package 
- round: actor or active process

> * Why is the "rpc" arrow drawn using dashed lines, but all other arrows
>   are drawn using solid lines? I think you can just use solid lines in
>   all cases to reduce cognitive noise.

You may be right but I was thinking that rpc is different than the
others which are more like data flow. Actually I am thinking of making
profile lines dotted too. What would you think of that?

> * Guix Hydra: This graphic makes hydra look special. But can't this role
>   be filled by anyone with a server who has built and published packages
>   (e.g., with guix publish)?  Hydra is just the default place from which
>   substitues are downloaded. Perhaps we can rename this to something
>   like "substitutes publisher" to reflect the decentralized architecture
>   of guix, which is one of its great features.

I agree with your points. But I am trying to keep it simple enough to be
understood without a lot of explanation. So I tied to use specific
examples rather than Guix concepts and capabilities.

> * Guix Hydra: consider replacing "prebuilt package" with "substitutes"
>   or "binary substitutes", so that it matches the terminology used in
>   other parts of the manual.

I went back and forth on this. "substitutes" requires explanation but I
think anyone will understand a "prebuilt package".

> * Guix build daemon: consider calling this simply the "guix daemon".

At first I did. Then I switched for the same reason as above.

> * GNU Guix Binary Install on Debian: consider removing the word
>   "binary". I don't think it adds any clarity here, especially because
>   you can build Guix from source on Debian.

I wanted to use a specific installation example. I thought that the
majority of installs on "foreign systems" would be binary so I used
that. Other possibilities:

- "GNU Guix installed on Debian (your suggestion)
- "GNU Guix installed on Debian from source or binary"
- "GNU Guix installed on GNU/Linux distribution"

> * GNU GuixSD Native Install: consider calling this the "GNU Guix System
>   Distribution (GuixSD)" to match the terminology used in the manual. I
>   don't think that using the word "native" adds any clarity here.

You and I know what GuixSD means but I want a noobe to understand that
GuixSD is all that is needed on the hardware. How about 'GNU GuixSD
installed directly to computer hardware" ?

> * GNU GuixSD Native Install: To make the commentary for the arrow
>   pointing to "system packages" match the the commentary for the arrow
>   in "GNU Guix Binary Install on Debian" pointing to "Debian
>   packages,"

I made these different because I am trying to show that Guix lets you
manage a system profile as opposed to "whatever is currently in
/usr/bin" to set the stage for talking about generations.

>   consider using a specific common program name as the example. For
>   instance, use "/usr/bin/sh" (or whatever the path is on Debian) and
>   "/run/current-system/profile/bin/sh".

I was trying to suggest the concepts of system profile, user profile,
and active guix version. So I used guix links rather than specific exe
locations.  Maybe the symbolic links should be replaced with labels that
are less guix-centric?

>   Currently, the Debian example uses the "/usr/bin" directory, while
>   the GuixSD example uses a conceptually different directory, so the
>   comparison is not as clear as it could be.

Could you say more about what you mean by "conceptually different
directory" ?

> * Consider replacing the single word "guix" with a phrase like "guix
>   tools and packages", since the contents of ~/.config/guix/latest, if
>   present, will be used for both command-line tools like "guix
>   package" as well as for finding package definitions.

How about "guix tools and package definitions" ?

> * One concept that is missing from this graphic is the idea that you can
>   add your own custom package definitions via the GUIX_PACKAGE_PATH
>   environment variable (or the --load-path option to commands such as
>   "guix build"). Adding this concept to the graphic may help users more
>   quickly realize the freedom they have for hooking up their own package
>   definitions into the Guix system, which is not as easy to do using
>   other package managers. What do you think? Can it be added without
>   cluttering it up too much?

I agree this would be great to show in a diagram. How about a separate
diagram? It would would only need to show one machine running Guix. So
the additional complexity will be offset by removing 3 machines.

> * Consider replacing "Debian" with "foreign distribution" to keep the
>   graphic sufficiently generic.

I used Debian because everyone knows what it is whereas "foreign
distribution" is "guix centric" and would have to be explained.

> * "Guix system services": consider renaming "Guix" to "GuixSD".

One issue with "GuixSD" is that GuixSD does not exist independently of
Guix, e.g., you can not install Guix without getting GuixSD tools and
packages. FWIW, thinking that these were separate caused a lot of
confusion for me in the first few weeks of using GuixSD.

From a Guix-centric point of view, whether your system is running "Guix
system services" or "Debian system services" only depends on whether you
have gotten around to running 'guix system init'. This is actually an
incredibly powerful and, so far, "not much talked about" feature of
Guix. But untill we know how we want to present this feature to the
world, I think we should go easy on pushing the idea that Guix and
GuixSD are so separate.

>   Also, I wonder if including this box here will make people think
>   that GuixSD services are basically the same as other services
>   launched by init systems like systemd in distros like Debian on
>   startup.

AIUI they are.

>   Case in point: where does the "operating-system-etc-service" fit in?
>   Does it have a Debian analogue? I'm not sure. Maybe this is OK
>   as-is.

Not qualified to say. Could someone that understands please comment?

>
> Thank you for taking the time to make a graphic to help explain things!
>
> Chris

Thank you for the constructive comments. Once I know specifically where
the diagram will be used I will adjust some of these things. At that
point I will revisit your comments and may have more questions :-)

- George

Re: Guix vs GuixSD

[Chris Marusich]

myglc2 <myglc2@gmail.com> writes:

> You may be right but I was thinking that rpc is different than the
> others which are more like data flow. Actually I am thinking of making
> profile lines dotted too. What would you think of that?

Unless the distinction is explained in a legend, I think this just
serves to distract. I can't speak for others, but the pattern was not
obvious to me.

>> * Guix Hydra: This graphic makes hydra look special. But can't this role
>>   be filled by anyone with a server who has built and published packages
>>   (e.g., with guix publish)?  Hydra is just the default place from which
>>   substitues are downloaded. Perhaps we can rename this to something
>>   like "substitutes publisher" to reflect the decentralized architecture
>>   of guix, which is one of its great features.
>
> I agree with your points. But I am trying to keep it simple enough to be
> understood without a lot of explanation. So I tied to use specific
> examples rather than Guix concepts and capabilities.

That's fair. A graphic can only say so much.

>> * Guix Hydra: consider replacing "prebuilt package" with "substitutes"
>>   or "binary substitutes", so that it matches the terminology used in
>>   other parts of the manual.
>
> I went back and forth on this. "substitutes" requires explanation but I
> think anyone will understand a "prebuilt package".

It's probably fine to use "prebuilt package" if you feel it will be
clearer. Same for "guix build daemon".

>> * GNU Guix Binary Install on Debian: consider removing the word
>>   "binary". I don't think it adds any clarity here, especially because
>>   you can build Guix from source on Debian.
>
> I wanted to use a specific installation example. I thought that the
> majority of installs on "foreign systems" would be binary so I used
> that. Other possibilities:
>
> - "GNU Guix installed on Debian (your suggestion)
> - "GNU Guix installed on Debian from source or binary"
> - "GNU Guix installed on GNU/Linux distribution"

I don't have a strong opinion between any of those alternatives, so
whatever you think is clear seems fine to me.

>> * GNU GuixSD Native Install: consider calling this the "GNU Guix System
>>   Distribution (GuixSD)" to match the terminology used in the manual. I
>>   don't think that using the word "native" adds any clarity here.
>
> You and I know what GuixSD means but I want a noobe to understand that
> GuixSD is all that is needed on the hardware. How about 'GNU GuixSD
> installed directly to computer hardware" ?

I suppose I like "native" better than the longer alternative, but I
still think that "system distribution" is a better alternative, since
I think it's pretty clear that it's a full system installation.

>>   Currently, the Debian example uses the "/usr/bin" directory, while
>>   the GuixSD example uses a conceptually different directory, so the
>>   comparison is not as clear as it could be.
>
> Could you say more about what you mean by "conceptually different
> directory" ?

I mean that the /usr/bin is analogous to the
/run/current-system/profile/bin directory (it's where a certain group of
executables are installed), but the /run/current-system/profile
directory is not analogous to the /usr/bin directory. The former
represents a Guix profile, while the latter represents only "the
directory to which a certain group of executables are installed." The
Guix profile is much different than the /usr/bin directory, but the bin
directory in your Guix profile does serve a similar purpose as the
/usr/bin directory.

>> * Consider replacing the single word "guix" with a phrase like "guix
>>   tools and packages", since the contents of ~/.config/guix/latest, if
>>   present, will be used for both command-line tools like "guix
>>   package" as well as for finding package definitions.
>
> How about "guix tools and package definitions" ?

On second thought, that's kind of a mouthful. Maybe "guix" is better
because it is more succinct, especially if we do not include mention of
GUIX_PACKAGE_PATH. Perhaps it's fine to group it all under the "guix"
label like you did originally.

>> * One concept that is missing from this graphic is the idea that you can
>>   add your own custom package definitions via the GUIX_PACKAGE_PATH
>>   environment variable (or the --load-path option to commands such as
>>   "guix build"). Adding this concept to the graphic may help users more
>>   quickly realize the freedom they have for hooking up their own package
>>   definitions into the Guix system, which is not as easy to do using
>>   other package managers. What do you think? Can it be added without
>>   cluttering it up too much?
>
> I agree this would be great to show in a diagram. How about a separate
> diagram? It would would only need to show one machine running Guix. So
> the additional complexity will be offset by removing 3 machines.

That might be helpful. It's a pretty simple concept, so I'm not sure it
warrants its own graphic, but if you have an idea for presenting the
different ways you can discover package definitions in a graphic, I'd be
happy to take a peek at it.

>> * Consider replacing "Debian" with "foreign distribution" to keep the
>>   graphic sufficiently generic.
>
> I used Debian because everyone knows what it is whereas "foreign
> distribution" is "guix centric" and would have to be explained.

That seems fair; I just thought we'd prefer to avoid mentioning specific
distributions to keep the manual generic.

>> * "Guix system services": consider renaming "Guix" to "GuixSD".
>
> One issue with "GuixSD" is that GuixSD does not exist independently of
> Guix, e.g., you can not install Guix without getting GuixSD tools and
> packages. FWIW, thinking that these were separate caused a lot of
> confusion for me in the first few weeks of using GuixSD.
>
> From a Guix-centric point of view, whether your system is running "Guix
> system services" or "Debian system services" only depends on whether you
> have gotten around to running 'guix system init'. This is actually an
> incredibly powerful and, so far, "not much talked about" feature of
> Guix. But untill we know how we want to present this feature to the
> world, I think we should go easy on pushing the idea that Guix and
> GuixSD are so separate.

Since I haven't run Guix on a foreign distro yet, I might not understand
this point as well as you do. Are you saying that you can run "Guix
system services" on Debian at startup if you run "guix system init"?

Chris

Re: Guix vs GuixSD

[myglc2]

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

Chris Marusich <cmmarusich@gmail.com> writes:

[...]

Thank you for the helpful comments. I have revised the diagram
accordingly. Please let me know if I missed something.

>>> * "Guix system services": consider renaming "Guix" to "GuixSD".
>>
>> One issue with "GuixSD" is that GuixSD does not exist independently of
>> Guix, e.g., you can not install Guix without getting GuixSD tools and
>> packages. FWIW, thinking that these were separate caused a lot of
>> confusion for me in the first few weeks of using GuixSD.
>>
>> From a Guix-centric point of view, whether your system is running "Guix
>> system services" or "Debian system services" only depends on whether you
>> have gotten around to running 'guix system init'. This is actually an
>> incredibly powerful and, so far, "not much talked about" feature of
>> Guix. But untill we know how we want to present this feature to the
>> world, I think we should go easy on pushing the idea that Guix and
>> GuixSD are so separate.
>
> Since I haven't run Guix on a foreign distro yet, I might not understand
> this point as well as you do. Are you saying that you can run "Guix
> system services" on Debian at startup if you run "guix system init"?

I am saying you can "upgrade" your computer from, say, Guix on Debian to
GuixSD by doing ...

     mount /dev/sdX /mnt
     guix system init /mnt/etc/config.scm /mnt

... where /dev/sdX is a new system disk. With more complicated maneuvers
you can no doubt convert an existing system disk.

- George
 

[-- Attachment #2: guixvssd2.png --]
[-- Type: image/png, Size: 64926 bytes --]

[-- Attachment #3: guixvssd2.dot --]
[-- Type: application/octet-stream, Size: 3175 bytes --]

// GNU Guix on Debian vs GuixSD
digraph G {
	compound=true
	size="12,12"
	edge [fontname = helvetica]
	graph [fontname = helvetica]
	node  [fontname = helvetica]
	{ node [shape=box style = filled fillcolor="white" color = transparent]
		pkgsource [label = "Source"]
		substitutes [label = "Prebuilt\nPackage"]
	}
	// guix on Debian
	{ node [shape=box style = filled fillcolor=pink color = transparent]
		dpkgs [label = "Debian packages" fillcolor=grey]
	}
	{ node [shape=box style ="filled,rounded" fillcolor=pink color = transparent]
		guixd2 [label = "Guix build daemon"]
		debs [label = "Debian system services" fillcolor=grey]
	}
	{ node [shape=box style ="filled,rounded" fillcolor=lightblue color = transparent]
		duser [label = "user"]
		guix [label="guix"]
	}
	{ node [shape=box style ="filled" fillcolor=lightblue color = transparent]
		du1pkgs [label = "user packages"]
	}
	subgraph cluster_guixdeb {
		label = "GNU Guix Installed on Debian"
		labelloc = "t"
		style = filled fillcolor= azure2 color = transparent
		duser -> dpkgs  [ label = "/usr/bin" ]
		duser -> guix  [ label = " ~/.config/guix/latest  " ]
		duser -> du1pkgs  [ label = " ~/.guix-profile  " ]
		subgraph cluster_debstore {
			label = "Guix Store /gnu/store"
			labelloc = "b"
			style = filled fillcolor= tan color = transparent
			du1pkgs
			guix
		}
		{ rank=same debs -> guixd2 [style=invis] }
		du1pkgs -> guixd2  [dir = back ltail=cluster_debstore ]
	}
	guix -> guixd2
	// source & hydra
	subgraph cluster_pkgsource {
		label = "Developer"
		labelloc = "t"
		style = filled fillcolor= azure2 color = transparent
		pkgsource
	}
	subgraph cluster_hydra {
		label = "Guix Hydra"
		style = filled fillcolor= azure2 color = transparent
		substitutes
	}
	// guixSD
	{ node [shape=box style = filled fillcolor=pink color = transparent]
		spkgs [label = "system packages"]
	}
	{ node [shape=box style ="filled,rounded" fillcolor=pink color = transparent]
		guixd [label = "Guix build daemon"]
		guixs [label = "Guix system services"]
	}
	{ node [shape=box style ="filled,rounded" fillcolor=lightblue color = transparent]
		user [label = "user"]
		guix2 [label="guix"]
	}
	{ node [shape=box style ="filled" fillcolor=lightblue color = transparent]
		u1pkgs [label = "user packages"]
	}
	subgraph cluster_guixSD {
		label = "GNU Guix System Distribution (GuixSD)"
		labelloc = "t"
		style = filled fillcolor= azure2 color = transparent
		user -> guix2 [ label = " ~/.config/guix/latest  " ]
		user -> u1pkgs  [ label = " ~/.guix-profile  " ]
		user -> spkgs [ label = " /run/current-system/profile/bin  "]
		subgraph cluster_guixstore {
			label = "Guix Store /gnu/store"
			labelloc = "b"
			style = filled fillcolor= tan color = transparent
			guix2
			u1pkgs
			spkgs
		}
		u1pkgs -> guixd  [dir = back ltail=cluster_guixstore ]
		{ rank=same guixd -> guixs [style=invis] }
	}
	guix2 -> guixd
	// source & hydra & guix & guixSD connections
	pkgsource -> substitutes [lhead=cluster_hydra ltail=cluster_pkgsource]
	pkgsource -> guixd [ltail=cluster_pkgsource]
	substitutes -> guixd [ltail=cluster_hydra]
	pkgsource -> guixd2 [ltail=cluster_pkgsource]
	substitutes -> guixd2 [ltail=cluster_hydra]
}

Re: Guix vs GuixSD

[myglc2]

myglc2 <myglc2@gmail.com> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
> [...]
>
> Thank you for the helpful comments. I have revised the diagram
> accordingly. Please let me know if I missed something.
>
[...]

Hey Chris,

I added this diagram to the doc introduction, referred to our
discussions to inform further simplification, revising the flow of the
introduction to be sympathetic. Submitted as a patch:

http://lists.gnu.org/archive/html/guix-devel/2016-03/msg00674.html

Should I have have made you a co-author? :-|

Anyway, I would be very interested in your comments ;)

Best - George