"A war between two of the major conglomerates will always have casualties, and unfortunately for us, this time we are the casualties. We aren't yet at a state where it is impossible to use Google services on Microsoft platforms, but we are moving towards a stricter ecosystem world where we might see Googlers/Gmail users on one side and Bingers/Outlook users on the other. We can only hope for the sake of technologies future and for the sake of innovation that the two companies can learn to work together in an ever expanding world of data." We can hope so, but we're talking large companies, and large companies do not care about users. Never have, never will.

To play the devil's advocate, this wouldn't matter so much if modern OSs were actually able to prioritize disk accesses properly, or alternatively if applications stopped performing long tasks like disk accesses in their main UI thread in a blocking fashion.

In hardware, disk seek times, which are the time intrinsically needed for a disk drive to switch from reading the data of a low-priority task to reading the data of a high-priority task, are of the order of a milisecond. So I don't buy the "hardware is too slow for multitasking" argument. If you imagine an OS optimized for responsive multitasking that would enforce a prioritization policy like "foreground tasks can get full access to system resources for up to 90% of the time, while background tasks share the remaining 10%". In such a scenario, why should the amount of background tasks matter?

If you imagine an OS optimized for responsive multitasking that would enforce a prioritization policy like "foreground tasks can get full access to system resources for up to 90% of the time, while background tasks share the remaining 10%". In such a scenario, why should the amount of background tasks matter?

Do able using systemd under Linux. You learn that this is not quite as good as it first seams when you think about it.

The items that are background tasks include items like print ques. So you have foreground task and it now wants to print and there are too many background tasks it might fail to print completely. Why because particular model printers have time limitations on when can receive messages. Print ques are one of many examples of background tasks that you kinda need to perform reasonably well. Of course there are other tasks that really should wait until slack time appears in system.

Systemd starts addressing some of this by making like cups and other services that are not required all the time start on demand.

Really no hardware is too slow for multitasking. The question is will it grant you a quality experience.

Linux Cgroups can order priority of IO requests this is how systemd pulled it off.

There are many solutions to the hard disc reading problem for multitasking. One is more ram like a battery backed up ramdrive and having a OS able to use that ramdrive as a cache to the old school cheaper spinning media. Linux use of ram also helps.

Writing is the worst problem at times. This is a bit harder to do prioritisation on writing half a file is not good.

"If you imagine an OS optimized for responsive multitasking that would enforce a prioritization policy like "foreground tasks can get full access to system resources for up to 90% of the time, while background tasks share the remaining 10%". In such a scenario, why should the amount of background tasks matter?"

Do able using systemd under Linux. You learn that this is not quite as good as it first seams when you think about it.

The items that are background tasks include items like print ques. So you have foreground task and it now wants to print and there are too many background tasks it might fail to print completely. Why because particular model printers have time limitations on when can receive messages. Print ques are one of many examples of background tasks that you kinda need to perform reasonably well. Of course there are other tasks that really should wait until slack time appears in system.

Systemd starts addressing some of this by making like cups and other services that are not required all the time start on demand.

Really no hardware is too slow for multitasking. The question is will it grant you a quality experience.

Linux Cgroups can order priority of IO requests this is how systemd pulled it off.

In this case, hardware access with time constraints should probably be treated in a soft real time fashion, similar to the one outlined above for foreground tasks.

Generally speaking, I think that "pure" round robin scheduling where tasks are only prioritized in a relative fashion is a bit overused nowadays. It's perfect for providing the illusion that equally important tasks are running simultaneously, but when tasks run under time constraints (latency for user-facing tasks, others for hardware), the scheduling policy really should outline this

There are many solutions to the hard disc reading problem for multitasking. One is more ram like a battery backed up ramdrive and having a OS able to use that ramdrive as a cache to the old school cheaper spinning media. Linux use of ram also helps.

Writing is the worst problem at times. This is a bit harder to do prioritisation on writing half a file is not good.

It is true that a lower latency comes at the cost of a worse throughput, but in my opinion OSs have taken throughput optimization way too far for interactive computer use. It's okay to maximize disk performance when the OS is running on a computer that is not meant to be directly used on a daily basis, like a server, but when user-facing tasks are present, they should really be treated with special priority.