F3nd0

> GNU Taler provides a backdoor for spying.

And that backdoor for spying in this entirely free/libre software is…?

> Also claiming buyer privacy when the money ultimately has to come from a bank transaction or another digital transaction leaving some sort of trail is a false illusion.

Don’t all state currencies ultimately come from banks? This feels much closer to cash in practice, which also comes from banks, yet I’d say it’s compatible with privacy.

> It's "money" but it has to be permanently connected to the Internet and it *expires* if disconnected for too long??

Staying disconnected is not what makes them expire, but you need connection to ‘renew’ them before they do expire, if you plan on keeping your tokens for a very long time (say, years). At least that’s my reading of it.

> This is infinitely worse than Bitcoin.

If we only consider this single aspect and ignore all the other ways in which it’s arguably better than Bitcoin, then yes.

Would it be technically possible to transfer tokens to another user directly, without an exchange acting as an intermediate?

My assumption is that this is possible but not supported by default, since there’s no way to guarantee (without using an exchange) that the giver has really deleted the tokens they sent to the receiver, and will not spend them before the receiver can (which would render the receiver’s copy of the tokens unusable).

But assuming someone implements this in software, would it be possible to make direct transfers like this while relying entirely on trust? Or are the tokens somehow tied to the wallet that has first received them?

Wishing Taler lots of success and hoping for the best. Adopting something like this should be a given, but unfortunately freedom and privacy aren’t seen as essentials, not even in the EU.

The struggle for human rights is always an uphill one, isn’t it?

Taler is meant to be private and anonymous for the payer (customer) and not for the payee (merchant). I feel they’ve always been very clear about this, so unless you disagree about the premise, calling them deceptive seems unreasonable.

Moreover, I don’t know in which part of the world you live where private on-line payments are commonplace, but the only cashless payment options I tend to see are with bank transfers, credit or debit cards and payment processors like PayPal. My understanding is that compared to those, Taler gives payers privacy and doesn’t make things any worse for payees than they already are, which makes it an enormous step forward for privacy. Perhaps I’ve missed something, because saying it helps bring about dystopia when it only strives to make things much better than they are right now seems terribly out of touch.

Sounds like Ul Shigure is a VTuber (youtuber/streamer) and the anime girl is her virtual avatar?

https://en.wikipedia.org/wiki/Ui_Shigure

At first I thought this was a Fediverse instance, but it seems like it was its own isolated thing? Shame.

Is that really an issue in practice? AV1 seems pretty well-established in spite of it (in video at least).

Yes. My understanding is that AV1 encoders have been continuously improving, while JPEG XL lost a lot of drive and manpower for a couple of years since its future on the web became uncertain, allowing AV1 to get ahead. That’s probably an important factor.

In particular, I don’t think there was significant progress on compression between libjxl v0.10.0 and v0.12.0, and there some regressions from earlier versions still remain. The article also measures the quite recent jixel, which is derived from the older libjxl-tiny and apparently does better in many cases. So JPEG XL encoders definitely have lots of room for improvement. With JPEG XL finally gaining wider adoption on the web, perhaps they’ll catch up or get ahead again. AV1 encoders are also still being improved, though.

Your impression is correct; when JPEG XL was first introduced, it did just as well or better than AVIF in many cases. But in short, work on JPEG XL encoders slowed down, so they fell behind, and JPEG XL now loses to AVIF in some areas.

As the article points out, this might change yet again in the future, depending on how much AVIF keeps improving and whether JPEG XL development picks up steam again and how far it’ll go.

And ironically, the lack of JPEG XL adoption (and careful consideration, really) probably held the best of JPEG XL back at the same time.

AV1 is not necessarily a better codec for the web. It’s just that its encoders have been continuously improving while those of JPEG XL weren’t seeing much attention, so they fell behind. The format might be better overall, but we won’t know for sure until the encoders catch up.

This is exactly the kind of misunderstanding I worried about in another reply. [1]

AVIF uses the AV1 codec. For the past several years, AV1 has been enjoying a wide interest and a continuous stream of improvements as the best, open, royalty-free video codec around that pretty much everyone had agreed to support from the get go.

JPEG XL started out with a smaller group behind it and took a massive hit when Google decided not to support it in Chrome (and by extension, the entire web, because market share). That made JPEG XL’s future as the universal format very uncertain for a few years. Excitement waned, development slowed down and was further divided to develop a new encoder which Mozilla later said they wanted.

So for a good while, AVIF was steadily improving and approaching its full potential, while JPEG XL was not. The article compares the current state of the current encoders; in no way does it indicate how good the formats themselves are. The article makes note of this. [2] It’s been known for years that JPEG XL compression can still be improved by quite a bit, so I imagine the current encoders are still far from reaching the format’s full potential. (Heck, they don’t even make use of all its features from what I know!) Back when it was first proposed, JPEG XL was very competitive. With interest in the format hopefully renewed, we might see it catch back up with AVIF and overtake it again. Or we might not. We have no way of knowing for sure right now.

  [1]: https://news.ycombinator.com/item?id=50128587
  [2]: https://jakearchibald.com/2026/jpeg-xl-vs-avif/#:~:text=Both%20AVIF,in%20future

Note: Author has worked on the most popular AV1 encoder, seems to be working on his own commercial AV1 encoder, and bases his suggestions on an educated guess. Presumably the authors of JPEG XL had reasons to believe otherwise when introducing JPEG XL.

Not to call into question the article’s author’s expertise, just to point out that they are a single individual and not an authoritative source (which you haven’t implied, but some people might read that way).

I think they were calling Chrome the Internet Explorer of our age. Having a majority market share and getting to decide on de-facto standards and indeed practically halting JPEG XL’s adoption at one point, pretty much on a whim. All that stuff. :-)

… are you all reading that as a serious statement, not a joke (possibly in poor taste, but still)?

> For screenshots and illustrations, AVIF is much better than JPEG XL.

Have you tried encoding with JPEG XL’s modular mode? By default, libjxl only uses it for lossless and I haven’t tried with jixel, but in my experience, it often handles clean edges and smooth surfaces (the likes of which you might see in digital art) better.

> I'm a little nervous about this, because discourse around JPEG XL can get a little… weird.

As someone who’s been rooting for JPEG XL for years now, I also find the discourse a little upsetting. When first introduced, the format was very competitive with AVIF and steadily improving, until Google decided to single-handedly halt web adoption (de facto, because market share). No careful evaluation presented, no solid argumentation given.

My understanding is that the future of the format became uncertain at that point, because web adoption is regarded as crucial and no one wants to go all-in on a codec that may not end up filling the universal role it was designed for. Of course, AV1 encoders kept seeing lots of interest and improvement in the meantime, because everyone was already all-in on AV1 for video.

And now, when JPEG XL has finally painstakingly clawed its way back onto its original trajectory, now there are comparisons popping up showing how AVIF actually compresses better. People end up quoting them around social media, painting the picture that JPEG XL turned out to be the inferior format after all. It hasn’t, it just got a massive handicap.

Not that it’s a problem with your article. It’s informative, you compare the current state of available encoders for a specific use case, and you mention how they’re still evolving. It just sucks that we can’t really do a fair comparison of the formats at this point, yet that’s exactly what people will end up doing anyway, and it’ll really suck if it ends up hurting JPEG XL even more than Google already has.

Is Latin still a living language outside of science and religion? Is it comparably regular and easy to learn?

Depends on how you use the word. I use and understand the term ‘vibecoding’ in a similar way the author of the article you link to does: instructing AI to write code for you. That’s how I normally see the word used and how some English dictionaries define it. [1] [2] [3] By those definitions, Raku++ is vibecoded.

Wikitionary adds the nuance of the prompter not understanding the generated code well. [4] If we go by that definition, Raku++ is not vibecoded. Would you say this definition is more correct? (I only go by what I’ve been hearing and able to find so far, so I might have missed something.)

  [1] https://www.merriam-webster.com/dictionary/vibe%20coding
  [2] https://dictionary.cambridge.org/dictionary/english/vibe-coding
  [3] https://www.collinsdictionary.com/dictionary/english/vibe-coding
  [4] https://en.wiktionary.org/wiki/vibe_coding

Yes, I was pointing to Raku as the one exception that does have Unicode operators. Other languages (that I know of) unfortunately don’t support them out of the box.

I’m still not sure what to think of their capabilities, so I’m curious to see where ambitious vibe-coded projects like Raku++ [1] will go.

[1] https://github.com/ash/rakupp/

The font might be nice, but that website makes it exceptionally hard to read, so I can’t really say.

Care to elaborate? I don’t see what you mean at all.

I wish more languages other than Raku did this. But no, not equal is written as surprised equal. And if something ought to be less or equal, you have to write a fat arrow pointing left. :/

Remember when Mozilla did a huge rebrand that introduced a new logo many people actually loved for its ingenuity, styling their name as moz://a? [1] And then, not very long after, they did another rebrand that resulted in… whatever they’ve got now? [2] Taking a step forward and then two steps back seems like a very Mozilla thing to do.

  [1] https://blog.mozilla.org/opendesign/arrival/
  [2] https://blog.mozilla.org/en/mozilla/mozilla-brand-next-era-of-tech/

There’s a massive difference between ‘I am okay with theft if it impacts me economically’ and ‘I am not okay with theft but will tolerate it for some time, in some measure, because not doing so would be extremely challenging and impractical’.

To give a comparable example, I hate proprietary software, but I still run some of it on my computer, because avoiding all proprietary software everywhere is extremely impractical in current day and age. You can take a meaningful stance against something without being Stallman levels of principled.

Sorry, this might be on me, but I don’t follow. I understood your first comment to point out that the author is not okay with AI consuming or processing his copyrighted works in any way, while also making use of software using code generated by AI (which was itself trained on copyrighted work, very possibly against the law and certainly against many of the contributors’ wishes) for his work. I thought you were painting that as plainly hypocritical, and I argued it wasn’t. Did I misunderstand you?

By his standards, as I understand them, AI should respect and preserve the copyright of the data it’s trained on. Since that is not the current practice, he doesn’t want AI training on his works or generating derivative art, and prefers to avoid AI-generated works in general (including software). I don’t see any discrepancy or hypocrisy in that, nor do I see how your ComfyUI example relates. A clarification would be much appreciated!

> he’s quite happy not to even discuss that and instead take the position that the maintainers said it’s fine.

Where does he take that position?

You can’t backport additional restrictions to a CC licence, but you can publish the same work under a new licence. Naturally that won’t stop anyone from using the work under terms of the old licence if they know about it, but it might discourage people (and in fantastical theory, bots) who don’t.

Another point is that any updates to existing works will only be available under the new licence. This might seem irrelevant to drawings and paintings, but the author has on occasion made changes to his older works for one reason or another, so at least the resulting newer versions would be protected by the additional terms (assuming they’re legally in the clear, of course).