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

Without even touching this "cheese is not as good as you find in Europe", if you had deep-dish pizza you should know that's tourist pizza. I grew up with cracker-thin pizza from Fox's, cut into squares; the real Chicago pizza.

Someone really needs to do a numerical study and food history on deep dish. There is a giordanos (one of the big local deep dish chains) around the corner from my house and I would estimate no more than 1 in 3 pizzas coming out of that place is deep dish.

And I can’t remember a single time I’ve been with a group of Chicagoans and they’ve decided to order deep dish with the exception after drinking at Pequods.

As someone who was raised elsewhere but has lived in Chicago a long time I’m fascinated how deep dish became externally associated with Chicago while internally it’s so poorly received. It would be like going to Southern California and finding out no one eats fish tacos.

Conversely Chicago hot dogs and (until recently) Italian beef are legitimately different and better in Chicago, widely acclaimed locally, but largely ignored outside of the city. So weird.


Glyphosate, not "glyphosates". Roundup. It's used everywhere. It's an extremely widely used herbicide.

Yes, but almost the entire cluster of the NB cases are around Caraquet NB, which is completely surrounded by softwood plantations, and this has been a case they have been fighting for years.

Additionally, Industrial scale lumber harvesting uses magnitudes more Glyphosate than a home gardener or your local HOA.


I don't doubt something specific is going on there, but it's unlikely it's Roundup, since every suburb in North America is carpet-bombed with the stuff.

While other areas might receive high doses, I'd wonder if there is a link here to the amount of salmon and deer the people there eat, that itself consumed exposed plants or lived in exposed water, compared to the rest of the country? Or the impacts on aquifers?

Also it's "glyphosate", right? Not "glyphosates". It's not like some weird class of industrial chemicals; it's a specific herbicide, used since 1975, more commonly known as Roundup, notable because Monsanto owns patents on genetically-modified crops that are resistant to it.

They're probably referring to the different salts (isopropylamine (IPA), potassium, or diammonium) which can greatly affect absorption and effectiveness

Roundup is IPA, Touchdown is DAM. Both extremely common.

Yeah both glyphosate.

But the doctor in the OP explicitly pointed out that they had increased levels of glyphosate in their blood:

> He also warned that some patients' blood work showed elevated levels for compounds found in herbicides such as glyphosate, and said more testing should be done to rule out environmental toxins, including the neurotoxin BMAA, which is produced by blue-green algae.

https://www.cbc.ca/news/canada/new-brunswick/new-brunswick-n...

Just because glyphosate is everywhere doesn't mean it can't be concentrated in a particular place.

To be clear I'm not taking a stand for the glyphosate argument at all. I just don't think your line of reasoning is a fair counterargument in this case


They would need to have been ingesting or breathing the glyphosate pretty recent to their blood draw. It doesn't absorb easily into skin, and it passes through you quickly. And if you do get a concentrated dose, you get nausea, vomiting, respiratory issues (if inhaled). It's a weird thing to be the culprit, since it's hard to get, and doesn't cause many issues. And it's weird to mention at all, since he says only "a few people" had elevated levels of it.

"Melissa Nicholson said her 59-year-old mother, who has suffered for four years with a neurological disorder, received test results indicating she had levels of glyphosate in her body that were 47 times higher than the acceptable level."

