kodablah

Mentioned in other comment, but this is what I did at https://github.com/cretz/vitaslop for Vita. Generic ARM-to-WASM transpiler.

I did similar for PS Vita over the past few months: https://github.com/cretz/vitaslop

But instead of single games, I "built" an ARM-to-WASM transpiler in WASM. Also cool transcoding of WebGPU shaders, audio, and more.

Only have tested a few games so far, it's early days, but works quite well in Chrome mobile on flagship Android phones.

> The way to do this safely (potentially still with suits happening, but safer at least) will be to have one execution to produce a specification, and a second fresh execution taking the specification to produce a design.

I have seen Claude literally suggest using a Sonnet sub agent to read source the main agent shouldn't, and have the sub agent describe the "facts and ideas" via markdown to the parent agent thereby maintaining that it is clean room and not, for example, GPL encumbered.

This seems as acceptable as asking a human to do the same. Otherwise, taken to its logical conclusion, if any LLM was trained on GPL software, it cannot be used for non-GPL authoring (and IIUC Claude does offer indemnity for enterprise plans if this is challenged).

While I would like this, my guess is it is hard to reconcile with all the other commercial ventures in the state (including datacenters) that aren't subject to such a requirement.

https://texas-connects.com/ is also running lots of commercials locally. But both this open letter _and_ the commercials intentionally skate around the resource needs.

> OpenAI will pay our own way and protect residential and small-business customers [...] OpenAI will work to support new power generation in Texas

Notice how this very intentionally doesn't say they will work to support generating as much or more power than they will use? Because if they could do that, they would just generate their own power. It doesn't matter if they "pay their own way", they are now competing with households.

Same with water, all of these projects want to leech on existing systems because they don't even want to entertain developing their own systems.

However, having worked inside Texas DCs for a long time now, I think it's just the burst that's the issue, not the concepts. Sadly they'll share our resources, but I think they should pay a premium on their energy compared to residential (but it's hard to reconcile this with other commercial ventures that do not).

Also touched on at https://typesetinthefuture.com/2016/06/19/bladerunner/ (and the book)

That tweet says:

> Opus 5 can silently fallback to Opus 4.8 (without any notice) on the serverside if you hit a guardrail

But https://support.claude.com/en/articles/16049681-why-claude-s... says (emphasis mine):

> These checks cause Claude to _visibly_ fallback from Opus 5 to Opus 4.8 [...] You'll see a notice explaining that the model switched, and the response will be labeled with the model that answered.

So who is right? I know for Fable I am visibly told, is this tweet trying to say it is silent against what Anthropic is saying?

All stay under because I had Claude build the workflow to respect it (text encoding, denoising, vae, etc), there's just a tiny bit of untracked pieces. While there are common interfaces to invoke them (CLI and API/webpage) and they share ops and some pieces, lots of model logic is unique. This is all vibe coded and surely has inaccuracies.

I've taken a similar strategy w/ image/video gen at https://github.com/cretz/thinfer (see video branch for a ton of work).

Basically I kept needing an inference engine that could stream weights in and out as needed in an LRU manner. So I ended up vibe coding this thing that accepts a `--vram-budget` and stays under it (mostly). It turns out moving mmap'd bytes in and out of VRAM is way cheap compared to compute. Coupled with some pipelining/double-buffering, I almost always end up compute bound not memory bound. Granted I use way smaller models heh.

And people that don't run red lights and suffer selective enforcement and are used for arbitrary surveillance and so on and so on. Don't let your naive view of what you want these things and their handlers to do distract you from reality, regardless of the brand or intent of widely deployed cameras.

They're all basically turned off by law, just not removed

"Meanwhile in <location> we can't even have Flock cameras to automatically catch people who may have killed someone"

Hopefully the absurdity of broad scale surveillance can't be so easily lost in hyperbole

Turbo appears GGUF'd already: https://huggingface.co/Abiray/Krea-2-Turbo-GGUF

I used CEF for a project and Google is detecting CEF via some opaque algorithms and not allowing logins from it. From https://security.googleblog.com/2019/04/better-protection-ag...:

> Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June

Granted this was years ago, maybe the situation improved? I had to abandon my CEF project because of this.

> Efficiency beats pristine. _I_ don't want [...]

Emphasis mine. This is the exact mindset I'm referring to, and when applied generally to files in the repo, will bite at some point. Even if you're lucky and it's unimportant/internal enough not to bite users, it will bite contributors. Luckily none of us would be discourteous enough to do this while contributing to another's repo.

