hyperrail

As far as I know, no browser for Windows allows sites to read the computer's telemetry global ID at all.

In a sense it doesn't matter how the global ID is used now. The fact that it exists allows it to be used in ways like what you describe, either by a malicious (?) Microsoft itself or by a malicious third-party attacker.

I'm familiar with these global IDs because I routinely used the Windows telemetry system as part of my work on the Windows core at Microsoft. We had strong policies on how and when we could access or use data for a single device as identified by global ID.

But ultimately, these policies will have a "government or court order" exception in reality even if not in theory, just like in most other consumer software observability systems. The Windows difference is simply the breadth of data that is intentionally collected by Microsoft or can be identified by any Microsoft-controlled IDs. That difference is huge in potential impact but very small conceptually.

How a Windows device's global ID is generated may be new info in the public sphere, but the fact that the global ID exists is not a secret. This format of device ID has been in Windows since the initial release of Windows 10 in 2015, when it was introduced as part of Windows' current telemetry subsystem. To see your device's global ID, open Windows Feedback Hub, then go to Feedback Hub Settings and look under Device Information.

This is almost entirely an artifact of the financial instruments used to pay for these buildings, regardless of any Seattle policy changes.

Why would this be different in Seattle than in other cities? Many downtown office towers are bought or built using a lot of debt throughout the U.S. What do you think makes Seattle special?

We just saw another building turn over, US Bank Center. The new owner bought it at a price where they'll be able to lease it competitively, and it won't sit empty. We'll see that continue to happen.

The news story mentions the U.S. Bank Center example. What it says that you're leaving out is just HOW big that discount is:

The new owner of the U.S. Bank Center, having paid just $280 million, or less than half of what the building went for in 2019, presumably can afford to lower rents enough to fill the place, which is now 45% vacant, according to CoStar.

A discount of more than 50% is a bubble bursting. It's great that the new owner can offer fire-sale rent, but where does that leave the old owner, if they were truly as leveraged as you suggest they were likely to be?

The Seattle Times has always been a conservative rag, and their editorial board hates the new mayor, so they hit the "Seattle is dying" story as often as possible. They've got a long history of this whenever there's leadership they don't like, ask me about it!

OK, I'll ask you about it. This "Seattle Times = Blethen family propaganda" line has been tiring for the 25 years I've been hearing it. What exactly are they not covering about Seattle's downtown today that you think they should be? Why do you think that their opinion staff influence the news coverage so much? In short, if the Seattle Times has a conservative bias in its news coverage, why does the Wall Street Journal famously have a liberal-biased newsroom?

