[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: It's time to build "guix deploy"

From: Giovanni Biscuolo
Subject: Re: It's time to build "guix deploy"
Date: Thu, 14 Feb 2019 16:35:47 +0100

Hello Pjotr,

thanks for sharing your thougts!

Pjotr Prins <address@hidden> writes:


> I am still using that setup today, to configure web, mail
> servers and home directory. The tool is here

quiting from the README: "`deploy’ is a deployment tool which operates
in the same domain as Chef, Puppet, Cfengine"

I'd call them "configuration management tools" instead of "deployment
tools", even if someway (*badly*) they can also deploy software and
apply the configuration

why not using (or defining [1]) system services in a Guix
operating-system declaration instead of *any* other configuration
management software?... except for legacy reasons

the very reason I'm here is I don't want to use *anymore* *any* of them,
with all due _respect_ for the venerable projects, your included!

I've used Puppet and some Ansible, studied CFengine and Salt
Stack... then discovered Nix and rigth next Guix: what else? :-)


> and the emacs files sit in a git directory in the same tree and get
> copied across running 'deploy emacs.yaml'.

yes, we still miss "stateless user services config" (Pierre Neidhardt
wrote an interesting summary here

I'd like to be able to declaratively manage a *stateless* .config/
instead of managing configuration with dotfiles [2]

anyway Guix is _perfect_ to declare and deploy system services, what we
miss is a little more abstraction (from operating-system to
infrastructure?) and remote control of "guix system reconfigure"

am I missing something?



[2] I'm using myrepos with "stowable = true" for my dotfolders... but
I'll _never_ use something like it's Drupal extension 

Giovanni Biscuolo

Xelera IT Infrastructures

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]