Coreutils are not only used in interactive contexts. They are the primitives that make up the countless shell scripts which glue systems together. Any edge case will be encountered and the resulting poor performance will impact somebody, somewhere.
Here's a related example of what happens when you change a shell primitive's behavior - even interactively. Back in the 2000s, Linux distributions started adding color output to the ls command via a default "alias ls=/bin/ls --color=auto". You know: make directories blue, symlinks cyan, executables purple; that kind of thing. Somebody thought it would be a nice user experience upgrade.
I was working at a NAS (NFS remote box) vendor in tech support. We frequently got calls from folks who had just switched to Linux from Solaris, or had just moved their home directories from local disk to NFS. They would complain that listing a directory with a lot of files would hang. If it came back at all, it would be in minutes or hours! The fix? "unalias ls". Because calling "/bin/ls" would execute a single READDIR (the NFS RPC), which was 1 round-trip to the server and only a few network packets; but calling "/bin/ls --color=auto" would add a STAT call for every single file in the directory to figure out what color it should be - sequentially, one-by-one, confirming the success of each before the next iteration. If you had 30,000 files with a round-trip time of 1ms that's 30 seconds. If you had millions...well, either you waited for hours or you power-cycled the box. (This was eventually fixed with NFSv3's READDIRPLUS.)
Now I'm sure whomever changed that alias did not intend it, but they caused thousands of people thousands of hours of lost productivity. I was just one guy in one org's tech support group, and I saw at least a dozen such cases, not all of which were lucky enough to land in the queue of somebody who'd already seen the problem.
So I really appreciate GNU coreutils' commitment to sane behavior even at the edges. If you do systems work long enough, you will ride those edges, and a tool which stays steady in your hand - or script - is invaluable.
NFS is more annoying on Linux than just using Samba though, at least for the NAS use case. With Samba on my server I can just browse to it in KDE's file manager Dolphin, and samba configuration is a relatively straight forward ini style file on the server. A pair of ports also need to be opened in the host firewall.
Contrast that with NFS, which last I looked needed several config files, matching account IDs between hosts, mounting as root, and would hang processes if connection was lost. At least I hear rpcbind is gone these days.
I don't think anyone sane uses NFS on Linux either these days. And it is rather funny that the protocol Microsoft invented is what stuck and became practical between Linux hosts.
First thing I have heard about NetApp. Seems to be some enterprise focused company, with more than one product. Not sure which product of theirs you refer to.
Synology, TrueNAS and Proxmox probably also have NFS support I would assume, and they definitely have Samba. Those are more relevant to me personally.
I just run a normal headless Linux distro on my NAS computer, I don't see the point of a specialised NAS distro. It too could have NFS if I wanted it, but it currently has Samba, because it is easier and works better.
So in conclusion, I'm not sure what your point is? Doesn't NetApp support anything except NFS?
For me NFS is easy and works better, edit two files, enable NFS and update firewall. I had NFS running before SMB, and if I am at hobby level I prefer http if it is good enough. There are technical reasons to use SMB, HTTP, NFS or Ceph. The easy to use options is just a function of how much you know, what you have run into and what you NEED to do.
For read-only access there could be way better caching, especially for common use cases like listing the contents of a filesystem directory. But stuff like this was excluded on purpose.
NFS is really stupid.
NFS made the assumption that a distributed system with over 100 times the latency of a local system could be treated like a local system in every single way.
I am not sure why this means why "NFS is really stupid" if the user assumes that a distributed file system can be treated just like a local system. That is provides the same interface is what makes NFS extremely useful.
Latency is at least two orders of magnitude higher. That is the (relevant) difference here. And treating it like a loc system with all the incidental non-optimizations made the NAS use-case take 40 hours for colored "ls" output.
I find it extremely useful and it works well for many use cases. This already implies that "it is useless" is pure nonsense. If it does not work for your usecase, just don't use it.
The basic argument was "NFS is stupid". The basis for this claim is its data model being ill-suited to network latency. This is different from "useless".
Here's a related example of what happens when you change a shell primitive's behavior - even interactively. Back in the 2000s, Linux distributions started adding color output to the ls command via a default "alias ls=/bin/ls --color=auto". You know: make directories blue, symlinks cyan, executables purple; that kind of thing. Somebody thought it would be a nice user experience upgrade.
I was working at a NAS (NFS remote box) vendor in tech support. We frequently got calls from folks who had just switched to Linux from Solaris, or had just moved their home directories from local disk to NFS. They would complain that listing a directory with a lot of files would hang. If it came back at all, it would be in minutes or hours! The fix? "unalias ls". Because calling "/bin/ls" would execute a single READDIR (the NFS RPC), which was 1 round-trip to the server and only a few network packets; but calling "/bin/ls --color=auto" would add a STAT call for every single file in the directory to figure out what color it should be - sequentially, one-by-one, confirming the success of each before the next iteration. If you had 30,000 files with a round-trip time of 1ms that's 30 seconds. If you had millions...well, either you waited for hours or you power-cycled the box. (This was eventually fixed with NFSv3's READDIRPLUS.)
Now I'm sure whomever changed that alias did not intend it, but they caused thousands of people thousands of hours of lost productivity. I was just one guy in one org's tech support group, and I saw at least a dozen such cases, not all of which were lucky enough to land in the queue of somebody who'd already seen the problem.
So I really appreciate GNU coreutils' commitment to sane behavior even at the edges. If you do systems work long enough, you will ride those edges, and a tool which stays steady in your hand - or script - is invaluable.