2004¦~10¤ë4¤é

File System Shoot-Out Speaking of not know what you're missing, we now come to the single largest usability difference between BeOS and OS X -- the file system and the practices and policies used to work in it. I've written at great length about Be's file system, as it remains the one functional aspect of the operating system which truly sets BeOS apart from anything else on the market (not that BeOS is really "in the market" anymore). BFS (the Be File System) is fully journaled, which means that data integrity is guaranteed even in the event of a loss of power. Pull the plug on a BeOS box and it boots back up in 15 seconds with no loss of data. File system operations that were in process at the time of the outage are simply replayed from the journal. No ScanDisk, no fschk, no rebuilding the desktop. OS X does not have a journaled file system (although, to be fair, I have lost power on this machine and found that it booted back up in a normal time span without appearing to do anything special). BFS is also fully multithreaded for optimum performance, and in keeping with the rest of BeOS, which is multithreaded from the lowest levels to the highest. I do not know whether HFS+ is multithreaded (I've heard that it's not), but it sure doesn't feel as fast as BFS. However, I do not have equivalent hardware on which to run comparative disk access benchmarks under various conditions. The address space in BFS is 64-bit, meaning that the theoretical maximum file size on a BFS volume is 18,000 petabytes (the practical maximum is much smaller for various reasons, but is still in the tens of thousands of gigabytes range). The 32-bit HFS+, like all 32-bit file systems, has a maximum file size of around four gigabytes. Larger files are possible via behind-the-scenes magic which transparently stitches files together, but it seems like this is an issue Apple would have addressed as long as they were creating a new operating system and had the chance to get it right. For the everyday user, though, BFS has much more tangible advantages. Any file or file type on a BFS volume can have arrays of metadata associated with it, in the form of "attributes." There is no limit to the amount, size, or type of attributes, and attributes can be displayed and edited, sifted, sorted, and queried for directly in the Tracker (Be's equivalent of the Finder). Because most attributes are indexed, search results are nearly instantaneous, regardless the size of the volume or the number of files being searched through. By default, BeOS ships with reasonable sets of attributes for common file types, but users are allowed to extend and customize these, and to create entirely new file types with entirely new arrays of attributes. In other words, the Be File System doubles as a database. Be's filesystem doubles as a database. Users can use built-in filetypes with existing attributes, or create entirely new filetypes with custom collections of attributes. These files were used to deliver a dynamic web site out of the BFS database without using 3rd-party database software. Click for larger image. It is difficult to describe to users of other operating systems just how advantageous an operating system built on top of a virtual database can be. Only other BeOS users really seem to understand the power and flexibility of the database-like file system, and it is the single feature I miss the most from BeOS. Some examples of Be's database-like file system in action: Copy your MP3 files' ID3 tags to Artist, Title, Year, Genre attributes. Sift and sort through your collection in the Tracker in almost anyway imaginable, or build playlists from MP3 attribute queries with far more flexibility than you get in other OSes. BeMail messages store Subject, From, To, CC:, Date, etc. in attributes. Create virtual mailboxes based on live, instantaneous query results. This lets you obtain views of your email store that are irrespective of the actual folder locations of BeMail messages on disk. Years ago, I created a custom file type based on text, with attributes for author, title, email, URL, etc. Then I wrote a CGI script in perl to extract and dish up these attributes over the web. In other words, I was serving up a database-backed web site without having to install or learn any database software whatsoever. That site now runs on LAMP, but you can see how the site was created here. OS X's closest approximation is the pathetic comments field, which is a pain to use (hell, you can't even enter Comments directly into the Finder), and which offers next to nothing in comparison to BFS attributes. The great usability of BFS and the Tracker don't end with plain-sight attributes. Additional attributes describe each file's type via the Internet-standard MIME system, which provides a great deal of compatibility with the world at large (download a file from the internet and its type can be gleaned from the HTTP header, without use of extensions), and BeOS web servers don't need to maintain separate MIME tables - each file's type is taken directly from the file system. Attributes are used by StyledEdit to allow for rich formatting in plain text documents, which are still viewable as plain text on other platforms. Attributes are used to retain cursor position in documents even after they're closed and re-opened, and are used to store equalization and cross-fade settings for MP3 files. The possibilities are endless. 1:26:54 PM