manbash

> Genie 4 is natively multimodal, enabling audio-like music, ambient noises, and interactive dialogue to be simultaneously generated with the world.

Looks like a hiccup, which created an odd and ambiguous sentence.

This is nice that you're walking them through it but I wonder why you'd need a tablet in the first place, then? It's better to sit with them in front of a monitor with the proper posture and viewing position.

If it's "rust still can't beat... performance-wise", then yeah I guess.

But there are other criteria. The move to rust might've also resolved numerous potential memory-safety bugs in the decoder.

I noticed lately that recent LLMs write very short sentences, sprinkling so many periods over one paragraph. I'm pretty sure that this is some new regression that we're having with new models.

Have you noticed it, too?

> Separately, we shortened packet queues—the lines packets wait in between stages of the pipeline. The queues are there to absorb bursts of traffic. Testing showed that most of that depth went unused, while shorter queues meant less waiting time and less memory overhead.

"lines"? "depth"? I feel like there is some context missing here. What are these terms they refer to?

Indeed this is an odd disclosure and I am not familiar with past posts by them.

Moreover, no CVE is associated with this claimed vulnerability. It's not even stated which Android version or automotive head-unit variant version is affected.

With Firefox, yes. I wouldn't fully trust other browsers to care about my privacy.

> December's headline feature was teaching the planner to push a whole correlated EXISTS subquery down as a single LEFT SEMI JOIN instead of a nested loop with one ClickHouse round trip per outer row. This moved the needle from 3 of 22 TPC-H queries all the way to 12.

LLMs sure love throwing in archaic expressions such as "move the needle". The abrupt contrast in jargons is so unpleasant and keeps throwing me off right in the middle of reading.

> Instead of one row per item with a quantity column, we use one row per sellable unit. An item with 10 units has 10 rows.

> But one row per unit for all inventory would break down at scale—an item with 50,000 units across 10 locations would mean 500,000 rows, and the reserve query would slow as it scans through them. Instead, we maintain a bounded pool of available rows, capped at 1,000 per item/location combination. Reservations consume rows from this pool; a replenishment process refills it from the inventory ledger.

Shouldn't I feel uncomfortable with such approach? It seems to create a backoff (pool) for lowering the chance of having a synchronization issue.

Very nice. Can you elaborate why you chose mTLS authentication vs. SSH as a mean to deploy the policies.

Regarding the docs, the diagrams should really be replaced with something more familiar and readable such as Mermaid (currently it looks like a mixture of ad-hoc ASCII charts).

...but do watch Golden Boy when given the opportunity!

Interesting, but IMHO the title of this post misses the point of the linked page.

> We'll surely avoid scurvy if we all eat an orange.