Re: Guix wiki

[Ricardo Wurmus]

Matt <matt@excalamus.com> writes:

> My guess, as Guix is a package manager, there are two audiences:
> package users (end users) and package maintainers. I'm curious what
> degree of separation between those should exist for Guix.

On of the goals of the GNU project is to give users the tools to
liberate themselves from arbitrary restrictions.  The Hurd pretty much
does away with the concept of an all-powerful root user as the only
privileged account to alter settings such as network, file system
virtualization, drivers, etc.

Emacs is designed to be a collection of extensions.

Guile was designed to be the extension language for every part of the
GNU system that was still constrained by the dead systems programming
language C.

Likewise, Guix aims to give “end users” control over their software
environments and systems, privileges that used to be reserved for the
sysadmin class.  All design decisions in Guix are aimed at extending
privileges to users: package transformations, package inheritance,
building packages from JSON descriptions for those averse to Scheme,
per-user channels, time machine, an extensive API to build and export
systems, virtual machines, containers, environments, etc.

We don’t like to erect arbitrary boundaries between “end users” and
maintainers.  The concept of “maintainer” only ever has meaning in the
context of project management.  (Unlike nixpkgs, for example, we don’t
record package maintainers with package definitions.)

So, ideally, the information in the manual / cookbook will benefit all
users, no matter how deep they want to dive.  A single document cannot
accomplish this, which is why we recognize the existence of other GNU
manuals and link to them where possible.

-- 
Ricardo