Re: Videos

[Pierre Neidhardt <pe.neidhardt@googlemail.com>]

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


As for the "no-turning-back" features of Guix (in my opinion):

- Rollbacks: system and user profiles are much harder to break.

- System integrity: because the system configuration is declarative,
this gives the user / sys-admin an actual guarantee of what's going
on.
On other Unices, it's much harder to tell when a random configuration
file has been touched somewhere.

- Keep your system config under version control: udev rules, Xorg, pam,
etc.  Thanks to Guile, the config can be made conditional to the
hardware or even the hostname!
With other Unices this is much harder, although I don't know much about
configuration management tools like Ansible.

- Replacement for other (not so good) package managers: TeXlive(!!!),
Emacs package.el, etc.  It makes user-profile declaration much easier.
Guix is possibly the only sane way to manage TeXlive.

- Package declaration using Guile: it makes it much easier to work out
package (re)definitions _en masse_.  It advantageously replaces concepts
such as Portage's USE flags (Guix is more flexible and can make use of
conditionals, filters, etc.), split packages (Guix "output" makes it much
easier and clearer to separate the doc, the libraries, the extra tools,
etc.).

- Non-propagated inputs: the first month using Guix I didn't get the
point of having two "inputs" and "propagated-inputs".  But now I see how
nice it is of Guix to not clutter my user profile with dependencies I
don't need for my own use.  See "inxi" for a good example: if I only
need a tool to report about my system and hardware, I don't necessarily
want 2-3 dozens of additional commandline tools (I know nothing of)
added to my PATH.

- guix environment: Like non-propagated inputs, it's a neat way to keep
the user profile clean.

- Partial upgrade are 100% supported.  This is possible the main cause
of breakages on Arch / Gentoo.  Because only one (or a few) version at a
time is supported, the whole system has to be updated together.  Which
means more bandwith usage on every upgrade.

- Continuous integration and lack of package maintainers: Thanks to
reproducible builds and partial upgrades, once a package works in Guix
it works "forever", it won't break at the next upgrade of some dependency.
This means that the workload of packaging can be transfered to build
farms.  Contrast that to the Arch community which needs a couple dozen
maintainers to stay tuned on thousand of packages.
With Guix, the contributors time can be put into better use.
In Guix it's straightforward to build from source or to install a
pre-built package directly, in fact, the distinction is not some
important to the end-user.  Guix can fall back on the building from
source if no substitute is available.

- "guix refresh": Update package definitions automatically.
Tools like that highlight the advantages of having a real programming
language at hand for package definitions.  What is a hard problem on
most distributions is pretty easy to implement on Guix.

- GUIX_PACKAGE_PATH: It's stupid but it's one of my favourite features!
On Arch Linux or Gentoo, one would have to set up a local repository.
Because they don't support partial upgrades, it means that the user has
to do some maintainance once in a while (i.e. make sure dependency
upgrades don't break the user's packages.)
Package inheritance makes it very easy to customize packages with a
patch, for instance.

- Emacs guix.el: Guix is the only distribution I know which comes with a
powerful user interface!

- Guix provides a good, concrete example of why containers are not the
right approach to packaging :)

- guix system vm / disk-image: It's trivial to build a "Live USB" with
my exact configuration (both system and user).

The list drags on, but that'll be it for today! :D

--
Pierre Neidhardt

Democracy is the recurrent suspicion that more than half of the people
are right more than half of the time.
		-- E. B. White

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]