Web site: (not active)
Desktop environment: CLI
Based on: UNIX-like
The last version | Released: unknown
Spring – a highly modular, distributed, object-oriented operating system. This paper describes the goals of the Spring system and provides overviews of the Spring object model, the security model, and the naming architecture. Implementation details of the Spring microkernel, virtual memory system, file system, and UNIX emulation are supplied.
The Spring operating system project grew out of a desire to have a better implementation of UNIX®. In 1987, as part of an agreement between Sun Microsystems and AT&T; to merge the System V and Berkeley (BSD) “strains” of UNIX®, Sun and AT&T; agreed to collaborate on a project to “reimplement UNIX in an object-oriented fashion”. That project consisted of only a few initial meetings and then was forgotten, but Sun had begun to build a team of OS experts, and we wanted to do something significant.
Currently supports the SPARCstation 2, SPARCstation 4, SPARCstation 5, SPARCstation Voyager, SPARCstation 10, and SPARCstation 20.
– Most of the Spring team has SPARCstation 10s, so this is the platform that we have done the most testing and tuning for. The SPARCstation 20 is very similar to the SPARCstation 10 and we treat it identically. Support both uniprocessors and multiprocessors. Note however that we only support the SuperSPARC-I CPU chip (e.g. in the SS10/41, SS10/51, SS20/61), and don’t support either the SuperSPARC-II chip (used in the SS20/71) or the HyperSPARC chip (used in the SS20/HS21 and SS20/151).
– Also support the SPARCstation-4, SPARCstation-5, and SPARCstation Voyager.
– Support the SPARCstation 2 largely for historical reasons. Unfortunately the SPARCstation 2 Memory Management Unit only supports a very small number of simultaneous contexts and simultaneous region mappings. Because Spring has lots of servers running in different contexts and because we use a lot of sparse virtual memory mappings, we tend to need to do lots of MMU updates on the SPARCstation 2, which hurts performance. So we only recommend the SS2 for fairly light use.
Memory Requirements: Recommended 48 Megs of memory if you want to do program development. The largest single memory consumer is the compiler, which likes to have up to 16 Megs of physical memory when its mulling over the intricacies of C++. If you’re only doing light work you can get by in 32 Megs.