Apple cost Meta billions by cutting off their data pipeline at the OS level, justifying it with a unilateral privacy moral high ground. Now, Meta is returning the favor. By astroturfing the App Store Accountability Act through digital childhood alliance, Meta is forcing Apple to build, maintain and also bear the legal liability for a wildly complex state-by-state identity verification API.

Gotta give it to Zuck. Standing up a fully-fledged advocacy website 24 hours after domain registration and pushing a bill from a godaddy registration to a signed Utah law in just 77 days is terrifyingly efficient lobbying.

Has anyone else successfully recovered a dormant package name from Google Play recently? I was under the impression that once an original developer account goes inactive, those namespaces were effectively burned forever? Is that an incorrect assumption on my part?

For nearly thirty years, notepad.exe was the gold standard for a "dumb" utility which was a simple, win32-backed buffer for strings that did exactly one thing...display text. An 8.8 CVSS on a utility meant for viewing data is a fundamental failure of the principle of least privilege.

At some point, they need to stop asking "can we add this feature?" and start asking "does this text editor need a network-aware rendering stack?"

I don't know if that's also true for data integrity on physical magnetic media. FAT12 is not a journaling filesystem. On a modern drive, a crash during a write is at best, annoying while on a 3.5" floppy with a 33mhz CPU, a write operation blocks for a perceptible amount of time. If the user hits the power switch or the kernel panics while the heads are moving or the FAT is updating, that disk is gone. The article mentions sync, but sync on a floppy drive is an agonizingly slow operation that users might interrupt.

Given the 253KiB free space constraint, I wonder if a better approach would be treating the free space as a raw block device or a tiny appended partition using a log-structured filesystem designed for slow media (like a stripped down JFFS2 or something), though that might require too many kernel modules.

Has anyone out there experimented with appending a tar archive to the end of the initramfs image inplace for persistence, rather than mounting the raw FAT filesystem? It might be safer to serialize writes only on shutdown, would love more thoughts on this.

I wonder how strictly they interpret behavior here given the architectural divergence?

As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of focus, hence clients can't steal it, they can only request it via xdg-activation. Porting the legacy x11 logic involves the challenge of actually designing a new policy that feels like the old heuristic but operates on wayland's strict authority model.

This leads to my main curiosity regarding the raw responsiveness of xfce. On potato hardware, xfwm4 often feels snappy because it can run as a distinct stacking window manager with the compositor disabled. Wayland, by definition forces compositing. While I am not concerned about rust vs C latency (since smithay compiles to machine code without a GC), I am curious about the mandatory compositing overhead. Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?

If the author is hitting 940 Mbps on a daisy-chain, either the echo cancellation or the frequency diversity on these chips must be lightyears ahead of standard DSLAMs. Does the web interface expose the SNR-per-tone graph? I suspect you would see massive dips where the wiring splits to the other rooms, but the OFDM is just aggressively modulating around them.

Hmm, the strong reason could be latency and layout stability. Tree-sitter parses on the main thread (or a close worker) typically in sub-ms timeframes, ensuring that syntax coloring is synchronous with keystrokes. LSP semantic tokens are asynchronous by design. If you rely solely on LSP for highlighting, you introduce a flash of unstyled content or color-shifting artifacts every time you type, because the round-trip to the server (even a local one) and the subsequent re-tokenization takes longer than the frame budget.

The ideal hygiene could be something like -> tree-sitter provides the high-speed lexical coloring (keywords, punctuation, basic structure) instantly and LSP paints the semantic modifiers (interfaces vs classes, mutable vs const) asynchronously like 200ms later. Relying on LSP for the base layer makes the editor feel sluggish.

This validates my hypothesis that the run-up in 2020–2022 was an artificial scarcity bubble driven largely by hyperscalers. AWS was right up there stockpiling before they shifted their pricing model. Once AWS introduced the hourly charge for public IPv4 addresses (effectively passing the scarcity cost to the consumer), their acquisition pressure vanished. The text notes Amazon stopped announcing almost 15M addresses in Nov 2025. I think they have moved from aggressive accumulation to inventory management.

We are seeing asset stranding in real-time. The market has realized that between the AWS tax and the efficacy of mobile CGNAT, the desperate thirst for public v4 space was not infinite. I'm curious to hear more takes on this.

This looks like a signal that Amazon's fulfillment network has reached a saturation point where the 'distributed cache' model of commingling is no longer necessary for speed. Ten years ago, commingling was a necessary optimization. If seller A (county A) and seller B (county B) both sold the same widget, Amazon treated them as a single distributed liquidity pool to guarantee 2-day prime shipping nationwide without forcing every small seller to split their stock across 10 warehouses.

Now that Amazon has moved to a highly regionalized fulfillment model (where they aggressively penalize sellers who don't have stock distributed across regions), the computational and reputational overhead of commingling outweighs the diminishing returns on shipping speed. For all intents and purposes, they have traded the operational complexity of physical sorting for the software complexity of forcing sellers to manage regional inventory better.

This is a big deal for local development imho. With the raw single-thread performance of the M4/M5 chips, an openbsd guest is arguably the best environment for testing pf configurations or running isolated mail servers (for example). Being able to rely on viogpu without the black-screen-of-death means we can slowly move away from serial console-only installs for quick VMs.

Big kudos to Helg and Stefan!

Apple OTOH operates at consumer electronics price points. They need mature yields (>90%) to make the unit economics of an iPhone work. There's also the binning factor I am curious about. Nvidia can disable 10% of the cores on a defective GPU and sell it as a lower SKU. Does Apple have that same flexibility with a mobile SoC where the thermal or power envelope is so tightly coupled to the battery size?

Nvidia's willingness to pay exorbitant prices for early 2nm wafers subsidizes the R&D and the brutal yield-learning curve for the entire node. But you can't run a sustainable gigafab solely on GPUs...the defect density math is too punishing. You need a high-volume, smaller-die customer (Apple) to come in 18 months later, soak up the remaining 90% of capacity and amortize that depreciation schedule over a decade.

Nvidia is the high-frequency trader hammering the newest node until the arb closes. Stability usually trades at a discount during a boom, but Wei knows the smartphone replacement cycle is the only predictable cash flow. Apple is smart. If the AI capex cycle flattens in late '27 as models hit diminishing returns, does Apple regain pricing power simply by being the only customer that can guarantee wafer commits five years out?

Comments URL: https://news.ycombinator.com/item?id=46628574

Points: 3

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46616992

Points: 3

# Comments: 1