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 > <mailto: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 <mailto: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 > <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 <mailto: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] *On Behalf > Of *Owen Densmore > *Sent:* Tuesday, August 11, 2015 7:41 PM > *To:* The Friday Morning Applied Complexity Coffee Group > <friam@redfish.com> <mailto: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 <mailto: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 <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 > <g...@tempusdictum.com > <mailto: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 <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
============================================================ 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
