Re: Nikon FDUtility
- From: Don <phoney.email@xxxxxxxxx>
- Date: Fri, 10 Feb 2006 17:18:42 +0100
On 09 Feb 2006 12:37:30 GMT, Marjolein Katsma <nobody@xxxxxxxxxxx>
wrote:
Don (phoney.email@xxxxxxxxx) wrote in
news:dsd9u1thrk3tia5nsrilp4kb5ggl159pj3@xxxxxxx:
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.
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 ---
On Sat, 04 Feb 2006 16:07:57 +0100, Don <phoney.email@xxxxxxxxx>
wrote:
Now, you may be bothered--- end ---
that you have two user sub-directories in different parent directories
but that can be reconciled with judicious use of symbolic links, etc.
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.
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!
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.
.
- Follow-Ups:
- Re: Nikon FDUtility
- From: Marjolein Katsma
- Re: Nikon FDUtility
- References:
- Re: Nikon FDUtility
- From: Marjolein Katsma
- Re: Nikon FDUtility
- From: Don
- Re: Nikon FDUtility
- From: Marjolein Katsma
- Re: Nikon FDUtility
- From: Don
- Re: Nikon FDUtility
- From: Surfer!
- Re: Nikon FDUtility
- From: Don
- Re: Nikon FDUtility
- From: Marjolein Katsma
- Re: Nikon FDUtility
- Prev by Date: Re: Is the EPSON 4990 really 16 bit?
- Next by Date: Re: Nikon super coolscan 5000 ED B&W film compatabilites
- Previous by thread: Re: Nikon FDUtility
- Next by thread: Re: Nikon FDUtility
- Index(es):
Relevant Pages
|