Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!ncoast!allbery
From: allbery@NCoast.ORG (Brandon S. Allbery KB8JRR)
Newsgroups: comp.unix.sysv386
Subject: Re: '386 Unix Wars
Message-ID: <1991Jan1.025724.25700@NCoast.ORG>
Date: 1 Jan 91 02:57:24 GMT
References: <1990Dec30.193929.16181@kithrup.COM> <1990Dec31.053142.10444@robobar.co.uk> <1990Dec31.100329.23178@kithrup.COM>
Reply-To: allbery@ncoast.ORG (Brandon S. Allbery KB8JRR)
Followup-To: comp.unix.sysv386
Organization: North Coast Computer Resources (ncoast)
Lines: 93

As quoted from <1990Dec31.100329.23178@kithrup.COM> by sef@kithrup.COM (Sean Eric Fagan):
+---------------
| that order of importance).  A friend set up the MMDF system while I was in
| Canada for a while, so I really cannot say how easy or difficult it was.  He
| said it was fairly easy.  I've since changed it a few times, in relatively
| minor ways.  While I admit the documentation could be better (all I had was
| the online stuff), it wasn't too hard.  (I think my major gripe with it was
+---------------

MMDF is one of the things SCO did right.  I plan to bring it up on a number of
other systems --- it beats sendmail all hollow for ease of maintenance.  And
the fact that it can handle a pathalias file by itself is nice, too.

+---------------
| the fact that I ended up, at one point, with a 25Mb log file, which had
| eaten up about three quarters of my available disk space.  *grrr*  Hooray
| for the quot command! 8-))
+---------------

The MMDFIIb #43 distribution on louie.udel.edu is worth getting just for the
documentation.  There is an automatic log maintenance facility in MMDF, where
you set a threshhold size and MMDF will run a program CMDFLDIR/setlogs when a
log exceeds that size.  "setlogs" is user provided, although there are
examples in the distribution; you can use a shell script and pretty much have
it do whatever you want.  (One of the benefits of having real documentation.)

+---------------
| Using cc, not gcc, incidently.  The couple of problems I ran into, I mailed
| to Henry, and got some feedback.
+---------------

Speaking of which....

(Please note that this is NOT an official bug report.  I'm still trying to
determine the exact problem and will pass it through official channels when I
have done so.)

I've been building MGR for the system I have to install.  (X is just too big
and too demanding for the circumstances.  A window manager which is complete
in 400K has a lot going for it....)  Anyway, cc will not compile the bitmap
code properly; it looks like a bit-twiddling macro used very often in the code
is being mis-compiled by cc.  I used gcc instead.  (On the other hand, gcc
botches the bitblt code completely; I had to use cc to get it to work.  And
rcc handled *neither* properly.)

+---------------
| 8-) 8-))  If it were just a *little* bit more unobtrusive, I think the only
| reason I would notice it's there is because I use sysadmsh to create users
| instead of vi, mkdir, and cp.
+---------------

Far and away, my *biggest* complaint with C2 is that some of the things it
does actually *reduce* system security.  If I want to su to another account to
deal with something (say, bsa -> mmdf), I must become root first.  I could
make mmdf "owned" by bsa, but what if lenj needs to do some maintenance on it?
Or I could make it a normal account and log out and back in, but this reopens
security holes closed by the concept of an administrative account.
Additionally, the administrative accounts collide with the use of luid's by
cron and at:  I must either make accounts like mmdf regular accounts or make
crontab changes as root directly to the crontab file *and* *then* *reboot*
to make cron see it; the "crontab" command uses the luid to determine whose
crontab to update, and you can't kill and restart cron without setting its
luid.  (Or using a hack to start it from init --- hack because cron puts
itself in the background, so the process started by init has to fork cron,
then sleep and occasionally kill -0 the process to see if it still exists.)
The reboot is inconvenient, to say the least (especially on a production
system); having to make changes as root pretty much cancels out security.
These flaws pretty much make the concept of administrative accounts useless.
A pity, as some of the things done in the name of security are d*mned useful.
My favorite example of the latter is allowing group "lp" to maintain the
spooler system, in conjuction with group vectors so that authorized users can
be given group "lp".

+---------------
| (i.e., a non-SCO supplier [including, potentially, myself!]).  About the
| only thing I want on kithrup right now, I think, is dynamic linking, and
| I've got a couple ideas about that anyway...
+---------------

All it would take to add dynamic linking to COFF is for someone with some time
to study the COFF format and write the COFF equivalent of BSD's "ld -A".
Someday --- except that things have moved on, and I'll probably wait for SVR4
and ELF if it isn't in there already.

++Brandon
(The most frustrating thing about SCO UNIX is that it contains the seeds of
greatness.  But it BADLY needs fertilizer, and the sh*t that comes with it
isn't working....)
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery@NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY