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 <[email protected]> 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:[email protected]] *On Behalf Of *Steve > Smith > *Sent:* Tuesday, August 11, 2015 11:36 PM > *To:* The Friday Morning Applied Complexity Coffee Group < > [email protected]> > *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:[email protected] > <[email protected]>] *On Behalf Of *Owen Densmore > *Sent:* Tuesday, August 11, 2015 7:41 PM > *To:* The Friday Morning Applied Complexity Coffee Group > <[email protected]> <[email protected]> > *Subject:* Re: [FRIAM] [EXTERNAL] Re: unikernels? > > > > Thanks! Fascinating. > > > > -- Owen > > > > On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <[email protected]> > 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 M: 505-238-9359 P: 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 <[email protected]> > 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 > > ============================================================ > 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
