netbsdusers

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 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.

Solaris and Windows NT both have fork() and strict accounting by default.

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.

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.

The pushback is motivated by the interests of the petty-bourgeois class, and those are a larger proportion of the former.

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.

> Linux won specifically because the GPL forced the "greedy" actors to collaborate.

How do we know that? It seems to me that a greater factor in the success of Linux was the idealism and community. It was about freedom. Linux was the "Revolution OS" and the hacker community couldn't but fall in love with Linux and its community that embodied their ideals. They contributed to it and they founded new kinds of firms that (at least when they began) committed themselves to respect those principles.

I realise the memory of Linux's roots in hacker culture is fading away fast but I really do think this might have been the key factor in Linux's growth. It reached a critical mass that way.

I'm quite certain of the fact that this was more important anyway than the fact that, for instance, Linksys had to (eventually! they didn't at first) release the source code to their modifications to the Linux kernel to run on the WRT54G. I don't think things like that played much of a role at all.

Linksys were certainly kind enough to permit people to flash their own firmware to that router, and that helped grow Linux in that area. They even released a special WRT54GL edition to facilitate custom firmware. But they could just as easily have Tivoised it (something that the Linux licence does not forbid) and that would've been the end of the story.

Just about everything of worth in operating systems (and in software in general) was already invented in those decades.

The C standard doesn't guarantee much of anything. Windows and its drivers are using bitfields anyway because they trust MSVC to do the right thing.