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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
