Re: Guix vs GuixSD

[Chris Marusich]

myglc2 <address@hidden> 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