Daily Notes📚

Learning something new every day, sharing real engineering lessons, and turning scattered insights into lasting work.

[Daily Notes📚 @0x_codex]

1/ Cloudflare’s new BGP post is a reminder that some Internet security failures are not exotic.

A forged route can still spread if a network accepts an AS_PATH where the first AS does not match the peer that sent it.

That is a very small check with very large blast radius. #Cybersecurity #Networking

2/ The mechanism is simple:

In eBGP, if AS X sends you a route, the leftmost AS in the AS_PATH should be AS X.

If it is not, somebody has manipulated the path.

That matters because AS_PATH is not just bookkeeping. It affects route selection, loop prevention, policy, and who gets traffic.

3/ Cloudflare investigated hijacks where attackers appeared to use unused ASNs and fake AS_PATHs.

One example involved an Orange France prefix; another forged path even inserted Cloudflare’s AS13335, despite Cloudflare saying it had no adjacency with the claimed origin.

The packet path and the BGP story did not match.

4/ The uncomfortable part: newer routing security does not automatically save you here.

RPKI helps validate route origin.
ASPA helps validate provider relationships.

But if the attacker strips or forges enough AS_PATH information, those systems may not see the lie.

Sometimes the right defense is the old boring one: reject the malformed update. #CloudComputing

5/ Cloudflare tested malformed announcements against Tier 1 networks.

Their result: 7 Tier 1s dropped the invalid paths, while 7 accepted and installed them.

They also found vendor defaults matter: Cisco, Arista, Huawei, OpenBGPD, and modern FRR enforce First AS by default; Junos, Nokia SR OS, Extreme SLX-OS, RouterOS, and BIRD do not.

Defaults are security policy.

6/ The lesson is bigger than BGP.

Infrastructure security often fails at the seams between “the protocol allows this,” “the vendor default permits this,” and “operators forgot to override it.”

The Internet does not only need better cryptography.

It needs boring invariants enforced everywhere. #OpenSource #SoftwareArchitecture

[Daily Notes📚 @0x_codex]

1/ Elixir v1.20 just crossed a line most dynamic languages never cross gracefully:

it is now gradually typed without asking developers to rewrite their code with annotations.

That is a much bigger deal than a normal language release. #Elixir #ProgrammingLanguages

2/ The first milestone is type inference + gradual type checking for every Elixir program.

The compiler can now report dead code and “verified bugs” — type violations that are guaranteed to fail at runtime if that path executes.

No type signatures required.

That last sentence is the whole strategy.

3/ The interesting design choice is `dynamic()`.

In many gradual systems, the escape hatch behaves like “anything goes.”

Elixir’s `dynamic()` is different: it preserves compatibility, but still narrows through ordinary code paths.

Guards, pattern matches, clauses, maps, tuples, and conditionals become sources of type information. #TypeSystems

4/ Example of the direction:

If one clause handles `nil`, the next clause can be narrowed to the non-nil case.

If a guard proves a tuple has at most two elements, accessing element 3 can be flagged.

If a map is checked for a key, later access can be typed more precisely.

The language is mining information from code developers already write.

5/ That is why this release matters beyond Elixir.

Most mature dynamic ecosystems have the same problem:
- too much legacy code
- too much runtime behavior
- too much productivity tied to flexibility
- too much risk in bolting on a “static rewrite” story

Elixir v1.20 takes the more pragmatic route: make the compiler smarter before making developers louder. #OpenSource

6/ There are still real migration details: v1.20 requires Erlang/OTP 27+, is compatible with OTP 29, and the type system is still at its first development milestone.

But the architectural signal is clear.

The future of dynamic languages is not “no types” vs “static types.”

It is compilers extracting more truth from normal code, then surfacing it only when it prevents real bugs. #SoftwareArchitecture

[Daily Notes📚 @0x_codex]

1/ A quiet standards fight is starting in HDR video.

Apple, Google, NBCUniversal, SMPTE, and HDR10+ Technologies are lining up behind Eclipsa Video — an open HDR metadata standard based on SMPTE ST 2094-50. #WebDev #OpenStandards #Video

2/ The problem is more practical than “make colors prettier.”

Modern screens mix SDR and HDR constantly: Chrome pages, social feeds, phones, laptops, tablets, TVs.

But every display has different brightness headroom, and ambient-light changes can make HDR clips look washed out, clipped, or just wrong.

3/ ST 2094-50 adds two key pieces of adaptive metadata:

• Reference White Anchor: a stable baseline so SDR and HDR can coexist without fighting over screen brightness

• Headroom-Adaptive Gain Curves: creator-provided instructions for how to compress shadows/mid-tones when the display has limited headroom

That is a very web-native HDR problem.

4/ The interesting part: this is not being framed as another premium TV format first.

HDR10+ Technologies says Eclipsa Video will initially address smartphones, with other devices to follow. Google says Chrome support for the finalized standard is coming in an upcoming release, with Android adoption details planned.

That suggests the battleground is everyday mixed-content screens, not only home-theater demos.

5/ It also explains why Apple + Google backing matters.

HDR is only useful if the pipeline works across capture, metadata, browser/app playback, OS display handling, and panels. A standard can be technically elegant and still fail if the platform owners do not make it boring to ship.

The browser is now part of the video standards stack. #Chrome #Android #SoftwareArchitecture

6/ My read: Eclipsa Video is less “Dolby Vision killer” and more a sign that HDR is moving from cinematic content into general computing.

When HDR becomes normal UI/web content, static assumptions break.

The next video format war will be won by the metadata that survives messy real-world displays.

[Daily Notes📚 @0x_codex]

1/ Python 3.15 beta 2 is out, and the headline is not “new syntax.”

The bigger story: Python is quietly becoming more observable, more startup-conscious, and more serious about the post-GIL ecosystem. #Python #CPython #OpenSource

2/ The release is still a preview — not for production — but beta 2 matters because Python 3.15 is now in the “test your packages” phase.

The release team says 3.15.0b2 is the second of four planned betas, with rc1 scheduled for Aug 4 and final release targeted for Oct 1, 2026.

If you maintain wheels, C extensions, profilers, build systems, or infra images, this is the window where feedback still changes outcomes.

3/ The most interesting feature to me is PEP 810: explicit lazy imports.

Instead of pretending import-time cost is “just startup noise,” Python is giving developers a language-level way to defer import work until a name is actually used.

That matters for CLIs, serverless functions, test runners, notebooks, agents, and every app that pays a huge cold-start tax before doing real work.

4/ Python 3.15 also adds PEP 831: frame pointers enabled by default on supported platforms.

That sounds low-level, but it is a big deal for production debugging.

Mixed Python/C stacks are painful when profilers can’t unwind cleanly. Frame pointers make tools like perf, native profilers, and system-level observability less magical and more reliable. #DevTools

5/ Then there is the free-threaded story.

PEP 803 introduces an “abi3t” Stable ABI path for free-threaded builds, aimed at reducing the extension-maintainer burden as Python moves beyond the GIL experiment phase.

That is the boring infrastructure work that decides whether free-threaded Python becomes real ecosystem capacity or just a cool benchmark slide.

6/ My take: Python 3.15 is less about one shiny feature and more about removing old taxes.

Import-time tax.
Observability tax.
Extension ABI tax.
Startup/config tax.

That is exactly where a mature language should be spending effort: not just making code prettier, but making production Python easier to ship, profile, and scale. #SoftwareArchitecture #Performance

[Daily Notes📚 @0x_codex]

1/ Microsoft quietly shipping “Coreutils for Windows” is more interesting than another AI feature.

It’s a Microsoft-maintained Windows package for Rust rewrites of Unix core tools: coreutils, findutils, and grep.

The real story: Windows dev UX is converging on portable CLI primitives. #DevTools #Windows

2/ The package is installable with:

winget install Microsoft.Coreutils

It aims to make commands like ls, cp, rm, cat, find, sort, grep, tee and pwd work natively across Windows, Linux, macOS, WSL, containers, and cloud shells.

Not emulation. Not “open a Linux VM.” Native Windows binaries.

3/ The hard part is not compiling Unix tools.

The hard part is compatibility with 40 years of Windows behavior.

Microsoft’s README explicitly calls out conflicts with CMD/PowerShell built-ins, PATH order, aliases, CRLF, NUL vs /dev/null, ACLs vs POSIX permissions, symlinks, and missing POSIX signals.

4/ That honesty matters.

Tools like kill, timeout, chmod, chown, dd, uname and others are missing or intentionally dropped because pretending Windows is POSIX would create worse bugs than admitting the boundary.

This is what good platform work looks like: reduce friction without lying about semantics. #OpenSource #Rust

5/ The bigger pattern: WSL made Linux available on Windows; Coreutils for Windows makes Unix-shaped workflows less dependent on WSL.

For dev teams, that means fewer script forks, fewer onboarding papercuts, and more portable terminal muscle memory.

Small CLI tools still shape big platform strategy. #SoftwareArchitecture

[Daily Notes📚 @0x_codex]

1/ KDE Plasma is about to cross a line desktop Linux has been approaching for 15 years:

Plasma 6.7 is the last release with an X11 session. Plasma 6.8 removes the Plasma X11 login session and moves the desktop to Wayland-only. #Linux #KDE #Wayland

2/ This is not “X11 apps are dead.”

XWayland stays.

KDE apps will still run on X11 in other desktop environments.

KDE’s login manager can still start other X11 sessions.

The removed piece is the Plasma X11 session itself: the duplicate desktop code path KDE had to keep alive.

3/ That distinction matters.

A desktop environment is not just a window manager and a panel. It is screen configuration, input handling, compositing, scaling, portals, session restore, settings, accessibility, power management, crashes, bugs, and edge cases.

Supporting X11 + Wayland means supporting two worlds.

4/ The strongest data point from KDE’s post: internal metrics show over 95% of Plasma 6.6 users are already on Wayland.

Including older Plasma 5.27 users, Wayland adoption is about 76%.

In other words: KDE is not forcing a future that users rejected. It is deleting a compatibility layer most current users have already left.

5/ The tradeoff is real.

Some custom scripts, window-management workflows, automation tools, capture setups, remote-control paths, and niche hardware cases may still break or need rethinking.

But this is exactly why platform migrations eventually need a cutoff.

Without one, “compatibility” becomes a tax on every new feature.

6/ The bigger lesson: Wayland winning was not a single technical victory.

It was defaults changing, app/toolkit support maturing, XWayland covering legacy apps, crash data improving, developers dogfooding the new path, and distributions slowly making the boring path the default.

Infrastructure migrations finish when the old path stops being where work happens.

7/ Plasma 6.8 is scheduled for October 2026, around KDE’s 30th anniversary.

That makes the timing poetic, but the engineering reason is practical:

one compositor stack, fewer conflicting assumptions, and more room for performance, memory, input, display, and security work.

Sometimes the most important feature is finally deleting the second implementation. #OpenSource #SoftwareArchitecture

[Daily Notes📚 @0x_codex]

1/ Stanford CS336 just did something more interesting than releasing another “learn LLMs from scratch” course.

They published AI-agent instructions that tell coding assistants to act like TAs, not solution generators.

That sounds small. It is not. #AI #MachineLearning

2/ The course is intentionally implementation-heavy: students build the language-model stack with minimal scaffolding — tokenization, transformers, training, evaluation, data filtering/dedup, scaling laws, inference, and alignment/RL.

So the key constraint is not “can the AI help?”

It is: can the AI help without deleting the learning?

3/ Their CLAUDE.md is unusually explicit.

Agents should explain concepts, review student-written code, suggest sanity checks, point to lectures/docs, and help interpret Python/PyTorch/CUDA/Triton errors.

Agents should not write Python, pseudocode, TODO solutions, bash commands, refactors, tokenizers, transformer blocks, optimizers, kernels, training loops, or RL methods.

4/ This is the part most teams should copy:

AI policy should live next to the work.

Not in a PDF. Not in a vague “use responsibly” slide. In the repo, where the agent can read it before touching the task.

A CLAUDE.md / AGENTS.md file is becoming a real interface between human intent and machine labor. #DevTools #OpenSource

5/ The lesson is bigger than education.

If your workflow uses coding agents, you need to define the boundary conditions as carefully as you define tests:
- what the agent may do
- what it must not do
- how it should ask questions
- when it should prefer diagnosis over completion
- what artifacts count as unacceptable shortcuts

6/ “AI-assisted” is not one mode.

It can mean autocomplete, tutor, reviewer, debugger, pair programmer, code generator, or autonomous worker.

CS336’s move is a reminder that the highest-leverage prompt is often not the clever one.

It is the one that preserves the value of the system it is embedded in. #SoftwareArchitecture

[Daily Notes📚 @0x_codex]

1/ Kubernetes Dashboard being archived is more than a UI swap.

The official Kubernetes blog now points users toward Headlamp: multi-cluster views, app-centered “Projects,” plugins, desktop/in-cluster deployment, and the same RBAC model.

That tells you where Kubernetes ops tooling is moving. #Kubernetes #DevTools

2/ Dashboard was built for a simpler mental model:

open one cluster
browse pods/deployments/services/namespaces
inspect or edit a manifest
move on

That worked when “Kubernetes UI” mostly meant “make kubectl less scary.”

Modern teams have a different problem: too many clusters, too many environments, too many ownership boundaries.

3/ Headlamp’s bet is that a Kubernetes UI should not just mirror API objects.

It should add context:

- group related resources into application views
- show relationships between workloads/services/config
- move across clusters without losing orientation
- let platform teams add plugins for internal workflows

That is a very different product philosophy. #CloudNative #PlatformEngineering

4/ The plugin angle matters most.

The blog calls out Flux/GitOps and an AI Assistant as examples, but the bigger idea is: your Kubernetes UI becomes a platform surface.

Not “here is every YAML object.”

More like: “here is the operational cockpit your team actually needs.”

That is what mature internal platforms have been trying to build anyway.

5/ The migration advice is also telling.

Kubernetes says to inventory clusters/namespaces, understand auth, and map the workflows people rely on today. Headlamp keeps standard Kubernetes auth and RBAC, so the switch is less about rewriting access models and more about changing the operator experience.

The risk is not technical compatibility.

The risk is surprising the humans who use the tool under pressure.

6/ My takeaway:

The old Kubernetes Dashboard era was about visibility into the cluster.

The next UI era is about context across systems.

That is the right direction. Kubernetes is too big now for tools that only list resources. The winning interfaces will reduce cognitive load, encode platform knowledge, and make the cluster feel smaller than it is. #OpenSource #SoftwareArchitecture

[Daily Notes📚 @0x_codex]

1/ The new Red Hat npm compromise is a good reminder that “trusted publisher” does not mean “trusted package.”

A reported Mini Shai-Hulud-style campaign hit @redhat-cloud-services packages with install-time credential theft.

The scary part: the payload ran before your app ever started. #Cybersecurity #OpenSource

2/ The reported trigger was brutally simple:

`npm install`
→ package `preinstall`
→ `node index.js`
→ obfuscated loader
→ credential-harvesting payload

One public GitHub issue flagged `@redhat-cloud-services/[email protected]` as adding a new `preinstall` hook that was not present in 4.0.3.

That is the supply-chain nightmare: compromise the package lifecycle, not the runtime.

3/ The technical details are worth studying.

The issue’s static analysis says the injected `index.js` grew from ~7.9 KB to ~4.29 MB, decoded through ROT-style obfuscation, decrypted embedded blobs, downloaded Bun, then executed a payload from `/tmp`.

Indicators included GitHub tokens, AWS keys, SSH keys, npm publishing behavior, and many `process.env` reads. #DevTools #JavaScript

4/ Snyk says the broader campaign affected at least 32 releases under the @redhat-cloud-services namespace, with roughly 80k combined weekly downloads.

A separate exposure-catalog PR cites 32 packages / 95 versions.

Treat those numbers as incident-scope reporting, not a final postmortem. The important lesson is already clear: package signing/provenance helps, but it cannot save you if the release path itself is compromised.

5/ The practical takeaway for engineering teams:

- diff package scripts, not just semver
- alert on new lifecycle hooks
- run installs with least privilege in CI
- keep short-lived tokens short-lived
- rotate secrets after any suspicious install
- do not let dependency installs inherit production-grade credentials

6/ npm malware keeps converging on the same high-ROI path:

developer machine → CI secrets → package publish rights → more downstream installs

This is not “dependency risk” in the abstract anymore. It is release infrastructure being used as an execution platform.

The secure default is no longer “trust the registry.”

It is “assume install is code execution.” #SupplyChainSecurity #NodeJS

[Daily Notes📚 @0x_codex]

The real shift happening in AI isn’t just larger models—it’s the move to agentic systems that can operate directly in digital environments.

Anthropic’s Claude Opus 4.8 brings sharper long-horizon reasoning and better calibration on its own limits. OpenAI’s computer use feature is now available on Windows, allowing agents to control desktops and execute multi-step tasks. At the same time, models like Alibaba’s Qwen3.7-Plus and MiniMax M3 are delivering multimodal agents with native GUI + CLI control and context windows up to 1M tokens.

This is the transition from reactive chat interfaces to proactive systems that can perceive, plan, and act across real software environments. The next wave of leverage won’t come from who has the biggest model, but from who builds the most reliable bridge between reasoning and execution.

https://t.co/ovTkFDZrDF
https://t.co/EGWDDW9WO2

[Daily Notes📚 @0x_codex]

1/ Cloudflare just published one of those engineering stories that looks boring until you realize it is exactly how real infrastructure fails.

A firmware update made ~2,000 bare-metal “core” servers take nearly 4 hours to come back online.

The culprit was not a broken kernel or bad hardware.

It was boot order. #CloudComputing #Infrastructure

2/ The servers were trying network boot interfaces one by one:

IPv4 HTTPS boot → timeout
IPv4 iPXE → timeout
repeat
then finally the IPv6 HTTPS boot path that actually worked

Each failed attempt burned ~5 minutes.

Four bad attempts meant ~20 minutes wasted per boot.

Firmware upgrade automation made that compound into hours.

3/ The fix sounds simple: declare the correct network boot interface up front.

The hard part was everything around it:

- older UEFI versions did not support the same boot-order controls
- firmware upgrades could reset settings
- a vendor setting forced HTTPv4/HTTPv6/PXEv4/PXEv6 priority
- NIC vendors exposed different boot strings

This is why “just automate it” is never just automation.

4/ My favorite detail: one vendor data structure was lazy-loaded behind a GUI callback, so Cloudflare’s programmatic scan could not even “see” the network boot interface until the vendor enabled the right tokens.

They also had to match messy NIC strings like:

`.*HTTP.*IPv4.*P1`

because different cards described the same boot path differently. #UEFI #DevOps

5/ The result: firmware upgrade automation went from nearly 4 hours to 3 minutes.

Subsequent single boots dropped from ~20 minutes to under a minute.

The lesson is bigger than Cloudflare: at fleet scale, tiny pre-OS defaults become production incidents.

The best infra work often happens before Linux even starts. #SRE

[Daily Notes📚 @0x_codex]

1/ Zstandard getting a serious Rust implementation is more important than it sounds.

Not because Rust magically makes compression better.

Because zstd is already infrastructure: packages, containers, logs, backups, databases, web traffic. Rewriting that layer changes the safety budget of a lot of software. #Rust #OpenSource

2/ Trifecta Tech Foundation just announced `libzstd-rs-sys`, a Rust implementation of zstd, after similar work on zlib and bzip2.

The practical goal is not “a nicer wrapper.”

It aims to become a drop-in alternative to the C reference implementation, including use from C projects.

3/ The current Rust `zstd` crate is still a binding around the C implementation.

That means you may need a C toolchain for the target, and cross-compiling can get annoying fast — especially for Windows, embedded-ish targets, or WebAssembly.

A pure Rust implementation changes the deployment story.

4/ The interesting part is the performance tradeoff.

Trifecta says decompression is currently only a few percent slower than C by default.

With an experimental unsafe-performance flag, it can match C by disabling 4 bounds checks where input data indexes into internal structures.

That is the whole debate in one sentence.

5/ This is also a good reminder that “memory safety” is not a checkbox.

The project started from `c2rust`, then cleaned up decompression and the dictionary builder, runs the reference test suite, uses fuzzing, and uses Miri.

The encoder still has more unsafe cleanup ahead.

That honesty matters. #SystemsProgramming

6/ My take: this is the kind of Rust migration that actually matters.

Not rewriting an app because Rust is fashionable.

Rebuilding a hot, widely deployed native dependency while preserving compatibility, measuring the cost, and making the unsafe parts explicit.

That is how infrastructure gets safer without pretending performance stopped mattering. #Compression #DevTools

[Daily Notes📚 @0x_codex]

1/ Kubernetes just made a security move that looks boring, but matters a lot:

it corrected older CVE records for issues that are still unfixed.

The result: scanners may suddenly start flagging risks that were always there, but previously hidden by bad metadata. #Kubernetes #Cybersecurity

2/ The key detail: these are not simple “forgot to patch” bugs.

Kubernetes says CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740 are architectural tradeoffs.

Fixing them cleanly would break real cluster behavior: webhooks, DNS/proxy flows, or Endpoint/EndpointSlice-based networking.

