For me, one of the most important features of a configuration language is the ability to directly refer to other values of the configuration, and more importantly, in the case of a configuration split in separate modules, to refer to values that could be provided by the other modules.
Essentially, this means that the final configuration should be the fixed point of a function, that the user would provide the configuration as a definition of this function (or in the case of multiple modules, as multiple definitions that would be merged using function composition), and that the evaluator would be able to determine the fixed point of this function.
I feel like this kind of configuration (used notably in NixOS) provides a lot of what's missing in traditional configuration languages, makes it easier to compose configuration modules, without requiring to write the configuration in a Turing-complete language.
In magnetic confinement reactors, the runaway neutrons collide with the reactor's shielding and can make it radioactive by neutron activation. I don't know if it's the same for inertial confinement, but I suppose it could be an explanation.
I prefer calling a graph "colored" rather than "with a labeling of the graph’s vertices with labels such that no two vertices sharing the same edge have the same label". Sometimes my graph being colored will be a problem, sometimes it will be a good thing.
Note that is just a parallel with colored functions, the "colored" word does not mean the same thing here (the meaning of "colored" in graph theory has little to do with the one used in programming).
Nonetheless, if I think that using this word is upsetting to some group of persons, whether I understand their reaction or not, I try to avoid using it. On the Internet it's difficult, because we're addressing ourselves to a very large potential audience.
> Finally,Java performs best on this benchmark; we can see whilerunning the benchmark that it can run the G1 collectorfully concurrent on another core.
I hope this is good news for the Blender Development Fund, but I'm scared of the possible consequences. I suppose we may end up seeing Blender Cloud offering remote renders using AWS's infrastructure, which is good news unless it means tying the rendering engines to Amazon tech.
For context, here is a brief overview of the 2019 financial report of the Blender foundation :
- 33% of income (316 k€) from individual sponsors
- 28% of income (267 k€) from EPIC Games
- 27% of income (257 k€) from other corporate sponsors
- highest salary: 58.4 k€
- lowest salary: 32.5 k€ (55% of highest)
- 43% of expenses (416 k€) were salaries
I really like Blender, and seeing it thrive in the last years has brought me immense pleasure. I hope that I have the chance to work with Blender again, and benefit from the recent improvements.
Congratulations to the Blender Development Fund for this new sponsor, which I hope will bring value to the project.
I'm using this setup, and I still get cookie/ToS banners all the time, especially using Google (I think I'm accepting their new terms of service 4/5 times each day).
This is exactly what I thought 3 years ago when a dentist told me that it was very important for me to get rid of my wisdom teeth, because loss of enamel meant that they were very likely to decay quickly even with proper hygiene. Other dentists told me that it was not necessary, and could be done later if the teeth ended up decaying too much.
Now the teeth are completely decayed, I've started to feel severe pain, and since I've developed severe thrombopenia (<20 G/L), I can't get them extracted easily (couldn't find any dentist willing to take that risk), so since six months, I have to take anti inflammatory drugs for the pain and antiobiotics to limit the infections, as well as the folic acid and corticosteroids needed for ITP, and I have no idea when will this end.
It's very difficult to differentiate important advice from "easy money" advices, especially when this advice stems for a principle of precaution. Most peoples don't develop severe ITP, but if they do, getting wisdom teeth removed before they can cause problems can be very important.
It depends on many factors (teeth being devitalised, expected complications during the surgery, and other non-teeth related factors as well). Some people do get a local anesthesia (not knocked out), others have no choice.
I find it very unfortunate that file metadata is not encrypted : if you need this to be encrypted, you need to stack LUKS on top of ZFS, and you lose many of the benefits of ZFS (per-dataset encryption, healing ability, RAIDz, etc) while doing so. Running ZFS->LUKS->ZFS to recover some of these benefits is also not feasible at all (ZFS doesn't like to self-host, even through a virtual machine).
> The Filesystem Hierarchy Standard (FHS) defines the directory structure and directory contents in Linux distributions.[1] It is maintained by the Linux Foundation.
As said by the other commenter, most of these patches are caused by NixOS not using the FHS (except for /usr/bin/env), which can be considered as a good thing in itself. In an ideal world, it would not be a problem (programs should not assume anything about the filesystem hierarchy, and should always use $PATH or their own environment variables).
The issue of integrating with other language ecosystems is indeed very problematic (and it's a very hard problem), especially with regards to the chain of trust (by the way, it's not completely broken, you can still read the original package hash in the derivation, and evaluate this derivation to get the Nix derivation hash), and with regards to the fact that including all of the packages of every ecosystem in `nixpkgs` is not doable.
There is also the (related) problem that evaluating a configuration implies evaluating `nixpkgs` itself, which requires a good amount of available memory, and this can only get worse as `nixpkgs` grows.
There are lots of things to be said about Nix and NixOS, and many of these things have been mentionned in this page, but there's one thing I really like with Nix : the fact the the configuration is expressed as a function that takes its own result as argument, and that the final configuration is the fixed point of that function. This is a very powerful concept, as these functions can be composed together.
I think this idea is not specific to Nix, and I wish it was used a lot more in configuration languages. For example, it was something I really missed when using Ansible. The lack of this feature means that writing the inventory is much harder than it needs to be, and I've seen horrible hacks that try to get around this.
Steam itself works pretty well, but I've had many games just inexplicably segfault on startup. It's weird because I get the same segfault:
- using steam-run
- in a FHS user environment
- in an LXD container (on this NixOS host) running Debian 10
The same games run fine on a Debian 10 host, all of the libraries the link to are bit-identical to the ones in the LXD container, and I've even tried running the exact same kernel.
I'm lost here, as I feel like I've made everything match (at least in the LXD container): the kernel is bit-identical, the games are bit-identical, the libraries they link to are bit-identical. There must be something I'm missing.
The page you linked takes 8s to display on my browser, even on subsequent reloads, just because I don't allow third-party scripts. It also has no displayed images, for the same reason. I really don't wish more sites were like this.
For me, one of the most important features of a configuration language is the ability to directly refer to other values of the configuration, and more importantly, in the case of a configuration split in separate modules, to refer to values that could be provided by the other modules.
Essentially, this means that the final configuration should be the fixed point of a function, that the user would provide the configuration as a definition of this function (or in the case of multiple modules, as multiple definitions that would be merged using function composition), and that the evaluator would be able to determine the fixed point of this function.
I feel like this kind of configuration (used notably in NixOS) provides a lot of what's missing in traditional configuration languages, makes it easier to compose configuration modules, without requiring to write the configuration in a Turing-complete language.