🚀 go-pugleaf

davidc@cs.uwa.edu.au (David Cake) wrote:
]
]    But what is administration? Most things are administration.

What?

Are you saying that most of the things you do qualify as
administrative tasks and not user tasks?

Buddy, you're using the wrong OS.  8-).


] >We are talking applications programming and end user use of canned
] >software.
] 
]   Installing most moderately complex canned software, on almost any
] machine, gets pretty close to system administration. Installing any
] software that relies on system capabilities that aren't there
] initially. 

This is the problem with OS's with limited capabilities in the
first place.  You only need to install that TSR SCSI Scanner
driver because the system didn't come with generic SCSI support
and the SCSI support they have you install isn't a generic
interface that can be accessed via interprocess communication
(mostly because the OS doesn't support multiple processes, let
alone communication between them).


]    Lets face it - your attitude that it Unix is superiour, because
] it is more stable once set up by an experienced administrator,
] and left just as it is in terms of major installed software,
] system updates, etc. does not really make it superiour to many
] people.

This isn't exactly what I posited, but I'll defend it.  8-).

A system update shouldn't be a major production.  If it is, you
have the wrong UNIX.  Currently, Linux and the BSD's are the wrong
UNIX (or UNIX-clone, in this case).  So are several commercial
versions.  This is the whole issue of divorcing system configuration
data from the configuration implementation.

SunOS 4.1.x is way ahead of many other systems in this area, mostly
because of their concept of "the miniroot".


I'd also argue that "major installed software" is not frequently
changed in terms of whimsy.

That DOS and Windows are imperfect in this regard is why there
are product like InstallShield and RemoveIt.

] In a more realistic situation (new software being installed
] often, new machines being added to networks quite often,
] sometimes on an ad hoc basis for a visitor or special event,
] people requesting new capabilities all the time) then Macs win
] a lot - they have crashes more often, sure. But when they do
] they solve them quickly by themselves 90% of the time, while
] unix problems are usually major crises. 

Use rdist.  It is your friend.  You can sit in your office and
update the software on every machine on your network.

]    I administer a large, primarily Mac network. My users have
] wildly varying needs and software, and computer knowledge. If
] I gave them all Unix accounts I would quickly go quite mad
] from having to personally install, administer, teach, etc.
] everything. But the Macs are fine. Not that Unix is not
] sometimes the best - they all have Unix mail accounts, for
] example. And most of them have telnet to get at various other
] Unix boxes around the place, mostly things that run one large,
] multi-user, complex and important app - our library system for
] example. But as user workstations, Macs are vastly superiour,
] because of my time saved.

This is all in how you administer things.

I think the only real criticism I've seen of UNIX so far in this
regard is the complaint about lack of commercial software that
DOS and Mac users are familiar with.  Although things like Island
Graphics and FrameMaker on UNIX show the DOS and Mac versions to
be toys in comparison.  It's hard to compete with 100M of virtual
address space using a PC or a Mac, or with spawning off another
process to handle something compute intensive.

] The 80% Macs here are less troublesome than the 20% PCs (and
] the handful of Unix boxes).

I think this has more to do with where you've spent time developing
expertise and procedures (well, except for the PCs 8-)).

] >After acknowleding that, we can dicuss CASE tools, code coverage,
] >branch path analysis, and version control, all issues which bear
] >on whether a third party OS extension will interoperate with your
] >particular copy of *whatever* OS.
]
]    Which illustrates the problem. On Unix, you could do this, with an
] expensive consultant, for a few hours. On a Mac, give it a try, and work
] it out for yourself in a day or two. Sorry, all the above is overkill when
] all you want to know is wether some complex app that adds to your system
] (Freehand or Illustrator, say) will run on your machine. Hiring a
] consultant for a couple of hours to work it out is not appropriate.

My point was that the majority of these serious tools require
many of the capabilities of UNIX that aren't present on the PC
(or the Mac).  They are the tools of the professional system
programmer.  I haven't seen one multiprogrammer source code control
system for PC's (or Macs) that I would entrust with my companies
future by putting my source there.  There's *nothing* that rivals
CVS, even though CVS source is available, or even comes close to
the HP and DEC management tools.

There's no large project engineering tools like BattleMap, which
as far as I know only runs on UNIX systems.

There's no branch path analyisys software for generation of test
cases and automated testing.

And there's no range and bounds checking, like in CodeCenter, to
ensure correctness.


These are all system software programming issues, and I agree that
they aren't generally applicable.


I disagree that the administrative issues should, perforce, have
a high enough profile that they become user issues.  Things like
CONFIG.SYS and AUTOEXEC.BAT are abominations, as is the ability
for a naieve end user to stuff things in a system folder.

We recently had a problem where I work where a sales-type was
picking his own IP address because when you used DHCP to get
an IP addres, you got the additional baggage of the default option
settings for buffers, etc., that the system administrator had
configured, and he didn't like them.

He should not have had the option to do this: it's an administrative
task.  It's very difficult to track down a machine that's stomping
on your name server (he happened to pick that as his address... it
could have been worse; at least the number was in our net and we
didn't start RIP'ing someone elses net to the world).


                                        Terry Lambert
                                        terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.