Forgot your password?
typodupeerror

Comment: Re:Signs clear enough even for a layman (Score 1) 524

by Electricity Likes Me (#48418755) Attached to: Debian Votes Against Mandating Non-systemd Compatibility

How the hell do you think changing PID 1 is supposed to be phased?

It is literally the first process which runs on Linux. Please explain "phased change" when something that fundamental is being altered. You might as well say "I'm outraged we had to get kernel 3.x all at once! It should've been a phased upgrade...."

Comment: Re:It's just wrong (Score 1) 307

Actually you only need a correct answer for 1 program: the one running on the firmware of the robot. At which point the question is simply "over the input space, can the program provide outputs which end human lives?"

Of course depending how you define that, you can take this right into crazy town - plenty of cellphones have ended human lives over the possible input space.

Comment: Re:Signs clear enough even for a layman (Score 0) 524

by Electricity Likes Me (#48416851) Attached to: Debian Votes Against Mandating Non-systemd Compatibility

This is class political strategy BS: "look at how much drama we're causing! Something is clearly wrong!"

It's why most successful projects have benevolent dictators: because it shuts down most of the political strategems people translate to democracies of any sort.

Comment: Re:Gnome3, systemd etc. (Score 2) 447

by Electricity Likes Me (#48345153) Attached to: Joey Hess Resigns From Debian

"RELP is TCP based with another layer of protocol over the top."

You could say the same about HTTP or any other application level protocol,

I don't know, maybe my point was spelled out in the immediately following sentences which you didn't read?

Because you just went on to prove the entire point I was making by talking all about extra network protocols and daemons all created to make networked syslog reliable while you're in the middle of complaining about using a separate daemon to make journald network exportable.

At this point, I have no idea what you think the problem is other then "oh my god journald is new and scary". Because you've been explaining in excruciating detail exactly why you wouldn't use the raw logging protocol of a local system to actually communicate over a network because networks aren't reliable.

In which case, we return to the original issue: what exactly is the problem with using a special purpose daemon for exporting logs over the network? You know, the aforementioned separation of concerns which in any other thread on systemd is apparently the only thing people can talk about?

Comment: Re:think of the children (Score 1) 250

Ban alcohol. A study on the economic cost of alcohol as a function of police resources, ambulance and hospital resources, lost productivity due to injuries and illness, and straight up population destruction, pegs the mean lost productivity at $20 billion per year.

Of course, we're not doing that because history tells us it will be a lot more if we do. Still...

Comment: Re: Sweet, can we stop talking about it now? (Score 2) 250

Part of it is also the reason that it should not be considered inconceivable that the way ratings tend to work for sex and violence has something of a schism. Now, generally I think the schism is bad - we can deal with this issue better. But at the same time, in thinking about explaining to children why something is or is not appropriate, violence is a lot easier to explain with far fewer edge cases:

Is violence okay? No.
Ever? Very rarely.
When? It is okay to defend yourself if attacked. You should try and avoid having to do so.

That will get you through 99% of individual life until you get to geopolitics and the diplomacy of nationstates, which a good deal of people will get through life without needing to know about anyway.

Sex on the other hand?

When is that okay? What is okay? Why do some people do that? What is normal? There's a neverending well of questions there, all of which have complicated answers, and which society has an active, ongoing and vitriolic argument about.

There is no concise answer. The simplest things get complicated fast, and very much unlike violence, people seeing depictions or media messaging about it don't have the option (in most cases) of dealing with it by simply not dealing with it. I can avoid most or even all violence and most of us will during our lives. But I and my children are not going to avoid issues of sexuality and it has the potential to be very much a defining element of how their lives will evolve.

To bring it back to the McDonalds and Coke point, this is very much the same reason they advertise. Because you have to eat. You do eat. They're not asking or trying to get you to do something so uncommon. And they know how your nose and satiation responses work. Unless you have an absolute policy of just "no" towards them, then all they've got to do is make "mcdonalds" or "I want a coke" come to the front of your brain with some type of positive feeling when you're anywhere near them.

Comment: Re: Meanwhile... (Score 3, Interesting) 250

Except correlations can be due to chance. You can test this, by picking things which can't possibly be causally linked, running the same statistic analysis, and observing how often you get a correlation hit.

And it's important to know this, because such a statistical issue was very much the cause of various excited reports of radiation, cellphones, powerlines and every other type of factor "somehow" increasing risk for cancer, despite the absence of any measurable causative effect.

Until it was realized that if you ran the analysis on any set of variables, you'd always get "roughly double" the risk even if the question was "cancer rates vs. mean daily use of swear words" or "cancer rates vs. global population of pirates".

Which is why they don't just report the result. Because without context, the result is meaningless.

Comment: Re:Yep (Score 1) 447

by Electricity Likes Me (#48344081) Attached to: Joey Hess Resigns From Debian

This list isn't a technical complaint, it's a bullet point list which provides no information on what the actual problem is supposed to be.

"overly complex" is a subjective term. Compared to...what exactly? init scripts aren't simple, and they're modular seeing as how daemon dependencies are a real thing. And I'm curious exactly which 70 pieces of systemd can't live without each other, because I genuinely don't know. I do know that it can't be all of them, since I run systemd and don't use the dhcp, network or cron replacements. So, logind maybe? Journalctl is kind of indispensable, but so is syslog on anything else.

Same issue with PID 1. What concerns? What is in PID 1 that is a problem? Why shouldn't it be there? Because the amount of functionality people keep implying is there (the aforementioned 70 daemons) distinctly are not. Whereas, having my init process be cgroups aware and able to use that functionality to provide isolation seems like a pretty good idea to me, seeing as how solid jailing support is sorely missing from Linux.

I'm happy to concede the lib dependencies are an issue. I don't know enough about the underlying plumbing concerns to know if it's avoidable, or who should be blamed - i.e. a lot of systemd is actually a Gnome pull in, which then just flows on to Gnome apps. Which would make it a Gnome problem, more then anything else.

Comment: Re:Gnome3, systemd etc. (Score 1) 447

by Electricity Likes Me (#48343919) Attached to: Joey Hess Resigns From Debian

systemd has this exact switch. Ubuntu flavored systemd default configuration is to not write binary logs and parse everything directly to syslog.

Cue some example of seeing a half flushed log line in a file, as though someone actually got any information from that line.

It's becoming rapidly apparent to me that the people who complain no one listens to their complaints about systemd haven't realized they don't listen or attempt to learn about what they're complaining about.

Comment: Re:Gnome3, systemd etc. (Score 1) 447

by Electricity Likes Me (#48343911) Attached to: Joey Hess Resigns From Debian

" rsyslog in TCP mode is how you achieve this currently"
False. It is possible to lose messages even with TCP mode. This is why rsyslog introduced RELP. And if you knew about this then you'd also know that rsyslog supports compressing the log stream over the network, rendering the size efficiency argument rather moot. Since you should be encrypting your network transit anyway, you;d know that enabling compression is a single line config. (I've never seen an un-compressed encrypted stream)

RELP is TCP based with another layer of protocol over the top. And you're going to be doing disk buffering in any robust system based on it. And I see no one wailing and complaining about it being "too complicated" because hey, network programming is hard, which was my original point. The assumptions involved in sending reliable network messages are manyfold and varied, and depending what you want absolutely don't work if you don't have any type of local buffer.

1. Portable. eg: there is more than one size of byte and byte ordering. The generating systems architecture and platform can change over time and it should not impact the next point.
2. Archival. The file needs to be read back, maintaining all information, years from now, despite changing systems and requirements.
3. Accurate. There should be a minimum of processing over the entire life-cycle, whereby errors can occur.
4. Integration friendly. On large log infrastructure, the initiating machine's log format is only the first step of the log's life. It must be usable by many other tools.

Text logs are in no way portable. People think they're portable because they can read them (you know, if they speak English), but ubiquitously we all grep through a hundreds of thousands of lines of logs by looking for a string we think might be there. Writing a regex to reliably get a log is an exercise in massacring that text back to the broadest conceivable category of things it could be and hoping some version update doesn't change the format. Heaven help you if you have localization concerns.

This is why we have log aggregation systems - no one wants to keep tons of redundant data, they want to sort it into their indexed, databased format that actually provides useful information.

At which point it is very much worth questioning why we're outputing so much text in the first place, when we could output precise binary structs, checksummed and signed, use the bit-savings for redundancy if we wanted and then only render text when it's needed. Which can either be instantaneous if you're paranoid, or never, if you're an embedded device with space concerns.

"The hottest places in Hell are reserved for those who, in times of moral crisis, preserved their neutrality." -- Dante

Working...