> Right? People forget the roots. Nowadays logs are super complicated things, but in unix and early Linux days, everything was a file descriptor and it happened

> Right? People forget the roots. Nowadays logs are super complicated things, but in unix and early Linux days, everything was a file descriptor and it happened to be that 0 was the default one to write to and by convention could be routed by pipes and streams into whatever making it super convenient way to emit informations not to users, but to anything No lol, that's not simple, that's just looking at the defaults that unix systems provide. If you've been hacking this long then you're familiar with all the fun issues like: * Are you writing to stdout as a buffered or unbuffered stream? * What happens if your writing process crashes before flushing its buffers if you're using a buffered stream. * Are you redirecting your log stream into a file on a slow volume? * Are collected log files being rotated? What happens if the target volume runs out of space before rotation kicks in? * If you are logging to a file does an error writing to this file block stdout streaming? If so, what happens to your process? These are hard problems which have a variety of solutions. There are more unix-y solutions such as runit's `svlogd` up to more involved solutions like systemd's `journald`, but problems they are nonetheless. I've hit each and every one of these in a system before, though most in non-prod environments. That's not to knock println debugging, which continues to be very popular, it's just that logging is actually a hard problem and pretending like it's not as some appeal to systems of yore isn't helpful. But by definition when you're debugging a system you're not in a production environment anyway so you can definitely deal with the log noise that comes with println debugging.