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"

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?

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.

The firmware might be hijacking the fn key. If you use one of the keycode-reporting tools, does it report the fn key? and what is fn+enter or fn+backspace being reported as? if you're not seeing the fn key, or if say fn+enter is reported as a singular key instead of two keys, maybe you could bind that "key" to enter?

If the Mac settings panel has an option to lock the F-keys to either F1-F12 or the keybinds, that option may be stored in the firmware, so for those keys simply reversing it in firmware may be enough.

Did you (or I?) miss something here? In the 3rd paragraph it's "revealed":

In a story of "what's old is new again", the solution dates back to ancient keyboards with physical keys for Copy and Paste.

Neo seems like a cool layout, reminds me of "unexpected keyboard" for android, but I fail to see the relevance since it doesn't have the copy/paste buttons (like the keyboard in the picture in the article) as far as I can see

In general I agree with you, especially on the image part, but I found the opensuse page to be a decent variation of this.

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.

Seems like the fn key is intercepted by the firmware then, that sucks. I'm repeating the same question differently just to ensure we're on the same page:

If I understood correctly, your fn key is constantly "active", making any key with an fn-modifier act as a different key, and that is why forexample the enter-button won't be... well, enter? but if it enter acts as a different key, i.e. pressing enter gives a totally different keycode, can't you rebind whatever keycode that turns into, into enter?

I did a super surface-level quick search, it seems like the older macbooks have had some firmware reverse engineering done. Might be some options there. Also, your issue may be a common case of a specific board trace needing new solder, which might not be too hard. Maybe that guy who does apple repairs/right to repair has something on this, or a community who may know. Louis Rossman something? can't recall.

Also, you may've mentioned in your original post, but are there other keys that could work? doesn't mac have that extra "option" key? i think i read that ctrl+fn key could be switched on a firmware level, if that means the ctrl key is then intercepted by the firmware I guess it won't add much, but if all else fails, could be worth checking if it acts differently.

good luck, I don't have any more ideas but I'm rooting for you, would be interesting to hear if you find a solution.

not 100% sure but I think the permittedimsecurepackage option takes effect after the rebuild. Doing the first rebuild with the env-override and --impure should work, and then it should work without for the next ones.

Some of these you're already doing, but writing a complete* list. *almost garuanteed not to be complete, suggestions welcome

1. Have everything behind the same reverse proxy, so that you have only one endpoint to worry about. Run it through ssllabs or similar to check your config.
2. On your reverse proxy, add one or more layers of authentication if possible. Many possibilities here: If one app supports client certificates, while another has limited capabilities, you could probably tie together something where IPs are whitelisted to the ither services based on that certificate auth.
3. Geoblock all countries you won't be accessing from
4. crowdsec is pretty nice, this detects/blocks threats. kinda like fail2ban but on steroids.
5. if you use one of those 5$/month VPSes, with a VPN tunnel to your backend services, that adds one layer of "if it's compromised, they're not in your house".

lastly consider if these things need to be publically avilable at all. I'm happy with 95% of my services only being available through Tailscale (mesh VPN, paid service with good enough free tier, open source+free alternatives available), and I've got tailscale on all my devices

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.

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

If you are on HDD then looking at what else is using the same disk, and reducing that usage, may yield some results. Forexample, if /var/log is on the same disk and can't be avoided, then reducing log volume or batching writes may reduce the "context switches" your HDD has to do. There should be options for I/O limits/throttling/priority in systemd. If you have only postgres on the HDD, I'd consider giving it 90% of the max bandwidth -- maybe that'd be more effective than going full throttle and hitting the wall. If you have postgres and some other service fighting for the HDD's time, these limits could help. Make sure access time tracking is off (or set to relatime).

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.

I don't understand what you mean with the content disappearing when you mount the virtiofs on the guest - isn't the mount empty when bound, untill the guest populates it?

Can you share what sync client+guest os you are using? if the client does "advanced" features like files on demand, then it might clash with virtiofs - this is where the details of which client/OS could be relevant, does it require local storage or support remote?

If guest os is windows, samba share it to the host. if guest os is linux, nfs will probably do. In both cases I would host the share on the client, unless the client specifically supports remote storage.

podman/docker seems to be the proper tool for you here, but a VM with the samba/nfs approach could be less hassle and less complicated, but somewhat bloaty. containers require some more tailoring but in theory is the right way to go.

Keep in mind that a screwup could be interpreted by the sync client as mass-deletes, so backups are important (as a rule of thumb, it always is, but especially for cloud hosted storage)

no what you really need is backups, isn't it? having an external hdd that you're backing up to is a lot better against data loss than putting that same drive into any kind of raid. (because now you truly have a copy, while in a raid it's still a single point of failure)

I can feel your pain on the ISP part though. (Haven't looked into this, but sounds like a zfs-job) Just saying that backups doesn't have to be offsite, but they do need to be separate from the original data medium. Going offsite is an important early step, but getting it on separate storage is the first step.

If anything, I would argue that especially in a homelab, the risk of misconfigurations or by mistakes when tinkering can increase by using raid. If you've have a couple of years of experience with raid and do not see my above argument, then please share your experiences.

I am sorry for this wall of text, your comment caught my eye while thinking about something else, tl;dr: raid is not a backup

If it's because of the lack of plan for the device, then if it helps, it's an extremely "in-character" and sensible action for the involved characters. It doesn't really need to be a plot device going forward, because the circumstances around it so far is pretty "complete" so to say.

I've tried to stay vague because of spoilers.

[I am not an electrician, so this is not a recommendation and I would not be qualified to make one] With that out if the way, what I would do to test this theory is to measure the voltage between a ground pin in each house, using am extension cord or similar to bridge the distance. A decent multimeter should do the job. Note that the cord itself would cause a voltage drop, but the ethernet cable would too so I think that'd if you can't measure a difference with the extension cord (which should have less ressistance than the ethernet one) then it shouldn't matter(?)

Note that while ground is normally "the safe pin" (not really a thing I guess but..) in this case, where the suspicion is a differential, then it should be very much considered live. And that means all precautions should be taken, such as not following a random stranger's advice.

It might be worth looking into those plugin-sockets with ground fault protection in both ends (not sure if they'd do anything in this case), if the ethernet cable is shielded, maybe removing the shield in one end (such that the cable is grounded only to one house) could make things better (or maybe even worse?),

and while maybe not feasible: fiber wouldn't be affected by this as it's just light, and likewise WiFi or other wireless tech could be feasible. with clear line of sight, 5GHz can provide very good speed and latency.

nah I think your reading comprehension is off, it's a week of treatment, then several weeks off. As a non-native English speaker I get why the original phrasing of "weekly" wasn't the clearest way of putting it, but I think the guy you called schizo just didn't understand what you were confused by