I thought that was a solved problem on Linux. Is it the reluctance to use binary blobs?

Yes. For the same reason you also don’t get firmware updates on Guix. Or Firefox.

I feel like it’s actually not that hard… if you can tell what advice is bad and shouldn’t be followed. Which I realize is a major catch-22 for new users.

My honest advice on Neovim (for everyone) is to do this:

• environment.systemPackages = [ pkgs.neovim ];
• Configure Neovim as you usually would (hand-written init.lua, Lazyvim installer, whatever)
• Ignore/Disable Meson and use shell.nix to get language servers and formatters instead (alternatively: enable nix-ld for Meson or Mise)
• Completely ignore all the wrapper garbage like programs.neovim, nixvim, nvf, nixCats, and all the others

The last one is important. You can try all you want to make the garbage work and it eventually will, at least kinda, but IMHO the very idea of what they’re trying to do is bad, ultimately making them a colossal waste of time.

I have less strong but overall similar feelings regarding Home Manager, those newly hyped wrapper managers and libraries, the “Dendritic Pattern”, etc. The NixOS community loves coming up with novel ways to shoot themselves in the foot.

It does, that’s the home.file escape hatch I mentioned. But then you end up paying 10-30 seconds eval for a “config” that looks like this:

{
  home.file.".bashrc".source = ./bashrc;
  home.file.".bash_profile".source = ./bash_profile;
  xdg.configFile.nvim.source = ./nvim;
  xdg.configFile.sway.source = ./sway;
  # ...
}

I suppose there are fringe use cases where Nix attrset merging behaviour is useful, but in the average case I just don’t see much value here.

Yeah that’s a KDE classic. I think I had one KDE version a few years back that had no issues with my dock but it broke on a kernel update. Maybe it’s not entirely fair to blame KDE but I never had the same issues on GNOME, Sway or Niri…

I’m not sure that description makes a lot of sense. Nixpkgs/NixOS is a fairly large community project. Some of the contributors are certainly anti-woke (although quite a few of those were banned from official spaces a while back), and some are MIC employees (Anduril is somewhat infamous with a seat on the so-called “steering council”). That’s not especially unusual by itself, and you can definitely do worse than “one guy is a MIC employee” (just ask the GNU or suckless folks). What is unusual is the very public meltdowns that happened surrounding it, including the moderation team resigning. The community fortunately seems to have survived all of that though.

Anyone curious can read through the most recently active governance related thread and the rest of the discourse meta category. Outside of that the subreddit had an issue with Lunduke spam at the time, but this has since died down (and the posts were removed). I don’t frequent the Matrix (official) or Discord (unofficial) so maybe those are really bad and I don’t know about it, but from my experience I honestly have little to complain about.

There’s a manual, a discourse (forum) and a Matrix. And an unofficial subreddit and a Lemmy community. As well as two wikis and a large number of random people writing blog posts and tutorials.

This might be a hot take but honestly I think the documentation quality isn’t the problem. You can point to specific topics that aren’t well documented but that isn’t unusual. What’s unusual is how NixOS is designed and how working around its quirks requires close to distro maintainer levels of knowledge.

Most distros don’t require several pages of documentation on how to install a Python application. NixOS on the other hand…

This module is actually a bit of a pet peeve of mine and a big reason I soured on Home Manager in general…

You inevitably end up writing chimera configurations like this:

# home.nix
programs.sway = {
  enable = true;
  
  # not supported by module - need to use escape hatch
  # good luck getting your editor to syntax highlight this snippet btw
  extraConfig = /* swayconfig */ ''
    bindgesture swipe:right workspace prev
    bindgesture swipe:left workspace next
  '';
};

programs.waybar = {
  enable = true:

  # can't do that in Nix
  style = /* css */ ''
    window#waybar {
      background: #16191C;
      color: #AAB2BF;
    }
  '';
};

# configuration.nix
# need to enable Sway a second time so the display manager can see it
# this may also install a second Sway if you fuck up your HM setup
programs.sway.enable = true;

and in exchange for this you get:

• 30s+ iteration times for basic changes like keybinds
• No ability to copy paste config snippets from READMEs/Wikis (unless you use home.file/extraConfig escape hatches)
• No ability to edit configuration in scripts (breaks a lot of theming functionality in “shells” like DMS, Noctalia, etc.)
• More ways to write configs that look right but don’t quite work or just do dumb things (extra Nixpkgs imports, duplicated packages, WMs that aren’t visible to the DM, etc.)

Alternatively you could just use a dotfile manager like rcm or stow or chezmoi like everyone not on NixOS+HM and not have to deal with any of this.

Do you have some specific threads in mind? Maybe I’m lucky to never click on the bad ones but my experience is that nobody is more cynical regarding Nix/NixOS jank than the long time NixOS users. You might not always get the answer you want, because it is very jank and doing some things will get you into trouble. But people pointing that out isn’t the same thing as gaslighting.

Guix SD might be worth a look, it seems to be just straight up better in many technical regards. It has no flakes, comprehensive documentation and a blessed way to manage user homes. At least as long as you don’t really need WiFi of course…

Bad RAM is still a thing (even on regular PCs), there’s a reason ECC memory has a market (true ECC, not the stuff that DDR5 has built-in). But I agree that it’s likely just an OOM/Thrashing situation. Linux famously doesn’t handle them very well, and the behavior OP is seeing is very much consistent with that.

If your DE/Launcher uses systemd scopes properly you might be able to see something in the journal. As an example somewhere in my logs I can see this:

Jan 17 17:52:50 sky systemd[2171]: app-niri-steam-40213.scope: Failed with result 'oom-kill'.
Jan 17 17:52:50 sky systemd[2171]: app-niri-steam-40213.scope: Consumed 6h 32min 39.773s CPU time, 9.4G memory peak, 6.2G memory swap peak.

That’s pretty clearly severe thrashing and an eventual OOM event caused by a game. If you’re not familiar, the command journalctl -e -b -1 gives you the last log lines from the last boot. Use d and u to navigate the pager and q to quit. This will only work if the launcher you are using sets up transient systemd scopes and doesn’t just fork-exec into the application (Fuzzel does the wrong thing by default, as do many others).

I’ve also seen large Steam downloads causing such issues, so capping your download speed might help. As could enabling ZRAM.

Edit: Also, this is most likely completely unrelated but do note that Neon is basically abandoned. You should very much consider switching to a maintained distribution, whether that’s another Ubuntu spin or Fedora or something else entirely.

A “pure” function could instead work around it by returning (without executing) a query, accepting a state and returning a new, modified state, or otherwise returning some kind of commands to the caller without directly querying the database.

At least in Haskell due to lazyness this is (almost) always what happens. A monad is just one kind of deferred computation, with an operator >>= (“bind”) that happens to prevent compiler reordering or deduplication. Any IO actions are only executed when main is evaluated and no earlier. Strict functional languages to my knowledge don’t need monads to do IO since they don’t have the same issues with evaluation order that Haskell does (though they might want them for type safety purposes).

Is a database handle you can write to not … basically mutable state, the arch-nemesis of functional languages?

Well, kind of. You would treat it the same way you would treat pipe/terminal or file IO: You write some impure functions that do the actual IO (database calls), and some pure functions that work on your data types. Then you compose them together to make an application. Hopefully most of your code is in the pure part which means you can test it without having to mock the world.

This honestly isn’t all that different from how a well written imperative code bases turn out. You generally don’t want to put all of the IO and all of the business logic into one super function or method or even class, because that makes things really hard to test (and hard to reason about too if you go far enough).

You can have actual in-memory mutable state in functional programming too, you just don’t get it on every variable by default. At least in Haskell you would usually achieve this by using a type that does it for you, like IORef or ST or MVar or TVar. The reasoning above applies to those - You would generally use them sparingly, when you really need mutability (e.g. to pass data between threads), and not everywhere.

These… don’t even remotely solve the same problem?

• (1) AshOS: Package managers are fragile, and partial or broken updates can break systems (up to not booting at all).
• (2) Nix: Package managers need to solve a SAT problem (which may be impossible) to resolve dependencies.
• (3) Distrobox: Containerized programs are annoying to work with.
• (4) Homebrew: Your system doesn’t have a package manager (e.g. MacOS).

Problems (1) and (2) (arguably also (3)) are quite difficult and don’t have trivial solutions. Fedora Silverblue solves (1) but has to jettison a reasonable package manager, creating problem (4) and the demand for Linuxbrew. NixOS solves (1) and (2) while avoiding (4) but at the cost of recompiling the world and breaking SELinux/AppArmor.

I wouldn’t consider running AshOS personally (even ignoring the abandoned status) as any package install or update requires a reboot (a variation of (4)), so the UX doesn’t appear to meaningfully different from just running Silverblue or MicroOS. I have doubts that the design space here has been completely explored, but you have to look back at the mediocre past attempts to understand why they were mediocre.