tgtweak

The cameras on the Pro versions used to be so good, then starting around one-plus 9 they really went downhill. I have photos in my archive from my OP8 Pro that look much better than those taken with the OP13.

Coinciding with Samsung nerfing the Ultra (aside from the bloatware) - it's not looking like a great landscape for Android Phones.

I think given how much benchmaxxing we're seeing - the anecdotal evidence of how competent this model is (and efficient) will depend on user's actual real-world use cases.

Given the pricing, it suggests that this model is much more efficient/competent than previous-gen OS/distilled models.

None of this is surprising - they're trying to mask and relay when they detect known patterns of what looks like distillation attacks and client app copying/modification. The list obfuscation here is likely to prevent or make it difficult for those same adversaries to work around this or delete/null it out when making a bootleg copy.

Cool reverse engineering/analysis report but if this is the extent of nefarious activity that came of it (trying to catch/mitigate chinese lab model distillations), that's kind of encouraging.

I feel like a clean room opensource keyboard could implement those without any patent liabilities. Software patents are notoriously difficult to enforce and I don't think nuance is spending any money enforcing this given they stopped swype in 2018.

swype was so good before it got destroyed by Nuance. Gboard's own swipe to type is decent but missing a lot of those features that made swype so much better (swipe once backwards to erase the previous word, loop a letter to double it, swipe up to the suggested word to select it, correct a previous word with the next few words context...)

It's the same for all the gambling platforms - they give creators and influencers privileged accounts that win more than they lose so when they stream it looks like they're not losing constantly.

Nuclear also works well with grid batteries to smooth demand curves, which Ontario is targeting 2700MW of scale by 2030.

Not a decision that users are aware of though. Nor is there a setting to disable/change it. It just showed up one day and erased your previous sessions.

Slightly better than the claude code "feature" that deletes all your session context and transcripts older than 30 days old.

This is a failure of malware flagging systems as well - VT should not return clean if there are any downstream files that are malicious - such as in this case.

Implying that google's "snippets" were never curated to remove anti-google facts or that they didn't curate the search results in their favor...

It'll be replaced by a new react app within a few hires lol

It's a disruption game - releasing competent open models disrupts smaller labs trying to release their own or commercialize their own. It's a similar rationale behind the Chinese labs releasing near-frontier open-weighted models, the goal is to disrupt and lift the barrier of entry for would-be competitors.

I think you can definitely improve the throughput/iops by using BAR vs treating it like a file store/mount through cuda which adds a lot of overhead.

Critically, it was the webhook/sync that was down which really messed with a lot of external systems (nosto, klaviyo, 3PLs...)

Is anyone using haiku 4.5?

Why not showcase it against something in a similar domain like qwen3.6 or gemma 4?

It may work - depending on your ram speeds it might not even be that much slower.

I feel like, if it was a codebase without using any security analysis tools, there would have been some more significant findings - perhaps they can re-run it on an 18 month old commit and see how many it found that were subsequenty found and fixed?

Anyway, I think the case that frontier and next-gen models will get increasingly adept at finding vulnerabilities and that those on the receiving end of those vulnerabilities need to be on top of it.

Cloudflare expects second-quarter revenue of $664 million to $665 million, just under analysts' estimate of $665.3 million

Is this considered below expectations on wallstreet... enough to merit an 18% stock cut?

You can definitely add some telemetry to this that records and analyzes realtime location to "map" the litter, even when using a device like this. The conveyor actually seems very well suited to an external camera that records and analyzes the mess to a degree that should be suitable for the purpose of "recording" litter types and concentrations based on the location, without resorting to manual sweep/dust bins which actually sounds pretty insane at this scale.

When RAM and an SSD cost more than an entire system used to it's not surprising to see this.

Depends entirely on quantization. Q6_K with max context length (262144) is ~40GB of VRAM.

Q8 with the same context wouldn't fit in 48GB of VRAM, it did with 128k of context.

I've been using it in a few harnesses (FP8 quant, max context length) and it does seem to get tripped up by tool use, often repeating the same tool when it failed previously - that's usually not a great sign for long-term context and multi-step reasoning. It is excellent at one-shotting though and might be most useful as a sub-agent for a stronger frontier coordinator.

If you run it in qemu, all good.

