3 ms·
I recall that the AT&T/BSD lawsuit was relevant then, especially for Linux as an alternative at the right time. A microkernel design seemed sane from experienc
by gnufx 11y ago
I recall that the AT&T/BSD lawsuit was relevant then, especially for Linux as an alternative at the right time.
A microkernel design seemed sane from experience in the UK. I don't know if it was technically a microkernel, but the GEC OS4000 Nucleus <https://en.wikipedia.org/wiki/OS4000> https://en.wikipedia.org/wiki/OS4000> supported a system that made VMS VAXen look slow in the 80s. (Latterly, OS6000, with a software Nucleus, still compared well with System V on the same hardware.)
L4 was already tried for Hurd, surely.
- nickpsecurity 11y agoThat's a good point. Lawsuit might have factored into the decision although they don't reference it. In any case, I think Nucleus is a good recommendation as I also regularly cite it as a great idea worth emulating. That GEC work integrated just the right functions into the kernel, built entire OS around that for consistency, and had non-software-writable firmware for security. Way ahead of it's time. Well, one company did build on that work that I can tell. They built on it so well they dropped bombs on the formal verification community. You might be surprised which company that was. Safe to the last instruction: Automated verification of a type-safe operating system (2010) http://research.microsoft.com/pubs/122884/pldi117-yang.pdf http://research.microsoft.com/pubs/122884/pldi117-yang.pdf
- gnufx 11y ago[I assume, but don't know, that GEC 4000 was influenced by Brinch Hansen's RC 4000, but all I remember about the then-ancient RC 4000 at the Niels Bohr Institute was that it seemed pretty primitive and the systems language was Algol, c.f. OS4000's structured assembler, and was pretty grotty.] I don't know to what extent security was the reason for the hardware nucleus rather than a by-product of the fast system. (I recall French colleagues thought the context switching was slow, thiking it must be in milliseconds, not microseconds.) However, the software versions for the later OS6000 and whatever the 88k implementation was called, seemed OK. I don't understand the reference to the paper. I don't think there was any formal verification in OS4000 (or the hardware, given the 4190 arithmetic bug), or GC in Nucleus, and the typed assembler doesn't look to have much in common with Babbage. Which company? Good to see an OS4000 user who appreciates its significance after all this time, anyhow.
- nickpsecurity 11y ago"I assume, but don't know, that GEC 4000 was influenced by Brinch Hansen's RC 4000, but all I remember about the then-ancient RC 4000 at the Niels Bohr Institute was that it seemed pretty primitive and the systems language was Algol, c.f. OS4000's structured assembler, and was pretty grotty." Interesting. I never thought about a connection to RC 4000: just figured it was another example of how things were named back then. Could've been some influence. "I don't know to what extent security was the reason for the hardware nucleus rather than a by-product of the fast system. (I recall French colleagues thought the context switching was slow, thiking it must be in milliseconds, not microseconds.) " I doubt security was the reason as well. Few were thinking of it then. It was just a benefit of the design. "I don't understand the reference to the paper. " The original system designed a core component to make everything else easier to implement and consistent. That was called Nucleus. It had specific functions key to any OS. The rest was built around it. The Microsoft system designed a core component to make everything consistent and verification easier. That was called Nucleus. It had specific functions key to the OS and many potential others. The rest was built around it. I just thought whoever designed Verve might have heard of GEC 4000 and copied it to some degree. Or independently invented the concept. GEC 4000 still has advantages, though. "Good to see an OS4000 user who appreciates its significance after all this time, anyhow." I've never used it or any machine from 1960's-1970's. Someone asked vezzy-fnord recently why he has so much arcane knowledge about computing and programming. I answered for myself on that as I similarly research old work for the wisdom to be gained: https://news.ycombinator.com/item?id=10488298 https://news.ycombinator.com/item?id=10488298 I have literally hundreds of papers on old stuff with many solving key problems and some doing better than today's stuff by at least one metric. I expressed the problem and potential solution here: https://news.ycombinator.com/item?id=10269245 https://news.ycombinator.com/item?id=10269245 So, referencing Nucleus is just me doing my part. Neat that you got to use the thing for real. How robust was the system compared to others of the time? Did you find the kernel design or process separation to have practical benefit in its day-to-day operation or administration?