NTY: Buy Apple gadgets, use Google services, buy media from Amazon

[Owen Densmore]

I came across this tweet advice on how to survive the next wave of tech extinction: 

Advice for NYT readers: Buy Apple gadgets, use Google services, buy media from Amazon.

Interesting if only they are jumping on the "digital ecology" bandwagon we've discussed here often.

But looking at my ecology: I buy Macs.  I primarily use Google services: mail, hangouts, calendar, groups, ...  And looking at our TV and our now completely digital music, we mainly use Amazon.  I was going to say they missed Dropbox as a 4th, but then Doh! .. DB is an Amazon S3/EC2 service.

Its not always easy.  Getting iTunes and Amazon finally is OK.  Getting Google Calendar, Mail and Contacts to integrate with OSX is harder.

Amazon seems to be the easiest: they make apps for integrating with everything, always with a web-app fallback.  And even my somewhat aging TV and new TiVo have direct to Amazon capabilities.

The real shock was when TiVo and the TV decided to have wireless remotes that worked on the iPhone.  Ditto for our Apple TV box.

What a triangle: Apple, Google, Amazon.  But it's true.  And the best defense is diversity.  How very complex!

   -- Owen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[glen ropella]

I would have (and do, actually) suggested the inverse: Don't buy Apple.
Don't use Google services.  And by Yog, never ever buy anything from
Amazon.  Survival is intimately linked to _not_ depending on these giant
abusive landmarks of homogeny/mediocrity ... I think. ;-)

But then, you're not talking about survival.  You're talking about the
persistence of consumerist tendencies through very mild changes in
infrastructure.  Perhaps "survival" is a euphemism?

On 02/12/2014 08:03 PM, Owen Densmore wrote:

> I came across this tweet advice on how to survive the next wave of tech
> extinction:
>
> Advice for NYT readers: Buy Apple gadgets, use Google services, buy media
> from Amazon<http://www.nytimes.com/2014/02/13/technology/personaltech/how-to-survive-the-next-wave-of-technology-extinction.html>
> .
>
>
> Interesting if only they are jumping on the "digital ecology" bandwagon
> we've discussed here often.
>
> But looking at my ecology: I buy Macs.  I primarily use Google services:
> mail, hangouts, calendar, groups, ...  And looking at our TV and our now
> completely digital music, we mainly use Amazon.  I was going to say they
> missed Dropbox as a 4th, but then Doh! .. DB is an Amazon S3/EC2 service.
>
> Its not always easy.  Getting iTunes and Amazon finally is OK.  Getting
> Google Calendar, Mail and Contacts to integrate with OSX is harder.
>
> Amazon seems to be the easiest: they make apps for integrating with
> everything, always with a web-app fallback.  And even my somewhat aging TV
> and new TiVo have direct to Amazon capabilities.
>
> The real shock was when TiVo and the TV decided to have wireless remotes
> that worked on the iPhone.  Ditto for our Apple TV box.
>
> What a triangle: Apple, Google, Amazon.  But it's true.  And the best
> defense is diversity.  How very complex!

--
⇒⇐ glen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Owen Densmore]

Good points.  But diversity?  Do you buy into that?

I certainly use services outside of Google.  Twitter mainly (have but don't use Facebook) but many forums which are not Google Groups.

I try to use cross platform apps where possible.  Sublime, for example, as a text editor. Chrome/Firefox.  Terminal w/ standard CLI. Dropbox (mac/windows/linux) for files. iOS apps that are cross platform for the most part, although my cant-live-without-it Italian dictionary is iOS only and they tell me that it's the best choice for their market. Possibly iOS folks are more willing to pay?  They seemed sincere. 

The article was about survival in a limited extent: how to deal with being jerked around by the demise of a popular service or platform.

How do you deal with it?  Could you teach a non-techie to follow your lead?  Would write down a simpler set of rules that are easy to follow?

   -- Owen

On Thu, Feb 13, 2014 at 11:37 AM, glen <[hidden email]> wrote:

I would have (and do, actually) suggested the inverse: Don't buy Apple.
Don't use Google services.  And by Yog, never ever buy anything from
Amazon.  Survival is intimately linked to _not_ depending on these giant
abusive landmarks of homogeny/mediocrity ... I think. ;-)

But then, you're not talking about survival.  You're talking about the
persistence of consumerist tendencies through very mild changes in
infrastructure.  Perhaps "survival" is a euphemism?

On 02/12/2014 08:03 PM, Owen Densmore wrote:
> I came across this tweet advice on how to survive the next wave of tech
> extinction:
>
> Advice for NYT readers: Buy Apple gadgets, use Google services, buy media

> from Amazon<http://www.nytimes.com/2014/02/13/technology/personaltech/how-to-survive-the-next-wave-of-technology-extinction.html>

> .
>
>
> Interesting if only they are jumping on the "digital ecology" bandwagon
> we've discussed here often.
>
> But looking at my ecology: I buy Macs.  I primarily use Google services:
> mail, hangouts, calendar, groups, ...  And looking at our TV and our now
> completely digital music, we mainly use Amazon.  I was going to say they
> missed Dropbox as a 4th, but then Doh! .. DB is an Amazon S3/EC2 service.
>
> Its not always easy.  Getting iTunes and Amazon finally is OK.  Getting
> Google Calendar, Mail and Contacts to integrate with OSX is harder.
>
> Amazon seems to be the easiest: they make apps for integrating with
> everything, always with a web-app fallback.  And even my somewhat aging TV
> and new TiVo have direct to Amazon capabilities.
>
> The real shock was when TiVo and the TV decided to have wireless remotes
> that worked on the iPhone.  Ditto for our Apple TV box.
>
> What a triangle: Apple, Google, Amazon.  But it's true.  And the best
> defense is diversity.  How very complex!

