On 2019/08/03 00:50, Neal Gompa wrote:
Ignoring the fact that SUSE != openSUSE,
ya, true enough, though that make it sound like the answers for the two are different. Is SUSE shipping alternatives for service control that openSUSE is not? If that's the case, why would they provide an alternative where openSUSE has not?
[open]SUSE is shipping various alternatives to [various parts of] systemd. So why?
this is not true.
As a scheduler of tasks, it _is_ true, but you clarify more down below, you are talking service manager, but I was referring to all the other areas it has replaced...
SUSE is *not* shipping alternatives to systemd. That's the point. The only scenario in which you don't have systemd is if you're making a single application/service OCI container. In *every other scenario*, you are using systemd.
openSUSE may have things that *look* like alternatives to systemd, but they're not intended to work that way. The one and only service manager for SUSE distributions is systemd.
==== Service manager. Does that include logging as provided by syslog/ng-syslog/rsyslog? Does it include boot-load functions (grub/lilo,etc?) I'm trying to narrow down what it is required for being "OpenSUSE", vs. where it is allowed to use an alternative. For example, if the startup process was in ROM, and turned control over to systemd after the system's hardware and locally required resources were activated: is hardware initialization part of systemd? Or could control be passed to systemd after some custom hw-initialization?
Our sysvinit package does not ship sysvinit, only some of the auxiliary tools useful for LSB script compatibility. To my knowledge, there are no alternatives being shipped in *any* SUSE distribution, product, or service.
Any SUSE, or openSUSE?
真実はいつも一つ！/ Always, there's only one truth!
Yes, and if you would recognize it a being my truth, things would be so much simpler! :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org