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 crate for tokio, so it’s not automatic but might still be interesting: https://lib.rs/crates/tokio-splice

We’re using cr-sqlite as part of our distributed state propagation system. It is indeed easy to bundle in the app!

https://github.com/superfly/corrosion

It would be possible to distribute cr-sqlite changes in many different ways (like you said, http or torrents, etc.) since any change can be applied out of order.

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.

This looks great. I might be giving this a shot for a use case we have. My main concern is the docs.rs-generated documentation is hard to use. I don't exactly know how things fit together. I'm sure I could figure it out via tests, but more docs and usage examples would help a lot.

As for your search for SWIM in the Rust ecosystem: I found a pretty good (well documented and tested) crate: https://crates.io/crates/foca

Looks like it was hidden, not on the main page: https://fly.io/feed.xml

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.

To be determined. We're hoping to contribute and use what's going to come out of hyper's h3 efforts (we use Rust for our reverse-proxy). There's not much there yet though: https://github.com/hyperium/h3

We're not in a huge hurry to support QUIC / H3 given its current adoption. However, our users' apps will be able to support it once UDP is fully launched, if they want to.

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.

That's nice to read! Thanks.

We do need to cleanup our old blog posts and links. We created a lot of content at various times. This content is not always relevant anymore.

As for your fly.toml question, you can get the config with `flyctl config save -a your-app`. It'll create a fly.toml with the latest config we know about.

Concurrency limits are still being worked on. They should definitely be visible in more places. The only way to know about them right now is from the fly.toml, that's not ideal.

This is what we do at fly.io: https://github.com/superfly/fly

It's based on node.js right now. It's a bit clunky, but we have many success stories of customers running it locally, on their CI and deploying to infrastructure.

Currently the open source version is not the same as the production version (due to the distributed nature of our platform.) We're working on fixing that very soon and going all-in open source.

That’s a lot of slang (shard author here)! Happy to see people using it so much.

I just happened to buy a Dual 1.8Ghz model for $10 CAD at a garage sale yesterday. Beautiful machine. Also had a keyboard, but unfortunately isn't a mechanical one (rubber domes over membrane.)

Thanks, that's appreciated!

It's not such a huge pivot. The "one hostname" was checking for interest in this area and it worked well. Putting stuff under a single hostname seems to be something people want to do.

At its core, the previous product was a flexible, globally distributed, load balancer. We built all these middleware, features we wanted and people might also want. In the end it was untenable: supporting such a large variety of small building blocks was going to be hard. Building new middleware all the time was also becoming a pain, changes were required in multiple components for each middleware.

This new "edge app" product gives the same flexibility, but puts the power (and burden) into the developer's hands. You could build our entire previous product on this new platform.

Note: https://onehostname.com still exists and runs on our new platform. However, the article it points to is for the old product. The source for it is available here: https://github.com/superfly/onehostname

Definitely not meant as arrogance. We'll make it clearer, it seems like there's a bit of that confusion here.

The project's page: http://cnp.neclab.eu/projects/lightvm/

Blog post with more information: http://blog.mongohq.com/two-factor-authentication-made-authf...

Just bought punypic.com with it. Thought it was a cool name. No idea what to do with it (except the usual image hosting service)