From owner-freebsd-current Sun Jul 16 11:54:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA04277 for current-outgoing; Sun, 16 Jul 1995 11:54:20 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA04269 for ; Sun, 16 Jul 1995 11:54:16 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id LAA09001 for freebsd-current@FreeBSD.org; Sun, 16 Jul 1995 11:53:58 -0700 From: "Rodney W. Grimes" Message-Id: <199507161853.LAA09001@gndrsh.aac.dev.com> Subject: Re: Move mt(1) to /bin? To: freebsd-current@FreeBSD.org Date: Sun, 16 Jul 1995 11:53:58 -0700 (PDT) In-Reply-To: <199507161625.SAA20762@uriah.heep.sax.de> from "J Wunsch" at Jul 16, 95 06:25:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4007 Sender: current-owner@FreeBSD.org Precedence: bulk > > As Rodney W. Grimes wrote: > > > > > Unless somebody objects, i would going to move it some day. > > > > I don't want to go doing this on a binary by binary as the need > > comes up. There are several things that given the same above > > conditions should be moved to /, and several that could move > > the other way. > > Ok. NB: i've made the above threat since this seems to be the only > way to get opinions from other folks here... This is not to say mt(1) > wouldn't be needed, it is. While ``mt fsf'' could also be performed > by ``dd if=/dev/nrst0 of=/dev/null'', things like ``mt blocksize'' and > ``mt density'' cannot be emulated. I don't have a problem with the technical reason that mt should move to /bin (or more probably /sbin since only root and operator class users cat access a tape device anyway) and agree this is one of them that should be static and on / _if_ the critera for being on / says ``Anything needed to restore a system from tape'' as one of it's items. The current man 7 hier is rather ambigous: /bin/ user utilities fundamental to both single-user and multi-user environments /sbin/ system programs and administration utilities fundamental to both single-user and multi-user environments I've almost growen sick of the /bin vs /usr/bin problems and maybe we should do what Bruce is doing and just make _every_ thing shared and move the libraries onto /lib :-) And while we are at it /usr/bin -> /bin and /usr/sbin -> /sbin. (That would be a 13MB increase for the shared /usr/bin and /usr/sbin, 3MB for /usr/lib/*.so.*, and I don't know what the shrink for shared /bin and /sbin is, but I seem to remeber Bruce saying that it makes the /usr/lib/*.so.* actually a 0 size increase to the root partition if you run all of /bin and /sbin shared, but I don't think we want all of it shared (/bin/sh is a bad things to have shared due to frequence of invokation and shlib startup times). I have seriously digressed from the original topic :-(, I'll move mt now, if no one objects to the folling moves: /usr/sbin -> /sbin bad144 (needed to fix your disk before you can restore from tape), chown (needed to fix and build /dev entries so you can mount your disk routed (needed to find routes to remote hosts before mounting nfs /usr or using a remote tape device to restore /usr from) sysctl (needed to tweak settings frequently so you can get to things over the network so you can get your system back to life) /usr/bin -> /bin awk (needed by /dev/MAKEDEV to rebuild several /dev entries that give you serious headaches if you try to do MAKEDEV all without /usr around, could be coded around with sh probably) chflags (So you can fix a permission problem that prevents you from restoring some part of / or /usr.) mt (So you can set the density on /dev/st0 to read your backup tape). I am going to stop now... but you get the idea... I have a very large pile of requests to move stuff to /bin, but not a one to go the other way :-(. IMHO, probably should not do these, though they have been requested at one time or another: kbdcontrol (Yes, I actually have a pending request to make this usable in single user mode, mainly to handle backspace key mapping, and load full keymap files, but that means /usr/share/syscons would need moving too :-() > > Also don't move things around with cvs remove/cvs add, contact me for > > a repository copy, otherwise history information is lost into the Attic. > > Of course. I didn't think about doing this myself. I know that this > is the kind of stuff to leave for our Repository Meister. ;-) > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-) > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD