The design of operating systems varies in response to the
expected audience for the system. Some operating systems are
intended for back rooms, some for desktops. Some are designed
for technical users, others for end users. Some are intended to
work standalone in real-time control applications, others for an
environment of timesharing and pervasive networking.
One important distinction is client
vs. server. ‘Client’ translates as: being lightweight,
suppporting only a single user, able to run on small machines,
designed to be switched on when needed and off when the user is done,
lacking pre-emptive multitasking, optimized for low latency, and
putting a lot of its resources into fancy user interfaces.
‘Server’ translates as: being heavyweight, capable of
running continuously, optimized for throughput, fully pre-emptively
multitasking to handle multiple sessions. In origin all operating
systems were server operating systems; the concept of a client
operating system only emerged in the late 1970s with inexpensive but
underpowered PC hardware. Client operating systems are more focused
on a visually attractive user experience than on 24/7 uptime.
All these variables have an effect on development style. One of
the most obvious is the level of interface complexity the target
audience will tolerate, and how it tends to weight perceived
complexity against other variables like cost and capability. Unix is
often said to have been written by programmers for programmers —
an audience that is notoriously tolerant of interface
complexity.
|
This is a consequence rather than a goal. I abhor a system designed
for the “user”, if that word is a coded pejorative
meaning “stupid and unsophisticated”.
|
|
--
Ken Thompson
|
|
To design the perfect anti-Unix, write an operating system that
thinks it knows what you're doing better than you do. And then adds
injury to insult by getting it wrong.
[an error occurred while processing this directive]