A closely watched Nvidia-backed startup called Reflection is preparing to shake up the AI race with a powerful open-weight system that could threaten Chinese upstarts and U.S. AI giants alike.

Why it matters: The marriage of an American open-weight model and Nvidia GPUs would give individuals and companies a new, cheaper alternative to Anthropic, OpenAI and Google.

Open models, designed to compete with Chinese rivals, can be harder to monitor and regulate than the Big Three so-called frontier models. Supporters of such ecosystems say their widespread availability and transparency also bring security advantages.

• Reflection's first model is set to be joined by other open-weight models from other Western players this month, sources tell Axios. That will bring a new competitive dimension to the AI boom.

State of play: Reflection's model, set to be released soon, is expected to initially lag behind the most cutting-edge U.S. models and be competitive with top Chinese open-weight models.

> A 100% free software project aimed at replacing the nonfree boot software (like BIOS or UEFI) of computers with free boot software.

This will go nowhere as similar projects before it. Modern motherboards are so choke full of features, many of which are heavily proprietary, a free/open UEFI replacement will only entice red-eyed geeks and no one else.

Xenolith Engine

Xenolith is a cross-platform SDK for building modern C and C++ applications: a Vulkan-based graphics engine, a custom system runtime (libc/C++ standard library/pthread) and a set of application libraries, all built with a single build system without relying on platform SDKs.

The SDK is organized as a monorepository and consists of three main layers:

• Xenolith Runtime (runtime/) — an umbrella libc implementation, a full C++ standard library (a freestanding minimal one plus a complete libc++ port) and a custom pthread. It provides a single POSIX-compatible interface on top of the platform libc, and on some platforms a fully custom implementation.
• Stappler utilities (stappler/) — application libraries: data and serialization, database access, cryptography, networking, raster and vector graphics, typography, documents.
• Xenolith Engine (xenolith/) — a graphics and compute engine, Vulkan first, with WebGPU, Metal, OpenGL ES and software backends: the core part of the project.

The SDK also includes its own GNU Make build system (make/) and self-contained toolchains (built from runtime/toolchains/, or installed from the binary releases into toolchains/) that allow building the project without third-party SDKs.

Project principles

• No barriers. The SDK requires no platform SDKs: Windows builds work without UCRT and the Windows SDK, Android without the NDK, macOS without the macOS SDK (the +open sysroot). This removes the related technical and licensing restrictions.
• For C and C++. A convenient and full-featured working environment specifically for these languages; support for other languages is limited to the dynamic-library level.
• Unified API. As far as technically possible, every supported platform gets the same interface — without massive configure scripts or platform-specific branches in the code.
• Unified build. All build tools ship as part of the SDK; the user simply builds the code with a fixed version of GNU Make.
• Compatibility. Any code built as a dynamic library must work with the SDK on supported platforms.

https://github.com/XenolithEngine/xenolith-engine/tree/nightly

OpenDLSS-NR

A Vulkan reimplementation of NVIDIA's DLSS 5 Neural Rendering network, bit-exact against the original.

The same 71-block Swin / ViT network as DLSS-NR build 310.8.0, running FP8 on the tensor cores. The intermediates match too, not just the final image: all 75 block boundaries, byte for byte.

ports/browser-webgpu/ is a second, independent implementation: the same bytes in a browser, with no tensor cores and no FP8.

You supply the weights, as a model directory in the layout described below.

The network

A U-net of shifted-window transformer blocks with a global ViT at the bottom: 71 blocks over six pooling levels, FP8 (E4M3) activations with FP16 accumulation, 141 MiB of weights. It is a generative neural rendering network (NVIDIA's term): it re-renders the frame the engine already drew, generating detail from injected noise and adjusting tone, structure and skin under a style setting. Input and output are the same resolution; it is not an upscaler.

The WebGPU port at 2048x1152, NR off on the left and on on the right. Scene: Cowboy Gramps by Muhammed Ismayil, CC0.

It takes one rendered frame (a low dynamic range proxy of it, three lanes of Gaussian noise, the previous frame's output reprojected, and five conditioning scalars) and produces four f32 channels per pixel: an RGB residual and one temporal-blend logit. docs/network.md is the graph in full. NVIDIA describes the model in its report, DLSS 5: Generative Neural Rendering (project page).

virtio-nvgpu

Near-native NVIDIA GPU access inside a KVM guest. A guest renders within 2% of the machine it is running on, and costs the same CPU.

virtio-nvgpu forwards NVIDIA kernel driver ioctls between a Linux guest and the host at the driver ABI level, bypassing API-level translation entirely. The guest runs NVIDIA's own user-mode drivers, unmodified — the same libraries, the same Vulkan and NVENC, talking to the same card.

The target is headless streaming: a compositor inside the VM renders, composites and encodes frames on the GPU, then sends compressed video out. The VM has no monitor, and the host keeps the card.

Where it stands

It works, and it has been measured. A Wayland client presents inside a guest, the capture layer encodes on the game's own device, and the H.264 comes out the other side — 618 frames that ffmpeg decodes without an error.

Measured on an RTX 3060 (driver 595.99.02), guest against the same host, bare metal, with an identical headless Vulkan load:

Above about 2 ms a frame — which is every frame a game draws — a guest is within 2% of bare metal. Below that, the cost of waiting for the GPU starts to show against a frame that barely exists.

CPU is the other half of it, because a shared GPU is only worth sharing if the guests are cheap. Unpaced at ~100 fps for 12 s, one guest:

A guest costs what the host costs. Nothing is spent on forwarding in a render loop, because nothing is forwarded: NVIDIA's user-mode driver submits through memory it has mapped, and that memory is the host's. Over 813,691 frames the backend served 13,792 messages — one crossing per 59 frames, nearly all of it device setup.

Full method, raw runs and the things these numbers do not support: BENCHMARKS.md.

Several guests on one card

Four guests on one RTX 3060, the same load in each: 25.84, 26.49, 25.57, 25.79 fps — 103.7 together, against 102.9 for a single guest — with p50 frame times of 39.165, 39.164, 39.168 and 39.165 ms. The total does not move as guests are added, and the split is even to four decimal places.

All four render correctly at the same time, and four of them encode H.264 at once, each paced at exactly 60 Hz, with no NVENC session limit reached.

Linux is great at emulating stuff.

I posted what I thought was a pretty boring technical question about Fedora dropping the ntfs3 kernel module in 7.2.6 that already hit testing and will be pushed to stable in the next few days:

Original thread

Maybe I'm completely missing something, because I genuinely did not expect the responses I got.

My situation seems fairly simple.

I use Fedora. I like Fedora. I have NTFS drives. My friends give me their NTFS drives. I've been using ntfs3 for years without problems, and I would prefer to continue using the same driver rather than suddenly switch to another implementation for data that I truly care about.

So I asked why Fedora disabled it, where the discussion happened, and why this happened during the Fedora 44 lifecycle.

Instead, as far as I can tell, the suggestions were basically:

• Switch distributions if stability matters to me.
• Compile ntfs3 myself whenever Fedora ships a new kernel. And deal with signing my own module because I use Secure Boot.
• Use ntfs-3g, which is considerably slower and is one of the reasons an in-kernel NTFS driver was attractive in the first place.
• Use the newer ntfs implementation, which I personally don't yet trust with writable filesystems containing data I care about.
• Stop using NTFS. Apparently having NTFS drives is itself a questionable life choice.

Am I missing something here?

I thought one of the nice things about Linux was having choices. I am not asking Fedora to make ntfs3 the default. I'm not asking anyone else to use it. I'm not even claiming that it is perfect.

I just want the module that is still present upstream to remain available so that existing users can continue using it.

One comment said that ntfs3 is "buggy as hell" and that Fedora removed it "to protect uninformed users". I asked for a source because I genuinely wanted to read the Fedora discussion or technical justification behind the decision. Cause I couldn't find one. I googled for hours.

I was also told that Paragon basically dumped the driver into the kernel and "abandoned it", but there are years of commits in the kernel:

https://github.com/torvalds/linux/commits/master/fs/ntfs3

So now I'm confused about both the technical decision and the reaction to asking about it.

Maybe I've expressed this badly. Maybe there's an obvious piece of Fedora history that I've completely missed. If there is, please point me to it. Seriously. A mailing-list discussion, Bugzilla discussion, Fedora change proposal, kernel-team explanation, anything at all.

What surprised me wasn't that people disagreed with me. That's OK.

What surprised me was that "why was this existing module removed?" somehow turned into "use another filesystem," "use another driver," "compile it yourself," or "use another distribution."

I've been using Linux since the late 90s. I'm not trying to start a filesystem holy war. I'm an old guy who wants his boring old setup to keep working. I don't want to touch my fstab needlessly. I've had it for years as it is.

Is this just one of those Reddit moments, or is asking "why was this removed?" really that unreasonable?

You can already enable the Nova redesign by opening about:config and setting browser.nova.enabled to true.

Looks a little bit toyish to me and I'm almost certain it will result in a higher power consumption.

What do you think?

Thousands of eyes they said. Given enough eyeballs, all bugs are shallow, huh? Except eyeballs prior to LLMs haven't bothered.

Incremental 7.2.5 - 7.2.6 patch: 3,274,400 bytes (!). 15,627 LoC removed, 33,457 LoC added.

329 of the 1,816 commits contain at least one security-ish indicator.

Remote/network-facing: ksmbd, Bluetooth, NFC, IPVS, iSCSI/iSER, RDMA, VXLAN and assorted networking parsers.

Malicious filesystem/image: NTFS/NTFS3, SquashFS, UDF, ISOFS, EROFS, ext4/OCFS2. A mountable crafted image turning into an OOB read/write is textbook vulnerability territory, even if mounting normally requires privilege; namespaces and automounters can complicate the threat model.

Local privilege boundary: AppArmor, BPF, net/sched, NVMe ioctl validation and some namespace-related fixes.

Expect a dozen of 0-days at the very least.

Even some Windows users transitioning to Linux prefer XFCE over everything else.

Self-reflection must be missing for them completely.

> A single pool that licenses HEVC and VVC (true SDO standards) together with AV1 and AV2 (proprietary consortium codecs) as if they were one homogeneous mass is not “a one-stop shop for the market”. It is a blurring of two philosophies that regulators – which are already monitoring open-media licensing under EU competition law and the Digital Markets Act – have every reason to examine closely. Efficiency for the licensee should never come at the cost of legal coherence.

They advocate that the licensing mess that HEVC and VVC have found themselves in, is actually fine!

This wonderful press release neatly leaves out the implementer's side of the story: even with FRAND commitments, HEVC ended up with multiple pools, licensors outside pools, changing royalty structures, uncertainty over aggregate burden, and years of commercial hesitation. A standard can be legally FRAND-encumbered and still have an absolutely miserable licensing ecosystem.

Wait, there's more:

And both present themselves as the party saving the industry from licensing dysfunction.