I have a bunch of these as headless gaming PCs in a rack running sunshine and Steam on Linux. The kids stream from them using moonlight on whatever smart device they want to play on.
Had the idea from LTT but he went a bit bonkers and bought expensive hardware to transmit video and input over cables. Gigabit Ethernet is more than enough.
We are able to make do with Software Encoding for now, more so with the unlocked cores but it is limiting its potential. There seems to be something called PyroWave making waves for being a low latency encoder/ decoder but nothing supports it yet except for a now pulled Steam Beta.
Otherwise I'll have to investigate capturing video via the DP port or switch it out altogether.
On a similar experience, I use moonlight on my Android TV to stream video games from my computer in another room. I use my own fork from an unmerged PR which enables me to use an Xbox One Wireless adapter so I can play with my pad wirelessly. These pads have a 3.5mm jack on them which on Windows and Linux enables me to route audio from the game to headphones connected to the pad. Moonlight and the xow driver it bundled, was nowhere near being able to provide this as a feature.
After about 5 hours, feeding it the GIP spec, an export of sniffed usb traffic from Windows, prior art (xone driver for linux), and giving Claude connectivity to my Shield via adb, I had it working. This continuously blows my mind that I dont have to beg a developer on Github to do it for me.
I have a Razer Wolverine Xbox controller that has extra back paddle buttons. The controller doesn't expose the paddles directly to PC's over USB. You have to use button remapping on the controller to map them to 'real' Xbox buttons for the PC to see them. But I wanted to use the back paddle buttons on Steam as separate controls.
So I downloaded the latest firmware update off the internet (because what device doesn't have firmware updates these days), installed Ghidra and an MCP server for it, and told Sol to look for how I can expose these extra buttons to a PC host. Maybe we could write a firmware patch?
Turns out the controller already has a special mode to expose those buttons, possibly as a hardware test. But it was enough to write a Linux driver to put the controller into that mode, and a little bit of extra driver code to map the paddles to a Linux controller button, and voila. Paddles working in Steam.
And it only took a few hours to do, too. I spent more time making an open source repository out of the concept than I spent making it work.
What's the repository link? I think it would be fascinating to have a corpus of "hacked" solutions like this. Can't tell you how many times a couch co-op game night got sabotaged by some piece of hardware failing to communicate with another.
The "linux" support is pretty narrow (because I made this for myself). It's restricted to SteamOS. But I'm sure it could be ported easily, the repository contains documentation about the important parts from reverse engineering the firmware.
I've been going a step further and trying to get AI to decompile the firmware to a different controller to add native SInput support. Hasn't been going well.
You're proud of yourself for being able to do the work yourself. That somebody else can get the end result without the skill means that they get the end result, but it doesn't undermine your achievement.
GitHub Enterprise Cloud has been chugging along with no issues. I hope your critical infrastructure isn't dependent on a free tier / service. And that you have a business continuity process in place.
Not only fable. Opus does this too. Which is exactly why I want to review. Like recently for some task it was convinced in a site dump images are not there and convinced itself db and files were skewed. But it didn’t check the actual site … if I hadn’t stopped it, it would have fine on and on or wasted tokens on some elaborate ‘fix’.
In the $19 plan, I've been able to reverse engineer both an android APK and firmware (in Ghidra and Radre) for a baby rocker and build a quick PoC application in my session limit. And then further refined the app in another session at another point in time without leaving Opus. I dont consider that to be a tiny task. How are you blowing through your usage?
I have no idea. Seems like normal stuff. I used Kimi Code with K3 to add support for Kimi Code to flar (https://swelljoe.com/post/i-let-every-agent-implement-its-ow...), a task I've done with almost every major model/agent combo. Most show up as a blip on the usage chart...it's basically usually one file, a README update, and adding the agent name to the CLI.
Then, I added it to my benchmark of security vulnerability auditing capability, and it burned a bazillion tokens, burned through the 5-hour limit, burned through $100 in extra usage I'd allocated, and was only 11% finished. That's more expensive than any model I've tested other than GPT 5.5 Pro on this task.
These are things I've done with a bunch of other models, I feel like I have a notion of what they ought to cost, and with K3, they end up being crazy expensive. (And it seems to be a function of how many tokens it burns accomplishing the tasks.)
I guess the problem is, that claude's 5 h/weekly limit is not consistent, but depends how many other people are using it/how much ressources Antrophic currently has. I did huge amounts of work without hitting the limit - and small tasks at some other times that hit the limit before it completed.
Those who pay for the expensive direct API, get served first.
Not surprising given the way they served super low-quality inference before they acquired compute from Musk.
And not convinced they couldn’t have instead tried the It’s A Wonderful Life strategy (“fam we’re oversold, would some of y’all be OK to limit your usage? We’ll get you back one day!”)
I wonder if the harness itself is not token-efficient? It would be fairer to compare K3 using the same generic harness, such as a Pi setup with some sane extensions for token optimisation.
My assumption would be, when there is a large corpus of crash reports for a certain configuration of hardware, knowing if it's a hardware failure, driver bug, or software incompatibly, is pretty hard. So it's probably easier to catch false positives and not get blamed for a faulty product, even if you aren't the cause. Drivers crash under the hood in windows all the time, even today, but once MS did a better job of just restarting the offending drivers where possible instead of BSODing, people thought windows was an unstable product. Which is technically true from the users perspective, even though it wasn't Microsoft's fault directly. You may have had a good combo that simply shouldn't have been on the list/was later patched/or your system is more stable that the average persons.
There was nothing special about my setup. Standard intel processor with i915 driver which I would imagine covers a fairly large chunk of installs out there.
I think the options are dependent on your setup. For example if you have a smart TV running Android, you could run https://www.virtualhere.com/usb_client_software on it to connect a dongle or controller attached to the TV through to your main device.
I do this with my Nvidia Shield and Xbox One Controller.
What a great idea! I've grown pretty frustrated by the ads and constant nags for subscriptions modern weather apps pester you with. I've resorted to the state developed apps in Norway and Denmark but yours seems like a great alternative too.
Had the idea from LTT but he went a bit bonkers and bought expensive hardware to transmit video and input over cables. Gigabit Ethernet is more than enough.
reply