Date: Mon, 1 Sep 2003 02:25:32 -0400 (EDT) From: "Adam C. Migus" <adam@migus.org> To: "Alexey Neyman" <alex.neyman@auriga.ru> Cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue Message-ID: <51381.192.168.4.2.1062397532.squirrel@mail.migus.org> In-Reply-To: <200307231042.29371.alex.neyman@auriga.ru> References: <20030719171138.GA86442@dragon.nuxi.com><20030722151138.GB72888@dragon.nuxi.com> <20030722153056.GM863@starjuice.net> <200307231042.29371.alex.neyman@auriga.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexey Neyman said: > Hi, there! > > On Tuesday 22 July 2003 19:30, Sheldon Hearn wrote: >> I don't see this as an unreasonable requirement, and I can't see >> what >> great cost it incurs that would motivate us to remove support foraccommodate >> it. >environments > Can't all this be done in a "user needs it, user adds it" fashion? > E.g., to > add /etc/rescue.mk that will be .include'd in > src/rescue/rescue/Makefile,compromise > adding the required binaries to the CRUNCH_PROGS_bin, > CRUNCH_PROG_sbin, > CRUNCH_LIBS lists? > > E.g: > --- /etc/rescue.mk --- > CRUNCH_PROGS_sbin += chown > > This will allow the "base" list to be trimmed to some minimalist > level, and > will still allow the users to add whatever they [think they] need to > restore > their system. > > Regards, > Alexey. > > -- > A quoi ca sert d'etre sur la terre > Si c'est pour faire nos vies a genoux? > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" > At the risk of throwing lighter fluid on smoldering ashes, some thoughts: The whole change to dynamic linking for / is a move to "modernize" FreeBSD. Thus /rescue is a "modern" attempt at creating a /stand. If we're going to be "modern" we ought to think about what "modern" sysadmins need to "rescue" their systems. Administrators as well as operating systems have gotten more "modern" over time. The days of fixing a system with 5 binaries and a not so portable tape drive are gone for some and not even known for others. The tools in /rescue need to accomadate the administrators of today. If they don't, those administrators will find an operating system they can fix more easily. /rescue to me implies "what's needed to rescue you're hosed FreeBSD system." Given FreeBSD system could be a file server, a web server, a firewall, a router or a VCR one could even say to rescue the network. Moreover, these systems could be deployed in a variety of different locations and enviornments. The set of tools required to fix each of these systems and keep them safe while doing so, can be quite different. Finally, this argument essentially comes down to space savings vs. ability to rescue the system. Is 100K of disk space worth 2 hours of time due to a missing tool? One must be very cautious about removing a tool more so than adding it. On the other hand I have to wonder about /rescue/wall... :-) Given these thoughts and some reflection on the previous posts I have a comprimise building on the idea above. Why not make the set of tools in /rescue easily configurable and divide them into three sets: 1. Those that are in the crunch and linked in /rescue, 2. Those that are in the crunch but aren't linked in /rescue, and 3. Those that aren't yet in the crunch. The first being tools everyone agrees are valuable, the second being tools that at least one person thinks might be useful (not in excess of what's there now), the last being tools everyone can agree are useless (and thus aren't there now). That way if an administrator complains about a missing tool someone said might be useful, the answer is "just create a link." If no one thought of it, it's a PR, a headache for the administrator and a lesson learned. In either case the number of complaints for the tool can drive a review process for inclusion in the next release. -- Adam - (http://people.migus.org/~amigus/) Migus Dot Org - (http://www.migus.org/)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51381.192.168.4.2.1062397532.squirrel>