Well Google is the intermediary. They can (and undoubtedly do) directly affect supply, demand, and price. They can purchase ad space from a publisher for $0.45, mark it up x, and sell it. They can slow demand by temporarily (even for seconds at a time) increasing cpc. They can lower supply by lower bids. They could in theory even pre-sell ads when supply is in excess.
If I'm not mistaken, it's apples and oranges. Docker Orchestration is closer to the Kubernetes/Diego/Mesos level, in that it's assigning opaque workloads to machines in a distributed cluster.
Flynn is more of a PaaS: it has additional logic to wire up your app, inject services, route traffic and so on.
I work for Pivotal, we donate the majority of engineering on Cloud Foundry, so I wind up peeking at lots of other cloud platforms that are emerging in this space. For example, Red Hat dropped their own code and built OpenShift 3 around Kubernetes.
For Cloud Foundry, we don't use any of these HN-famous systems currently. We built and use Warden/Garden because Docker didn't exist at the time. We built and use the Diego orchestrator because Kubernetes, Mesos and co didn't exist at the time. There's a lot of convergent evolution occurring in this area because lots of smart people see the same problems and arrive at similar ideas.
As for scaling up, Nomad currently holds the benchmark porn crown: they posted a 1-million number a few months ago. That said, it depends a lot on what you're counting. We've have Diego running at 10,000 genuinely genuine application instances -- full routing, full logging, full service injection -- in production for some time now. There's work to push the official-we-can-sell-it-to-F1000s-and-not-get-sued limit to 250,000.
Sure, there are are companies who need more than 250,000 copies of their apps running and it may be a bit longer before Cloud Foundry can meet their needs. I mean, I guess they can probably afford to run two copies of Cloud Foundry, if they have to. They might have to hire another operator. Ruinous.
Anyhow. We built an early version of Diego that was to my mind architecturally very elegant but, as I am given to understand, fell prey to a stampeding herd problem as we began to approach heavier workloads and simulations showed it would only get worse unless we went to something simpler.
I'm not sure I agree with the argument in this post that Docker's approach is particularly novel in this area -- separating workers and managers seems pretty standard to me. Diego breaks the work into more than a dozen cooperating subsystems, variously distributed into brains and cells. Diego relies on etcd, which Docker's engineers consider to be an operational overhead. That makes sense because of Docker's engineering assumptions (that someone has only installed Docker), so they kinda sorta have to be autarkic on this matter.
Cloud Foundry -- and by extension Diego -- can rely on BOSH to make operational management of etcd or any other service very close to a non-issue, while pushing that engineering effort out of the core product. I heard recently that a standard OSS Cloud Foundry has 90 (ninety) running processes. I never knew this because I've never noticed, because the upgrades are relatively trivial and almost offensively reliable.
Docker say that read optimisation is a major win from using an inbuilt store, but this presupposes a read-heavy design. A lot of what Diego does is push that work out of the central manager towards the edges. Mesos achieves a similar trick (though it pushes back to the consumer, rather than to the executor). Originally Diego's approach was was more decentralised, with a full auction model (meaning that the central orchestrator didn't need to update any node information at all), but as I said, the stampeding herd of bids on new jobs or processes made it hard to scale. (I am not sure what the alternative was, I'm just an interested spectator.)
Reminder: I work for Pivotal, insofar as Docker is turning back into a PaaS company, we're becoming competitors. I don't work on Diego and I never have, so my understanding of architecture and the course of its evolution is based on snippets of conversation and distant fan-boying. My understanding of Docker's new architecture is from hastily skimming a single blogpost and includes the industry-standard level of heavily and unfairly discounting every other engineer's intelligence and foresight.
So take everything I said under careful consideration.
Here in India they just return NXDOMAIN for the name. So it is pretty easy to bypass using 126.96.36.199. Also, the guy who installed the router at my home changed the default DNS to 188.8.131.52. I think ISPs do this on purpose. They don't wanna block sites their customers wanna access. And the government is dumb enough to not understand the difference between a DNS block vs a real block.
If you need workflows, there's also VisualReview  with some basic workflow for approval testing, and Applitools , a commercial tool with integration with Selenium, Appium and Protractor that can do screenshot and video comparisons. I wrote about them as part of the 'Automated testing: back to the future' tools review . In the article, I also mentioned DomReactor, but that seems to be discontinued now.
While I share your sympathy for people being able to communicate, on the other hand, I can't possibly see a good future if multinational corporations are allowed to pick and choose which laws they have to comport with.
The points that have merit constitute the bulk of the message coming from people self-identifying as feminists. Sure, there's all kind of weird stuff - TERFs, separatist and even supremacist feminists etc - but they're a minority compared to the mainstream.
On the other hand, when looking at the MRA scene (again, going by self-identification of the speakers), the mainstream seems to consist of "incels", red pillers, and the like. So, as far as most people are concerned, the label is firmly associated with that sort of stuff. Consequently, suggestion to listen to "points that have merit", when they come in a binder with "MRA" on the cover, is not going to fly. If you want to be heard, you'll have to break the association by using a different label - or by finding enough like-minded vocal associates to reclaim the label (and at this point it would need to be a supermajority with a hefty margin before we can seriously start talking about this).
You might object that this is unfair, because the label is descriptive and appropriate, and all those misogynists have misappropriated it. Tough luck - descriptive labels get misappropriated all the time. For example, if you happen to be a socialist and a civic nationalist at the same time, a common sense descriptive label would be "national socialist" - but you really shouldn't be using it for obvious reasons.
In fluid dynamics, gravity waves are waves generated in a fluid medium or at the interface between two media when the force of gravity or buoyancy tries to restore equilibrium. An example of such an interface is that between the atmosphere and the ocean, which gives rise to wind waves.
I understand that once a rootkit is installed, all bets are off. I was wondering if the syscalls by which the rootkit gets installed will be obfuscated to make them look more like a benign/normal process, and evade detection by a malware-syscall-pattern-recognizer. or are some malware syscall patterns essentially "unhideable"?
About a few years ago I was offered a $10K bounty to make Solaris 7 work with QEMU, and the only progress anyone ever made was mounting the ISO image as a hard drive image and install from there. Nobody ever got the NIC card to get on the Internet. I found out CDROM0: or something could access the ISO image. Everytime I set up TCP/IP it would cause a kernel panic, or lock the system up, or crash. I was given like a week and could not do it. Then I found out about Hackers in Russia trying to do the same thing and not getting anywhere. Apparently the Solaris 7 Kernel has a NIC bug in it where some pointers are out of place. It was solved in a Y2K CD-ROM from Sun which is no longer offered.
Client who wanted me to make it work has a failing SPARC Server with Solaris 7 and needed everything the same. Problem was fixed in Solaris 9, but they needed Solaris 7 even if 9 is backward compatible.
Writing a new Kernel for Solaris 7 based on the old Kernel that works with QEMU might just work. Remember it is QEMU SPARC that I was working with to get networking going.
But if the best and brightest Hackers couldn't get Solaris 7 to have networking, then I for sure couldn't do it either.
But there is a need to emulate any sort of hardware no longer supported or made anymore because many businesses run on software created for those old hardware and software standards and when they can't buy the old hardware or it costs too much, it is better to just run it on QEMU.
The main food/eatery "the mess" was operated by Agnew/BHP but was accessible to anyone who lived there, employed by the site or not. There are a few cafes and shops which are privately owned. It operates like a functioning small town, just with the extra money behind it.
The downside is that when BHP closes the site (temporarily or permenantly, as is happening now), the primary workforce is moved out and the secondary businesses (school/shops/cafes) become unfeasible - not a good place to build a long term business!