At 07:27 AM 2/17/2007, Lars Schimmer wrote:
Has anyone started a list (in a wiki or for only his own usage) of
software for windows (workstations) which runs out of OpenAFS filespace?
Throughout our history here at the University of North Carolina at
Charlotte, the College of Engineering's Mosaic Computing group has had
quite a bit of success running applications out of AFS. Most applications
will run out of AFS without problems, but there are quite a number of
issues that doing so will cause.
Rewind and let us look at history...
1. DOS applications could run almost anywhere because all of the
application was basically in one place.
2. Windows 3.x applications began the problem of...
a. An application folder.
b. Application INI settings in "c:\windows\file.ini"
c. Application DLLs in "c:\windows\systemxx"
3. Windows 9x and WinNT 4.0, Win2k...
a. An application folder.
b. Application INI settings in "c:\windows\file.ini"
c. Application registry settings in both the global and user registries.
d. Application DLLs in "c:\windows\systemxx"
e. User data stored in a profile space.
4. WinXP and beyond...
a. An application folder.
b. Application INI settings in "c:\windows\file.ini" (now deprecated)
c. Application registry settings in both the global and user registries.
d. Application DLLs in "c:\windows\systemxx"
e. User data stored in a profile space.
f. User data stored in "Application Data" which might be redirected.
g. Applications are installed and managed by the Windows Installer
database services. These run as both the user and SYSTEM (guess
what... The SYSTEM user doesn't have user token).
In short Microsoft, due to their own negligence and incompetence, allowed
this "mess" to happen. Then they tried to clean it up later, only making a
complex problem even worse. Finally, we are here with Vista and the UAC
environment. That's why any Microsoft Windows client total cost of
ownership is so high. Recent numbers I've seen are around 5000 (American
dollars) per client.
The problem was made worse in the 90's when most vendors started ignoring
the network shares as an install and run resource. You had vendor thoughts
like "oh, users have tons of space on their C: drives now". So where in
the past you could upgrade one or two share (mount) points and suddenly all
the users would be upgraded to the new software versions virtually "over
night", now you've got N clients, at N locations, in N different
configurations to manage. It's complete and total madness. I could
continue to drone on and on about this messy problem but it would come to
nothing.
Recently we've given up on installing most applications in AFS. It is just
too complex to do so. We are now using AFS as an application distribution
resource. By in large, most applications are installed and run
locally. The applications start faster, but take up more space on the
users hard drive. Mostly this is due to the fact that most software
vendors really have poor software architects and programmers. The nice
applications that can live in AFS, basically don't use the registry at all,
install few DLLs, and the whole application lives in AFS, just like the DOS
days.
Incoherent ramblings aside, take it from someone who has worked in the
trenches. DON'T do it. You are setting yourself up for more pain than
gain by trying to screw an application into running from a network (on
Windows). With 'nix environments it is virtually painless.
Rodney
Rodney M. Dyer
Operations and Systems (Specialist)
Mosaic Computing Group
William States Lee College of Engineering
University of North Carolina at Charlotte
Email: [EMAIL PROTECTED]
Web: http://www.coe.uncc.edu/~rmdyer
Phone: (704)687-3518
Help Desk Line: (704)687-3150
FAX: (704)687-2352
Office: Cameron Hall, Room 232
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
