Nikon FDUtility
in [Scanners]
|
From: Surfer! on 5 Feb 2006 05:05 In message <dsd9u1thrk3tia5nsrilp4kb5ggl159pj3(a)4ax.com>, Don <phoney.email(a)yahoo.com> writes >On Fri, 3 Feb 2006 20:54:29 +0000, Surfer! <surfer(a)127.0.0.1> wrote: > >>>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. > >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. -- Surfer! Email to: ramwater at uk2 dot net
From: Marjolein Katsma on 9 Feb 2006 07:37 Don (phoney.email(a)yahoo.com) wrote in news:dsd9u1thrk3tia5nsrilp4kb5ggl159pj3(a)4ax.com: > 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. :) -- Marjolein Katsma *Help with HomeSite/Studio: http://hshelp.com/ *Travel blog: http://blog.iamback.com/ *Spam reporting addresses: http://banspam.javawoman.com/report3.html
From: Don on 10 Feb 2006 11:18 On 09 Feb 2006 12:37:30 GMT, Marjolein Katsma <nobody(a)example.net> wrote: >Don (phoney.email(a)yahoo.com) wrote in >news:dsd9u1thrk3tia5nsrilp4kb5ggl159pj3(a)4ax.com: > >> 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(a)yahoo.com> wrote: >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. >> 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.
From: Marjolein Katsma on 10 Feb 2006 12:48 Don (phoney.email(a)yahoo.com) wrote in news:rj9pu1pvbookqc2p4n9bub0454psv3ut2h(a)4ax.com: >>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 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). >>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. Applications, if re-written, would. Humans would not - and they can't be rewritten. ;-) -- Marjolein Katsma *Help with HomeSite/Studio: http://hshelp.com/ *Travel blog: http://blog.iamback.com/ *Spam reporting addresses: http://banspam.javawoman.com/report3.html
From: Don on 11 Feb 2006 10:03
On 10 Feb 2006 17:48:22 GMT, Marjolein Katsma <nobody(a)example.net> wrote: >>>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 > >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. >>>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. > >Applications, if re-written, would. Humans would not - and they can't be >rewritten. ;-) Yes, they can! ;o) It's called education. Don. |