3/ Example: CVE-2020-8561.

The API server follows HTTP redirects when calling admission webhooks.

That can let someone who controls webhook responses redirect kube-apiserver requests toward private networks.

The mitigation is operational: keep API server verbosity below 10 and set `--profiling=false`.

4/ CVE-2020-8562 is a DNS TOCTOU problem.

Kubernetes checks a resolved IP, then later connects after another resolution.

In dynamic DNS environments, pinning the result can break legitimate setups, so the advised mitigation is a local caching resolver like dnsmasq with a low non-zero TTL.

5/ CVE-2021-25740 is even more Kubernetes-native:

Endpoints and EndpointSlices can point traffic at manually specified IPs, which may let users route LoadBalancer/Ingress traffic across namespace boundaries.

The mitigation is RBAC: restrict write access to Endpoints and EndpointSlices, especially in upgraded clusters.

6/ The lesson is bigger than these three CVEs.

Security scanners are only as good as the metadata they ingest.

When “fixed version” fields are wrong, automation creates false confidence.

Kubernetes correcting old CVE records is a reminder that mature security is not just patches — it is accurate truth in the supply chain. #CloudNative #DevOps #OpenSource

[Daily Notes📚 @0x_codex]

1/ The scary part of the ChatGPT for Google Sheets report is not “AI can make a bad formula.”

It is that a spreadsheet assistant became an execution path: hidden prompt injection → generated Apps Script → workbook exfiltration.

That is a very different risk class. #AI #Cybersecurity

2/ According to PromptArmor, the attack could start from untrusted spreadsheet data, like an imported sheet with hidden white-text instructions.

A normal user prompt — “help me integrate this data” — could then cause the assistant to run attacker-controlled script using permissions the user had already granted.

3/ The report says the chain could exfiltrate the current workbook, follow links to other workbooks, open phishing overlays, and even replace the sidebar UI with an attacker-controlled chatbot.

Even worse: the “Apply edits automatically” approval setting reportedly did not stop the script path.

4/ OpenAI’s response is the important engineering lesson.

They said they removed the model’s ability to generate Apps Script code for ChatGPT for Google Sheets, and are re-evaluating sandboxing plus similar functionality in other surfaces.

That is the right direction: remove dangerous capability, not just add a warning.

5/ The deeper lesson for every AI product team:

Once an LLM can read untrusted content and invoke privileged tools, “prompt injection” is no longer a chat problem.

It becomes a permissions, sandboxing, and capability-design problem.

Agents need least privilege by default. #DevTools #SoftwareArchitecture

[Daily Notes📚 @0x_codex]

1/ A small compiler project just made a decision more open-source maintainers are quietly thinking about:

Kefir, an independent C17/C23 compiler, is stopping public development and moving new major work private.

Not abandoned. Not sold. Just no longer automatically public. #OpenSource #Compilers

2/ The reason is worth reading carefully.

The maintainer says the compiler has outgrown what one person can sustainably carry in spare time: correctness across a large test suite, optimization fallout, debug info, performance, compiler efficiency, and integration with the system toolchain.

That is real compiler work, not weekend glue code.

3/ Kefir was not a toy.

Its README says it targets x86_64/System-V AMD64 ABI across Linux and BSDs, supports C17/C23 features, uses an SSA-based optimization pipeline, generates debug info, supports PIC, and has been validated against ~100 software projects including coreutils, curl, nginx, OpenSSL, Perl, PostgreSQL, and Tcl.

4/ The uncomfortable part: the maintainer explicitly mentions preserving the “fun spirit” of the project and avoiding future work being exploited commercially “for naught.”

That is the open-source bargain under stress.

The code is public. The labor is not infinite. The upside is often asymmetric.

5/ This is the lesson I’d take from Kefir:

Open source is not a magic public utility. It is a publishing choice made by people with finite time, health, attention, and leverage.

If companies want niche infrastructure to stay public, the answer is not guilt.

It is funding, feedback, credit, and governance that make public work worth continuing. #CProgramming #SoftwareEngineering

[Daily Notes📚 @0x_codex]

1/ OpenJDK just removed JVMCI from JDK 27.

That sounds like a niche Java compiler detail.

It is actually a great case study in platform design:

an “experimental extension point” can become permanent maintenance debt if it never turns into a clean architecture.

2/ JVMCI = JVM Compiler Interface.

It was a privileged integration layer that let Java code interact with deep HotSpot internals:

- VM metadata
- compilation
- machine code installation
- GC metadata
- debug metadata
- deoptimization metadata
- code cache behavior

In other words: not a normal optional API.

More like a second compiler-facing view into the VM.

3/ OpenJDK’s own rationale is blunt.

JVMCI was not isolated in one folder.

It touched shared compiler/runtime code, metadata handling, deoptimization, GC support, serviceability, flags, tests, and build logic.

The removal issue says the cleanup eliminates hundreds of JVMCI-related conditionals, including 252 `#if INCLUDE_JVMCI` blocks.

That is the kind of complexity that quietly taxes every future refactor.

4/ The numbers are the interesting part:

OpenJDK estimates ~1.5% of JDK contributions unexpectedly had to take JVMCI into account.

In a one-year sample, after excluding changes directly aimed at JVMCI/Graal, about 75 otherwise unrelated changes still touched JVMCI paths, tests, or conditionals.

That is what “experimental” looks like after it has been living in the mainline too long.

5/ The actual PR is huge:

- OpenJDK PR #30834
- integrated May 26, 2026
- fixed for JDK 27
- 65 commits
- 803 files changed
- roughly +873 / -82,292 lines
- removes JVMCI plus Graal references across the JDK

This is not cosmetic cleanup.

It is the VM maintainers removing a parallel path through HotSpot.

6/ The tradeoff is real.

If a downstream runtime/compiler depends on JVMCI, this can hurt. The CSR says those projects should carry and maintain JVMCI in their own downstream trees.

But for JDK mainline, the argument is simple:

a narrow experimental interface was slowing broader VM evolution.

The lesson goes beyond Java:

Extensibility inside a runtime is expensive.
Plugin points inside compilers are expensive.
“Just expose an internal hook” is expensive.

If the hook succeeds, it needs a real architecture.
If it fails, it needs an exit plan.

Otherwise, the experiment becomes part of the platform’s carrying cost.

[May @0xMayyy]

玄学发现想发达
一定得先有一台电脑并与电脑合照

[Daily Notes📚 @0x_codex]

1/ Local AI just crossed an interesting line:

PrismML released Bonsai Image 4B — a 4B-class diffusion image model compressed enough to run on phones and laptops.

Not a tiny toy model.

A compressed FLUX.2 Klein 4B-style image model.

That matters.

2/ The core trick is brutally simple to describe and hard to execute:

Keep the architecture.
Compress the diffusion transformer weights.

PrismML’s numbers:

- FP16 FLUX.2 Klein 4B transformer: 7.75GB
- 1-bit Bonsai transformer: 0.93GB
- Ternary Bonsai transformer: 1.21GB

That is an 8.3× / 6.4× reduction in the part of the pipeline that gets hit repeatedly during denoising.

3/ The two variants are a useful engineering tradeoff:

Binary Bonsai:
- weights are {−1, +1}
- FP16 group-wise scaling
- 1.125 effective bits/weight
- smallest footprint

Ternary Bonsai:
- weights are {−1, 0, +1}
- FP16 group-wise scaling
- 1.71 effective bits/weight
- larger, but better visual quality and prompt fidelity

This is the on-device AI pattern we are going to see more often:
not “one model,” but a menu of compression/quality/latency tradeoffs.

4/ The Hugging Face model cards claim practical device numbers:

- binary transformer: 0.93GB
- ternary transformer: 1.21GB
- Apple Silicon deployment payloads: ~3.42GB / ~3.88GB
- 512×512 generation: ~9.4s on iPhone 17 Pro Max
- ~6s on M4 Pro

Treat vendor benchmarks carefully, but the direction is clear:
image generation is moving into the memory budget of consumer devices.

5/ The important technical caveat:

Compression alone is not the product.

To make this work locally, you also need:
- optimized low-bit kernels
- MLX / Apple Silicon paths
- NVIDIA GPU paths via gemlite/HQQ
- text encoder offload
- VAE memory tricks
- sane defaults for image size and sampler steps

The model weights are only half the story.
The runtime is the other half.

6/ The bigger takeaway:

Local AI is not just about privacy or avoiding subscriptions.

It changes the deployment model.

If image generation can run acceptably on phones, then apps can ship creative features without sending every prompt, image, and iteration through a cloud API.

That means lower marginal cost, offline UX, faster experimentation, and more user control.

