Oh this is just the thing for playing bard, and casting “vicious mockery” several times per combat

The justification for invading Iraq was a claim that they were developing nuclear weapons. It was well known at the time that the evidence was flimsy, and that even if true it was a flimsy excuse for an invasion. The main piece of evidence was an intercepted shipment of aluminum tubes that were soon shown to have nothing to do with a nuclear program. (See https://en.m.wikipedia.org/wiki/Iraqi_aluminum_tubes). That one is not a conspiracy theory.

This is exactly why we have Reversed Polish Notation. When will people learn?

Oh goddammit! Why doesn’t PEMDAS prepare us for unary negation??

The problem is that the way PEMDAS is usually taught multiplication and division are supposed to have equal precedence. The acronym makes it look like multiplication comes before division, but you’re supposed to read MD and as one step. (The same goes for addition and subtraction so AS is also supposed to be one step.) It this example the division is left of the multiplication so because they have equal precedence (according to PEMDAS) the division applies first.

IMO it’s bad acronym design. It would be easier if multiplication did come before division because that is how everyone intuitively reads the acronym.

Maybe it should be PE(M/D)(A/S). But that version is tricky to pronounce. Or maybe there shouldn’t be an acronym at all.

The parentheses step only covers expressions inside parentheses. That’s 2 + 2 in this case. The times-2 part is outside the parentheses so it’s evaluated in a different step.

The comment from subignition explains that the phone’s answer, 16, is what you get by strictly following PEMDAS: the rule is that multiplication and division have the same precedence, and you evaluate them from left-to-right.

The calculator uses a different convention where either multiplication has higher priority than division, or where “implicit” multiplication has higher priority (where there is no multiply sign between adjacent expressions).

Radium produces the most radiation by miles. The plutonium gives off some alpha radiation that won’t hurt you if you don’t eat it. (Eye protection would be a good idea I suppose.) I don’t remember what U-235 emits but I don’t think it’s a huge amount.

Nice! I was looking for something like this a couple of days ago, and I landed on serokell/nix-npm-buildpackage. But I can see that the adisbladis one has a couple of advantages: it puts each dependency in its own store path so you get more cache hits, and it supports dependencies that want to write to node_modules.

There is also a buildNpmPackage in nixpkgs but it wants a dependencies hash up-front which is not what I’m looking for.

And also asking, how does it compare to a high-yield savings account?

Wow, this is one of the most complicated Snopes analyses I’ve seen. But it seems like the statement is accurate with caveats. If the brightest component of Polaris is probably 50 million years old what was there before wasn’t really Polaris. And then it doesn’t make a difference whether sharks have been around for 450 million or 195 million years.

Oh very nice - thanks!

After some more digging I think I figured it out.

I was trying to use nix repl nixpkgs to interactively query packages. But I forgot that that command loads the flake, not the package set. You have to prefix everything with legacyPackages.x86_64-linux. to access packages in this environment. I got better results running nix repl followed by :l angle-bracket nixpkgs angle-bracket. (Btw the repl tells me how many variables have been loaded. Is there a way to list them? That would be helpful.) (Edit: nix repl nixpkgs#legacyPackages.x86_64-linux also works)

I eventually found https://github.com/NixOS/nixpkgs/blob/35d87899f7c8f6fad50447301465d51b5dd87753/doc/languages-frameworks/rust.section.md?plain=1#L18 which tells me that what I want is pkgs.rustPlatform.buildRustPackage

I would still like a way to search for nested attributes.

The other gotcha I ran into was a problem with volume permissions. This is on NixOS running MongoDB. This might not be a problem with other services. The Arion doc example for volumes has you store the volume in a repo directory. Here is what I tried:

{
  services.mongodb = {
    service.image = "mongo:6-jammy";
    service.volumes = [ "${toString ./.}/mongo-data:/data/db" ]; # <-- volume defined here
  };
}

When I tried this the volume data in my repo directory is owned by avahi, and is not readable by my user account. Subsequent arion commands fail trying to read those files.

This fix is to let docker-compose manage the volume for you:

{
  services.mongodb = {
    service.image = "mongo:6-jammy";
    service.volumes = [ "mongo-data:/data/db" ]; # <-- volume defined here
  };
  docker-compose.volumes = {
    mongo-data = null; # <-- this name matches the volume name referenced in the mongodb service
  };
}

I noticed that Arion has an interesting option, useHostStore = true, for services that are defined using a command or a nixos config instead of a Docker image. This mounts the host system’s /nix/store directory in the running container. It looks like the image that gets produced is only a customization layer with the command to run, environment variables, etc. It looks quite efficient.

I haven’t checked, but I’d guess that if you don’t use useHostStore you get layered images. Those are great for image layer reuse, but they do involve copying store paths to the local image repository.

Sitting in an airplane takes me to the same headspace I was in the previous time I was on an airplane - it feels like I pick up my train of thought right where I left it months earlier. So yeah I can see how the aircraft door is a significant threshold.

Oh yeah, the need for parenthesis often has me scratching my head for a bit

You might simplify it a bit with something like,

let my-hello-scripts = [
  (writeShellApplication {
    name = "my-hello-1-script";
    text = "echo my hello world 1";
  })
  (writeShellApplication {
    name = "my-hello-2-script";
    text = "echo my hello world 2";
  })
];
in
{
  environment.systemPackages = 
    my-hello-scripts ++
    [ pkgs.whatever-else-you-want ];
}

I have a recurring task called “rotate butter” scheduled once a month which seems about right to me.

I can at least try to define the concepts I mentioned in my comment.

• store path is a directory or file in /nix/store/. It has the format /nix/store/--. Every installed package gets a store path. There is other stuff too - if you use flakes each flake and each flake input are copied to a store path before being evaluated. IIUC certain directories within each store path are treated specially. For example if a store path has a bin/ directory, and that store path is included in your user “profile” of installed packages, then everything in that bin/ directory is automatically symlinked to your profile bin/ directory, which is in your $PATH. For example,

$ which git
/home/jesse/.nix-profile/bin/git
$ ls -l $(which git)
lrwxrwxrwx 62 root 31 Dec  1969 /home/jesse/.nix-profile/bin/git -> /nix/store/nqdyqplahmhdgz8pzzd5nip17zf3ijzx-git-2.40.1/bin/git

• derivation is a value in the Nix language that represents one or more files that could potentially be written to a store path. Specifically a derivation is an attribute set (the Nix term for a dictionary/object) with certain special attributes/properties. A derivation contains all the information necessary to produce some files to go into a store path (often by downloading or compiling something), and also contains the specific path that those files will be written to. When you access a package in a Nix expression, such as nixpkgs.git, the value you get is a derivation. But you can also make derivations yourself using functions like stdenv.mkDerivation or writeShellApplication. I think you can even write an attribute set from scratch if you want to.

To get from a Nix attribute set to a set of files there is a process called instantiation that is separate from evaluation of Nix expressions. (By “expressions” I mean Nix programs, anything in a .nix file.) Certain Nix programs will evaluate a Nix expression, read a derivation that the expression produces, and do the instantiation to actually create the files. As I mentioned the derivation includes all of the information necessary to do this. Part of this process actually serializes each derivation to a file in /nix/store/ - that’s what the .drv files in there are. Those are very-specialized scripts that produce store paths.

• package is I think a less-specific term for a derivation or a store path. Maybe there is an implication that a derivation that is a package comes from a software repository, or includes either executables or libraries. (Derivations don’t necessarily have to provide executables or libraries - they can represent any file or directory of files.)