14 ms·

My impression as game developer: - Vulkan first graphics interfaces. I mean, OK. Not that I'm in love with this overly complex API, but fine. - No OpenGL supp

by Svoka 8y ago

My impression as game developer: - Vulkan first graphics interfaces. I mean, OK. Not that I'm in love with this overly complex API, but fine. - No OpenGL support. I guess this is where world is moving - No POSIX support. Quite a bit of game engines rely on it, oh well, when google cared about developers - Nothing about sound (my personal thing) As game developer working with Android was unpleasant to say the least. For example sound - android has like 4 sound systems, all of them (except simplest one available from Java side) are not fully implemented, and swarming with compatibility bugs across manufacturers and android versions. Oh, not to say that they introduce new one once in a while, with new version adoption slower than a sloth. I get that Google engineers enjoy rewriting things they don't like, but, come on. Fix existing first. Don't change APIs on us - not everyone has extra million of $$$ to throw on a project to refactor it every time Google decided that they want shiny new thing, which as result is broken too but in different ways. OK. I admit, I exaggerate, but it seems like tough times for game engines (besides super hyped ones like Unity or Unreal, which also has no problem throwing tens of millions). Note about OpenGL support: I'm pretty sure they'll drag it in by porting ANGLE library which is currently actively worked on. Compatibility layers for Vulkan are getting momentum, but I hope they'll join forces with MoltenGL/VK instead of making their own worse analog.

