There was a bug in an uninstaller, once, that deleted all of the files on the disk. Sounds like malware to me!
There was a bug in some Linux driver installer that accidentally /usr, the whole thing.
Any sufficiently advanced uninstaller is indistinguishable from malware
231–240 of 556 posts
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#232Fight fire with fire
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#233Earlier quoted context omitted.
The ~/.whatevertheyfeellike is an antipattern (that is annoying) but the others are well defined in the xdg_desktop spec[0]. Personally I appreciate knowing where the config/cache for each application is. (Though it does annoy me when programs don't follow this as in your third example) [0] https://specifications.freedesktop.org/basedir-spec/basedir-...
Why does the XDG spec have authority over software?
It usually doesn't, and it's mostly a good standards recommendation that even the most GPL of GPL codebases doesn't always follow (looking at you, emacs).
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#234Earlier quoted context omitted.
Cache files might contain user's sensitive data. Makes sense to keep in them in the user's home directory in those cases.
File permissions?
Isn't that very anti-linux though, to have a directory owned by root but populated with subfolders owned by other users? /home is the only exception I can think of that does this.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#235I love how it goes from hardcore x86 assembly right into beautiful JavaScript lol.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#236Earlier quoted context omitted.
If you can just delete its directory (or its single file) and everything works, that should be fine?
I guess so... but then you're assuming that the user isn't saving data in that directory :-P but honestly, please Windows Dev's.. use MSI's please it make me love you and i have so much love to give.
Yes. But if you stick everything into a single .exe, the user can't interfere.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#237Earlier quoted context omitted.
I wonder why Raymond Chen suggest a WSH solution. Isn't PowerShell the official scripting language for Windows nowadays?
PowerShell has weird restrictions where it'll refuse to run scripts unless they're signed and stuff.
If the sysadmin chooses to, otherwise PowerShell can be run arbitrarily
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#238I keep forgetting Windows-isms that won't allow you to delete the executable file of a running process. I guess that's also why the arcane .dll upgrade process / WoW is so necessary.
>won't allow you to delete the executable file Any open file
But there must be an API to unlock files that programs like "The Unlocker" use? Or do they just enumerate the other processes handles to that file and close them?
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#239Earlier quoted context omitted.
Cache files might contain user's sensitive data. Makes sense to keep in them in the user's home directory in those cases.
File permissions?
There's no other path that the user is guaranteed to have write permissions to (except maybe /tmp, I guess).
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#240Earlier quoted context omitted.
The ~/.whatevertheyfeellike is an antipattern (that is annoying) but the others are well defined in the xdg_desktop spec[0]. Personally I appreciate knowing where the config/cache for each application is. (Though it does annoy me when programs don't follow this as in your third example) [0] https://specifications.freedesktop.org/basedir-spec/basedir-...
Why does the XDG spec have authority over software?
Software specifications are usually adopted by convention and implemented to minimize surprise and make things interoperable. They are not authorities and cannot make anyone do anything. One of the most common software failure modes is to implement a specification too tightly or in a way that nobody wants although the reverse is a problem as well.