leg100

>> I can't remember an AWS resource that isn't nameable or taggable.

ElasticIP is one among many. For a complete list: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tag...

Jamaican, Greek, Lebanese, hell even Belgian (mussels and frites!)

Size is no excuse.

Personally, I find the Dutch diet to be pretty unadventurous and poor. Sandwiches predominate, with not a lot of variety in cooking. This may well be irrelevant to the OP; nothing but cheese sandwiches and sour buttermilk may well be the perfect diet for growing tall.

As for the Rotterdam argument, I suspect fresh food would have to be flown in rather than shipped, which takes weeks.

> I don't know if anyone has done good studies on it.

And why would they! If an industry or country can get an advantage out of a renewable tech, it's not in their interests to fund studies if they could give the wrong answers. That's the reality of it. Biofuel was a good case in point, it's proponents are now back peddling pretty fast. The drive to profit forbids foresight.

You can add diesel cars, electric cars, and CFD, LED bulbs to that list too.

Why would cash being invested "cause high inflation"?

Inflation depends on a number factors, whether it be productivity, supply, unemployment, etc, or how that cash is being spent. If it's being invested, who's to say it isn't in capital goods, thereby reducing cost of goods?

I reckon it's a pithy statement the finance news is prone to making, and requires further elaboration.

It's clear to us all when one says there is a bubble in housing, but this doesn't make much sense, and may well on further elaboration be found to be nonsense!

If one were to be treating cash an as investment, i.e. in a savings account, then one would think a cash bubble would be where you're getting a relatively good return, and were the bubble to burst, the return would collapse. That's clearly not the case now: cash returns little or a loss (interest - inflation).

And in terms of its value, rather than its return, well it's been losing value there too, relative to stocks and housing. So hard to see a bubble there either.

> Humans have to evolve

No, we don't. We are in power of our own destiny. We don't have to create a race of robot humanoids. There is nothing inevitable about any of this.

> Duh. We don't know how the brain works yet. A big chunk of The Singularity is Near deals with how we build that understanding. Once we know how the brain works, computing will take advantage.

That's not what I hear. The singularity-is-near proponents argue that understanding the brain is unnecessary, and that there are short-cuts, whether it be trial-and-error, big data approaches, or neural networks. Otherwise it's going to take a long long time to truly understand how it works and the Singularity-won't-be-so-near.

The industry was pretty regional back then, which may make for a fuzzier historical record. U.S. insularity means some histories neglect this, and assume what's true for the U.S. held true elsewhere (which is a safer assumption today).

Interesting that the author says the 1200 "seemed to rule" in the UK in early 90's. Why didn't it succeed elsewhere? It seemed powerful and good value at the time.

Can't counter these points other than that what else is there to automate AWS infrastructure? Terraform suffers all these problems, too.

This is effectively the 'dry-run' feature that has been sought for a long long time [1], and led me to switch to Terraform (which does do this amongst other key differences) . Why did it take so damn long to implement?

I do appreciate it has come about eventually. Terraform has its foibles (and stupid half-declarative language) but it would take further improvements to consider going back to CF.

[1] https://forums.aws.amazon.com/thread.jspa?messageID=563929&#...

What makes it "a tax haven in its own right"? Is it subject to different taxation than the rest of London or the UK?

This clearly is much more about Tower, consultancy, etc, than their main product, but their yaml encoded language is an abomination; masquerading as 'declarative' and easy to read, yet piling on loops and conditional statements and an unintuitive inheritance tree of global and local variables.

I'd argue, in this regard, there is nothing qualitatively different about being an IT worker compared to any other occupation or any other time under capitalism. Marx never considered labour power to be a purely physical act. Otherwise technology alone would be a source of value, too. Of course, we are the only source of value because of our innate creativity, our ideas; our hands or interaction with others, merely sets it in motion.

Because it's clear the person he's responding to understood that relationship. If he'd bothered to read all four sentences, it's clear he meant he wasn't sure why yields would rise if the Fed would react by buying bonds.

More specifically I've noticed less reliance on configuration management frameworks like puppet and chef.

If you're building a container cloud, consisting of 'immutable' servers and a scheduler like kubernetes, then there's not much of a role left for one. You might use the lightweight versions (e.g. chef-solo) to bootstrap the servers, bake an AMI (or god forbid a container image). And you'll use something like cloudformation or terraform to configure the cloud. But if I'm going to toe the immutable infrastructure line I'm not going to use a config mgmt tool to update the state of my existing servers.

I gave up on SDNs and fell back to doing what anyone does without an SDN: published ports to the host interface and advertised the endpoint <host_ip>:<container_port> to etcd. Note this wasn't with kubernetes but with a similar system. Still reliant on etcd, which I wasn't happy with, but one less cog to go wrong.

Flannel relies on etcd. I had stability issues with v1 of etcd which meant flannel couldn't route packets. Since then, the idea of using an immature SDN atop an immature distributed key value store fills me with dread.

> It means that when you build Docker containers, it makes good sense to install a CM tool and use it to do the systems configuration.

