[HN Gopher] FSF Slams Google over Dropping JPEG-XL in Chrome
___________________________________________________________________
FSF Slams Google over Dropping JPEG-XL in Chrome
Author : YakBizzarro
Score : 186 points
Date : 2023-04-16 11:50 UTC (11 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| ifeeltriedboss wrote:
| Google is so SLAMMED now
| shp0ngle wrote:
| Yeah
|
| Look how FSF slammed Apple in the past for their iPod ecosystem
| with "defective by design". Apple never recovered from that
| csdreamer7 wrote:
| One of the most interesting things to me is that JPEG-XL is under
| an open Patent License, unlike the original JPEG.
|
| https://en.wikipedia.org/wiki/JPEG_XL
|
| Also, Google contributed quite a bit to it's development. As the
| patent grants show:
|
| https://github.com/ImageMagick/jpeg-xl/blob/main/PATENTS
|
| https://github.com/libjxl/libjxl/blob/main/PATENTS
|
| Microsoft seemed to have gotten a patent on part of it's
| implementation (which Google also tried to get). Not sure if
| Google will pay to invalidate that patent, but I have a feeling
| they are more likely to defend AVIF.
|
| https://www.theregister.com/2022/02/17/microsoft_ans_patent/
|
| Google's control is a little concerning, but I do feel there are
| bigger fish to fry then choosing between two free formats. A
| bigger concern is the H.264 and H.265 patents domination of
| video.
| rwmj wrote:
| But surely JPEG is patent free by now (having been invented in
| the very early 90s)? To be honest I'm confused about what FSF's
| argument is here, as JPEG seems just fine to me.
| Beldin wrote:
| I don't know what the FSF's argument is. I personally don't
| feel very strongly yet about this, but I am not comfortable
| with the "JPEG is sufficient" line of reasoning.
|
| I don't know what the world could look like if a much-
| improved image format was common, but I don't think I'll see
| that future as long as the browser with 90% market share
| doesn't support that new format.
| csdreamer7 wrote:
| Yes, the original JPEG is patent free now. The point of my
| comparison was between the times that both of them were
| seeking adoption.
| iambateman wrote:
| I mean...it's a PR issue more than anything. I know what webp is
| and I had never heard of jpeg-xl.
|
| I think that's true for a lot of people. Maybe one of them is
| better, but webp definitely has a distribution advantage by a
| mile.
| Y_Y wrote:
| While I'm aligned with the FSF in most things, I'm happy to link
| to a bug tracker despite its shitty JS.
|
| https://chromium-review.googlesource.com/c/chromium/src/+/40...
|
| Maybe they're sour about webp not obseleting all other formats by
| now?
| rippercushions wrote:
| That's the pull request, the actual discussion is in this bug:
| https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
|
| And apparently JPEG XL, which was only added in 2021, will be
| supported again from Chrome 117 onward.
| ninepoints wrote:
| That was an april fool's joke
| mef wrote:
| is there any evidence for this other than this tweet?
| samwillis wrote:
| > will be supported again from Chrome 117
|
| That appears to have been an April 1st joke:
|
| https://twitter.com/jonsneyers/status/1642039947719745537?t=.
| ..
| [deleted]
| zxcvbn4038 wrote:
| Mozilla had the same issue - it was one engineer who stubbornly
| kept webp support out of the browser for years. Then he quit or
| got laid off and Mozilla finally got support. Mozilla also
| refused to support Yubikey for years, which we are still paying
| for now. It seems to me like Mozilla forgot really quickly what
| life was like when Internet Explorer was the dominant browser.
| Half the reason Chrome can ignore community outrage is because
| Mozilla decided existing options were "good enough" and stopped
| being competition.
|
| That said though, that FSF guy is nuts. He can't link to their
| bug tracker because it uses Javascript? I think that battle is
| lost. But he did obviously read the tracker, does this mean he
| has to remove his tinfoil hat and go bathe in the living waters
| of Richard Stallman's bathtub?
| quadrangle wrote:
| Maybe you misread or misunderstood (although maybe it makes no
| difference to you), but the specific issue is: the FSF _won 't_
| link to the bug tracker (not can't) because of _proprietary_
| Javascript. The FSF has no absolute rejection of JS, they just
| are purist about the JS being free software.
|
| And it wasn't a personal post by an "FSF guy", it's the stance
| of the whole FSF organization.
|
| Yes, the battle is lost. Fighting an effectively lost battle
| isn't necessarily nuts, but criticizing it is quite
| understandable.
| [deleted]
| xoa wrote:
| So a few dozen comments, but so far it doesn't look like any
| mention the immediate thing that jumped out at me which was the
| claims vs AVIF:
|
| > _" In turn, what users will be given is yet another facet of
| the web that Google itself controls: the AVIF format."_
|
| Huh? I'll admit I haven't been following codecs as super ultra
| closely as I used to, but I thought AOM was a pretty broad
| coalition of varying interests and AV1 an open, royalty free
| codec that was plenty open source friendly? I've heard plenty of
| reasonable arguments that JPEG XL has some real technical
| advantages over AVIF and as well as superior performance is much
| more feature rich and scalable. So I could see people being
| bummed for that. But this is the first time I've heard the
| assertion that it's somehow a Google project? I mean, AOM's
| libavif reference is BSD too [0]? I'd love some more details on
| that from anyone who has been following this more closely. I can
| even understand if AOM isn't as community friendly and an
| accusation that it's dominated by big corps, but in that case why
| single out Google alone? From wiki:
|
| > _The governing members of the Alliance for Open Media are
| Amazon, Apple, ARM, Cisco, Facebook, Google, Huawei, Intel,
| Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and
| Tencent._
|
| Like, Google is certainly significant, but that's a lot of
| equally heavy hitters. And interesting that Mozilla is there too.
|
| ----
|
| 0: https://github.com/AOMediaCodec/libavif
| pessimizer wrote:
| > Like, Google is certainly significant, but that's a lot of
| equally heavy hitters. And interesting that Mozilla is there
| too.
|
| Mozilla is a dependent of Google's. The thing that stands out
| about that list is that aside from Google and Facebook (who
| completely control their markets), the New Microsoft and the
| aforementioned Mozilla, most of these companies are notoriously
| openly hostile to anything open.
| jerryX wrote:
| In practice AVIF is made practically only by Google team.
|
| Good summary from
| https://www.phoronix.com/forums/forum/phoronix/latest-
| phoron... : Max image size is limited to 4K
| (3840x2160) in AVIF, which is a deal breaker to me. You can
| tile images, but seams are visible at the edges, which makes
| this unusable. JPEG XL supports image sizes of up to
| 1,073,741,823x1,073,741,824. You won't run out of image space
| anytime soon. JXL offers lossless recompression of
| JPEG images. This is important for compatibility, as you can
| re-encode JPEG images into JXL for a 30% reduction in file
| size for free. AVIF has no such feature. JXL has a
| maximum of 32 bits per channel. AVIF supports up to 10.
| JXL is more resilient to generation loss.5 JXL
| supports progressive decoding, which is essential in web
| delivery, IMO. AVIF has no such feature. AVIF is
| notoriously based on the AV1 video encoder. That makes it far
| superior for animated image sequences, outperforming JXL in
| this department by a wide margin. However, JXL also supports
| this feature. AVIF is supported in most major
| browsers. This includes Chrome (and derivatives) and Firefox
| (and forks). JXL is supported by almost nobody right now.
| Only Thorium, Pale Moon, LibreWolf, Waterfox, Basilisk and
| Firefox Nightly incorporate it. Most of these are community-
| maintained forks of Firefox. That is a big downside for
| adoption, as I already ranted about in this post.
| Both formats support transparency and wide gamut (HDR).
| xoa wrote:
| So right away on the first item:
|
| > _Max image size is limited to 4K (3840x2160) in AVIF,
| which is a deal breaker to me. You can tile images, but
| seams are visible at the edges, which makes this unusable.
| JPEG XL supports image sizes of up to
| 1,073,741,823x1,073,741,824. You won't run out of image
| space anytime soon._
|
| > _JXL has a maximum of 32 bits per channel. AVIF supports
| up to 10._
|
| Max resolution and bit depth is certainly massively higher
| for for JPEG XL, but spec [0] says that:
|
| > _" NOTE: [AV1] supports 3 bit depths: 8, 10 and 12 bits,
| and the maximum dimensions of a coded image is 65536x65536,
| when seq_level_idx is set to 31 (maximum parameters
| level)."_
|
| And 12-bits per channel is considered a lot for end user
| final display formats? It also seems to be supported in
| browsers too so it's not just theoretical. It looks like
| back in 2021 there was discussion around this and
| clarifying that the profiles decided on in 2018/2019 were
| more about giving targets for hardware acceleration of the
| time, but software decoders by 2021 supported essentially
| the whole spec (and it appears to me that another 2 years
| later now final lingering stuff has been dealt with) [1,2]:
|
| > _Cyril has proposed a pull request (#130) to better
| clarify what is and is not supported in AVIF. In short,
| AVIF supports everything that AV1 supports, which includes
| 12-bit encoding. The current software decoder
| implementations also support more or less all of AV1, which
| can be seen if you try to decode a 12-bit AVIF file in a
| web browser._
|
| And for still images, hardware acceleration isn't
| important, so as a practical matter unlike AV1 video pure
| software for max features is fine. So 65k x 65k and 36-bit
| color appear to be the limit, which definitely isn't as
| much as JPEG XL, but is pretty respectable for majority of
| end user usage?
|
| Edit to add: the comments there also mention complaints
| that the JPEG XL author has a history of spreading
| misinformation about AVIF, "See the article and infographic
| recently posted by the JPEG-XL author that claims (among
| other things) that AVIF does not support 12-bit images". So
| apparently there has been some good old dev drama going on
| during the last few years which means one may need to be a
| little suspicious about any "Good summaries" :(.
|
| ----
|
| 0: https://aomediacodec.github.io/av1-avif/#profiles-
| overview
|
| 1: https://github.com/AOMediaCodec/av1-avif/issues/128
|
| 2: https://github.com/AOMediaCodec/av1-avif/pull/130
| kps wrote:
| > And 12-bits per channel is considered a lot for end
| user final display formats?
|
| WebP and AVIF introduced a bifurcation between general
| purpose image formats and 'end user final display
| formats' (i.e. internet delivery to consumer
| entertainment devices). I don't think this is a good
| thing.
| zinekeller wrote:
| > and the maximum dimensions of a coded image is
| 65536x65536
|
| As pointed out in another comment, this is less of 65536
| by 65536 and more of 65536* by 65536* if you followed
| some more complicated steps. Considering that the
| original JPEG supports that without relying internally on
| multiple images (the trick AVIF used to "support" the
| full 65536 by 65536), it seems not suitable for software
| which writes images in one pass.
| brigade wrote:
| No, it's AV1 that uses (up to) 16-bit fields for image
| dimensions. HEIF grids, which is the AVIF feature that
| combines multiple AV1 images into one, have 32-bit fields
| for dimensions so are limited only by what the decoder is
| willing to allocate.
| Wowfunhappy wrote:
| > Max image size is limited to 4K (3840x2160) in AVIF
|
| What?! That is _terrible_ for a next-generation image
| format, and should be an immediate and obvious dealbreaker
| for introducing any type of support.
|
| It would be one thing if AVIF was a legacy format already
| in widespread, but anything _new_ should be several orders
| of magnitude more future-proof.
| izacus wrote:
| Maximum image size for AVIF is 65535x65535, no idea where
| you're all picking up this crock.
| formerly_proven wrote:
| Seems to be not so simple.
|
| > AVIF has different limitations when it comes to the
| highest megapixel count / largest dimensions. Several
| decoders may not support larger images, so single-coded
| photos do not exceed 4k resolution. According to AV1,
| AVIF Baseline profile coded image items must not have
| more pixels than 8912896 or wider widths or higher
| heights than 8192 or 4352. The Baseline profile can still
| be used to create larger images using grid derivation.
| You might encounter discontinuities along the grid
| boundaries, depending on how the image is decomposed. For
| this particular case, however, the maximum size of a
| coded picture is 65536x65536.
|
| https://avif.io/blog/faq/avif-megapixel/
|
| So as I understand this, anything with more than ~9 MP
| would be encoded in some kind of tiled way, possibly
| introducing artifacts where tiles meet.
|
| However, another blog post claims different limits
|
| > The default limit of AVIF is 8K. Video professionals
| will recognize this as the size of an 8K video frame. It
| is possible to break this limit for both formats by
| independently encoded tiles of 8K frames. But this method
| introduces artifacts at the tile boundaries, affecting
| the overall appearance of images.
|
| https://avif.io/blog/comparisons/avif-vs-heif/
| brigade wrote:
| The profiles only matter if you want to be decodable by
| hardware decoders. If you only care about software
| decoders, which must be true if JPEG-XL is your
| comparison, then you don't have to use the HEIF grid for
| large dimensions, and the better question is how much
| memory your application will allow to be allocated.
| Because chances are JPEG's maximum 65535x65535 exceeds it
| that too.
|
| AV1 itself allows a maximum of 65536x65536 for a single
| picture, whereas the HEIF grid hypothetically allows even
| more than that regardless of how large each individual
| picture is (HEIF grid dimensions are 32-bits). As a
| practical example, libavif will not use the grid for
| large dimensions unless explicitly told to do so, by
| default producing files that aren't compliant to either
| baseline or advanced profiles.
|
| (to further my pedantry against your source: AVIF is a
| subset of HEIF; what people usually mean by "HEIF" is the
| HEIC subset)
| izacus wrote:
| It is that simple, you're just noving the goal posts.
|
| The concept of profiles is nothing new to ensure HW
| decoder compatibility and JPEG-XL offers nothing extra
| there either (except no support for the concept ensuring
| that HW decode isn't possible at all).
|
| Pretty much all newer formats are tiled in some way too -
| even JPEG.
| pixelesque wrote:
| The format supports that technically (the resolution is
| stored in two uint32_t variables), but libavif however
| currently seems to have pretty small limits in this area
| based off attempts a few months ago to try using it for
| high res photos: I couldn't get it to save images of size
| 8192 x 5464 (native Canon R5 res). avifEncoderAddImage()
| just returns a generic error when the size is too big. If
| I reduced the size of the image a bit, it then worked.
|
| Given I was trying to store high res panoramas of even
| larger dimensions, I was pretty surprised at the apparent
| limits, wherever they exist in the callstack.
| [deleted]
| [deleted]
| jcranmer wrote:
| >> The governing members of the Alliance for Open Media are
| Amazon, Apple, ARM, Cisco, Facebook, Google, Huawei, Intel,
| Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and
| Tencent.
|
| > Like, Google is certainly significant, but that's a lot of
| equally heavy hitters. And interesting that Mozilla is there
| too.
|
| The Alliance for Open Media basically arose from the fact that
| MPEG decided to use the success of H.264 to charge a king's
| ransom in licensing fees for H.265, whereupon most of the
| consumer industry took one look at those fees and said "we need
| a free alternative."
| kmeisthax wrote:
| To be fair to MPEG, they don't actually run the patent pools,
| they just make everyone promise to join one.
|
| MPEG-LA is the patent pool that everyone was using and it was
| assumed that would be the case for H.265. HEVC Advance and
| Velos Media realized they could break this business structure
| by giving a few net-implementer companies (e.g. Samsung) a
| sweetheart deal on patent licensing if they moved their
| patents over to their pool. They paid for this by double-
| charging people who were already licensed through MPEG-LA for
| those patents.
|
| Leonardo Chiariglione, co-founder of MPEG, tried to get ISO
| to change their patent policy to allow more scrutiny of
| patent ownership in standards. ISO responded by... denying
| Leonardo's petitions, cutting MPEG up into pieces, and
| pushing him out of the working group he built.
|
| Funny thing is, MPEG actually knows royalty-free video
| encoding is a thing people want. They've tried building an
| ISO standard for that. Problem is, ISO's patent policy only
| allows removing patented technology from a standard if the
| technology is not licensable - not if the technology is too
| expensive. So their standardized royalty-free codecs[0] are
| not actually royalty-free and nobody uses them.
|
| The underlying problem was pointed out by Leonardo on his
| blog: patent owners want to go back to the days of charging
| an arm and a leg for MPEG-2, and they are willing to suck the
| brains out of MPEG in order to do it, under the assumption
| that people were paying royalty fees for the ISO branding
| rather than for the technical superiority of the standard.
| MPEG is not the cause of this problem, they are a victim of
| it.
|
| [0] Fun fact: Google outright just submitted VP8 to MPEG as a
| candidate for MPEG IVC, but they decided against using it in
| favor of building their own royalty-free standard.
| teddyh wrote:
| Actual link: https://www.fsf.org/blogs/community/googles-
| decision-to-depr...
| CharlesW wrote:
| All of the people here who are so passionate about JPEG-XL will
| be happy to learn that there's nothing preventing them from using
| it on their sites right now:
|
| https://github.com/niutech/jxl.js
|
| If you want Chrome to ship with JPEG-XL support, use it. At some
| point, browser makers will decide it's worth the incremental cost
| (to them and all users) to add it.
| zamadatix wrote:
| A bundling approach works great for web apps (e.g. an online
| image editor) but for serving images you have to be willing to
| not only lose any of the size and speed benefits but to
| completely demolish your website's performance all in hopes one
| day enough sites agree to do the same.
| CharlesW wrote:
| If the advantages of JPEG-XL are not worth websites
| downloading ~300KB (the size of 1 or 2 "hero" images) to
| users, one could argue that browser makers shouldn't add it
| to every download of their browser in perpetuity.
| zamadatix wrote:
| To be clear I'm not a fan of adding JPEG-XL to browsers
| rather I think you're presenting a strawman for why. Even
| if the size overhead were 0 bytes you're still completely
| ignoring the project page says it takes ~0.8 seconds (~0.5
| multithreaded) to load 0.2 kilobyte image files with
| nothing else going on. An infinitely better format wouldn't
| make sense to a lot of sites.
|
| That is to say people excited about JPEG-XL being removed
| aren't simply just ignorant they could decode it via
| JavaScript/WASM. Mostly they seem to disagree on what
| "enough improvement" to outweigh the cost of a shipping a
| new format is. E.g. Cloudinary is a commonly referenced
| proponent not by chance but because they operate a media
| CDN and it makes sense for them to present lots of material
| about the advantages vs say a single site.
| CharlesW wrote:
| > _To be clear I 'm not a fan of adding JPEG-XL to
| browsers rather I think you're presenting a strawman for
| why._
|
| I'm trying to make a good faith argument that if even
| passionate fans of the format are not willing to bear the
| time and bandwidth equivalent of loading a small number
| of images to use the format, that's a strong signal that
| it's not worth it.
| edflsafoiewq wrote:
| There is indeed nothing in JPEG-XL worth breaking the
| entire image ecosystem for, where the image can used in a
| normal <img> tag, where you can direct link to the image
| URL, where you can save the image, where you can upload
| the image to any site you want, where you can see the
| thumbnail in your file browser, where you can open it in
| any image editor, etc.
|
| There is probably never going to be an image format that
| would be worth throwing all that away for a JS shim that
| dumps pixels into a <canvas>. But that doesn't mean it is
| never worth adopting a new format into the image
| ecosystem.
| threeseed wrote:
| To save people some clicks here are the two discussions:
|
| * https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
|
| * https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
| zamadatix wrote:
| Discussion about the root article from FSF:
|
| - https://news.ycombinator.com/item?id=35554107
|
| Similar discussions when Chrome/Mozilla were removing it:
|
| - https://news.ycombinator.com/item?id=33563378 (dang's comment
| has a list of additional related at the time)
|
| - https://news.ycombinator.com/item?id=33803941
|
| Relevant discussions:
|
| - https://news.ycombinator.com/item?id=35212522
|
| - https://news.ycombinator.com/item?id=33442281
|
| - https://news.ycombinator.com/item?id=35018672
| jeroenhd wrote:
| Google removes a standard nobody uses, I don't see the problem.
| AVIF is a decent alternative that can actually be used in modern
| browsers, with WebP as a fallback.
|
| We've got plenty of open image formats for the web already. I
| don't get why people get so hung up about JPEG XL, it's not as if
| they're trying to force HEIF onto you like some other tech
| companies do.
| vehemenz wrote:
| The same reasoning could have applied to AVIF and WebP a few
| years ago. Nobody used these formats back then, so what's the
| problem if Google discontinues them?
| zamadatix wrote:
| There was a long period between the jpg/png/gif era and free
| alternatives that were significantly better but could replace
| all three format use cases (really 4, if you count that they
| were just a special format of the video codec they
| introduced). Even between webp and avif there was about a
| decade gap.
|
| Despite this jpg/png/gif aren't really gone and at the same
| time jpegxl is a one off codec for images. Mozilla didn't see
| the rush to introduce another format either but the FSF
| article isn't going to talk about that. Jpegxl definitely has
| some cool stuff about it and from the technical side I love
| it but from the "god damn it why isn't this saved image
| working this time" perspective I'm not angry at all to the
| browsers for not supporting it. Hell I'm still waiting for
| Microsoft to feel ready to enable AVIF in Edge when they had
| an employee as an editor for the standard.
| bick_nyers wrote:
| No one used it because they were waiting for it to not be
| behind a development flag in Chrome etc.
|
| My backend had the code written and ready to go, just
| waiting...
| Someone1234 wrote:
| This is worth looking at:
|
| https://caniuse.com/jpegxl
|
| Unless I'm misunderstanding that, no browser actually ever
| supported JPEG-XL without a flag (or at all on Safari's cases).
| No OS appears to have supported it natively either[0]. The
| reality is that formats have a chicken & egg problem. Normally
| Google deserves to get dunked on, but in this case, why is Google
| the scapegoat instead of the entire industry that didn't adopt
| it? Feels like there is a bigger issue with JPEG-XL's failure to
| launch, and they did more than some (Apple? Microsoft?).
|
| [0]
| https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a...
| ksec wrote:
| >The reality is that formats have a chicken & egg problem.
|
| The same company that gave us WebP. At least Mozilla and Safari
| did the sane thing and push back against it.
| bastawhiz wrote:
| Is your argument that more folks should have pushed back
| against JPEG XL? Webp was initially released in 2010 when it
| _was_ the best alternative. JPEG XL came along almost a
| decade later. The state of image formats is very different.
| zinekeller wrote:
| No, instead Google should made WebP a proof-of-concept that
| there are technological advancements that can improve and
| made a successor of WebP like they've done with QUIC (to
| HTTP 3), not force-slinging it to everyone. Also, WebP
| violates the "two independent implementations" standard -
| at least AVIF can be argued to have two different
| implementations (due to dav1d).
| Spivak wrote:
| Huh? Is there some drama because they all support webp so
| clearly push didn't come to shove.
| Matl wrote:
| > why is Google the scapegoat instead of the entire industry
| that didn't adopt it?
|
| Because on the web Google is 'the industry'. It's not a problem
| that it was behind a flag, it's a new format after all.
|
| The problem is Google did implement it and then removed support
| without sufficient explanation. Given their market power and
| the fact they're behind competing standard, it raises a few
| questions.
| brookst wrote:
| Yep. This is like teenagers blaming Walmart for their band's
| lack of success. "If only they had carried our album and
| featured it on endcaps!"
| zinekeller wrote:
| Yep, teenagers like Facebook and Adobe - oh wait. _Maybe
| Google is now flexing its anticompetitive muscles now, isn 't
| it?_
| brigade wrote:
| Adobe didn't support WebP until 2021, they're the poster
| child for not supporting a format _until_ it 's popular
| enough that they need to add support.
| brookst wrote:
| I must be failing to understand your comment. The people
| complaining are FSF, and no matter how hard I squint, I
| cannot see how fair competition could require Google to be
| the first one to support a standard that literally nobody
| else supports.
| zinekeller wrote:
| > The people complaining are FSF
|
| Nope, not just FSF. The Chromium team have prototyped
| JXL, but removed it initially for unknown reasons (https:
| //bugs.chromium.org/p/chromium/issues/detail?id=117805...
| ). Engineering teams including but not limited to Adobe,
| Facebook, Intel and Shopify have complained about its
| abrupt removal. Chromium developers have subsequently
| said that it was "due to low interest" (despite piles of
| messages from engineering teams both in leading companies
| and small groups saying otherwise).
|
| > I cannot see how fair competition could require Google
| to be the first one to support a standard that literally
| nobody else supports.
|
| First, Adobe products have just included JXL. Second,
| It's because Google is pushing for AVIF, which was
| extended from AV1. While it has some advantages (as
| essentially extended version from AV1), it also has a lot
| of disadvantages:
| https://news.ycombinator.com/item?id=35590516. No one
| said to remove AVIF in favor of JXL and in fact there are
| instances where AVIF is the better choice (animated
| images due to its interframe support) but instead to
| support JXL regardless of Google's support of AVIF, and
| some people have seen it as _forcing_ Google-favored AVIF
| instead of considering all formats developed (like how
| WebP was rammed a decade ago).
| SquareWheel wrote:
| > but removed it initially for unknown reasons
|
| Just an FYI, they gave their reasons in comment #84 of
| the thread you linked.
| quadrangle wrote:
| There's also the more widespread phenomenon of profitable-
| enough local businesses blaming Walmart for putting them out
| of business. How do we evaluate which analogy is appropriate?
| adgjlsfhk1 wrote:
| Google has 90% of the market. They are the industry.
| robin_reala wrote:
| They definitely don't. Globally they don't even touch 70%,
| and if you look at specific markets like the US they only
| just hit 50%.
| adgjlsfhk1 wrote:
| this depends a lot on how you count. edge and Samsung
| Internet are both just reskinned chrome. Safari, Firefox
| and Opera Hot sound 20%, but that's almost all Safari, and
| Apple still wants to pretend that their special image
| format is relevant.
| robin_reala wrote:
| Edge isn't just reskinned Chrome when it comes to image
| formats: they deliberately don't support AVIF for
| example. https://caniuse.com/avif
| markdog12 wrote:
| Interesting, why not?
|
| Found this:
| https://stackoverflow.com/questions/75459594/why-doesnt-
| edge...
| izacus wrote:
| So they're now forced to maintain every single format someone
| invents, keep it compatible and security patched forever?
| Even though even FOSS champion Mozilla wouldn't touch it?
| toyg wrote:
| They definitely have a responsibility to shepherd standards
| that show potential to do good for the internet.
| illiarian wrote:
| They have no reservations when its their own formats and
| they force others to implement them on pain of removing
| essential apps like Youtube.
| jsnell wrote:
| JPEG XL _is_ one of their own formats!
| illiarian wrote:
| Then it's internal politics at play. Or perhaps image
| codecs are not as important to Google.
|
| E.g. Android TV now requires hardware support for AV1 [1]
| and Google threatened Roku that Rouku would lose Youtube
| support if it didn't support AV1 in hardware [2]
|
| [1] https://www.protocol.com/bulletins/av1-android-14-req
| uiremen...
|
| [2] https://www.protocol.com/youtube-tv-roku-issues
| neurostimulant wrote:
| What funny is google's own chromecast hardware doesn't
| support av1, yet they require their competitors to
| support it.
|
| https://developers.google.com/cast/docs/media
| izacus wrote:
| Big surprise.
| ksec wrote:
| >So they're now forced to maintain every single format
| someone invents,
|
| Or they could pick a better format and evaluate it? The
| question is why the better format here, even though it is
| the same royalty free ( or patents free in AOM's term ),
| wasn't picked.
| mynameisvlad wrote:
| They _could_. They could also choose to not to. They
| could also have done it and their set of reasons doesn't
| align with yours.
|
| They're a private company. They can choose to do whatever
| they want or don't want to.
|
| If they don't want to support JPEGXL, why should they be
| forced to do it? If it was such a necessary format, it
| would have been a competitive disadvantage to not have
| support and that would have forced their hand, but nobody
| else supports it either so why should Google be forced to
| if they (clearly) don't want to.
| ksec wrote:
| They dont have to. But they could also not lie about it.
| Or lie about do no evil ( I know that is no longer their
| motto ). Or they could also not lie about WebP, AOM or
| AMP or everything else about being Good.
| mynameisvlad wrote:
| I mean they _could_ do all those things, but, once again,
| they don't have to. They don't have a responsibility to
| anyone but their shareholders and therefore bottom line.
| crote wrote:
| Yeah, because it is a new format. You don't immediately
| publicly release support for an experimental format.
|
| Chrome added support for the in-progress version of JPEG XL in
| April 2021. The core coding specification was finished in March
| 2022, and the last part of the spec wasn't done until October
| 2022.
|
| Chrome removed it in December 2022, citing a "lack of interest
| from the ecosystem", despite it having support in most major
| image editors already. It was a new format which was rapidly
| being adopted and a lot of major players were very excited
| about it, but Chrome's removal pretty much killed it due to
| their dominance in the browser space. At the time of removal,
| it had better support than HEIC!
| pjmlp wrote:
| Similar to how they killed WebGL 2.0 compute, actually.
| GuB-42 wrote:
| The problem is that old PNG and JPEG are good enough for most
| purposes. They are certainly not as efficient but with todays
| technology and bandwidth, there is little downside to using
| JPEG and you know it will be supported everywhere.
|
| It is not the case for video. Video is still a huge bandwidth
| hog, and finding better codecs is worth it, that's why they get
| better support. Webp is a clever hack as it is essentially a
| single frame webm video, so if you have webm support, which is
| worth it, then you can have webp almost for free, JPEG-XL
| doesn't have that incentive.
| enlyth wrote:
| Agreed, PNG and JPEG already serve most purposes.
|
| JPEG = I want to see the content in the image but don't care
| too much about the quality
|
| PNG = I want a lossless version of this image
|
| Since bandwidth is cheap in most places, the only advantage
| that JPEG XL has is suddenly not that enticing.
| exmadscientist wrote:
| It's not just that. There are purposes that _require_ JPEG
| and so if I get a WEBP or AVIF or JXL I am actively angry.
|
| I was trying to set the desktop background image on a
| project laptop last week. I found an image I liked, that
| would immediately remind me what machine this was when I
| look at it.
|
| It was an AVIF. Windows 10 won't accept those as desktop
| backgrounds. It looked, for all intents and purposes, like
| the search image results were going to give me JPEGs -- the
| URL ended in .JPG and had "jpeg" as the media type! -- but
| that is not what I got. This did not work. Refusing to give
| up, I eventually determined that using curl to retrieve the
| image gave me a usable JPEG, and so I got my background and
| now I can tell this stupid project laptop apart.
|
| For _my_ use cases, which is as someone who does light work
| with images (backgrounds, occasional use in some kind of
| paint program, occasional insertion into documents or
| slides), anything that isn 't a JPEG or PNG is actively
| harmful. Not everyone uses images the way I do, but
| developers need to remember that not everyone is a passive
| sheep who just stares at things or a power-developer who
| builds JPEG-XL from source in their sleep. There are people
| in between, and we don't take kindly to being forgotten.
| jemmyw wrote:
| We shouldn't use a new format because some website sent
| you the wrong mime type and you don't know how to use an
| image converter? By that logic we should still be using
| .bmp files for all images.
| [deleted]
| kevin_thibedeau wrote:
| Webp max resolution is 16383 x 16383. That is a problem in
| some applications.
| eviks wrote:
| There are many reasons, just to list a couple:
|
| 1) Chrome is much bigger, so it's much more consequential, so
| it's valid is a bigger target for criticism
|
| 2) It's much easier to performantly support the format on some
| OS without it being "native", so again, lack of browser support
| is worse, and thus it's valid it's a bigger target for
| criticism
| illiarian wrote:
| > https://caniuse.com/jpegxl
|
| This is kinda how standards are supposed to work: at least two
| independednt implementations [1], released behind a flag to
| gather developer and user feedback. However it seems that in
| the end it went nowhere.
|
| [1] See Implementation experience:
| https://www.w3.org/2021/Process-20211102/#implementation-exp...
| Among other considerations: "are there independent
| interoperable implementations of the current specification?"
| ars wrote:
| It's the "behind a flag" part that is the issue.
|
| How are you supposed to get feedback for a feature people
| can't actually use?
|
| It's like when Debian removed a package I use that was not
| shipped under the rationale that "no one uses it". Obviously
| no one uses it - you never actually shipped it, you just had
| the source available if people wanted to compile it.
| illiarian wrote:
| > How are you supposed to get feedback for a feature people
| can't actually use?
|
| The moment it's out there (that is, not behind a flag), you
| cannot fix it, update it etc. because people will be
| relying on the observed behaviour.
|
| The hard part is advertising the feature (at the very least
| to developers) because there are just too many featurs in
| modern browsers. Edit: for example, Chrome has Origin
| Trials
| https://developer.chrome.com/origintrials/#/trials/active
| for experimental features.
| ars wrote:
| Sure you can - you just do it. You just make the
| necessary fix.
|
| But you do it quickly, within a short time of launching
| it. Anyone who was able to make use of it within a couple
| months, will be able to adapt and fix things.
|
| Once it's been there for a year, then sure, people rely
| on it. But there's no reason to take so long.
| illiarian wrote:
| > Sure you can - you just do it. You just make the
| necessary fix.
|
| No, you can't. Not simply.
|
| > But you do it quickly, within a short time of launching
| it. Anyone who was able to make use of it within a couple
| months, will be able to adapt and fix things.
|
| That's not how the web works. "People who make use of it
| in a few months" could easily apps and sites serving
| millions of people. This is a process that applies not
| only to image codecs, but to, say hardware APIs and
| interfaces, network protocols etc.
|
| > But there's no reason to take so long.
|
| There are very many reasons from technical to political
| to anything in between (and sideways, too).
| ars wrote:
| So, if it's behind a flag then people know not to use it,
| and therefor no one actually uses it. So you can change
| it if you want, but you never will because you'll never
| get feedback.
|
| Or, if it's not behind a flag, then you can tell people
| not to use it, but they will anyway, which is exactly
| what you want, because then you get feedback. And when
| you change it, nothing really bad happens.
|
| Sounds like the flag method is a failure, and just
| releasing it actually works.
| saltcured wrote:
| Does anybody know why the earlier JPEG-XR also never got useful
| browser support? Are we just going to see this repeating over
| and over with nice general purpose image formats being
| relegated to individual vendor-centric ecosystems and never
| providing widespread interop?
|
| I find it frustrating how computers have gained so much compute
| and storage capacity but the web seems to be slipping away as
| ever more consumer-focused and neutered. Having been there
| since the beginning, I really expected the web tech and
| browsers to improve and facilitate scientific data sharing. Not
| being able to natively decode and display any "exotic" imagery
| without a bunch of server-side nonsense is frustrating.
|
| Today's client machines have so much capability but become
| totally balkanized when you can't just serve an image tag and
| display a real scientific image. Instead you either have to
| hope the users install extra "workstation" tools to display an
| image after downloading, or deploy absurdly over-engineered
| "image servers" to do the basic image rendering and ship plain
| 8-bit JPEGs to the client.
|
| Why can't a browser natively provide some basic range-mapping
| color transfer function tools for high bit-depth images in an
| image tag? Why can't it provide a pan-zoom viewing mode for
| high resolution images in an image tag?
| csdreamer7 wrote:
| > No OS appears to have supported it natively either[0].
|
| Not sure what you mean by OS. The link you provided shows that
| Linux with several GNOME and other tools support JPEG-XL
| (especially GIMP).
| eviks wrote:
| But it's not "native"!
| croes wrote:
| It's not really a chicken egg problem.
|
| If a browser doesn't support a format as default nobody will
| use it unless big players like Apple or Google enforce it.
|
| If Jpeg XL had been enabled some time without a flag they could
| claim > There is not enough interest from the entire ecosystem
| to continue experimenting with JPEG XL
|
| but hidden behind a flag there is no way to know.
|
| How many users enable experimental features in their browser?
| 0x_rs wrote:
| >instead of the entire industry that didn't adopt it?
|
| Is this a good argument? Nobody is going to adopt something
| without being natively supported by browsers without ugly js
| hacks, and when it comes to browser standards it seems to me
| Google has more leverage than anybody else. Cloudinary has made
| a lot of posts about JPEG-XL, so you might say they're quite
| biased towards it, but it also seems to me there is some
| interest in it by multiple companies [0, 1]. I personally very
| much doubt webp would be _anywhere_ today without the massive
| (arguably deceptive) campaigning and double standards it had.
|
| 0.
| https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a...
|
| 1.
| https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
| SquareWheel wrote:
| > Nobody is going to adopt something without being natively
| supported by browsers without ugly js hacks
|
| That's fair, but it is worth pointing out that <picture> tags
| support multiple source formats. I serve some logos and other
| important images as both .png and .webp. Adding additional
| lines for avif for jxl seem reasonable - especially if
| browsers are testing new formats.
| mynameisvlad wrote:
| Why should Google be the ones _solely_ responsible for
| pushing forward file formats? Either you criticize everyone
| for their parts in not adopting it, or not at all. It seems
| silly to single out Google and Google alone when nobody else
| batted an eyelash to try and support the format.
| demonshreder wrote:
| The majority market share is for Google Chrome, directly
| and indirectly, thus they are the primary target, while
| Firefox & Safari will only come next.
| jsnell wrote:
| Being supported by some browsers is useless. It needs to be
| supported by all the major browsers, as shown by webp.
|
| Apple did not support JPEG XL, based on past history was
| unlikely to do so, and despite what you say about Google
| having the most leverage they have none on Apple. If Apple
| doesn't want something supported, no iOS browser will support
| it. And if no iOS browser supports a format, it is not going
| to be useful in production.
|
| I do find it hilarious that all the people who complained
| about Chrome supporting webp then went on to complain about
| Chrome not supporting JPEG XL. They're both Google-created
| formats not widely supported by the ecosystem!
| bbarnett wrote:
| https://en.wikipedia.org/wiki/JPEG_XL
|
| How is it Google created?
| jsnell wrote:
| It was based on Google's submission, the majority of the
| authors are Google employees, and the majority of the
| commits to the reference implementation were written by
| Google employees. You mean other than that?
|
| That's not to say they're the only contributors or should
| have all the credit. But it does make the "Google is
| trying to kill an open standard to push their own format"
| narrative here completely moronic.
| kps wrote:
| > _I do find it hilarious that all the people who
| complained about Chrome supporting webp then went on to
| complain about Chrome not supporting JPEG XL._
|
| They are different formats with different attributes, so
| it's reasonable to distinguish between them. JPEG XL is a
| general purpose image format. It's reasonable to want
| browsers to display it. WebP and AVIF are special-purpose
| formats, designed to leverage their corresponding video
| decoders, for delivery of ephemeral images to end-user
| devices. It's reasonable to object to limited formats that
| are manifestly crowding out general ones.
| RedShift1 wrote:
| JPEG XL is not Google created. The problem here is that
| there's a conflict of interest, Google has its own image
| formats and they're being petty about competition.
| zinekeller wrote:
| JXL was partly derived from Google technologies although
| it went to ISO standardisation.
| bryanrasmussen wrote:
| Ok so one is controlled by Google and one isn't, the idea
| that any argument over them was ridiculous seems weird
| given this salient difference.
| RedShift1 wrote:
| Heh that makes it even worse because the people who
| decided to remove JPEG XL from Chrome claimed it was
| technically inferior :')
| jsnell wrote:
| Of the people listed as the main authors of the JPEG XL
| spec on Wikipedia, I believe 2 out of 3 worked at Google.
|
| What's the "conflict of interest" you're talking about?
| AVIF? How is that their own format when JPEG XL isn't?
|
| If Apple, Mozilla and Microsoft wanted JPEG XL and
| committed to supporting it, I bet Chrome could be
| convinced to restore the support. But AFAIK those
| companies have made no such commitment, or even any kind
| of indication of intent. Why should we have another image
| format that gets only implemented in Chrome, not the
| wider web ecosystem? (Of course, they too are members of
| the foundation building AVIF. Oh my God, so many
| conflicts of interest!)
| ksec wrote:
| >Of the people listed as the main authors of the JPEG XL
| spec on Wikipedia, I believe 2 out of 3 worked at Google.
|
| Google _Research_. Which is similar to Microsoft
| Research.
| jsnell wrote:
| I don't know what distinction you're trying to draw
| there.
| bryanrasmussen wrote:
| >And if no iOS browser supports a format, it is not going
| to be useful in production.
|
| graphics heavy sites often optimize for various platforms
| instead of serving to just one standard.
| kps wrote:
| > [0]
| https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_a...
|
| JPEG XL is a general purpose image format, like JPEG and PNG,
| but improved. WebP is not a serious modern image format; it
| doesn't even support 16-bit channels. WebP has one specific
| purpose: web delivery of ephemeral images, leveraging VP8
| hardware decoding driven by consumer consumption devices.
| That's what Google, and web-oriented companies in general, care
| about. They have no particular interest in general purpose
| image formats.
| GoblinSlayer wrote:
| Here have it: https://github.com/GoogleChromeLabs/squoosh/tre
| e/dev/codecs/...
| Spivak wrote:
| That seems fine then? Browsers are consumer consumption
| devices. And you have different formats good for other
| things. That's Apple's philosophy for HEIC.
| webkike wrote:
| No they are not. They are information delivery devices
| being co-opted for content consumption
| kps wrote:
| Although I'm not personally a fan of web apps or Electron,
| the reality is that browsers are _not just_ consumer
| consumption devices. And my reading of
| http://crbug.com/1178058 is that the existence of WebP and
| AVIF is being used as a justification for removing JPEG XL
| support.
| unethical_ban wrote:
| You see it's chicken and egg, but then ask why people are upset
| that the giant chicken with the ability to put out 10,000 eggs
| a week dropped a feature that was already in their product.
| devinprater wrote:
| FSF slams Google? Do they even have enough power to slap
| companies on the wrist anymore?
| BuyMyBitcoins wrote:
| "Slammed" is a word journalists love to use for when one entity
| criticizes another, regardless of impact or severity. It's a
| trope that seems to have been around for a long time.
| bunbun69 wrote:
| I thought HackerNews and Reddit hated words such as "slams" in
| the title. Guess it's okay now because we love FSF and Phoronix
| samwillis wrote:
| > _While we can 't link to Google's issue tracker directly
| because of another freedom issue -- its use of nonfree JavaScript
| -- we're told ..._
|
| While there may be genuinely good arguments for keeping JPEG-XL,
| I cannot take seriously the arguments of an organisation that
| cuts itself off from the rest of the world for such silly
| reasons.
|
| Edit: Google's argument that there wasn't enough interest is
| equally impossible to take seriously when it was always behind an
| optional flag. No web devs are going to invest time in developing
| JPEG-XL functionality until their users can actually use it.
| kps wrote:
| Chromium's issue tracker appears to be open source, under the
| same BSD-type license as the core browser.
| https://chromium.googlesource.com/infra/infra/+/refs/heads/m...
|
| The deployment references google-analytics, but everyone
| already blocks that, right?
| jacooper wrote:
| And that exact mindset made them totally irrelevant in the real
| world. The FSFE and other organizations like the EFF and the
| EDRI are much more relevant and have a bigger impact than an
| org which still insists on using devices from 2007
| guilhas wrote:
| I agree with the FSF principles. But they could add a picture,
| or a link to an archive site that strips most JS. To avoid
| users having to go and open the real thing to see it
| tedunangst wrote:
| But then they themselves may have to read the source
| material, instead of relying on a vague "we're told" that may
| or may not be true.
| thriftwy wrote:
| If Google's website is designed in the fashion where none of
| the content is available statically and the only way to access
| it is via running a blob of intrusive code, I can understand
| their sentiment.
|
| I would love people to stop linking, and posting links, to e.g.
| Facebook because the only thing it would show me is "you have
| to register to view this".
| politelemon wrote:
| If non-intrusive browsers existed, which could run
| Javascript, is that considered acceptable to go to JS sites?
| eg what about Firefox or its derivatives?
| matheusmoreira wrote:
| > If non-intrusive browsers existed, which could run
| Javascript, is that considered acceptable to go to JS
| sites?
|
| User agents need not be browsers. What if we had a scraper
| for every site? What if we had reverse engineered free
| software clients for every website's API endpoints? We'd be
| in full control.
|
| People maintain humongous repositories of ad blocker
| filters and executable countermeasures against "clever"
| websites. Perhaps it would be feasible to maintain a
| collection of scrapers and custom clients too.
| chomp wrote:
| No. The objection to linking to sites with JS is that they
| contain nonfree JS blobs that spy on you, run unknown
| obfuscated code, and are not open to modification, because
| they're almost always obfuscated.
| Eduard wrote:
| Still silly, because whoever cares about that stance can
| just visit the site with (requests for) Javascript
| disabled.
| jraph wrote:
| Chromium bug tracker doesn't work with Javascript
| disabled.
| aendruk wrote:
| The FSF opposes _nonfree_ i.e. proprietary software.
| JavaScript is fine if properly licensed:
|
| https://www.gnu.org/software/librejs/free-your-javascript
|
| Just like any other software.
| thriftwy wrote:
| I wonder what FSF thinks of PDF.
| eesmith wrote:
| Why do you think there is an issue?
|
| The FSF - and Stallman! - publish PDF documents. At
| https://stallman.org/cgi-
| bin/showpage.cgi?path=/archives/202... you can see
| Stallman uses xournal to fill in a PDF form.
| Kwpolska wrote:
| I wouldn't be surprised if RMS said "I don't file tax
| returns, because I would have to either (a) use nonfree
| online filing software, (b) use nonfree PDF technologies
| (since the US Form 1040 features XFA forms, and Wikipedia
| says the are nonfree [0]), or (c) hire an accountant, but
| they would also be using nonfree software, and the IRS is
| using proprietary software to process the tax returns
| anyway, so therefore I am not filing them".
|
| [0] https://en.wikipedia.org/wiki/XFA
| eesmith wrote:
| The link I gave described that exact topic. Stallman
| wrote:
|
| "I do not submit my tax returns on line because it
| requires nonfree software. I use xournal to write my data
| on the PDF form, and print that. As I have no printer, I
| will visit a copying store to do the printing."
|
| Note that the copying store will be using a printer with
| nonfree software.
|
| Thus, your (a) is correct, your (b) appears to be
| incorrect as Stallman was doing this 3 years ago, and
| your (c) is incorrect as Stallman doesn't have that
| objection.
|
| We futher know (c) is incorrect because Stallman at
| https://stallman.org/rms-lifestyle.html write that he
| will use someone else's cell phone, even though it it not
| free.
|
| Regarding (b), I can't tell if the 1040 at
| https://www.irs.gov/pub/irs-pdf/f1040.pdf uses XFA forms
| ("deprecated in PDF 2.0", in 2017), but it appears to
| work in Firefox, which I believe is using free software.
| Even if it does, you can order the forms at
| https://www.irs.gov/forms-pubs/forms-and-publications-by-
| us-... or visit a post office or library (see
| https://www.irs.com/en/articles/local-irs-tax-forms ).
|
| These do not require using software, so I don't see why
| you conclude that Stallman would have a free software
| objection to filing taxes at all.
| Kwpolska wrote:
| When you open the form linked, SumatraPDF will warn that
| "The document uses unsupported features (XFA) and might
| not render properly", and it cannot fill out the form.
| Perhaps it's not XFA specifically, but some other strange
| technology.
|
| I did see that note about how Stallman does his taxes.
| But if Stallman has a sectarian objection to basic things
| like using a cell phone, or to even more basic non-tech
| things like personal hygiene, an objection to taxes
| wouldn't seem far-fetched to me.
| thriftwy wrote:
| PDF is a programming language, or at least PostScript is.
| I wonder if Stallman will refuse to open a random PS
| file?
| pama wrote:
| At worst, postscript can crash your printer or take up a
| lot of cpu. There are no networking libraries or access
| to system stuff for postscript. So it should be safe for
| all practical purposes assuming you don't care about the
| possible inconveniences that any Turing complete language
| can provide. This is a very different concern than
| executing random JavaScript.
| thriftwy wrote:
| I can't imagine why you would not be able to run site
| JavaScript in sandboxed manner (it already is) - just
| throw in some additional limitations and you are done.
|
| This will break JS on some sites but not all of them, but
| that is apparently not sufficient for Stallman & co.
| eesmith wrote:
| I don't think there's any doubt that Postscript would
| have the same copyright and software freedom issues as
| Javascript. I myself have written a GUI Postscript
| program for NeWS.
|
| So yes, of course Stallman would have objections to some
| Postscript files.
| neilv wrote:
| Unfortunately, I think this is a phenomenon with the FSF...
|
| They want to raise a point X, which could in theory be
| communicated in a persuasive way.
|
| But they can't resist also mentioning their zero-tolerance on
| unrelated point Y.
|
| I think the Y makes people tend to go WTF, and then dismiss
| both X and Y.
|
| Every time now, I'm thinking "You don't have to always mention
| Y!"
|
| On at least a couple occasions, I actually abandoned an
| argument I was making on some X in a venue, because some FSF
| person jumped in with a Y. If I didn't know they were a true-
| believer in Y and at least sympathetic to X, I'd think they
| were trying to discredit both.
|
| The FSF has some great principles, but a lot of the
| communications don't seem to be calibrated for me, nor for my
| understanding of anyone else.
| jzb wrote:
| I've been saying this for years and years. [1] The FSF / GNU
| folks are only preaching to the choir and don't really have
| any positive solutions.
|
| They're happy to tell you what not to do, what software not
| to use (and what software they won't use) but that's it.
|
| Their communications are calibrated for true believers only.
| They rely heavily on the reader/audience 1) agreeing with a
| fairly extreme position relative to the mainstream, and 2)
| the idea that the FSF/GNU has a position of authority/trust
| with the audience.
|
| What's annoying is that I agree with them on the idea that
| deprecating JPEG-XL is counter to user interests and that
| Google has too much power. But they could've led with IceCat
| and made a more pragmatic case that might resonate with a
| larger audience. Hilariously, though, "building binary
| packages for Windows and MacOS currently requires nonfree
| software, so we no longer distribute binary packages for
| those platforms."
|
| So... if you're already happy to be an Orthodox Free Software
| True Believer then you have an alternative. If you aren't,
| well, too damn bad. If you're a budding free software fan but
| happen to have a macOS machine or Windows machine your
| parents supplied, too bad. If you'd like to make a work
| computer slightly more free, too bad. Etc.
|
| [1] https://web.archive.org/web/20100703110224/http://www.lin
| ux-... [2] https://www.gnu.org/software/gnuzilla/
| chx wrote:
| > If you're a budding free software fan but happen to have
| a macOS machine or Windows machine your parents supplied,
| too bad.
|
| There's much more to this. I have tried for well over a
| decade to run Linux as my daily driver on my laptop and
| gave up in 2018 January and just run Windows + WSL,
| especially since WSL2 this is quite good. There's always
| something that doesn't work. (And yes, if all you connect
| your laptop to is a normal wifi then your experience might
| differ. My problems were with Bluetooth, enterprise wifi
| and multifunctional printers.) It's entirely possible some
| people would prefer not running Linux because the
| manufacturers refuse to pay much attention to it.
|
| I have been on Linux since 1993. Still running it on
| servers and router. It's still not the year of Linux on the
| desktop.
| matheusmoreira wrote:
| FSF is the uncompromising idealist for better and for worse.
| It takes some serious balls to live life the way RMS does,
| fetching HTML by sending email and all that. No one else
| wants to be that extreme, so even though they value computing
| freedom in the abstract they compromise and tolerate little
| injustices in the name of getting things done.
|
| At the end of the day RMS is still right though. Those little
| injustices add up, the corporations creep up on you slowly
| and next thing you know you're being surveilled by the
| javascript you used to see as harmless, and soon you learn
| how to tolerate that too. Dude saw ridiculously far into the
| future even decades ago but it doesn't matter because stuff
| like RYF certification is irrelevant and will only ever apply
| to machines that must 20 years old by now because
| manufacturers don't care and everyone is on mobile now
| anyway.
| grumbel wrote:
| The Javascript issue never made sense to me. You are
| reading a non-free document to begin with, what difference
| does it make if it is running Javascript or not? If they
| wanna spy on you they can do that with HTML and CSS just as
| well. Even releasing the spying software under GPL wouldn't
| stop it from spying on you.
|
| The party one should be angry about here is the browser,
| which provides little to no tools to show the user what is
| going on and provides no real means to stop it. This is
| quite a bit different from the early web days when every
| browser had a "Javascript off" and style sheet selector
| right in the main menu by default.
|
| > Dude saw ridiculously far into the future even decades
| ago
|
| Not far enough. Ever since the whole world moved to
| "software as a service" and your computer has become little
| more than a thin terminal to some Google/Facebook/whatever-
| service FSF started to feel quite out of touch. Sure, they
| tell you "don't do that", but while that isn't wrong, it's
| not exactly helpful either. Many service simply have to run
| on a computer that you don't own and we need rules to
| govern that. None of the Free Software licenses help here.
|
| FSF never bothered to create any kind of licenses or best
| practices that deal with how those services should work.
| They are stuck in dealing with software freedom problems of
| the 90s, not the problems we face today. Luckily we do have
| the GDPR now, but the FSF had nothing to do with that and
| never provided anything similar.
| javajosh wrote:
| _> The party one should be angry about here is the
| browser, which provides little to no tools to show the
| user what is going on_
|
| Wait, what? The browser is the single best platform in
| existence for showing people what is going on behind the
| scenes - hit F12 and enjoy. Very few other software
| projects give users these kinds of tools, available at
| runtime.
|
| But if you refuse to use software because of religious
| reasons, you may not be aware of this.
| robalni wrote:
| > The Javascript issue never made sense to me. [...] Even
| releasing the spying software under GPL wouldn't stop it
| from spying on you.
|
| Exactly. The licence is not the only problem with
| javascript on the web because you can't use your freedoms
| in practice anyway since the code is automatically
| downloaded and executed when you load the page in a
| common web browser.
|
| What we need is something that allows people to choose
| what code to run, similarly to how software traditionally
| is downloaded and executed in two separate steps. We need
| to get away from the assumption that people will run all
| code you throw at them when they visit your site. Then
| maybe licences on javascript can start to make more
| sense.
| jraph wrote:
| > because you can't use your freedoms in practice anyway
|
| Yes, you could. You can adapt the code and use an
| extension to use your "fork" instead of the provided one.
| A convenient extension to do this might not exist yet,
| but you could block the website's provided JavaScript
| with uBlock Origin / uMatrix and use your fork with
| ViolentMonkey or another *Monkey extension. And
| distribute your fork on some user scripts repository (for
| instance).
|
| Free software is not (only) about avoiding spying. It's
| about running the code you want to run for any endeavor
| you can have, and be able to study and distribute your
| modifications.
|
| I totally agree with your last paragraph and I agree
| something should be done to deal with how (web) software
| is distributed and run.
| hammyhavoc wrote:
| That's assuming RMS isn't just LARPing.
| [deleted]
| principles1 wrote:
| [flagged]
| jmull wrote:
| Do you really think an insult is the right rebuttal?
|
| (Also, the insult is baseless, since the previous poster may
| have strong principles, even if they aren't the same as
| yours.)
| skissane wrote:
| New account whose first comment is flamewar-style insult-no
| point engaging with them, they clearly aren't here for
| constructive discussion, just flag and move on. With enough
| flags it will go dead
|
| (Can everyone flag comments? Or is there some minimum karma
| for it? I forget.)
| z500 wrote:
| Seems the minimum karma limit is at least 4.
| anotherhue wrote:
| The keyboard you used to type this likely lacks open
| firmware.
| rightbyte wrote:
| > I cannot take seriously the arguments of an organisation that
| cuts itself off from the rest of the world for such silly
| reasons.
|
| Why would they risk unsuspecting visitors running Google code
| on their computer? It is a spyware company.
|
| There is nothing silly about not wanting to link to Google.
| Maybe futile given their market domination. But not silly.
| Jyaif wrote:
| In this case, Google should be applauded for not pushing down
| everyone's throat a new image format _they_ created.
| chomp wrote:
| Ehhh not quite. Google has some technology in JPEG-XL, but
| theirs isn't the only in the project, there's other code too,
| plus the JPEG group's development, and it's an ISO standard.
|
| WebP is just flat out a Google thing, no standards body other
| than Google.
| zamadatix wrote:
| The article is about avif not webp. Note the editors (past
| and present) for the AOM avif specification don't even
| include Google https://aomediacodec.github.io/av1-avif/
| Google was involved in each format but not responsible for on
| in control of either.
| Jyaif wrote:
| I see. Thank you!
___________________________________________________________________
(page generated 2023-04-16 23:01 UTC)