Talk:BeOS
I don't understand the second part of the following sentence: It has an optimised 64-bit journaling and indexed file system called BFS, but rather than use a database BeOS relied on its low OS latencies to journal and query file attributes on the fly. Can someone clarify it ? -- FvdP 10:24 Sep 5, 2002 (PDT)
osnews.com is not only about BeOS!
- I removed the OS News link. If someone wants to put it back, then I don't think that it should be under BeOS community sites.
- Tim Ivorson 19:26, 9 Aug 2004 (UTC)
BFS discussion
The BFS used to be a full relational database, such as Microsoft Access or *SQL. This created the capability to assign any number of 'attributes' to a particular file type. For example, on my BeOS installation, I added the following attributes to the .mp3 filetype: title, artist, source cd, length, rating. Once those attributes were assigned, and the values filled in for each song, I could search my hard drive like this: "Find all .mp3s by Tom Petty that are over 3 minutes in length and have a rating higher than 8".
However, during early development, it was obvious that a databse as a file system would be much slower than what they wanted. Be, Inc. still wanted the functionality of a databse-drived file system, with the speed of a conventional file system. So, they redesigned the file system to be database-'like'. Details on the underlying structure of the BFS can be found here. The book referenced at that link has portions of the source code for the BFS.
Once the filesystem was redesigned, and no longer running on a full relational database, it still had the functionality to execute the query I described above. On a side note, a query like that on a 5GB hard disk took about .2 seconds. The combination of a powerful file system attribute system and a trim, legacy-free operating system yielded the query speeds that Be, Inc. wanted to see.
For a short discussion on filesystem journaling, see "BeOS and BFS" on Low End Mac.
Cleanup tag
Either explain whats wrong with the article, or I'm taking it away in a few days. --Kiand 19:04, 27 August 2005 (UTC)
BeOS Interface was notable! Gui comparisons.
- The BeOS user interface was notable at the time for being almost completely unthemeable, even with third party hacks. While Mac OS X is now similarly locked, the BeOS theme of yellow, changing length tabs on the top of windows, and relatively plain grey interface widgets was enforced. This UI remained relatively unchanged from 1995, but had been completely overhauled by the time of the leaked Dano release. An easter egg in the OS allowed changing the titlebar look-and-feel to a few others, and in Dano, this had been extended to be a feature allowing changing of the title bar and scrollbars. No other interface widgets could be changed.
Yes, the BeOS user interface was notable at the time for being a superior blend of Amiga Toolbox, Mac System and Windows 95 conventions. No interfaces at the time were themable, except by third party hacks. Just because the Mac System software had these hacks for so long, eventually pieces of them were integrated into Mac OS proper. The BeOS was functional wnough that hacks to add trivial functionality weren't an urgent need The only bit that was overlooked was movable tabs, that were added later. Note that Mac OS nor Windows had tabs at all, so this is an understandable oversight.
Of course if this means to say trivial appearance hacks, then this paragraph is totally unbalanced nonsense. Since at least BeOS R3 the easter egg was present that allowed changing the behaivor of the window management similar to Windows, MacOS, or Amiga, if you didn't mind giving up the superior BeOS functionality in exchange for some nostalgia.
I am not disputing the facts of the paragraph, but its use of technical truths to distort the picture. "...Even with third party hacks" as if the superior functionalty of the BeOS not needing 3rd party hacks for basic funtionality is a shortcoming. For example, many Mac users of the time purchased a utility called Window Shade to improve the functionality of the window management, because there was no Minimize style functionality. Neither Windows nor MacOS had a send window to back feature, yet under Be the Amiga theme highlighted this feature. It seemed as if the three alternative themes served to highlight the strengths of the unique (at the time) interface, which seems to have strongly influenced Gnome and KDE, as well as Windows and Mac OS to lesser extents.
Note that I don't remember being able to change the tab lengths, they were fixed. But a later release allowed sliding the position of the tab, so that windows could be stacked, and flipped between like folders in a filing cabinet. This functionality is now present in many preference dialog boxes on other GUIs when there are too many selections to fit on one screen.
The only BeOS interface shortcoming I recall, at least compared to Windows, was that keyboard shortcuts weren't pervasive and standard enough. The GUI depended more on the mouse than it needed to. Of course it was better than the Mac, without a mouse your Mac is dead in the water! But Windows was very irregular and inconsistent, with too many exceptions.
One notable problem that Windows had, was with Ctrl versus Alt shortcuts. Ctrl-C was long established as Break on Windows and Unices. Shift Insert and Shift delete were deemed inferior to the Macintosh's simple and handy OpenApple-Z/X/C/V convention, so Windows 95 adopted that behaivor. Unfortunately for everybody, they decided to use Ctrl instead of Alt to implement these functions, which not only was inconsistent with how the Mac Operated (they had their own control key, but use the apple specific modifer. Mac's didn't have Alt, so Windows should have used Alt as the specific Modifier. The WindowsFlag Modifer didn't appear until later.) but it also was inconsistent with itself, and it broke Ctrl-C for DOS/Windows and Unix/POSIX.
Now BeOS initially routed around that damage, and properly used Alt instead of Ctrl. They also used Windows style Alt-Tab for task switching, which was good, becuase it respected a convention of Alt for window related functionality, and Ctrl for console related functionality. Then when BeOS was released for Intel PCs, too many people had muscle-memory issues from Windows' Ctrl-C mean copy, that they couldn't easily relearn to use Alt-C means copy. Unfortunately, instead of allowing Ctrl-C to be remapped for the BeOS GUI, they only offered an outright swap of the Alt and Ctrl keys, which only served to perpetuate the braindamage started by a poor Windows 95 GUI decision.
So in summary, BeOS has some issues with Keyboard shortcuts in the GUI, but this was hardly notable... only Windows hada robust Keyboard to GUI mapping, and even they were plagued by a few surprisingly poor decisions, mainly based around not respecting their own conventions. I could go on about this, about how Win NT had an almost Universal sequence of Ctrl-Alt-Del, Alt-S, S, Enter - should work almost universally to shut down the system safely without needing to see the screen output. But then they introduced Sytem policy pop-up that borked it. To finish up back on topic, the BeOS GUI was notable, but like a few other parts of it, it was notable for being ahead of it's time, and better than what was available from competetive setups.
Right now, as much as I like Epiphany on Gnome better than anything available on Windows or Mac OS classic OR X 10.2 (I han't had enough experience yet to fairly rule out Mac OS X Tiger), I still long for Multithreaded and lightweight NetPositive burning through BeOS, with Monsterzilla waiting to handle any javaScript dependencies I come across. While NetPositive was positively deficient compared to other browsers of its time, it was also superlight and highly responsive.
Dillo doesn't come close. If it did, then I would use it, with epiphany as my backup, and then curse at it for crashing and losing all the sites I'm browsing. Even when Netpositive crashed, It wouldn't die... I would push the error dialog to the side, and finish up with my other broswer windows, before returning to acknowlege the crashed browser window at my convenience. Unix seems to be to happy to kill it's processes out from under you, which is great for a batch processing behind the scenes server that needs to protect it's data from corruption, but terrible for a GUI Browser that needs to be responsive and interactive.
The BeOS browsing experience was without match, and it's a damned shame that Haiku OS doesn't have access to NetPositive, because then I would be a happy browser right now. I might even be temped to tackle that beast monsterzilla and see if pieces of gecko could somehow be shimmed into the NetPositive framework. Sure, BeOS didn't handle Java Applets. On Windows, Firefox Doesn't handle ActiveX or BasicScript, which sucks when you really need, but most of the time that's a feature. Well I was Java and Javascript on NetPositive the same way, becuase when Windows is running without abundant RAM, it is ususally Java that kills the system, and I'd usually rather it was just ignored.
Okay, enough delerious posting in the wee hours of 4AM for now. Maybe I'll come back to this at a saner hour, and see if I can distill this down a bit. Because it is important for posterity that the BeOS GUI and all of its advancement, isn't dismissed an "not even having third party hacks that change the color from yellow". Damnit, even Mac OS X wanted a bright primary "candy" coloring after jealously beeing the Brilliant Yellowjacket hue of the Be in all of it's glory! Castlan 09:47, 10 December 2005 (UTC)