3 ms·
It's a C++ library that Google needs to secure and maintain security patches forever. If there's any bug in that library, it's Chrome and Google that will get b
by izacus 3y ago
It's a C++ library that Google needs to secure and maintain security patches forever. If there's any bug in that library, it's Chrome and Google that will get blasted and blamed by rabid news media and HNers - so people here are essentially demanding that private company supports and patches their library for ever and ever. Once released, it's pretty much impossible to rollback support for media formats on the web.
Behaving like there's no cost in such maintenance is just whack.
- josefx 3y ago> It's a C++ library that Google needs to secure and maintain security patches forever. Compile it to wasm and run it in a sandbox? Or throw some rust groupies at it? > Once released, it's pretty much impossible to rollback support for media formats on the web. We must live in a time where flash still dominates short web animations, streaming providers use silver light and every enterprise user is stuck waiting for the companies 5GB Java applet to load right when IE6 suddenly pops up to kill everything with an ActiveX based Windows update that adds more video codecs instead of removing them from the system. The list goes on forever. Browsers are not above killing features and breaking things for security reasons or if they just feel like it.
- magicalist 3y agoMaintaining your own rust fork of a codec or forcing the web through another painful breaking change drawn out over years seem like fantastic arguments to wait until the ecosystem is visibly moving to jpegxl before committing to it, actually.
- spider-mario 3y agoIt wouldn’t be a fork, it would be another implementation. There are already a few.
- jeffbee 3y agoChrome uses WUFFS to decode GIFs. It could also use WUFFS to decode JXL, if WUFFS supported JXL.