SunOS

null

Web site: oracle.com/us/sun/index.html (not active)
Origin: USA
Category: Server
Desktop environment: CLI
Architecture: 386i, Sun, SPARC
Based on: BSD
Wikipedia: SusOS
Media: Install
The last version | Released: 4.1.4 | November 1994

SunOS – a UNIX based OS derived from BSD, created by Sun Microsystems. Initially released in 1982, it was the standard OS on Sun Machines at that time. Platforms supported by this OS were the Motorola 68000, the Sun 386i, and the SPARC.

Sun-1’s were the very first models ever produced by Sun. The earliest ran Unisoft V7 UNIX; SunOS 1.x was introduced later. According to some sources, fewer than 200 Sun-1’s were ever produced; they are certainly rare. The switch from Motorola 68000’s to 68010’s occurred during the Sun-1’s reign. Some models are reported to have 3Mbit Ethernet taps as well as 10Mbit.
68000-based Sun-1’s are not supported by SunOS. The last version of SunOS to support Sun-1’s may be the same as the last version to support Sun-2’s, since the 100U CPU boards are the same part.

Sun-2’s were introduced in the early 1980’s and were Sun’s first major commercial success. While not as popular or as common as the later Sun-3’s, they did well and there are still quite a few in circulation in the home/collector-used market.
All Sun-2’s are based on the Motorola 68010 and run SunOS. The last version of SunOS to support Sun-2’s was 4.0.3. Early Sun-2’s were Multibus; later models were VME, which Sun continued to use through the Sun-3 era and well into the Sun-4 line.

Sun switched to using the Motorola 68020 with the introduction of the Sun-3’s. A few later models had 68030’s, but by that time Sun was already moving toward SPARC processors. All models either have a 68881 or 68882 FPU installed stock or at least have a socket for one. All models which are not in pizza box chassis are VMEbus. Two out of three pizza box models have a “P4” connector which can take a framebuffer; the exception is the 3/50.
Support for Sun-3’s was introduced in SunOS 3.0. The last version of SunOS to support Sun-3’s was 4.1.1U1.
During the Sun-3 era, Sun introduced the handy practice of putting the model number on the Sun badge on the front of the chassis.
There are two different kernel architectures in the Sun-3 model line. All 68020-based models are “sun3” architecture; 68030-based models (the 3/80 and 3/4xx) are “sun3x” architecture.

The Sun 386i models, based on the Intel 80386 processor, were introduced when 80386-based IBM PC/AT clones were starting to become widespread. Intel had finally produced a chip sufficiently capable (32-bit, among other things) to allow porting SunOS, and using an Intel processor and an ISA bus offered the ability to run MS-DOS applications without speed-draining emulation. Unfortunately, they were a dismal failure.
Support for Sun-386i’s was introduced in SunOS 4.0. The 386i SunOS releases came from Sun’s East Coast division, so 386i SunOS was not identical to the standard version with the same number. The last released version of SunOS to support Sun-386i’s was 4.0.2; there are a few copies of 4.0.3Beta (with OpenLook 2.0) floating around.

Support for Sun-4’s was introduced in SunOS 4.0, although there was a special variant of SunOS 3.2 for Sun-4’s which was shipped with some very early units. Since this product line is still current, it is still in general supported by SunOS, which has mutated to become part of Solaris. Support for some earlier models has been dropped, and some later models require at least 4.0.3c, 4.1.1, or Solaris 2.x.

SunOS took a shift starting with version 5.0, which changed its base from BSD to Unix System V Release 4, and became Solaris. The last release under the SunOS name was Version 4.1.4, released in November 1994.

Download

No download is available.
md5sum:

 

Evolution Makeiso

Evolution Makeiso

Web site: evolutionlinux.com (not active)
Origin: USA
Category: Desktop
Desktop environment: CLI
Architecture: x86_64
Based on: Arch Linux
Wikipedia:
Media: Live CD
The last version | Released: 2015.11.01 | November 1, 2015

Evolution Makeiso – a live media based on Arch Linux, created by Makeiso script.

The goal of Makeios is to create an easy to use method of duplicating an existing Arch install for installation on new hardware. Makeiso will create a live iso containing all the info to recreate your Arch install, within a GUI environment.

The Makeiso script will create a live ISO that will include an all new net-based, guided manual CLI installer.

The newly created live ISO will install an up to date duplicate of your Arch install, or alternatively install a new Arch “base only” system.

Download

Evolution Makeiso 2015.11.01 amd64 572MB.iso
md5sum: 50dba50a0e104d0f04bb00bbb0d4ec66

 

GNOSIS

null

Web site: cis.upenn.edu/~KeyKOS/Gnosis/Gnosis.html (not active)
Origin: USA
Category: Server
Desktop environment: CLI
Architecture: IBM ?
Based on: Independent
Wikipedia: GNOSIS
Media: Install
The last version | Released: ? | ?

GNOSIS (Great New Operating System In the Sky) – an example of a completely different kind of operating system. Gnosis was developed by TYMSHARE as a proprietary control program and it also developed proprietary application packages to run on it. GNOSIS was based on the research of Norman Hardy, Dale E. Jordan, Bill Frantz, Charlie Landau, Jay Jonekait, et al. McDonnell Douglas bought Tymshare, Inc. and then sold it in 1984 to Key Logic.

Programs under Gnosis are built out of protection domains with firewalls between them. Domains are small, simple, and cheap.
Domains communicate through doors in the firewalls, called capabilities. Capabilities are a simple, uniform, efficient means of representing authority.

There are several significant factors which make it possible.

* First, and foremost, the Gnosis concept of distinct domains without implicit interactions between them results in simpler programs. Because of this, we have had to spend a great deal of time designing the interfaces between these domains to insure that adequate function exists in each; but perhaps even that is a benefit since we will know exactly how the system goes together. The basic design of Gnosis will ensure that no compromises to the design occur during the implementation.

* Second, because individual components are completely isolated from each other, except for the prescribed interfaces, it is a simple matter to implement each domain independently of the remainder of the operating system. Very little scaffolding is required. We went to install the CMS editor in Gnosis and noted all of the things we thought ought to be there as co-requisites, things like a command language to call the editor, a file system, a loader, catalog facilities, and so on. To our surprise, we discovered that we didn’t need any of those facilities. We could just connect the editor directly to the terminal handler and test it. This made development go much quicker.

* Third, we have been able to coexist with, and take advantage of, CMS during the early going. We expect to use CMS services for quite some while for compiling programs and so forth. Thus our “critical mass” of code is very much smaller that it would otherwise be.

* Fourth, the basic design of Gnosis allows us to write most of the operating system as user code, which means we will be able to eliminate a lot of duplication of effort in terms of testing tools, etc. The system will also be much simpler because all of the details of the hardware are masked in the kernel. Consequently no domain programmer need ever deal with them, which makes the domains simpler, and also greatly reduces the impact of any hardware changes. We have tended to follow the advice of Fred Brooks in the Mythical Man-month, where he suggests “be prepared to throw the first one away.” We have implemented each domain with the simplest possible algorithms in order to test the design. Later we will have to discard many of these domains and rewrite them with high performance algorithms which obey the same interface specifications. Most of these first attempt domains can be implemented In a matter of days.

* Last, but certainly not least, we have a relatively high technology “office of the future” system called AUGMENT which we are using to keep all of our design notes as well as our user documentation. The use of this system,will save us a significant amount of labor as we develop a user community over the next several years.

The combination of these facilities has made it possible for us to implement a great deal of function very quickly. As Norm mentioned earlier, we have only just started running our first domains recently. Yet we expect to be able to have a significant online database application operational within a year.

Download

No download is available.
md5sum:

 

HPBSD

null

Web site: flux.utah.edu/~mike/hpbsd/hpbsd.html
Origin: USA
Category: Server
Desktop environment: CLI
Architecture: HP 9000
Based on: 4.3BSD
Wikipedia:
Media: Install
The last version | Released: 2.0 | April 1993

HPBSD – a port of 4.3BSD UNIX operating system for the HP9000 300, 400, 700 and 800 series machines done by Systems Programming Group at the University of Utah, developed between 1987 and 1993.

The goal was to replace the HP-UX (System V derivative) with BSD environments on HP machines in Utah CS department, in order to improve compatibility with Vaxen who worked on BSD and Sun workstations that ran on SunOS. Port was completed in a month, thanks to an older BSD port for HP 9000/200. Trait that was HPBSD tell any binary compatibility with HP-UX-TV. I went to support the HP 9000 HPBSD was later inserted into the main tree BSD code, and appeared in 4.3BSD-Reno.

The current version, HPBSD 2.0, is still largely based on 4.3bsd but has the 4.4bsd filesystem and networking kernel code and utilities as well as the ANSI-compliant C library. This version was “released” in April 1993. Improvements has been limited to bug fixes and support for new hp700 CPUs that we have. It is still the desktop operating system of choice inside the Flux and Avalanche research groups.

HPBSD is based on the 4.3 release of BSD from CSRG at Berkeley with additions from 4.4bsd and numerous local modifications. It still looks and feels pretty much like a 4.3 system, but configuring and building software packages is more 4.4bsd-like.

Supported Hardware: HP300/400 (68k based) and HP700/800 (PA-RISC based).
Since HPBSD contains AT&T and HP proprietary code it is not freely available.

The project founder is Mike Hibler.

Download

No download is available.
md5sum:

 

386BSD

null

  • Web site: 386bsd.org
  • Origin: USA
  • Category: Server
  • Desktop environment: CLI
  • Architecture: x86
  • Based on: UNIX
  • Wikipedia: 386BSD
  • Media: Install
  • The last version | Released: 2.0 | August 2016

386BSD – a derived from 4.3BSD, the first open source Berkeley UNIX operating system. It was the progenitor of Linux, iOS, and Android. Beginning with “A Modest Proposal” in 1989, 386BSD broke from proprietary systems by having publicly accessible code and documentation.

386BSD Release 0.0 was distributed in 1993 in tandem to the popular “Porting Unix to the 386” article series published in Dr. Dobb’s Journal.
Release 0.1 quickly followed, enhanced with contributions throughout the globe.

386BSD Release 1.0, aka Jolix, was a break from earlier Berkeley UNIX systems through use of a modular architecture. 386BSD Release 2.0 built upon the modular framework to create self-healing components. Each release introduced novel mechanisms from role-based security to polymorphic protocols.

386BSD.org provides the opportunity to interact with the original source, articles and supporting materials, and a live demo of 386BSD Release 2.0.

386BSD is a mother of free BSD systems today, such as: BSD/386, NetBSD, FreeBSD, BSD/OS, Darwin, OpenBSD and others.

The project authors are Lynne and William Jolitz.

 

KeyKOS

null

Web site: cap-lore.com/CapTheory/KK/
Origin: USA
Category: Microkernel, Others
Desktop environment: CLI
Architecture: IBM S/370, IBM Mainframe
Based on: GNOSIS
Wikipedia: KeyKOS
Media: Install
The last version | Released: ? | ?

KeyKOS – an operating environment for S/370 computers which provides a high level of security, reliability, performance, and productivity. It allows emulation of other environments such as VM, MVS, and POSIX.

When Tymshare started work on KeyKOS in the early 1970s, there were solid business requirements justifying the project. With the price of main storage dropping, applications were too tightly bound to disk storage. Because Tymshare’s systems were accessed from around the world, continuous operation was a requirement. Existing systems were prone to failure from many causes, both hardware and software. They did not recover from these failures gracefully. These systems required significant operator intervention in both normal operation and during recovery. They did not provide the security needed to allow competing organizations to share programs and data in a controlled manner where it made economic and social sense.

Because of these deficiencies, Tymshare decided its best option was to build a system of its own. This system had a number of design goals including: high security, high reliability, economical processing of high transaction volumes, and enhanced productivity for managers, programmers, users, operators, and hardware.

KeyKOS provides persistent virtual address spaces where programs may keep data. The system caches frequently referenced data in main storage. When several processes are accessing the same data, for example the CMS “S” disk, the data blocks involved are likely to already in main storage, improving access times. Only one copy will be maintained in main storage, improving storage utilization. Persistent virtual storage allows the kernel to globally optimize disk arm movement and rotational latency. The KeyKOS implementation also provides complete separation of physical and logical DASD management. No unprivileged program is aware of the type or configuration of real DASD in the system.

KeyKOS has a system-wide checkpoint which periodically saves the state of the entire system. If a system outage occurs, the system will restart from the last checkpoint with all data and processes in a consistent state as of that checkpoint. The KeyTXF transaction processing system will recover database updates to the point of failure. Should a CPU fail, the DASD can be shared with or switched to a backup CPU to quickly restore service by restarting from the last checkpoint.

Data mirroring stores multiple copies of data for reliability and performance. The KeyKOS system continues to operate if a mirrored disk fails. When the disk is repaired, or a replacement disk is formatted and brought online, the mirrored data is automatically restored to that disk. Performance is enhanced by having several paths to a particular piece of data. The full function of the system is available in essentially any S/370 computer language. A standard invocation protocol permits high level languages to invoke low level function and low level languages to invoke high level function, enhancing the usefulness of all languages.

The KeyKOS system is designed for unattended operation. The only common operator functions are mounting tapes and servicing the printer.

The KeyKOS system is designed for continuous operation. Full system backup dumps may be taken while the system is running. When a dump has completed, the backup tapes contain an image of all data and processes in the system at a consistent instant of time. avoiding inconsistency in the data. These “tape checkpoints” are conceptually independent of the physical DASD type or configuration. They may be restored to different physical devices if necessary.

KeyKOS/370 runs on System/370-compatible single processor CPUs. It currently supports 3330, 3350, and 3380 count key data format disks and 3370 FBA format disks. System software includes the context switcher and two command systems.

Copyright © 1985, 1987, 1988, 1990 Key Logic. All rights reserved.
Permission to reproduce and redistribute this document in paper or electronic form is hereby granted, provided that this copyright notice remains intact.

KeyKOS is a predecessor of the EROS and its successors are CapROS and Coyotos operating systems.

Download

No download is available.
md5sum:

 

Firefly BSD

null

Web site: www.fireflybsd.com (not active)
Origin: USA ?
Category: Server
Desktop environment: CLI
Architecture: x86
Based on: DragonFly BSD
Wikipedia:
Media: Live
The last version | Released: 1.4 ? | September 14, 2004 ?

Firefly BSD – a commercially-supported operating system based on industry DragonFlyBSD a fork of FreeBSD. It comes with complete source and binaries for the kernel, compiler, libraries, and user utilities. In addition, thousands of contributed programs have been ported to Firefly BSD and are included in the 4-CDROM set.

A LiveCD that you can boot and run off without having to install anything on your hard drive.
A parallelized networking stack that allows for better use of multiprocessors than the serialized approach taken in FreeBSD 5.
It offers a choice of KDE 3 or Gnome 2 graphical environments on top of XFree86-4.4.0.
Ability to run Microsoft Windows network drivers to support an even wider range of network devices.

The project developer is David Rhodus.

Download

No download is available.
md5sum:

 

Caos Linux

Caos Linux

Web site: www.caoslinux.org (not active)
Origin: USA
Category: Server
Desktop environment: GNOME, Xfce
Architecture: x86, x86_64
Based on: Independent
Wikipedia: CAOS Linux
Media: Live
The last version | Released: 1.0.25 | October 14, 2009

Caos Linux – an independent, RPM based Linux distribution developed by the CAOS Foundation. The CAOS Linux Project was first initated because of the need for an openly managed, RPM based version of Linux. CAOS NSA (Node, Server, Appliance) pursues the “sweet spot” concept for a Linux distribution.

CAOS Linux is designed to run on all x86_64 and i386 based hardware ranging from clusters and servers to production level appliances to personal desktops and laptops. Scientific research labs, public agencies, ISP’s, private enterprise, virtualization and cloud computing ventures will find CAOS Linux to be an integral component to their operation.

CAOS NSA focuses on being a lightweight, fast, efficient, stable, and secure distribution of Linux that is appropriate for servers, compute nodes, network appliances, and even the latest desktop and laptop computers.

Supporting a wide variety of software, CAOS Linux is based on the best aspects of GNU/Linux and has full binary compatibility with the most popular enterprise distribution of Linux.

The CAOS Linux installer would be found easy to use by both an experienced admin or a Linux newcomer. Users can either have a fully automated install (including HD partitioning) or they can take full control from the install prompt. The automated CAOS Linux installer, Cinch, is a very user friendly, written from scratch and open to use by other distributions. Your CAOS system has the advantage of grabbing the latest packages from our online repository during installation, guaranteeing your system is up to date. Post-installation configuration is simple through either Sidekick, our server administration Swiss Army Knife, manually, or via the web using an industry compatible webmin tool.

Download

Caos Linux 1.0 x86_64 2.37GB.iso
md5sum: 15f68fa01cd74c788c11df771c4d218a

 

Finnix

Finnix

Web site: www.finnix.org
Origin: USA
Category: Rescue
Desktop environment: CLI
Architecture: x86, x86_64, ARMHF, PowerPC
Based on: Debian
Wikipedia: Finnix
Media: Live CD
The last version | Released: 111 | June 4, 2015
Zobacz po polsku Zobacz po polsku: Finnix

Finnix – a small, text based rescue CD based on Debian GNU/Linux, targeted to system administrators. Finnix works in Live mode, but it can be installed on your computer’s hard drive. The Live system can be started from a CD, USB flash drive and via the network (PXE).

Finnix includes tools for disk partitioning, network traffic monitoring, boot record repair and installation of other operating systems.

Finnix is built on Debian from the testing branch and is available for i386, amd64, armhf and powerpc machines.

The Finnix Live image also includes the FreeDOS system.

The project was started in 1999, with its first public release in March 2000, making it one of the oldest LiveCDs (predated by DemoLinux and immediately preceded by the Linuxcare Bootable Toolbox).
The project developer is Ryan Finnie.

Download

Finnix 111 i386/amd64 163MB.iso
md5sum: f111ff8eee915f508ade13b934d47ce6
Finnix 111 ARMHF 111MB.iso
md5sum: f111ffa290ab46ad193fdbbb2952a785
Finnix 111 PowerPC 158MB.iso
md5sum: f111ff0864d2796d788a98785ecb7589

 

EROS

null

Web site: www.eros-os.org (not active)
Origin: USA
Category: Microkernel, Others
Desktop environment: CLI
Architecture: x86
Based on: KeyKOS
Wikipedia: EROS
Media: Install
The last version | Released: 1.1 | April 18, 2001

EROS (Extremely Reliable Operating System) – an operating system being implemented at the University of Pennsylvania, as a clean-room reconstruction of an earlier system, KeyKOS. The system merges some very old ideas in operating systems with some newer ideas about performance and resource management. The result is a small, secure, real-time operating system that provides orthogonal persistence.

EROS is a pure capability system. Authority in the system is conveyed exclusivly by secure capabilities, down to the granularity of individual pages.

The EROS kernel itself is implemented using multiple kernel-mode threads. This improves the performance of EROS drivers, makes them simpler to code, and greatly simplifies the design of the kernel. In addition, it enables selected kernel functionality to be preempted by higher priority user activities.

Because EROS processes are persistent, processes can hold authorities in their own right rather than inheriting them from the user. This enables a rich variety of options for security and access control that are impossible in systems lacking persistent processes.

EROS developed beginning in 1991 by The EROS Group, LLC., the Johns Hopkins University, and the University of Pennsylvania. Features include automatic data and process persistence, some preliminary real-time support, and capability-based security. EROS is purely a research operating system, and was never deployed in real world use. As of 2005, development has stopped in favor of two successor systems, CapROS and Coyotos.

The project founder is Jonathan Shapiro. He is also the driving force behind Coyotos, which is an “evolutionary step” beyond the EROS operating system.

Download

No download is available.
md5sum: