OSDev.org

Brendan wrote:If the metadata can be obtained automatically, then it could be obtained automatically when it's needed and not stored anywhere. In this case the extended attributes would cache the metadata (e.g. to improve the time it takes to obtain) rather than adding something new.

I'm thinking an AI to analyze your photo library would take a really long time to run, just like downloading metadata for thousands of tracks from CDDB. I wouldn't tend to think of local storage of this metadata as a cache, especially since the user should always be able to correct mistakes (there's no way an AI will be right 100% of the time... probably 80% would be the best you could ever expect, but it's better than 0%).

Brendan wrote:I'm also wondering how you'd avoid problems with context. For example, a friend takes some photos with a phone and sets the metadata to "My family on holiday", and then sends these pictures to you (including the metadata). Now you've got pictures that say "My family" when it's not your family at all. There's also a major internationalization issue here - e.g. metadata in one language isn't going to be useful to someone who doesn't understand that language.

I've faced these sorts of problems in real life, sharing photos with my wife and my parents. In practice, it isn't a problem because the amount of photos we share is far, far less than the amount of our own photos that we manage. Plus, the tools we use for managing the metadata make bulk updates really easy.

Brendan wrote:I'm the opposite - a hierarchical filesystem helps me find exactly what I'm after. For example, for OS development information I've got a large directory called "info" that contains hundreds of files, but this directory has many subdirectories (e.g. "video", "network", "CPU", etc). Using the hierarchical filesystem, if I want to find some errata for Pentium 4 CPUs I can find it fast because it's in the "/info/CPU/Intel/Pentium4/errata" directory. Without a hierarchical filesystem I'd be forced to use searches, which can be slow but more importantly aren't very precise - for example, maybe I use the word "netburst" in my SQL query and find nothing because I forgot the metadata called these files "Pentium 4" instead.

I used to be the same, but since I started using Spotlight I hardly ever browse the file system. If I remember part of the name of the file or app I want to open, I just hit command-space and start typing. In less than a second, what I'm looking for is selected in the drop-down search results menu and I just hit Return, and there it is. It's almost like having a command line that magically knows what the current directory should be.

@mbluett: Your objection to hierarchical file system navigation is justified -- it really does take training for novices to understand. Fast & accurate search capability is much more user-friendly. However, you do not need a full database engine to implement this, as many of us have pointed out. Try OS X for a while and see for yourself....

mbluett wrote:Opening one file and closing it is not an issue. That is quite fast. However, when you have a search process traverse an entire file system containing 100's of thousands of files watch how long it takes. Each file results in at least two system calls. And each involves moving the heads and reading a file. This is the slowest part of the process.

This is why you use indexing.... The search service can keep the index file open all the time, and have access to everything it needs without constantly opening and closing files. The technology already exists today!

mbluett wrote:For example, say they want to attach a digital image file to an email. After clicking on the "Attach" button of your email package, what are you presented with? A filesystem browser box. What does the Novice do now?

In Mac OS X, the "file open" sheet has a "media" section on the left hand side in addition to the usual file system browser. You click on "photos", and your entire iPhoto library is presented as thumbnails. Even my Mom can figure this out.

mbluett wrote:With a database and properly designed applications there is no filesystem traversal. Instead, a database search occurs for image relative information, the image (or images) are retrieved, the user selects the proper one, it is attached and the user is all done. That is the way it should work. This type of thing might be available on the MAC, but does not exist in any other O/S I have ever seen. Why hasn't this issue been addressed in Linux or MS O/S's?

As I said, it does exist on Mac OS X, but not because of a database engine. As to why, IMO it's a matter of business priorities. Apple's competitive advantage is their ability to make very simple, elegant user interfaces. Until recently, MS' focus has been more on the business side of things, along with a strong emphasis on adding features over increasing usability. I expect this to shift over time, starting with Windows 7, due to competitive pressure from Apple.

As for Linux, IMO its usability is always going to suffer because it depends too much on the good graces of volunteer engineers, and we engineers for the most part can't UI-design our way out of a paper bag.

JackScott wrote:So what do the application programmers do? They make up their own functions, their own GUI elements, all specific to their application, and unusable by everybody else. IMHO, one of the biggest violations of the 'standard' API is MS's own software suite, Office '07. Noticed how it fits in perfectly with Vista? Very good. Now run it on Windows XP. It still looks like it did on Vista: it doesn't fit in with the XP themes. Now why the hell did they do that?

Because they expected everyone to upgrade to Vista, of course.

I wouldn't even want to try speaking for the Office team, but I do know that they are seen as the vanguard of new UI paradigms within MS. The ribbon was a carefully planned UI experiment. If you look at past releases, Windows tends to pick up Office's UI look & feel one version later. This does hurt the consistency of the overall UI, but on the other hand it lets them try out new UI ideas in the field before committing to them across the entire OS.

Hi,

Colonel Kernel wrote:

Brendan wrote:I'm also wondering how you'd avoid problems with context. For example, a friend takes some photos with a phone and sets the metadata to "My family on holiday", and then sends these pictures to you (including the metadata). Now you've got pictures that say "My family" when it's not your family at all. There's also a major internationalization issue here - e.g. metadata in one language isn't going to be useful to someone who doesn't understand that language.

I've faced these sorts of problems in real life, sharing photos with my wife and my parents. In practice, it isn't a problem because the amount of photos we share is far, far less than the amount of our own photos that we manage. Plus, the tools we use for managing the metadata make bulk updates really easy.

IMHO wrong or unreadable metadata is worse than no metadata, and manually checking and then changing the metadata of received files sounds like a pain in the neck to me. If this new OS is meant to make things easier, then I shouldn't be forced to spend time managing the metadata. For current OSs it's optional, but Mbluett isn't going to provide the "hierarchical tree" alternative.

Colonel Kernel wrote:

Brendan wrote:I'm the opposite - a hierarchical filesystem helps me find exactly what I'm after. For example, for OS development information I've got a large directory called "info" that contains hundreds of files, but this directory has many subdirectories (e.g. "video", "network", "CPU", etc). Using the hierarchical filesystem, if I want to find some errata for Pentium 4 CPUs I can find it fast because it's in the "/info/CPU/Intel/Pentium4/errata" directory. Without a hierarchical filesystem I'd be forced to use searches, which can be slow but more importantly aren't very precise - for example, maybe I use the word "netburst" in my SQL query and find nothing because I forgot the metadata called these files "Pentium 4" instead.

I used to be the same, but since I started using Spotlight I hardly ever browse the file system. If I remember part of the name of the file or app I want to open, I just hit command-space and start typing. In less than a second, what I'm looking for is selected in the drop-down search results menu and I just hit Return, and there it is. It's almost like having a command line that magically knows what the current directory should be.

What can you tell me about the file name's Intel uses for their documents? That's right - they're all numbers. The only part of "24919966.pdf" that I'll ever remember is the ".pdf" part. I checked - there's a total of 1235 files that match "*.pdf" in my "info" directory (including subdirectories).

To estimate how useful metadata is, see how many attempts it takes you to find a query for Google that finds less than 20 files including at least 5 (of the 7) Pentium 4 errata documents.

I tried about 20 queries before I succeeded, but I also spent 10 minutes looking through Google's documentation (advanced search and advanced operators) to narrow down the list. After you've tried, here's my best attempt: Google...

It takes me 5 mouse clicks to find "info/cpu/intel/pent4/errata/24919966.pdf" from a blank desktop. Unless Mbluett's SQL searches can improve that, then it's not making the OS easier to use for me, and probably not making the OS easier to use for a lot of other people too.


Cheers,

Brendan

I'm looking for things that make your database different to a normal filesystem, and reasons why it's better.

There are a lot of things you can do with a database that would be more difficult with individual files. For example, data created by a specific application would easily be accessible from another without doing any additional programming.

mbluett wrote:1. To get rid of the notion of having to understand how to traverse an hierarchical filesystem. Files stored in folders,
stored in folders, etc. The concept is usually easy to grasp. The problem is that the general public have great difficulty
determining where to find a file. In addition, they typically can't remember what the file was called even if they wanted
to do a search. So, they must search within files to find what they are looking for.

I'm the opposite - a hierarchical filesystem helps me find exactly what I'm after. For example, for OS development information I've got a large directory called "info" that contains hundreds of files, but this directory has many subdirectories (e.g. "video", "network", "CPU", etc). Using the hierarchical filesystem, if I want to find some errata for Pentium 4 CPUs I can find it fast because it's in the "/info/CPU/Intel/Pentium4/errata" directory. Without a hierarchical filesystem I'd be forced to use searches, which can be slow but more importantly aren't very precise - for example, maybe I use the word "netburst" in my SQL query and find nothing because I forgot the metadata called these files "Pentium 4" instead.

Again, I'm not intending this O/S for people like yourself. I am intending it for the general public who do not know how to do the things you do.

Google is very fast because they're using over 450000 servers in parallel. You enter a query and the front-end sends that query to lots of computers, and each of these computers searches a tiny fraction of the database and returns it's results, then the results from all of the computers are combined. Unfortunately, most people don't have that many computers (and even if they did they wouldn't want to keep them running all the time just so they can find files).

You could be right. I have no knowledge of how they run their servers. How did you come across the information that told you this is the way Google searches work?

mbluett wrote:2. To create more flexibility in being able to make simple additions to the descriptive information that can be stored with
files in todays O/S's. For example, if I wanted to add a descriptive field to indicate which application created a file it
would be a trivial matter with a database. However, with a conventional filesystem, it would involve re-compiling and
testing the new changes. And what about backward compatibility issues?

This can be done with the extended attributes that most OSs already support. You don't need to recompile anything just to add a new attribute (although for Linux almost everyone would need to enable support for extended attributes and recompile the kernel, because this sort of thing is so useful that almost everyone doesn't bother enabling it). Windows/NTFS always supports it.

I am aware of the existing fields where metadata can be added under XP. However, how does one add new fields? I have seen that you can add pre-defined field types to a Word Document, for example. But tell me how you would do this with a URL file. If you right-click on the file I cannot see any place where you can add ANY metadata.

If the capability to do this exists somewhere hidden in the O/S then what value is it to the majority? I have been working with this system ever since it's onset and I am unaware of how this can be accomplished. If I can't find out, easily, how to do this then what about the general public? If the facility is available, there would only be a handful of people using it because the majority wouldn't even know it exists. In other words, they may as well not even have bothered adding it.

This is just one of the problems with current implementations with MS O/S's. Linux is no different. I have used it for years as well. There are issues with functionality existing, but that is hard to get to or even know that it exists. This poses a problem to the general public. If the general public cannot make use of these features they are only good for the technical types. So these O/S's are then designed for technical types, not the general public. Seems like a very poor solution to me.

The problem with existing systems is that most applications don't support extended attributes, there's often no tools to index and/or search for files based on information in the extended attributes, and there's no standards to say how extended attributes should be used. For example, I could write an application for Windows or Linux that creates an "application = my_application_name" extended attribute, and other applications might create a "program = my_application_name" extended attribute, and some applications might set a "my_application_name = yes" attribute; and nobody will know what to search for. Of course the same can happen for your database - e.g. my application creates a field in the database called "application" and sets this field to "my_application_name" for it's files, while other people's applications create different fields for the same purpose, and end users have no idea which database field/s they need to search in their query.

From this it sounds like you may agree with at least some of what I have just written above.

To avoid that problem you'd need to have some sort of specification that describes "standard fields" and their intended purpose (so all software uses the database fields in a compatible way), but if you're going to do that you might as well just add the "standard fields information" to the directory entries (e.g. filename, file size, file permission flags, file owner, file description, keyword list for the file, application that created the file, application that modified the file last, etc).

[/quote]

Yes, I agree it could be done that way. However, to me that method is not a consistently organized method.

In a lot of the general public's machines I have seen, they have files scattered all over the place. Sometimes there are copies of copies of copies. Sometimes this has occurred by accident. Once this occurs they have no idea if they can delete any of the files without losing something.

This kind of condition can be prevented when using a database as there is no need to make copies of anything unless it is being saved for backup purposes.

All applications can easily make use of the same data. Currently, this is not easily possible.

Databases have to be organized for them to work efficiently. One of the standard design methods in databases is to reduce redundancy as much as possible: It's called "normalizing" a database.

Also, this organization is handled by the database and not the user. Yet another advantage to using a database.

Colonel Kernel wrote: @mbluett: Your objection to hierarchical file system navigation is justified -- it really does take training for novices to understand. Fast & accurate search capability is much more user-friendly. However, you do not need a full database engine to implement this, as many of us have pointed out. Try OS X for a while and see for yourself....

That's great that OS X is that easy to use. However, most of the computer users of the world don't use OS X. In other words it makes no sense to talk of O/S's that most of the general public don't use. My desire is not offend you, but the reality of it is that MS O/S's, unfortunately, are the majority. To try and convert them to OS X will never happen. If it was going to happen it would have already.

What is required is a radical new design that makes it so easy for the general public as well as free (or darn close to it) that they would not hesitate. This maybe a tall order and it maybe that none of us will ever accomplish it. But we have to try.

Colonel Kernel wrote:

mbluett wrote:Opening one file and closing it is not an issue. That is quite fast. However, when you have a search process traverse an entire file system containing 100's of thousands of files watch how long it takes. Each file results in at least two system calls. And each involves moving the heads and reading a file. This is the slowest part of the process.

This is why you use indexing.... The search service can keep the index file open all the time, and have access to everything it needs without constantly opening and closing files. The technology already exists today!

The indexing file may stay open all the time, but the files that are being searched are not.

Colonel Kernel wrote:

mbluett wrote:For example, say they want to attach a digital image file to an email. After clicking on the "Attach" button of your email package, what are you presented with? A filesystem browser box. What does the Novice do now?

In Mac OS X, the "file open" sheet has a "media" section on the left hand side in addition to the usual file system browser. You click on "photos", and your entire iPhoto library is presented as thumbnails. Even my Mom can figure this out.

Again, there is another cudos for OS X. However, how do we convince the public to switch? Why hasn't this happened if OS X is so great.

Colonel Kernel wrote: As for Linux, IMO its usability is always going to suffer because it depends too much on the good graces of volunteer engineers, and we engineers for the most part can't UI-design our way out of a paper bag.

I don't think you give the volunteer engineer's of the world enough credit. I refuse to accept that they are that bad. What it ultimately takes is organization and the desire to move a new design ahead regardless of the fact that it flies in the face of everything (or most things) that currently exist.

After all Apple has done a great job with interface design. What needs to occur is either for MS to get their act together or for some other group to find a solution that cannot be ignored. Despite many attempts Apple has been unable to accomplish this goal.

For example, why doesn't Apple go to all the hardware vendors and offer them money (or some other deal) so that they will provide OS X with their hardware? Why is it that MS O/S's (and sometimes Linux) are the only ones available?

Why does Apple insist on proprietary hardware? This is a real problem in having OS X replacing MS O/S's.

Sure I love their designs, but that is not enough.

mbluett wrote:For example, why doesn't Apple go to all the hardware vendors and offer them money (or some other deal) so that they will provide OS X with their hardware?

Apple wouldn't even need to offer any money, I reckon. There are plenty of companies which'd love to sell OS X machines. Just look at Psystar Apple experimented with licensing the OS a while ago, and it didn't work out. Apple is doing very well right now, and has no need to risk a drastic change to its business model.

M

Brendan wrote:IMHO wrong or unreadable metadata is worse than no metadata, and manually checking and then changing the metadata of received files sounds like a pain in the neck to me. If this new OS is meant to make things easier, then I shouldn't be forced to spend time managing the metadata. For current OSs it's optional, but Mbluett isn't going to provide the "hierarchical tree" alternative.

That would be a mistake... I agree that hierarchical filesystems still make sense, from the point of the view of the system if not the user. However, I don't think you've really experienced or thought through how metadata-driven search actually works in practice. Hang on for some concrete examples...

Also, I'm not talking about mbluett's OS here, but about OSes that already exist. I happen to believe that a lot of mbluett's usability goals can be achieved with current OSes, and that a radical re-design is not necessary, at least not for the sake of usability. I can think of a lot of other reasons for a brand new OS architecture, but that's a topic for another thread.

Brendan wrote:What can you tell me about the file name's Intel uses for their documents? That's right - they're all numbers. The only part of "24919966.pdf" that I'll ever remember is the ".pdf" part. I checked - there's a total of 1235 files that match "*.pdf" in my "info" directory (including subdirectories).

That's fine -- file contents are also indexed, not just the file name. You can always re-name the documents after you download them, too.

Brendan wrote:To estimate how useful metadata is, see how many attempts it takes you to find a query for Google that finds less than 20 files including at least 5 (of the 7) Pentium 4 errata documents.

Google is searching the entire web. Built-in OS search just searches your local drives. I searched for "Pentium 4 errata" and got about a dozen results, all of which were Intel manuals that had descriptive titles (because I re-named them after downloading them, which is only sensible IMO). But this is something I would only do if I had forgotten where I had put the docs. The case I mentioned in my last post is for when I know *exactly* what I'm looking for, but I don't happen to have a shortcut to it on my desktop or some other quick way of getting there. For some people, it's quicker for them to remember what something is called rather than where it is in a spatial GUI.

There are different use cases for search and metadata, and they make sense in different situations. A single mechanism is not enough to make things convenient for the user in all cases.

Brendan wrote:It takes me 5 mouse clicks to find "info/cpu/intel/pent4/errata/24919966.pdf" from a blank desktop. Unless Mbluett's SQL searches can improve that, then it's not making the OS easier to use for me, and probably not making the OS easier to use for a lot of other people too.

As mbluett has already pointed out, you are not most people. None of us are.

Ok, here's a concrete example of how metadata and search are being used to good effect today, and why partial metadata is better than no metadata at all: iPhoto.

iPhoto has a library into which you can import your pictures. In the file system, this is implemented as a bundle with an internal directory structure that the user doesn't need to see. If you use iPhoto for managing all your pictures, then you rarely encounter them in the file system. If you need to use a picture for something (send it as an e-mail attachment, put it in a presentation, etc.), there is a "media browser" integrated into the shell's "file open" dialogs that lets you browse your library as if you were actually using iPhoto, which means that you can search for pictures in the same non-hierarchical way throughout the system.

As for how iPhoto organizes the library, it is basically in a number of orthogonal ways. First and foremost, all pictures have a date & time stamp, usually put there by the digital camera that took them, but it can also be set manually (on individual pics or in bulk batches, to absolute times or with relative adjustments). The user can group pics with similar dates into "events". So, for example, if I took a bunch of pictures of my Hawaiian vacation, I have the option of grouping them all together, or perhaps splitting them up by each day of the trip, or perhaps by each island I visited, etc. This is the backbone of organizing photos, since the chronological presentation helps you to find pics that you would otherwise have misplaced, or that wouldn't show up in a search due to missing metadata.

The other major way of organizing pics is by album. An album is just a collection of pics from the library, but the same picture can be in multiple albums. This is just a way for the user to organize things in an ad-hoc fashion.

Finally, there is searchable metadata like title, keywords, and description. Keywords are especially useful since they can be assigned to many pictures at once. For example, I can create a keyword for each of my family members and use this to tag all the photos that they're in. This is all optional -- it is only for the case when you're trying to find a picture, but you may not remember what albums you put it in or when exactly it was taken. Incorrect metadata doesn't hurt here -- it gives a few incorrect results, which are obvious to the user from the context and can easily be corrected.

Remember, when it comes to pictures, there is a really simple way of looking for them if all else fails -- look through them one by one until you recognize the one you're looking for! Metadata & search can only help here, not hurt.

mbluett wrote:You could be right. I have no knowledge of how they run their servers. How did you come across the information that told you this is the way Google searches work?

I thought it was common knowledge. I remember hearing about their data center's power requirements on the news. Where exactly have you been for the past 12 years...?

http://labs.google.com/papers/mapreduce.html

Other search engines also work roughly in the same way.

mbluett wrote:I am aware of the existing fields where metadata can be added under XP. However, how does one add new fields? I have seen that you can add pre-defined field types to a Word Document, for example. But tell me how you would do this with a URL file. If you right-click on the file I cannot see any place where you can add ANY metadata.

It isn't exposed in the GUI. NTFS supports "streams" which allow you to programmatically read & write arbitrary data into a part of the file that is normally hidden from file I/O operations. You have to know that they're there to make use of them.

BTW, having a database does not magically make adding new fields any easier. Adding a new column to a table is an extremely disruptive change, requiring lots of records to be re-organized on disk and re-indexed.

mbluett wrote:All applications can easily make use of the same data. Currently, this is not easily possible.

Sure it is. You just need to have a common file format or plug-in architecture to allow different apps to read the same file. This is why we have standard file formats like PDF, jpeg, html, etc. A database does not magically make this easier. Each piece of data has some purpose, structure, and semantics that require interpretation. The database knows what BLOBs are, but it doesn't understand what's inside of them. That's still the applications' job. Database, file system, to-may-to, to-mah-to!

mbluett wrote:Databases have to be organized for them to work efficiently. One of the standard design methods in databases is to reduce redundancy as much as possible: It's called "normalizing" a database.

Have you ever tried designing a normalized schema that will take into account every single type of data a user could possibly, ever, be interested in using, including those that haven't even been invented yet?

mbluett wrote:That's great that OS X is that easy to use. However, most of the computer users of the world don't use OS X. In other words it makes no sense to talk of O/S's that most of the general public don't use. My desire is not offend you, but the reality of it is that MS O/S's, unfortunately, are the majority. To try and convert them to OS X will never happen. If it was going to happen it would have already.

I'm perfectly ok with that, for several reasons, but let me just say one of them: Diversity of OSes is much better for the global computing infrastructure than a monoculture, from a security point of view. No one OS should dominate IMO, not even one as usable as OS X. But having real competition for Windows in the consumer space is a good thing for everyone (including Microsoft, believe it or not).

Anyway, I'm not trying to advocate OS X, just point out that a lot of your usability goals have already been met with existing technology. Maybe you should consider OS X as a nice source of ideas for your own projects. Just don't make Apple's lawyers angry.

mbluett wrote:What is required is a radical new design that makes it so easy for the general public as well as free (or darn close to it) that they would not hesitate. This maybe a tall order and it maybe that none of us will ever accomplish it. But we have to try.

I can't argue this point without getting into economics, so I won't bother.

mbluett wrote:The indexing file may stay open all the time, but the files that are being searched are not.

So? The index contains everything you need to find the file. Why would you need to open any file other than the index, and the file you ultimately find?

mbluett wrote:Again, there is another cudos for OS X. However, how do we convince the public to switch? Why hasn't this happened if OS X is so great.

Lots of reasons... The price of Apple hardware, the perceived hassle of switching from Windows, the fact that until two years ago, you couldn't reliably run Windows on a Mac, the fact that it takes time to chip away at Microsoft's huge installed base, etc. However, they are making great advances in consumer market share. It just hasn't reached critical mass yet. It's grown at a much faster pace than usage of desktop Linux, though. That says a lot IMO.

mbluett wrote:I don't think you give the volunteer engineer's of the world enough credit. I refuse to accept that they are that bad.

I meant all engineers, not just volunteer ones. Go through any thread like this on OSDev and count how many people claim to know what's best for "the user". How many such people have hard data to back up their claims? How many have a background in human psychology and HCI? Usability experts exist for a reason -- because engineers are not like other people, but most of us refuse to admit it!

mbluett wrote:For example, why doesn't Apple go to all the hardware vendors and offer them money (or some other deal) so that they will provide OS X with their hardware?

Apple is a hardware company. That's where their profits come from. Software for them is a value-add -- a way to create a compelling reason to buy their hardware. They are very successful with this business model, not just with the Mac but also with the iPod and now the iPhone. They sell widgets, not software licenses.

Brendan wrote:
To estimate how useful metadata is, see how many attempts it takes you to find a query for Google that finds less than 20 files including at least 5 (of the 7) Pentium 4 errata documents.

I tried about 20 queries before I succeeded, but I also spent 10 minutes looking through Google's documentation (advanced search and advanced operators) to narrow down the list. After you've tried, here's my best attempt: Google...

It takes me 5 mouse clicks to find "info/cpu/intel/pent4/errata/24919966.pdf" from a blank desktop. Unless Mbluett's SQL searches can improve that, then it's not making the OS easier to use for me, and probably not making the OS easier to use for a lot of other people too.

There are a number of issues here:

1. The fact that you had to hunt through various documents just means that Google does not search inside those
documents for you. That problem is not an issue with an O/S database search.

2. Another problem in making comparisons to Google searches is that your search results greatly depend on the websites
ability to organize information so that the public can find what they are looking for. There is a HUGE amount of
inconsistency in this department. As well, there is a HUGE amount of duplication of the same articles or articles that
make reference to the article you are looking for.

These issues can be overcome in a local database.

When you do this from your desktop, what are you searching for? The same thing as you searched for on Google? If so, and you happen to have this document socked away on your HD, then comparing the Google search to a search from your desktop is a little unfair, don't you think?

I am not saying I can improve on finding documents. The reason for using a database is not just to provide searching capability. It has a number of other useful features.

For example:

1. Whole sentences that occur in multiple documents can be reduced to one copy.

You can't do that with the current file structure (at least not easily).

One advantage to this is it would reduce the amount of time to accomplish a search. Another is that it is very fast to
present a list of documents this sentence occurs in. The amount of time to do this with the conventional file system
is not near as fast. I realize this time difference would be small given the fast HDs these days; however, instant list
production is much better than 10 sec (or longer) list production.

2. The organizing is done by the database, not so much by the user.

Today you have to organize your files manually. Most of the time this just never occurs for the general public. This is a
significant issue and that is why there are a fair number of applications that have been written to provide a way of
viewing files, that are spread all over the place, in one concise view. The problem is the MS O/S's don't do a very good
job of this.

Also, consider the problem where copies upon copies are made (potentially by accident). I have seen this occur many
times. In many cases, the users don't know what they can delete and what they can't. The clutter problem just gets
worse and worse. With a database, this would never occur, because the database would prevent it. There is no reason to
make a copy of anything unless you are performing a backup or making a copy for someone else on a thumb drive, for
example.

3. Text within files can be indexed.

Current O/S's don't do this resulting in searches taking much, much longer. As an example, when I am searching for a
particular function call in a bunch of code files that is part of a programming project, in some cases I can go and have a
cup of coffee before the search completes. This search would be almost instantaneous in a database. Even if the data
was not indexed it would be faster. By the way, the search was performed on a Pentium 4 (2.66Ghz) with 2 Gig of RAM
and a 7200RPM SATA HD with 16MB buffer. Not the fastest, but should be quite adequate for accomplishing such a
task.

These are advantages and I am sure, in time, I could come up with more.

M-Saunders wrote:

mbluett wrote:For example, why doesn't Apple go to all the hardware vendors and offer them money (or some other deal) so that they will provide OS X with their hardware?

Apple wouldn't even need to offer any money, I reckon. There are plenty of companies which'd love to sell OS X machines. Just look at Psystar Apple experimented with licensing the OS a while ago, and it didn't work out. Apple is doing very well right now, and has no need to risk a drastic change to its business model.

M

If Apple was doing really well, why do they spend so much time and money degrading MS in TV adds?

Besides, companies are never happy unless they have the lion's share of the market.

mbluett wrote:If Apple was doing really well, why do they spend so much time and money degrading MS in TV adds?

Is that a serious reply? You're taking an advertising strategy as some kind of indication of sales performance? You need to look at Apple's market share gains over the last five years before making any further comments

The company is doing extremely well, and has absolutely no need to release OS X to the clone vendors. As much as we think it'd be cool, we are ultimately armchair pundits and Apple's team of bean counters will have contemplated this option a zillion times. Their current strategy is working very effectively -- so it's pointless for us, without all the stats and plans and knowledge, to comment on this unless Apple gets into the doldrums and desperately needs a major change of direction.

M

Colonel Kernel wrote:
Apple is a hardware company. That's where their profits come from. Software for them is a value-add -- a way to create a compelling reason to buy their hardware. They are very successful with this business model, not just with the Mac but also with the iPod and now the iPhone. They sell widgets, not software licenses.

I agree with you. As a result, we can never expect Apple to supercede MS unless they can convince the market place that their hardware is the best. Despite amazing innovation, they still haven't succeeded in doing that. I can only assume it has something to do with the price. Why do people keep buying Windows machines?

I know lots of answers, I am curious about yours.

M-Saunders wrote:

mbluett wrote:If Apple was doing really well, why do they spend so much time and money degrading MS in TV adds?

Is that a serious reply? You're taking an advertising strategy as some kind of indication of sales performance? You need to look at Apple's market share gains over the last five years before making any further comments

The company is doing extremely well, and has absolutely no need to release OS X to the clone vendors. As much as we think it'd be cool, we are ultimately armchair pundits and Apple's team of bean counters will have contemplated this option a zillion times. Their current strategy is working very effectively -- so it's pointless for us, without all the stats and plans and knowledge, to comment on this unless Apple gets into the doldrums and desperately needs a major change of direction.

M

Yes, it is a serious reply. Regardless of what I think, I again ask you, why do they spend so much time and money degrading MS in TV adds?

mbluett wrote:Yes, it is a serious reply. Regardless of what I think, I again ask you, why do they spend so much time and money degrading MS in TV adds?

Umm, because the company wants to keep improving its marketshare instead of standing still? Apple is aware of the widespread dissatisfaction with Vista and is capitalising on that, like any company would in a similar position. You may not like the ads, but they know they're on to something and have an effective hook with this approach.

It doesn't mean they're not doing well, as your original post seemed to imply. They're doing extremely well, and also know how to capitalise on a slip-up by a competitor. Those two things are not mutually exclusive.

M