What is the historical reason for limits on file descriptors (ulimit -n)

When I first borrowed an account on a UNIX system in 1990, the file limit was an astonishing 1024, so I never really saw that as a problem. Today 30 years later the (soft) limit is a measly 1024. I imagine the historical reason for 1024 was that it was a scarce resource - though I cannot really find evidence for that. The limit on my laptop is (2^63-1): $ cat /proc/sys/fs/file-max 9223372036854775807 which I today see as astonishing as 1024 in 1990. The hard limit (ulimit -Hn) on my system limits this further to 1048576. But why have a limit at all? Why not just let RAM be the limiting resource? I ran this on Ubuntu 20.04 (from year 2020) and HPUX B.11.11 (from year 2000): ulimit -n ulimit -Hn On Ubuntu this increases the limit from 1024 to 1048576. On HPUX it increases from 60 to 1024. *In neither case is there any difference in the memory usage as per ps -edalf*. If the scarce resource is not RAM, what *is* the scarce resource then? I have never experienced the 1024 limit helping me or my users - on the contrary, it is the root cause for errors that my users cannot explain and thus cannot solve themselves: Given the often mysterious crashes they do not immediately think of ulimit -n 1046576 before running their job. I can see it is useful to limit the *total* memory size of a process, so if it runs amok, it will not take down the whole system. But I do not see how that applies to the file limit. What is the situation where the limit of 1024 (and not just a general memory limit) would help back in 1990? And is there a similar situation today?