--

⇒⇐ glen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[glen ropella]

TL;DR -- but you asked...

Well, I was being purposefully provocative, of course.  When serious, I
advocate agnosticism.  Use everything as often as you can.

For me, it's less about diversity and more about core skills.  In my
experience (which is admittedly peculiar), the primary skill is the
ability to try something out, figure out the basic use cases, then move
on to the next tool.  If your purpose is to get something done, then use
the first tool you try/learn that actually works. Do the job; move on.
If, however, your purpose is to understand, then use as many tools as
you can, taken to the extent of some predefined test.

RE: platforms.  It seems to me platforms are primarily a way to avoid
learning, especially the more closed they are.  Ease of use is the bogey
man.  It's the scapegoat upon which all platform closures hang their
debt to society.  This is why I cringe when I hear things like "They
[Apple's devices] are also the easiest to learn to use and the most
durable."  This is antithetic to what I would teach a child.  If you
always/only use the easiest tools to use, then you're only hurting
yourself.  And you're setting yourself up to be exploited by nefarious
agents.

Sure, it's OK to (mostly) use easy to use tools... but only AFTER you've
become at least adequate at using the other tools in the same domain.
(In fact, anyone who claims something like OS X is the easiest or most
intuitive OS is just ASKING to be grilled about, say, the difference
between Gnome 3 and Unity.  And if they show _any_ hint that they know
those aren't operating systems, then we get to grill them on Plan 9 or
the Hurd ... or maybe VMS if I'm feeling generous.)  My point being that
ubiquity = ignorance.

If I were to try to write it down, it would read more like a book for
kindergarten.  Pay attention.  Poke everything that looks like it'll do
something when you poke it.  Don't be afraid to break it. Actually, try
to break it.  You learn more about a thing by learning what breaks it
than by doing what it's supposed to do.  ("Bending" is the real
cognitive target, of course. http://www.moogfest.com/circuit-bending)
You learn even more if you try to fix it after you broke it.

Anyway, my main point is that if you want to "survive" the next "mass
extinction" event, learn the _domains_ and their use cases.  The
devices/tools that implement the use cases are interchangeable and
largely irrelevant.



On 02/13/2014 11:49 AM, Owen Densmore wrote:

> Good points.  But diversity?  Do you buy into that?
>
> I certainly use services outside of Google.  Twitter mainly (have but don't
> use Facebook) but many forums which are not Google Groups.
>
> I try to use cross platform apps where possible.  Sublime, for example, as
> a text editor. Chrome/Firefox.  Terminal w/ standard CLI. Dropbox
> (mac/windows/linux) for files. iOS apps that are cross platform for the
> most part, although my cant-live-without-it Italian dictionary is iOS only
> and they tell me that it's the best choice for their market. Possibly iOS
> folks are more willing to pay?  They seemed sincere.
>
> The article was about survival in a limited extent: how to deal with being
> jerked around by the demise of a popular service or platform.
>
> How do you deal with it?  Could you teach a non-techie to follow your lead?
>  Would write down a simpler set of rules that are easy to follow?

--
⇒⇐ glen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Parks, Raymond]

What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power.

In terms closer to most on the list - programming in the scripting language du jour is fine for productivity, but just in case it falls out of fashion and loses support, you should be able to fall back on a HLL, and, just in case, assembly.

In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality.

Ray Parks

Consilient Heuristician/IDART Program Manager

V: 505-844-4024  M: 505-238-9359  P: 505-951-6084

NIPR: [hidden email]

SIPR: [hidden email] (send NIPR reminder)

JWICS: [hidden email] (send NIPR reminder)

On Feb 13, 2014, at 2:40 PM, glen wrote:

TL;DR -- but you asked...

Well, I was being purposefully provocative, of course.  When serious, I
advocate agnosticism.  Use everything as often as you can.

For me, it's less about diversity and more about core skills.  In my
experience (which is admittedly peculiar), the primary skill is the
ability to try something out, figure out the basic use cases, then move
on to the next tool.  If your purpose is to get something done, then use
the first tool you try/learn that actually works. Do the job; move on.
If, however, your purpose is to understand, then use as many tools as
you can, taken to the extent of some predefined test.

RE: platforms.  It seems to me platforms are primarily a way to avoid
learning, especially the more closed they are.  Ease of use is the bogey
man.  It's the scapegoat upon which all platform closures hang their
debt to society.  This is why I cringe when I hear things like "They
[Apple's devices] are also the easiest to learn to use and the most
durable."  This is antithetic to what I would teach a child.  If you
always/only use the easiest tools to use, then you're only hurting
yourself.  And you're setting yourself up to be exploited by nefarious
agents.

Sure, it's OK to (mostly) use easy to use tools... but only AFTER you've
become at least adequate at using the other tools in the same domain.
(In fact, anyone who claims something like OS X is the easiest or most
intuitive OS is just ASKING to be grilled about, say, the difference
between Gnome 3 and Unity.  And if they show _any_ hint that they know
those aren't operating systems, then we get to grill them on Plan 9 or
the Hurd ... or maybe VMS if I'm feeling generous.)  My point being that
ubiquity = ignorance.

If I were to try to write it down, it would read more like a book for
kindergarten.  Pay attention.  Poke everything that looks like it'll do
something when you poke it.  Don't be afraid to break it. Actually, try
to break it.  You learn more about a thing by learning what breaks it
than by doing what it's supposed to do.  ("Bending" is the real
cognitive target, of course. http://www.moogfest.com/circuit-bending)
You learn even more if you try to fix it after you broke it.

Anyway, my main point is that if you want to "survive" the next "mass
extinction" event, learn the _domains_ and their use cases.  The
devices/tools that implement the use cases are interchangeable and
largely irrelevant.



On 02/13/2014 11:49 AM, Owen Densmore wrote:

Good points.  But diversity?  Do you buy into that?

I certainly use services outside of Google.  Twitter mainly (have but don't

use Facebook) but many forums which are not Google Groups.

I try to use cross platform apps where possible.  Sublime, for example, as

a text editor. Chrome/Firefox.  Terminal w/ standard CLI. Dropbox

(mac/windows/linux) for files. iOS apps that are cross platform for the

most part, although my cant-live-without-it Italian dictionary is iOS only

and they tell me that it's the best choice for their market. Possibly iOS

folks are more willing to pay?  They seemed sincere.

The article was about survival in a limited extent: how to deal with being

jerked around by the demise of a popular service or platform.

How do you deal with it?  Could you teach a non-techie to follow your lead?

Would write down a simpler set of rules that are easy to follow?

--
⇒⇐ glen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[glen ropella]

On 02/17/2014 09:39 AM, Parks, Raymond wrote:
> In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality.

Precisely.

An additional point, though, is that "survival" across infrastructure
changes is similar to proof through isomorphism.  The objective is to
establish a kind of Platonic form (or "category") for any given set of
tools, then whatever tools you find lying about that are close enough to
that form will do just fine.  (Seriously. E.g. how is bandcamp.com
different from amazon.com?  Git vs. Mercurial?  Pinterest vs. Instagram?
 Boinc vs. Tidbit?  Cloud Foundry vs. Heroku?  Etc.) Of course, to think
this way is antithetic to what the hyperbole machines out there want you
to think.  I attribute the hype mostly to the venture capitalists and
their desire for 10-fold RoI exits (or at least the consumerist product
differentiation that drives our economy).  But it could easily be caused
by the same thing that causes our 2 party political system, something
like an addiction to convenient pigeon-holing.

--
⇒⇐ glen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Steve Smith]

On 2/17/14 10:39 AM, Parks, Raymond wrote:

What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power.

In terms closer to most on the list - programming in the scripting language du jour is fine for productivity, but just in case it falls out of fashion and loses support, you should be able to fall back on a HLL, and, just in case, assembly.

In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality.

My mystical version of this is that while it *is* "Turtles all the way Down", it is worth knowing the names of the Turtles.  I don't honestly expect people to do their development using "rod logic" but it might behoove any self-respecting hacker to actually  understand how such a thing *might* be done... just as Assembly/Machine language is a useful lower-level abstraction for understanding the basis for early HLL's like Fortran IV and ultimately Block Structured (F77 and C?) and then OO (C++/ObjC/Java/etc.)?   One *needn't* be proficient in these lower levels of abstraction, just *appreciative?* of how to get from one to another?

I'm just sayin'

Ray Parks

Consilient Heuristician/IDART Program Manager

V: 505-844-4024  M: 505-238-9359  P: 505-951-6084

NIPR: [hidden email]

SIPR: [hidden email] (send NIPR reminder)

JWICS: [hidden email] (send NIPR reminder)

On Feb 13, 2014, at 2:40 PM, glen wrote:

TL;DR -- but you asked...

Well, I was being purposefully provocative, of course.  When serious, I
advocate agnosticism.  Use everything as often as you can.

For me, it's less about diversity and more about core skills.  In my
experience (which is admittedly peculiar), the primary skill is the
ability to try something out, figure out the basic use cases, then move
on to the next tool.  If your purpose is to get something done, then use
the first tool you try/learn that actually works. Do the job; move on.
If, however, your purpose is to understand, then use as many tools as
you can, taken to the extent of some predefined test.

RE: platforms.  It seems to me platforms are primarily a way to avoid
learning, especially the more closed they are.  Ease of use is the bogey
man.  It's the scapegoat upon which all platform closures hang their
debt to society.  This is why I cringe when I hear things like "They
[Apple's devices] are also the easiest to learn to use and the most
durable."  This is antithetic to what I would teach a child.  If you
always/only use the easiest tools to use, then you're only hurting
yourself.  And you're setting yourself up to be exploited by nefarious
agents.

Sure, it's OK to (mostly) use easy to use tools... but only AFTER you've
become at least adequate at using the other tools in the same domain.
(In fact, anyone who claims something like OS X is the easiest or most
intuitive OS is just ASKING to be grilled about, say, the difference
between Gnome 3 and Unity.  And if they show _any_ hint that they know
those aren't operating systems, then we get to grill them on Plan 9 or
the Hurd ... or maybe VMS if I'm feeling generous.)  My point being that
ubiquity = ignorance.

If I were to try to write it down, it would read more like a book for
kindergarten.  Pay attention.  Poke everything that looks like it'll do
something when you poke it.  Don't be afraid to break it. Actually, try
to break it.  You learn more about a thing by learning what breaks it
than by doing what it's supposed to do.  ("Bending" is the real
cognitive target, of course. http://www.moogfest.com/circuit-bending)
You learn even more if you try to fix it after you broke it.

Anyway, my main point is that if you want to "survive" the next "mass
extinction" event, learn the _domains_ and their use cases.  The
devices/tools that implement the use cases are interchangeable and
largely irrelevant.



On 02/13/2014 11:49 AM, Owen Densmore wrote:

Good points.  But diversity?  Do you buy into that?

I certainly use services outside of Google.  Twitter mainly (have but don't

use Facebook) but many forums which are not Google Groups.

I try to use cross platform apps where possible.  Sublime, for example, as

a text editor. Chrome/Firefox.  Terminal w/ standard CLI. Dropbox

(mac/windows/linux) for files. iOS apps that are cross platform for the

most part, although my cant-live-without-it Italian dictionary is iOS only

and they tell me that it's the best choice for their market. Possibly iOS

folks are more willing to pay?  They seemed sincere.

The article was about survival in a limited extent: how to deal with being

jerked around by the demise of a popular service or platform.

How do you deal with it?  Could you teach a non-techie to follow your lead?

Would write down a simpler set of rules that are easy to follow?

--
⇒⇐ glen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Gary Schiltz-4]

On Feb 17, 2014, at 9:39 PM, Steve Smith <[hidden email]> wrote:
> On 2/17/14 10:39 AM, Parks, Raymond wrote:
>> What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power.
>>
>> In terms closer to most on the list - programming in the scripting language du jour is fine for productivity, but just in case it falls out of fashion and loses support, you should be able to fall back on a HLL, and, just in case, assembly.
>>
>> In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality.
> My mystical version of this is that while it *is* "Turtles all the way Down", it is worth knowing the names of the Turtles.  I don't honestly expect people to do their development using "rod logic" but it might behoove any self-respecting hacker to actually  understand how such a thing *might* be done... just as Assembly/Machine language is a useful lower-level abstraction for understanding the basis for early HLL's like Fortran IV and ultimately Block Structured (F77 and C?) and then OO (C++/ObjC/Java/etc.)?   One *needn't* be proficient in these lower levels of abstraction, just *appreciative?* of how to get from one to another?
>
> I'm just sayin’

I’m in violent agreement. While someone can drive a car without being an auto mechanic, I can’t really understand why anyone who drives a car wouldn’t want to at least understand the basics of internal combustion engines, automatic/manual transmissions, hybrid powertrains, and so on. Same with microprocessors, compilers, assembly language, high level languages, lambda calculus. I think that being a hacker is a state of mind that naturally wants to tear things apart to see how they work, and (hopefully) put them back together again. Maybe even put something new together just for the heck of it.
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Marcus G. Daniels]

On 2/17/14 7:54 PM, Gary Schiltz wrote:
> I think that being a hacker is a state of mind that naturally wants to
> tear things apart to see how they work, and (hopefully) put them back
> together again.
Java is an example of a language that can be compiled to be fast. When
Java isn't fast in the wild, various accusations get made like the
garbage collector is to blame (i.e. some other factor supposedly out of
that person's control that isn't just their own sloppy work and laziness
-- like, say, _making_ lots of garbage).  Of course, the individual who
is really to blame is the sort of person that does not have the mindset
you mention.  Nonetheless, Java is often`for' the person that wants to
be insulated from things, and is happy to work that way.

It's not about paying dues, or learning the right things or the right
way or bollocks like that.  It's about whether a developer insists to be
able to find answers when they ask questions about how things work, and
whether they are the sort of person that asks those questions at all.  
Developer communities that _like_ their constraints may be productive by
some measures, but IMO aren't, in the end, very interesting.

Marcus

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Carl Tollander]

What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power.

Well, I dunno.   Several points along these lines.

- What is foundational for one is not foundational for another.  As an example,  for drum music, I may worry a great deal about the welds on the tacks, the speed of sound in the wood, distribution of force laterally in a drum shell, various details about adhesives and even what they fed the cow that supplied the cowhide, but that doesn't necessarily make me a better drummer than somebody worried about kinesthesiology of the forarm and shoulder and how it relates to the mass and dimensions of their drumsticks.  

- Knowing too well what is apparently foundational may prevent you from innovating.   For example in wood joinery instead of cutting biscuits, I may know enough about epoxy strength to design a situation in which a bead of epoxy is its own biscuit and thus make a stronger joint that I would be able to if I had kept to wood joinery fundamentals.

- The ability to perform a task at all depends on the capabilities at hand.   In the power tool example, losing electricity does not necessarily mean one can effectively fall back to hand tools.   It such a case it may no longer be economical to perform the task at all, given alternatives.

- Then there's time.   One could of course say that flint knapping an obsidian hand axe from scratch will make you more proficient with a hand chisel.    At some point one has a task to do, a time constraint, and a power planer at hand.

That said, yes, its good to know some hand drafting before you get into CAD.  But "fundamentals" and "foundations" can be slippery concepts.

Carl

On 2/17/14, 10:39 AM, Parks, Raymond wrote:

What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power.

In terms closer to most on the list - programming in the scripting language du jour is fine for productivity, but just in case it falls out of fashion and loses support, you should be able to fall back on a HLL, and, just in case, assembly.

In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality.

Ray Parks

Consilient Heuristician/IDART Program Manager

V: 505-844-4024  M: 505-238-9359  P: 505-951-6084

NIPR: [hidden email]

SIPR: [hidden email] (send NIPR reminder)

JWICS: [hidden email] (send NIPR reminder)

On Feb 13, 2014, at 2:40 PM, glen wrote:

TL;DR -- but you asked...

Well, I was being purposefully provocative, of course.  When serious, I
advocate agnosticism.  Use everything as often as you can.

For me, it's less about diversity and more about core skills.  In my
experience (which is admittedly peculiar), the primary skill is the
ability to try something out, figure out the basic use cases, then move
on to the next tool.  If your purpose is to get something done, then use
the first tool you try/learn that actually works. Do the job; move on.
If, however, your purpose is to understand, then use as many tools as
you can, taken to the extent of some predefined test.

RE: platforms.  It seems to me platforms are primarily a way to avoid
learning, especially the more closed they are.  Ease of use is the bogey
man.  It's the scapegoat upon which all platform closures hang their
debt to society.  This is why I cringe when I hear things like "They
[Apple's devices] are also the easiest to learn to use and the most
durable."  This is antithetic to what I would teach a child.  If you
always/only use the easiest tools to use, then you're only hurting
yourself.  And you're setting yourself up to be exploited by nefarious
agents.

Sure, it's OK to (mostly) use easy to use tools... but only AFTER you've
become at least adequate at using the other tools in the same domain.
(In fact, anyone who claims something like OS X is the easiest or most
intuitive OS is just ASKING to be grilled about, say, the difference
between Gnome 3 and Unity.  And if they show _any_ hint that they know
those aren't operating systems, then we get to grill them on Plan 9 or
the Hurd ... or maybe VMS if I'm feeling generous.)  My point being that
ubiquity = ignorance.

If I were to try to write it down, it would read more like a book for
kindergarten.  Pay attention.  Poke everything that looks like it'll do
something when you poke it.  Don't be afraid to break it. Actually, try
to break it.  You learn more about a thing by learning what breaks it
than by doing what it's supposed to do.  ("Bending" is the real
cognitive target, of course. http://www.moogfest.com/circuit-bending)
You learn even more if you try to fix it after you broke it.

Anyway, my main point is that if you want to "survive" the next "mass
extinction" event, learn the _domains_ and their use cases.  The
devices/tools that implement the use cases are interchangeable and
largely irrelevant.



On 02/13/2014 11:49 AM, Owen Densmore wrote:

Good points.  But diversity?  Do you buy into that?

I certainly use services outside of Google.  Twitter mainly (have but don't

use Facebook) but many forums which are not Google Groups.

I try to use cross platform apps where possible.  Sublime, for example, as

a text editor. Chrome/Firefox.  Terminal w/ standard CLI. Dropbox

(mac/windows/linux) for files. iOS apps that are cross platform for the

most part, although my cant-live-without-it Italian dictionary is iOS only

and they tell me that it's the best choice for their market. Possibly iOS

folks are more willing to pay?  They seemed sincere.

The article was about survival in a limited extent: how to deal with being

jerked around by the demise of a popular service or platform.

How do you deal with it?  Could you teach a non-techie to follow your lead?

Would write down a simpler set of rules that are easy to follow?

--
⇒⇐ glen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Steve Smith]

Carl and others have made several good points...

What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power.

Well, I dunno.   Several points along these lines.

...

That said, yes, its good to know some hand drafting before you get into CAD.  But "fundamentals" and "foundations" can be slippery concepts.

I believe Marcus made some points about "paying dues" and other references to expectations "the group" has on the individual for being admitted into the "masters" category, as it were.

I tried to keep my own ideologizing down to "knowing the names of the Turtles (who are all the way down)" because as Carl points out, the fundamentals (acoustics in materials, material fabrication, kinesthesiology, etc.) are *all* fundamental and for the most part, it is possible to become "good" at the process without necessarily understanding all of that stuff, even if it is extremely interesting and useful to the geeks in the crowd.

Since Carl invoked Drumming over Programming which is overtly a more sensorial and perhaps spiritual activity (at least the way Carl does it?) it is worth noting that I believe there may even be some value in *NOT* knowing the technical fundamentals of the drums and the kinesthetics of the human body involved.   It may *add* to the mystical power of the experience to learn and practice it entirely "rote", coming to insights about the underlying processes and materials entirely from one's own direct experience without any formal explanations to draw from.

To be fair, there is probably a school of programming which is parallel...  I *do* remember a time for myself when the magic of code was mystical...  mostly as I learned the intricacies of debugging my own faulty logic and code-generation and of profiling and then algorithmic complexity, memory management, etc.    Had I had *more* formal training up front, it might have undermined that mystical experience of discovering so many things "the hard way".   So rather than "knowing the names of the turtles all the way down", I got to/had to make up names for them as I met them, and only later discover that they had been named many times already.

- Steve

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Marcus G. Daniels]

On 2/18/14 7:31 AM, Steve Smith wrote:

So rather than "knowing the names of the turtles all the way down", I got to/had to make up names for them as I met them, and only later discover that they had been named many times already.

It seems to me the folks that are given the names don't value the names.  Clearly there is value in standard language for technical communication, but harder for me to imagine being taught something but otherwise having no intuition for it.  I guess that's what many people expect, though?

Marcus

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

Well said Carl!

+1 for spending some time on the ‘fundamentals’  but also an acknowledgement that choosing the proper level of ‘fundamentals’ is also very important,  and indeed sometimes it is the outsider/maverick that makes new progress in a field just because they don’t know the ‘proper’ way to approach a problem.

—joshua

On Feb 17, 2014, at 11:46 PM, Carl Tollander <[hidden email]> wrote:

What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power.

Well, I dunno.   Several points along these lines.

- What is foundational for one is not foundational for another.  As an example,  for drum music, I may worry a great deal about the welds on the tacks, the speed of sound in the wood, distribution of force laterally in a drum shell, various details about adhesives and even what they fed the cow that supplied the cowhide, but that doesn't necessarily make me a better drummer than somebody worried about kinesthesiology of the forarm and shoulder and how it relates to the mass and dimensions of their drumsticks.  

- Knowing too well what is apparently foundational may prevent you from innovating.   For example in wood joinery instead of cutting biscuits, I may know enough about epoxy strength to design a situation in which a bead of epoxy is its own biscuit and thus make a stronger joint that I would be able to if I had kept to wood joinery fundamentals.

- The ability to perform a task at all depends on the capabilities at hand.   In the power tool example, losing electricity does not necessarily mean one can effectively fall back to hand tools.   It such a case it may no longer be economical to perform the task at all, given alternatives.

- Then there's time.   One could of course say that flint knapping an obsidian hand axe from scratch will make you more proficient with a hand chisel.    At some point one has a task to do, a time constraint, and a power planer at hand.

That said, yes, its good to know some hand drafting before you get into CAD.  But "fundamentals" and "foundations" can be slippery concepts.

Carl

On 2/17/14, 10:39 AM, Parks, Raymond wrote:

What I think I'm hearing from Glen is that while it's nice to use power-planers and router tables to shape wood, one should know how to use the right type of hand-plane, chisels, and scrapers in case you lose electric power.

In terms closer to most on the list - programming in the scripting language du jour is fine for productivity, but just in case it falls out of fashion and loses support, you should be able to fall back on a HLL, and, just in case, assembly.

In both of my examples, learning the more primitive methods means that one learns the foundational knowledge that makes using the modern methods easier and higher in quality.

Ray Parks

Consilient Heuristician/IDART Program Manager

V: 505-844-4024  M: 505-238-9359  P: 505-951-6084

NIPR: [hidden email]

SIPR: [hidden email] (send NIPR reminder)

JWICS: [hidden email] (send NIPR reminder)

On Feb 13, 2014, at 2:40 PM, glen wrote:

TL;DR -- but you asked...

Well, I was being purposefully provocative, of course.  When serious, I
advocate agnosticism.  Use everything as often as you can.

For me, it's less about diversity and more about core skills.  In my
experience (which is admittedly peculiar), the primary skill is the
ability to try something out, figure out the basic use cases, then move
on to the next tool.  If your purpose is to get something done, then use
the first tool you try/learn that actually works. Do the job; move on.
If, however, your purpose is to understand, then use as many tools as
you can, taken to the extent of some predefined test.

RE: platforms.  It seems to me platforms are primarily a way to avoid
learning, especially the more closed they are.  Ease of use is the bogey
man.  It's the scapegoat upon which all platform closures hang their
debt to society.  This is why I cringe when I hear things like "They
[Apple's devices] are also the easiest to learn to use and the most
durable."  This is antithetic to what I would teach a child.  If you
always/only use the easiest tools to use, then you're only hurting
yourself.  And you're setting yourself up to be exploited by nefarious
agents.

Sure, it's OK to (mostly) use easy to use tools... but only AFTER you've
become at least adequate at using the other tools in the same domain.
(In fact, anyone who claims something like OS X is the easiest or most
intuitive OS is just ASKING to be grilled about, say, the difference
between Gnome 3 and Unity.  And if they show _any_ hint that they know
those aren't operating systems, then we get to grill them on Plan 9 or
the Hurd ... or maybe VMS if I'm feeling generous.)  My point being that
ubiquity = ignorance.

If I were to try to write it down, it would read more like a book for
kindergarten.  Pay attention.  Poke everything that looks like it'll do
something when you poke it.  Don't be afraid to break it. Actually, try
to break it.  You learn more about a thing by learning what breaks it
than by doing what it's supposed to do.  ("Bending" is the real
cognitive target, of course. http://www.moogfest.com/circuit-bending)
You learn even more if you try to fix it after you broke it.

Anyway, my main point is that if you want to "survive" the next "mass
extinction" event, learn the _domains_ and their use cases.  The
devices/tools that implement the use cases are interchangeable and
largely irrelevant.



On 02/13/2014 11:49 AM, Owen Densmore wrote:

Good points.  But diversity?  Do you buy into that?

I certainly use services outside of Google.  Twitter mainly (have but don't

use Facebook) but many forums which are not Google Groups.

I try to use cross platform apps where possible.  Sublime, for example, as

a text editor. Chrome/Firefox.  Terminal w/ standard CLI. Dropbox

(mac/windows/linux) for files. iOS apps that are cross platform for the

most part, although my cant-live-without-it Italian dictionary is iOS only

and they tell me that it's the best choice for their market. Possibly iOS

folks are more willing to pay?  They seemed sincere.

The article was about survival in a limited extent: how to deal with being

jerked around by the demise of a popular service or platform.

How do you deal with it?  Could you teach a non-techie to follow your lead?

Would write down a simpler set of rules that are easy to follow?

--
⇒⇐ glen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[glen ropella]

The objective is not the essentialness or something borderline
metaphysical like that.  The objective is to do a job with _whatever_
tools you find lying about.  And to do that, you need to know enough
about the tools that do that job, and how they're used, so that you can:

a) use a different tool when you want/need to,
b) make your own tool when the ones lying about are inadequate, and
c) accomplish a slightly different task with a tool not designed for
that task.

The point is the category of use cases for the tools, the domain.  To
me, this is the heart of "survival" across infrastructure changes,
innovation, and everyday efficiency and efficacy.

--
⇒⇐ glen

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Steve Smith]

Marcus -

My father, for better or worse, wanted/needed huge swaths of well traveled territory to learn within.  He went from Boy Scouts to Navy to College to Civil Service, wearing uniforms much of that time, and learning (by rote) the many standard forms they presented.  It made him feel safe, it let him be useful/performing in places he otherwise might not have.  

Somehow that sent me in an opposite direction, appreciating the core tools, formalisms, methodologies not as an end, but as a means or more to the point, a beginning, a point of departure.

As I matured, I *did* discover that I was in fact often/usually (re)inventing as I went and as you so aptly point out, I'm thankful for having done so... the things I was "given" were never mine in the way the things I "created" or "discovered" were.  We are a curious species and maintaining/feeding that curiosity seems to be an important part of our nature.

I would say my father's curiosity was limited to exploring a vast landscape of things already laid out for him while mine was to blunder around in wildernesses often of my own making, only to discover that I was actually inside of a park so well groomed that at times it felt to be a wilderness...  early on, I resented discovering that my "inventions" were really "re-discoveries" but at some point, I began to appreciate that with some of them I was adding valuable nuances too. 

So rather than "knowing the names of the turtles all the way down", I got to/had to make up names for them as I met them, and only later discover that they had been named many times already.

It seems to me the folks that are given the names don't value the names.  Clearly there is value in standard language for technical communication, but harder for me to imagine being taught something but otherwise having no intuition for it.  I guess that's what many people expect, though?

Marcus

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Owen Densmore]

Who'd'a thought the initial post would make such an interesting conversation!  Love it.

   -- Owen

On Tue, Feb 18, 2014 at 11:52 AM, Steve Smith <[hidden email]> wrote:

Marcus -

My father, for better or worse, wanted/needed huge swaths of well traveled territory to learn within.  He went from Boy Scouts to Navy to College to Civil Service, wearing uniforms much of that time, and learning (by rote) the many standard forms they presented.  It made him feel safe, it let him be useful/performing in places he otherwise might not have.  

Somehow that sent me in an opposite direction, appreciating the core tools, formalisms, methodologies not as an end, but as a means or more to the point, a beginning, a point of departure.

As I matured, I *did* discover that I was in fact often/usually (re)inventing as I went and as you so aptly point out, I'm thankful for having done so... the things I was "given" were never mine in the way the things I "created" or "discovered" were.  We are a curious species and maintaining/feeding that curiosity seems to be an important part of our nature.

I would say my father's curiosity was limited to exploring a vast landscape of things already laid out for him while mine was to blunder around in wildernesses often of my own making, only to discover that I was actually inside of a park so well groomed that at times it felt to be a wilderness...  early on, I resented discovering that my "inventions" were really "re-discoveries" but at some point, I began to appreciate that with some of them I was adding valuable nuances too. 

So rather than "knowing the names of the turtles all the way down", I got to/had to make up names for them as I met them, and only later discover that they had been named many times already.

It seems to me the folks that are given the names don't value the names.  Clearly there is value in standard language for technical communication, but harder for me to imagine being taught something but otherwise having no intuition for it.  I guess that's what many people expect, though?

Marcus

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Parks, Raymond]

I understand what you're saying, Steve, and I respect you for doing things your way.  However, the practical engineer in me wants to scream whenever someone reinvents stupid ways to do things.  Right now, one of my biggest concerns is that smartphone apps are reinventing all of the stupid vulnerabilities that have been hammered out of web-servers (not that web-servers don't still have stupid vulnerabilities - just not the same ones).  Smart meters are reinventing all of the same stupid vulnerabilities that cable boxes have.  I suppose it's the difference between the engineering mindset and the scientific mindset.

Long ago, when I was working on a satellite project, one of the young scientists decided to build his own serial stack from the ground up.  Even in the early '90s, serial protocol stacks were building blocks available in standard libraries for PCs.  This curiosity and the time delay inherent to relearning all of the lessons of the previous thirty years meant the project was at risk of failure from delay.

Ray Parks

Consilient Heuristician/IDART Program Manager

V: 505-844-4024  M: 505-238-9359  P: 505-951-6084

NIPR: [hidden email]

SIPR: [hidden email] (send NIPR reminder)

JWICS: [hidden email] (send NIPR reminder)

On Feb 18, 2014, at 11:52 AM, Steve Smith wrote:

Marcus -

My father, for better or worse, wanted/needed huge swaths of well traveled territory to learn within.  He went from Boy Scouts to Navy to College to Civil Service, wearing uniforms much of that time, and learning (by rote) the many standard forms they presented.  It made him feel safe, it let him be useful/performing in places he otherwise might not have.  

Somehow that sent me in an opposite direction, appreciating the core tools, formalisms, methodologies not as an end, but as a means or more to the point, a beginning, a point of departure.

As I matured, I *did* discover that I was in fact often/usually (re)inventing as I went and as you so aptly point out, I'm thankful for having done so... the things I was "given" were never mine in the way the things I "created" or "discovered" were.  We are a curious species and maintaining/feeding that curiosity seems to be an important part of our nature.

I would say my father's curiosity was limited to exploring a vast landscape of things already laid out for him while mine was to blunder around in wildernesses often of my own making, only to discover that I was actually inside of a park so well groomed that at times it felt to be a wilderness...  early on, I resented discovering that my "inventions" were really "re-discoveries" but at some point, I began to appreciate that with some of them I was adding valuable nuances too. 

So rather than "knowing the names of the turtles all the way down", I got to/had to make up names for them as I met them, and only later discover that they had been named many times already.

It seems to me the folks that are given the names don't value the names.  Clearly there is value in standard language for technical communication, but harder for me to imagine being taught something but otherwise having no intuition for it.  I guess that's what many people expect, though?

Marcus

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Marcus G. Daniels]

On 2/20/14, 5:47 PM, Parks, Raymond wrote:
> However, the practical engineer in me wants to scream whenever someone
> reinvents stupid ways to do things.
It is indeed infuriating when someone makes no effort to learn about
what the state-of-the-art is and imposes their ignorance and
incompetence on other people.  Being curious and fearless (motivated
learning) is not the same thing as not-invented-here syndrome and being
stubbornly illiterate.

Marcus

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[Steve Smith]

Marcus/Ray -

I agree wholeheartedly with both of you.   I've encountered more than
enough of both NIH and stubborn re-invention, especially in the Academia
and the National Lab context.

This has been one of my biggest challenges as a mentor of young people
who have *plenty* of book learning but not much practical experience...
learning the balance between (motivated) learning and wasteful
re-invention.

I am *not* a trained engineer, though a few phases of my career I have
in fact done systems and software engineering.   I am *most* interested
in exploration, discovery, and innovation and try to arrange my work
life so that such activities *are* appropriate.

Many of my (re)inventions are relatively subtle (I think).   I was once
trying to expand on a set of graph analysis tools to do some consistent
comparison of complex graphs from a wide variety of disparate sources.  
No one graph library really had the full suite of tools I needed and
even within a given library, the actual execution complexity (space and
time) were not consistent. Where I had source to review, I discovered
(unsurprisingly) that the libraries were collections thrown together
from more than one source (multiple graduate projects by different
students?).    I even found some latent bugs in a few of them.   The
only way to get consistent results was to in fact re-implement these
algorithms.   This was well over 10 years ago before graph analysis
became so "en vogue".

What I tripped over in the process was the "Tree Heap" or "Treap"...  
but I didn't trip over it by doing research... i tripped over it by
*needing* a data structure that had those properties, so I ended up
building one from whole cloth... only to discover months later that such
an data structure had already been devised.   To add insult to injury, a
few years later, I was relating the story to a woman who had come to
work at LBL while I was there, and *she* was one of the original
discoverers/inventors of the Treap!   It is truly a small world.

To make this relevant to the discussion...  I don't think I could ever
have come to recognize the value of such a data structure if I *hadn't*
felt obliged to re-invent (re-implement?) a number of algorithms that
had already been implemented by others... to differing degrees of quality.

- Steve

> On 2/20/14, 5:47 PM, Parks, Raymond wrote:
>> However, the practical engineer in me wants to scream whenever
>> someone reinvents stupid ways to do things.
> It is indeed infuriating when someone makes no effort to learn about
> what the state-of-the-art is and imposes their ignorance and
> incompetence on other people.  Being curious and fearless (motivated
> learning) is not the same thing as not-invented-here syndrome and
> being stubbornly illiterate.
>
> Marcus
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com

[glen ep ropella]

On 02/21/2014 07:35 AM, Steve Smith wrote:
> To make this relevant to the discussion...  I don't think I could ever
> have come to recognize the value of such a data structure if I *hadn't*
> felt obliged to re-invent (re-implement?) a number of algorithms that
> had already been implemented by others... to differing degrees of quality.

The meat of the discussion lies in the person's (or organization's)
agility to change paths once prior work, or a better way regardless of
its source, is brought to light.  I recently had to characterize "agile"
software development in comparison to ... what? ... "large-scale,
entrenched process" to a CIO type who understands some of the economics,
but not the technologies.  Me being largely agnostic, trying to explain
the two to him in an informal setting proved more difficult than I would
have thought.  (Shows how often I talk to those types these days.)

In microcosm, the contrast isn't between engineer-types and
scientist-types, but between ... I don't know... authoritarian vs.
egalitarian(?) types.  I've met plenty of authoritarian scientist-types
and plenty of egalitarian engineer-types.  I've even met some certified
PEs who showed remarkable agility when shown a better way.  Actually,
"better" is loaded.  "More appropriate to the task at hand" is better
than "better".

--
glen ep ropella -- 971-255-2847

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com