Nikon FDUtility

[Marjolein Katsma]

Don ([email protected]) wrote in

Think about it. How are different desktop settings saved for different
users?

In *different* lcoations - definitely not the same!

Yes, each user has a separate directory for their system settings
(e.g. desktop, etc) usually called the same as their login name.

You just called that "undisciplined and incompetent"! Which is why I asked
you to give me a conctete example of using the *same* location for
*different* user's data. What you come up with now is the exact opposite.

Never mind...

 

[Surfer!]

Surfer! ([email protected]) wrote in view.co.uk:


Of course - each user their own branch (no matter what it's under,
really): their data goes in *separate* locations.

I said before:

Me > No proof at all since for many programs different users can have
Me > their *own* settings; they need to be kept separate, of course.
Me > Which is proof settings *are* user data. ;-)

To which Don replied:

Don > No, that's a proof of undisciplined and incompetent so-called
Don > "programmers".

I fail to see how keeping different user's data separate is
"undiciplined" or "incompetent" - NOT keeping them separate would be!

Me too. It seems fine to me, despite the arguments of the semantics of
'My' that we seem to be able to have.

Exactly. Quite competent, in fact. ;-)



Gosh - that's promising!

I'm not sure that two letters and a space are really worth that much...

All such firms have no chance with me - I consider them equally
childish. http://yourdictionary.com now, that's a clever site! (It
really is, too)

Now surely 'your' is just as stupid as 'my'? It's the computer talking
to me? I prefer a person-oriented view of things. It's *my* computer,
I am not *it's* user, it's *my* stuff on it, *my* phone line it uses,
*my* money that buys bits & pieces for it, and *me* that gets aggravated
if they play up. And, of course, it's *me* that spends ages cleaning
slides before scanning, *me* that has to unjam the slide feeder and
(wild and desperate attempt to get back on-topic here!) *me* that was
struggling without the Nikon FDUtility.

BTW *my* spell checker wants to turn that to Nikon Futility, and it's
*me* that has stopped it doing that.

 

[Don]

The ring of "dumbed down to stupidity". Maybe appeals to people who like
to be pampered.

You get no argument from me, there! And I sympathize fully!

But, regrettably, that's how things work in the free marketplace. You
aim for the lowest common denominator in order to appeal to the
largest possible audience. If in the process you annoy a few
sophisticates, so be it! Once you have monopoly they'll be forced to
grudgingly use it.

I think it was Ford who said: "Never overestimate the American
public". Take out "American" and it becomes a generic rule.

BTW, it was definitely Ford who said (referring to Model-T):

"You can have it in any color, as long as it's black!"

;o)

Don.

 

[Don]

You just called that "undisciplined and incompetent"! Which is why I asked
you to give me a conctete example of using the *same* location for
*different* user's data. What you come up with now is the exact opposite.

That's not what "undisciplined and incompetent" referred to. It
referred to lumping system settings and user data in the same
directory.

NOTE: Read the parallel message on two meanings of "user data". From
the system point of view "user data" refers to the data *about* a
user, from the user point of view "user data" refers to data *created
by* the user themselves (not system settings).

Conceptually, those two are poles apart and lumping them together is
undisciplined and incompetent.

I mean, just look at the name "Documents and Settings". It's totally
meaningless and pointless. They may have just as well called it "All
and Sundry" or "Everything"!

Don.

 

[Surfer!]

I mean, just look at the name "Documents and Settings". It's totally
meaningless and pointless. They may have just as well called it "All
and Sundry" or "Everything"!

So given that there can be different system settings for different
users, how do you suggest it should have been done? It seems quite
logical to me to put everything to do with a given user in one place.
Now if all those things were dropped in a single big mess in a single
directory you would be right - but it isn't. There is quite a
complicated directory structure and (for example) desktop icons are held
in a different place to the contents of the 'Send To' drop-down menu.

 

[Don]

