Information Technology Reference
In-Depth Information
Android vs. iPhone
One avenue to improving system reliability might be to limit third party applications,
or to vet them in some way. Of course, limiting applications can hurt adoption. Two
operating systems vendors taking opposite positions on this recently are Apple and
Google. For the iPhone, Apple requires pre-approval before any application can be
loaded on the iPhone, possibly enhancing reliability. In practice, however, it can be
difficult to verify all aspects of application behavior, e.g., to prevent a game applica-
tion from downloading telephone numbers stored on the smartphone for telemarketing
purposes. Thus, it is unclear how much benefit users will have in practice. Google
takes the opposite approach: it gives the users control over which applications can
be installed on Android phones, possibly enhancing wider user adoption, but potentially
hurting system reliability. It will be interesting to see which approach is more successful.
1.2.6
Tradeos
Most practical operating system designs need to strike a balance between the
goals of reliability, security, portability, performance, and adoption. Design
choices that improve portability | for example, by preserving legacy interfaces
| often make the system as a whole less reliable and less secure. Similarly,
there will often be ample room for breaking an abstraction to tweak some added
performance out of the system. However, such performance optimizations come
at a cost of added complexity and therefore potentially decreased reliability.
The operating system designer must carefully weigh these competing goals.
To illustrate the tradeoff between performance and complexity, we relate the
following true story. An operating system was designed and implemented in the
late 1980's, using a type-safe language to reduce the incidence of programmer
errors. For speed, the most frequently used routines at the core of the operat-
ing system were implemented in assembly code. In one of these routines, the
implementers decided to use a sequence of instructions that shaved a single in-
struction off a very frequently used code path, but that would sometimes break
if the operating system exceeded a particular size. At the time, the operating
system was nowhere near this limit. After a few years of production use, how-
ever, the system started mysteriously crashing, apparently at random, and only
after many days of execution. Many weeks of painstaking investigation revealed
the problem: the operating system had grown beyond the limit assumed in the
assembly code implementation. The fix was easy, once the problem was found,
but the question for the reader is: do you think the original optimization was
worth the risk?
Exercises
Search WWH ::




Custom Search