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 <[email protected]> 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 <[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 >
============================================================ 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
