I think many people disliked Google's control of Chrome blocking JPEG XL rather than it being able to compete on its merits.
JPEG XL also has some big benefits for many use cases like lossless re-encoding and supporting higher resolution. AVIF images have a max size of 8192x4352 last I checked. That's not a problem for web images almost all of the time, but there's certainly uses where you might want more. I think AFIV might be limited to 12bit overall while JPEG XL can do 32bit. Again, is that something many will take advantage of on the web? No, but if it's something you care about it might be really meaningful to you.
Also, if you care about the 90% quality level, JPEG XL often outshines AVIF, but when I'm putting images on the web it's often well below that.
Some of it was bad information. I saw some people saying JPEG XL being way less computationally intensive (even less than WebP) and offering much better compression. Some of it was selective data - do you only test things at 95% quality level and declare a winner?
But I think the big thing is that a lot of people wanted the two formats to succeed or fail based on their merits. I think a lot of people don't like AVIF because it isn't well supported outside of browsers - and there can be a hope that the JPEG name would mean JPEG XL would get the kind of adoption JPEG did.
And it's hard to truly compare formats - or benchmark in general. As the article shows, different JPEG XL encoders offer vastly different performance. And when we're dealing with lossy compression, sometimes it can be a bit of personal preference. At some point, people started enjoying the way that MP3 garbled symbols (the instrument) and that was the sound they expected a symbol to make.
> coded image items compliant to the AVIF Baseline profile may not have a number of pixels greater than 8912896, a width greater than 8192 or a height greater than 4352.
I'm assuming if both the encoder and decoder support more than the baseline profile, then higher resolutions up to 64k x 64k are possible, although I would worry the file would be incompatible with some software.
It's been a few years since I last tried, so hopefully no longer an issue, but trying to encode 8192 × 5464 images from a Canon R5 a few years ago with libavif, and avifEncoderAddImage() would return a generic error.
If I reduced the res a bit, then it worked, so there did seem to be a limit there somewhere. height and width are stored as u32s internally though, so yes, the format itself technically supports it...
I never looked into it more, so might have been a libavif issue, or maybe the way I was using it (maybe it has defaults or profiles?)
I've kinda stopped looking at token pricing. Argon might be the same token pricing as Sol, but in Artificial Analysis' testing, Argon costs 5.8x more to run their coding tasks and 2.2x more for their general index.
Likewise, you look at Artificial Analysis' general index and it cost $8,708 to run with Opus and $2,407 to run with Argon so even if Argon's token price doubles, it won't be the same price as Opus.
Sonnet is cheaper than Opus per-token, but in their coding tests Sonnet burns through enough tokens that it's 7.5% more expensive.
So much depends on how token efficient something is and whether it gets you a good result or not, right?
Plus, if one is using a plan instead of paying token rates, what does my $200 get me from OpenAI, Anthropic, or Google?
It just feels very hard to compare pricing given that the number of tokens used can vary so much. In Artificial Analysis' coding tests, Sonnet used 7.1x more tokens than Sol. Sonnet and Sol might have the same per-token pricing, but there's a huge difference in the number of tokens used.
Does your company care about compatibility with UNIX® infrastructure or that it's compatible with Linux/BSD infrastructure?
People care that macOS has a lot of compatibility with Linux/BSD, but most don't care that it's UNIX® - just as people don't care that Linux/BSD aren't UNIX® compatible. Yes, Linux/BSD are very similar to UNIX® and mostly compatible, but they don't conform to the specification.
You (probably) don't care about the UNIX® specification. You care that your MacBook has good compatibility with Linux/BSD infrastructure. Many people assume that Linux/BSD are UNIX® and just don't pay for certification. They aren't UNIX® compatible. They are extremely similar, but they don't follow the spec 100%.
Sorry for putting the ® everywhere, but people often use UNIX when they mean nix-like operating systems and when we're talking about whether people care about macOS as a UNIX® or not, it matters whether were saying "people want macOS to be UNIX®" vs "people want macOS to have good compatibility with nix-like operating systems such as Linux and BSD like it does today." People usually care a lot about the latter and not about the former.
There's a long story behind it, but Apple started saying that Mac OS X was UNIX, but UNIX was a trademark. So Apple decided that they either needed to alter OS X to conform to UNIX standards or buy the trademark. They chose the former.
> Is this Apple just not wanting to pay for the certification anymore or does it actually change anything for us devs?
It's probably not about paying and more about tiny differences. Will it change anything for you? Almost certainly not. In fact, it might make things better for you. If anything, Apple's adherence to the UNIX spec can sometimes mean subtle differences in tools between macOS and BSD/Linux. Do you want things like grep or sed that conform to the UNIX spec or that work like grep and sed work in the real world?
And these differences are often small edge cases that don't come up much, but a spec is a spec.
The money is inconsequential for Apple, but at this point it probably makes more sense to just stop calling it UNIX and not worry about shipping a version of a tool exactly meets the UNIX spec - it'd be more useful for their users if it matched the behavior on Linux/BSD.
That grep/sed difference on mac caused me issues so many times, always thought it was just Apple doing their own thing.
I didn't realize it was a spec thing.
It's neither, really. OS X takes its command line utilities from BSD world, while Linux's mostly come from GNU. They're independent implementations, and GNU utilities are as a rule much more featureful than their BSD equivalents. Or much more bloated, depending on your point of view.
Both aim to conform to the POSIX, but POSIX is a very spartan spec, people routinely use non-POSIX features without realizing it.
> I would prefer if Toyota just released a new EV model with roughly the same proportions as the Corolla
I think the issue is time and money. Toyota maybe doesn't want to spend the money on a completely different car in the compact sedan category just for EVs - at least not yet. Plus, it might mean waiting several years when they want something out now. Sometimes it's about tradeoffs like time and money. Adapting an ICE Corolla might be reasonably cheap and fast. They might feel the need to have an EV Corolla out sooner than later. They might want to take their time with a new platform EV so that they don't put out something that doesn't meet their quality standards. While the drivetrain might be different, everything else in the Corolla is battle tested.
Further, Japan is especially hard hit by the Strait closing. Toyota may have thought they had years before they had to go fully EV, but the world has forced their hands. They need to be offering options today.
You're probably not getting mm wave with Mint. T-Mobile hasn't deployed mm wave much. They have deployed a lot of 2.5GHz spectrum which will be very fast (faster than most people's home internet connections). If you're seeing 5GUC, that's probably not mm wave.
I think a lot of people are attributing speeds of 200-700Mbps to mm wave when it's actually pretty ordinary speeds for 2.5-5GHz coverage today now that carriers have decent capacity there. If you're getting below 144Mbps, you're in the bottom 25% of T-Mobile's network experience. Over the past 6 years, speeds have gotten a ton faster, mostly from 2.5-5GHz spectrum. Verizon is the only carrier that put much effort into mm wave and it still covers basically nothing.
Ignoring latency, you're likely to get speeds similar to wifi from today's mobile networks without mm wave - unless you have a really great home internet connection and a good wifi setup. I have a MacBook Pro, but it only has wifi 6 and I can get 700-800Mbps out of my wifi, but I'm not getting 2Gbps from it.
5GUW on Verizon isn't necessarily mm wave. Originally, it meant mm wave, but that hasn't been the case since 2022. Now it means the 3-5GHz C-Band spectrum or the 20-50GHz mm wave. If you're seeing 5GUW on your phone, it's going to be C-Band a lot more than mm wave.
C-Band spectrum also makes sense given a speed test of 400-800Mbps. That's fast, but not hugely faster than what you should expect with really good coverage today. T-Mobile experiences speeds above 560Mbps 25% of the time. Verizon's 5GUW (which is mostly C-Band) experiences speeds above 620Mbps 25% of the time. You ran two speed tests and got 477Mbps and 767Mbps. One of those is pretty average for C-Band and one of those is quite good for C-Band (25% faster than the 75th percentile), but nothing too out of the ordinary.
Those are speeds that are relatively common when carriers have around 150MHz of 2.5-5GHz spectrum deployed in your area and you have good signal and not too much congestion.
mm wave does exist, but the coverage is often a block or two with indoor coverage being really spotty. C-band coverage will be measured in square miles. C-Band won't have the coverage that lower frequencies have, but it's a lot more practical to deploy than mm wave. mm wave shines when you have a small, high-value area where you want to deploy 1,000MHz+ of capacity. Carriers might have 50MHz of capacity around 800MHz, 90MHz of capacity around 1.9GHz, 150MHz of capacity around 4GHz, and 1,000MHz of capacity around 30GHz. That really high frequency mm wave won't cover a large area, but there's a lot of it. If you're looking to cover a sports stadium, it makes sense. If you're looking to cover people's homes (even in major cities), C-Band is going to get you really good speeds with coverage that will be a lot more usable.
It's possible that you're getting mm wave, but those speeds are pretty normal for good C-Band coverage. The first test is pretty average and the second test is quite good, but nothing extraordinary.
Everyone uses the example of stadiums, but the occupancy rate of stadiums makes the economics of the network and backhaul iffy. I would guess only the biggest NFL stadiums get it as a showcase. Maybe parts of Manhattan, too.
Chinese cities, especially at train stations and the surrounding area get really impressive flows of people every day. But even in China I would expect that while they might have a lot more 5G SA when in the US, that the radios are actually mid band and not millimeter wave for most coverage. You still get higher capacity and low latency, but most people probably don't notice the low latency, except maybe Chinese autonomous taxis faking it till they make it.
I've gotten mmWave on Verizon in certain spots in Midtown Manhattan. But it doesn't really give me a lot of practical benefits over non-mmWave 5G.
In general, putting aside the bandwidth/crowding concerns (which are real, of course), I don't find 5G that much of a step above LTE - it's nothing compared to the jump from 3G to LTE. LTE changed how I used my phone in a big way (e.g., I could now watch video or download something on my phone practically). LTE got pretty fast over time anyway.
Yes, there are trade-offs, but you can get really great tires on all three. The Michelin CrossClimate2 tires are arguably the best traction tires, Consumer Reports estimates 95,000 miles of tread life in their testing (higher than basically anything else), and they got a 4/5 for rolling resistance on Consumer Reports' dynamometer testing.
There's a lot of tires that are poorly made and just bad tires. For example, one tire got 2/5 for rolling resistance, tested to 55,000 miles for tread, and 2/5 and 3/5 ratings for the traction categories like wet braking, snow traction, ice braking.
I'm not arguing that there aren't trade-offs, but tire companies have been working to make better tires that minimize the trade-offs and produce better tires on all three.
> The rule is “designed to ensure that replacement tires sold in the state are at least as energy efficient, on average, as tires sold in the state as original equipment.”
It sounds like the rule isn't exactly that strict. This (combined with the fact that all season tires aren't covered) presents a very low bar. But there are tires that are just garbage - they're bad at all three. It doesn't sound like this rule would impact good tires that have very long tread life and amazing traction. It sounds like it'd impact the tires that are a pile of garbage.
There's a difference between a tire that trades off a small portion of rolling resistance for traction and tire wear and tires that are poorly made and are trading off a huge amount of one or two of those categories because they're just bad tires.
It's worth pointing out the CrossClimate2 tires are all-seasons and exempt from the requirement. The 4/5 is specific to Consumer Reports all-season category - actual efficiency is going to be noticeably lower than the high efficiency tires they are talking about in the article.
But you're not wrong in general. There are a lot of garbage tires. And that's not even considering the intentionally "bad" tires like the knobby off-road treads that also have the side effect of massively increasing road noise and reducing engine life.
But like a lot of the California rules, they have carved out so many exceptions and have no real enforcement mechanism (the worst offending tires are being imported directly from China). So the reality is that there is not going to be a lot of juice for the squeeze.
The US military-industrial complex is the single largest institutional hydrocarbon consumer and greenhouse gas emitter on the planet. It would be pretty stupid for me to listen to the government's advice about how best we should preserve the environment.
So the issue is under regulation, yeah, agree on that point.
Sounds like the only reasonable solution to the problem you raise is that the part of our government that's responsible for defense should be put under the seperate part that is responsible for protecting our environment instead of being exempt. I can't see any other real way of resolving that issue can you?
Because government self regulation totally works and the resources used up and the size of the government has not grown by such magnitudes that would make the founding fathers rethink the whole idea of democracy?
Ok, so no particular disagreement or pragmatic pitched alternative, great! I agree, structurally improved government and regulations is the only definable way forward for me too.
China has been the largest ghg emitter for the last 20 years, and currently emits more than twice as much as the us. Gdp spent on defense is similar as a fraction of gdp (slightly more in the us). So realistically the Chinese military is by far a larger emitter of ghg than the us military.
> The Michelin CrossClimate2 tires are arguably the best traction tires,
In their class, but not in general.
They are all-season tires. They don't perform as well as winter tires in the winter, and they don't perform as well as summer tires in the summer.
They're also a terribly mushy tire. They feel like you're floating around on the road and wallowing through the turns. This doesn't matter in the slightest to someone commuting to work in their 15 year old Honda Accord with blown struts, but if you enjoy driving they're on the list of tires to avoid.
Everything is a tradeoff. Some tires do a better job of optimizing within their class, but the Michelin CC2 is assuredly not the best traction tires in general.
>They don't perform as well as winter tires in the winter, and
A lot of people don't live in climates where winter tires are even sold; particularly California, Texas, Florida, three of the most populous states. Many people in those states aren't even aware "winter tires" are even a product category. That's like complaining the Walmart in Anchorage, Alaska doesn't carry SPF 50 sunscreen.
Just as a geographic note: You can buy winter tires in California. The Sierra Nevada (snowy mountains) run down a sizable chunk of the state. California has even hosted the winter olympics.
You left the "and" but left out the critical part of my quote: They're not as good as summer-only tires in the summer.
> A lot of people don't live in climates where winter tires are even sold
The CrossClimate 2 tire we're talking about is an all-weather tire with the 3-peak snow designator. If you're trying to call me out for talking about winter tires in comparison to a tire designed for winter weather, I think you don't understand what we're talking about.
> Many people in those states aren't even aware "winter tires" are even a product category
Again, the CrossClimate 2 is a tire with a winter designation. California also has a lot of snowy locations.
> That's like complaining the Walmart in Anchorage, Alaska doesn't carry SPF 50 sunscreen.
Not only do stores in Anchorage carry SPF 50, but you're going to need it in the summer. When the sun is out for 20 hours a day, it adds up.
My Mach-E came with CrossClimate2 tires and I am not impressed. I've accidentally lit up all 4 tires under hard acceleration on a dry road, despite 5000 lbs pushing them into the ground and some amount of traction control still active.
I have a lighter sports car making similar power, on Michelin Pilot 4S summer tires. That car just grips and goes with barely a squeal. Good summer tires also have far better wet performance than CC2s, and they provide better feedback.. you feel more planted and in control.
I am impressed overall with the CC2's ability to be a true all-rounder that is usable in snow, but it is still an exercise in trade-offs and it'll never be as good as any purpose-built tire is at its purpose.
> ... can get really great tires on all three. The Michelin CrossClimate2 tires are arguably the best traction tires, Consumer Reports estimates 95,000 miles of tread life in their testing (higher than basically anything else), and they got a 4/5 for rolling resistance on Consumer Reports' dynamometer testing.
That is incredible. My front ones are toast after only 15 000 miles / 25 000 km ( Continental Sport Contact 3 / N0 rating) and two years. 95 000 miles and I'd need to change them not because of wear but because they'd be legally too old.
Indeed, I put a full set of CrossClimate2 on my German car and the two back tires were completely toast within 24 months and ~15k Km (on Canada). After that I decided to start using proper summer and winter tires.
Have any of yall given up on “nice tires” due to constant nail / screw punctures and subsequent loss within a very low mileage count?
I believe I spent $1200 on my last set only to lose two of them in the first six months due to road debris. Perhaps this is down stream of living in a boom state with constant construction but I’m nearly replacing cracked windshields and at least partial tires annually as of late.
Artificial Analysis shows Grok 4.6 taking $1,068 to run their suite while Gemini 3.7 Flash takes $485. So it looks like Gemini 3.7 Flash is less than half the price in the real world.
Per-token cost isn't a great metric given that some use way more tokens than others.
JPEG XL also has some big benefits for many use cases like lossless re-encoding and supporting higher resolution. AVIF images have a max size of 8192x4352 last I checked. That's not a problem for web images almost all of the time, but there's certainly uses where you might want more. I think AFIV might be limited to 12bit overall while JPEG XL can do 32bit. Again, is that something many will take advantage of on the web? No, but if it's something you care about it might be really meaningful to you.
Also, if you care about the 90% quality level, JPEG XL often outshines AVIF, but when I'm putting images on the web it's often well below that.
Some of it was bad information. I saw some people saying JPEG XL being way less computationally intensive (even less than WebP) and offering much better compression. Some of it was selective data - do you only test things at 95% quality level and declare a winner?
But I think the big thing is that a lot of people wanted the two formats to succeed or fail based on their merits. I think a lot of people don't like AVIF because it isn't well supported outside of browsers - and there can be a hope that the JPEG name would mean JPEG XL would get the kind of adoption JPEG did.
And it's hard to truly compare formats - or benchmark in general. As the article shows, different JPEG XL encoders offer vastly different performance. And when we're dealing with lossy compression, sometimes it can be a bit of personal preference. At some point, people started enjoying the way that MP3 garbled symbols (the instrument) and that was the sound they expected a symbol to make.
reply