The win client does not run very 'nice' at all so to say... When I had the client running and configured to be active constantly, I too noticed a serious responsiveness impact. Turned out the dumb thing ran at normal priority. Even switching it back by hand the the lowest priority still gave me the feeling it was clogging something. Besides, I had the DES still running as well, which I could see being totally repressed by the SETI client. Needless to say, I dumped the SETI. I don't mind spending spare cycles, but I don't want it to interfere with my normal work. I haven't tested the SETI client on an SMP box.. Maybe I'll do that this weekend. Anybody else did this? ---------- 'We have no choice in what we are. Yet what are we, but the sum of our choices.' --Rob Grant ----------
Yes and no.:-) Indeed, installing apps require local dll's and often local registry entries. This however, does not need to be a problem in regard to rolling out an app for multiple users. What IS a problem is that most software vendors do not offer much help and/or documentation in how to achieve this. I don't think this is a problem of NT in itself, but more of the application software. In short, when using a fully NT solution, NT servers and workstations you can achieve this by doing somehting similar to:
figure out what dll's and registry entries the software wants/makes and where it expects them. This is the toughest part.
create a repository for dll's on a server and share it.
have all users use a mandatory profile. Add the used menu structure in this profile, as well as the neededuser-registry entries. Have your environment path include the repository you created.
If needed, system registry entries can be added by either running a remote registry update in batch, or a run-once like configuration, which can be implememted through the profile
test, twiddle, fiddle, test, test, test:-)
It's not easy, true. It will cost you a lot of time. true. And all of this makes it practically only interesting to actually do when you have to do a large roll-out. But, as i stated before, it's only for a small part an problem with NT. It's much more a problem with the software vendors who do not document or tell you what dll's, registry entries and such are needed for their apps to run. Once they would do that, the biggest time-consumer in large roll-outs would be eliminated. ---------- 'We have no choice in what we are. Yet what are we, but the sum of our choices.' --Rob Grant ----------
So you needed to say "fuck(ing)" 4 times in order to get your point across that you deem some things inapropriate for general viewing/playing. How ironic. ---------- 'We have no choice in what we are. Yet what are we, but the sum of our choices.' --Rob Grant ----------
"That's because even traveling at the speed of light it would take more than 4 years to reach Earth's nearest star, Proxima Centauri."
Damn... I could have sworn Sol was closer... ---------- 'We have no choice in what we are. Yet what are we, but the sum of our choices.' --Rob Grant ----------
Nah... Just kick the lower left-hand corner of the machine... ---------- 'We have no choice in what we are. Yet what are we, but the sum of our choices.' --Rob Grant ----------
Slashdot Mirror
The win client does not run very 'nice' at all so to say... When I had the client running and configured to be active constantly, I too noticed a serious responsiveness impact. Turned out the dumb thing ran at normal priority. Even switching it back by hand the the lowest priority still gave me the feeling it was clogging something. Besides, I had the DES still running as well, which I could see being totally repressed by the SETI client. Needless to say, I dumped the SETI. I don't mind spending spare cycles, but I don't want it to interfere with my normal work. I haven't tested the SETI client on an SMP box.. Maybe I'll do that this weekend. Anybody else did this?
----------
'We have no choice in what we are. Yet what are we,
but the sum of our choices.' --Rob Grant
----------
- figure out what dll's and registry entries the software wants/makes and where it expects them. This is the toughest part.
- create a repository for dll's on a server and share it.
- have all users use a mandatory profile. Add the used menu structure in this profile, as well as the neededuser-registry entries. Have your environment path include the repository you created.
- If needed, system registry entries can be added by either running a remote registry update in batch, or a run-once like configuration, which can be implememted through the profile
- test, twiddle, fiddle, test, test, test
:-)
It's not easy, true. It will cost you a lot of time. true. And all of this makes it practically only interesting to actually do when you have to do a large roll-out. But, as i stated before, it's only for a small part an problem with NT. It's much more a problem with the software vendors who do not document or tell you what dll's, registry entries and such are needed for their apps to run. Once they would do that, the biggest time-consumer in large roll-outs would be eliminated.----------
'We have no choice in what we are. Yet what are we,
but the sum of our choices.' --Rob Grant
----------
So you needed to say "fuck(ing)" 4 times in order to get your point across that you deem some things inapropriate for general viewing/playing. How ironic.
----------
'We have no choice in what we are. Yet what are we,
but the sum of our choices.' --Rob Grant
----------
----------
'We have no choice in what we are. Yet what are we,
but the sum of our choices.' --Rob Grant
----------
Nah... Just kick the lower left-hand corner of the machine...
----------
'We have no choice in what we are. Yet what are we,
but the sum of our choices.' --Rob Grant
----------