Was honestly thinking "yeah nice Google, now do it for Android" since the worst offenders are apps (looking at you, Tiktok)

There is a huge market for "its faster" at the cost of efficiency, but I don't think your claim that an EML hardware block would be inherently less inefficient than the same workload running on a GPU. If you think it would be, back it up with some numbers.

A 10-stage EML pipeline would be about the size of an avx-512 instruction block on a modern CPU, in the realm of ~0.1mm2 on a 5nm process node (collectively including the FMA units behind it), at it's entirety about 1% of the CPU die. None of this suggests that even a ~500 wide 10-stage EML pipeline would be consuming anywhere near the power of a modern datacenter GPU (which wastes a lot of it's energy moving things from memory to ALU to shader core...).

Not sure if you're arguing from a hypothetical position or practical one but you seem to be narrowing your argument to "well for simple math it's less efficient" but that's not the argument being made at all.

For basic arithmetic, this is not required nor would it be faster, as it is not likely advantageous for bulk static transcendal functions. Where this becomes interesting is when combining them OR when chaining them where today they must come back out to the main process for reconfiguration and then re-issued.

Practical terms: Jacobian (heavily used in weather and combustion simulation): The transcendental calls, mostly exp(-E_a/RT), are the actual clock-cycle bottleneck. The GPU's SFU computes one exp2 at a time per SM. The ALU then has to convert it (exp(x) = exp2(x × log2(e))), multiply by the pre-exponential factor, and accumulate partial derivatives. It's a long serial chain for each reaction rate.

The core of this is the Arrhenius rate, (A × T^n × exp(-E_a/(R×T))), which involves an exponentiation, a division, a multiplication, and an exponential. On a GPU, that's multiple SFU calls chained with ALU ops. In an EML tree, the whole expression compiles to a single tree that flows through the pipeline in one pass.

GPU (PreJacGPU) is currently the state of the art for speed on these simulations - a moderate width 8-depth EML machine could process a very complex Jacobian as fast as the gpu can evaluate one exp(). Even on a sub-optimal 250mhz FPGA, an entire 50x50 Jacobian would be about 3.5 microseconds vs 50 microseconds PER Jacobian on an A100.

If you put that same logic path into an ASIC, you'd be about 20x the fPGA's speed - in the nanoseconds per round. And this is not like you're building one function into an ASIC it's general purpose. You just feed it a compiled tree configuration and run your data through it.

For anything like linear algebra math, which is also used here, you'd delegate that to the dedicated math functions on the processor - it wouldn't make sense to do those in this.

I actually don't think this is true -

Traditional processors, even highly dedicated ones like TMUs in gpus, still require being preconfigured substantially in order to switch between sin/cos/exp2/log2 function calls, whereas a silicon implementation of an 8-layer EML machine could do that by passing a single config byte along with the inputs. If you had a 512-wide pipeline of EML logic blocks in modern silicon (say 5nm), you could get around 1 trillion elementary function evaluations per second on 2.5ghz chip. Compare this with a 96 core zen5 server CPU with AVX-512 which can do about 50-100 billion scalar-equivalent evaluations per second across all cores only for one specific unchanging function.

Take the fastest current math processors: TMUs on a modern gpu: it can calculate sin OR cos OR exp2 OR log2 in 1 cycle per shader unit... but that is ONLY for those elementary functions and ONLY if they don't change - changing the function being called incurs a huge cycle hit, and chaining the calculations also incurs latency hits. An EML coprocessor could do arcsinh(x² + ln(y)) in the same hardware block, with the same latency as a modern cpu can do a single FMA instruction.

You could also make an analog EML circuit in theory, using electrical primitives that have been around since the 60s. You could build a simple EML evaluator on a breadboard. Things like trig functions would be hard to reproduce, but you could technically evaluate output in electrical realtime (the time it takes the electrical signal to travel though these 8-10 analog amplifier stages).

Yes actually, it is very regular which usually lends itself to silicon implementations - the paper event talks about this briefly.

I think the bigger question is whether it will be more energy-optimal or silicon density-optimal than math libraries that are currently baked into these processors (FPUs).

There are also some edge cases "exp(exp(x))" and infinities that seem to result in something akin to "division by zero" where you need more than standard floating-point representations to compute - but these edge cases seem like compiler workarounds vs silicon issues.