I think with the advent of agents, self-hosting has become a lot easier. For example, I self-host an XMPP server, and in the past there were error cases where you could spend days finding out what was wrong.
A few weeks ago, I had trouble with audio and video calls. Sometimes they worked; sometimes they did not. So I gave an agent access to my phone via ADB and access to the server logs, and within 30 minutes the problem was clear, and the fix was deployed.
Background: During the last migration, I forgot to enable STUN/TURN discovery, and therefore the client did not find it and could not connect when both were behind NATs. And you don't have to trust those agents blindly; you can use it as a learning opportunity and understand everything before you do anything or ask questions.
I think they just decided to use the formatting different than the others.
Normally, the background highlight color indicates the leader for every benchmark, but they chose to highlight their column even though there are better models.
> I think they just decided to use the formatting different than the others.
500px of the landing page is dedicated to share how they're more "token efficient" than the base model they used. Apparently this -6.5% difference is worth highlighting as the very top feature of this fine-tune they've made.
How much is 6.5% percent concretely though? Assuming the six benchmarks have ~30 tasks each (180 in total), and we're doing 120 tok/s lets say, time/task for GLM-5.3 Flash would be ~25 minutes and this "token efficient fine-tune" would arrive at ~23 minutes.
Again, a 6.5% difference is highlighted as the most impactful change for this fine-tune, but it's a marginal difference. They're definitely trying to mislead people into thinking this is something more than it is, otherwise this landing page would have been much more realistic and less self-patted.
My guess: because the OP forgot that to decode AV2/AV3 it matters not that it is in an AVIF container, it matters that the display system (browser, etc.) actually have the codec available to it that can decode the new format (AV2/AV3/etc.).
With no codec for a new compression algorithm, it does not matter if the browser can read the container, you still see the "broken image" icon on your display.
You didn't get the point of the post. I explained why and how container matters here. Not a specific container, but just the idea of container itself. Hint, it's not the browser.
Concrete example. Let's say GitHub will add AVIF support at some point (it's not yet handled well by the site as you can notice[1].
You as user can then upload AVIF images to wherever images on the site are processed. And after that, let's say when newer codec inside AVIF will get a good browser coverage, you'll be able to start using it without waiting another decade for GitHub to pipe it through their site code.
For formats without a container, it's always a two step process. Browser coverage first, then another huge period of sites support catching up.
> You as user can then upload AVIF images to wherever images on the site are processed
Those image upload pipelines almost always process the image in some way (downscaling, compressing). So a new codec in the same file format can only break them.
But even if it didn’t, I can’t help but view this as a dependency hell. Somebody uploads a version of AVIF not yet supported everywhere. Things break. User doesn’t understand why, because user doesn’t understand that .avif != .avif. Developers have a hard time figuring out why, because they have to check all software touching those files and check what specific codecs or version those support for AVIF. And all they can do anyway is to wait for all affected libraries or software to roll out the new codec.
So I guess in other words, the codec is the file format.
It might break or it might not. If it breaks - things can be figured out as you said. But the alternative is to wait on the site for who knows how long and in the end - it's not usable during that time anyway. I'd say not waiting just gives you more options.
Somehow, those principles remind me of SVN (the version control that was popular before git). The central server and clients can't run independently... Does not feel like progress.
I am also not a big fan of everybody calling them system one models. AFAIK, system one also refers to activities like driving a car, but I don't want to have those decision models driving cars.
So I think I understand what is meant, but I don't like the comparison.
Metaphors are easy to disagree with if you don't attempt to understand what they are used to try to communicate.
System one was an attempt to distinguish the "thinking" of thinking models (which is more akin to system two thinking with deliberate arguing/building up a decision) from fast instinctive thinking. It's a really good metaphor for the kind of trade-off or use case this applies to.
It is not and was never implying that it is a replacement for all human system one thinking activities.
Due to consoles being very locked down and due to them preventing users from running unsigned code, cheaters aren't a problem in multiplayer games on console
I think they're less of a problem, but still a problem. There are devices one can use to add/remove aim jitter, counter weapon recoil, etc. They sit between an input device and the console, and have per-game and per-weapon profiles.
Did you check if the correct exif data is present? Normally, cameras don't rotate the data but place an EXIF attribute to let the viewer know how the data should be presented. If the viewer does not read the EXIF attribute or it is not present, the picture has the wrong orientation. So I would start by finding out if the EXIF data is actually present.
Nevertheless, this is stuff even LLMs know how to do correctly, so there's no excuse for Apple here.
Not because of the models, but because it comes in a nice (easy-to-set-up) package, and the latency was lower than I expected with such a setup.
reply