I wasn't meaning to say that Mac's system is like Windows. I was saying it suffers from similar problems:
# Centralizing configurations makes it difficult to back up and recover individual applications. /Applications, ~/Library, ~/Library/Application Support, ~/Library/Preferences # In practice, manual manipulation of the registry might be required where applications that are using the Registry do not implement configuration through their user interface. Secrets. # Because the Registry structure is contained in binary files, damage to it is difficult to repair. Because information required for loading device drivers is stored in the registry[25], a damaged registry may prevent a Windows system from booting successfully. Note that damaged configuration files have the same result to other operating systems, but these can be repaired more easily using a text editor. Some plists are in binary form and must be converted to XML before being editable. # Any application that does not uninstall properly, or does not have an uninstaller, can leave entries in the registry. Over time the computer suffers "software rot" as the registry fills with left-over and possibly incorrect entries. Preferences, receipts, application data = rot. # Installers and uninstallers become complex, much more than just copying files into a folder. Stupid people like Adobe that don't use .pkg. Stupid people that use .pkg to transport a .app with no other data. # Since an application's configuration is centralized away from the application itself, it is often not possible to copy installed applications that use the Registry to another computer. This means that software usually has to be reinstalled from original media on a computer upgrade or rebuild, rather than just copying the user and software folder to the new computer. See "Centralizing configurations". On Thu, Nov 19, 2009 at 5:23 PM, Scott Granneman <[email protected]> wrote: > Secrets was created to expose hidden Preferences that one normally accesses > via the command line because they're not present in the plist files. > > Plist files are just XML files. I can read or edit or script them with the > normal bash tools; in fact, I've done just that before. No biggie. > > Also, the plist files are yes, stored in ~/Library, but that's hardly the > same thing as Gconf or the Registry. > > Scott > -- > R. Scott Granneman > [email protected] ~ www.granneman.com > Full list of publications @ http://www.granneman.com/publications > My new book: Google Apps Deciphered @ http://www.granneman.com/books > > "It matters not whether you win or lose; what matters is whether I win or > lose." > ---Darrin Weinberg > > On Nov 19, 2009, at 12:17 PM, Nathan Nutter wrote: > >> Mac OS X does the same thing with preferences. Data is stored in a >> data directory, in a preferences file, and then finally the >> application itself. Preference files are just as mysterious, hence the >> creation of Secrets. >> >> So I think the real question is why the three biggest operating >> systems all use centralized storage of preferences? >> >> Spinning some of those disadvantages: >> >> single point of failure = single point of troubleshooting >> centralized configuration = makes it *easier* to backup data that is >> actually unique to the user >> >> I don't know about you but I could care less about backing up my >> /Applications directory but you can bet I back up ~/Library! >> >> --Nathan >> >> On Thu, Nov 19, 2009 at 11:03 AM, Scott Granneman <[email protected]> >> wrote: >>> I guess my first question would be, why replace conf files? They're >>> ASCII, so they're readable & writable & scriptable by just about >>> anything. They're easily portable & copyable. They work. >>> >>> The Windows Registry is a big fat mess. Wikipedia goes into detail at >>> http://en.wikipedia.org/wiki/Windows_registry#Advantages_and_Disadvantages: >>> >>> "# Centralizing configurations makes it difficult to back up and >>> recover individual applications. >>> >>> # In practice, manual manipulation of the registry might be required >>> where applications that are using the Registry do not implement >>> configuration through their user interface. >>> >>> # Because the Registry structure is contained in binary files, damage >>> to it is difficult to repair. Because information required for loading >>> device drivers is stored in the registry[25], a damaged registry may >>> prevent a Windows system from booting successfully. Note that damaged >>> configuration files have the same result to other operating systems, >>> but these can be repaired more easily using a text editor. >>> >>> # Any application that does not uninstall properly, or does not have >>> an uninstaller, can leave entries in the registry. Over time the >>> computer suffers "software rot" as the registry fills with left-over >>> and possibly incorrect entries. >>> >>> # Installers and uninstallers become complex, much more than just >>> copying files into a folder. >>> >>> # Applications that make use of the registry to store and retrieve >>> their settings are unsuitable for use on portable devices used to >>> carry applications from one system to another. >>> >>> # Since an application's configuration is centralized away from the >>> application itself, it is often not possible to copy installed >>> applications that use the Registry to another computer. This means >>> that software usually has to be reinstalled from original media on a >>> computer upgrade or rebuild, rather than just copying the user and >>> software folder to the new computer. >>> >>> # The Windows Registry is said to be a single point of failure.[26][27] >>> >>> # There are thousands upon thousands of different keys used by many >>> different Windows applications, and vendors rarely, if ever, document >>> the purpose of these keys to the outside world. Such information is >>> useful to the power user or system administrator." >>> >>> Now, granted, the same article, at >>> http://en.wikipedia.org/wiki/Windows_registry#Equivalents_in_other_operating_systems, >>> does say this about Gconf: >>> >>> "However, in GConf, all application settings are stored in separate >>> files, thereby eliminating a single point of failure." >>> >>> Great. But what about all the other criticisms? They seem apropos to me. >>> >>> The point being, Gconf was a bad idea to begin with. And on top of >>> being a bad idea, it sounds like it was poorly implemented. Hey, now >>> we're approaching Microsoft levels of incompetence! Well done. >>> >>> Scott >>> -- >>> R. Scott Granneman >>> [email protected] ~ www.granneman.com >>> Full list of publications @ http://www.granneman.com/publications >>> My new book: Google Apps Deciphered @ http://www.granneman.com/books >>> >>> "I read about an Eskimo hunter who asked the local missionary priest, >>> 'If I did not know about God and sin, would I go to hell?' 'No,' said >>> the priest, 'not if you did not know.' 'Then why,' asked the Eskimo >>> earnestly, 'did you tell me?'" >>> ---Annie Dillard >>> >>> On Wed, Nov 18, 2009 at 11:03 AM, Robert Citek <[email protected]> >>> wrote: >>>> My guess is that it is supposed to be an auxiliary to (or replacement >>>> for) the ~/.*rc files. That's not a bad thing, if done well. gconf >>>> doesn't seem to be done well. Or if it is done well, it is poorly >>>> documented. >>>> >>>> Regards, >>>> - Robert >>>> >>>> On Wed, Nov 18, 2009 at 11:24 AM, Scott Granneman <[email protected]> >>>> wrote: >>>>> Gconf was one of the worst things GNOME ever did. After years of knowing >>>>> how complex, user-hostile, & fragile the Windows Registry was, GNOME >>>>> decided to implement the same kind of thing for Linux. Brilliant! >>>> >>>> -- >>>> Central West End Linux Users Group (via Google Groups) >>>> Main page: http://www.cwelug.org >>>> To post: [email protected] >>>> To subscribe: [email protected] >>>> To unsubscribe: [email protected] >>>> More options: http://groups.google.com/group/cwelug >>>> >>> >>> -- >>> Central West End Linux Users Group (via Google Groups) >>> Main page: http://www.cwelug.org >>> To post: [email protected] >>> To subscribe: [email protected] >>> To unsubscribe: [email protected] >>> More options: http://groups.google.com/group/cwelug >>> >> >> -- >> Central West End Linux Users Group (via Google Groups) >> Main page: http://www.cwelug.org >> To post: [email protected] >> To subscribe: [email protected] >> To unsubscribe: [email protected] >> More options: http://groups.google.com/group/cwelug > > -- > Central West End Linux Users Group (via Google Groups) > Main page: http://www.cwelug.org > To post: [email protected] > To subscribe: [email protected] > To unsubscribe: [email protected] > More options: http://groups.google.com/group/cwelug > -- Central West End Linux Users Group (via Google Groups) Main page: http://www.cwelug.org To post: [email protected] To subscribe: [email protected] To unsubscribe: [email protected] More options: http://groups.google.com/group/cwelug
