A super-server or sometimes called a service dispatcher is a type of daemon run on Unix-like systems. A super-server starts other servers when needed with access to them checked by a TCP wrapper, it uses few resources when in idle state. This can be ideal for workstations used for local web development, client/server development or low-traffic daemons with occasional usage. There is a slight delay in connecting to the sub-daemons. Thus, when compared to standalone servers, a super-server setup may perform worse when under high load; some servers, such as hpa-tftpd, therefore take over the internet socket and listen on it themselves for some specified interval, anticipating more connections to come. Inetd launchd systemd ucspi-tcp xinetd
The system console, computer console, root console, operator's console, or console is the text entry and display device for system administration messages those from the BIOS or boot loader, the kernel, from the init system and from the system logger. It is a physical device consisting of a keyboard and a screen, traditionally is a text terminal, but may be a graphical terminal. System consoles are generalized to computer terminals, which are abstracted by virtual consoles and terminal emulators. Today communication with system consoles is done abstractly, via the standard streams, but there may be system-specific interfaces, for example those used by the system kernel. Prior to the development of alphanumeric CRT system consoles, some computers such as the IBM 1620 had console typewriters and front panels while the first programmable computer, the Manchester Baby, used a combination of electromechanical switches and a CRT to provide console functions—the CRT displaying memory contents in binary by mirroring the machine's Williams-Kilburn tube CRT-based RAM.
On traditional minicomputers, the console was a serial console, an RS-232 serial link to a terminal such as a DEC VT100. This terminal was kept in a secured room since it could be used for certain privileged functions such as halting the system or selecting which media to boot from. Large midrange systems, e.g. those from Sun Microsystems, Hewlett-Packard and IBM, still use serial consoles. In larger installations, the console ports are attached to multiplexers or network-connected multiport serial servers that let an operator connect a terminal to any of the attached servers. Today, serial consoles are used for accessing headless systems with a terminal emulator running on a laptop. Routers, enterprise network switches and other telecommunication equipment have RS-232 serial console ports. On PCs and workstations, the computer's attached keyboard and monitor have the equivalent function. Since the monitor cable carries video signals, it cannot be extended far. Installations with many servers therefore use keyboard/video multiplexers and video amplifiers to centralize console access.
In recent years, KVM/IP devices have become available that allow a remote computer to view the video output and send keyboard input via any TCP/IP network and therefore the Internet. Some PC BIOSes in servers support serial consoles, giving access to the BIOS through a serial port so that the simpler and cheaper serial console infrastructure can be used. Where BIOS support is lacking, some operating systems, e.g. FreeBSD and Linux, can be configured for serial console operation either during bootup, or after startup, it is possible to log in from the console. Depending on configuration, the operating system may treat a login session from the console as being more trustworthy than a login session from other sources. Command-line interface Console application Console server Linux console Virtual console Win32 console
In computing, a desktop environment is an implementation of the desktop metaphor made of a bundle of programs running on top of a computer operating system, which share a common graphical user interface, sometimes described as a graphical shell. The desktop environment was seen on personal computers until the rise of mobile computing. Desktop GUIs help the user to access and edit files, while they do not provide access to all of the features found in the underlying operating system. Instead, the traditional command-line interface is still used when full control over the operating system is required. A desktop environment consists of icons, toolbars, folders and desktop widgets. A GUI might provide drag and drop functionality and other features that make the desktop metaphor more complete. A desktop environment aims to be an intuitive way for the user to interact with the computer using concepts which are similar to those used when interacting with the physical world, such as buttons and windows.
While the term desktop environment described a style of user interfaces following the desktop metaphor, it has come to describe the programs that realize the metaphor itself. This usage has been popularized by projects such as the Common Desktop Environment, K Desktop Environment, GNOME. On a system that offers a desktop environment, a window manager in conjunction with applications written using a widget toolkit are responsible for most of what the user sees; the window manager supports the user interactions with the environment, while the toolkit provides developers a software library for applications with a unified look and behavior. A windowing system of some sort interfaces directly with the underlying operating system and libraries; this provides support for graphical hardware, pointing devices, keyboards. The window manager runs on top of this windowing system. While the windowing system may provide some window management functionality, this functionality is still considered to be part of the window manager, which happens to have been provided by the windowing system.
Applications that are created with a particular window manager in mind make use of a windowing toolkit provided with the operating system or window manager. A windowing toolkit gives applications access to widgets that allow the user to interact graphically with the application in a consistent way; the first desktop environment was sold with the Xerox Alto in the 1970s. The Alto was considered by Xerox to be a personal office computer. With the Lisa, Apple introduced a desktop environment on an affordable personal computer, which failed in the market; the desktop metaphor was popularized on commercial personal computers by the original Macintosh from Apple in 1984, was popularized further by Windows from Microsoft since the 1990s. As of 2014, the most popular desktop environments are descendants of these earlier environments, including the Aero environment used in Windows Vista and Windows 7, the Aqua environment used in macOS; when compared with the X-based desktop environments available for Unix-like operating systems such as Linux and FreeBSD, the proprietary desktop environments included with Windows and macOS have fixed layouts and static features, with integrated "seamless" designs that aim to provide consistent customer experiences across installations.
Microsoft Windows dominates in marketshare among personal computers with a desktop environment. Computers using Unix-like operating systems such as macOS, Chrome OS, Linux, BSD or Solaris are much less common. Among the more popular of these are Google's Chromebooks and Chromeboxes, Intel's NUC, the Raspberry Pi, etc. On tablets and smartphones, the situation is the opposite, with Unix-like operating systems dominating the market, including the iOS, Tizen and Ubuntu. Microsoft's Windows phone, Windows RT and Windows 10 are used on a much smaller number of tablets and smartphones. However, the majority of Unix-like operating systems dominant on handheld devices do not use the X11 desktop environments used by other Unix-like operating systems, relying instead on interfaces based on other technologies. On systems running the X Window System, desktop environments are much more dynamic and customizable to meet user needs. In this context, a desktop environment consists of several separate components, including a window manager, a file manager, a set of graphical themes, together with toolkits and libraries for managing the desktop.
All these individual modules can be exchanged and independently configured to suit users, but most desktop environments provide a default configuration that works with minimal user setup. Some window managers—such as IceWM, Openbox, ROX Desktop and Window Maker—contain sparse desktop environment elements, such as an integrated spatial file manager, while others like evilwm and wmii do not provide such elements. Not all of the program code, part of a desktop environment has effects which are directly visible to the user; some of it may be low-level code. KDE, for example, provides so-called KIO slaves which give the user access to a wide range of virtual devices; these I/O slaves are not av
Z/OS is a 64-bit operating system for IBM mainframes, produced by IBM. It is the successor to OS/390, which in turn followed a string of MVS versions. Like OS/390, z/OS combines a number of separate, related products, some of which are still optional. Z/OS offers the attributes of modern operating systems but retains much of the functionality originating in the 1960s and each subsequent decade, still found in daily use. Z/OS was first introduced in October 2000. Z/OS supports stable mainframe systems and standards such as CICS, COBOL, IMS, DB2, RACF, SNA, IBM MQ, record-oriented data access methods, REXX, CLIST, SMP/E, JCL, TSO/E, ISPF, among others. However, z/OS supports 64-bit Java, C, C++, UNIX APIs and applications through UNIX System Services – The Open Group certifies z/OS as a compliant UNIX operating system – with UNIX/Linux-style hierarchical HFS and zFS file systems; as a result, z/OS hosts a broad range of open source software. Z/OS can communicate directly via TCP/IP, including IPv6, includes standard HTTP servers along with other common services such as FTP, NFS, CIFS/SMB.
Another central design philosophy is support for high quality of service within a single operating system instance, although z/OS has built-in support for Parallel Sysplex clustering. Z/OS has a Workload Manager and dispatcher which automatically manages numerous concurrently hosted units of work running in separate key-protected address spaces according to dynamically adjustable goals; this capability inherently supports multi-tenancy within a single operating system image. However, modern IBM mainframes offer two additional levels of virtualization: LPARs and z/VM; these new functions within the hardware, z/OS, z/VM — and Linux and OpenSolaris support — have encouraged development of new applications for mainframes. Many of them utilize the WebSphere Application Server for z/OS middleware. From its inception z/OS has supported tri-modal addressing. Up through Version 1.5, z/OS itself could start in either 31-bit ESA/390 or 64-bit z/Architecture mode, so it could function on older hardware albeit without 64-bit application support on those machines.
IBM support for z/OS 1.5 ended on March 31, 2007. Now z/OS only runs in 64-bit mode. Application programmers can still use any addressing mode: all applications, regardless of their addressing mode, can coexist without modification, IBM maintains commitment to tri-modal backward compatibility. However, increasing numbers of middleware products and applications, such as DB2 Version 8 and above, now require and exploit 64-bit addressing. IBM markets z/OS as its flagship operating system, suited for continuous, high-volume operation with high security and stability. Z/OS is available under standard license pricing as well as via IBM Z New Application License Charges and "IBM Z Solution Edition," two lower priced offerings aimed at supporting newer applications. U. S. standard commercial z/OS pricing starts at about $125 per month, including support, for the smallest zNALC installation running the base z/OS product plus a typical set of optional z/OS features. Z/OS introduced Variable Workload License Charges and Entry Workload License Charges which are sub-capacity billing options.
VWLC and EWLC customers only pay for peak monthly z/OS usage, not for full machine capacity as with the previous OS/390 operating system. VWLC and EWLC are available for most IBM software products running on z/OS, their peaks are separately calculated but can never exceed the z/OS peak. To be eligible for sub-capacity licensing, a z/OS customer must be running in 64-bit mode, must have eliminated OS/390 from the system, must e-mail IBM monthly sub-capacity reports. Sub-capacity billing reduces software charges for most IBM mainframe customers. Advanced Workload License Charges is the successor to VWLC on mainframe models starting with the zEnterprise 196, EAWLC is an option on zEnterprise 114 models. AWLC and EAWLC offer further sub-capacity discounts. Within each address space, z/OS permits the placement of only data, not code, above the 2 GB "bar". Z/OS enforces this distinction for performance reasons. There are no architectural impediments to allowing more than 2 GB of application code per address space.
IBM has started to allow Java code running on z/OS to execute above the 2 GB bar, again for performance reasons. Starting with z/OS version 2 release 3, code may be placed and executed above the 2 GB "bar"; however few z/OS services may be invoked from above the "bar". Memory is obtained as "Large Memory Objects" in multiples of 1 MB. There are three types of large memory objects: Unshared – where only the creating address space can access the memory. Shared – where the creating address space can give access to specific other address spaces. Common – where all address spaces can access the memory. Generation Data Group is a special type of file used by IBM's mainframe operating system z/OS; the actual GDG is a description of how many generations of a file are to be kept and how old the oldest generation must be at least before it is deleted. Whenever a new generation is created, the system checks whether one or more obso
Universal Time-Sharing System
The Universal Time-Sharing System was an operating system for the XDS Sigma series of computers, succeeding Batch Processing Monitor /Batch Time-Sharing Monitor. UTS was announced in 1966, but because of delays did not ship until 1971, it was designed to provide multi-programming services for online user programs in addition to batch-mode production jobs, symbiont I/O, critical real-time processes. System Daemons, called "ghost jobs" were used to run monitor code in user space; the final release, D00, shipped in January, 1973. It was succeeded by the CP-V operating system, which combined UTS with the batch-oriented Xerox Operating System; the CP-V operating system, the compatible successor to UTS, was released in August 1973. CP-V supported the same CPUs as UTS plus the Xerox 560. CP-V offered "multiprogrammed batch. Realtime processing was added in release B00 in April 1974, transaction processing in release C00 in November 1974. CP-V version C00 and F00, Telefile's TCP-V version I00 still run on a Sigma emulator developed in 1997.
CP-R was Sigma 9 computer systems. CP-R supported three types of tasks: Foreground Primary Tasks, Foreground Secondary Tasks, Batch Tasks. In 1975, Xerox decided to exit the computer business which it had purchased from Scientific Data Systems in 1969. Honeywell offered to purchase Xerox Data Systems to provide field service support to the existing customer base; the CP-6 system including OS and program products was developed, beginning in 1976, by Honeywell to convert Xerox CP-V users to run on Honeywell equipment. The first beta site was installed at Carleton University in Ottawa Canada in June 1979, three other sites were installed before the end of 1979. Support for CP-6 was transferred to ACTC in Canada in 1993. CP-6 systems continued to run for many years in the US, Sweden, the UK, Germany; the final system shutdown was at Carleton University in 2005. CP-6 and its accomplishments, its developers, its customers are commemorated with a plaque on the community wall at the Computer History Museum in Mountain View, California.
CP-V Software as of release B00, 1974. CP-V was supporrted by the CP-6 team at the Honeywell Los Angeles Development Center until 1977 and thereafter. TEL - Terminal Executive Language. EASY - Simple interactive environment for FORTRAN and BASIC programs and data files. CCI - Control Command Interpreter; the batch counterpart of TEL. BATCH - Submit jobstream to batch queue. PCL - Peripheral Conversion Language. Data file device to device copy. EDIT - Line Editor. LINK - One-pass linking loader. LOAD - Two-pass overlay loader. DELTA - Instruction-level debugger. SORT/MERGE. Extended FORTRAN IV. FDP - FORTRAN Debug Package. META-SYMBOL - Macro assembler. BASIC. FLAG - Load-and-go FORTRAN compatible with IBM Fortran-H. ANS COBOL. COBOL On-Line debugger. APL. SL-1 - Simulation Language. IBM 1400 Series Simulator. SYSGEN - System Generation. DEFCOM - Export external definitions from a load module. SYMCON - Manipulate symbols in a load module. ANALYZE - System dump analyzer. MANAGE - A generalized file management and reporting tool.
EDMS - Database Management System. GPDS - General Purpose Discrete Simulator. CIRC - Electronic Circuit Analysis. Xerox maintained user-written software from the EXCHANGE user group. Bryan, G. Edward, "Not All Programmers Are Created Equal --Redux," 2012 IEEE Aerospace Conference Proceedings, March 2012 P. A. Crisman and Bryan, G. Edward, "Management of Software Development for CP 6 at LADC", Proceedings of the Fifth Annual Honeywell International Software Conference, March 1981. Bryan, G. Edward, "CP-6: Quality and Productivity Measures in the 15-Year Life Cycle of an Operating System," Software Quality Journal 2, 129-144, June 1993. Frost, Bruce, “APL and I-D-S/II APL access to large databases,” APL'83 Proceedings of the international conference on APL, pages 103-107. Fielding, Roy T. "An Empirical Microanalysis of Software Failure Data from a 12-Year Software Maintenance Process," Masters thesis, University of California Irvine, 1992 UTS Documentation at Bitsavers CP-V Documentation at Bitsavers CP-R Documentation at Bitsavers The COMPUTER That Will Not Die: The SDS Sigma 7 A working Sigma 9 running CP-V at Living Computers: Museum + Labs: request a login
A command-line interface or command language interpreter known as command-line user interface, console user interface and character user interface, is a means of interacting with a computer program where the user issues commands to the program in the form of successive lines of text. A program which handles the interface is called shell; the CLI was the primary means of interaction with most computer systems on computer terminals in the mid-1960s, continued to be used throughout the 1970s and 1980s on OpenVMS, Unix systems and personal computer systems including MS-DOS, CP/M and Apple DOS. The interface is implemented with a command line shell, a program that accepts commands as text input and converts commands into appropriate operating system functions. Today, many end users if use command-line interfaces and instead rely upon graphical user interfaces and menu-driven interactions. However, many software developers, system administrators and advanced users still rely on command-line interfaces to perform tasks more efficiently, configure their machine, or access programs and program features that are not available through a graphical interface.
Alternatives to the command line include, but are not limited to text user interface menus, keyboard shortcuts, various other desktop metaphors centered on the pointer. Examples of this include the Windows versions 1, 2, 3, 3.1, 3.11, DosShell, Mouse Systems PowerPanel. Programs with command-line interfaces are easier to automate via scripting. Command-line interfaces for software other than operating systems include a number of programming languages such as Tcl/Tk, PHP, others, as well as utilities such as the compression utility WinZip, some FTP and SSH/Telnet clients. Compared with a graphical user interface, a command line requires fewer system resources to implement. Since options to commands are given in a few characters in each command line, an experienced user finds the options easier to access. Automation of repetitive tasks is simplified - most operating systems using a command line interface support some mechanism for storing used sequences in a disk file, for re-use. A command-line history can be kept, allowing repetition of commands.
A command-line system may require paper or online manuals for the user's reference, although a "help" option provides a concise review of the options of a command. The command-line environment may not provide the graphical enhancements such as different fonts or extended edit windows found in a GUI, it may be difficult for a new user to become familiar with all the commands and options available, compared with the drop-down menus of a graphical user interface, without repeated reference to manuals. Operating system command line interfaces are distinct programs supplied with the operating system. A program that implements such a text interface is called a command-line interpreter, command processor or shell. Examples of command-line interpreters include DEC's DIGITAL Command Language in OpenVMS and RSX-11, the various Unix shells, CP/M's CCP, DOS's COMMAND. COM, as well as the OS/2 and the Windows CMD. EXE programs, the latter groups being based on DEC's RSX-11 and RSTS CLIs. Under most operating systems, it is possible to replace the default shell program with alternatives.
Although the term'shell' is used to describe a command-line interpreter speaking a'shell' can be any program that constitutes the user-interface, including graphically oriented ones. For example, the default Windows GUI is a shell program named EXPLORER. EXE, as defined in the SHELL=EXPLORER. EXE line in the WIN. INI configuration file; these programs are shells, but not CLIs. Application programs may have command line interfaces. An application program may support none, any, or all of these three major types of command line interface mechanisms: Parameters: Most operating systems support a means to pass additional information to a program when it is launched; when a program is launched from an OS command line shell, additional text provided along with the program name is passed to the launched program. Interactive command line sessions: After launch, a program may provide an operator with an independent means to enter commands in the form of text. OS inter-process communication: Most operating systems support means of inter-process communication.
Command lines from client processes may be redirected to a CLI program by one of these methods. Some applications support only a CLI, presenting a CLI prompt to the user and acting upon command lines as they are entered. Other programs support both a CLI and a GUI. In some cases, a GUI is a wrapper around a separate CLI executable file. In other cases, a program may provide a CLI as an optional alternative to its GUI. CLIs and GUIs support different functionality. For example, all features of MATLAB, a numerical analysis computer program, are available via the CLI, whereas the MATLAB GUI exposes only a subset of features; the early Sierra games, such as the first three King's Quest games, used commands from an internal command line to move the character around in the graphic window. The command-line interface evolved from a form of dialog once conducted by humans over teleprinter machines, in which human operators remotely exchanged inf
In computing, multitasking is the concurrent execution of multiple tasks over a certain period of time. New tasks can interrupt started ones before they finish, instead of waiting for them to end; as a result, a computer executes segments of multiple tasks in an interleaved manner, while the tasks share common processing resources such as central processing units and main memory. Multitasking automatically interrupts the running program, saving its state and loading the saved state of another program and transferring control to it; this "context switch" may be initiated at fixed time intervals, or the running program may be coded to signal to the supervisory software when it can be interrupted. Multitasking does not require parallel execution of multiple tasks at the same time. On multiprocessor computers, multitasking allows many more tasks to be run than there are CPUs. Multitasking is a common feature of computer operating systems, it allows more efficient use of the computer hardware. In a time sharing system, multiple human operators use the same processor as if it was dedicated to their use, while behind the scenes the computer is serving many users by multitasking their individual programs.
In multiprogramming systems, a task runs until it must wait for an external event or until the operating system's scheduler forcibly swaps the running task out of the CPU. Real-time systems such as those designed to control industrial robots, require timely processing. Multitasking operating systems include measures to change the priority of individual tasks, so that important jobs receive more processor time than those considered less significant. Depending on the operating system, a task might be as large as an entire application program, or might be made up of smaller threads that carry out portions of the overall program. A processor intended for use with multitasking operating systems may include special hardware to securely support multiple tasks, such as memory protection, protection rings that ensure the supervisory software cannot be damaged or subverted by user-mode program errors; the term "multitasking" has become an international term, as the same word is used in many other languages such as German, Dutch and Norwegian.
In the early days of computing, CPU time was expensive, peripherals were slow. When the computer ran a program that needed access to a peripheral, the central processing unit would have to stop executing program instructions while the peripheral processed the data; this was very inefficient. The first computer using a multiprogramming system was the British Leo III owned by J. Co.. During batch processing, several different programs were loaded in the computer memory, the first one began to run; when the first program reached an instruction waiting for a peripheral, the context of this program was stored away, the second program in memory was given a chance to run. The process continued; the use of multiprogramming was enhanced by the arrival of virtual memory and virtual machine technology, which enabled individual programs to make use of memory and operating system resources as if other concurrently running programs were, for all practical purposes, non-existent and invisible to them. Multiprogramming doesn't give any guarantee.
Indeed, the first program may well run for hours without needing access to a peripheral. As there were no users waiting at an interactive terminal, this was no problem: users handed in a deck of punched cards to an operator, came back a few hours for printed results. Multiprogramming reduced wait times when multiple batches were being processed. Early multitasking systems used applications; this approach, supported by many computer operating systems, is known today as cooperative multitasking. Although it is now used in larger systems except for specific applications such as CICS or the JES2 subsystem, cooperative multitasking was once the only scheduling scheme employed by Microsoft Windows and Classic Mac OS to enable multiple applications to run simultaneously. Cooperative multitasking is still used today on RISC OS systems; as a cooperatively multitasked system relies on each process giving up time to other processes on the system, one poorly designed program can consume all of the CPU time for itself, either by performing extensive calculations or by busy waiting.
In a server environment, this is a hazard. Preemptive multitasking allows the computer system to more reliably guarantee to each process a regular "slice" of operating time, it allows the system to deal with important external events like incoming data, which might require the immediate attention of one or another process. Operating systems were developed to take advantage of these hardware capabilities and run multiple processes preemptively. Preemptive multitasking was implemented in the PDP-6 Monitor and MULTICS in 1964, in OS/360 MFT in 1967, in Unix in 1969, was available in some operating systems for computers as small as DEC's PDP-8.