ejablow@dasys1.UUCP (Eric Robert Jablow) (01/11/88)
I am organizing the math department at SUNY--Stony Brook's new Sun
installation. The department ordered (while I was away) A file server
(named fawn), and two workstations (named donna and jessica). They
also obtained 2 Micropolis 141 Mbyte disks; this is, of course, not
enough for the entire faculty. Now, I had installed all the optional
software Sun produces except for the Versatec stuff, the Transcript
software for our Apple LaserWriter (the shredder), and Macsyma. Thus,
as more people use the system, the closer we approach a disk space
crisis. What should I get rid of? The System V compatibility
libraries? Which things should I jettison? Please note that we'd like
to get on the net ourselves sometime.
As an additional problem, all our phone service comes through a Rolm
system; this is giving us many problems. If anyone out there with some
expertise on Rolm systems can help me, please write.
Please reply to this account, or to ejablow@sbccvm.bitnet.
Respectfully,
Eric Jablow
P.S. Should we name our disk drives Vanna?
--
Eric Jablow {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!ejablow
New York, NY, USA Soon to be eric@fawn.sb.edu.
Copyright 1988 First Category Pressgwyn@brl-smoke.UUCP (01/12/88)
In article <2509@dasys1.UUCP> ejablow@dasys1.UUCP (Eric Robert Jablow) writes: >crisis. What should I get rid of? The System V compatibility libraries? Although you could probably survive without the System V software right now, note that SunOS is supposedly moving in the direction of full SVID conformance (Release 4.0?). So, if you do software development, you should make plans now rather than face a massive conversion effort when a new release of SunOS shows up. If you don't develop much software and don't particular need the common System V environment (which might be useful if you have other systems that are System V based), then certainly the System V package would be a good candidate for removal temporarily, until you get adequate disk space.
chris@mimsy.UUCP (Chris Torek) (01/12/88)
In article <7050@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
-Although you could probably survive without the System V software right now,
-note that SunOS is supposedly moving in the direction of full SVID conformance
-(Release 4.0?). So, if you do software development, you should make plans now
-rather than face a massive conversion effort when a new release of SunOS shows
-up.
You seem to believe that SVID compatibility => BSD incompatibility.
This is largely false. (We even fixed sprintf :-) )
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chrisdpz@athos.rutgers.edu (David P. Zimmerman) (01/12/88)
In article <2509@dasys1.UUCP> ejablow@dasys1.UUCP (Eric Robert Jablow) writes: > Now, I had installed all the optional software Sun produces except > for the Versatec stuff, the Transcript software for our Apple > LaserWriter (the shredder), and Macsyma. Thus, as more people use > the system, the closer we approach a disk space crisis. What should > I get rid of? The System V compatibility libraries? Which things > should I jettison? As Doug said, you can chuck the SysV stuff if you really don't need it right now. You can get rid of /usr/demo, and /usr/src if you don't care about the suntool/* sources. If you are willing to risk mutiny, you can poof /usr/games (buy an Amiga for the diehard gamers). I find that we don't even bother "stat"ing /usr/sccs :-), much less use it, so you can save a bit of space there. You can probably turn off accounting if no higher-ups care about the stats, and write some scripts to clean up the rest of /usr/adm very frequently. /usr/diag is, well, up to you. Suffice it to say that it eats ~2M. It all comes down to what you are willing to do without. I personally would get rid of /usr/dict, but then again, I think a PC is a wonderful terminal with Kermit running on top of Turbo Lightning. What we often do around here when partitions fill up is move things off of /usr onto a user file partition, and put in a symbolic link from the expected place. I don't think you would be able to do this, given that your saturation is global rather than on just one filesystem, but maybe you can adapt this somehow. You can also chmod /usr/man/cat* to be not writable, so that the cat* formatted man pages don't eat up more and more disk space. This will, of course, require them to be rebuilt every time someone wants a man page, but maybe someone will get aggravated enough to buy you another disk :-). Certainly this is your classic space/time tradeoff. Speaking of that, you want to go through your locally installed stuff and see what can be shot that will only require extra time to build when actually needed. GNU Emacs *.elc files are good candidates. Space is limited, but time is infinite (well, at least it is when I'm in a boring class). Also! Look carefully at how you set up the client partitions. Make a directory /pub/etc, move a lot of the client /etc programs there, and make links to them. We save MeGaByTeS of space that way, and can get away with ~2M client roots. You can also nuke /private and do some other stuff along that line, but that is more involved than just killing a directory. If you need to, skimp a bit on the swap space for everything (see my point of annoying a money-payer above). dpz -- Internet: dpz@rutgers.edu UUCP: rutgers!dpz Bitnet: zimmerman@zodiac
decot@hpisod2.HP.COM (Dave Decot) (01/13/88)
No, you should not name your disc drive Vanna. Your disc has too much information stored; Vanna has rather the opposite problem. Dave Decot hpda!decot
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/13/88)
In article <10139@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >You seem to believe that SVID compatibility => BSD incompatibility. No, rather that developing under BSD without paying much attention to portability often results in SVID-incompatible code (and vice-versa, I'm sure), so if SunOS starts to default to SVID-conforming, some BSD-dependent code will break. It is easier to develop SVID-compatible applications under a System V environment, even an approximate one like my emulation, than under a native BSD environment.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (01/14/88)
In article <10139@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >You seem to believe that SVID compatibility => BSD incompatibility. >This is largely false. "Largely" may be the critical word here. Consider a function long gettz(); that returns the user's local timezone in seconds west of GMT, taking into account daylight savings time. I haven't figured out a way of implementing this that works unchanged on both System V and 4.3BSD. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi