Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The ceremonial file tree doesn't 'work' for nearly anybody. All significant apps embed their own structured data inside a big file, effectively implementing their own filesystem. The OS could have done so much to help.

In particular, no single OS can reimplement a distributed object store by themselves - there has to be an ecosystem. Somebody big has to invent that. Then, how to shim that under the file tree without changing the OS? E.g. I want an entire enterprise to get their apps from ... wherever its convenient for them to be stored today. Not from c:\xyz on their local disk. And I want some subset of my users to change to a new version without obsoleting the old, by changing the directory record in my enterprise cloud, NOT by triggering some binary update monstrostrosity, then writing another script to back out the update etc.

I'd say its universities that are letting us down, by continuing to teach the obsolete ideas current in the 1980s.



> The ceremonial file tree doesn't 'work' for nearly anybody. All significant apps embed their own structured data inside a big file, effectively implementing their own filesystem. The OS could have done so much to help.

Do you mean like a SQLite file? You have to consider how much there is to gain from embedding this stuff deeper.

> In particular, no single OS can reimplement a distributed object store by themselves - there has to be an ecosystem. Somebody big has to invent that. Then, how to shim that under the file tree without changing the OS? E.g. I want an entire enterprise to get their apps from ... wherever its convenient for them to be stored today. Not from c:\xyz on their local disk. And I want some subset of my users to change to a new version without obsoleting the old, by changing the directory record in my enterprise cloud, NOT by triggering some binary update monstrostrosity, then writing another script to back out the update etc.

This doesn't necessarily need to be in the OS. Look at it as a technical problem to solve. Is there a way to meet this need without changing the OS? There's usually a creative solution.


Ever try playing with plan9? It persuaded me that, yes, the modern tree filesystem sucks, but not because organizing persistent data into heirarchies is bad, but because you don't always want the physical translation presented to you. Plan9 was pervasively virtual, with an applications filesystem view being radically different than anothers, and with everything accessable through file read / writes (including OS system calls besides open, read, write, and close).


I've never tried Plan9. Doing searches over deep source code hierarchies has been my most recent experience with the inefficiency of the directory tree (nevermind the inefficiency of overly-complex source code). Really, there's no fundamental reason why `find /usr -name foo` has to take all day. While installing software, also, I was struck by how long it took, while it was apparently updating all the filesystem metadata. For the problem of long installs, I had a brainstorm: what if userspace could hand the filesystem an entire archive in a single transaction, and let the filesystem handle materializing it into a directory tree at its leisure? Just give the filesystem a tarball, rather than the application having to piece together the subtree step by tiny step? It would certainly make it more ACID, and it's not like tarfiles are bleeding-edge technology. Maybe that's a good project for someone who wants to hack filesystems.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: