I don't think MacPorts users have those kind of problems.
Personally I was burnt by Homebrew many years ago already. I lost trust in any such package managers. Since then I went back to just compile everything myself (I manage about 300 packages like that in my installation.) It's not that a big of problem. Only initially when you need to bootstrap everything to replace Homebrew it was quite the time investment, of course. But now you compile like a package here or there… just follow the script. It's very quickly done.
The best thing… no clutter. Every package has its strict directory. I only symlink from that what I need into /usr/local/bin.
When Homebrew first came out, I found its antagonistic marketing off-putting. The website used to read "MacPorts driving you to drink?" I always found its takeover of /usr/local and the lack of authentication for software installation to be strange decisions. Amusingly, its approach these days is closer to the way MacPorts has always done things.
> Every package has its strict directory. I only symlink
Isn't that exactly the benefit of homebrew? It installs in one folder and symlinks.
And my guess, it would've been much easier to remove extra symlinks you don't need from its package manifest rather than rewrite the whole system
Homebrew links everything by default (at least that's how it was), so you ended up with all kind of extra junk files all over the place you never needed that comes with some packages... all cluttering up things in the /usr/local main directories and the PATH.
Homebrew additionally also had bunch of other directories, a huge git checkout, etc. then add the weird permission restrictions/ limitations on top of it… many packages then stopped supporting the customisation options at some point, so you were forced to rebuild half of them yourself anyway, if you needed the respective options. Now you had even more mess in /usr/local. :-)
It may work for some, but it wasn't for me anymore (and I used Homebrew for many years before that.)
Same. When they explained why they assumed and required /usr and/or /usr/local was owned by steve or bill or whatever, with a straight face, I was gobsmacked and never touched it again.
Like, how did people so ignorant come to manage such a project? I excuse most of the users but not the authors who have the balls to call themselves "engineers" on top.
I wouldn't be suprised if they weren't the very reason shortly after that Apple took over ownership and brute force OS control over those dirs.
It's just the same on Linux though. Don't touch anything under /usr but /usr/local or you will run into issues, third-party software uses /usr/local, and that is why Macports ended up in /opt/local - guaranteed free of collisions.
I don't see any advantage of any of the new formats over the good old and proven formats, so I stick with PNG and JPEG (properly optimized.) I can fire up any old browser and it will just work.
Unless you're targeting really old browsers, lossless WebP is absolutely worth it over PNG.
As a test, I have a set of 36 old MS paint Drawings, originally drawn on Windows 98SE, originally saved in bitmap format with a total size of 53.4 MB.
Transcoded to PNG format using FFmpeg and the highest -compression_level of 100, this same set of images takes up 403.8 kB.
Transcoded to -lossless WebP format using FFmpeg and libwebp with the maximum -quality value of 100 and maximum -compression_level of 6, the set of images takes up 174.8 kB.
Transcoded to lossless JPEG XL format using cjxl in the highest compression settings, the 36 images only takes up 126.6 kB.
Given the computing power required to decode JPEG XL images and their limited support, it may not make sense to use JPEG XL for non-archival purposes, but lossless WebP is an excellent middle-ground, achieving over 2x the compression level of PNG.
Lossless WebP has also been supported by all major web browsers since September 2022, when Apple finally added full support for lossless and animated WebP images. It really doesn't make sense to still be using PNG, unless you're targeting really out-of-date Mac or iOS devices. Having drawings and illustrations be 50% smaller (versus PNG) is huge!
Personally, I avoid WebP out of spite. While it has greatly improved over previous formats in certain uses, it has been lacking or offering only marginal improvements in others. That didn’t stop Google from pushing it hard on the web.
I was left feeling like the next time we adopt a format that tries to do everything, it should actually do everything just as well or better than its predecessors. Lo and behold, JPEG XL is probably the first format which actually achieves this, covering all kinds of pictures you can think of and doing a pretty good job on all of them. So for the first time, I feel like the format has actually earned its place in the ecosystem, rather than just being some megacorporation’s personal favourite.
Of course, this point of view is emotional more than rational. Technically, WebP is a sensible choice, so I don’t mean to discourage anyone from using it today.
It wasn't some one company's choice and push. Almost everyone wins when bandwidth is cut and you get higher quality for less space. I'd argue most people's hatred for webp purely comes down to a few other corporations like microsoft, not supporting it well in the early days and blaming the format instead.
How so? This table [1] shows the adoption dates for WebP in various popular programs (as does Wikipedia [2]). Of all high-profile programs, Chrome was the only early adopter; other browsers were avoiding it for years, not to mention off-line software. Mozilla went as far as to work on a JPEG encoder [3] after WebP was introduced by Google, to see if maybe JPEG itself could be improved enough. How does that not read like one company’s choice and push?
> Almost everyone wins when bandwidth is cut and you get higher quality for less space.
Sure, but that doesn’t mean you immediately adopt every new codec that brings improvements in some area. With every new feature comes new code, new baggage, new potential attack surface. You have to ask if the improvements are big and consistent enough to go through the effort and burden the entire ecosystem with yet another format everyone now has to deal with. You need to think of the user and developer experience both in and outside of the web.
Microsoft would have been perfectly within their right to blame the format, since Google just decided to let it run wild on the web without garnering more support for it first. The format has its pros and cons, and it’s up to all the involved parties to weigh them and hopefully reach a consensus.
I'm sure they have some preferences for smaller pages.
If you're saying they did a thing where 200KB webp had an advantage over 200KB jpeg, please link your source. When I search I only see people saying that's not the case.
JPEGXL literally is able to display images and colors that jpeg and png cannot (32-but floating point, layers, emission independent transparency, spot colors, built im depth maps). It’s not just about compression optimization. So for those use cases standard JPEG and PNG alone will never work. There are “updated” versions of JPEG that support some of these like HDR but those won’t work with any old browser either so back to the same issue.
Bottom line it can deliver greater quality at much smaller filesizes. Considering RAM and storage are more expensive per byte now than they have been in years, I think it's incumbent on everyone in a position to do so, to use those resources wisely.
WebP and AVIF and HEIC had similar advantages but also some disadvantages (honestly chief disadvantage to WebP in my humble opinion was that nothing except web browsers -- to this day -- seem to support it!).
Another important point in its favor is that JPEG XL is designed as a royalty‑free, open standard, and Google provides a perpetual, worldwide, royalty‑free patent license for its reference implementation.
Avoiding JXL (once the rollout is sufficiently complete) seems, to me, like still shipping (non-animated) .GIF files where .PNG is better and smaller.
I imagine the result of this will be social media platforms and such will deliver higher quality images at the same filesize. Currently for local storage any image format is mostly fine, but for web services the image size becomes a massive cost which is why they compress your 8MB JPEG down to a 2 megapixel crunchy mess.
It's trivial to make an image that you can see the 8-bit quantization in. Just make 256 vertical gray bars, equally spaced. In much of the image (usually the darker parts, but depends somewhat on monitor calibration) you will see the border between two values. Note that this is every single possible grey value in 8-bit RGB, so it is a proper un-dithered rendering of a gradient, and the borders you are seeing are definitely quantization artifacts.
Now, if you apply proper dithering, particularly on a high-dpi screen, you can make it look a lot better, possibly even undetectable.
And this is just with the dynamic range that is comfortable on a computer monitor! If we really want to represent vibrant images, then the glare of the sun off of shiny objects should be much brighter than the "paper white" background used in e.g. your word processor. It should be intuitive that the brightest highlight in a real-world image ought to be too uncomfortable to fill your entire monitor with...
Lastly, there's a question what and how the image gets to the browser. Sure for the images on the landing page for $LARGE_CORPORATION you have a graphic designer make everything look great, and since most people still have 8-bit displays, you'll want something that looks good on one. But what about e.g. a site for uploading photos? Are you going to quantize all of their photos before displaying them (possibly to someone with an HDR display)?
The cost of HDR displays is decreasing, and the data cost is minimal. (adding more bits to video actually decreases the size because the rounding errors get smaller)
Yes, a hdr photo in heif or jxl is a night and day difference. And if you apply any kind of color edits to the photo it stretches the colors to the point visible banding occurs on jpeg.
Yes, and image editors absolutely can. If JXL lets me correct over/underexposed images by default everywhere I find them then it's worth it even just for that reason alone
E-commerce is the important use case, particularly in goods where people care about appearance: clothing, cosmetics, food.
Things in these categories have colorful packaging with spot colors, metallic inks, coatings, as well as store displays with carefully designed lighting. The added cost is justified because it increases sales. It makes sense to carry that over online.
JPEG can represent "X" number of colours, but the human eye can detect Y>X colours. JPEG-XL can represent >X colours (but not as many as they human eye, Y):
JXL can do more colors than the human eye can perceive. Some chunks are out of range when using current standards, but it can do other chunks at 100000x the color resolution your eye can detect.
It looks fine sure, but that doesn't make it good either. Are you going to lock display technology to 8 bit forever? Most PC monitors already match or exceeding that limit, phones especially. HDR is something that needs to happen eventually, and for that new format is very important
I used to think this and then I saw how well webp reduced my website's bandwidth costs compared to optimized jpg or png. I felt a bit left behind at that moment, like I should have been paying attention to these great improvements over the years.
It is great to reduce file size but also the quality drops faster than it does with JPG. I did some testing and could confirm, it is quite documented.
Which I think it might be one of the reasons why Instagram still uses JPG for their images. The rule of thumb is that if your product is picture quality sensitive (like photos in IG) then use JPG, if not then WebP is fine since the compression is higher.
Are you actually comparing apples to oranges? If webp reduced your bandwidth that much you're properly overcompressing way below the quality you used for jpg.
I'm not sure if the parent comment means to say, but I could choose to interpret their meaning to be:
PNG/JPEG have strong support (nearly everywhere). I think of them almost as the modern TIFF - relatively simple, and almost everything supports one or both of them (few to no issues).
JXL may eventually get there (that indeed seems to be its goal), but for now I wouldn't drop e.g. PNG or JPEG support in favor of JXL now.
And arguably, perhaps never drop support; its such a prevalent format, even if all software (prevalent or otherwise) supports the format in 10 years, there will be such a huge stockpile of JPEG/PNG that something will need to be used to read/convert.
Not everyone needs to be an early adopter of every technology.
Even if JXL is superior in every single way, it doesn't make sense to throw out a perfectly functional graphics package and design language for a marginal bump in capability.
The industry already started throwing out jpeg for heif because jpeg is so woefully inadequate. Most camera brands have heif support now despite heif having horrible patent issues. Jpeg XL provides all the technical benefits without being patent encumbered.
For a past customer, not at all. That customer really cared about delivering image-heavy pages quickly. There was a fairly big difference in customer perception at a timing threshold.
The very point of this topic is that JXL is leaving the "early adopter" realm. If your website begins serving JXL assets next month, you'll simply be an adopter.
I just switched over some machine vision code to use it for the lossless format, saving around 30% file size (~5 gigabytes per dataset) over optimized lossless PNG. I'll gladly take any storage donations you may be passing out though, so I can continue to use the good old and proven formats! ;)
biggest advantage for me is file size and lossless conversion of existing jpg images. In a network scenario that can meaningfully impact load times. Others will care about e.g. bit depth
Yeah but file size and lossless conversion of existing JPEG are something done by many other codecs. Dropbox famously developed Lepton[0] to compress existing JPEGs losslessly. There need to be some other factors that would lead to increased mindshare.
Being a well supported format on all OSs will allow that. One of the biggest failure of WebP was very poor native support beyond browsers. JXL is supported natively by pretty much all operating systems right now beside Android. JPEG recompression is simply an advantage
I think the main issue with webp is it was pushed as purely a web delivery optimisation format and not a final output file you’d use in software. So it worked fine if you have a website automatically converting files for delivery, but no one was pushing for it to be supported in other programs.
JPEG XL is marketed as a high end format for photographers and already has support in most editing software.
There are many websites that would happily deliver webp images to the user and then refuse to accept webp images uploaded by the user (in forums for example). It just didn’t work for anything other than being displayed in a browser.
well, lepton doesn't have browser support. I'm not married to jxl specifically, I just want something in the browser with those features, and jxl fills that niche
What a weird name to choose. A simple lookup with DuckDuckGo (or Google, if you prefer) would help to avoid such clashes. Probably any of the so called "AIs" could have pointed that out too.
It might be well known in Amiga circles, but it would be hard to call a web browser for Amigas that last had a release nearly two decades ago "well known".
Name clashes happen all the time, it doesn't seem like a big deal.
here's what I did instead, I went to https://duck.ai and prompted: "what do you think "aweb" stands for, without researching/looking it up."
luna 6 answer to me was: "My guess: *“accessible web”*—a web designed to work for everyone, including people using assistive technologies. Could also just be a stylized spelling of “a web.”"
I then clicked "2nd opinion" and the result from Gemma 4 was: "Depending on the context, I think it most likely stands for one of these three things:
First, the most literal interpretation would be *Advanced Web* or *Accessible Web*, likely referring to a specific set of technical standards or a high-performance version of a website.
Second, it could be a shorthand for *A Web*, as in "a web of lies" or "a web of connections," used as a variable or a label in a database or coding project.
Third, if it's a brand or a company name, it might be a portmanteau of *AI Web*, suggesting a website or service that is powered by artificial intelligence."
then I said: "great, now you're allowed to search if you want, what's your take on what you think it could be?"
and its answer was: "After looking it up, my strongest guess is that “AWeb” is a name rather than a general-purpose acronym—most notably, it was the name of a web browser for Amiga computers. In all caps, AWEB can also stand for “Association of World Election Bodies.” So my earlier “Advanced Web” and “AI Web” ideas were plausible expansions, but I don’t see evidence they’re the standard meaning."
just sharing, thought it was fun to run this N=1 experiment since you shared yours
For the fun of it: I asked Google Gemini and ChatGPT (OpenAI) "What is AWeb?" and they both gave me the amiga browser as answer. No idea if they just know, or did a similar lookup as I did? :)
I did use nmap on a Linux VM going over the free ProtonVPN for this purpose, but at some point Proton broke something (it may be related to their VPN accelerator feature) and checking any port always reports "Open" (even if it's not), so sadly that made this cool use case entirely useless for me. It definitely was nice to know you had no open ports other than the ones you purposefully opened. :)
Occasionally drag'n'drop failures —where it just stops working— I experienced already with Yosemite, so it may be a VERY old bug. :) Usually you would see "CoreDragError" codes popping up in the system.log
Rather than rebooting, I just kill "pboard" in Activity Monitor, and afterwards restart a few GUI programs that were directly affected (including Finder and Dock.)
My wild theory is that Firefox is the culprit. At least the issues happened more frequently once I had to switch to Firefox for proper content blocking extensions. Anyway… I have no idea how to prove that, so it's just a guess, not a blame.
If you leave that in it's actually worse, since the platform was discontinued. I had to fix all my client's projects to remove this stuff. One of those stillborn ideas of the EU.
In my own ranking of favourite programming languages C is at the first place. C++ comes in last. I personally hate it when people write C/C++ as if it's the very same thing. I'm quite sure there's more like me out there. :)
Interestingly Perl comes in second, even I use it rarely (aka not at all) these days. But that's a slightly off-topic side note. :)
And yes, for the most part. C++ as simple shorthand for struct-attached functions and automatic memory management (no, not smart pointers; RAAI) is good. Every single thing added after that is misery and should push a modern developer to Rust, Go, or Zig (roughly in that order) where such things are implemented sanely or not at all.
And direct access to system calls. And the uncanny ability to look like it's going to do what I want and then five minutes into a run wind up in a small town in Arkansas blind drunk and crying vaguely about fluffy red squirrels taking its sandwich.
For me, C++ is always in first place. It allows me to do high-level abstractions to low-level hijinks all with total control (i.e. zero-cost abstractions, Templates for compile time programming etc.) across all levels of the software stack and the full spectrum of available hardware.
Furthermore, any C++ programmer who says they do not know C, knows neither C nor C++ (hence my preference in using C/C++ as a shorthand to encompass both and highlight the dependency of the latter on the former). I often see this in novice C++ programmers who started with "Modern C++" and identify it as something like Java/C# because of the now huge set of standard libraries and copious syntactic sugar which only compounds their confusion further.
> Furthermore, any C++ programmer who says they do not know C, knows neither C nor C++ (hence my preference in using C/C++ as a shorthand to encompass both and highlight the dependency of the latter on the former).
Right, but this dependency is one-way. There is an entire legion of C programmers who reject C++ (most notably Linus), so claiming that almost all C programmers are also C++ programmers is a bit off.
What i meant was that almost all C programmers are aware of and know C++ to varying degrees. But they choose to not use it for their application based on needs/expertise/etc.
Linus Torvalds objection to using C++ is perfectly logical for his use-case. I know many embedded programmers who refuse to use C++ even though they understand and agree with the benefits that it can bring to the table. Their C expertise is so good that when they program, cognitively the language just disappears and they "flow" through the problem solution implementation. This is the crux of problem-solving.
Many of us were there when yada yada white wizard. Hell, my first paid job was writing Perl CGI scripts. Well, script. Monolithic MFing thing spread across 100 files and running a whole company on text files with zero format documentation and RCS as version control. No need for CVS because the systems were incrementally archived with tar every hour...
Until they weren't. (I'm glad you saw that coming, because they didn't.)
If they don't have to re-code half the app (new UI kit, not required features, etc.) then what does it matter if they are 10k unrelated commits behind?
I like it's there as a choice for us who prefer the old-timey Audacity for some quick sample editing.
Personally I was burnt by Homebrew many years ago already. I lost trust in any such package managers. Since then I went back to just compile everything myself (I manage about 300 packages like that in my installation.) It's not that a big of problem. Only initially when you need to bootstrap everything to replace Homebrew it was quite the time investment, of course. But now you compile like a package here or there… just follow the script. It's very quickly done.
The best thing… no clutter. Every package has its strict directory. I only symlink from that what I need into /usr/local/bin.
reply