uhhh... that's mostly on your browser. The css is at the top and pretty skimpy. If it really bothers you, find a styler extension that will override the CSS to render it more pleasingly.
>having to eff around with the crap show of Ruby/Python/Node envs and how every person likes to use different tools for setting those up
This was the problem I wanted to solve, and I ended up on nix+direnv (and am considering devenv) because nix, due to the existence of nixos, packages all the tools already! Does Mise support zig? or nim? or crystal? Nix does! And Nix will continue to keep up to date with all the tools, whereas things like asdf and mise - since they're specialized and not the basis of a full distro - are less likely to do so.
The practical problem with logging by time is that it's not resource constrained: holding N seconds of logs, even when each line is a bounded size, takes potentially unlimited memory. Logging 'by count' used a bounded amount of memory, and is easy to implement with a fixed size array in memory.
You're talking about a different scenario than than the article. The article is about a strategy of how to generate a single log line. You're talking about a strategy of how to batch multiple log lines together.
The problem with the 'characters are just numbers' approach is that they're not _just_ numbers.. with the advent of unicode, they're _sequences of numbers_... so bytes thus can mean different things when part of a a sequence than when standalone.
That said, since they're numbers, we should use the most efficient checks for them... which are likely vectorized SIMD assembly instructions particular to your hardware. And which I've seen no one mention.
Yes, that's it. Vectorized SIMD annihilates this problem, a space I've been working in since 2006 and it wasn't all that new even then. A close second would be a heavily optimized (pipelined and less branchy) table or bitvector lookup. Doing anything that involves lots of control flow, like the grandparent post, will be slow as a wet week with our without bit manipulation tricks due to the inherently unpredictable nature of the branches (subject to our input).
My first thought was that a library was writing fake books to poison LLMs that were using their corpus without their permission, and that someone had developed a tool to identify such books.
>The logical endgame of that approach is to have a big tug-of-war between two big coalitions
...why just two? He specifically mentioned advocating for ranked choice voting, which would make it a tug-of-war between N coalitions, and would lead to better outcomes that our current broken two-party system.
Power is somewhat binary - either you've got it or you don't. Ranked choice doesn't change that. The advantage of ranked choice voting is it allows people to be more expressive in signalling who they want to be in power.
And if N coalitions playing tug-of-war, that means there is an (N-1)/N chance that your preferred one loses. It is much better if everyone agrees not to play that game and adopts smarter strategy. Which has little to do with the number of people participating in the election.
