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.
Oh, of course, and in my case it was an important discovery, because my custom packages were all also defined in terms of my own mkDerivation-wrapping function, so I happily copy-pasted the definition of overridePythonAttrs to make my own overrideMyAttrs version of it.
But it was brutal that I had to just stumble across this. I think the article correctly identifies that there is decent enough documentation in Nix for:
- Beginners to the nix language/concept (Nix Pills)
- Beginner users of NixOS (the NixOS manual)
- Beginners to packaging for Nix (wiki articles, blogs)
But there is a huge, huge gap for the user who is trying to cross the chasm and become a true expert in it all— who wants to understand at a deep level things like how overlays and namespaces work, how bootstrapping works and what is the division of responsibilities between nix and nixpkgs, plus the inner workings of things like buildEnv and stdenv.
I mentioned it already below, but just to emphasize: I think Burke Libbeys playlist on Nix [1] is that missing piece. It lays down a solid foundation of understanding on what Nix is both conceptually and syntactically. You are then able to derive the rest of the needed understanding by clicking through the nix source of whatever it is you are trying to figure out.
As someone who really likes the idea of declarative system configuration and management, shares the vision of nix and guix, and have been dipping my toes by using nix package management on macos (and sharing most of the experiences mentioned upthread):
I do thank you for the pointer, and I think I've come across these videos before, _but_ to me, video is probably the last format I can assimilate this type of information. Usually, in my experience, well designed systems have a way of making sense so that documentation and understanding flows naturally from base abstractions, and this is something I miss in nix. I would like to try guix to see whether that makes more sense to me, but I am hesitant given that nix seems to have so much more of the mindshare.
One day I'll try to give the video tutorials a chance, maybe it will clear things up. Thanks again and thanks to mr Libbey as well.
> well designed systems have a way of making sense so that documentation and understanding flows naturally from base abstractions
Honestly, thats the main revelation I had when going through that playlist. Basically Nix is just attribute sets (which is sort of just a JSON object). The entire thing. Nix files are just some preamble and then they return an attribute set at the end. Understanding that will get you 90% of the way there in terms of understanding the syntax and being able to cut through the "weirdness".
At that point its about understanding actual concepts like overlays, derivations, etc but its much easier now that you understand the attrset concept.
I hear you, I think I understand what you mean and I definitely want to believe you, but how come this can't be explained in a succinct written documentation, instead of a series of video tutorials by example?
I do realize it's a work of passion done by numerous volunteers, to whom I feel gratitude, but at this point, why can't this be adequately defined, in a written form, in a way that is understandable? To me, the concept of a series of projections of declarative configuration statements onto a final state is not hard to understand in itself; yet, I am somewhat struggling to create and maintain such a configuration without feeling that I am just copypasting bits and pieces from random people.
I guess I just have to bite the apple and spend a few days watching YouTube to see if I reach enlightenment - at this point, I barely understand the function names.
Yeah like I said, I struggled for a couple _years_ on having a feeling of complete confusion when copying a shell.nix to every project I spun up. I was never able to understand _any_ of the written documentation. After that playlist I easily click through the actual nixpkgs repo itself and find almost everything I need to handroll my own derivations.
It seems like the community is just a bunch of people who have had that lightbulb go on already, so its hard to go back and view things without the lightbulb on.
The language reference worked out fine for me but the chasm between "basically running" and "knowing what I'm actually doing" has been substantially painful and I'm still not on the other side.
Though I say this while continuing to slog through said pain as I find time because once I've learned a particular thing it's always felt like it was worth the effort to get there.
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.
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!
If you use the TinyCC/tcc back end then compiling is nearly instant (I use the "tcc mob branch" all the time). You can even put a shebang at the top of your file (#!/usr/bin/nim r) and have an edit-run cycle similar to scripting languages, just a tiny edit toward "nim c -d:danger foo.nim" the file to get a production/deployment performance self-contained binary.
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.