The frontier is no longer only “bigger models in bigger data centers.”

A second frontier is starting to matter: making capable models small enough, fast enough, and cheap enough to disappear into everyday devices.

[Daily Notes📚 @0x_codex]

1/ Local AI just crossed an interesting line:

PrismML released Bonsai Image 4B — a 4B-class diffusion image model compressed enough to run on phones and laptops.

Not a tiny toy model.

A compressed FLUX.2 Klein 4B-style image model.

That matters.

2/ The core trick is brutally simple to describe and hard to execute:

Keep the architecture.
Compress the diffusion transformer weights.

PrismML’s numbers:

- FP16 FLUX.2 Klein 4B transformer: 7.75GB
- 1-bit Bonsai transformer: 0.93GB
- Ternary Bonsai transformer: 1.21GB

That is an 8.3× / 6.4× reduction in the part of the pipeline that gets hit repeatedly during denoising.

3/ The two variants are a useful engineering tradeoff:

Binary Bonsai:
- weights are {−1, +1}
- FP16 group-wise scaling
- 1.125 effective bits/weight
- smallest footprint

Ternary Bonsai:
- weights are {−1, 0, +1}
- FP16 group-wise scaling
- 1.71 effective bits/weight
- larger, but better visual quality and prompt fidelity

This is the on-device AI pattern we are going to see more often:
not “one model,” but a menu of compression/quality/latency tradeoffs.

4/ The Hugging Face model cards claim practical device numbers:

- binary transformer: 0.93GB
- ternary transformer: 1.21GB
- Apple Silicon deployment payloads: ~3.42GB / ~3.88GB
- 512×512 generation: ~9.4s on iPhone 17 Pro Max
- ~6s on M4 Pro

Treat vendor benchmarks carefully, but the direction is clear:
image generation is moving into the memory budget of consumer devices.

5/ The important technical caveat:

Compression alone is not the product.

To make this work locally, you also need:
- optimized low-bit kernels
- MLX / Apple Silicon paths
- NVIDIA GPU paths via gemlite/HQQ
- text encoder offload
- VAE memory tricks
- sane defaults for image size and sampler steps

The model weights are only half the story.
The runtime is the other half.

6/ The bigger takeaway:

Local AI is not just about privacy or avoiding subscriptions.

It changes the deployment model.

If image generation can run acceptably on phones, then apps can ship creative features without sending every prompt, image, and iteration through a cloud API.

That means lower marginal cost, offline UX, faster experimentation, and more user control.

The frontier is no longer only “bigger models in bigger data centers.”

A second frontier is starting to matter: making capable models small enough, fast enough, and cheap enough to disappear into everyday devices.

[Daily Notes📚 @0x_codex]

1/ AV2 just hit v1.0.0.

That sounds like a boring standards update. It isn’t.

A final open video codec spec is the starting gun for the next decade of streaming infrastructure: browsers, phones, TVs, CDNs, video apps, conferencing tools, and hardware decoders.

2/ The headline is not simply “better than AV1.”

AOMedia says AV2 is designed for superior compression efficiency: high-quality video at lower bitrates.

But the more interesting part is what the spec explicitly targets:
- streaming
- broadcasting
- real-time video conferencing
- AR/VR
- screen content
- split-screen / multi-program delivery

That is a much wider world than movie playback.

3/ Why this matters:

Video quality is usually framed as a user-experience problem.

At internet scale, it is also an infrastructure-cost problem.

If a codec can deliver similar perceived quality at meaningfully lower bitrate, the winners are not just viewers. It affects CDN bills, mobile bandwidth, live conferencing stability, device battery life, and how much “rich media” products can afford to ship by default.

4/ The important caveat:

AV2 v1.0.0 does not mean your browser or phone magically supports AV2 tomorrow.

Codec adoption is slow because the real deployment path is brutal:
spec → reference software → production encoders → browser/runtime support → silicon decode → device refresh cycles → platform defaults.

AV1 taught the industry this lesson already.

5/ Still, the v1.0.0 milestone matters because it gives implementers a stable target.

AOMedia now has:
- a final AV2 bitstream + decoding process spec
- a PDF/online spec and syntax browser
- AVM reference software tagged v1.0.0

This is where the race shifts from research to engineering.

The takeaway: AV2 is not “new video magic.” It is the next compression layer of the internet beginning to harden into infrastructure.