Nice find. That indeed sounds terrible for anyone executing external code in what they believe to be sandboxes. Good thing it can be patched (and AFAICT, it seems to be a good fix, rather than a performance-affecting workaround.)
The biggest issue isn’t being able to run locally, it’s getting access to systems where an unexpected error is happening in production that didn’t happen in dev.
This is not a pitfall of an environment; this is a pitfall of awful programming. It's nice that the rescale folks have implemented a workaround, but it shouldn't stop users from pressuring the vendors for better software.
I would also love to see that dhclient issue resolved upstream, or at least a cleaner way to work around it. But we should also be mindful that for most workloads the impact is probably way, way less.
Some of these things really only show up when you push things to their extremes, so it probably just wasn't on the developer's radar before.
We maintain a lightweight platform alongside a legacy platform that is an untestable ball of mud. This resulted from rapid implementation of business demands over the years, along with a practice of addressing numerous data quality problem through hacks in components, rather than cleaning the data or using a sanitization layer to access it.
Lack of dependency inversion in systems like this is truly the road to ruin, as the system complexity grows so quickly in time, due to interactions, that eventually nobody really understands what it does or why it does it.
I suppose this is tolerable for some applications, but if you need to numerically validate it, it's a nightmare.
It has a significant goal that tends to degrade performance: it needs to disallow exposing undefined or unsafe behavior of the driver to the client, regardless of how crazy the calls are.
It is not a real issue in modern days. You just enable address sanitizer in all your debug builds and these issues are obvious at runtime (still not perfect, but an improvement from dark days).
Maybe "add a runtime that switches execution contexts on behalf of the user" and "force the programmer to reimplement everything" are not the only options.
It's a flaw for performant client-specific/standalone graphical use, yes. Literally one that the Linux community fought with with multiple hacks (DRI, AIGLX, etc) through the years.
It's not a flaw if you want to run a thin-client from a central machine or otherwise offer a networked interfacing system, no.
One of those use cases is far more common today than the other.
they also mention async rendering. cool.
but they also did in ways that breaks the Detox e2e testing framework ,if i am not mistaken, in a way that is difficult to fix without proper support from RN code itself.
this kind of stuff is awkward. do something new cool, but break major functionality for some users of RN.
The biggest problem with this is that no one is maintaining all of those old userlands, so when you use an old userland, you are reintroducing tons of known and fixed (but not backported) bugs, including many serious security issues.
reply