On Sat, Feb 14, 2015 at 12:25 AM, Orion Poplawski <[log in to unmask]> wrote:
> On 02/13/2015 09:06 PM, Nico Kadel-Garcia wrote:
>>
>> On Fri, Feb 13, 2015 at 9:59 PM, Keith Lofstrom <[log in to unmask]> wrote:
>>>
>>> If systemd is a major resource hog, then our high-performance-
>>> machine comrades will come up with something that leaves more
>>> CPU cycles for doing computation over the next decade.  I hope.
>>> Zillion-CPU computing is intolerant of expensive waste.  If RH
>>> someday insists on intolerable resource misuse, we are in the
>>> right community for a mutiny and a new direction.
>>
>>
>> The difficulty is that it's creeping into levels and components that
>> didn't ask for it and don't need it, and thus becoming even more
>> bloated, With extraneous binary logging, and the tools to decode the
>> binary logging into something useful, with dbus integration and the
>> latest round of multiple ring integration for Fedora applications,
>> it's wedging it's bulky way into places that had no need of it.
>
>
> I'll be clear that there are things about systemd that do bug me, and it has
> taken a while to grow on me, but I think too much of the discussion gets
> emotional or subjective with terms like "bloated".  Someone's bloat could be
> someone else's greatly useful feature.
>
> In particular, while perhaps the use of a binary format is debatable, the
> existence of the journal is incredibly useful.  It allows for the capture of
> so much more output from system processes that wasn't possible before.  And
> it presents it in a structured and consolidated way.  Running "journalctl -f
> -p warning" is a great way to quickly monitor issues on a machine.
\
Which is great, when you need it, which is only a tiny fraction of
normal operating time. And it has a tendency to *spew* when you least
expect it. The results are fascinating and require yet another layer
of development insight and systems management. Those layers add up, in
the long run, to more resources for normal operation.

> In general I believe systemd takes system management, control, and
> monitoring to the next level.  There are growing pains, implementation
> issues, and other problems, but overall a great step forward.

And that next level will require significantly more system resources.
The "how much of the CPU is used by systemd" is misleading: how much
of the *kernel itself* is now involved in supporting systemd itself,
and how much of every new component that is dealing with the new
binary logging?

It's not the sole contributor to feature creep and bloat, but it's now
a component of it. And it's nowhere near a stage where the excess can
and will be stripped away: I see no sign of anyyone successfully
putting breaks on it and saying "whoah, partner, let's keep this
smaller and more stable!!!"

> Can't speak to dbus integration and I don't know what is meant by "latest
> round of multiple ring integration for Fedora applications".

You can see one of the proposals here:

        https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html


>
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA/CoRA Division                    FAX: 303-415-9702
> 3380 Mitchell Lane                  [log in to unmask]
> Boulder, CO 80301              http://www.cora.nwra.com