|
|
|
|
|
by diskzero
359 days ago
|
|
Former Be employee here who ended up at Apple eventually. BeOS was way, way behind NeXTStep in so many ways. We also had fragile base class problems and had a lot of kernel issues. BeFS was cool but Dominic ended up at Apple (and is still there) so I feel Apple got generations of BeFS evolution. Jean Louis wanted an unrealistic price and Apple spent the smartest 400 million dollars that I can think of by buying NeXT. Apple got Steve, Avie, Bertrand and so many others. Many Be people ended up on board after journeys with Eazel and others. Some never made it to Apple due to their Danger/Android/Google paths. This saddens me even to this day. |
|
The "database file system" was just a regular file system with a somewhat crude indexing system for xattrs. By crude I mean it was up to apps to manage indexes, i.e. it wasn't really useful as a cooperative scheme to help apps work together. Files that had an xattr before an index was created wouldn't be incorporated into a newly created index, so in practice it was only useful to help an app find its own data quicker assuming it stored each data item only in individual files. If you connected a storage device and labelled a file with an xattr, it just wouldn't show up in indexes at all unless an app had created an index on that device first. People hear "database file system" and assume it had similar features to an RDBMS but it didn't. And of course it suffered the conceptual problems that kill off most attempts to extend the FS into a DB; users don't want to interact with their data via a one-size-fits-all file explorer filled with confusing things like tree widgets, and devs don't want to end up exposing a pseudo-API to other apps for technical or business reasons.
The BeOS API had wider design issues too. C++ was one, as you note. Microsoft invented COM and NeXT invented Objective-C to dodge that. But the heavy use of multi-threading was another. People can't handle that even today, and they were doing this in 1995! It led to slick demoware but, as an HN commenter said last time, you could "deadlock the entire system". That was a Win3.1/MacOS Classic level design issue, but BeOS was targeting NT level hardware. When Be engineers went to Android and built a Be-inspired API, the first thing they did was tone down the multithreading and dump C++. The OS was less responsive but more stable and easier to program.