suchar

I agree. Even more: I saw vim users who manually edited dozens of files which could be done by running inspection by name on the entire project in IntelliJ. Even (questionably) superior text editing capabilities of vim won’t help here.

I think many vim/emacs users are not aware of the functionality of modern IDEs and development speed is mostly defined by text editing speed. Sadly, many users of sophisticated IDEs also are not using these functions, so the experienced vim user will likely be more performant than inexperienced IDE user.

What’s the difference between company-provided notebook and remote IDE in regard to micromanagement? Employer may provide you shiny new M1 MacBook with all necessary spyware. Even if you use your own machine, you should check every script in the project if it is not installing anything if you don’t trust your employer.

Actually, if you decide to use your own computer for work then remote IDE is probably better solution in terms of security and privacy of your own computer. You don’t have to worry that something nasty will be installed (be it malicious NPM package or spyware from employer).

The problem is running, possibly untrusted, code in isolation from the host in a convenient way. "Convenient way" is, of course, very subjective: in my case, it is doing as much as possible from the IDE (IntelliJ Idea). As a result, this means sandboxing graphical applications, and I'm not aware of a way to run a graphical application in a Linux container on MacOS.

IntelliJ has access to all downloaded packages (to provide autocompletion, etc.) and run npm/yarn/whatever's scripts/actions. This IDE has a lot of customized support for specific tools, which I find valuable, and wrapping everything in a shell script delegating work to a container means losing this support. At the same time, running IntelliJ as a native application, I'm able to open an embedded terminal and enumerate files in my home folder (with exceptions, like Documents and Downloads, but I'm not able to isolate projects from each other). I'm trying to keep all fancy stuff but isolate different projects from the host and each other.

As for yarn: npm is only an example. The same problem affects almost every package manager. NodeJS ecosystem is convenient here because nearly everybody has heard of some malicious JS package.

My primary use-case for Home Manager is dotfiles management. This way I can keep them consistent across all machines and development containers (managed with NixOS declarative containers, so Home Manager configuration is applied on container startup).

Over the years, I tested multiple options, and currently, I'm using NixOS declarative containers. It requires more work to create a new environment than with nix-shell, but in my experience, this is not a bottleneck. With some setup, you can even run graphical applications inside containers. I've written more about this and other approaches on my blog: https://msucharski.eu/posts/application-isolation-nixos-cont... if you are interested. It is pretty specific to my needs, so it may not work for you.

Regarding the Windows: after playing with GPU-passthrough, I came back to dual-boot. It is more reliable because you are less likely to run into some hardware quirk.

I think NixOS would benefit from easily accessible collection of opinionated modules/profiles/configurations with minimal set of options. Something like gnome-desktop / sway-desktop / etc. Gnome actually does pretty good job here.

The point is: currently my NixOS and Home Manager configurations have over 2k LOC total. When you search for configurations on GitHub/Google you are likely to find complex ones. For example, quick search for "nixos gnome" (Google) gives me link to NixOS Wiki (which describes only Gnome part) and blog post (https://gvolpe.com/blog/gnome3-on-nixos/) which is useful but links to really huge configuration (https://github.com/gvolpe/nix-config) that is overwhelming to any beginner.

Great example of such approach is nixos-hardware (https://github.com/NixOS/nixos-hardware) which provides one-line configuration covering hardware quirks.

Is there any practical benefit of Podman over Docker on a Mac? Virtual machine is still needed, so any performance issues are likely to persist (well, maybe Docker for Mac is a bit more buggy, but we can manually setup Docker instead of Podman in a similar way).

Also, I think we are losing here access to the Docker socket on the host (inside the virtual machine it can be emulated using docker-podman).