<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Gentoo uses OpenRC by default. <br><br>Sent from my iPhone</div><div><br>On Sep 30, 2016, at 3:26 PM, Anon Anon <<a href="mailto:lokotejones@gmail.com">lokotejones@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><p dir="ltr">What flavor of Linux currently doesn't use systemd?</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Sep 30, 2016 11:58, "Joseph Sinclair" <<a href="mailto:plug-discussion@stcaz.net">plug-discussion@stcaz.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Responses Inline:<br>
<br>
> [snip]<br>
><br>
>> SystemD should be restricted to it's INIT<br>
>> functions, dump the horrible non-standard logging, drop all of the<br>
>> service replacements (or spin them into separate services), and get<br>
>> laser-focused on getting that INIT service bullet-proof,<br>
><br>
> But if systemd were restricted to PID1 plus a process starter, what<br>
> would differentiate it from very nice INITs like runit, s6, and Epoch?<br>
<br>
Quality code, simple design, and/or security could differentiate.<br>
If none of those applies, then the community should choose the alternative that does offer those things.<br>
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.<br>
<br>
> [snip]<br>
><br>
>> I think the entire RedHat organization (and the professional<br>
>> open-source community in general) might need a refresher course on<br>
>> operating system design, particularly focusing on microkernel<br>
>> architectures and the how/why those are inherently more secure (also<br>
>> why the tradeoffs involved don't work as well in Ring-0 kernel space<br>
>> as they do in Ring-3 user space).<br>
><br>
> This would be counterproductive for Redhat. Please remember they make<br>
> their money on consulting, certs and education: Three services that<br>
> lose value as the underlying system becomes easier to use and<br>
> comprehend. Read<br>
> <a href="http://asay.blogspot.ru/2006/10/interview-with-red-hat-cto-brian.html" rel="noreferrer" target="_blank">http://asay.blogspot.ru/2006/<wbr>10/interview-with-red-hat-cto-<wbr>brian.html</a><br>
> and search for the first occurrence of the word "complexity" and you'll<br>
> hear, straight from the horse's mouth, why they'll never make systemd a<br>
> simple PID1 plus process runner.<br>
<br>
I am well aware that the corporate incentive militates against doing what's best in the case of systemd.<br>
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.<br>
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.<br>
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.<br>
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.<br>
<br>
I have no desire to tell Red Hat how to run their business, and they shouldn't listen to me if I did.<br>
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.<br>
<br>
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.<br>
<br>
><br>
> SteveT<br>
><br>
<br>
==Joseph++<br>
<br>
<br>
<br>------------------------------<wbr>---------------------<br>
PLUG-discuss mailing list - <a href="mailto:PLUG-discuss@lists.phxlinux.org">PLUG-discuss@lists.phxlinux.<wbr>org</a><br>
To subscribe, unsubscribe, or to change your mail settings:<br>
<a href="http://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer" target="_blank">http://lists.phxlinux.org/<wbr>mailman/listinfo/plug-discuss</a><br></blockquote></div></div>
</div></blockquote><blockquote type="cite"><div><span>---------------------------------------------------</span><br><span>PLUG-discuss mailing list - <a href="mailto:PLUG-discuss@lists.phxlinux.org">PLUG-discuss@lists.phxlinux.org</a></span><br><span>To subscribe, unsubscribe, or to change your mail settings:</span><br><span><a href="http://lists.phxlinux.org/mailman/listinfo/plug-discuss">http://lists.phxlinux.org/mailman/listinfo/plug-discuss</a></span></div></blockquote></body></html>