Now I'm not talking flash rom, no. Nothing that slow. Instead I'm suggesting that when you pay the $300 for an operating system, that you get a hard burned ROM module that has a release version of the operating system on it.
Basically the idea is to add a slot (that would probably look like some kind of ram module, but mostly because it's connected to a memory bus) to the motherboard that allows you to insert either a a rom module, a flash module, or a hybrid flash/rom module. Then rewrite the bios so that if it's a rom module, the drive is treated as read only, and read-write if it's a flash or flash hybrid module. Then when you write your OS, you write your own "OS Drive" driver module. This module would first find the ROM drive, then it would load a "changed files" image off of the hard disk. The OS would take and create a virtual file system that has the OS files (from the rom/flash module) that has the OS and the HDD on it. In the case of rom/flash hybrid modules (Which would be the preferred method), OS patches would be installed into the flash space, and then between the rom/flash/hdd a virtual drive would be created. If the file exists on the HDD, the HDD file is preferred over the flash file, which is preferred over a rom file. This would allow for patching and the like to be used, but would take the basic operating speed of the computer and send it through the roof. And if you make the OS patches do a forcible install onto the flash module, then you can minimize the amount of terribly slow HDD access. And if you keep a list of files in memory that have HDD overlays, you can speed up the search process by knowing in advance to bypass the rom module.
The hope would be to have maybe two or three slots (three preferred) that could be filled in. The hope would be to have a "OS" module, a slot for a dedicated applications module (Which would allow business computers to have tiny hard drives and just FLY), and a slot for a dedicated patched file flash module. On computer labs and processing banks, this, coupled with a ram drive, would allow for completely disk less systems. If the "Overlay File System" where made to natively support a ram-drive in it's design, the terminals you could build would be just scary fast. And since hard burned rom modules are cheap and fast, the cost of implementation would be small. It'd be kinda like being able to buy a system from Dell or some such with the applications preinstalled while still being able to customize the system. It's the best of both worlds, and on top of that, it doesn't force a single os either. You could leave the extension slots empty and still make the system work. You could install all of the OS onto the HDD, or an experienced user could take their own custom OS and burn it onto a flash module. This way even Linux and OpenBSD users could have their cake and eat it too.
There would be a strong limitation, and the bios would have to check this, and that's that all of the modules and the associated HDD partition would have to be designed to work together. I mean consider, you really would have to make sure that the file system was truly aware of this design. But that would be pretty easy if you where to modify an existing file system to include markers for what module layer the file is on, and then actually keep the file system on the HDD (Which would probably be merged with the discovered module file systems at boot time by a software utility in the OS.)
A second problem exists in dealing with moving HDD's around. I mean, how do you handle the scenario that a person with OS module X takes his HDD out and puts it in a computer with OS module Y. Especially in the case that OS module X and Y are two slightly different versions of the same OS (Keep in mind, just a slightly different DLL is enough here) I think it would be important to have a way to copy the data off the modules onto the HDD and mark the HDD as a non-layered file system, so that you could make a transfer. I really don't think it would be wise to go the other way, but even in the case of the slightly different OS case, it would be quite useful to be able to go the other way as well. Basically do a file compare between all of the modules and the HDD and if a module has an appropriate file, mark the file to use it instead and then mark the partition as layered again.
Oohh... oohh, what if this tech was built into an "external hard drive controller" and made into a PCI board? The controller would emulate a standard ATAPI IDE controller, and would actually have an IDE controller on it, but it would map the ROM to a fixed space in the HDD's virtual address space. Wouldn't be anywhere as good as making a true implementation at the OS level (Because a whole bunch of optimizations could be done to make better use of the virtual address space,) but it would definitely make for a useful transitional solution.
Hmmm... I think this one may actually be within my skill level within the next 3 years (Being an EE major kinda helps there...) Maybe I should sit down and actually build a computer with this hardware structure and then modify a version of linux to handle it. I would have to write my own hardware drivers, and file system drivers, but it might definitely be a worthwhile project.
Yum... Booting in 20 seconds... Nice.
Mood: Creative