3 ms·

Calling into native drivers directly is unportable so not suitable for eg a published Node module that's supposed to be generally usable, and the APIs are very

Calling into native drivers directly is unportable so not suitable for eg a published Node module that's supposed to be generally usable, and the APIs are very unsafe so they'll turn your managed language app into a segfault and security hole prone basket of surprises.

jatone 5y ago
good thing you're running on a server then.
- fulafel 5y ago
  Because portability, robustness or security are not concerns in server side components...?
  - jatone 5y ago
    reality is opengl and vulkan are portable. but the fact youre on a server means you have control on the environment. not like you need to deal with every tom dick and harry system configuration.
    - fulafel 5y ago
      I guess you are thinking of a situation where you would run this on a on-prem server system that you had a hand in spec'ing out? Yes it's possible to do this, but most Node apps in use run in various cloudy environments, possibly containerized, that you have less control over, and of course on random dev setups that people have. If you put out an open source Node module, you'll have devs trying to run it on systems with plentiful variability.
      - jatone 5y ago
        even in cloud environments you control the environment by choosing to use that service.
kevingadd 5y ago
Using OpenGL (or Vulkan) to talk to the GPU is one of the most portable things around. It works more places than Node does, even
- fulafel 5y ago
  This is technically true, if you don't count WebGL, but the bar is very low. Nontrivial OpenGL apps are epic battles requiring you to carefully & constantly test and debug zillions of configuration combos, with implementation specific OpenGL bugs, workarounds thereof, and delaing with myriad combos of feature and OpenGL version availability. A bit like SQL is portable for some meaning of "portable" (ANSI SQL!), only much worse. Also Apple keeps threatening to kill OpenGL so any day now all the people developing on Mac might lose the ability to dev this headless component locally. (And this was always the situation with Vulkan.)

jatone 5y ago

good thing you're running on a server then.

fulafel 5y ago
Because portability, robustness or security are not concerns in server side components...?
- jatone 5y ago
  reality is opengl and vulkan are portable. but the fact youre on a server means you have control on the environment. not like you need to deal with every tom dick and harry system configuration.
  - fulafel 5y ago
    I guess you are thinking of a situation where you would run this on a on-prem server system that you had a hand in spec'ing out? Yes it's possible to do this, but most Node apps in use run in various cloudy environments, possibly containerized, that you have less control over, and of course on random dev setups that people have. If you put out an open source Node module, you'll have devs trying to run it on systems with plentiful variability.
    - jatone 5y ago
      even in cloud environments you control the environment by choosing to use that service.

kevingadd 5y ago

Using OpenGL (or Vulkan) to talk to the GPU is one of the most portable things around. It works more places than Node does, even

fulafel 5y ago
This is technically true, if you don't count WebGL, but the bar is very low. Nontrivial OpenGL apps are epic battles requiring you to carefully & constantly test and debug zillions of configuration combos, with implementation specific OpenGL bugs, workarounds thereof, and delaing with myriad combos of feature and OpenGL version availability. A bit like SQL is portable for some meaning of "portable" (ANSI SQL!), only much worse. Also Apple keeps threatening to kill OpenGL so any day now all the people developing on Mac might lose the ability to dev this headless component locally. (And this was always the situation with Vulkan.)