From owner-freebsd-hackers Thu Nov 2 16:05:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA22749 for hackers-outgoing; Thu, 2 Nov 1995 16:05:54 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA22706 for ; Thu, 2 Nov 1995 16:05:28 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA29059; Fri, 3 Nov 1995 01:03:52 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA15622; Fri, 3 Nov 1995 01:03:51 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id XAA16203; Thu, 2 Nov 1995 23:39:28 +0100 From: J Wunsch Message-Id: <199511022239.XAA16203@uriah.heep.sax.de> Subject: Re: Automounting CD-ROMs To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Thu, 2 Nov 1995 23:39:28 +0100 (MET) Cc: lyndon@orthanc.com (Lyndon Nerenberg) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511021912.LAA05649@multivac.orthanc.com> from "Lyndon Nerenberg" at Nov 2, 95 11:12:45 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1453 Sender: owner-hackers@freebsd.org Precedence: bulk As Lyndon Nerenberg wrote: > > I don't buy the argument that having the process hanging around is > going to burn a ton of memory. Most of the time the active code set > would be a short loop probing the device(s). The rest would page out > if real memory was scarce. The SGI manager also didn't buy this argument. They didn't buy it in a lot of places, and the result was an operating system that nobody does really wanna use. :-) > Personally, I don't care whether we handle the problem with a daemon > or standalone command, That wasn't the point. However, i think "on demand" (``automount'') is better than "in advance, since there might be some demand some time later" (``mediad''). > just so long as I (the sysadmin) can specify > what devices the lusers are and are *not* allowed to fiddle with, > and that if luser-1 mounts a volume, luser-2 cannot unmount it to > create a denial of service type attack. Even SGI fails this criterium. Simply log in as luser-2 over the network, type "eject" (well, sometimes you have to type something obvious like "eject /dev/rdsk/fds0d2.3.5.20m" instead :), and *plong*, luser-1 will happily pick up his floptical right out of the slot. ;-) But that doesn't mean i wouldn't agree to your wishlist. Somebody has to implement it however. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)