Every community I care about is dead
How would Amazon track a voucher? It’s a physical scratch off code, sealed by Mullvad before they send it over to Amazon. More importantly, if you think that was possible why would Mullvad be unaware of it and/or lie about it? Just go with the vouchers if you want untraceability. They’re also cheaper in USD than other methods IIRC, at $29/6 months and $57/12 months.
Vote with your wallet regards any sort of purchase. By giving money to someone you are giving them the most encouragement possible to continue doing what they’re doing. If you purchase something that you end up not liking, they will still receive your initial vote loud and clear. The gaming industry especially has shown us that companies will happily take both the money and the negative review and say ‘thank you’.
I feel piracy for demo purposes is fully justified if you buy it after you like it. People always say vote with your wallet but it’s more like gambling with your wallet if you don’t get to see and touch the product before you make the purchase. Giving proper demos should be more common with digital media.
Semi-related, can these automations really be relied upon for quality, or is there a system to help find the best copy? When I’m downloading books I do it manually through Anna’s Archive and I always download as many unique versions of a book that I see, then open them all and compare their internals to see which one I keep. Often not many ebooks are suitable for using my own font and layouts with Koreader.
The readme links to this one. It will automatically update after manual installation.
The torrents are broken up into smaller pieces - don’t be intimidated by the big TB numbers from the sum total. Otherwise donations are always useful.
Usually torrents remain seeded because private tracker users are encouraged to seed everything forever. In addition, often if a private tracker has a bonus system they will offer extra bonus points for seeding low-seed torrents, and some even automatically mark torrents as freeleech if they’re below ~5 seeds, encouraging people to revive its seed count in a targeted manner.
“If you don’t wear Special Clothes around me I’m going to lose it.”
When are we going to move past costuming for work?
Lemmy’s comment sorting does also actively prevent getting buried, unlike reddit (?). Newer comments are biased towards the top, and even heavily-upvoted older comments will fall towards the bottom. The lack of “global karma” and our community’s propensity to heavily downvote anyone doing redditisms like pun threads are also doing a lot of work here.
Emphasis on #4 here - the anti-adblock will trigger if it detects any subpar adblocker, including e.g. Brave Browser’s “Shields” thing (even if you also use uBlock Origin). Helped a friend figure this out lately and found out they were running 3 adblockers and Brave Browser. Some people are truly special.
Right, it was clearly LTT’s fault for not reading, but automatic upgrades are the same thing as not reading. I’ve been using Linux for a very long time now, and I’ve seen Apt try to do some very stupid things before. Maybe it’s better nowadays but I don’t know if I’ll ever shake the gut instinct to not allow Apt to do whatever it thinks is right.
Blind automatic upgrades are a bad idea even for casual home users. You could run into a Linus Tech Tips “do as I say” scenario where it uninstalls half your system due to a dependency issue. Or it could accidentally uninstall part of your system that you don’t notice.
I’m not sure how stable Gentoo’s default branch is but I know that daily upgrades on Arch Linux is close to suicide - you have a higher chance of installing a buggy package before it’s fixed if you install every package version as it comes in.
I’m surprised this strategy was approved for a public server - it’s playing with a loaded revolver and it looks like you were finally shot.
Laser printers are great also if you just need black.
With effort level 7 you should be getting images roughly 2/3’s of the size of the original PNG on average (assuming the PNG is already properly optimized). I would try again with at least effort levels 3, 4, 5, and 7. Also consider that PNGs need very expensive CPU time to properly compress them, using a tool like oxipng.
What sort of balance are you looking for with regards to filesize and encode time? At the very least, effort levels 1 through 3 will probably still give you better results than PNG while being ridiculously quick, so there shouldn’t be any configuration where PNG is a better choice than JXL with regards to speed.
JXL has been ready for practical use for a while now - the only place where JXL support is still missing is browsers (due to Google’s politically-motivated removal from chromium). I’m not sure if anyone has tried using JXL with ML, but it’s certainly ready to be tested right now. IMO JXL has been ready since their libJXL 0.7.0 release, which happened September 2022 last year. They’re still working towards a 1.0 but every image-related application has built-in support for JXL already and it can more or less be considered ready.
haven’t seen any major downsides, besides less optimal performance for very low resolution images
Just to note here, to be precise AVIF starts (barely) winning at low fidelity ranges, not low resolution. Meaning if you want a blurry mess that looks like this, AVIF will compress slightly better (that’s an actual AVIF converted to PNG by the way).
At the risk of sounding like sour grapes, this compression advantage doesn’t truly matter. This level of compression is almost never used, and even if it was, even drastic relative filesize savings would ultimately amount to bytes/kilobytes in the grand scheme of all images you’re serving. It’s more impactful to compress large images simply because they are larger. Smaller images are already small and efficiency deltas in a 1kB vs 1.1kB image are meaningless compared to a 600kB vs 800kB image.
I also wonder if the support for progressive loading might be useful for more efficient, low resolution variants of high resolution models. Just store one set of high res images and load them in progressive steps to make smaller data sets. Like, say you have a bunch of 8k images, but you only want to make a website banner based on the model from those 8k res images. I wonder if it’s possible to use the the progressive loading support to halt reading in the images at 1k
I’m not fully confident on this aspect but I’m pretty sure that JXL supports more than just traditional progressive decoding - you can actually pull “complete” images out of the bitstream from arbitrary ranges. Meaning you could efficiently store a full range of quality options in just one image, then serve them on the fly.
Any time I see a big feature jump, like better file size, I assume the trade off in another feature negates at least half the benefit. It’s pretty rare, from what I’ve seen, to have improvements on all fronts.
JXL is self-described “alien technology from the future”, and it was made by a “dream team” of image engineers who have had a hand in just about every image codec and compression technique from our past. It also benefits from being a real image codec, whereas every recent image format that has gained widespread adoption has been derived from a video codec (WebP, AVIF, HEIC).
The only truly useful thing it doesn’t perform best-in-class at is animation encoding (losing to AVIF because it’s based on the amazing AV1 video codec), and I would honestly recommend just serving AV1 videos instead, and skipping image formats entirely.
A neutral aspect of JXL is that it does worse in single-core decode speed compared to JPEG (which is disgustingly fast), but JXL can be parallelized whereas JPEG cannot. This is ultimately an advantage for JXL for general usecase where users have at least 4 cores available, but for large-scale distributed processing I imagine this property of JPEG may still have an edge use-case?
If you’re curious about the technical aspects of JXL, I recommend reading their official slidedeck. The nitty-gritty details start at page 59, but the whole thing is a good read.
No one uses hardware decoding for images - it’s just not a good fit for the reality of how we use images. Images are small and easy to decode, whereas starting up a hardware decoder takes a non-trivial amount of time. Additionally, GPU decoders only work single-threaded, so each image would have to be decoded one by one, instead of all at once like with CPU decoding. This was already attempted with VP8/WebP and they gave up trying to make it any good. Videos are good candidates for hardware decoding since they’re large and you’re only looking at one at a time.
If you have benchmarks or some proof showing otherwise by all means post here.
You don’t need to use the high compression profiles to get good performance though. If you have a usecase where you are resource limited you should stick to effort levels 5-7 for very little loss in quality, or even 3-4 for lightning quick speed (the default is effort 7). Reference this benchmark against AVIF for effort values vs. speed (SSIMULACRA 2 is a deterministic psychovisual metric - higher is better).
Also, an important consideration in this realm is that JXL makes really clever use of variable-DCT (how big a chunk is) and adaptive quantization (what quality should be used for that chunk), allowing “quality levels” that you specify to be much more visually consistent across every image, instead of other codecs that make some images look bad at quality level 90 and some images look good at level 70. This allows you to select a consistent quality level and lower your encoding effort to compensate, instead of needing to always drive a high quality+effort level to account for every region in a picture looking good.
(If you want a slightly deeper dive into JXL’s performance, this is a concise post on various metrics)
I think you forgot a pretty crucial point, that it is also royalty free.
I’ll go back and add it - there’s a lot of great stuff that I didn’t mention just for brevity. The biggest royalty concern is HEIC atm, which is basically a nonstarter. I’m not sure how the licensing on the other free formats compares against JXL.
I wonder how the Chrome team managed to test it so poorly they claimed it wasn’t worth it? Just the versatility alone should make it a no-brainer.
Make no mistake, it was a political killing. They didn’t kill it because of perceived performance, they killed it ahead of their public benchmarks because of “lack of interest”. Their cited lack of interest was determined after only a few months of the format going live behind opt-in experimental flags, and once they made their original decision, just about every large tech company spoke up in favor of JXL against Google’s decision on their bugtracker, including Adobe, Intel, Nvidia, Facebook, Shopify, and Flickr. Google still plugged their ears and pretended no one was interested.
Google is trying to push WebP (2.0?) and AVIF, and using their browser marketshare to kill JXL and make that happen. Why they went through all this trouble to kill a format that they themselves co-developed, I really have no idea. I follow JXL relatively closely and I still am not 100% sure why they went through with this. All I know is that the decision was politically-motivated, and without applying political/ecosystem pressure they’re not going to change their minds with data.
Edit: by the way, the last few comments still trickling in on that bugtracker are a great read, especially #406. #406 reads so similarly to my comment I’m surprised I didn’t write it, haha.
A shortlist:
If JXL is not the next image format then we will never ever get rid of JPEG and PNG. There has never been a more obviously superior image format in history.
You probably have a higher attack surface from the gremlins in your walls. OTOH, Amazon knowing that you use Mullvad is a tangible downside, as they will probably use that to stick you in a marketing group or something. Monero is still an easy solution with the ~same cost if you’re concerned about that.