Operating Systems: Intro and Overview

The text packs high-level concepts into chapter 1.  It sets the  focus of the text, and for much of the course, as Operating Systems.  

Figure 1.1 might be a little incomplete.  Here's a diagram that shows a System or Network Administrator interfacing directly with the OS, and sometime directly with some of the hardware. Users of servers are typically isolated from the OS by the application software:

For IT professionals, knowledge and understanding of OSs is important for their organizations to maintain a competitive edge, keep their computing resources safe, secure, and economical.  Choice of 'platform' (hardware & OS combination) influences, facilitates some options, and limits others.  Choice of 'operating environments' is one of the most important strategic decisions an enterprise has to make.

Platform = CPU + Operating System:

Operating Systems are built for or adapted to each CPU they operate.  The combination of CPU and OS is called a platform. Common platforms are WinTel-Windows on Intel, Linux-like on Intel, iOS on iPhone, HP/UX on PA-RISC or Itanium, iPad, or iPod, Android on ARM, i5 on Power...

Some application software, where performance is an issue, is distributed for a particular platform and won't run on another. We're familiar with this 'platform dependency' in the different apps available for Mac vs. Windows, or for iPhone vs. Android in each of their stores, but it also applies to servers and personal computers.

Some OS are built for more than one type of CPU: Apple's Mac OSX launched on RISC FreeScale/IBM Power CPUs, then switched to CISC Intel. The Linux kernel was developed on Intel and has been optimized for Acorn, ARM, Power, zAPP, Intel, Sparc, IRIS, and others. IBM has embraced the Open Source community and both RedHat Enterprise and Suse run the Linux kernel 'native' on IBM's p & z Series CPUs, which power their mid-range & mainframe product line. In Summer of 2015 IBM announced a liason with Ubuntu to run their zSeries mainframe/super-server -- one zSeries can handle the workload of a farm of 2,500 server-class machines.

Applications and databases written for one platform may or may not be 'portable' to another. We're familiar with this where some Mac or iOS applications won't run on Windows or Android. This is inconvenient for personal devices, but can be devastating for a business that has picked an application environment that will not 'scale up' when it's needed.

The best advice for any organization is to Expect Exponential Growth and buy into an application and platform with a proven track record for 'scalability'. It can be fatal or extremely uncomfortable for a business to be faced with an expensive change of software and procedures while they are growing by leaps and bounds.

CPU Architectures: CISC & RISC

Since the great shake out of computer manufacturers since the mid-'80s, two main CPU architectures predominate: CISC & RISC. There are other, proprietary, CPU schemes but CISC and RISC account for close to 100% of personal and business computers.

The acronyms stand for Complex Instruction Set Computers and Reduced Instruction Set Computers. Here are some differences:

• RISC CPUs have fewer instructions which all execute within one 'tick' of the CPU's clock (as in 2.4GHz). CISC CPUs have more instructions and some are 'complex' and may take lots of clock ticks to execute.
• RISC is code intensive: For most purposes the binary code for RISC CPUs has more instructions. Algorithms that involve loops and complex operations must be written in assembly or produced by a 3GL's compiler or interpreter.
• CISC is CPU intensive: Some CISC instructions take longer than a clock tick may result in 'wait state' for the remainer of the tick. Rendering complex instructions takes fewer lines of code.
• There are other differences, as this article discusses.
• (Google CISC vs RISC for more...)
• To further confuse the matter, some modern CISC CPUs are 'hybrid' and include RISC-style instructions to use 'internally' or by Assembly programmers where they're better-suited, while maintaining compatibility with the 'x86' standards Windows OS and applications generally require.

CISC - Mostly Intel & AMD, also IRIS

Most CISC chips are engineered and manufactured by Intel, AMD, and a couple or few others who are licensed to make 'Intel CPUs' with special characteristics. SGI's Legacy CPU, IRIS, is a super-complex CISC chip, not x86 compatible, with a unique instruction set for a 'geometry engine' that can manipulate multi-dimensional matrices and other complex operations needed to render exquisitely textured 3D animations or crunch multi-dimensional data structures for factor or Fourier analysis and other statistics. IRIS/IRIX is the animation engine behind Star Wars, Hobbits, Harry Potter, Finding Nemo, and scores of other FX by ILM and other studios.

RISC - Manufactured by Whoever's Quickest & Cheapest

RISC means 'Motorola' to most oldsters, since most RISC chips derive from the venerable Motorola 68000 product line. Motorola no longer builds these chips, but passed the baton and tooling to FreeScale to build the low-end CPUs for embedded and other low-powered applications. IBM took over the manufacture of the high-end RISC chips for gaming, personal computers, and their own mid-range and super-computer lines. In 2015 IBM passed the line off to the NY-based Global Foundry. FreeScale, QualComm, Global Foundry, TI, and several other manufacturers supply the world's growing demand for low-end RISC for embedded computers and the more powerful 32 & 64-bit CPUs that run our tablets and smartphones.

Where CISC chips are proprietary and involve 'trade secrets' of companies like Intel or AMD, the RISC design is 'open' for anybody to see and the design is advanced by a 'consortium' of interested companies who manufacture RISC chips: IBM, TI, ARM, Acorn, QualComm, and maybe Google or Foxconn and any other outfit interested in and able to do RISC technology. It's easy to ramp up to the latest technology with RISC, CISC is more difficult. 24 Cores is no big deal in either CISC or RISC. For most purposes today, either CISC or RISC cab deliver excellent performance for most any application.

Which is Best? CISC or RISC?

There is no quick answer to 'which is best, RISC vs. CISC '. CPUs are so fast these days that either architecture can work fine for many purposes. In 2010 it was easy to point and say things like 'RISC chips use less power and generates less heat' but recent developments by Intel and their licensees have produced low-powered CISC chips that run cool.

When CPUs were running a KiloHz or MegaHz it was easy to demonstrate which architecture was best for which kinds of tasks. The erratic 'wait state' of CISC could be evidence of wasted CPU time, and RISC won on networking, database, and other tasks important for servers. CISC often appeared better for graphics and the tasks important for desktop and notebook computers. Now that CPUs are running at GigaHz speeds and often deployed in multi-cores with 'pipelining', it's become harder to prove which is the better.

The market, for the time-being, likes CISC on desktops, notebooks, gamer's machines, and smaller servers. RISC rules embedded, mobile, tablets, and other personal devices, larger servers, mid-range, mainframe, and super computers. In 2015 Intel got a little of the mobile/tablet market with their inexpensive Atom CPU, and we're seeing them run Android and ChromeOS just fine.

So, the 'which is best' question can be answered like 'the cheapest', 'the longest battery life' , 'the fastest way to get this application to market'.

Since RISC is a fairly 'open' technology it's likely to be less expensive unless Intel/AMD hankers for this market. Since Intel and AMD are competitive, they're likely to match the price in some later product, maybe the Atom or Curie?

Next Architecture?

IBM's new Synapse technology may be poised as the next CPU Architecture? They have more experience than anybody else with AI-Artifical Intelligence and will be ready to exploit this new kind of CPU all the way to 'the singularity' if the odds are with them. Quantum Computing is another technology alogether. Whether these will be a variation on 4th Generation, or a whole 'nother lineage of machines remains to be seen.

Jumping Platforms, Rehosting Server Applications

There are fewer urgent reasons to 'jump platforms' these days. In the 1980s and '90s when computer manufacturers were going out of business and stranding customers on defunct platforms there were lots of companies looking to move their applications and data to another, viable platform. Or, with newer and faster server-class computers that cost a small fraction of the older mid-range computer, it made economic sense to retire an old machine the size of a refrigerator with a smaller server. Sometimes, some kind of unix would come to the rescue and a software house or consultant could 'rehost' application software, especially if the company owned the source code.

Rehosting applications and databases in a unix environment could be facilitated because there are standards-compliant flavors of unix for both RISC and CISC platforms, and they share several programming languages so many application systems are able to be 'ported' or 'rehosted' from RISC to CISC or the other way around. In any cases the data and programs could be converted from RISC's big-endian to CISC's little-endian using a *ix process similar to fnuxi. Then the source code could be recompiled to produce the app's binary object code for the CPU on the new platform.

These days, moving data between RISC and CISC can be very easy since the current generation of RISC chips allows the endian-ness to be selected as Little, making them easier to share data with the CISC-based Windows or Mac platform or wireless printer nearby or anywhere else.

Low-tech Solutions are Easy to Move

If an application has been written in a very 'generic' way, not using any special features of a particular CPU's instruction set or operating system then it is very likely that the application's code can be moved very easily among any of these CPUs, making it very easy to deploy on another platform.

Platform Independence, Middleware, Virtual Machines

 The text briefly introduces this topic with a couple of block diagrams that emphasize the fit between OS and hardware, but it is an important practical matter to understand 'what is a platform?' since it's going to affect strategy...

This topic is expanded below, where the platforms you're likely to encounter are shown in some detail...

For a several decades new 'layers' have been added to the traditional OS cake that make applications less 'platform dependent'. The layer is sometimes called 'middleware' -- it goes between an application and an OS.

Java is the best-known example of middleware/virtual machine because so many of us use it:

JVM-Java Virtual Machine & JRE-Java Runtime Engine

Java has been adapted to almost every CPU known to man, from drink machines, self-checkout, DVD players, through teachers' gradebooks and business applications that run on Mac, PC, or Linux. Java Net Beans uses the JRE for free, Enterprise Net Beans is not free but can represent good ROI.

In the best cases Java applications can be 'developed once, deployed anywhere'.

Unless the features of a virtual machine are used to best advantage the VM is slower than a real machine would be. IMHO, Some developers don't learn all the rich stuff in the JRE, or the .NET Framework, and don't take advantage of them, instead reinventing stuff, and their applications run very slowly.

If Java or .NET were the fastest we'd be gaming with Java and .NET.

Java's critics, maybe customers of less-talented Java developers, to say 'develop once, sucks bandwidth everywhere'. It's best suited for relatively lightweight apps for business or personal use, or embedded in appliances it was built to operate. Java server applications run better on Sun/Oracle's Solaris running on Sparc than any

(IMHO none of the virtual machines allows true 'develop once deploy everywhere', yet, and developers need to test on every potential target device, virtual and real, so mobil developers need drawers full of phones and tablets... )

.NET Framework

Microsoft's virtual machine is the .NET Framework. It was very well thought out and in its 3rd revision is stable and quick. It knows how to do practically anything needed for a windows desktop environment, browser, or web service (used for B2B exchanges) and does it very quickly. The Visual Studio IDE produces 'byte code' DLL-Dynamic Load Libraries for .NET. Microsoft distributes most Windows OS components as DLLs - Dynamic Load Libraries and uses EXEecutables for stuff that needs to be fast. Windows applications built with their Visual Studio produce DLLs with 'byte code' which may be obfuscated, making it more difficult for a customer or competitor to 'reverse compile' the application to get source code not included with their software distro.

The .NET Framework was added to Microsoft operating systems starting with XP and Server 2000. Compared to Java on Windows, .NET has a definite home court advantage and has run crisply since it was released on the market. The .NET Framework is comprehensive, includes essentials for web services, web pages, and GUI. .NET sits between the application and OS to run Microsoft's CLR-Common Runtime Language byte code. Applications developed using the languages of Micro$oft's Visual Studio compile to this 'CLR'. The CLR will run anywhere the .NET framework runs, which is Windows and, surprisingly, Linux and practically any portable device. Apps coded in a very 'generic' may run cross-platform with no or very little tweaking.

Lubricated by this CLR, the .NET framework has been tweaked to work with Linux servers, iOS, Android, OSX, and even mainframe-class hardware.   (So something like this joke from the late '90s is actually happening...)

The Mono Project has been afoot for a decade or more, has gained some traction. A VCU IS grad, Mr Wickes, has been with it in Seattle for almost that long.

IBM Virtual Machines

History: Although the .NET Framework and other virtualization schemes like VMWare, Virtual Box, and Windows HyperV get lots of attention these days, IBM was there first with a virtual machine. As the next-generation IBM370 mainframes arrived in the '70s, most included a VM-Virtual Machine environment that ran everything written for the prior generation, IBM360, OS. This allowed customers to operate their legacy of 'batch processed' card and tape oriented record-keeping and accounting systems as they developed or purchased applications that used the 'interactive terminal facilities' and TSO-Time Sharing Options introduced with the IBM370s, pre-dating PCs by a decade.

IBM has maintained backward compatability as their mainframes evolved from the '60 through today. IBM 3080, 3090, and the new zOS all include VM so customers' application environments have not been obsoleted.

IBM's mid-range AS400 and the new i5 also use a virtual machine, the SLIC-System Licensed Internal Code, for decades. This allows IBM to swap CPUs and make other engineering changes as they maintain the state of the art without their customers' valuable software legacy being obsoleted.

Some of IBM's customers operate legacy mainframe applications on competitor's equipment. IBM provides OS software to customers who run on mainframes built by Hitachi, Siemons, Amdahl, and other manufacturers. IBM's VM architecture makes it very easy for them to adapt their venerable OS to other hardware when their customer demand it.

VCU was an early adopter of IBM370 and operated the largest mainframe in the gret commonwealth of Va on the 4th floor of what is now Harris Hall, serving both the academic and medical campuses. VCU was among the first to deploy Memorex disk drives on an IBM mainframe, and also to jump platforms from IBM to Amdahl/OS3080 when the computer center was moved downtown to the Pocohontas Building and much of the quarter-acre raised-floor computer room was repurposed to classrooms. VCU returned to an IBM hardware platform after several years on the Amdahl, and retired a zSeries mainframe from service at MCV and VCU in about 2010.

IBM never obsoletes its customers' code and its enterprise and government customers own the largest systems on Earth. Some of this legacy code was written to run indefinitely and remains perfect for the application at hand. In many enterprises, legacy applications originally deployed in the '70s have been 'web-faced' and are thoroughly modern.

Seven Operating System Functions

Operating systems have 'traditionally' provided five main funtions as in the text's Ch 1:

• Interfaces: User, Application Program, Web, and other systems
• Device management: Anything plugged into the bus, USB...
• File management: Local and remote file systems
• Memory management: RAM and Virtual
• Process management: Puts processes to the processors

Prior to the '90s the purchase of a separate 'network operating system' was required if a company wanted to network their computers. Since the '90s as systems became more and more 'client/server' oriented and by more than one person, practically every OS likely to be used in a home or business provided two more functions:

• Authentication, Authorization & Accounting for multi-users
• Networking and Internetworking

Here's discussion of these OS functions. They will be demonstrated during class:

Interfaces:

The User Interface, often called a 'shell', is what we see and use.   Windows provides a GUI shell that handles most OS functions for ordinary users.  It also provides a Windows Command Line (no more DOS since XP) Window where a 'command line interface' is available for less-than-ordinary tasks by owners or network managers.

A Linux or Unix user may have a choice of GUI by using one of the popular XWindows interfaces like Gnome, KDE, or Unity maybe enhanced by Compiz Fusion or other eye-candy for desktop functions.   But, many system and network management functions require use of the 'command line' or 'character based' interfaces. Some servers, routers, and other industrial-strength OSs don't provide a GUI at all.  

We'll cover a few OS/shell combinations in later weeks. The shell allows a user to control the other four components.

OSs also provide other, non-human, interfaces: the API-Application Program Interface provides a way for programs to interface with the OS, allowing a script to direct the OS to do something or query it to get data like file-sizes or the current system date/time. In OS that support web servers there is the CGI, Common Gateway Interface that makes it easy to get data from browsers' or web-services' GET & POST data and Cookies.

Device Management

On a PC Device Management components control access to: peripherals like keyboard, mouse, monitor, printers, speakers, &c;  and, Secondary Storage devices like disk, CD, or tape; network devices; and anything else that is put into a slot or plugged into a PC Slot or USB -- usually the same CPU (or CPUs) that run the OS and programs manage devices. On a larger machine, mid-range or mainframe, specialized CPUs might be dedicated to managing devices so the CPUs that run programs aren't interrrupted for device management tasks.

Spoolers Printers and other 'asynchronous' processes like email generally have a 'spooler' so that jobs don't get mangled together when a network full of people are printing and handling email.

When a print job starts, the output is first placed in 'spool files' on disk, then doled out to the printers using rules set by a network manager. When the job has printed the spool file is deleted. 'Runaway spoolers' are perhaps the biggest cause of system crashes, so careful placement of spool files is critical to prevent spooled print jobs from consuming all the space on a disk...

File System Management

File Management functions let users, or application software, do the basic 'file functions', 'CRUD', with files: create, read, update, delete, + copy.  The OS generally handles entire files, locating them in a hierarchical directory path (hierarchy commonly denoted with \ in Windows, / in *ix, or : in early Mac) and by name.  

Windows and Linux both provide features for searching file systems using 'pattern matching' or other techniques, so that we can find most anything if we can recollect bits or snippets of the content.

To get at the data _inside_ the files usually takes some kind of application software, sometimes provided by the OS and other times purchased thru some developer of software for a platform. For example, OS components called 'editors' (like vi in unix or notepad in Windows) allow users to modify the contents of ASCII, 'plain text', files. But, another, 'non-OS provided' editor provides more functionality for the non-casual user, especially a programmer or administrator, so we find data processing pros choose editors like EMACS, Midnight Commander, Crimson, Visual Studio, DreamWeaver MX, or FrontPage (aggh!) to provide extra power for the particular tasks at hand.

The contents of files containing other data for images, spreadsheets, or Word documents are maintained by applications like GIMP, Excel, or Word.

Memory Management

Memory Management is concerned with the system's Primary Storage, RAM and Cache, located further and nearer from The CPUs. Many operating systems provide Virtual Memory to swap the contents of RAM to disk when there is not enough contiguous space in RAM to handle demands from active processes.  DMA-Direct Memory Access channels built into a computer's switch sets move most data without burdening the CPU.

Memory management includes 'Garbage Collection' to return memory no longer needed by retiring processes to the pool for new processes to use. Garbage collection routines attempt to regain large, contiguous, blocks of space and keep them available for the next process that is launched.  'Memory Leakage', which is rampant in some application environments, especially Windows IMHO, which may result in 'blue screen of death' that was so familiar to NT administrators if they failed to reboot their servers often enough. Later versions of Windows, personal and server, handle memory leakage more gracefully but haven't entirely ridded the environment of the problem. AIX and other UNIXes, especially the non-stop versions, may run their entire service life without leaking memory.

Process and Processor Management

Process Management schemes in personal devices and larger computers are almost all 'multiprocessing' these days.  Flip phones and other primitive personal devices only run one process at a time. Everything else runs at least several concurrent processes, with mid-range and mainframe computers handling millions at a time.

Using ps (process status) in *ix or the Process Manager (ctrl-alt-delete) in Windows shows a list of processes that are running on your computer. Android and iOS can also show us the processes that are running, maybe using up the battery? An operating system's process management functions more-or-less equitably divvy up the limited resource of CPU Time.

In most GUI desktop systems (Windows, Mac, or Linux) there are usually a couple or a few dozen 'processes' vying for compute cycles. Even in a single 32-bit CPU, space in RAM & Cache, and bandwidth on a disk or network controller has been more than adequate to keep a person happy. These systems have provided very 'crisp' response since processors have been at 400-800 MegaHz, where an active GUI presentation & mouse-event capturing was taking about 80% of the CPU's power. Today's 64-bit, multi-core processors only use a few percent of their bandwidth to handle our GUIs and make our applications run faster than ever.

The busy 'host computer' or server that is running an enterprise may have hundreds or thousands of users entering and using data processed by the applications it runs. Each user may be running running one or more processes as they do their work. The mid-range or mainframe computer has more resources and more 'channels' & 'dedicated processors' to manage them. For example, a 32-bit desktop PC could manage 4 GigaBytes of RAM and this was OK for a gamer or engineer running a 'compute intensive' task, or a small server handling a few dozen users, and 'disk swapping' is minimal.

But, a computer with 64-bit technology is able to reference a TeraByte or more of RAM and avoid much disk access altogether, working directly from huge RAM-drives. (IBM has been providing dual-core, 64-bit processors in the Power line since the '90s and 8-core Cell technology since about Y2K. Intel, AMD, and others got there about 2006 and they're headed to the desktops.)

Larger mid-range and mainframe machines can handle several or lots of TeraBytes of RAM and juggle millions of processes among dozens of CPUs to satisfy hundreds of thousands or millions of users' processes.

SMP-Symmetrical Multi Processing

Programming for multiple CPUs can be very difficult. Luckily, technology has mostly automated the job so that most application developers don't have to worry with the complexity of multi-programming to take advantage of the multi-processor environment. They write the code and the OS figures out how best to deploy it on however many CPUs are available.

Along with referencing relatively huge amounts of memory and cache with their 64-bit CPU words, modern workstations, gaming machines, mini-computers, and mainframes may have two or more CPUs/Cores working in parallel using 'SMP' (Symmetrical Multi Processing).  This allows  'multi-threading' techniques of modern OSs & programming languages to be used so that an application's processes can be programmed to run concurrently, when appropriate, instead of in sequence as is required when only one CPU is available. SMP components on the CPUs, mainboards, and operating systems make all this happen automatically. Languages like C++, Java, and VS.NET let programmers write code to take better advantage of multi-CPUs if needed.

An OS that supports SMP automatically divvies up tasks for the multiple CPUs without any of the Programmers' concern. These machines & OSs can service thousands of time-shared Users' keystrokes & requests for database access so efficiently that they all get sub-second response times. Of course, any computer can be 'over loaded' and Users of inadequately-sized systems decorated their cubicles with a picture of skeleton sitting in front of a computer terminal over the caption 'How is the response time?'.

As an historical note, the Motorola 68000 line of included features for communication with a 'supervisory processor' on a board or a backplane that made them more suitable for deployment in a multi-CPU environment for years before Intel processors. When the Intel's 80486 processors came out with this feature, manufacturers of 'highly-available' or 'fault-tolerant' hardware platforms that had used RISC CPUs for a decade, like Stratus, were able to use whichever CPU gave the best bang/buck performance in the season the machine was delivered. This allowed them to deploy multiple unix or Windows servers in one fault-tolerant chassis.

Where we oldsters used to say that RISC processors were better suited for multi-CPU deployment of enterprise applications, there are lots of systems with CISC CPUs that do it well, too. ARM-64 technology may push the server market more firmly toward RISC again, with both Google and Facebook deploying RISC in their data centers. SoC-Systems on Chips built on with ARM-64 technology include Ethernet Fabric processors on the same die with the CPU and are ideal for hyper-converged systems using spine and leaf architecture for their storage-area networks.

We used to see, through the '90s, that the 'point of diminishing returns' was reached at something less than six or eight CPUs in a SMP scheme. But now that number is higher, with server-class machines handling a couple dozen cores per socket and mid-range computers making effective use of hundreds of CPUs for SMP.

IBM provides the ultimate in process control, 'Capacity on Demand', where systems are shipped with additional CPUs to be used, and paid for, only during peak seasons and turned off at other times -- since many of their customers are in retail and 'mail order' they need more CPUs in the lead up to the Holidays in late Fall and the returns season than the other 10 months of the year.

Multi-User OS AAA & Networking

The text discusses the same Five OS Functions the instructor's been discussing since the '80s. Since networks and The Internet came on the scene personal and server operating systems have included two more critical functions:

AAA-Authentication, Authorization & Accounting

AAA Authenticating users, Authorizing their access to system resources, and Accounting for their activity are parts of modern OS like Unix, Linux, or Windows NT or 2003 Server.  Even a 'desktop OS' like XP or an OS for a portable device is likely to include methods for someone with administrator privileges on the machine to set up profiles for individuals who will be using the machine. DOS and early Apple OS, on the other hand, had no way of identifying individual users, and made everything on a machine more-or-less available to whoever flipped the power on.

A UserId and PassWord combination is involved in most methods for authenticating users as they 'log on' to a server or host machine.  Magnetic stripes, rf chips, or biometric devices are also involved in some systems.

Modern 'multifactor' authentication schemes involve more than one factor to authenticate persons:

• Something they know, like a login name and password;
• Something they have, like the magnetic stripe or rf id on an id card, or temporary passcode transmitted to a person's pager via TAP-Telocator Alphanumeric Protocol or their smartphone via SMS;
• Something they are, like a fingerprint or iris scan. Or, more recently, something they do, like gait or gestures on a touch screen.

Other schemes for authenticating users as they connect from one node on a network to another involve keeping a 'private key' in the user's home directory on their 'home machine' and storing a 'public key' in their home directory on machines they visit. This also works to support non-repudiation in eBusiness, where part of the setup for an EDI trading partnership includes exchange of public keys. The PKI-Public Key Infrastructure provides a very secure authentication scheme.

You're welcome to set up rsa keys at info300.net so you can log in from a trusted device without keying the password.

In organizations where there may be a large number of servers it would be extremely inconvenient for a user to be challenged for a password by each of the servers/domain controllers that provides services. In these cases, a 'super domain' scheme like Kerberos, LDAP-Lightweight Directory Access Protocol, or Windows Active Directory is used to authenticate users once and then 'trust' and continue to authorize their use of resources in a secure way. VCU's CAS-Central Authentication Service works this way -- log in once and get access to BlackBoard, VCU's GMail and Google Apps, eServices, and other university on-line resources.

Network Management

Ethernet and Internet protocols have been included in OSs since the mid-80's.  Windows, after 3.11 for workgroups, and Unix have provided networking functions built into the operating system. For years, Apple bundled AppleTalk into their Mac OS and started providing Internet and Ethernet in the late '80s.

Earlier desktop and server OSs, like DOS or CPM, required separate purchase of a 'Network OS' like Novell, LanTastic, Banyon Vines, ThinNet or other network OS so that a PC could share networked resources. Since Windows 3.11 for Workgroups Microsoft included support for SMB and other protocols for a GUI-managed 'Network Neighborhood' with peer-to-peer and client-server relationships.  

All today's personal operating systems have support for Ethernet and Internet protocols built-in. Linux, Windows, Mac, Android, iOS, even Windows CE can do Ethernet and Internet via Cell or LAN. We expect our computers to come out of the box able to participate in LANs and access The Internet as presented by our ISP. Personal devices from smartphones through notebooks and desktops handle the several protocols of the TCP/IP suite, like SMTP, ICMP, POP3, IMAP, HTTP, SFTP, SSH, SSL. TCP, IP.

Common Server OSs are any of these: Proprietary unices like AIX or HP/UX, or SCO UNIXWare; Open Source unices like Linux or OpenBSD; IBM's proprietary non-unix i5/OS or z/OS; or Windows proprietary Server 2000+. These all have protocols built-in for Ethernet, Internet, plus they can interface directly to T-Carrier, E-Carrier for telephone and OC-Optical Carrier for high-speed fiber optices. Since the late '90s practically all servers handle security protocols like SSH, SFTP, and public/private key TLS/SSL for browsers, web services, and applications. Linux and unix servers may be used as gateway, firewall, and/or proxy for internet traffic of http, smtp, pop3 on wired or optical circuits.

Virtual Memory

'Virtual Memory' is a scheme used in multi-tasking OSs where process, memory, and file system management cooperate to run lots of processes thru a number of CPUs that reference the same RAM. Most OSs since the '90s are multi-tasking, whether they operate systems for one or millions of users. PC OSs like Mac, Windoze, or Ubuntu run lots of tasks for a single user -- the W7 I'm using now is running 107 processes for me at the time of this keystroking. Droids run dozens of processes -- my Droid GingerBread is running 47

Servers, like Windows Server, Linux, or zOS run a few tasks at a time for each of the dozens, hundreds, or millions of users attached to the server. Info300.net, aka info202.info, reliably supports a lab or two of 30 users pounding at vi, debugging websites, and running scripts and database queries -- each of these users runs two or three tasks at a time, and would hit a hard limit at about 32,000 tasks. A busy pair of mainframes can handle millions of users' tasks at a time, some of them for employees using the enterprise's application software and others for customers using the enterprise's websites.

As each task is presented to the OS executive, it is assigned a location in 'virtual memory' located on the system's disk and the application's code and data are placed there. The task is scheduled to run on a CPU until completion, usually according to a 'timeslicing' scheme where lots of tasks share a CPU. When a task has a slice of time its code and data are moved into RAM where the data and instructions are available to the CPU and its registers. When the task's timeslice is used, the OS moves the data and code back to Disk and moves the next task's data and code to RAM. This 'swapping' to and from virtual memory to RAM goes on & on until the task is complete.

The benefit of virtual memory is that a multi-tasking server can handle more users' work simultaneously, or a personal computer can handle more tasks for a user at the same time. The cost is that disk access is much slower than RAM access, so a system that needs to swap runs lots slower than one with enough RAM to accomodate all the users' processes' code and data without swapping.

DMA and a large, contiguous 'swap area' laid out cylinder-by-cylinder on disc make swapping as quick as it can be, but swapping is always slow compared to systems that have so much RAM that they don't need to do much swapping. This is true whether the system is a notebook used by one person, or a server used by many. Servers that need to process 'real-time' are configured with enough RAM so that swapping isn't necessary.

Occasionally, virtual memory is used to do the 'garbage collection' required to get enough contiguous space in RAM to launch a large process. We may experience this as several seconds, or more, of a paused interface where we wonder if the system has 'hung up' or 'frozen'.

Huge RAMs on 'Heavy Iron' Mid-range and mainframe computers, with their HUGE RAMs (Several to many TeraBytes!) are able to handle many thousand through millions of tasks without swapping to virtual memory at all -- they do the timeslicing, but don't have to do much swapping.

The sloth of swapping can be demo'd on a personal scale by running Windows Vista or 7 on a machine with only 1 gig of RAM and then loading a few memory-loving apps, or by switching between applications on a cheap tablet with only 256MBytes of RAM. It can be done, but the OS takes up most of the CPUs' bandwidth leaving little available for the users' tasks. If every application has to swap as it runs its timeslice, the effect is not a pleasant experience for the user.

Thrashing is the official term for this. This wiki link describes episodes of thrashing, where the virtual memory system is spending more time swapping users' tasks than processing their work, taking a _lot_ of system resources without doing much real work, ticking off users, and customers, who get a multi-second response where sub-second is the best.

If a non-scalable application environment was chosen, a thrashing system can be the death of an enterprise which can't afford to upgrade or jump to a scalable platform. If scalability was a key objective, an enterprise anticipated exponential growth and can handle it by adding more hardware or computers, quickly 'throwing hardware at it' to keep pace with new acquisitions and markets.

Midrange and mainframes systems with two or three large chassis that can hold lots of components can hold multi-Terabytes of RAM, minimizing the need for swapping, and run literally thousands of times quicker than smaller machines that need to swap.

Server and blade farms made up of smaller machines can also handle exponential growth and give millions of users good response time using 'load balancing', high-speed storage networks, and a lot of power and a/c. The trade-off to give millions of users sub-second response time is a couple of farms of a couple thousand 'server class' machines vs. a couple of big mainframes.

More About CPUs, OSs, Platforms

Business decisions about computer systems aren't usually about the theoretical stuff of CPU architecture and OS features. They're usually about software and databases that will provide a competitive edge and the platforms available to support them. Here's a practical discussion of platforms and their providers in the marketplace these days:

• Intel processors - CISC were at the forefront of the IBM PC revolution, starting with the 8086 and quickly moving to the 80286, then 80386, 80486, Pentium, and Cores 2-7.  The Intel style of instruction set is CISC - Complex Instruction Set Computer. Intel's 8086 CPU was in the the first IBM PCs to leave the factory in 1981. IBM PC technology was made relatively open and easy to license, leading to the 'IBM PC Clones' such as Acer, DFI, Dell, Compaq, and the dozens of others who have shared this huge PC market ever since.
• Motorola processors - RISC Motorola 68000-series RISC CPUs powered Macs for decades, until the recent jump to Intel. Other manufacturers of small computers before IBM and Apple entered the market, like Radio Shack and Commodore, also used RISC/Motorola. These Motorola 68K CPUs were also widely used in small and mid-range servers from the '70s into the '90s.
• Microsoft Operating Systems DOS 1 thru 3.3, Windows 1 thru 3.11 for Workgroups,  Windows NT,  Windows 95 thru 98se, Windows ME (aggh!!), Windows Server 2000 - 2013, Windows XP, Windows 7, 8 (agGH!), and now 10 and all its flavors remain the popular OS for the Intel processor deployed as Notebook, Desktop, or Server. 'WinTel' is a common term for these Windows/Intel platforms.
• IBM is No Longer in the PC Market! IBM immediately grabbed a huge share of the new personal computing marketplace in 1981 with the debut of the IBM PC. IBM encouraged cloning of their machines and component parts for its bus, the first ISA-Industry Standard Architecture. IBM and several clone manufacturers like DFI, Acer, Gateway, or Dell quickly captured about 98% share of the new personal computing market, and kept it for nearly three decades. Now, Apple has about %20+ of the share of this dwindling market. Macs started eating into the PC share when OSX was released and Apple switched from multi-core IBM Power CPUs to Intel at the end of the '00s. IBM left the PC market several years back, making a sweetheart deal with Lenovo to take over their entire line of Intel-based computers for desktops, notebooks, and eventually their xSeries 'blades' for IBM's blade chassis or to slide into a mid-range or mainframe computer's bus. In 2015, without demand for Power in Apple Mac or Sony PS, IBM left this market, too, turning over manufacture of their Power CPUs to Global Foundries. Now IBM buys its the Power chips for their iSeries, pSeries, Watson, and larger super computers from Global Foundries.
  
  IBM also abandoned their OS/2 desktop and small server operating system. They provided OS/2 to their mid-range and mainframe customers as an alternative to Windows that would better integrate with the proprietary networks IBM provided for the environment around their mainframes and mid-range systems. OS/2 was released about the time that Windows 3 was released, and OS/2 could also run DOS & Windows applications. IBM provided several  releases of this probably-superior OS and tried to market it in the personal computing market without much success. They gave up the effort as Microsoft abandoned DOS in new releases of Windows starting with XP, and IBM's customers were asking for compatibility with Ethernet and Internet for small servers and desktop systems. IBM quit marketing OS/2 and immediately became Microsoft's largest customer, able to make more in margins by selling Windows to IBM customers than the profit from selling OS/2. IBM helped their customers extend the value of their legacy mid-range and mainframe systems by better _integrating_ with Windows rather than competing with it.
  
   Well into the 2000's OS/2 was still in use in some environments to run applications associated with IBM mainframes.  My bank used OS/2 to run their telephone banking application until they were acquired by another bank in the early '00s. As recently as 2014, a student in class who works in an IBM mainframe environment reported that their last OS/2 machines were going to be replaced.
  
  
• Windows NT in 1993 followed by Windows 2000 & later 'Windows Server' versions have slowly gained about half share of the workstation/server market. Relative to Unix, Windows is a newcomer to the server market, and in '93 there were few business applications for Windows servers so there was little reason to adopt them and most seasoned network managers viewed NT as a flawed product.
  
   Each release of NT and Windows Server has improved, and it is now more stable and better suited for enterprise computing. Microsoft and other software houses have built excellent applications, Microsoft databases have matured. Now, Windows is an increasingly attractive option for server-class machines. Low-cost & fast 64-bit Intel Processors are bringing more computing power and RAM to these NT descendants, and the next couple of years will be exciting for Windows fanboys as Windows Server continues to mature and may scale to enterprise operations.
• UNIX and Unices on Intel: Prior to the PC in the '80s the ordinary commercial unix platform had a RISC CPU in a mid-range machine, aka mini-computer, that cost $20+K through $1 Million. Starting with the IBM PC-AT and its clones in the early '80s, unix was adapted to Intel's 80286 CPU to make an inexpensive, $6K, and quick platform. Microsoft/SCO released XENIX, SCO released UNIXWare and Open Server, and a few other software houses released unix-like OSs optimized for the Intel/AMD processor. Some of these new Intel, 'x86', operating systems were compliant with major unix standards: ANSI, POSIX, & System V (five).
  
  These new Intel/unix platforms were much more economical and could support applications written for a unix-based minicomputer that cost ten or twenty times more, perhaps ten or twenty years before. With hardware this cheap, a CAL-Concurrent Access License fee of about $179 per user for an operating system was reasonable.
  
  Here is a Unix Pedigree showing how unix & linux have evolved over the decades.  
  
  The Open Source community supports a rich legacy of Linux distributions for Intel collaborating with Linus Torvalds. They made Linux run on 32-bit, multi-core, Intel processors, and it was also adapted to Motorola/Power both 32 and 64-bit multi-core CPUs. When Intel/AMD introduced 64-bit processors, the talented open source community optimized Linux for this platform.
  
  Linux quickly gained a small share of the Intel/SCO UNIX market, but its growth was hampered by the SCO/IBM Lawsuits diagrammed in the Software Wars diagrams. It's tough to compete with a standards-compliant, very quick and reliable, unix that's available for free. IBM and HP, with major market-share in mid-range computers both ship more hardware loaded with Linux than their own AIX or HP/UX.
  
  At 2015, the entry point for a 'supported' RedHat Enterprise OS is $379 per year for two single-socket machines or one mainboard with two sockets, with no charges per CAL-Concurrent Access License. For this price, the machines can be used to support as many concurrent users as their Intel or Power box can support, perhaps 500 or a few thousand depending on the application. RedHat provides their customers with excellent support and tools for managing and virtualizing their servers.
  
  When RedHat became a good option for unix, the most prevalent UNIX on Intel was SCO UNIXWare and Open Server and it cost about $175 per CAL with some discounts for volume, and so was Windows NT or Server.  For an organization with 100 users in the domain a SCO license would cost more than $15,000 to purchase the current version.   It's easy to see the attractiveness of 'Open Source Software' like RedHat? Within a couple of years Microsoft and proprietary Unixes dropped their price per CAL by more than half to about $70 per user. Some few application environments depend on proprietary features and are 'locked into' a proprietary unix like AIX, HP/UX, IRIX, or Solaris. Everybody else can run on standards-compliant Linux, OpenBSD, or another freely available version of unix.
  
  Note: SCO, from 2003 until the case was thrown out of court in about 2010, sued IBM and others in the open source community for violation of intellectual property rights, claiming that substantial portions of their code had been included in the Linux kernel, especially features to handle huge RAM and large directly attached storage units common on mid-range IBM machines running AIX.  (Search google with IBM SCO suit and be prepared to read a lot.)  They wanted end users of Linux to pay them a few hundred dollars for the right to use 'their' code and threatened some of the largest early adopters of Linux with lawsuits if they didn't pay thousands of $$.  We expected these issues would be settled sometime in 2004 but they dragged on. SCO never showed provided the evidence to the IT community and Open Source developers claimed that they arrived at their solutions independently. Early in 2010, the case was thrown out of court with Novell declared the owner of the UNIX trademark and SCO getting nothing. Mid-2010, SCO tried to get the case back in court and in 2014 were able to, only to have it thrown out of court again early in 2016...
  
  FreeBSD provided another unix platform with the Intel processor.  This is another freely available unix, perhaps not as popular as Linux, but it does have its devotees. Microsoft ran HotMail using BSD for some years, had hitches at the first attempt to move HotMail to Windows servers, got it right a few years back... 
  
  Recently, in 2013, IBM divested themselves of all manufacturing of Intel-based computers in the low end of their xSeries, deployed as 'blades' in a chassis that provides redundant power supplies and connections to the network backbone. They still sell a lot of these, but buy them from Lenovo...
  
  
• Motorola shed it's role as a leading manufacturer of CPUs for computers of all sizes, following a few decades of dominance.  The demise of this product line was easily observed right here in River City where, in the mid-'90s Motorola bought a large tract of land West of town to build a new plant where they would make the follow-on models of their 68000-series CPU. They abandoned the project about Y2K, and since then have become less-and-less involved in CPU development. At VCU, their interest was one of the facilitating factors for the founding of the Engineering School. Now, Motorola specializes in relatively low-powered CPUs embedded in radios, cellphones, appliances of all kinds, and automobiles.
  
  This 'Motorola class of processor' uses a different style of instruction set, RISC (Reduced Instruction Set Computer), which is optimal for some diverse computing tasks, like graphics,  database management, SMP, networking, and other tasks associated with running a 'host' computer using Unix or another 'multi-user' OS like DBMS.
  
  The high end of the 'Motorola' line is the 'Power' processor and it has been used in platforms by several manufacturers.  Apple used it until a couple of years back in the Mac.   IBM used Motorola processors in their ubiquitous Unix platform, the RS6000, where it could easily scale to support a thousand or more simultaneous users.  They usually ran 'AIX', written & supported by SCO. 
  
  The '8-core, 64-bit Cell Chip' was IBM's state of the art of the 'Power' Technology, released in about 2004. The Cell Chip has 8 64-bit CPUs on one chip, with a separate CPU to manage the other 8 and handle the SMP with the mainboard. First introduced in Sony's PlayStations and IBM's Super Computers, the Cell Chip is now deployed in IBM's pSeries (i5OS, AIX, Linux) and their super-computer line including Watson. The 64-bit, 8-core Cell Chip was on the market several years before Intel released dual-core, 64bit CPUs, but was introduced without much or any advertisement, typical for IBM, so it remains somewhat obscure where most of Intel's advances get lots of attention.
  
  From the late '70s these 'Motorola' machines running somebody's Unix provided a more-or-less standard platform all around the world and many are still in service.  Hewlett-Packard, ADDS, NCR, Data General, McDonnell Douglas Information Systems, and many other less-well-known manufacturers used Motorola processors -- some putting them on their own processor boards and others buying Motorola boards & chassis and relabelling them as their own ('Original Equipment Manufacturers', called OEMs). 'Standard Unixes' were provided by many computer manufacturers who were compliant with industry standards.
• Unix Standards & Open Systems Several factors helped to standardize unix: ANSI, System V, POSIX, and other standards for unix prevailed. Owners of unix-based application software found that the hardware for their enterprise platforms was now available at commodity rates. Many consultants and software houses embraced the concept of 'Open Systems' and began to drop their strong affiliations with manufacturers of 'closed systems' so they could sell their software and services to run on any platform that ran a standards-compliant unix. XENIX arrived on the scene about the time that IBM PCs emerged, 1981, and the cost of computing hardware to complete an *ix platform plummeted. Relative to the owners of closed systems (IBM System 38, AS400; UNIVAC, Burroughs, NCR, &c, &c), those who owned these open systems were getting excellent results at a fraction of the cost, and found that it was inexpensive to extend the value of their legacy of data and applications by taking advantage of the ethernet, internet, and web server software built-into unix.
  
  Motorola, Sony, IBM, FreeScale, and others were members of a consortium of manufacturers licensed to produce RISC technology. Motorola provided the manufacturing facilities for these RISC processors until the emergence of the 'Power4' chips in the late '90s, which are manufactured directly by IBM. The recent developments in the high-end of the RISC family had been by IBM, with the dual-core, 64bit 'Power5' processor coming into the market at greatly reduced prices in the Summer of '04. The Power5 processor is well-suited for diverse applications like gaming, database, web servers, and process control. IBM used these Power5 processors, sometimes dozens of them in a chassis, to power their 'eServer iSeries' platform, small to mid-range servers. (The 'Cell Chip', or 'SuperComputer on a Chip' is an extension of this, combining 9 RISC CPUs on one chip -- 8 to do processing and the other to divvy up tasks among the other 8. IBM's Watson super computer uses this technology.)
  
  Although they were not as active in development, Motorola continued manufacturing and providing the entire line of '68000' processors for industrial & embedded use, for prices ranging from a few dollars to about $75. Motorola rather abruptly left this market in about 2004 as other RISC manufacturers joined the fray for low-end RISC chips...
  
  There was a resurgence of interest in RISC chips starting in the 2000's. ARM, ACORN, OMAP and other RISC chips after Motorola's departure were exploding into the Smart Phones marketplace including Androids, iPhones, netbooks, and other machines where low cost and low power consumption and temperatures are desirable.
  
  
• IBM provides and supports platforms that range from desktop through mainframe and is notable for surviving as a major provider of computing goods and services since pioneering in the commercial market of the early 1900s.   Here is a side trip through IBM's current product line, to serve as an introduction to the range of computing platforms, from desktop (of which they've abandoned the manufacture in the Summer of '05) through Mainframes and Super Computers.
  
  Many game machines and Apple's Macsintoshes used  IBMs Power4 & Power5 processors, having obsoleted the Motorola chip where blazing speed is required. Apple announced in Summer of '05 that they would be adapting their *ix-like OS to Intel processors, to avail the Mac platform (with a consistent couple-percent of the market for decades) of the power-saving & blazing speed of the CISC line's next generation of 64-bit, dual-core processors. In 2014, Sony moved to Intel chips for its PlayStation line.
  
  IBM's eServer product line makes extensive use of IBM processors, although the lower end is likely to be Intel powered.   They've recently (2004) streamlined and renamed their venerable old product lines, always providing excellent support and backward compatability for the languages and DBMS for their customers' applications.  It is not uncommon for an application developed in the 70's for a System 38 or AS400 to be in use today on an eServer iSeries, and to be the best application for the job.
  
  IBM's eServer xSeries uses both Intel & 64-bit, RISC, Power processors. Through '04 & '05 IBM has gained market share among Intel platform providers by optimizing their 'blade center' to support dozens or hundreds of Intel machines to provide highly-available clusters and interface to the industry's fastest network storage. (Now, Lenovo builds all the Intel-based product line for IBM.) IBM provides 'instrumentation' software for the OSs in the blades so that they may be efficiently management by system & network administrators using IBM's 'Virtualization Engines' to manage their herd of CPUs.
  
  Nearly 100% of Fortune 500 Enterprises and governments run on IBM. Nearly 80% of those, by 2014, were running some form of IBM's Cloud technology, extending the value of their legacy systems in a virtualized environment.
  
  For many, perhaps the most reasonable, administrators (no bias here, no dinosaur in this room) the ideal is _not_ to have hundreds or thousands of little *ix or Windoze servers. The ideal is to have one big, fast machine that can handle everything -- that is quick and easy to back up and recover from a single volume of tapes -- or that can participate in a cluster, grid, or 'parallel sysplex' to ensure 100% availability. The 'mid-range' computer evolved in the '60s as an affordable alternative for businesses that had not afforded the 'mainframe' computer that dominated big business from its emergence in he '50s. In many cases, these mid-range computers (built to support larger & larger numbers of on-line, time-shared users) out-performed the mainframes (built for 'batch' processing).
  
  IBM's current _proprietary_ mid-range product line started with System 3 and 38 and grew into the very popular AS400. This has been renamed as the eServer iSeries and now it extends IBM's multi-core, true 64bit Power processors through a range of computers which may host from a few thru tens of thousands of simultaneous users and provide them with sub-second response times and 100% availability.   These machines run combinations of OS400, i5/OS, Linux, AIX, Windows, and other OSs for special purposes.
  
  Leading the industry in 'virtualization of resources', IBM took what it learned from the VM 'Virtual Machine' Mainframes that were able to run multiple OSs simultaneously and applied it to their mid-range computers. Today, a single iSeries (perhaps deployed in multi-chassis) may have dozens of LPARs-Logical Partitions that share a huge 'pool' of CPU, RAM, Disk, and Network components. This allows a company who may have inadvertantly grown a server farm for linux and unix applications the option of migrating them all to 'one box', maybe another in parallel somewhere else, where it may be backed up, managed, and recovered much more conveniently than dozens of 'really separate machines'.
  
  IBM's other mid-range product line started with the RS6000 in the '80s which has been renamed the eServer pSeries and makes use of the Power processor.  The OS for this platform is either AIX (from SCO) or Linux. For decades IBM has provided support world-wide for these Motorola-based, RISC machines and eventually started building the CPU chips for them as their own POWER line of proessors. This allowed companies to enjoy almost-commodity pricing of reliable hardware and also participate in the savings of excellent, multi-user applications developed for 'open systems' supporting *ix. IBM shared world-wide in this market along with HP, NCR, SGI, Sun & a few other manufacturers.
  
  The 'Mainframe' goes beyond the mid-range in capacity for transaction processing and databases. Originally developed in the 1960s for 'batch processing' of transactions for organizations and business of all sizes, 'the mainframe' has been adapted to high-speed optical circuits on the internet and can serve as a web server that can provide millions of users with sub-second response time.
  
  Most mainframes, and mid-range computers, run their entire service life without any unscheduled downtime, and some don't schedule any downtime. The most critical application servers are deployed in parallel with one or more remotely located machines, resulting in an exceptional record for availability and business continuity in spite of local or regional disasters.
  
  Today, IBM has a few competitors in the Mainframe market and some of them run IBM's mainframe OS. After a few years of avoiding the term 'mainframe' in favor of 'Super Servers' (HESS-High End Super Servers) to avoid the dinosaur imagery conjured up by the word mainframe, IBM now calls these machines mainframes and markets them as theeServer zSeries.
  
   IBM's mainframes can scale to dozens and dozens of zAAP processors and and can run multiple OSs concurrently. z/OS is IBM's current OS and it's VM can also run anything earlier and Linux simultaneously.  In the past, it took a working knowledge of IBM's assembler language to administer a mainframe-class system -- now, the machines can boot and run Linux without requiring this rare skillset.  Also, leaving the very, very expensive OS/390 or z/OS out of the platform allows IBM to market these machines at a much lower price for applications where backward compatability for a legacy of old COBOL applications isn't needed.  
  
  A middle-of-the-line zSeries machine costing a couple million dollars can provide sub-second response to  millions of simultaneous web browsers, making this a really kick-butt web server for a company that has a legacy of OS/360-based applications tending data that need to be made available for customers and employees via The Internet.   There's little wonder that EBay recently partnered with IBM and continues to provide crisp response for 100s of thousands of EBayers waiting until the last possible moment to snipe some item.
  
• Sun Microsystems had a proprietary Sparc processor that for decades out-performed many of its competitors and until recently was the server-of-choice for large unix-based applications, especially those written in Java.  The Sparc processor and Solaris OS are a very scalable platform for all kinds of networked applications.  They're hanging onto share in the multi-processor server market, and recently donated lots of software to the Open Source community. In 2010, Sun was acquired by Oracle, who continues to develop the Sun product-line -- most of Oracle's (a giant DBMS and software house) customers were running on Sun so they stepped in to stabilize a flagging Sun Microsystems to provide comfort for their customers.
  
  
• SGI (Silicon Graphics) is trying to hang onto market share they gained when their Geometry Engine made them the processor of choice for graphics & animation.  Many of the animations and special effects that have dazzeled us for the last decade where produced on SGI platforms running irix as the OS. SGI was also, through the '90s, the platform of choice for data-warehousing and other database-intensive applications. Their ability to reference huge amounts of RAM got them in as the heart of AOL, which grew quickly from a small BBS to a huge on-line community just as the World Wide Web was also taking on more and more users. In 2015 SGI may be going bust, or may continue on with the support of relatively few loyal customers, who are locked into the platform. Recently SGI has made advances in the Super-Computer market. With very powerful options in other CISC and RISC CPUs, SGI has no need for their own IRIS Geometry Engine.
  
  
• Other Platforms There are a dozen or more other platforms still used for deploying applications.  These discussed here come to my mind as the most likely to be encountered, but they aren't the whole spectrum or history of computing.  
  
  If we look at particular 'vertical markets' we find odd names popping up.  For example, half the auto dealers in Richmond (or any city) are likely to use a platform provided by McDonnell Douglas Information Systems, which is now a UK-based firm that specializes in systems for police and hospitals.  
  
  If we go back to the 60s there are hundreds of platforms that have become obsolete, sometimes causing great expense for the enterprises that used their special, proprietary features to develop their applications and had to replace an entire legacy of application software.  But, I'm not going to try a recitation of those here...  
• Emerging Platforms: New technologies like Virtualization, Hyperconverged Systems, and Web-Scale IT are gaining market share in these modern times. In some cases they're adopted by start-up organizations, in others they are a way of extending the value of legacy software and database system. These are discussed further in another topic

---