On Thu, Feb 20, 2014 at 5:37 PM, Michael Higgins <li...@evolone.org> wrote: > 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.
Since you beat a lot around the bush, I will try to answer to (what I believe is) your main point. Take a look at [1]. That's all the code from the journal. The format the journal uses to store its logs its binary. There is no grand conspiracy behind this; it's simply the fact that it wants the logs indexed so it can search by key on O(log n) time, instead of O(n) like the regular logs from all the family of syslog. It also compress them while at it. The format is binary; but the code to read it (and write it) is not, and is available for everyone to see. Again, take a look at [1]. You can see the hate systemd generates around. A lot of people are keeping an eye on it, looking for things to criticize. At the first moment something fishy got into the journal source code (like your mail seems to imply is possible), those watchers would howl like there is no tomorrow. The fact that this hasn't happened is the most simple proof that there is no grand conspiracy. You don't believe on the collective eyes of the Linux community? OK, then *you* take a look trying to find something fishy; everything is done in the open: again, take a look at [1]. You don't have the necessary abilities to determine if there is something fishy going on them? Then pay someone to do the analysis for you; it's probably what Intel, AMD, IBM, Oracle, Valve, and other companies that have a deep interest in seeing that Linux remain independent of any single entity have been doing all the time since systemd (and other core technologies) have appeared. But I'm going to save you some bucks: there is nothing fishy. Carry on with the wires on the tin hat. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/journal -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
