Get out of here with this nonsense. We tell people when we’re a bad option all the time. Do you really think we have a desire (or time) to punish somebody for doing the same?

Also, here’s the long forgotten badge, still with 3 people… https://community.fly.io/badges/107/aeronaut

> Do you really think we have a desire (or time) to punish somebody for doing the same?

idk man, there's these awfully convenient disappearing forum threads too. The benefit of the doubt is starting to expire.

I see you're a co-founder, so presumably you have some sway on priorities and skin in the game. I think you should take the reputational damage you're accruing here much more seriously than you apparently are. A few more incidents like this and it won't just be you telling people you're a bad option.

* edited to tone down the forum thread disappearance angle. FWIW I do believe that it likely wasn't deliberate. My main point was that these things add up and "of course we wouldn't do that!" starts to ring a little hollow the 10th time you hear it...

> you've just been caught hiding inconvenient forum threads too

FWIW, I do believe them when they say this wasn't intentional. Considering how the Internet operates, they would be incredibly stupid to do something like that on purpose.

That being said, the way the entire affair was handled certainly leaves a lot to be desired.

I actually believe them on that too, FWIW. This time. It's just too dumb. I hope, for their sake, it's the truth.

I was really just trying to point out that this kind of good faith benefit-of-the-doubt has a limit, and fear of reaching that limit should be keeping people at fly up at night a lot more than it apparently is. I don't know how many colossal public fuckups a company can endure before its reputation is permanently ruined, but it's definitely not infinite.

Why are you acting so hostile? If you don't like that the community is dunking on you, then maybe posting on Hacker News isn't for you.

Why is anyone on HN "dunking" on Fly.IO of all companies?

Michael - Don't take the bait.

As someone who has zero affiliation with Fly.IO other than a few PR's to their OSS(I don't even know Michael), I greatly appreciate the contributions they have given back to the community.

There are a lot of great hosting companies. Fly.IO stands out due to their revolutionary architecture and contributions back to the OSS community. I wish more companies operated like this.

It's understandable some are upset about an outage. But Fly is doing really interesting and game-changing things, not copying a traditional vmware, cpanel or k8s route.

Just as a reminder to what this company has offered back to everyone.

SQLite: Ben Johnson's OSS work around SQLite stands out. Fly.IO and his work have really made sqlite a contender. - https://fly.io/blog/all-in-on-sqlite-litestream/ - https://fly.io/blog/introducing-litefs/ - https://github.com/superfly/litefs - https://github.com/benbjohnson/litestream - https://fly.io/blog/sqlite-internals-wal/ - https://fly.io/blog/wal-mode-in-litefs/

Who really considered sqlite as a production option before Fly and Ben? Not me.

Firecracker: Firecracker is amazing, but difficult to debug when something bad happens. There aren't a ton of people in devops who would share what they have. If you've ever used Firecracker, you've really been helped a lot by the various guides they have provided back to the community like these: - https://fly.io/docs/reference/architecture/ - https://fly.io/blog/fly-machines/ - https://fly.io/blog/sandboxing-and-workload-isolation/

Their architecture is beautiful and revolutionary. They're probably the first or second ones to find a lot of the new edge cases as they grow.

It's a lot harder to be the first one over the wall than it is to copy. They've literally given the average developer a blueprint to build scalable businesses that compete with their own.

That category was added after one of our support folks replied, likely for tracking. I don't know why it's private. They may not even know this category is private. Hiding negative shit wasn't a deliberate decision... we're aware of google cache and we don't need to give HN another reason to dunk on us.

> That category was added after one of our support folks replied

FYI, this doesn't appear to be strictly accurate. The OP commented at 23:52 UTC saying that the thread had been made private, and the reply from "Sam-Fly" was not posted until 02:36 UTC.

My point was that the app-not-working category is used in conjunction with support/our team getting involved. I assume this is what Sam meant by "flagged it internally", which was followed by investigation, then a post. I don't see how the timestamps uncover something nefarious.

I don't know why the app-not-working category effectively delists threads, but until we find out, I just removed it so this thread is public again.

may be it's to avoid search engines to not scrape these threads?

My understanding is that it was causing support problems, because people were Googling for solutions to problems with their apps (because of the Heroku diaspora, we have a lot of first-time Docker users), finding old stale threads on our forum that looked related, and then reviving them.

I think we can just `noindex` the category instead of making it private?

So the tagged posts were intentionally hidden, then.

As an employee that would be a catastrophic outcome.

Docker (or rather OCI) is our first class citizen. The launchers for phoenix/rails/etc just generate dockerfiles and config by inspecting source code.

This is really cool! I don't use discord much, how much effort would a Slack bot version be?

We do hire entry level people, in fact we're wrapping up our first cohort of interns right now. Exclusively hiring experienced dudes from the tech bubble is a failure mode in the long run. We're invested in hiring folks with diverse backgrounds and experience levels, and we need to talk about that more for sure.

Our jobs page is sparse right now because we’re focusing on hiring EMs to help grow a healthy eng org. We’ll have more openings before long, and you should absolutely apply when something sounds right. Feel free to hunt me down online in the mean time!

Since you mention hiring EMs, is there a place to view the open roles for EMs?

The jobs page seemed mostly IC focused

This is for employees only. We don't collect more than necessary for customers, and if we did we sure as hell wouldn't be sending it to Google.

Thanks, and right... I don't expect maliciousness on fly's part. But you'd be surprised (or not) how many goog products phone home with anything they can find. In fact it might be called a "business model" of some sort.

Google's SSO can't really phone home. You're either using SAML or OAuth; in either scenario, the information flow is Google --> the app you're SSOing into; name, email, and user group information.

If you're SSOing into, say, AWS, Google doesn't get any access or private info out of AWS in the flow.

What rest api is that? If it’s not the machines api it’s in graphql at api.fly.io/graphql.

The one at https://api.fly.io/api/v1/ ?

That’s an old api we need to sunset. How did you stumble on it?

By clicking on the first Google result for "fly.io rest api" ;)

Ah!!! Thanks for pointing that out, we'll take it down.

If you mean moving (or copying) VMs to another region/host, sorta. Stateless compute is easy; our apps platform (orchestrated by Nomad) already does it. Volumes complicate things because they live on a specific host, and moving volumes between hosts is a slow and tedious process. Solving this is high on our priority list. We need super fast volume forking and host migrations like yesterday.

Yeah I was referring to VM snapshot transfer vsphere/openstack/gcp instance style.

> our apps platform (orchestrated by Nomad) already does it

Preserving internal vm state or just restart everything?

Ah! I've had volumes on the top of my mind all week... Firecracker supports snapshots in a dev preview but we're not using it yet. We can't really do anything like that on Nomad, which is one of the many reasons we're keen to get off it.