Also it is possible to boot from RAM: as well, Toni Wilen did it once by accident.
That sounds like he's not using the standard ram handler, because it's not recoverable.
There was a 3rd part recoverable ram drive that was variable sized and recoverable.
The only reason the original rad: was fixed size was because it's easier to make it resident if it doesn't keep changing size. The source was also used as an example of a block device.
A network boot wouldn't be hard, you just need to write a device that fetches an image across the network when it starts & decompresses into ram. From then on it can just memcpy when asked to read. You could use something like this
http://web.mit.edu/~mkgray/afs/bar/afs/net/dev/project/cgw/misc/tinytcp/ and store the image on an ftp server. Once you've got the code written then making sure it's rommable and making it auto boot at startup is a bit of work, but not too hard. You'd need to have the file system in rom as well.
Configuration for stuff like this is usually done using DHCP and files are provided by TFTP, but people generally don't have a TFTP server & DHCP is a bit of a pain to setup. Obviously you can just burn the settings into an eprom if you're doing it for yourself, but for something commercial you'd probably want to either go through the pain of DHCP or use some other form of broadcast that communicates with software on a pc.
If you want to only fetch files as they are used to reduce on ram usage then it's going to be more complex as you'll need to write a file system, a better network implementation and it's likely to be slower because of latency. You'll also need to use the same tcp/ip stack at bootup as you're using when running your computer, so that would also have to be rommable as well (which because of settings etc none currently are) or come up with some shim that allows both your mini tcpip stack and the main tcpip stack to run at the same time.
