XPost: comp.os.linux.advocacy   
   From: brock.mcnuggets@gmail.com   
      
   On Jan 22, 2026 at 1:10:02 PM MST, "candycanearter07" wrote   
   :   
      
   > Brock McNuggets  wrote at 20:17 this Tuesday   
   (GMT):   
   >> On Jan 20, 2026 at 9:53:59 AM MST, "Chris Ahlstrom" wrote   
   >> <10kobv9$1bonr$2@dont-email.me>:   
   >>   
   >>> Brock McNuggets wrote this post by blinking in Morse code:   
   >>>   
   >>>> On Jan 20, 2026 at 7:50:03 AM MST, "candycanearter07" wrote   
   >>>> :   
   >>>>   
   >>>>> Brock McNuggets  wrote at 06:06 this Sunday   
   (GMT):   
   >>>>>> On Jan 17, 2026 at 10:27:14 PM MST, "Gremlin" wrote   
   >>>>>> :   
   >>>>>>   
   >>>>>>> Brock McNuggets    
   >>>>>>> news:696c2034$1$20$882e4bbb@reader.netnews.com Sat, 17 Jan 2026   
   23:50:12   
   >>>>>>> GMT in comp.os.linux.advocacy, wrote:   
   >>>>>>>   
   >>>>>>>> On Jan 17, 2026 at 3:47:39 PM MST, "Gremlin" wrote   
   >>>>>>>> :   
   >>>>> [snip]   
   >>>>>>>>>  MS was actively discouraging the use of .INI files   
   >>>>>>>>> from Windows 95. They wanted you using the centralized registry   
   >>>>>>>>> instead.   
   >>>>>>>>   
   >>>>>>>> Yes... what a pain.   
   >>>>>>>   
   >>>>>>> It could be if you weren't very familiar with it.   
   >>>>>>   
   >>>>>> I prefer the INI or stand alone preferences system. Especially when   
   they are   
   >>>>>> stored in a logical location they make troubleshooting easier.   
   >>>>>   
   >>>>> I honestly never really got the registry. For system settings, fine, I   
   can   
   >>>>> get wanting to use a binary format like that. For user options, it just   
   >>>>> makes it harder to access, change, backup, etc... and is inherently not   
   >>>>> cross-platform.   
   >>>>   
   >>>> Agreed.   
   >>>>   
   >>>>> The only benefit I can think of would be having   
   >>>>> persistent user settings, and that can easily be achieved by storing   
   >>>>> user settings in %AppData% and/or not deleting it with the built in   
   >>>>> uninstaller.   
   >>>>> [snip]   
   >>>>   
   >>>> I like how macOS does it... a Preferences folder with files. Apple has   
   changed   
   >>>> it a bit so it is cached which might help in some ways but makes   
   >>>> troubleshooting a bit harder. Not exactly sure how Linux does it.   
   >>>   
   >>> It can vary, but in general: sample config files reside in   
   >>> /usr/share/appname, the system-wide config file reside in   
   >>> /etc/appname, user-specific overrides of the configuration are in   
   >>> /home/username/.config/appname or are stored as "rc" or "conf"   
   >>> files whose names start with ".".   
   >>>   
   >>> User-specific/app-specific state files (settings) are in   
   >>> /home/user/.local/share/appname ... or somewhere thereabouts :-D.   
   >>>   
   >>> Arch Linux has slightly different conventions, a bit like   
   >>> FreeBSD's.   
   >>>   
   >>> It's a bit krufty from having been built up over the years, but   
   >>> one gets used to it, just as one gets used to Window's Registry   
   >>> and the locations for 32 vs 64-bit Registry entries.   
   >>   
   >> I know I have looked at SOME of those over the years but always have to look   
   >> up where they all are. Not a weakness of Linux, just an artifact of my not   
   >> using it as much as I use macOS, and some level of macOS being more   
   consistent   
   >> in that are. Preference files (.plist) are either in:   
   >>   
   >> ~/Library/Preferences/   
   >>   
   >> or   
   >>   
   >> /Library/Preferences/   
   >>   
   >> While rarely something I have worked with, they can also be:   
   >>   
   >> /Library/Managed Preferences/   
   >>   
   >> In more modern macOS versions the .plist files can be cached, which might   
   make   
   >> things faster but also can complicate troubleshooting.   
   >>   
   >> Thanks for your info.   
   >>   
   >> Side note: Unlikely, but do you have a relative name Dale? If so you might   
   >> want to contact me offline... I am getting calls about him (maybe he had my   
   >> number sometime in the past?). Will not discuss publicly.   
   >   
   >   
   > I imagine its more consistent on Mac because of XCode, and file access   
   > permissions.   
      
   I am NOT a developer, but from what I understand Xcode doesn’t really drive   
   that —- it’s more Apple (largely) enforcing preference APIs and directory   
   conventions at the OS level. Linux has conventions too, but they're optional   
   rather than mandatory. Again, take all that with a grain of salt... outside of   
   my area of expertise.   
      
      
   --   
   It's impossible for someone who is at war with themselves to be at peace with   
   you.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)