On Thu, 20 Feb 2014 15:38:46 -0600 Canek Peláez Valdés <can...@gmail.com> wrote:
> On Thu, Feb 20, 2014 at 3:22 PM, Tanstaafl > <tansta...@libertytrek.org> wrote: > > On 2014-02-20 4:04 PM, Canek Peláez Valdés <can...@gmail.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
