Try clicking on "All projects", the vast majority of projects that this website lists are labelled "restricted". The conclusion that open source "says no" seems somewhat dishonest.

Author here. Just found the pun fun, I have no intention to claim that OSS says no. I'm mostly interested in finding cases where OSS does say no.

Fair enough, it's interesting to have a concise overview like this.

It doesn't help that GrapheneOS _only_ works on Pixel phones (and also doesn't mention this on their homepage).

That's _not_ true. See recent HN submissions about GrapheneOS on Motorola (signature 27).

Edit: https://news.ycombinator.com/item?id=50380810

Seems confirmed but not released yet?

Can't find it on

https://grapheneos.org/faq#device-support

https://grapheneos.org/releases

That's a flagship release - but it's

  Motorola's first with a performant implementation of ARM Memory Tagging Extension

with more cheaper variants following. MTE is the hardware capability that GrapheneOS relies on for its claims of security (along with coding practices) and it's the reason GrapheneOS has only been released to certain Pixels to date.

(2023) https://security.googleblog.com/2023/11/mte-promising-path-f...

I think it's the combination of the profound writing style with the underwhelming substance that bothers people.

It's true but it doesn't "vibe" well with the "power to the people" messaging. I think what I'd want to see is someone putting their heart into this before I'd even consider joining the cause. The low effort text makes me not have faith.

> Why

They hope this goes viral and many join.

I do see many FOSS projects completely reject AI contributions. This looks like a different variant of FOSS where blatant copying with AI is the go-to.

A more honest analogy would be that they'd build an identical house for themselves.

They can. Not on the same land and not from the same budget.

Poor quality is the problem and since the bandwidth of editors doesn't magically grow with the amount of input, rejecting AI content is a very effective way to keep average quality up.

It's already typical to call into a native library with Python bindings for performance critical work in Python. Even Pydantic's validation runs in Rust code.

This works well if there are obvious hot spots that can be easily isolated, but sometimes the perf issues are more uniformly distributed throughout a codebase.

Given that the speedup is modest (~10%) and the Python 3 migration caused enough pain for users, I get it though. If it was a 2x speedup it would be a different story IMO

Even with 2x speed, I don’t think it would be worth it. Do we really want a repeat of that with years of packages not working with each other and a bunch of smug people telling others to update their code or whatever.