> That sounds like you want to continue using APIs and OS from 1970s
If possible, I'd prefer to keep using APIs from 1960 instead.
Then perhaps you shouldn't be using an OS from 2020 ?
Demands for POSIX compatibility really seem like cargo culting these days, considering none of the popular platforms will have apps use only POSIX APIs. It's a crutch that holds back API design white still demanding that you use OS specific syscalls in pretty much every software out there.
>> It's a crutch that holds back API design
When I read that I caught a hint at a problem. API design should not be an ongoing activity. People should design a new API and then we should all use it for a long time. If it's frustrating that POSIX is still used, you might want to consider that stability is the feature that keeps it around.
Perhaps it's time to reread Joel on "fire and motion":
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
I'm all for this Fuchsia thing, but they claim to have the experience to design something better so do that and let it stand. Regular software updates are actually a sign that you don't know what you're doing.
Re:Fuchsia OS Introduction
by imtringued on Tuesday March 26, 2019 @07:31AM
(#19490755)
New APIs make sense but keeping the old ones for backwards compatibility does too.
Re:Fuchsia OS Introduction
by AnIdiotOnTheNet on Tuesday March 26, 2019 @10:08AM
(#19491946)
Sure, but there's no reason you have to do that in the kernel.
OpenGL was never a serious contender for modern games and there's a good reason why all new 3D APIs are moving to more low-level representations (Vulcan, DX12, Metal) with libraries on top. OpenGL is a horrible implicit stateful machine which is terrible to multithread and still holds a model of a hard-wired 3D accelerator as a base, which isn't how new graphics cards work. Everything else is bolted on top of that out-of-date idea which makes is hugely unwieldly for new software.