So given that there can be different system settings for different
users, how do you suggest it should have been done? It seems quite
logical to me to put everything to do with a given user in one place.

Which exposes another reason why "Documents and Settings" is a totally
ridiculous name. In addition to what I wrote before, if you look
inside you'll see that it contains a number of *user* directories.
Therefore (within this context) it should really be called "Users" or
whatever.

But at its most basic (literal!) level this is really a question about
data base design. The same principles apply especially if we're
talking about hierarchical databases.

At the most absolute extreme (relational databases) each data item
will be defined separately and then combined using logical
relationships. That's the theory. Even though that's the cleanest and
most flexible design, in practice, almost nobody does that because of
the overhead. So each design is compromised to satisfy immediate
requirements and maintain a balance between consistency and
performance. So much for generalities to establish the context...

Specifically - one answer to your question - a (!) possible option is
to have two top level directories e.g. User Data and System Settings,
or whatever. Within each define another level for each user. In other
words, turn the current design on its head. Why is that "better"?
Because we have cleanly separated system and user data. This means we
can back them up separately, for example. Now, you may be bothered
that you have two user sub-directories in different parent directories
but that can be reconciled with judicious use of symbolic links, etc.

What those contortions clearly illustrate is that we are talking about
the wrong question because it assumes a certain paradigm as a given
and then tries to fit a concept within this (flawed) paradigm. My
answer to that would be to go a level up (meta context) and fix the
paradigm instead of trying to fix its consequences. Why is the
paradigm wrong? For one, because Windows is a hodge-podge of ad hoc
band-aids instead of a clean design from the ground up.

Do note that all of the above is very simplistic and superficial
because this subject is quite complex going to the core of OS design.
Anyway, we're now miles away from scanning... ;o)

Don.

 

[Surfer!]

Which exposes another reason why "Documents and Settings" is a totally
ridiculous name. In addition to what I wrote before, if you look
inside you'll see that it contains a number of *user* directories.
Therefore (within this context) it should really be called "Users" or
whatever.

It's not as obvious and simple as (say) sales order processing. Hence,
you have a choice of top-level directories - by users, or by system &
documents etc. It wouldn't surprise me if there were a lot of heated
discussions about this at Microsoft when Win2K/XP was being designed.

However, with XP a lot of 'system settings' can be different for each
user (for example the desktop wallpaper), so although it's a kind of
system setting it's *also* user data. That's why I feel the current
structure is fine, and is clearly named.

You also need to remember that by default, the 'My Documents' desktop
icon does genuinely point to that user's documents - C:\Documents and
Settings\<user>\My documents.

If you redesign to have 'settings' and 'documents' you will end up with
exactly the same kind of things but coming from the other direction.
Unless you redefine settings that are user-specific as data rather than
settings, you will still end up with having to specify which user that
setting is for - in which case it might as well be in the user's
directory instead of some other directory in some other place.

 

[Marjolein Katsma]

Don ([email protected]) wrote in

But at its most basic (literal!) level this is really a question about
data base design. The same principles apply especially if we're
talking about hierarchical databases.

At the most absolute extreme (relational databases) each data item
will be defined separately and then combined using logical
relationships. That's the theory.

It is indeed comparable to database design. And a hierarchical database
is possibly the closest parallel (although with adding symbolic
links/shortcuts you end up with something more like a network database).
So why come up with the relational model? It does *not* apply at all,
it's a totally different organization.

Any file system that uses nested directories is fundamentally unlike a
relational database and very like a hierarchical one. The various
Windows file systems are just examples. So to design a logical structure
in a hierarchical "world" you need techniques similar to those designing
a hierarchical database.Clearly Windows is doing that differently than
the various *nix systems, for instance.

What those contortions clearly illustrate is that we are talking about
the wrong question because it assumes a certain paradigm as a given
and then tries to fit a concept within this (flawed) paradigm. My
answer to that would be to go a level up (meta context) and fix the
paradigm instead of trying to fix its consequences.

Here we agree. It would, logically, be the best thing to do. Except
Windows would soon lose a lot of customers is MS actually did that ...
people, and applications, would no longer be able to find their data!
Backwards compatibility is something you cannot ignore as a software
maker, and even less as an OS maker.

 

[Don]

Don ([email protected]) wrote in


It is indeed comparable to database design. And a hierarchical database
is possibly the closest parallel (although with adding symbolic
links/shortcuts you end up with something more like a network database).
So why come up with the relational model? It does *not* apply at all,
it's a totally different organization.

No, it's not! A relational data base model is based on logical indices
and a symbolic link (i.e. a shortcut) could (if stretched) be
(mis)used as an index due to its indirect nature. It would be *very*
convoluted, but possible. Which is why I wrote:

--- start ---

Now, you may be bothered
that you have two user sub-directories in different parent directories
but that can be reconciled with judicious use of symbolic links, etc.

--- end ---

Clearly Windows is doing that differently than
the various *nix systems, for instance.

Indeed! But that's what monopolies do. Once a monopoly is established
the onus changes completely i.e, it's revered. Clear code and
efficient design are no longer a plus but a huge minus (potentially
opening a door for up-and-coming would-be competition). So design
obscurity and convoluted coding are a must to maximize the proprietary
nature of the OS and thereby be a "moving target". Of course, that
disadvantages users immensely, but users do not factor in a
monopolist's calculations at all because they have no choice.

Here we agree. It would, logically, be the best thing to do. Except
Windows would soon lose a lot of customers is MS actually did that ...
people, and applications, would no longer be able to find their data!

Oh, but they would, if implemented properly. As the above paragraph
outlines that's not what a monopolist is after. Indeed, it's the very
last thing in the world they want!! Why make it easier for the
up-and-coming potential competitor?

Backwards compatibility is something you cannot ignore as a software
maker, and even less as an OS maker.

Especially when the goal is not to help the user but help maintain the
monopoly! ;o)

Don.

 

[Marjolein Katsma]

Don ([email protected]) wrote in

No, it's not! A relational data base model is based on logical indices

Eh? Where did you get the idea that a relational database is based on
"logical indices"?

And have you even considered *how* a hierarchical database has
similarities with hierarchical directories? Have you ever *used* a
hierarchical database system? I suspect not.

Symlinks and shortcuts would be crutches in both models - that's just an
extra layer. But directories have direct links to their parents. That's
exactly what you have in a hierarchical database - there's no such
concept in a relational model (you can implement it in data - but that's
not the same thing at all).

Oh, but they would, if implemented properly.

Applications, if re-written, would. Humans would not - and they can't be
rewritten. ;-)

 

[Don]

Eh? Where did you get the idea that a relational database is based on
"logical indices"?

And have you even considered *how* a hierarchical database has
similarities with hierarchical directories? Have you ever *used* a
hierarchical database system? I suspect not.

You would suspect wrong. Since you want to get personal, I've
programmed hierarchical databases probably before you were even born,
or at least shortly thereafter.

Applications, if re-written, would. Humans would not - and they can't be
rewritten. ;-)

Yes, they can! ;o) It's called education.

Don.

 

[Marjolein Katsma]

Don ([email protected]) wrote in

You would suspect wrong. Since you want to get personal, I've
programmed hierarchical databases probably before you were even born,
or at least shortly thereafter.

They didn't exist when I was born, and not for a long time after. In fact,
I was legally of age by the time IBM came public with IMS thopugh
development started a few years before. ;-)

So now I'm even more puzzled why you bring in relational databases when a
hierarchical model is clearly the best fit...

 

[Don]

So now I'm even more puzzled why you bring in relational databases when a
hierarchical model is clearly the best fit...

That's because you're locked into the MS "solution"/thinking.

