I just *had* to comment.

[dsr at tao.merseine.nu (dsr at tao.merseine.nu)]

On Thu, Jun 03, 2004 at 04:42:14AM +0900, Derek Martin wrote:
> > I am, and thus I can delete the rest of a rather lengthy
> > response.
> 
> That's fine, but you're ignoring a rather large reality where Windows
> exists on 95% of the client machines in the world.  But as I said, it
> doesn't matter, because your argument is still not correct for many
> all-Unix environments, unless you want to more clearly define the
> kinds of environments where it holds up.  Your assertion was that no
> one would want the kind of environment like MIT has, but now you're
> rather narrowly redefining who qualifies to make that decision...

No, I said that MIT was a special case. Further discussion
showed that the special case was "large universities", and a
single non-university was mentioned but not named.

> I'm telling you that I worked in 4 environments that were set up not
> exactly like, but similar to, what MIT did for basically the same
> reasons, and you're ruling them out because they don't conform to your
> very narrow idea of what an environment needs to be like.  That's 4
> out of 4 environments that I worked in.  But no, none of them were all
> Unix.

I don't require that they be all Unix; just that they be
primarily Unix. This is, after all, BLU. I'm not particularly
interested in the administration of large groups of Windows
machines; as far as I'm concerned, after 30 minutes to an hour
of helpdesk time, problems with Windows machines are either
hardware or solved by reinstallation. That's not an interesting
environment, and in general I don't want to work there.

> The idea is simple: the user should be able to log into any computer
> and do the same work, no matter where it is.  We didn't use AFS or
> athena, but we did use other network filesystems and authentication
> schemes to approximate the same effect.  I think it's not a special
> case at all.  [In practice, some of these environments varied from
> this a little, but the data that existed on individual clients was
> considered temporary and/or unimportant, and was not backed up in any
> way by the sysadmin team. OTOH, some of these environments ran with
> dumb terminals...]

I'm not convinced that what I think of as "Athena style" matches
what you did all that closely. I will grant the intent is the
same... for the class of machines which are intended for
personal usage. And that's the big "thing" here: Athena is
suited for large numbers of essentially personal-use machines. I
live in production and operations environments where most
machines are only accessible by the sysadmin staff. Personal
machines are a minor subclass.

Any data on individual machines that are not backed up does not exist
as far as I am concerned.

And I'm not concerned about dumb terminals, X terminals, 3270
terminals or multiheaded machines; these are all aspects of a
single machine.

I'm mostly concerned with classes and roles of machines: these
are NTP servers; these are HTTP servers; these run databases.
These are development boxes; these are beta test areas; these
are graphics workstations; these are general purpose
computation; these are safe storage. When I upgrade some
software, it must happen on all the boxes of that class, not
affecting any other class, and without regard for the number of
boxes in that class. There are machines which anyone with a
general login can use, machines which no one except system
administrators can use, and machines which have restricted
access of various sorts. And in all cases, I have to be able to
manage them remotely, with a minimum of manpower, and with tools
that keep track of what has happened and allow rollback to
previous states in a minimum of time.

-dsr-