wirybeige

I have noticed it to be slightly worse, mostly on "bad" sites. Just using Brave at this point though.

Granite is IBM

I presume the providers are the ones giving the info to OpenRouter? I mean, technically it is a mix of fp8 and fp4 (although it is predominately fp4), so I don't think either is inaccurate.

DS4 Pro/Flash were post trained with QAT, so they are already quantized to FP4 for the most part. That's why when downloading the weights, they are much smaller than what their weights at fp8 or fp16 would be. For example, Flash is a 284B model, but its GB size is only ~160GB. OFC maybe DeeppInfra went even further, but there is no proof of that.

Personal anecdote --- Proton Pass very quickly went from worse than Bitwarden to better with more reliable auto-fill.

These were trained on NVIDIA gpus. It is running inference on Huawei.

Why would these 3rd-party providers be taking losses? Together, Novita, etc... are not losing money on inference services, they are profiting. You can easily do napkin math with current & last gen Nvidia cards to calculate cost to host/serve these models. I would also doubt that any 1st-party providers like OpenAI and Anthropic lose money on per token billing. There is almost undoubtedly healthy margin being made on that.

Pricing for DeepSeek V4 flash is $0.14 in/$0.28 out across basically every provider or close to it. It seems most providers just follow the model creator and set their prices to match. V4 pro was set to be $1.74 in/$3.48 out when DeepSeek first announced it; all providers have set their prices to be about that price, & now DeepSeek has set their pricing to $0.435 in/ $0.87 out. I don't know if this is special pricing, or the promise they made for dropping the price when they get more Huawei cards online. It seems that providers like ParaSail, Together, and Novita just set the price when the model comes out and don't compete.

The vulkan backend for llama.cpp isn't that far behind rocm for pp and tp speeds

Sodium batteries don't yet have the scale that lifepo4 batteries have. I'd expect we will see them get cheaper.

HDR playback in chrome on KDE works as expected from what I can tell. For GNOME 49.2 it does not, it doesn't get the luminance that it should at this time. 49.3 may fix this.

The post links to this: https://github.com/MCRcortex/nvidium

nvidium is using GL_NV_mesh_shader which is only available for nVIDIA cards. This mod is the only game/mod I know of that uses mesh shaders & is OpenGL. & so the new gl extension will let users of other vendors use the mod if it gets updated to use the new extension.

Sorry it doesn't work for you. I don't have that issue. Gnome looks proper in HDR mode for both HDR and SDR content for me.

GNOME has both color management and color representation protocols implemented. HDR works fine on it

Their GUI is closed-source. If someone wants an easy to use & easy to setup app, may as well use LMStudio, which doesn't try to pretend to be OSS. Or use ramalama which is basically just containerizing LLMs and the relevant bits, pretty damn similar to ollama. Or just go back to "basics" and use llama.cpp or vllm.

Xe2 is superior to current AMD integrated already

I think this is the first blog on JJ that has made me want to use it. The flow seems like it could be quite a bit better than git

It happens on GNOME at the very least, and I would expect every modern platform is the same way.

The proposal has been retracted, but I fully expect 32-bit to be removed in time.

https://discussion.fedoraproject.org/t/f44-change-proposal-d...

Setting this to none should remove that button. "features": { "edit_prediction_provider": "none" }

I'm well aware of this issue. I don't expect windows to look the same to each other. I like that the title bar can have other content in it other than just the app name and the close button.

For that reason alone I avoid Qt apps, as almost none draw their own title bar. Qt apps aren't even consistent among themselves in theming/style, for example the only apps that look in place on KDE are specifically made with KDE in mind.

I don't understand where the "consistency" obsession comes from, all these apps use different tool kits and will look different regardless.

I've found GNOME developers to be pleasant to work with & I enjoy the experience I have with the DE.

They refuse to work with the community. There's also the open question of how they are going to monetize, given that they are a VC-backed company.

Why shouldn't I go with llama.cpp, lmstudio, or ramalama (containers/RH); I will at least know what I am getting with each one.

Ramalama actually contributes quite a bit back to llama.cpp/whipser.cpp (more projects probably), while delivering a solution that works better for me.

https://github.com/ollama/ollama/pull/9650 https://github.com/ollama/ollama/pull/5059

I always thought the "Your Desktop Trying To Sort Its Shit Out" part was a necessary evil, but other platforms don't suffer from this (at least from what I can tell); the state of HDR on Windows is very disappointing, even just adjusting the TF to gamma 2.2 would make it substantially better. Watching all your non hdr content's blacks become gray is terrible. I assume the washed out appearance comes from it giving up on doing SDR->HDR for the desktop.

My brother got an OLED monitor & was telling me how bad his experience was on Windows, & he recently switched to Linux & does not have the issues he was complaining about before. Ofc, downsides to hdr on Linux (no hdr on chromium, hdr on Firefox is unfinished) atm, but the foundation seems better set for it.

I use HDR for general usage, Windows ruins non-HDR content when HDR is enabled due to their choice of sRGB tf. Luckily every Linux DE has chosen to use the gamma 2.2 tf, and looks fine for general usage.

I use a mini-led monitor, and its quite decent, except for starfields, & makes it very usable even in bright conditions, and HDR video still is better in bright conditions than the equivalent SDR video.

https://github.com/dylanraga/win11hdr-srgb-to-gamma2.2-icm

To add, even before SV we've had VHDL which is also strongly typed and has other nice features. But I do still like using SV more than VHDL :3. I'm not wholly convinced of these languages that have been popping up so far.

AMD already has large firmware blobs. Both intel and nvidia have the software side of GPUs figured out.

We do not use vercel. Unfortunate that the experience varies so much.

It's acceptable for me because I (and others on my team) do not have to way 6-7 seconds almost ever, it is nearly instant. On odd occasion changes can take a long time to show up, ~5 seconds, but it seems restarting the server fixes it, so not sure what that is about.

It enables only a small selection of RPM Fusion as your link shows, ofc flathub gets around some of the need for RPM Fusion, like video codecs, as long as everything else your using is a flatpak (and uses the applicable runtimes).