Re: [DNG] SystemD's brownie points over non-systemd OSs.

2016-08-09 Thread Simon Hobson
Edward Bartolo  wrote:

> Considering the fact that many Linux users moan about not being able
> to run the latest "shiny" software, and sometimes even complain and
> insist they want their MS Windows applications on their Linux
> machines, I have to concede them, that this time systemd scored an
> extra brownie point in their favour. This alone will be an extra
> reason for any of them to choose systemd.

+1

> I am saying this because Linux users are very diverse, with
> experienced and knowledgeable system administrators being a small
> minority. In my opinion, if Devuan want to be a competitor/alternative
> it must provide the same functionality with reasonably the same effort
> and efficiency.

+1

> It is useless to tell the younger generations they
> should lock themselves somewhere to research and study if they can
> effectively do the same task with little to no effort.

And this, in shovelfuls.

I was introduced to computers in the days when (for a desktop) you switched it 
on, and typically ended up at an input prompt for a basic interpreter. You 
could then type in your program to do something - whether that be something you 
wrote yourself, or something printed in a magazine (I bet a few here can 
remeber magazines with pages of listings !)

Or you could try your luck and see if what you wrote out to a cassette tape 
yesterday will load today, armed with your little screwdriver for twiddling the 
azimuth adjustment.
If really posh, you'd have a disk drive - my second computer was an ITT2020 
(Apple II clone) and did have a disk drive - storing what seemed like a massive 
143k per disk (less overheads).

These days, the vast majority want their shiny tablet/phone, press the button 
and instant gratification, and even IT people I've discussed things with really 
don't give a s**t about "open". Some are even hostile to the whole idea that 
anyone should be able to "fiddle with the insides".

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] SystemD's brownie points over non-systemd OSs.

2016-08-09 Thread Peter Olson
I apologize for top-posting, but I have no idea what you are talking about.

For the record, I am not fond of GRUB2 either.

Peter Olson

> On August 9, 2016 at 1:52 AM Edward Bartolo  wrote:
> 
> Considering the fact that many Linux users moan about not being able
> to run the latest "shiny" software, and sometimes even complain and
> insist they want their MS Windows applications on their Linux
> machines, I have to concede them, that this time systemd scored an
> extra brownie point in their favour. This alone will be an extra
> reason for any of them to choose systemd.
> 
> I am saying this because Linux users are very diverse, with
> experienced and knowledgeable system administrators being a small
> minority. In my opinion, if Devuan want to be a competitor/alternative
> it must provide the same functionality with reasonably the same effort
> and efficiency. It is useless to tell the younger generations they
> should lock themselves somewhere to research and study if they can
> effectively do the same task with little to no effort.
> 
> My biggest motivation to support Devuan and all "old style Linuxes" is
> derived from the fact that I do not conform to a ready made recipe
> telling me to do everything in a rigid way that often interferes with
> how I want to use a computer. This very machine I am using right now
> has a complicated setup with an independent boot-loader although the
> GRUB2 developers made a huge effort to force users to use GRUB2 as an
> integrated part of their installation. I remember when the changes
> took place I immediately devised a workaround to have GRUB2 installed
> in an independent way as I wanted it. Yes, there are many users who
> would scold me for doing it the way I did it, but that is my choice.
> When it proves itself to be less efficient than doing it "the right
> way" it will be time for me to reconsider my choice.
> 
> Now systemd is looming ahead with even more restrictions and lock-ins.
> Keep it up people, choice is sacrosanct and fighting for it does not
> come free of injuries.
> 
> Edward
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] SystemD's brownie points over non-systemd OSs.

2016-08-08 Thread Brad Campbell

On 09/08/16 06:03, Go Linux wrote:


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.


In that context I believe it is along the lines of an environment where 
the same basic programming mistakes and logical fallacies are propagated 
over the maximum amount of system components.


Thankfully there are still alternatives.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] SystemD's brownie points over non-systemd OSs.

2016-08-08 Thread Go Linux
On Sun, 8/7/16, Adam Borowski <kilob...@angband.pl> wrote:

 Subject: Re: [DNG] SystemD's brownie points over non-systemd OSs.
 To: dng@lists.dyne.org
 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=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





 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] SystemD's brownie points over non-systemd OSs.

2016-08-08 Thread Brad Campbell

On 08/08/16 13:44, Aldemir Akpinar wrote:


Sun, Aug 07, 2016 at 06:31:10PM +0200, Edward Bartolo wrote:

On the other hand, full-machine virtualization costs you the max of
assigned
memory to that system, at all time.


Going off-topic but I just wanted to correct this statement, when you're
using full machine virtualization in the worst case it will use all the
memory assigned to the server (unless you're using xen). Products like
vmware or hyper-v uses in memory deduplication and swapping the virtual
machine files to the disk to reduce the memory usage.


Just for the record, so does KVM if you turn on ksm. It actually works 
very well for a free solution.


This is a tiny array of linux & windows VMs (5 linux / 3 windows). ksm 
effectively saves half the memory footprint.


root@srv:~# ./ksmstat2
Shared memory is 488 MB
Saved memory is 6557 MB
Shared pages usage ratio is 13.43
Unshared pages usage ratio is .95

Sure, not as efficient as any of the containers, but then the containers 
can't run a blackberry BES or any of the other horrid windows software 
you sometimes have to run as part of day to day business life catering 
for others.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] SystemD's brownie points over non-systemd OSs.

2016-08-07 Thread Aldemir Akpinar
> Sun, Aug 07, 2016 at 06:31:10PM +0200, Edward Bartolo wrote:
>
> On the other hand, full-machine virtualization costs you the max of
> assigned
> memory to that system, at all time.
>

Going off-topic but I just wanted to correct this statement, when you're
using full machine virtualization in the worst case it will use all the
memory assigned to the server (unless you're using xen). Products like
vmware or hyper-v uses in memory deduplication and swapping the virtual
machine files to the disk to reduce the memory usage.

--
aldemir
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] SystemD's brownie points over non-systemd OSs.

2016-08-07 Thread Adam Borowski
On Sun, Aug 07, 2016 at 06:31:10PM +0200, Edward Bartolo wrote:
> http://forums.debian.net/viewtopic.php?f=16=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.
-- 
An imaginary friend squared is a real enemy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] SystemD's brownie points over non-systemd OSs.

2016-08-07 Thread Brad Campbell

On 08/08/16 00:31, Edward Bartolo wrote:

Hi All,

http://forums.debian.net/viewtopic.php?f=16=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.



Unless I'm mistaken, it looks like someone re-invented a more 
complicated chroot.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


[DNG] SystemD's brownie points over non-systemd OSs.

2016-08-07 Thread Edward Bartolo
Hi All,

http://forums.debian.net/viewtopic.php?f=16=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.


-- 
If you can't explain it simply, you don't understand it well enough.

Albert Einstein
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng