[danengel]

Why didn't Apple put every effort into making a great Finder? For many Mac users, Finder = OS = Mac. Safari and iTunes are so good, why did the Finder suck for 2+ years?

[Adam Betts]

Maybe they're working on a rewrite of Finder and they're not finished so they synced some of the changes to Finder 10.3.

They have to be because Finder 10.3 is still not multi-threaded

[Millennium]

The Finder's problems can be pretty much pinned on political issues with Apple. The problem comes from the fact that the Finder was totally scrapped and rewritten from scratch between DP2 and DP3, and did not have enough time for the code to mature before it was released.

Earlier versions of OSX had a working Finder. It was written in Cocoa. This does not make it inherently better than a Carbon-based finder; it was merely a fact that one existed and one did not. In fact, at this point, Carbon did not yet exist.

However, in the early days of Rhapsody -later to evolve into OSX- developers resisted Cocoa. They were not looking forward to rewriting large portions of their applications, just to make the apps run on an OS which, for quite some time, would hold a minority installed base within a minority installed base. It is rumored that some large developers, such as Adobe, threatened to pack up and leave unless Apple were to come up with a path for upgrading code.

Apple's response was to come up with a compatibility API, which it called Carbon (whether or not Carbon is "just a compatibility API" now, it was advertised as such back then). But developers were skeptical. They weren't sure that Apple had put enough effort into this new API to ensure that apps would work well. And to be fair, Apple really hadn't put in the effort at that point, as the early Carbon apps would show.

This put Apple in a bind. They needed an app of their own which used Carbon extensively, to prove to developers that Carbon would actually be a viable API. There were two apps which they could have used to do this: AppleWorks and the Finder. Either take an existing app and improve it (AppleWorks), or start over from scratch and write an app from the ground up in Carbon (Finder).

Much to many people's later sorrow, they chose the latter approach. Not only that, but they chose to write this new Finder using PowerPlant, Metrowerks' application framework, layered on top of Carbon. Nothing wrong with that in and of itself, except that PowerPlant was still extremely early in its Carbonization; it wasn't even finished yet by the time Apple released 10.0.

So in essence, through the first several versions of the Finder, it was immature technology (Finder 10.0), built on immature technology (PowerPlant, at that time) which was itself built on immature technology (Carbon, at that time). That's a recipe for disaster if ever I've heard of one. Had they chosen to use AppleWorks as their dogfood app instead, the Finder could have continued along its existing code base while AppleWorks was further improved, resulting in two good apps versus one pretty bad app (Finder) and an app so bad that they invented the term Bad Carbon Port specifically to describe it (AppleWorks).

But what's done is done. The Finder in 10.3 doesn't suck, but not not because it's Cocoa (it probably isn't Cocoa anyway). It doesn't suck, because it's finally using a mature codebase. That's more important than many people realize.

[danengel]

The Finder's problems can be pretty much pinned on political issues with Apple.
[snip]

Cool, thanks for this great answer!

Either take an existing app and improve it (AppleWorks), or start over from scratch and write an app from the ground up in Carbon (Finder).

Why not take the existing Finder and port it to Carbon? Who the heck wanted the new concept (non-spatial, column view) anyway?

They have to be because Finder 10.3 is still not multi-threaded

This discussion will probably never end... It is multithreaded, only not enough. Type `top` in the Terminal, under "Finder" and "#TH" you find the current number of threads, which is >1 on my 10.2.

[mitchell_pgh]

Apple Developer to Code Guy: "See, we wrote the Finder in Carbon and it works..."

Code Guy: "What's that pinwheel beachball thing..."

Apple Developer: "Don't worry, that will go away in 3 to 30 seconds... if not you can always relaunch... Did I show you the cool Dock! It's the coolest............................."

[Millennium]

Originally posted by danengel:
Why not take the existing Finder and port it to Carbon?

That would not have been possible; OS9's Finder was too closely tied to the system.

Who the heck wanted the new concept (non-spatial, column view) anyway?

A surprising number of people, actually.

Non-spatial metaphors can be made to work, contrary to what the self-proclaimed All-Knowing Merciless God of UI (Tog) may say. Column View was an excellent example of this; it was easily one of the most popular features in early demonstrations. Aficionados of Greg's Browser, an alternative file manager for OS9 which used something very similar to Column View, also loved it.

[danengel]

Wouldn't a complete (maybe Cocoa) rewrite after ~10.1 have been faster? The Finder seemed so screwed up to me that only a general overhaul would put things straight.

[nayr x]

I just like the fact that we are only now regaining some of the features that bubbled out of the rich froth of os8 and 9. Why did it take 2 releases to get spring-loaded folders back? (to name one example).. and how dare they list that as a "new" feature when they total up everything... Sucks we have to wait and have the wheel reinvented on every go-around.

[smeger]

Originally posted by Millennium:
That would not have been possible; OS9's Finder was too closely tied to the system.

Actually, I'm fairly certain that, at least as of Jaguar, the Finder shares quite a bit of code with the OS 9 Finder. Having played around with it quite a bit in the debugger, I've seen lots of cruft that can only be explained by assuming that the code was originally written for, well, System 6.

Stuff like code wrappers around CDEFs and horrid crap like that. It looks like they just threw in lots of hacks to make it work.

[clebin]

I simply can't understand why Apple are not putting more effort into what is the crown jewels of the MacOS.

When OS X came out, they thought it was simply enough to have a Finder, even if it was very flawed.

With 10.1 and 10.2, they thought it was simply enough to have a Finder with the most requested OS 9 features, even if it was still flawed.

With 10.3, Apple think that it's simply enough to have a Finder that works.

When will they wake up and stop doing the absolute bare minimum with the Finder? Why do they not think the Finder key to the operating system? I couldn't give the slightest toss about Mail threading - let's invest that time in a revolutionary Finder that befits it's status.. instead of yet another token effort.

[voodoo]

After using the 10.3 Finder for a few hours I'd say that it is good. It is almost OS 9 good. It has a character to it. It may have taken Apple 2 years to come up with this but it *exists*. It is. And it is pretty fine.

There will be furure revisions of the Finder to be sure, but the 10.3 Finder is not just 'good enough' it is rather pretty much just as good as the one we got used to in OS 9. That is saying something. No more inventing the wheel. It is all done now. Labels are _back_. It is all back. Expos�+the Dock+live search make the 10.3 Finder very very powerful. We all know the iTunes metaphor and we have no problems using that. It works for a file system as well.

Finder 10.3 is a winner.

[Don Pickett]

Could someone please answer the Finder-Multithreaded question? I have seen multiple threads in top output for the Finder.

[RooneyX]

Why is the OS9 Finder being rated? It was absurd. No multithreading, terribly slow at scrolling lots of files, I mean it was cute looking and snappy but awful for people with serious **** to do.

[Developer]

Originally posted by RooneyX:
Why is the OS9 Finder being rated? It was absurd. No multithreading, terribly slow at scrolling lots of files, I mean it was cute looking and snappy but awful for people with serious **** to do.

Both the OS 9 and the OS X Finder are multi-threaded.

[Amorph]

Originally posted by nayr x:
I just like the fact that we are only now regaining some of the features that bubbled out of the rich froth of os8 and 9. Why did it take 2 releases to get spring-loaded folders back?

Bluntly: The first couple releases were put out by NeXTies. After OS 9 died, the OS 9 programmers were folded into the OS X group, and lo and behold, OS X started sprouting all kinds of OS 9-like behavior (at least, the good behaviors).

As for why Finder is still in PowerPlant (iTunes was for a while, BTW): That's a crucial library to have running, and running well, on OS X. Untold amounts of Macintosh code is based on PowerPlant to some degree. There really wasn't any way to perfect the port that didn't involve a trial by fire, and Finder certainly provided that.

Generally, I think Panther will be the first version of OS X that didn't have large swaths of missing, incomplete, or immature code in it. It's certainly the first one to receive the tender ministrations of the veteran Mac OS programmers.

[Gul Banana]

I don't see why the Finder should be considered key to the operating system. It's just a file browser! There are many alternative file browsers and other ways of accessing and organising your data, and it's mostly irrelevant to the real work you do on the computer - or, the real fun you have, for enthusiasts and gamers. I spend almost no time in the Finder, and don't have it running most of the time...

All the Finder is is a program which displays and edits the filesystem hierarchy. That's an important thing to have, but certainly not among THE most important components of an operating system.

[besson3c]

Originally posted by Adam Betts:
Maybe they're working on a rewrite of Finder and they're not finished so they synced some of the changes to Finder 10.3.

They have to be because Finder 10.3 is still not multi-threaded

More multi-threading would not make the Finder instantly better, it isn't some magic thing that makes everything fast and responsive.

There are performance tradeoffs involved with spawning a thread.

[TheIceMan]

Originally posted by Gul Banana:
I don't see why the Finder should be considered key to the operating system. It's just a file browser...
All the Finder is is a program which displays and edits the filesystem hierarchy. That's an important thing to have, but certainly not among THE most important components of an operating system.

Gul I'm not try to start an argument, but have you tried Path Finder? I would say that Path Finder is the Finder that Apple SHOULD have done. I love it. Amazing sodtware.

[CharlesS]

Originally posted by Adam Betts:
They have to be because Finder 10.3 is still not multi-threaded

The Finder in Jaguar is multi-threaded. You can do other stuff while files are copying, moving, etc. Unless they've done something really stupid, the Panther Finder should still be multi-threaded as well.

[Wet Jimmy]

I've a question regarding the Finder in 10.3 - Currently, in 10.2.8, when I select a bunch of files of any decent size (say for example 50 files of 10Mb each) and I wish to perform an action on these files (Right click delete, move,copy, Stuffit, etc) the Finder locks while it thinks about what to do. This can take MINUTES, rendering the rest of the system useless. To make matters worse, if you happen to click away during the process, you have to wait for the current process to finish before having to start over again.

My question is - Has this issue been resolved? I hate to say it, but when working with multiple files, I much prefer my WinXP box - working with many large files on a Mac is like pulling teeth.

So... is there any light at the end of the tunnel?

Cheers!

[Cipher13]

Originally posted by RooneyX:
Why is the OS9 Finder being rated? It was absurd. No multithreading, terribly slow at scrolling lots of files, I mean it was cute looking and snappy but awful for people with serious **** to do.

Bullsh!t. Slow at scrolling lots of files? It's vastly faster than OS X at that task - OS X chokes on large folders far worse than OS 9 ever did.

Don't put words in my mouth - I'm not saying the OS 9 Finder is better - I'm just calling BS on your statement.

[Gul Banana]

Originally posted by TheIceMan:
Gul I'm not try to start an argument, but have you tried Path Finder? I would say that Path Finder is the Finder that Apple SHOULD have done. I love it. Amazing sodtware.

I've tried it, yes. It's quite well done, and certainly has a lot of features - which would be more useful to me if I actually used a file browser much. Which I don't. So, I stick with the Finder, because it's simply less of a hassle.

For Wet Jimmy:

*opens folder on network drive containing 70 100 MB+ files*
*selects all*
*right clicks*
It took about half a second for the contextual menu to come up. Subsequent invocations are instantaneous. Moving and copying them around is similarly lagless.

[- - e r i k - -]

Originally posted by Cipher13:
Bullsh!t. Slow at scrolling lots of files? It's vastly faster than OS X at that task - OS X chokes on large folders far worse than OS 9 ever did.

HAH! I call having a LIMIT (255?) of how many files you can have in a folder a whole lot worse choking than anything in OS X.

[Developer]

Originally posted by - - e r i k - -:
HAH! I call having a LIMIT (255?) of how many files you can have in a folder a whole lot worse choking than anything in OS X.

If there is a limit on how many files you can have in a folder than it's the same in OS 9 and OS X since the file system is exactly the same in case you didn't notice.

[danengel]

There is a limit to the number of files in a folder?? If so, be it 2^32 or more, anything else would be so stupid.

[a holck]

I believe you guyes, when you say that the finder is already multitreaded.

But what is Apple doing wrong in the codebase that makes one haltet operation in one view freeze the whole finder app?

I would think that making every window having it's own thread should make every window independent. Right?

For example If I select a .Mpeg2 in one view the finder will contact the QuickTime API to make a preview in the priview column. As this takes about 10 seconds for QT to parse the file The process freezes until QT reports back.
What should happen is that the finderwindow should run along fine without waiting for the exterrnal process in QT, but iis doesnt. Actually not only the current finder window freezes, but the whole Finder does.

Why can't they program this for flexability? Is it at all possible?

[Developer]

Originally posted by a holck:
But what is Apple doing wrong in the codebase that makes one haltet operation in one view freeze the whole finder app?

I would think that making every window having it's own thread should make every window independent. Right?

The UI can only be handled from the main thread. That doesn't mean that the whole Finder freezes. For example if you drag a file copy window around the progress bar isn't updated any more, but the file copy is actually continuing.

[Terri]

Can this be fixed?

We often have to move thousands of files around in the Finder and Mac OS X is killing us when doing this kind of stuff. System 9 was much better at doing this, but still not great.

[danengel]

We often have to move thousands of files around in the Finder and Mac OS X is killing us when doing this kind of stuff. System 9 was much better at doing this, but still not great.

I always use the Terminal for file management. Tcsh's filename completion is very smart (don't forget to `set complete=enhance`), and with some tricks or a little shell script, everything can be done.

tcsh, find, locate, grep, sort etc. are your friends, you just have to get to know them a little.

[Millennium]

Originally posted by a holck:
I believe you guyes, when you say that the finder is already multitreaded.

But what is Apple doing wrong in the codebase that makes one haltet operation in one view freeze the whole finder app?[

Actually, the problem there is not with the Finder at all. The problem is with HFS+.

I know I'm going to get lynched for that unless I talk fast, so please allow me to explain. The reasons for this go all the way back to the very first versions of the Mac OS, which used a file system called MFS (Macintosh Filing System).

MFS was slavishly devoted to real-world metaphors. Among these was the fact that you could not put a folder inside a folder. This was an interface concern, rather than a filesystem concern, but back in those days it was believed that the frontend and backend had to be tightly tied together -the tighter the better- or nothing would work well.

Because of that, Apple stored pointers to files on disk in a data structure known as B-trees. These allowed the OS to look up files extremely quickly. It also meant that the OS could only use one thread to access the disk at a time. This suited Apple just fine, because the OS had no notion of multiple thread -or even multiple applications running at once- back then.

MFS didn't last very long. People were clamoring for more features, among them the ability to nest folders. Apple relented around the days of System 4, and created HFS (Hierarchical File System). This included many benefits over MFS, but kept much of the underlying technology. For example, it kept the B-trees, because these continued to provide very fast file lookups, and the OS still had no concept of multitasking or multithreading. MFS would continue to be supported, however, up until OS8, if I recall correctly.

FUN FACT: The original way to multitask in the Mac OS came about as an extension called MultiFinder, which was introduced in System 6. This was actually optional until System 7 came around.

Users, however, clamored for still more features. The biggest was longer filenames, but there were other, more technical, features which would later be needed, particularly in the case of the upcoming Rhapsody project. In order to support this, Apple came up with a new system, HFS+ (sometimes called Mac OS Extended). This was actually little more than a set of extensions to HFS, rather like how journalling is little more than a set of extensions to HFS+ nowadays. But this means -you guesses it- that they kept B-Trees. Same fast file lookups -HFS+ still beats other filesystems in this regard- but still single-threaded access only.

Now, however, Apple was in a bit of trouble. Around the time of System 7.5, Apple had introduced the Thread Manager, which allowed a limited form of multithreading in the OS. With this, people began to realize some of the problems with HFS. Apple would later respond by using a "threaded Finder", but in reality they had to perform many other very interesting tricks -not just multithreading- to create the illusion of threaded access.

This is, as it turns out, one of the reasons that BeOS did not choose HFS+ as its main filesystem. It was originally a contender, but the fact that truly multithreaded access wouldn't work was one of the main deathblows. Be would later write its own file system which wipes the floor with most other filesystems out there, though it lacks one or two key features of HFS+ (in particular, unique file IDs, which are what make aliases possible on the Mac OS).

Ahem. One of the problems with OSX's Finder is that it cannot perform all of the tricks that OS8/9's Finder did, because it is not as closely tied in with the OS itself. Although Apple manages to make it better and better with every release, the only way to solve the problem completely is with a new filesystem.

I would think that making every window having it's own thread should make every window independent. Right?

It does, to a limited degree, but they cannot be made independent in terms of file access.

Why can't they program this for flexability? Is it at all possible?

As long as they continue to use HFS+, it is not entirely possible, no. A new filesystem will be needed to clean out the last of the problems. It is possible that, now that he's brought journaling to HFS+, Dominic Giampaolo (creator of Be's filesystem, now employed by Apple) will work on this. Nobody outside Apple knows for sure.

[Terri]

Originally posted by danengel:
I always use the Terminal for file management. Tcsh's filename completion is very smart (don't forget to `set complete=enhance`), and with some tricks or a little shell script, everything can be done.

tcsh, find, locate, grep, sort etc. are your friends, you just have to get to know them a little.

You really think a bunch of left brained artist are going to start moving files around using the terminal???

Not to mention you need to actually look at the file's icons and where they are placed in the window and what window they are in. Designers mostly work in the Finder the same way they do in the real world. Files are all over the place and there are piles of them here and there with different pretty icons and colors to remind then what is what and what goes where. Anyone that thinks the terminal is going to get used by designers has no understanding of how Macs are used in the creative fields.

[danengel]

Anyone that thinks the terminal is going to get used by designers has no understanding of how Macs are used in the creative fields.

You got me wrong. The command line is nice for geeks, scientists and engineers. Neither my girlfriend nor an artist should know that it even exists.

The 10.2 Finder sucks, it's an impudence to claim this "the most advanced OS in the world". All I wanted to point out is that the Terminal is an alternative for those who have the time and fun exploring the world of UNIX.

[stew]

Originally posted by Developer:
The UI can only be handled from the main thread.

Nope, multiple threads could update the UI if written properly. The problem is that the Carbon Event model is braindead enough to force window dragging events through the application's event loop (just like Win32). Unless the application developer explicitly spawns threads here, dragging a window will make the app unresponsive to other events. To see how it should be done, take a look at Cocoa, X11 or BeOS.

[Leia Shoots Like a Girl]

Bad news but the 10.3 Finder isn't all that much better, it is just silver now.

[foamy]

re: moving files in the terminal

I created 1024 empty files, then tried to mv them in the terminal.

The response, "too many arguments" and the files don't get moved. Same command on 10 files works fine.

FWIW

One more thing. Pathfinder also chokes on large numbers of files just like the Finder does.

[danengel]

Originally posted by foamy:
re: moving files in the terminal

I created 1024 empty files, then tried to mv them in the terminal.

The response, "too many arguments" and the files don't get moved. Same command on 10 files works fine.

FWIW

Try

foreach i(*)
mv $i ~/.Trash
end

"Too many arguments" sucks. I hate arbitrary limits only because some programmer was too lazy to implement a dynamic list. It's not 1970 anymore.

[Adam Betts]

Originally posted by Leia Shoots Like a Girl:
Bad news but the 10.3 Finder isn't all that much better, it is just silver now.

Exactly, I know it's multithreaded but it is poorly done.

danengel, my point is that Finder CAN be improved but Apple must have some reason for not shifting enough attention to Finder.

[danengel]

Originally posted by Adam Betts:
... my point is that Finder CAN be improved but Apple must have some reason for not shifting enough attention to Finder.

Maybe Steve's wife told him. I can't believe this. They have so many things to be proud of but the Finder is still crap, after three years... They could have bought PathFinder instead...

[ryaxnb]

Originally posted by Millennium:
Actually, the problem there is not with the Finder at all. The problem is with HFS+.

I know I'm going to get lynched for that unless I talk fast, so please allow me to explain. The reasons for this go all the way back to the very first versions of the Mac OS, which used a file system called MFS (Macintosh Filing System).

MFS was slavishly devoted to real-world metaphors. Among these was the fact that you could not put a folder inside a folder. This was an interface concern, rather than a filesystem concern, but back in those days it was believed that the frontend and backend had to be tightly tied together -the tighter the better- or nothing would work well.

Because of that, Apple stored pointers to files on disk in a data structure known as B-trees. These allowed the OS to look up files extremely quickly. It also meant that the OS could only use one thread to access the disk at a time. This suited Apple just fine, because the OS had no notion of multiple thread -or even multiple applications running at once- back then.

MFS didn't last very long. People were clamoring for more features, among them the ability to nest folders. Apple relented around the days of System 4, and created HFS (Hierarchical File System). This included many benefits over MFS, but kept much of the underlying technology. For example, it kept the B-trees, because these continued to provide very fast file lookups, and the OS still had no concept of multitasking or multithreading. MFS would continue to be supported, however, up until OS8, if I recall correctly.

FUN FACT: The original way to multitask in the Mac OS came about as an extension called MultiFinder, which was introduced in System 6. This was actually optional until System 7 came around.

Users, however, clamored for still more features. The biggest was longer filenames, but there were other, more technical, features which would later be needed, particularly in the case of the upcoming Rhapsody project. In order to support this, Apple came up with a new system, HFS+ (sometimes called Mac OS Extended). This was actually little more than a set of extensions to HFS, rather like how journalling is little more than a set of extensions to HFS+ nowadays. But this means -you guesses it- that they kept B-Trees. Same fast file lookups -HFS+ still beats other filesystems in this regard- but still single-threaded access only.

Now, however, Apple was in a bit of trouble. Around the time of System 7.5, Apple had introduced the Thread Manager, which allowed a limited form of multithreading in the OS. With this, people began to realize some of the problems with HFS. Apple would later respond by using a "threaded Finder", but in reality they had to perform many other very interesting tricks -not just multithreading- to create the illusion of threaded access.

This is, as it turns out, one of the reasons that BeOS did not choose HFS+ as its main filesystem. It was originally a contender, but the fact that truly multithreaded access wouldn't work was one of the main deathblows. Be would later write its own file system which wipes the floor with most other filesystems out there, though it lacks one or two key features of HFS+ (in particular, unique file IDs, which are what make aliases possible on the Mac OS).

Ahem. One of the problems with OSX's Finder is that it cannot perform all of the tricks that OS8/9's Finder did, because it is not as closely tied in with the OS itself. Although Apple manages to make it better and better with every release, the only way to solve the problem completely is with a new filesystem.

It does, to a limited degree, but they cannot be made independent in terms of file access.

As long as they continue to use HFS+, it is not entirely possible, no. A new filesystem will be needed to clean out the last of the problems. It is possible that, now that he's brought journaling to HFS+, Dominic Giampaolo (creator of Be's filesystem, now employed by Apple) will work on this. Nobody outside Apple knows for sure.

My fun corrections. HFS was introduced in System 3 - 1986. It only worked on the Mac Plus unless you used to HD 20 driver to fool the system. Actually it was introduced with the HD 20 even earlier. Multifinder was introduced in System 4.2, not 6.

[smeger]

I suspect that the rationale behind not making big improvements to the Finder is that Apple plans to move to a filesystem with extensible metadata at some point. Making use of this will require rewriting large chunks of the Finder, hence, there's no reason doing it now when they'll just have to do it again.

This, of course, is total speculation on my part.

But I think the fact that they've already moved to something that looks like the iTunes playlist idea in the Finder makes it a good bet that "smart Finder playlists" based on metadata are in the future. I hope, anyway.

[danengel]

I suspect that the rationale behind not making big improvements to the Finder is that Apple plans to move to a filesystem with extensible metadata at some point. Making use of this will require rewriting large chunks of the Finder, hence, there's no reason doing it now when they'll just have to do it again.

Makes sense for two reasons:

1. Microsoft is going in that direction too: http://news.com.com/2100-1016_3-5090584.html

2. HFS+ is so antiquated, while everything else in OS X is new. (Yes I know BSD is old, but in that case old=solid, not as with HFS old=bad.)

Would it have been too much to implement a new filesystem into 10.0? What about UFS?

[CharlesS]

Originally posted by stew:
Nope, multiple threads could update the UI if written properly. The problem is that the Carbon Event model is braindead enough to force window dragging events through the application's event loop (just like Win32). Unless the application developer explicitly spawns threads here, dragging a window will make the app unresponsive to other events. To see how it should be done, take a look at Cocoa, X11 or BeOS.

The AppKit in Cocoa is not thread-safe either, so if you want to update the UI from a thread, you have to send a message to the main thread. Anything involving the UI in Cocoa needs to be done from the main thread. Otherwise, your app will get very unstable. I'm not sure where you get the idea that you can update the UI from multiple threads in Cocoa.

[smeger]

Originally posted by CharlesS:
The AppKit in Cocoa is not thread-safe either, so if you want to update the UI from a thread, you have to send a message to the main thread. Anything involving the UI in Cocoa needs to be done from the main thread. Otherwise, your app will get very unstable. I'm not sure where you get the idea that you can update the UI from multiple threads in Cocoa.

Not generally true. Here's Apple's take on this.

[Phoenix1701]

It's kind of cool that you should mention Dominic... he attended my college (Worcester Polytechnic Institute) and I'm actually currently doing my senior project with the same advisor who did his -- my project, in fact, is something of a follow-up of the project that he did, which dealt with something called "AttrFS" -- a bit of foreshadowing, I would think.
Anyway, here's what Dominic has to say about HFS in his book, "Practical File System Design":

Almost nothing about HFS resembles a traditional file system. It has no i-node table, it has no explicit directories, and its method of recording which blocks belong to a file are unusual. About the only part of HFS that is similar to existing systems is the block bitmap that records which blocks are allocated or free.
HFS extensively uses B*trees to store file system structures. [...]
[...]In addition to the normal information, the file system also stores information used by the GUI with each file. Both directories and files require additional information to properly display the position of a file's icon when browsing the file system in the GUI. Storing this information directly in the file record was unusual for the time. [Note: this information is no longer used in OS X; that's where those horrible .DS_Store files come in.]
[...]
The catalog file is a complicated structure. Because it keeps all file and directory information, it forces serialization of the file system -- not an ideal situation when there are a large number of threads wanting to perform file I/O. In HFS, any operation that creates a file or modifies a file in any way has to lock the catalog file, which prevents other threads from even read-only access to the catalog file. Access to the catalog file must be single-writer/multireader.
[...]
A recent revision to HFS, HFS+, removes some of the original limitations of HFS, such as the maximum number of blocks on a volume, but otherwise makes very few alterations to the basic structure of HFS. HFS+ first shipped with Mac OS 8.1 about 14 years after the first version of HFS.
Despite its serious limitations, HFS broke new ground at the time of its release because it was the first file system to provide direct support for the rest of the graphical environment. The most serious limitations of HFS are that it is highly single threaded and that all file and directory information is in a single file, the catalog file. [...] HFS set the standard for file systems supporting a GUI, but it falls short in many other critical areas of performance and scalability.

[Don Pickett]

Originally posted by Millennium:
FUN FACT: The original way to multitask in the Mac OS came about as an extension called MultiFinder, which was introduced in System 6. This was actually optional until System 7 came around.

And I remember in System 6 that you could start up in Singlefinder mode and switch to Multifinder by opening the System Folder and doubleclicking on Multifinder holding down the right keyboard combo.

Of course, that was when a 40 meg HD was huge.

[besson3c]

Originally posted by Leia Shoots Like a Girl:
Bad news but the 10.3 Finder isn't all that much better, it is just silver now.

Are you kidding? The 10.3 Finder is much better... its caching is far better (only have to wait for icons to be drawn once), it is much smarter about disconnected servers, scrolling is faster, and of course there are several new features.

[daftpig]

Originally posted by Gul Banana:
I don't see why the Finder should be considered key to the operating system. It's just a file browser! There are many alternative file browsers and other ways of accessing and organising your data, and it's mostly irrelevant to the real work you do on the computer - or, the real fun you have, for enthusiasts and gamers. I spend almost no time in the Finder, and don't have it running most of the time...

All the Finder is is a program which displays and edits the filesystem hierarchy. That's an important thing to have, but certainly not among THE most important components of an operating system.

Don't know how the rest feel.

But I think the "Finder" was Macintosh par excellence in pre-OSX days. Maybe I'm being silly but I think just its name tells of what it means to experience a Mac. I've always wondered who was the one who suggested that it be called "Finder".

I'm not good with expressing my thots, sorry.

[sniffer]

I wonder if the problems related with HFS+ also explain why X is so unbearable with only 128 mb ram. I mean everytime X tries to swap something on the disk and execute some app or whatever the system stalls like it's waiting for a task to complete. With this amount of ram the whole system acts like Finder. (Just forget about multitasking w/128)

[Big Mac]

Great find, Phoenix!

In HFS, any operation that creates a file or modifies a file in any way has to lock the catalog file, which prevents other threads from even read-only access to the catalog file. Access to the catalog file must be single-writer/multireader.

Doesn't this mean that any write access whatsoever precludes any other access to the drive by any other thread until the write is complete? That is extraordinary. The article seems to indicate that HFS+ doesn't change this aspect of the filesystem. I simply cannot believe that in such a highly multitasking, multithreaded environment as OS X there could possibly be such an absurd restriction. If there is, we're really not giving Apple engineers enough credit for hiding the limitation as well as they have. (Hey, maybe this limitation is really what's to blame for zombie processes. I'm talking about the instance when an application beach balls and then any attempt to force quit or launch other applications fails. I was under the impression this rare condition was caused by errant applications improperly accessing the kernel, but it sounds like HFS maybe to blame. We should be thankful this doesn't happen all the time.) Wow, this discussion really makes me want to switch to UFS! Please do let me know if I've interpreted things correctly.

No, on second thought, it simply can't be that way. Things are written to disk all the time, and it doesn't cause other applications to come screeching to a halt. Apple must have found a way around this in OS X, or else it simply wouldn't function as well as it does. Update: I found something through Google which implies a write locks the catalog for a given file, not the entire disk. That must be it, right?

[voodoo]

Originally posted by daftpig:
Don't know how the rest feel.

But I think the "Finder" was Macintosh par excellence in pre-OSX days. Maybe I'm being silly but I think just its name tells of what it means to experience a Mac. I've always wondered who was the one who suggested that it be called "Finder".

I'm not good with expressing my thots, sorry.

I agree 100%. The Finder is the Macintosh. Those of you who are governed by the left side of your brain know what I mean.