ehsankia 8y ago
Someone correct me if I'm wrong, but this is probably lower level than what you're speaking of. I doubt they'll be revamping all those "Android sound systems" you speak of, but rather rewire them to this new kernel. It wouldn't make sense for the to completely throw away all Android apps ever and rewrite all the APIs from scratch.
stdcli 8y ago
Fuschia relies on the kernel Zicron which last time I checked used Magma as a framework to provide compositing and buffer sharing between the logical split of the application and system driver, which exist as user space services. The fact that graphics drivers exist as user space services should reduce latency by minimizing the need for capabilities, the equivalent of a system call which requires an expensive system call/trap handling routine in std linux (for example). This is presumably to support an architecture with direct access to a GPU where the main CPU scheduler doesn't have to schedule a round trip of data from main CPU to data bus to GPU and back, compared to std linux on std hardware architecture, for example which will support this overall design to decrease latency and advance open source graphics development in a user space setting. - No OpenGL support. I guess this is where world is moving Vulkan is still built off of OpenCL, which is kernel code designed explicitly for the GPU. While not technically OpenGL, it is a more direct interface architecturally with the hardware and there are plenty of engines working on vulkan support. Consider there are other advantages to using a graphics driver than just OpenGL (like parallel computing and abstracting large data sets into matrices that map nicely into GPUs) and optimize based on this assumption and it is not as unreasonable as it sounds. - No POSIX support "Full POSIX compatibility is not a goal for the Fuchsia project; enough POSIX compatibility is provided via the C library, which is a port of the musl project to Fuchsia. This helps when porting Linux programs over to Fuchsia, but complex programs that assume they are running on Linux will naturally require more effort." - https://lwn.net/Articles/718267/ https://lwn.net/Articles/718267/
klodolph 8y ago
You may want to take a second impression. - OpenGL should be a library. This is just going to make OpenGL development easier in the long run. Right now there are too many OpenGL implementations and the differences matter. Running one OpenGL library on top of N different Vulkan implementations is miles better than running on top of N different OpenGL implementations. - POSIX can be a library too. It doesn’t have to be provided by the kernel. People have been strapping POSIX layers on top of things for ages. This was originally how Mach worked. You can still do weird things on iOS and macOS “below” the POSIX layer (although most POSIX syscalls are just provided by the kernel). You talk about how hard it is to change APIs… and how much you hate to refactor things every time Google decides they want the shiny new thing. But POSIX is rooted in the 1970s. It sucks. It’s about time to try something new. The entire POSIX model is based around the idea that you have different people using the same computer and you don’t want them to accidentally delete each others’ files. There are a ton of APIs in POSIX which are straight-up shit, like wait(). Sandboxes are unportable and strapped-on, using arcane combinations of things like chroot and cgroups. Let’s give people a chance to try out something new. Unix is somewhere around 50 years old now. OS research is dying out. Make it easier to run untrusted programs.
- stdcli 8y ago
  "OS research is dying out" - this I was learning about kernel dev around the same time as trying to understand how conditional execution and speculative execution worked as a result of really trying to understand every step that happens when a system call hands something to the kernel and the kernel does something with it and hands it back to the system. I kept asking but alot of supposed linux nerds I spoke with couldn't tell me how the kernel and user space truly handed off data or negociated memory with eachother, leaving me drawing out trap handling routines on a posterboard penciling in gdb dissassembles of memory for system call source code, feeling dumb for not knowing, meanwhile we all find out about Spectre and Meltdown and that really there is not a secure handoff without significant performance degradation and/or increased sandboxing for things like the browser, etc. And of course what is the root of the issue here? The root of the issue is that linux is too deeply integrated into monopolized hardware architectures, which is perhaps why AMD's stock price skyrocketed the day Spectre and Meltdown came out, when we found out the only mitigation for this legendary security vuln in the near future, will cost a 30% reduction in performance across the board with intel as opposed to much less with AMD given the AMD architecture was less prone to exploiting the vulnerabilties around speculative execution. The more I learned about these things plus issues with other basic functions like wait() ot strcpy() or in general the lack of protections around C, the more I entertained the idea of looking for alternative operating systems. The networking stack in Fuschia is written in Go for example. While I don't know much about Go, can it be worse than C when it comes leaving it up to almost every developer to take care of their own garbage collection and what the performance and security implications of this are? Magenta is designed to be modular enough in nature to withstand the waves of hardware architectural evolution coming and given we are approaching 5nm development (the theoretical limit of how small a transistor gate can be before we can no longer control interactions/flipping a transistor switch due to quantum interaction), and this is not far off, Intel already has 10nm in production and probably others now as well (its been a bit since I checked) then to quantum computing: Because quantum computing (this is debatable and I know the least about this) is not ready for mass production, particularly on the mobile scale, my conjecture is once we reach the theoretical limit of how small a transistor will be, designs will turn to optimizing for performance in every other way we can without relying on powerful processors to accomodate for memory bloat or endless dependencies (yes I also pray this requires javascript modules to be better or die out but thats a long range dream). Meanwhile AMD gains ground post spectre and meltdown. So, in summary, there are alot of other options to consider than just optimizing for POSIX forever. Therefore, I am glad there is a push to explore alternatives. I feel as though anyone who thinks it's not potentially beneficial to explore POSIX alternatives based distros does not work with Unix based systems in any kind of depth on a daily basis, but if someone does, and you think Linux for example, is the best operating system in the world and can't be improved upon outside of its defining protocols, then I would love to hear from you on this thread. I am not nearly as experienced as most people who work with Linux, but I can say that most I have interacted with it view it as a love hate relationship for many of these very reasons. You can also see this trend of unhappiness with Linux OS defaults out in the wild outside of google. More and More and serious applications are looking to bypass userspace application development to be either more secure, customize, most often for the purpose of if not security, to optimize performance for the things we use to consider the std linux kernel somewhat good at. Here are few varied examples I can think of off the top of my head anecdotally when trying to solve everyday problems for users with linux, but I am sure there are many more: 1. Dropbox bandaid attempts to customise network schedulers usually handled in kernelspace due to performance issues: https://blogs.dropbox.com/tech/2018/03/meet-bandaid-the-dropbox-service-proxy/ https://blogs.dropbox.com/tech/2018/03/meet-bandaid-the-drop... 2. Wiregaurd is an example of a VPN where communication negociation is handled more and more in the kernel, because traditional vpn designs have left TLS handoffs in userspace (what is the point of userspace anymore for serious application development when this is the trending security default): https://www.wireguard.com/ https://www.wireguard.com/ 3. Sysdig implements epf functionality to allow for sysadmins and devops engineers to customise and or secure in ways we don't trust or consider the default linux operating systems userspace/kernel space design to do anymore: https://dig.sysdig.com/c/pf-blog-introducing-sysdig-ebpf https://dig.sysdig.com/c/pf-blog-introducing-sysdig-ebpf
taneq 8y ago
> Don't change APIs on us - not everyone has extra million of $$$ to throw on a project to refactor it every time Google decided that they want shiny new thing, which as result is broken too but in different ways. This was what drove me out of my (brief) stint at Android development. Did some hobby development to learn the ropes, spent a lot of time trying to "do it right". It was a bit clunky but alright I guess. Left my project alone for a few months while my day job was busy. Came back to it to find that, in a few months, there had been not one but two generations of deprecated APIs between what I'd written and current 'best practices' and that a bunch of pretty fundamental stuff had been deprecated. I'm not wasting my life chasing that particular Red Queen.
- pjmlp 8y ago
  Yep, Android's best practices tend to last one Google IO.
mapcars 8y ago
>- No POSIX support. Quite a bit of game engines rely on it, oh well, when google cared about developers This is caring about developers, just that you don't understand it.
- siteshwar 8y ago
  It's not and eventually they will have to find ways to provide POSIX compatibility, it can happen through a separate compatiblity layer or a library. You don't want to break compatibility with millions of lines of already written code if you want widespread adoption. No one is going to rewrite everything from scratch, just because Google says so.
  - izacus 8y ago
    Which "millions of lines of code" are compatible with POSIX without having any Linux or macOS specific code? Or being compatible with Windows for that matter, which is POSIX compliant just in the name? I think you're hugely overstating the importance of POSIX, not to mention downplaying the fact that POSIX really isn't sufficient requirement to not have to do any code porting.
    - siteshwar 8y ago
      > Which "millions of lines of code" are compatible with POSIX without having any Linux or macOS specific code? Those layers would have to be reimplemented to retain compatibility. > I think you're hugely overstating the importance of POSIX. People generally understate importance of POSIX, just because it's old. It's impossible to get APIs perfect and you are throwing away decades of work in the name of getting APIs "right". No one is going to rewrite everything from scratch, just because the new APIs look shiny. For reference read about Unix wars[1]. [1] https://en.wikipedia.org/wiki/Unix_wars https://en.wikipedia.org/wiki/Unix_wars
      - markstos 8y ago
        If Fuchsia is wrong on this point, they can add more POSIX compatibility later.
jayd16 8y ago
When the goal is a clean slate OS design, we can't get up in arms about compatibility out of the box, can we?
- Svoka 8y ago
  I think first and only goal should be user experience. OS is a tool to start apps, and if they can't make it comfortable to make and support apps, they failed before they started. Google's problem is their academic goal to make a nice OS, IMO.
  - spdionis 8y ago
    Why do you want to force your idea of what the goal should be upon Google? If they want to test the waters in relatively unexplored waters let them do so.
izacus 8y ago
That sounds like you want to continue using APIs and OS from 1970s, while Fuchsia is deliberately trying to break those old conventions. 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.
- yc12340 8y ago
  > 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.
  - imtringued 8y ago
    New APIs make sense but keeping the old ones for backwards compatibility does too.
    - AnIdiotOnTheNet 8y ago
      Sure, but there's no reason you have to do that in the kernel.
  - izacus 8y ago
    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.
    - phkahler 8y ago
      >> 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/ 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.
pjmlp 8y ago
Google is making Vulkan a required API in Android Q, and they are updating ANGLE also run on top of Vulkan. As for Fuchsia, given that the team comes from a different background and the OS APIs, I am not expecting the straightjaket experience from NDK.
Orphis 8y ago
> No OpenGL support. I guess this is where world is moving > No POSIX support. Quite a bit of game engines rely on it, oh well, when google cared about developers Well, tell that to game developers working for consoles. They don't have access to the same APIs and they made it work just fine. Most of the time, you don't make your own engine and rely on some other engine to support your platform, so it just works. I've done enough Wii, PSP, PS3 or PS4 development and having different APIs was never a problem.
- flohofwoe 8y ago
  Console APIs are nice and clean compared to Vulkan though, since they are tailored to the underlying hardware. Vulkan is a weird compromise between a low-level API and covering fairly different GPU architectures.
  - Orphis 8y ago
    The point was more about general APIs like threading or file access, anything covered by POSIX. It is already expected to have to rewrite your GFX backend anyway using the specialized API for the platform, but people don't expect the same for general use APIs too.
neop1x 8y ago
I tried to start android development couple of times and it was impossible for me. The last time I created a new project from the Android Studio built-in template, it was broken from the start - UI editor throwing an error, googling didn't help, I didn't have so much time to debug it so gave up again. I expected built-in template to always work. I hate java, I always hated that tree of subdirectories. What worse, there are some Maven repos and some proprieters Gradle binary which is randomly downloaded to my pc like a malware. Why is that? It is very difficult to configure the project, so many XMLs, documentation is not very good, build process takes a long time. Android studio is slow and takes much RAM as any java-based IDE. Rename a project? Near impossible. You have to be a guru to know all the places where to change it, rename directories, etc. In comparison, it is very straightforward to develop for iOS. It is possible to integrate C/C++ easily. Normal gdb/lldb. Cocoa UI is nice, nice frameworks with reasonable documentation. The only problem is the closed platform, requirement to pay for Development program, signing all binaries.

by Svoka 8y ago

ehsankia 8y ago

Someone correct me if I'm wrong, but this is probably lower level than what you're speaking of. I doubt they'll be revamping all those "Android sound systems" you speak of, but rather rewire them to this new kernel. It wouldn't make sense for the to completely throw away all Android apps ever and rewrite all the APIs from scratch.

stdcli 8y ago

Fuschia relies on the kernel Zicron which last time I checked used Magma as a framework to provide compositing and buffer sharing between the logical split of the application and system driver, which exist as user space services. The fact that graphics drivers exist as user space services should reduce latency by minimizing the need for capabilities, the equivalent of a system call which requires an expensive system call/trap handling routine in std linux (for example). This is presumably to support an architecture with direct access to a GPU where the main CPU scheduler doesn't have to schedule a round trip of data from main CPU to data bus to GPU and back, compared to std linux on std hardware architecture, for example which will support this overall design to decrease latency and advance open source graphics development in a user space setting. - No OpenGL support. I guess this is where world is moving Vulkan is still built off of OpenCL, which is kernel code designed explicitly for the GPU. While not technically OpenGL, it is a more direct interface architecturally with the hardware and there are plenty of engines working on vulkan support. Consider there are other advantages to using a graphics driver than just OpenGL (like parallel computing and abstracting large data sets into matrices that map nicely into GPUs) and optimize based on this assumption and it is not as unreasonable as it sounds. - No POSIX support "Full POSIX compatibility is not a goal for the Fuchsia project; enough POSIX compatibility is provided via the C library, which is a port of the musl project to Fuchsia. This helps when porting Linux programs over to Fuchsia, but complex programs that assume they are running on Linux will naturally require more effort." - https://lwn.net/Articles/718267/ https://lwn.net/Articles/718267/

klodolph 8y ago

You may want to take a second impression. - OpenGL should be a library. This is just going to make OpenGL development easier in the long run. Right now there are too many OpenGL implementations and the differences matter. Running one OpenGL library on top of N different Vulkan implementations is miles better than running on top of N different OpenGL implementations. - POSIX can be a library too. It doesn’t have to be provided by the kernel. People have been strapping POSIX layers on top of things for ages. This was originally how Mach worked. You can still do weird things on iOS and macOS “below” the POSIX layer (although most POSIX syscalls are just provided by the kernel). You talk about how hard it is to change APIs… and how much you hate to refactor things every time Google decides they want the shiny new thing. But POSIX is rooted in the 1970s. It sucks. It’s about time to try something new. The entire POSIX model is based around the idea that you have different people using the same computer and you don’t want them to accidentally delete each others’ files. There are a ton of APIs in POSIX which are straight-up shit, like wait(). Sandboxes are unportable and strapped-on, using arcane combinations of things like chroot and cgroups. Let’s give people a chance to try out something new. Unix is somewhere around 50 years old now. OS research is dying out. Make it easier to run untrusted programs.

stdcli 8y ago
"OS research is dying out" - this I was learning about kernel dev around the same time as trying to understand how conditional execution and speculative execution worked as a result of really trying to understand every step that happens when a system call hands something to the kernel and the kernel does something with it and hands it back to the system. I kept asking but alot of supposed linux nerds I spoke with couldn't tell me how the kernel and user space truly handed off data or negociated memory with eachother, leaving me drawing out trap handling routines on a posterboard penciling in gdb dissassembles of memory for system call source code, feeling dumb for not knowing, meanwhile we all find out about Spectre and Meltdown and that really there is not a secure handoff without significant performance degradation and/or increased sandboxing for things like the browser, etc. And of course what is the root of the issue here? The root of the issue is that linux is too deeply integrated into monopolized hardware architectures, which is perhaps why AMD's stock price skyrocketed the day Spectre and Meltdown came out, when we found out the only mitigation for this legendary security vuln in the near future, will cost a 30% reduction in performance across the board with intel as opposed to much less with AMD given the AMD architecture was less prone to exploiting the vulnerabilties around speculative execution. The more I learned about these things plus issues with other basic functions like wait() ot strcpy() or in general the lack of protections around C, the more I entertained the idea of looking for alternative operating systems. The networking stack in Fuschia is written in Go for example. While I don't know much about Go, can it be worse than C when it comes leaving it up to almost every developer to take care of their own garbage collection and what the performance and security implications of this are? Magenta is designed to be modular enough in nature to withstand the waves of hardware architectural evolution coming and given we are approaching 5nm development (the theoretical limit of how small a transistor gate can be before we can no longer control interactions/flipping a transistor switch due to quantum interaction), and this is not far off, Intel already has 10nm in production and probably others now as well (its been a bit since I checked) then to quantum computing: Because quantum computing (this is debatable and I know the least about this) is not ready for mass production, particularly on the mobile scale, my conjecture is once we reach the theoretical limit of how small a transistor will be, designs will turn to optimizing for performance in every other way we can without relying on powerful processors to accomodate for memory bloat or endless dependencies (yes I also pray this requires javascript modules to be better or die out but thats a long range dream). Meanwhile AMD gains ground post spectre and meltdown. So, in summary, there are alot of other options to consider than just optimizing for POSIX forever. Therefore, I am glad there is a push to explore alternatives. I feel as though anyone who thinks it's not potentially beneficial to explore POSIX alternatives based distros does not work with Unix based systems in any kind of depth on a daily basis, but if someone does, and you think Linux for example, is the best operating system in the world and can't be improved upon outside of its defining protocols, then I would love to hear from you on this thread. I am not nearly as experienced as most people who work with Linux, but I can say that most I have interacted with it view it as a love hate relationship for many of these very reasons. You can also see this trend of unhappiness with Linux OS defaults out in the wild outside of google. More and More and serious applications are looking to bypass userspace application development to be either more secure, customize, most often for the purpose of if not security, to optimize performance for the things we use to consider the std linux kernel somewhat good at. Here are few varied examples I can think of off the top of my head anecdotally when trying to solve everyday problems for users with linux, but I am sure there are many more: 1. Dropbox bandaid attempts to customise network schedulers usually handled in kernelspace due to performance issues: https://blogs.dropbox.com/tech/2018/03/meet-bandaid-the-dropbox-service-proxy/ https://blogs.dropbox.com/tech/2018/03/meet-bandaid-the-drop... 2. Wiregaurd is an example of a VPN where communication negociation is handled more and more in the kernel, because traditional vpn designs have left TLS handoffs in userspace (what is the point of userspace anymore for serious application development when this is the trending security default): https://www.wireguard.com/ https://www.wireguard.com/ 3. Sysdig implements epf functionality to allow for sysadmins and devops engineers to customise and or secure in ways we don't trust or consider the default linux operating systems userspace/kernel space design to do anymore: https://dig.sysdig.com/c/pf-blog-introducing-sysdig-ebpf https://dig.sysdig.com/c/pf-blog-introducing-sysdig-ebpf

taneq 8y ago

> Don't change APIs on us - not everyone has extra million of $$$ to throw on a project to refactor it every time Google decided that they want shiny new thing, which as result is broken too but in different ways. This was what drove me out of my (brief) stint at Android development. Did some hobby development to learn the ropes, spent a lot of time trying to "do it right". It was a bit clunky but alright I guess. Left my project alone for a few months while my day job was busy. Came back to it to find that, in a few months, there had been not one but two generations of deprecated APIs between what I'd written and current 'best practices' and that a bunch of pretty fundamental stuff had been deprecated. I'm not wasting my life chasing that particular Red Queen.

pjmlp 8y ago
Yep, Android's best practices tend to last one Google IO.

mapcars 8y ago

>- No POSIX support. Quite a bit of game engines rely on it, oh well, when google cared about developers This is caring about developers, just that you don't understand it.

siteshwar 8y ago
It's not and eventually they will have to find ways to provide POSIX compatibility, it can happen through a separate compatiblity layer or a library. You don't want to break compatibility with millions of lines of already written code if you want widespread adoption. No one is going to rewrite everything from scratch, just because Google says so.
- izacus 8y ago
  Which "millions of lines of code" are compatible with POSIX without having any Linux or macOS specific code? Or being compatible with Windows for that matter, which is POSIX compliant just in the name? I think you're hugely overstating the importance of POSIX, not to mention downplaying the fact that POSIX really isn't sufficient requirement to not have to do any code porting.
  - siteshwar 8y ago
    > Which "millions of lines of code" are compatible with POSIX without having any Linux or macOS specific code? Those layers would have to be reimplemented to retain compatibility. > I think you're hugely overstating the importance of POSIX. People generally understate importance of POSIX, just because it's old. It's impossible to get APIs perfect and you are throwing away decades of work in the name of getting APIs "right". No one is going to rewrite everything from scratch, just because the new APIs look shiny. For reference read about Unix wars[1]. [1] https://en.wikipedia.org/wiki/Unix_wars https://en.wikipedia.org/wiki/Unix_wars
    - markstos 8y ago
      If Fuchsia is wrong on this point, they can add more POSIX compatibility later.

jayd16 8y ago

When the goal is a clean slate OS design, we can't get up in arms about compatibility out of the box, can we?

Svoka 8y ago
I think first and only goal should be user experience. OS is a tool to start apps, and if they can't make it comfortable to make and support apps, they failed before they started. Google's problem is their academic goal to make a nice OS, IMO.
- spdionis 8y ago
  Why do you want to force your idea of what the goal should be upon Google? If they want to test the waters in relatively unexplored waters let them do so.

izacus 8y ago

That sounds like you want to continue using APIs and OS from 1970s, while Fuchsia is deliberately trying to break those old conventions. 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.

yc12340 8y ago
> 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.
- imtringued 8y ago
  New APIs make sense but keeping the old ones for backwards compatibility does too.
  - AnIdiotOnTheNet 8y ago
    Sure, but there's no reason you have to do that in the kernel.
- izacus 8y ago
  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.
  - phkahler 8y ago
    >> 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/ 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.

pjmlp 8y ago

Google is making Vulkan a required API in Android Q, and they are updating ANGLE also run on top of Vulkan. As for Fuchsia, given that the team comes from a different background and the OS APIs, I am not expecting the straightjaket experience from NDK.

Orphis 8y ago

> No OpenGL support. I guess this is where world is moving > No POSIX support. Quite a bit of game engines rely on it, oh well, when google cared about developers Well, tell that to game developers working for consoles. They don't have access to the same APIs and they made it work just fine. Most of the time, you don't make your own engine and rely on some other engine to support your platform, so it just works. I've done enough Wii, PSP, PS3 or PS4 development and having different APIs was never a problem.

flohofwoe 8y ago
Console APIs are nice and clean compared to Vulkan though, since they are tailored to the underlying hardware. Vulkan is a weird compromise between a low-level API and covering fairly different GPU architectures.
- Orphis 8y ago
  The point was more about general APIs like threading or file access, anything covered by POSIX. It is already expected to have to rewrite your GFX backend anyway using the specialized API for the platform, but people don't expect the same for general use APIs too.

neop1x 8y ago

I tried to start android development couple of times and it was impossible for me. The last time I created a new project from the Android Studio built-in template, it was broken from the start - UI editor throwing an error, googling didn't help, I didn't have so much time to debug it so gave up again. I expected built-in template to always work. I hate java, I always hated that tree of subdirectories. What worse, there are some Maven repos and some proprieters Gradle binary which is randomly downloaded to my pc like a malware. Why is that? It is very difficult to configure the project, so many XMLs, documentation is not very good, build process takes a long time. Android studio is slow and takes much RAM as any java-based IDE. Rename a project? Near impossible. You have to be a guru to know all the places where to change it, rename directories, etc. In comparison, it is very straightforward to develop for iOS. It is possible to integrate C/C++ easily. Normal gdb/lldb. Cocoa UI is nice, nice frameworks with reasonable documentation. The only problem is the closed platform, requirement to pay for Development program, signing all binaries.