The problem here is misleading numbers. The most common metric used in comparing computers is Megahertz: 1 Megahertz is 1,000,000 processor cycles per second. When comparing processors in the same family, it's very useful: a Pentium II will do the same thing with its cycles as any other, so you can pretty much assume a 350Mhz PII will give you about 75% of the performance of a 450Mhz PII.
This comparison breaks down, however, when you're comparing processors of different families, e.g. a 400Mhz Intel Celeron will not be as fast as a 400Mhz Pentium II. It breaks down even further when you compare processors of completely different architectures: a 400Mhz G4 will perform most tasks faster than a 500Mhz PIII. This might seem odd to some, since computer manufacturers and retailers tend to advertise the clock speed of a computer as an overall performance gauge - but it's not. A PowerPC will require fewer clock cycles to perform a task - scaling a font, converting from hex to decimal, rotating an image - than a Pentium class processor will, because it can perform more operations per cycle. There are a few reasons for this, and most of them relate to efficiency. Simply stated, the Motorola philosophy is "power through simplicity"; more work can be done if the work is made simpler. The Intel philosophy tends to be "power through brute force": instead of making the processor simpler or even redesigning it altogether, Intel will bolt features and instructions onto it, then crank the clock speed. This works for a while; since the processors are running at ridiculous rates, it doesn't matter how efficient they are. The problem arises when they reach the limits of what can be grafted on and then turbocharged: we end up with monstrosities like the Pentium III that require redundant fans and have to be neutered to fit them into the power, space, and heat constraints of a laptop.

The reason behind this assumption is clear as soon as you walk into any software store: the Macintosh section, if there is one, is usually takes up a rack or two, while the Windows software section is much bigger. But most of the Windows section tends to be filler: stacks of flavor-of-the-month games that offer no real innovation or benefit compared with any others, fifty word processors, and all sorts of vertical-market stuff like garden-planning, geneology, and such (this is generally available for Macintosh as well, but usually via mail order). The irony of a Windows advocate rattling off a list of word processors or spreadsheets that aren't available on the Macintosh should be readily apparent when you realize that everybody uses Microsoft Office anyway. I use one text editor (BBEdit), I use one mail client (Eudora), I use one newsreader (MT Newswatcher). It's nice that the choice is available, but I don't feel cheated because I can't use Pegasus or Calypso: I'm sure they're great mail clients, but Eudora works fine for me. I can't use SecureCRT or NoteTab, but I'm not lacking for shell or text editors; NiftyTelnet and BBEdit are more than adequate. Many applications (Word, Photoshop, Netscape Communicator, Excel, Illustrator, Eudora, QuickTime Player, and WordPerfect, to name just a few) are feature-compatible and can share files across both platforms. If anybody knows of a show-stopper killer app for Windows that has no comparable Macintosh application, let me know. I don't know of any. And now that MacOS X can run almost any Unix application with available source code and run the X windowing system concurrently with its native Quartz system, I can compile and run gvim within WindowMaker on my desktop -- and switch back to OmniWeb on command.

If so, they've been going out of business for twenty years. I've heard this one before, along with the assertions every spring that another company (first IBM, then Microsoft, then Sony, and now Disney) is going to buy Apple. For a company with over a billion dollars in cash reserves, brand recognition, enviable customer loyalty, and more relative market share than BMW, Mercedes, and Mitsubishi put together, I guess it takes quite a while to go out of business...

Many of these claims are true of the MacOS, and have been since 1984. There's no denying that the Macintosh memory management is inelegant, to put it politely. Nor does the Mac support symmetric multiprocessing, nor does it support preemptive multitasking. These technologies aren't supported for historical reasons, and because of the massive investment in developer time that would be requred to implement them.

But they're already here. If you're using MacOS X, you can already take advantage of the powerful features of the Unix operating system without losing the comfortable Macintosh aesthetic. Here are a few of those features:

• Preemptive Multitasking is a scheduling system, an inherent component of an operating system's kernel. On a modern operating system, like Unix, the kernel determines which processes will receive which slices of execution time, and may interrupt a process when its time is up to allow another process to execute for a while. The Classic MacOS (up until OS 9, inclusive) operates on cooperative multitasking, which means that a process may run until it decides to give control back to the kernel, which may return control of the CPU to the same process, or allow another process to execute for a period of time. This is one of the reasons that the Classic MacOS seems so responsive - while you're using an application, everything else is secondary to that application's needs. This is also why many concurrent tasks seem to run so slowly on Classic MacOS - they are all contending for the same CPU cycles, and one process may monopolize the CPU. Multithreading is a sort of subset of multitasking. It is the ability for an application to perform multiple tasks concurrently within itself; in this way, it is like multitasking within an application.
  Preemptive multitasking and multithreading are fully implemented in MacOS X.
• Protected Memory is a memory management scheme in which applications have their own specific area of memory and are not permitted to write to another application's memory space. A well-behaved application should never do this, of course, but not all applications are well-behaved. A modern operating system should catch an attempt to access another application's memory space, and terminate the offending program. The majority of software crashes in consumer operating systems like Classic MacOS and Windows 9x are due to memory-space violations like this.
  Protected memory is fully implemented in MacOS X.
• Symmetric multiprocessing is a capability that is closely related to preemptive multitasking. Once an operating system's kernel can choose which applications will have which timeslices for execution, the logical extension is to put more than one processor in a machine and allow the kernel to dictate which processor will be used for which execution. The idea is to have as little idle time on a processor as possible. This allows tasks which are composed of smaller tasks to be broken up and run in parallel, which speeds up execution significantly. Older implementations of the MacOS may use a scheme called asymmetrical multiprocessing, wherein a single application or task may use an entire processor of a multiprocessor machine. This speeds up that task significantly, but is not very efficient since all of the other tasks still reside on the same processor.
  Symmetric multiprocessing is fully implemented in MacOS X.
• A decent development environment is a necessity for any operating system, if its vendor wants developers to write programs for it.
  Unix systems, for the most part, use cc or gcc, which are command-line compilers (an actual Unix development environment has, in addition to the compiler, a parser, preprocessor, linker, and a few other components, but for simplicity's sake I'm only going to discuss (g)cc as a compiler here). Most applications are distributed in source code form, that is, not yet compiled. On the Mac, this would be equivalent to downloading a program and finding a directory full of text files instead of a double-clickable application, and would be unacceptable for nearly all Mac users. On Unix, however, source is undoubtedly the best way to distribute a package. There are a few reasons for this. First, most Unix administrators are familiar with the tasks necessary to compile and install code, and to patch existing code with bugfixes and security fixes. Second, Unix itself is a loosely-defined term: versions of Unix or Unix-compatible systems may be run on many different hardware platforms, from handheld palm computers to Intel-, PowerPC-, and SPARC-based workstations, to massive multiprocessor servers with more RAM than I have disk space. Various versions of Unix are available from many vendors, or, in the case of the popular Free Unixes, from no vendor at all. A Unix developer rarely knows if his customers are going to be running Linux, Solaris, SunOS, FreeBSD, OpenBSD, BSDi, MacOS X, NeXTSTEP, AIX, HP/UX, IRIX, or something totally different. Even if the customer uses Linux, they may be running it on Intel, PowerPC, SPARC, or a more esoteric platform. A single, double-clickable application may run fine on an Intel Linux box, but OpenBSD on SPARC won't know what to do with it. Therefore, a script called a Makefile is often distributed with a Unix application's source code. The user can edit this file, by hand or with another script, and when the application is built it will be customized and tweaked for all of her platform's idiosyncracies.
  Most developers for Windows use Microsoft's Visual C++, usually for the same reason most documents are typed in Microsoft Word - it's what everybody else uses. Some use Visual Basic instead, because it's a bit simpler, and gcc has been ported from Unix for those who don't feel complete without tweaking a makefile.
  But what about the Macintosh? In the past, Mac programmers had three options. They could use Apple's Macintosh Programmer's Workshop (MPW), a collection of free programs that would allow a programmer to develop for the Mac, but it had a big problem: it was based on the same arcane Makefile scheme as Unix, and it turned many programmers off from developing on the Mac. This machine is simple to use - why should the development tools look like they just came from a Unix system? Second, they could use Metrowerks' CodeWarrior. CodeWarrior is a powerful and elegant development environment, and it uses standard Macintosh conventions for its development environment. Furthermore, all of the components needed for development are included in a single package - an editor for creating and editing source files, and an integrated parser, preprocessor, compiler, and linker. MetroWerks also includes an excellent framework called PowerPlant which simplifies many of the more tedious programming tasks. But a standard version of CodeWarrior will cost you USD 500, putting it out of the reach of many shareware programmers and hobbyists. Programmers also had a third option: tools like RealBasic and AppleScript, tools which are usually simple to develop with, but whose programs tend to lack performance and features so that the software can be made more simple. These tools are useful for simple shareware applications and utilities, but many developers find that they grow out of them quickly, and the skills needed for them can't be transferred to other platforms as easily as C or C++.
  And now, we have MacOS X. Project Builder and Interface Builder, the two core components of the OS X development environment, are distributed free by Apple with every copy of OS X. But while Project Builder uses the Unix compiler gcc for its heavy lifting, it's more than the simple wrapper that MPW was. Project builder offers a clean and simple way for programmers to develop with the power of Objective-C or Java, and includes a debugger, editor, and the full compiler suite. Interface Builder makes designing an interface as simple as building a webpage in a graphical editor: drag a button, text element, OpenGL display, or any other control to the mock window in the editor, then drag lines to link objects with their functions in your code. This makes creating an application's interface as simple as linking a button to an action, but underneath it all is the power of Java (one of the most common and popular languages today) or Objective-C (described by many developers as "what C++ should have been").