5 ms·
BeFS wasn't a database. It had indexed queries on EAs and they had the habit of asking application files to add their indexable content to the EAs. Internally
by foobiekr 1y ago
BeFS wasn't a database. It had indexed queries on EAs and they had the habit of asking application files to add their indexable content to the EAs. Internally it was just a mostly-not-transactional collection of btrees.
There was no query language for updating files, or even inspecting anything about a file that was not published in the EAs (or implicitly do as with adapters), there were no multi-file transactions, no joins, nothing. Just rich metadata support in the FS.
- Ericson2314 1y agoYeah I am talking more deep architecture, and BeOS is more notable here mostly on just the user-interface level. However, I think it is reasonable to think that with way more time and money, these things would meet up. Think about it as digging a tunnel from both sides of the mountain.
- foobiekr 1y agoMicrosoft poured at least $100M into this hole with nothing to show for it.
- Ericson2314 1y agoThat doesn't disprove anything for me. It just says POSIX DOS lowest common denominator network effects are a hell of a drug. Whenever we're talking about interfaces, coordination success or failure is the name of the game.
- foobiekr 1y agoWhat problem do you think a DB-as-filesystem solves? The only obvious one that makes any sense at all is cross-file transactions.
- Ericson2314 1y agoThe filesystem is a bad database Directories are a shitty underpowered way to organize data? No good transactions Conflation of different needs such as atomic replace vs log-structured I would like to use a better database instead.
- foobiekr 1y agoWould you pay 50x performance decrease?
- Ericson2314 1y agoNo, and I would also not need to.