Of solutions, Numba, Nuitka, are probably also worth mentioning.
Then just looking at those, I now know of Shedskin and ComPyler.
I do feel like one nice thing about so many people working on solutions to every problem in python, is that it means that when you do encounter a serious downside, you have a lot more flexibility to move forwards along a different path.
1. Everyone who uses a static site generator can add XSLT
2. Everyone who doesn't use a static site generate only has to add the XSLT file and add a single line to the XML. No need to write any code: new code is not a big deal for many HN readers, but not every blog author is a coder.
Probably more due to the fact that browsers only support the 1999 XSLT 1.0, and no one has shown any interest in implementing XSLT 2.0 from 2001, or XSLT 3.0 from 2017. So there has been a sign of lack of desire since 2001 at minimum, likewise there is seemingly no attempt by anyone to document incompatibilities and push browsers to unify their incompatibilities like HTML, JS, and CSS.
The writing has been on the wall for a long while. Mozilla hasn't stepped up, Google hasn't stepped up, GNOME hasn't stepped up, Oracle hasn't stepped up, etc. Maybe its just a format that once anyone gets involved with, they no longer want to be involved with it any further.
> In January 2025, the PSF submitted a proposal to the US government National Science Foundation under the Safety, Security, and Privacy of Open Source Ecosystems program to address structural vulnerabilities in Python and PyPI.
> It was the PSF’s first time applying for government funding.
It doesn't seem to be a renewal, and they seem to have applied before the clauses were added.
- - -
Additionally, on September 29, 2025, the NSF posted
> The U.S. National Science Foundation announced the first-ever Safety, Security, and Privacy of Open-Source Ecosystems (NSF Safe-OSE) investment in an inaugural cohort of 8 teams
Implying that until that point, there was no distribution of funds as part of Safe-OSE, so no prior years of funding existed
That's really as far as they need to go; if the userland is compatible with Linux, it can use all of the work that KDE and other organizations have put into building mobile interfaces.
These projects have stuff that works, but the lack of firmware for chips that can connect to modern cell infrastructure means that they can't really create an appealing product. The OS layer is where all previous Linux phone efforts have failed, and I hope the FSF makes it farther than everyone else has.
> The OS layer is where all previous Linux phone efforts have failed
The OS layer is where the existing projects are thriving, with various distros and shells to choose from to match one's needs and tastes. It's the appropriate hardware that's in undersupply. I'm using a Librem 5, a 2019 design, and if I wanted to switch to something newer I can't because there's no viable upgrade path on the market. No other hardware vendor has invested significant resources into mobile GNU/Linux since then, everything else is either purely community-based or uses Halium.
Does webrender work with the Librem 5? Last time I checked it didn't-- Firefox disallowed it because the etnaviv driver didn't have all the features available needed to enable it. It appears there's been a lot of work on etnaviv recently but I don't know if it affects this issue.
etnaviv doesn't do GLES3 yet, so no, but the work to support it (mostly done by Christian Gmeiner) is ongoing and progressing. I'm using Epiphany though, it's pretty snappy these days and I make extensive use of its webapp feature. I don't even remember when was the last time I had to fallback to Firefox because of some incompatibility, but it did happen at least once.
