The weird thing about death (as in aging, not as in accidents/getting eaten) is that it's "an invention". As in natural selection decided at one point to introduce death. It really is the case that older lifeforms don't die. All mammals do though.
If you study it, it becomes pretty obvious that in most cases reproduction and death are linked. Death is fundamentally a way to optimize reproduction, to control DNA variability and number of offspring.
Also, it is obvious that death has "levels". The cells humans are made of are immortal, in the sense that human cells are capable of living and even reproducing indefinitely, if so directed by DNA. Gametes are meant to survive your death, becoming your children. Now very few cells actually do survive, but that's a constant across pretty much every immortal species. On the other hand, every cell in your body was, in a very real sense, the first bacteria, the first cell ever, billions of years ago. So it certainly is NOT the case that all human cells age, senescence, and die. Only the human as a whole ages, and it is something your cells conspire to do (or conspire not to do, in the case of ovi (~ children), or in the case of cancer cells)
At one point, during the period mammals were all still fish, evolution was still experimenting with death, and so fish have much more variation in their aging and death than mammals do. If you go back further, to reptiles, there's even less death. Most reptiles could be alive for thousands of years (even though the odds are wildly against that). Most reptiles die because of slowly advancing accumulated diseases over time (meaning over hundreds of years, a great many diseases, parasites, even physical damage, ... accumulates. No one cause is really causing their death, but combined they introduce such a strain on the organism as a whole it "dies of old age". Except it's not really of old age in the sense like humans age, it's dying of what you might call 99.9% victories against disease. Eventually the 0.1% damage per incident overpowers the metabolism)
Unfortunately this does mean that death is built into our cells and a lot of processes depend on aging and death. Therefore we are very far away from curing death: you don't just have to fix the mechanism that "ages" our cells, but you have to find alternate ways of working for everything that depends on it. Resetting the clock may be easier, but even the methods that we currently know (ie. regrowing telomeres) have a bad reputation for causing aggressive cancers, and therefore shortening life rather than prolonging it. Plus, at best if you fix aging in humans entirely, we'll be like reptiles. At that point medicine will have to radically change and every tiny trace of every minor infection will have to be treated as a life threatening condition.
Author here, just pushed a quick update to the article.
To be fair, compared to the prices of Certum and other providers if you ever want to sign something for Windows, perhaps Apple isn't uniquely overpriced (they all seem to be that way): https://www.certum.eu/en/code-signing-certificates/
Looking more into the Windows side of things, I also found Azure Artifact Signing which is supposedly affordable at 8.54 EUR per month, but unfortunately they don't actually support individual users in the EU (only in US & Canada, meanwhile EU only gets support for organizations). I'd probably have to set up a SIA (equivalent of Ltd.) here first - it was in the plans for later, but this is a bit of a roadblock for using Azure too: https://azure.microsoft.com/en-us/products/artifact-signing
My tone might have been frustrated, but I will absolutely say that the code signing industry needs to have a Let's Encrypt moment of some description - at least commoditize it like Azure Artifact Signing was trying to do, but also for individual developers, across all platforms! Sadly, that doesn't seem to be possible when the platforms are intentionally walled gardens. I don't hate the idea of code signing, though - if done right, it's a good idea, same as TLS for (many) websites.
The problem is a management pattern:
removing people and organizational slack because they don’t generate immediate profit,
and then expecting the knowledge to still be there when it’s needed.
Short-term cost cutting leads to less junior hiring,
and removes the slack that experienced engineers need in order to teach.
As a result, tacit knowledge stops being transferred.
What remains is documentation and automation.
But documentation is not the same as field experience.
Automation is not the same as judgment.
Without people who have actually worked with the system,
you end up with a loss of tacit knowledge—and eventually, declining productivity.
AI is following the same pattern.
What AI is being sold as right now is not really productivity.
In many domains, productivity is already sufficient.
What’s being sold is workforce reduction.
The West has seen this before, especially in the case of General Electric.
GE pursued aggressive short-term financial optimization,
cutting costs, focusing on quarterly results, and maximizing shareholder returns.
In the process, it hollowed out its own long-term capabilities.
It effectively traded its future for short-term gains.
The same mindset is visible today.
The core problem is that decision-makers—often far removed from actual engineering work—
believe that tacit knowledge can be replaced with documentation, tools, and processes.ti cannot.
Tacit knowledge comes from direct experience with real systems over time.
If you remove the people and the learning pipeline,
that knowledge does not stay in the organization. It disappears.
Maybe OT - I find Claude Code hit or miss, I spend a lot of time removing dumb code or asking Claude to remove it eg "why do you have a separate..." Claude: "Good catch — there's no real reason...." and so on.
Where I find it incredible - learning new things, I recently started flutter/dart dev - I just ask Claude to tell me about the bits, or explaining things to me, it's truly revolutionary imho, I'm building things in flutter after a week without reading a book or manual. It's like a talking encyclopaedia, or having an expert on tap, do many people use it like this? or am I just out of the loop, I always think of Star Trek when I'm doing it. I architected / designed a new system by asking Claude for alternatives and it gave me an option I'd never considered to a problem, it's amazing for this, after all it's read all the books and manuals in the world, it's just a matter of asking the right questions.
I don't know. Claude helped me implement a ton of features I had been procrastinating for months in a matter of days. I'm implementing features in my project faster than I can blog about them. It definitely manifested as a huge commit spike.
And it's not like I'm blindly commiting LLM output. I often write everything myself because I want to understand what I'm doing. Claude often comments that my version is better and cleaner. It's just that the tasks seemed so monumental I felt paralyzed and had difficulty even starting. Claude broke things down into manageable steps that were easy to do. Having a code review partner was also invaluable for a solo hobbyist like me.
Early employees often have difficulty with the new reality. In the early days everyone is involved in making product decisions, helping with sales by implementing features, doing support for customers. If you hired juniors this is all they know.
Everyone doing everything is exactly what you don’t want in a larger organization. You need structure, you need dedicated teams for CX, product, development, QA, etc.
Often early employees perceive the decrease in scope as a demotion. They’re no longer defining the product, they’re no longer helping land the sale, at least not directly. For some that’s a hard pill to swallow and they resent it. Managing these so they can grow within the organization can be the right path, or not depending on the person.
I see making a game engine as the illusion of progress on making a game. Making a game engine is fun and relatively easy. You have a check list of things to do. Each of them the solutions are relatively well known. so you do them and make tons of progress. You get a window open, then you get a triangle up, then you get a texture loaded, then you get some basic text for debugging, then you read the keyboard for input, etc etc. each day new stuff comes up and you think you’re making progress but really you haven’t even started making the game , you’re just reproducing what you could have already had if you’d started with an existing engine.
Then you start it hit the more tedious stuff. loading animated characters, blending animations on selective subtrees of a character hierarchy. Making a level editor. Adding quality of life feature to it like undo. Etc…
I’m not saying you shouldn’t do this. It’s fun to do. just don’t delude yourself that that’s making progress on your game. It’s instead making progress on a game engine. That’s a different thing.
I've shipped 18 games, 4 of them AAA. I wrote the engines for most fo them. I wouldn't do it again.
All that said, some nuance. If the game you are making is simple for some defintion of simple, Celeste, Dead Cells, Geometry Wars. Then making your own engine isn't much work and there maybe some benefits.
On the other hand, see all the tiles made with engines. Silksong is Unity. A Short Hike is Unity. Blue Prince is Unity. Valheim is Unity. Peak is Unity. Dredge is Unity. You don't need to make your own engine to make an indie game.
This is another case where it's highly important to "plant your flag" [1] and set up all those services like Search Console, even if you don't plan to use them. Not only can this sort of thing happen, but bad-guys can find crafty ways of hijacking your search console account if you're not super vigilant.
Google Postmaster Console [2] is another one everybody should set up on every domain, even if you don't use gmail. And Google Ads, even if you don't run ads.
I also recommend that people set up Bing search console [3] and some service to monitor DMARC reports.
It's unfortunate that so much of the internet has coalesced around a few private companies, but it's undeniably important to "keep them happy" to make sure your domain's reputation isn't randomly ruined.
Thing is, regular Linux distros are most prone to breakage when it comes to updates - especially Ubuntu and Ubuntu-based distros[1]. My elderly mum is non-technical and has been a Linux user for the past decade, and she had Xubuntu, Mint and Zorin - all of which ran fine until update broke it (and this is just a bog standard DELL Optiplex desktop with an Intel iGPU). So I switched her to Aurora a couple of years ago and it's been rock solid.
This is why I recommend immutable/atomic distros for newbies, especially if the person installing it doesn't want to be a 24x7 tech support for that user.
If you like Fourier, you're going to love Laplace (or its discrete counterpart, the z transform).
This took me down a very fascinating and intricate rabbit hole years ago, and is still one of my favorite hobbies. Application of Fourier, Laplace, and z transforms is (famously) useful in an incredibly wide variety of fields. I mostly use it for signal processing and analog electronics.
function sprung_response(t,pos,vel,k,c,m)
local decay = c/2/m
local omega = math.sqrt(k/m)
local resid = decay*decay-omega*omega
local scale = math.sqrt(math.abs(resid))
local T1,T0 = t , 1
if resid<0 then
T1,T0 = math.sin( scale*t)/scale , math.cos( scale*t)
elseif resid>0 then
T1,T0 = math.sinh(scale*t)/scale , math.cosh(scale*t)
end
local dissipation = math.exp(-decay*t)
local evolved_pos = dissipation*( pos*(T0+T1*decay) + vel*( T1 ) )
local evolved_vel = dissipation*( pos*(-T1*omega^2) + vel*(T0-T1*decay) )
return evolved_pos , evolved_vel
end
For anticipation, just add an extra initial velocity in the opposite direction and let the closed-form solution handle the time evolution. The main trick here is to keep both position and velocity as state. There is no need to “step through the simulation”.
Do yourself a flava and read the
Manga. The movie ends before where the first volume ends, but the story goes in a completely different and much more interesting direction.
The least effective leadership I've ever seen has been in non-profits. Well, non-profits and middle management in F100 companies!
Because ineffectiveness is not disqualifying in these organizations.
Honestly I believe this to be irreconcilable.
Donors are not investors. Clients are not customers. Volunteers are not employees. They just aren't. Their motivations and their goals are completely different.
I have also seen well-managed non-profits, but only those with large budgets who had a fairly even employee-to-volunteer ratio, and produced goods or services that could be reliably measured for quality and quantity.
In that example, they do the character's physics first (just a ball), then match the animation to it. The animation speed is controlled by a "surveyor wheel" approach — go to to 336s in the video for that part.
So, the animation speed is derived from the physics, rather than the physics speed being derived from the animation.
I wouldn't call that "IK" exactly, which would be more for things like matching the foot to individual stair steps as the character walks up them, or such. But I suppose in a broader sense it is, since you're deciding on a physical goal a-priori, then forcing the animation to match that goal.
„ We need to think about failure differently. I’m not the first to say that failure, when approached properly, can be an opportunity for growth. But the way most people interpret this assertion is that mistakes are a necessary evil. Mistakes aren’t a necessary evil. They aren’t evil at all. They are an inevitable consequence of doing something new (and, as such, should be seen as valuable; without them, we’d have no originality). And yet, even as I say that embracing failure is an important part of learning, I also acknowledge that acknowledging this truth is not enough. That’s because failure is painful, and our feelings about this pain tend to screw up our understanding of its worth. To disentangle the good and the bad parts of failure, we have to recognize both the reality of the pain and the benefit of the resulting growth.“
Somewhat related, I have found The On-Line Encyclopedia of Integer Sequences[1] to be an amazing resource when I come across interesting numeric sequences.
My midlife crisis at 40 was more like a midlife epiphany. We moved from a perfectly good and totally beautiful city (Bath, UK) into the arse end of nowhere in Devon to live in a shack in the woods with no running water and to be near the sea.
We went with two small (8 and 5) kids (responding to those here saying it's not possible - it is!) and downsized from a busy city life to a quiet rural one.
Our intention was to stay a year. After two years we mentioned going back to the kids and they put their feet down - the most relaxed kids in the world decided they knew what was good for them: splashing about in rivers with sticks, fires on the beach, mud, a tiny school, more present parents, late nights lying on a hill looking at the stars. So we listened to them and stayed.
We're still in the country, by the sea, and our kids are now nearly grown up. We're having a blast. We're here for them. They're here for us. We'll never be rich but we're a great family unit.
If we hadn't had the guts to do a crazy thing (I give all credit to my wife for having the idea!) and decide pretty much off the cuff to follow our "crisis", we'd never have discovered our new life.
We've been very fortunate with our circumstances and I never forget that - but fundamental to all of this has been making the leap. Fear of the unknown can be countered by just doing it, knowing that crazy looking decisions can create amazing futures. Doing things is often better than curling up in fear and not doing them.
A throwback to vintage serials, shot as time and budget allowed over years. I pre ordered a copy of the DVD and waited a few years for it to arrive so I guess it was like a crowd funding thing long before that was easy to do.
"His mission begins with the unlikely delivery of a cat to a small outer-belt asteroid saloon where he meets his former dance partner, and renowned interplanetary fruit thief, the Blueberry Pirate. As payment for his delivery of the cat, Curtis receives a homemade cloning device already in the process of creating a creature most rare in this space quadrant – a Real Live Girl."
Oh, there's a copy hiding out on YouTube. I don't feel so bad posting this link because it's long out of print, I actually own a copy that I bought from the original artist, and it's just... pretty amazing.
After the opening credits, there's just 2 minutes of the protagonist shaving that I forgot about. But then he jumps out of his ship to bring the cat to the asteroid/saloon. I'll just link that moment because it's the moment I fell in love with this movie.
If you study it, it becomes pretty obvious that in most cases reproduction and death are linked. Death is fundamentally a way to optimize reproduction, to control DNA variability and number of offspring.
Also, it is obvious that death has "levels". The cells humans are made of are immortal, in the sense that human cells are capable of living and even reproducing indefinitely, if so directed by DNA. Gametes are meant to survive your death, becoming your children. Now very few cells actually do survive, but that's a constant across pretty much every immortal species. On the other hand, every cell in your body was, in a very real sense, the first bacteria, the first cell ever, billions of years ago. So it certainly is NOT the case that all human cells age, senescence, and die. Only the human as a whole ages, and it is something your cells conspire to do (or conspire not to do, in the case of ovi (~ children), or in the case of cancer cells)
At one point, during the period mammals were all still fish, evolution was still experimenting with death, and so fish have much more variation in their aging and death than mammals do. If you go back further, to reptiles, there's even less death. Most reptiles could be alive for thousands of years (even though the odds are wildly against that). Most reptiles die because of slowly advancing accumulated diseases over time (meaning over hundreds of years, a great many diseases, parasites, even physical damage, ... accumulates. No one cause is really causing their death, but combined they introduce such a strain on the organism as a whole it "dies of old age". Except it's not really of old age in the sense like humans age, it's dying of what you might call 99.9% victories against disease. Eventually the 0.1% damage per incident overpowers the metabolism)
Unfortunately this does mean that death is built into our cells and a lot of processes depend on aging and death. Therefore we are very far away from curing death: you don't just have to fix the mechanism that "ages" our cells, but you have to find alternate ways of working for everything that depends on it. Resetting the clock may be easier, but even the methods that we currently know (ie. regrowing telomeres) have a bad reputation for causing aggressive cancers, and therefore shortening life rather than prolonging it. Plus, at best if you fix aging in humans entirely, we'll be like reptiles. At that point medicine will have to radically change and every tiny trace of every minor infection will have to be treated as a life threatening condition.