Could try 1 per IPv4 address? There’s just barely enough!

No he’s not. Disney still owns the trademark on the signature mouse. What’s in the public domain is Steamboat Willy.

And for x86-64 Windows builds, you should be testing using an x86-64 Windows machine, not Rosetta 2

I am writing from a user perspective, rather than testing your builds.

That’s what Guix did. All the way back to a 357 byte assembly code blob that turns a hex file into a binary file, and can “compile” itself.

SQLite is public domain (as much as is legally possible). So there's no "rights" to "sell" except the trademark.

The testing suite is not open, which is one of the most important part of the project.

.NET ResX localization generates a source file. So localized messages are just `Resources.TheKey` - a named property like anything else in the language. It also catches key renaming bugs because the code will fail to compile if you remove/rename a key without updating users.

.NET Framework tried that with their whole "security" system, but it was a massive failure.

The only fool-proof solution is separate address spaces and OS cooperation.

Are you referring to Midori?

I've only ever seen three reasons for Midori to shutdown:

1) they were hitting C# limitations (and started working on custom compilers etc) (and people involved in Midori say Rust has already shipped things they failed to do)

2) there was a bit too much academic overeagerness, e.g. software transactional memory will kill any project that attempts it

3) basically getting their budget taken away

https://www.zdnet.com/article/whatever-happened-to-microsoft...

https://joeduffyblog.com/2015/11/03/blogging-about-midori/

Midori is certainly an interesting project, but no; I meant the old "code access security" model that .NET Framework had.[0][1] Administrators (and other code) could restrict you from doing certain operations, and the runtime would enforce it. It was removed in .NET Core.[2]

[0]: https://learn.microsoft.com/en-us/previous-versions/dotnet/f...

[1]: https://learn.microsoft.com/en-us/dotnet/api/system.security...

[2]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/...

Okay, that looks really funky. Like, libraries explicitly state what access they have ambient authority to use, and then callers can be constrained by an access control list, or something like that. Really weird design.

I'd love to see someone put genuine thought into what it would take to say that e.g. a Rust crate has no ambient authority. No unsafe, applied transitively. For example, no calling std::fs::open, must pass in a "filesystem abstraction" for that to work.

I think the end of that road could be a way to have libraries that can only affect the outside world by values you pass in (=capabilities), busy looping, deadlocking, or running out of memory (and no_std might be a mechanism to force explicit use of an allocator, too).

(Whether that work is worth doing in a world with WASM+WASI is a different question.)

Not exactly the same, but intrinsics in some languages are purely name+signature matched.

Sure, but will anyone name a method like "__nvidia_experimental_feature_xyz_v1"?

Because Objective-C doesn’t have access controls. If a method exists, you can call it. A "private" API is just an undocumented one.

Given enough motivation, access control is irrelevant too. See early Windows "private" API that was used for decades and Microsoft supported despite being "private", because they knew it was being used and they (used to) care about their users.

IBM*. They approached Intel for the 8088 for the 5150, but said "We want a second source". So Intel reeled in AMD. Second sourcing at the time was pretty common.