Fog Creek Software
Discussion Board




Feasibility of a VMOS

There are too many flamewars, so I'd like to start a constructive thread.

I've thought about this a bit, but haven't done anything about it.

Computers have gotten fast enough that running VM's like VB, Java, or .NET isn't a big deal.

MS and others are investigating making file systems a database.

Open Source is a great way to test new technological paradigms.

Would it be feasible to create a new operating system where the kernel works on a VM, allowing the kernel to remain the same across hardware.  Further, the file system would be a database.  And finally, since the system is a VM, could all libraries and API's be stored in code form in the database, and compiled on the fly, instead of storing binaries?

How do you envision next-next-generation operating systems?

Wishful Dreamer
Tuesday, August 17, 2004

How about this:  http://cjos.sourceforge.net/archive/

r1ch
Tuesday, August 17, 2004

What bit was accidentally flipped in the minds of those that thought 'Hey, lets make the file system a database!'?

Really, I just don't see how this would be advantageous at all. Enlighten me, please?

I am Jack's impending coronary
Tuesday, August 17, 2004

Yes, but only sometimes.

Dennis Forbes
Tuesday, August 17, 2004

I've ranted and raved about this before; I'm not an OS guru (but I am a DBMS one) but I’ve been waiting for the antiquated concept of a ‘file’ to go away for a long time now. The ‘file’ concept exposes the underlying physical construct (e.g. an entry in a MFT or FAT for example) to the user for no particularly good reason. Nowadays this limitation is foisted upon users simply because “that’s the way we’ve always done it” which is totally contrary to the way we think of logical constructs: documents, emails, contacts, etc.

When you really think about it, though, current operating systems are a form of DBMS except without some of the DBMS features that we all know and love -- constraints, domains, query language etc. (some of these are currently emulated via application programs). And if you think the other way around a complete DBMS would really be an OS in of itself (it has paging mechanisms, disk I/O, replication, distribution, etc.).

Taking it to the furthest level applications would no longer necessarily be compiled code but ‘business rules’ (aka constraints) that plug into the user’s DBMS and are interpreted via the UI (which itself would be a single program a la browser-based systems).

(And as an aside, the above concepts are slowly being “reinvented” by the XML crowd (e.g. XUL, WinFS, etc.). It’s a shame we’ve had the framework for a good 30-40 years but no one has really thought about it until now and instead choose the flavor-of-the-month instead of the sound foundation that the RDBMS provides. The probable outcome is that the XML-based products will fail just like their ancestors (IBM IMS and other hierarchic/network products) did and kill any future development in this area through guilt-by-association.)

It would probably require re-thinking virtually everything that we do nowadays for application development, but I think it’s quite an idea.

Captain McFly
Tuesday, August 17, 2004

BTW: The Fight Club is an awesome movie. Maybe I'll put it on the second monitor tonight.

Dennis Forbes
Tuesday, August 17, 2004

And of course all applications written would have their own database in which to work, and uninstalling an application would be kind of nice (you just drop their database) – no left over bits of an application strewn over your OS.

Such a system would be quite complex to develop but I think, for the first time in computing science, we have both the power (e.g. hardware is to the point in which this is feasible) and the talent (we have a lot of great developers) to get it done. If I had enough money I’d start a company to develop this system. :)

Captain McFly
Tuesday, August 17, 2004

I am enlightened, sir. Thanks. I suppose it is already a database of sorts just with an interface layer over it.

I guess where I was getting lost is thinking about things like primary and foreign keys and referential integrity.

In the sanse that a FAT is already a table, there is an unnecessary layer there, and we may do well to remove it.

I don't know though, many users still seem a bit dumbfounded about what the file system is and how it works. I'd hate to change the game on them if they've made any progress whatsoever towards understanding it.

And Fight Club is one of the best movies ever. I have a theory I haven't heard anyone else say that I always like to debate with people though.

You know Jack = Tyler.

My theory? Marla = Tyler = Jack. Next time you watch, think about that possibility. I don't know if it was Pahlniuk's<sp?> intention or not, but it sure doesn't seem like a far stretch. Some parts of the movie all but scream it.... to me anyway.

I am Jack's nirvana
Tuesday, August 17, 2004

Check out the platforms NetBSD will run on. Your toaster is probably in there somewhere.

http://www.netbsd.org

Tom H
Tuesday, August 17, 2004

The Squeak smalltalk system ( http://www.squeak.org ) is already written in this way for the most part. The VM is actually written in Smalltalk itself, and the VM can run another VM within itself (slowly).

The advantage of this is that it's really really easy to experiment with the structure of the VM within this environment. When they want a "real" version, they run a smalltalk-to-C translator, and get a native VM out.

Squeak runs on everything from bare hardware up to mainframes, and is almost identical on each of them.

Now if I could only figure out how to actually *do* anything in smalltalk, I'd be set. :-)

Chris Tavares
Tuesday, August 17, 2004

"Would it be feasible to create a new operating system where the kernel works on a VM, allowing the kernel to remain the same across hardware"

It's not clear to me that the VM running on bare metal would be easier to write than the kernel itself. Remember that all VMs rely heavily on the underlying operating system.

But Burroughs actually did something very much like this back in the 60's and 70's. They had a whole series of machines from very small to mainframe that all ran the same (interpreted) microcode (the microcode was written in what they called nanocode, the nanocode varied by processor line). 

Tom H
Tuesday, August 17, 2004

Isn't this what the HAL and x86 already provide?

Just me (Sir to you)
Wednesday, August 18, 2004

"Isn't this what the HAL and x86 already provide?"

Pretty much. The Windows (NT) kernel is written to be portable, although I read a while ago that some performance critical parts of it--such as the trap handler--are written in assembler.

John Topley (www.johntopley.com)
Wednesday, August 18, 2004

1.  No, computers have NOT gotten fast enough that running a VM like Java is not a big deal.  The survival of C and C++, and comments on the efficiency and speed of Java, show that there is still a noticible performance penalty for using a VM.

2.  The VM HAS to run on something.  That something IS the OS.  Even in these days of multi-gigahertz hardware, the classic boot process of ROM boot loading hard-disk boot-sector loading some OS file still has to happen.  The OS must provide services for disk access, port access, and user I/O access.  Multi-tasking support is awfully nice (though MSDOS never had it, Unix and Windows do).

These things already exist in the OS in compiled code.  I suppose you could put a VM 'wrapper' around calls to the underlying OS, and CALL that a 'VMOS' -- how else does Java write to the disk, after all -- but I don't think that would make it a 'VMOS'.

3.  It was the writing of Unix in C, a high-level language, that led to a large break-through in OS portability.  Before that, only assembly language could be compiled to efficient enough code to run the OS.  C was a language designed for efficient compilation -- but it still had to be compiled to produce the OS run-time file. 

AllanL5
Wednesday, August 18, 2004

>> What bit was accidentally flipped in the minds of those that thought 'Hey, lets make the file system a database!'?

Really, I just don't see how this would be advantageous at all. Enlighten me, please?  <<

Hmmm.  Never ran BeOS, eh?

BeOS used a database (not an RDMS, but still...) to track file attributes (yer usual create/modified date, etc), plus you could add your own -- like the genre of that cool MP3 you just ripped.  So when it came time to find that DreamTheater album, the criteria to find it is: WHERE Genre = 'ProgRock'

Very nice feature.

example
Wednesday, August 18, 2004

*  Recent Topics

*  Fog Creek Home