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.
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.
Windows HDR implementation is janky as hell. For months after I got my monitor I couldn't take screenshots because they'd all appear completely blown out, like you cranked the brightness to 300%.
Eventually I did some digging and found there's a setting in Snipping Tool that just... makes screenshots work on HDR displays.
It also seems to add another layer of Your Desktop Trying To Sort Its Shit Out when launching a game that's full screen. Sometimes it's fine, but some games like Balatro will appear fine at first, but then when you quit back to the desktop everything is washed out. Sleeping my PC and waking it back up seems to resolve this.
I recently played through Armored Core VI, and it supports HDR, but whenever I adjust my volume the screen becomes washed out to display the volume slider. Screenshots and recordings also appear washed out in the resulting file.
Agree. Wide gamut and HDR is janky as hell on Windows. I have multi-mon with one SDR and one HDR and that plays havoc with things. But even Microsoft apps aren't updated. I'm pretty certain even Explorer still doesn't support HDR or wide gamut for thumbnails so everything looks either under or oversaturated in the previews. If you open stuff in the default Photos app there is a "flash of content" where it displays it in the wrong profile before it maps it to the correct one, too.
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.
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.
Spade author here :) Coming from a functional programming adjacent background, the VHDL type system leaves a lot to be desired. Not supporting types with generics means you can't encode things like a genral purpose ready/valid stream. When you have those, you can start using methods to compose those streams which becomes even more powerful when you add higher order functions which allow you to transform the content of the stream without worrying about the stream details.
NVIDIA's blobs are different when compared to others. They do not want to give away how their GPU clocking and enablement works. As a result, NVIDIA's blobs are both signed and picky about "who" they communicate with. You can't use the NVIDIA's full fledged firmware with nouveau for example.
On the other hand, the card enablement sequences are open for AMD and Intel. AMD only protects card's thermal and fan configuration data to preventing card damage, AFAIK. You can clock the card and use its power management features the way you like. For NVIDIA, even they are out of reach.
AMD's open drivers work way better than NVIDIA's closed ones, too. I have never seen how a single application refused to launch until I used NVIDIA closed drivers.
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.
I had the same experience of slow refreshes on the NextJS project I worked on (running locally) and the other seasoned NextJS developers didn't think it was unusual.
Moving between distros I usually just have files I care about like documents and music on their own drive so I don't need to worry about moving them. As for moving from Ubuntu to Fedora, there are more steps to getting non-free software/codecs/drivers working on Fedora, you will need RPM Fusion for that. There are relevant How-Tos provided by RPM Fusion and other sources for installing NVIDIA drivers, ffmpeg (non-free), and more.
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).
Having all my actual files separately stored from my system files just makes so much sense. Good call. Right now they're mostly relegated to a few directories, but I'm not positive, which is part of the headache I'm worried about with a switch. Having them completely separate and symlinked is a great call.
I've been using Fedora 42 since it branched, it has been quite nice; I haven't encountered any breaking bugs with it. Has gnome 48 which comes with HDR support. Hope that chromium can get support for it soon, MPV can already do it apparently, but haven't tried it; games have been hit & miss for it, but I presume those will get ironed out over time.
This used to be true, but they have been focusing very heavily on services, and on ads to a lesser degree for quite a few years to pursue greater profits. & It's clear that this trend will not stop.
Hard to say why the density is that different, if those transistor numbers are accurate. A less dense design would allow for higher clocking, & while the clocks are fairly high, they aren't that far out there, but that's one factor (I'd hope they wouldn't trade half the area for a few extra MHz, when a gpu w/ 2x the tr will just be better).
It could also be in addition that the # of transistors that each company provides is different as they may count them differently (but I'm not convinced of this).
Customers pay by the wafer, so mm^2; though tr cost is a function of that so :3 .
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