Data can be encapsulated in many ways. That's what a (good) database
designer does. They're not swayed by how the data *looks* at first
blush but take the full context into consideration i.e. think
laterally.

The relational model is far more flexible than hierarchical and e.g.
therefore more likely to be future proof. To discount it a priori just
because the data may appear hierarchical is very shortsighted.

Don.

 

[Marjolein Katsma]

Don ([email protected]) wrote in

That's because you're locked into the MS "solution"/thinking.

I'm not locked into any OS/software manufacturer's thinking at alll -
I've worked with way too many OSs for that to happen. I am simply stting
that a file system that uses nested directories is more closely related
to a hierarchical database than to a relational one. That applies
equally to *nix as to MS OSs.

The relational model is far more flexible than hierarchical and e.g.
therefore more likely to be future proof.

On flexibility we agree - but it's not always the most efficient
solution.

To discount it a priori just because the data may appear hierarchical
is very shortsighted.

I'm not discounting anything. I'm merely comparing a hierarchical *file
system* with a hierarchical database, with its direct "links" to parents
and siblings. In a sense a file system *is* a database, it's just not
called that. ;-)

 

[Don]

I'm not locked into any OS/software manufacturer's thinking at alll -

Yes you are because you are not even considering the relational model.
Indeed, you can't even understand why I mentioned it showing how
locked you are into the hierarchical MS thinking.

I've worked with way too many OSs for that to happen. I am simply stting
that a file system that uses nested directories is more closely related
to a hierarchical database than to a relational one. That applies
equally to *nix as to MS OSs.

Which is all fine but not the point. The context was how bad MS design
is. Therefore, when looking for alternate designs the last thing a
good designer does is stay locked in the old paradigm.

On flexibility we agree - but it's not always the most efficient
solution.

Which is why the*full* context must be taken into account. And by
eliminating the relational model up front just because "it doesn't
fit" the hierarchical *appearance* of the registry (which itself is a
tiny part of the big picture!) you are not doing that.

I'm not discounting anything. I'm merely comparing a hierarchical *file
system* with a hierarchical database, with its direct "links" to parents
and siblings.

Didn't it occur to you that the hierarchical appearance of the
registry could be a *consequence* of the whole MS design? A good
analyst does not accept that design but looks at everything. That's
the whole point and why I mentioned the relational model.

Don.

 

[Marjolein Katsma]

Don ([email protected]) wrote in

Yes you are because you are not even considering the relational model.

I did consider teh relational model and rejected it as a poorer "fit" to
how a file system with a nested directory structure works. Nothing to do
with MS. Like I said, equally applicatble to hierarchical file systems
in *nix.

Indeed, you can't even understand why I mentioned it showing how
locked you are into the hierarchical MS thinking.

Indeed I can't. Because hierarchies are not MS' territory only - may OSs
use hierarchical file systems. So what's MS about it??

Which is all fine but not the point. The context was how bad MS design
is. Therefore, when looking for alternate designs the last thing a
good designer does is stay locked in the old paradigm.

Of course. But I wasn't "looking for alternate designs" at all - I was
looking for the best fit of a database system to *describe* a
hierarchical file system. And that still is a hierarchical database in
my book - as the best fit for *any* hierarchical file system (of which
there are many).

For an alternative system - it's possible a relational model may work;
but the problem here is efficiency. Relational database systems may be
flexible, but they're not always the most efficient systems for all
applications. And for a file system efficiency is critical.

Think about why hierarchical file system are so ubiquituos - MS is just
one among many, and in good company ;-)

Which is why the*full* context must be taken into account. And by
eliminating the relational model up front just because "it doesn't
fit" the hierarchical *appearance* of the registry (which itself is a
tiny part of the big picture!) you are not doing that.

I'm not eliminating anything, let alone "up front". It's *possible* that
a relational system (model) may be a "better" solution than a
hierarchical file system.

