Firstly, what is an operating system really. Well, it's a piece of software, nowadays usually written in a mixture of C/C++ and assembly language. Part of it is loaded into the computer's memory when the machine boots and stays there til the machine powers down; other parts may be loaded and unloaded into and from memory as required. Typically after initialising data structures and querying I/O devices, the OS will load an application program called a 'shell' (or User Interface). The shell is thereafter responsible for interacting with the user and asking the OS to load other programs on behalf of the user.
How can we pin down exactly what we mean by 'operating system'? (section 1.1)
Why build operating systems? Why install one on your computer?
Because a computer, even a very simple one is, like, vastly complicated. If you want to do anything useful, it's reasonable to use existing applications programs rather than writing the software yourself. Similarly, even if you do write your own software, it is more reasonable to make use of other software instead of writing everything from scratch. End users and applications software alike rely on other software performing the lower-level tasks.
What is there in the naked machine (unclothed by an OS)?
That's it. You don't have files. All you can see of the disks and other devices is a wodge of hardware registers. You do everything to devices by setting device registers and responding to interrupts. When an event occurs, the CPU receives an interrupt which must be dealt with (and if you aren't careful, you can lose track of where you were in the program). Memory is just in one (or several) big contiguous block(s), and may not be enough to run the applications you want.
You (the application programmer) could deal with all this complexity yourself (and quite recently many games programmers did), but consider the simple task of reading some bytes out of a file on a floppy disk (section 1.1.1):
The book goes into some detail about the NEC PD765 controller chip on the IBM-PC and how READ and WRITE commands require some 13 parameters packed into 9 bytes, specifying a block, number of sectors and what to do with a deleted-data-address-mark---which return 23 error and status fields packed into 7 bytes; how you can't leave the motor on for too long, but you don't want to keep switching it on and off...
On my machine at home, you still have to decode the data from the flux encoding used on the physical disk. Then there's still the problem of locating data when reading and allocating storage space when writing (making sure that new data does not overwrite old data).
The point is that it is tricky, and any one of several things could go wrong. How much better if someone could write code to deal with the general case, which could be reused by anyone wanting to use the device.
This is what the operating system does.