Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Anyone suggesting staying with sysvinit should be shot at down for
foolishness If you wish to stay something sysvinit like you should
be backing OpenRC.
The basic issue with sysvinit is lack of process tracking.
This is the historic problem.
You start a service.
You stop a service.
Ok everything is fine.
You go to start service again. Hello some random process is still
running so preventing the service starting because the service did not
stop properly.
Systemd and OpenRC both can address this using cgroups under Linux.
OpenRC also can use Jails under BSD line.
Upstart might be simpler to port but it does not address this base
problem at all.
The dbus issue is going to get major on all platforms. This is
another http://www.freedesktop.org/wiki/Software/hal/ item. Hal was
implemented in userspace and its functionality it has been replaced by
devicekit. Same with the recent termination of userspace X11 drivers.
kdbus changes things major way. Both upstart and openrc are well behind.
The big risk is after kdbus is in the Linux kernel items like kernel
power management move straight connected to it. So there may be no
option bar use kdbus while running on the Linux kernel.
Debian has big trouble ahead. No point putting head in sand. The
Multi OS debian is means there is a lot of critical work that must
start straight now. Like will kdbus be a feature we should expect
from all kernels debian supports?
Cgroups from Linux and Solaris Containers from Solaris operate close
enough to make porting systemd possible. The major road block to
systemd on freebsd kernel is nothing really like cgroups or Solaris
Containers.
Yes I know this would upset the freebsd guys no end but at this point
we do have to serously consider if the freebsd branch is even worth
keeping it is too alien to Linux.
Working with www.openindiana.org to bring on something that can be
systemd compatible as second kernel might be the correct way forward.
Maybe then freebsd kernel developers would see the need to provide
Container class features in their OS kernel.
http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-basics-s11-1729181.html
Service Management Facility of Solaris and systemd of Linux have a lot
in common how they operate. This is why porting systemd to Solaris
is not too bad. cgroup functionality can be directly swapped with
Solaris Containers functionality. Cgroups was not a magical new idea
that the Linux world dreamed up. Someone had been look at Solaris
and liked what they saw.
This is really the choice do we keep on attempting to make
incompatible designed kernels interchange or do we move to kernels
with similar operating designs.
Yes we can still maintain the multi OS going forwards. But we are to
the fork in the road.
Debian cannot support everything. The project has to be willing to
spill blood at times. I know killing kfreebsd branch completely is a
lot of blood shed. But if that allows redirecting those resources to
a more compatible kernel so be it.
The big answer we need from freebsd kernel developers are they going
to implement functionality to match cgroup and solaris containers.
If not going forwards compatibility with them is going to become
harder and harder to maintain.
https://people.gnome.org/~alexl/glick2/ something people forget
container/cgroup class tech enable relocatable installation of
programs without the program seeing it. Containers is something that
could be used in future to make multi-arch cleaner. Like allowing
32bit and 64bit development files and applications to be installed
side by side without issues. Like being able to install 32bit and
64bit ice-weasel at the same time.
The road block coming from freebsd is blocking systemd is also
blocking debian from using the same features to address other problems
as status normal. Solaris kernel and Linux kernel could have
identical instructions given to developer to build packages due to the
existence of container tech in both.
Sorry everyone is hard choice time.
Do we go forwards having to work around the limited functionality of freebsd?
Do we nuke freebsd and move on to another kernel more compatible?
Do we pressure freebsd kernel developers to add containers?
Yes most people are missing the major road block to systemd on freebsd
is road blocking a solutions to stacks of other problems. So really
this is more than a init system problem. The fact systemd is not
portable to freebsd is showing missing features. So far no one other
me has went out and looked at the other kernels to see if the bsd line
is a edge. This case they are an outer edge.
Peter Dolding
Reply to: