Applying BeOS lessons to MacOS X?

[eirik]

As many of you have no doubt read, Apple hired Dominic Giampaolo. Dominic is said to be a primary author behind BeOS. BeOS, a POSIX compliant Unix variant, achieved incredible performance by optimizing the OS code from the highest levels down to the lowest levels, maximizing multithreading at every opportunity.

BeOS also implemented a filing system that featured a metadata construct far superior to virtually every OS around. So tightly integrated into the OS, the metadata construct enabled BeOS's journalling, which offers additional performance increases as well as enhanced usability and extensibility. Journalling was a subject in a recent thread under Current/Apple Inc.

I haven't played with BeOS. But after reading about it this weekend, I am very intrigued. Practically speaking, BeOS is dead!

MacOS X is hardly known as a super fast OS. Its current metadata construct, which includes file extension text in the file name, is an unfortunate set-up. And, its application binding screams for some enhancement.

So, I'm opening this thread in hopes that some of you brilliant, knowledgeable folks can enlighten the rest of us as to how Apple could and might apply some of the same 'advances' that BeOS did. Said another way, how can Apple apply some of the BeOS accomplishments within the NextOS/Darwin code base? Are there some things from the BeOS that Apple can never employ, why? What do you suppose we might see in the way of a timeline for implementing some the BeOS improvements? Why is MacOS X so much slower than BeOS? What can Dominic do for MacOS X as an Apple employee?

Thanks,

Eirik

 

[alex_ant]

Re: Applying BeOS lessons to MacOS X?

Originally posted by eirik
BeOS also implemented a filing system that featured a metadata construct far superior to virtually every OS around. So tightly integrated into the OS, the metadata construct enabled BeOS's journalling, which offers additional performance increases as well as enhanced usability and extensibility.

Sorry to nitpick, but the BeFS's journalling implementation has nothing to do with metadata. And the journalling itself did not really affect performance in any positive way. But anyway, I do agree that the BeFS was rocking. Best desktop filesystem ever by far, hands down, no arguments.

I haven't played with BeOS. But after reading about it this weekend, I am very intrigued.

Go download a copy of the personal edition then! What are you waiting for!!! Anyone who has ever used OS X on a dual-1GHz Power Mac AND used BeOS on a 300MHz Celeron has probably looked at what they spent on the Mac and broken down in tears. Well, maybe not any Mac zealots...

So, I'm opening this thread in hopes that some of you brilliant, knowledgeable folks

That's me!

Are there some things from the BeOS that Apple can never employ, why?

Never say never, but if Apple wants to replace the HFS+ filesystem, they will need to do two things: 1) acquire/develop the filesystem with which they intend to replace HFS+, and 2) develop an OS 9 compatibility layer, which would require an update of OS 9, so that Classic apps are compatible with this new fs, resource forks and all. Apple is going to have to replace HFS+ sooner or later, but I would wager that they'd rather opt for doing it later, just because they have more urgent things to do right now. (At the moment, bug fixes and new features.)

Also, I don't believe OS X will ever be able to match the speed of BeOS. Well, I should say it will never be more efficient; BeOS will always be faster clock-for-clock. BeOS was just so finely tuned and highly optimized it's not even funny. Aiming to be faster than BeOS is like aiming to be a better guitarist than Eric Clapton. You can work on your guitar skills for 6 hours per day for the next three decades, and who knows, you might just get there.

As well, OS X will certainly never, ever be able to manage the memory usage of BeOS. The 300MHz Celeron I mentioned running BeOS is able to, with 128MB of RAM, run circles around the dual 1GHz Mac with 1GB of RAM in everyday desktop use. No joke. I realize that RAM is very cheap these days, but a program that uses 32MB of RAM will inevitably be slower than a similarly-written program that uses 16MB.

What do you suppose we might see in the way of a timeline for implementing some the BeOS improvements?

Supposing Apple does implement any of BeOS's technologies/ideas, who knows. The only thing of BeOS's that I think OS X would really benefit from would be the BeFS. This gets into the whole idea of filesystem metadata and how it can be successfully implemented and utilized. Metadata will be, I believe, the first line on BeOS's epitaph. Now we're hearing that Windows will be going in this direction. Apple will want to, as well. They've already got a nice proof of concept in the form of iTunes' song index. It would take a long time and a lot of work (including a change of filesystem) for an OS X metadata concept to be both implemented AND widely exploited, but it is something for Apple to think about.

Why is MacOS X so much slower than BeOS?

You'll get a lot of different answers to this one, from "it's the display layer" to "I don't know" to, seeing as how this is a forum frequented mostly by Mac users, "its not you idiot, osx is faster on my 300mhz imac than beos is on my friend's 1ghz athalon and you sir are a moron!!!111" My opinion is that OS X is much slower than BeOS because Apple was concerned simply with getting it out the door. My reasoning for this opinion is:

- It takes A LOT of work to engineer an entire modern desktop operating system. Apple had the advantage of some very solid foundations in OpenStep and FreeBSD, but they also developed quite a bit from scratch. The entire display layer (I think?), the Blue Box (Classic), Carbon, support for a wide array of modern Mac hardware... It's quite remarkable that such a troubled (at the time) company was able to pull off such a feat of successfully rolling out a state-of-the-art desktop OS that retained full compatibility, either via Carbon or via Classic, with most existing Mac software. It took less than four years from their purchase of NeXT for Apple roll out the public beta, and there is no way that they weren't busting their asses from the date of acquisition until the early morning before the beta's release. When you're working that frantically, simply getting everything working right is much more important than speed.

- OS X's compilers all suck. GCC is great for standards compliance and "freedom" etc., but when all is said and done, it's not a great performer even on its primary platform (x86). It's much, much, worse on PPC. Apple and Motorola have contributed a few improvements to it, which have helped, but it's still a poor compiler as far as code optimization (including memory usage optimization!) are concerned. What do you expect from a bunch of dirty hippies working for free! (Joke.)

- Quartz, the display layer, is doing quite a bit. Window drop shadows, elaborate animation, real-time alpha blending, etc. This could account for some of the slow graphics rendering (e.g. window resizing) evident in OS X, but the fact that many non-graphical operations are still slow is reason enough to discount Quartz as being solely responsible for OS X's doggedness.

- Slow filesystem. HFS+ is Apple's FAT32. An add-on to an add-on to a filesystem that, truth be told, wasn't so great in the first place.

I'm sure this list could be made longer.

What can Dominic do for MacOS X as an Apple employee?

Well, I doubt he was hired to write OS X Quickcam drivers...

Alex

 

[b8rtm8nn]

Yep, filesystem is a big one, Quartz is another big one. Of course, BeOS looked nothing like Aqua, it has kind of a cute. dopey look to it, like OS9. BeOS also had some crappy networking, lack of true multiuser support and some other really annoying thing that I can't remember now, hmmm...


Anyways, it was built from scratch and it would have slowed down once the overhead was built in to make it a "corporate" machine; even after all that, it still would be faster than OSX will ever be. But after OSX is put on a new filesystem (I'm betting version 11 will have that in Jan 2004), and the threading is modified, a lot of system transactions will increase efficiency. They hired two other Unix kernal gurus last year, so things should improve quite a bit.

But go get BeOS, that is why I use OSX; and you will learn how to use the *nix shell in Be which really help you become comfortable when you want to hack OSX.

 

[sparkleytone]

pervasive multithreading down to the absolute lowest levels of code. if they could achieve this on OS X, it would be SO ridiculously fast. Be patient, Apple is going the right direction. They made the core OS, as buggy as it was at first, and simultaneously gave developers a great environment and began to develop their killer apps for it. Functionality, first party software, third party support, then optimization. All in due time. There are reasons BeOS failed besides being strongarmed by Bill Gates (directly) and Steve Jobs (indirectly). One of them is that although it was ridiculously fast, it was full of gaping holes. People like me can appreciate the speed, but won't switch unless it can provide stability and reliance. Apparently the networking stack was extremely beta and was never really made to completion. That's a HUGE part of a modern OS.


P.S. People Like Me = extremely demanding users.

 

[blakespot]

Re: Re: Applying BeOS lessons to MacOS X?

You'll get a lot of different answers to this one, from "it's the display layer" to "I don't know" to, seeing as how this is a forum frequented mostly by Mac users, "its not you idiot, osx is faster on my 300mhz imac than beos is on my friend's 1ghz athalon and you sir are a moron!!!111" My opinion is that OS X is much slower than BeOS because Apple was concerned simply with getting it out the door. My reasoning for this opinion is:

- It takes A LOT of work to engineer an entire modern desktop operating system. Apple had the advantage of some very solid foundations in OpenStep and FreeBSD, but they also developed quite a bit from scratch. The entire display layer (I think?), the Blue Box (Classic), Carbon, support for a wide array of modern Mac hardware... It's quite remarkable that such a troubled (at the time) company was able to pull off such a feat of successfully rolling out a state-of-the-art desktop OS that retained full compatibility, either via Carbon or via Classic, with most existing Mac software. It took less than four years from their purchase of NeXT for Apple roll out the public beta, and there is no way that they weren't busting their asses from the date of acquisition until the early morning before the beta's release. When you're working that frantically, simply getting everything working right is much more important than speed.

- OS X's compilers all suck. GCC is great for standards compliance and "freedom" etc., but when all is said and done, it's not a great performer even on its primary platform (x86). It's much, much, worse on PPC. Apple and Motorola have contributed a few improvements to it, which have helped, but it's still a poor compiler as far as code optimization (including memory usage optimization!) are concerned. What do you expect from a bunch of dirty hippies working for free! (Joke.)

- Quartz, the display layer, is doing quite a bit. Window drop shadows, elaborate animation, real-time alpha blending, etc. This could account for some of the slow graphics rendering (e.g. window resizing) evident in OS X, but the fact that many non-graphical operations are still slow is reason enough to discount Quartz as being solely responsible for OS X's doggedness.

- Slow filesystem. HFS+ is Apple's FAT32. An add-on to an add-on to a filesystem that, truth be told, wasn't so great in the first place.

I'm sure this list could be made longer.

Classic and Aqua are slow elements of OS X. The core OS itself, Darwin, is not slow. Apple did not just put OS X together out of nowhere--it was born in 1988 as NEXTSTEP and has evolved over the past 13 years. Aqua is basically new, a layer that gets its roots from NeXT's innovative Display PostScript.

We hope Apple will speed up Aqua and the speed of Classic is not so relevant down the road---but I think the distinction should be made that the "sluggish" feel of OS X is not due to the meat and potatos of the OS it self.

And as for HFS+'s slowness...UFS is not appreciably faster with OS X.


blakespot

 

[alex_ant]

Re: Re: Re: Applying BeOS lessons to MacOS X?

Originally posted by blakespot
Classic and Aqua are slow elements of OS X. The core OS itself, Darwin, is not slow. Apple did not just put OS X together out of nowhere--it was born in 1988 as NEXTSTEP and has evolved over the past 13 years. Aqua is basically new, a layer that gets its roots from NeXT's innovative Display PostScript.

I think you're using the word "Aqua" when you should be using the word "Quartz." Aqua is just a theme. And no, Darwin itself is not slow, but it's hardly a speed demon either, which is not something I've tested first-hand but something I am hypothesizing based on the compiler issue I mentioned. The speed of Darwin itself is of little importance anyway when few if any people use a standalone Darwin on their Macs. I realize that OpenStep, formerly, Nextstep is one of OS X's ancestors, but from the time Apple bought NeXT in 1997 to the time Apple shipped the OS X public beta in 2000, there was a great amount of work done. Just look at the difference between the initial release of OS X Server in 1999 and the public beta in 2000.

And as for HFS+'s slowness...UFS is not appreciably faster with OS X.

The fact that UFS is also slow is not an excuse. I'm willing to bet that the only reason UFS is even an option in OS X is to preserve POSIX-compatibility for those who need it - not to provide an alternative for those who need mega fs performance. UFS was OpenStep's default filesystem, and most of the BSDs use different variations of it. It's good and solid and proven, but it's also what, 15 years old? It's not gonna be winning any performance benchmarks against BeFS, or even XFS orReiserFS, anytime soon. Right now OS X is lacking in the area of a decent, modern filesystem, and sooner or later they will have to make the big changeover. Even Microsoft had to, and they're not a company known for pioneering innovation.

Alex

 

[alex_ant]

Originally posted by sparkleytone
pervasive multithreading down to the absolute lowest levels of code. if they could achieve this on OS X, it would be SO ridiculously fast.

Of course! I guess I forgot to mention this because I don't have a dual-processor machine to make BeOS really shine. Right on man, BeOS also had excellent multiprocessor support. As I remember it, it was one of the guiding principles of the BeBox - why have one very fast, very expensive CPU when you can have two moderately fast CPUs for less money? A brilliant idea of course, and made possible entirely by their multithreading model - the only reason it hasn't caught on elsewhere is because nobody else has yet been able to accomplish (or at least, nobody has tried to accomplish) what Be has.

Alex

 

[sparkleytone]

alex i think you misunderstood me, or maybe my understanding is hazy. My understanding of what multiTHREADING does is allow different processes to share a processors resources, whether there is one or 20. Most OS's up until lately have been of a different model, that break up the processes at the kernel level and send them in a line to the processor, which will then give all its resources one at a time. (a good analogy is serial) what multithreading does is take advantage of the latest processors' ability to handle more than one task, and sending multiple "chunks" of data at the processor all at once. (a semi-good analogy is parallel) therefore we could all benefit from this. symmetric multiprocessing is the name for multiprocessor configs being able to achieve a higher level of performance.

 

[sparkleytone]

"...On a system that is not multithreaded, only one thread of execution runs at a time. DOS, for instance, was single-threaded, only capable of executing one 16-bit program at a time. BeOS is multithreaded, meaning that it can execute more than one thread at a time. In BeOS, one or more threads comprise a program.

BeOS also goes things a step further and insures that every program runs in a multithreaded fashion. The programmer does not have to automatically account for the spawning of new threads within a process (although it certainly doesn't hurt). This is called pervasive multithreading."


From This Web Page <-- Click me.

 

[mischief]

You ARE the weakest link............

Avi Trevinian has been the defacto weakest link in OS X from the beginning.

Perhaps he will be superceded by Dom?

(Darwin+BeOS)-Quartz=?

 

[lance]

Threading vs. multiprocessing

Alex-

What you are referring to has more to do with multiprocessing then with multithreading. Yes, in modern OSs multithreading leads to multiprocessing on multiprocessor machines, but you do not need multiple processors to get a benefit from multiple threads. One of the reasons why the BeOS (and any OS that uses threads so pervasively) shows such great performance is due more to PERCEIVED performance then ACTUAL performance. For example, assume that the Mac OS X Finder works as it does now. When you empty trash, the performance of the Finder dips. You may even see that damn spinning beach ball for a second. You could assume incorrectly that the OS is just that slow that it takes a second or two to delete N files. In BeOS, you may not see the performance dip at all. Does this mean that the BeOS is faster at deleting those same N files? No, it just means that the BeOS "finder" is just better at multithreading. The fact is if every piece of software provided by Apple would be fully multithreaded, then Mac OS X would probably feel like a speed daemon. At this point, almost everything is blocking everything else. Quartz may be doing a lot of work, but even on my old PMac 8500<1> with 96 MB of memory, Quartz/Aqua show the same performance as my Rev 2 Ti (550 MHz G4). Obviously I find myself waiting and waiting for everything else, but drop shadows, buffered windows, etc are just as fast between the two very different computers.

Anyway, in my humble opinion, Apple could go a long long long way to making a "faster feeling" OS if they would spend more of their time focusing on making sure that every aspect of the OS is fully multithreaded. Mach is already multithreaded...so now let's make sure the rest of the OS is as well. It would be nice if they could somehow limit the bloat of this new OS as well. I love OS X, but needing 128, 256, or even 512 MB of memory is ridiculous no matter how cheap RAM is.

-Lance


<1> I have a hacked kernel that allows me to run OS X on a G3 upgraded 8500 which was released in the mid 90's. Nothing is changed with the display properties of the OS, only a couple lines in the kernel.

 

[alex_ant]

Originally posted by sparkleytone
alex i think you misunderstood me, or maybe my understanding is hazy. My understanding of what multiTHREADING does is allow different processes to share a processors resources, whether there is one or 20. Most OS's up until lately have been of a different model, that break up the processes at the kernel level and send them in a line to the processor, which will then give all its resources one at a time. (a good analogy is serial) what multithreading does is take advantage of the latest processors' ability to handle more than one task, and sending multiple "chunks" of data at the processor all at once. (a semi-good analogy is parallel) therefore we could all benefit from this. symmetric multiprocessing is the name for multiprocessor configs being able to achieve a higher level of performance.

Right, I understood you. I only brought up the point of multiprocessing because I felt that this was the area where such pervasive multithreading really shined even moreso than on a single processor, compared to all the other kludgey multiprocessing implementations.

Alex

 

[oddfuzz]

BeOS buyout?

This may be a dumb question, so please forgive my "newbiness", but from what i've read in this thread, BeOS sounds like a pretty amazing OS and i was just wondering if it would have been a possibility for apple to, instead of NeXT, purchasing BeOS?

would it have been possible for apple to use it for mac osx?

it just seems like a shame to see such a speedy OS end like it did.

 

[eirik]

Re: BeOS buyout?

Originally posted by oddfuzz
This may be a dumb question, so please forgive my "newbiness", but from what i've read in this thread, BeOS sounds like a pretty amazing OS and i was just wondering if it would have been a possibility for apple to, instead of NeXT, purchasing BeOS?

would it have been possible for apple to use it for mac osx?

it just seems like a shame to see such a speedy OS end like it did.

Not a dumb question at all. That people still discuss BeOS relative to NextOS illustrates the great controvercy over Apple's choice back in 1997. The choice between the two for Apple was evidently an exercise in trade-offs. While BeOS is vastly superior to NextOS in a few ways, the overall benefits of NextOS (and Steve Jobs) were evidently greater. This thread is about how can we maximize the best of both worlds.

Here is an article about this decision with other references that I haven't read yet.

Why BeOS Lost

It looks like good reading (those other references).

Cheers,

Eirik

 

[oddfuzz]

Thanks for the article.

Thanks for the article. Being at the ripe age of 13 back in '97, I guess I just needed a history lesson.

 

[Beej]

These threads really show who knows the insides of their computers well! I'm almost finished my computer science degree and I can't follow this stuff. You'd hate to try and read it if you were normal dave from off the street...

Sorry to interrupt. I'll leave you guys to it

 

[b8rtm8nn]

It's not that bad Beej, but the CS education you receive in college is usually lacking in some areas, I know my minor(which I didn't get because I dropped a class I was flunking) didn't help me at all.

I learned an immense amount when I was using Be because you were forced to modify some configurations using the terminal or trying to swap variables in some file like a monkey banging on a keyboard.

So if you want to learn, download Be or Linux or Darwin and start experimenting - but have a goal first. If you want to learn the low level crap, install an unsupported piece of software and try to build a stable driver for it based on a generic example. You'll learn more in two weeks than in two semesters of CS, but you'll be glad you have the background.

 

[blakespot]

Originally posted by sparkleytone
alex i think you misunderstood me, or maybe my understanding is hazy. My understanding of what multiTHREADING does is allow different processes to share a processors resources, whether there is one or 20. Most OS's up until lately have been of a different model, that break up the processes at the kernel level and send them in a line to the processor, which will then give all its resources one at a time. (a good analogy is serial) what multithreading does is take advantage of the latest processors' ability to handle more than one task, and sending multiple "chunks" of data at the processor all at once. (a semi-good analogy is parallel) therefore we could all benefit from this. symmetric multiprocessing is the name for multiprocessor configs being able to achieve a higher level of performance.

Indeed, multithreading is an enabler for high performance under SMP, but also on a single CPU there are serious advantages to multithreading. This was one of the advantages of Windows 95 over Win 3.1---one of many, but true multithreading arrived with 95. When 95 was on the shelves, the Linux kernel was incapable of multithreadng--a weapon used by Windows devotees in arguments I'd witness on IRC. I am not sure when mt arrived on the Linux kernel.


blakespot

 

[blakespot]

Re: You ARE the weakest link............

Originally posted by mischief
Avi Trevinian has been the defacto weakest link in OS X from the beginning.

Perhaps he will be superceded by Dom?

(Darwin+BeOS)-Quartz=?

Those seem like overly strong words. Tevanian was the driving force behind NEXTSTEP. Yes, time moves on, but lots of what OS X "is" was pushed by him. His contributions have been, I would say, certainly positive in nature overall. Tevanian was one of the developers of Mach, a component of NEXTSTEP and OS X that I've always been quite impressed with.


blakespot

 

[blakespot]

Re: BeOS buyout?

Originally posted by oddfuzz
This may be a dumb question, so please forgive my "newbiness", but from what i've read in this thread, BeOS sounds like a pretty amazing OS and i was just wondering if it would have been a possibility for apple to, instead of NeXT, purchasing BeOS?

would it have been possible for apple to use it for mac osx?

it just seems like a shame to see such a speedy OS end like it did.

Amelio, then Apple CEO, contacted Jobs and asked his opinion of Apple's idea of purchasing Be and using it's OS as the basis for the future of the MacOS. Jobs told him to forget about that, as this would make MacOS just another proprietary OS (which it would have--despite it's being POSIX compliant, BeOS is not Unix, which NEXTSTEP "really" is). He told Amelio Apple needed to go with NEXTSTEP, and that's the way it played out.


blakespot

 

[eirik]

Will the True Unix please stand up?

Originally posted by blakespot

would make MacOS just another proprietary OS (which it would have--despite it's being POSIX compliant, BeOS is not Unix, which NEXTSTEP "really" is). blakespot

I've read this point elsewhere several times about BeOS not being a true Unix but I haven't seen anything specific about why it is not a true Unix. I thought being POSIX compliant was a rather rigorous hurdle to clear to be considered a full-fledged member of the Unix family.

The only thing that I know of about BeOS not being 'fully Unix' was that it was a single-user OS, something not too difficult to overcome.

As I recall, there was some controvercy over whether or not Apple should work to make MacOS X POSIX compliant. I don't know whether Apple has done so or not. Please help me better understand.

Thanks,

Eirik

 

[sparkleytone]

even Windows is POSIX compliant...it has to be. They get alot of money from the gov't for WINNT WIN2k etc. A requirement is POSIX compliance. Darwin is an actual, "real" unix that is based on SystemV i believe. The philosophy of its underpinnings and the core of what makes it work are UNIX through and through. Altho i say its UNIX, the argument is really whether UNIX can be defined, because there are so many different types, with different file structures and support.

 

[lance]

Mac OS X/Darwin is BSD derived

Originally posted by sparkleytone
even Windows is POSIX compliant...it has to be. They get alot of money from the gov't for WINNT WIN2k etc. A requirement is POSIX compliance. Darwin is an actual, "real" unix that is based on SystemV i believe. The philosophy of its underpinnings and the core of what makes it work are UNIX through and through. Altho i say its UNIX, the argument is really whether UNIX can be defined, because there are so many different types, with different file structures and support.

Actually, System V came from the AT&T/Novel side of things.

If I can toot my own horn a bit, take a look at this link:

<A HREF="http://www.applelust.com/alust/terminal/archives/terminal020301.shtml">Applelust Article</A>

In the 70's and 80's Berkley began producing thier own breed of UNIX based largely on the code from AT&T. Then, as the 80's turned into the 90's, BSDI (the company that marketed BSD) was forced to complete the transformation that had begun a few years before: the complete rewrite of BSD UNIX to not include any AT&T then Novel code. 4.4BSD was the result and this is the BSD that all other BSDs (FreeBSD, NetBSD, OpenBSD, BSDI, Darwin, etc) needed to sync with in order to be totally free of AT&T code (though some files did need to note some AT&T references).

Hope that clears things up a little.

-Lance

 

[lance]

Applelust Link

Let's try that again, the link for my article is:

http://www.applelust.com/alust/terminal/archives/terminal020301.shtml

 

[Taft]

Re: Applying BeOS lessons to MacOS X?

Originally posted by eirik
And, its application binding screams for some enhancement.

What are you refering to exactly when you say 'application binding'? .app bundles? Late-binding of objects with Obj-C? Could you clarify?

Matthew