Titanous

It's not particularly well documented, but the code is here: https://github.com/flynn/flynn/tree/master/controller/schedu...

We've basically implemented the minimum viable system for our use case, and only add features as needed. The main thing that's missing right now is awareness of resource constraints and usage and then balancing based on that. There is a patch in progress that adds awareness of host-specific persistent volumes for our database appliances.

As an aside, when we started Flynn, the only open source scheduler that was available was Mesos and it didn't meet our criteria for integration so we ended up writing our own code. That code has since been rewritten approximately twice.

Tesla does have a bug bounty program: https://bugcrowd.com/tesla

No, you retain all of the properties of Tor hidden services: censorship resistance, authenticated end-to-end encryption, onion routing that hides your source IP.

Obviously if you log into a Facebook account with your real-world identity then all actions performed on the site will be linked with it, but that is expected.

The driver for the network offload is proprietary, however the pre-installed OS is Debian Linux with a fork of Vyatta.

No. Both BoringSSL and LibreSSL use substantially different (and safer) systems for their CSPRNG.

https://boringssl.googlesource.com/boringssl.git/+/refs/head...

https://github.com/libressl-portable/openbsd/blob/master/src...

There are a bunch of great unofficial clients, several written in Go (I like acmetool): https://www.metachris.com/2015/12/comparison-of-10-acme-lets...

I have worked with systems implementing 3D Secure and have multiple credit cards that trigger it. I can assure you that the standard deployment for US-based banks and merchants uses iframes and in the majority of cases will ask for enough personal information to steal your identity or drain your bank account.

3D Secure is a complete disaster. It encourages users to put ridiculously sensitive information like social security numbers and bank credentials into an iframe in the merchant site. This trains users to be phished.

Is the source code available? I don't see it at https://github.com/docker

Especially when crypto is involved. Given the large number of completely broken cryptosystems, making this open source will give it a fighting chance to not be entirely broken.

This is basically a worst-case scenario. The entire public Certificate Authority trust model depends on the validation of ownership of domains that certificates are being issued for. If an attacker can get a trusted certificate for facebook.com, then they can silently man-in-the-middle connections and pretend to be Facebook.

The Texas public intoxication law is apparently very broad (you could be arrested without having had a single drink) and is apparently used to discriminate regularly: http://www.motherjones.com/politics/2010/03/texas-racist-law...

The feature exists to protect against less sophisticated attacks. It's not necessary, as setting a long alpha-numeric passphrase will mitigate brute force attacks.

At that point they can swap out the flash chip for a new one, new chips can be obtained easily. Also, the PIN is 4 numeric digits, no alpha characters.

Yes, there are many reasons to deploy TLS everywhere, and everyone should be working towards it for these reasons:

- Increased resistance to surveillance. Instead of seeing the pages/information that a client downloads from your server, state actors, ISPs, local attackers, and anyone else listening only learn that the client downloaded some bytes from your server.

- Mitigation of man-in-the-middle and man-on-the-side attacks against your website. These can be as simple as someone attacking a local open Wi-Fi access point to sophisticated attacks like the Chinese DDoS against GitHub and the NSA's QUANTUM INSERT. Potential attacks range from replacing/rewriting information to attacking client machines with browser exploits.

- Better SEO rankings, Google weighs HTTPS sites higher than their equivalent insecure plaintext.

If you need a shared host that supports HTTPS, take a look at DreamHost, they have a free one-click Let's Encrypt integration.

This is not a duplicate. The post is about a new lawsuit filed due to the change in rules, the suit has not been previously on the front page.

It's not open source in the traditional sense of the term, though they have published the source code. The license is proprietary.

This looks neat, but the license is fatal. It is not "just like an open-source license."

First, what is a "user"? It is not defined anywhere in the license.

I did not look at the source code, because of the potential IP issues. What would happen if you looked at the source code and then later worked on another open source project and implemented a bit of code that looks similar? The worst case scenario if you did this and the "upstream" was open source is that you'd have to do a bit of re-licensing, the worst case scenario here is that every user of the "downstream" project gets sued by SourceGraph.

Asking for contributions is also problematic, as you're asking for employers to authorize free contributions including a blanket license and patent grant to a proprietary commercial project. And even after that the contributor doesn't have the right to freely use and distribute the software they modified.

