I recommend reading "Being Mortal" by Atul Gawande to get a good sense of how hopeless "curing aging" is. Although that's not the focus of the book it does a wonderful job describing the challenge.
The way it reads to me as a lay person, the body just falls apart. Things go wrong. It's not one thing going wrong, it's a very long list of disparate problems that ultimately aren't survivable. Aging isn't a losing battle, it's a massacre. It's one damn thing after another.
What struck me is how our veins go "crunchy" in old age from the build up of calcium and how an expert can tell the age of a person within a 5 year period from just a picture of their gums and teeth. I put the book down and couldn't sleep that night.
I never read the book, but during the last couple years I became more attentive to things in life. Nothing special, but just the general flow of life so to speak. I started noticing an interesting pattern. There is pretty much always exists a single solution to any problem. A core solution. A polymorphism in programming could be an example of what I mean. Say you have a program with a bunch of similar entities and a ton of if/else statements handling the logic for various cases. Conditions keep growing with each new entity. The code becomes messy as you fight the language trying to "cure" your program. Then you introduce an interface and suddenly everything becomes more clear and things just _make sense_. Your conditionals slowly disappear, the logic gets simpler and the code is now flat.
I keep noticing similar patterns pretty much everywhere in life and somewhat confident that the same core solution exists for aging as well.
Shot in the dark (coming from a MS in Biomedical Engineering): circadian control to stabilize the body’s metabolic activity to lessen the “wear and tear” of the body’s condition to intensely survive for but a cosmic microsecond. Once we can “hack” ourselves to de-couple the body away from its heliocentric regularity, we can “slow aging”.
After all, ex vivo cellular immortality exists. I think it’s the hormones that ruin everything.
That's interesting. I've always suspected that "curing" something as fundamental as aging would change some basic aspect of what makes us human. Per your comment about hormones, imagine that if you want immortality, you have to never have had testosterone or estrogen in your body. That person would have a vastly different human experience than everyone else. It sounds like it would make a pretty cool scifi story, as a matter of fact.
The human genome is full of harmful mutations. While many are widespread and some are shared by everyone, we each still have our own unique collection of them. I often wonder how much longer we'd live with every obviously harmful mutation reverted.
It's probably not black and white, some of those harmful mutation may have necessary benefits in some other function. It's like drinking a poison that will kill in the long term but you need to live in the short term.
For a more hopeful picture: Ending Aging, by Aubrey de Grey. He organizes that long list of disparate problems and propose a possible path for their solution. Doesn't make it sound any easier, but at least it is a hopeful reading.
Making a very crude analysis based on the size of data, I would say solving aging is a piece of cake comparing to scanning someone's brain content. Our proteins that eventually break down with aging are coded by the DNA. The DNA is a few GB across. Sure there are mutations, folding and other complexities, but it is still mostly digital data. The brain has 80B neurons, each with thousands of dendrites. You'd need to scan not only the (real valued) state of the neurotransmitters in each of these dendrites, but also the topology of the (varying) connection to other neurons. Not that it isn't a daunting challege, but I would bet my money on beating aging, rather than scanning the brain.
It depends on how close the biological cells are to being immortal. What I was referring to in somewhat sarcastically in another post is that modern senescence research is basically operating from the position that the cell just has, you know, maybe one or two or three things wrong with it, and if we can "just" extend the teleomeres (presumably with just ingesting some substance), and maybe supplement our diet with a couple of substances, and maybe fix cancer or something, we'll be there.
There are some reasons to believe this may be true, such as the existence of cells in the wild that seem to be effectively immortal, like certain jellyfish and such. (Nothing terrible close to us taxonomically, but at least they're from planet Earth.)
On the other hand, it may turn out that after a couple of quick wins worth, say, 20 or 30 years, that the whole thing devolves into dozens, then hundreds, then thousands, then tens of thousands of interventions, all complicating each other, a good number of them unique to the individual, as you try to pick up the pieces in your ever-aging organs as they continue to find new and exciting ways to fail. Imagine trying to keep an old car running, but you're not actually allowed to just replace parts, and you have to do all the fixes while the car is on the road, and this is just barely the tip of the iceberg. Senescence research may be one of the worst examples of a light-post problem in human history, as they search for this or that substance that will fix aging but the minimal solution is in fact literally gigabytes worth of information converted into biological machines we can barely even conceive of.
If you can read one neuron, you can read two; those problems are not independent. (That's a simplification to some extent, but at this level we'll take it.) If you can understand one protein's function, that doesn't help anywhere near as much with the next one, and the state of the body is roaming through a very high-dimensional space over time, with the interventions all also affecting the next intervention that will be necessary... it can get pretty ugly in there, potentially. Amusingly, the brain is the problem in both cases; biological immortality probably wouldn't be so hard, we could probably solve everything by transplants of freshly-grown organs based on our genetic code... except transplanting a freshly-grown brain in kinda defeats the whole purpose. In the end, both problems may come back to scanning brains one way or another.
Simulating the micro-environment is the tricky part. Humans go great distances and interact a lot with the world, and that, plus time, is what aging is, isn't it?
Can you simulate all the different ways DNA can mutate?
Wow. I understand that you are a layperson, but that’s a very strong statement in my view. What do you base it on? Or did you just pull it ”out of a hat”?
Changing genetics seems to me a bit like changing an engine in-flight. Mappping the brain to a computer is more like building a plane from scratch in a hangar.
In a computer, we build the materials but we also build the world around them. With biology, all we have to work with is are the real-life materials, which are harder to grok than their digital equivalents.
Piece by piece migration/replacement into a computer/ artificial neurons seems more likely. Still a gargantuan task with the requirement of a gargantuan amount of neurons.
First, the goal I'm shooting for is the conquest of aging, effective biological immortality, not just living 150-200 years.
When understanding a complicated existing system, like a program, with the intention of making changes to it or fixing it, I find there are characteristic phases to it. There's the part where you have no handle on it at all. At this point you think there maybe isn't that much to the system. Then you get a handle, and you view the whole system through that handle for a while, and everywhere you look you see new stuff. Every time you find something new, your estimate of the size of the task grows. Slowly, but surely, you begin to go more places and look at more things and you encounter stuff you've already seen before. Your estimate of how much work you have to do goes up, but the rate of change starts to decrease. You find more useful handles to understand more bits of the system as you encounter new subsystems and bunches of code. There's a long period of consolidation, where your understanding finally starts matching the complexity and you start getting to the point you know what you are doing, and the rate of surprises you encounter slopes off, perhaps never quite reaching zero, but certainly dropping off. You then have the long slog of actually doing the work, because now you understand it.
In biology, you can argue about exactly where we are, but we are certainly not at the "long period of consolidation" yet, because we keep finding entirely new subsystems that we weren't even aware of. For the past several decades, it seems like every 5 or 10 years we keep finding new subsystems and the apparently complexity of what's going on keeps going up. The ratio of "things we know" over "things we know we don't know" has been steadily going down over the past decades, even as the "things we know" may be increasing in absolute terms. At this point I would have no confidence in anyone's claim that "no, this is the last complication we'll find, we're on our way now!"
Trying to get into that mess and fix it for the long term may just be an unrealistic goal entirely. I suspect modern research into fixing senescence and this or that promising treatment option (oh, look, maybe if we supplement with this, oh, look, maybe if we supplement with that!) may be the equivalent of trying to fix an architectural issue in a large-scale code base armed with the equivalent of three letter "a"s you can insert into the code base, or trying to reassemble a supernova armed with a BB gun.
Not that brain simulation is easy either. In fact, I'm not even convinced the simulating is the hard part. It's the reader I can't hardly imagine how we're going to build without some serious borderline-magic nanotech. You need to be able to read millions of neurons in parallel if you have any hope of finishing before the patient being scanned dies of old age. (And what does "reading" a neuron even mean? Can a "reader" fit into the space between neurons? If not you've got some serious scheduling problems with how to cover everything. And it's not like 'a neuron' is a point, either... one of their major purposes is to spread.) There's also a chance you'll have to be dynamically simulating the already-scanned parts as you go, since the system is changing as you scan it and it's basically the equivalent of a stroke if everything scanned is just dead afterwards, and who would want to be scanned that way? It's an insane machine to build.
It's really hard to tell which is harder, because they are both insanely hard. Neither would particularly surprise me. It's like an ant trying to judge which Redwood is higher.
Even if we could separate your mind from your body and run it on an immortal computer (or rather succession of computers), I don't think we have any evidence to suggest that making a mind immortal is easier than making immortal tissues and organs.
It's not just making the machine immortal or serviceable. You also need to make the program robust enough to run continuously without crash/reset conditions or other pathological bugs. But, the techniques we understand to engineer "immortal" programs are at odds with the complexity of a real mind, in much the same way as our techniques for engineering machines are at odds with real biology. I.e. it isn't really preserving a real mind if we have to strip away the stateful learning and memory, the moods and emotions, and the inherent potential for bouts of irrationality or even psychosis.
Finally, to "solve aging" for one organism or one mind just raises more questions which are equally as hard. What is an immortal society or civilization? How do new people ever relate to their immortal forebears or participate on equal footing in an economy where some have literally had forever to gather wealth and power? Or does sexual reproduction cease in a future with backup-restore options? Immortality means solving all these levels, otherwise you just replace illness and senescence with accident and violence as the common cause of death...
Just to your first sentence: even if we had biological immortality, the current estimate is that you can only make it about 250 years before on average you suffer a fatal accident.
Beating aging isn't really enough - we have to beat death.
One nuance is that if you want to live forever you only need to hit longevity escape velocity where every year there is another discovery which buys you another year of healthy life.
Of course it might lead to living to 800 and being confined to a wheelchair by 80.
Several companies and research groups are working on it. The challenge is a lack of priority, funding and even recognizing aging as a disease, at least in legal terms.
Look up the Sens foundation (Dr. Aubrey De Grey), Dr. David Sinclair (Harvard .. Some are skeptical because he has started several companies) and Dr. Bruce Ames as starting points.
I think the real challenge is mind boggling complexity of interactions. Suggesting it’s a question of funding etc is vastly understating the actual issues.
Curing cancer for example is a vastly simpler problem.
Don't get me wrong, it is a very complex set of complex issues depending on which pillar we attack. (Metabolism, Repair, Pathology). The latter is very expensive and too late in the game. That is what we attempt today with conventional medicine and it's just treating symptoms of aging. We barely understand human metabolism and the little bit we know is a auditorium wall sized flow chart. Repair is the new area and Aubrey is putting a lot of effort into that pillar. That is where funding would certainly help. Then there are legal and ethical issues we will eventually dive in to.
Absolutely. There is already a great deal of work on the metabolic side, such as removing biofilms of cancer with AGE (aged garlic extract), slowing or stopping metastases with bio-availability enhanced Curcumin, up-regulating autophagy and cell apoptosis with the up-regulation of NRF2 via cycling Sulforaphane and Myrosinase, starving cancer cells by removing all glucose and processed carbs via Keto and intermittent fasting, 5 day FMD (fast mimicking diet). All of these things highly complement Chemo, increasing the effectiveness and mitigating much of the damage caused by Chemo Therapy.
On the repair pillar, quite a bit of work is being done with CRISPR to attack cancer cells. There is also research on targeting specific cells using sound (11th harmonics) and destroying them.
Sorry I don't have any links to share. I must get back to work. :-)
Why Bruce Ames? Bruce Ames is long retired, and his research was on the free radical theory of aging, which is largely seen as a dead-end for the past 15 years after it was realised that merely throwing different antioxidants into the works gummed up the normal function of reactive oxygen species and did nothing or worsened aging.
Actually he still does a lot of work and is currently researching theories around "conservation". e.g. when the body is low on a particular micro-nutrient, it conserves delivery on particular pathways that are related to longevity.
So while he may have "retired", I mean, he's 90, so it's about time, he most certainly still works full time in the lab.
Define "curing". Is it giving some decent percentage of people an extra 10, 20, maybe even 30 years of reasonably healthy life, compared to what they have today? Or is it making people live forever? The first objective, as challenging as it is, sounds a lot more plausible than the second. If we ever achieve either, I'm sure the first will be reached long before the second is.
By a literal definition of "curing", only the second is a "cure". But the first would still be an amazing achievement, and is probably a prerequisite to ever being able to achieve the second.
You might be able to cure dying without curing age related degeneration of the body. Migrating minds outside of the body might be possible. To me it seems quite likely.
It's worth noting that there are a lot of active efforts towards tackling the different hallmarks of age related disease to extend healthspan. Some are in clinical trials already: https://www.lifespan.io/the-rejuvenation-roadmap/
Probably not soon enough to be of much benefit to anyone alive today. I have no qualifications to say this, so I can only base it on the staggering lack of progress made on many other medical fronts in the last decades.
I think the idea that a Ops needs to wake up in the middle of the night to deal with shit outages because a developer is unwilling to stand behind their code is probably outdated.
We're reaching a point where two groups of people, rather than one, is required to wake up in the middle of the night. Previously just the operations people needed to get up, now developers need to be on-call as well.
Operations teams are scaling down their monitoring to just infrastructure, because the applications are more opaque than ever. Incidents at the application level are no longer fixable by Ops, because they have no idea what the developers deployed or how it's configured.
Developers now need to take responsibility for application monitoring, patch management and incident management. Meaning that we're shifting more work to a group of people that where already in short supply.
I don't think we're necessarily moving in the right direction. There's certainly benefits to development and operations working in tandem, but currently we're just moving operations to developers without much consideration for the people that needs to do the actual work.
In my opinion your company/solution needs to be somewhat limited for "DevOps" to make sense. For everyone else, it's two separate roles.
Realstically, if the platform isn't down, I wouldn't need to wake up my platform engineer, just the dev. But the point is, the dev should build more reliable software so they don't have to wake up.
However, you're right, often these are two different teams. There are some people that can do both, but they're few and far between.
I would say that the problem in this situation is hard to avoid. If you can have an operations team who are experts on the application as well, and have the team more closely integrated with the development team, then you generally don’t need to wake up developers at night. I spent a few years on a team set up like this and it worked very well. If your project isn’t big enough for its own operation team you can share a team between a few different projects.
But I don’t think it’s necessarily that much harder to hire developers than it is to hire devops. Some managers have told me that hiring for devops is harder.
And developers should feel some of the pain—I’m not saying page them in the middle of the night, but they should be doing daytime on-call rotations. This helps align incentives and makes developers aware of reliability issues in the systems that they create.
> In my opinion your company/solution needs to be somewhat limited for "DevOps" to make sense. For everyone else, it's two separate roles.
When I think DevOps, I already think of it as a role separate from development. You have devs, and then you have devops. You can combine both roles into one, and that makes sense for smaller / earlier stage projects, but otherwise I think of devops as a separate role.
Kind of a mess because devops varies so much between companies and isn’t even consistently named.
But my experience is that it’s not necessary to wake up two groups of people—it’s either a developer that gets woken up because the project is too small or too early to be supported by operations, or it’s someone in devops/SRE/production engineer who gets woken up. There’s a lot of practices that need to be put into place to make this work, but it’s doable.
Better call the second role "Ops" then, and wait for someone to propose merging it with "Dev" again.
There's so much mental confusion and meaningless use of language now, about the term "DevOps" that was a fairly simple suggestion about bringing DEVelopment and OPerationS together. That sentiment is literally in the word, I don't know how it could be plainer.
> If you can have an operations team who are experts on the application as well
Then functionally they're going to end up as software developers. And you're going to treat them as such or they're going to leave. Which is what the notion of a "devops engineer" evolved to be, yet every good-to-great "devops engineer" I've ever worked with identified as a software developer and could be hired at any developer role they wanted.
If you want a warm-body ops team, they're not going to be experts. If you want experts, in 2019 they're going to rapidly stop being just-an-ops-team.
> Some managers have told me that hiring for devops is harder.
It's easier to hire "devops" if your idea of "devops" is "somebody with an AWS Associate cert." It's much harder to hire "devops" if your idea of "devops" is "thinks systematically and is capable of debugging a problem nose-to-tail without waking up a developer."
I am the latter, and there are remarkably few of these.
> And developers should feel some of the pain—I’m not saying page them in the middle of the night, but they should be doing daytime on-call rotations.
I feel like you've got this wildly backwards. Developers should be first-line on-call in almost every situation modulo detectible hardware failures. Because here's the thing--I've been doing this a long time as a mostly-unbiased consultant (I'm in-house now and it still holds), and in most environments, operations/infrastructure 1) break things less, and 2) break things quickly, so there's usually relatively little time between the break and the working-hours fix.
If a developer can't solve a developer problem because they think it's actually infrastructural, they can escalate. Making that ops/infra group be first-line support for application pages is both inefficient and unfair.
Anyway, that's a bit sad IMHO. In my opinion, running what you build is great to discover ways to improve your software.
Regardless if you want to or don't want to touch ops: You still might want to talk to ops or vice-versa.
Even if you have strict roles for devs and ops (and no mixed roles), you might be in a team where both are present and hopefully talk to each other.
The truth of what the code that you develop actually does, is in production; often buried in log stores and timing stats and other "ops" places.
It's better if that data is unearthed and fed back into the development process, it's better if that feedback loop is closed, it's better if that separation is removed.
That's one of the reasons for "DevOps" as originally formulated.
Sounds like a tool for devops. As a developer I would rather do extra work but on a mainstream cloud using a favourite language. Then again I am not in start-ups.
