Titanous

Since the page is loaded over plaintext, there's no easy way for a normal user to know that the credit card isn't being intercepted by a malicious script. It's not safe to serve a payment page over plaintext HTTP, even if it POSTs to a HTTPS endpoint as it could be modified in transit.

Stripe explains that TLS is required in their docs: https://stripe.com/help/ssl

Facebook makes RocksDB. The MySQL forked you linked is maintained by Facebook. The blog post is from a Facebook engineer who works on MySQL at Facebook. The tweet linked in the blog post is from a Parse engineer talking about using MongoDB with a RocksDB storage backend. Parse is a Facebook product.

I don't see how any of that is attacking MySQL or MongoDB, just their stock storage engines.

Oops, missed that. This is more complete: http://man.cat-v.org/plan_9/5/intro

The protocol itself is much cleaner, but I'm not aware of any recent benchmarks.

Compare https://ericvh.github.io/9p-rfc/rfc9p2000.html vs https://tools.ietf.org/html/rfc5661

We use it to share filesystems into QEMU/KVM VMs, so far zero issues, but it's not a performance-constrained use case.

I do have some plans to do benchmarks for another use case that's more performance intensive, but it's buried in my backlog right now.

9p is a better network filesystem protocol, and it's available on Linux.

Here are some shorter/alternative takes on the situation:

http://freelawproject.org/2015/03/20/what-is-the-pacer-probl...

http://qz.com/283772/why-pacer-should-and-should-not-be-like...

https://freedom-to-tinker.com/blog/sjs/making-excuses-for-fe...

There are many more if you take time to peruse the Re: PACER document and click through the citations.

Manta is part of SDC and implements a S3-like API (plus distributed map-reduce data processing).

I believe that CoreOS can use kexec to update the kernel. kexec basically looks the same as a reboot except instead of stopping fully, and going through the BIOS/bootloader again (which can take a long time on server-grade hardware), the old kernel 'execs' the new kernel and boots userspace back up.

https://en.wikipedia.org/wiki/Kexec

Hey, Flynn cofounder here. We merged the repos (there were a few dozen!) after encountering a ton of friction landing project-wide changes and managing the build system (vendoring dependencies in every repo got ridiculous).

Contributors were also having a lot of trouble figuring out where to report issues and submit patches. On the whole the unified repo and build system has been a massive improvement to our productivity and the quality of the project. Unfortunately using components in a modular fashion can be harder, and we haven't come up with a great solution to that. We're still committed to keeping our components independently useful and would love to get feedback on what we can do better.

Here are our current issues to date: https://github.com/flynn/flynn/issues?q=label%3Aupstream%2Ft...

It would be a good blog post topic, I'll make a note of that.

Yeah, tup is neat. Much lower friction than the equivalent Makefiles as it can auto-detect dependencies and outputs in many cases. We've run into a couple issues, but for the most part it's been smooth sailing.

Previously: https://news.ycombinator.com/item?id=7863856

>> Is there a draft specification available for libtrust?

> https://github.com/docker/docker/issues/8093 https://github.com/docker/docker/issues/9015

libtrust does not appear to be mentioned in either of these issues.

> There is nothing particularly new in Jonathan's post and I thank him for facilitating a conversation.

Maybe not new to you or Docker Inc staff, but I don't see any warnings that a pull could result in complete compromise. On top of this, the inaccurate "verified" image message is still in the current release.

> I have explicitly called out the need for containerization of the 'xz' process, and to run it in an unprivileged context.

Do you have a link to this?

> As this work comes out of review and a specification is finalized, we should expect to see a much better experience and more secure image transport

Is there a draft specification available for libtrust?

> However, as the libtrust and v2 image work, and subsequently, registry protocols are still in draft and security review, it is difficult for us to recommend that users yet attempt deploying these.

And yet you deployed it to production in 1.3.

Author here.

> I wish the author had not omitted this crucial paragraph in the announcement he quotes:

I did not quote this announcement, only linked to it.

If this is intended to be prototype code, it should not be enabled by default, and certainly shouldn't be printing inaccurate messages to users in a 1.0 product.

Also, the referenced warning goes to the daemon log, and doesn't appear to ever be triggered.

Here's the original: https://web.archive.org/web/20141201195306/https://blog.dock...

These may be the blog posts that you are thinking of:

http://opine.me/a-better-way-to-store-password-hashes/

http://opine.me/all-your-hashes-arent-belong-to-us/

http://ethanheilman.tumblr.com/post/28481738192/security-thr...

We're working creating database appliances (think RDS/Elasticache/Heroku Postgres) at Flynn[0] (I'm one of the creators).

[0] https://flynn.io

Flynn co-creator here.

Short answer: A lot. At Flynn we're building solutions to what we see as the big problems that developers will face in the next few years. Deis seems to be solely focused on Heroku-like featureset.

Flynn runs anything that runs on Linux, including stateful services like databases. In fact, we package major open source databases as "appliances" that run within the Flynn cluster for ease of use.

Deis has historically required users to use very specific technologies (initially Chef, and now CoreOS). Flynn does not rely on a specific Linux distribution or configuration management system. In fact, Flynn was designed to be modular to give users the greatest possible choice of components (Deis uses a few components we created for Flynn).

Flynn is designed to be a single toolkit that lets you run everything, not just twelve-factor stateless webapps.

We have created a lot of new technology where necessary but we also use off-the-shelf components like CoreOS's etcd, which Deis also uses. Neither we nor CoreOS consider etcd production-ready, and we don't consider any platforms (including Flynn) production-ready until etcd and all underlying components are stable (Deis also depends on the CoreOS alpha channel).

When you see a "1.0" release from Flynn it will come with our full confidence in the stability of all of its components. We also aim to go well beyond what's possible in Heroku today.

Awesome, thanks! Don't forget the gh-pages branch.

This is a great idea, but the "non-commercial" clause of the Creative Commons license makes the documents pretty useless as the only real use would be in a commercial context.

With the update installed:

  $ curl -s https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck | bash
  Not vulnerable to CVE-2014-6271 (original shellshock)
  Not vulnerable to CVE-2014-7169 (taviso bug)
  bash: line 18: 14885 Segmentation fault: 11  bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null
  Vulnerable to CVE-2014-7186 (redir_stack bug)
  Test for CVE-2014-7187 not reliable without address sanitizer
  Variable function parser inactive, likely safe from unknown parser bugs

The iPhone 5 doesn't have the "motion coprocessor" (added in 5S), so it's unlikely that it will gather this data without a third-party app.

Asciidoc (and the myriad of other markup languages that are supported in their file rendering) is not supported in comments/issues/pull requests, only "GitHub Flavored Markdown".

I have one and highly recommend it. The distro is actually Debian-based and is mostly an open source fork of Vyatta but has some proprietary bits for the Cavium offload.

If you have a Docker image on a registry somewhere you can create a release in Flynn from it using the `flynn release add` command (or the API).

We certainly not cloning Heroku's API, but we have most of the things you describe and much more in our API and CLI, including release management, configuration, job control, resource provisioning, log access, docker image releases, interactive and detached one-off processes, etc.

We can use sdutil[0] to render info from service discovery into a config template.

[0] https://github.com/flynn/flynn/blob/master/sdutil/configure....

We're tracking this issue at https://github.com/flynn/flynn/issues/85

To date we've tried to push fixes upstream to buildpacks so that we can avoid the maintenance burden of keeping forks up-to-date.