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:
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.
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.
This only works when the completion buffer is selected though (e.g. via completion-auto-select). I'm not really sure how to get useful backtab behavior in the minibuffer itself.
Edit -- These bindings might be worth trying as well if you don't like the auto selection:
Every blog post like this contains a bunch of new variables I've never heard of but always wanted. Like help-window-keep-selected or window-combination-resize.
Putting that aside though, am I the only one who likes the built-in completions buffer?
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).
There's probably a combination of magic command line flags that allows podman/distrobox to work, but we honestly shouldn't need containers for this at all.
It's frustrating how we have all the pieces to make this work, but they just don't come together properly:
Brew isn't sandboxed and pollutes the environment
Nix isn't sandboxed and can't prefix install (also the DX with Nix really sucks)
Guix is like Nix but without the packages
Flatpak doesn't have the packages
Snap is proprietary garbage
Maybe this is a hint that I should write my own package manager, with blackjack and hookers that works like Nix, but doesn't hardcode /nix/store, runs everything in bubblewrap and works with SELinux?
The only strong holdout is glibc (musl is no match, and doesn't pretend to be anyway).
Chimera Linux patches musl to use mimalloc and that allegedly mostly closes the performance gap. With notable glibc stronghold systemd supporting musl in recent versions I wouldn't be too surprised if it catches on eventually, like clang arguably already has.
I appreciate the work ahead of time, and the law is the law.
@svartkanin raised this PR internally within staff channels, and the feedback is that we'll wait until there's an overall stance from Arch Linux on this before merging this, and preferably involve legal representatives on this matter on what the best way forward is for us.
But from a personal reflection it's clear that there's a disconnect between law makers intent and how things like this will be implemented in reality, and once a law is in place - we might have to implement inconvenient things..
So I'll leave this open for now, but I'll also lock the conversation because experience from the mailing lists on this topic has told us this thread will get out of hand quickly.
@dylanmtaylor: this stance does not mean that we won't merge this. And despite locking this thread, I think you, me and other contributors and maintainers can still comment (which is fine, and good).
I can at least think of a few counterexamples:
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?
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
/run/current-system/sw/bin/rebootactually would work, although it relies on your system closure containing arebootbinary. That's a reasonably safe assumption to make on a NixOS system, but you might not want to do this with other packages.The reason that doesn't work is that the structure of packages and the structure of a NixOS fiile system are different. Consider this:
So the systemd package in the nix store has a
binsubdirectory containing its binaries. However:NixOS doesn't, at least not really (
/bin/shmust exist because thesystemsyscall 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:More accurately, building a NixOS system creates a sort of meta-package that contains a link farm to all installed binaries in the
sw/bindirectory, and that meta-package is symlinked to/run/current-systemat activation/boot. (Not all package contents are symlinked into this meta-package, also see the NixOS optionenvironment.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:
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:
The NixOS search can also search for binaries. It seems that
busyboxalso provides arebootwhich 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?
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
evalModulescall 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
evalModulesand also imports all the modules. As isflake-partsif you use that (though in that case the set of modules is small so you it's much less noticeable).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
evalModuleswould 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.
Shift-Tab just does the correct thing for me on Emacs 30.2. That might be a newer default though.
I think on an older version something like this should do it:
This only works when the completion buffer is selected though (e.g. via
completion-auto-select). I'm not really sure how to get useful backtab behavior in the minibuffer itself.Edit -- These bindings might be worth trying as well if you don't like the auto selection:
Every blog post like this contains a bunch of new variables I've never heard of but always wanted. Like
help-window-keep-selectedorwindow-combination-resize.Putting that aside though, am I the only one who likes the built-in completions buffer?
I like that it doesn't move the modeline up for completion and that it feels like shell completion. It also works for completion at-point.
The variable
completion-auto-selectis load bearing for my workflow though, before I knew about it I very much thought I needed icomplete or vertico.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
/homeand/runinto thesandboxchroot, 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/homeaccess you wouldn't be able to write to the filesystem and without/runaccess 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$HOMEaccess), 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.
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.
This unfortunately gets misunderstood a lot, mostly because of the stupid flake hype. You do not need flakes for reproducibility, Nix comes with a
fetchTarballbuiltin 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).
Would you mind elaborating on that? I do have some suspicions but I would love to hear what bothered you about it.
There's probably a combination of magic command line flags that allows podman/distrobox to work, but we honestly shouldn't need containers for this at all.
It's frustrating how we have all the pieces to make this work, but they just don't come together properly:
Maybe this is a hint that I should write my own package manager,
with blackjack and hookersthat works like Nix, but doesn't hardcode/nix/store, runs everything in bubblewrap and works with SELinux?This was already posted three hours ago.
Chimera Linux patches musl to use mimalloc and that allegedly mostly closes the performance gap. With notable glibc stronghold systemd supporting musl in recent versions I wouldn't be too surprised if it catches on eventually, like clang arguably already has.
Sounds reasonable to me
You also see Common Lisp on occasion, like in the browser Nyxt or the editor Lem.