home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.linux.advocacy      Torvalds farts & fans know what he ate      164,974 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 163,829 of 164,974   
   CrudeSausage to All   
   Re: The trouble with Mac apps vs. Linux    
   25 Jan 26 14:13:03   
   
   XPost: comp.sys.mac.advocacy   
   From: crude@sausa.ge   
      
   On Sun, 25 Jan 2026 00:50:09 -0000 (UTC), candycanearter07 wrote:   
      
   > CrudeSausage  wrote at 16:37 this Friday (GMT):   
   >> On Fri, 23 Jan 2026 16:10:07 -0000 (UTC), candycanearter07 wrote:   
   >>   
   >>> CrudeSausage  wrote at 23:14 this Tuesday (GMT):   
   >>>> On Tue, 20 Jan 2026 20:10:03 -0000 (UTC), candycanearter07 wrote:   
   >>>>   
   >>>>> CrudeSausage  wrote at 17:47 this Tuesday (GMT):   
   >>>>>> On Tue, 20 Jan 2026 16:39:27 +0000, vallor wrote:   
   >>>>>>   
   >>>>>>> So say you side-load a Mac app.  You usually get a .dmg which you   
   >>>>>>> mount,   
   >>>>>>> then drag the app folder on top of the handy alias for the system   
   >>>>>>> app folders.   
   >>>>>>>   
   >>>>>>> That's fine, but what if you want to uninstall?  There doesn't   
   >>>>>>> seem to be much of a package manager involved.   
   >>>>>>>   
   >>>>>>> But on Linux, apps are in packages that are tracked by the system.   
   >>>>>>> When you uninstall an app on Linux, the default is to take away   
   >>>>>>> the app without touching config files -- but with the apt/dpkg   
   >>>>>>> "purge" option, the package system will clean out the config   
   >>>>>>> files, too.   
   >>>>>>>   
   >>>>>>> (Not user dot-files though, those are yours to keep.)   
   >>>>>>   
   >>>>>> Generally, even after I purge an application in Linux, its settings   
   >>>>>> remain. You have to manually delete the folder in .config the same   
   >>>>>> way you would in any other operating system. Of course, it's a lot   
   >>>>>> easier to do on Linux since those folders are exactly where you   
   >>>>>> would expect them to be, not lost in the registry or some obscure   
   >>>>>> folder.   
   >>>>>   
   >>>>>   
   >>>>> Unfortunately, theres a LOT of applications that dump everything in   
   >>>>> the home folder instead of just using the prebuilt stuff. Still not   
   >>>>> HARD to find, but tis very annoying.   
   >>>>> My person home folder has over 200 folders.   
   >>>>   
   >>>> I don't have that many, but at least I know that the ones I do have   
   >>>> were created by me. I never found anything as annoying as every   
   >>>> Windows program deciding that it would create a folder for itself in   
   >>>> your "My Documents" folder. My understanding was that this was   
   >>>> supposed to be a personal folder; why programs were doing anything in   
   >>>> there was beyond me. It bothered me enough that I made an actual   
   >>>> "Personal" folder inside of "My Documents" just to avoid the garbage.   
   >>>   
   >>>   
   >>> A lot of programs, especially ones originally written for Windows,   
   >>> tend to do that, at least for me.   
   >>   
   >> It's a common behaviour, and one that annoyed me to no end. The very   
   >> fact that the folder is called "_My_ Documents" should mean that   
   >> third-party applications would stay out of it. There should be a   
   >> directory in which applications can create a subdirectory, not   
   >> interfere with the user's own folders.   
   >   
   >   
   > I think %appdata% was sorta supposed to be that, but I guess devs   
   > figured it was too scary for the end user so they use the Docs folder.   
      
   The question is: why do the developers believe it is necessary for users   
   to have access to the application data in the first place?   
      
      
   --   
   CrudeSausage   
   John 14:6   
   Isaiah 48:16   
   Pop_OS!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca