The latest news and developments on Firefox and Mozilla, a global non-profit that strives to promote openness, innovation and opportunity on the web.
You can subscribe to this community from any Kbin or Lemmy instance:
Related
While we are not an official Mozilla community, we have adopted the Mozilla Community Participation Guidelines as far as it can be applied to a bin.
Always be civil and respectful
Don't be toxic, hostile, or a troll, especially towards Mozilla employees. This includes gratuitous use of profanity.
Don't be a bigot
No form of bigotry will be tolerated.
Don't post security compromising suggestions
If you do, include an obvious and clear warning.
Don't post conspiracy theories
Especially ones about nefarious intentions or funding. If you're concerned: Ask. Please don’t fuel conspiracy thinking here. Don’t try to spread FUD, especially against reliable privacy-enhancing software. Extraordinary claims require extraordinary evidence. Show credible sources.
Don't accuse others of shilling
Send honest concerns to the moderators and/or admins, and we will investigate.
Do not remove your help posts after they receive replies
Half the point of asking questions in a public sub is so that everyone can benefit from the answers—which is impossible if you go deleting everything behind yourself once you've gotten yours.
@[email protected] To put in perspective:
@[email protected] or about C++ and the state of coding and programming language tooling...
@bagder (i will keep banging the drums that most of the FOSS "supply chain" fear could be handled by investing more in programming language tooling, as Rust demonstrate, and that it would be a small overall cost for massive pay off...)
@Di4na possibly: I believe Rust is generally a good thing for most things, but I believe the Rust ecosystem with cargo and bazillions of always-updatiing tiny dependencies risk adding friction and at least complicates the equation quite a lot
@[email protected] i mean yes, but at least the compiler is a tool.
While C and others are uh. Well some are finally realising they have users
@[email protected] This is my biggest worry too: they essentially copied the NPM package management model and practices. Good for short term productivity, but I worry that it causes significant long-term maintainability problems.
And everything is version 0.x, in part due to technical limitations of Cargo: moving out of 0.x is a breaking change, so if you have users on 0.x (which Cargo encourages by treating 0.x specially) moving out of 0.x breaks them.
@[email protected] @[email protected]
I'm not sure it is a tooling issue. I find cargo to be a great tool, and it have a lock file to let you update deps in a controlled fashion.
I think this comes down to a cultural issue, where the rust community, much like the JS community, put every little utility function in it's own library. Hence, you tend to get a gazillion small dependencies that is hard to keep track of.
@bagder I think it is a bit misleading (and arguably unfair) to attribute this to Firefox specifically: this is the reference jpeg-xl implementation, originally created and maintained by Google, and in widespread experimental use across all kinds of browsers, including Chromium, Safari, Edge and more
@bagder We had 100kloc C++ in a smart radiator valve that saved a bunch of extra energy.
I think it is just a reflection that extracting efficiency requires complexity.
@[email protected]
I really don't envy the people who'd have to rewrite that monstrosity.
See https://flak.tedunangst.com/post/on-building-jpeg-xl-for-wasm by @[email protected] for the current state of the art method of decoding jpegxl safely, which is both hilarious and sad.
@[email protected] It's a good hot take, but what amazes me most is the replies so far immediately jumping to conclusions with biased gut reactions as if their identity is tied to one or the other camp.
@[email protected] Wait, so JPEG XL isn't completely dead? That's probably not what you meant to communicate but I'm so happy to hear that
fwiw I think that LOC of the reference implementation doesn't really say anything about anything - even if Firefox "adopted" it, which feels like a sensible choice given the state of things
@[email protected] could isolate the decoder in a WASM runtime and only starting the rewrite if and when the format becomes popular enough :-)
@[email protected] It’s what I wondered when I saw https://jxl-art.surma.technology/ and https://jpegxl.info/art/
@[email protected] browser vendors should coordinate which subset of JPEG XL they want to support, and only this part of the standard needs to get implemented.
I remember JPEG and that you could never use progressive JPEGs. Some programs even offered an “export for web” feature so that you wouldn't use any unsupported JPEG features.
@[email protected]
And, just wondering:
How many of those lines are for handling security issues such as boobytrapped JPEGs?
How many lines do the other HTML rendering engine use for the same function?
The graphical web has many sins to make amends for!
@[email protected] To be clear, this is just the reference implementation at https://github.com/libjxl/libjxl
@freddy ... and that happens to be the one Firefox uses...
@[email protected] Well, it seems that your point is "Firefox consists of bad code", whereas I believe that the conclusion from the post should be "The library is bad code, which is why we are not using it in production. We'd be happy to look at their rust implementation, when it's possible"
(footnote: "bad code" being an abbreviation of "100k multi-threaded C++")
@freddy you're reading too much into my words. I'm just amazed by how large the existing JPEG XL decoder is.
And I don't think I am alone.
@[email protected] Oh, OK. Sorry for misreading then. I'll back off. 🙂
(And yes, the existing library is... 🤯)
@[email protected] @freddy
and "uses" in this case means "has it available behind a feature flag in their nightly builds, and does not ship it to normal users because of this very issue"
@[email protected] I wonder if it's turing complete... something something Pegasus 0-click iMessage exploit.
@[email protected] yeah, kinda puts into perspective all the 'negative feedback' the Chrome team received for removing JPEG-XL support. I wouldn't want to have such a monstrosity in my code base either, no matter what advantages the actual encoding might have over existing formats.