I can at least think of a few counterexamples:

• Cats live longer than dogs.
• Small stars live longer than large stars (by dramatic amounts).
• Black holes larger than the ~10^10 kg mark shown here live a lot longer than any other object with the same mass. A hypothetical moon mass black hole can most likely outlive every single star in the universe.
• Protons are smaller than anything in this chart yet are believed to decay over an extremely long time scale (>10^34 years).
• Even smaller particles like electrons likely live forever.

just seems like extremely poor communication and more "open letter" bullshit that's really a nothing burger. Seems like one or two people said "we're disbanding!" while based on some threads I've read the remaining team was like "yeah...we really didn't want to"

There is no remaining team. The two people who are resigning here are the entire team (originally it was four members, but two had already resigned previously). What's the point of having a team without any members?

just privately quietly resign

How are you supposed to "quietly and privately" resign from a community project that versions team membership and responsibility in Git? Genuinely, what are you imagining that is lower profile than this and not wildly irresponsible?

just swapped it to remove the ${pkgs.coreutils} but i suspect thats not right either

Just /run/current-system/sw/bin/reboot actually would work, although it relies on your system closure containing a reboot binary. That's a reasonably safe assumption to make on a NixOS system, but you might not want to do this with other packages.

the path i used was the output of which reboot

The reason that doesn't work is that the structure of packages and the structure of a NixOS fiile system are different. Consider this:

$ ls -l $(readlink $(type -P reboot))
lrwxrwxrwx 33 root root 9  1. Jan 1970  /nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot -> systemctl

So the systemd package in the nix store has a bin subdirectory containing its binaries. However:

$ ls -l /bin/reboot
ls: cannot access '/bin/reboot': No such file or directory
$ ls -l /bin/*
lrwxrwxrwx 1 root root 74 Aug  1 06:31 /bin/sh -> /nix/store/dddwfz7nph37q3cjky9lhpy9kb90rrrx-bash-interactive-5.3p15/bin/sh

NixOS doesn't, at least not really (/bin/sh must exist because the system syscall uses it). Instead binaries for "installed" packages (the technical term would be "packages which are part of the system closure") are symlinked to /run/current-system/sw/bin:

$ type -P reboot
/run/current-system/sw/bin/reboot
$ ls -l /run/current-system/sw/bin/reboot
lrwxrwxrwx 9 root root 66  1. Jan 1970  /run/current-system/sw/bin/reboot -> /nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot

More accurately, building a NixOS system creates a sort of meta-package that contains a link farm to all installed binaries in the sw/bin directory, and that meta-package is symlinked to /run/current-system at activation/boot. (Not all package contents are symlinked into this meta-package, also see the NixOS option environment.pathsToLink.)

Putting that together with what string interpolation of packages does... well, you kinda just have to look at/know the contents of the package you are referring to:

$ nix repl
Nix 2.34.8
Type :? for help.
nix-repl> pkgs = import <nixpkgs> { }

nix-repl> "${pkgs.systemd}/bin/reboot"
"/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot"

nix-repl> "${pkgs.systemd}/run/current-system/sw/bin/reboot"
"/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/run/current-system/sw/bin/reboot"

One of these paths exists, the other doesn't.

Side note: You're looking at the old and mostly abandoned wiki, don't use that. There's an official wiki which is better. This particular article happens to be the same in both, but the old wiki also has tons of outdated and terrible articles like For Beginners or NixOS Woke Invasion.

For installed packages, you can use readlink:

$ readlink $(type -P reboot)
/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot

The NixOS search can also search for binaries. It seems that busybox also provides a reboot which I guess might be useful for weird systemd-less deployments?

If you want to search for any file across all packages, there's also nix-index, which scrapes Hydra for output files and builds a database which you can then query with nix-locate.

Technically yes but tabs are modal: You have to leave the tabbed mode to look at more than one window at once, and then the third window that opens will cause one of them or both to resize. Then you need to fix that by moving it to a new workspace or the tab container.

The idea is that with scrolling, resizing is always manual. New windows will never resize any existing ones, independent of any "mode" or which element you have focused.

It's not for everyone (personally I realized after a few months that I did not actually like scrolling, I just put up with it), but I do think it's a comparable paradigm shift as going from a stacking WM to a tiling one. Sure you can create tiling layouts on almost all stacking WMs fairly easily with simple mnemonic keyboard shortcuts, but using it feels different, if that makes sense?

I'm sorry but what are you talking about? How is this random GNOME extension related to DHH (who does not even use GNOME if that isn't obvious)? How does that relationship poison the concept of scrolling window management? Is Drew DeVault a fascist because he made Sway which works vaguely similar to Hyprland, which was made by a fascist?

In my world that kind of transpilation should be instant.

Well, as you've guessed, it's not really just a transpilation. A NixOS rebuild evaluates significant parts of Nixpkgs, <nixpkgs/nixos> as well as your configuration from scratch (technically flakes have evaluation caching, but it's not fit for purpose).

Nix isn't a fast language to begin with, but the evalModules call that actually takes your configuration and turns it into a package that can be built is very expensive. Because NixOS imports (almost) all modules by default, it has to do deep merges of most of <nixpkgs/nixos>, which amounts to almost 32 MB of Nix code. Everything else is a rounding error compared to that.

Oh, and it has to do this for Home Manager too, because Home Manager is also built on evalModules and also imports all the modules. As is flake-parts if you use that (though in that case the set of modules is small so you it's much less noticeable).

How much of speedup would it yield to rewrite Nix and/or home-manager in a faster language like Zig or Rust?

It would probably make the performance worse before making it better. Nix is slow but it's not because of the implementation language (which is C++), you would have to do actual interpreter engineering (e.g. writing a JIT) to make an interpreter much faster than the current one.

A builtin (C++ instead of Nix) implementation of evalModules would probably help, but nobody wants the versioning headaches that would come from that. I'm also not sure it would do that much, the amount of data is just massive.

A more promising optimization is to make NixOS not import all the modules by default, but efforts to do this haven't really gained traction. Probably because you pretty much have to check all modules for cross dependencies.

As a user the best thing you can do right now is using Home Manager standalone and not as a NixOS module. That way, while switching generations will still be slower than it really should be, at least it won't evaluate and merge all NixOS modules every time you change your mind about a background color.

You can also use a non-Nix-based dotfile manager and forego Nix evaluation (and building) entirely. The only thing you really lose is being able to remote deploy dotfiles with things like nixos-rebuild build-vm.

That is basically what the EUPL is.

In the sense that allowing a malicious application to steal your SSH keys is "fixing", yes.

This is interesting, but I wouldn't consider this to be at all comparable to Flatpak. From what I can see the only purpose of using bubblewrap here is the dependency isolation (without having to recompile the world ala Nix), which does have some value but it feels misleading to even call it a sandbox.

It mounts /home and /run into the sandbox chroot, which means that "sandboxed" applications can do things like reading your SSH keys, dumping your keyring or escaping the sandbox via write to .bashrc (so most of the attacks you'd want to prevent). This is presumably done because without /home access you wouldn't be able to write to the filesystem and without /run access you can't even display a graphical window, which would make the packages quite useless.

XDG Desktop Portal solves this by allowing filtered dbus access controlled by package metadata (/.flatpak-info), and then having sandboxed applications use portals to access files, secrets and other resources. The metadata is a major flaw in Flatpaks design (note that a lot of the most popular Flatpaks want full $HOME access), but it's also what allows Flatpak to be useful. In this project, there's no metadata since the packages just come from Alpine repositories.

I haven't heard of Coldbrew before, it looks very interesting.

The unfortunate thing about snap is that of all options, it is the most capable. You get GUI, CLI, server, full filesystem access if needed (aka classic snaps). But Canonical really drags the project down and handicaps it with poor decisions.

That's also how I feel about it. I've heard many good things about it technically, but Canonical really killed its adoption outside of Ubuntu.

Then you look into it a bit more and the story changes to "oh actually you need to enable this experimental feature to get better reproducibility".

This unfortunately gets misunderstood a lot, mostly because of the stupid flake hype. You do not need flakes for reproducibility, Nix comes with a fetchTarball builtin function which allows you to pin a specific Nixpkgs commit and output hash.

You're right though, I agree on basically every point (including the part about flakes).