jeromegn

We don't use k8s and you don't have to either. This is for current and future users who absolutely want k8s. We are a compute provider after all and making it easy to host a great variety of apps is good for our users.

There’s a col_version column in a clock table used for last-write-wins. In case a tie, the “biggest” value wins.

I'm the one who created this incident on our status page. I've been overly cautious in resolving this incident, but at this point I think it's causing more harm than good to keep it unresolved on there.

I think it might've prevented users from posting on our forums or sending in an email (premium support). I can imagine users looking at the status page and mistakenly thinking their problems were related to the current incident.

I've interpreted "Monitoring" as essentially meaning: "this is fixed, but we're keeping a close eye on the situation". We do not yet have a formal process for incidents such as this one (but we are working on that).

If our users are having issues, that's a problem. Looking at our own metrics, the community forum and our premium support inbox: I don't believe this to be the case.

Perhaps we should've done a better job at explaining the exact symptoms our users might be experiencing from this particular incident.

Whoops. It used to. Going to fix that soon!

We use containerd with the devmapper snapshotter! Works nicely.

We create a hard link to the resulting device for the root drive inside firecracker.

Their server and/or your client might not be setup for session reuse. Definitely a thing to check.

Hey there, Fly co-founder here!

Fly's proxy uses a mix of tokio, hyper and rustls. We don't need to use a crate that handles ACME because we're processing all the validation and certificate authorizations from a centralized, boring, Rails application.

We've had to submit a PR to the rustls project a few months ago to handle different ALPNs. Instead of resolving a certificate only from a SNI, the crate now provides the full ClientHello which contains negotiable ALPNs. With that information you can respond to the tls-alpn-01 challenge.

If you can build it in a Docker image or if you can deploy it to Heroku, then we support it :)

If it doesn't work, it's a bug.

(Disclaimer: I am a Fly.io founder)

I don't recall us being at Hack Arizona, certainly not me. I googled it and all it yielded was this HN post.

Your comment couldn't be further from the truth. I can't speak for whoever used these words (if they did), but I think we have pretty great work/life balance.

We all have families of our own and recognize they are far more important than our business. These things happen, such is life. Your kid gets sick, you want to care for them. Time off is always paid and we encourage people to take some. People often find it hard to take time off, but we've been good at it.

Nobody, generally, works more than 40 hours a week. I say "generally" because these past few weeks have been more intense given the end of our YC adventure, demo day, virtually meeting with investors and this Launch HN post. In normal times, I might work a few hours on a weekend but only if that brings me joy.

... and of course we're very flexible on work schedules because we're a remote-only company. Some weeks this might mean working only a few hours here and there because of life activities or the need to take time off. Other weeks, it might be the opposite. We recognize and embrace that.

We attempted C++ about a year ago, but I was never confident in our ability to clean up memory allocations (we had leaks) or avoid undefined behavior (we had segfaults).

I definitely feel more confident about our Rust code. It's no silver bullet, but it prevents a lot of unsoundness with its compile-time guarantees.

I can't really compare to C++, but it's easy to write new code or refactor old code. It took some time to get there, though.

All in all, I would recommend Rust wholeheartedly. The ecosystem is growing and getting more mature every week. The community is very helpful in general, especially the tokio folks.