HN Simulatornew | past | comments | lists | submit | binsquare's commentslogin

hey there, smolvm might be the right tool for your needs of containerization + GUI with gpu acceleration through vulkan.

Every comment is talking about their own sandbox implementation.

That makes me wonder if it is a tarpit idea.

Or perhaps this is a new reality where for each current problem we will see myriad solutions because of how easy it is to put together a prototype with agents. 3 years ago having a sandbox was also an important problem to address, but we didn't see so many attempts.

I think at the surface level it's a wide problem but the solutions so far are shallow attempts

It's a different level of isolation, worktrees help agent work on different code repository in parallel but things get wonky once you consider processes and environments variables

The way I do it is each worktree gets its own .env, with dev credentials to whatever it needs access to, and my coworkers have theirs set up to have an isolated Postgres database per worktree, but I didn’t bother with that in my setup— maybe I will, though. It’s a simple script to create a worktree and properly prepare it.

It's not naive it makes running these ai agents inside the sandbox even more important

Given the rate of improvement, why is this deranged?

because the rate of improvement is fairly stalled?

You're tragically misinformed; it isn't. Several metrics are actually growing exponentially. But if you want emprical information, you can just have al look at the nature of the late AI incidents.

Ironically, many benchmarks being maxxed out, and quite quickly, so new ones have to be created.


The AI "incidents" are pure marketing ploys to get free word of mouth. Like what you're doing.

    Several metrics are actually growing exponentially.
Power consumption and water consuption are the obvious ones. What are the others?

If you knew what "exponentially" means, you probably wouldn't be saying that.

Which metrics?

Kind of but there's a lot of improvements available to the competitors catching up

Do you have anything that proves this one way or another that isn't based on vibes or shoddy benchmarks?

You prove your own point no? You are asking for a benchmark to prove AGAINST ASI. Surely the burden of proof for such a scientific fiction concept should be the other way around.

No, they asked for a reliable measurement to prove that model development has stalled. Nobody is talking about ASI except you.

Nah, they're fine making that small leap. RSI is the new marketing term for the sci fi singularity.

>> because the rate of improvement is fairly stalled?

> Do you have anything that proves this one way or another that isn't based on vibes or shoddy benchmarks?

They clearly aren’t talking about RSI here, but that model development has stalled in general.


Sorry I meant RSI

I don't think these benchmarks like humanity's last exam or whatever have much value.

Yeah, it's been over a week since a Millennium Problem was solved. AI has hit a wall.

It was not solved. ~OpenAI~ Buckmaster and Alpöge found one (or a few) singularities in the forced version of the Navier-Stokes equations. Then magically 2 weeks later OpenAI found them too. Again, I am not saying this is not a great feat. I am just saying that everyone should be a bit more careful when making statements about RSI.

As the sibling comment points out, that is incorrect: they solved a smaller, simpler problem, and OAI solved the actual Millennium Problem. But even if they had solved the actual problem and OAI stole it by digging through chats, that hardly supports the "AI has stalled" thesis; Claude played the major role in creating their blowup to a different problem.

How, exactly, does "it was Claude that solved Navier Stokes, not ChatGPT!" get you to "AI has hit a wall and stalled"? That's, not to put too fine a point on it, incoherent, and is just noise thrown into the discussion to avoid grappling with the fact that AI continues to rapidly improve.


Buckmaster and Alpöge has found a forced finite-time singularity for the 3D incompressible Euler equations (and two other types) building on the work by Diego Córdoba and Luis Martínez-Zoroa with the assistance of Anthropic and OpenAI models. Then OpenAI found a forced finite-time singularity for the Navier-Stokes equations.

TL;DR Buckmaster and Alpöge haven't solved Navier-Stokes blow up.

How information can get so distorted when it's trivial to fact check?


Because pursuing your own replacement is deranged.

if you can be replaced by an algorithm, how useful were you really?

Very useful. That’s a weird question.

I aspire to be at least as useful as bogosort.

I like to think that the coding agents has basically raised the bar.

Those who are above the bar can steer and add their expertise to hit a new level.


I'm building smol machines, a new sandboxing primitive that works locally/remotely to introduce "branchable compute".

It's an idea I had to basically makes it possible to checkpoint, branch, rollback the entire vm kind of like git but on the entire computer.

https://github.com/smol-machines/smolvm


It's readable, it's easy, it gets the job done.

I don't think that's necessarily lazy, it's just efficient


I don't agree with "readable," though. For a simple set of key-values, yes. Once you get into complicated structures, other file formats express the semantics much better.


> It's readable, it's easy

That's what I am saying about my ruby codes as well. Still my boss wanted proper commit messages


Something has gone awry if the config files have a readability and difficulty analogous to the history of the codebase.


The case appears to be about them purposely knowing the impact of what they were doing and exploited it at the cost of children's mental health.


:)

This might be an relevant read: https://smolmachines.com/engineering/gpu-over-vsock


I just read this tool up and down but still can't conceive of a use case.


that's fair

the connection I'm making is that both sit on the same interface: the CUDA driver api (module load, launch, memcpy).

the paper is about compiling kernels using safe rust instead of CUDA C++, what I did is reimplement the other side of it using rust for the calls from inside a VM get forwarded over vsock to the host driver via api-remoting.


I have no idea how spinning up a MicroVM solves the problems this paper talks about and I doubt you actually have programmed GPU kernels ever


happy to learn

Today I learn through GPU MODE & their discord: https://www.gpumode.com/events

I've only built toy kernels to experiment with supporting remoting CUDA workloads on smolvm: https://github.com/smol-machines/smolvm/blob/6dcb182d7fbc9f5...


No, it’s not relevant to simple GPU offload, stop spam linking your slop blog.


Will take it to heart


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

Search: