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?

23.23.142.124

Did a digit go missing? Get flipped? Maybe it meant to say 231.23.142.124

It's redundant in the sense that it's useless. Not redundant in the sense that it's robust.

Yes. You should clearly protest this unfair characterizing by leaping to the defense of people sending rape and death threats to women who write anything which could be construed as criticism! That'll show how peaceful and non-violent you are!

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...

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.

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.

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.

Did you...not take economics 101?

What do you think capitalism is?

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.

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.

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.

Name 1 that isn't something about binary logs.

Why are you not okay with this situation? Is there a risk that the systemd log viewer binary on your system will suddenly go away, and you will be unable under any circumstances to somehow get another one?

Is such a (possible, but extremely contrived) situation likely, and if you were worried about it, why did you install a syslog daemon? And why have you never been similarly concerned about how you'd view logs if your syslog daemon stopped writing them?

Also, you realize rsyslog reads systemd log files natively right? As in, not via the syslog protocol, but it parses the binary format and extracts text directly. So number of programs which read is greater then 1, probably greater then 2 (just not to my knowledge) and - oh yeah - the entire format is documented and freely available online.

Yeah, we shouldn't have released X11 until it was 100% bug free either...

You mean a disconnect like the fact that you can pretty trivially 100% a couple of servers running feature extracting daemons processing text based logs at the moment for a small cluster of machines?

Where has this absurd notion that text logs are efficient come from? 16 redundant bytes for a 4 byte IP address? Another 5 for a 2-byte port number? Text based logs generate a huge amount of redundant network traffic. journal-gatewayd might not be the solution people are looking for, but it absolutely makes sense to separate log collection on the local machine and the network interface in some way, since no sane syslog configuration just blasts UDP packets into the ether and hopes they arrive, and network programming is an *entirely* different set of concerns to local programming.

Which on some level, makes HTTP GET just as valid as anything else, since the important parameter is "did the server get the data" not "have I sent it?". rsyslog in TCP mode is how you achieve this currently. But you're left with a lot of text data volume to handle for something like access logs. Of course rsyslog also reads systemd journals natively.

You know I'd been wondering what his position was (was about to look it up while reading this thread) because there seemed to be an awful lot of people jumping to the conclusion that obviously this was systemd related and "look systemd is driving away developers!".