Re: Guix vs GuixSD

[myglc2 <myglc2@gmail.com>]

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