This is bullshit on par with the Chinese firewall, meant to effectively prevent the (entire!) western world from information by parties deemed persona non-grata. SSL certificates are supposed to be about security, not geopolitics.

I'm pretty sure a LE server hitting an Iranian or North Korean endpoint and validating a crypto challenge does not break any OFAC or EAR rules, and no money changes hands. And if a non-US entity wants to do it, the US would just sanction them. Microsoft and Mozilla are certainly not going to include a North Korean or Russian state CA in the root trusted certs (and if they did, the US government could just threaten them with sanctions, too).

Hard not to say "we warned you" about making self-signed certs completely unusable in favor of a very centralized approach.

I used Gemini exclusively via the API but downloaded the app last week for something. Even on max settings, it is ridiculously nerfed!

Unfortunately, even the API variant got RLHF'd pretty hard into being that dumb end-user assistant personality :(

But beside that, I feel like the app variant got worse the day they've had that wwdc-style release thing recently.

Previously it was a sparring partner that could actually keep up. But now it just doesn't.

Truly a shame. And nothing that could be fixed by local models any time soon, given that you need the size for the (cross-)domain knowledge.

It's saying it's better than naively truncating the QAT release to 4 bits.

I'm not surprised Chen's patch was rejected; that's an extremely niche usecase not worth supporting. With my shell developer hat on, I agree with the closing "developers would likely welcome a native implementation that isn't (unlike the current implementation) hiding fork() and exec() under the covers".

It sounds like they're interested in the concept though, just not that specific implementation.

Yeah this seems like a promising discussion.

It has been for decades at this point. thiago's blog posts which introduced me to the topic over a decade ago (and is still one of the best explainers) points out that posix_spawn was introduced in POSIX.1-2001: https://web.archive.org/web/20120718152158/http://www.maciei...

Yeah fair enough.

How were you getting anything useful out of that? We found the (unquantized!) E2B model to be completely useless at even the simplest real-world classification tasks.

So what we want now is unsloth (or anyone) to release 4/6-bit quantized models of these releases?

Yep, Unsloth already did, as linked in the comment at the top of this thread

ADBC: https://arrow.apache.org/docs/format/ADBC.html

Seems like a columnar version of ODBC, for OLAP instead of OLTP.

Quite aside from the architectural changes, I suppose this is the answer to why Google had such a glaring hole in the (pretrained) Gemma4 model lineup between the Gemma4 4b and Gemma4 26b models!

A model that comfortably fits in 16GB of VRAM (allowing room for context) is a welcome upgrade.

I’m not sure I agree? For each of your examples there are algorithmic approaches and neural network approaches. Companies have certainly been loose and wild with how they market these, but there remain distinct approaches and implementations for each. Very generally speaking, the neural network based approaches (aka “generative AI”) perform better but with much worse degenerative cases and a higher baseline rate of unwanted side effects (that are normally not immediately visible but tend to cause issues down the line).

My bigger concern is that these neural network based solutions have taken the place of the former rather than supplemented them. Many tools no longer provide the algorithmic/kernel-based approach at all, and have marketed the “AI” (née ML) alternative as a strict superset/upgrade, despite its potential drawbacks.

(Interestingly while the inference-based implementations generally have higher latency (or infinitely worse, cloud and pay-as-you-go requirements), for some computationally difficult kernels the inference-based approach is actually faster!