unikernels?

[glen ropella]

On 08/11/2015 08:36 PM, Steve Smith wrote:
> I'm surprised *anything* bores the living crap out of you!

What's not so boring is that Nick's crap _is_ alive!  But he may have the cause and effect reversed:

  https://www.mvppt.com/can-the-bacteria-in-your-gut-explain-your-mood/

> micro-organisms in the gut tickle a sensory nerve ending in the fingerlike protrusion lining the intestine and carry that electrical impulse up the vagus nerve and into the deep-brain structures thought to be responsible for elemental emotions like anxiety.

Perhaps being bored doesn't get the living crap out of you.  Perhaps the living crap causes your boredom. 8^)

--
⇒⇐ glen e. p. ropella



============================================================
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]

Glen -

Are you trying to "chap my a**" ?

I *knew* I could depend on you to suss out another level of meaning in
any words I used ;)  Much appreciated!

The article leaves me wondering two things:
     Does NASA study this stuff as well?  Seems like space colonization
might hinge on this... keeping a healthy microbiome in a microgravity
and overly sterile environment.
     Are *we* a key part of the microbiome of the planet?   It seems
like *we* are an essential element of the "living crap" of mother earth
and our "virulent" destruction of other species and habitat even for
ourselves, might have similar implications. Though I suppose that the
analogy might be better with the "skin biome"?

In any case, maybe someone should dose Nick's coffee with a fresh
innoculant?  This might be an important reason to attend FriAM, to
maintain a healthily compatible "collective biome" by "shooting the
shit" in person?   I do sometimes imagine ourselves (on this e-mail
list) as Asimov's Solarians in our "Splendid Isolation", communicating
via "Holograms"...

     http://asimov.wikia.com/wiki/Solaria

- Steve
> On 08/11/2015 08:36 PM, Steve Smith wrote:
>> I'm surprised *anything* bores the living crap out of you!
> What's not so boring is that Nick's crap _is_ alive!  But he may have the cause and effect reversed:
>
>    https://www.mvppt.com/can-the-bacteria-in-your-gut-explain-your-mood/
>
>> micro-organisms in the gut tickle a sensory nerve ending in the fingerlike protrusion lining the intestine and carry that electrical impulse up the vagus nerve and into the deep-brain structures thought to be responsible for elemental emotions like anxiety.
> Perhaps being bored doesn't get the living crap out of you.  Perhaps the living crap causes your boredom. 8^)
>


============================================================
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 08/12/2015 08:49 AM, Steve Smith wrote:
>      Are *we* a key part of the microbiome of the planet?   It seems like *we* are an essential element of the "living crap" of mother earth and our "virulent" destruction of other species and habitat even for ourselves, might have similar implications. Though I suppose that the analogy might be better with the "skin biome"?

Well, there is this:

The human gut microbiome as a transporter of antibiotic resistance genes between continents
http://aac.asm.org/content/early/2015/08/04/AAC.00933-15.abstract

--
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

[Nick Thompson]

Dear FRIAM,

 

I apologize for this REPLY TO ALL error.  I was actually reaching out to Owen about an old private argument concerning what was appropriate for FRIAM.  I hope you all will forgive me. 

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Nick Thompson [mailto:[hidden email]]
Sent: Tuesday, August 11, 2015 9:58 PM
To: 'The Friday Morning Applied Complexity Coffee Group' <[hidden email]>
Subject: RE: [FRIAM] [EXTERNAL] Re: unikernels?

 

Hi Owen,

 

How’s your summer.

 

I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me.  But I am not threatening to pick up my marbles and go home. 

 

I think it’s in the nature of things.  They are multitalented bores.  Polybores, we might call them.  I guess being a polybore is the other side of being a polymath. 

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [mailto:[hidden email]] On Behalf Of Owen Densmore
Sent: Tuesday, August 11, 2015 7:41 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels?

 

Thanks! Fascinating.

 

   -- Owen

 

On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <[hidden email]> wrote:

  The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin.  The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker.  The articles predict that the future is unikernels.  A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app.  At least two of the current unikernel projects use functional languages - OCaml and Haskell.  The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor.  In theory, this makes for greater efficiency and less chance of the tail wagging the dog.  By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature.   That means all of the vulnerabilities as well as all the features that are not used.

 

  As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application.

 

  The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables.  In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild.  Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before.

 

The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises.  The UX will not be different for the end-user although it might be somewhat better for the content provider.

 

  It's not clear to me that the visionaries have thought about this outside of the WWW.  For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption.  They started with their standard server and added SSL - the performance hit made that impractical.  Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable.  A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software.  But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix.  Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs.  But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible.

 

  The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change.  The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel.  That latter means there will be performance hits - how bad those will be is TBD.

 

Ray Parks
Consilient Heuristician/IDART Old-Timer
V: <a href="tel:[phone]" target="_blank">505-844-4024  M: <a href="tel:[phone]" target="_blank">505-238-9359  P: <a href="tel:[phone]" target="_blank">505-951-6084

 

On Aug 11, 2015, at 3:25 PM, Owen Densmore wrote:

 

I'm so outta this conversation!

 

Could one of us give a brief explanation of unikernels and the related tech being discussed?

 

On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella <[hidden email]> wrote:

OK.  But what I'm still missing is this:  if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit.  I.e. one dev environment for many deployables.  We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled.  And that may even have multiple layers, meta-meta.

So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective.  I.e. "closeness" in terms of automation doesn't necessarily mean "closeness" in terms of total cost of attack.

It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result.  I'd expect a lot more failed integration/deployment attempts if my devops process was modified.

But this is all too abstract, of course.  The devil is in the particulars.


On 08/11/2015 01:13 PM, Parks, Raymond wrote:

   I would expect the dev environment to be closer if not actually in the same hypervisor.  It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site.  Right now, with devops, the dev environment is probably not in the cloud/hypervisor.  And, for unikernels that may also be true.  But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud.

   In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server.  While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server.  From my standpoint, that means I can attack the production server directly or the development server on a separate network.  There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment.

   In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM.  The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old.

   One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity.  In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM.  In traditional environments, the attacker might need to assume the privileges of several entities.

 

--
glen ep ropella -- <a href="tel:[phone]" target="_blank">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

 

============================================================
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

[Nick Thompson]

Thank you, Glen, for your indulgence.  

I take a pill every day that has 5 billion of those little suckers in it.    Think of that.  Each one with its own world view.

Nick

Nicholas S. Thompson
Emeritus Professor of Psychology and Biology
Clark University
http://home.earthlink.net/~nickthompson/naturaldesigns/

-----Original Message-----
From: Friam [mailto:[hidden email]] On Behalf Of glen
Sent: Wednesday, August 12, 2015 10:43 AM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: Re: [FRIAM] A PolyMath by any other name...

On 08/11/2015 08:36 PM, Steve Smith wrote:
> I'm surprised *anything* bores the living crap out of you!

What's not so boring is that Nick's crap _is_ alive!  But he may have the cause and effect reversed:

  https://www.mvppt.com/can-the-bacteria-in-your-gut-explain-your-mood/

> micro-organisms in the gut tickle a sensory nerve ending in the fingerlike protrusion lining the intestine and carry that electrical impulse up the vagus nerve and into the deep-brain structures thought to be responsible for elemental emotions like anxiety.

Perhaps being bored doesn't get the living crap out of you.  Perhaps the living crap causes your boredom. 8^)

--
⇒⇐ glen e. p. ropella



============================================================
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

[Roger Critchlow-2]

Okay, resurrecting this four plus year old discussion because it matched a search for vagus.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5807379/#B20 reports that electrical stimulation of the outer ear can stimulate the vagus nerve and has positive results for treating depression.  It's hitting a spot that acupuncture uses to treat depression.

-- rec --

On Thu, Aug 13, 2015 at 11:22 AM Nick Thompson <[hidden email]> wrote:

Steve,

 

Thank you for not chastising me, as I surely deserved.  I want to take this opportunity to renew my apology to the list. 

 

If you asked me to think deeply, I would say that boredom is actually one of those things that is in the eye of the beholder.  A person who is bored by a topic is just a person without the resources or energy to find what is interesting about it. 

 

Obviously I, the pot, who has been known the regale this list with commentary on Elevated Mixed Layers, should not be calling any pots black. 

 

Thanks, Steve, as always, for your good will.

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [mailto:[hidden email]] On Behalf Of Steve Smith
Sent: Tuesday, August 11, 2015 11:36 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: [FRIAM] A PolyMath by any other name...

 

Nick!

I'm surprised *anything* bores the living crap out of you!  I hear tell of you staring for hours at water swirling down a drain, considering the philosophical and psychological implications of such,  and even more hours listening to the squawks of Ravens!

That said,  I have to say that Marcus' and Glen's conversation here was far enough above my head that I can't imagine finding the time to noodle out enough of the reserved lexicon to do more than gape at it awkwardly.  

I have a good friend who is a former AstroPhysicist who has reinvented himself a few times as a High Performance Simulation Scientist, then Virtual Reality Researcher, then Nueroscience Researcher.  He is definitely a PolyBore to anyone without experience or interest in those fields, but the hoot of it all is that one of his best and oldest collaborators has stuck with "Applied Math" for 50 years and he calls HIM a "MathHole"... they are finishing up a multi-year book project on their theory of Neural Function based in Category Theory.  I suspect even people who Neurophysiology and Category Theory find them Polybores!

I do like the duality of PolyMath/PolyBore... we might have more than a few such creatures here on this list! 

- Steve

Hi Owen,

 

How’s your summer.

 

I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me.  But I am not threatening to pick up my marbles and go home. 

 

I think it’s in the nature of things.  They are multitalented bores.  Polybores, we might call them.  I guess being a polybore is the other side of being a polymath. 

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [[hidden email]] On Behalf Of Owen Densmore
Sent: Tuesday, August 11, 2015 7:41 PM
To: The Friday Morning Applied Complexity Coffee Group [hidden email]
Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels?

 

Thanks! Fascinating.

 

   -- Owen

 

On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <[hidden email]> wrote:

  The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin.  The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker.  The articles predict that the future is unikernels.  A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app.  At least two of the current unikernel projects use functional languages - OCaml and Haskell.  The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor.  In theory, this makes for greater efficiency and less chance of the tail wagging the dog.  By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature.   That means all of the vulnerabilities as well as all the features that are not used.

 

  As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application.

 

  The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables.  In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild.  Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before.

 

The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises.  The UX will not be different for the end-user although it might be somewhat better for the content provider.

 

  It's not clear to me that the visionaries have thought about this outside of the WWW.  For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption.  They started with their standard server and added SSL - the performance hit made that impractical.  Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable.  A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software.  But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix.  Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs.  But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible.

 

  The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change.  The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel.  That latter means there will be performance hits - how bad those will be is TBD.

 

Ray Parks
Consilient Heuristician/IDART Old-Timer
V: <a href="tel:[phone]" target="_blank">505-844-4024  M: <a href="tel:[phone]" target="_blank">505-238-9359  P: <a href="tel:[phone]" target="_blank">505-951-6084

 

On Aug 11, 2015, at 3:25 PM, Owen Densmore wrote:

I'm so outta this conversation!

 

Could one of us give a brief explanation of unikernels and the related tech being discussed?

 

On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella <[hidden email]> wrote:

OK.  But what I'm still missing is this:  if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit.  I.e. one dev environment for many deployables.  We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled.  And that may even have multiple layers, meta-meta.

So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective.  I.e. "closeness" in terms of automation doesn't necessarily mean "closeness" in terms of total cost of attack.

It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result.  I'd expect a lot more failed integration/deployment attempts if my devops process was modified.

But this is all too abstract, of course.  The devil is in the particulars.


On 08/11/2015 01:13 PM, Parks, Raymond wrote:

   I would expect the dev environment to be closer if not actually in the same hypervisor.  It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site.  Right now, with devops, the dev environment is probably not in the cloud/hypervisor.  And, for unikernels that may also be true.  But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud.

   In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server.  While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server.  From my standpoint, that means I can attack the production server directly or the development server on a separate network.  There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment.

   In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM.  The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old.

   One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity.  In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM.  In traditional environments, the attacker might need to assume the privileges of several entities.

 

--
glen ep ropella -- <a href="tel:[phone]" target="_blank">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

 

============================================================
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

 

This body part will be downloaded on demand.

 

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

[Frank Wimberly-2]

Bruce, do you receive this list?

On Mon, Dec 30, 2019, 2:04 PM Roger Critchlow <[hidden email]> wrote:

Okay, resurrecting this four plus year old discussion because it matched a search for vagus.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5807379/#B20 reports that electrical stimulation of the outer ear can stimulate the vagus nerve and has positive results for treating depression.  It's hitting a spot that acupuncture uses to treat depression.

-- rec --

On Thu, Aug 13, 2015 at 11:22 AM Nick Thompson <[hidden email]> wrote:

Steve,

 

Thank you for not chastising me, as I surely deserved.  I want to take this opportunity to renew my apology to the list. 

 

If you asked me to think deeply, I would say that boredom is actually one of those things that is in the eye of the beholder.  A person who is bored by a topic is just a person without the resources or energy to find what is interesting about it. 

 

Obviously I, the pot, who has been known the regale this list with commentary on Elevated Mixed Layers, should not be calling any pots black. 

 

Thanks, Steve, as always, for your good will.

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [mailto:[hidden email]] On Behalf Of Steve Smith
Sent: Tuesday, August 11, 2015 11:36 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: [FRIAM] A PolyMath by any other name...

 

Nick!

I'm surprised *anything* bores the living crap out of you!  I hear tell of you staring for hours at water swirling down a drain, considering the philosophical and psychological implications of such,  and even more hours listening to the squawks of Ravens!

That said,  I have to say that Marcus' and Glen's conversation here was far enough above my head that I can't imagine finding the time to noodle out enough of the reserved lexicon to do more than gape at it awkwardly.  

I have a good friend who is a former AstroPhysicist who has reinvented himself a few times as a High Performance Simulation Scientist, then Virtual Reality Researcher, then Nueroscience Researcher.  He is definitely a PolyBore to anyone without experience or interest in those fields, but the hoot of it all is that one of his best and oldest collaborators has stuck with "Applied Math" for 50 years and he calls HIM a "MathHole"... they are finishing up a multi-year book project on their theory of Neural Function based in Category Theory.  I suspect even people who Neurophysiology and Category Theory find them Polybores!

I do like the duality of PolyMath/PolyBore... we might have more than a few such creatures here on this list! 

- Steve

Hi Owen,

 

How’s your summer.

 

I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me.  But I am not threatening to pick up my marbles and go home. 

 

I think it’s in the nature of things.  They are multitalented bores.  Polybores, we might call them.  I guess being a polybore is the other side of being a polymath. 

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [[hidden email]] On Behalf Of Owen Densmore
Sent: Tuesday, August 11, 2015 7:41 PM
To: The Friday Morning Applied Complexity Coffee Group [hidden email]
Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels?

 

Thanks! Fascinating.

 

   -- Owen

 

On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <[hidden email]> wrote:

  The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin.  The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker.  The articles predict that the future is unikernels.  A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app.  At least two of the current unikernel projects use functional languages - OCaml and Haskell.  The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor.  In theory, this makes for greater efficiency and less chance of the tail wagging the dog.  By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature.   That means all of the vulnerabilities as well as all the features that are not used.

 

  As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application.

 

  The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables.  In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild.  Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before.

 

The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises.  The UX will not be different for the end-user although it might be somewhat better for the content provider.

 

  It's not clear to me that the visionaries have thought about this outside of the WWW.  For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption.  They started with their standard server and added SSL - the performance hit made that impractical.  Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable.  A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software.  But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix.  Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs.  But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible.

 

  The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change.  The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel.  That latter means there will be performance hits - how bad those will be is TBD.

 

Ray Parks
Consilient Heuristician/IDART Old-Timer
V: <a href="tel:[phone]" target="_blank" rel="noreferrer">505-844-4024  M: <a href="tel:[phone]" target="_blank" rel="noreferrer">505-238-9359  P: <a href="tel:[phone]" target="_blank" rel="noreferrer">505-951-6084

 

On Aug 11, 2015, at 3:25 PM, Owen Densmore wrote:

I'm so outta this conversation!

 

Could one of us give a brief explanation of unikernels and the related tech being discussed?

 

On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella <[hidden email]> wrote:

OK.  But what I'm still missing is this:  if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit.  I.e. one dev environment for many deployables.  We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled.  And that may even have multiple layers, meta-meta.

So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective.  I.e. "closeness" in terms of automation doesn't necessarily mean "closeness" in terms of total cost of attack.

It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result.  I'd expect a lot more failed integration/deployment attempts if my devops process was modified.

But this is all too abstract, of course.  The devil is in the particulars.


On 08/11/2015 01:13 PM, Parks, Raymond wrote:

   I would expect the dev environment to be closer if not actually in the same hypervisor.  It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site.  Right now, with devops, the dev environment is probably not in the cloud/hypervisor.  And, for unikernels that may also be true.  But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud.

   In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server.  While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server.  From my standpoint, that means I can attack the production server directly or the development server on a separate network.  There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment.

   In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM.  The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old.

   One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity.  In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM.  In traditional environments, the attacker might need to assume the privileges of several entities.

 

--
glen ep ropella -- <a href="tel:[phone]" target="_blank" rel="noreferrer">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

 

============================================================
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

 

This body part will be downloaded on demand.

 

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

[Marcus G. Daniels]

https://www.cbsnews.com/news/psychedelic-drugs-lsd-active-agent-in-magic-mushrooms-to-treat-addiction-depression-anxiety-60-minutes-2019-12-29/

---

From: Friam <[hidden email]> on behalf of Roger Critchlow <[hidden email]>
Sent: Monday, December 30, 2019 2:04 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: Re: [FRIAM] A PolyMath by any other name...

 

Okay, resurrecting this four plus year old discussion because it matched a search for vagus.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5807379/#B20 reports that electrical stimulation of the outer ear can stimulate the vagus nerve and has positive results for treating depression.  It's hitting a spot that acupuncture uses to treat depression.

-- rec --

On Thu, Aug 13, 2015 at 11:22 AM Nick Thompson <[hidden email]> wrote:

Steve,

 

Thank you for not chastising me, as I surely deserved.  I want to take this opportunity to renew my apology to the list. 

 

If you asked me to think deeply, I would say that boredom is actually one of those things that is in the eye of the beholder.  A person who is bored by a topic is just a person without the resources or energy to find what is interesting about it. 

 

Obviously I, the pot, who has been known the regale this list with commentary on Elevated Mixed Layers, should not be calling any pots black. 

 

Thanks, Steve, as always, for your good will.

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [mailto:[hidden email]] On Behalf Of Steve Smith
Sent: Tuesday, August 11, 2015 11:36 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: [FRIAM] A PolyMath by any other name...

 

Nick!

I'm surprised *anything* bores the living crap out of you!  I hear tell of you staring for hours at water swirling down a drain, considering the philosophical and psychological implications of such,  and even more hours listening to the squawks of Ravens!

That said,  I have to say that Marcus' and Glen's conversation here was far enough above my head that I can't imagine finding the time to noodle out enough of the reserved lexicon to do more than gape at it awkwardly.  

I have a good friend who is a former AstroPhysicist who has reinvented himself a few times as a High Performance Simulation Scientist, then Virtual Reality Researcher, then Nueroscience Researcher.  He is definitely a PolyBore to anyone without experience or interest in those fields, but the hoot of it all is that one of his best and oldest collaborators has stuck with "Applied Math" for 50 years and he calls HIM a "MathHole"... they are finishing up a multi-year book project on their theory of Neural Function based in Category Theory.  I suspect even people who Neurophysiology and Category Theory find them Polybores!

I do like the duality of PolyMath/PolyBore... we might have more than a few such creatures here on this list! 

- Steve

Hi Owen,

 

How’s your summer.

 

I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me.  But I am not threatening to pick up my marbles and go home. 

 

I think it’s in the nature of things.  They are multitalented bores.  Polybores, we might call them.  I guess being a polybore is the other side of being a polymath. 

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [[hidden email]] On Behalf Of Owen Densmore
Sent: Tuesday, August 11, 2015 7:41 PM
To: The Friday Morning Applied Complexity Coffee Group [hidden email]
Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels?

 

Thanks! Fascinating.

 

   -- Owen

 

On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <[hidden email]> wrote:

  The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin.  The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker.  The articles predict that the future is unikernels.  A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app.  At least two of the current unikernel projects use functional languages - OCaml and Haskell.  The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor.  In theory, this makes for greater efficiency and less chance of the tail wagging the dog.  By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature.   That means all of the vulnerabilities as well as all the features that are not used.

 

  As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application.

 

  The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables.  In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild.  Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before.

 

The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises.  The UX will not be different for the end-user although it might be somewhat better for the content provider.

 

  It's not clear to me that the visionaries have thought about this outside of the WWW.  For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption.  They started with their standard server and added SSL - the performance hit made that impractical.  Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable.  A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software.  But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix.  Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs.  But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible.

 

  The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change.  The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel.  That latter means there will be performance hits - how bad those will be is TBD.

 

Ray Parks
Consilient Heuristician/IDART Old-Timer
V: <a href="tel:[phone]" target="_blank">505-844-4024  M: <a href="tel:[phone]" target="_blank"> 505-238-9359  P: <a href="tel:[phone]" target="_blank">505-951-6084

 

On Aug 11, 2015, at 3:25 PM, Owen Densmore wrote:

I'm so outta this conversation!

 

Could one of us give a brief explanation of unikernels and the related tech being discussed?

 

On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella <[hidden email]> wrote:

OK.  But what I'm still missing is this:  if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit.  I.e. one dev environment for many deployables.  We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled.  And that may even have multiple layers, meta-meta.

So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective.  I.e. "closeness" in terms of automation doesn't necessarily mean "closeness" in terms of total cost of attack.

It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result.  I'd expect a lot more failed integration/deployment attempts if my devops process was modified.

But this is all too abstract, of course.  The devil is in the particulars.


On 08/11/2015 01:13 PM, Parks, Raymond wrote:

   I would expect the dev environment to be closer if not actually in the same hypervisor.  It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site.  Right now, with devops, the dev environment is probably not in the cloud/hypervisor.  And, for unikernels that may also be true.  But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud.

   In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server.  While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server.  From my standpoint, that means I can attack the production server directly or the development server on a separate network.  There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment.

   In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM.  The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old.

   One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity.  In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM.  In traditional environments, the attacker might need to assume the privileges of several entities.

 

--
glen ep ropella -- <a href="tel:[phone]" target="_blank">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

 

============================================================
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

 

This body part will be downloaded on demand.

 

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

[Steve Smith]

I believe that Bruce (if you mean Sherwood) went AWOL from this list, expatriating to WedTech when it was formed (5 or more years ago?), along with a few others.  I heard rumors of a contingent getting overly tired of our endless philosophical maunderings here, in favor of a more "actionable" set of discussions, whether it be CS/Tech details or "good places to eat/plumb/roof/get-drunk in Santa Fe", etc.    I try to keep my own endless blather on esoteric topics on this list rather than our sister WedTech, but am not terribly disciplined about such things.   I could be wrong, Bruce (and others I assume expatriated) might well be lurking here...  

PolyBores R' US!

Bruce, do you receive this list?

On Mon, Dec 30, 2019, 2:04 PM Roger Critchlow <[hidden email]> wrote:

Okay, resurrecting this four plus year old discussion because it matched a search for vagus.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5807379/#B20 reports that electrical stimulation of the outer ear can stimulate the vagus nerve and has positive results for treating depression.  It's hitting a spot that acupuncture uses to treat depression.

-- rec --

On Thu, Aug 13, 2015 at 11:22 AM Nick Thompson <[hidden email]> wrote:

Steve,

 

Thank you for not chastising me, as I surely deserved.  I want to take this opportunity to renew my apology to the list. 

 

If you asked me to think deeply, I would say that boredom is actually one of those things that is in the eye of the beholder.  A person who is bored by a topic is just a person without the resources or energy to find what is interesting about it. 

 

Obviously I, the pot, who has been known the regale this list with commentary on Elevated Mixed Layers, should not be calling any pots black. 

 

Thanks, Steve, as always, for your good will.

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [mailto:[hidden email]] On Behalf Of Steve Smith
Sent: Tuesday, August 11, 2015 11:36 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: [FRIAM] A PolyMath by any other name...

 

Nick!

I'm surprised *anything* bores the living crap out of you!  I hear tell of you staring for hours at water swirling down a drain, considering the philosophical and psychological implications of such,  and even more hours listening to the squawks of Ravens!

That said,  I have to say that Marcus' and Glen's conversation here was far enough above my head that I can't imagine finding the time to noodle out enough of the reserved lexicon to do more than gape at it awkwardly.  

I have a good friend who is a former AstroPhysicist who has reinvented himself a few times as a High Performance Simulation Scientist, then Virtual Reality Researcher, then Nueroscience Researcher.  He is definitely a PolyBore to anyone without experience or interest in those fields, but the hoot of it all is that one of his best and oldest collaborators has stuck with "Applied Math" for 50 years and he calls HIM a "MathHole"... they are finishing up a multi-year book project on their theory of Neural Function based in Category Theory.  I suspect even people who Neurophysiology and Category Theory find them Polybores!

I do like the duality of PolyMath/PolyBore... we might have more than a few such creatures here on this list! 

- Steve

Hi Owen,

 

How’s your summer.

 

I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me.  But I am not threatening to pick up my marbles and go home. 

 

I think it’s in the nature of things.  They are multitalented bores.  Polybores, we might call them.  I guess being a polybore is the other side of being a polymath. 

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [[hidden email]] On Behalf Of Owen Densmore
Sent: Tuesday, August 11, 2015 7:41 PM
To: The Friday Morning Applied Complexity Coffee Group [hidden email]
Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels?

 

Thanks! Fascinating.

 

   -- Owen

 

On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <[hidden email]> wrote:

  The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin.  The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker.  The articles predict that the future is unikernels.  A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app.  At least two of the current unikernel projects use functional languages - OCaml and Haskell.  The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor.  In theory, this makes for greater efficiency and less chance of the tail wagging the dog.  By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature.   That means all of the vulnerabilities as well as all the features that are not used.

 

  As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application.

 

  The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables.  In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild.  Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before.

 

The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises.  The UX will not be different for the end-user although it might be somewhat better for the content provider.

 

  It's not clear to me that the visionaries have thought about this outside of the WWW.  For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption.  They started with their standard server and added SSL - the performance hit made that impractical.  Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable.  A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software.  But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix.  Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs.  But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible.

 

  The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change.  The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel.  That latter means there will be performance hits - how bad those will be is TBD.

 

Ray Parks
Consilient Heuristician/IDART Old-Timer
V: <a href="tel:[phone]" target="_blank" rel="noreferrer" moz-do-not-send="true">505-844-4024  M: <a href="tel:[phone]" target="_blank" rel="noreferrer" moz-do-not-send="true">505-238-9359  P: <a href="tel:[phone]" target="_blank" rel="noreferrer" moz-do-not-send="true">505-951-6084

 

On Aug 11, 2015, at 3:25 PM, Owen Densmore wrote:

I'm so outta this conversation!

 

Could one of us give a brief explanation of unikernels and the related tech being discussed?

 

On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella <[hidden email]> wrote:

OK.  But what I'm still missing is this:  if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit.  I.e. one dev environment for many deployables.  We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled.  And that may even have multiple layers, meta-meta.

So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective.  I.e. "closeness" in terms of automation doesn't necessarily mean "closeness" in terms of total cost of attack.

It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result.  I'd expect a lot more failed integration/deployment attempts if my devops process was modified.

But this is all too abstract, of course.  The devil is in the particulars.


On 08/11/2015 01:13 PM, Parks, Raymond wrote:

   I would expect the dev environment to be closer if not actually in the same hypervisor.  It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site.  Right now, with devops, the dev environment is probably not in the cloud/hypervisor.  And, for unikernels that may also be true.  But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud.

   In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server.  While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server.  From my standpoint, that means I can attack the production server directly or the development server on a separate network.  There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment.

   In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM.  The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old.

   One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity.  In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM.  In traditional environments, the attacker might need to assume the privileges of several entities.

 

--
glen ep ropella -- <a href="tel:[phone]" target="_blank" rel="noreferrer" moz-do-not-send="true">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

 

============================================================
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

 

This body part will be downloaded on demand.

 

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

[Frank Wimberly-2]

No I meant Bruce Simon.  He works for a company that makes devices that treat depression and migraines by stimulating the vagus nerve electrically.

Frsnk

On Mon, Dec 30, 2019, 2:31 PM Steven A Smith <[hidden email]> wrote:

I believe that Bruce (if you mean Sherwood) went AWOL from this list, expatriating to WedTech when it was formed (5 or more years ago?), along with a few others.  I heard rumors of a contingent getting overly tired of our endless philosophical maunderings here, in favor of a more "actionable" set of discussions, whether it be CS/Tech details or "good places to eat/plumb/roof/get-drunk in Santa Fe", etc.    I try to keep my own endless blather on esoteric topics on this list rather than our sister WedTech, but am not terribly disciplined about such things.   I could be wrong, Bruce (and others I assume expatriated) might well be lurking here...  

PolyBores R' US!

Bruce, do you receive this list?

On Mon, Dec 30, 2019, 2:04 PM Roger Critchlow <[hidden email]> wrote:

Okay, resurrecting this four plus year old discussion because it matched a search for vagus.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5807379/#B20 reports that electrical stimulation of the outer ear can stimulate the vagus nerve and has positive results for treating depression.  It's hitting a spot that acupuncture uses to treat depression.

-- rec --

On Thu, Aug 13, 2015 at 11:22 AM Nick Thompson <[hidden email]> wrote:

Steve,

 

Thank you for not chastising me, as I surely deserved.  I want to take this opportunity to renew my apology to the list. 

 

If you asked me to think deeply, I would say that boredom is actually one of those things that is in the eye of the beholder.  A person who is bored by a topic is just a person without the resources or energy to find what is interesting about it. 

 

Obviously I, the pot, who has been known the regale this list with commentary on Elevated Mixed Layers, should not be calling any pots black. 

 

Thanks, Steve, as always, for your good will.

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [mailto:[hidden email]] On Behalf Of Steve Smith
Sent: Tuesday, August 11, 2015 11:36 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: [FRIAM] A PolyMath by any other name...

 

Nick!

I'm surprised *anything* bores the living crap out of you!  I hear tell of you staring for hours at water swirling down a drain, considering the philosophical and psychological implications of such,  and even more hours listening to the squawks of Ravens!

That said,  I have to say that Marcus' and Glen's conversation here was far enough above my head that I can't imagine finding the time to noodle out enough of the reserved lexicon to do more than gape at it awkwardly.  

I have a good friend who is a former AstroPhysicist who has reinvented himself a few times as a High Performance Simulation Scientist, then Virtual Reality Researcher, then Nueroscience Researcher.  He is definitely a PolyBore to anyone without experience or interest in those fields, but the hoot of it all is that one of his best and oldest collaborators has stuck with "Applied Math" for 50 years and he calls HIM a "MathHole"... they are finishing up a multi-year book project on their theory of Neural Function based in Category Theory.  I suspect even people who Neurophysiology and Category Theory find them Polybores!

I do like the duality of PolyMath/PolyBore... we might have more than a few such creatures here on this list! 

- Steve

Hi Owen,

 

How’s your summer.

 

I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me.  But I am not threatening to pick up my marbles and go home. 

 

I think it’s in the nature of things.  They are multitalented bores.  Polybores, we might call them.  I guess being a polybore is the other side of being a polymath. 

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [[hidden email]] On Behalf Of Owen Densmore
Sent: Tuesday, August 11, 2015 7:41 PM
To: The Friday Morning Applied Complexity Coffee Group [hidden email]
Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels?

 

Thanks! Fascinating.

 

   -- Owen

 

On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <[hidden email]> wrote:

  The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin.  The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker.  The articles predict that the future is unikernels.  A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app.  At least two of the current unikernel projects use functional languages - OCaml and Haskell.  The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor.  In theory, this makes for greater efficiency and less chance of the tail wagging the dog.  By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature.   That means all of the vulnerabilities as well as all the features that are not used.

 

  As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application.

 

  The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables.  In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild.  Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before.

 

The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises.  The UX will not be different for the end-user although it might be somewhat better for the content provider.

 

  It's not clear to me that the visionaries have thought about this outside of the WWW.  For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption.  They started with their standard server and added SSL - the performance hit made that impractical.  Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable.  A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software.  But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix.  Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs.  But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible.

 

  The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change.  The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel.  That latter means there will be performance hits - how bad those will be is TBD.

 

Ray Parks
Consilient Heuristician/IDART Old-Timer
V: <a href="tel:[phone]" rel="noreferrer noreferrer" target="_blank">505-844-4024  M: <a href="tel:[phone]" rel="noreferrer noreferrer" target="_blank">505-238-9359  P: <a href="tel:[phone]" rel="noreferrer noreferrer" target="_blank">505-951-6084

 

On Aug 11, 2015, at 3:25 PM, Owen Densmore wrote:

I'm so outta this conversation!

 

Could one of us give a brief explanation of unikernels and the related tech being discussed?

 

On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella <[hidden email]> wrote:

OK.  But what I'm still missing is this:  if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit.  I.e. one dev environment for many deployables.  We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled.  And that may even have multiple layers, meta-meta.

So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective.  I.e. "closeness" in terms of automation doesn't necessarily mean "closeness" in terms of total cost of attack.

It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result.  I'd expect a lot more failed integration/deployment attempts if my devops process was modified.

But this is all too abstract, of course.  The devil is in the particulars.


On 08/11/2015 01:13 PM, Parks, Raymond wrote:

   I would expect the dev environment to be closer if not actually in the same hypervisor.  It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site.  Right now, with devops, the dev environment is probably not in the cloud/hypervisor.  And, for unikernels that may also be true.  But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud.

   In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server.  While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server.  From my standpoint, that means I can attack the production server directly or the development server on a separate network.  There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment.

   In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM.  The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old.

   One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity.  In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM.  In traditional environments, the attacker might need to assume the privileges of several entities.

 

--
glen ep ropella -- <a href="tel:[phone]" rel="noreferrer noreferrer" target="_blank">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

 

============================================================
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

 

This body part will be downloaded on demand.

 

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

[thompnickson2]

OUCH!

 

The person who said the internet is forever sure knew a thing.

 

Why we need to resurrect these posts, in particular, is unclear to me. Suffice it to say, I cannot recreate the context in which I would say such nasty things so nastily.  But the evidence that I did is overwhelming.  So.  All I can do is apologize again.  I have learned so much over the years from talking with glen and marcus.  Much of what they talk about is still foreign to me, but in the last year I feel I am understanding more, and would hate to have that channel gummed up by digging up this trash. 

 

But that is the consequence of having said stupid things; one is thereafter and forever dependent upon the grace and maturity of others. 

 

Nick

 

Nicholas Thompson

Emeritus Professor of Ethology and Psychology

Clark University

[hidden email]

https://wordpress.clarku.edu/nthompson/

 

 

From: Friam <[hidden email]> On Behalf Of Roger Critchlow
Sent: Monday, December 30, 2019 2:04 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: Re: [FRIAM] A PolyMath by any other name...

 

Okay, resurrecting this four plus year old discussion because it matched a search for vagus.

 

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5807379/#B20 reports that electrical stimulation of the outer ear can stimulate the vagus nerve and has positive results for treating depression.  It's hitting a spot that acupuncture uses to treat depression.

 

-- rec --

 

On Thu, Aug 13, 2015 at 11:22 AM Nick Thompson <[hidden email]> wrote:

Steve,

 

Thank you for not chastising me, as I surely deserved.  I want to take this opportunity to renew my apology to the list. 

 

If you asked me to think deeply, I would say that boredom is actually one of those things that is in the eye of the beholder.  A person who is bored by a topic is just a person without the resources or energy to find what is interesting about it. 

 

Obviously I, the pot, who has been known the regale this list with commentary on Elevated Mixed Layers, should not be calling any pots black. 

 

Thanks, Steve, as always, for your good will.

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [mailto:[hidden email]] On Behalf Of Steve Smith
Sent: Tuesday, August 11, 2015 11:36 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: [FRIAM] A PolyMath by any other name...

 

Nick!

I'm surprised *anything* bores the living crap out of you!  I hear tell of you staring for hours at water swirling down a drain, considering the philosophical and psychological implications of such,  and even more hours listening to the squawks of Ravens!

That said,  I have to say that Marcus' and Glen's conversation here was far enough above my head that I can't imagine finding the time to noodle out enough of the reserved lexicon to do more than gape at it awkwardly.  

I have a good friend who is a former AstroPhysicist who has reinvented himself a few times as a High Performance Simulation Scientist, then Virtual Reality Researcher, then Nueroscience Researcher.  He is definitely a PolyBore to anyone without experience or interest in those fields, but the hoot of it all is that one of his best and oldest collaborators has stuck with "Applied Math" for 50 years and he calls HIM a "MathHole"... they are finishing up a multi-year book project on their theory of Neural Function based in Category Theory.  I suspect even people who Neurophysiology and Category Theory find them Polybores!

I do like the duality of PolyMath/PolyBore... we might have more than a few such creatures here on this list! 

- Steve

Hi Owen,

 

How’s your summer.

 

I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me.  But I am not threatening to pick up my marbles and go home. 

 

I think it’s in the nature of things.  They are multitalented bores.  Polybores, we might call them.  I guess being a polybore is the other side of being a polymath. 

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [[hidden email]] On Behalf Of Owen Densmore
Sent: Tuesday, August 11, 2015 7:41 PM
To: The Friday Morning Applied Complexity Coffee Group [hidden email]
Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels?

 

Thanks! Fascinating.

 

   -- Owen

 

On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <[hidden email]> wrote:

  The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin.  The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker.  The articles predict that the future is unikernels.  A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app.  At least two of the current unikernel projects use functional languages - OCaml and Haskell.  The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor.  In theory, this makes for greater efficiency and less chance of the tail wagging the dog.  By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature.   That means all of the vulnerabilities as well as all the features that are not used.

 

  As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application.

 

  The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables.  In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild.  Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before.

 

The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises.  The UX will not be different for the end-user although it might be somewhat better for the content provider.

 

  It's not clear to me that the visionaries have thought about this outside of the WWW.  For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption.  They started with their standard server and added SSL - the performance hit made that impractical.  Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable.  A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software.  But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix.  Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs.  But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible.

 

  The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change.  The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel.  That latter means there will be performance hits - how bad those will be is TBD.

 

Ray Parks
Consilient Heuristician/IDART Old-Timer
V: <a href="tel:[phone]" target="_blank">505-844-4024  M: <a href="tel:[phone]" target="_blank">505-238-9359  P: <a href="tel:[phone]" target="_blank">505-951-6084

 

On Aug 11, 2015, at 3:25 PM, Owen Densmore wrote:

I'm so outta this conversation!

 

Could one of us give a brief explanation of unikernels and the related tech being discussed?

 

On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella <[hidden email]> wrote:

OK.  But what I'm still missing is this:  if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit.  I.e. one dev environment for many deployables.  We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled.  And that may even have multiple layers, meta-meta.

So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective.  I.e. "closeness" in terms of automation doesn't necessarily mean "closeness" in terms of total cost of attack.

It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result.  I'd expect a lot more failed integration/deployment attempts if my devops process was modified.

But this is all too abstract, of course.  The devil is in the particulars.


On 08/11/2015 01:13 PM, Parks, Raymond wrote:

   I would expect the dev environment to be closer if not actually in the same hypervisor.  It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site.  Right now, with devops, the dev environment is probably not in the cloud/hypervisor.  And, for unikernels that may also be true.  But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud.

   In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server.  While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server.  From my standpoint, that means I can attack the production server directly or the development server on a separate network.  There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment.

   In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM.  The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old.

   One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity.  In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM.  In traditional environments, the attacker might need to assume the privileges of several entities.

 

--
glen ep ropella -- <a href="tel:[phone]" target="_blank">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

 

============================================================
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

 

This body part will be downloaded on demand.

 

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

[Roger Critchlow-2]

I see I replied to the wrong strand of the thread, this was Glen's contribution to which I was replying.

On Wed, Aug 12, 2015 at 9:01 AM glen <[hidden email]> wrote:

On 08/11/2015 08:36 PM, Steve Smith wrote:
> I'm surprised *anything* bores the living crap out of you!

What's not so boring is that Nick's crap _is_ alive!  But he may have the cause and effect reversed:

  https://www.mvppt.com/can-the-bacteria-in-your-gut-explain-your-mood/

> micro-organisms in the gut tickle a sensory nerve ending in the fingerlike protrusion lining the intestine and carry that electrical impulse up the vagus nerve and into the deep-brain structures thought to be responsible for elemental emotions like anxiety.

Perhaps being bored doesn't get the living crap out of you.  Perhaps the living crap causes your boredom. 8^)

-- rec -- 

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

[Steve Smith]

Oh Nick!

 Let me "chastise" you again <grin>.   This was so far from trash (your original observation, my "chastisement", and your polite but unnecessary "apology").   I was, of course, friendly-teasing you about your use of the term "bored" while trying to acknowledge that PolyBores abound (esp. on this list) and "boredom" is very much in the eye of the bored-beholder. 

This list/meetup is going on 15-18 years old now... I'm too lazy/skeered to go look at the archives... and I don't know when I joined the list (or made my first meetup)... I think it was before I took a year's sabbatical in Berzerkely 2005/2006 as I think I remember making a "meetup" at St. Johns during a (re)visit to LANL during that year.   I have enjoyed watching the evolution of various character's characters on this list, including your own...   I think we met at that meetup but I didn't get to know you much at all until SfX days when you were noodling a lot about noodling and had (recently) written the MOTH paper with Guerin/Densmore...  

I am attracted to PolyBores, because/in-spite of their endless prattling on various pet topics...   the signal-noise ratio always seems low at first, but with enough listening (attentive as well as background) I eventually begin to learn the language of such individuals and can begin to at least speak a pidgin of sorts with them, or adopt the pidgin/creole I hear them speaking with another who I might be closer in spirit/language to.

I have off-list engagements with several from this list, some in person, others online, some professional, others personal and while those engagements have a much higher signal-noise ratio (because focused on mutually interesting topics and including specific attempts to meet halfway), the conversations here which I might not fully be able to follow (over my head, beyond my patience, outside my ken, etc) often "soften me up" for important/interesting conversations later on or in private.   We are on a good day, a "rich, living batch", a PolySpecies symbiotic colony of PolyMaths/PolyBores methinks.

I definitely hear you converging on more understanding  or at least more shared language with others here...  and your tireless pursuit of many topics Pearcian and otherwise, have provided both helpful "convergence" and "divergence" in the sense of annealing..  

It was a (mild) shock for me to hear my own "voice" here 4+ years old, but it was a reminder that we've been rattling on about the same things for years now!

Which reminds me of one of my favorite "They Might Be Giants" song-lyrics:

https://greatsong.net/PAROLES-THEY-MIGHT-BE-GIANTS,LUCKY-BALL-CHAIN,335311.html

I lost my lucky ball and chain
Now she's four years gone
Just five feet tall and sick of me
And all my rattling on

...

        I was young and foolish then,

        I am old and foolish now...

    ..

Carry On!

 - STeve

On 12/30/19 2:51 PM, [hidden email] wrote:

OUCH!

 

The person who said the internet is forever sure knew a thing.

 

Why we need to resurrect these posts, in particular, is unclear to me. Suffice it to say, I cannot recreate the context in which I would say such nasty things so nastily.  But the evidence that I did is overwhelming.  So.  All I can do is apologize again.  I have learned so much over the years from talking with glen and marcus.  Much of what they talk about is still foreign to me, but in the last year I feel I am understanding more, and would hate to have that channel gummed up by digging up this trash. 

 

But that is the consequence of having said stupid things; one is thereafter and forever dependent upon the grace and maturity of others. 

 

Nick

 

Nicholas Thompson

Emeritus Professor of Ethology and Psychology

Clark University

[hidden email]

https://wordpress.clarku.edu/nthompson/

 

 

From: Friam [hidden email] On Behalf Of Roger Critchlow
Sent: Monday, December 30, 2019 2:04 PM
To: The Friday Morning Applied Complexity Coffee Group [hidden email]
Subject: Re: [FRIAM] A PolyMath by any other name...

 

Okay, resurrecting this four plus year old discussion because it matched a search for vagus.

 

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5807379/#B20 reports that electrical stimulation of the outer ear can stimulate the vagus nerve and has positive results for treating depression.  It's hitting a spot that acupuncture uses to treat depression.

 

-- rec --

 

On Thu, Aug 13, 2015 at 11:22 AM Nick Thompson <[hidden email]> wrote:

Steve,

 

Thank you for not chastising me, as I surely deserved.  I want to take this opportunity to renew my apology to the list. 

 

If you asked me to think deeply, I would say that boredom is actually one of those things that is in the eye of the beholder.  A person who is bored by a topic is just a person without the resources or energy to find what is interesting about it. 

 

Obviously I, the pot, who has been known the regale this list with commentary on Elevated Mixed Layers, should not be calling any pots black. 

 

Thanks, Steve, as always, for your good will.

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [mailto:[hidden email]] On Behalf Of Steve Smith
Sent: Tuesday, August 11, 2015 11:36 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: [FRIAM] A PolyMath by any other name...

 

Nick!

I'm surprised *anything* bores the living crap out of you!  I hear tell of you staring for hours at water swirling down a drain, considering the philosophical and psychological implications of such,  and even more hours listening to the squawks of Ravens!

That said,  I have to say that Marcus' and Glen's conversation here was far enough above my head that I can't imagine finding the time to noodle out enough of the reserved lexicon to do more than gape at it awkwardly.  

I have a good friend who is a former AstroPhysicist who has reinvented himself a few times as a High Performance Simulation Scientist, then Virtual Reality Researcher, then Nueroscience Researcher.  He is definitely a PolyBore to anyone without experience or interest in those fields, but the hoot of it all is that one of his best and oldest collaborators has stuck with "Applied Math" for 50 years and he calls HIM a "MathHole"... they are finishing up a multi-year book project on their theory of Neural Function based in Category Theory.  I suspect even people who Neurophysiology and Category Theory find them Polybores!

I do like the duality of PolyMath/PolyBore... we might have more than a few such creatures here on this list! 

- Steve

Hi Owen,

 

How’s your summer.

 

I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me.  But I am not threatening to pick up my marbles and go home. 

 

I think it’s in the nature of things.  They are multitalented bores.  Polybores, we might call them.  I guess being a polybore is the other side of being a polymath. 

 

Nick

 

Nicholas S. Thompson

Emeritus Professor of Psychology and Biology

Clark University

http://home.earthlink.net/~nickthompson/naturaldesigns/

 

From: Friam [[hidden email]] On Behalf Of Owen Densmore
Sent: Tuesday, August 11, 2015 7:41 PM
To: The Friday Morning Applied Complexity Coffee Group [hidden email]
Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels?

 

Thanks! Fascinating.

 

   -- Owen

 

On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <[hidden email]> wrote:

  The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin.  The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker.  The articles predict that the future is unikernels.  A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app.  At least two of the current unikernel projects use functional languages - OCaml and Haskell.  The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor.  In theory, this makes for greater efficiency and less chance of the tail wagging the dog.  By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature.   That means all of the vulnerabilities as well as all the features that are not used.

 

  As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application.

 

  The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables.  In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild.  Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before.

 

The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises.  The UX will not be different for the end-user although it might be somewhat better for the content provider.

 

  It's not clear to me that the visionaries have thought about this outside of the WWW.  For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption.  They started with their standard server and added SSL - the performance hit made that impractical.  Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable.  A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software.  But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix.  Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs.  But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible.

 

  The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change.  The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel.  That latter means there will be performance hits - how bad those will be is TBD.

 

Ray Parks
Consilient Heuristician/IDART Old-Timer
V: <a href="tel:[phone]" target="_blank" moz-do-not-send="true">505-844-4024  M: <a href="tel:[phone]" target="_blank" moz-do-not-send="true">505-238-9359  P: <a href="tel:[phone]" target="_blank" moz-do-not-send="true">505-951-6084

 

On Aug 11, 2015, at 3:25 PM, Owen Densmore wrote:

I'm so outta this conversation!

 

Could one of us give a brief explanation of unikernels and the related tech being discussed?

 

On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella <[hidden email]> wrote:

OK.  But what I'm still missing is this:  if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit.  I.e. one dev environment for many deployables.  We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled.  And that may even have multiple layers, meta-meta.

So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective.  I.e. "closeness" in terms of automation doesn't necessarily mean "closeness" in terms of total cost of attack.

It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result.  I'd expect a lot more failed integration/deployment attempts if my devops process was modified.

But this is all too abstract, of course.  The devil is in the particulars.


On 08/11/2015 01:13 PM, Parks, Raymond wrote:

   I would expect the dev environment to be closer if not actually in the same hypervisor.  It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site.  Right now, with devops, the dev environment is probably not in the cloud/hypervisor.  And, for unikernels that may also be true.  But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud.

   In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server.  While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server.  From my standpoint, that means I can attack the production server directly or the development server on a separate network.  There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment.

   In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM.  The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old.

   One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity.  In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM.  In traditional environments, the attacker might need to assume the privileges of several entities.

 

--
glen ep ropella -- <a href="tel:[phone]" target="_blank" moz-do-not-send="true">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

 

============================================================
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

 

This body part will be downloaded on demand.

 

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

[Marcus G. Daniels]

https://vimeo.com/69181785

Eyeo2013 Ignite #12 - Kevin Slavin Toxoplasmosis vimeo.com

---

From: Friam <[hidden email]> on behalf of Roger Critchlow <[hidden email]>
Sent: Monday, December 30, 2019 3:14 PM
To: The Friday Morning Applied Complexity Coffee Group <[hidden email]>
Subject: Re: [FRIAM] A PolyMath by any other name...

 

I see I replied to the wrong strand of the thread, this was Glen's contribution to which I was replying.

On Wed, Aug 12, 2015 at 9:01 AM glen <[hidden email]> wrote:

On 08/11/2015 08:36 PM, Steve Smith wrote:
> I'm surprised *anything* bores the living crap out of you!

What's not so boring is that Nick's crap _is_ alive!  But he may have the cause and effect reversed:

  https://www.mvppt.com/can-the-bacteria-in-your-gut-explain-your-mood/

> micro-organisms in the gut tickle a sensory nerve ending in the fingerlike protrusion lining the intestine and carry that electrical impulse up the vagus nerve and into the deep-brain structures thought to be responsible for elemental emotions like anxiety.

Perhaps being bored doesn't get the living crap out of you.  Perhaps the living crap causes your boredom. 8^)

-- rec -- 

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

[gepr]

CONTENTS DELETED

The author has deleted this message.

[thompnickson2]

Thanks, Glen.  

I am particularly glad for your good humor because I have so valued your comments on some of what I have published.   Keep close a colleague who will read what you write.  There is no greater friend an academic can have.

Nick

Nicholas Thompson
Emeritus Professor of Ethology and Psychology
Clark University
[hidden email]
https://wordpress.clarku.edu/nthompson/
 


-----Original Message-----
From: Friam <[hidden email]> On Behalf Of u?l? ?
Sent: Monday, December 30, 2019 5:30 PM
To: FriAM <[hidden email]>
Subject: Re: [FRIAM] FW: A PolyMath by any other name...

You have *nothing* to apologize for. As Steve hinted, I suspect most, if not all, of us cringe a bit when reading our own stuff (or even hearing our own voice: https://www.theguardian.com/film/2019/dec/18/adam-driver-walk-out-interview-npr-fresh-air-voice). I have 3 stories explicitly related to the point: 1) Something I once wrote offended so many people, it earned me the nickname "Nazi", the story of which held a prominent place in my friend's PhD dissertation. 2) While supporting Swarm, something I wrote offended a person so much, they *demanded* an apology from the group. And 3) a good friend and mentor once called me a "digital austistic" due to my seeming insensitivity in online interaction versus my seeming sensitivity in meat space.

I won't tell any of those stories, here, to save y'all from yet another TMI share. But I can say I don't regret any of those utterings. Would I say them now? No. But that's precisely *because* they were learning experiences. The only thing that prevents learning experiences is the *lack* of engagement. So, as long as you stay engaged, then apologies are surplus sugar that none of us really need ... though some of us -- not me -- really like sugar. 8^)

On 12/30/19 2:19 PM, [hidden email] wrote:

> Here I am, renewing my apology for yet a third time, it seems.
>
> I was actually preaching my belief that we come to friam for different things, and nobody should try to dictate what FRIAM is about.  But I sure as hell had a strange way of putting it!  I am so grateful for Steve’s contemporary correction, which says precisely what I wish I had said.
>
> I have written to the list.  If I need to do anything more to regain
> your trust, please let me know.
>
> All the best, and thank you for your many insights, some of which are
> on matters I understand.
>
> I look forward to understanding more.

--
☣ uǝlƃ

============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove


============================================================
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
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove