Please read this: http://thomas.enix.org/pub/rmll2005/rmll2005-shapiro1.pdf

Because EROS processes survive system shutdown, no file system is required to provide persistence. The operating system instead implements a transactional block store with only two kinds of objects at the disk level of abstraction: pages (which hold user data) and nodes (which hold capabilities). Human naming services (directories) are provided by applications that act as directory servers. EROS does not have any notion of a “file system root directory” or a universally shared file system at all. An EROS system is simply a very large space of objects that are connected together by capabilities. Surprisingly, the resulting persistence implementation is both simpler and faster than a conventional file system.

You can actually go further, and dispense with the operating system too, by running an image-based programming language, such as Smalltalk or Lisp, on the bare metal. Device drivers and other essential functions of operating systems then become part of the language.

I read the paper, and it appears to describe a scenario where users don't even own the computer---they just rent time on a computer run by somebody else (known today as the "cloud"). Also, it seems to describe a silo of applications where moving a file across applications becomes a significant action. I'm reminded of a story of a person, who, when asked to copy a file, loads up the application that made it (in this case, Microsoft Word), opens the file (from the harddrive) and saves it in a new location (the floppy drive), not even aware that one could just "copy c:file.doc a:file.doc".

It does not seem like a system I would like.

I'm also skeptical of image based languages (but I'm willing to admit I am biased towards files).

Thanks for the reference. A quick glance over that paper suggests they have a powerful capability system which tied with the objects provides the necessary abstraction. As such page objects themselves don't provide any benefits.

In that sense files can also be thought of objects with a set of methods (walk, open, read, write, close etc). The only difference being their object collection is graph while filesystem is a tree.

Historically unix systems have very weak capability system; there are research operating systems which try to address this but you don't need to get rid of the filesystem/file as an abstraction.

I have played with image based programming environements(pharo, CL) in the past; i am not sure how well they will inter-operate with programs written in other languages that don't share the same semantics.