I've got this setup recently via pipewire! With something like barrier for kvm, it's great!

I have an alias on each side -- one gets a new source, the other a new sink.

  audio_recv='pactl load-module module-native-protocol-tcp port=4656 listen=0.0.0.0'
  audio_send='pactl load-module module-tunnel-sink server=target:4656'

Left to his own devices, I found Claude liked to copy the code under test into the test files to 'remove dependencies' :/

Or would return early from playwright tests when the desired targets couldn't be found instead of failing.

But I agree that with some guidance and a better CLAUDE.md, can work well!

I have the Kinesis Advantage 360 which is split but has all the non-numpad buttons.

I do spend lots of time in Emacs, but also use it for plenty of gaming. Just remap in-game to ESDF and only use the left hand. (Or set up layers, but I'm generally too lazy for that).

I think the thumb clusters are great, but may not be to your taste. I'm very happy with it, but have used various iterations of kinesis keyboards for a long time now.

I'm making a game finally! Merge-three + village sim.

Hoping to actually take this one to something polished as opposed to the many half-finished prototypes littering my git repo over the years. I've discovered (always knew?) that heavily cutting scope is the best way, and been successful thus far.

It gets pretty boring/unbalanced by ~150 turns, but I have some ideas on how to fix. I'm still playing with ways to help de-clutter the board and make use of the economy aspects.

After some false starts with ai-gen art, I had fun learning to color the pixels myself. The process wasn't as scary as I'd thought and the results are better than I hoped.

https://tower3.dreamofninjas.com/

Inspired by TripleTown from the wonderful studio Spry Fox.

Semi-related; One of the Zelda DS games required you to close the DS (so the top and bottom screen met), which moved a mark from the top to bottom screen. Was infuriating for me, only figured it out after closing the DS in frustration. Not really something you can do with modern portables, but clever in retrospect.

I wonder how much this is causing the worldwide swing toward authoritarianism. Lead exposure can cause lower conscientiousness, lower agreeableness, and higher neuroticism.[1]

Especially considering the age of people who actually vote and who the politicians in power are (at least in the U.S.)

[1] https://pmc.ncbi.nlm.nih.gov/articles/PMC8307752/

Is lead exposure going up or down? I assume it's going down, because lead gasoline was banned, lead paint was banned, and the lead that was in the environment due to those 2 source is slowly being cleaned up.

I at least assume lead exposure now is lower than when leaded gas was primarily used. In the US it started to be phased out in 1973 and finished in 1996.

Down a lot now, but likely peaked in the 70s -- Kids growing up then are likely 50-60 which are the higher turnout voting brackets.

There's a lagging effect from lead exposure, so it's difficult to pinpoint when those exposed would be most impacted.

https://usafacts.org/articles/how-many-americans-vote-and-ho...

Yeah, having all the defaults for system keybinds be on super is really nice.

It feels like macosx lucked into this with their historical use of command as the modifier, but I also wish I could easily replicate. Instead I just go and remap a few line ctrl-a in KDE settings and otherwise try to live in emacs.

"Lucked"? Is it not a choice to continue using PC keybindings? I would simply call this lack of attention to the user experience.

Anyway, the first distro or desktop environment that figures out this problem will get a lifetime sponsorship from me. It's a huge productivity killer and remapping all apps, toolkits, etc, is untenable.

Of note, Haiku os seems to have solved this issue permanently. It's a matter of will, really.

It's harder to learn the impact of your design decisions -- Seeing how software evolves to meet changing business goals and how the design choices made play out in the long run helped teach me a lot.

Coming up with a neat API that turns out to be difficult to modify in the future, or limiting in ways you didn't imagine would when writing it is a good learning experience.

Or seeing how long a system can survive growing usage -- Maybe a simple hack works better than anyone expected because you can just pay more for RAM/CPU each year rather than rebuild into a distributed fashion. Or the opposite, maybe there's some scaling factor or threshold you didn't know existed and system performance craters earlier than predicted.

I've thought about this a lot in relation to typescript over the years and had various opinions -- For some time I thought it'd be better if there was an implicit `await` on every line and require `void` or some other keyword to break execution like `go` in Golang.

But, eventually I realized the difference in pre-emption between languages -- Go can (now) preempt your code in many places, so locks and thread-safety are very important.

The javascript runtime only preempts at certain places, `await` being one. This means I can know no other code can be running without explicit locks around all critical sections.

Finally understanding the trade-offs, I no longer am as frustrated when recoloring a bunch of functions. Instead, I can appreciate the areas where I'm not required to lock certain operations that I would in other languages.

There is no preemption in Javascript. It is based on cooperative multitasking[1] (your await statements and non-blocking callback) which is the opposite of preemption.

[1]https://en.wikipedia.org/wiki/Cooperative_multitasking#:~:te....

As anyone who has done the old setTimeout(fn, 0) trick in the browser probably knows.

They even created setImmediate(fn) for this purpose

If every line had an implicit await then it is indistinguishable from pre-emption, which I think is the point the person you're replying to is trying to make.