Timesharing

I have decades of experience with what were called timesharing systems.  Much effort was put into making each user's experience satisfying.  Many users would logon to a single computer (perhaps several CPUs and a good amount of main memory).  Since each user evaluated the computer's performance by how responsive it was for him, the manufacturer put logic into the operating system to ensure that user response time was minimized.  That meant that I/O bound batch jobs would run, but not at the expense of giving good response to live, breathing human beings who want answers immediately, not 10 minutes from now.  Comes the revolution.  Now, everybody has his own computer and very few choices for operating systems.  The Microsoft operating system (I think they call it Windows) can be maddeningly unresponsive when an I/O bound process (like a file backup) is running.  Even dropping the CPU priority of the I/O bound job is not sufficient to make the user interface responsive.  Why is that?  Well, I would imagine there is a great deal of disk contention between the user interface-related work and the file backup-related work.  Everytime an I/O completes for the batch job, the next-queued I/O for that job gets started from the I/O request queue.  Work that gets queued from the not-I/O-bound job has no priority.  So, while my file backup job (long running) is active, I can double-click an icon on the desktop and wait ... and wait for the operating system to do all the magic necessary to get the program into memory (from disk) and started executing.  This problem was solved very satisfactorily in the 1970s.   And unsolved when the Unix-heads started designing operating systems for the 21st century.