Durable consensus means this is waiting for confirmed write to disk on a majority of nodes, it will always be much slower than the time it takes a NIC to put bits on the wire. That's the price of durability until someone figures out a more efficient way.
Remote start isn't a luxury feature unless you also classify remote unlock as a feature. Toyota (and many manufacturers) used to use the key fob to also start the car but they disabled that so they could charge for it as part of the subscription.
My point was you can buy a car that is primarily safety+capability and not luxury+subscription. My rav4 has a touchscreen and power windows but that’s literally it as far as convenience/luxury. ~28k a couple years ago, no subscription.
Anything heated, remote, touch to start, etc is in the luxury category what gp was asking about avoiding.
This comment section went from “I don’t understand why car makers don’t sell a cheap stripped down car without luxuries” to “Heated mirrors and seats are very important” very quickly.
HN comments discovering in real time why the stripped-down base model vehicles don’t actually sell. People like those luxury features and they choose to pay extra for them.
Once you start looking at the world through the lens of frequency domain a lot of neat tricks become simple. I have some demo code that uses fourier transform on webcam video to read a heartrate off a person's face, basically looking for what frequency holds peak energy.
It's effectively the underpinning of all modern lossy compression algorithms. The DCT which underlies codecs like Jpeg, h264, mp3, is really just a modified FFT.
Inter/intra-prediction is more important than the DCT. H264 and later use simpler degenerate forms of it because that's good enough and they can define it with bitwise accuracy.
>Once you start looking at the world through the lens of frequency domain a lot of neat tricks become simple.
Not the first time I've heard this on HN. I remember a user commenting once that it was one of the few perspective shifts in his life that completely turned things upside down professionally.
My dumb ass sat there for a good bit looking at the example in the first link thinking "How does a 30-60 Hz webcam have enough samples per cycle to know it's 77 BPM?". Then it finally clicked in my head beats per minute are indeed not to be conflated with beats per second... :).
I befriended the guy in high school who built a Tesla coil. For his next trick he was building a laser to read sound off of plate glass. The decoder was basically an AM radio. Which high school me found slightly disappointing.
I basically asked my math and physics teachers in high school what the Fourier transform was, but none of them knew how to answer my questions (which were about digital signal processing -- modems were important things to us back in the early '90s). If I had to do it over again, I would have audited the local university's electrical engineering and math courses in evenings. The first time MIT ran 6002x online back in 2012, the course finally answered a lot of those questions when touching upon filters and bandwidth.
Yeah I wish I had known about or had access to that stuff when I was a kid. To really learn and internalize ideas like negative frequency early would have been quite fun.
It is, I've done it live on a laptop and via the front camera of a phone. I actually wrote this thing twice, once in Swift a few years back, and then again in Python more recently because I wanted to remember the details of how to do it. Since a few people seem surprised this is feasible maybe it's worth posting the code somewhere.
It is, but there's a lot of noise on top of it (in fact, the noise is kind of necessary to avoid it being 'flattened out' and disappearing). The fact that it covers a lot pixels and is relatively low bandwidth is what allows for this kind of magic trick.
The frequency resolution must be pretty bad though. You need 1 minute of samples for a resolution of 1/60 Hz. Hopefully the heartrate is staying constant during that minute.
I've followed the research a little bit. The general sense I get is that, specifically vehicle control at the edge of traction, software in the lab has far outperformed normal humans for over a decade. The problem is that delivering the "boring" point A to B reliably in all conditions is still unsolved. Relative safety is also a moving target because all the advances in the first bucket are directly applicable to human-driven cars as driver aids.
Yeah, my non-autonomous Toyota can already see the lane lines better than me in the rain. However, that's not too beneficial when no other driver can see the lanes and everyone is just driving to not crash into each other.
It gets real hard when the entire road surface is covered with snow for weeks at a time (like after small 1" snowfalls that might not get cleared immediately like a heavy snow would). Or when snow buildup on the road edges change road edge location and cars parked on the side project well into the "nominal" GPS derived lanes. Lanes which human drivers won't be using. They'll be using emergent lanes defined by flocking behavior. I haven't seen any evidence that autonomous vehicles can detect or navigate such emergent, non-marked except by tracks and human gut feeling lanes.
Being "better" than human in these situations will cause crashes. The real goal is to drive like a human.
They pitch their company as finding bugs "with AI". It's not hard to point one of the coding agents at a repo URL and have it find bugs even in code that's been in the wild for a long time, looking at their list that looks likely to be what they're doing.
The list is pretty short though for 8 months. ossfuzz has found a lot more even with the fuzzers often not covering a lot of the code base.
Manually paying people to write fuzzers by hand would yield a lot more and be less expensive than data centers and burning money, but who wants to pay people in 2026?
It does not matter what purported categories buffer overflows are in when manual fuzzing finds 100 and "AI" finds 5.
If Google gave open source projects $100,000 per year for a competent QA person, it would cost less than this "AI" money straw fire and produce better results. Maybe the QA person would also find the 5 "AI" detected bugs.
This would make sense if every memory corruption vulnerability was equivalently exploitable, which is of course not true. I think you'll find Google does in fact fuzz ffmpeg, though.
Google gives a pittance even for full ossfuzz integration. Which is why many projects just have the bare minimum fuzz tests. My original point was that even with these bare minimum tests ossfuzz has found way more than "AI" has.
Another weird assumption you've got here is that fuzzing outcomes scale linearly with funding, which, no. Further, the field of factory-scale fuzzing and triage is one Google security engineers basically invented, so it's especially odd to hold Google out as a bad actor here.
At any rate, Google didn't employ "AI" to find this vulnerability, and Google fuzzing probably wouldn't have outcompeted these researchers for this particular bug (totally different methods of bugfinding), so it's really hard to find a coherent point you'd be making about "fuzzers", "AI", and "Google" here.
My guess is the main "AI" contribution here is to automate some of the work around the actual fuzzing. Setting up the test environment and harness, reading the code + commit history + published vulns for similar projects, identifying likely trouble spots, gathering seed data, writing scripts to generate more seed data reaching the identified trouble spots, adding instrumentation to the target to detect conditions ASan etc don't, writing PoC code, writing draft patches... That's a lot of labor and the coding agents can do a mediocre job of all of it for the cost of compute.
For sure, and I think it expands the scope of what factory scale efforts can find. The big question of course being how to handle remediation because more bugs without more maintainer capacity is a recipe for tears.
I can't speak to what exactly this team is doing but I haven't seen any evidence that with-robot finds less bugs than without-robot. I do have some experience in this area.
FWIW I have some background in this area and got curious how Meshtastic works so I read some of the docs and code. It seems like they are unaware of existing work even 20+ years ago, a specific suggestion is to study the state of single radio CSMA meshes in say 2005 and make a list of subjects to read on, then do that. There's a lot of stuff that happened later but in the early 2000s many people tried to make meshes out of 802.11b IBSS and a lot got written about those efforts.
I haven't tried it yet, but yes. Qwen3 Next 80B works decently in my testing, and fast. I had mixed results with the new Nemotron, but it and the new Qwen models are both very fast to run.
Same experience: on my old M2 Mac with just 32B of memory both Qwen 3 30B and the new Nemotron models are very useful for coding if I prepare a one-shot prompt with directions and relevant code. I don’t like them for agentic coding tools. I have mentioned this elsewhere: it is deeply satisfying to mix local model use with commercial APIs and services.
There are challenges with really big monolithic caches. IBM does something sort of like your idea in their Power and Telum chips, with different approaches. Power has a non-uniform cache within each die, Telum has a way to stitch together cache even across sockets (!).
reply