Pinderkent

Today I read an article suggesting that 8 GB of RAM is "only just enough" memory for a typical developer's PC running Windows. I'm not here to dispute that claim. Indeed, the RAM usages given in the article are somewhat realistic. Using recent versions of Microsoft's various software and database development tools does require a significant amount of RAM. In many ways, the need for that much RAM is unfortunate and likely quite unnecessary.

In the mid-1990s, I had the pleasure of doing software development on a NeXTstation Color. Unlike the base NeXTstation Color models, which came with 12 MB of RAM, the system I was using had been upgraded at some point to 16 MB of RAM. But by that point, it had been used by several developers before being passed on to me. Yet it was still an extremely powerful development system.

Now, it might be argued that Windows development today isn't much like the software development we did on a NeXT system 15 years ago. In some sense this is true, but for the most part very little has changed. Objective-C is relatively similar to C#. The various NeXTstep kits are fundamentally similar to the .NET standard class library. We had Project Builder for development, as well as Interface Builder for drag-and-drop GUI creation. And although it wasn't available yet when I was developing on that NeXTstation, NeXT would later introduce WebObjects for developing Web applications.

Anyone who has done any Mac OS X development lately has a general idea of what it was like to develop software on a NeXT system. It was an experience quite comparable to software development today, due to how far ahead of its time NeXT and their software offerings were. And although many people today might find it difficult to believe, we actually were able to develop relatively complex business software on a system that had only 16 MB of RAM. To put things into perspective, the article I read today claims that at least 500 times as much RAM is needed today than was needed 15 years ago. But the software we're developing today really isn't much more complex.

It's obvious why this has happened. Since then, the price of RAM has dropped considerably. It has become far cheaper to acquire more RAM than it is to pay a developer to write more efficient software. In fact, we see this reflected throughout the entire software stack. It's no secret that Windows Vista requires a significant amount of memory to run efficiently. The same goes for .NET. Developer tools like Visual Studio are also very memory-intensive. Given the platform and development tool vendor's general disdain towards writing memory-efficient software, it's no surprise that the applications developed by software developers using those tools would also consume more memory than necessary.

One thing to consider is how we now approach a simple task, such as reading and writing data files, versus how it was done 15 years ago. Today, we're likely to see some given data persisted to an XML file on disk. To work with such files, we'll need an XML parser, some way of representing the XML document in memory, custom code to tie everything together, and so forth. Fifteen years ago, we would have used a custom binary format, and written the serialization and deserialization code ourselves. Although it would have taken longer to develop, the overhead in terms of memory usage and CPU usage would have been considerably less with the custom binary format.

But to require over 500 times as much memory today is still quite excessive. I think it just goes to show how little developers today care about minimizing memory usage of their applications. The low cost of RAM no doubt helps our "cause" immensely. Today we can get away with waste that would have been considered intolerable a decade ago. But on the other hand, I think we are shortchanging ourselves to some extent. The memory we consume today, essentially out of waste and carelessness, could no doubt be better used for other purposes. Extra memory put towards even just caching data from disk is typically beneficial to system performance, even in systems with significant amounts of RAM.

Fifteen years ago, I don't think I would have believed it if somebody from now had come and told me that we'd have low-end PCs with 4 GB of RAM, typical development systems with 8 GB, and we'd actually need that much RAM to run contemporary applications. Yet here we are. And I don't even think it'd take that much more care or effort to minimize the amount of RAM we use, or at least bring it down to a more reasonable level. To have any effect, we'd need to see this initiative at all software levels, from the operating system, to any higher-level runtimes like .NET and Java, to our software development tools, and finally to the applications we develop. Unfortunately, I don't see this happening.

Today I read an article reminiscing about the high responsiveness of BeOS. It is unfortunate that people in general are beginning to forget about BeOS. It was a truly remarkable operating system, and as the article I read correctly points out, the responsiveness of the desktop environment it provided over a decade ago still hasn't been matched even by contemporary desktop environments.

It's no wonder that BeOS was able to provide such a responsive desktop experience. We can better understand this by reading the The Media OS whitepaper from Be, Inc.. Their BeOS R4 datasheet is also a useful document to read.

They correctly predicted the rise of multiprocessor systems, although perhaps anticipated their widespread adoption somewhat prematurely. Furthermore, they correctly predicted that such processors would be 64-bit processors. The result was an operating system that was heavily threaded throughout, with powerful 64-bit filesystem, and high-performance graphics and I/O subsystems.

At a higher level, BeOS's various "Kits" provided very well-organized and sensible chunks of functionality. In addition, it offered a very UNIX-like filesystem layout and set of commands. I recall feeling very comfortable and productive with BeOS the first time I used it in the 1990s, because I could reuse so much of my knowledge from my previous experiences with operating systems like Solaris, HP-UX, Linux and BSD/OS.

Even today, over ten years after its release, we can read through the BeOS Release 4 specifications and still not find some of this functionality suitably implemented in today's best desktop and workstation operating systems. And we can't forget that BeOS Release 4 wasn't even the last release of BeOS!

For a variety of reasons, BeOS never succeeded in the marketplace. In many respects, it was likely available far too early to really prove its worth. It's only now that we are just beginning to have widely-available systems, like those built around Intel's Core i7 CPUs, that could really benefit from the pervasive multi-threading and 64-bit support that BeOS offered a decade ago.

Although there have been some attempts, it's unlikely at this point that we'll see much, if anything, further come of the original BeOS codebase. Thankfully, there have been efforts by the open source community to develop operating systems that bring us the benefits of BeOS. The most notable of these projects is likely Haiku. It has been progressing well, with VMware images available for use.

BeOS was a truly amazing desktop and workstation operating system, clearly a decade before its time. Were it to have survived and been continually developed, today it would likely provide a tremendously responsive, productive and powerful desktop environment. This is would be especially true on today's computers with 8 logical 64-bit CPUs, extremely capable graphics hardware, and much faster I/O. Even if open source efforts like Haiku manage to capture a small fraction of the BeOS experience, we'll be very well off.