On 10/27/2010 10:45 AM, Kent Quirk (Q Linden) wrote: > Au contraire. Some people get very upset when an installer leaves any files > behind that were created by the program automatically, such as log files. Au contraire contraire. MANY people get VERY upset when an installer deletes files that belong to them that they directed the program to create, either explicitly, or automatically via an explicit setting. I have the original viewer 2 installed right now and am not going to uninstall it until I am DAMN SURE I have backed up my entire profile, specifically because of this asinine design flaw. If I didn't already know about it, I would be ROYALLY pissed off when it deleted years' worth of accumulated data; MY data. Despite having backups, there still will be incremental loss (data since last backup), and the hassle of having to restore said data. Other people aren't so lucky, not knowing to back up said profile data, or simply not doing backups (yeah, their risk, but there is NO call to intentionally manifest that failure in code). > It's simply not true that the uninstaller shouldn't remove anything in the > profile -- I have worked at multiple companies where leaving behind any > breadcrumbs (anything that wasn't created by File Save) after an uninstall > was considered a major bug. Then that is multiple companies which promoted a SERIOUS installer design paradigm flaw. I can't say I envy you there. Of the hundreds of customers I have developed software for over the past 3 decades, if I had implemented such a design flaw in my uninstallers, I would have lost a lot of money, and potentially been sued by at least a couple of them. (btw, aren't anecdotal stories acting as appeal to authority logical fallacies fun?)
Look, this isn't hard to grok; it really isn't. Any collection of data which is created by or at the behest of the user is considered "user data". Implementations of a proper installer paradigm should NEVER *EVER* touch user data, either automatically or by default WITHOUT the full knowledge and consent of the user. That includes things like chatlogs, user-created folders underneath the program directory, user preferences, etc. This does not apply to things like temporary files, cache files/folders, or program data (because none of that is "user data"). An uninstaller also should inform the user of any files that it left behind, where, and why. Give the user information and control, and you don't have "very upset" users. Maybe "mildly annoyed" users, but not "I want to throttle the idiot developer that did this to me" users. At MOST, an uninstaller, if it is hell-bent on trying to clean up *COMPLETELY* after itself, *must* inform the user that it wants to cleanup his/her user data, explain EXACTLY and IN DETAIL what is going to be cleaned, and leave the default for the option to NO (as in "don't delete my data!"). This is simply proper (un)installer design, and I am amazed that so many developers simply "don't get it", to the pain of their users (including myself). Deleting data is FAR more serious of an issue than leaving data behind. Once it is gone, it is gone; if it is left behind, the user can clean it up themselves. Anger from lost data >>> annoyance of having to break out the data dustbuster. > Now I do think we can try do better; asking about deletion is on the > Snowstorm backlog. I sure hope so. <.< > Installers are always tricky and hard to test, and very often the uninstaller > comes "for free" with writing the installer. It's also specialized, > platform-specific code, sometimes in a strange language, so it's not easy to > find devs who want to work on it. They are not nearly as tricky or hard to test as code itself. Yeah, the uninstaller is often auto-generated by the installer generator, but to not then go through it with a fine-toothed comb for verification and add application-specific changes to the uninstall script is just laziness, pure and simple. The "strange language" is often fairly simplistic and easy to manipulate with only a modicum of time and effort put into learning it. I would be extremely surprised to learn that there isn't at least one "installer expert" at LL, whose primary job function is building and testing installer packages (note I said "primary", not "sole"; let's not go there). > There's work going on right now that will probably affect this, and we'll > make sure this is considered. It needs more than consideration; it needs to be done, period. It's improper and incorrect, it is a design flaw, and it needs to be fixed ASAP before it does any more damage to user data. --TL _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
