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."
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?
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...
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.
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.
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.
To clarify: the dotCloud pricing hasn't actually changed yet, the new pricing has been released to a limited group to collect initial feedback, and will likely be altered before it's official release. That being said, the general model of differentiating between apps in a development sandbox vs those in production is likely to stick around.
As for your initial question: dotCloud and Heroku have rather different models for how applications are built and deployed, but in the end, the amount you pay for comparable apps will be about the same[1]. Though price is certainly an important consideration, it is probably not the best way to compare the two. The real difference is in how much flexibility you need. By making fairly strong assumptions about the architecture of your application (you will have a single blob of single-language code as a web front-end, PostgreSQL database, no local write access, fixed-size memory allocation for containers etc.) Heroku is able to optimize for apps that fit within those particular constraints. dotCloud, on the other hand, makes many fewer assumptions about these types of architectural decisions, leaving more power, but also somewhat more responsibility, in the hands of the developer.
This difference is a direct result of the two companies' origins: while Heroku used to be a Rails-only provider and has since opened up to multiple languages, dotCloud began life as a generic "service" runtime upon which more technology-specific abstractions have been built.
In short, which one is "better" depends far more on your own particular requirements than it does on the minor differences in price between the two.
Either of the two workflows you mention are easily doable with dotCloud. Building locally (as you do today) should be fine: the dotCloud command line client uses git or hg (whichever you're using) by default, but can fall back to rsync if you want to push untracked changes[1].
In the long run, though, it's probably better to include the Brunch step as part of your build. With the new version of the dotCloud Python service[2], you can hack the build script[3] to do whatever you want. For simple build tasks, there's one version of Node already installed, but you could also poach part of the Node build script[4] to install another version, if you need it.
The default behaviour at these trade show/exhibit hall events (stand behind a table, look pretty and hand out swag) has always struck me as a colossal waste of time and money. This sort of slightly-different format seems like a good way to shake things up a bit. Have others tried different creative tactics to get (and hopefully give attendees) more value from these events?
The main problems I ran into when upgrading were with the new timezone support, but it was easy to just disable it (set `USE_TZ = False`) until I have a real need for the feature (and the time to fix the issues it causes for current code).
I'm really surprised and sorry to hear that. We usually have pretty prompt support replies, and generally give really thorough answers, since support is mostly handled by core engineers (we have an engineering support rotation)
I'll admit that the one downside of having an engineering support rotation is that the quality of the written English does vary a bit from day to day because some of our engineers aren't native English speakers. But I'd much rather have a thorough and technically accurate (if somewhat poorly written) support response than a well-written but technically inept one.
Sorry to hear things that you're having trouble with dotCloud. A couple quick questions:
First, which requirements are you putting in your dotcloud.yml? In general, pip-installable requirements should just go in a standard requirements.txt file, and dotcloud.yml should be used to describe the higher-level structure of your application (ie which service types you need).
Also, I'm not sure what you mean about "masking the debug interface", but all your Flask/WSGI and nginx logs are available with the "dotcloud logs" command, and you can also log into your service instance directly to debug using "dotcloud ssh" (in which case logs can be found in the /var/log directory). You can also certainly use Flask in debug mode, by setting "application.debug = True" in your wsgi.py
It is true that you may have trouble using the interactive, browser-based debugger with the default setup on dotCloud, then but this is a Flask limitation, not a dotCloud one. From http://flask.pocoo.org/docs/quickstart/#debug-mode: "the interactive debugger does not work in forking environments (which makes it nearly impossible to use on production servers)"
Hope that helps, and if you have any other questions, drop us a line: [email protected]
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