If you belong to the "one container, one process" camp, I'd say CM has little utility.

Let's say we have a redis image. Using a CM I'd have to:

  * install ruby and various ruby lib pkgs
  * install chef or puppet, and a multitude of rubygems 
  * add recipes/manifests

My image is now several times bigger than it need be, and the configuration is now more opaque, in several files. It's a pain to debug and troubleshoot when something deep inside the recesses of chef-solo fails. And why would I?

I'd rather have a dockerfile with `apt-get update && apt-get install -y redis-server` and perhaps a line adding a custom config file. Very readable.

What's the difference between bad luck and "we just don't know"?

Modern housing on the continent is far superior to that in the UK (and I like carpets!).

There were standards on house building which assured a minimum floor area which were later abandoned. The UK now has the smallest homes in Europe. The windows are tiny, and the materials are cheap.

I agree turn-of-the-century housing was generally generously proportioned, and well built, and stand the test of time. And the housing that followed up to 1940s, even the austere housing that followed in the 50s wasn't bad either. But from the 60s onwards the quality took a nose dive (there are some good quality social housing complexes), and the puny mock victorian 80s and 90s houses are the worst examples.

This is a great book on the subject: http://en.wikipedia.org/wiki/A_Guide_to_the_New_Ruins_of_Gre...

I'd be interested to hear why the UK took a turn for the worse, and other places didn't (or perhaps they did to a lesser degree). Belgium is similarly cramped but seems to continue to build good proportioned housing.

How about getting outside? The days are shorter and there is less light but we get outdoors far less than previous generations. That will be a contributor to light deprivation and S.A.D.

There's nothing inherently wrong with winter. If you're willing to make time for a lightbox in the morning, you can make time for a lunchtime stroll and get outdoors at the weekend.

The persistence can follow the DB container:

https://github.com/leg100/docker-ebs-attach

You'll need three fleet units in total:

  - one to attach the EBS volume (wrapping the above container)
  - one to mount the device to a directory on the host
  - one to run the DB container, with a bind mount to the host directory

If the CoreOS host terminates, the cluster will reschedule the units to another host.

> As for the slowing of innovation. No. I am fairly positive the rate of innovation is increasing at an exponential rate just like it's always been.

The rate of innovation has not always increased at an 'exponential' rate. Why should it? No one would seriously suggest the rate of innovation has always increased since the year dot, in a proportionately upward curve. History has shown that we are quite capable are going backwards, forgetting previous advances, and and then relearning from the ancients (such as your steam engine).

The author is arguing innovation has slowed to a crawl. Many of the advances you've listed have their origins in breakthroughs made some time ago.

I'd also debate the degree to which many of those are genuine advances. What seems like a great shiny achievement now may be considered foolish or irrelevant in hindsight.

Progress is indeed amazing. But how do you know it is progress, or a greater or lesser progress than before?

At the time of the crisis they were listed on the stock market and then put into 'conservatorship'.

They bought mortgages and resold them on as mortgaged-backed securities, presumably to a mix of US and foreign entities.

Facile indeed, full of loose talk.

> and the only effect will be to devalue the yen, if anyone cares, which they don't.

So if the yen is devalued to $0.0000001 they won't care? With what will they pay for imported oil? Japan might prefer a weaker currency; not worthless, but stable. Many japanese entities have foreign denominated debts, and exporters also rely on imports in some form.

> Everyone knows it's unpayable, if it had to actually be repaid, which it doesn't.

The national debt of any country is not expected to be repaid. Japan is no different. Nor is the Japan the only country writing a bunch of cheques to itself. That's the essence of QE.

Japan is heavily in debt. Were they to write off that debt overnight, it would still be heavily in debt because the write-off would show up in the accounts of the bond-holders, many of whom would be made insolvent. Foreign entities would then refuse to trade with Japan. You'd merely be taking from one hand and giving to the other. There's no trickery or matrices, there's nothing unreal about any of this. The accounting practices may be absurd, but there is real value at stake, and destroying it is to be avoided, not posed as a solution.

Chef/Puppet are typically used for managing servers. Using them to configure the SSH client configuration on your laptop is very likely overkill.

This falls more within the terrain of orchestration rather than config mgmt. You might want to rely on your munging your SSH config rather than something more elaborate like "knife ssh", fabric, mcollective, salt, etc.

Paramiko [1] parses SSH configs, but Emre's lib is an improvement as it also updates configs.

[1] http://www.lag.net/paramiko/docs/paramiko.SSHConfig-class.ht...

Coming off the gold standard was probably the correct monetary policy at the time. But one cannot correlate the ending of deflation with a 'recovery', especially one that is sustainable and not at the expense of others (i.e. those who left the gold standard later; if a country devalues its currency it would see an 'immediate recovery', but really it's a case of taking from one hand and giving to another).

Furthermore, it may be that looser monetary policy went hand in hand with war production in leading a recovery. Convertibility was often suspended in previous wars to help finance them.

There's no consensus on this matter.