Didn't it occur to you that the hierarchical appearance of the
registry could be a *consequence* of the whole MS design?

No, because we were talking about file systems and their parallels with
database (system) models. In this context I wasn't considering the
appearance (which is what it is: appearance - technically it's more like
a network database) or the actual organization of the Registry at all.
The registry is a non-heirarchical database, implemented in the
hierarchical file system (just like any other database system
implemented in a DOS / Windows environment).

 

[Don]

I did consider teh relational model and rejected it as a poorer "fit" to
how a file system with a nested directory structure works.

Because you accepted the hierarchical model up front. That's what
"being locked into a design" means!

Instead of looking for a truly best design (no holds barred) you
limited your considerations to finding a "best fit" for an existing
design.

Indeed I can't. Because hierarchies are not MS' territory only - may OSs
use hierarchical file systems. So what's MS about it??

You're mixing up things. The hierarchies mentioned above are in the
context of the registry not a generic discussion.

Of course. But I wasn't "looking for alternate designs" at all - I was
looking for the best fit of a database system to *describe* a
hierarchical file system.

And that's exactly the problem!

Think about why hierarchical file system are so ubiquituos

Because most so-called data base designers are incompetent and/or
their superiors got there through the "Peter principle" and don't want
to rock the boat.

Germans have a saying which loosely translates into:

Excrement must taste good because 1 billion flies can't be wrong!

Ubiquity and/or popularity are not a sign of quality. Usually, it's
quite the opposite i.e. the lowest common denominator which appeals to
the numerically superior but intellectually inferior "great unwashed".

Don.

 

[Surfer!]

Instead of looking for a truly best design (no holds barred) you
limited your considerations to finding a "best fit" for an existing
design.

There is often no truly best design, and barring some holds is often a
good idea so that the final result can be understood by anyone with a
less than Einstein IQ.

 

[Marjolein Katsma]

Don ([email protected]) wrote in

Because you accepted the hierarchical model up front. That's what
"being locked into a design" means!

No - I only "accepted" that as a *fact* - the one we're comparing with.
I never said that was the best solution.

Instead of looking for a truly best design (no holds barred) you
limited your considerations to finding a "best fit" for an existing
design.

I'm not limiting my consideratoions at all. We have a file system and in
order for teh discussion want to discuss file systems in terms of
database models. It helps to find the best fit for the *current* model
first, before discussing a possible model for a new system. I maintain
that the best database model to describe a hierarchical file system is a
hierarchical database.

You're mixing up things. The hierarchies mentioned above are in the
context of the registry not a generic discussion.

Seems you forgot you were complaining about "Documents and Settings" in
the first place; that's not Registry - it's implemented in the file
system.

And that's exactly the problem!

No, merely a starting point. If you want to discuss file systems in
terms of database models you mneed to be able to discuss the current
system the same way.

Because most so-called data base designers are incompetent and/or
their superiors got there through the "Peter principle" and don't want
to rock the boat.

I don't think that's the reason (although true ;-)). Hierarchical file
systems existed before relational databases existed, let alone were
developed enough to be efficient enough to be even considered as a
replacement for a system that was very efficient already. If it ain't
broke, and all that.

 

[Don]

There is often no truly best design, and barring some holds is often a
good idea so that the final result can be understood by anyone with a
less than Einstein IQ.

That's a bit misleading because it mixes the absolute with the
relative. However, there always is a best design in either case.

Each design is (or, more accurately, should be) a function of its
respective context. Therefore, once that context is clearly and
comprehensively (!!) defined then there certainly is a best (relative)
design for that particular context. On other hand, in a "context-free"
environment (i.e. merely in theory) there is also a best (absolute)
design. The key, as always, is context. (Note the quotes around
"context-free" i.e. a lack of any specific context is also context!)

However, all that is very generic and not relevant in the context
(sic) in which I mentioned relational databases merely as an option to
be considered without a qualitative assessment or recommendation.

Don.