Well let's don't get all romantic about something that was, in the end, half-baked. BeOS debuted at the dawn of the web, and it had a barely-working, userspace network stack and a web browser that essentially didn't work at all.
It had some novel APIs, a nifty filesystem, and made for a damn good demo, but there wasn't much more to it.
The filesystem metadata queries were real-time back when spinning disks were much slower and neither the processing power or ram was comparable to what we have today. With today's machines we do not have the same experience under Windows, macos, GNOME, KDE. Feature-wise yes, performance no. Is there a technical reason we couldn't have the same filesystem integration? No, there isn't, it's just incompatible priorities and half-baked 2nd system syndrome in effect and repeated all the time.
BeOS did it by writing their own filesystem. The filesystem author wrote a good book about the design and implementation, including overviews of other filesystems (eg NTFS). He has made the book available for free download at http://www.nobius.org/~dbg/practical-file-system-design.pdf
The way it implemented the queries well was because they were integrated into the filesystem. Windows/Mac/Linux do it in userspace. Doing it in the filesystem would be considered a layering violation by most.
Layer violations are fine if they give you value. ZFS is very layer "violating" as well. However, the layers are concepts put in place by humans to help, not God given laws of nature.
Agreed, and if you run on a microkernel, then pretty much everything is in userspace and any boundaries are those of, say, a capability system for security purposes. I still cannot wrap my head around the fact that we're adding ways to avoid the kernel network stack and other exceptions to the rule, while ignoring microkernels as the sorely needed feature for mainstream computing it is.
The last time I used Spotlight (no mac at the moment), it was so slow that I had to disable it globally. The metadata integration in BeOS was different. For example media and email storage in BeOS.
I feel like I'm missing out. I occasionally use it to search for images in web applications I'm working on, and that's about it. What else is it good for that i could be doing?
The network stack was totally rewritten and optimized, in kernel mode, about halfway through the BeOS lifetime.
The kernel did a better job at heavy threading and SMP than Linux or NT or NextStep at the time.
The interrupt model and thus latencies led to much better soft real time performance than the other OSes at the time.
I think it was more than half baked, but Linux took over the enthusiast market (with zero dollar cost) and Microsoft asserted their OEM monopoly (as determined in court, way too late to matter) and it wasn't to be.
I'm not so sure. When you implement your own OS your hands are mostly free. With browser on the other hand, you have to comply to large, complex and evolving standards (HTML/CSS/Javascript). I might be biased by the fact that I dabbled a bit with the Linux kernel and dislike graphics programming, though.
So, now you just need to build a highly-optimizing, C++ compiler instead of a browser? That's another project that few got right over a period of a decade or so. Of course, one could use a C++ to C compiler or extend existing C++ compiler with OS-specific backend. Might still be plenty work but easier than clean-slate browser.
Both gcc and clang have flags to emit raw object files. At which point, your porting work really centers around making sure you have a good standard library in place, and that your kernel has a reasonable implementation of parsing a binary format like ELF or PE, etc.
The gist of the comment was whether GCC automatically made something like WebKit + JIT + Native Client work on very, different OS by a simple compile. I doubted that was true or that the work was easy.
That's true. Take the Redox project that's been moving along nicely. Or Haiku, Syllable, MenuetOS, etc. All of them had small teams with external vontributors that got plenty done in terms of a usable OS.
Whereas, a fast, standardized browser like Firefox takes a huge company to support it. The complexity is just huge. Plus, the standards and web experience are always moving along. Can't wait for more people to scratch an itch if you want to stay competitive.
the network stack is the reason i never got into it; it didn't work on my machine at the time and i wasn't about to buy a new network card just to experiment with beos.
That is what kept me out of Linux when I was a teenager, but it was MODEM drivers at that time. Lack of driver support for an operating system is not a technical problem, it is a social problem.
Essentially, it doesn't matter what mechanism generates the signals except when it came down to me wanting to play with Linux twenty years ago and a company decided to release a product that was only compatible with a single operating system. My desire to play with Linux did not happen to be worth as much as it would have cost to do so at the time, so I waited.
It does. The soft modens were partly a lockin technique to decrease odds you'd be able to use something like Linux without buying new hardware. The strategy apparently worked. It's why I push for standards-compliant hardware that requires no funny business to use in new ways.
It had some novel APIs, a nifty filesystem, and made for a damn good demo, but there wasn't much more to it.