BeOS solved elegant file search in 1995—why we abandoned it for bloated daemons

There's a daemon running on your computer right now, probably. Open your activity monitor and you'll likely find it—a background process whose sole job is to index everything so your operating system can search. Most of the time it sits quietly in the background, but when something breaks, it can consume enormous amounts of your CPU, drain your battery, and grind your machine to a halt. It's become so normal that we barely notice it anymore. But there was a time, not that long ago, when someone figured out a fundamentally better way to do this. They built it in 1995. We threw it away anyway.

When BeOS arrived in 1995, the computing world was split between Apple's System 7 and Microsoft's Windows 95. Be Inc. built their operating system from the ground up with a specific purpose: to handle multimedia files and heavy computational workloads better than anything else on the market. The real innovation came two years later, in 1997, when they introduced the Be File System—BFS—a file storage architecture that worked on a principle so simple it's almost embarrassing we abandoned it.

Instead of treating files as opaque blobs of data, BFS let applications tag files with structured attributes. An image could carry metadata about its creator. A song could store artist, title, and genre. The crucial part: the moment a file was written to disk, the operating system automatically filed all those attributes into B+ trees—database-like structures that kept everything organized at the kernel level. There was no need for a background daemon to crawl through your hard drive looking for things. The index was complete and current the instant the file arrived. If you wanted to find every Daft Punk MP3 on your computer, you could write a query like "NAME == '*.mp3' && ARTIST == 'Daft Punk'" and get results instantly. The entire operation was fast because the OS could grab all the information in a single disk access.

For a moment in the late 1990s, this looked like the future of computing. It was elegant. It was efficient. It required no background processes consuming your resources. But then the internet happened, and everything changed. As the web exploded, computers began downloading vast quantities of unstructured files—HTML pages, PDF documents, raw text, Office files—none of which came with the kind of metadata that BFS depended on. To make these files searchable, an operating system would have to do something BFS was never designed for: open each document, extract every single word, tokenize it, and index it. For a five-page document, that's manageable. For a 500-page PDF, it's a different story. If BeOS had tried to do this work at the file-system level, it would have locked up the entire machine while it churned through the text.

So the industry made a choice. Instead of having the operating system do the heavy lifting immediately, they created background daemons that would gradually work through files over time, updating a search catalog as they went. It was less elegant than BFS, less efficient, and it required constant background processing. But it worked. It could handle the messy, unstructured reality of the internet. Be Inc. sold its assets and liquidated in 2001. BeOS faded into obscurity. The daemons stayed.

Today, we live with the consequences of that choice. Modern search tools sacrifice efficiency for accessibility. They consume resources, drain batteries, and occasionally drag entire systems to a crawl when something goes wrong. People still search for better solutions—Haiku, an open-source continuation of BeOS, still has adherents who remember what elegant file search looked like. But the daemon is here to stay. We traded a system that worked perfectly for structured data to handle a world that generates mostly unstructured data. It's not clear we got the better end of that bargain.