Bug#727708: Some how I think I might have a way to end this argument.
Lets look at the problem little more broad than systemd vs upstart....
the Linux kernel linked stuff.
Freebsd the most intergrated init system is most likely going to be
launchd or releation.
https://wiki.freebsd.org/launchd
Solaris Management Console is the most integrated init system with a
Solaris kernel. http://osdyson.org/ exists off to the side of debian
at the moment due to debian sticking dominantly with sysvinit.
The idea of porting upstart and systemd most likely can be given up
on. Since porting either to Freebsd or Solaris is most likely
pointlessly. The upstream supported in Freebsd and Solaris for there
own init is going to be many times more current on their kernel
feature support than any third party.
Package maintainers don't want to have to create individual files per
init system. Add on the fact there will be multi init systems. How
to resolve the issue. Unified generator solution that reads from a
common file format and spits out the format the init system requires.
Systemd does support generated SourcePath= declare in Unit files.
It would be great if upstart would add equal. Yes this is where
upstarts contributor agreement is a problem.
There is no reason a SourcePath equal declare could not be added to
existing LSB systemv init.
Like it or not the author of Systemd is correct. Its basically
pointless porting init systems across kernels. Init systems to work
right have to end up kernel dependant to take advantage of platform
particular security features. Also including waffle defining all
the unique bends for all the unique platforms like sysvinit did also
made life more complex for administrators.
Its time to bite the bullet.
Systemd vs Upstart if you restrict to Linux only and number of
supported Linux Kernel features systemd is clearly winning.
Upstart major argument has be in theory portability to other
platforms. This is totally not an option.
Without portablity in the init system it becomes how well does the
init system intergrate with having its configuration files generated
so package maintainers can create common file declaring what they need
the init system todo for them.
Objective package and init system dependency totally unlinked from
each other. Packages become dependant on particular versions of
generators.
Yes the problem here is another project is required. Something that
should be part of the standard processes.
Reply to: