choeger

Of course they buy real things for it. And of course they do buy a lot and take up a lot of resources.

But I think it's orders of magnitudes below what their wealth number suggests. For instance, I don't believe that Elon Musk uses hundreds of square kilometers of living space (US average is 66m², scaling by wealth would give Elon hundreds of square kilometers). Same holds for food, heating, medicine, etc.

Fighting power concentration is a whole different game and I agree that it's necessary. But I think that wealth taxation isn't the right tool for it at all. You need something much more progressive than that.

The thing is: You cannot eat, or live inside, or get medical treatment from, stocks.

Wealth taxation cannot redistribute the kind of wealth we care about most. At least not by itself.

You need someone to buy the stocks in exchange for labor. So you need to keep the stocks themselves valuable.

As an extreme example, if you'd just take away all the SpaceX and Tesla stock from all shareholders and redistribute them, they would probably be near worthless because you just demonstrated that their value is more or less random.

I think that wealth taxation will only work if you give ironclad guarantees that people that are merely rich or middle-class will never be subject to it. If you can show that a stock is more valuable to, say, a medical doctor, then to the CEO of a hyperscaler, you might have a working system.

I am long out of this game, but the complexity class they show still has an n in the exponent, even if divided by log(n).

I have no intuition whatsoever on how that algorithm scales. Can anyone enlighten me?

Maybe a house tax should not be based on the value of the house, then?

You could easily imagine a flatrate per square meter. Or a flatrate per capita.

For the "stronger shoulders should carry more" argument, I'd look at the income from the property. If someone owns a collection of old paintings, why should they be taxed based on their value?

I read the agents used SSRF via artifactory to gain uncontrolled access to the net.

Apparently their intended net access went through a tightly controlled proxy. Even that appears to be very risky, tbh.

If I was to setup a sandbox for such a complex and autonomous system, I'd probably point them to an archive-like cache for net access and cut their comms at the package level.

There are two things I don't understand about this story.

First, why does an agent get any write access to artifactory at all?

Second, why is the artifactory cache not disconnected from the net? Surely you'd not feed it with new software versions while the eval or training is running.

So rewriting gets cheaper and cheaper. New features fall more or less into the same category. Refinement doesn't.

The question is: Will we live in the world of breathless re-implementation, new features every week, rebranding every quarter or will we eventually discover the value of stability, software that does its thing more or less optimally for decades?

Recent examples of things like curl or Firefox are interesting in that regard. Will we end up with a nearly perfect HTTP user agent and stick with it for decades?

Who said that? It certainly helps. Poland has close trade and manufacturing ties to Germany and has rightfully developed from a "cheap" image to "quality that's still affordable" image.

It certainly helps to be neighbor with an economically strong but demographically weak and overly beaurocratic country that hungers for eager, competent workers.

Transformers are great translators. So, yeah, starting with structured output like SVG is probably the best way to start.

It should be fairly trivial to fix any logic errors in the structured output, too.

You seem to have no idea what you're talking about. Type theory is a thing, much older than any compiler. And soundness has a meaning.

> It just means type errors are checked at runtime instead of compile time.

This is a fundamental misconception. A type checker proves the absence of errors. It doesn't check for error conditions. That is: A program that isn't (cannot be proven to be) well-typed can very well be correct. But a program that is well-typed is guaranteed to be free from certain errors.

What you call "dynamically typed", in contrast, is comsequent just value inspection and stopping the evaluation/execution early. A program that has been executed successfully often is not necessarily correct.

Dynamic typing is no typing.

The point of types is to prove the absence of errors. Dynamic typing just has these errors well-structured and early, but they're still errors.

To me it looks like formal verification is going to be the answer. We're going to move up the ladder and write formal specs and proofs soon.