4 ms·
Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack
by EMM_386 10mo ago
Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface?
I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we've had since forever.
- tensegrist 10mo ago100M+ is a bit more than i would expect for an image format. have i not been paying attention
- crooked-v 10mo agoIt's a container format that does about a bajillion things - lossy, lossless, multiple modes optimized for different image types (photography vs digital design), modern encode/decode algorithms, perceptual color space, adaptive quantization, efficient ultra-high-resolution decoding and display, partial and complete animation, tile handling, everything JPEG does, and a bunch more.
- furyofantares 10mo agoThe Linux kernel is 40M lines of code after 34 years of development. OP might have well have said "infinite lines of code" for JPEGXL and wouldn't have been much less accurate. Although I'm guessing they meant 100k.
- aw1621107 10mo agoAccording to tokei, the lib/ directory from the reference implementation [0] has 93821 lines of C++ code and 22164 lines of "C Header" (which seems to be a mix of C++ headers, C headers, and headers that are compatible with both C and C++). The tools/ directory adds 16314 lines of C++ code and 1952 lines of "C Header". So at least if GP was talking about libjxl "100K+" would be more accurate. [0]: https://github.com/libjxl/libjxl https://github.com/libjxl/libjxl
- palmotea 10mo ago>> 100M+ is a bit more than i would expect for an image format. have i not been paying attention > So at least if GP was talking about libjxl "100K+" would be more accurate. M can mean thousands and I think it's common to use it used that way in finance and finance-adjacent areas: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Abbreviations/faq0094.html https://www.chicagomanualofstyle.org/qanda/data/faq/topics/A...: > A. You’ve identified two commonly used conventions in finance, one derived from Greek and the other from Latin, but neither one is standard. Starting with the second convention, M is used for amounts in the thousands and MM for amounts in the millions (usually without a space between the number and the abbreviation—e.g., $150M for $150,000 and $150MM for $150 million). This convention overlaps with the conventions for writing roman numerals, according to which a thousand is represented by M (from mille, the Latin word for “thousand”). Any similarity with roman numerals ends there, however, because MM in roman numerals means two thousand, not a thousand thousands, or one million, as in financial contexts... https://www.accountingcoach.com/blog/what-does-m-and-mm-stand-for https://www.accountingcoach.com/blog/what-does-m-and-mm-stan...: > An expense of $60,000 could be written as $60M. Internet advertisers are familiar with CPM which is the cost per thousand impressions. > The letter k is also used represent one thousand. For example, an annual salary of $60,000 might appear as $60k instead of $60M.
- WheatMillington 10mo agoI assume this is regional... I work in accounting and finance in New Zealand (generally following ordinary Western/Commonwealth standards) and I've never heard of using M for thousands. If I used that I would confuse the hell out of everyone around me.
- mkaic 10mo ago"It's... a regional dialect." "What region?" "Er, upstate New York." "Really. Well, I'm from Utica and I've never heard anyone use the phrase '100M' to mean '100 thousand'" "Oh, no, not in Utica. It's an Albany expression."
- deleted 10mo ago
- GaggiX 10mo agoThey wanted to say 100K instead of 100M
- EMM_386 10mo agoThey did indeed.
- munificent 10mo agoThe article says 100K, not 100M. I'm guessing that's what the parent comment meant. 100MLOC for an image format would be bananas. You could fit the entire codebases of a couple of modern operating systems, a handful of AAA videogames, and still have room for several web apps and command line utilities in 100MLOC.
- JyrkiAlakuijala 10mo agothe article includes test code and encoder code, that is not the way how we compute the decoder size the decoder is something around 30 kloc
- EMM_386 10mo agoYou are correct, "K" not "M" in my typo.
- dataflow 10mo agoYou mean 100K+? A large chunk of which they say is testing code?
- ajcp 10mo ago-> They were concerned about the increased attack surface resulting from including the current 100K+ lines C++ libjxl reference decoder, even though most of those lines are testing code. Seems like Google has created a memory-safe decoder for it in Rust or something.
- cornstalks 10mo agolibjxl is is <112,888 lines of code, about 3 orders of magnitude less than you're 100M+ claim.
- sunaookami 10mo agoDo people really not know what a hyperbole is?
- cornstalks 10mo ago100M+ lines of code isn't a hyperbole for some codebases, though. google3 is estimated at about 2 billion lines of code, for example. Maybe it was hyperbole. But if it was it wasn't obvious to me, unfortunately.
- MaxBarraclough 10mo ago> I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.
- dgacmu 10mo ago99% safe with 1% unsafe mixed in is far, far better than 100k loc of c++ -- look at Google's experience with rust in Android. It's not perfect and they had one "almost vulnerability" but the rate of vulnerabilities is much, much lower even with a bit of unsafe mixed in.
- MaxBarraclough 10mo agoAgreed, and Google developers can probably be trusted to 'act responsibly', but too often people forget the distinction. Some Rust codebases are wildly unsafe, and too often people see written in Rust and falsely conclude it's a memory-safe codebase.
- otabdeveloper4 10mo ago> ...but now in le Rust!!1 I look forward to the next generation of rubes rewriting this all in some newer ""safe"" language in three decades.
- UltraSane 10mo agoBecause a language happily letting you try to access an array index far past its end isn't stupid at all.
- otabdeveloper4 10mo agoIf this was a real problem then you could have just `s/[]/at()/g` across your codebase and called it a day. But you all don't even bother to do that, so I guess it's not actually a problem in practice.
- UltraSane 10mo agoC doesn't have any protection for accessing out of bounds. It does zero bounds checking behind the scenes. Which is actually really, REALLY stupid. And when all computers are connected to the internet this is disastrous.
- otabdeveloper4 10mo ago> It does zero bounds checking behind the scenes. Thankfully you can fix that with one sed command. Why don't you?
- theoldgreybeard 10mo agobecause memory safety is the only attack vector, as we all know
- JyrkiAlakuijala 10mo agoThis is some strange misinformation. The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code. It is not difficult to measure from the repository. The compiled compressed binary for an APK is 5x smaller than that of full AVIF. The complete specification at under 100 pages is ~13x more compact than that of full AVIF.
- charleslmunger 10mo ago>The compiled compressed binary for an APK This doesn't undermine your argument at all, but we should not be compressing native libs in APKs. https://developer.android.com/guide/topics/manifest/application-element#extractNativeLibs https://developer.android.com/guide/topics/manifest/applicat...
- bmicraft 10mo agoGoogle is one of the parties involved in the creating of jxl. If it's their own fault they didn't write a decoder in a memory safe language sooner.