Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

I just *had* to comment.

> 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


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /