>>1066977
>Ironically, reading the design docs for Plan9 (written after decades of real world experience by the Unix authors themselves) highlights all the shortcomings of Unix better than any of its detractors ever could. And even today, those same people are talking about the shortcomings of Plan9, asking people to put effort into OS research again.
Plan9 is crap. If it wasn't for the names associated with it, it would be considered on the same level as some hobby UNIX clone. It's even more disappointing considering it was made after all that money AT&T got from licensing fees, so they should have been able to hire real OS developers, but no, it's the same old crap with some badly implemented features removed instead of redone properly.
https://en.wikipedia.org/wiki/Open_Systems_Interconnection
>The NCC (UK) publication 'Why Distributed Computing' which came from considerable research into future configurations for computer systems, resulted in the UK presenting the case for an international standards committee to cover this area at the ISO meeting in Sydney in March 1977.
https://en.wikipedia.org/wiki/V_(operating_system)
>The V operating system (sometimes written V-System) is a discontinued microkernel operating system that was developed by faculty and students in the distributed systems group at Stanford University from 1981 to 1988, led by Professors David Cheriton and Keith A. Lantz.
If OSI is from the 70s and distributed microkernels were developed in the 80s, why do all these weenies point to Plan 9, which does it worse than any real distributed OS? It's the same reason weenies always bring up C++ and Java when complaining about OOP, and not CLOS.
>>1067099
Read this. It has no segmentation or rings, other than the bare minimum needed to work around them in x86, while Multics is based entirely on segments and rings.
https://multicians.org/exec-env.html
>>1067103
That just means Linux sucks. Mainframes in the 60s already had drivers distributed separately from the OS, so it doesn't even need a microkernel. Microkernels are just a way to provide additional protection and separation.
>>1067109
I posted a link to an OS written in Modula-2, which was tiny. It might have even fit on a floppy. They ended up "converting" C programs to run on it, which made it into UNIX with a tiny Modula-2 subsystem. This is exactly what happened with microkernels.
>>1067179
UNIX weenies care more about UNIX than free software. They would rather pay licensing fees to use C and UNIX than get something better for free. That's why Stallman cloned UNIX, and it sucks. Ironically, if he cloned something good, none of the UNIX weenie "programmers" would want to use it, which means the quality of free software would be better because it would be made by competent people.
>>1067181
Read some links on this site. One of the big advantages is segmented virtual memory. In other words, all files are mapped into the address space and can be accessed directly with CPU instructions.
https://multicians.org/
https://multicians.org/multics-vm.html
https://opensource.com/article/18/10/linux-data-streams
>Think about how this program would have to work if we could not pipe the data stream from one command to the next. The first command would perform its task on the data and then the output from that command would need to be saved in a file. The next command would have to read the stream of data from the intermediate file and perform its modification of the data stream, sending its own output to a new, temporary data file. The third command would have to take its data from the second temporary data file and perform its own manipulation of the data stream and then store the resulting data stream in yet another temporary file. At each step, the data file names would have to be transferred from one command to the next in some way.
>I cannot even stand to think about that because it is so complex. Remember: Simplicity rocks!
This is a great example of UNIX brain damage. A real OS wouldn't use temporary files for this at all. It would just call functions in libraries, which is much simpler and needs no system calls or task switches or address spaces at all. UNIX weenies don't want simplicity, they want UNIX. Even worse, pipes can only send sequences of bytes so you have to serialize and deserialize data in both directions, which you wouldn't have to do with real IPC. It all makes sense when you realize pipes were a hack over teletypes, the 70s equivalent to controlling a program by scripting keypresses and mouse movements.
Raise your hand if you remember when file systems
had version numbers.
Don't. The paranoiac weenies in charge of Unix
proselytizing will shoot you dead. They don't like
people who know the truth.
Heck, I remember when the filesystem was mapped into the
address space! I even re<BANG!>