update systemd

[Anon Anon]

What flavor of Linux currently doesn't use systemd?

On Sep 30, 2016 11:58, "Joseph Sinclair" <plug-discussion at 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 at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20160930/c56569cc/attachment.html>