ozkatz

8 ms·

1.
by ozkatz 2mo ago
costs? 1PB of EBS volumes on sc1-class HDD is roughly $15k/month. Let's say you need at least 2 copies of each byte for cross-AZ availability and durability, that's 30k per PB for JUST the drives. These disks also need compu
2.
Basha256.sh – Pure Bash 3.2 implementation of sha256(gist.github.com)
6 points by ozkatz 3mo ago|0 comments
3.
by ozkatz 3mo ago
Curious if you’ve had a chance to try lakeFS? It was designed with large-scale environments in mind. I’m aware of several deployments managing hundreds of petabytes of data and billions of objects, which is why lakeFS does not use Git’s Mer
4.
by ozkatz 4mo ago
That’s the current RBAC implementation: agents by default can make no API calls. the only way for them to contact the outside world is through a forward proxy configured in the sandbox. that proxy only allows making requests to destinations
5.
by ozkatz 4mo ago
Appreciate the honest feedback. I agree there's a lot to improve there.
6.
by ozkatz 4mo ago
very very fast: proportional to the count of objects modified, but not their size. Every commit represents a snapshot - an immutable listing of objects that represents the repository. reverting is essentially applying the inverse of the dif
7.
by ozkatz 4mo ago
S3 offers versioning at the single file level. Imagine an agent dropping a directory with 1m images in it. just figuring out what happened and what got dropped, restoring it one by one, etc. - doable, but ergonomics are a bit lacking.
8.
by ozkatz 4mo ago
Regarding pricing - that's indeed a great question and we don't have an answer yet. It will very likely be based on consumption and should be competitive to similar solutions. Atomic commits are based on snapshotting done by lakeF
9.
by ozkatz 4mo ago
It uses lakeFS under the hood, so the unit of conflict would be a single file (object, under the hood). Resolving conflicts requires "picking" a winning side, or rerunning a conflicting job. Would you see a use case for merging ch
10.
by ozkatz 4mo ago
It provides a filesystem abstraction, which agents are really good at interacting with. Because it's just a POSIX filesystem - you can put a sqlite database directly on it and get those same transactional capabilities for that too.
11.
by ozkatz 4mo ago
it should absolutely scale to that. The filesystem is backed by lakeFS, where every sandbox automatically branches out, and mounts that branch. so you get isolation from lakeFS and the scale of an underlying object store (S3, in Tilde).
12.
by ozkatz 4mo ago
If that database is stored on the transactional filesystem available to the sandboxes, yes! Instead of backing up, it utilizes an efficient snapshot mechanism (lakeFS under the hood).
13.
by ozkatz 4mo ago
Part of the appeal (subjective, I know) of versioning is stuff like human-in-the-loop approvals. Think of a pull request: a change is requested by an agent, a human approves, changes get merged atomically. Even if other changes were applied
14.
by ozkatz 4mo ago
Hey! It doesn't necessarily have to be "data heavy", but any form of state (from code to binary files) that an agent might use for automation. Agents are really good at interacting with files and directories (text in, text ou
15.
by ozkatz 4mo ago
Oh VMS, How I miss thee
16.
by ozkatz 4mo ago
In a perfect world, every system and external API would expose a standardized interface for versioning its own immutable state, so you'd be able to rollback and time travel across multiple such systems. Not sure what else we can do in
17.
by ozkatz 4mo ago
oz dot katz at treeverse.io would be best. ICP is SMB/mid-sized ISVs.
18.
by ozkatz 4mo ago
not at the moment. You can use lakeFS directly with Fuse-Mount to do something similar with your own compute.
19.
by ozkatz 4mo ago
Currently a static 2 cores and 4GB RAM, no GPU. Will be configurable soon!
20.
by ozkatz 4mo ago
Exactly that!
21.
by ozkatz 4mo ago
Much appreciated! and good luck with your project
22.
by ozkatz 4mo ago
https://www.youtube.com/watch?v=fDR8tmes020 - a 2 minute hands-on demo!
23.
by ozkatz 4mo ago
indeed - this only applies to the filesystem managed by tilde. Existing version control is fine if you're only managing code. For data (Think large parquet files, millions json files, images and videos, etc), git doesn't scale wel
24.
by ozkatz 4mo ago
The repository itself get fuse-mounted into the running sandbox - no skill or MCP required to interact with data: an agent can simply `cat <file>` and use whatever tools they are already good at using.
25.
by ozkatz 4mo ago
Sure! and it's not either/or - you can either import code from GitHub (or any other git remote) into a Tilde repository, or simply clone a repository directly inside the sandbox if you want full control over the git commit/br
26.
by ozkatz 4mo ago
That's fair. What makes this unique is the versioned, composable filesystem. It's built on top of lakeFS ( https://github.com/treeverse/lakeFS ) so it scales really well, unlike other solutions that try and do
27.
by ozkatz 4mo ago
the repo acts as a source of truth for agents. think memory, data & code. If an agent decides to change any of those, version control allows: 1. to have a human in the loop to approve certain changes 2. rollback changes that end up bein
28.
by ozkatz 4mo ago
Fair enough - the underlying technology is indeed open source ( https://github.com/treeverse/lakeFS ) - the service provides the hosting and tooling to make it easy for consumption by agents.
29.
by ozkatz 4mo ago
Good question - the filesystem is Fuse-mounted into the sandbox, not copied into it. This way agents can modify data directly simply by interacting with the "local" files.
30.
Show HN: Tilde.run – Agent sandbox with a transactional, versioned filesystem(tilde.run)
205 points by ozkatz 4mo ago|133 comments

More ›