Live data from Hacker News

Show HN: Smol machines – subsecond coldstart, portable virtual machines

github.com

121–130 of 162 posts

Re: Show HN: Smol machines – subsecond coldstart, portable virtual machines

#121

Hello, I'm building a replacement for docker containers with a virtual machine with the ergonomics of containers + subsecond start times. I worked in AWS previously in the container space + with firecracker. I realized the container is an unnecessary layer that slowed things down + firecracker was a technology designed for AWS org structure + usecase. So I ended up building a hybrid taking the best of containers with…

How is this different from lxd/lxc? How tied is this to kvm or could it work with other hypervisors like xcp-ng, VMware, or virtual box?

lxc/lxd are ~container managers, the kernel is still shared like docker containers. It runs on linux & needs to run in a linux virtual machine on macOS.

smolvm is a virtual machine with the ergonomics of containers like packaging and distributing, kernel is not shared. You'd run containers inside of smolvm.

Also, smolvm runs ontop of both kvm for linux and apple's hypervisor for macOS. So it's cross platform.

Re: Show HN: Smol machines – subsecond coldstart, portable virtual machines

#122

Earlier quoted context omitted.

uhh sort of different things. smol machines is a virtual machine that has properties and ergonomics of containers. It's not an ai project, it's designed to run any software inside. docker sandbox sounds like it's running ai stuff inside of a microvm. So if you need to use a virtual machine - use smol machines. If you need a to run coding agents, use smol machines still because agents are just software.

I think I see one new VM / sandbox thingie a week. > If you need a to run coding agents, use smol machines still because agents are just software. I get mixed signals from your argument

it was a tongue in cheek response :), completely fair take

Re: Show HN: Smol machines – subsecond coldstart, portable virtual machines

#123

Can .smolmachine be digitally signed and self authenticate when run? Similar to https://docs.sylabs.io/guides/main/user-guide/signNverify.ht...

probably, don't see why not based on cursory glance.

will look into it

Re: Show HN: Smol machines – subsecond coldstart, portable virtual machines

#126
post #83

Earlier quoted context omitted.

[flagged]

Hey 'software engineer', how much of the output of an LLM it's actually reproducible vs the one from a calculator or any programming language with the same input in different sessions?

A lot vs a human? I bet the LLM with the same prompt will write same code as before more often than I would (given I don’t remember what I wrote in the past).

Re: Show HN: Smol machines – subsecond coldstart, portable virtual machines

#127
This is a very cool project and I'm happy to see it getting traction here. I stumbled upon it when I was looking to build something similar and surveying the state of the art...then I realized you built _exactly_ what I wanted!

Thank you, great work!

Re: Show HN: Smol machines – subsecond coldstart, portable virtual machines

#128
post #83

Earlier quoted context omitted.

Hey 'software engineer', how much of the output of an LLM it's actually reproducible vs the one from a calculator or any programming language with the same input in different sessions?

Why are you so concerned about the LLM producing the exact same code across different sessions? Seems like a really weird thing to focus on. Why aren't you focused on things like security, maintainability, UI/UX, performance?

Agreed. It's not like humans can produce the same output given the same input for anything more than trivial inputs.

I'd argue that it's actually a benefit; I like that I can do several generations and compare them and pick the best result. HP, for example, used to do this with software teams, and that's how we got Rocky Mountain BASIC (AIUI the competing team was East Coast BASIC).

Re: Show HN: Smol machines – subsecond coldstart, portable virtual machines

#129

This looks very cool. Does the VM machinery still work if I run it in a bubblewrap? Can it talk to a GPU? Can you pipe into one? It would be cute if I could wget in machine 1 and send that result to offline machine 2 for processing.

Haven't tried with bubblewrap - but it should. Yes! GPU passthrough is being actively worked on and will land in next major release: https://github.com/smol-machines/smolvm/pull/96 Yea just tried piping, it works: ``` smolvm machine exec --name m1 -- wget -qO- https://example.com/data.csv \ | smolvm machine exec --name m2 -i -- python3 process.py ```

[dead]

Re: Show HN: Smol machines – subsecond coldstart, portable virtual machines

#130
post #39

Hello, I'm building a replacement for docker containers with a virtual machine with the ergonomics of containers + subsecond start times. I worked in AWS previously in the container space + with firecracker. I realized the container is an unnecessary layer that slowed things down + firecracker was a technology designed for AWS org structure + usecase. So I ended up building a hybrid taking the best of containers with…

What is the status of supporting live migration? That's the one feature of similar systems that always gets left out. I understand why: it's not a priority for "cloud native" workloads. The world, however, has work loads that are not cloud native, because that comes at a high cost, and it always will. So if you'd like a real value-add differentiator for your micro-VM platform (beyond what I believe you already have,)…

Somewhat related: I have a branch of Ganeti that has first-class ZFS support baked in, including using ZFS snapshot replication to do live migration without shared storage or CEPH: https://github.com/linsomniac/ganeti

Current status is I'm looking for more feedback. In a few weeks when Ubuntu 26.04 comes out I'm going to set up my dev/stg clusters at work with it, at the moment I've only tested it in a test cluster at home.

It works this way: It creates a snapshot of the zvol, and replicates it to the secondary machine. When that's done, it does another snapshot and does a "catch up" replication (the first replication could take hours on large volumes). Pause the VM, do a final snapshot+replication. Replicate the working RAM. Start up the VM on the new host.

Post reply on HN