Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
wrote: > On Wed, Jun 02, 2004 at 02:56:06PM -0400, Don Levey wrote: >> Well, I have. Note that he said "exclusive of help-desk activities". > > Yeah I guess that's true, but it depends on what constitute help-desk > activities in your organization, or if there is even a distinction > between the help desk and the sysadmin team. I think making such a > qualification is meaningless because it can't hold up for many, if not > most organizations for those reasons. > The organisations with which I've been involved that have multi-thousands of desktops do in fact make the distinction. Sometimes it's desktop support vs operations, or help-desk and sysadmins. But these are the stratifications I've seen, not just in the companies for which I've worked, but also the companies I've supported. >> Keeping Windows up-to-date can be accomplished by a number of >> things, including their auto-update feature, SMS, and even remote >> desktop. > > All of which users can and will break, given sufficient motivation > and/or opportunity. > Well, sure - but perhaps that's yet a different issue. The only way to make sure that the users never have sufficient motivation (and opportunity) is to have a one-to-one ratio of monitors to employees (or other draconian measures). Anything less requires some degree of trust. >>> I have re-implemented, or been involved in environments that >>> re-implemented something very similar to what Derek describes on >>> more than one occasion. And I never lived at MIT. Doing so, in as >>> much as is possible at your site, makes everything a lot nicer. > >> It may be - but there's only been one unnamed) example mentioned so >> far. Considering the number of production environments out there, >> this does not seem to move it beyond the "special case" category. >> If you're mentioning others, then that might change. > > Requiring that they be named is a bogus requirement, since without > going into those environments and examining their configurations, > they're not really verifiable anyway. All of the environments I > worked at were engineered this way, to differing degrees. I'm not > inclined to name them though, mainly because I think that discussing > the details of any of their implementations is a violation of their > trust, possibly of their security, and in some cases maybe even my > employment agreement with those parties. But there were 4 of them, 2 > of which were very large companies, and 2 of which were relatively > small engineering shops. If you find that unacceptable as anecdotal > evidence to the contrary, then you're welcome to continue to believe > the original supposition... I don't really care. ;-) Fair enough - perhaps there's no need to name names, though oftentimes it at least provides something that *could* be checked if necessary, and thus gives a small amount of backing to the statement. But now, in total, we've got 5. Anyone else want to speak up, to add to that number (or provide counter-cases)? -Don
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |