_flux

Let's say we didn't have assemblers, but instead we would have three professions:

- Specifiers, who make the specification for the system

- Programmers, who write C code

- Machine encoders, that take that C code and write machine code for a CPU

Would it be that the copyright would then belong to programmers, if no other explicit assignments would be made?

---

Thinking about it, probably yes: copyright of the spec belongs to specifies, copyright of the C belong to programmers, and copyright of machine code to machine encoders. Or would it depend on the amount of optimizations the machine encoders would do, i.e. is it creative or not? And then does this relate to the task and copyrightability of C compiler output, where optimizations can sometimes surprise the developer?

I think it should be pretty clear that if you provided the tool the specification for the code you want, you have already provided creative input.

After all, is this not what happens with compilers as well? LLM agents are just quite advanced compilers that don't require the specification to be as detailed as with traditional compilers.

If someone really wants to continue the name, they can of course ask the author; maybe they have a compelling case.

I looked it up: https://doc.rust-lang.org/std/string/struct.String.html#meth...

In case anyone else was wondering it, yes, it's "unsafe".

I don't know how large the cache is, but Gemini guessed that the quantized cache size for Gemini 2.5 Pro / Claude 4 with 1M context size could be 78 gigabytes. ChatGPT guessed even bigger numbers. If someone is able to deliver a more precise estimate, you're welcome to :-).

So it would probably be a quite a long transfer to perform in these cases, probably not very feasible to implement at scale.

Wouldn't it help if the system did compaction before the eviction happens? But the problem is that Claude probably don't want to automatically compact all sessions that have been left idle for one hour (and very likely abandoned already), that would probably introduce even more additional costs.

Maybe the UI could do that for sessions that the user hasn't left yet, when the deadline comes near.

What we would call O(n^2) in your rewriting message history would be the case where you have an empty database and you need to populate it with a certain message history. The individual operations would take 1, 2, 3, .. n steps, so (1/2)*n^2 in total, so O(n^2).

This is the operation that is basically done for each message in an LLM chat in the logical level: the complete context/history is sent in to be processed. If you wish to process only the additions, you must preserve the processed state on server-side (in KV cache). KV caches can be very large, e.g. tens of gigabytes.

The term unityped is used as well, and at typing level this also makes sense: you have one type called object, you put that object alongside the value object ("tag"), and then at runtime all operations on that object check if its type object provides the operation the code is trying to apply on it (or maybe each value object directly knows the operations it supports). I think I prefer this term.

"syntactic type" is a weird term to me, though. Is that in common use?

Oh I actually had some editing mistake, I meant to say that also Rust has restrict by default, by virtue of all references being unique xor readonly.

As I understand it, the Fortran compiler just expects your code to respect the "restrictness", it doesn't enforce it.

I believe __restrict, and __builtin_prefetch/__builtin_assume are compiler extensions, not part of the C++ language as is, and different compilers implement (or don't) these differently.

The rust compiler actually has similar things, but they're not available in stable builds. I suppose there are some issues if principle why not to include them in stable. E.g: https://doc.rust-lang.org/std/intrinsics/fn.prefetch_read_da...

Maybe some time in the future good acceptable abstractions will be conceived for them.. Perhaps using just using nightly builds for HPC is not that far out, though.

Ah well that does simplify things significantly, I suppose it's probably still somewhat useful.

But I'd expect a big part of the nets are not connected to the ground? I mean in my hobby designs a majority of them is, but let's say if you generously use decoupling capacitors, then that might not be the case?

What does it do with a single probe, though? You need two to actually probe anything, right?

So I'm wondering how is the second probe problem dealth with. I've considered something similar but with small weight attached to a pogo pin, so the CNC arm could then just move it around, which would not be very easy to get completely reliable as there may be components on the board.

Will it help? AI authors will just then buy those subscriptions and in the big picture it won't cost that much.

They could write to the RFID how much filament "it has left".

I mean definitely a good starting point is a share-nothing system, but then it becomes impossible to use tools (no shared filesystem, no networking), so everything needs to happen over connections the agent provides.

MCP looks like it would then fit that purpose, even if there was an MCP for providing access to a shell. Actually I think a shell MCP would be nice, because currently all agent environments have their own ways of permission management to the shell. At least with MCP one could bring the same shell permissions to every agent environment.

Though in practice I just use the shell, and not MCP almost at all; shell commands are much easier to combine, i.e. the agent can write and run a Python program that invokes any shell command. In the "MCP shell" scenario this complete thing would be handled by that one MCP, it wouldn't allow combining MCPs with each other.

Maybe an "agent shell" is what we need.

In principle it could use e.g. the `gdb` and step until it gets the secret. Or it can know ahead where the app stores the cerentials.

We could use suid binaries (e.g. sudo) to prevent that, but currently I don't think we can. Most anyone would agree that using a separate process, for which the agent environment provides a connection, is a better solution.

I've found Gemini useful in extracting timestamps for particular spots in videos. Presumably it works with transcriptions, given how fast it is.

The three answers it found were:

- Avoiding lock-in to them: http://www.youtube.com/watch?v=KKbgulTp3FE&t=1914

- Competitive advantage: http://www.youtube.com/watch?v=KKbgulTp3FE&t=1852

- Perceived Lack of Use Case: http://www.youtube.com/watch?v=KKbgulTp3FE&t=1971

Those points do actually exist in the video, I checked. If there are more, I don't know about them, as I haven't yet watched the rest of the video.

They make noise, and people remote, so that might not be the case.

In addition, more working time equals more wear and tear for parts.

Surely mapping also helps reducing the time it takes to achieve the task?

I think it would be impossible to find the price point for a monthly subscribtion that would both be profitable to a provider, as well as attractive to the customer. If anything, as the customers would now be paying necessarily even a higher amount for agentic use, they'd make certain they'd be using the agent as effectively as they can, meaning it would be even more costly for the provider.

Pay-per-token is really the only way it can work. If some kind of fixed monthly price is desirable, then there should be a quota the user can assign, and then the agent could e.g. slow itself down by 50% when 50% of the quota is spent, another 50% at 75%, etc, to make it last longer..

As a side thought, I wonder how it could affect an agent's behavior if the information of this token usage/limit was brought to it..

That's what these providers want as well, but from the other side. They want to know that a customer won't be able to eat more than certain number of servings, as they need to pay for each of those servings.

It works out even if some customers are able to eat a lot, because people on average have a certain limit. The limits of computers are much higher.

What I'd like to see would be some useful extra APIs in Wine, that would allow it to perform even better in some situations, and that such APIs would be then embraced by the game developers.

Finally some embrace, extend, and extinguish love right back at Microsoft!

Ah, I completely missed the point of your question :).

Yes, I think that's a good point. Possibly they were made before the project name was changed and no further thought was given to them after.

They are environment variables. I enjoy seeing from my large number of environment variables to which applications they belong to.

There are the commands git request-pull and git send-email to work with that workflow, though.

Frankly I don't think one even needs to learn it, if you know a bunch of other languages and the codebase is good. I was able to just make a useful change to an open source project by just doing it, without having written any lines of Go before. Granted the MR needed some revisions.

Rust is my favorite, though. There are values beyond ease of contribution. I can't replicate the experience with a Rust project anymore, but I suspect it would have been tougher.

Keyboard arrows worked.

But this method is now spent, as if someone is determined on keep using LLM, this should be pretty easy to overcome.

I suppose though new methods could be devised, but it's not "certainty" that they will catch them.

It doesn't seem the actual serialization format is specified? Other than in the code that is.

Is it versioned? Or does it need to be..

And as I understand it, most (if not all) of these segfaults were in casual use, not when someone is trying to attack it..