I don't believe the bankruptcy clawback provisions you're referring to apply here, because this is an FDIC conservatorship/receivership, not a bankruptcy proceeding. I don't fully understand why this particular part of the processes differs, but I'd argue it's that it does unfortunate, as it incentivizes bank runs like this.

There is an extensive comparison of the two processes in [1]. Specifically:

> the Bankruptcy Code provides trustees the authority to avoid, that is, claw-back or reverse, certain transfers (subject to certain limitations52) made by debtors

> the FDIC as conservator or receiver may not avoid (i.e., reverse or claw-back) any property transfer pursuant to a qualified financial contract unless the transfer was performed with the "actual intent to hinder, delay, or defraud."

[1]: https://www.everycrsreport.com/reports/R40530.html

to be clear: you're calculating embeddings based on the timestamped transcript, yes? or are you doing something with the actual video content? what are you using for the embeddings?

tl;dr?

Actually, "Year of Birth" appears to be one of the voter file fields too. Not quite the same as an exact birth date (esp for identity theft purposes), but useful for demographic targeting.

It's interesting how concerns around the long-term effects of EMF exposure that we heard about fairly frequently in the early days of widespread cell phone usage seem to have virtually disappeared from the public consciousness, despite, AFAICT, not really ever being answered. Meanwhile usage, power output, and proximity (BT headphones, ie. RF transmitters in your head for hours at a time?) are all increasing.

Much of the research (and the FCC's regulatory regime) has traditionally used a model based on cell PHONE usage ie testing for effects of relatively short periods of exposure, with the phone beside the head, where the skull acts as a shield[1]. But these assumptions aren't applicable to smartphone usage today, where 90% of people under 35 have been sleeping with their phones for years[2], and most usage involves the screen in front of the face, where there are large areas of only soft tissue (eyes & nasal cavity) between the device and your brain.

Furthermore, most testing largely centers around Specific Absorption Rate (SAR), which is basically concerned with the question of power (ie heat) transmitted to the body (basically "are the microwaves cooking your?"). "Cooking" is a fairly well-understood process, and tissue's ability to dissipate heat can be fairly easily modeled to ensure exposure stays within a safe range. But several of the concerns this meta-analysis points to have a dose-response curve is not so simple or clearly understood, meaning the effects could well occur, even within the usage patterns deemed "safe" on a SAR basis (their language is actually stronger, claiming these "should be considered [...] established effects of Wi-Fi")

All that being said, I don't see this as a definitive answer that our current exposure levels of RF radiation are necessarily harmful, but I have definitely wondered whether our (grand)children's generation will look back at images of us staring at our screens the way we look at images of our parents' generation frolicking in clouds of DDT[3] (I've also wondered this a more often about spray-on sunscreen ads[4], but that's a whole other rant)

----

[1]: Most industry recommendations make the laughable assumption that the phone is not even in contact with the body. Manufacturers basically threw a shit-fit when Berkeley started trying to inform people that most "normal", against-the-body usage was likely outside of what FCC exposure guidelines test for: https://arstechnica.com/tech-policy/2017/04/berkeleys-cellph...

[2]: https://www.businessinsider.com/90-of-18-29-year-olds-sleep-...

[3]: https://youtu.be/mX6fQLrueW0?t=14

[4]: https://youtu.be/m0WH-xb6Htw?t=6

From both the blog post and the website, it's not clear to me what this buys me over plain Docker (or possibly Docker + Compose). Is this a Compose competitor?

You're absolutely right. That's why Lessig's proposed Citizen Equality Act has multi-member districts with ranked choice voting (effectively ending gerrymandering) as the second major component: https://lessig2016.us/the-plan/

I saw that same presentation at the same event, but came away with a very different impression: the container management they showed was implemented completely outside of docker itself, with no patches to the docker codebase needed. Also, IIRC it actually did use significant code from etcd for coordination.

How do these compare to https://www.wisebanyan.com?

It seems to be roughly the same idea, but without any fees at all (I haven't used any of them, so I'm likely missing something)

EmberJS: http://emberjs.com/

It's primarily author is Yehuda Katz, the man behind (much of) Rails 3

ZeroRPC uses Gevent for concurrency

Faults are handled differently depending on whether they are ZeroRPC-layer errors or application errors. To maintain the integrity of the connection itself, there is a heartbeat system independent of any given request. There is also an optional timeout that can be set for a given call's response. Application-level errors are propagated as "RemoteError" exceptions in the python interface. In order to collect more info about remote errors, there is also support for ZeroRPC[0] in Raven[1], the Sentry[2] client (Disqus' error logging system). In any failure case, both sides of the connection are notified and given an opportunity to clean up after themselves.

As to the philosophical concerns, I do agree on some level: RPC in general (and ZeroRPC in particular) are powerful weapons that need to be treated with care. That being said, there are a number of cases that are greatly simplified by the higher-level abstractions and more-robust error handling ZeroRPC provides.

------

[0]: http://raven.readthedocs.org/en/latest/config/zerorpc.html [1]: https://github.com/dcramer/raven [2]: https://github.com/dcramer/sentry

While you're right that EC2 is pretty close the metal, dotCloud starts at a very different level of abstraction. On most VPS providers (as with dedicated hosting) the first question you answer when you go to deploy your web app is "what Linux distro do you want to run?" If you're trying to learn sys admin skills, that's great, but for most people, the end goal is to deploy a web app, not run a Linux box.

With dotCloud, you start higher up: list the components (eg Python web frontend, MySQL and Redis) that make up your actual application, push your code and you're handed back a URL with your app running. A single command lets you scale out for reliability, with load balancing across your multiple web front-ends and master-slave replication for your databases. Running a single physical server? Sure, not that hard. Setting up reliable, automated failover for every component in your stack? That's a bit more work.

In the end, it's really a question of the value of your time. Can you do all your own sys admin work? Sure. You could also build and maintain your own hardware, but from the sounds of it, you've decided that work is worth outsourcing Hetzner.

In the same way, for a lot of people, wasting time administering servers is just time taken away from building a real business: a distraction that is worth paying a few extra dollars a month to make disappear.

I see there being two, somewhat distinct, categories of players: those with a realtime-first, focus (Meteor, Firebase and, now, dotCloud.js) and those that take more of a traditional REST-based approach (Parse, StackMob, Backlift, etc.).

The later have an easier time integrating into existing client-side frameworks (Backbone, Ember, Angular, etc), since those mostly seem to be built with a REST-based model in mind, but it will be interesting to see what patterns emerge to plug push-based updates into these pull-oriented systems. For starters, I suspect we'll need the client-side frameworks to clarify the distinction between the server and client state and the source of changes. Henrik Joreteg's talk at BackboneConf[1] was good overview of this and other problems they've run into.

[1]: https://speakerdeck.com/u/henrikjoreteg/p/real-world-realtim...