Hacker News Reader

Comment by honkhonkpants | Hacker News Reader

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.

View on HN

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.

We have all that and more in macos today and have for many years. Spotlight is implemented by the same person who wrote BeFS.

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.

Spotlight is amazing, I use it everyday. It is VERY fast.

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?

It's a perfectly good launcher, for one thing. Having it right under my fingers (cmd+space) means I almost always use Spotlight to launch apps.

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

Ars Technica also has a nice 2010 article: http://arstechnica.com/information-technology/2010/06/the-be...

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.

Yeah, Dominic Giampaolo. He works at Apple now and is heading its new file system efforts.

For years I though he was secretly writing a BeFS like replacement to HFS.

APFS seems less ambitious however.

Good points, though hard disk sizes are orders of magnitude bigger than they were in the day of BeOS.

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.

and it wasn't to _Be_

Network stacks and web browsers are easier to improve incrementally than more fundamental parts of the OS.

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.

Why is he being downvoted?

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.

Browser engines like WebKit are (with some work) portable to any platform with a C++ compiler: that's how the current Haiku browser is built.

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.

Now that's pretty cool. Appreciate the tip.

> So, now you just need to build a highly-optimizing, C++ compiler instead of a browser?

No. You just use gcc. Like everyone else.

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.

You only need to implement the window system and widget rendering glue. The layout, javascript, CSS, DOM, history, etc is all platform independent.

But implementing `drawButton()`, `blitToScreen()` and similar is in no way similar to implementing a C++ compiler, as you implied.

An example of a port is here, in this directory: https://trac.webkit.org/browser/trunk/Source/WebCore/platfor...

Sounds a lot better than I thought. Appreciate the explanation. :)

I ran firefox on BeOS.

Im curious how it ran. Was there a performance boost from BeOS architecture?

Not noticeably. It just rendered better than the built in browser..

I prefer clang.

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.

Software modems, you mean. Real modems are attached to serial ports and don't require drivers :-)

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.

WinModems were a way to save money, plain and simple. Even Apple had their GeoPort software modem, and they sure didn't need any more lock-in.

That was the other thing people told me. I was never sure which was most accurate reason.

That was one of the key events in my life that convinced me of free software ideals.

The web-first approach of the entire global software industry is half-baked.

Reply on news.ycombinator.com