On Sun, 8/7/16, Adam Borowski <kilobyte@???> wrote:

Subject: Re: [DNG] SystemD's brownie points over non-systemd OSs.
To: dng@???
Date: Sunday, August 7, 2016, 9:42 PM

On Sun, Aug 07, 2016 at 06:31:10PM +0200, Edward Bartolo wrote:
>> http://forums.debian.net/viewtopic.php?f=16&p=621842#p621842
>>
>> Excuse me for the topic title. But the above link at first looked like
>> some inherent advantage in using SystemD. However, after a little
>> reflection, a couple of minutes, it seems there are actually no extra
>> brownie-points in using SystemD.
>>
>> This *appears* like an advantage SystemD users have over non-systemd
>> users. But if Devuan allows the use of virtualisation software, the
>> same can be achieved without requiring any sort of benediction
>> SystemD.
>>
>> virtualbox is the Devuan 64 bit repository. So, the above is not an
>> advantage but another way to make a cup of tea rather than the known
>> ways.
>
> virtualbox is _not_ an equivalent. What virtualbox and qemu-kvm, or
proprietary vmware and MS Hyper-V, do, is full machine virtualization.
You put an entire operating system inside, with its own kernel, and it
can be anything, even Windows or SCO ClosedServer if you fancy so.
>
systemd-nspawn is a worse clone of lxc which in turn is a worse remake
of vserver and openvz. These run using host's kernel.
>
The difference between these two is mostly in efficiency and memory use.
While for most devices (network, disk) the cost of full virtualization
isn't significant (but always noticeable), the memory needs are MASSIVE.
With OS-level virtualization, it costs you only for processes that are
running. That's around 100KB for init (obvious snide skipped), 1.1MB
for rsyslogd, perhaps 380KB for sshd if you dislike "vserver exec" or
"lxc-attach" and that's it. Anything more are daemons that do productive
work. It's not uncommon to put 400ish vservers on a single physical
machine in production[1], or tens of thousands to prove a point. And on
a load spike, any vserver can take most of the machine's memory and
resources (of course, if others stay mostly quiet at that time), which
works wonders if you do maintenance serially.
On the other hand, full-machine virtualization costs you the max of assigned
memory to that system, at all time.
>
systemd-nspawn, lxc and docker[2] are built upon chroot+unshare+cgroups+
seccomp. The purposes of those are:
* chroot: separating the filesystem
* unshare: separating namespaces. Of note are the mount namespace (a
container can have mounts of its own), hostname, network (containers
have their own IPs, routing tables, etc), user (you get to be root inside
yet can't break the rest)
* cgroups: resource limiting: caps and fair share of CPU/memory/IO/etc
* seccomp: syscalls which could harm the rest of the system are vetoed
>
You can try playing with those on your own. Especially "unshare -n"
(read the manpage) is fun!
>
But for a whole package, use lxc. It will configure all of the above for
you. systemd-nspawn is merely a NIH copy of it.
>

> [1]. Depends on what your customers do, obviously.
> [2]. Docker is mostly about what you put _inside_ the container, but can
manage them on its own.
>
--------------------------------------------

I posted a link to this response at the FDN link posted above. This was the response from the author of the howto:

http://forums.debian.net/viewtopic.php?p=621972#p621972

He concludes:

". . . I would prefer to use the systemd-supplied components (systemd-boot, systemd-networkd, systemd-resolved, etc) wherever available as I believe this offers a more cohesive, UNIX-like working environment."

That would depend on your definition of a 'UNIX-like working environment' IMO.

golinux