There’s no way to even attempt to answer your question without the actual code

There’s no rack mount server there. I see a UPS, switch (network and Nintendo varieties), PS4 and mini PC

I’m… Not really sure what your question is. What do you mean by your laptop “fitting in the community?”

Why would anyone stop using those standards? You seem very confused about the incentives for adopting standards. Sure, maybe US-driven standards were chosen over other possibilities partly because of political environment, but once you have a perfectly good standard adopted you’re not just going to throw it out because the original author isn’t cool anymore. You don’t need a dominant power to adopt standards.

And for being “slightly political” and “focused on the standards,” your post sure does spend the majority of its time talking about only politics and not about standards at all

Other than maybe a few very rote, boilerplate types of development, all this shit about replacing coders is almost entirely noise made by either the wishful thinking of oligarchs or credulous repetition of that wishful thinking by clueless journalists.

But it’s still a pretty rough time to be just getting into tech, just because of the state of the job market.

Now you’ll have a zillion users trying to install software in ways that violate all the assumptions that NixOS operates on, but which are still tightly coupled to your NixOS config. Now updates to your system, or even seemingly unrelated config changes (through some transitive dependency chain) can easily break that software.

So now we’ve basically removed half the advantages that motivate Nix/OS in the first place, and when stuff breaks it will look like it’s Nix’s fault, even if it isn’t.

On the other hand, nixpkgs is already the most comprehensive repository of system software out there, and for 99% of packages Nixifying it is pretty trivial. Hell, my NixOS config does that for 3 different GitHub repos right inline in my config.nix

The bashrc poisoning thing was sarcastic. the point is it’s not important as an attack vector because if that’s even part of your surface area, then the attacker is already pretty well into your system

If your system uses 3 different Pythons as dependencies of different packages, which one gets to be /usr/bin/python?

Not sure about 1, but 2 and 3 both have the same answer. Both TSInstall and Mason are just trying to install other software packages on your system, and you’re on NixOS, so of course they can’t do that. You don’t install your software, you declare it. Add the Treesitter parsers you need right next to your plugins (there is a sub collection under the vimPlugins collection just for Treesitter parsers), and put whatever Mason would be installing into your user packages instead.

That said, I agree with the other commenter. Even though the community has done a lot of work on rich config options for Neovim, they’re just too far away from the normal way of doing things in the Neovim world, and plenty of plugins are written in ways that assume it’s configured in “normal” ways. Plus configuring Neovim is already kinda like assembling your own car from parts in any case, so it’s honestly better to just use nix to install Lazyvim or whatever flavor of choice and let it handle the plugin management/config. And believe me, I really tried to do it all in Nix, I wanted to do it that way. But it’s just not worth the headache at this point

Lambda is certainly an interesting case for this, I’ll give you that. Outside of that, though, the impact on deployment speed is also not relevant; the bottlenecks for deployment are things like CI, canarying, even rolling blackout windows across AZs, etc. The actual time spent transmitting your build artifact over the network is completely negligible even at huge sizes

The size of the code is mostly irrelevant if you’re not shipping it to clients over the network on every request. Short of truly gargantuan statically-linked binaries in compiled languages, anyway, and bundling isn’t really an applicable concept there. And similarly, the overhead of loading modules from the filesystem is a one-time cost that’s mostly irrelevant for server-side code that runs for days or weeks or years at a time.

On the other hand, the complexity overhead of adding the additional bundling step is a major drag on development productivity, debuggability, etc.