It wouldn't surprise me if I learned that the vast majority of programming globally is in languages like Visual Basic or PHP that are utterly unfashionable on a board like this, but still make the world go round.
It's a bit hard to comprehend that's reality to be honest.
But I could see that it could be the case from the fact that old industrial factories or old corporates would still run with what works for them.
It's a completely uncontroversial fact that NT does implement fork(). Turn to page 183 of Helen Custer's "Inside Windows NT" and you will read about it.
The principle of a paging system is that main memory is just a cache for secondary memory, and the concept of "free memory" ideally rather means something like "memory that can be quickly reclaimed for another purpose". Sometimes anonymous memory will be of less us occupying main memory at some given time than would be letting cached file contents take their place.
You've described what the purpose of a swapfile is – thanks? My argument is simply that you don't need a swapfile with enough real memory; that swapfiles can unnecessarily shorten the lives of SSDs, entirely unnecessarily.
----
>I have 20GB of RAM free (me)
>>~need to have quick access to main memory
>I have 20GB of RAM free (still me)
>>~yeah but "quickly reclaimed for another purpose"
>I have 20GB of RAM free (!m!e!)
//of//32GB//ttl//
----
In linuxland, I'd just type `sudo swapoff -a` and be done with it. That machine has 96GB of RAM, so it would have ~84GB of RAM free (if, hypothetically, the same hardare/configuration were operating that system).
Does. not. need. a swapfile.
The operating system, during bootup, should think "hey I have dozens of gigabytes of RAM, won't be needing any swapfiles" – behind the scenes and without input.
The general principle is that what is involved in paging should not be paged itself. Wiring the memory of that whole daemon is then a trivial solution to the problem.
Plan 9 implements some sort of "everything has a directory entry" concept. Sockets are files already in Unix. "Everything is a file" in Unix means they have a uniform treatment as file descriptors. Its perfection is probably in Capsicum where when you create a new process, you get a process file descriptor referring to it instead of a PID.
As much as I like bsd I think the socket interface is their biggest failure, don't get me wrong, the socket interface is not bad, it is an amazing accomplishment that most of the internet is based on. The reason I regard it as a failure is because it is so close but not quite touching. A core unix idea is to have a single namespace registry and a simple universal api(open, seek, read, write, close) to access resources on this registry. and you can tell the bsd socket team was trying(like I said it's close) but they failed to close the loop and shipped an api that did not match the core unix api.
And for free, a rant, I think this is why Microsoft's registry is so bad. On paper it sounds great "a single place to put all your config" I could totally sell it. But in practice it is miserable to use. When proposed nobody said "we already have a hierarchical namespace where all our config can go and it already has pretty great tooling, lets just make it better" so they invented a custom one that required custom special access patterns and custom special tooling and custom special api's, and... it sort of sucks to use. I guess in their defense they were not fully onboard the idea that you could have one tree(they liked their many trees A: B: C:)
You do read sockets with read/write, that's the point of saying 'everything is a file'. You can basically can do read/write/close on things that are a socket.
Yeah, I probably went too far in saying it's just the userland, but I'll insist it's more complicated than saying it was based on 4.4BSD-Lite2. I haven't done a proper deep dive yet, but I can tell that it wasn't strictly based on the Lite2 release. Take a look at XNU 123.5's (OS X 10.0) kern/tty.c:
You'll also see the source has been reorganized, with e.g. the VFS source being regrouped into bsd/vfs, instead of being left in bsd/kern. This coincidentally mirrors how OSF/1 was organized (no other source relation though, just an interesting observation):
This file had to be reimplemented by all of the BSDs. In this case, this version appears distinct from the FreeBSD and NetBSD versions I can find.
If you grep around for the `NeXT` ifndef/ifdefs in XNU, too, you'll see some code of which some appears to have been copied/adapted from the NeXT source tree, itself derived from Mach/CMU sources. (and 4.3BSD ;-)
I say all this to draw attention to the ways XNU differs from BSD, which is pretty interesting, at least to me.
I find it interesting that this fulfills some of Dennis Ritchie's goals for what became the STREAMS framework for byte-oriented I/O:
> I decided, with regret, that each processing module could not act as an independent process with its own call record. The numbers seemed against it: on large systems it is necessary to allow for as many as 1000 queues, and I saw no good way to run this many processes without consuming inordinate amounts of storage. As a result, stream server procedures are not allowed to block awaiting data, but instead must return after saving necessary status information explicitly. The contortions required in the code are seldom serious in practice, but the beauty of the scheme would increase if servers could be written as a simple read-write loop in the true coroutine style.
The power of that framework was exactly that it didn't need independent processes. It avoided considerable overhead that way. The cost was that you had to write coroutines by hand, and at a certain point that becomes very difficult to code. With a language that facilitates stackless coroutines, you can get much of the strengths of an architecture like STREAMS while not having to write contorted code.
