Date: Wed, 15 May 2002 20:29:25 -0700 From: "Chris McCluskey" <chris@digitaldeck.com> To: <brett@lariat.org> Cc: <mlafren@dowco.com>, <freebsd-security@FreeBSD.ORG> Subject: RE: Patch/Announcement for DHCPD remote root hole? Message-ID: <ECEPLGOFLCLKKCNAGCBHOEOFCCAA.chris@digitaldeck.com> In-Reply-To: <4621.66.171.47.11.1021506833.squirrel@webmail.allneo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Acknowledged misuse of specific list] New to the FreeBSD administration side of things, so I might be able to provide a more unique point of view as compared to all you FreeBSD veterans. Both "sides" from my POV are making valid points (even if the methods of presentation could be improved). I think we all agree that the fix-it-or-forget it philosophy rule applies for all open source development -- whether it's bugs, improvements, or documentation: If you like it, use it -- make it better. If you don't like it, fix it to make it better. The end result -- it's better. In this specific case I think all that is required is a simple front end to cvsup -- a kind-of "This package has been fixed for the following issues... Do you want to build it and install it now?" kind of thing. I'm not ready to write this myself, so I'll "shut up" on the subject. <grin> But I think there is another issue here, which may be more to the point. The FreeBSD documentation is great, but I have yet to see perfect documentation. There are some small potholes in learning the cvsup tool, and there are no concrete examples to follow. For those that are good admins with tarballs and Makefiles, but are new to CVS this is a hard road. The handbook basically says -- we tend to use cvsup, cvsup uses CVS, these are the options, here's a template, now go! A step by step example would be great (saying things like "This is where you specify the release tag. Go to http://here for a list of valid tags."). The important gotchas for me were as follows: 1) Starting out with the template file is good -- but knowing which CVS server supports which protocols, which servers are online, and which servers are "fully-synced" on a certain tree would be valuable. A monitoring web page that checks for these things and a link to this page in the handbook could easily fix this. The mirrors page is just a bit to static. 2) The convention for naming (and retrieving) certain releases is good. But a small blurb refreshing the user/admin as to what the options are would be good. In fact a page listing and annotating the different suffixes would be cool (does it exist already?!). It takes the "new user" a bit of time to understand the labels used, but that's part of the FreeBSD rite of passage. That said some clear references and reminders as to what exactly [example only] RELENG_4_5 is would be nice. A valid frame of reference for cvsup documentation would be to take an admin who has used tarballs, configure scripts, and Makefiles to the next level that of a CVS/cvsup user -- one the things that make BSD unique and cool. My hats off to all the coders, developers, and documentation people -- FreeBSD is a great OS. We can't write code for those that can't read, but for those that can read, let's give them enough text and examples so they can find out how good FreeBSD is -- and can be. Thanks for the time and the bits. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ECEPLGOFLCLKKCNAGCBHOEOFCCAA.chris>