3 ms·

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

Right? People forget the roots. Nowasays 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 Which is the right thing anyway. If your target are interactive users a log is a terrible thing to do as they won't know where it ends up. And if the target is not interactive users you should have error codes not log messages. I think that is partly because today is hard to just attach a debugger to things and see the state of a program so people try to serialise the program state to english strings with a timestamp and work backwards from that to understand what the program was doing, but then what we need is a differentiable single stack core dump not an english approximation of it. And especially not one that gets stolen by systemd and hidden away. Sorry for the rant but just printing infos and core dumping errors was the best thing ever and it was taken away from me.

Karrot_Kream 3y ago
> 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.

Karrot_Kream 3y ago

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