What flavor of Linux currently doesn't use systemd?

On Sep 30, 2016 11:58, "Joseph Sinclair" <plug-discussion@stcaz.net> wrote:

Responses Inline:

> [snip]
>
>> SystemD should be restricted to it's INIT
>> functions, dump the horrible non-standard logging, drop all of the
>> service replacements (or spin them into separate services), and get
>> laser-focused on getting that INIT service bullet-proof,
>
> But if systemd were restricted to PID1 plus a process starter, what
> would differentiate it from very nice INITs like runit, s6, and Epoch?

Quality code, simple design, and/or security could differentiate.
If none of those applies, then the community should choose the alternative that does offer those things.
In my opinion, systemd does have some very good features in it's core function space, it just has some major implementation and kitchen-sink issues that need to be fixed.

> [snip]
>
>> I think the entire RedHat organization (and the professional
>> open-source community in general) might need a refresher course on
>> operating system design, particularly focusing on microkernel
>> architectures and the how/why those are inherently more secure (also
>> why the tradeoffs involved don't work as well in Ring-0 kernel space
>> as they do in Ring-3 user space).
>
> This would be counterproductive for Redhat. Please remember they make
> their money on consulting, certs and education: Three services that
> lose value as the underlying system becomes easier to use and
> comprehend. Read
> http://asay.blogspot.ru/2006/10/interview-with-red-hat-cto-brian.html
> and search for the first occurrence of the word "complexity" and you'll
> hear, straight from the horse's mouth, why they'll never make systemd a
> simple PID1 plus process runner.

I am well aware that the corporate incentive militates against doing what's best in the case of systemd.
There is nothing, however, that requires systemd be exclusively or even significantly driven by Red Hat, the community is completely free to fork and fix the project.
The Linux community (of which Red Hat is only a small part) has a responsibility to itself to reject or repair overly complex and insecure solutions to the needs of a modern operating system.
There are already projects underway in various places that begin to address these concerns, and the natural self-interest of the community will tend to bring those to the forefront, absent external interference.
Red Hat will, eventually, either recognize the constraint (do what's best for the community or the community will go elsewhere) or cease to exist; both outcomes are eminently reasonable and beneficial.

I have no desire to tell Red Hat how to run their business, and they shouldn't listen to me if I did.
The quoted paragraph is more of a recognition of a common technology blindspot that happens to manifest in Red Hat's organization (and applies to the systemd design issues) than a prescription for action.

Note, I don't pretend to have the time or skill to fix systemd either. I just made some observations that, if it's bad enough (and it might be), there could be enough interested entities who do have time and skill to fix the problem.

>
> SteveT
>

==Joseph++

---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss