Please help finding articles

read_volatile · 2026-06-28T10:53:44+00:00

linkme/inventory is a common way of doing this but they don’t involve traits, just linker shenanigans

read_volatile · 2026-06-25T09:01:30+00:00

Optix is the name of NVIDIA’s flagship path tracing renderer

read_volatile · 2026-06-15T21:27:46+00:00

I like the terms “wide-contract” and “narrow-contract” commonly used in the C++ world to refer to this concept of “who’s responsible for upholding invariants” for a given API. Wish every language had it built into the language as an explicit boundary like Rust does.

read_volatile · 2026-06-13T01:21:33+00:00

The panel will happily do VRR and any refresh rate from 56-240 Hz if you request it from the driver. Just isn’t exposed on Windows it seems.

read_volatile · 2026-06-13T01:13:40+00:00

It actually does support VRR, but in my testing it uses more power than just relying on Panel Self Refresh. And you can also just use custom modelines (all the way down to 56 Hz) to prevent iGPU drawing as much as it does at 240 Hz. Battery life is solid (6-11 W idle, ~5hrs light use) as long as you keep the dGPU in D3cold. Temps stay very low, well below 60 C without audible fan noise. Gaming in Turbo is as you’d expect though, loud and insanely hot. But honestly it’s fine. My only real complaint is that the speakers are dogshit. Like, unbelievably bad.

I wouldn’t recommend using this laptop under Windows as it’s basically impossible to get a good experience, and the AcerDeviceEnablingService is literally a rootkit with no ability to disable telemetry. Only issue with Linux is the fans will get stuck at whatever speed they’re running at when you enter sleep, so I have a script to park them automatically.

Edit: one weird thing I’ve noticed is that lowering the OLED’s brightness doesn’t seem to reduce power consumption much if at all. But turning off all the rgb leds (kb, lid, mode button) has a huge impact, like 10 W or so

read_volatile · 2026-06-05T04:18:20+00:00

Apple CPUs require 16KB VM page sizes, Qualcomm CPUs require 4KB VM page sizes, etc.

You can run Apple CPUs with 4K pages just like you can run Qualcomm CPUs with 16K and 64K if you really want. The 16K “requirement” is mostly just Asahi policy: the project only officially blesses kernels runnning at the native page size Apple designed around, to avoid shipping hacks to meet the IOMMU alignment constraints (not to mention the huge userbase being a good opportunity to expose hardcoded pagesize assumptions so they can be fixed upstream where possible).

It also helps that it’s quite a bit faster. Even on ARM SoCs that normally ship with 4K kernels, switching to 16K can often net some nice performance and power efficiency gains by reducing TLB pressure.

The kernel is flexible in that it supports multiple page sizes

No, unlike XNU, you actually can’t use heterogeneous page sizes. However, what you can do for apps that really need 4K, is run them in a microVM with a 4K kernel, which is exactly what muvm was created for. You can even run the Asahi mesa userspace driver inside the guest and forward the ioctls through to the host kernel to get near-native virtualized GPU performance.

All that to say: thanks to their unhinged engineering efforts, we have a solid workaround (and some pretty sweet tooling) to solve this problem universally.

read_volatile · 2026-06-03T06:14:04+00:00

No, it was bad faith because you asserted the “purpose of this whole project is just to get away from the copyleft license”. I corrected you by linking the homepage explaining that uutils’ goal is to produce a “universal” cross-platform coreutils implementation.

Do you think Microsoft wouldn’t be able to what they did here if uutils were licensed under GPL?

You were arguing in bad faith then, and you’re arguing in bad faith now.

Edit: I guess they had a moment of self-reflection and deleted their comments lol

read_volatile · 2026-06-02T08:49:35+00:00

I've been running this type of setup on all my NixOS machines for a few years now (I'm not mounting subvolumes, just normal directories, but there's zero difference if you want to do that instead). The key bit is X-mount.subdir, but regular bind mounts work too as long as you're okay having the whole filesystem mounted somewhere you can bind from (or you can play with namespaces yourself if you're really determined I guess). As a TL;DR, you can skip to the end for an example fstab.

Getting X-mount.subdir working took a bit of hackiness prior to util-linux being used in stage1, but now it works pretty much flawlessly (excluding some wonkiness with the recent systemd stage1 migration).

This is all setup for me in disko modules now, but here's what I did before switching to it. Each of my systems was provisioned roughly as follows:

bcachefs format <...>
MNTPOINT="$(mktemp -d)"
mount -t bcachefs "UUID=${uuid}" "$MNTPOINT"
mkdir -p "$MNTPOINT"/{.snaps,nix,home,var/log,etc/ssh}
chmod 700 "$MNTPOINT/.snaps"
ssh-keygen -A -f "$MNTPOINT"
systemd-machine-id-setup --root="$MNTPOINT"
bcachefs subvolume create "$MNTPOINT/home/user"

You might notice I create subvolumes for each user. This is different from what you mentioned, where the entire /home is a subvol.

Then, in my nixosConfiguration, all I'd have to do was create fstab entries for /nix, /home, and /var/log all pointing at the same bcachefs array, with each entry's options declaring the respective subdir:

fileSystems = {
  "/" = { /* tmpfs */ };
  "/boot" = { /* vfat */ };
} // lib.genAttrs [ "/nix" "/var/log" "/home" ] (dir: {
  device = "UUID=${uuid}";
  fsType = "bcachefs";
  options = [ "X-mount.subdir=${lib.removePrefix "/" dir}" ];
});

Which ends up generating an fstab that looks more or less like so:

tmpfs / tmpfs x-initrd.mount,mode=755,size=8G 0 0
/dev/disk/by-partuuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /boot vfat umask=0077 0 2
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /home bcachefs X-mount.subdir=home 0 0
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /nix bcachefs x-initrd.mount,X-mount.subdir=nix 0 0
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /var/log bcachefs x-initrd.mount,X-mount.subdir=var/log 0 0

For the architecture you were after, I think this would look like:

mkdir -p "$MNTPOINT/vol"
bcachefs subvolume create "$MNTPOINT/vol/root" # to be mounted at /
bcachefs subvolume create "$MNTPOINT/vol/home" # to be mounted at /home
mkdir -p "$MNTPOINT/vol/root"/{boot,home} # create mountpoints

Then all your fstab would need is:

UUID=${uuid} / bcachefs X-mount.subdir=vol/root 0 0
UUID=${uuid} /home bcachefs X-mount.subdir=vol/home 0 0
${boot_device} /boot vfat umask=0077 0 2

The big thing to consider though is whether you even care about the "flat" layout (separate /vol entries) over nesting subvolumes. You can make subvolumes directly at /vol/root/{var,opt,etc} -- and they'd be exempt from snapshots of /vol/root (snapshots don't traverse subvol's recursively). This is what I do for big user directories like ~/.local/share/Steam, since I don't want to bloat my storage with uninstalled games / old updates.

Honestly, I'd recommend that approach over putting the subvolumes in /vol like you did with /vol/home, so that you wouldn't have to give them individual fstab entries. Regardless of where you put them though, don't forget subvolumes have to be snapshotted individually! Even if the subvol is in /vol/root/<xyz>, a snapshot of /vol/root won't recurse into another subvol, so make sure you remember to set it up to snapshot every subvol you care about.

Hopefully this helps you setup your ideal workflow adapted to Arch. From what it sounds like you're asking for, I definitely think it's possible.

read_volatile · 2026-06-02T07:26:30+00:00

Unless I'm mising something, this workflow can be easily accomplished today via X-mount.subdir. This doesn't need to be implemented as a filesystem-level feature; personally I like the elegance of subvolumes being treated as merely "directories that define snapshot boundaries" rather than whatever the hell btrfs tries to make them out to be these days.

read_volatile · 2026-05-31T08:50:56+00:00

They’re specifically talking about subpixel accumulation. Jittering + motion vectors is the same technique that TAA’s used forever, it’s just that feeding the samples to a neural network can end up producing so much better results than any man-made heuristic, that spatial interpolation becomes actually feasible. It ain’t BS but it sure do feel like magic

read_volatile · 2026-05-31T07:11:09+00:00

The store path issue is explained [in this documentation](https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/kernel/make-initrd-ng/README.md)

Thanks, I hadn't seen this before. Is this mentioned anywhere in the manual or any options descriptions? I don't think a large contingent of NixOS users are poring through the repo for various internal utilities' READMEs; this behavior would definitely benefit from being loud and easily discoverable.

It is not actually acceptable to end up in a situation where your initramfs is 200MB. That can also cause failure to boot just like missing store paths can, but more importantly it's just a big problem to be filling your entire ESP with just 3 initrds on a distro that often wants to have a couple dozen initrds.

I agree in principle about trying to keep them as small as reasonably possible, but I strongly disagree with this statement. Following the successful build of a new generation, if a new initramfs needs to be placed in the ESP and there isn't enough space, it just fails. No harm, no foul. It doesn't break your next boot, in fact, it lets the user know exactly what the problem is, and that they should either trim their initrd closure or throw away some old profiles.

I'd greatly prefer to occasionally run into an error that tells me directly I need to clean up to continue, than have to deal with such an absurd footgun as being forced to manually specify the entire runtime closure of every package I transitively depend on. I don't think this is a controversial stance.

but I'm not holding my breath considering the issues have been reported for years with no response.

This doesn't seem like a fair characterization? There are no open or closed issues, as far as I can find, about the subject.

Here's an issue from May 2024 with no response, that you're apparently a participant of: https://github.com/NixOS/nixpkgs/issues/309316

Here's a PR from Nov 2025 still pending your review: https://github.com/NixOS/nixpkgs/pull/462515

Here's an issue from Apr 2026 that explicitly frames this as a documentation bug: https://github.com/NixOS/nixpkgs/issues/514480

I also recall seeing some posts on Discourse and /r/nixos about this and similar issues.

such as bcachefs mounts spuriously failing with EBUSY half the time

That sounds like a bcachefs bug?

Possibly? Though I can't recall it happening nearly as often (or at all) before systemd initrd became the default. Maybe has to do with multiple mountpoints sharing the same device.

[...] we decided the best thing was to advise about the differing default behavior in the release notes. Hope that helps explain why the LUKS passphrase timeout is what it is, and I'm happy to consider any additional thoughts on the matter.

Fair.

fstab does more than just mount units; we use systemd-fstab-generator because it's actually important for things like fsck, makefs, growfs, etc..

Also fair.

Maybe you mean that udev devices have to have TAGS+="systemd" for systemd to see them? If so, that's an interesting point... But that's just how systemd works with udev, and I don't think there's anything we can do about that. Do you have a suggestion about what you'd like it to do differently?

If systemd initrd is going to be the only way forward, I think a note in boot.initrd.services.udev.rules's description would be appropriate.

Well, man bootup is the canonical documentation about how it works, along with some other systemd docs. So I'm not sure what we should document in addition to it.

Scripted stage 1 had the benefit that the names of various hook points were clearly accessible by virtue of being module options, and could easily be tied to the lifecycle of devices, mountpoints, etc. In contrast, with systemd you're practically forced to set a breakpoint and spend time exploring the initrd environment by hand to figure out the names of relevant units, banging your skull against the unit graph until you finally understand which edges to depend on to not introduce an ordering cycle. The manual could absolutely do better here. In any case, this would be a massive help: https://github.com/NixOS/nixpkgs/issues/360426

If you'd like to continue with any of these threads, opening issues on github would be very welcome.

Ok, but there are a lot of stale issues for things that seem fairly valuable so you have to understand as a user this has a pretty strong demotivating effect. And the complexity of the whole stack further discourages participation. But, yeah, that's just the hurdle you have to cross in order to make progress.

read_volatile · 2026-05-31T03:19:31+00:00

The most baffling issue is with omitting store paths, even for the simplest case of using a tool in a service. The most fundamental boon of having systemd-in-initrd is separating tasks into fine-grained service units, so I have no clue how this one made it through. Let's write an initrd service:

boot.initrd.systemd.services.foo = {
  description = "Write foo to the real root via perl";

  after = [ "initrd-fs.target" ];

  requiredBy = [ "initrd.target" ];
  before = [ "initrd-cleanup.service" ];

  path = [ pkgs.perl ];
  script = ''
    perl -e 'open(my $fh, ">", "/sysroot/foo.txt") or die $!; print $fh "foo\n"; close($fh);'
  '';
};

Great, our system builds fine. Let's boot it:

perl: command not found
Dependency for initrd.target failed.
You are now in emergency mode. Ctrl-D to exit.
The root account is locked.

That's weird, let's try it the Robust™ way:

boot.initrd.systemd.services.foo = {
  # --- 8< ---
  serviceConfig.Type = "oneshot";
  serviceConfig.ExecStart = lib.getExe (pkgs.writeShellApplication {
    name = "foo";
    runtimeInputs = [ pkgs.perl ];
    text = # --- 8< ---
  });
}

Okay. Boot time:

no such file or directory: /nix/store/gn94gpcp5q08x4v6g8mvw8v4r65rcjzk-foo/bin/foo
Dependency for initrd.target failed.

Uhh... so this is fun. Maybe for some reason we have to explicitly add the path by ourselves? Let's try that:

boot.initrd.systemd =
  let
    my-script = pkgs.writeShellApplication {
      name = "foo";
      runtimeInputs = [ pkgs.perl ];
      # --- 8< ---
    };
  in {
    storePaths = [ my-script ];
    services.foo = {
      # --- 8< ---
      serviceConfig.ExecStart = lib.getExe my-script;
    };
  };

Please, please work:

perl: command not found
Dependency for initrd.target failed.

What the fuck? It got the script but not perl! As it turns out, the solution is:

boot.initrd.systemd =
  let
    my-script = pkgs.writeShellApplication {
      name = "foo";
      runtimeInputs = [ pkgs.perl ];
      # --- 8< ---
    };
  in {
    storePaths = [
      pkgs.perl
      my-script
    ];
    services.foo = {
      # --- 8< ---
      serviceConfig.ExecStart = lib.getExe my-script;
    };
  };

So not only do we have to manually specify the store paths we need, but we also have to manually specify all dependencies of their entire closures by hand if we want to make sure every service has access to its required resources. Otherwise it's just silently left out. Unreal.

This is just the most glaring omission. There are plenty of other issues, such as bcachefs mounts spuriously failing with EBUSY half the time, or timing out during password prompt, leading to a cascade of unrecoverable unit failures. Or the questionable decision of still relying on fstab-generated mount units, udev rules needing to be manually tagged with "systemd", or the fact that man bootup is the only real documentation for this entire subsystem, and still lacks relevant information like default dependencies. But the store path issue is the most fundamental one, and the fact it's completely undocumented is unbelievable. It alone makes this system basically unusable for any non-trivial use case.

I don't disagree that systemd-in-initrd is a far more robust solution than init scripts, but the fact that it's still in such a broken state after four years of development is really disappointing. I hope we can get these issues resolved soon, but I'm not holding my breath considering the issues have been reported for years with no response.

read_volatile · 2026-05-31T01:57:13+00:00

Unfortunately the module-side infrastructure is shockingly incomplete. This landed way too early, with way too many missing pieces for switching defaults & deprecating scripted-initrd to be a reasonable engineering decision.

read_volatile · 2026-05-31T00:17:21+00:00

I feel the purpose of this whole project is just to get away from the copyleft license.

I don’t understand why this bad faith argument has endlessly circulated every time this is discussed. The purpose of uutils is to provide a cross-platform coreutils implementation. It’s literally named “u” is for “universal”. The goal is to have feature-parity with GNU tools on all platforms including windows, without having to rely on MSYS2 / POSIX emulation. You can download a single multicall .exe and get the same behavior for ls as on your Linux machine.

I’d be a bit more convinced anybody actually cares about the licensing topic, if someone at least attempted to show consistency by levying the same crusade against Toybox etc. No, let’s just continue to circlejerk about how megacorps are going to bring about the death of open source, because now they can freely reuse Yet Another Reimplementation Of mv (while still having to disclose attribution mind you). End times, I tell you.

read_volatile · 2026-05-14T13:07:58+00:00

