e.g. in an installer:

  1. Download package
  2. Maybe 'prepare' as the user – this could be _entirely_ caller-driven (i.e. you didn't run any code, you just provided materials for the installer to unpack/place/prepare), or it could include some light/very restricted code execution
  3. Perform 'just one operation' such as 'copying things into place' (potentially with escalation/root)
  4. In step 3, the preparation from 2 resulted in the placement of something in binary position (that then runs), and/or overwriting of important files (if something placed in step 2 was used as a target)

To be clear, I'm not one of the people who believes that software is going away or that UX is going away. I think those are both still very important. But I do think that a lot of legacy software can be replaced, and then we'll end up with a new level of software in the longer term.

Of course it's trivially NOT true that you can defend against all exploits by making your system sufficiently compact and clean, but you can certainly have a big impact on the exploitable surface area.

I think it's a bit bizarre that it's implicitly assumed that all codebases are broken enough, that if you were to attack them sufficiently, you'll eventually find endlessly more issues.

Another analogy here is to fuzzing. A fuzzer can walk through all sorts of states of a program, but when it hits a password, it can't really push past that because it needs to search a space that is impossibly huge.

It's all well and good to try to exploit a program, but (as an example) if that program _robustly and very simply_ (the hard part!) says... that it only accepts messages from the network that are signed before it does ANYTHING else, you're going to have a hard time getting it to accept unsigned messages.

Admittedly, a lot of today's surfaces and software were built in a world where you could get away with a lot more laziness compared to this. But I could imagine, for example, a state of the world in which we're much more intentional about what we accept and even bring _into_ our threat environment. Similarly to the shift from network to endpoint security. There are for sure, uh, million systems right now with a threat model wildly larger than it needs to be.

Whoever is writing this seems to have absolutely no clue how AI works.

Given that Google is clear about the fact that they don't train on your emails, the worst that could be happening here is that... within the scope of your account they maintain an extra index or two, or... additional synthesized data, in addition to the many indexes that they already maintain over your email.

Finding a little bit tricky to evaluate because the harness is unfortunately very, very bad (e.g. search is awful). Can't wait to try this in some real external services where we can see how it performs for real.

Definitely getting ordinary high-quality results, overall. But hard to test agentic behavior and hard to test prose quality, even, when just working off of the default chat interface.

One thing that stands out is that _for_ the quality it feels very, very fast. Perhaps it's just only very lightly loaded right now, but irrespective it's lovely to feel.

I'm quite impressed with the tone overall. It definitely feels much more like Opus than it does, like, GPT or Grok in the sense that the style is conversational, natural and enjoyable.

I'm looking forward. Things are moving very quickly. As I said above, I'm afraid of us diverging into another Apple situation in the future. If I suggest that they should be looked at and thought about, it's not for today, it's for tomorrow. If divergence continues. Because as with everything in AI, it might hit us a lot faster than people expect. Hell, given their approach to morality, I suspect that Anthropic folks have already thought deeply about these sorts of concerns. That's why it's actually a lot more in character for them to be doing this not due to self-preferencing, but due to unaffordability, which - if you look at my first post - is what I said seems to be happening.

Suffice to say that I have a graveyard of things that I think phones could have been, where unfortunately we've ended up with these - as you say - addicting consumerist messes.

Gonna stop here so I don't flood the thread. We're getting very off topic.

We have a similar situation in mobile where Apple may not be considered a monopoly, but people have walked around for a decade with a supercomputer in their pocket that is wildly underused.

Things have gotten faster; things are different than they were decades ago when a lot of this was devised.

The reality of the matter is that some of us just want to see innovation actually happen apace, and not see 5, 10, or 30 years of slowdown while we litigate whether or not such a company is holding all the cards, while everyone is collectively waiting at the spigot for a company to get its shit together because we're not allowed to fix the situation.

For what it's worth, I'm hopeful that the other model providers will catch up and put us in a situation where this conversation is irrelevant.

What I'm afraid of is a situation where we see continued divergence, and we end up with another Apple situation.

Honestly, this just looks like what Dylan of SemiAnalysis suggested on Dwarkesh – that they've massively under-provisioned capacity / under-spent on infrastructure.

That would honestly be a comforting answer if true, because I would gladly take 'we can't afford to do this right now' over 'we are self-preferencing, and the FTC should really take a look at us, even if we're technically not a monopoly right now, since we're the only strongly-instruction-following model in town and we clearly know it'.

> current: 2.1.88 · latest: 2.1.87

Which makes me think they pulled it - although it still shows up as 2.1.88 on npmjs for now (cached?).

That said, I would love to see a solution in my favorite class of solution: where library authors can use and benefit from this, but the average user doesn't have to notice.

I tend to think that the non-existential Scala system was _so close_, and that if you _slightly_ tweaked the scoping rules around it, you could have something great.

For example, if - as a user - I could use `.serialize(...)` from some library and it used _their_ scoped traits by default, but if I _explicitly_ (named) imported some trait(s) on my side, I could substitute my own, that'd work great.

You'd likely want to pair it with some way of e.g. allowing a per-crate prelude of explicit imports that you can ::* import within the crate to override many things at once, but... I think that with the right tweaks, you could say 'this library uses serde by default, but I can provide my own Serializer trait instead... and perhaps, if I turn off the serde Cargo feature, even their default scoped trait disappears'.

With AI this pace difference is even more noticeable.

I do think that the way that Scala approaches this by using imports historically was quite interesting. Using a use statement to bring a trait definition into scope isn't discussed in any of these proposals I think?

In a situation where you're building, I find the orphan rule frustrating because you can be stuck in a situation where you are unable to help yourself without forking half of the crates in the ecosystem.

Looking for improvements upstream, even with the absolute best solutions for option 1, has the fundamental downside that you can't unstick yourself.

The rest of us were able to implement things like push a long time ago, but because Claude Code and Codex stubbed those things out, we couldn't really use them for 'most agent users'.

In fairness to OpenAI, they have been generous in allowing for example OpenCode to sign in with your ChatGPT subscription – so you _could_ build a more powerful agent (which OpenCode is... not) – but unfortunately GPTs' instruction following just isn't up to snuff yet. Hopefully they pre-train something amazing this year!

It's lovely to see the polite and respectful back and forth in this comment thread where the Iroh folks are talking about deciding to fork. :)