|
Unix Programming - Operating-System Comparisons - Linux
Linux
Linux, originated by Linus Torvalds in 1991, leads the pack of
new-school open-source Unixes that have emerged since 1990 (also
including FreeBSD, NetBSD, OpenBSD, and Darwin), and is representative of the design
direction being taken by the group as a whole. The trends in it can
be taken as typical for this entire group.
Linux does not include any code from the original Unix source
tree, but it was designed from Unix standards to behave like a Unix.
In the rest of this book, we emphasize the continuity between Unix and
Linux. That continuity is extremely strong, both in terms of
technology and key developers — but here we emphasize some
directions Linux is taking that mark a departure from
‘classical’ Unix tradition.
Many developers and activists in the Linux community have
ambitions to win a substantial share of end-user desktops. This makes
Linux's intended audience quite a bit broader than was ever the case
for the old-school Unixes, which have primarily aimed at the server
and technical-workstation markets. This has implications for the
way Linux hackers design software.
The most obvious change is a shift in preferred interface
styles. Unix was originally designed for use on teletypes and slow
printing terminals. Through much of its lifetime it was strongly
associated with character-cell video-display terminals lacking either
graphics or color capabilities. Most Unix programmers stayed firmly
wedded to the command line long after large end-user applications had
migrated to X-based GUIs, and the design of both Unix
operating systems and their applications have continued to reflect
this fact.
Linux users and developers, on the other hand, have been
adapting themselves to address the nontechnical user's fear of CLIs.
They have moved to building GUIs and GUI tools much more intensively
than was the case in old-school Unix, or even in contemporary
proprietary Unixes. To a lesser but significant extent, this is true
of the other open-source Unixes as well.
The desire to reach end users has also made Linux developers
much more concerned with smoothness of installation and software
distribution issues than is typically the case under proprietary Unix
systems. One consequence is that Linux features binary-package
systems far more sophisticated than any analogs in proprietary
Unixes, with interfaces designed (as of 2003, with only mixed
success) to be palatable to nontechnical end users.
The Linux community wants, more than the old-school Unixes ever
did, to turn their software into a sort of universal pipefitting for
connecting together other environments. Thus, Linux features support
for reading and (often) writing the file system formats and networking
methods native to other operating systems. It also supports
multiple-booting with them on the same hardware, and simulating them
in software inside Linux itself. The long-term goal is subsumption;
Linux emulates so it can absorb.[40]
The goal of subsuming the competition, combined with the drive
to reach the end-user, has motivated Linux developers to adopt design
ideas from non-Unix operating systems to a degree that makes
traditional Unixes look rather insular. Linux applications using
Windows .INI format files for configuration is a minor example we'll
cover in Chapter10;
Linux 2.5's incorporation of extended file attributes, which among
other things can be used to emulate the semantics of the Macintosh
resource fork, is a recent major one at time of writing.
|
But the day Linux gives the Mac diagnostic that you can't open a
file because you don't have the application is the day Linux becomes
non-Unix.
|
|
| --
Doug McIlroy
|
|
The remaining proprietary Unixes (such as Solaris, HP-UX, AIX,
etc.) are designed to be big products for big IT budgets. Their
economic niche encourages designs optimized for maximum power on
high-end, leading-edge hardware. Because Linux has part of its roots
among PC hobbyists, it emphasizes doing more with less. Where
proprietary Unixes are tuned for multiprocessor and server-cluster
operation at the expense of performance on low-end hardware, core
Linux developers have explicitly chosen not to accept more complexity
and overhead on low-end machines for marginal performance gains on
high-end hardware.
Indeed, a substantial fraction of the Linux user community is
understood to be wringing usefulness out of hardware as technically
obsolete today as Ken Thompson's PDP-7 was in 1969. As a consequence,
Linux applications are under pressure to stay lean and mean that their
counterparts under proprietary Unix do not experience.
These trends have implications for the future of Unix as a
whole, a topic we'll return to in Chapter20.
[an error occurred while processing this directive]
|
