kodablah

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.

You can try the technical preview today by running npx cf. Or you can install it globally by running npm install -g cf.

A couple of obvious questions - Is it open source (npmjs side doesn't point to repo)? And in general will it be available as a single binary instead of requiring nodejs tooling to install/use? If so, using recently-acquired Bun or another product/approach?

It is also in that book, page 36/37, with transcription and minor note on issues with ISS toilets in 2008.

Modern languages are not safe enough nor are they very amenable to versioning, serialization, resumption, etc. It makes sense for modern durable execution engines to meet developers where they are (I wrote multiple of the SDKs at Temporal, including the Python one, this is just a fun toy side project), but a purpose-built language that has serialization, patching, wait conditions, kwargs everywhere, externalizing side effects, etc, etc, etc is a big win vs something like Python.

Admittedly the lang spec doesn't do a great job at the justification side, but the engine spec adjacent to it at https://github.com/cretz/duralade/blob/initial-runtime/docs/... that has sections showing CLI/API commands can help make it clearer where this runtime is unique.

Duralade - a programming language for durable execution (but has many neat aspects)

Most of the work as of today is in a branch, can see the language spec at https://github.com/cretz/duralade/blob/initial-runtime/docs/..., and some samples at https://github.com/cretz/duralade/tree/initial-runtime/sampl....

May not amount to anything, but the ideas/concepts of this durable language are quite nice.

People who are saying they're not seeing productivity boost, can you please share where is it failing?

At review time.

There are simply too many software industries that can't delegate both authorship _and_ review to non-humans because the maintenance/use of such software, especially in libraries and backwards-compat-concerning environments, cannot justify an "ends justifies the means" approach (yet).

that's the only way they "learn" anything

I think skills and other things have shown that a good bit of learning can be done on-demand, assuming good programming fundamentals and no surprise behavior. But agreed, having a large corpus at training time is important.

I have seen, given a solid lang spec to a never-before-seen lang, modern models can do a great job of writing code in it. I've done no research on ability to leverage large stdlib/ecosystem this way though.

But I'd be interested to see what you come up with.

Under active dev at https://github.com/cretz/duralade, super POC level atm (work continues in a branch)

I'm of the mind that it will be better to construct more strict/structured languages for AI use than to reuse existing ones.

My reasoning is 1) AIs can comprehend specs easily, especially if simple, 2) it is only valuable to "meet developers where they are" if really needing the developers' history/experience which I'd argue LLMs don't need as much (or only need because lang is so flexible/loose), and 3) human languages were developed to provide extreme human subjectivity which is way too much wiggle-room/flexibility (and is why people have to keep writing projects like these to reduce it).

We should be writing languages that are super-strict by default (e.g. down to the literal ordering/alphabetizing of constructs, exact spacing expectations) and only having opt-in loose modes for humans and tooling to format. I admit I am toying w/ such a lang myself, but in general we can ask more of AI code generations than we can of ourselves.

The thing is, if you want people to understand durability but you also hide it from them, it will actually be much more complicated to understand and work with a framework.

The real golden ticket I think is to make readable intuitive abstractions around durability, not hide it behind normal-looking code.

It's a tradeoff. People tend to want to use languages they are familiar with, even at the cost of being constrained within them. A naive DSL would not be expressive enough for the turing completeness one needs, so effectively you'd need a new language/runtime. It's far easier to constrain an existing language than write a new one of course.

Some languages/runtimes are easier to apply durable/deterministic constraints too (e.g. WASM which is deterministic by design and JS which has a tiny stdlib that just needs a few things like time and rand replaced), but they still don't take the ideal step you mention - put the durable primitives and their benefits/constraints in front of the dev clearly.

that your entire workflow still needs to be idempotent

If just meaning workflow logic, as the article mentions it has to be deterministic, which implies idempotency but that is fine because workflow logic doesn't have side effects. But the side-effecting functions invoked from a workflow (what Temporal dubs "activities") of course _should_ be idempotent so they can be retried upon failure, as is the case for all retryable code, but this is not a requirement. These side effecting functions can be configured at the callsite to have at-most-once semantics.

In addition to many other things like observability, the value of durable execution is persisted advanced logic like loops, try/catch, concurrent async ops, sleeping, etc and making all of that crash proof (i.e. resumes from where it left off on another machine).

At Temporal, for Java we did a hybrid approach of what you have. Specifically, we do the java.lang.reflect.Proxy approach, but the user has to make a call instantiating it from the implementation. This allows users to provide those options at proxy creation time and not require they configure a build step. I can't speak for all JVM people, but I get nervous if I have to use a library that requires an agent or annotation processor.

Also, since Temporal activity invocations are (often) remote, many times a user may only have the definition/contract of the "step" (aka activity in Temporal parlance) without a body. Finally, many times users _start_ the "step", not just _execute_ it, which means it needs to return a promise/future/task. Sure this can be wrapped in a suspended virtual thread, but it makes reasoning about things like cancellation harder, and from a client-not-workflow POV, it makes it harder to reattach to an invocation in a type-safe way to, say, wait for the result of something started elsewhere.

We did the same proxying approach for TypeScript, but we saw as we got to Python, .NET, and Ruby that being able to _reference_ a "step" while also providing options and having many overloads/approaches of invoking that step has benefits.