entrope

2048-bit RSA gives something like 28 more bits of security than 1024-bit RSA has, so it would take about 250 million times as long to factor one 2048-bit key.

> This time the glitch was 33 feet, who's to say next time it couldn't be 3300 feet?

People who study this. This glitch was caused by unusual, structured, widespread distortions in the ionosphere. There's no known mechanism that would cause enough distortion to make the errors 100 times as large. There would also be other symptoms of any unknown cause.

https://claude.ai/share/5cc4163e-9cbf-47cd-9749-4bb55bca42fe if you don't mind discursions into safety of aviation navigation systems. Caution: Do not take the error bounds in the second half as relevant to errors for unaugmented single-frequency users; those users will see much bigger errors.

M-Code is a new encrypted signal that is not fully operational yet. OCX was supposed to enable it.

GPS has always had the P(Y) code, which is an encrypted signal, at a higher chip rate than the C/A code that has been broadcast on L1 forever. The P(Y) code has its own interesting history of (semi-)codeless processing. If the US military is lucky, the history books will close on that by 2030: https://www.gps.gov/codelesssemi-codeless-gps-access-commitm... . (Currently, 21 GPS satellites broadcast L5.)

To meet its integrity budget, a GBAS needs at least triple redundancy, not just a single station.

If one has a lot of patience, one can read the details of how it works at https://elibrary.icao.int/product/299828 (along with SBAS, the ICAO name for what WAAS does; the constellations they can augment; GRAS, a weird hybrid between GBAS and SBAS that apparently went nowhere; ILS; VOR; DME; and VHF marker beacons). Annex 10 Vol I probably doesn't say explicitly that triple redundancy is required, because if you had a single receiver with an MTBF of something like 10 billion hours then you could use just that one.

This particular 30-foot error should go away almost entirely for future receivers that implement DFMC SBAS or ARAIM.

Yes. WAAS should also help a lot, or at least tell you that you can't get a good position.

No (current) mention of weights being released, so apparently not.

This article describes what is usually called a Pareto frontier: the best known achievable trade-offs between two (or more) optimization goals. "Efficient frontier" in common usage seems to be specifically a Pareto frontier for financial risk versus return of an investment portfolio. Even outside of finance, points on a Pareto frontier are called Pareto optimal or Pareto efficient. A Pareto frontier is sometimes shown with more than two dimensions, although usually people will pick just two for simplicity.

Within LLMs, and even inference naturally, there are many other potential parameters that one might optimize: Unsloth typically shows a Pareto frontier for size of a quantized model versus KL divergence. Others trade total concurrent tok/s against single-stream tok/s. KV cache size, context length and context coherency are other trade-offs that are closely related to inference. Total intelligence is usually a defining characteristic of a "frontier model", with cost (per token or task) as a salient trade-off. Cost is one parameter that is implicitly fixed by the "throughput versus latency" analysis: using a GB300 versus Radeon R9700 moves the curve enormously and probably changes the shape of it. Lots of threads here argue over local vs cloud inference regarding cost efficiency, often with privacy and control as competing objectives.

A decade ago, I worked on a simulation program that involved a C++ core with a Python wrapper and DB interface. End users cared a lot about throughout with a rather limited size, weight and power budget. We spent a lot of time optimizing the core -- but basically hit a bottleneck once we got to about 15% of the time that was spent in malloc-related functions. It turned out that was all in the Python layer. Probably there was some level of bad code in our Python code, but it was impractical to figure out where that was. I was shocked because I assumed the simulation core (which ended up almost allocation-free by the end) would always dominate CPU usage.

Both allocators and Python have probably gotten better since then, but it was a fascinatingly large and stubborn fraction of CPU time.

My guess is that it's not complete or stable or qualified enough for them to publish it as a supported feature. Maybe the power draw is too high and it triggers thermal throttling too quickly, similar to early Intel AVX-512? Maybe they are still sorting out how to have each process choose SVE vs NEON mode, so libraries using the other one don't cause a fault? (Note that this seems limited to M4 and newer CPUs.)

I agree this is an important feature. I have very often wished that my Mac had wider vectors.

No, they use the same definition of memory bandwidth as others, but Apple Silicon has a lot of memory channels. In previous generations, prefill has been compute-limited and decode is fast.

https://blog.exolabs.net/nvidia-dgx-spark/ outlines a combination of a DGX Spark and an M3 Ultra that took advantage of fast prefill on the Nvidia hardware and fast decode on Apple Silicon.

It takes almost 8 years for $3.25/mo of electricity savings to break even with a $300 difference in up front cost. Assuming the time value of money is zero, that is.

Usually, the exposure limit is based on an active phone next to an ear. RF field strength falls off with the square of distance, so a phone on each side of your head is most dangerous to the respective ear and bits of your brain close to your skull; each phone is considered acceptably safe to the middle of your brain and the opposite ear.

Is it that impressive? It is a model generating short strings from scratch, so I do not think there is significant token parsing or memory allocation going on.

In compute performance, 10M tok/s * 4096 parameter/tok * 4 byte/param = ~160 GiB/sec implied memory bandwidth, vs nominal ~300 GB/sec for the M5 Pro's RAM. That seems even less notable once we consider that 4096 parameter * 4 byte/param = 16 KiB of parameters fit easily within L1 data cache (the M5's efficiency cores each have 64 KiB of L1 data cache). 40 GFLOPs means ~10 FLOP/cycle, about 2.5 NEON instructions per cycle given that the core instructions are fused multiply-adds (FMAs). A random web page I found says the M5 family cores have a 4-wide SIMD block, meaning this gets about 63% utilization: respectable but not super high.

Yes, but their "run rate" assumes the current level continues unchanged, right? If revenue per month goes down then the projected run rate is optimistic. However, revenue has been increasing, so the reported run rates have underestimated revenue.

I think the better question is how much more than $65B/year revenue they need to cover what they are spending on capex and model development. I would bet money their revenue in the next year is over $75B (vs $65B), but also that their amortized costs exceed their revenue.

"Latent" means it (the space) is there all the time but usually not exposed or apparent. Latent space is a high-dimensional space that is not legible to humans, so normally reasoning gets constrained to progress in tokens instead so that it can be evaluated.

I think https://arxiv.org/abs/2412.06769 is a good description of the premise of reasoning in latent space, although https://arxiv.org/abs/2604.15726 argues it's already what really happens.

Yes, it's notable that they mean "production" in the sense of 40 vehicles rather than 40 models or model variants. It's close to prototype quantities rather than production; US law allows the military to build up to 10% as part of "low rate initial production".

Yes, this. At work, I have side-by-side 32" 4K monitors. At home, I have a 59" curved 7680x2160 monitor that is the same size as the two work monitors combined. My home setup is much more ergonomic than work. Beyond your point about angles being bad with two monitors, pretty often I have three things open that are wider than 1920 pixels worth of content. At home, each can be 2560 pixels wide. At work, I can either have bezels in the middle of one or shrink two of them. And the fairly aggressive curve at home means pixels are close to the same angular size.

Depends on the source and what you're trying to exercise. M-Code and spot beams are supposed to provide something like 20 dB of jamming resistance, and if your jammer is not right next to the target then the jamming could be a factor a long way off. (For reference, a target 40 miles from a jammer would see ~20 dB more interference than a target 400 miles away. White Sands Missile Range is 3200 square miles, but much longer north-south than east-west.)

I don't think attitudes have changed on that. The last PM on my current project (in aircraft navigation) was a pilot, and he always stressed that a pilot in charge should have alternatives planned for destination and means of navigation.

WSMR does enough GPS jamming that I'm surprised these pilots didn't have more experience with, or at least expectation of, it happening.

100 ms might be a good threshold for a lot of purposes, but for when refresh, 30 fps is painful to use compared to 60 fps: it is extremely noticeable when moving windows, but I'm old and can tell the difference even just moving the cursor. (Others will say the same about 60 fps compared to 120 or 144 fps.)

I think ripgrep does avoid allocations in that innermost loop. That's why this report says all the crashes are associated with opendir() and its memory allocation: the opendir() call is outside of ripgrep's innermost loop but still runs often enough to trigger the race condition.

It got arm-waved to a race condition in munmap(). Claude (or a distill of Claude) didn't identify a race, it just convinced itself that was the cause.

I understand all the words in it and follow the argument, but it's still bullshit in the technical sense of being written by someone who wants to sound authoritative but doesn't ultimately care if they are right or wrong.

The write-up should have been about five paragraphs: (1) "The script at https://... generates a tree with X million files taking 20 GB total. Running ripgrep 1.2.34, compiled with musl, on my Threadripper 9876 as 'rg ...' crashes about a fourth of the time. With glibc, it does not crash." (2) "This appears to be a bug introduced by commit abcdef1234 in some_vm_call() that allows a race between [...] such that user space can see a corrupt whatever." (3) "The sequence of operations that causes this is: (show two or more kernel threads with lines interleaved to explain the bug)". (4) and (5) as needed to elaborate on those three core points.

But the actual post is long on (fluent) speculation and short on reference to actual code. That's a large part of why it's offensive slop.

> It’s the kernel. Nothing a user space library can do should ever be able to call this.

I don't follow. An application might see this kind of crash if it has a bug causing it to access a page while another thread is mapping or unmapping that page. That would be a bug in mallocng, musl or ripgrep. Or, as someone else mentioned, it could be bug in the processor's virtual memory logic that has the same effect. Why do you say it can only be a kernel bug?

The ISO C definition of opendir() requires an allocation in practice because it returns a DIR* and it's bad practice for the library to arbitrarily limit how many of those an application has at a time.

Maybe a C library could preallocate several DIRs and only use the heap when those are exhausted, but this ripgrep use case (lots of threads running in parallel on a large tree) would still be likely to trigger that.

As long as the hardware can be used on newer models, hardware costs can be recouped running a future model.

But if they're hoping to recoup non-recurring engineering costs rather than just hardware costs, they do need to consider the useful lifetime of the specific model.

That's one of the nice features of jj: instead of having an index, the working tree is its own commit, and it tracks the history of that when you run most jj commands.

This works because each commit gets a "change id" assigned that only changes when you say. When you create a new commit, edit its commit message, and edit files, you end up with three git commits with the same change id, but two of the git commits will be gc'ed eventually. (The change id is what you normally use to identify what's in the git commit graph.)

So even if you issue a command that destroys overwrite some important changes, jj has a good chance of remembering your worktree state.

Not in every case. I would call (in the US) National Public Radio "public media", but Voice of America "government-run".

I personally don't know enough about BBC or France 24 to go beyond "government-funded", so I would want more details about their governance before using the terms mentioned before to describe them.

It means entering a personal identification number (PIN) as an authentication step.

Base 4 isn't substantially different from base 2 except in granularity.

There's a somewhat famous result that base e gives the best expected density for representing numbers, but fractional (and especially irrational) bases are inconvenient for real-world quantities. So ternary is theoretically the best integer choice, but binary has practical advantages for electronic logic.