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 06:51:44PM +0000, dsr at tao.merseine.nu wrote:
> > Just keeping windows up-to-date will probably be a full-time job for
> 
> What Windows boxes? We're discussing all-UNIX environments with
> proper support infrastructure for system administration. We're
> just disagreeing about what constitutes proper support
> infrastructure.

Who said so?  If I can quote Derek's message:

  ~/.* is not sufficient to deal with "global settings".  However a
  registry isn't sufficient, either.  Think distributed systems (i.e.,
  I've got 1000 machines and the software is installed on a central
  file server (not on each machine) and run out of the network file
  system).  Registries of all forms fall flat in the face of
  distributed file systems, unless there is some standard way to read
  the global registry info out of the file system.                                                    
Nowhere was it specified that all systems are Unix.  And why should
they need to be?  Windows machines can (potentially, if they're
architected properly) run applications from the network as well as
Unix machines.

> Possibly not. Are 15,000 servers considered small these days?

Special cases abound.  Most environments with real users don't have
15,000 servers.  Note that Derek was talking about large numbers of
CLIENT machines...  That's invariably where things get messy.

> > 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.
> 
> That I find interesting. Did you use AFS? Was it a university?

No, and no.  We used NFS and/or Samba and/or NIS, and it was always at
a commercial business.

> > > The number of client machines is not important to anything
> > > except hardware replacement and initial install. 
> > 
> > That's quite preposterous.  You don't work in support at all, do
> > you...
> 
> Installing a new machine is a matter of:
 
Since my assertion is that there's more to supporting machines than
just installing them and hardware failures, the discussion of the
initial install is irrelevant.

> Anything subsequent is either O(1) for universal changes, O(#of groups
> affected), or related to hardware failure or handled by the help-desk.

Wrong, if you don't exclude Windows (which I wasn't).  You're
forgetting about the case where the user does something inadvertently
to screw up the installed software on the system.  You're forgetting
about the case where some software goes hog-wild and screws the system
up for them... etc. etc. ad nauseum.  And sometimes, software just
breaks for no reason.  IME, for example, Windows just simply needs to
be re-installed from time to time (though recent releases are a lot
better about that, if you keep them up to date).

Even on Unix systems, things can get whacky if you have buggy software
or if the users have the root password.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20040602/4dd0eba2/attachment.sig>



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 / webmaster@blu.org