[FRIAM] A PolyMath by any other name...
Steven A Smith
sasmyth at swcp.com
Mon Dec 30 16:30:54 EST 2019
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?
>
> -----------------------------------
> Frank Wimberly
>
> My memoir:
> https://www.amazon.com/author/frankwimberly
>
> My scientific publications:
> https://www.researchgate.net/profile/Frank_Wimberly2
>
> Phone (505) 670-9918
>
> On Mon, Dec 30, 2019, 2:04 PM Roger Critchlow <rec at elf.org
> <mailto:rec at elf.org>> 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
> <nickthompson at earthlink.net <mailto:nickthompson at earthlink.net>>
> 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:friam-bounces at redfish.com
> <mailto:friam-bounces at redfish.com>] *On Behalf Of *Steve Smith
> *Sent:* Tuesday, August 11, 2015 11:36 PM
> *To:* The Friday Morning Applied Complexity Coffee Group
> <friam at redfish.com <mailto:friam at redfish.com>>
> *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 [mailto:friam-bounces at redfish.com] *On Behalf
> Of *Owen Densmore
> *Sent:* Tuesday, August 11, 2015 7:41 PM
> *To:* The Friday Morning Applied Complexity Coffee Group
> <friam at redfish.com> <mailto:friam at redfish.com>
> *Subject:* Re: [FRIAM] [EXTERNAL] Re: unikernels?
>
>
>
> Thanks! Fascinating.
>
>
>
> -- Owen
>
>
>
> On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond
> <rcparks at sandia.gov <mailto:rcparks at sandia.gov>> 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: 505-844-4024 <tel:505-844-4024> M: 505-238-9359
> <tel:505-238-9359> P: 505-951-6084 <tel: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
> <gepr at tempusdictum.com
> <mailto:gepr at tempusdictum.com>> 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 -- 971-255-2847 <tel: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://redfish.com/pipermail/friam_redfish.com/attachments/20191230/6ce7c81d/attachment.html>
More information about the Friam
mailing list