Re: [Userops] Why is it hard to move from one machine to another? An analysis.

[David Thompson]

Dave Crossland <address@hidden> writes:

> On 8 April 2015 at 11:22, Christopher Allan Webber <address@hidden>
> wrote:
>
>> the direction I'm thinking of is
>> more along the lines of Guix becoming our Glorious Future (TM) assuming
>> something like GuixOps can happen (go Dave Thompson, go Guix crew!) and
>> a web UI can be built on top of it with some sort of common recipe
>> system.
>>
>> But I don't think our imperative systems like Debian are going away
>> anytime soon; I certainly don't intend to move all my stuff over to Guix
>> at this time.  For that reason, I think there needs to be another
>> program to fit the middle ground: something like salt/ansible/puppet,
>> but with less insane one-off domain specific languages, with a sharable
>> recipe system, and scalable both from developer-oriented scripts
>>
>
> I think that this is totally missing the point of containers.
>
> Tar did not go away when apt came along, because apt is (if you squint) a
> wrapper around tar. It packages programs into systems.
>
> So imperative systems like Debian are not going away, because lxc is a
> wrapper around such systems. It packages systems into containers.

Containers are unrelated to the paradigm used.  Containers are *a*
platform for running an operating system.  NixOS has functional,
stateless system management and is capable of creating containers to
host such systems.

Using Docker doesn't in any way address the serious issues with
imperative, stateful systems.  Your Dockerfile still has to list a
sequence of imperative instructions in the correct order if it is to
build a working system.  Since anything can happen, the only meaningful
way to represent a "generation" of a system is to take a disk image,
which is quite primitive compared to what Nix and Guix do.

We mustn't use containers to paper over real problems because we can
just throw them away and make new ones easily.

> And it hits a goldilocks just-right spot that VMs and hypervisors missed as
> they were too heavy, with meaningful new properties.
>
> Those properties at a macro-social scale emerge a new context of computing,
> that the docker/sandstorm/etc companies are trying to monetize.
>
> As I understand it, salt/ansible/puppet/guix provides similar properties
> within systems. But that conceptually seems like a bare metal mindset to
> me.

All of these tools are agnostic towards the platform the system runs on.
And I don't think it's quite fair to lump Guix in with the others, it is
really a completely different tool.

See the following article, about Nix (which Guix is based on), for
reasons why I think Guix falls into a separate category:

https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enough-and-we-can-do-better/

> It reminds me of what I believe happened to HURD in the 80s, which had
> properties that were meaningful for minicomputers which were so expensive
> only organizations had them, and where the persnickety administrators had
> root and users didn't; but in the context of microcomputer computing,
> micros were cheap enough for individuals to outright own them and have root
> and no other users, so HURD lost its allure.

HURD, being a microkernel, naturally offers more robust and secure
isolation than Linux containers can offer.  Sure, maybe there's only one
human user on most machines, but there are numerous other system users
for daemons and such.  I have never seen a system with just a root user,
it doesn't seem very useful.

> In the context of lxc computing, the properties provided by guix are also
> losing their allure: Transactional upgrades and roll-backs are done outside
> a system by replacing it wholesale rather than inside it; unprivileged
> package management doesn't matter because its root privs on the docker host
> that matters, not inside the container; per-user profiles inside a system
> don't matter when each user can have their own containers; etc.

Your solution to every issue raised seems to be "containers".  You've
found your hammer, and everything is a nail.

Transactional upgrades and roll-backs apply to entire systems in Guix as
well on a user's profile.  When you upgrade a system in Guix, you
replace the old system configuration "wholesale".  The instanation of a
new system could be manifest as a container, a VM, or an installation to
a physical host.  The technique used for system management is decoupled
from the target infrastructure.  Believe it or not, there are valid
use-cases for all of these platforms, despite containers being the hip
new thing right now.

> I suspect that the provision of these properties via lxe wrapper, with 'all
> the way down' distros like coreos/rancheros/smartos/mirageos - maybe
> SandstormOS some day? ;) - will become the way not just data centers are
> run but also our laptops -
> https://mobile.twitter.com/jperkin/status/520352024249249792

The need for a special distro to serve as the container host doesn't
make any sense.  A distro worth anything can be used as the physical
host OS, the container OS, the VM OS, and the
platform-we-haven't-invented-yet OS.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate