It almost certainly does only survive for minutes on hard surfaces. The surfaces it survives on longer are those which are literally covered in blood and bodily fluids for it to reside in.

This might be a crazy idea, but have you considered that bombing things, in fact, violence of any kind! might not be the solution to all of America's concerns in the Middle East. I mean has it really worked out for you lately?

Storage needs to be detected on boot before the init system can do anything with it. That's going to effect when you can bring up other daemons, including network ones. Which in turn may require bringing up network connectivity so you can mount network filesystems that you may be booting from in the first place.

All of which needs to be done in accordance with the idea that we might not be booting, but instead coming out of hibernation or sleep mode, and we need to check that the world wasn't exploded around us while we were doing that (i.e. the network is still there, is still the same network, and the storage is still reachable or hasn't been hot plugged).

If you don't think cgroups are the responsibility of the init system though I don't even know what to say to that. That the process which launches all other processes shouldn't be able to request they be isolated, and monitor them to check they're still running?

Frankly, I don't know why people think these things aren't the domain of the init system. They are all absolutely fundamental activities of a modern computer system, which need to functional at the various levels of boot time when nothing else may be running.

Those people who know a better way also seem to have no intention to ever write any of the code themselves. It's open source: nothing's stopping them. Much as ultimately Linus did the hard work and Tennenbaum did not, such as it will be for whatever init system people want: the code which gets written gets run. Or in this case, the distro which is maintained gets used.

Frankly, you also cut back to my original point: character assassination and not technical discussion is not "a better way".

More over, this "how did it get corrupted" is the height of naivete. How did it get corrupted? On a random user system of unknown providence? Oh let me count the ways.

1. Hard disk developed a bad sector, wasn't redundant in anyway. Did you know mirror RAID in Linux doesn't actually have a mechanism to vote on the correct data, at least last time I checked?
2. Non ECC RAM suffered a random bit flip from a cosmic ray (8% per year, per chip, according to Google).
3. Bad SATA cables, power supply to the PC or any other thing (checkout people exploring the origin of errors with ZFS checksum faults to see the things that can happen).

So "why are the logs corrupted" - well, pick one. And then tell me how a text log that writes half a line of any data would fair any better.

People think plain text logs are somehow more intelligible in failure scenarios but never actually deal with them and likely never notice them since amongst other things, plain text logs include no hashes or checksums or any other type of actual error checking. Or to put it simply: google "corrupted logs" and see how often it happens to people's text logs.

People who seem to think log files are so important sure seem to spend a lot of time not learning about log files in systemd before writing angry internet posts about them. Otherwise they'd know that you can forward text logs to any system you want with journald, and avoid the binary log format entirely. Which is information one can find out from say, man pages, Google or any of the sources I presume they consult when configuring such important log file storage systems.

I mean, I also assume they're up to speed on problems with syslog, like how by default the whole protocol is UDP and will drop packets freely?

Funny I thought you did, since if you have "broad" workloads you probably have heavily customized a bunch of sys-v init scripts to boot up, and your upgrades are carefully planned affairs with tests, regression testing and a lot of preparation. In which case, why do you care? You're not blindly upgrading distros in the first place, so you're free to do what you want.

Moreover the presenter is asked repeatedly if he's okay with the exchange continuing by someone (an organizer I presume).

Yeah I mean, all those other people should just learn English really.

Do you realize how inane this is? In the same breath people ask "why bother? No one needs it" you're complaining that "oh it'll ruin my shortcut keys because I, personally, switch language all the time".

You know what doesn't work anywhere? Any of the shortcuts in my .bashrc file because I don't have the file on that specific computer. But you know what you could almost certainly do with a well localized terminal system? Quickly and easily change the language to the one you're familiar with. Exactly unlike the current situation if you don't speak American English.

Do you? Seriously, do you have a single, coherent and plausible reason that this is a bad idea, in some way which would not just as equally effect syslog or any other process which provides logging?

A tiny minority. People who apparently are going to maintain a fork, but "don't have time to deal with Debian".

What do they think maintaining a distro involves, other then a lot of time working on procedure, process and politics?

The fact you feel the need to engage in character assassination rather then technical discussion speaks volumes about you yourself.

Binary log files are more compact. They can be better indexed. They lend themselves to localization more easily by abstracting the problem away from the executable that writes them. They can be strongly typed.

Frankly, you listed a bunch of tools which process "text logs" as though they're not doing exactly the same thing a binary log file tool is doing. They are also not "basic tools". Regex parsing is anything but basic, it's just commonly included. Just as journalctl will be on *any* system which uses journald because it's a basic tool.

There's also a huge strain of American-centrism here. Plain text sounds great so long as you assume it's English.

Such as?

Seriously, people keep saying this and I am genuinely curious what these needs are, and how they're presently met with init scripts.

Because "advanced" uses server side tend to be "monitoring and surveillance" - two things systemd is actually really good at. Binary logs? Literally no one cares, because your logging is going over the network and into a database of some type anyway and sending a few bytes less is actually kind of a big deal.

What people call "rare" edge cases in it's detractors seems to include, amongst other things, hot pluggable storage, localization, power management, service monitoring, cgroup isolation, network connectivity for enterprise configuration...