[Discuss] systemd sucks and containers suck and language-specific package repos suck

[dsr at randomstring.org (Dan Ritter)]

markw at mohawksoft.com wrote: 
> > Kent Borg wrote:
> >> And it reinforces my dislike of systemd, and suspicion that Docker is
> >> the
> >> first thing people throw at any problem making the starting size and
> >> complexity always large whether it needs to be or not.
> >
> >
> > VM images as deployment mechanisms are the direct descendant of
> > "it works on my laptop... let's put my laptop in the rack".
> 
> This is a point I STRONGLY disagree with. A VM is a very powerful tool, it
> allows you to run fundamentally different environments on an otherwise
> well managed uniform server environment.

... which is evidence that the development process is broken, because
instead of running portable software, a VM emulates a whole machine
(understandable in short term use) and brings along a whole OS and
a dependency structure and (hopefully) tools for manipulating that
structure which are *different* from your standard. If they weren't
different, you wouldn't need it.

> People, I think, misunderstand VMs on a conceptual level. Hear me out.
> Think about the VM as a packaging vehicle. I can test and deploy whole
> environments as a single step. I can shut down VM 1.0, spin up VM 1.1, in
> one step. Don't think of a VM as "laptop in a rack" think of it as a self
> contained way to deploy whole systems.

We have users, permissions, ports and namespaces to separate software
running on a given system.

What you are describing is figuratively "it didn't work with this laptop,
let's try a different one".

A VM for testing can actually be useful, because it provides the
simulation of an entire machine, controlled from top to bottom, without
the resource expenditure of an entire very capable machine. So you can
offer lots of VMs for a lower cost per-"machine" at the time when you
need lots of low cost machines: testing and development.

At deployment time, however, software should be able to take advantage
of the available hardware capabilities.

> With overly file systems, you can have a fully read-only VM image that can
> be impervious to attacks.

It turns out that reading the wrong data out to a hostile user is
an attack, and one which a read-only VM image does not solve. It
is also the case that nearly all "read-only" VM images are not
read-only. They are, at best, selective in the places that they are
allowed to write.

In other words, UNIX permissions and mount options can do the same thing,
cheaper.


-dsr-