[prev] [thread] [next] [lurker] [Date index for 2005/04/07]
Ghod do I love installing applications on Windows for new hires. In a better world, this would be no big deal. Install the OS, set us basic system settings, create accounts &/or attach to Samba domain, install standard applications, deploy. But no, the application installs are rarely that straightforward. Some require an administrator account to install, because they need to vomit random files and folders all over <C:\Program Files> and possibly <C:\Documents and Settings>. Some do not require an administrator account to install, because they just need to vomit random files and folders all over <C:\Program Files> and possibly <C:\Documents and Settings>. Spot the inconsistency thus far. The former tend to be available to all users of the system; the latter tend to just work for the account that installed it. Moreover, more often than not, the latter *don't work at all* for any account other than the one that installed it, which leads to all kinds of fun debug routines. "What the hell? Palm Desktop worked when I gave you that computer, and so did AdAware. Why don't they work now? Why does everything else work?" Sometimes, the "easy" fix is to go in, move any vomitus from my <C:\Documents and Settings\Administrator> tree over to the system-wide <C:\Documents and Settings\All Users> one, then follow this up with the equivalent of a `chmod -R 0777` to allow anyone to do anything to the settings and application files & folders, not because this makes sense, but because if I don't do it, the application doesn't work at all. And of course, there's no rhyme or reason to this. As near as I can tell, it's all just down to the whim of the vendor's programming and QA departments, because Microsoft doesn't appear to enforce any kind of recognized coding or deployment policy about this. My favorite crapware of an installation is probably Meetingmaker, which can only be installed by an account with administrator priviliges -- implying that it's going to be available system wide. But no, it only works for the account which installed it, so if your company policy is not to grant users admin accounts on their desktops, then they can't use the company groupware system. To fix this, you have to do the above mentioned "grant full access to this folder tree to all accounts", at which point anyone can tamper with it however the whim might please them. This may be risky, but if you don't do it that way, you just can't run it. Brilliant. I'd be berating Meetingmaker for this bonedead setup, but they're hardly the only ones doing this sort of thing. Palm Desktop makes the same mistake. AdAware is "better", in that it will run for other users, but all the widgets are missing, so it might as well not work at all. Etc. Haven't these people learned any lessons from other systems? All the endless wrangling over /bin /usr/bin /usr/local/bin /opt/bin /sw/bin etc is tedious, but the point being debated is valid & widely accepted -- there needs to be distinctions among vendor, system, and user installed programs -- and the approaches to the problem all more or less make the situation Less Bad. Windows just ignores it all and has everything drop into a shared /bin directory, which you may or may not need magic pixie dust to alter. Maybe I just need some of the magic pixie dust that the stoner that settled on this was smoking at the time... -- Chris Devers
Generated at 20:00 on 08 Apr 2005 by mariachi 0.52