One way I find traditional Lisp style more painful for functional code than Ruby is that fully functional-style Lisp pushes me to read and write code the opposite way from how I think about it. In the author's example:

    orders
      .select { |o| o.placed_at > 1.week.ago }
      .group_by(&:customer_id)
      .transform_values { |group| group.sum(&:total) }

    (reduce #'+
      (map (lambda (o) (getf o 'total))
        ; this group_by replacement function
        ; might be written as hash-table code
        (my-group-by 'customer-id
          (remove-if-not
            (lambda (o)
              (>
                (getf o 'placed-at)
                (- (my-now) (* 60 60 24 7))))
            orders))))

Other imperative languages that support functional code either make you do things imperatively to get the "logical" ordering of functional operations like I feel Lisp pushes you to do, or they do something like Ruby where things can be chained left to right in a "single" statement even for operations that were not thought of ahead of time by the creators of opaque data structures you later need to operate on. (Everything is a user-extensible object like Ruby, unified function call syntax in D, extension methods in C#, or pipelines of structured objects in PowerShell.)

My use of `git add` - and the explicit staging area more generally - is mostly a workaround for the fact that the repos I work with have checked-in dev setup scripts, IntelliJ/Visual Studio/Xcode/VS Code configurations, and so on.

My own setup differs in slight ways from what those scripts expect, and even where they match I like to do my own customizations. I don't want to commit those changes, and staging makes it easy to not do that MOST of the time. The rest of the time, it's a `git stash` dance, which I sometimes screw up and lose the customizations.

I've tried to manage the configurations a different way, such as by having a private branch with my own settings checked in, but that doesn't usually work out. I'm aware that the REAL problem is that my coworkers have checked in those settings to begin with, but I would counter-argue that the REAL REAL problem is that those tools don't have a good way to combine "settings that I override or that only I care about" and "settings that have project-wide defaults but are safe for me to override." (Visual Studio gets it close to right with its .xyzproj and .xyzproj.user files, but VS Code's single .vscode/ folder breaks down in shared repos.)

Doesn't seem like all climate scientists are fans of it either. From a 2022 critique of a news story also based on this map:

https://cliffmass.blogspot.com/2022/04/is-large-portion-of-w...

The essential message is that weather and climate data do not support the claims of extreme or severe drought in eastern Washington this year.

There is no expectation of water problems over or near the Columbia Basin. The Drought Monitor graphics, which are created subjectively, are sufficiently problematic and deficient that they should not be considered or applied to any serious decision making.

The drought map used here is partly subjective opinion.

https://droughtmonitor.unl.edu/About/WhatistheUSDM.aspx

Who draws the map?

Meteorologists and climatologists from the NDMC, NOAA and USDA take turns as the lead author of the map, usually two weeks a time. The author’s job is to do something that a computer can’t. When the data is pointing in different directions, they make sense out of it.

How do we know when we're in a drought?

No single piece of evidence tells the full story, and neither do strictly physical indicators. That’s why the USDM isn’t a statistical model

Indeed, even ones from companies as big as Microsoft!

There is a story in Writing Solid Code by Steve Maguire [1] where Apple asked Microsoft to fix hacks in its Mac apps that didn't conform to the developer docs in Inside Macintosh because such workarounds were required when the apps were first developed alongside the original Macintoshes. However, Microsoft's workarounds would be broken by a major System Software update under development at Apple, which naturally wanted to avoid having to permanently add back the implementation bugs and quirks that the workarounds either relied on or were meant to avoid.

As Maguire told it, removing one such workaround in Microsoft Excel was hotly debated by the Excel team because it was in a hot-path 68k assembly function and rewriting the code to remove it would add 12 CPU cycles to the function runtime. The debate was eventually resolved by one developer who ran Excel's "3-hour torture test" and counted how many times the function in question was called. The total: about 76,000 times, so 12 more cycles each time would be about 910,000 cycles total... which on the Macintosh 128k's ~7 MHz 68000 CPU would be about 0.15 seconds added to a 3-hour test run. With the slowdown from removing the workaround thus proven to be utterly trivial, it was indeed removed.

[1] https://openlibrary.org/books/OL1407270M/Writing_solid_code - page 136, heading "Don't Overestimate the Cost"

What actually happened [re Windows RT, but I think the point applies to UWP in general] was that the users went WTF because none of their native apps - which, contrary to his take, were very much alive and kicking! - worked there, and devs went WTF because they were told that they'd need to rewrite everything yet again in some new thing that was kinda sorta but not quite like WPF, because Windows just hated .NET that much and couldn't accept that the devs liked it over their stuff. So the app store was a barren waste, and without apps there would be no users.

The fact that UWP XAML was its own new thing and not a extension of an existing Microsoft GUI app framework like WPF was not necessarily a "we hate managed code" thing, or even a "we hate those guys who invented managed code and want to screw them because we're Windows" thing. After all, .NET managed code had equal access to UWP through the .NET WinRT projection!

And to me at least (I didn't work on UI-facing stuff in Win8), it was absolutely conceivable that UWP could have just delivered Windows Phone 7 Silverlight's version of XAML to native code apps, with a thin adaptation layer to let even unmodified WP7 app binaries run on the desktop Windows .NET Framework with the WinRT projection and to allow slightly modified WP7 apps to look good in landscape mode on both Windows 8 and WP8. If we had done that instead of making UWP XAML its own thing, and if we had integrated the Windows Store with the Windows Phone Marketplace from the beginning so that Windows and Windows Phone apps could be sold as variants of each other through a single Store/Marketplace product entry on Windows 8 GA day, then I think we could have brought a lot of people forward who were already making good WP7 apps, and the Store wouldn't have been so empty.

Furthermore, IIRC much of the original UWP XAML implementation was done by the original people who built WPF and Silverlight the first time, and they would have known what they were doing in separating UWP XAML from Phone Silverlight. That they didn't go in the direction of extending Phone Silverlight was not necessarily shortsightedness on the part of provincial Windows people. Maybe they thought Phone Silverlight actually demonstrated fundamental limitations of WPF or Silverlight XAML or the Silverlight "coreCLR", or they wanted to make breaking changes as lessons learned from Phone Silverlight, which was put together about as hurriedly. (Windows Mobile 6 -> Windows Phone 7 first previews = 1.5 years; Windows 7 -> Windows 8 first previews = 1.5-2 years, tending toward 1.5 years if you account for the frantic re-planning after iPad came out in early 2010.)

And then there was Windows RT (not to be confused with WinRT, because Microsoft product naming!). Aka the Windows-on-ARM that ditched decades of backwards compatibility because Sinofsky decided that rebooting the ecosystem is the only way to compete with iPad or whatever.

It's important to remember the specific reasons why Windows RT 8 chose to not support third-party desktop apps. The most important aspect of "iPad compete" that we wanted on Windows for ARM was not "all app UXes look and work well on touchscreen tablets" but "you can't ship malware, not even by rebuilding your x86 malware from source." Thus, every 3rd party app on Windows RT would have to live in the AppContainer sandbox that UWP apps are in by default, and the requirement that you ship through the artist formerly known as the Windows Store would be a second line of defense against malicious apps. And with the forced-enabled Secure Boot, subverting the user-mode controls by secretly installing a bootkit would be hard even with physical access to the PC.

Even within the Microsoft world only, Windows Phone 7 had proven the success of this approach of locked-down apps only available through an app store that checked apps on submission and afterward for security. It was not unreasonable to think that similar lessons might also benefit users of "big" Windows, which is why Windows 10 and 11 have the opt-out "S mode" which defaults to the Windows RT restrictions.

I do wish though that Windows 8 had learned different lessons from WP7 (about which more in another point).

It was also when Windows was aggressively pushing their Metro styling on everything in the company, sometimes to ridiculous lengths - e.g. Visual Studio at the time "aligned" with Metro by, I kid you not, making the main menu bar ALL UPPER CASE so that it looked like Metro tabs! You can still see the blog posts announcing this "feature" when it shipped in the first public beta of VS 2012, and the comments on them.

fair. but that struck me as strange even then. if anything, visual studio should have adopted the all-lowercase typography of the original metro-style design language from zune and windows phone 7, not AN ALL-UPPERCASE ONE.

Perhaps that was just another way that Windows 8 Metro-style apps' design and developer platform was like Windows Phone 7's Metro style, yet different in seemingly gratuitous ways. That is something I would attribute to internal Microsoft politics. Steven Sinofsky and Terry Myerson (leader of Windows Phone at that time) never really got along, and in the Microsoft philosophy of that era where engineering divisions were completely locked down from each other by default, that rivalry would have discouraged what little natural collaboration would have happened anyway.

I was in DevDiv during his great WinRT push and the overall feeling I remember was that the guys in Windows had zero clue as to what the devs actually wanted, but were hell bent on scorching all the ground that wasn't theirs. My team actually did some prototyping for Python/WinRT support, and we had it working to the point of the visual WPF designer in Visual Studio even. Unlike JS, it was full fledged - you could use anything in WinRT same as C#, extend classes etc, while JS limited you to a "consumer" surface of the API. That prototype was killed because Windows (i.e. at the time = Sinofsky) said they didn't think developers cared about anything but JS so they didn't need another high level language.

I think the real mistake there was not so much that a particular projection of the Windows Runtime was stopped, but the more general idea that developers should be forced to consume what became known as the Universal Windows Platform or author custom WinRT components through only Microsoft-made WinRT projections.

In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012". (Martyn Lovell's Build talks on the origin of WinRT were a notable exception to this.) This discouraged people from using their existing COM skills to develop Metro-style/UWP apps or to gradually adopt features from UWP APIs that were accessible to them in their existing desktop apps. Other people have written that "WinRT=COM" thinking is actually a bad idea because it forces people to deal with COM and its more annoying ideas (separate IDL etc.); I disagree because we should have reached out to people who live in COM world to get a ready developer base.

That mistake was a key part of the still larger mistake you touched on of trying to make the UWP and desktop worlds 2 completely different developer platforms that happen to co-exist on the same desktop edition of the Windows OS. That was the key "we didn't listen to developers" mistake that set up UWP for its market failure. Another example: Even today, you can't adopt the battery-friendly UWP app lifecycle using Windows App SDK, which is supposed to be the UWP successor for desktop app developers. So much for WinAppSDK (or indeed UWP/Metro-style apps in Win8) enabling a true no-compromise user experience.

It took real tours-de-force like Kenny Kerr building C++/WinRT and blogging about it, Raymond Chen blogging about using WinRT APIs through the unprojected "ABI" interfaces, or the VideoLAN organization building a Win8/Win10 UWP version of VLC in C, to get the word out that the UWP world wasn't some alien thing with dark magic that only Microsoft wizards had full access to. And it doesn't help that the wizards really do have a few special powers that they jealously guard even now.

It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms. Or why the HTML/JS app model in Win8 never really took off.

At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework.

Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that.

So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.

(disclaimer: I was an individual engineer in the Windows division during the Windows 8 project, i.e. reporting through Steven Sinofksy)

I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs and how it has made Windows' developer platform much worse over the years, but I have always thought we had a better relationship than that, since my group's product was the main reason for yours for many years, and your group delivered so much for us in turn. Clearly your side had at least some reason to see things differently. On behalf of all of us, yes even up to stevesi, I'm sorry.

Now let me completely undermine my apology by nitpicking your comment :)

[continued in my replies to this comment]

There are still some things that are still locked in the UWP world that I wish were not.

For example, Windows classic desktop apps still have no equivalent to the UWP app lifecycle. Your UWP app's processes can be suspended and resumed without you writing code to force the suspension and request when to be resumed later. Instead, you are expected to appropriately handle event notifications for suspend, resume, and the app entering and leaving background state.

This system-managed UWP app lifecycle makes life harder for UWP app authors, but I think the net win for battery life is much better for the user experience, which is why mobile apps operate the same way. Yet the docs for the Windows App SDK, which is supposed to bring the best of the UWP to desktop apps, explicitly say that WinAppSDK apps control their lifecycle just like other desktop apps, and the only power friendliness in the WinAppSDK API is voluntary (aka no one will use it). [1, 2]

I'll probably write more soon in response to other parts of the original link's comment thread. Overall, I feel like UWP is being unfairly maligned here, and that while its introduction was unforgivably arrogant, Steven Sinofsky is also right that it was daring and necessary to fix the mistakes and outdated decisions of 16-bit Windows and Win32.

[1] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...

[2] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...

Microsoft has always had a broad vision of itself as a technology company; I feel it's perfectly fine to not be able to describe Microsoft in one sentence without using platitudes like "empower every person on Earth to achieve more" or "put a computer in every home and every office" (both paraphrases of actual MSFT company mission statements), and I suspect many other current and former Microsoft employees would feel the same way.

IMO Microsoft's best long-lived products have always been both finished solutions to your problems and platforms to help you develop more solutions, and Microsoft leadership has always recognized this. Examples: Windows. Office. Dynamics (their Salesforce competitor).

But even if a product doesn't meet that "why not both?" ideal, there is always going to be room for it at Microsoft, as long as it is not only a good or at least mediocre product by itself, but also works to sell you on the whole Microsoft ecosystem. Sometimes that is a bad thing (see all the Windows adware for Bing, Copilot, and M365). But that at least is where Microsoft remains consistent.

Both this blog post and the Steven Sinofsky response really set my blood boiling, because they both reek of retired-executive score settling, a kind of blame game that gets played out decades after the fact between ex-high-ranking people in hopes that whoever writes last is able to cement the conventional wisdom.

People who play this corrosive game either refuse to believe that they are at fault for not changing what they were doing at that time or speaking up about what they were observing then, or they know they're at fault and want to deceptively distract us from that fact. Either way, ask yourself this: "Aren't they sorry?" If they're not, just move on.

Unfortunately the only valid response is "Don't be so sure." There have been too many exposés about the poor data privacy practices of virtually every automaker including Honda. [1]

[1] Example: https://www.mozillafoundation.org/en/privacynotincluded/arti... (prev. HN discussion: https://news.ycombinator.com/item?id=37401563 )

I too thought VSCode's being web based would make it much slower than Sublime. So I was surprised when I found on my 2019 and 2024 ~$2,500-3,000 MacBook Pros that Sublime would continually freeze up or crash while viewing the same 250 MB - 1 GB plain text log files that VSCode would open just fine and run reliably on.

At most, VS Code might say that it has disabled lexing, syntax coloring, etc. due to the file size. But I don't care about that for log files...

It still might be true that Visual Studio Code uses more memory for the same file than Sublime Text would. But for me, it's more important that the editor runs at all.

Even then, that happened at most twice as you say, not three times as the other poster said.

And I disagree with your implicit claim that the WP7 & WP8 Silverlight -> Win10 UWP transition had no migration path. There was >= 90% source code similarity, bolstered if you had already adopted the Win8.1/WP8.1 "universal" project templates. And Microsoft provided tooling to ease the transition. Sometimes it was literally just s/Microsoft.Phone/Windows.UI/g.

Games were a different matter, I'll admit. XNA as an app platform had no direct replacement that was binary compatible with Win10 desktop, but even then, not only was DirectX already available from WP8.0, but Microsoft invested in MonoGame as an XNA replacement precisely because they knew the end of XNA would hit hard. (In fact it was the Windows Phone division that had essentially kept XNA on life support in its final years so that WP7 games would not break.)

Wrong. There was full app compat of WP7 apps in WP8 and Win10 Mobile, and for WP8 apps in W10M. The only full backward app compat break was from WM6.5/WP6.5 to WP7.

I'll give you the benefit of the doubt and assume you're thinking of the lack of device OS upgrades: from WP6.5 to WP7, from WP7 to WP8, and from older WP8 devices to W10M. So no forward compat, but absolutely yes to backward compat.

I might be misremembering, but if I remember correctly, back in 2019 Windows' pre-installed calculator had an interesting issue with the Japanese era change in 2019 from Heisei to Reiwa, due to Emperor Akihito's abdication and the succession of his son Emperor Naruhito. I was not personally involved with this issue but I was aware of it as I was working on the Windows team at Microsoft at that time.

The announced plan was that Akihito would abdicate on April 30 and Naruhito would take the throne on May 1, so that Jan 1-Apr 30, 2019 would be Heisei 31 (平成31年) and May 1-Dec 31 would be Reiwa 1/Reiwa Gannen (令和元年).

The issue was with Windows Calculator's date calculation. If you ask it which day is 61 days after April 1, 2019, it correctly calculates June 1, 2019. The question, though, is what if you have your Windows settings set to show the Japanese era year - should it show "2019" in "June 1, 2019" as Heisei 31 or Reiwa 1?

If I remember right, the answer chosen was "it depends on what your computer's current clock time is!" In other words, if you ask Calculator while your PC's clock is set to April 2019 or earlier, it "wrongly" shows June 1, 2019 as in Heisei 31, but if your clock is set to May 2019 or later, June 1, 2019 is "correctly" shown as in Reiwa 1. This would be true even if the running Calculator and Windows code was already updated with the knowledge that the new era would be called "Reiwa." (Though the date when Reiwa would begin was specified by a law passed in 2017, Reiwa's name was only announced on April 1, 2019.)

(I forget whether this problem was solved in the calculator app itself or whether it inherited the solution from Windows' date and time formatting code.)

The justification was that the change of era would only be finalized when Akihito actually abdicated. In modern times, Akihito's abdication was the first time that the era changed without the reigning emperor dying. Calculator acting as if it knew before May 1, 2019 that Reiwa would begin on that day would thus be in bad taste, because it would be the moral equivalent of Calculator predicting or wishing for Akihito's death on April 30 - never mind that it was already well known that Akihito planned to abdicate on that day instead.

Eric Lippert's "Complete Guide to BSTR Semantics" explains this well: https://ericlippert.com/2003/09/12/erics-complete-guide-to-b...

Aside: Why do we use the terms "mutable" and "immutable" to describe those concepts? I feel they are needlessly hard to say and too easily confused when reading and writing.

I say "read-write" or "writable" and "writability" for "mutable" and "mutability", and "read-only" and "read-only-ness" for "immutable" and "immutability". Typically, I make exceptions only when the language has multiple similar immutability-like concepts for which the precise terms are the only real option to avoid confusion.

https://github.com/IRS-Public/direct-file <- Direct File's web app source code is public-domain and published on GitHub!

Obviously the 2025 version will be out of date for the 2026 filing season, though public code means it can always be revived by anyone else.

(previous HN threads: https://news.ycombinator.com/item?id=44182356 https://news.ycombinator.com/item?id=44131901 )

Font sizes and families are also a relatively little-used way to visually distinguish things in a code editor.

Years ago I used to work on C++ code in a commercial editor called Source Insight [1]. At its default settings, it would do things like:

1. Show function and class names in HUGE fonts in declarations and definitions, so you always knew what was a declaration as opposed to a use

2. Show nested parentheses with the outermost parens being biggest and getting smaller as you got further in

3. Show comments in a proportional sans-serif font instead of a monospaced one so that you could tell where the comments were even if you have color blindness

Those features, along with having a C++ parser and code relationship visualizer much faster than the Visual Studio of the day without having to parse ahead of time (a la ctags), made Source Insight a near standard in my company. I still miss it on occasion.

[1] https://www.sourceinsight.com/feature-details/

This is the first time I've heard of Deno so I'm only going by their Security & Permissions doc page [1], but it looks like the doc page at the very end recommends using system-level sandboxing as a defense in depth. This suggests that Deno doesn't use system sandboxing itself.

To me this is a bit alarming as IIRC most app runtime libraries that also have this in-runtime-only sandboxing approach are moving away from that idea precisely because it is not resistant to attackers exploiting vulnerabilities in the runtime itself, pushing platform developers instead toward process-level system kernel-enforced sandboxing (Docker containers or other Linux cgroups, Windows AppContainer, macOS sandboxing, etc.).

So for example, .NET dropped its Code Access Security and AppDomain features in recent versions, and Java has now done the same with its SecurityManager. Perl still has taint mode but I wonder if it too will eventually go away.

[1] https://docs.deno.com/runtime/fundamentals/security/

Consumer Reports' reviews of newer Mazdas always stress the infotainment system as a big negative, to the point that I would seriously reconsider them as a result.

Apparently it's a case of "right idea, wrong execution." The deep menu hierarchies and small text make the jog wheel knob controls even more awkward (in CR's view) than a decent touch-screen system plus a few buttons. [1]

Maybe that's one reason that BMW has just abandoned their Mazda-like wheel controller [2], despite having had it for years before Mazda.

(Interestingly CR says the latest Mazdas do have a touchscreen, but touches are allowed when the car is moving only for CarPlay/Android Auto.)

[1] https://www.consumerreports.org/cars/mazda/cx-50-hybrid/2025... - "the CX-50's infotainment system is frustrating and distracting to use while driving. [...] the text- and list-based menu structure forces drivers to glance away from the road for too long. Even simple radio tasks require multiple taps and twists of the rotary controller knob"

[2] https://www.caranddriver.com/news/a63576709/bmw-kills-idrive...

The original academic article:

https://doi.org/10.1038/s43587-024-00702-3

S. Jay Olshansky et al., "Implausibility of radical life extension in humans in the twenty-first century", Nature Aging (2024)

Open access, here is the abstract:

Over the course of the twentieth century, human life expectancy at birth rose in high-income nations by approximately 30 years, largely driven by advances in public health and medicine. Mortality reduction was observed initially at an early age and continued into middle and older ages. However, it was unclear whether this phenomenon and the resulting accelerated rise in life expectancy would continue into the twenty-first century. Here using demographic survivorship metrics from national vital statistics in the eight countries with the longest-lived populations (Australia, France, Italy, Japan, South Korea, Spain, Sweden and Switzerland) and in Hong Kong and the United States from 1990 to 2019, we explored recent trends in death rates and life expectancy. We found that, since 1990, improvements overall in life expectancy have decelerated. Our analysis also revealed that resistance to improvements in life expectancy increased while lifespan inequality declined and mortality compression occurred. Our analysis suggests that survival to age 100 years is unlikely to exceed 15% for females and 5% for males, altogether suggesting that, unless the processes of biological aging can be markedly slowed, radical human life extension is implausible in this century.