Why it is hard to design an operating system?

What is the guideline for

.designing an effective interface for an operating system

With the advancement of technology, developers and designers come up with

many different hardware levels, to cope up to the requirements of the user.
According to Moore's Law, computer hardware improves by a factor of 100
every decade. So the latest operating systems developed are said to be better and
more complex than before. But, is that really the case? Some operating systems
have gotten worse with time in terms of reliability. With time, the requirements
people want changes rapidly. With this the development and design of operating
systems get worse day by day. Some of the identified issues, according to
Tanenbaum's book, are as follows. Of course these points are from his
perspective and some others may have different opinions on this regard.

1. Operating systems have become very large programs: The size and
complexity of programs have increased so bad that, no one person can sit
and implement an operating system in a few months.
2. Operating systems have to deal with concurrency: With the current
multi-core architectures we see today, operating systems have to handle
multiple users and multiple devices at the same time, which makes the
design way more complex and harder to maintain.
3. Operating systems have to deal with potentially hostile users: Security
and privacy are two main factors that users prefer when it comes to a
good operating system. There can be hostile users who may steal user
programs or even hi-jack machines. Operating system designs have to
incorporate these aspects in to their design process as well.
4. Anonymous and different users accessing computers today: Operating
systems need to take measures to do proper file and resource sharing
between multiple users. The management of sharing files is very hard
when multiple users are accessing the same computing device.
 5. Operating systems should be able to handle future hardware and
software changes: Many operating systems that we see today have
existed for decades. And with the changing world they have been well
thought and designed with respect to future hardware and software
changes. This is also a major design consideration.
6. Most operating systems do not have a specific type of users: When
designing an operating system, we need to provide for a considerable
generality, so that many users can use this. Even if you decide to target a
specific user base, there should be different levels of users within that
base. So there should be some level of generality in the design.
7. Operating systems should generally be portable: Portable means, it
should work on different types of hardware and machines. There are
certain operating systems which are designed specifically for certain
kinds of machines. Instances like this are very rare, and most users prefer
operating systems to be portable.
8. Operating systems should provide backward compatibility: New
operating systems may have different restrictions on word lengths, file
names and other aspects. But some applications and users are still stuck
with the previous operating system designs, which shows the need for
backward compatibility to older operating systems.
What is the guideline for designing an effective interface for an operating
.system

Are there any principles that can guide interface design? We believe there
are. Briefly summarized, they are simplicity, completeness, and the ability to be
implemented efficiently.
Principle 1: Simplicity

A simple interface is easier to understand and implement in a bug-free way.

All system designers should memorize this famous quote from the pioneer
French aviator and writer, Antoine de St. Exupery: Perfection is reached not
when there is no longer anything to add, but when there is no longer anything
to take away.

This principle says that less is better than more, at least in the operating system
.itself. Another way to say this is the KISS principle: Keep It Simple, Stupid

Principle 2: Completeness

Of course, the interface must make it possible to do everything that the users
need to do, that is, it must be complete. This brings us to another famous quote,
this one from Albert Einstein: Everything should be as simple as possible, but
no simpler.
In other words, the operating system should do exactly what is needed of it and
no more. If users need to store data, it must provide some mechanism for storing
data. If users need to communicate with each other, the operating system has to
provide a communication mechanism, and so on. In his 1991 Turing Award
lecture, Fernando Corbatd, one of the designers of CTSS and MULTICS,
combined the concepts of simplicity and completeness and said: First, it is
important to emphasize the value of simplicity and elegance, for complexity has
a way of compounding difficulties and as we have seen, creating mistakes. My
definition of elegance is the achievement of a given functionality with a
minimum of mechanism and a maximum of clarity.
The key idea here is minimum of mechanism. In other words, every feature,
function, and system call should carry its own weight. It should do one thing
and do it well. When a member of the design team proposes extending a system
call or adding some new feature, the others should ask whether something awful
would happen if it were left out. If the answer is: "No, but somebody might find
this feature useful some day," put it in a user-level library, not in the operating
system, even if it is slower that way. Not every feature has to be faster than a
speeding bullet. The goal is to preserve what Corbatd called minimum of
mechanism. Let us briefly consider two examples from my own experience:
MINIX (Tanenbaum and Woodhull, 2006) and Amoeba (Tanenbaum et al.,
1990). For all intents and purposes, MINIX has three system calls: send,
receive, and sendrec. The system is structured as a collection of processes, with
the memory manager, the fde system, and each device driver being a separate
schedulable process. To a first approximation, all the kernel does is schedule
processes and handle message passing between them. Consequently, only two
system calls are needed: send, to send a message, and receive, to receive one.
The third call, sendrec, is simply an optimization for efficiency reasons to allow
a message to be sent and the reply to be requested with only one kernel trap.
Everything else is done by requesting some other process (e.g., the file system
process or the disk driver) to do the work. Amoeba is even simpler. It has only
one system call: perform remote procedure call. This call sends a message and
waits for a reply. It is essentially the same as MINIX' sendrec. Everything else
is built on this one call
Principle 3: Efficiency
The third guideline is efficiency of implementation. If a feature or system call
cannot be implemented efficiently, it is probably not worth having. It should
also be intuitively obvious to the programmer about how much a system call
costs. For example, UNIX programmers expect the Iseek system call to be
cheaper than the read system call because the former just changes a pointer in
memory while the latter performs disk I/O. If the intuitive costs are wrong,
programmers will write inefficient programs.