Antti wrote:If we think about Linux, like already mentioned, it follows the work done by previous "inventors".
That's only true to a certain degree. Sure, in some fundamental prinicples like files it just follows. But there's more to a kernel (even more a monolithic one) than just one part of the userspace API.
We have persistent objects, they're called files. - Ken?
Alright, so this is what you want to overcome. Great, but the way to do this isn't to tell us to keep doing the same, but just use less of these files. You need to come up with a new concept that fulfills the same requirements (and probably some more, because otherwise there would be no motivation to make a switch from the familiar concept) in a better way. This is the part that's completely missing in your proposal yet, you don't have an alternative.
So what part exactly do you want to get of? "persistent objects"? Probably not, people wouldn't like to lose persistency. I have a strong suspicion that it's the "they're called files" part, and you're really just after renaming things. Or, if it's neither, your definition of a file wasn't complete.
Another thing that the most common file systems provide is a hierarchical directory structure to actually find files/persistent objects. This is where you could change things if you found a good new way of presenting/addressing the objects. I must say that I like tree-like structures not too bad (symlinks turn it into a directed graph and then things already start to become a bit more confusing) and organise things in hierarchies even outside the file system, so I'm not unhappy with what we have today. Occasionally I've been thinking about two- (or multi-)dimensional file systems, but it turned out a bit confusing and I didn't consider it worth thinking more about it given that hierarchical file systems just work fine.
(This is all simplified a bit by ignoring that files aren't atomic objects, but rather contain many subobjects. Therefore your proposal doesn't really make a difference for this part of the discussion, because you're merely changing the granularity at which the file system vs. the user application manages the objects in a given set of objects. Using the file system is common code, doing it in the application can easily lead to reinventing the wheel everywhere.)
b) "Hey hey hey let's hold on. What we did back then seemed to be good idea and we did best we could. We have quite limited resources but we wanted to get something done and we were paid for that. It turned out that our ideas were quite good. However, I am terrified that those ideas are so high-valued among the people in this field. There were many temporary solutions that were supposed to last just until we got more hardware resources or found other way to do that more elegantly. Now it turned out that we are so stuck in this. The whole computer industry depends on these assumptions. Please try to break this and try to search new ways of doing things you consider self-evident. We won't mind. I think some of the ideas were bad at the very beginning."
Does that latter make any sense? I think it does.
Can you name the temporary solutions made for the limited hardware resources that we're still stuck with? We're not using the exact same file system any more. What we do use is the abstraction of files and the tree-like structure. They seem pretty universal and not tied to hardware capabilities.
