I concur. It is an incredibly stupid practice for an e-commerce portal to distract or burden their users with anything other than the product they're viewing. I'm like, "Buddy, you have a potential paying customer at your doorstep, all you have to do is not insult them and they'll whip out their credit card on the next step."
Anyone reading this purely as a child safety or campaign finance story might miss the broader architectural war happening here. If you zoom out a little, this is the inevitable, scorched-earth retaliation for Apple's ATT rollout from a few years back.
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.
The return of com.getpebble.android.provider.basalt is a very nice development. It revives the legacy plugin ecosystem overnight without requiring original developers (many of whom may be long gone) to push updates. Moving the app store native and switching iOS weather to WebSockets are also solid wins for latency, but I'm most curious about the package ID reclamation.
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?
We have officially reached the logical conclusion of the feature-bloat-to-vulnerability pipeline.
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?"
The persistence strategy described here (mount -t msdos -o rw /dev/fd0 /mnt) combined with a bind mount to home is a nice clever touch for saving space.
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.
>The goal is, that xfwl4 will offer the same functionality and behavior as xfwm4 does...
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?
This is a fantastic result, but I am dying to know how the G.hn chipset creates the bit-loading map on a topology with that many bridge taps. In VDSL2 deployment, any unused extension socket in the house acts as an open-circuited stub, creating signal reflections that notch out specific frequencies (albeit usually killing performance).
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.
>It is possible to use the language server for syntax highlighting. I am not aware of any particularly strong reasons why one would want to (or not want to) do this.
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.
The collapse in IPv4 transfer prices is what caught my eye here, dropping from a ~$55 peak in 2021 to a mean of $22 in early 2026 (figure 12).
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.
The text in that attached screenshot is the key giveaway, "Now that most sellers maintain inventory levels that keep products close to customers..."
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.
It feels strange to be cited this quickly (by gemini) about something so silly. I used Empire State as an example cause I had just been listening to that song by Jay Z :D
A good update. The VIRTIO_NET_F_MTU negotiation has been a roadblock for many guest OS implementations on apple's virtualization stack. The spec is vague enough that linux just does it while openbsd had to explicitly patch in support to handle the hypervisor's hardmtu limit.
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.
That is the traditional textbook yield curve logic, if I'm not wrong? Smaller area = higher probability of a surviving die on a dirty wafer.
But I wonder if the sheer margin on AI silicon basically breaks that rule? If Nvidia can sell a reticle-sized package for 25k-30k USD, they might be perfectly happy paying for a wafer that only yields 30-40% good dies.
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?
I think it is less of a trade and more of a symbiotic capital cycle, if I can call it that?
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.
Calling Nvidia niche feels a bit wild given their status-quo right now, but from a foundry perspective, it seems true. Apple is the anchor tenant that keeps the lights on across 12 different mature and leading-edge fabs.
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?
The funniest part is beyond the typo, the complete lack of physical intuition from the analysts who circulated this. 500,000 tons is roughly the weight of 1.5 Empire State buildings. If your rack busbars weigh more than the structural steel of the facility housing them, you have a geotechnical engineering crisis on your hands. It is wild that we reached a point where financial modeling is so decoupled from physical reality that nobody paused to ask if the floor would collapse.
Incredible! That contributor stat going to 146 people is super validating for the rust ecosystem. considering servo was the original "rewrite it in rust" project that basically birthed the language. Since memory safety is the bottleneck for every other legacy engine right now, is there any reason for embedded devices to keep using stripped-down webkit instead of switching to servo at this point?
Reading this felt like the official obituary for the 90s techno-optimism many of us grew up on.
The "end of history" hangover is real. We went about building the modern stack assuming bad actors were outliers, not state-sponsored standard procedure. But trying to legislate good use into licenses? I don't know how you would realistically implement it and to what extent? That solution implies we have to move toward zero-trust architectures even within open communities.
As an example: formal proofs and compartmentalization are unsexy but they're a solid way we survive the next decade of adversarial noise.
I remember reading a quote somewhere that stuck with me. Paraphrasing, "If the architecture of my code doesn't enforce privacy and resistance to censorship by default, we have to assume it will be weaponized".
I am out of ideas, practical ones, lots sound good on paper and in theory. It's a bit sad tbh. Always curious to hear more on this issue from smarter people.