Skip to main content

Meat production local versus export and why SHI will make it not matter any more...

From this blog post an interesting quote highlighted is:


it is twice as energy efficient for people in Britain to eat dairy products from New Zealand than from domestic producers. It is four times more energy efficient for them to eat lamb shipped from the other side of the world than it is to eat British lamb.

The main reason for this is one simple phrase from the economics of manufacturing:

Economies of scale.

New Zealand pretty much has defined industries around the lamb, they have massive herds and it is a big part of the economy as a result locally lamb is very cheap to produce. It is also over abundant there for the population, we means demand is low and that in turn means local pricing is low...local producers would have a glut if they don't export. Exporting is profitable since local producers can tie the price of export into the final distributor fees and those are padded on a bit before sitting in English meat stores, where lamb is much more rare...is not in abundance and there for greatly in demand to command a high price.

If we analyze any other produced good with few limited regions of production with out sized advantages to production we will see this type of advantage built in...how do we fix it?

Well, we are approaching a time (I say within 10 years) when our ability to produce high quality locally produced meat products will flatten the production playing field. Lamb grown in a sterile factory in England will be just as inexpensive to produce as lamb grown in New Zealand since the advantageous factors in the latter location that made natural grown lamb more efficient can be normalized away. However delivery cost will still make the latter over all more expensive. Thus final costs post production will be dissimilar in both places which would bias against export from one place being price competitive with locally grown product. So it simply won't happen. At least not at first, as delivery costs zero this will normalize but the localization of production movement I predict will happen ahead of the zero cost of distribution is achieved. This state will be reached when photovoltaic cells finally achieve cost parity with gas/coal...the idea of paying a provider to line in electricity will exceed the cost of purchasing panels and maintaining them over the life time of need...this will kill remote delivery in favor of ubiquitous self generation.

Much further down the road, I predict in about 40 years or so once we have fully autonomous humanoid robots with artificially intelligent minds we'll be able to have them take over the bulk of the physical tasks that we currently perform. Contrary to what many fear this will not be the tragedy to work that it may seem...humans will be able to profit from the labor of their robot work force (like slaves but minus the ethical issues) and pinch off more and more of the production loop. Homes that run from photovoltaic panels on the roof will eliminate electric and heating bills. Robots set to plant and harvest from personal plots will reduce the costs of produce in general and make much cheaper for humans to buy good produce, robots will drive delivery trucks (actually the trucks will BE robotic and will drive themselves), robots will mine for ore and work in the smelting factories that produce our goods. Robots will even design and repair other robots...as more and more are done by the robots at zero cost to us the more our existing wealth is maximized in it's efficiency. Eventually we will pinch off from the cycle entirely...with robots doing everything for us and requiring nothing from us to maintain the system, that is when we will reach full SHI (self healing infrastructure).

http://sent2null.blogspot.com/2011/07/coming-age-of-shi-self-healing.html

http://sent2null.blogspot.com/2011/09/how-approach-to-self-healing.html

Comments

Popular posts from this blog

On the idea of "world wide mush" resulting from "open" development models

A recent article posted in the Wall Street Journal posits that the collectivization of various types of goods or services created by the internet is long term a damaging trend for human societies.

http://online.wsj.com/article/SB10001424052748703481004574646402192953052.html

I think that the author misses truths that have been in place that show that collectivization is not a process that started with the internet but has been with us since we started inventing things.

It seems that Mr. Lanier is not properly defining the contexts under which different problems can benefit or suffer from collectivization. He speaks in general terms of the loss of the potential for creators to extract profit from their work but misses that this is and was true of human civilization since we first picked up a rock to use as a crude hammer. New things make old things obsolete and people MUST adapt to what is displaced (be it a former human performance of that task or use of an older product) so as to main…

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

Live Coding Exercises: How NOT to hire potentially Brilliant Engineers.

I've intimated this view before but, I abhor "live coding" exercises for engineering interviews and will never have them as part of any interview process I conduct. They are simply unrealistic to real world engineering in every possible way, they only test familiarity (or luck) with a tiny subset of solution methods to a specif subset of problems...that you either "nail" or get spectacularly wrong depending on who is observing you.

They are mostly entirely unfair to the candidate on top of the pressure of having a gun under them while coding, only in the most extreme cases is coding under the gun and that's just competitions where the code is far from real world engineering related...so why test for general coding ability with such tests?? Stupid.

I posit, it is significantly more effective to see examples of a candidates finished working code in the form of a project or projects they've created. How long it took some one to get some uber algorithm work…