Linked by J. Scott Edwards on Fri 17th Dec 2004 18:51 UTC
Every hard-core OS aficionado has done it: Laid out a grand scheme for creating the perfect OS. Taking all the best features and attributes from the OSes we love, and making sure to assiduously avoid the pitfalls of the OSes we don't. Maybe our goals were modest, and we just wanted a slightly tweaked version of an existing OS. But sometimes we're feeling ambitious, and we have large, creative ideas for revolutionizing computing. Long-time OSNews reader and contributor J. Scott Edwards just couldn't help himself, and he has set about to not only plan, but to try to build his dream OS.
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
In many ways this is an ideal situation.
If you have, essentially, a boatload of non-volitale RAM, you never have the issue of serializing data out to a different medium (at least not as an everyday task like loading and saving a file).
You simply work on your internal structures just like any other piece of internal data. Say your program has options that you'd normally store in something like the Registry, or an XML file, or whatever.
In a pervasive system, this problem is gone. Once a program is "installed", it's essentially there forever, always "running", but simply "swapped out" when idle.
The classic example of this is something like a Smalltalk image. "Everything is an object", and always alive, running, and kicking. When you snapshot the image, you "freeze it" in time for revival later.
Now, imagine the new 64-Bit systems, with their ungodly address spaces. Imagine taking your 120GB drive.
int fd = open("/dev/hda", O_RDWR);
void *heap = mmap(NULL, 120*1024*1024*1024, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE, 0);
and away you go...
It seems like a panacea, but while it can be argued that writing programs would be easier because we no longer have all of these marhalling problems of moving data across boundaries from "disk" to "ram", in the end you would end up with the exact same problems that you have today.
A zillion "files" (or, now, Objects), all in different formats that requires particular programs to understand them. You still wouldn't be able to find anything, you'd still have problems manipulating the files in an "easy way", you'd still have vendors that may write code to the letter of the "interoperability" rules, but are still horrible "citizens" in the computing environment because they don't go all way with the spirit of interoperability.
Think about Microsoft's object models for its documents. Microsoft doesn't document it's Word format, but it does document its programming interface, and any VB programmer on the planet can make those documents jump through hoops by leveraging Word directly to manipulate the document, just like you'd do to manipulate an XML document.
The problems aren't necessarily the systems themselves, but simply the domain of the problem.
Simple example, I have 700,000+ files on my machine, not including those files stored in ZIP/tar files. As a whole, 700,000 disparate, loosely grouped, but mostly unrelated files are just a flat hard thing to ogranize and wrap your head around.
The two framed pictures of my wife on desk are easy to organize, but two large boxes of thousands random photos at home are not.
It's not a systems problem, it's a data problem.