Zig build system can do all that just fine though

Apparently they are planning to create their own machine learning model with all the font data they have gathered.

kqueue is similar to epoll, it's readiness based and not completion like IOCP and io_uring. IOCP is nice in theory, but the api and the different ways everything has to be fed for it leaves a lot to be desired... Windows also has own version of iouring, but it's bit abandoned and only works for disk io which is shame, because it could have been nice new clean io api for windows.

I don't know how it compares, but for sockets Windows also has Registered I/O: https://learn.microsoft.com/en-us/previous-versions/windows/...

> the api and the different ways everything has to be fed for it leaves a lot to be desired

I think Microsoft fixed that in Windows Vista by providing a higher-level APIs on top of IOCP. See CreateThreadpoolIo, CloseThreadpoolIo, StartThreadpoolIo, and WaitForThreadpoolIoCallbacks WinAPI functions.

CI's job for me is to just run a nix flake

Target apple and in 5 years your binary wont work anymore anyways

Well, some games like Civ V still manage to work! But they actually had to port it to 64-bit, otherwise it'd have the fate of all other 32-bit macOS games unfortunately...

You are only safe if you run Tim's rootkit :)

Yes filc as abi makes most sense. Do note that while fil-c seems to have pretty good source compatibility some stuff still require patches (like python!)

I don't know how it's going on the nixpkgs side, but my impression from Alpine is that it's pretty normal to carry some patches for any ABI/platform that isn't GNU.

Yep, you can look around in Nixpkgs and see a bunch of conditionally applied patches based on target platform.

My Fil-C flake already includes like 50 different patches extracted from the upstream port catalogue!

Yeah, I was thinking nix will be probably one of the first things that can easily adapt Fil-C as it already packages in a way that allows different packages to be completely independent of each other, thus Fil-C's ABI compatibility does not matter. I assume other targets will be mostly enterprise distros where the perf hit and source compatibility issues are less of a concern, and memory safety is absolutely critical.

Fil-C compiled flatpaks might be a interesting target as well for normal desktop users. (e.g. running a browser)

I wonder if GPU graphics are possible in Fil-C land? Perhaps only if whole mesa stack is compiled using Fil-C as well, limiting GPU use to open drivers?