This is bizarre. Either she lives right next to a farm that's spraying it, and she's getting it blown into an open window in her house where she's breathing it, and then immediately went for a blood test... or she's somehow ingesting it in/around her house (like from a bottle of Roundup that keeps getting splashed on something she's ingesting).


Without getting into Kurt's galaxy-brained take on the declining importance of "production" in a post-AI world, I'd say: yeah, run prod apps on Fly Machines, for more predictable performance, scaling, and pricing. Do exploratory computing --- "figuring out what you'd run on a Fly Machine" --- in Sprites.

One of the coolest things about this is that Claude in his environment --- without him asking to --- knows how to drive Sprites. If you ask it to run a server, it will register it as a local service so it survives reboots. Without you asking to, it'll checkpoint when it makes big changes. I think this is kind of freaky.

I can't say enough how, if you're using this like Kurt and Chris have been, you have like, a dozen sleeping Sprites in your Sprite list. If you're not doing anything with them, they're not really costing you anything. When you want to do something new, there's no point figuring out which of your existing Sprites to do it on. Just make a new one.

Always having a sane place to run anything I happen to be doing, without making any decisions, it's a weird feeling.


Oh no, as someone who hoards browser tabs, I fear where this will lead me...

That’s a great demo! For curious mere mortals, are all those custom instructions that make Claude know how to use it public? I’d like to learn how to drive it myself too, just out of curiosity!

Check out the skills that are installed on the box by default

Do we pay a storage penalty for inactive sprites?

You pay for the storage you actually use (not the raw capacity). If you build, like, a relatively complicated Python web service with some assets, and all the build deps that go with that, you might be on the hook for, like, 90 cents in a month.

Right that makes sense thank you

More complicated than that, but with respect to Sprites --- this is a totally new stack.

it seems like when you snapshot, you snapshot memory AND the filesystem (immutable ftw), that's pretty awesome

i am dying to know: firecracker still? I know you have an upcoming post abt it, but i'm incredibly impatient when it comes to fool new infra


Alright nerd-snipe snooping research post happning now!

Seems like they are using JuiceFS under the hood, with an overlay root for your CoW semantics. JuiceFS gives them instant clone (because they're not cloning the whole rootfs), while the chnages to the overlay are done as an overlayfs and probably synced back to S3 via a custom block device they have mounted into firecracker.

You can also see they are using juicefs it for the "policy" directly (which I'm assuming is the network policy functionality). iirc juicefs has support for block devices too, so maybe they are using that to back the rootfs overlay.

One concerning thing is the `/var/lib/docker` mount - i ran this in an ubuntu container, did they... attach it? Maybe that's a coincidence, but docker is not installed on the sprite by default. (the terminal is also super busted when used through an ubuntu container)

https://pastebin.com/raw/kt6q9fuA (edit: moved terminal output to pastebin because it was so ugly here)

I played with a similar stack recently, my guess is they are: 1. making some base vm, snapshotting it 2. when you create a vm, they just restore a copy and push metadata to it (probably via one of the mounts) 3. any changes that you make to the rootfs are stored on the juicefs block device (the overlay), which is relatively minimal compared to the base os. JucieFS also supports snapshotting, so that's probably how they support memory + filesystem snapshot and restore so quick

interestingly, seems they provision maybe a max disk size of 100GB for total checkpoints?

```

NAME TYPE SIZE FSTYPE MOUNTPOINTS

loop0 loop 100G /.sprite/checkpoints/active

```

fuse is definitely being used within the VMM, i can see a fuse mount and id being assigned. They're probably using juicefs directly for the policy mount because that doesn't need to be local nvme-cached, just consistent. The local-nvme -> s3 write-through runs on the hypervisor through a custom block device they attach to the firecracker vmm. This might just be the --cache-dir + --writeback cache option in juicefs. Wild guess is just 1 file per block.

guessing the "s3" here is tigris, since fly.io seems to have a relatoinship with them, and that probably keeps latency down for the filesystem


i think firecracker, just snooping around a sprite i see a lot of virtio-mmio, which afaik CHV would be using PCI in those instances

You can do this now without an MCP, by auth'ing the `sprite` command inside of a Sprite and telling Claude to go document it for you. You can do things like "make me three versions of this feature on three different Sprites so I can compare them". It is spooky how easy it is to teach agents this stuff.

If you have an LXD setup working for your own workloads that's working well for you, that's awesome. Why would we want to talk you out of that? Fundamentally you're getting at the difference between "elastic" cloud services and personal infrastructure. Personal infra is great!

If it helps: Jerome has been working for a couple months on a local, open-source Rust version of Sprites, so you can use the same DX with your own infrastructure. We just think this is the right "shape" for modern sandboxes, wherever you actually run them.


Yes that would be awesome!

Exe.dev is very cool.

It's coming, and it'll make sense how and why next week when I run the "how this shit works" post.

I actually pushed to include it in the launch release. You'd have to ask Kurt why he didn't, but I think the idea is just to get more real-world usage first.


Do you expect that to replace git worktree for getting Claude to work on multiple things in parallel? That was something I was curious about watching the demo video.

Can’t edit, but adding I noticed that there’s a limit of 3 sprites running concurrently for pay as you go, so that’s probably not a realistic day-to-day workflow.

> It's coming, and it'll make sense how and why next week when I run the "how this shit works" post.

Thanks! Also looking forward to reading the post :)

> the idea is just to get more real-world usage first

My particular wish notwithstanding, I agree with this.


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

Search: