For now, but with EU digital sovereignty efforts in full swing, it's possible this changes over time. More so if the EU uses regulation to dissuade the use of US Big Tech products and services.
This is round 5 or 6 of a " EU digital sovereignty efforts in full swing" maybe this time they will having a success or two but nothing seems to indicate they've changed enough to avoid failing again.
... which is irrelevant to the demonstrated and shocking incompetence of being unable to deliver either to the #1 or #2 inbox for businesses in the EU?
because the author self admitted they don't know C! One of the reason why people use the Beam VM is because its robust and fault tolerant.
a lot of the choice here are made at the expense of VM's health.
also why wouldn't anyone just use :disksup.get_disk_info/1. (Thats immediate)
calling :disksup.get_disk_info/1 won’t mess with the scheduler in the way a custom NIF or a big blocking port might.
I see the above code/lib and just see reflags all over the place.
The post explains why I don't want to use disksup. You have to start an extra application (os_mon) and configure disksup to update the starts more frequently than the default of every 30 minutes.
Do we really need to do all that instead of the equivalent of a df?
Agree about the C code, which is why the latest version (on GitHub, the HEAD, not yet released in Hex.pm) is now using Rust and Rustler.
:disksup.get_disk_info/1 (from :os_mon) just calls into the underlying OS once, grabs the info, and returns it. It’s not a blocking “long-running monitor” the way a NIF doing I/O in a scheduler thread would be.
https://www.erlang.org/docs/26/man/disksup#get_disk_info-1