Readit NewsThe objection is the tiniest bug-fix windows get everything but the kitchen sink.
These are both uncomfortable positions to occupy, without doubt.
Ideally they'd be developed outside the kernel until they are perfect, but Kent addresses this in his LWN comment: There is no funding/time to make that ideal scenario possible.
If you’re using experimental file systems, I’d expect you to be pretty competent in being able to hold your own in a storage emergency, like compiling a kernel if that’s the way out.
This is a made up emergency, to break the rules.
Run a full screen term on my machine for a good chunk of my workflow and I just like to have time and battery in my term. I render it as ‘(15:35) [80} <hostname> $ ‘ and for boxes without batteries it’s just ‘(15:35) <hostname> $ ‘
Some times I’ll go back through my scroll back and look at the time when I’m trying to figure things out. Or when I run a command that generates a ton of output, I’ll note the time and run the command then later search back to the time in scroll back to start at the top of the log.
None of these are features I truly miss on a vanilla box, I can look at a clock or watch and will put a comment into the scroll back to find later.
When I first started using screen some years ago the emacswiki (I think) even mentioned it and recommended to remap it to ^p which it is for me for screen and tmux since then.
(I could remember something wrong here)
It seems like I’ve seen several of these over the years when a patch to parse comments would probably be simpler and less of an anti-pattern. What am I missing here?
Edit: or a config dir that allows multiple key files.
It all comes down to understanding whether the intersection of two grammars is empty.
Sure you could add a convention to your 'how to log' doc that specifies that all user input should be tagged with double '#' but who reads docs until things break? convention is a shitty way to make things work.
There's 100 ways that you could make this work correctly. Only restarting on a much more specific string, i.e. including the app name in the log line etc . . . but that's all just reducing the likely hood that you get burned.
I've also written a OOM-Killer.sh myself, I'm not above that, but it's one of those edge cases that's impossible to do correctly, which is why parsing and acting on log data generally considered and anti-pattern.