Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!stanford.edu!leland.Stanford.EDU!leland.Stanford.EDU!fangchin From: fangchin@leland.Stanford.EDU (Chin Fang) Newsgroups: comp.sources.wanted Subject: Re: SUMMARY: Super-simple UNIX editor Message-ID: <1991Jun22.032944.7273@leland.Stanford.EDU> Date: 22 Jun 91 03:29:44 GMT References: <1991Jun18.065340.25187@yenta.alb.nm.us> <17174@darkstar.ucsc.edu> <1991Jun21.012239.4994@cbfsb.att.com> <1991Jun21.040309.26255@leland.Stanford.EDU> <9754@cognos.UUCP> Sender: news@leland.Stanford.EDU (Mr News) Organization: AIR, Stanford University, CA 94305 USA Lines: 114 In article <9754@cognos.UUCP>, jimp@cognos.UUCP (Jim Patterson) writes: |> In article <1991Jun21.040309.26255@leland.Stanford.EDU> fangchin@leland.Stanford.EDU (Chin Fang) writes: |> >In article <1991Jun21.012239.4994@cbfsb.att.com>, Dan_Jacobson@ATT.COM writes: |> >|> >>>>> On 20 Jun 91 03:26:55 GMT, fangchin@leland.Stanford.EDU (Chin Fang) said: |> |> >Whenever BIG disk space is required, root privilage (at least stuff or source |> >privilage) is required. ^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ Note that I said either root privilage of staff (sorry about my earlier typo) or source privilage. The later two are not the same as root, but people with such privilage can write into certain directories like /usr/local/.... Why so many people misread this provision? It's obvious, isn't it? |> We don't bother with disk quotas at our site. I know this isn't a feasible |> approach at many educational sites, but it works quite well in a software |> development environment. |> Quite infeasible at our site. We have (PAY ATTENTION!) 9763 active user accounts, only 7 gig bytes for user disk space :-( and about 7 gigs for holding apps and other system stuff. These are file server disk space. We may acquire another 40 gigs in this summer, but with over NINE thousand users, even with 40 gigs more, it's not much. Totally, we have 14 DEC 3100s, 54 SUN SPARCs, 15 IBM RISC 6000s, and one DEC 5500 These workstations each have about 200~300 megs disk space for /tmp, swapper, OS, X etc, and they are NFS mounted to file servers, ie, a few powerful SUN 4s and one RISC 6000 530. We provide unlimited computing time to any Stanford student/faculty/staff, but unfortunately with so many users, only 4megs for each as default. This is due to economics, nothing else. With 9000+ users, some of them are bound to be very irresponsible :-(, we didn't impose disk quota for about one year and we got TONS of troubles because there are many careless users turned disk hogs :-( They caused system crash on the average once a week. After a while, we SAs had enough (and I imagine responsible users also had enough too) so we kicked in disk quota. Note, this is a campus-wide computing service, even a new freshman can immediately have a UNIX account, you don't need to be a grad student to get one. You don't need to be a member of a research lab to get one either. I imagine many schools also have a similar site like ours. We also provide hand-holding consulting etc. Of course, at my school, each dept has it's own computing facilities. Place like Center of Integrated Systems has so much disk space and CPU power it's eye-poping! The place I work is just one of the sites on this compus but it's the only one available to ANY Stanford academic member therefore the busiest :-( |> Your site seems to have two classes of users: |> - Those with 4MByte disk quotas |> - Those with root privilege |> WRONG! Root, staff/source group/privilaged subgroups and general users. People in staff/source group don't have security privilage, which is reserved by two super users. (I am not one of these two, what a relief :-) You know how much time my head SA spent on fending off off-campus system breakers? |> All you're really saying is that you need lots of disk space. If your |> operations group can't give someone some additional disk quota without |> just giving them root privilege, I think you have a serious organizational |> problem. |> That's what staff/source groups etc are for, we also have subgroups, like people taking care of IBMs have ibm_src group privilages. They can modify file systems on file servers used by IBM workstations, for instance. We don't have any "orgainzational problem" at all. What "I" have now is lot's people have misunderstanding of my post(s). |> Granted you will likely have to "justify" your request, but the basic |> problem is one of economics (you can't afford unlimited disk space). Indeed, we sometime grant a group of students like hundred megs for their projects, but their sponsors have to sign some forms. |> I'd also suggest that it is (or should be) a lot easier to justify 20 |> MBytes of disk space to your system manager than it is to justify root |> privilege, since the latter is basically giving away the keys to the After you read above, I guess you would know the way we do is what most SAs would as well. |> store. Of course if you can convince your sysops to maintain emacs |> for you, all the better. |> Yes, I am the guy maintain NFS mounted /usr/local/bin for all our platforms. That's why almost all our users are happy :-) Because they don't need to build emacs in their own $HOME. If at a wide access site like ours, a user HAS TO build emacs in his/her $HOME, it's a sign of incompetent system adminstration! Besides, at a busy site like ours, disk usuage checking is a must given our limited disk space. We even have to expire news fairly quick to recover disk space too. Imagine you let hundreds users build/use their own emacs in their $HOME, what a waste! Finally, as a "conclusion" related to the subject, I think if someday, an editor like the MSDOS shareware Qedit from SamWare is available to the UNIX world, all the better. If I am not mistaken, it only requires 45k bytes disk space to hold it. GNU emacs is granted extremely powerful and is a nice interface to many apps, but it's SOOOOOOO HUUUUUGE! Sincerely Chin Fang Student UNIX system adminstrator, Academic Information Resources, Stanford University, grad student Mechanical Engineering Department Stanford University fangchin@leland.stanford.edu