History
It's a long history!
It's simply amazing how far we have come. Oftentimes to demonstrate this point, many graphs of hardware spec numbers are shown. In most cases, it is clearly how far the computing power has increased year after year. But those graphs showing how computing power increased by leaps and bounds only tell a very small part of the story, probably a quite unimportant part from operating system perspective. To this end, how the community together forged the playing field as we know today - answers to this question is more likely to help with things that matter to us. Just to name one example - operating system is not standing still, as new mechanisms get proposed and put into place, am I jumping on the bandwagon and if so, when and how?
In essence, and we use this phrase literally, we need to become an active thinker to critically analyze the basic principles involved in making complex design decisions. Virtually any findings that you garner would be of instructive value.
In this lecture we use the design and evolution of terminals to motivate the problem. Fasten up - here is the journey.
Back in the days, when PDP-11 was the institutional computing work horse, the world looked quite different. As an expensive machine, PDP-11 was housed away from users. Only a relatively inexpensive thin terminal like a VT100 could sit on a user's desk. The terminal connects to PDP-11 remotely and costs merely $2200 in 1980s' dollar. All public pictures of VT100 that you can find all look very old and low tech. But actually if you look in the right place, you can still buy mint condition VT100 family terminals and they look pretty much as nice on the exterior as a PC that you see today. BTW, during that era, a device called teleprinter also existed.
Obviously, the PDP-11 must be shared by many users at the same time - hence the need of preemption (well, given your understanding of cs360, you now know even for a single user device, preemptive multitasking is imperative!). It is also quite obviously that your process would live on PDP-11 and simply the display and user keyboard input would take place on your VT100.
How does the PDP-11 talk to the VT100 then? Well, through a set of communication protocols. Here is a surprise, 1978 was the year when VT100 was first released by the Digital (DEC), and a few years later graphic displays appeared on those terminals and printers can be hooked to the terminals as well. Many of today's consoles still use the very same design - even reusing the very same protocols. So 30 years of proven technology of how to build a useful terminal - pretty cool if you think about it. Just to name a few of those old technology. ANSI escape code sequence which descibes how color and text and symbols on a (remote) terminal is controlled by a stream of text. These textual sequences are still used even on the terminals running local to your very cool linux laptop.
More fundamentally on linux as well as BSD, consoles as we know of today are all implemented as emulators of VT100 family of terminals. Here is a slight difference, the Unix world was not very harmonious over the years. :-). So there were two branches - one group went with a teletype design, and the other group went with pseudo terminal. To users, these two alternatives behave similarly, but deeply within the system these two options affects how the default files 0, 1 and 2 are opened and hooked up with each process. Now think, your process is running remotely on PDP-11 and the display and keyboard consoles are all local, so how is this seemingly easy default std[in|out|err] implemented? Where psuedo terminal is used, ptm and pts (the master and the slave) cooperate to support each terminal. Type in the following in my terminal:
Unix> tty /dev/pts/0
On a different system the following is a sample output of typing:
Unix> tty /dev/ttys002
pts is part of the Unix98 standard and Linux implements that. BSD did not adopt Unix98 (well, you know why :-)), so the ttys002 is on a BSD (in fact my Macbook). Still using ptm/pts as the example, we know there is a master and a slave serving the same terminal - then the notion of "everything is a file" is really not that strange. In fact, a more proper statement should be that a process talks to everything though fd and occassionally that fd really points to a inode-proper file.
Still that is not the full story. So far we have not covered how graphics get displayed on the terminal. The de facto Unix solution is called X. Many versions passed until X has become what we know of today and that version is no. 11. So today X is better known as X11. X11 in essence defines a communication protocol between a machine like PDP-11 and a terminal like VT100 (please note: VT100 is not a graphics terminal, so this is just an analogy). X11's protocol is textual, mostly just textual messages bouncing back and forth between the X client and the X server. Note, in this case because the request to display something comes from a process on the mainframe, the running process is then by definition on the client side, and the terminal side is providing resources and hence on the server side. This distinction has stayed true till today. In all graphics and today's popular GPU programming world, the graphics card is the server and the CPU side is the client. See, another thing that stayed constant for 30 years!
Even though I say the protocol itself is textual, programming X11 is not like writing an essay, it is still programming using a library API. Programming in X11 in almost all scenarios is too low level, as if you'd be writing quicksort in assembly code as opposed to in C. You can look at xlib manual or a programming example from another website here. Although few people have ever programmed using xlib, on all Unix and linux interactive graphics exclusively goes through X11, regardless of whether you program using OpenGL, Java, Python etc.
Why talking about this? Because I also want to ask - how graphics gets onto a printer? Many of your are pretty familiar with PDF files, or at least you use it very regularly as a file format. But actually, PDF is in essence a programming language that describes text, layout, graphics (both raster and vector format) such that a printer can understand and reproduce your docment on paper. PDF has little to do with Unix, right? True, but its parent PS is born right out of Unix. Guess what, PS is a programming language too and it's more powerful than that of PDF and more expensive to parse through and execute. Actually, VT100 family used processors of the class of Intel 8008 and the first postscript printer that was hooked up with the terminals had to use Motorola 68k which has much more processing power.
Now the summary of this relatively long story. (1) Operating system should never be considered as a monolithic thing. (2) Operating system complexities often are due to the communication complexity. (3) Although it manages system resources, serves requests by user programs and very rarely directly interact with a user, operating system in many ways defines what is possible. This question deserves much in-depth thinking. Operating system is not as far away from the user as you think, and