I think you’re referring to the short term impacts of AI and he’s thinking more long-term.
Also, AI, even short term, is going to make some people and some countries extremely wealthy, so maybe this isn’t such a bad time to be thinking about those who are still extremely poor and who won’t benefit.
It's entirely plausible Google won't tell Railway without an NDA to prevent them disclosing exactly what set it all off.
The bigger point though is Google really need to flag any business account as not subject to these suspensions until checked into by several humans. Back when I had a team that used a lot of App Engine they would even call us when we caused all their pagers to go off, and then conspire to keep the lights on while things got fixed. It's sad they have ended up like this.
> It's entirely plausible Google won't tell Railway without an NDA to prevent them disclosing exactly what set it all off.
That case is called:
> or Railway can tell us that Google is refusing to tell them.
I'm not paying you (which let's face it, that's what an NDA is) just to find out why you messed up about as severely as one can imagine. In theory, there was a contract here: $ for cloud services, and the rug got pulled. One should get a very clear, and very apologetic explanation as to why, with no strings attached, or one should be voting with their wallet.
Now, whether Railway will do any of that, who knows.
"We take full responsibility for the architectural decisions that allowed a single upstream provider action to cascade into a platform-wide outage, and detail below what happened, how we recovered, and the changes we are making to prevent this from happening again."
My guess is they will be switching away from Google Cloud. Because anything else would be nuts.
I know hating GCP is hip, but why do only a minority entertains the possibility that Railway did really something off to trigger some alarms?
The calibration of the alarms might be off, and that's acceptable, but in the end if something can be held wrong, somebody will hold it wrong.
I did the same thing in the past, albeit in a much smaller scale. There's no shame in being wrong and admitting as long as it results in progress, so this stance of "we do nothing wrong" from both parties is getting a bit old now.
Of course it doesn’t work this way but why shouldn’t it? It doesn’t because Google is a massive company and could kill dozens of Railways before they notice an issue to their bottom line. However in a world where companies care I’d expect them to make a statement.
I took this a different way which was that to google railway is their customer and out of a variety of professional and security considerations want the communications to come from their customer and not them.
I think there’s been far too many Google/GCP ‘suspensions with no human in the loop’ that Google does need to put out a statement about their practices.
Administration officials will insist that this will be bipartisan and just for national security.
Trump will then just come out and say it: that they won't authorize models that provide "fake news" such as him not winning the election by the most votes ever.
There will be a big fuss as people and media point to this as the smoking gun, but then it will turn out that American voters just don't care.
I guess we could learn to appreciate Mistral sooner than expected.
This sounds great, except for one thing: you can scale your compute (CPU & RAM) as needed but your storage appears to scale with it.
So, if I use a "16 vCPUs, 32GB RAM, 400GB SSD" machine for a period of intense compute, and then want to scale that down to "2 vCPUs, 4GB RAM", most of my storage disappears?
That rather ruins the potential of the advertised scalability.
Joplin looks great, and is open source, but it appears to have one problem: the primary data store is SQLite, not files, and in this AI infected era having plain text files on the local filesystem is really important.
So if I am correct the "cloud drive as the storage" option is syncing with a the local SQLite db and to get local files one would need to be syncing the local db with both the cloud drive and the local filesystem.
With Obsidian I sync from local files direct to a cloud drive.
? You say 'yes' but you seem to be answering a different question. Docker desktop only makes me choose a max ram - it dynamically scales RAM usage. I don't need fully automatic like that, but the ability to vertically scale RAM for an existing instance is really important, particularly given the cost of RAM these days.
Fly.io sprites is the most similar to us of the bunch. They do hardware virtualization as well, have comparable start times and are full Linux. What we call snapshots they call checkpoints.
The big pros of Sprites over us is their advanced networking stack and the Fly.io ecosystem. The big cons are that Sprites are incredibly bare bones — they don't have any templating utilities. I've also heard that Sprites sometimes become unavailable for extended periods of time.
The big pros of Freestyle over Sprites is fork, advanced templating, and IMO a better debugging experience because of our structure.
Thanks for the thoughtful response. I'm predominantly a self-hoster, but I think your product makes a lot of sense for a wide variety of users and businesses. I'm excited to try out freestyle!
Freestyle/other providers will likely provide better debugging experience but thats something you can probably get past for a lot of workloads.
The time when you/anyone should think about Freestyle/anyone is when the load spikes/the need to create hundreds of VMs in short spikes shows up, or when you're looking for some of the more complex feature sets any given provider has built out (forks, GPUs, network boundaries, etc).
I also highly recommend self hosting anything you do outside of your normal VPC. Sandboxes are the biggest possible attack surface and it is a feature of us that we're not in your cloud; If we mess up security your app is still fine.
Obviously your service/approach is different than exe, more like sprites but like you said more targeted/opinionated to AI coding/sandboxing tasks it looks like. Interesting space for sure!
I built yoloAI, which is a single go binary that runs anywhere on mac or linux, sandboxing your agents in disposable containers or VMs, nested or not.
Your agent never has access to your secrets or even your workdir (only a copy, and only what you specify), and you pull the changes back with a diff/apply workflow, reviewing any changes before they land. You also control network access.
Still WIP, but the core works — three rootfs tiers (minimal Ubuntu, headless Chromium with CDP, Docker-in-VM), OCI image support (pull any Docker image), automatic thermal management (idle VMs pause then snapshot to disk, wake transparently on next API call), per-user bridge networking with L2 isolation, named checkpoints, persistent volumes, and preview URLs with auto-wake.
Fair warning: the website is too technical and the docs are mostly AI-generated, both being actively reworked. But I've been running it daily on a Hetzner server for my AI agents' browser automation, and deploy previews.
I'd love any feedback if you want to go ahead and try it yourself
We do auto suspend depending on your configured timeout. We'll pause your VM and when you come back the processes will be in the exact same state as when you left.
But your pricing page suggests that that is not available without a subscription: in the on-demand pricing section "persistent Snapshots" and "Persistent VM's" have an 'x'.
We do not allow long term persistence for the free tier.
This is purely a defense mechanism, I don't want to guarantee storing the data of an entire VM forever for non paying users. We have persistence options for them like Sticky persistence but it doesn't come with the reliability of long term persistence storage.
Also, AI, even short term, is going to make some people and some countries extremely wealthy, so maybe this isn’t such a bad time to be thinking about those who are still extremely poor and who won’t benefit.
reply