Hi George, > You misunderstand. I do not propose changing names. I do propose that > you present Guix + GuixSD to the outside world in a unified way. I meant > "GuixE" as a "handle" to that idea. Sorry if that was misleading.
I understand the idea, and I recognize that this is a possible means to address the overlap between Guix and the distribution. Since you can build virtual machine images of GuixSD even if you don’t have GuixSD installed yourself, the difference between Guix and GuixSD may seem blurry. However, *installing* GuixSD and using it as distribution is *very different* from using Guix as a tool to build and share reproducible environments (be that as a Docker image, as a tarball, as a temporary environment, as a virtual machine image, or just by installing packages into a profile). GuixSD is both a natural extension of the ideas and features of Guix, but it is also a variant of the GNU system that you can install on your workstation, server, or laptop. > PRODUCT DESCRIPTION: > > The Guix software environment manager creates user environments that > are completely and independently specified by users. Guix users are > never stuck needing software that a Sysadmin can't, won't, or hasn't > installed. A Guix user can run multiple, differing environments > simultaneously and can replicate any environment on any Guix run-time > platform. I wouldn’t write it like this, but explicitly mentioning that users can specify any number of reproducible environments is a good idea, in my opinion. > Guix provides system-wide environment management when > appropriate to the run-time platform. This sounds *really* vague, and it shows that is done just to avoid speaking of GuixSD as a separate entity :) > Creation, modification, and > upgrade are atomic and roll-back is instantaneous, so Guix users and > sysadmins are never stuck with a broken user environment or system. “instantaneous” is not true for GuixSD where a reboot is required. > Guix implements a functional specification of package, user, and system > configurations using the Scheme language. Guix complies with the FSF > Four Essential Freedoms and Free System Distribution Guidelines and > provides easy and immediate access to the exact source being run. > By > default, Guix uses pre-built package substitutes from the Guix build > farm and mirrors but users may build any package, or a complete system, > from package developer sources. I don’t think this feels at home in an introduction. It doesn’t seem like much of a feature; in my opinion this is an implementation detail. > Guix is available on multiple run-time platforms including bare metal > (GuixSD), Virtual Machines (QEMU image), and any GNU/Linux distro (Guix > Binary). I don’t know about this. I still feel that GuixSD (be it on bare metal or on virtual machines) is a different beast; different enough to deserve separate intros, each with more detail than one could achieve by glossing over the differences. > SALES MESSAGE: > > Introducing Guix - the first software environment manager that solves > the problems of both sysadmins and users of GNU/Linux: > > - sysadmin problems: > > - Because I have to modify the system to meet user needs and these are > risky, I have to prototype every change on a test system > > - because system changes takes time, I can't keep up with user software > requests and users are unhappy > > - Users request conflicting packages, so I can't make everyone happy > > - user problems: > > - I need software that sysops won't or hasn't provided > > - sysops changes stuff and my environment breaks > > - I need software that sysops can't provide because it conflicts with > other user requirements I’m not a fan of sales messages and that kind of language (“introducing”, “the first foo to do bar”, etc); I also don’t like that these are all worded negatively, which is something we should avoid. I agree that we can speak of Guix in a little wider terms (e.g. “software environment manager” instead of just “package manager”), but I feel even more strongly that trying to smoothen over the differences between Guix and GuixSD would not be a good idea. I do agree, though, that we could describe GuixSD as a special case of other Guix features: it’s a bare-metal deployment of these virtual systems that “guix system” can produce. I still think that moving the introduction and the screenshots of GuixSD to a sub-page would be an improvement, as it reduces confusion and keeps the focus on the features of Guix (which also include “guix system”, which has GuixSD as a special case). -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
