Agreed! I think a part of the "problem" is that with Nix, there's now at least 3 sides: application specific knowledge, system knowledge, and you have to use the nix language, architecture and tools to interface with it. so for a seasoned linux user, there's maybe just a new programming language, but if you're new to Linux, it's quickly gonna overwhelm you. which in a way is a bit ironic because I'd argue that it's easier to manage a NixOS system, and getting help is so much easier when your problems can be replicated by just aharing your config.

that is one way to do it, and it's a very common one - it's robust and simple. So I can't correct you, but thought I would add to it. In NixOS, they've improved it by making sure all your apps are symlinked, and when updating, these symlinks are updated. That way you can start using your newly updated system straight away, without a reboot. When rebooting, you are prompted to which generation you want to boot into, (defaulting to "latest" after a few seconds of no input) making rollbacks a breeze.

The tank and 6v6/5v5 has been heavily discussed, recently devs made a long devblog about it. I can kinda see where you're coming from, I think, but between balance/queue times/the average player (of which there tends to be more of when you're with 5 others instead of just 4) it seems to me like 1 tank works better in practice even though it struggles when compared to the ideal world+nostalgia goggles.

I was very pleasently ~~surprised~~ not disappointed by the monetization, like uncompleted weekly (battle pass -primary method of profression) challenges carry over, so in theory you can do all weekliesduring the last week if a battle pass. also aren't the new heroes available if you play just a few matches?

can I ask what level of experience/knowledge you have in this field? for fairness sake, I'm a sysadmin-ish role at work, having worked with remote terminal solutions, (optimizing remote desktop for use over satelitte and borderline dialup-speeds, if I ever again need to deep dive into the ICA-protocol it'll be too soon, lol) have tinkered with building keyboards, hobby involves arduinos & going deep down linux confing rabbit holes. Also done some gamejams, without ever really finishing any prototyoes.

Also - I think the way I brought up the OS implementation bit was too poorly phrased and we're too out of sync context wise for that to be a worth discussing at this point, but to answer your point, yes I am very versed in the subject, but I'm very curious ti see if there's something I;ve missed:

If you have one of these keyboards, please hook it up to your favorite key-input listening tool, and share what you see. I'm especially curious to if the priority you mentioned is something you see sent along with the keypress-signals, or if it is handled by the firmware of the device.

And for the record, I really do likewhat these keyboards are doing, I think it's about time we see some actuall progress in the field, and i sure as heck want those features in my next keyboard, but not seeing how this is unwelcome in competetive games at this point seems delusional to me. You're very welcome to challenge me om that, but the only argument I can see having an impact now is if you got some raw techical proof that challenges the models I've mentioned.

As an "outside observer", I think maybe you're not seeing (what I believe is) the other guys viewpoint: What you are bringing up (photoshop has been possible already) is a core part of what he said from the start, and his point builds on top of that. So obviously he already knows it, and arguing about it disregards that his line of argumentation builds upon the basis we all agreed upon to be true until you brought it up as ... contrarian? To his point. doesn't seem like "old man yells at cloud" energy, more like "Uhm, achtually"

they do in a way move the character on their own though, through emulating extra input events on behalf of the user.

without, these inputs are sent, one per human action: KEYDOWN=A, KEYDOWN=D with the same two keypresses: KEYDOWN=A, KEYDOWN=D+KEYUP=A

The problem is that these create input events on behalf of the user. forexample: When pressing A while still having D pressed, the keyboard sends a KEY_UP=D event even as the user is still pressing D.

As for your comparisom, lowering latency is something different, if anything it's attempting to make the users actions registered more accurately.

Do note that without this kind of processing, the games already knows that D is still pressed while A is presses, and they decide how to act on it. Games handle this differently, a common one being both keys as "stand still".

So we're:

1. creating new input eventson behalf of the user
2. tricking the game to to avoid a state the devs have intended
3. resulting in a huge advantage for the player.

In my opinion this should be implemeted on a OS level for all to use, but I don't struggle one bit to see how this is disruptive and a no-go in competitive games.