You can have lots of buckets, but each one typically still contains many datasets.
Think of a team doing ML, for example. They work with data all day across many different tools, each reading some inputs from S3 and writing outputs to S3. They won't create a bucket for every output, that's not practical. So they write to a single bucket with outputs organized under prefixes.
Buckets are more of an administrative boundary (IAM, cost, replication) than a data organization unit. So even with more buckets, the dataset abstraction is still missing - there's no good native way to track what a prefix represents, who created it, whether it's still accessed, how much it costs, etc.
Latency matters if you want programmers to be able to work interactively. We multitask because LLMs are too slow.
That's happened before, with people submitting batch jobs in the mainframe era, people working on big projects that take an hour to compile, or people waiting for code reviews.
However, even if the LLMs become fast, the coding agent will likely bottleneck on running tools. You will need to keep your tests fast, too.
You don't need to put up a marketing page that tries to convince people to use your software. Instead (or as well), consider explaining all the reasons why someone should not use your software. More users, more problems.
They didn't make a clear argument in favor of that architecture and I'm not really convinced.
On exe.dev the agent (Shelley) runs in a Linux VM, which is the security boundary. All the conversations are saved to a sqlite database, and it knows how to read it, so you can refer to a previous conversation in the database. It's also handy for asking the AI to do random sysadmin stuff, since it can use sudo.
A downside is that there's nowhere in the VM where secrets are safe from possibly getting exfiltrated via an injection attack. But they have "integrations" where you can put secrets into an http proxy server instead of having them locally.
Also, you don't need to use AI at all. You can use the VM as a VM.
No matter how smart you think you get, I personally dont trust the models in an environment where they can read the secrets one way or another, in any high volume production environment.
Ideally Roblox would be able to rely on the platform to tell them whether the device is child-locked or not. It would be up to parents to make sure their kids only have access to devices with appropriate locks turned on. Parents could rely on vendors to make devices where it’s easy to set appropriate locks, and rely on stores not to sell unlocked devices to kids.
But we don’t live in that world.
Also, the are trying to prevent adults from pretending to be kids, which is much harder than preventing kids from accessing adult sites.
> Ideally Roblox would be able to rely on the platform to tell them whether the device is child-locked or not. It would be up to parents to make sure their kids only have access to devices with appropriate locks turned on
Yes, for people who live from selling tech, it is ideal when parents have to buy a separate device for everyone. But for people who do not live from selling tech, they prefer one or two tablets for the whole family, you know it is cheaper.
And being cheap is one of reasons for roblox popularity. Kids could have play it without buying anything (except that tablet).
It seems pretty reasonable to me that when you're not driving, the car is basically a taxi and the taxi service is to blame for any mistakes. The car manufacturer isn't just making cars anymore. It's providing a service.
Perhaps they could sell the car to a different taxi service, though?
Although most of the real-world data is probably boring, collecting more of it likely makes discovering rare edge cases more likely. But since they happen rarely, I imagine that after discovering them, they would then need to figure out how to simulate them.
The cost plan is a crude approximation of the actual query cost. Sometimes, the query planner makes a terrible guess. Your resident DBA won't appreciate being sometimes paged at 3 AM on a Sunday. A good strategy is to freeze the query plan once you have sufficient sample size of data in the involved tables.
Perhaps not every aspect of the query plan can be dictated, but both MySQL and Postgres (with pg_hint_plan) allow you to specify hints that enforce specify join order and scan behavior for the tables in your query, which is where the majority of "unexpected change in query plan" problems will arise. As for SQLite, I'm less familiar with the knobs available for query tuning, but a cursory Google tells me that join order is respected when using CROSS JOIN, and index usage can be forced with INDEXED BY/NOT INDEXED.
reply