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 ----------------------------------- 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:31 PM Steven A Smith <sasm...@swcp.com> 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? > > ----------------------------------- > 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 <r...@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 < >> nickthomp...@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-boun...@redfish.com] *On Behalf Of *Steve >>> Smith >>> *Sent:* Tuesday, August 11, 2015 11:36 PM >>> *To:* The Friday Morning Applied Complexity Coffee Group < >>> friam@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-boun...@redfish.com >>> <friam-boun...@redfish.com>] *On Behalf Of *Owen Densmore >>> *Sent:* Tuesday, August 11, 2015 7:41 PM >>> *To:* The Friday Morning Applied Complexity Coffee Group >>> <friam@redfish.com> <friam@redfish.com> >>> *Subject:* Re: [FRIAM] [EXTERNAL] Re: unikernels? >>> >>> >>> >>> Thanks! Fascinating. >>> >>> >>> >>> -- Owen >>> >>> >>> >>> On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond <rcpa...@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 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 <g...@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 >>> >>> ============================================================ >>> 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
