Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Michael Higgins]

On Thu, 20 Feb 2014 15:38:46 -0600
Canek Peláez Valdés <caneko@×××××.com> wrote:

> On Thu, Feb 20, 2014 at 3:22 PM, Tanstaafl
> <tanstaafl@×××××××××××.org> wrote:
> > On 2014-02-20 4:04 PM, Canek Peláez Valdés <caneko@×××××.com> wrote:
> >>>
> >>> No, actually, I think whatever is defined as the current default
> >>> should dictate which group should be required to do the work.
> >
> >
> >> I think this is where we think differently (regarding this
> >> particular point). The work must be done by *whomever* wants to do
> >> the job. So if the systemd people want to do a profile that's fine
> >> (and this already happened); but if they don't want to, nobody can
> >> force them to do it (this is academic right now, since they
> >> already did the [pretty trivial] work).
> >>
> >> If the systemd people did not wanted to do the job, then, since you
> >> can't force them, the people *not* wanting systemd would be the
> >> ones required to do it. And that makes absolutely no sense.
> >
> >
> > I think we agree, but you keep saying we don't... ;)
> >
> > The difference is, since OpenRC is the default, all of the existing
> > profiles are, by definition, OpenRC based profiles. So, people who
> > don't want systemd simply have to do... nothing!
>
> OK, I see your point.
>
> > As I said before, it is people who want systemd who currently have
> > to 'do something', and that is as it should be, unless/until the
> > default of OpenRC is changed to systemd.
>
> Agreed.
>
> Regards.

Been following along, jumping in late.

That does settle the issue with regard to Gentoo 'defaults' for now. As
I see it, if you are a desktop [l]user, then go ahead and use a quick
systemd default. It's good enough. And Gnome folks, from what I
understood, didn't have an easy opt-out choice, really. At least not
easy enough for me to grok right away.

Anyway, some arguments on the other branches of this thread got me
thinking. Take the binary log files. This seems to be something we all
understand to some extent (as compared to init systems, say), whether
a tinkerer or enterprise user. There's now something corporate sitting
between me and the evil crap coming out of my daemons.

Who logs the loggers?

My thought was, well, say if someone else, some other, unrelated team
entirely, was maintaining a codebase for handling that logging data,
that's a way out of the monoculture of systemd that would give some
peace of mind. If they, as also smart, talented coders began to
disagree, they might have capacity to keep the project in bounds.

So, for the hell of it, I just went to have a look at what the deal
might be with that binary data that hangs around and dumps to disk,
maybe, in one format or another.

"This document explains the basic structure of the file format on disk.
We are making this available primarily to allow review and provide
documentation. Note that the actual implementation in the systemd
codebase is the only ultimately authoritative description of the
format, so if this document and the code disagree, the code is right.
That said we'll of course try hard to keep this document up-to-date and
accurate.

Instead of implementing your own reader or writer for journal files we
ask you to use the Journal's native C API to access these files. It
provides you with full access to the files, and will not withhold any
data. If you find a limitation, please ping us and we might add some
additional interfaces for you."

From:

http://www.freedesktop.org/wiki/Software/systemd/journal-files/

Wow, that makes me feel all warm, fuzzy and secure as shit. I think I
just fell asleep for a moment. (My background would make me read this,
essentially advertising copy, as a classic example of perverse use of
semiotics, thus raising the reading on my B.S. meter. But I digress.)

The best part is the conclusion:

*If you find a limitation, please ping us and we might add some
additional interfaces for you.*

Please! Ping!

Second best is, "we'll of course try hard to keep this document
up-to-date and accurate". Of course.

So. If I were paranoid, or even mildly concerned, I'd take this to mean
two things:

One. There is, or could be, data that the systemd logging magic box
doesn't give you an interface for. Unless you know what it is, then
they might let you log it. Or you can, of course, contribute code, I'm
sure. Though, "Note that the actual implementation in the systemd
codebase is the only ultimately authoritative description of the
format".

Two. If I want to have a reasonable degree of surety that the code
isn't collecting data that isn't interfaced for you in the
journalcontrol, I'd have to delve into the codebase for systemd. Which,
I'm sure, is a piece of cake. And, of course, I, and my security team,
have to review the basic code on my GNU/Linux F[L]OSS machine regularly
anyway.

Oh, wait... No I don't. 

The beauty of the development model I trust is a diverse group of folks
with a *variety of interests* contributing to various areas of code, in
turn reviewed by some set of that same varied group, eventually
committed and merged rolled tested in the wild.

Or however you may see the ideal (or fantasy) of the ecosystem as we
know, or knew it.

Just the comment in this other related thread, systemd deprecating a
straightforward encryption setup in version N, what is next?

Okay, I'll go re-wire my tin hat now. Hope someone found this amusing.

Cheers,

- mykhyggz