An OS nobody heard of solved file search in the 90s, and we've traded its elegance for bloat

Published Aug 15, 2026, 8:00 PM EDT Simon is a Computer Science BSc graduate who has been writing about technology since 2014, and using Windows machines since 3.1. After working for an indie game studio and acting as the family's go-to technician for all computer issues, he found his passion for writing and decided to use his skill set to write about all things tech. Since beginning his writing career, he has written for many different publications such as WorldStart, Listverse, and MakeTechEasier. However, after finding his home at MakeUseOf in February 2019, he would eventually move on to its sister site, XDA, to bring the latest and greatest in Windows, Linux, and DIY electronics. If you've ever taken a peek into your operating system's activity monitor, there's a good chance you can spot a background daemon whose only job is to index everything for your OS's search function. Usually, it just sits there and does what it does best, but when something goes awry, it can end up consuming a ton of your resources. So how come nobody has invented a better, more efficient way for your PC to index everything for search? Well, it turns out someone already did. In fact, they released a more elegant search function in 1995, but modern-day computing had to leave it on the wayside. BeOS entered the scene to transform how PCs searched for things It had an early start, too Back in 1995, when Apple was tackling System 7, and Microsoft was putting the finishing touches on Windows 95, the humble BeOS was released. This OS was built from scratch by Be Inc., and its main goal was to handle multimedia files and heavy workloads better. One of the most unique elements of BeOS was its file system. Called "the Be File System" (BFS), it arrived a little later in BeOS's lifespan in 1997. This system didn't save files as unknown blobs of data. Instead, applications could tag files with attributes. An image's attributes could include information about who made it, while a song may have an artist, title, and genre associated with it. Once a file had all these attributes, the OS filed it away within its B+ trees the moment it was made. This meant there was no need for a daemon to trawl a system looking for files; everything was in its place the moment it arrived. The Be File System organised the data into neat pigeonholes... It was very smart for the time Let's take a closer look at how the Be File System did its job. When BeOS saved a file, it stored all of its attributes in a database-like system. This stored the attributes in columns that the OS could easily read. In fact, these attributes were stored alongside the file's inode data, so the PC could grab all the information in a single disk access pass. Because the Be File System stored files this way, it meant people and the OS could look for files the same way you would in any database software. For instance, you could run "NAME == "*.mp3" && ARTIST == "Daft Punk"" to fetch all the Daft Punk MP3s on your computer. As long as your discography was properly tagged, it would find them all. And it would do so very quickly. Keeping the indices current was pretty much instant, too. BeOS stored all the attributes in separate B+ trees. Whenever a file was written or updated, BeOS could update these B+ trees at the kernel level. This means the index was 100% up to date the moment a file hit the disk. It seemed like it would be the future of file storage. ...but data quickly became very un-pigeonhole-able Things got messy Of course, we now know that BeOS's system wasn't the future of file storage. But why did we default to a daemon devouring our system resources? Why did we ditch the Be File System's excellent file searcher? The BFS's search engine only works when every file has its proper home. And in 1997, that was pretty easy to do. However, as the internet took hold, we saw a huge flood of unstructured files. We saw HTML pages, PDF documents, raw text, and Office files uploaded to servers and downloaded en masse, and these files did not have metadata for each word inside them. To make the files searchable, operating systems have to go through the documents, extracting and tokenizing every single word. That's fine when your documents are a few pages long; when you start moving into 500-page PDF file territory, you start encountering issues. If BeOS had attempted that on the file-system layer, it would lock up the PC as it churned through the document. But there was an alternative. Instead of having the OS chug through a document and tokenizing each word, it would allow users to download the file, then sic a daemon on it that would gradually chew over the file. It would then update a search catalog with its findings over time. As such, the elegant BeOS faded into obscurity (with Be Inc. selling its assets and liquidating in 2001), while the daemons lived on as a modern-day operating system feature. BeOS's excellent system fell prey to modern-day needs BeOS's search feature was elegant. It took in files, put them in their proper places, and kept an organized and tidy record of where everything lived. However, as the internet took off, OS search tools had to sacrifice efficiency for accessibility, as people were now downloading huge documents on a regular basis. For that, the modern-day daemon was the best bet. It chews through your CPU resources, drains the battery, and when something goes wrong with it, it can drag your system down to a crawl. But when faced with the task of tokenizing every single word in that Lord of the Rings ebook someone just downloaded, it did the job far better. And while people to this day still search for instantaneous search tools (including BeOS's open-source continuation, Haiku), the daemon is here to stay.