In message <[EMAIL PROTECTED]>, Ross Ridge wrote: > Ross Ridge wrote: > >> As opposed to the file system being the single point failure? > > Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote: >>The file system is involved regardless. But leaving out an additional >>layer of failure on top of it does make things more robust, yes. > > No, that doesn't follow. Having TCP as layer on top of IP doesn't make > the Internet less robust even though it's additional point of failure.
Which is a vacuous example. > For the matter, settings files also have an additional layer of failure > in the code that intreprets and updates the setting files. See, it's clear you're too accustomed to the Windows mentality: under "settings files" you're subsuming system config files, read-only shared data, writeable data and per-user prefs--a whole bunch of things. Recognize the distinction between these, and the fact that they need to be kept distinct, and you can see how your assertions no longer hold up. >>The file system already has provisions for simultaneous access by multiple >>processes, journalling, integrity checking etc; implementing a "registry" >>on top of this means reinventing a whole separate API and architecture >>that has to provide this sort of thing, or leave it out and suffer the >>well-known consequences. > > If settings files benefit from those provisions of the filesystem then > so does the registry. If the registry needs additional provisions so > do settings files for the same reasons. Quite different reasons, as I pointed out above. >>Plus the fact that the Windows Registry is actually a munging together of >>things that are kept in quite separate places in Unix/Linux: system config >>files versus shared read-only data versus writable data versus user prefs >>etc. Putting all these things together just makes it more likely that >>somebody will clobber something it didn't mean to. > > Nope. Microsoft implemented the registry because users were clobbering > things they weren't ment to, and it succeded in making it a less likely > occurence. <http://www.google.co.nz/search?q=registry+damage+prone> -- http://mail.python.org/mailman/listinfo/python-list
