I suspect that is something specific to Ecosia, that they changed parameters from time to time which changes the entry, making your selected one no longer available, and then this happens: https://support.mozilla.org/en-US/kb/search-engine-removal
The fact that they announce Ecosia now after it's been available for a bit, makes me think this is what happened. I'll see
Cool stuff, now of Firefox didn't switch back to Google every major update or so, that would be great... because I actually do have Ecosia selected and need to switch back to it every once in a while because hey why not
It's kind of in line with their plan to get rid of OCSP: short certificate lifetimes keep CRLs short, so I get where they're coming from (I think).
90 days of validity, which was once a short lifetime. Currently, Google is planning to enforce this as the maximum validity duration in their browser, and I'm sure Mozilla will follow, but it wouldn't matter if they didn't because no provider can afford to not support chromium based browsers.
I was expecting that they reduce the maximum situation to e.g. 30 days, but I guess they want to make the stricter rules optional first to make sure there are no issues.
How do the results from ddg match the query? It doesn't look particularly helpful to me, and if not, why would I prefer to wade through a number of results that are ultimately unhelpful?
In the same way words like "antique" and "vintage" bring about specific time periods and aesthetics, "retro" does as well.
In my opinion, "retro" gaming is a misnomer and "vintage" is more fitting for what people usually mean. Retro is something modern or recent made in an older style. Actual old stuff is "vintage". So a game like UFO 50 is actual retro gaming; of course the definition gets more fuzzy when you look at ROM hacks that don't even work on the original hardware of the base ROM. But if you buy an original old console and play the games from back then, that's not really retro by the original definition.
Yeah, they provide a reproducible environment for the modules.
However, one should know that there is a catch which can make flakes believe differently on different machines when updating inputs. That is when you have inputs in your flake that point to your flakes registry. Especially the system entries can trip you up
NixOS is probably the or one of the distributions where you need docker the least.
That's not to say you shouldn't use it, but it makes less sense to me than on other systems, and you lose out on some of the good stuff from what I understand (no module system configuration for imported docker containers for example? I have never tried this).
You can already manage your dependencies very accurately with Nix, no need to ship them all in a container; and if you use containers for isolation, there are stronger mechanisms available, e.g. MicroVM.nix.
It's not only adding one character, which is also probably why this doesn't have a proper alias. Before, it was a single package providing multiple fonts; now, it's an attribute set providing multiple packages, providing one font each, with the name changed from before (in my case "SourceCodePro" became "sauce-code-pro")
nerdfonts = throw "nerdfonts has been separated into individual font packages under the namespace nerd-fonts"; # Added 2024-11-09
It would also only make limited sense because the package definition has changed so that aliasing nerdfonts to nerd-fonts would still break if you chose individual fonts.
You will only see the changes after your <nixpkgs> has been updated (which for you is still the nixpkgs state of a week ago), so not right now. Or maybe this option was always there? I don't know and I'm tired. Anyhow, when unstable gets updated and your evaluation complains not finding the package, you know where to look ;)
nixos-unstable{,-small} are both rolling NixOS channels. The difference between them are the requirements for updates. Both need a specific set of packages to build successful and pass the tests on hydra, the central build server. The jobset for nixos-unstable is https://hydra.nixos.org/jobset/nixos/trunk-combined if I'm not mistaken; nixos-unstable-small is https://hydra.nixos.org/jobset/nixos/unstable-small. Small, as the name implies, has a smaller jobset.
That's also the reason I had to rebuild so many packages: while unstable provides most (I think all redistributable ones), nixos-unstable-small only builds a subset of packages like the kernel, coreutils etc (I don't actually know what constitutes it exactly); and the packages it didn't build, you can't download, which means if you have others installed, you need to build them yourself. It happen automatically, NixOS is a source-based distribution after all and binary packages are just substitutions, but this was a bit of a pitfall.
Edit: By the way, to get the new names of the fonts I did something like this:
Don't hit enter after the dot, but rather press TAB to make the REPL show you the available packages inside that set. The nix-repl> doesn't need to be entered, just signifies that this is no longer in your normal shell, but inside the REPL.
If I had a different specialisation, I'd probably care. But my job is mostly reading and writing documents, and they installed Miktex on my office machine, so I don't want to complain.
We do have formal security requirements to meet though, and I think in general locking down machines in your network is the correct choice. But it's probably not needed in every job
I suspect that is something specific to Ecosia, that they changed parameters from time to time which changes the entry, making your selected one no longer available, and then this happens: https://support.mozilla.org/en-US/kb/search-engine-removal
The fact that they announce Ecosia now after it's been available for a bit, makes me think this is what happened. I'll see