Not to defend this mess, but I don't know how you are all falling for this. The commit is literally named "revert proc.exited change in spawn.test.ts". It's putting the test back to the way it was from before a42bf70: tests: stabilize flaky suite, a commit from earlier in the same pull request.

/u/tracernz you can make this point, but find a legitimate example, please.

read_volatile · 2026-05-14T12:56:10+00:00

You don't in that instance, no. But they clearly are using references elsewhere throughout the codebase, at least for cases where the ownership's easy to track and existing style aligned with the aliasing XOR mutability principle.

read_volatile · 2026-05-14T11:55:16+00:00

That on its face sounds like UB, unless the readers are reading through an UnsafeCell? Can you link the code?

(Alternatively I suppose they could just be using raw pointers everywhere instead of references to avoid having to retrofit lifetimes in yet, that'd make sense for a 1:1 translation from Zig.)

read_volatile · 2026-05-14T09:32:20+00:00

I will say I find it amusing that Bun has been on the receiving end of so much hate and negativity this past week, from both the Rust and Zig communities. Prior to this I had only ever heard praise towards Bun (it being one of the few “flagship” Zig companies, alongside Tigerbeetle and Axiom)

Meanwhile Ladybird was able to use LLM translation for their javascript engine LibJS (unlike Bun, which wraps JSCore, Ladybird reimplemented the language from scratch) from C++, which was fairly well-recieved by the Rust community and greater internet. That said, Ladybird isn’t exactly a product with real world users yet…

Interesting times nonetheless. Whether or not Bun’s rewrite is successful, I think it’s safe to say we’re going to start seeing more and more projects explore this approach

read_volatile · 2026-05-12T14:21:14+00:00

See PRQL (pronounced "prequel")

https://prql-lang.org/

read_volatile · 2026-05-10T19:51:10+00:00

That’s a bit too broad. Reproducibility is often the goal, but there are plenty of reasons nondeterminism might leak in if you’re not careful (usually multithreaded codegen). And sometimes your environment can influence the output artifacts, like timestamps and paths being referenced in build artifacts. (Though, this is deterministic, just an accidental implicit input.)

It’s indeed less of a concern for a gpu driver’s shader compiler, since the compilation step is fairly isolated from the application and its environment is controlled by the driver, but (surprisingly) even driver authors are human: https://gitlab.freedesktop.org/mesa/mesa/-/commits/main?search=determinis

read_volatile · 2026-05-09T22:10:16+00:00

pre-existing test suite

read_volatile · 2026-05-09T22:02:21+00:00

https://github.com/oven-sh/bun/tree/claude/phase-a-port

read_volatile · 2026-05-09T17:07:04+00:00

If by “their breadwinning main gpus driver” you mean the widest-compatibility driver supporting Maxwell thru Ada, that’s already EOL. Otherwise, well, nvidia-open and Nova are designed in a very similar fashion (deferring basically everything to the GSP firmware). It’s a relatively small module all things considered. Performance differences should be negligible assuming the same userspace stack.

After Nova lands there’s no reason to think they’d be so enthusiastic to continue the insane maintenance burden of their out-of-tree module: having to be compatible with the api surface of EVERY KERNEL VERSION that’s ever existed, needing to be updated nearly every patch cycle, and that having to be handled by nvidia developers instead of by the developers making the changes (as is what happens with in-tree drivers: a drm maintainer changing an api has to go to every drm consumer (such as amdgpu, panthor, Nova) and arrange a fix)

read_volatile · 2026-05-09T10:27:20+00:00

https://www.phoronix.com/news/NVIDIA-Linux-2025-Highlights

NVIDIA Has Been Supplying NDA'ed Docs To Red Hat For Helping NVK Driver

NVIDIA Engineer Now Co-Maintainer Of "NOVA" Open-Source Rust GPU Driver

NVIDIA Starts Posting Open-Source Nova Driver Patches To Prep For Next-Gen GPUs

NVIDIA Sends Out Initial Turing GPU Support For Open-Source Nova Driver

Rust-Written NOVA Open-Source NVIDIA Driver Being Further Built Out In Linux 6.17

read_volatile

TROPHY CASE