thayne

How does this compare to distrobox?

> Recent incidents have highlighted a fundamental hurdle for AI agents, and that is that model-level safeguards alone can’t govern what agents can access or do

Um, yes. That is fairly obvious, and really should not be surprising to anyone doing research with LLMs. But we don't need anything really novel here, we already have VMs, containers, firewalls, airgaps, etc.

I think that question is very similar to why, if AI is making software developers so much more productive, those developers are not getting paid substantially more, or having to work fewer hours.

I think it is more akin to paying a software contractor to make something to meet your specific need, and they give you an off the shelf product (which they may or may not have made themselves).

Vendoring isn't a clear win for security. It may provide some protection against "supply chain" attacks, but makes it more difficult for you to respond to vulnerabilities discovered in the version you vendored. And for business continuity, in many cases depending on an external registry is an acceptable risk.

And both of those concerns can be addressed by using an internal/private registry that mirrors the packages you need.

But in any event, your original question was to elaborate on why vendoring is inconvenient. Whether or not the benefits are worth the inconvenience is a different question, to which IMHO the answer is "it depends". Sometimes it is, and sometimes it isn't.

> But it does mean you need people who are experienced at solving them or who care enough to learn.

That sounds like it's inconvenient to me.

> Disk is cheap

The biggest problem isn't (usually) disk space, or network bandwidth, it is that git operations slow down as the size of the repo grows. And it means that cloning or pulling the repo takes longer, which can be especially problematic for CI.

> Recursive dependencies have the same issues whether you vend them or not.

Package managers usually handle resolving recursive/transitive dependencies for you. Some have support for vendoring dependencies, but not all do. In theory, you could have similar tooling for vendoring dependencies, but in practice that often isn't the case.

Updates mean you have to copy over all the code into your repo, which creates a large diff, and hope you aren't overwriting any local changes someone might have made.

It bloats your repo, both with the actual code, and the large diffs when you update it.

You have to manually track new versions, without something to tell you if new versions are available, or if your version has known security vulnerabilities.

If the dependency has it's own dependencies, you have to vendor those too recursively. And if multiple dependencies have the same transitive dependency, it is up to you to deduplicate them, and make sure you have a version compatible with all dependents.

Etc.

The irony is that it ended up more complicated than it neeeded to be because it was added on later and had to be backwards compatible. I think if go had had generics from the beginning it could have had a simpler design. And go wouldn't have needed magic functions like make and len that are kind of generic, but not in the same way as user-defined generic functions.

From what I can tell, you can get more total performance from intel/amd, but at the cost of more power draw, which besides needing more cooling also means shorter battery life.

And even on my desktop, where battery life doesn't matter, I wouldn't mind my CPU needing less cooling.

I say this as someone who will probably never own a mac.

I'm surprised it doesn't mention the shade would also reduce water lost to evaporation. Although you might need a lot of such solar panels to make a significant difference.

I think ASN.1, specifically DER, actually would have been better because it avoids the canonicalization problems saml has, as well as the general XML problems like XXE.

Both may be correct, but one is more prevalent. And in English, the article is always required.

The fact your health insurance is tied to your employer is the source of many of the problems.

There are so many problems with American healthcare that should have forced a real solution. But nothing much has happened.

That is a first party mechanical rewrite from one language to another. And I'm sure a significant part of the motivation was as a publicity stunt to increase demand for Anthropic's products. If anthropic hadn't acquired bun and had instead "vibe coded" their own replacement, do you think that would have become more popular than bun?

I think Kickstarter and similar are a great model for creating open source software. It's more problematic for maintaining it. It could work for some features and bugs, but it doesn't scale down super well (maybe have campaigns for a packet of related features and bugs?), and more importantly it isn't great to have security fixes dependent on a successful funding campaign.

Yes and no. It isn't about ownership of the project as a whole, but it is about ownership of your copy of the software.

There are occasionally more obvious tells as well, if you look closely. Some examples that I saw:

- A boat cast a shadow, but the mooring rope didn't

- A bench leg was out of perspective, and didn't touch the ground

- In a pile of logs,the ends were sharpened in an unnatural way[0]

- In several there seems to be an inconsistent contrast between something that looks more dirty, worn, weathered, etc. while the surroundings are more clean and smooth.

Some also feel off in a way that I can't really articulate.

[0]: I think the relationship to the prompt was interesting here, the prompt actually asked for a stack of wooden fence posts, but they were really thick for fence posts, and looked more like firewood with a sharpened point. Interestingly, the prompt included the phrase "without excessive sharpening" which I think meant increasing the sharpness of the image, but I wonder if the AI interpreted as referring to the sharpness of the fence posts.

Interstingly it is the same in german, you would say "Er ist Arzt" not "Er ist ein Arzt". Which makes me wonder why english uses an indefinite article there, since it doesn't seem to be either germanic or romantic in origin.

IDK, it seems reasonable that railway companies, some which had significant wealth and influence, used the decline of superstition as a superficial reason to get rid of laws that were inconvenient to them.

I think it is accurate to say that it is poorly understood by the general population, and probably the majority of operators using LLMs. Although I agree that is partly the fault of the companies making LLMs and related products.

But his family inheriting his ownership of the company contradicts his statements about estate taxes in that article. And passing the chairman position to his son may even be part of a plan to pass wealth to him that avoids estate taxes.

> All elements remain valid at all times. free does not release any memory and does not end any lifetime — it adds an index to a freelist. The slot is still a live, well-typed Item afterwards, and it still belongs to the pool, which still belongs to its owning scope. > > So there is nothing here to be unsafe. A reference to a freed-and-reused slot reads a different Item — a perfectly good one, just not the one you were thinking of.

This avoids the dreaded undefined behavior, but it can still be pretty bad. For example, accessing a record that has been freed and re-used could leak sensitive information from one user to another. Granted that kind of bug is possible with any memory safe language, but this pattern is probably more like to be used in goose than languages with automated memory management.

Say you wanted a map of some key to growable arrays (or maps), where the number of keys isn't known until runtime. It I understand correctly, you can't really do that because the number of growable stacks nees to be known at compile time.

Project valhalla allows more things to be on the stack but doesn't get rid of the heap.

It is what people in control of the US government seem to want. Which is not the same as what the American population wants (although there is a subset that wants it). As an American, it is absolutely not what I want.

> which is not necessarily free

Not just in terms of service costs, but in time and complexity. In many cases building out that complexity is complicated and difficult. And sometimes the functionality you need isn't supported in the regions you use.

Firefox is already using small local models for a few things, like tab grouping and link previews. I assume that this is for cases where a reasonably sized model isn't adequate.

They also have a lot more money than you do to spend on lawyers