Even now over 20 years later we still haven't had anything near as cool as BeFS. Who needs an email client when the file system can literally index it all and your inbox and email messages are literally files in a folder in a Tracker window that's just displaying email specific metadata for its columns.
> Who needs an email client when the file system can literally index it all and your inbox and email messages are literally files in a folder in a Tracker window that's just displaying email specific metadata for its columns.
As it soon turned out, almost everybody. All that BeFS does, in exchange for a bunch of your disk space and CPU, is BTree indexes, for each index you want your filesystem gets a little slower and bigger. It starts out "Quite a bit worse than some of the alternatives available at the time" and goes down from there. If you switch the indexing off so as to get back reasonable performance, now your email folders are just unsorted and sorting them takes forever as it would on a Windows PC (except your Windows PC has an email client so you wouldn't do that).
This makes for a cool demo of course, which is important if your actual goal is to get Apple to hire you instead of Jobs, but there's a reason why your filesystem did not add this fairly simple feature and you still have an email client.
Naive question... if your email client would have to do that anyway, in exchange for a bunch of your disk space and CPU, does moving that responsibility to the OS make a net difference?
Is it that BeFS was indexing everything and not just the folders that needed to be indexed?
macos spotlight is also routinely indexing the file system, doesn't seem so different to me, naively
I believe Spotlight has a full text search, which is a pretty major improvement, at of course a considerable price. Feels like a reasonable choice for My Novel/ and not a sane choice for Movie Downloads/ (unless maybe Spotlight can read subtitles???)
Also, an actual email client can specialise. BeFS is very general, the attributes can be typed but there's only one string type (other types include 32-bit and 64-bit integers, floats) so a Subject and a Sender email address both get indexed the same way. An email client might reasonably optimise for @corp.example type address searches for example, but then also do some simple keyword optimisations for subject line too.
You could not turn off indexing for some/ all folders in BeOS only for an entire filesystem (and if you do a bunch of stuff doesn't work)
Dominic Giampaolo worked on Spotlight at Apple, and was the BFS guy at Be... he (along with another engineer) wrote BFS pretty much from scratch for the PR1 release.
Before BFS, was OFS which was an actual database and was horribly buggy, requiring the BTree to be regenerated often enough that it was a "BIOS" level boot menu option on the BeBox running that version's Boot ROM.
A lot of the wonder at BFS stems from the marketing of OFS. BFS only retained the bare minimum features that OFS had, to make the database stuff still exist.
It doesn't seem entirely fair to say it stems from "marketing". There were and still are plenty of fully functional applications that rely on the filesystem attributes and indexing on BeOS/Haiku.
I'm sure it is way more limited than some original failed vision but limiting scope doesn't have to be a bad thing and I think what they ended up with does live up to the hype in some ways. That said, it certainly also has some flaws like not even being able to efficiently use the index for the built-in file find dialog because of case insensitivity.
No - it was marketing. The older Filesystem was a full on database and would allow the user to do all kinds of weird and wonderful things with metadata. But the Filesystem interface in BeOS prior to PR1 (well, technically AA) made it almost a herculean feat to interface an external non native file system to the OS.
BFS was written in a way that complied to a file system API that could then support other non-BFS file systems being plugged in. But because it was written in more of a traditional file system way, the database features got massively cut down to just attributes and indexes with live queries. It was a trade off. The database hype built by the DR releases (mainly for BeBox, I think only one made it publicly to Mac) was maintained because the attributes sort of mimicked the bare minimum functionality needed to tick a marketing box. But BFS really doesn't do much more than some other file systems have since done.
The OFS was more like the SQLServer based WinFS that Longhorn was going to have.
Well, I probably haven't seen the marketing you're referring to if it all happened before even that prerelease but people have kept talking about the BFS features for decades now and the interest is certainly not all based on some early marketing.
Yes it is a trade off. Not sure what other file systems you are referring to but I'm not aware of any others that enable the kind of applications BeOS had using these features. Those are also a key part of it.
> All that BeFS does, in exchange for a bunch of your disk space and CPU, is BTree indexes, for each index you want your filesystem gets a little slower and bigger. It starts out "Quite a bit worse than some of the alternatives available at the time" and goes down from there.
It’s true that indexes can impact performance but “quite a bit worse” is far from what I observed at the time. Even with hundreds of thousands of files it was quite responsive - Apple needed SSDs and 15 more years of development to get close, and Windows still hasn’t.
> Who needs an email client when the file system can literally index it all and your inbox and email messages are literally files in a folder in a Tracker window that's just displaying email specific metadata for its columns.
Everyone who uses more than one device to access his/her e-mail? Sure BeOS had nice features, but it seems to me that it solved the wrong problems.
Using this doesn't prevent you from using another email client to access the inbox too. It is true you don't get the same view to your data on all clients/platforms but then again this is usually true to a large extent always when using multiple generic email clients to access the same inbox.
BeFS has file attributes (so you can say this file is an email I received, add from="Bob Smith <b.smith@example.com>", received="2022-11-15") and it can optionally but by default index all these attributes using an on-disk BTree.
Many modern systems do have file attributes, although they're not always as capable as the ones in BeFS, and none of them to my knowledge chose to add all these BTrees because keeping them up-to-date is expensive.
NTFS provides on-disk indexes, that's where Windows Search stores its data... and how directories work in NTFS. Similar features can be handled in ZFS (the biggest issue is that IIRC its large K/V structure is AVL Tree, so you'd probably need to add a new object at ZPL layer).
What is the big difference is that BeFS exposed the extended attributes easily in the file manager and APIs - compare it with other systems where the APIs were little known or not used - POSIX extended attributes which are very limited (4k), Solaris extended attributes (which let you open a file as a directory) but are Solaris only, WinNT which had the issue of WinNT being a niche among windows systems, etc. etc.
BeOS in comparison required at least considerable porting work, at worst writing from scratch, and that meant the new features were much more visible.
