Thursday, May 09, 2013

The Mac As We Know It Is Slipping Away.

The Macintosh as we know it, since its introduction in 1984, may soon disappear as an identity, as Apple transitions its Macintosh line of computers to something that bears a closer resemblance to the iPhone than anything else.

The MacBook Air and Retina MacBook Pro have already started towards this transition, with the iMac not far behind them. Many features that the MacBook Air has introduced along with OS X 10.7 Lion include:

  • solid-state storage memory, replacing disk storage,
  • much larger amounts of system memory; greater than 2 GB, and
  • much longer battery life; greater than 5 hours,

have given it potentially operational similarity with the iPhone, but in a much larger scale. While OS X still has the same operational aspects of earlier Mac OS X releases, there are some operating system features which could soon see major changes as the new hardware features make some of the Mac's existing system software features redundant, particularly:

  • virtual memory, due to markedly improved performance of solid-state memory devices and copious amounts of system memory, and
  • background process scheduling, in an active effort towards extending battery life.

And for Apple's mobile devices that have no internal spinning hard disk, and have less opportunity to be plugged into a power source for charging, these modifications to standard UNIX system services make excellent design sense; replacing the virtual memory system with active process termination facilities is a necessary modification to what is considered staple UNIX system services on an iPhone.

But the Mac has started to appear with the same features as iPhone, all centred around the absence of an internal hard disk drive. With Macs using solid-state storage in place of a hard disk, performance has improved tremendously as one of the longest-living bottlenecks in computing history has been absolved in recent years.

The issue at hand is whether the benefits of incorporating iOS system services into OS X is of benefit for improving system performance in mobile roles, at the cost of losing some existing Mac features may be substantial to compatibility and capacity for server and workstation roles.

It is unclear as to whether Apple will want to abandon the traditional and long-standing UNIX technologies used by their computers in high-performance computing services. Apple still make computers that are notbattery-operated, and may be used as servers or professional workstations in usage scenarios where high performance and reliability are desired. And even for their laptop computers which do have batteries and can benefit from the technologies that iOS has introduced to augment solid-state storage, reducing the versatility of the system software by imposing artificial limits to applications may not be in the best interests of users.

Traditional technologies for UNIX perform feats in computing that would otherwise not be possible on the hardware that the system runs on. Virtual memory services are what allow computers to run more applications, with larger data sets, than would otherwise fit in a computer system. Time sharing is the means by which computers can run many processes concurrently, thereby allowing computers to be busier and more useful in serving the processing requirements of one or more people.

What Apple are potentially proposing with future versions of OS X is an operating system that takes away these two staple capabilities from UNIX. For a mobile role, the reduction of such services makes sense: it reduces the size of the kernel, thereby saving on resources that would otherwise be taken up by services that cannot be used or aren't effective under the given usage scenarios. But for workstation and server roles, these services are of greater utility, since the plan here is to allow the computers to run as many processes and with as large datasets as possible, and run them efficiently.

And OS X is an operating system using a multi-context window system. The window system allows users to display and control many applications at once, since each view of every application is easily accessible. The need to have applications run concurrently is greater than for a mobile platform—for at least one user interface feature, this need is mandatory.

Interapplication drag-and-drop, a feature which arrived to the Macintosh with System 7, requires that the source application has execution context to prepare at the commencement of the drag-and-drop operation, the Macintosh Toolbox to obtain execution context in order for drag-and-drop to be conducted and data to be transferred, and then the target application to attain execution context in order to complete and receive the results of the drag. If the target application were to hang at all, then the application would never be able to respond to the drop event from the Macintosh Toolbox, and the feature wouldn't work. And it is possible for there to be more than one target application: try dragging a clipping over many application windows owned by different applications! If any of these target applications hang, then the entire drag-and-drop operation may cause the system to malfunction.

On Mac OS X, while drag-and-drop operates differently to how it is implemented on Mac OS, it is still a requirement for applications involved to obtain processing time in order to implement the feature. While applications run concurrently on Mac OS X to provide richer user interface feedback during a drag-and-drop operations, the premise of preparation, transfer and deposit are still there, requiring that applications have processing resources allocated to them.

On iOS, drag-and-drop across applications does not exist as a user interface feature. This is a reason or a consequence for the absence of continual concurrent processing.

Virtual memory is a feature which allows one or more users to work with data that cannot be accommodated for completely in system memory. Whether the memory requirements are due to running a large number of applications that exceed the capacity of system memory, or whether the datasets consumed by applications are large, or both, virtual memory allows computers to function without having to handle circumstances where memory resources have been exhausted, allowing applications to continue to run without interruption or special exception.

iOS changes this so that applications, for the first time on a UNIX platform in over 20 years, need to be prepared for handling low memory situations or risk being terminated by the kernel. For an operating system that was originally designed to help ensure the survivability of user programs, and thus simplify the programming model, iOS presents a backwards step in removing system support for virtual memory and induce instability by employing active process termination techniques.

The strategy that iOS uses is not without merit, however. iOS devices do not have a hard disk, and the life span of non-volatile storage is severe enough to warrant special treatment, making the use of a paging file impractical. And system memory sizes on iOS devices have already grown to a quarter of the addressable memory space that their processors allow.

On a modern Mac, the limits are even higher, given the use of advanced 64-bit architectures. Virtual memory, then, appears to be unnecessary at the face of it, but there are a multitude of other reasons why virtual memory is still a useful system service to have available, even on Macs without a hard disk. Users may have the need to run a large number of applications that work on large datasets concurrently. The chances of that being a concern is becoming smaller by the year as new Mac models grow in storage and system memory capacities; conversely, systems reach their useful life sooner when users needs grow beyond what they are capable of.

The ability to handle the amount of code and data processed by the CPU is not the only issue that is directly affected by the availability of virtual memory services. Macs also have other devices available to its disposal, including GPUs—through their drivers—which can also use the virtual memory subsystem in holding data for its needs during execution. Taking away the virtual memory subsystem also limits what the GPU can do.

In addition, current applications assume the presence of a working virtual memory system in OS X. If virtual memory services are removed, then applications need to be re-written in order to implement mitigation procedures for when system memory runs low. Thus changing the memory model of an operating system has direct consequences to system compatibility.

Particularly when some applications are not completely written under Apple's system frameworks. Some applications may be limited to POSIX, which does not support any of the additional features that OS X and iOS support, including Apple Events, Auto-save and Versioning, and Suspend and Resume, let alone any of the Mac's fundamental frameworks. Many of these applications are written as front-ends to POSIX tools that run in the background, such as Disk Utility and Network Utility. Changing traditional UNIX application environments, including the dismissal of virtual memory, may require that these applications and tools be re-written; a staggering amount of work.

A crucial aspect to changing something so entrenched in UNIX legacy that virtual memory is a service that affects every UNIX process on the system; not just Mac applications! There is no interface for POSIX applications to use to tell whether the Mac is running out of memory; the only thing that POSIX can do that is in the best interest of iOS automatic process termination ideals is to deliver a lethal signal and hope for the best. And it is not in the best interests to have programs written against POSIX re-written just to cater for events that will only happen on Apple's UNIX operating systems.

So far, there is no compelling reason to disable traditional virtual memory services from OS X. Even with high performance storage, virtual memory can still be useful in expanding the apparent system memory space to applications. Instead, the automatic termination of processes should be considered as an option for those applications that support Auto-save and Suspend and Resume services, introduced in OS X 10.7 Lion. There are times when the system may ask applications to quit, such as when a user logs out (either explicitly or through a normal system restart), or an application elects to terminate rather than use virtual memory services if the application or the system considers that it is cheaper for the application to quit and restart, rather than for the system to page the application out to disk or storage. Having both services available will allow existing applications to function as expected, whilst allowing new applications of the new system services and provide a potential compatibility bridge with iOS.

While there is some scope for the OS X platform to encompass some of the resource-saving features of iOS, they shouldn't take precedent over application—and UNIX—compatibility. As a matter of fact, iOS requires this to be true as well, since there are many system daemons operating on iOS that implement some of its services. It is important for Apple to realise that developers should be able to choose what system services are best for their applications, and not for Apple to force the adoption of these services through stringent licensing agreements and artificial restrictions.

In short, the Mac should stay a Mac, even if some of iOS does shine through. And it should stay as a UNIX '03 compliant system, too.


Labels: , , , ,