I had a similar usecase and also struggled with supported devices. Ended up grabbing some Yepkit switchable hubs (aka YKUSH), they work great, but a tad on the pricey side.
Interesting, I guess we've been doing it wrong this whole time, as we do `fix(ABC-123): some message here`, which ends up being linked great, renders very nicely into the automated release notes, etc.
There's an interesting subset of Windows machines out there running in "S" mode [1]. This mode restricts the customer to only using applications from the Windows Store.
We get occasional support tickets about the popups that come when trying to run a regular installer while in this mode. Luckily, people can disable "S" mode, but there's no way to re-enable "S" mode without a fresh install.
This model does not fit in 12G of VRAM - even the smallest quant is unlikely to fit. However, portions can be offloaded to regular RAM / CPU with a performance hit.
I would recommend trying llama.cpp's llama-server with models of increasing size until you hit the best quality / speed tradeoff with your hardware that you're willing to accept.
The I-prefix stands for Imatrix smoothing in the quantization. It trades a little more accuracy for speed than other quant styles. The _0 and _1 quants are older, simpler quants that are very accurate but kinda slow. The K quants, in my limited understanding, primarily quantize at the specified bit depth, but will bump certain important areas higher, and less used parts lower. It generally performs better while providing similar accuracy to the _1 quants. MXFP4 is specific to Nvidia, so I can't use it on my AMD hardware. It's supposed to be very efficient. The UD part includes more of Unsloth's speed optimizations.
Also, depending on how much regular system RAM you have, you can offload mixture-of-expert models like this, keeping only the most important layers on your GPU. This may let you use larger, more accurate quants. That is functionality that is supported by llama.cpp and other frameworks and is worth looking into how to do.
I did this as well when the previous Nova launcher news came out. It took maybe a day to get used to, but I like it much more now - I have nothing to organize, I just access what I want to use instead. It feels natural.
Since this is about DO managed Postgres: if you're using it with replicas, they use async replication and RPO can be greater than 15 minutes. Since failover is triggered during upgrades, there ends up being a lot of periods where you can lose multiple minutes of committed data.
Do they at least allow you to set your own schedule for upgrade windows? That way you could schedule them for quiet times of day, minimising the likelihood of there being significant replica lag.
It's common to do this on AWS and the other hyperscale providers (though, of course, they tend to do synchronous replication anyway, meaning that this particular failure mode wouldn't apply) - upgrades are a common source of unforeseen issues, so it makes sense to minimise the potential blast radius by running them out of hours.
I'd love a referral to your certificate authority and rep - we go through a big kerfluffle each renewal period, only eventually receiving the certificate after a long exchange of government docs and CPA letters. For us, only the last step is the phonecall like you say.
This exchange seemingly proves the argument that user trust gained from the EV treatment is misplaced, and that the endeavor was a farce all along. It's not as though the user's browser was distinguishing the good CAs from the bad!
I disagree. I specifically said in my original comment they were very useful for those that knew what EV certs were and EV certs weren't.
You may not know that Digicert is a quality CA who wasn't going to risk their position as a CA to sign an EV cert for a typo squatting phishing site pretending to be PayPal but there are those who do. The green UI in chrome & firefox made finding all of this information out incredibly simple and obvious.
