F3nd0

In this instance, Stallman was arguing semantics. His long-term criticism [1] is that ‘sexual assault’ is being used to cover a wide range of wrongful actions, where a more nuanced terminology to distinguish between them would be more appropriate. That in itself doesn’t imply he finds any of those actions acceptable, only that he’d like them to have more specific names.

He might not have picked a good time and place to share his terminological views, but I don’t think there’s anything wrong with them per se.

[1] https://stallman.org/antiglossary.html#assault

The topic seems to be warnings and predictions coming true even if they seem far-fetched at first. The linked article doesn’t talk about any warnings or predictions. It only recounts (in a way) how RMS, while discussing the topic of Epstein’s abuse, said some things which many people found offensive, leading to his resignation.

I guess it is marginally relevant; it just seems odd to drop a marginally relevant link unaccompanied by further comment. Usually people seem to mention what brought it to mind, or which part they found particularly interesting.

Being wrong, being malicious, being harmful, and being unpleasant are all mostly separate, but get mixed up occasionally.

How is the link relevant to the topic at hand?

I did make a distinction between ‘the basic idea’ and the rest. That implies temporarily focusing on some parts more than the others, yes.

I think it’s pretty evident that letting ‘other artists’ (or ‘the community’) know implies hurting the business (since they are likely to disappreciate the use of AI, the way many other people have).

I wrote my comment with the assumption that the ‘basic idea’ was intentionally making reputation worse on account of poor behaviour, and communicating that to the business owner. Of course, if you imagine the basic idea to be the extortive aspect, then it is literally extortion.

Well, the basic idea of it is not so bad. A business generally wants to keep their customers happy and care for their reputation, so telling a business when we’re unhappy and influencing their reputation is the feedback mechanism we have at our disposal.

The important thing is how we go about it, and whether their reputation remains reflective of their actions, or we try and make it worse than it ought to be. We can’t say for certain the author of the message was going to do the latter, but it does not inspire good faith.

I think it’s relevant in that they lack the personal experience, and so can’t comment on the given points from experience, as they might be expected to.

Saying you’ll do something that’ll harm someone (or, more precisely in this instance, their business) can reasonably be called a threat (in the broad sense of the word), though not necessarily the unfair kind of threat most people imagine when they say ‘threat’.

You can threaten someone with ceasing to be a customer if they don’t change their business practices, and that’s perfectly fine. Sharing publicly available information is generally not a problem, either. But in this case, the author of the message is coming off as very insincere, setting deadlines, and trying to strike up deals, which comes off as unreasonable and makes one wonder if they really are simply going to share publicly available information, or if they’re going to give undue focus over them being ‘uncooperative’. If they did not want their message to come off as a threat, this was very far from an ideal way to write it.

It’s more about the way it was phrased and presented. Just sharing publicly available facts with your community (or anyone really) is not a problem in itself, but the message does rub me the wrong way.

The message’s author is trying to present themselves as someone helpful and compassionate (‘I understand’, ‘I’m trying to help’), but at the same time, they’re one-sidedly setting a firm and short deadline (‘I’ll give you a day’) unprompted and suggesting the café owner strike a deal with one of the people they’re going to recommend. They might have written this with good intentions at heart, but it also wouldn’t feel out of place in a mafia setting (as in ‘do business with us, or else’), so it’s a hard sell.

If they really were compassionate and wanted to help, they easily could have suggested to get the owner in touch with some affordable artists and left her with time to mentally deal with the backlash and all. They didn’t need to emphasise how they were going to tell on her like they were about to launch a vendetta smear campaign or something.

True. I can’t speak from experience, but this seems like it might often fall within the scope of normal job duties, though.

Isn’t HALIC proprietary?

JPEG XL is an open format with a libre reference implementation, usually compresses better than WebP/PNG, and supposedly has plenty of room for improvement still (in said implementation). Add to that its versatility in other areas and the fact that it seems to have generated widespread interest (much unlike WebP in its time, from what I recall), and I think campaigning for it makes perfect sense.

Thank you for an interesting article. You’ve helped AV1 come a long way!

In the ‘Lossy Compression Efficiency’ section, you compare the codecs using various metrics, but I don’t think you say anywhere what quality the images were encoded for. Did you forget to mention that or am I just reading things wrong?

(I assume BD-rate tells us how similar the images look, but I also assume the values would change if the encoders were made to target different qualities, hence why the intended quality seems quite important to know.)

jxl-rs is a relatively new implementation, not yet optimised for speed. It’s hard to say how much faster it’ll get, but I assume it would at least get near libjxl’s level.

Not at lossless, though.

jxl-rs will presumably get much faster in time. The work on it started much later than work on libjxl (because it took years for anyone to say they had vested interest in it), and if my understanding is correct, it hasn’t been production-ready until recently. Once it behaves correctly, speed improvements are next in line, presumably.

The stated reason for Chrome was not ‘we need a memory-safe implementation’. It was ‘there is not enough interest’ and ‘there is not enough improvement over AVIF’. At the time, there was interest and there was improvement over AVIF (which Google has decided to support regardless of memory safety, interest, or seemingly any deeper consideration).

Memory safety as a condition for adoption was brought up only years later, and by Mozilla rather than Google. The JPEG XL devs, who’d offered to work on it if there was interest, got to work as soon as interest was proclaimed. You might say it’s a good thing for Chrome to have held off adoption until then, but that’s completely incidental, not because they cared. Near-zero efforts to be fair and responsible were made.

Well, anything that supports JPEG XL will support all of them, so you can just re-use the files an the web as-are.

It may not be as widely used as lossy, but it does have valid uses that lossy just can’t substitute and the web needs to accomodate for. And the space savings offered by JPEG XL seem pretty great in that regard.

‘The average Web consumer’ may not need lossless, but a non-negligible minority very well might, hence why lossless should absolutely be on topic.

Wasn’t WebP pushed pretty hard by Google for several years, until the (ever shrinking) rest of the ecosystem sort of caved in? My impression was that there wasn’t much interest until it became more or less inevitable because of that.

> It is getting its try, actively, in libjxl.

That’s the thing, though: libjxl development hasn’t seemed all that active in recent years. The community contributors you mention seem quite far from driving the development, and some of them say that the usual devs have been busy with other projects (including jxl-rs as of recently).

> People like to pretend AV1 got infinite resources

I would not suggest that, but in another comment here you yourself say that SVT-AV1 (which you compare to JXL favourably in your article) has seen active involvement from ‘Meta, Netflix, Intel, independent contractors, and others’ – not to the community fork SVT-AV1-PSY and its successors contributing their improvements back upstream.

I can believe that JXL may very well be more difficult to work with, but am I wrong to assume you’ve been able to continuously focus on your own encoder (and apply your experiences from your earlier work on SVT-AV1)?

Which sounds very useful if your connection is slow enough to make use of progressive image decoding. (Often enough the case for me.)

Can a similar technique be employed in JPEG XL, or does the format not allow for it in any way?

It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs.

That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.

> NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course)

Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?

With people making an effort to cut them off instead, presumably.

Mad Hattershy.

I think all humour is.

They’re only concerned with capability determination, not name determination. Some people just have no SPINE when it comes to naming things.