> Design Principle #1 [...] The secondary masses should never compete with the primary mass.

> Design Principle #2 [...] shows multiple violating their own mass rule as good examples

While there are some ugly/gaudy houses out there, the gatekeeping behind what is a "McMansion" is subjective and silly.

This mindset is how you get lots of IDE/dev-env-specific/platform-specific cruft inside of repos instead of pristine repos. It makes both contribution and maintenance difficult over time. While less of an extreme issue as IDE/dev-env-specific/platform-specific hacks/scripts littering the repo, gitignore entries should be generally justifiable, not ever-growing cruft to be added by each developer specific to their situation.

My guess is this is leveraging GDX same as "Gameday" uses (or used to use). https://gdx.mlb.com/components/copyright.txt states

> Only individual, non-commercial, non-bulk use of the Materials is permitted

Unsure if this falls within. I have written my own scripts against the XML regularly updated there, but am unsure if they allow it to be used on a shared site.

In browser AI image/video gen: https://intabai.dev/

(V)RAM conscious AI inferencer/generator: https://github.com/cretz/thinfer

In-browser AI image/video generation: https://intabai.dev.

And now working on an inference engine specifically geared to low mem situations. Both basically vibe coded. Not broadcasting either project widely as they remain unstable, unpolished side projects.

I've worked around lower RAM machines with ONNX web models by first separating .onnx from .onnx_data, and second having scripts that split up the "layers" and shards the run (e.g. https://huggingface.co/cretz/Z-Image-Turbo-ONNX-sharded). Then you can have the runtime only run one at a time. I don't understand the details too deep, but Claude is good at writing scripts to shard onnx protos.

Nice, I've also been doing some similarly neat things via ONNX web at https://intabai.dev (caution, just PoC tools atm, only Chrome tested, only some mobile devices work, no filters).

I think all-client-side in-browser AI imagery is becoming very doable and has lots of privacy benefits. However ONNX web leaves a lot to be desired (I had to proto patch many pytorch conversions because things like Conv3D ops had webgpu issues IIRC). I have yet to try Apache TVM webgpu approaches or any others, but I feel if the webgpu space were more invested in, running these models would be even more feasible.

> I don't think that "computing freedom" means you get to use other people's computers without consent

Consent from whom? Consent is already required, why are you discussing this as though consent is not required? Why are you stating it as if people are using other's computers without consent? Right now when I sideload an APK on _my device_, I have to explicitly consent to allowing it to install. And I do not require the author of that APK to have made any deals/interactions with Google. What you mean is Google's consent or a debugger's consent or my consent tomorrow.

So I, as the user, will no longer be able to provide consent alone. I wish that you were right and it was just "no running without consent", but that is today's behavior, and that is being altered.

> I think a good compromise is that they could permit you to sideload. Which they are doing.

They always have, and that was a good compromise. They've now decided you can't sideload until tomorrow unless you break out debugging tools or require the author make special deals with a specific vendor. What exists today is a good compromise, the change is not.

I expect the same from my desktop and mobile devices here.

Such is the cost of computing freedom. This line of thinking is analogous to surveillance justifications in meatspace.

Doing a 24h wait _is_ much different from what happens today. That's the whole point. If my two options to run an application of my choosing are to use ADB to flip a switch or to wait a day, that is ridiculous.

I am only slightly comforted by the fact that desktop computing had set (some) self-ownership precedence before the current restrictive computing hegemony took control, though even that is eroding.

> Saying there is no opt-out is just false

I can't see where one can opt-out of this new behavior and into the existing behavior, only a description of the new behavior's bypass (which is not the same thing at all)

> easy to bypass the cooling-off period with ADB

I don't think this is a reasonable use of the term "easy". I should be able to give my non-technical friend an apk and they can use it right then, with the one "are you very sure" screen.

> If you dont have analytics you are flying blind

More like flying based on your knowledge as a pilot and not by the whims of your passengers.

For many CLIs and developer tooling, principled decisions need to reign. Accepting the unquantifiability of usage in a principled product is often difficult for those that are not the target demographic, but for developer tools specifically (be they programming languages, CLIs, APIs, SDKs, etc), cohesion and common sense are usually enough. It also seems real hard for product teams to accept the value of the status quo with these existing, heavily used tools.