Outline is another (more mature) option: https://github.com/outline/outline
HN user
Titanous
jonathan@titanous.com
Other cofounder here. I just wanted to add that we still have some t-shirts and stickers left. So if you want some defunct project/startup swag, we'd love to send it to you! https://shop.flynn.io
Jason (the creator of Wireguard) wrote a great response to this: https://lists.zx2c4.com/pipermail/wireguard/2020-December/00...
Sure, I combined the two tables in the spreadsheet linked below, and there are many occupations that are more dangerous than police officer if we look at fatalities by per-capita occupation.
https://docs.google.com/spreadsheets/d/1dXtv2wnutujfXWUHB9Bm...
This is correct. In fact, landscaping and groundskeeping workers (among many other categories) suffered more fatalities than police officers in 2018 according to the Bureau of Labor Statistics: https://www.bls.gov/iif/oshwc/cfoi/cftb0326.htm
Here’s the primary source: https://www.keypointsabout.org/blog/advancing-the-internet-s...
Duplicate of https://news.ycombinator.com/item?id=19840397
It's worth noting that the new VS Code Remote Development extensions are not open source, which means that it is impossible for the community to fix bugs, and add new platforms/environments/features, or see the code that's running in their environment without reverse engineering.
https://code.visualstudio.com/docs/remote/faq#_why-arent-the...
Yes, when you use a US carrier roaming in China you have a US IP:
This censorship occurs despite the fact that when in China a cell phone using a foreign SIM is not subject to the firewall restrictions (all traffic is tunneled back to your provider first), so Google, Twitter, Facebook, et al all work fine on a non-mainland China SIM even though you’re connected via China Mobile or China Unicom’s network.
I vouched it after it got flagged dead which resurrected, but it hasn't returned to the front page.
Here's what they are actually collecting: https://github.com/Microsoft/calculator/blob/master/src/Calc...
In case anyone is wondering what telemetry is collected: https://github.com/Microsoft/calculator/blob/master/src/Calc...
Work has already started on a new challenge using ALPN: https://mailarchive.ietf.org/arch/msg/acme/mrKOeRK1K6H_42Hxb...
Previous discussion: https://news.ycombinator.com/item?id=13449398
(edited for clarity)
Flynn developer here. This is correct, a three node cluster can withstand loss of any single host before things start failing.
Also, log shipping and Let's Encrypt support are coming soon.
You can use S3, Google Cloud Storage, or Azure Storage even if you're running on DigitalOcean.
Yeah, check out this blog post about how to deploy Phoenix: http://nsomar.com/how-to-use-flynn-to-deploy-a-phenix-app/
Distributed communication should work fine, feel free to ping us on IRC or GitHub if you run into any trouble or have any questions!
That's at the process level only currently.
No current plans, but feel free to request it in a GitHub issue. We consider the number of votes on GitHub when adding to the roadmap.
When we started in 2013, the only open source scheduler available was Mesos and the ecosystem didn't have community efforts like Kubernetes, so we had to write our own components to build Flynn.
Flynn is designed to be an end-to-end solution for production deployment, and all of our components are created to work together. The whole system is self-bootstrapping and self-hosting, so installation is easy, and the same APIs are used to manage the whole platform as are used to manage apps deployed on it.
In addition to the twelve-factor stateless webapps that Deis Workflow supports, Flynn also includes highly available database appliances with safe, automatic failover (currently PostgreSQL, MySQL, and MongoDB with more coming in the future). We also have a bunch of security features coming over the next few months like Let's Encrypt support and flexible user authentication with 2FA and very granular access control.
If you don't need or want our database appliances and you are comfortable with Kubernetes and happy to install and operate it, then Deis Workflow is a good option. If you don't care about using Kubernetes specifically, Flynn is a good pick as it is easier to get up and running with.
There are healthcare companies that already use Flynn today, though not for HIPAA compliance specifically.
Compliance is a really interesting vertical. As we make progress on our security roadmap, Flynn will become a very compelling option for environments like HIPAA, PCI, etc. especially when combined with clouds like AWS that are also compliant.
Yeah, we ship unmodified Heroku buildpacks, plus one Cloud Foundry buildpack (https://github.com/cloudfoundry/staticfile-buildpack).
So far no one is using Flynn in a fully disconnected environment, and we're aware of this limitation. My take on this is that we need a replacement for buildpacks that allows for repeatable/functional builds (think Nix for app deployment).
Yeah, it's definitely something we want to support in the future. Autoscaling requires building some components that are aware of and can communicate the underlying infrastructure APIs (AWS, GCP, Azure, DigitalOcean, OpenStack, etc.) combined with app/host metrics. It's just a matter of putting the implementation effort. We'll get there eventually.
re-deploying a few images on Flynn it wasn't cleaning up images and disk space was disappearing fast
I'm really sorry to hear that you switched off of Flynn. We're aware of this issue, and are in the process of fixing several things that can cause it (it only happens when not using an external blobstore backend like S3). Hopefully you'll try Flynn again at some point in the future!
Here's the issue tracking this: https://github.com/flynn/flynn/issues/3375
Flynn itself doesn't communicate with infrastructure APIs currently, but you could hook this up so that there is a base set of three servers that are always running and then an autoscaling group that watched your metrics or a schedule and added/removed servers.
I'd be happy to explain this more on IRC if you're interested (#flynn on Freenode).
Awesome, thanks for the feedback!
If Heroku works for you, that's fine, but for lots of people it doesn't. For example, Heroku only supports HTTP, not TCP. There are a number of technical limitations Heroku places on apps that other platforms like Flynn don't.
There are lots of reasons why users need a different, or especially an open source, PaaS.
Some users run into scaling problems when their products grow beyond a certain point. Others want to have more control over their infrastructure for compliance, governance, or other administrative reasons. Others have huge deployments and want to save money by using their own cloud accounts.
It varies from customer to customer, but for many Heroku isn't an option or isn't the best option.
Yeah, our security roadmap will get us to multi-tenancy eventually.
Due to the security posture of the Linux kernel, we won't recommend running untrusted code side-by-side on the same hosts as more sensitive workloads, but we plan to harden everything to the maximum extent possible.
I'd love to hear about any trouble you ran into while trying Flynn so that we can fix it! Feel free to send me an email: jonathan@flynn.io
Convox is a great pick if you want to use AWS-specific services for your entire stack. Instead of using portable open source components, Convox uses AWS services wherever possible, and acts as a lightweight coordinator to combine them into a platform.
Flynn has no external dependencies on cloud features, so you can run it anywhere, whether that's on your laptop, AWS, Google Cloud, a VM somewhere, or bare metal in a colo or private datacenter. We also include RDS-like highly available database appliances so that your whole stack is portable and you are not locked into a single hosting provider.
edited to add: We didn't know about this post until Bitmatica posted it, this is just a great post from a happy user, not planned Flynn marketing!