The problem with using decibels is that since it is a relative unit you need to know what it is relative to, and that is often not just the unit but also the quantity. Unfortunately, this part is (as expressed) at times omitted or put in the wrong place. And its often also the engineers in the respective fields that keep using this incorrect notation spreading the confusion for those outside the domain.
E.g., acoustic engineers often write db(A) for A-weighted sound pressure levels. Yes, it is often noted this way, but it is incorrect. The correct way is to specify the quantity and that the quantity is A-weighted, `L_{p, A} = 80 dB` for example to express an A-weighted sound pressure level of 80 dB.
Regarding sound pressure and sound power. Sound power is not expressed using A-weighting because it does not make sense. Sound power is a property of the source. A-weighting is a property of the receiver, that is, the human listener.
The speed of sound is the square root of a modulus over the density where the modulus for a gas is the bulk modulus. The funny thing with vibrations is that it is not the density that primarily determines the change in speed of sound, but actually the modulus. Both typically change with temperature, however, the change in modulus is typically larger than the change in density and hence it dominates.
To improve the COP you need a gas with a high ratio of specific heats and low Prandtl numbers. The Prandtl number is the ratio of viscosity to thermal diffusivity. Helium works fairly well for this, though adding xenon, argon or krypton improves it even further.
Really cool to see a company getting this in the market. I'm surprised though to see a standing-wave device instead of a traveling-wave device.
This is indeed not very good. Note there is a reason that overridePythonAttrs exists: it overrides the call to buildPythonPackage instead of mkDerivation. There is/was an RFC on standardizing overriding in Nixpkgs but it got stuck. I think for these things to improve what is really necessary is funding to improve Nixpkgs. These kind of issues are fairly hard to solve as they span multiple ecosystems and require coordination.
What we need is to be able to use a resolver such as included by pip or poetry, to build up our package set. In Nixpkgs this is nowadays unfortunately done manually, and I suppose the same goes for Guix. In Nixpkgs the reason is simple: too eager pinning makes it impossible to resolve a package set that works with the entire set.
Now that pip has a resolver what is needed is a way to use constraints not to set only lower and upper bounds, but to enforce a version when resolving. That makes it usable for downstream integrators to construct their primary package set. One could then even make the next step and construct "stable" sets that extend the primary set.
Thanks! I was only aware of Nimble. I'll have a look at it.
One thing I noticed right away that it seems to be lacking (judging from the `nimph.json` assuming that is the lock file) are checksums over the data or hashes of revisions the references correspond to. References such as tags are mutable, and thus hashes are needed to validate them. See e.g. the discussion over at https://github.com/NixOS/nix/pull/3216.
For a while now I've been looking at using Nim, and this weekend I did my first project with it: a tool for creating binary wrappers. In Nixpkgs we often create wrappers, but those have thus far been shell scripts causing trouble at times on e.g. OSX. https://github.com/NixOS/nixpkgs/pull/95569
I found it easy to get up to speed and do something useful with it. The language is also in my opinion very readable. The documentation could use some more (larger) examples though.
For this wrappers tool I needed a front-end for which I wanted to create an interface with argparse. Unfortunately the standard library lacks an implementation, and third-party packages did not deliver what I needed. In the end I wrote that part in Python still.
The biggest issue I currently find is the lack of a lock file format for its package manager. It's being developed, and as soon as its there I intend to implement support for it in Nixpkgs. https://github.com/nim-lang/nimble/issues/127.
The compiler gives very useful output and is fast as well, and the generated binaries are small. I like this language!
Yet another format for self-contained executables, and one that looks pretty similar to the already existing AppImage.
Note that Nix users can use `nix-bundle` to create AppImages of all the software in Nixpkgs, which is according to Repology one of the largest and freshest package sets:
https://repology.org/statistics