Date: Sat, 17 Apr 1999 11:27:34 -0500 From: "C. Stephen Gunn" <csg@physics.purdue.edu> To: Greg Black <gjb-freebsd@gba.oz.au> Cc: freebsd-hackers@freebsd.org Subject: Re: Entombing for FreeBSD Message-ID: <19990417112734.A6483@ohm.physics.purdue.edu> In-Reply-To: <19990417114814.22986.qmail@alice.gba.oz.au>; from Greg Black on Sat, Apr 17, 1999 at 09:48:14PM %2B1000 References: <199904160332.WAA28377@poynting.physics.purdue.edu> <19990416113734.18605.qmail@alice.gba.oz.au> <19990416150649.A1060@ohm.physics.purdue.edu> <19990417114814.22986.qmail@alice.gba.oz.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 17, 1999 at 09:48:14PM +1000, Greg Black wrote: > Indeed. But I don't think it's desirable for anybody in the way > you have proposed, and I was (and still am) arguing against that. Thats fine. :-) > Is this supposed to mean something? What makes you imagine that > you know anything at all about what I do? If it matters, which > it doesn't, I have regularly taken care of many hundreds of > users on individual systems; and I do have some practical > experience with what that means. But I don't think this should > degenerate into one of those "mine is bigger than yours" things. I didn't mean for it to. Apparently, from your description, our environments are very different. As you describe, your users are using GUI's and interfaces to large databases. Some of mine use FreeBSD Boxes, NCD X11 terminals, some use freaking Wyse Terminals at 19,200 baud. They all telnet/ssh into several central machines. > Users can be trained, no matter what anybody claims to the > contrary. Users who are so difficult to train that it doesn't > seem to be worth the effort rarely have to be let loose with > tools that can delete files, but can be accommodated within some > GUI interface to the company database or whatever it is they do. My users are professors of physics, with egos the size of Manhattan (some days). The average age of prof in our department is something like 62. We've got secretaries, and the "business" side of the department, alas, runs on Windows. But on the academic side of our department, we have 500 people who do their real work with vi/emacs and LaTeX. They're the first to balk at the fact that they need training, and the first to demand that they get that deleted file back. We have 3 computer staff, for 500+ people in our department. That's to manage a network of over 700 nodes. My job entails everything from filling the papers with printer, to debugging Fortran code, to troubleshooting the network, to restoring files. Again, we back up 100G of disk every night to DLT from 20 or so hosts on our network. We even have a DLT Changer to change the tapes for us. The average "restore" takes 45 minutes, assuming the person who wants/needs a file back knows when they last had it. If it's a directory it could take 1.5 hours or so to do Level 0,1,2,3 restore. > Ah, no -- that's not what you have presented to us. You're > talking about hacking this thing into libc where it will affect > every program in the world, to provide a facility that would > have been invented a million years ago if it was really useful. I didn't present it, but I'm familiar with it, so I'm contributing. The code, yes in libc (right now), checks the environment before doing the deed. Actually it checks a glob pattern to be precise. As far as "really useful" and long times, I will direct you to the USENIX paper presented at the 1989 Winter conference by Matthew Bradburn of Purdue University. The original implementation used RPC, and it was re-implemented by Kevin Braunsdorf at Purdue sometime thereafter. This has been in production at Purdue University for nearly 10 years. This has been in production on FreeBSD (2.x/3.x) for nearly 2 years here at the Department of Physics. I will try to get the paper and some documentation into HTML and online, and post a link when I do. > If you can dream up a way to provide it *without* affecting all > those people who don't want it, then I would have no objection. > But if it has to be via a hack to libc, then I trust that the > decision makers in the FreeBSD team will choose not to commit it > to the standard system. I would argue that _if_ this is accepted to FreeBSD, it should be off by default, and documented ala FTPD_INTERNAL_LS in make.conf. If you want it, build it into the system. Even if it is there, there are plenty of ways to get it turned off for a user, or the entire system as a whole (if you want). Let us get the patches/documentation prepared so that people can look at the internals and how it works. - Steve -- C. Stephen Gunn, Computer Systems Engineer <csg@physics.purdue.edu> Physics Computer Network, Purdue University To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990417112734.A6483>