>Our view is, that using an non-mainstream distribution is a lot of work
>for our purpose of being an PaaS provider. That would in the end mean
>packaging a lot of services on our own.
>
>Today the mainstream distribution doesn't package anymore all needed
>services in the needed versions. In practice a lot of upstreams package
>their stuff on their own or some people do it in ubuntu's PPA.
I come from the old school of thought that it isn't software authors'
job to package their own software for distribution - that is the
definition of distributions' job. And mainstream distributions, to me,
are entirely slacking off on this, and abusing their monopoly, relying
on authors' and community labor to get all the packages done that they
should be working on.
Unfortunately, my school of thought seems all but dead nowadays, and
does not reflect reality.
As a software author who would like to get his software distributed,
but who does not want to favor mainstream distributions over small
ones, and who does not have the resources to package software for
every distribution in the world, I often wonder what a good approach
may be here.
>If you mean "keep it installed": yes, definitly. For container based
>systems, the one shot problem of system initialization is in practice
>non-existent. So we tend to avoid running systemd as PID 1, even if
>it's installed.
Right. A lot of companies like to keep systemd as the host's init,
and to use a lighter init in containers; that is why projects like
s6-overlay have bloomed.
However, s6-overlay and most similar projects predate s6-rc and
are essentially sets of clunky scripts (be they execline or shell),
which are not as efficient and maintainable as proper dependency-based
service managers such as s6-rc.
>For VM based or bare metal based systems, there is a lot of one shot
>jobs to do, loading drivers, mounting filesystems, decrypt block
>devices, scan for logical volumes, attach iSCSI, whatever.
>
>Writing units for that from scratch for everything is a big mess. So
>without an portable approach of this (means at least portable for linux
>distributions) I don't believe in a big success of a s6 one shot
>implementation, which offers a full range of use cases - because it's
>impossible to manage the effort of writing all this stuff.
That is one of the goals of the s6-frontend project: provide not only
integrated mechanism for the whole s6 stack, but also policy, i.e. a
complete booting environment, as systemd and OpenRC do, so users get
turnkey system initialization. I am painfully aware that this is a
necessary evil - s6 will never be viewed as a "complete" init system
until it does all the policy work.
>Ok, I was wondering, where this frontend is. ;-) Good to know, that
>there are plans around. We would like to support the s6 project. Today
>we implement it on our side to see how good it is and will later decide
>if we can keep it for production.
If you are interested in supporting the s6-frontend project directly
to make it happen faster, I am very open to this, and largely available
for a variety of contracts. Please send me a direct e-mail! :)
Regardless of whether we go this route, I am always interested in your
insights as potential users, about what you expect from such a project,
from a design / implementation / usability perspective.
--
Laurent
Received on Mon Mar 18 2019 - 19:37:49 UTC