I'm all for publishing source code of proprietary projects, but dressing it up as an open source project is not great. I'd suggest adding a license clickwall to avoid accidental IP contamination.

Flynn co-founder here. We plan to expand to support many more popular open source databases next year (and expose a framework for others to do the same). The goal is that a supported database should "just work" on the platform and be sanely configured out of the box with high availability, automatic failover/recovery, encrypted streaming backups, app credential provisioning, etc.

Our Postgres appliance is unique in that it is explicitly designed to not lose data in the face of failure. Simply wrapping up a database in a container with leader election and replication is not enough, as there are many pitfalls that can cause data to be lost during failures. Of course we are limited by the guarantees the database can provide, so some datastore appliances we build may have clearly defined caveats.

Storing binary blobs is another tricky matter, and we're exploring what we can do with little to no configuration. We currently store app images and git repos in Postgres, which works but will only scale so far.

We are also improving our scheduler so that it is capable of providing the constraints necessary to place stateful services properly.

The discovery URL is only used for bootstrapping, nothing will break if you specify IPs instead. They are interchangeable.

Great question! We're aware of the Heroku issues, and they don't fully apply in our case. We currently do not have any queues in the router other than the kernel's accept queue. All incoming connections are assigned a goroutine immediately and the requests are proxied back to service instances without queuing. So if your application instances can handle concurrent requests, the performance impact of random load balancing should not be huge.

We are absolutely open to implementing other balancing algorithms, including least connections. The one caveat is that at any time multiple routers will be in operation and we're not going to do extensive coordination between them, so the balancing will never be perfect.

Thanks!

Minimum high availability setup would be three nodes with 1GB of memory each, more memory if you're using a heavier application framework like Rails.

When you run a scale command Flynn creates new application containers that are balanced across the cluster, so if you scaled to six instances with three hosts in the cluster, you'd end up with two instances on each of the three hosts.

You can specify the host IPs explicitly instead of using the discovery service. The current snag for isolated clusters is that stock buildpacks require internet access to download languages and frameworks. We'll solve this, but some additional work is necessary.

Thanks! Tutum is a proprietary SaaS product that provides a web UI for Docker. Flynn is a full-featured open source platform, you don't need to think about containers, just your app.

> 1) Is this tool the same as Docker Swarm?

No, it is much higher level. You could think of it as open source Heroku, apps are deployed using buildpacks and a PostgreSQL cluster is included.

> 2) Has the code been security-audited?

Not yet. We've been focusing on stability, work on internal security will be starting soon. You can expose ports 80/443 to the Internet, but shouldn't run untrusted code on it. See here for more details: https://flynn.io/docs/security

> 3) Can I use this as a combination of Puppet/Chef + Swarm?

For most use cases it would replace those tools.

> Lastly, who is this tool for? The guy running his 1 VPS or the startup running their 50 AWS medium instances?

All of the above, though we recommend at least three instances for high availability and haven't tested large clusters yet.

Yes, absolutely. We do a rolling deployment of new app instances, requests are not dropped.

We didn't really need all the features of etcd, this change is part of a longer term plan to only use Raft for leader election and service metadata with service instances propagated using cluster gossip. We also ran into some issues with etcd that were very hard to diagnose, and the developer who worked on the project was familiar with and confident in the Hashicorp package.

No current plans, but if there's enough demand for it we'd be quite happy to implement it (or accept a contribution!). Please file a feature request on GitHub if you'd like to see it in Flynn: https://github.com/flynn/flynn/issues/new

Edited to add: It looks like there is already a buildpack for ASP.NET 5 (uses Mono) that's worth a try: https://github.com/heroku/dotnet-buildpack

Flynn CTO here, happy to answer any questions about Flynn. This is the first release in our stable channel with an update path, we'll be releasing weekly from now on.

It may not be "production ready" for everyone, though please try it out and let us know how it goes.

If you're in SF, please come to our meetup in Tuesday and we can talk in person: https://www.eventbrite.com/e/flynn-stable-sf-meetup-tickets-...

Thanks for the answer! WebCrypto is obviously a disaster, it is very unfortunate that new systems are being stuck with legacy crypto if they use it instead of non-native libraries.