Hacker Newsnew | past | comments | ask | show | jobs | submit | sylvinus's commentslogin

I did the same for a scanner that was missing an driver for latest macOS! https://github.com/sylvinus/freethescan

Are we all posting our agent VM containers ? :) https://github.com/sylvinus/agent-vm


We're basically at the point where people can build their own "X", with "X" being internal tooling.


Yes, but for certain things like sandboxing I hope we can converge on a handful robust, well-tested/audited solutions...


What is different about yours?


Why not try to define a strict subset of the current specs, that would target ease of implementation & graceful degradation? I'd rather have many different clients compatible with a "web-lite" spec that is enough to navigate on 95% of websites, which would have an incentive to officially support that subset if it becomes popular enough.


Thanks for the write up. Always interesting to see how very senior developers interact with AI these days.

@antirez: Introducing a regex feature that late into the project for a seemingly unrelated feature feels a bit weird? Can you explain more your rationale on that? thanks!


Once I realized arrays were a great fit for text files, many use cases I could conceive were always limited by the fact we need to grep on files. So I thought: what is the AROP equivalent for files? ARGREP. Then I made sure to add both fast, exact and regexp matching so that depending on the use case the best tool could be used. I then discovered that for many OR-ed strings regexps could be the faster way if we'll optimized. And then I specialized TRE a bit.


Are there other existing Redis data types and features that might benefit from integrating TRE?


KEYS comes immediately to mind :)


I'm using this as my main way to run Claude & others, it's just a shell wrapper but it provides a lot of niceties and a pretty good developer experience in a single command line. Curious to have feedbacks on it!


Love Oxide and what they're building, but I'm not sure raising even more VC money is the way to build a generational company. Quite the opposite? With money you don't need, you're trading faster growth for more dependencies on third parties that will seek a ROI eventually?


Hardware businesses are capital intensive. They need the money.

They also need to grow and iterate faster. Their software stack is great, but their hardware is quite dated in a fast moving industry. This limits them to domains that value their software and security but don’t need the latest hardware for performance and aren’t necessarily concerned with performance per dollar, which is a small market.


They state:

> ...it's not uncommon for us to be asked directly: "How do I know you won’t be bought?"

Raising ~infinite runway from investors who are already known quantities signals that you can safely buy into their product knowing they're not getting snapped up by $megacorp anytime soon. That's where the faster growth comes from--customers who feel secure in the knowledge that the company isn't going anywhere.


If they didn't buy all the RAM they needed for their near future before the prices spiked, they probably need most of the $200M just for that.


Not necessarily. Supply chains and vendor management into scale is very difficult and very very expensive, I think we prob spend north of $200MM to get to $150MM ARR, but the economics started to shake out thereafter based on CAGR. To do this without owning 0% of the company while still recognizing needing a lot of cash in the system to keep everything lubricated, (for example Michael Dell might be fine personally extending a $500MM line of credit to the business, if the business has $50MM in venture funds on some predictable growth rate) - basically you use true risk capital via the smallest amount of equity you can give to de-risk downstream capital requirements. I don't know anything about how Oxide is growing their business so this could be total nonsense in their case, but it's how we built a generational business (digitalocean)!


There is a gold-rush going on. It needs plenty of compute besides GPU's, this is definitely the time to scale as quickly as possible.


I don't think any Oxide racks come with GPU's at present, and the power density of modern GPU-centric AI compute is on a rather unprecedented level. Oxide racks are very well cooled but are no match for the racks in an AI datacenter that's literally burning a full gigawatt of power.


> needs plenty of compute besides GPU's

Databases, K/V stores, crawlers, services, etc all still necessary besides GPU's. The closer to GPU's the better and if you have GPU's in your own DC.


Yeah, they're not going to go up against the nVidia NVL72, NVL144 or AMDs UAL systems

https://www.nvidia.com/en-us/data-center/gb200-nvl72/ https://www.amd.com/en/blogs/2025/amd-delivering-open-rack-s...


As companies grow, their capital needs actually increase, even if they are profitable.

We can hope that this is the case for Oxide, though I don’t expect they are reliably profitable yet.


Not sure this is necessarily for faster growth. Riding out the AI bubble's rise and/or its bursting will each present a lot of need for capital and a lot of barriers to raising it. They're not an AI company but they obviously have tons of exposure across the stack to these markets. They may simply be making the call that this is a better time to be raising money than the years to come.


This is the way to go! On my side I've build a very small `claude-vm` wrapper to run each instance in a VM with Lima: https://github.com/sylvinus/agent-vm


I did similar with incus!

I'm convinced that VMs are the right primitive here, for now. Being able to give an agent full root and passing it in just the stuff you want it to have is super easy and it's extremely foolproof. I have my assistants free to install software, run docker, build their own nested VMs, etc. knowing that the boundary is sound and that no capabilities will ever be sacrificed.

I might switch to LXC to reduce the weight somewhat (easy with incus) but this requires providing a more limited set of tools (i.e. podman instead of docker).

bwrap is great, but you're stuck with the limitations of the environment, which depending on what you're doing may neuter the agent.



Yup, DINUM does support the Matrix Foundation, which is appreciated in terms of helping keeping Matrix itself alive and independent.

However, this doesn't help support the folks improving & maintaining Element (either its clients or servers), which is the actual upstream product that Tchap is dependent on. Just like donating to the W3C doesn't help improve Firefox, if you were operationally dependent on a Firefox fork.


I think it's a very convenient way of framing it and nicely occults how the stewardship at Matrix significantly changed since they chose it for Tchap.


We’re not trying to obscure anything: we very well know that Tchap’s adoption of Matrix and their current support (Foundation membership, code contributions to Element Web, evangelisation to other countries, etc.) are key to our success, and we are very grateful for it.

We’re just stating facts: DINUM stopped funding upstream development at Element in 2022/2023 when their post-COVID funding evaporated, and this then directly contributed to the licensing changes at Element at the end of 2023 (https://element.io/blog/element-to-adopt-agplv3/) as we tried to figure out a way to survive (which, thankfully, worked).

But we also know that the Tchap team is very budget constrained internally themselves to keep it running, despite the growing criticality and huge visibility of the service, and are trying to find ways to fix the situation at every level.

This is not a challenge limited to France: the question of how to support the upstream when heavily using open source was one of the top topics of last week’s Open Source Week in Brussels, involving folks at every level in European government.


Exactly, we do have private forges we build and deploy from.


ClickHouse has native support for sampling https://clickhouse.com/docs/sql-reference/statements/select/...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: