Introduction & 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:
  
  
  
  
  
  
• 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.  It is one of the most important strategic decisions an enterprise has to make.
  
  It's not a simple situation these days where there are so may choices competing for a share of the market.  My OS Humor page includes 3 battlefield diagrams of the Software Wars from 2000 thru 2003 that highlight the effect of the Open Source movement.
  
  
• Operating Systems are always built for or adapted to a particular class of 'processor' or CPU.  The combination of computing hardware and OS provides a platform. Some OS are built for more than one CPU -- Mac OSX started on Power & was adapted to Intel. The Linux kernel runs fine on Acorn, ARM, Motorola, Intel, and has also been adapted to Sparc and SGI. IBM has embraced the Open Source community and has adapted the kernel to run 'native' on its p & z (mid-range & mainframe) processors.
  
  If an application has been written in a very 'generic' way, not using any special features of a particular CPU's instruction set, then it is very likely that the application's code can be moved very easily among any of these CPUs. Microsoft _used_ to run on MIPS, Sparc, and Intel but now I believe it's only deployed on Intel & Intel-clone CPUs
  
   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...
  
  
• These days, new 'layers' are being added to the traditional OS cake.  
  
  Microsoft has recently provided an important, additional 'layer', the .NET Framework, where several application environments (web services, web pages, Windows forms, &c) sit above a 'Common Runtime Language' that sits between application programs and the OS.  
  
  
  
  
  

  Lubricated by this CLR, it won't be long before the .NET framework is tweaked to work with Unix, Linux, and even mainframe-class hardware.   (So something like this might actually happen...)
  
  Actually, it _is_ happening with the Mono Project.
  
  
• Other 'manufacturers' of hardware and/or software, like IBM, 
  Sun, and/or the Open Source Community provide similar layers to facilitate programming and operation of application software.  Java and its surrounding tools and 'addons' are an example.  These 'runtime layers' help make an application development environment easy to deploy on multiple OSs and provides lots of tools that make programmers much more productive.
  
  
• Operating Systems traditionally have five components:
  
  
  • The User Interface, often called a 'shell', is what we see and use.  
    
    Windows provides a GUI shell that handles most OS functions.  It also provides a DOS or Command (no more DOS since XP) window where a 'command line interface' is desirable.
    
    A Linux or Unix user may have a choice of GUI by using one of the popular XWindows interfaces like Gnome or KDE.  But, many of us prefer to use command line or 'character based' interfaces for some OS functions.  
    
    We'll cover a few OS/shell combinations in later weeks.
    
    The shell allows a user to control the other four components.
    
    
  • 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.
    
    
  • File Management functions let users, or application software, do the basic 'file functions' with files: create, modify, delete, & copy.  The OS generally handles entire files, locating them in a hierarchical directory path (hierarchy commonly denoted with \,/, or :) and by name.  
    
    To get at the data _inside_ the files usually takes some kind of 'application', 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 that provide extra power for the 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 is concerned with the system's Primary Storage, which is RAM and Cache, located nearer or further, respectively, from The Processor.  DMA (Direct Memory Access) channels and hardware components in a computer's 'chip set' offload some memory processing from the CPU so that the CPU can initiate data movement to ro from RAM, do something else while the data are moving, and get notified via an interrupt when the data have been moved.
    
    Memory management involves activity in the 'background' like the 'garbage collection' routines that free up the space in RAM that has been used by OS and applications that no longer need the space.  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 Windows (and *ix) applications, may result in no contiguous blocks of RAM and the 'blue screen of death' that was so familiar to Windoze Users & NT administrators if they failed to reboot their servers often enough...
    
    
  • Processor Management schemes are almost all 'multiprocessing' these days.  Using ps (process status) in *ix or the Process Manager (ctrl-alt-delete) in Windows shows a list of processes that are running on a computer. The OS's processor 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 in a single 32-bit CPU, space in RAM & Cache, and bandwidth on a disk or network controller. These systems have provided very 'crisp' response since processors have been at 200-400 MegaHz, where an active GUI presentation & mouse-event capturing was only taking about 80% of the CPU's power.
    
    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 can manage 2 GigaBytes of RAM and this is fine for a gamer or engineer running a 'compute intensive' task, and 'disk swapping' is minimal -- but, a large mid-range computer with 64-bit technology is able to reference multi-TeraBytes 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. Intel, AMD, and others got there about 2006 and they're headed to the desktops.)
    
    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 working 'in parallel' or 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. Java and .NET let programmers take advantage of multi-CPUs.
    
    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 line of CPUs 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 80486 processors came out, 'highly available' system manufacturers like Stratus used whichever gave the best bang/buck performance in the season the machine was delivered. Where we used to say that RISC processors were better suited for multi-CPU deployment of enterprise applications, it may be a moot point now that CISC CPUs can do it too. We used to see, in the '80s, 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, allowing 'ordinary' mid-range computers to make effective use of 32 or more CPUs for SMP in multi-user applications. (IBM provides the ultimate in 'process control', 'capacity on demand', where systems are shipped with additional CPUs to be used, and paid for, during peak seasons and turned off at other times...)
    
    
    
• 'Modern' OSs include more functions than the text mentions:
  
  
  • Authenticating users & authorizing their access to files, applications, and OS functions is part of a 'multi user' OS like Unix, Linux, or Windows NT or 2003 Server.  Even a 'desktop OS' like XP includes methods for someone with administrator privileges on the machine to set up profiles for individuals who will be using the machine. DOS, 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.
    
    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.
    
    In computer rooms and NOCs where there may be a large number of servers it would be extremely inconvenient for a user to be challenged by each of the servers as it provided its service. In these cases, a 'super domain' scheme like Kerberos, 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.
    
  • Network support is included in modern OSs since the mid-80's.  Windows after 3.11 for workgroups, and Unix provide networking functions. Earlier desktop OSs, like DOS or CPM, required purchase of a 'Network OS' like Novell, LanTastic, or Banyon Vines so that the PC could share networked resources. 
    
    All today's desktop systems, like Linux, Windows and Mac, have support for multiple LAN protocols along with TCP/IP for The Internet. Even the PDAs come out of the box able to participate in LANs, wired & WiFi, and Internet.
    
    Server OSs (NT, W2xServer, *ix) include networking functions for LAN, WAN, and The Internet.  They may serve 'The Internet' by acting as a gateway, firewall, and/or proxy for 'internet traffic' of http, smtp, pop3 and other web documents and services.
    
    
    
    
• Platforms
  
  The text's first paragraph packs a wallop into a few words.  The author observes that: a computer fresh off the assembly line can't do anything without any software; it provides an unfriendly interface; even experienced programmers find it difficult to program the 'raw iron.'
  
  There are only a few hundred programmers who do this programming at the 'machine code level'.  They are gifted individuals who can visualize how a CPU and it's registers and instructions work in binary and write the 'assemblers' and 'compliers' that are used by other programmers to write the operating system and programming languages for a particular platform. 
  
  Machine Code is binary code, and/or hex code, that interacts directly with a particular CPU's 'instruction set'.  After it's in place, the way is paved for use of kinder, gentler languages to complete the platform.
  
  Assembler Code is somewhat more civilized than binary and provides a pretty much one-to-one correspondence between a CPU's instruction set and the abbreviations (acronymns) that make up the rather cryptic assembly language.  An 'assembler programmer' needs to understand how the CPU works, but their programming can be quicker because they can type abbreviations instead of long strings of zeroes and ones.  When the 'assembler program' has been edited and debugged, it can be 'assembled' into binary, or executable, code that will run on one (class of) processor.
  
  'Assembly Language', and higher order languages like C or C++, are used to write the OS.  There are relatively few 'assembler programmers'.  Even though coding in assembly language isn't _as_ tedious as coding in binary, it still takes special skills and interest to do this work.
  
  Machine and assembler programmers are likely to work for a software house that provides an operating system for a particular processor.  They work for Sun, IBM, MicroSoft, and SCO.  
  
  They also work in the OpenSource environment, providing Linux and FreeBSD platforms for Intel-like processors as a by product of their self-actualization.
  
  They make the application development languages work for their platform.  This paves the way for the 'application programmers' who write the programs we install after the OS is in place.  
  
  Some 'application programming languages' are 'platform independent' and have been designed so that it is easy for a platform provider to make that language work on their platform.  COBOL, C, C++, BASIC, FORTRAN, Pascal, Java, Python, and a host of less-well-known languages will run on Windows, and other platforms.  If you know how to program in COBOL on an IBM mainframe most of the skills will still apply on a UniSYS mainframe.  
  
  Other application programming languages are quite dependent on a particular platform and won't run anywhere else. VisualBasic, for example, runs only on a Windows platform, and inroads are being made by the Mono project to support the .NET Framework on Linux & BSD.
   
  
• Operating Systems are dependent on & written for (or adapted to) a particular manufacturer's CPU.   There are important exceptions to this.  IBM's OS390 runs on IBM's 3090 & 9000 series of processors but is also licensed for use by their competitors, most notably Hitachi.  
  
  Microsoft writes OSs for an Intel CPU, but AMD builds a processor that uses the same binary instruction set as Intel, so either manufacturer's chip will combine with Windows to provide a stable platform.  
  
  Microsoft _used to_ write Windows to run on Sun's Sparc processor, which is quite a different instruction set from an Intel processor.  It was quite a quick combination for a couple of years and attracted a lot of attention, but there's no market for this platform anymore.
  
  
• Here are platforms you're likely to encounter today:
  
  
  • Intel processors were at the forefront of the PC revolution, starting with the 8080 (I believe).  This style of instruction set (CISC - Complex Instruction Set Computer) has continued on through the current Pentium IVs and whatever comes next.  They were the first in the IBM PC, and the technology was made relatively open and easy to license, leading to the 'IBM Clones' that have had huge market share ever since.  
    
    DOS 1 thru 3.3, Windows 1 thru 3.11 for Workgroups,  Windows NT,  Windows 95 thru 98se, Windows ME (aggh!!), Windows 2000, and Windows XP in all its flavors are the most popular platforms for the Intel processor when it is deployed as a 'Personal' or 'Desktop' computer.
    
    IBM provided another platform for Intel processors with their OS/2.  It was released about the time that Windows 3 was released, and they provided several  releases of this probably-superior OS until they gave up the effort a couple years back.  OS/2 is still in use in some environments to run applications that are associated with IBM mainframes.  My bank uses OS/2 to run their telephone banking application. As at '09 OS/2 applications are pretty much off the digital landscape...
    
    Windows NT followed by 2000 & 2003 Server have gained share in the low-to-mid-range server market. Relative to Unix, Windows is a relative newcomer to the 'host' and 'server' market.  Each release becomes more stable and easy to use, making Windows an attractive option for this class platform. Emerging, low-cost & fast 64-bit Intel Processors are bringing true mainframe power to NT descendents...
    
    Software houses have combined Unix and unix-like OSs with the Intel processor to provide a more economical platform to support applications that were written for a unix-based minicomputer, perhaps ten or fifteen years before.  SCO (Santa Cruz Operation) is the 'owner' of the most prevalent platform, and maintains that they own some of the code in current Linux distributions. Here is a pedigree showing how unix & linux have evolved.  
    
    The Open Source community has provided a 'unix-like' platform, loosly collaborating with Linus Torvalds to make Linux run on Intel-class processors.  Linux quickly gained share in the unix-server market from SCO.   And, it made unix/linux readily available for the ordinary hacker, and cracker, which has fostered diverse interests in this platform.
    
    At 2010, a well-supported RedHat Linux distribution cost about $379 for two single-socket machines or one with two sockets. For this price, the machines can be used to support as many concurrent users as an Intel box can support, perhaps 200 or a thousand depending on the application.   SCO costs about $175 per user license, with some discounts for volume.  For an organization with 100 users in the domain, the OS costs $379 for Linux, where the SCO license cost more than $15,000.   See the attraction?
    
    SCO has been for the past year (since 2003) suing IBM and others for violation of intellectual property rights, claiming that substantial portions of their code has been included in the Linux kernel.  (Search google with IBM SCO suit and be prepared to read a lot.)  They're wanting end users of Linux to pay them a few hundred dollars for the right to use their code and have threatened some of the largest users of Linux with suits as well.  We expected these issues would be settled sometime in 2004, but now it appears litigation will be long-term. (Early in 2010, the case was thrown out of court with Novell declared the owner of the UNIX trademark. Mid-2010, SCO is trying to get the case back in court...
    
    FreeBSD provides another 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, IBM has packaged Intel processors in the low end of their xSeries, deployed as 'blades' in a chassis that provides redundant power supplies and connections to the network backbone.
    
    
  • Motorola has pretty much shed it's role as a leading manufacturer of CPUs for computers, 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, and other tasks associated with running a 'host' computer using Unix or another 'multi-user' OS like DBMS.
    
    The Motorola 'Power' processor is (still) found in machines 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 'cell chip' is IBM's state of the art of the 'Power' Technology. This has 8 64-bit processors on one chip, with a separate CPU to handle the SMP. First introduced as a game box CPU, the Cell Chip is now deployed in IBM's System i, mid-range system.
    
    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.
    
    ANSI, System V, POSIX, and other standards prevailed and owners of *ix-based application software found that the hardware for their enterprise platforms was now available at commodity rates. 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 to take advantage of the networking functionality built-into *ix.
    
    Motorola and IBM were members of a 'consortium' of manufacturers licensed to produce RISC technology, and 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 line have 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 uses these Power5 processors, sometimes dozens of them in a chassis, to power their 'eServer iSeries' platform, which covers the entire range of small to mid-range servers. (The 'Cell Chip', or 'SuperComputer on a Chip' is an extension of this, combining 9 PISC CPUs on one chip -- 8 to do processing and the other to divvy up tasks among the other 8.)
    
    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. I've learned from a student in class Fall '05 that Motorola no longer manufactures the low-end, industrial & embedded, CPUs, and need to update this posting.
    
    In 2010, there has been a resurgence of interest in RISC chips. ARM and other RISC chips are being actively deployed in Smart Phones including Androids, netbooks, and other machines where low power consumption and reduced instruction set 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 newest Macintoshes use  IBMs Power4 & Power5 processors, having obsoleted the Motorola chip where blazing speed is required, and much of the old Apple/Mac OS was replaced with Unix at the same time. Apple announced in Summer of '05 that they will 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.
    
    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. They provide '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.
    
    For many, perhaps the most reasonable, administrators (no bias here, no dinosaur in this room) the ideal is _not_ to have dozens or hundreds of little *ix or Windoze machines. 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 or grid 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 dual-core, true 64bit Power5 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, for example, a single iSeries (perhaps deployed in multi-chassis) may be 'logically partitioned' into dozens of 'virtually separate machines' that share in a huge 'pool' of CPU, RAM, Disk, and Network components. This allows a company who may have inadvertantly grown a 'server farm' to migrate all the applications into 'one box' where it may be backed up, managed, and recovered much more conveniently than dozens of 'really separate machines' in some computer rooms.
    
    IBM's very popular _open_ mid-range product line started with the RS6000 in the '80s which has been renamed the eServer pSeries and makes use of IBMs 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. 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 & others I could recollect.
    
    The 'Mainframe' goes beyond the mid-range in capacity. Although originally developed for the 'batch processing' of transactions for large enterprises and agencies, 'the mainframe' has been adapted to modern networking and can also serve as a database or web server that can provide hundreds of thousands of simultaneous users with sub-second response time.
    
    Today, IBM has few competitors in the Mainframe market. After a few years of avoiding the term in favor of 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.  They use IBM's zAAP processor and can even run multiple OSs concurrently: z/OS, OS/390, VM, and Linux.  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 few million dollars can provide subsecond response to  hundreds of thousands of simultaneous web browsers, making this a really kick bu-- 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 Sparc processor that for decades has out-performed many of its competiors and until recently was the server-of-choice for large *ix-based applications.  This processor and the Solaris OS provide a powerful and 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.
    
    
  • 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.
    
    
  • There are dozens of 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...