Nobody said there were, but you were completely misguided. Piping is a key feature of Unix, and nobody would suggest removing it today. The key principles of Unix are not "to be obeyed" simply because they are rules that you are meant to follow. They are principles that emerged from development (like piping) which became a "way" that people follow because they make sense.

If moving the goalposts is the best that you can accomplish, then surely we cannot progress this conversation past this point. There are many things which can happen to a log file besides truncation.

They don't work without journalctl. And this is relevant because text logging (which does work without journalctl) is a second-class citizen to the binary logging. This is the part of the binary logging which is completely unacceptable. If only one of the logs is going to be accurate, it must be the log which I can read without special tools. Indeed, with a filesystem debugger or even a filesystem editor, if necessary.

False. You only say that because you do not understand the Unix Way, which includes preference for flat and human-readable files. You are praising one particular tree while cutting down the forest.

In the real world, where things sometimes do not go according to plan, it does not make sense to tie myself to proprietary tools. This point has been proven time and again, again, in the real world. Your coulda woulda shoulda nonsense is just that; journald coulda woulda shoulda made text logging as important as binary logging, and then the chief objection to it would not even exist. But arrogance has led its development otherwise. Presumably this will be fixed and eventually, with some snarky bullshit comments about how it's for the fogeys thrown in as a means of avoiding any personal responsibility for the bad decision in the first place.

I find your lack of imagination typical, but disturbing. It is, of course, the mindset which led to systemd, so I am anything but surprised to see it here.

The particular citizens of Waco we're discussing decided not to resist when the FBI rolled in with tanks and flamethrowers. Then the FBI parked a tank on the escape hatch and set the building on fire with a flamethrower. This was mounted on another tank, clearly visible in the only decent footage of the incident, shot at long range because the FBI wouldn't permit the press anywhere near. They knew where the hatch was because they had advance information, and they had the complete plans of the facility. This led to the suffocation death of the people we're talking about. If this is an example of anything, it's an example of a time when armed defense was warranted, and an example of what will happen to you if you concentrate yourself.

I want you to stop blaming shitty init scripts on init. Only an idiot would do that.

My pre-obamacare insurance was useless. There were zero providers in my area accepting new patients. I had 0% coverage. So if I have useless coverage now, at least nothing is worse.

You have to start somewhere.

Yeah well, nobody should expect 100% coverage.

Who says that American insurgents couldn't get some backing? The proliferation of weapons across the country is meant to make taking the citizenry expensive, not impossible. But people want to claim otherwise to support the assertion that taking away the guns makes sense if the purpose of the second amendment is a hedge against tyranny.

I don't think the founders ever foresaw the development of world-destroying weapons. But then, I doubt they would have seen wisdom in their construction.

Your problem was not a problem with init. Systemd will not solve the problem where you need NFS to boot, and NFS shits itself because it is shit.

Give us an actual example where init itself caused you a problem, or admit that you're just making shit up so that you can justify new and shiny. You're calling me stupid for insisting that you provide an actual example of a failure of init when what you provided was an example of a failure of the networking setup which could have also occurred with systemd if you misconfigured it. Now, provide an actual example of a failure of init, or if this was somehow init's fault (did it really start two init scripts at once all on its lonesome, or did the first script exit before it was done?) then explain that, and don't just describe a problem with scripts (which could also happen by misconfiguring a unit file) or with a daemon. From your description, it sounds a lot more to me like a problem with your distribution's network setup system, whatever that looks like.

the majority of the world is walking around with computers in their pockets, there is no class warfare here, unless you had a point but were very far from it in your comment

right, but when people propose to ban virtual child porn because they argue that it promotes child abuse, they have to propose banning depictions like the one you mention, because that depiction could be used by someone for sexual gratification, and/or it could arouse those desires in them. Sure, it's a crude representation, but there are cruder ones on cave walls that we seem to be able to recognize.

Sadly, it is not true that the US can only copy. Well, perhaps it is true today, but for a while there, we were real innovators... including the area of moral panics and crusades.

It's clear that you haven't looked at Japan. It may well be one of the countries in which rape is most underreported.

Right, but that's actually a lie. It is exactly like the phone system which used only one application. In the case of the phone system that application was transmission of sound, and in the case of the internet system that application is transmission of packets. If you argue that these packets' different nature makes them fundamentally different applications, then you must also argue that carrying data on a modem call over the phone system is a fundamentally different application, and then you cannot state that the phone system used only one application. In fact, it had two, and yet they were treated exactly identically. That is, in fact, a strong argument in favor of net neutrality.

The experiment by a bunch of white male land owners, most of them slave owners, succeeded brilliantly. Its goal was to determine whether it was possible to use jingoism (nee patriotism) and bullshit to fool the subjects of rule into believing that they hold the reins of power. Guess who still runs the country? A bunch of white male land owners, who are now actually in charge of something superior to slavery for their purposes: corporatism. They buy the laws, and we follow the laws. They've criminalized homelessness, and used the government to buy over 25% of the nation's land for the purposes of their exploitation in the form of the Bureau of Land Management. Rather than homesteading it and handing it to private citizens, homesteading was suspended so that this land could be raped wholesale. It's allegedly held in our interest, but those who've tried to (for example) use some of it to build a thermal-solar plant found that it was only available for mining coal, drilling oil, running cattle on land which was deliberately deforested for that purpose and therefore preventing it from becoming reforested, and the like.

It was an extremely early development, introduced before Unix was introduced to the world at large. That's why it's described in the first edition of "The Unix Programming Environment". Describing piping as a johnny-come-lately feature of Unix is disingenuous.

No. Maybe the log file implementation, but they didn't even get that right. An error in the file means the whole thing is useless. Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read. If you don't agree, then we can't agree. You simply don't understand the problem of trying to deal with potentially corrupt binary logs on another computer entirely, which is a real scenario. On occasion I have to resort to pulling the disk and slapping it into something else for analysis, and I shouldn't need special tools for that. I should be able to use anything lying around.

I'm not against also having binary logs, I can see the potential benefits. However, it makes no sense whatsoever to just chuck them into a bunch of loose files anyway. Doing that doesn't solve the organizational problem of having a bunch of files lying around. The same data that goes into the text logs should go into an RDBMS. Then I could really do something with the data. systemd's binary log files actually represent a failure in the form of a missed opportunity, and not a rational evolution.

Further, there's no reason why the logging daemon should be tied to the init daemon at all. If this init daemon is so wonderful, reliable, and good at starting processes in order, then it should be able to kick off any logging daemon, wait until it is running and accepting log messages, and then continue booting, perhaps after delivering the boot time log messages to the logging daemon. Want to argue that we need a new syslogd with binary logging? Fine. But where's the argument that it should be married to init?