From owner-freebsd-arch Sun Feb 11 9:25:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AC38137B491 for ; Sun, 11 Feb 2001 09:25:09 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1BHP8h76621 for ; Sun, 11 Feb 2001 12:25:08 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 11 Feb 2001 12:25:08 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-arch@FreeBSD.org Subject: Darwin VFSisms - VOP_COPYFILE() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been perusing the Darwin source base for a while now, looking at porting various features back and forth. While visiting Apple in Cuptertino, I had a chance to discuss some of the VFS differences between Darwin and recent FreeBSD. I was particular interested by the following vnode operation that they added: # #% copyfile fvp U U U #% copyfile tdvp L U U #% copyfile tvp X U U # vop_copyfile { IN WILLRELE struct vnode *fvp; IN WILLRELE struct vnode *tdvp; IN WILLRELE struct vnode *tvp; IN struct componentname *tcnp; IN int mode; IN int flags; }; The gist is that rather than manually copying a file in userspace, the operation can be performed using an appropriate system call, pushed down the VFS stack, and implemented by the file system. Much in the same way as our rename() command maps into vop_rename at the VFS layer. For file systems that implement efficient copying internally, this would be a great boon. Two situations come to mind that make it relevant to us: recent introduction of vop_copyonwrite() by Kirk in FFS, and the existence of network file systems that offer a remote copy semantic (RPC), so that when a client performs a copy, the file doesn't have to be shipped over the network twice. My understanding is that Apple introduced this call for AppleShare, which does support the remote copy semantic. I don't know, but would guess that smb/cifs offers a similar RPC. Presumably the VOP would have the opportunity to return EXDEV, as rename() does, to indicate that the copy cannot be done magically, and that the userland utility should fall back on doing it the old-fashioned way. They provide a couple of flags for the flags field: sys/fcntl.h:#define CPF_OVERWRITE 1 sys/fcntl.h:#define CPF_IGNORE_MODE 2 sys/fcntl.h:#define CPF_MASK (CPF_OVERWRITE|CPF_IGNORE_MODE) I'm not sure if their construction of the VOP is right, and we should discuss the semantics with regards to preserving various types of file attributes (copyfile() might do the preservation a lot better than a userland utility, for example), locking, etc. In particular, I'm not sure I like the (mode) argument, which presumably specifies the mode of the new file. I'd like copyfile() to preserve all existing protection attributes (and other attributes) of the source file that the underlying file system knows about. This would make it scale more easily into alternative file system types where the protection of file extended attributes differ. Anyway, your thoughts would be welcome. I'm not suggesting that we import this immediately, rather, that if we find a rationale for doing so (if, for example, smb/cifs does support a remote copy), that we try to structure it in a way similar or identical to the Apple version to increase interoperability. BTW, it would be nice if documentation for VOP_COPYONWRITE() would turn up someday. The idea of VFS is that it's a bit like an RPC interface space: the interface is well-defined, and then various file systems implement that interface. However, if there's no documentation, that makes it all a bit ad hoc :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 11 13:39:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 926B937B401; Sun, 11 Feb 2001 13:39:18 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1BLcJh78866; Sun, 11 Feb 2001 16:38:19 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 11 Feb 2001 16:38:18 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org, freebsd-audit@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: Import of additional kernel ACL support, 0.5.2 ACL release Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (Blatant cross-posting detected by author, sending anyway) The TrustedBSD ACL implementation is now up to release 0.5.2 and appears to be relatively stable when in use. There are several components to the ACL implementation: - Kernel interfaces (ACL system call interface, and VFS interface) - Kernel generics (POSIX.1e evaluation routines, syscall->VFS wrappers/locking/name lookup) - Kernel UFS implementation mapping ACLs into extended attributes - Userland library (acl* in libposix1e) - Userland utilities (getfacl, setfacl) Right now, the userland library (part of libposix1e) is in the base source tree, as are the kernel interfaces (system call and VFS). The userland utilities are now reaching maturity thanks to efforts by Chris Faulhaber, and the libraries are also reach maturity with the help of Chris Faulhaber and Brian Feldman. The next two components I'd like to import are the userland utilities, and the kernel generics. These are relatively mature, and accurately implement the majority of the desirable POSIX.1e and POSIX.2c specs (library and tools respecively). This will allow us to start using ACLs on synthetic file systems, such as sysctlfs and devfs, by providing common evaluation functions in kern_acl.c. Before I import these, I would like it if there could be a fairly thorough review of correctness of the evaluation code in kern_acl.c (in particular, the access control portions that replace the standard vaccess() on file systems providing ACLs). It is very important to me, and I'm sure others, that I do not introduce weaknesses through incorrect implementation :-), and that it comply with the POSIX.1e draft spec so that portable tools supporting ACLs function correctly. The files I intend to commit are src/sys/kern_acl.c and src/sys/sys/acl.h; both exist in -CURRENT right now, but kern_acl.c is largely a stub. There are minor updates to acl.h to reflect the new support functions exported from kern_acl.c. For a copy of the POSIX.1e spec and related documents, see the URLs inside the 0.5.2 tarball, in the references directory. I do not plan to import the UFS/FFS implementation until the extended attribute implementation is more mature -- this is work that we're currently identifying funding for and hope to have underway by summer. These improvements will include a block-level implementation of extended attributes, which will offer higher performance and tighter integration in FFS and with regards to softupdates. The existing implementation on top of current extended attributes appears to work correctly, but it's performance leaves something to be desired. You can grab the complete ACL distribution from: http://www.TrustedBSD.org/downloads/ The 0.5.2 distribution is now online and available for download, and should apply against a recent -CURRENT (although you probably want to avoid the SMP instabilities from yesterday, and brief lc* stuff today). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 11 18:53:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 127DE37B4EC; Sun, 11 Feb 2001 18:53:48 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id 6BC2128DD1; Mon, 12 Feb 2001 08:53:43 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 60C9B28DBE; Mon, 12 Feb 2001 08:53:43 +0600 (ALMT) Date: Mon, 12 Feb 2001 08:53:43 +0600 (ALMT) From: Boris Popov To: Robert Watson Cc: freebsd-arch@FreeBSD.org Subject: Re: Darwin VFSisms - VOP_COPYFILE() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Feb 2001, Robert Watson wrote: > vop_copyfile { > IN WILLRELE struct vnode *fvp; > IN WILLRELE struct vnode *tdvp; > IN WILLRELE struct vnode *tvp; > IN struct componentname *tcnp; > IN int mode; > IN int flags; > }; > > network twice. My understanding is that Apple introduced this call for > AppleShare, which does support the remote copy semantic. I don't know, > but would guess that smb/cifs offers a similar RPC. Presumably the VOP Yes, SMB protocol have similar RPC and NCP (NetWare Core Protocol have it too). > would have the opportunity to return EXDEV, as rename() does, to indicate > that the copy cannot be done magically, and that the userland utility > should fall back on doing it the old-fashioned way. Correct. > They provide a couple of flags for the flags field: > > sys/fcntl.h:#define CPF_OVERWRITE 1 > sys/fcntl.h:#define CPF_IGNORE_MODE 2 > sys/fcntl.h:#define CPF_MASK (CPF_OVERWRITE|CPF_IGNORE_MODE) 'IGNORE_MODE' sounds a bit unclear. > I'm not sure if their construction of the VOP is right, and we should > discuss the semantics with regards to preserving various types of file > attributes (copyfile() might do the preservation a lot better than a > userland utility, for example), locking, etc. In particular, I'm not sure > I like the (mode) argument, which presumably specifies the mode of the new > file. I'd like copyfile() to preserve all existing protection attributes > (and other attributes) of the source file that the underlying file system > knows about. This would make it scale more easily into alternative file > system types where the protection of file extended attributes differ. Well, I think behavior of VOP_COPYFILE should very well documented, because any misbehavior may lead to significant data loss. The major problem is that copyfile-like RPCs are very OS/protocol specific. For example, NCP allows user to copy any number of bytes from specified offset in the source file to specified offset in the destination file. SMB protocol doesn't support any of these parameters. But SMB protocol offers ability to copy multiple files (using wildcards) and even a MOVE RPC which deletes file(s) after copy. I'm unsure, but some sort of 'capabilities' bits would be useful. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 11 19:35:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 8177437B401; Sun, 11 Feb 2001 19:35:12 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id UAA09517; Sun, 11 Feb 2001 20:33:46 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpdAAAcAayFs; Sun Feb 11 20:33:34 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id UAA18209; Sun, 11 Feb 2001 20:34:57 -0700 (MST) From: Terry Lambert Message-Id: <200102120334.UAA18209@usr08.primenet.com> Subject: Re: Darwin VFSisms - VOP_COPYFILE() To: bp@butya.kz (Boris Popov) Date: Mon, 12 Feb 2001 03:34:57 +0000 (GMT) Cc: rwatson@FreeBSD.ORG (Robert Watson), freebsd-arch@FreeBSD.ORG In-Reply-To: from "Boris Popov" at Feb 12, 2001 08:53:43 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well, I think behavior of VOP_COPYFILE should very well > documented, because any misbehavior may lead to significant data loss. > > The major problem is that copyfile-like RPCs are very OS/protocol > specific. For example, NCP allows user to copy any number of bytes from > specified offset in the source file to specified offset in the destination > file. SMB protocol doesn't support any of these parameters. But SMB > protocol offers ability to copy multiple files (using wildcards) and even > a MOVE RPC which deletes file(s) after copy. > > I'm unsure, but some sort of 'capabilities' bits would be useful. Better to just fail the call, if it used against an FS where it's not implemented. This is the way the other VOP's operate. If you introduce capability bit, then you have to define them and maintain them between operating systems. One of the original goals of the Heidemann stacking framework, and the reason that it uses descriptors, it that they can be transparently passed through layers or even proxied across a network, without intermediate layers (or hosts) needing to be able to understand their contents. Anything that creates a need to rendesvous between a producer and consumer unnecessarily is a bad thing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 11 19:38:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 11D1737B401; Sun, 11 Feb 2001 19:38:20 -0800 (PST) Received: from xor.obsecurity.org ([63.207.60.67]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G8M00I36KH0NT@mta5.snfc21.pbi.net>; Sun, 11 Feb 2001 19:31:49 -0800 (PST) Received: by xor.obsecurity.org (Postfix, from userid 1000) id 187B366B32; Sun, 11 Feb 2001 19:34:33 -0800 (PST) Date: Sun, 11 Feb 2001 19:34:32 -0800 From: Kris Kennaway Subject: Re: cvs commit: src/usr.bin/login login.c In-reply-to: ; from rwatson@FreeBSD.org on Sun, Feb 11, 2001 at 10:27:19PM -0500 To: Robert Watson Cc: Garance A Drosihn , Kris Kennaway , Jacques Vidrine , arch@FreeBSD.org, security-officer@FreeBSD.org Message-id: <20010211193432.A5428@mollari.cthul.hu> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-disposition: inline User-Agent: Mutt/1.2.5i References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 11, 2001 at 10:27:19PM -0500, Robert Watson wrote: > Perhaps I'm confused here, but isn't the list above the list of > environmental variables being applied to environmental variables exported > by the authentication/login authorization system itself? I'm a bit > confused as to why those variables even need filtering, other than to > discourage module developers from colliding on use of these potentially > abused variables. Yes, this has been clarified, although I still worry about a PAM module passing in environment variables from the remote system somehow. > More on your point, however -- having a centralized list of "safe"=20 > variables, possibly classifiable by user class, would be nice. However, a > lot of the places where this list of variables is needed are places where > a user class is not available -- for example, in the telnetd->login > transition.=20 Yes, we need a way for the administrator to add environment variables which are safe or desired in the local environment. Recently telnetd was changed to filter out all but a set of known safe variables, so the only way for an administrator to do this would be to recompile telnetd. Kris --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6h1nIWry0BWjoQKURAgESAKCaH4+2o+wZ/DTgoS9bIoElDeIUdACgn2Oy YQrp7CV5sqSzsLxGOREEiQk= =BmuL -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 0:49: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5C0B237B491; Mon, 12 Feb 2001 00:49:01 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA29343; Mon, 12 Feb 2001 19:48:52 +1100 Date: Mon, 12 Feb 2001 19:48:27 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Brian Somers Cc: John Baldwin , Chuck Paterson , freebsd-arch@FreeBSD.ORG Subject: Re: usb, clists, spltty, splbio In-Reply-To: <200102091736.f19HaJN01324@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Feb 2001, Brian Somers wrote: > > On 09-Feb-01 Chuck Paterson wrote: > > > > > > I have been mucking with making moused talk to a usb joystick. > > > This all turned out pretty straight forward, all user land code in > > > moused talking to the hid device. The problem is that the kernel > > > crashes randomly, more often as the system get more loaded. A couple > > > of times I got a panic in the clist code, but it really didn't > > > show anything direct. Oh yah, this is with stable, not current. > > > > > > Reading through the code I found what looks like a problem. > > > The hid, and other usb code use clists. The various usb code is > > > protected by splusb which is a defined as splbio. The function > > > b_to_q() and all the other clist code use spltty. > > > > > > I changed the definition of spltty from > > > > > > GENSPL(spltty, |=, tty_imask, > > 14) > > > > > > to > > > > > > GENSPL(spltty, |=, tty_imask | bio_imask, > > 14) > > > > > > and the crashes appear to have gone away. I say appear, it has run > > > longer now than it has before, but it hasn't been up much more than > > > twice as long yet. > > > > > > I am not quite sure the best way to deal with this. The only > > > idea I have thought of that I like at all is to create a splclist() > > > which is the or of tty and bio and put that into the code that > > > mucks with clists, perhaps just the allocation/free routines. > > > > We have a similar problem with the slip and ppp devices, which have > > run code under botth spltty and splnet. The trick we use there is > > to actually change the imasks by doing something along the lines of: > > > > net_mask |= tty_imask; > > tty_imask = net_imask; > > > > So there is at least prior precedent for doing this sort of thing. > > Hmm. I would think that Chucks' idea has the advantage that it > doesn't adversely affect existing splnet/spltty code. Despite this > only mattering for a finite amount of time, I don't think the > precedent is good here :-/ It is more robust, but to be completely robust it would have to use (bio_imask | net_imask | tty_imask) for all of splbio(), splimp() and spltty(). This is a small step away from using splhigh() for everything. I sometimes feel that there should have been at at most 3 hardware spls: slpall(), splallbutclocks() and splnone(). Some machines can only support splall() and splnone(), so MI code shouldn't require more than 2 levels to operate properly, and optimizing for that case might be good for all cases (it essentially requires all hardware interrupt handlers to not take very long). I don't completely understand the uhid bug, but it seems to be a little different from the one with slip and ppp. Usb doesn't seem to use the hardware usb interrupt, and it only seems to use SWIs for netisrs, so I assume it uses timeouts for the relevant interrupt handlers. This makes it more like vpo than slip or ppp, so there should be no problem -- timeouts are certainly masked by spltty(), and we don't need splusb() to mask tty interrupts because non-usb tty drivers don't use usb code or data (*). The problem may be that usb is unwarrantedly chummy with the clist internals, but not chummy enough to use the correct spl for accessing them, e.g., in uhid_do_read(). However, I can't see how this would cause panics. (*) Part of the problem in slip and ppp is that the net and tty subsystems can get in each others way. This is handled in slip by setting set the imasks equal, and in ppp by setting the masks much more subtly and using a few extra spls. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 1:50:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (unknown [194.128.198.234]) by hub.freebsd.org (Postfix) with ESMTP id 4B51237B401; Mon, 12 Feb 2001 01:50:44 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.1/8.11.1) id f1BIa3e12115; Sun, 11 Feb 2001 18:36:03 GMT (envelope-from nik) Date: Sun, 11 Feb 2001 18:36:03 +0000 From: Nik Clayton To: Robert Watson Cc: freebsd-arch@FreeBSD.org Subject: Re: Darwin VFSisms - VOP_COPYFILE() Message-ID: <20010211183603.A12094@canyon.nothing-going-on.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Sun, Feb 11, 2001 at 12:25:08PM -0500 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 11, 2001 at 12:25:08PM -0500, Robert Watson wrote: > BTW, it would be nice if documentation for VOP_COPYONWRITE() would turn up > someday. The idea of VFS is that it's a bit like an RPC interface space: > the interface is well-defined, and then various file systems implement > that interface. However, if there's no documentation, that makes it all a > bit ad hoc :-). Someone ship me a copy of "Filesystems for dummies" :-) N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 5:28: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 9B10B37B401; Mon, 12 Feb 2001 05:27:57 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 6B52218C93; Mon, 12 Feb 2001 07:27:56 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1CDRuI39934; Mon, 12 Feb 2001 07:27:56 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 12 Feb 2001 07:27:56 -0600 From: "Jacques A. Vidrine" To: Kris Kennaway Cc: Robert Watson , Garance A Drosihn , arch@FreeBSD.org, security-officer@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/login login.c Message-ID: <20010212072756.A39882@hamlet.nectar.com> References: <20010211193432.A5428@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010211193432.A5428@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 11, 2001 at 07:34:32PM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 11, 2001 at 07:34:32PM -0800, Kris Kennaway wrote: > On Sun, Feb 11, 2001 at 10:27:19PM -0500, Robert Watson wrote: > > > Perhaps I'm confused here, but isn't the list above the list of > > environmental variables being applied to environmental variables exported > > by the authentication/login authorization system itself? I'm a bit > > confused as to why those variables even need filtering, other than to > > discourage module developers from colliding on use of these potentially > > abused variables. > > Yes, this has been clarified, although I still worry about a PAM > module passing in environment variables from the remote system > somehow. This is easy to check: 1) It is a bug for a PAM module to call `putenv' or `setenv'. 2) If a PAM module wishes to modify the environment, it notifies the application by caling `pam_putenv'. [1] It's simple to audit a PAM module for these cases. Note that none of the modules in our base system modify the environment. The only module that I know of that modifies the environment is pam_krb5 -- it sets KRB5CCNAME (via pam_putenv, of course). > > More on your point, however -- having a centralized list of "safe" > > variables, possibly classifiable by user class, would be nice. However, a > > lot of the places where this list of variables is needed are places where > > a user class is not available -- for example, in the telnetd->login > > transition. > > Yes, we need a way for the administrator to add environment variables > which are safe or desired in the local environment. Recently telnetd > was changed to filter out all but a set of known safe variables, so > the only way for an administrator to do this would be to recompile > telnetd. [this more or less directed at the comment about restricted variables determined by user class] I'm skeptical. It is up to the application that is granting priviledges to decide what is safe in the environment. e.g. sshd might set SSH_* stuff; sshd, telnetd, login might set KRB5CCNAME; xdm might set DISPLAY, XDM*; who knows what else may come down the line. Such trusted applications must be audited anyway. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org [1] It is this list of environmental variables that my commit `filters'. For the convenience of archive users, I'll restate here that the `filter' is present merely to duplicate the behavior of Solaris login/PAM interaction. Previous to my commit, _no_ variables were exported -- which was a bug. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 6: 9:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 1CF9E37B491; Mon, 12 Feb 2001 06:09:32 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 12 Feb 2001 14:09:31 +0000 (GMT) To: Boris Popov Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org, iedowse@maths.tcd.ie Subject: Re: CFR: Sequential mbuf read/write extensions In-Reply-To: Your message of "Fri, 09 Feb 2001 08:30:48 +0600." Date: Mon, 12 Feb 2001 14:09:30 +0000 From: Ian Dowse Message-ID: <200102121409.aa34378@salmon.maths.tcd.ie> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Boris Popo v writes: > No, in the current implementation mb_get* functions will work >properly. But mb_put* will fail. This can be avoided by implementing >alignment-safe set* macros (which can be written in two variants - first >form is for aligned objects and second for bad aligned ones). Ah, I missed the details of how the mb_get functions work - you just perform a byte-by-byte copy into the destination. Great! I wonder if it makes sense to do something similar for the mb_put functions too? BTW, I'd recommend making MB_PUT() a more 'normal' macro, or even calling mb_fit directly from the mb_put functions - the implicit declaration of 'p' and use of 'mbp' is confusing. If mb_fit was changed to return a void *, the code wouldn't look too bad, and would be less magic. e.g.: int mb_put_byte(struct mbdata *mbp, u_int8_t x) { u_int8_t *p; if ((p = mb_fit(mbp, sizeof(*p))) == NULL) return (ENUBUFS); *p = x; return (0); } > Hmm, since so_send() can fail and some erros can be recovered by >another call to so_send(), I'm just called m_copym() to duplicate the mbuf >chain and give it to so_send(). This is reasonable for a client of an RPC-type protocol, but the server side may wish to give the reply to the sosend function and ignore errors - NFS does this for example. It seems natural to call the _init function to clobber any state, though the semantics aren't that important. There just needs to be a defined way of disassociating the chain from the mbdata struct so that mb_done will not free it. If you are going to split struct mbdata into two structs, you can probably optimise operations a bit by storing the right information for each case. For the build case, maybe: struct mbuf *mb_top; /* head of chain */ struct mbuf *mb_cur; /* current (last) mbuf in chain */ int mb_mleft; /* bytes remaining in mb_cur */ int mb_count; /* total bytes in chain */ Storing the number of bytes remaining in the current mbuf as 'mb_mleft' avoids using M_TRAILINGSPACE() which expands to quite a complex expression. The current offset is not explicitly stored in mbdata, but evaluating 'mtod(m, char *) + m->m_len' is cheap. An optimised case at the start of mb_fit could look like m = mbp->mb_cur; if (mbp->mb_top != NULL && size <= mbp->mb_mleft) { mbp->mb_mleft -= size; mbp->mb_count += size; bpos = mtod(m, char *) + m->m_len; m->m_len += size; return (bpos); } but I guess worrying about minor optimisations like these probably isn't too important now :-) For the breakdown, you probably only need: struct mbuf *mb_top; /* head of chain */ struct mbuf *mb_cur; /* current mbuf in chain */ u_char *mb_pos; /* current position in mb_cur */ Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 13:19: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 2F06A37B491 for ; Mon, 12 Feb 2001 13:18:58 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1CLIo926029 for ; Mon, 12 Feb 2001 23:18:53 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102122118.f1CLIo926029@gratis.grondar.za> To: arch@freebsd.org Subject: LOCORE considered evil... Date: Mon, 12 Feb 2001 23:19:24 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi In my grovellings through the kernel, I became rather annoyed with the LOCORE macro. This used to mean (inside #ifdef LOCORE/#endif) "this code is inside locore.s, do not show any C code". These days it has come to mean 'this (#if .../#endif) code is assmbler code, please don't bother me with C'. Thus, LOCORE is meaningless, and counter-intuitive. I have replaced LOCORE (and _LOCORE) with __ASM__, and put the patch up at http://people.freebsd.org/~markm/patches/sys.LOCORE.diff. Please test and review. Please resist bikeshedding :-) (It works on i386, i386/LINT compiles, and alpha/GENERIC compiles. Alpha/Generic has not been runtested). There is a _tiny_ userland patch that goes with this. Utterly trivial. (Available on request) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 17:48:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 9B4F537B491 for ; Mon, 12 Feb 2001 17:48:29 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1D1mSq09285 for freebsd-arch@freebsd.org; Mon, 12 Feb 2001 17:48:28 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Feb 2001 17:48:28 -0800 From: "David O'Brien" To: freebsd-arch@freebsd.org Subject: Proposal on shared libs version values. Message-ID: <20010212174828.Q3038@dragon.nuxi.com> Reply-To: freebsd-alpha@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know why the participants of this will not bring this to -arch for discussion..... So I will. The proposal on the table is an allowance in our policy that in -CURRENT, a shared lib's version number may be bumped to "<-CURRENT_MAJ_VER_NUMBER>XY", where XY=00 initially when the FreeBSD major version is bumped (ie, right after a new -STABLE branch is created). [note we may want to postpone the bumping until the first non-compatible change to help keep track of which libs are incompatible with the latest -STABLE] At any point along the development of -CURRENT that a shared version bump would be helpful. One month (or so) before the -CURRENT --> -BETA change (ie, feature slush) we change the shared libs' version numbers to the next consecutive value from what is in the latest -STABLE. Opinions? -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 17:56:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id CFE7637B4EC for ; Mon, 12 Feb 2001 17:56:52 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id CAA92773; Tue, 13 Feb 2001 02:56:52 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. References: <20010212174828.Q3038@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 13 Feb 2001 02:56:51 +0100 In-Reply-To: "David O'Brien"'s message of "Mon, 12 Feb 2001 17:48:28 -0800" Message-ID: Lines: 15 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" writes: > Opinions? Count me as an "aye". I've modified Peter's patch and posted it on freefall: http://people.freebsd.org/~des/software/stdio-20010213.diff I haven't tested it yet, but am reasonably certain that 'make world' will complete without a hitch with this patch. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 17:58:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id BE1ED37B491 for ; Mon, 12 Feb 2001 17:58:20 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1D1wKY09561 for freebsd-arch@freebsd.org; Mon, 12 Feb 2001 17:58:20 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Feb 2001 17:58:19 -0800 From: "David O'Brien" To: freebsd-arch@freebsd.org Subject: Proposal on shared libs version values. Message-ID: <20010212175819.A9537@dragon.nuxi.com> Reply-To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [reply to *THIS* one, not the one with the wrong reply-to: -alpha] I don't know why the participants of this will not bring this to -arch for discussion..... So I will. The proposal on the table is an allowance in our policy that in -CURRENT, a shared lib's version number may be bumped to "<-CURRENT_MAJ_VER_NUMBER>XY", where XY=00 initially when the FreeBSD major version is bumped (ie, right after a new -STABLE branch is created). [note we may want to postpone the bumping until the first non-compatible change to help keep track of which libs are incompatible with the latest -STABLE] At any point along the development of -CURRENT that a shared version bump would be helpful. One month (or so) before the -CURRENT --> -BETA change (ie, feature slush) we change the shared libs' version numbers to the next consecutive value from what is in the latest -STABLE. Opinions? -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 17:58:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id CBA2037B503; Mon, 12 Feb 2001 17:58:34 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id CAA92793; Tue, 13 Feb 2001 02:58:34 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: freebsd-alpha@FreeBSD.ORG Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. References: <20010212174828.Q3038@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 13 Feb 2001 02:58:33 +0100 In-Reply-To: "David O'Brien"'s message of "Mon, 12 Feb 2001 17:48:28 -0800" Message-ID: Lines: 5 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please follow up on -arch, not on -alpha... DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 18: 0: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id C3C2937B491; Mon, 12 Feb 2001 18:00:06 -0800 (PST) Date: Mon, 12 Feb 2001 18:00:06 -0800 From: David O'Brien To: freebsd-arch@freebsd.org Subject: Re: Proposal on shared libs version values. Message-ID: <20010212180006.A990@hub.freebsd.org> Reply-To: freebsd-arch@freebsd.org References: <20010212174828.Q3038@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010212174828.Q3038@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Mon, Feb 12, 2001 at 05:48:28PM -0800 X-Operating-System: FreeBSD 4.2-STABLE Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 12, 2001 at 05:48:28PM -0800, David O'Brien wrote: > I don't know why the participants of this will not bring this to -arch > for discussion..... So I will. PLEASE, do not reply to this email, I have the "reply-to" to the wrong list. I reposted the message with a correct replyto. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 18: 8:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 1CA7837B491 for ; Mon, 12 Feb 2001 18:08:16 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1D28FY09777 for freebsd-arch@FreeBSD.ORG; Mon, 12 Feb 2001 18:08:15 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Feb 2001 18:08:14 -0800 From: "David O'Brien" To: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. Message-ID: <20010212180814.V3038@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20010212174828.Q3038@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Tue, Feb 13, 2001 at 02:56:51AM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 13, 2001 at 02:56:51AM +0100, Dag-Erling Smorgrav wrote: > I've modified Peter's patch and posted it on freefall: > http://people.freebsd.org/~des/software/stdio-20010213.diff > > I haven't tested it yet, but am reasonably certain that 'make world' > will complete without a hitch with this patch. Well... that is another story. It would certainly be nice if this patch were `make world' tested before committing. We've seen enough breakage this week due to hack of proper testing before committing. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 18:58:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 49CD537B491 for ; Mon, 12 Feb 2001 18:58:53 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id DAA93080; Tue, 13 Feb 2001 03:58:52 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. References: <20010212174828.Q3038@dragon.nuxi.com> <20010212180814.V3038@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 13 Feb 2001 03:58:51 +0100 In-Reply-To: "David O'Brien"'s message of "Mon, 12 Feb 2001 18:08:14 -0800" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" writes: > On Tue, Feb 13, 2001 at 02:56:51AM +0100, Dag-Erling Smorgrav wrote: > > I haven't tested it yet, but am reasonably certain that 'make world' > > will complete without a hitch with this patch. > Well... that is another story. It would certainly be nice if this patch > were `make world' tested before committing. Did you happen to notice the "yet" in that sentence? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 22:23: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 6E42437B491 for ; Mon, 12 Feb 2001 22:23:06 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1D6N2H80985 for ; Mon, 12 Feb 2001 22:23:02 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. In-Reply-To: Message from "David O'Brien" of "Mon, 12 Feb 2001 18:08:14 PST." <20010212180814.V3038@dragon.nuxi.com> Date: Mon, 12 Feb 2001 22:23:01 -0800 Message-ID: <80981.982045381@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well... that is another story. It would certainly be nice if this patch > were `make world' tested before committing. We've seen enough breakage > this week due to hack of proper testing before committing. Well, it almost works but falls over during the build of perl: cc -O -pipe -I/usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5 -I/usr/ob j/usr/src/gnu/usr.bin/perl/perl -DPERL_CORE -I/usr/obj/usr/src/i386/usr/includ e -Wl,-E -L/usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl -o perl perlmain.o lib/auto/DynaLoader/DynaLoader.a -lperl -lm -lcrypt -lmd /usr/lib/libutil.so.3: undefined reference to `__sF' *** Error code 1 - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 22:24:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8072E37B491 for ; Mon, 12 Feb 2001 22:24:53 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id HAA93719; Tue, 13 Feb 2001 07:24:49 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Jordan Hubbard Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. References: <80981.982045381@winston.osd.bsdi.com> From: Dag-Erling Smorgrav Date: 13 Feb 2001 07:24:49 +0100 In-Reply-To: Jordan Hubbard's message of "Mon, 12 Feb 2001 22:23:01 -0800" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan Hubbard writes: > Well, it almost works but falls over during the build of perl: This is an unrelated bug which the patch uncovers, Peter just fixed it an hour ago. Update your sources and try again. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 22:50:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id C6F7C37B491 for ; Mon, 12 Feb 2001 22:50:10 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1D6lXU59162; Mon, 12 Feb 2001 22:47:33 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102130647.f1D6lXU59162@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: Jordan Hubbard , freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. In-Reply-To: Date: Mon, 12 Feb 2001 22:47:33 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Jordan Hubbard writes: > > Well, it almost works but falls over during the build of perl: > > This is an unrelated bug which the patch uncovers, Peter just fixed it > an hour ago. Update your sources and try again. A post-perl-fix buildworld finished while I drove home. An installworld is in progress.. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 12 22:57:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 812FB37B491 for ; Mon, 12 Feb 2001 22:57:29 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1D6sIU59242; Mon, 12 Feb 2001 22:54:19 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102130654.f1D6sIU59242@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Dag-Erling Smorgrav , Jordan Hubbard , freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. In-Reply-To: <200102130647.f1D6lXU59162@mobile.wemm.org> Date: Mon, 12 Feb 2001 22:54:18 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: > Dag-Erling Smorgrav wrote: > > Jordan Hubbard writes: > > > Well, it almost works but falls over during the build of perl: > > > > This is an unrelated bug which the patch uncovers, Peter just fixed it > > an hour ago. Update your sources and try again. > > A post-perl-fix buildworld finished while I drove home. An installworld is > in progress.. The tail of which just ended with the usual: [..] install: sshd -> /usr/sbin/sshd install -Cv -c -o root -g wheel -m 444 sshd.8.gz /usr/share/man/man8 ===> etc ===> etc/sendmail install -Cv -c -o root -g wheel -m 644 freebsd.cf /etc/mail/sendmail.cf install: freebsd.cf -> /etc/mail/sendmail.cf -------------------------------------------------------------- >>> Rebuilding man page indices -------------------------------------------------------------- cd /home/src/share/man; make makedb makewhatis /usr/share/man gzcat: stdout: Broken pipe [10 screenfulls deleted] gzcat: stdout: Broken pipe gzcat: stdout: Broken pipe rm -rf /tmp/install.553 45.408u 46.693s 6:05.16 25.2% 278+515k 6979+47293io 15693pf+0w Script done, output file is install.log Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 4:54: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 48BC337B503 for ; Tue, 13 Feb 2001 04:54:04 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA95025; Tue, 13 Feb 2001 13:54:03 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: sparse core dumps From: Dag-Erling Smorgrav Date: 13 Feb 2001 13:54:02 +0100 Message-ID: Lines: 40 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I finally found the time to finish hacking savecore(8) to generate sparse dumps. The good news is it's even noticeably faster than the old version :) There's a patch up on freefall: http://people.freebsd.org/~des/software/savecore-20010213.diff Here's a side-by-side comparison (using a version of savecore(8) that doesn't clear the dump after saving it): root@rsa /var/crash2# time savecore $(pwd) savecore: reboot after panic: from debugger savecore: system went down at Tue Feb 13 11:33:22 2001 savecore: /var/crash2/bounds: No such file or directory savecore: writing core to /var/crash2/vmcore.0 savecore: writing kernel to /var/crash2/kernel.0 savecore /var/crash2 0.17s user 32.25s system 19% cpu 2:48.72 total root@rsa /var/crash2# time /tmp/savecore $(pwd) savecore: reboot after panic: from debugger savecore: system went down at Tue Feb 13 11:33:22 2001 savecore: writing core to /var/crash2/vmcore.1 savecore: writing kernel to /var/crash2/kernel.1 /tmp/savecore /var/crash2 18.29s user 5.62s system 19% cpu 1:59.96 total root@rsa /var/crash2# du -k vmcore.0 vmcore.1 524352 vmcore.0 35712 vmcore.1 root@rsa /var/crash2# cmp vmcore.0 vmcore.1 && echo 'Mrreaow!' Mrreaow! This is with a 4096-byte block size (equal to PAGE_SIZE), which was noticeably better than my original choice of 512 bytes. I think the best overall block size is the crashed kernel's page size, as most of the holes will originate from (series of) zeroed pages; I tried 8192-byte blocks (my /var/crash and /var/crash2 file systems have 64k blocks and 8k fragments) but noticed no improvement. Writing to a file system with smaller (1024-byte) fragments gave a smaller actual disk usage but a 50% increase in system time. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 5:44:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id 6437137B491 for ; Tue, 13 Feb 2001 05:44:34 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 14Sfkv-0004xw-0V; Tue, 13 Feb 2001 13:44:33 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.1/8.8.8) with ESMTP id f1DDiWs62957; Tue, 13 Feb 2001 13:44:32 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 13 Feb 2001 13:44:32 +0000 (GMT) From: Doug Rabson To: Dag-Erling Smorgrav Cc: Subject: Re: sparse core dumps In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 13 Feb 2001, Dag-Erling Smorgrav wrote: > I finally found the time to finish hacking savecore(8) to generate > sparse dumps. The good news is it's even noticeably faster than the > old version :) There's a patch up on freefall: > > http://people.freebsd.org/~des/software/savecore-20010213.diff > > Here's a side-by-side comparison (using a version of savecore(8) that > doesn't clear the dump after saving it): > > root@rsa /var/crash2# time savecore $(pwd) > savecore: reboot after panic: from debugger > savecore: system went down at Tue Feb 13 11:33:22 2001 > savecore: /var/crash2/bounds: No such file or directory > savecore: writing core to /var/crash2/vmcore.0 > savecore: writing kernel to /var/crash2/kernel.0 > savecore /var/crash2 0.17s user 32.25s system 19% cpu 2:48.72 total > root@rsa /var/crash2# time /tmp/savecore $(pwd) > savecore: reboot after panic: from debugger > savecore: system went down at Tue Feb 13 11:33:22 2001 > savecore: writing core to /var/crash2/vmcore.1 > savecore: writing kernel to /var/crash2/kernel.1 > /tmp/savecore /var/crash2 18.29s user 5.62s system 19% cpu 1:59.96 total > root@rsa /var/crash2# du -k vmcore.0 vmcore.1 > 524352 vmcore.0 > 35712 vmcore.1 > root@rsa /var/crash2# cmp vmcore.0 vmcore.1 && echo 'Mrreaow!' > Mrreaow! Cool! > > This is with a 4096-byte block size (equal to PAGE_SIZE), which was > noticeably better than my original choice of 512 bytes. I think the > best overall block size is the crashed kernel's page size, as most of > the holes will originate from (series of) zeroed pages; I tried > 8192-byte blocks (my /var/crash and /var/crash2 file systems have 64k > blocks and 8k fragments) but noticed no improvement. Writing to a file > system with smaller (1024-byte) fragments gave a smaller actual disk > usage but a 50% increase in system time. Probably it should just use getpagesize() to decide what block size to use. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 5:53:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 2D16637B65D for ; Tue, 13 Feb 2001 05:53:42 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 14Sftk-000HZi-0W; Tue, 13 Feb 2001 13:53:40 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.1/8.8.8) with ESMTP id f1DDrTs63009; Tue, 13 Feb 2001 13:53:39 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 13 Feb 2001 13:53:29 +0000 (GMT) From: Doug Rabson To: Peter Wemm Cc: Dag-Erling Smorgrav , Jordan Hubbard , Subject: Re: Proposal on shared libs version values. In-Reply-To: <200102130654.f1D6sIU59242@mobile.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Feb 2001, Peter Wemm wrote: > Peter Wemm wrote: > > Dag-Erling Smorgrav wrote: > > > Jordan Hubbard writes: > > > > Well, it almost works but falls over during the build of perl: > > > > > > This is an unrelated bug which the patch uncovers, Peter just fixed it > > > an hour ago. Update your sources and try again. > > > > A post-perl-fix buildworld finished while I drove home. An installworld is > > in progress.. > > The tail of which just ended with the usual: > > ... > > gzcat: stdout: Broken pipe > I don't understand. If this build was with the version number bumped to 501, what is is causing the problem. In general, if we can construct a build which actually works, I fully support the idea of using three digit version numbers during development. The last thing we need is for people to waste valuable development time working around version number problems. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 5:54:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7B60237B491 for ; Tue, 13 Feb 2001 05:54:19 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA95316; Tue, 13 Feb 2001 14:54:15 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Doug Rabson Cc: Subject: Re: sparse core dumps References: From: Dag-Erling Smorgrav Date: 13 Feb 2001 14:54:15 +0100 In-Reply-To: Doug Rabson's message of "Tue, 13 Feb 2001 13:44:32 +0000 (GMT)" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson writes: > Probably it should just use getpagesize() to decide what block size to > use. Why not just hardcode PAGE_SIZE like I did? An incorrect value will still work, just slightly less efficiently. Empirical tests show that as long as you stick to reasonable values, the block size doesn't affect disk usage much. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 5:56:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rapier.smartspace.co.za (rapier.smartspace.co.za [66.8.25.34]) by hub.freebsd.org (Postfix) with SMTP id 1B7D137B503 for ; Tue, 13 Feb 2001 05:56:10 -0800 (PST) Received: (qmail 71207 invoked by uid 1001); 13 Feb 2001 13:55:43 -0000 Date: Tue, 13 Feb 2001 15:55:43 +0200 From: Neil Blakey-Milner To: Doug Rabson Cc: Peter Wemm , freebsd-arch@freebsd.org Subject: Re: Proposal on shared libs version values. Message-ID: <20010213155542.A71042@rapier.smartspace.co.za> References: <200102130654.f1D6sIU59242@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dfr@nlsystems.com on Tue, Feb 13, 2001 at 01:53:29PM +0000 Organization: Building Intelligence X-Operating-System: FreeBSD 4.2-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue 2001-02-13 (13:53), Doug Rabson wrote: > > Peter Wemm wrote: > > > Dag-Erling Smorgrav wrote: > > > > Jordan Hubbard writes: > > > > > Well, it almost works but falls over during the build of perl: > > > > > > > > This is an unrelated bug which the patch uncovers, Peter just fixed it > > > > an hour ago. Update your sources and try again. > > > > > > A post-perl-fix buildworld finished while I drove home. An installworld is > > > in progress.. > > > > The tail of which just ended with the usual: > > > > ... > > > > gzcat: stdout: Broken pipe > > > > I don't understand. If this build was with the version number bumped to > 501, what is is causing the problem. > > In general, if we can construct a build which actually works, I fully > support the idea of using three digit version numbers during development. > The last thing we need is for people to waste valuable development time > working around version number problems. It could be the openssh sigpipe thing that Matt Dillon was looking at. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 5:57:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B3B0137B4EC for ; Tue, 13 Feb 2001 05:57:37 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA95347; Tue, 13 Feb 2001 14:57:35 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Doug Rabson Cc: Peter Wemm , Jordan Hubbard , Subject: Re: Proposal on shared libs version values. References: From: Dag-Erling Smorgrav Date: 13 Feb 2001 14:57:35 +0100 In-Reply-To: Doug Rabson's message of "Tue, 13 Feb 2001 13:53:29 +0000 (GMT)" Message-ID: Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson writes: > I don't understand. If this build was with the version number bumped to > 501, what is is causing the problem. The "broken pipe" problem is a bug in makewhatis, not in libc, and is totally irrelevant to what is being discussed here. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 5:58:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id 9A78137B4EC for ; Tue, 13 Feb 2001 05:58:48 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 14Sfyh-0003JX-0U; Tue, 13 Feb 2001 13:58:47 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.1/8.8.8) with ESMTP id f1DDwls63080; Tue, 13 Feb 2001 13:58:47 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 13 Feb 2001 13:58:47 +0000 (GMT) From: Doug Rabson To: Dag-Erling Smorgrav Cc: Subject: Re: sparse core dumps In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 13 Feb 2001, Dag-Erling Smorgrav wrote: > Doug Rabson writes: > > Probably it should just use getpagesize() to decide what block size to > > use. > > Why not just hardcode PAGE_SIZE like I did? An incorrect value will > still work, just slightly less efficiently. Empirical tests show that > as long as you stick to reasonable values, the block size doesn't > affect disk usage much. That would probably be ok too. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 6: 0:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 8F03F37B491 for ; Tue, 13 Feb 2001 06:00:12 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 14Sg03-000GTs-0A; Tue, 13 Feb 2001 14:00:11 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.1/8.8.8) with ESMTP id f1DE0As63105; Tue, 13 Feb 2001 14:00:10 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 13 Feb 2001 14:00:10 +0000 (GMT) From: Doug Rabson To: Dag-Erling Smorgrav Cc: Peter Wemm , Jordan Hubbard , Subject: Re: Proposal on shared libs version values. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 13 Feb 2001, Dag-Erling Smorgrav wrote: > Doug Rabson writes: > > I don't understand. If this build was with the version number bumped to > > 501, what is is causing the problem. > > The "broken pipe" problem is a bug in makewhatis, not in libc, and is > totally irrelevant to what is being discussed here. So did the installworld work or not? I'm confused now... If it worked, then I think Peter's stdio patch should be committed. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 7:52:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from vega.dmnshq.net (vega.dmnshq.net [194.19.34.94]) by hub.freebsd.org (Postfix) with ESMTP id 84F6937B491; Tue, 13 Feb 2001 07:52:44 -0800 (PST) Received: (from eivind@localhost) by vega.dmnshq.net (8.11.1/8.9.3) id f1DFpxP76498; Tue, 13 Feb 2001 16:51:59 +0100 (CET) (envelope-from eivind) Date: Tue, 13 Feb 2001 16:51:59 +0100 From: Eivind Eklund To: Terry Lambert Cc: Boris Popov , freebsd-arch@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: vnode interlock API Message-ID: <20010213165159.A76093@thinksec.com> References: <200102072126.OAA24284@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102072126.OAA24284@usr08.primenet.com>; from tlambert@primenet.com on Wed, Feb 07, 2001 at 09:26:00PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 07, 2001 at 09:26:00PM +0000, Terry Lambert wrote: > > So, I suggest to introduce two macro definitions which will hide > > implementation details for interlocks: > > > > #define VI_LOCK(vp) mtx_enter(&(vp)->v_interlock, MTX_DEF) > > #define VI_UNLOCK(vp) mtx_exit(&(vp)->v_interlock, MTX_DEF) > > > > for RELENG_4 they will look like this: > > > > #define VI_LOCK(vp) simple_lock(&(vp)->v_interlock) > > #define VI_UNLOCK(vp) simple_unlock(&(vp)->v_interlock) > > > > Any comments, suggestions ? > > 4) You need to wrap the calls with "{ ... }"; this is because > it may be useful in the future to institute turnstile or > single wakeup semantics, and converting the macro into a > single statement instead of a statement block would mean > a potentially large amount of work would be needed to cope > with the change later, whereas, you seem to plan to already > need to touch all those spots now. This is not an issue. You can get a block that behaves as a single statement by doing do { ... } while (0), and this is the recommended way of writing blocks in macros (so the macros behaves like single statements instead of blocks.) Please do NOT introduce pure statement block wrapped macros. They make for strange semantics, and we are trying to get rid of them. Thanks. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 8:41:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [132.197.97.45]) by hub.freebsd.org (Postfix) with ESMTP id 5B8CD37B491 for ; Tue, 13 Feb 2001 08:41:16 -0800 (PST) Received: (from ak03@localhost) by h132-197-97-45.gte.com (8.11.2/8.11.2) id f1DGfAq01720 for freebsd-arch@FreeBSD.ORG; Tue, 13 Feb 2001 11:41:10 -0500 (EST) (envelope-from ak03) Message-ID: X-Mailer: XFMail 1.4.6-3 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010212175819.A9537@dragon.nuxi.com> Date: Tue, 13 Feb 2001 11:41:07 -0500 (EST) Organization: Verizon Laboratories Inc. From: "Alexander N. Kabaev" To: freebsd-arch@FreeBSD.ORG Subject: RE: Proposal on shared libs version values. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I know this will sound silly, but if numbers in shared libraries file names mean nothing to the loader, why can't we just go back to using lib.so.. naming convention for libc? Jumping between versions (5xx -> 5) just does not seem right. ---------------------------------- E-Mail: Alexander N. Kabaev Date: 13-Feb-2001 Time: 11:37:05 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 8:45:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 16D9E37B491 for ; Tue, 13 Feb 2001 08:45:17 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id RAA96148; Tue, 13 Feb 2001 17:45:11 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Alexander N. Kabaev" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. References: From: Dag-Erling Smorgrav Date: 13 Feb 2001 17:45:11 +0100 In-Reply-To: "Alexander N. Kabaev"'s message of "Tue, 13 Feb 2001 11:41:07 -0500 (EST)" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Alexander N. Kabaev" writes: > I know this will sound silly, but if numbers in shared libraries file names > mean nothing to the loader, why can't we just go back to using > lib.so.. naming convention for libc? Jumping between versions > (5xx -> 5) just does not seem right. Because the loader would ignore the minor number - plus, the semantics we want are not those that minor library version numbers used to have. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 8:56:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2B6B837B6A4 for ; Tue, 13 Feb 2001 08:56:05 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1DGu3h23675; Tue, 13 Feb 2001 09:56:03 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1DGrqE12816; Tue, 13 Feb 2001 09:53:53 -0700 (MST) Message-Id: <200102131653.f1DGrqE12816@billy-club.village.org> To: Doug Rabson Subject: Re: Proposal on shared libs version values. Cc: Dag-Erling Smorgrav , Peter Wemm , Jordan Hubbard , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 13 Feb 2001 14:00:10 GMT." References: Date: Tue, 13 Feb 2001 09:53:52 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Doug Rabson writes: : So did the installworld work or not? I'm confused now... : : If it worked, then I think Peter's stdio patch should be committed. It did and it should. However, there's the issue of 6 vs 500. Hell, peter said it could be "anything". Can it be "5.1"? I know this isn't a "minor" number in the a.out sense, but that would give us room to grow. Of course, I still say there's no reason we can't bump it by more than one each major release cycle. That's, sadly, how ELF libraries work. Keeping the same major for the release is a hold over from the a.out days and is inappropriate for ELF. The X folks learned this in the X11R4 time frame when they stopped trying to make libX11.so.R match the number after the R, except on new platforms. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 8:58:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id EF0CA37B491 for ; Tue, 13 Feb 2001 08:58:50 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1DGwnh23703; Tue, 13 Feb 2001 09:58:50 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1DGukE12832; Tue, 13 Feb 2001 09:56:46 -0700 (MST) Message-Id: <200102131656.f1DGukE12832@billy-club.village.org> To: "Alexander N. Kabaev" Subject: Re: Proposal on shared libs version values. Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 13 Feb 2001 11:41:07 EST." References: Date: Tue, 13 Feb 2001 09:56:45 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Alexander N. Kabaev" writes: : I know this will sound silly, but if numbers in shared libraries file names : mean nothing to the loader, why can't we just go back to using : lib.so.. naming convention for libc? Jumping between versions : (5xx -> 5) just does not seem right. I just got mail telling me that's what OpenBSD does for these things. ELF libraries do not have minor numbers. The major number in this case would be 5.1, but that's OK. It still looks "pretty" enough to ship with 5.0 since 5.0 is going to have a FreeBSD_version number greater than 500000. We're already up to 500013 (or likely higher since the current system I'm typing on is very old). There's no reason we couldn't ship with 5.4 and just leave it at that. Of course there's also no reason, besides OBrien's yell of HACK (which it isn't), of shipping with libc.so.12 either. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 9: 0:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 68BEE37B491 for ; Tue, 13 Feb 2001 09:00:07 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1DH06h23721; Tue, 13 Feb 2001 10:00:06 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1DGw2E12845; Tue, 13 Feb 2001 09:58:02 -0700 (MST) Message-Id: <200102131658.f1DGw2E12845@billy-club.village.org> To: Dag-Erling Smorgrav Subject: Re: Proposal on shared libs version values. Cc: "Alexander N. Kabaev" , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "13 Feb 2001 17:45:11 +0100." References: Date: Tue, 13 Feb 2001 09:58:02 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Dag-Erling Smorgrav writes: : "Alexander N. Kabaev" writes: : > I know this will sound silly, but if numbers in shared libraries file names : > mean nothing to the loader, why can't we just go back to using : > lib.so.. naming convention for libc? Jumping between versions : > (5xx -> 5) just does not seem right. : : Because the loader would ignore the minor number - plus, the semantics : we want are not those that minor library version numbers used to have. The loader doesn't ignore the minor number. The symbolic link makes the library default, so it would "use" it. You are right that it wouldn't have a.out shared library minor number semantics. It is just a tag. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 9: 4:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1B1FF37B503 for ; Tue, 13 Feb 2001 09:04:27 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA96254; Tue, 13 Feb 2001 18:04:22 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Warner Losh Cc: "Alexander N. Kabaev" , freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. References: <200102131658.f1DGw2E12845@billy-club.village.org> From: Dag-Erling Smorgrav Date: 13 Feb 2001 18:04:21 +0100 In-Reply-To: Warner Losh's message of "Tue, 13 Feb 2001 09:58:02 -0700" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > The loader doesn't ignore the minor number. The symbolic link makes > the library default, so it would "use" it. You are right that it > wouldn't have a.out shared library minor number semantics. It is just > a tag. Hmm? I must have seriously misunderstood all the discussions that went on around E-day. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 9:10:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [132.197.97.45]) by hub.freebsd.org (Postfix) with ESMTP id 1501B37B4EC for ; Tue, 13 Feb 2001 09:10:39 -0800 (PST) Received: (from ak03@localhost) by h132-197-97-45.gte.com (8.11.2/8.11.2) id f1DHAOV01969; Tue, 13 Feb 2001 12:10:24 -0500 (EST) (envelope-from ak03) Message-ID: X-Mailer: XFMail 1.4.6-3 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 13 Feb 2001 12:10:23 -0500 (EST) Organization: Verizon Laboratories Inc. From: "Alexander N. Kabaev" To: Dag-Erling Smorgrav Subject: Re: Proposal on shared libs version values. Cc: freebsd-arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Minor/major numbers in library file name mean nothing to the loader, so there is no prioblem with that. I am not proposing to restore the old minor number semantics. Rather, I am proposing to add '.' to the 5xx versioning scheme as an eye candy and ship libraries with these numbers in without doing counter-intuitive version numbers reversals. Just imagine how often these poor folks who bother to answer to postings on -questions from time to time will have to explain why 5 is >= than 5xx otherwise :) On 13-Feb-2001 Dag-Erling Smorgrav wrote: > "Alexander N. Kabaev" writes: >> I know this will sound silly, but if numbers in shared libraries file names >> mean nothing to the loader, why can't we just go back to using >> lib.so.. naming convention for libc? Jumping between versions >> (5xx -> 5) just does not seem right. > > Because the loader would ignore the minor number - plus, the semantics > we want are not those that minor library version numbers used to have. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org ---------------------------------- E-Mail: Alexander N. Kabaev Date: 13-Feb-2001 Time: 11:58:15 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 9:17:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id BBBE037B491 for ; Tue, 13 Feb 2001 09:17:29 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1DHHNW39519; Tue, 13 Feb 2001 10:17:23 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102131717.f1DHHNW39519@harmony.village.org> To: Dag-Erling Smorgrav Subject: Re: Proposal on shared libs version values. Cc: "Alexander N. Kabaev" , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "13 Feb 2001 18:04:21 +0100." References: <200102131658.f1DGw2E12845@billy-club.village.org> Date: Tue, 13 Feb 2001 10:17:23 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Dag-Erling Smorgrav writes: : Hmm? I must have seriously misunderstood all the discussions that went : on around E-day. What I had thought happened was that ld just uses the symbolic link blindly. However, I just tried it on my system: cd /usr/lib cp libc.so.4 libc.so.4.1 ln -sf libc.so.4.1 libc.so ldconfig -R ldconfig -r | grep libc.so.4 33:-lc.4 => /usr/lib/libc.so.4 So it does look like it has to be a single number. Forget what I said about 5.1 being a viable option. My OpenBSD box does have minor numbers appended, but they also have hacks in their ld to cope. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 10:24:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from titanic.medinet.si (titanic.medinet.si [212.18.32.66]) by hub.freebsd.org (Postfix) with ESMTP id 0BA6C37B4EC for ; Tue, 13 Feb 2001 10:24:22 -0800 (PST) Received: by titanic.medinet.si (Postfix, from userid 1000) id A95FB26C06; Tue, 13 Feb 2001 19:24:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by titanic.medinet.si (Postfix) with ESMTP id 993101170B; Tue, 13 Feb 2001 19:24:19 +0100 (CET) Date: Tue, 13 Feb 2001 19:24:19 +0100 (CET) From: Blaz Zupan To: Dag-Erling Smorgrav Cc: Doug Rabson , Peter Wemm , Jordan Hubbard , Subject: Re: Proposal on shared libs version values. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The "broken pipe" problem is a bug in makewhatis, not in libc, and is > totally irrelevant to what is being discussed here. The "broken pipe" problem is a bug in OpenSSH 2.3.0 sshd. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: blaz@amis.net, Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 10:41: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id F179E37B4EC for ; Tue, 13 Feb 2001 10:41:03 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1DIemH83700; Tue, 13 Feb 2001 10:40:48 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Peter Wemm Cc: Dag-Erling Smorgrav , freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. In-Reply-To: Message from Peter Wemm of "Mon, 12 Feb 2001 22:47:33 PST." <200102130647.f1D6lXU59162@mobile.wemm.org> Date: Tue, 13 Feb 2001 10:40:48 -0800 Message-ID: <83696.982089648@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A post-perl-fix buildworld finished while I drove home. An installworld is > in progress.. And that will work fine, but any ports/packages which include things like libreadline will cease to function thereafter. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 11:42:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 3431C37B4EC for ; Tue, 13 Feb 2001 11:42:09 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1DJffU66659; Tue, 13 Feb 2001 11:41:41 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102131941.f1DJffU66659@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Warner Losh Cc: Dag-Erling Smorgrav , "Alexander N. Kabaev" , freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. In-Reply-To: <200102131717.f1DHHNW39519@harmony.village.org> Date: Tue, 13 Feb 2001 11:41:41 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message Dag-Erling Smorgrav writes: > : Hmm? I must have seriously misunderstood all the discussions that went > : on around E-day. > > What I had thought happened was that ld just uses the symbolic link > blindly. However, I just tried it on my system: > > cd /usr/lib > cp libc.so.4 libc.so.4.1 > ln -sf libc.so.4.1 libc.so > ldconfig -R > ldconfig -r | grep libc.so.4 > 33:-lc.4 => /usr/lib/libc.so.4 > > So it does look like it has to be a single number. Forget what I said > about 5.1 being a viable option. ldconfig -r is fake anyway. ld(1) does not use it. ldconfig -r exists only for the benefit of 3rd party scripts. > My OpenBSD box does have minor numbers appended, but they also have > hacks in their ld to cope. In order to inject facts into the discussion, consider: peter@mobile[11:22am]~src-161> objdump --all-headers /usr/lib/libc.so.5 ... Dynamic Section: SONAME libc.so.5 ... peter@mobile[11:22am]~src-162> ls -l /usr/lib/libc.so lrwxr-xr-x 1 root wheel 9 Dec 22 15:35 /usr/lib/libc.so@ -> libc.so.5 The way it works is this: - ld opens libc.so (via the symlink, it can be a hard link or copy even) - it sees the embedded DT_SONAME in the object. - the DT_SONAME is what gets copied to the DT_NEEDED of the program being linked. You had better hope they are the same file. :-) - at runtime, ld-elf.so.1 searches for "libc.so.5" by name because that is what was copied. If DT_SONAME had "libc.so.5.1", then that is what ld would copy to the application and ld-elf.so.1 will look for "libc.so.5.1". ldconfig has *nothing* to do with it except provide a list of directories for ld-elf.so.1 to look in, besides the hard coded /usr/lib. peter@mobile[11:27am]~src-166> strings /var/run/ld-elf.so.hints Ehnt /usr/lib:/usr/lib/compat:/usr/X11R6/lib:/usr/local/lib (that's "Elf Hint") Note there are no pathnames, version numbers, anything. ldconfig -r is simply doing a readdir() of /usr/lib and generating a fake a.out lookalike output. It can be easily fixed to deal with libc.so.5.1 if that is desirable. When libc is built, we could link it with "-h libc.so.5-13-Feb-2001" and that is what all applications will depend on (so it had better exist). At link time, all ld looks at is what is embedded in whatever it opens by opening "libc.so" and records the dependency embedded in there. Nothing would check if "libc.so.5-13-Feb-2001" actually existed until you tried to run the application that depended on it. This is not directed at anybody in particular, just an attempt to get some concrete facts and common understanding into the discussion. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 13: 9:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 4FDF737B491 for ; Tue, 13 Feb 2001 13:09:39 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1DL9QB79836; Tue, 13 Feb 2001 13:09:26 -0800 (PST) (envelope-from obrien) Date: Tue, 13 Feb 2001 13:09:26 -0800 From: "David O'Brien" To: Peter Wemm Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. Message-ID: <20010213130926.A79651@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <200102131717.f1DHHNW39519@harmony.village.org> <200102131941.f1DJffU66659@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102131941.f1DJffU66659@mobile.wemm.org>; from peter@netplex.com.au on Tue, Feb 13, 2001 at 11:41:41AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 13, 2001 at 11:41:41AM -0800, Peter Wemm wrote: > When libc is built, we could link it with "-h libc.so.5-13-Feb-2001" Actually I think I like libc.so.5. to stand for a development version of libc.so.5 better than the libc.so.500 scheme. libc.so.5. gives a better matching of what the shared version number would be when released. It also makes it very clear when the incompatible change happened. (encoding of date left unspecified) Opinions? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 13:14:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id CEF8137B4EC for ; Tue, 13 Feb 2001 13:14:29 -0800 (PST) Received: from newsguy.com (p02-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.131]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id GAA02350; Wed, 14 Feb 2001 06:14:27 +0900 (JST) Message-ID: <3A89A313.4E5B6865@newsguy.com> Date: Wed, 14 Feb 2001 06:11:47 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: freebsd-arch@FreeBSD.ORG Cc: Peter Wemm Subject: Re: Proposal on shared libs version values. References: <200102131717.f1DHHNW39519@harmony.village.org> <200102131941.f1DJffU66659@mobile.wemm.org> <20010213130926.A79651@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Tue, Feb 13, 2001 at 11:41:41AM -0800, Peter Wemm wrote: > > When libc is built, we could link it with "-h libc.so.5-13-Feb-2001" > > Actually I think I like libc.so.5. to stand for a development > version of libc.so.5 better than the libc.so.500 scheme. > libc.so.5. gives a better matching of what the shared version > number would be when released. It also makes it very clear when the > incompatible change happened. (encoding of date left unspecified) > > Opinions? Keep the date in ISO format (yyyy-mm-dd), otherwise 5-14-Feb-2001 would get priority over 5-13-Mar-20001. (Unless I skipped this discussion too much, but the point still kind of stands.) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "That's evil, Sir," Layson said admiringly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 17:40:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 52BAB37B491 for ; Tue, 13 Feb 2001 17:40:29 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1E1eJh25767; Tue, 13 Feb 2001 18:40:20 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1E1c9E14268; Tue, 13 Feb 2001 18:38:16 -0700 (MST) Message-Id: <200102140138.f1E1c9E14268@billy-club.village.org> To: "Daniel C. Sobral" Subject: Re: Proposal on shared libs version values. Cc: freebsd-arch@FreeBSD.ORG, Peter Wemm In-reply-to: Your message of "Wed, 14 Feb 2001 06:11:47 +0900." <3A89A313.4E5B6865@newsguy.com> References: <3A89A313.4E5B6865@newsguy.com> <200102131717.f1DHHNW39519@harmony.village.org> <200102131941.f1DJffU66659@mobile.wemm.org> <20010213130926.A79651@dragon.nuxi.com> Date: Tue, 13 Feb 2001 18:38:09 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I like this idea better than 501 and 5.1 formats. If we have to have libc.so.5 for the release, then this gives us name space that we can use (libc.so.5.1 could be used if we *HAD* to bump the major version in the RELENG_5 branch). libc.so.5.1 looks a lot different than libc.so.5.20013013, for example. Of course, I'd really rather not see 5.1 in a release if we can avoid it, but using the date as David suggests gives us this option if we need to use it. In message <3A89A313.4E5B6865@newsguy.com> "Daniel C. Sobral" writes: : Keep the date in ISO format (yyyy-mm-dd), otherwise 5-14-Feb-2001 would : get priority over 5-13-Mar-20001. (Unless I skipped this discussion too : much, but the point still kind of stands.) I'd use YYYYMMDD. Short, simple to the point, no locales to worry about. We use it other places in the tree (UPDATING) as well as it being a subset of the widespread YYYYMMDDCC format for named serial numbers so it is well understood by many of the folks that might be running current. It also has the "nice" properties of being monitonically increasing and easy to parse. However, like Peter pointed out earlier today, it just doesn't matter at all what the date we use is. It only matters to humans reading ls listings :-). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 18:41:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B6CBA37B503; Tue, 13 Feb 2001 18:41:29 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id SAA10935; Tue, 13 Feb 2001 18:41:29 -0800 Date: Tue, 13 Feb 2001 18:41:29 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: now that DEVFS is standard.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ....Can we now have wildcarded major numbers for creating devices? I mean, now that we have the name just appear each time you boot, the actual major number is not all that relevant now, is it? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 18:42:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1234637B503 for ; Tue, 13 Feb 2001 18:42:11 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id NAA05280; Wed, 14 Feb 2001 13:41:56 +1100 Date: Wed, 14 Feb 2001 13:41:30 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dag-Erling Smorgrav Cc: Doug Rabson , arch@FreeBSD.ORG Subject: Re: sparse core dumps In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 13 Feb 2001, Dag-Erling Smorgrav wrote: > Doug Rabson writes: > > Probably it should just use getpagesize() to decide what block size to > > use. > > Why not just hardcode PAGE_SIZE like I did? An incorrect value will > still work, just slightly less efficiently. Empirical tests show that > as long as you stick to reasonable values, the block size doesn't > affect disk usage much. One reason is that it is a bug for PAGE_SIZE to be visible to applications. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 20:18: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id C1B3237B491 for ; Tue, 13 Feb 2001 20:18:04 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id PAA24140; Wed, 14 Feb 2001 15:17:55 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01K03SFHER1CO2JDJ3@cim.alcatel.com.au>; Wed, 14 Feb 2001 15:17:45 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f1E4HmU73629; Wed, 14 Feb 2001 15:17:48 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Wed, 14 Feb 2001 15:17:48 +1100 From: Peter Jeremy Subject: Re: Proposal on shared libs version values. In-reply-to: <20010213130926.A79651@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Tue, Feb 13, 2001 at 01:09:26PM -0800 To: freebsd-arch@FreeBSD.ORG Cc: Peter Wemm Mail-followup-to: freebsd-arch@FreeBSD.ORG, Peter Wemm Message-id: <20010214151748.Q90937@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200102131717.f1DHHNW39519@harmony.village.org> <200102131941.f1DJffU66659@mobile.wemm.org> <20010213130926.A79651@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Firstly, I also like the idea of a `development' shared library version that can change as necessary before -CURRENT forks at each major release. On 2001-Feb-13 13:09:26 -0800, David O'Brien wrote: >On Tue, Feb 13, 2001 at 11:41:41AM -0800, Peter Wemm wrote: >> When libc is built, we could link it with "-h libc.so.5-13-Feb-2001" > >Actually I think I like libc.so.5. to stand for a development >version of libc.so.5 better than the libc.so.500 scheme. It's not clear to me whether you are proposing that be the date of the buildworld, or the date of the last library API change. In the former case, you wind up bloating /usr/lib much faster[1] and the values don't mean anything to anyone else (since it depends what timezone you are in and when you ran buildworld). Neither case handles the situation where multiple API changes occur in a day - which might be rare but isn't entirely impossible. Given access to CVS, you can easily translate a version number to the date on which the change occurred in any case. [1] The only way I know of to verify that it's safe to delete an old shared library is to run ldd on all dynamic executables. (Maybe within a date range). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 20:44:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id E288937B491 for ; Tue, 13 Feb 2001 20:44:21 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1E4iLU70786 for ; Tue, 13 Feb 2001 20:44:21 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102140444.f1E4iLU70786@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. In-Reply-To: <20010214151748.Q90937@gsmx07.alcatel.com.au> Date: Tue, 13 Feb 2001 20:44:21 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Jeremy wrote: > Firstly, I also like the idea of a `development' shared library version > that can change as necessary before -CURRENT forks at each major release. > > On 2001-Feb-13 13:09:26 -0800, David O'Brien wrote: > >On Tue, Feb 13, 2001 at 11:41:41AM -0800, Peter Wemm wrote: > >> When libc is built, we could link it with "-h libc.so.5-13-Feb-2001" > > > >Actually I think I like libc.so.5. to stand for a development > >version of libc.so.5 better than the libc.so.500 scheme. > > It's not clear to me whether you are proposing that be the > date of the buildworld, or the date of the last library API change. > > In the former case, you wind up bloating /usr/lib much faster[1] and > the values don't mean anything to anyone else (since it depends > what timezone you are in and when you ran buildworld). Neither > case handles the situation where multiple API changes occur in a day - > which might be rare but isn't entirely impossible. No way will we do the former. And if we have to do something that has two bumps in the same day, we're doing something badly wrong. The idea is NOT to make it a free-for-all bumping frenzy (remember poor bento has to deal with a bump!), but bump only when we cannot avoid it without causing an anreasonable amount of developer pain. Minor things can be easily worked around, but big stuff (like a buildworld will hose your machine) needs a bump. When we have to bump, use the current YYYYMMDD date. As Doug Rabson so elegantly put it: The last thing we need is for people to waste valuable development time working around version number problems. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 21:55: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 78FF437B65D for ; Tue, 13 Feb 2001 21:54:58 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1E5suw55331; Wed, 14 Feb 2001 06:54:56 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: arch@freebsd.org Subject: Re: now that DEVFS is standard.... In-Reply-To: Your message of "Tue, 13 Feb 2001 18:41:29 PST." Date: Wed, 14 Feb 2001 06:54:56 +0100 Message-ID: <55329.982130096@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Matthew Jacob writes: > >....Can we now have wildcarded major numbers for creating devices? > >I mean, now that we have the name just appear each time you boot, the actual >major number is not all that relevant now, is it? Weeeeeeell, devfs is default, but not mandatory so we still support running !devfs systems, and unfortunately I suspect we will do so for some time still. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 22: 2:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 74C4D37B4EC for ; Tue, 13 Feb 2001 22:02:46 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id WAA11532; Tue, 13 Feb 2001 22:02:37 -0800 Date: Tue, 13 Feb 2001 22:02:36 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: now that DEVFS is standard.... In-Reply-To: <55329.982130096@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message , Matthew > Jacob writes: > > > >....Can we now have wildcarded major numbers for creating devices? > > > >I mean, now that we have the name just appear each time you boot, the actual > >major number is not all that relevant now, is it? > > Weeeeeeell, devfs is default, but not mandatory so we still support > running !devfs systems, and unfortunately I suspect we will do so > for some time still. How about us having a 'range' of numbers, so we can do things like: static struct cdevsw sa_cdevsw = { /* open */ saopen, /* close */ saclose, /* read */ physread, /* write */ physwrite, /* ioctl */ saioctl, /* poll */ nopoll, /* mmap */ nommap, /* strategy */ sastrategy, /* name */ "sa", /* maj */ SA_CDEV_ANY, /* dump */ nodump, /* psize */ nopsize, /* flags */ D_TAPE, /* bmaj */ -1 }; or static struct cdevsw sa_cdevsw = { /* open */ saopen, /* close */ saclose, /* read */ physread, /* write */ physwrite, /* ioctl */ saioctl, /* poll */ nopoll, /* mmap */ nommap, /* strategy */ sastrategy, /* name */ "sa", /* maj */ SA_CDEV_MAJOR|SA_CDEV_ANY, /* dump */ nodump, /* psize */ nopsize, /* flags */ D_TAPE, /* bmaj */ -1 }; (make_dev gets SA_CDEV_MAJOR if !devfs, else any old number will do....) We went round and round and round with this at Sun. We ended up with the persistent file /etc/name_to_major which then binds a driver to a particular major. I've *never* liked it- so prone to porking. However, I like distributed, hemi-demi-asssigned, majors even less. Just some thoughts. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 22: 9:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id C194D37B491 for ; Tue, 13 Feb 2001 22:09:15 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1E69Dw55521; Wed, 14 Feb 2001 07:09:13 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: arch@freebsd.org Subject: Re: now that DEVFS is standard.... In-Reply-To: Your message of "Tue, 13 Feb 2001 22:02:36 PST." Date: Wed, 14 Feb 2001 07:09:13 +0100 Message-ID: <55519.982130953@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Matthew Jacob writes: > >> In message , Matthew >> Jacob writes: >> > >> >....Can we now have wildcarded major numbers for creating devices? >> > >> >I mean, now that we have the name just appear each time you boot, the actual >> >major number is not all that relevant now, is it? >> >> Weeeeeeell, devfs is default, but not mandatory so we still support >> running !devfs systems, and unfortunately I suspect we will do so >> for some time still. > >How about us having a 'range' of numbers, so we can do things like: I plan to implement support for dynamic assignment in the devfs case, so that it doesn't matter what major the driver ask for, but a driver which doesn't ask for something sensible will fail to operate on a !devfs system... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 22:24:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C2F2737B491 for ; Tue, 13 Feb 2001 22:24:31 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id WAA11611; Tue, 13 Feb 2001 22:24:23 -0800 Date: Tue, 13 Feb 2001 22:24:22 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: now that DEVFS is standard.... In-Reply-To: <55519.982130953@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I plan to implement support for dynamic assignment in the devfs > case, so that it doesn't matter what major the driver ask for, but > a driver which doesn't ask for something sensible will fail to > operate on a !devfs system... Okay. Fair enough. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 13 23:39:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id DA0EE37B491; Tue, 13 Feb 2001 23:39:15 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id AAA27779; Wed, 14 Feb 2001 00:36:12 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAAn1a4m2; Wed Feb 14 00:36:04 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id AAA20903; Wed, 14 Feb 2001 00:38:54 -0700 (MST) From: Terry Lambert Message-Id: <200102140738.AAA20903@usr08.primenet.com> Subject: Re: vnode interlock API To: eivind@FreeBSD.ORG (Eivind Eklund) Date: Wed, 14 Feb 2001 07:38:23 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), bp@butya.kz (Boris Popov), freebsd-arch@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG In-Reply-To: <20010213165159.A76093@thinksec.com> from "Eivind Eklund" at Feb 13, 2001 04:51:59 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is not an issue. You can get a block that behaves as a single statement > by doing do { ... } while (0), and this is the recommended way of writing > blocks in macros (so the macros behaves like single statements instead of > blocks.) > > Please do NOT introduce pure statement block wrapped macros. They make for > strange semantics, and we are trying to get rid of them. The point was to block them; I personally prefer the "{ ... } while(0)" semantics, but the important thing is to allow the use of multiple statements, of course, so your correction is welcome, but it's the ability to add statements later that's important here. This wasn't being done. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 14 3:45:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B869537B4EC for ; Wed, 14 Feb 2001 03:45:43 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA99775; Wed, 14 Feb 2001 12:45:31 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Peter Wemm Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. References: <200102140444.f1E4iLU70786@mobile.wemm.org> From: Dag-Erling Smorgrav Date: 14 Feb 2001 12:45:30 +0100 In-Reply-To: Peter Wemm's message of "Tue, 13 Feb 2001 20:44:21 -0800" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm writes: > As Doug Rabson so elegantly put it: The last thing we need is for people > to waste valuable development time working around version number problems. Right, so why are we getting bogged down in this bikeshed? I want the next libc version to be numbered 5.pink, btw. Somebody please just take the patch (~des/software/stdio-20010213.diff), replace 501 with their favorite numbering scheme, and commit it. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 14 3:47: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A305E37B401 for ; Wed, 14 Feb 2001 03:46:58 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA99788; Wed, 14 Feb 2001 12:46:53 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bruce Evans Cc: Doug Rabson , arch@FreeBSD.ORG Subject: Re: sparse core dumps References: From: Dag-Erling Smorgrav Date: 14 Feb 2001 12:46:52 +0100 In-Reply-To: Bruce Evans's message of "Wed, 14 Feb 2001 13:41:30 +1100 (EST)" Message-ID: Lines: 8 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans writes: > One reason is that it is a bug for PAGE_SIZE to be visible to applications. Fair enough. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 14 13:23:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 18BAB37B503 for ; Wed, 14 Feb 2001 13:23:56 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1ELNOW91541; Wed, 14 Feb 2001 14:23:35 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102142123.f1ELNOW91541@harmony.village.org> To: Dag-Erling Smorgrav Subject: Re: Proposal on shared libs version values. Cc: Peter Wemm , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "14 Feb 2001 12:45:30 +0100." References: <200102140444.f1E4iLU70786@mobile.wemm.org> Date: Wed, 14 Feb 2001 14:23:24 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Dag-Erling Smorgrav writes: : Peter Wemm writes: : > As Doug Rabson so elegantly put it: The last thing we need is for people : > to waste valuable development time working around version number problems. : : Right, so why are we getting bogged down in this bikeshed? I want the : next libc version to be numbered 5.pink, btw. Somebody please just : take the patch (~des/software/stdio-20010213.diff), replace 501 with : their favorite numbering scheme, and commit it. The committed changes have problems. See my note in -current for details. Basically, we have to bump *ALL* shared libriares in -current that use std{err,out,in}. The version number has nothing to do with this :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 14 16:19:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id B057137B4EC for ; Wed, 14 Feb 2001 16:19:29 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id RAA29578; Wed, 14 Feb 2001 17:14:32 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAqpaaB5; Wed Feb 14 17:14:12 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA09453; Wed, 14 Feb 2001 17:18:58 -0700 (MST) From: Terry Lambert Message-Id: <200102150018.RAA09453@usr08.primenet.com> Subject: Re: sparse core dumps To: des@ofug.org (Dag-Erling Smorgrav) Date: Thu, 15 Feb 2001 00:18:53 +0000 (GMT) Cc: bde@zeta.org.au (Bruce Evans), dfr@nlsystems.com (Doug Rabson), arch@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Feb 14, 2001 12:46:52 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > One reason is that it is a bug for PAGE_SIZE to be visible to applications. > > Fair enough. That's like saying that it's a bug for alignment boundaries to be visible to the application (which they are, on architectures where unaligned accesses result in faults, either because of the fault causing a failure, or because of the fault being detectable through profiling aligned vs. unaligned access, and therefore detecting the fixup). Having the page size is useful information, so that cross-platform or cross architecture (on a single platform) applications can make good decisions. For example, a naieve program would buffer at the preferred block size on an audio CDROM, whereas a smart program will realize that the data will be loaded into page buffers, in order to ensure against having to reread data already loaded into cache, and to minimize the number of real faults, which might break up audio playback (same for DVDs). Similarly, databases and other mmap-using code have need of the information, for optimization purposes. You really can't hide the page size, and more than you can hide alignment boundaries, or any of a dozen other hardware artifacts that affect performance, if handled suboptimally (register windows and their effect on call stack depth and stack frame pushing vs. signal and longjmp behaviour, register window flushing as a result of user space threads context switches, etc., etc.). Now if you wanted to change that to say "./..it is a bug for applications to externalize behaviour that makes page size visible", then you _might_ have an argument (one could still argue about optimim pipe data blocking, between peers). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 14 18:10:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 8D35437B401 for ; Wed, 14 Feb 2001 18:10:46 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id NAA29149; Thu, 15 Feb 2001 13:10:42 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01K052A0OWSWI8TCQV@cim.alcatel.com.au>; Thu, 15 Feb 2001 13:10:28 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f1F2AaV71832; Thu, 15 Feb 2001 13:10:36 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Thu, 15 Feb 2001 13:10:36 +1100 From: Peter Jeremy Subject: Re: sparse core dumps In-reply-to: <200102150018.RAA09453@usr08.primenet.com>; from tlambert@primenet.com on Thu, Feb 15, 2001 at 12:18:53AM +0000 To: Terry Lambert Cc: arch@FreeBSD.ORG Mail-followup-to: Terry Lambert , arch@FreeBSD.ORG Message-id: <20010215131036.W90937@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200102150018.RAA09453@usr08.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2001-Feb-15 00:18:53 +0000, Terry Lambert wrote: >> > One reason is that it is a bug for PAGE_SIZE to be visible to applications. >> >> Fair enough. > >That's like saying that it's a bug for alignment boundaries to be >visible to the application (which they are, on architectures where >unaligned accesses result in faults, either because of the fault >causing a failure, or because of the fault being detectable through >profiling aligned vs. unaligned access, and therefore detecting the >fixup). I think the intention was that a userland reference to the macro PAGE_SIZE (hard-coded to 4096, 8192 or some other value) is a bug. Applications should be using getpagesize(3) instead. (And of course, neither approach covers the situation where different parts of the address space effectively have different page sizes). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 1: 3:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2EECB37B491 for ; Thu, 15 Feb 2001 01:03:54 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1F93rW62243 for ; Thu, 15 Feb 2001 02:03:54 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102150903.f1F93rW62243@harmony.village.org> To: arch@freebsd.org Subject: The whole libc thing. Date: Thu, 15 Feb 2001 02:03:53 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK. Pere's bumping of libc won't work. We'd have to bump all shared libraries that use stdio, which is too many. Even in the ports system. The issue, for those following along at home. libc.so.5 defined std{in,out,err} in terms of absolte offsets into the __sF array. This is bad if we ever want to change the size of __sF. libc.so.5.20010213 introduced __std{in,out,err} to deal with this. These would be referenced rather than the __sF array. Now here's where the problem comes in. If I rebuild the world, certain libraries, like libcam.so.2, change from referencing __sF to referencing __stderr and the like. This is fine for new binaries, but introduces a problem for old binaries. Consider cdrecord built before the change, say on 4.2R. It will reference libc.so.4 (which has the __sF symbols, but not the __stderr ones) and libcam.so.2. After the above buildworld, running cdrecord will break with __stderr undefined. why? Well, that's involved. cdrecord runs and ld.so brings in libcam.so.2 and libc.so.4. Since libcam.so.2 references __stderr and libc.so.4 doesn't have it, we get the error. The only solution is to bump the major number of libcam.so.3 so that old applications continue to work. However, that's the rub. *ALL* libraries that reference std{in,out,err} would need their major numbers bumped. So what solutions do we have? Green's solution of stealing a pointer and using that to "grow" FILE. This would allow old binaris to keep working at the cost of binary compatibility. There's a few extra indirections in this case, you'll likely not be able to measure that performance loss. But it will work with the case above and most of the others we threw at it. Mike Smith has another solution that I'll let him explain because I don't understand it. It might work, but it might not. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 1:32:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 9DED737B401 for ; Thu, 15 Feb 2001 01:32:14 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1F9W0d68953; Thu, 15 Feb 2001 01:32:00 -0800 (PST) (envelope-from obrien) Date: Thu, 15 Feb 2001 01:32:00 -0800 From: "David O'Brien" To: Peter Jeremy Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. Message-ID: <20010215013159.B66813@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <200102131717.f1DHHNW39519@harmony.village.org> <200102131941.f1DJffU66659@mobile.wemm.org> <20010213130926.A79651@dragon.nuxi.com> <20010214151748.Q90937@gsmx07.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010214151748.Q90937@gsmx07.alcatel.com.au>; from peter.jeremy@alcatel.com.au on Wed, Feb 14, 2001 at 03:17:48PM +1100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 14, 2001 at 03:17:48PM +1100, Peter Jeremy wrote: > It's not clear to me whether you are proposing that be the > date of the buildworld, or the date of the last library API change. The date the incompatable ABI change was committed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 1:34:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 9FB1737B401 for ; Thu, 15 Feb 2001 01:34:20 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1F9YF669009; Thu, 15 Feb 2001 01:34:15 -0800 (PST) (envelope-from obrien) Date: Thu, 15 Feb 2001 01:34:14 -0800 From: "David O'Brien" To: Dag-Erling Smorgrav Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. Message-ID: <20010215013414.C66813@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <200102140444.f1E4iLU70786@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Wed, Feb 14, 2001 at 12:45:30PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 14, 2001 at 12:45:30PM +0100, Dag-Erling Smorgrav wrote: > Right, so why are we getting bogged down in this bikeshed? Why is it a bike shed? Are we to the point that *every* discussion is a "bike shed" these days? An idea came up, some of us liked it, and said so. Are we really to the point we cannot have a discussion anymore? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 2:39:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 184B537B401 for ; Thu, 15 Feb 2001 02:39:21 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA30563; Thu, 15 Feb 2001 21:39:13 +1100 Date: Thu, 15 Feb 2001 21:38:45 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: The whole libc thing. In-Reply-To: <200102150903.f1F93rW62243@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001, Warner Losh wrote: > Green's solution of stealing a pointer and using that to "grow" FILE. > This would allow old binaris to keep working at the cost of binary > compatibility. There's a few extra indirections in this case, you'll > likely not be able to measure that performance loss. But it will work > with the case above and most of the others we threw at it. Pointers to FILEs can be converted to pointers extensions of FILEs using a hash lookup. This takes slightly more than a few indirections, but it doesn't cost binary compatibilty. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 3: 8:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 65E0537B491 for ; Thu, 15 Feb 2001 03:08:15 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA04457; Thu, 15 Feb 2001 12:08:14 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. References: <200102140444.f1E4iLU70786@mobile.wemm.org> <20010215013414.C66813@dragon.nuxi.com> From: Dag-Erling Smorgrav Date: 15 Feb 2001 12:08:13 +0100 In-Reply-To: "David O'Brien"'s message of "Thu, 15 Feb 2001 01:34:14 -0800" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" writes: > On Wed, Feb 14, 2001 at 12:45:30PM +0100, Dag-Erling Smorgrav wrote: > > Right, so why are we getting bogged down in this bikeshed? > Why is it a bike shed? Because we're spending way more time discussing what version number to pick than discussing the pros and cons of the bump itself. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 6:17:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id AD2A837B491 for ; Thu, 15 Feb 2001 06:17:19 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id JAA02146; Thu, 15 Feb 2001 09:16:48 -0500 (EST) Date: Thu, 15 Feb 2001 09:16:47 -0500 (EST) From: Daniel Eischen To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: The whole libc thing. In-Reply-To: <200102150903.f1F93rW62243@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001, Warner Losh wrote: > > OK. Pere's bumping of libc won't work. We'd have to bump all shared > libraries that use stdio, which is too many. Even in the ports > system. > > The issue, for those following along at home. > > libc.so.5 defined std{in,out,err} in terms of absolte offsets into > the __sF array. This is bad if we ever want to change the size of > __sF. > > libc.so.5.20010213 introduced __std{in,out,err} to deal with this. > These would be referenced rather than the __sF array. > > Now here's where the problem comes in. > > If I rebuild the world, certain libraries, like libcam.so.2, change > from referencing __sF to referencing __stderr and the like. This is > fine for new binaries, but introduces a problem for old binaries. > > Consider cdrecord built before the change, say on 4.2R. It will > reference libc.so.4 (which has the __sF symbols, but not the __stderr > ones) and libcam.so.2. After the above buildworld, running cdrecord > will break with __stderr undefined. why? Well, that's involved. > > cdrecord runs and ld.so brings in libcam.so.2 and libc.so.4. Since > libcam.so.2 references __stderr and libc.so.4 doesn't have it, we get > the error. > > The only solution is to bump the major number of libcam.so.3 so that > old applications continue to work. > > However, that's the rub. *ALL* libraries that reference > std{in,out,err} would need their major numbers bumped. Let's just bump the libraries and be done with it. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 6:22:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 344A637B4EC for ; Thu, 15 Feb 2001 06:22:32 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id JAA02923; Thu, 15 Feb 2001 09:22:02 -0500 (EST) Date: Thu, 15 Feb 2001 09:22:01 -0500 (EST) From: Daniel Eischen To: Bruce Evans Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: The whole libc thing. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001, Bruce Evans wrote: > On Thu, 15 Feb 2001, Warner Losh wrote: > > > Green's solution of stealing a pointer and using that to "grow" FILE. > > This would allow old binaris to keep working at the cost of binary > > compatibility. There's a few extra indirections in this case, you'll > > likely not be able to measure that performance loss. But it will work > > with the case above and most of the others we threw at it. > > Pointers to FILEs can be converted to pointers extensions of FILEs using > a hash lookup. This takes slightly more than a few indirections, but > it doesn't cost binary compatibilty. And introduces another place where locks would be needed. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 7:15:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 1B5BA37B491; Thu, 15 Feb 2001 07:15:26 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f1FFFJg28572; Thu, 15 Feb 2001 17:15:19 +0200 (EET) (envelope-from ru) Date: Thu, 15 Feb 2001 17:15:19 +0200 From: Ruslan Ermilov To: arch@FreeBSD.org Cc: Andrey Chernov , Dag-Erling Smorgrav Subject: Proposed change for ISO_8859-1 catpages Message-ID: <20010215171519.A24192@sunbay.com> Mail-Followup-To: arch@FreeBSD.org, Andrey Chernov , Dag-Erling Smorgrav Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! The attached patch will create /usr/share/man/en.ISO_8859-1 tree. man* subdirectories here will just be symlinks to the corresponding directories in /usr/share/man. cat* are true subdirectories. This adds nice ability to display and store /usr/share/man manpages in the correct eight-bit Latin-1 charset for all ISO_8859-1 locales, as opposed to the 7-bit ASCII output produced now. Let me illustrate this by example. Suppose, your locale is de_DE.ISO_8859-1, and you are looking for a cat(1) manpage. man(1) will first look for a localized cat(1) manpage in the following locale directories, in that order: /usr/share/man/de_DE.ISO_8859-1/man1 /usr/share/man/de.ISO_8859-1/man1 If a match is found in the de_DE.ISO_8859-1/man1 directory (Germany), that page will be passed to groff(1) with -Tlatin1 device, which will produce the correct Latin-1 output in German. The output (catpage) will then be stored by man(1) on disk in the de_DE.ISO_8859-1/cat1 directory, and displayed to a requesting user. If the match is not found, man(1) will look for a localized cat(1) manpage in the de.ISO_8859-1/man1 directory (which matches all de_*.ISO_8859-1 locales). If the match is found here, groff(1) will produce Latin-1 output, and man(1) will store the catpage in the de.ISO_8859-1/cat1 directory. If the localized manpage could not be found, man(1) will look for an Engligh cat(1) manpage with the same charset as in locale, i.e., in the /usr/share/man/en.ISO_8859-1/man1 directory. If found, groff(1) will produce the Latin-1 output, and man(1) will then store catpage in the en.ISO_8859-1/cat1. If all three searches above fail, man(1) will attempt a search in /usr/share/man/man1, will find the cat.1* here, and pass it to groff(1) with -Tascii device. This will produce 7-bit ASCII catpage which will be stored on disk in the /usr/share/man/cat1. (For a full list of rules of how man(1) searches for the manpage, please refer to the -o option description in the man(1) manpage, revision 1.14 or higher.) **************************** Now the problem. To make this patch actually do its job, and create symbolic links for /usr/share/man/man* in /usr/share/man/en.ISO_8859-1/, we need to drop the -d flag from mtree(8) call for BSD.usr.dist: Index: Makefile =================================================================== RCS file: /home/ncvs/src/etc/Makefile,v retrieving revision 1.240 diff -u -p -r1.240 Makefile --- Makefile 2001/01/09 22:28:17 1.240 +++ Makefile 2001/02/15 15:05:29 @@ -153,7 +153,7 @@ distribution: distrib-dirs: mtree -deU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.root.dist -p ${DESTDIR}/ mtree -deU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.var.dist -p ${DESTDIR}/var - mtree -deU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.usr.dist -p ${DESTDIR}/usr + mtree -eU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.usr.dist -p ${DESTDIR}/usr mtree -deU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.include.dist \ -p ${DESTDIR}/usr/include mtree -deU ${MTREE_FOLLOWS_SYMLINKS} -f ${.CURDIR}/mtree/BSD.include.dist \ So, are there any objections or goaheds? :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: BSD.usr.dist =================================================================== RCS file: /home/ncvs/src/etc/mtree/BSD.usr.dist,v retrieving revision 1.213 diff -u -p -r1.213 BSD.usr.dist --- BSD.usr.dist 2001/02/15 12:25:48 1.213 +++ BSD.usr.dist 2001/02/15 13:31:46 @@ -634,7 +634,52 @@ .. catn .. - ja uname=root + en.ISO_8859-1 uname=root + cat1 + .. + cat1aout + .. + cat2 + .. + cat3 + .. + cat4 + i386 + .. + .. + cat5 + .. + cat6 + .. + cat7 + .. + cat8 + i386 + .. + .. + cat9 + i386 + .. + .. + catn + .. +/set uname=root +/set type=link + man1 link=../man1 + man1aout link=../man1aout + man2 link=../man2 + man3 link=../man3 + man4 link=../man4 + man5 link=../man5 + man6 link=../man6 + man7 link=../man7 + man8 link=../man8 + man9 link=../man9 + mann link=../mann +/set type=dir + .. + ja +/set uname=man cat1 .. cat2 --rwEMma7ioTxnRzrJ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 7:38:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1632E37B491 for ; Thu, 15 Feb 2001 07:38:38 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1FFcMh33042; Thu, 15 Feb 2001 08:38:26 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1FFaeE77660; Thu, 15 Feb 2001 08:36:40 -0700 (MST) Message-Id: <200102151536.f1FFaeE77660@billy-club.village.org> To: Daniel Eischen Subject: Re: The whole libc thing. Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Feb 2001 09:16:47 EST." References: Date: Thu, 15 Feb 2001 08:36:40 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Daniel Eischen writes: : Let's just bump the libraries and be done with it. That's *ALL* the libraries, even in ports? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 7:58:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B19F037B65D; Thu, 15 Feb 2001 07:58:36 -0800 (PST) Received: from localhost (jie1jh@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f1FFwLA21464; Thu, 15 Feb 2001 10:58:24 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200102151558.f1FFwLA21464@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: Warner Losh , arch@FreeBSD.org Subject: Re: The whole libc thing. In-Reply-To: Message from Bruce Evans of "Thu, 15 Feb 2001 21:38:45 +1100." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 10:58:21 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Thu, 15 Feb 2001, Warner Losh wrote: > > > Green's solution of stealing a pointer and using that to "grow" FILE. > > This would allow old binaris to keep working at the cost of binary > > compatibility. There's a few extra indirections in this case, you'll > > likely not be able to measure that performance loss. But it will work > > with the case above and most of the others we threw at it. > > Pointers to FILEs can be converted to pointers extensions of FILEs using > a hash lookup. This takes slightly more than a few indirections, but > it doesn't cost binary compatibilty. Please see http://people.freebsd.org/~green/libc-evil.patch for what my actual proposition is (ignoring style bugs at the moment, please, which I know for you is hard ;) What Warner meant is this will allow us to grow the FILE structure _without_ the cost of losing binary compatibility, which is what a direct changeover to __stdio with no ABI compatibility hack would get you iff every single library immediately got its version bumped. My proposition wouldn't break any binary compatibility because it would keep the FILE structure size the same. The actual contents are _not_ allowed to be known outside of libc, so anything that gets it wrong after this change deserves to break in many horrible ways. We don't need a hash lookup because there is already a _very_ seldom-used field, _up, which can be absorbed for this purpose. I initially thought _cookie was better, but convinced myself otherwise (though DES may still not be convinced). In fact, if it even _looks_ ugly, we can rearrange the inside of FILE at will so it looks nicer without actually then changing the size. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 8: 4:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B373C37B491 for ; Thu, 15 Feb 2001 08:04:47 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1FG4jW62156 for ; Thu, 15 Feb 2001 09:04:47 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102151604.f1FG4jW62156@harmony.village.org> Subject: Re: The whole libc thing. To: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Feb 2001 02:03:53 MST." <200102150903.f1F93rW62243@harmony.village.org> References: <200102150903.f1F93rW62243@harmony.village.org> Date: Thu, 15 Feb 2001 09:04:45 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102150903.f1F93rW62243@harmony.village.org> Warner Losh writes: : Green's solution of stealing a pointer and using that to "grow" FILE. : This would allow old binaris to keep working at the cost of binary : compatibility. There's a few extra indirections in this case, you'll : likely not be able to measure that performance loss. But it will work : with the case above and most of the others we threw at it. I've become convinced that the old FILE layout is what we need to do. Step 1: Back out to Feb 10. Step 2: Apply Green's and Daniel's changes (Green to get the new layout, Daniel's for thread locking). These two changes are in my tree right now. Step 3: Introduce __stdin, __stdout, and __stderr into libc.so.3, libc.so.4 and libc.so.5. WE can do this in the building of libc.so via a trick that Tor Egge sent me (he did it to libc.so.3): --- /usr/obj/usr/src/gnu/usr.bin/binutils/ld/ldscripts/elf_i386.xs Sun Feb 4 00:23:05 2001 +++ /tmp/tegge1 Thu Feb 15 05:46:01 2001 @@ -62,6 +62,9 @@ .data : { *(.data) + __stdin = __sF; + __stdout = __sF +0x58 ; + __stderr = __sF +0xB0 ; *(.gnu.linkonce.d*) CONSTRUCTORS } Or, alternatively, I think that we could do this with a small amount of assembler on each platform that we support (i386, pc98 and alpha). I'm not sure how to do this, but something like the following might work on i386: .set __stdin, __sF .set __stdout, __sF + 0x58 .set __stderr, __sF + 0xB0 Step 4: Create compat libraries for libc.so.4 and libc.so.3. Encourage people to upgrade to these. This is the hard part and the weak part of my plan. Step 5: Bump the major version of libc and start using something like peter's change. I think that this will work. But need to make sure that we have no cases where newer libraries are using __sF and that breaking things. I'll try to put together a table to convince myself and others that this path will work. Steps 1 and 2 are known to work. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 8:16:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 308EC37B491; Thu, 15 Feb 2001 08:16:45 -0800 (PST) Received: from localhost (a9ob5c@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f1FGGgA21579; Thu, 15 Feb 2001 11:16:43 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200102151616.f1FGGgA21579@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: Warner Losh , arch@FreeBSD.org Subject: Re: The whole libc thing. In-Reply-To: Message from Bruce Evans of "Thu, 15 Feb 2001 21:38:45 +1100." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 11:16:42 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Thu, 15 Feb 2001, Warner Losh wrote: > > > Green's solution of stealing a pointer and using that to "grow" FILE. > > This would allow old binaris to keep working at the cost of binary > > compatibility. There's a few extra indirections in this case, you'll > > likely not be able to measure that performance loss. But it will work > > with the case above and most of the others we threw at it. > > Pointers to FILEs can be converted to pointers extensions of FILEs using > a hash lookup. This takes slightly more than a few indirections, but > it doesn't cost binary compatibilty. Replying _again_ because I'm pretty sure I didn't Cc: the list (damn Reply... menu). Warner meant that it would allow old binaries to keep working _without_ the cost of binary compatibility which would accompany anything we do now that doesn't bump every single shared library major in all ports and in the base. There's no need to even take a huge hit by making a hash of extra junk for __sFILE when there is at least one pointer just lying around which is used _so_ seldomly it will never be measurably noticed in anything but (imagining here...) a .00001% difference on some memory-backed-file microbenchmark that does nothing but attempt a worst case with ungetc ops and locked ops that force all CPU time to be spent in libc/stdio. Here's the change, not updated to -current with peter's introduction of __stdxxx, but that would of course be incorporated (with or without the new libc version bump, doesn't matter). I've not fixed the style yet, and noone's verified my pointer arithmetic yet, but I've tested it with a -D2/13/2001 HEAD and noticed no problems, and it doens't break _any_ binaries like an incompatible ABI would. (Please note that this ABI compatibility hack can be deprecated after one generation of using __stdxxx instead of __sF[]. So, probably after 5.x. IMHO, that's very acceptable.) Index: include/stdio.h =================================================================== RCS file: /usr2/ncvs/src/include/stdio.h,v retrieving revision 1.28 diff -u -r1.28 stdio.h --- include/stdio.h 2001/02/12 03:31:23 1.28 +++ include/stdio.h 2001/02/15 06:00:52 @@ -70,6 +70,12 @@ struct __file_lock; +/* hold a buncha junk that would grow the ABI */ +struct __sFILEX { + struct __file_lock *_lock; /* used for MT-safety */ + unsigned char *_up; /* saved _p when _p is doing ungetc data */ +}; + /* * stdio state variables. * @@ -111,10 +117,13 @@ int (*_read) __P((void *, char *, int)); fpos_t (*_seek) __P((void *, fpos_t, int)); int (*_write) __P((void *, const char *, int)); + struct __sFILEX *_extra; /* stuff that needs to move to not break ABI */ /* separate buffer for long sequences of ungetc() */ struct __sbuf _ub; /* ungetc buffer */ +#if 0 unsigned char *_up; /* saved _p when _p is doing ungetc data */ +#endif int _ur; /* saved _r when _r is counting ungetc data */ /* tricks to meet minimum requirements even when malloc() fails */ @@ -127,7 +136,6 @@ /* Unix stdio files get aligned to block boundaries on fseek() */ int _blksize; /* stat.st_blksize (may be != _bf._size) */ fpos_t _offset; /* current lseek offset (see WARNING) */ - struct __file_lock *_lock; /* used for MT-safety */ } FILE; __BEGIN_DECLS Index: lib/libc//stdio/_flock_stub.c =================================================================== RCS file: /usr2/ncvs/src/lib/libc/stdio/_flock_stub.c,v retrieving revision 1.5 diff -u -r1.5 _flock_stub.c --- lib/libc//stdio/_flock_stub.c 2001/02/11 22:06:39 1.5 +++ lib/libc//stdio/_flock_stub.c 2001/02/15 06:14:52 @@ -82,7 +82,7 @@ p->fl_mutex = PTHREAD_MUTEX_INITIALIZER; p->fl_owner = NULL; p->fl_count = 0; - fp->_lock = p; + fp->_extra->_lock = p; ret = 0; } return (ret); @@ -98,17 +98,17 @@ * the lock if needed: */ if ((fp->_file >= 0) && - ((fp->_lock != NULL) || (init_lock(fp) == 0))) { - if (fp->_lock->fl_owner == curthread) - fp->_lock->fl_count++; + ((fp->_extra->_lock != NULL) || (init_lock(fp) == 0))) { + if (fp->_extra->_lock->fl_owner == curthread) + fp->_extra->_lock->fl_count++; else { /* * Make sure this mutex is treated as a private * internal mutex: */ - _pthread_mutex_lock(&fp->_lock->fl_mutex); - fp->_lock->fl_owner = curthread; - fp->_lock->fl_count = 1; + _pthread_mutex_lock(&fp->_extra->_lock->fl_mutex); + fp->_extra->_lock->fl_owner = curthread; + fp->_extra->_lock->fl_count = 1; } } } @@ -133,16 +133,16 @@ * the lock if needed: */ if ((fp->_file >= 0) && - ((fp->_lock != NULL) || (init_lock(fp) == 0))) { - if (fp->_lock->fl_owner == curthread) - fp->_lock->fl_count++; + ((fp->_extra->_lock != NULL) || (init_lock(fp) == 0))) { + if (fp->_extra->_lock->fl_owner == curthread) + fp->_extra->_lock->fl_count++; /* * Make sure this mutex is treated as a private * internal mutex: */ - else if (_pthread_mutex_trylock(&fp->_lock->fl_mutex) == 0) { - fp->_lock->fl_owner = curthread; - fp->_lock->fl_count = 1; + else if (_pthread_mutex_trylock(&fp->_extra->_lock->fl_mutex) == 0) { + fp->_extra->_lock->fl_owner = curthread; + fp->_extra->_lock->fl_count = 1; } else ret = -1; @@ -161,27 +161,27 @@ * Check if this is a real file with a valid lock owned * by the current thread: */ - if ((fp->_file >= 0) && (fp->_lock != NULL) && - (fp->_lock->fl_owner == curthread)) { + if ((fp->_file >= 0) && (fp->_extra->_lock != NULL) && + (fp->_extra->_lock->fl_owner == curthread)) { /* * Check if this thread has locked the FILE * more than once: */ - if (fp->_lock->fl_count > 1) + if (fp->_extra->_lock->fl_count > 1) /* * Decrement the count of the number of * times the running thread has locked this * file: */ - fp->_lock->fl_count--; + fp->_extra->_lock->fl_count--; else { /* * The running thread will release the * lock now: */ - fp->_lock->fl_count = 0; - fp->_lock->fl_owner = NULL; - _pthread_mutex_unlock(&fp->_lock->fl_mutex); + fp->_extra->_lock->fl_count = 0; + fp->_extra->_lock->fl_owner = NULL; + _pthread_mutex_unlock(&fp->_extra->_lock->fl_mutex); } } } Index: lib/libc//stdio/findfp.c =================================================================== RCS file: /usr2/ncvs/src/lib/libc/stdio/findfp.c,v retrieving revision 1.12 diff -u -r1.12 findfp.c --- lib/libc//stdio/findfp.c 2001/02/12 03:31:23 1.12 +++ lib/libc//stdio/findfp.c 2001/02/15 06:31:21 @@ -60,13 +60,15 @@ #define NDYNAMIC 10 /* add ten more whenever necessary */ #define std(flags, file) \ - {0,0,0,flags,file,{0},0,__sF+file,__sclose,__sread,__sseek,__swrite} -/* p r w flags file _bf z cookie close read seek write */ + {0,0,0,flags,file,{0},0,__sF+file,__sclose,__sread,__sseek,__swrite, __sFX + file} +/* p r w flags file _bf z cookie close read seek write extra*/ /* the usual - (stdin + stdout + stderr) */ static FILE usual[FOPEN_MAX - 3]; static struct glue uglue = { NULL, FOPEN_MAX - 3, usual }; +static struct __sFILEX __sFX[3]; + FILE __sF[3] = { std(__SRD, STDIN_FILENO), /* stdin */ std(__SWR, STDOUT_FILENO), /* stdout */ @@ -92,18 +94,26 @@ int n; { struct glue *g; - FILE *p; static FILE empty; + static struct __sFILEX emptyx; + FILE *p; + struct __sFILEX *fx; - g = (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * sizeof(FILE)); + g = (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * sizeof(FILE) + + n * sizeof(struct __sFILEX)); if (g == NULL) return (NULL); p = (FILE *)ALIGN(g + 1); + fx = (struct __sFILEX *)&p[n]; g->next = NULL; g->niobs = n; g->iobs = p; - while (--n >= 0) - *p++ = empty; + while (--n >= 0) { + *p = empty; + p->_extra = fx; + *p->_extra = emptyx; + p++, fx++; + } return (g); } Index: lib/libc//stdio/fseek.c =================================================================== RCS file: /usr2/ncvs/src/lib/libc/stdio/fseek.c,v retrieving revision 1.10 diff -u -r1.10 fseek.c --- lib/libc//stdio/fseek.c 2001/01/24 13:00:45 1.10 +++ lib/libc//stdio/fseek.c 2001/02/15 06:08:49 @@ -204,7 +204,7 @@ */ if (HASUB(fp)) { curoff += fp->_r; /* kill off ungetc */ - n = fp->_up - fp->_bf._base; + n = fp->_extra->_up - fp->_bf._base; curoff -= n; n += fp->_ur; } else { Index: lib/libc//stdio/refill.c =================================================================== RCS file: /usr2/ncvs/src/lib/libc/stdio/refill.c,v retrieving revision 1.10 diff -u -r1.10 refill.c --- lib/libc//stdio/refill.c 2001/02/11 22:06:42 1.10 +++ lib/libc//stdio/refill.c 2001/02/15 06:08:58 @@ -109,7 +109,7 @@ if (HASUB(fp)) { FREEUB(fp); if ((fp->_r = fp->_ur) != 0) { - fp->_p = fp->_up; + fp->_p = fp->_extra->_up; return (0); } } Index: lib/libc//stdio/ungetc.c =================================================================== RCS file: /usr2/ncvs/src/lib/libc/stdio/ungetc.c,v retrieving revision 1.8 diff -u -r1.8 ungetc.c --- lib/libc//stdio/ungetc.c 2001/01/24 13:00:47 1.8 +++ lib/libc//stdio/ungetc.c 2001/02/15 06:09:12 @@ -164,7 +164,7 @@ * Initially, we will use the `reserve' buffer. */ fp->_ur = fp->_r; - fp->_up = fp->_p; + fp->_extra->_up = fp->_p; fp->_ub._base = fp->_ubuf; fp->_ub._size = sizeof(fp->_ubuf); fp->_ubuf[sizeof(fp->_ubuf) - 1] = c; -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 8:21: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id DBA7337B65D; Thu, 15 Feb 2001 08:21:01 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1FGL0h33192; Thu, 15 Feb 2001 09:21:00 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1FGJIE77829; Thu, 15 Feb 2001 09:19:18 -0700 (MST) Message-Id: <200102151619.f1FGJIE77829@billy-club.village.org> To: "Brian F. Feldman" Subject: Re: The whole libc thing. Cc: Bruce Evans , arch@FreeBSD.org In-reply-to: Your message of "Thu, 15 Feb 2001 11:16:42 EST." <200102151616.f1FGGgA21579@green.dyndns.org> References: <200102151616.f1FGGgA21579@green.dyndns.org> Date: Thu, 15 Feb 2001 09:19:18 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102151616.f1FGGgA21579@green.dyndns.org> "Brian F. Feldman" writes: : Here's the change, not updated to -current with peter's introduction of : __stdxxx, but that would of course be incorporated (with or without the new : libc version bump, doesn't matter). I've not fixed the style yet, and : noone's verified my pointer arithmetic yet, but I've tested it with a : -D2/13/2001 HEAD and noticed no problems, and it doens't break _any_ binaries : like an incompatible ABI would. I have a few tweaks to Brian's changes, but am waiting for my compile to get done before making them available. They will be relative to 4am MST this morning's current. I also have a few ideas on how to introduce __stdxxx now so that we can move to them in the future. With a netonly 3.5.2 release and 4.3 having the "good" libraries. More when I know more. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 10:15:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0B62137B491 for ; Thu, 15 Feb 2001 10:15:12 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA11455; Thu, 15 Feb 2001 13:14:44 -0500 (EST) Date: Thu, 15 Feb 2001 13:14:44 -0500 (EST) From: Daniel Eischen To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: The whole libc thing. In-Reply-To: <200102151536.f1FFaeE77660@billy-club.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001, Warner Losh wrote: > In message Daniel Eischen writes: > : Let's just bump the libraries and be done with it. > > That's *ALL* the libraries, even in ports? Hmm, perhaps not then. It would be nice to get rid of __sF; if we don't do it now, will we ever? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 10:18:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C5CD637B401 for ; Thu, 15 Feb 2001 10:18:22 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1FIIHk27229; Thu, 15 Feb 2001 10:18:17 -0800 (PST) Date: Thu, 15 Feb 2001 10:18:17 -0800 From: Alfred Perlstein To: Daniel Eischen Cc: Warner Losh , arch@FreeBSD.ORG Subject: Re: The whole libc thing. Message-ID: <20010215101817.G3274@fw.wintelcom.net> References: <200102151536.f1FFaeE77660@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eischen@vigrid.com on Thu, Feb 15, 2001 at 01:14:44PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Daniel Eischen [010215 10:15] wrote: > On Thu, 15 Feb 2001, Warner Losh wrote: > > In message Daniel Eischen writes: > > : Let's just bump the libraries and be done with it. > > > > That's *ALL* the libraries, even in ports? > > Hmm, perhaps not then. It would be nice to get rid of __sF; if we > don't do it now, will we ever? I still think that no matter how painful we should just loose __sF in -current, afaik the only thing depending on it is the std* macros. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 10:34:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id D87FE37B401 for ; Thu, 15 Feb 2001 10:34:03 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1FIXv941778 for ; Thu, 15 Feb 2001 20:34:00 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102151834.f1FIXv941778@gratis.grondar.za> To: arch@freebsd.org Subject: The /usr/bin/games bikeshed again Date: Thu, 15 Feb 2001 20:34:33 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a little time on my hands while the library gurus sort out stuff, so I thought I'd divert a little attention to the games dir. Jordan brought this up a couple of years ago, and it got badly bikeshedded, even though it was generally deemed to be a good idea. So - I bring up an improvemnt on the original idea, and throw it open for discussion. I have coarsely cateogorised the games in src/games into broad groups - adventure/strategy, board/card, novelty, quiz, arcade and utility. PLEASE PLEASE resist the temptation to recategorise games unless there is a strong reason to do so. I'd prefer to not see this thread die in a nitpicking argument about what category a particular game belongs to. I'd like to turn each category into a port (ports/games/bsd-adventure for example), with the exception of "utility"). Those, I'd like to keep where they are. In that class ("utility") is everyone's favourite - fortune, so that should deal with most of the fears from last time :-). The ports/games/* ports could probably get a clue-injection on how to use dm(6), but that is another bikeshed. Here are all the games in their categories (I propose that we ditch the "junk" category; wargames(6) is a rather stale joke by now.): Adventure/Strategy ------------------ adventure A atc A battlestar A hack A larn A phantasia A rogue A sail A trek A wump A Board/Card ---------- backgammon B bs B canfield B cribbage B fish B mille B Junk ---- wargames J Novelty ------- bcd N (U?) grdc N (U?) piano N pig N pom N ppt N (U?) rain N worms N Quiz ---- arithmetic Q hangman Q quiz Q Arcade ------ robots R (A?) snake R (A?) worm R (A?) Utility ------- caesar U factor U fortune U morse U number U primes U random U M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 11:10:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1993537B401; Thu, 15 Feb 2001 11:10:51 -0800 (PST) Received: (from jmz@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f1FJApM59398; Thu, 15 Feb 2001 11:10:51 -0800 (PST) (envelope-from jmz@FreeBSD.org) Date: Thu, 15 Feb 2001 11:10:51 -0800 (PST) Message-Id: <200102151910.f1FJApM59398@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: jmz set sender to jmz@FreeBSD.org using -f From: Jean-Marc Zucconi To: Mark Murray Cc: arch@FreeBSD.org Subject: Re: The /usr/bin/games bikeshed again In-Reply-To: <200102151834.f1FIXv941778@gratis.grondar.za> References: <200102151834.f1FIXv941778@gratis.grondar.za> X-Mailer: Emacs 20.7.1 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> Mark Murray writes: > I'd like to turn each category into a port (ports/games/bsd-adventure > for example), with the exception of "utility"). Those, I'd like > to keep where they are. In that class ("utility") is everyone's > favourite - fortune, so that should deal with most of the fears > from last time :-). I prefer to move *all* the games to ports, including the "utility" ones. If one one them is really useful, then it should be in /usr/bin. Fortune does not belong to any "utility" category. Jean-Marc -- Jean-Marc Zucconi -- PGP Key: finger jmz@FreeBSD.org [KeyID: 400B38E9] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 11:13:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 9794D37B698 for ; Thu, 15 Feb 2001 11:13:48 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1FJDVn32289; Thu, 15 Feb 2001 13:13:31 -0600 (CST) (envelope-from jlemon) Date: Thu, 15 Feb 2001 13:13:31 -0600 From: Jonathan Lemon To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again Message-ID: <20010215131331.C25880@prism.flugsvamp.com> References: <200102151834.f1FIXv941778@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200102151834.f1FIXv941778@gratis.grondar.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's my suggested patch: --- /etc/aliases Thu Jan 18 22:51:36 2001 +++ aliases Thu Feb 15 11:10:20 2001 @@ -416,6 +416,11 @@ owner-freebsd-arch-request: owner-freebsd-arch #XXX no digest owner-freebsd-arch-digest: owner-freebsd-arch +# freebsd-bikeshed +# +bikeshed: freebsd-arch +freebsd-bikeshed: freebsd-arch + # # BSD-serious -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 11:14:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 85DAC37B503; Thu, 15 Feb 2001 11:14:07 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f1FJE4c45426; Thu, 15 Feb 2001 21:14:04 +0200 (EET) (envelope-from ru) Date: Thu, 15 Feb 2001 21:14:04 +0200 From: Ruslan Ermilov To: arch@FreeBSD.org Subject: [Call for *quick* review] architecture-specific manpages Message-ID: <20010215211404.A44780@sunbay.com> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Bcc'ed to -developers] Hi! The attached patch implements one nice feature of original BSD man(1), to look into the machine-specific subdirectory, specifically: : As some manual pages are intended only for specific architectures, : man searches any subdirectories, with the same name as the current : architecture, in every directory which it searches. Machine specific : areas are checked before general areas. The current machine type may : be overridden by setting the environment variable MACHINE to the name : of a specific architecture. This would eliminate the need to MLINK every arch-specific file to the parent directory, and would allow us to have both architecture-specific and generic manpages with the same name in the same section. Comments? -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: man.c =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/man/man/man.c,v retrieving revision 1.44 diff -u -p -r1.44 man.c --- man.c 2001/02/15 19:01:41 1.44 +++ man.c 2001/02/15 19:02:10 @@ -20,7 +20,7 @@ #include #include -#include +#include #include #include #ifdef __FreeBSD__ @@ -74,6 +74,7 @@ extern int do_system_command (); char *prognam; static char *pager; +static char *machine; static char *manp; static char *manpathlist[MAXDIRS]; static char *section; @@ -495,6 +496,12 @@ man_getopt (argc, argv) if (debug) fprintf (stderr, "\nusing %s as pager\n", pager); + if ((machine = getenv ("MACHINE")) == NULL) + machine = MACHINE; + + if (debug) + fprintf (stderr, "\nusing %s architecture\n", machine); + if (manp == NULL) { if ((manp = manpath (0)) == NULL) @@ -662,6 +669,15 @@ convert_name (name, to_cat) *t1 = '\0'; t2 = strrchr (to_name, '/'); *t1 = '/'; + + /* Skip architecture part (if present). */ + if (t2 != NULL && (t1 - t2 < 5 || *(t2 + 1) != 'm' || *(t2 + 3) != 'n')) + { + t1 = t2; + *t1 = '\0'; + t2 = strrchr (to_name, '/'); + *t1 = '/'; + } } if (t2 == NULL) @@ -1469,6 +1485,22 @@ try_section (path, section, name, glob) register int cat; register char **names; register char **np; + static int arch_search; + char buf[FILENAME_MAX]; + + if (!arch_search) + { + snprintf(buf, sizeof(buf), "%s/man%s/%s", path, section, machine); + if (is_directory (buf) == 1) + { + snprintf(buf, sizeof(buf), "%s/%s", machine, name); + arch_search++; + found = try_section (path, section, buf, glob); + arch_search--; + if (found && !findall) /* only do this architecture... */ + return found; + } + } if (debug) { --MGYHOYXEY6WxJCY8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 11:24:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from blizzard.sabbo.net (smtp.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 0785C37B491; Thu, 15 Feb 2001 11:24:20 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f1FJOHn07174; Thu, 15 Feb 2001 21:24:18 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.2/8.11.2) with ESMTP id f1FJOIm20467; Thu, 15 Feb 2001 21:24:18 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A8C2CDC.307458AE@FreeBSD.org> Date: Thu, 15 Feb 2001 21:24:12 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Ruslan Ermilov Cc: arch@FreeBSD.org Subject: Re: [Call for *quick* review] architecture-specific manpages References: <20010215211404.A44780@sunbay.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > [Bcc'ed to -developers] > > Hi! > > The attached patch implements one nice feature of original BSD man(1), > to look into the machine-specific subdirectory, specifically: > > : As some manual pages are intended only for specific architectures, > : man searches any subdirectories, with the same name as the current > : architecture, in every directory which it searches. Machine specific > : areas are checked before general areas. The current machine type may > : be overridden by setting the environment variable MACHINE to the name > : of a specific architecture. > > This would eliminate the need to MLINK every arch-specific file to the > parent directory, and would allow us to have both architecture-specific > and generic manpages with the same name in the same section. > > Comments? Why not to use HW_MACHINE mib to get current arch, so it would just work [tm] w/o the need to define MACHINE env variable? -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 11:37:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 73D4F37B684; Thu, 15 Feb 2001 11:37:29 -0800 (PST) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA63098; Thu, 15 Feb 2001 11:37:29 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200102151937.LAA63098@gndrsh.dnsmgr.net> Subject: Re: Proposed change for ISO_8859-1 catpages In-Reply-To: <20010215171519.A24192@sunbay.com> from Ruslan Ermilov at "Feb 15, 2001 05:15:19 pm" To: ru@FreeBSD.ORG (Ruslan Ermilov) Date: Thu, 15 Feb 2001 11:37:28 -0800 (PST) Cc: arch@FreeBSD.ORG, ache@FreeBSD.ORG (Andrey Chernov), des@FreeBSD.ORG (Dag-Erling Smorgrav) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ... > **************************** > > Now the problem. > > To make this patch actually do its job, and create symbolic links > for /usr/share/man/man* in /usr/share/man/en.ISO_8859-1/, we need > to drop the -d flag from mtree(8) call for BSD.usr.dist: > > Index: Makefile ... > > So, are there any objections or goaheds? :-) README: b) Only directories should be listed here. Have you taken a look at what happens when you run cd /usr/src; make hierarchy with your patch in place? -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 11:44:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from borg-cube.com (226-193.adsl2.netlojix.net [207.71.226.193]) by hub.freebsd.org (Postfix) with ESMTP id 8F8AF37B503; Thu, 15 Feb 2001 11:44:10 -0800 (PST) Received: from borg-cube.com (dburr@borg-cube.com [207.71.226.193]) by borg-cube.com (8.11.0/8.11.0) with ESMTP id f1FJi9W73418; Thu, 15 Feb 2001 11:44:09 -0800 (PST) (envelope-from dburr@borg-cube.com) Date: Thu, 15 Feb 2001 11:44:09 -0800 (PST) From: Donald Burr of Borg To: Maxim Sobolev Cc: Ruslan Ermilov , arch@FreeBSD.org Subject: Re: [Call for *quick* review] architecture-specific manpages In-Reply-To: <3A8C2CDC.307458AE@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001, Maxim Sobolev wrote: MS>> : As some manual pages are intended only for specific architectures, MS>> : man searches any subdirectories, with the same name as the current MS>> : architecture, in every directory which it searches. Machine specific MS>> : areas are checked before general areas. The current machine type may ---------------------------- MS>> : be overridden by setting the environment variable MACHINE to the name --------------------------------------------------------- MS>> : of a specific architecture. MS>> MS>> This would eliminate the need to MLINK every arch-specific file to the MS>> parent directory, and would allow us to have both architecture-specific MS>> and generic manpages with the same name in the same section. MS>> MS>> Comments? MS> MS>Why not to use HW_MACHINE mib to get current arch, so it would just work [tm] w/o the MS>need to define MACHINE env variable? Umm, I think you misunderstand. The way I read it, the patches automatically detect the machine architecture that you're running, but you can set the MACHINE environment variable to *override* that automatic detection. Please note the underlined passage in the quotation. -- Donald Burr Resistance is Futile | FreeBSD: The WWW: http://www.borg-cube.com/ ICQ: UIN#16997506 | Power to Address: P.O. Box 91212, Santa Barbara, CA 93190-1212 | Serve! http:// Phone: (805) 957-9666 FAX: (800) 492-5954 | www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 11:48:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 7D0AD37B491; Thu, 15 Feb 2001 11:48:31 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f1FJmMn07559; Thu, 15 Feb 2001 21:48:23 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.2/8.11.2) with ESMTP id f1FJmQm20553; Thu, 15 Feb 2001 21:48:26 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A8C3283.57266038@FreeBSD.org> Date: Thu, 15 Feb 2001 21:48:20 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Donald Burr of Borg Cc: Ruslan Ermilov , arch@FreeBSD.org Subject: Re: [Call for *quick* review] architecture-specific manpages References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Donald Burr of Borg wrote: > On Thu, 15 Feb 2001, Maxim Sobolev wrote: > > MS>> : As some manual pages are intended only for specific architectures, > MS>> : man searches any subdirectories, with the same name as the current > MS>> : architecture, in every directory which it searches. Machine specific > MS>> : areas are checked before general areas. The current machine type may > ---------------------------- > MS>> : be overridden by setting the environment variable MACHINE to the name > --------------------------------------------------------- > MS>> : of a specific architecture. > MS>> > MS>> This would eliminate the need to MLINK every arch-specific file to the > MS>> parent directory, and would allow us to have both architecture-specific > MS>> and generic manpages with the same name in the same section. > MS>> > MS>> Comments? > MS> > MS>Why not to use HW_MACHINE mib to get current arch, so it would just work [tm] w/o the > MS>need to define MACHINE env variable? > > Umm, I think you misunderstand. The way I read it, the patches > automatically detect the machine architecture that you're running, but you > can set the MACHINE environment variable to *override* that automatic > detection. > > Please note the underlined passage in the quotation. Yeah, I read and understood it correctly, but I have not found anything even remotely resembling autodetection in the patch attached. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 12:35:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E623537B4EC for ; Thu, 15 Feb 2001 12:35:09 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1FKYoW63859; Thu, 15 Feb 2001 13:34:53 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102152034.f1FKYoW63859@harmony.village.org> To: Alfred Perlstein Subject: Re: The whole libc thing. Cc: Daniel Eischen , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Feb 2001 10:18:17 PST." <20010215101817.G3274@fw.wintelcom.net> References: <20010215101817.G3274@fw.wintelcom.net> <200102151536.f1FFaeE77660@billy-club.village.org> Date: Thu, 15 Feb 2001 13:34:50 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010215101817.G3274@fw.wintelcom.net> Alfred Perlstein writes: : * Daniel Eischen [010215 10:15] wrote: : > On Thu, 15 Feb 2001, Warner Losh wrote: : > > In message Daniel Eischen writes: : > > : Let's just bump the libraries and be done with it. : > > : > > That's *ALL* the libraries, even in ports? : > : > Hmm, perhaps not then. It would be nice to get rid of __sF; if we : > don't do it now, will we ever? : : I still think that no matter how painful we should just loose __sF : in -current, afaik the only thing depending on it is the std* : macros. Yes. That's the "only" thing. But *EVERYTHING* depends on those macros. Just about every single library has at least one fprintf(stderr, "Something bad happened"); in it. We have to be smart about how we transition away from __sF. If we aren't, we badly break binary compatibility. We all want to get rid of it, but the way Peter did it is *WRONG* and we need to retrench and do it *RIGHT*. OK? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 12:38: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9BB3337B401 for ; Thu, 15 Feb 2001 12:38:06 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1FKbwT01274; Thu, 15 Feb 2001 12:37:58 -0800 (PST) Date: Thu, 15 Feb 2001 12:37:58 -0800 From: Alfred Perlstein To: Warner Losh Cc: Daniel Eischen , arch@FreeBSD.ORG Subject: Re: The whole libc thing. Message-ID: <20010215123758.L3274@fw.wintelcom.net> References: <20010215101817.G3274@fw.wintelcom.net> <200102151536.f1FFaeE77660@billy-club.village.org> <20010215101817.G3274@fw.wintelcom.net> <200102152034.f1FKYoW63859@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102152034.f1FKYoW63859@harmony.village.org>; from imp@harmony.village.org on Thu, Feb 15, 2001 at 01:34:50PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Warner Losh [010215 12:35] wrote: > In message <20010215101817.G3274@fw.wintelcom.net> Alfred Perlstein writes: > : * Daniel Eischen [010215 10:15] wrote: > : > On Thu, 15 Feb 2001, Warner Losh wrote: > : > > In message Daniel Eischen writes: > : > > : Let's just bump the libraries and be done with it. > : > > > : > > That's *ALL* the libraries, even in ports? > : > > : > Hmm, perhaps not then. It would be nice to get rid of __sF; if we > : > don't do it now, will we ever? > : > : I still think that no matter how painful we should just loose __sF > : in -current, afaik the only thing depending on it is the std* > : macros. > > Yes. That's the "only" thing. But *EVERYTHING* depends on those > macros. Just about every single library has at least one > fprintf(stderr, "Something bad happened"); in it. We have to be smart > about how we transition away from __sF. If we aren't, we badly break > binary compatibility. > > We all want to get rid of it, but the way Peter did it is *WRONG* and > we need to retrench and do it *RIGHT*. OK? We'll still have libc.so that contains __sF for old apps, and the newer stuff will be less brain damaged. We're only breaking applications for those of us running -current. I'd say a large cross posted 'HEADS-UP (we mean it!)' would be enough. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 12:45:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 90F5837B4EC for ; Thu, 15 Feb 2001 12:45:17 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1FKj9W88215; Thu, 15 Feb 2001 13:45:09 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102152045.f1FKj9W88215@harmony.village.org> To: Alfred Perlstein Subject: Re: The whole libc thing. Cc: Daniel Eischen , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Feb 2001 12:37:58 PST." <20010215123758.L3274@fw.wintelcom.net> References: <20010215123758.L3274@fw.wintelcom.net> <20010215101817.G3274@fw.wintelcom.net> <200102151536.f1FFaeE77660@billy-club.village.org> <20010215101817.G3274@fw.wintelcom.net> <200102152034.f1FKYoW63859@harmony.village.org> Date: Thu, 15 Feb 2001 13:45:09 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010215123758.L3274@fw.wintelcom.net> Alfred Perlstein writes: : We'll still have libc.so that contains __sF for old apps, and the newer : stuff will be less brain damaged. We're only breaking applications : for those of us running -current. : : I'd say a large cross posted 'HEADS-UP (we mean it!)' would be enough. Alfred, you are incorrect. We're working on a long term solution that will be compatible. The HEADS-UP isn't enough. Too many things are broken. I really mean that when I say it. The solution that we're coming up with will move towards what Peter did, but what Peter did is incomplete right now and needs to be backed out until it can be made complete. Once it is complete, we can move to it without too much hassle. The biggest hassle would be that -current users MUST (and -stable users should) recompile libraries before linking to new things. Let me thread through these issue before people rush in and try to "Fix" it. We'll end up with another incomplete solution. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 13: 3:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id C39AE37B491; Thu, 15 Feb 2001 13:03:51 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.2/8.11.2) id f1FL3oK91543; Fri, 16 Feb 2001 00:03:50 +0300 (MSK) (envelope-from ache) Date: Fri, 16 Feb 2001 00:03:49 +0300 From: "Andrey A. Chernov" To: arch@FreeBSD.org, Dag-Erling Smorgrav Subject: Re: Proposed change for ISO_8859-1 catpages Message-ID: <20010216000349.A91289@nagual.pp.ru> References: <20010215171519.A24192@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010215171519.A24192@sunbay.com>; from ru@FreeBSD.org on Thu, Feb 15, 2001 at 05:15:19PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 15, 2001 at 17:15:19 +0200, Ruslan Ermilov wrote: > Now the problem. > > To make this patch actually do its job, and create symbolic links > for /usr/share/man/man* in /usr/share/man/en.ISO_8859-1/, we need > to drop the -d flag from mtree(8) call for BSD.usr.dist: If adding links by mtree cause problems, they can be added like locale.alias links (see etc/Makefile) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 13:19:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from privatecube.privatelabs.com (privatecube.privatelabs.com [63.114.185.254]) by hub.freebsd.org (Postfix) with ESMTP id 82BC737B503; Thu, 15 Feb 2001 13:19:12 -0800 (PST) Received: from misha.privatelabs.com (root@misha.plten [10.0.0.106]) by privatecube.privatelabs.com (8.9.3/8.9.2) with ESMTP id QAA16027; Thu, 15 Feb 2001 16:39:17 -0500 Received: from misha.privatelabs.com (mi@localhost [127.0.0.1]) by misha.privatelabs.com (8.11.1/8.11.1) with ESMTP id f1FLJ6v10117; Thu, 15 Feb 2001 16:19:08 -0500 (EST) (envelope-from mi@misha.privatelabs.com) Message-Id: <200102152119.f1FLJ6v10117@misha.privatelabs.com> Date: Thu, 15 Feb 2001 16:19:05 -0500 (EST) From: mi@aldan.algebra.com Subject: Re: [Call for *quick* review] architecture-specific manpages To: Maxim Sobolev Cc: ru@FreeBSD.org, arch@FreeBSD.org In-Reply-To: <3A8C2CDC.307458AE@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15 Feb, Maxim Sobolev wrote: [...] = Why not to use HW_MACHINE mib to get current arch, so it would just work [tm] w/o the = need to define MACHINE env variable? Because I may be interested in the man page for one architecture while working on the other? There should be a command line option for that too, IMHO... -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 13:23:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3A58F37B4EC; Thu, 15 Feb 2001 13:23:17 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1FLNFh46547; Thu, 15 Feb 2001 16:23:16 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 15 Feb 2001 16:23:15 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ruslan Ermilov Cc: arch@FreeBSD.org Subject: Re: [Call for *quick* review] architecture-specific manpages In-Reply-To: <20010215211404.A44780@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001, Ruslan Ermilov wrote: > The attached patch implements one nice feature of original BSD man(1), > to look into the machine-specific subdirectory, specifically: > > : As some manual pages are intended only for specific architectures, > : man searches any subdirectories, with the same name as the current > : architecture, in every directory which it searches. Machine specific > : areas are checked before general areas. The current machine type may > : be overridden by setting the environment variable MACHINE to the name > : of a specific architecture. > > This would eliminate the need to MLINK every arch-specific file to the > parent directory, and would allow us to have both architecture-specific > and generic manpages with the same name in the same section. It's a good idea to check the results of calls like snprintf or you can get truncation bugs. I'd recommend you go pass these patches by -audit. Any time you have programs running with privilege of some sort (and yes, setuid man or setgid man counts as privilege), you have to be *really* careful. These patches do not appear to be very careful at all, and they seem to make heavy use of environmental variables in constructing strings. I'd personally feel a lot more comfortable with all this if we'd simply remove the setuid/setgid man'ness of man, and either pre-generate cached pages as appropriate, or simply eschew caching, given the speed of modern machines. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 13:37:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 7920C37B67D; Thu, 15 Feb 2001 13:37:15 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f1FLb8n09355; Thu, 15 Feb 2001 23:37:10 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.2/8.11.2) with ESMTP id f1FLbDm20747; Thu, 15 Feb 2001 23:37:13 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A8C4C02.D8300939@FreeBSD.org> Date: Thu, 15 Feb 2001 23:37:06 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: mi@aldan.algebra.com Cc: ru@FreeBSD.org, arch@FreeBSD.org Subject: Re: [Call for *quick* review] architecture-specific manpages References: <200102152119.f1FLJ6v10117@misha.privatelabs.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG mi@aldan.algebra.com wrote: > On 15 Feb, Maxim Sobolev wrote: > [...] > = Why not to use HW_MACHINE mib to get current arch, so it would just work [tm] w/o the > = need to define MACHINE env variable? > > Because I may be interested in the man page for one architecture while > working on the other? There should be a command line option for that > too, IMHO... Please read my message again. I have not implied that detection of MACHINE env variable should be removed. I only noted that value returned by the HW_MACHINE mib is to be used when no MACHINE env variable is defined. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 13:54:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 5CB3137B401 for ; Thu, 15 Feb 2001 13:54:38 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1FLsbk04122 for arch@freebsd.org; Thu, 15 Feb 2001 13:54:37 -0800 (PST) (envelope-from obrien) Date: Thu, 15 Feb 2001 13:54:37 -0800 From: "David O'Brien" To: arch@freebsd.org Subject: Re: The /usr/bin/games bikeshed again Message-ID: <20010215135437.A3838@dragon.nuxi.com> Reply-To: freebsd-arch@freebsd.org References: <200102151834.f1FIXv941778@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102151834.f1FIXv941778@gratis.grondar.za>; from mark@grondar.za on Thu, Feb 15, 2001 at 08:34:33PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 15, 2001 at 08:34:33PM +0200, Mark Murray wrote: > I have coarsely cateogorised the games in src/games into broad > groups - adventure/strategy, board/card, novelty, quiz, arcade and > utility. ... > I'd like to turn each category into a port (ports/games/bsd-adventure > for example), with the exception of "utility"). Those, I'd like > to keep where they are. I fully support this idea. Anything else in the base system that was so old and little used, would have been pushed to ports a long time ago. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 14:36:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C598B37B491; Thu, 15 Feb 2001 14:36:17 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1FMaHW11860; Thu, 15 Feb 2001 15:36:17 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102152236.f1FMaHW11860@harmony.village.org> To: freebsd-arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Feb 2001 13:54:37 PST." <20010215135437.A3838@dragon.nuxi.com> References: <20010215135437.A3838@dragon.nuxi.com> <200102151834.f1FIXv941778@gratis.grondar.za> Date: Thu, 15 Feb 2001 15:36:17 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010215135437.A3838@dragon.nuxi.com> "David O'Brien" writes: : On Thu, Feb 15, 2001 at 08:34:33PM +0200, Mark Murray wrote: : > I have coarsely cateogorised the games in src/games into broad : > groups - adventure/strategy, board/card, novelty, quiz, arcade and : > utility. : ... : > I'd like to turn each category into a port (ports/games/bsd-adventure : > for example), with the exception of "utility"). Those, I'd like : > to keep where they are. : : : I fully support this idea. Anything else in the base system that was so : old and little used, would have been pushed to ports a long time ago. Agreed. The make buildworld stuff is slowed down by a whole minute :-) Seriously, except for fortune there's nothing in /usr/games that gets used enough to warrant its inclusion in the base system, except for sentimental reasons. Hey, what's this uucp stuff? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 14:36:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C598B37B491; Thu, 15 Feb 2001 14:36:17 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1FMaHW11860; Thu, 15 Feb 2001 15:36:17 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102152236.f1FMaHW11860@harmony.village.org> To: freebsd-arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Feb 2001 13:54:37 PST." <20010215135437.A3838@dragon.nuxi.com> References: <20010215135437.A3838@dragon.nuxi.com> <200102151834.f1FIXv941778@gratis.grondar.za> Date: Thu, 15 Feb 2001 15:36:17 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010215135437.A3838@dragon.nuxi.com> "David O'Brien" writes: : On Thu, Feb 15, 2001 at 08:34:33PM +0200, Mark Murray wrote: : > I have coarsely cateogorised the games in src/games into broad : > groups - adventure/strategy, board/card, novelty, quiz, arcade and : > utility. : ... : > I'd like to turn each category into a port (ports/games/bsd-adventure : > for example), with the exception of "utility"). Those, I'd like : > to keep where they are. : : : I fully support this idea. Anything else in the base system that was so : old and little used, would have been pushed to ports a long time ago. Agreed. The make buildworld stuff is slowed down by a whole minute :-) Seriously, except for fortune there's nothing in /usr/games that gets used enough to warrant its inclusion in the base system, except for sentimental reasons. Hey, what's this uucp stuff? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 14:43:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D39F837B491 for ; Thu, 15 Feb 2001 14:42:56 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1FMgsW11899 for ; Thu, 15 Feb 2001 15:42:56 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102152242.f1FMgsW11899@harmony.village.org> To: arch@freebsd.org Subject: Step 1 and 2 patch Date: Thu, 15 Feb 2001 15:42:54 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK. This appears to work for me. I can run ports and other things with these changes. I'm submitting them for review. Please note, that this does *NOT* help us with the sizeof FILE being encoded into the binaries, yet. That's stage 3 and further. This just gets the tree working again with enough "headroom" for us to develop and review a change that will get us out from under this issue. We do need to fix this problem, but not right now and not by breaking the tree for days at a time. And not by requiring all libraries to have their major numbers bumped. Sorry to be blunt here, but I'm feeling nibbled to death by the "what about donig this or that" folks that aren't producing code that works. My frustration is showing through. Since the patch is only 200 lines, I've included it here. It is a slightly fixed up version of the patch that Brian posted here earlier and tries to minimize the grossness. I plan on committing this tomorrow morning. I'll be on IRC later today. Pass the word to interested parties. Warner Index: include/stdio.h =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/include/stdio.h,v retrieving revision 1.29 diff -u -r1.29 stdio.h --- include/stdio.h 2001/02/14 05:00:19 1.29 +++ include/stdio.h 2001/02/15 17:50:52 @@ -70,6 +70,12 @@ struct __file_lock; +/* hold a buncha junk that would grow the ABI */ +struct __sFILEX { + struct __file_lock *_mtlock; /* used for MT-safety */ + unsigned char *_up; /* saved _p when _p is doing ungetc data */ +}; + /* * stdio state variables. * @@ -114,7 +120,7 @@ /* separate buffer for long sequences of ungetc() */ struct __sbuf _ub; /* ungetc buffer */ - unsigned char *_up; /* saved _p when _p is doing ungetc data */ + struct __sFILEX *_extra; /* additions to FILE to not break ABI */ int _ur; /* saved _r when _r is counting ungetc data */ /* tricks to meet minimum requirements even when malloc() fails */ @@ -127,13 +133,10 @@ /* Unix stdio files get aligned to block boundaries on fseek() */ int _blksize; /* stat.st_blksize (may be != _bf._size) */ fpos_t _offset; /* current lseek offset (see WARNING) */ - struct __file_lock *_lock; /* used for MT-safety */ } FILE; __BEGIN_DECLS -extern FILE __stdin; -extern FILE __stdout; -extern FILE __stderr; +extern FILE __sF[]; __END_DECLS #define __SLBF 0x0001 /* line buffered */ @@ -196,9 +199,9 @@ #define SEEK_END 2 /* set file offset to EOF plus offset */ #endif -#define stdin (&__stdin) -#define stdout (&__stdout) -#define stderr (&__stderr) +#define stdin (&__sF[0]) +#define stdout (&__sF[1]) +#define stderr (&__sF[2]) /* * Functions defined in ANSI C standard. Index: lib/libc/Makefile =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/Makefile,v retrieving revision 1.29 diff -u -r1.29 Makefile --- lib/libc/Makefile 2001/02/14 05:00:20 1.29 +++ lib/libc/Makefile 2001/02/15 07:23:29 @@ -7,7 +7,7 @@ # from CFLAGS below. To remove these strings from just the system call # stubs, remove just -DSYSLIBC_RCS from CFLAGS. LIB=c -SHLIB_MAJOR= 5.20010213 +SHLIB_MAJOR= 5 SHLIB_MINOR= 0 CFLAGS+=-DLIBC_RCS -DSYSLIBC_RCS -I${.CURDIR}/include AINC= -I${.CURDIR}/${MACHINE_ARCH} Index: lib/libc/stdio/_flock_stub.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/_flock_stub.c,v retrieving revision 1.5 diff -u -r1.5 _flock_stub.c --- lib/libc/stdio/_flock_stub.c 2001/02/11 22:06:39 1.5 +++ lib/libc/stdio/_flock_stub.c 2001/02/15 20:31:21 @@ -68,6 +68,16 @@ }; /* + * We need to retain binary compatibility for a while. So pretend + * that _lock is part of FILE * even though it is dereferenced off + * _extra now. When we stop encoding the size of FILE into binaries + * this can be changed in stdio.h. This will reduce the amount of + * code that has to change in the future (just remove this comment + * and #define). + */ +#define _lock _extra->_mtlock + +/* * Allocate and initialize a file lock. */ static int Index: lib/libc/stdio/findfp.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/findfp.c,v retrieving revision 1.13 diff -u -r1.13 findfp.c --- lib/libc/stdio/findfp.c 2001/02/14 05:00:20 1.13 +++ lib/libc/stdio/findfp.c 2001/02/15 16:29:55 @@ -59,21 +59,22 @@ #define NDYNAMIC 10 /* add ten more whenever necessary */ -#define std(handle, flags, file) \ -FILE handle = {0,0,0,flags,file,{0},0,&handle,__sclose,__sread,__sseek,__swrite} -/* p r w flags file _bf z cookie close read seek write */ - +#define std(flags, file) \ + {0,0,0,flags,file,{0},0,__sF+file,__sclose,__sread,__sseek,__swrite, __sFX + file} +/* p r w flags file _bf z cookie close read seek write extra*/ /* the usual - (stdin + stdout + stderr) */ static FILE usual[FOPEN_MAX - 3]; static struct glue uglue = { NULL, FOPEN_MAX - 3, usual }; + +static struct __sFILEX __sFX[3]; + +FILE __sF[3] = { + std(__SRD, STDIN_FILENO), + std(__SWR, STDOUT_FILENO), + std(__SWR|__SNBF, STDERR_FILENO) +}; -std(__stdin, __SRD, STDIN_FILENO); -std(__stdout, __SWR, STDOUT_FILENO); -std(__stderr, __SWR|__SNBF, STDERR_FILENO); - -static struct glue sglue2 = { &uglue, 1, &__stderr }; -static struct glue sglue1 = { &sglue2, 1, &__stdout }; -struct glue __sglue = { &sglue1, 1, &__stdin }; +struct glue __sglue = { &uglue, 3, __sF }; static struct glue *lastglue = &uglue; static struct glue * moreglue __P((int)); @@ -93,18 +94,26 @@ int n; { struct glue *g; - FILE *p; static FILE empty; + static struct __sFILEX emptyx; + FILE *p; + struct __sFILEX *fx; - g = (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * sizeof(FILE)); + g = (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * sizeof(FILE) + + n * sizeof(struct __sFILEX)); if (g == NULL) return (NULL); p = (FILE *)ALIGN(g + 1); + fx = (struct __sFILEX *)&p[n]; g->next = NULL; g->niobs = n; g->iobs = p; - while (--n >= 0) - *p++ = empty; + while (--n >= 0) { + *p = empty; + p->_extra = fx; + *p->_extra = emptyx; + p++, fx++; + } return (g); } Index: lib/libc/stdio/fseek.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/fseek.c,v retrieving revision 1.10 diff -u -r1.10 fseek.c --- lib/libc/stdio/fseek.c 2001/01/24 13:00:45 1.10 +++ lib/libc/stdio/fseek.c 2001/02/15 07:16:26 @@ -204,7 +204,7 @@ */ if (HASUB(fp)) { curoff += fp->_r; /* kill off ungetc */ - n = fp->_up - fp->_bf._base; + n = fp->_extra->_up - fp->_bf._base; curoff -= n; n += fp->_ur; } else { Index: lib/libc/stdio/refill.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/refill.c,v retrieving revision 1.10 diff -u -r1.10 refill.c --- lib/libc/stdio/refill.c 2001/02/11 22:06:42 1.10 +++ lib/libc/stdio/refill.c 2001/02/15 07:16:26 @@ -109,7 +109,7 @@ if (HASUB(fp)) { FREEUB(fp); if ((fp->_r = fp->_ur) != 0) { - fp->_p = fp->_up; + fp->_p = fp->_extra->_up; return (0); } } Index: lib/libc/stdio/ungetc.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/ungetc.c,v retrieving revision 1.8 diff -u -r1.8 ungetc.c --- lib/libc/stdio/ungetc.c 2001/01/24 13:00:47 1.8 +++ lib/libc/stdio/ungetc.c 2001/02/15 07:16:26 @@ -164,7 +164,7 @@ * Initially, we will use the `reserve' buffer. */ fp->_ur = fp->_r; - fp->_up = fp->_p; + fp->_extra->_up = fp->_p; fp->_ub._base = fp->_ubuf; fp->_ub._size = sizeof(fp->_ubuf); fp->_ubuf[sizeof(fp->_ubuf) - 1] = c; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 14:59:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id AD44437B401 for ; Thu, 15 Feb 2001 14:59:43 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1FMxgW12025 for ; Thu, 15 Feb 2001 15:59:43 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102152259.f1FMxgW12025@harmony.village.org> Subject: Re: Step 1 and 2 patch Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Feb 2001 15:42:54 MST." <200102152242.f1FMgsW11899@harmony.village.org> References: <200102152242.f1FMgsW11899@harmony.village.org> Date: Thu, 15 Feb 2001 15:59:42 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102152242.f1FMgsW11899@harmony.village.org> Warner Losh writes: : OK. This appears to work for me. I can run ports and other things : with these changes. I'm submitting them for review. % ls | sort sort in free(): error: junk pointer, too high to make sense. Abort(core dumped) % gdb sort sort.core: (gdb) where #0 0x280a89c8 in kill () from /usr/lib/libc.so.5 #1 0x280e8ce6 in abort () from /usr/lib/libc.so.5 #2 0x280e7869 in isatty () from /usr/lib/libc.so.5 #3 0x280e7895 in isatty () from /usr/lib/libc.so.5 #4 0x280e871e in isatty () from /usr/lib/libc.so.5 #5 0x280e898d in free () from /usr/lib/libc.so.5 #6 0x280d760d in __srefill () from /usr/lib/libc.so.5 #7 0x280d20e9 in fread () from /usr/lib/libc.so.5 #8 0x804950d in free () #9 0x804b520 in free () #10 0x804c4c7 in free () #11 0x8048d7d in free () (gdb) quit So maybe we aren't there yet. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 15: 0:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 59F3037B401 for ; Thu, 15 Feb 2001 15:00:48 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1FN0lF08312 for freebsd-arch@FreeBSD.ORG; Thu, 15 Feb 2001 15:00:47 -0800 (PST) (envelope-from obrien) Date: Thu, 15 Feb 2001 15:00:47 -0800 From: "David O'Brien" To: freebsd-arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again Message-ID: <20010215150047.C3838@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20010215135437.A3838@dragon.nuxi.com> <200102151834.f1FIXv941778@gratis.grondar.za> <20010215135437.A3838@dragon.nuxi.com> <200102152236.f1FMaHW11860@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102152236.f1FMaHW11860@harmony.village.org>; from imp@harmony.village.org on Thu, Feb 15, 2001 at 03:36:17PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 15, 2001 at 03:36:17PM -0700, Warner Losh wrote: > Seriously, except for fortune there's nothing in /usr/games that > gets used enough to warrant its inclusion in the base system, except > for sentimental reasons. Acutally a few things are used in `make world'. Some of these are in Mark's U list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 15:21:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 41A7137B491 for ; Thu, 15 Feb 2001 15:21:09 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1FNL8W12194 for ; Thu, 15 Feb 2001 16:21:08 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102152321.f1FNL8W12194@harmony.village.org> Subject: Re: Step 1 and 2 patch Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Feb 2001 15:42:54 MST." <200102152242.f1FMgsW11899@harmony.village.org> References: <200102152242.f1FMgsW11899@harmony.village.org> Date: Thu, 15 Feb 2001 16:21:08 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102152242.f1FMgsW11899@harmony.village.org> Warner Losh writes: : OK. This appears to work for me. I can run ports and other things : with these changes. I'm submitting them for review. Actually, this does *NOT* work for me. Do NOT try to use this or you will mess up your system in many small, but frustrating, ways. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 16:17:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 0D42137B684; Thu, 15 Feb 2001 16:17:03 -0800 (PST) Received: from jehovah ([24.202.203.190]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G8TQ4601.9YZ; Thu, 15 Feb 2001 19:16:54 -0500 Message-ID: <002701c097ae$11abf680$becbca18@jehovah> From: "Bosko Milekic" To: "Jean-Marc Zucconi" , "Mark Murray" Cc: References: <200102151834.f1FIXv941778@gratis.grondar.za> <200102151910.f1FJApM59398@freefall.freebsd.org> Subject: Re: The /usr/bin/games bikeshed again Date: Thu, 15 Feb 2001 19:19:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jean-Marc Zucconi wrote: > >>>>> Mark Murray writes: > > > I'd like to turn each category into a port (ports/games/bsd-adventure > > for example), with the exception of "utility"). Those, I'd like > > to keep where they are. In that class ("utility") is everyone's > > favourite - fortune, so that should deal with most of the fears > > from last time :-). > > I prefer to move *all* the games to ports, including the "utility" > ones. If one one them is really useful, then it should be in /usr/bin. > > > Fortune does not belong to any "utility" category. > Mais oui, it does! Remember: fortune is not a game. It's a way of life. :-) > Jean-Marc > > -- > Jean-Marc Zucconi -- PGP Key: finger jmz@FreeBSD.org [KeyID: 400B38E9] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 16:35: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id ACDCF37B503 for ; Thu, 15 Feb 2001 16:35:06 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id RAA07233; Thu, 15 Feb 2001 17:29:36 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAi4ayfo; Thu Feb 15 17:29:25 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA11196; Thu, 15 Feb 2001 17:34:52 -0700 (MST) From: Terry Lambert Message-Id: <200102160034.RAA11196@usr08.primenet.com> Subject: Re: The whole libc thing. To: eischen@vigrid.com (Daniel Eischen) Date: Fri, 16 Feb 2001 00:34:51 +0000 (GMT) Cc: imp@village.org (Warner Losh), arch@FreeBSD.ORG In-Reply-To: from "Daniel Eischen" at Feb 15, 2001 01:14:44 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > : Let's just bump the libraries and be done with it. > > > > That's *ALL* the libraries, even in ports? > > Hmm, perhaps not then. It would be nice to get rid of __sF; if we > don't do it now, will we ever? While you are at it, break out libresolv, even if you end up linking libc.so against libresolv.so, so that programs won't notice. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 17:20:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 11AEC37B4EC for ; Thu, 15 Feb 2001 17:20:16 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1G1KCW56176 for ; Thu, 15 Feb 2001 18:20:15 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102160120.f1G1KCW56176@harmony.village.org> To: arch@freebsd.org Subject: Updated diffs Date: Thu, 15 Feb 2001 18:20:12 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel came up with a hint that allowed me to fix. I'd changed green's patches to change the FILE layout. This caused problems with initialziation in the std macro, which lead to the problem. Sorry Green. This seems to work for me. ls | sort works now. Other indications are that it is working. Warner Index: include/stdio.h =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/include/stdio.h,v retrieving revision 1.29 diff -u -r1.29 stdio.h --- include/stdio.h 2001/02/14 05:00:19 1.29 +++ include/stdio.h 2001/02/15 17:50:52 @@ -70,6 +70,12 @@ struct __file_lock; +/* hold a buncha junk that would grow the ABI */ +struct __sFILEX { + struct __file_lock *_mtlock; /* used for MT-safety */ + unsigned char *_up; /* saved _p when _p is doing ungetc data */ +}; + /* * stdio state variables. * @@ -114,7 +120,7 @@ /* separate buffer for long sequences of ungetc() */ struct __sbuf _ub; /* ungetc buffer */ - unsigned char *_up; /* saved _p when _p is doing ungetc data */ + struct __sFILEX *_extra; /* additions to FILE to not break ABI */ int _ur; /* saved _r when _r is counting ungetc data */ /* tricks to meet minimum requirements even when malloc() fails */ @@ -127,13 +133,10 @@ /* Unix stdio files get aligned to block boundaries on fseek() */ int _blksize; /* stat.st_blksize (may be != _bf._size) */ fpos_t _offset; /* current lseek offset (see WARNING) */ - struct __file_lock *_lock; /* used for MT-safety */ } FILE; __BEGIN_DECLS -extern FILE __stdin; -extern FILE __stdout; -extern FILE __stderr; +extern FILE __sF[]; __END_DECLS #define __SLBF 0x0001 /* line buffered */ @@ -196,9 +199,9 @@ #define SEEK_END 2 /* set file offset to EOF plus offset */ #endif -#define stdin (&__stdin) -#define stdout (&__stdout) -#define stderr (&__stderr) +#define stdin (&__sF[0]) +#define stdout (&__sF[1]) +#define stderr (&__sF[2]) /* * Functions defined in ANSI C standard. Index: lib/libc/Makefile =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/Makefile,v retrieving revision 1.29 diff -u -r1.29 Makefile --- lib/libc/Makefile 2001/02/14 05:00:20 1.29 +++ lib/libc/Makefile 2001/02/15 07:23:29 @@ -7,7 +7,7 @@ # from CFLAGS below. To remove these strings from just the system call # stubs, remove just -DSYSLIBC_RCS from CFLAGS. LIB=c -SHLIB_MAJOR= 5.20010213 +SHLIB_MAJOR= 5 SHLIB_MINOR= 0 CFLAGS+=-DLIBC_RCS -DSYSLIBC_RCS -I${.CURDIR}/include AINC= -I${.CURDIR}/${MACHINE_ARCH} Index: lib/libc/stdio/_flock_stub.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/_flock_stub.c,v retrieving revision 1.5 diff -u -r1.5 _flock_stub.c --- lib/libc/stdio/_flock_stub.c 2001/02/11 22:06:39 1.5 +++ lib/libc/stdio/_flock_stub.c 2001/02/15 20:31:21 @@ -68,6 +68,16 @@ }; /* + * We need to retain binary compatibility for a while. So pretend + * that _lock is part of FILE * even though it is dereferenced off + * _extra now. When we stop encoding the size of FILE into binaries + * this can be changed in stdio.h. This will reduce the amount of + * code that has to change in the future (just remove this comment + * and #define). + */ +#define _lock _extra->_mtlock + +/* * Allocate and initialize a file lock. */ static int Index: lib/libc/stdio/findfp.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/findfp.c,v retrieving revision 1.13 diff -u -r1.13 findfp.c --- lib/libc/stdio/findfp.c 2001/02/14 05:00:20 1.13 +++ lib/libc/stdio/findfp.c 2001/02/16 00:35:43 @@ -59,21 +59,24 @@ #define NDYNAMIC 10 /* add ten more whenever necessary */ -#define std(handle, flags, file) \ -FILE handle = {0,0,0,flags,file,{0},0,&handle,__sclose,__sread,__sseek,__swrite} -/* p r w flags file _bf z cookie close read seek write */ - +#define std(flags, file) \ + {0,0,0,flags,file,{0},0,__sF+file,__sclose,__sread,__sseek,__swrite, \ + {0}, __sFX + file} + /* p r w flags file _bf z cookie close read seek write */ + /* _ub _extra */ /* the usual - (stdin + stdout + stderr) */ static FILE usual[FOPEN_MAX - 3]; static struct glue uglue = { NULL, FOPEN_MAX - 3, usual }; + +static struct __sFILEX __sFX[3]; + +FILE __sF[3] = { + std(__SRD, STDIN_FILENO), + std(__SWR, STDOUT_FILENO), + std(__SWR|__SNBF, STDERR_FILENO) +}; -std(__stdin, __SRD, STDIN_FILENO); -std(__stdout, __SWR, STDOUT_FILENO); -std(__stderr, __SWR|__SNBF, STDERR_FILENO); - -static struct glue sglue2 = { &uglue, 1, &__stderr }; -static struct glue sglue1 = { &sglue2, 1, &__stdout }; -struct glue __sglue = { &sglue1, 1, &__stdin }; +struct glue __sglue = { &uglue, 3, __sF }; static struct glue *lastglue = &uglue; static struct glue * moreglue __P((int)); @@ -93,18 +96,26 @@ int n; { struct glue *g; - FILE *p; static FILE empty; + static struct __sFILEX emptyx; + FILE *p; + struct __sFILEX *fx; - g = (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * sizeof(FILE)); + g = (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * sizeof(FILE) + + n * sizeof(struct __sFILEX)); if (g == NULL) return (NULL); p = (FILE *)ALIGN(g + 1); + fx = (struct __sFILEX *)&p[n]; g->next = NULL; g->niobs = n; g->iobs = p; - while (--n >= 0) - *p++ = empty; + while (--n >= 0) { + *p = empty; + p->_extra = fx; + *p->_extra = emptyx; + p++, fx++; + } return (g); } Index: lib/libc/stdio/fseek.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/fseek.c,v retrieving revision 1.10 diff -u -r1.10 fseek.c --- lib/libc/stdio/fseek.c 2001/01/24 13:00:45 1.10 +++ lib/libc/stdio/fseek.c 2001/02/15 07:16:26 @@ -204,7 +204,7 @@ */ if (HASUB(fp)) { curoff += fp->_r; /* kill off ungetc */ - n = fp->_up - fp->_bf._base; + n = fp->_extra->_up - fp->_bf._base; curoff -= n; n += fp->_ur; } else { Index: lib/libc/stdio/refill.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/refill.c,v retrieving revision 1.10 diff -u -r1.10 refill.c --- lib/libc/stdio/refill.c 2001/02/11 22:06:42 1.10 +++ lib/libc/stdio/refill.c 2001/02/15 07:16:26 @@ -109,7 +109,7 @@ if (HASUB(fp)) { FREEUB(fp); if ((fp->_r = fp->_ur) != 0) { - fp->_p = fp->_up; + fp->_p = fp->_extra->_up; return (0); } } Index: lib/libc/stdio/ungetc.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/ungetc.c,v retrieving revision 1.8 diff -u -r1.8 ungetc.c --- lib/libc/stdio/ungetc.c 2001/01/24 13:00:47 1.8 +++ lib/libc/stdio/ungetc.c 2001/02/15 07:16:26 @@ -164,7 +164,7 @@ * Initially, we will use the `reserve' buffer. */ fp->_ur = fp->_r; - fp->_up = fp->_p; + fp->_extra->_up = fp->_p; fp->_ub._base = fp->_ubuf; fp->_ub._size = sizeof(fp->_ubuf); fp->_ubuf[sizeof(fp->_ubuf) - 1] = c; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 18:25: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 40BB337B401 for ; Thu, 15 Feb 2001 18:24:57 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f1G2OBk16690; Fri, 16 Feb 2001 02:24:11 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.1) with ESMTP id f1G2PFw09227; Fri, 16 Feb 2001 02:25:15 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Warner Losh Cc: arch@freebsd.org, brian@Awfulhak.org Subject: Re: The whole libc thing. In-Reply-To: Message from Warner Losh of "Thu, 15 Feb 2001 09:04:45 MST." <200102151604.f1FG4jW62156@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 02:25:15 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.....] > Step 5: > Bump the major version of libc and start using something like > peter's change. Step 5.1: Bump the version number on all libraries that don't contain a dependency on libc but contain __sF references. And I'm sure there are other horrors there... For example: cd /usr/local/lib for f in lib*.so.* do objdump -x $f | fgrep NEEDED | fgrep -q libc.so. || nm $f | fgrep -wq __sF && echo $f done Produces a list of 23 libraries (out of 54) on my laptop :-( Tell me if I'm wrong, but I believe these libraries contain no indication of what libc they want, but may be mucking about with stdio internals... I think step 5 can't happen 'till we declare declare a D-day after which old binaries and libraries just won't work. I also can't think of any way to soften the blow. At the end of the day, there are binaries out there that not only know the size of sF, but they also play with the internals directly. Binary support of this without some currently-unused-internal-changed-to-a-pointer kludge is unlikely AFAICT. > Warner -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 19:19:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D0A9837B491 for ; Thu, 15 Feb 2001 19:19:33 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.2/8.11.0) with ESMTP id f1G3JSh35302; Thu, 15 Feb 2001 20:19:28 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f1G3HqE26659; Thu, 15 Feb 2001 20:17:52 -0700 (MST) Message-Id: <200102160317.f1G3HqE26659@billy-club.village.org> To: Brian Somers Subject: Re: The whole libc thing. Cc: arch@freebsd.org In-reply-to: Your message of "Fri, 16 Feb 2001 02:25:15 GMT." <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> References: <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> Date: Thu, 15 Feb 2001 20:17:51 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> Brian Somers writes: : Step 5.1: : Bump the version number on all libraries that don't contain : a dependency on libc but contain __sF references. Umm, that can't happen. __sF is a libc dependency by definition. stdio lives in libc. : Produces a list of 23 libraries (out of 54) on my laptop :-( Tell me : if I'm wrong, but I believe these libraries contain no indication of : what libc they want, but may be mucking about with stdio internals... That's right. That's the problem. Actually, none of them are mucking with the internals of libc. They just know that __sF[0] is stdin, __sF[1] is stdout, etc. They know the size of FILE. That's bad. However, the only way these will break is for new compiles after we bump the libc version. Old binaries linked against them will continue to work. Barring kernel dependencies, new libraries will continue to work with old binaries if you update libc as I describe below. : I think step 5 can't happen 'till we declare declare a D-day after : which old binaries and libraries just won't work. That's half right. We don't need to declare D-day and make things not work. There's a solution to that. : I also can't think of any way to soften the blow. At the end of the : day, there are binaries out there that not only know the size of sF, : but they also play with the internals directly. Binary support of : this without some currently-unused-internal-changed-to-a-pointer : kludge is unlikely AFAICT. Programs that play with the internals of stdio are few and far between these days. Too many different ones :-) The problems come up when we're trying to introduce new symbols. If we do it smartly, and give users a transition time to rebuild (say 3-6 months), then we'll be be able to make this transition mostly seamless. The solution to all this mess is to sit tight. I know people hate doing that, but those people will have to cope for a while. Here's what I propose after my patches go into the tree: 1) We introduce some assembler or other magic that will alias __stdin to __sF[0], __stdout to __sF[1], etc being careful to preserve the size of FILE, and the __sF array. 2) We introduce this assembler to all ELF RELENG branches. This is just RELENG_3 and RELENG_4 and current, so it isn't as bad as it sounds. 3) We wait a while. 4) We bump libc.so.5 to libc.so.5.20010501 or something like that. At this stage, we make __std* ala peter's changes and start generating binaries with __std* references. These will work with the old and the new libc, since the size of __sF isn't encoded into the binary. This means that old binaries with slightly fixed old libc will continue to work. The reason we wait a while is to give people a chance to upgrade their libc.so.3 and libc.so.4 libraries. If they do this, or if we have the "fixed" libraries in compat, then the old binaries will just continue to work. Why you ask? Well, new libraries will have __std* in them. What is breaking things right now is that the old binaries were linking against libc.so.OLD which doesn't have the __std* symbols. If we add them to the old libraries as aliases, things will work as before. Maybe even "better" because the new shared libraries won't have __sF encoded into them. The old binaries will still have __sF encoded into them, but that's OK because they will be using a library that matches. The only wrinkle in all of this is old libraries and fresh builds after libc's version is bumped. They will break because they will have __sF in them. We've had this sort of problem before, and can tell people in those cases they will have to rebuild the libraries. When they rebuild the libraries, they will be abled to be linked with old and new libc and they won't even have to recompile their old binaries, just the old libraries. Warner P.S. I think that the following assembler would work for this on i386. Alpha might be different and the only other port to worry about. I might have an indirection error in here somewhere. .data .globl __stdin .p2align 2 .type __stdin, @object .size __stdin,4 __stdin: .long __sF .globl __stdout .p2align 2 .type __stdout, @object .size __stdout,4 __stdout: .long __sF+88 .globl __stderr .p2align 2 .type __stderr, @object .size __stderr,4 __stderr .long __sF+176 At least that's what my test program tells me: #include extern FILE *__stdin; extern FILE *__stdout; extern FILE *__stderr; int main(int argc, char **argv) { printf("stdin %p %p\n", stdin, __stdin); printf("stdout %p %p\n", stdout, __stdout); printf("stderr %p %p\n", stderr, __stderr); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 19:34:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 94DE637B401; Thu, 15 Feb 2001 19:34:27 -0800 (PST) Received: from localhost (w2a9ia@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f1G3YPA23124; Thu, 15 Feb 2001 22:34:25 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200102160334.f1G3YPA23124@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: Warner Losh , arch@FreeBSD.org Subject: Re: The whole libc thing. In-Reply-To: Message from Brian Somers of "Fri, 16 Feb 2001 02:25:15 GMT." <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Feb 2001 22:34:24 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers wrote: > [.....] > > Step 5: > > Bump the major version of libc and start using something like > > peter's change. > > Step 5.1: > Bump the version number on all libraries that don't contain > a dependency on libc but contain __sF references. > > And I'm sure there are other horrors there... > > > For example: > > cd /usr/local/lib > for f in lib*.so.* > do > objdump -x $f | fgrep NEEDED | fgrep -q libc.so. || > nm $f | fgrep -wq __sF && echo $f > done > > Produces a list of 23 libraries (out of 54) on my laptop :-( Tell me > if I'm wrong, but I believe these libraries contain no indication of > what libc they want, but may be mucking about with stdio internals... > > I think step 5 can't happen 'till we declare declare a D-day after > which old binaries and libraries just won't work. > > I also can't think of any way to soften the blow. At the end of the > day, there are binaries out there that not only know the size of sF, > but they also play with the internals directly. Binary support of > this without some currently-unused-internal-changed-to-a-pointer > kludge is unlikely AFAICT. I change my mind. I'll keep everything in the same place but the _up. An application, even a gross one that tries to touch all inside FILE, still shouldn't be touching the most private parts of it. (Sounds so sick, doesn't it? It is.) That won't break e.g. libftpio and sendmail (bf_torek.c), at least. *sigh* Those need to be rewritten, of course, really.... -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 19:47:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 48D1537B491 for ; Thu, 15 Feb 2001 19:47:23 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f1G3klk48574; Fri, 16 Feb 2001 03:46:47 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.1) with ESMTP id f1G3lmw10596; Fri, 16 Feb 2001 03:47:49 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102160347.f1G3lmw10596@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Warner Losh Cc: Brian Somers , arch@freebsd.org, brian@Awfulhak.org Subject: Re: The whole libc thing. In-Reply-To: Message from Warner Losh of "Thu, 15 Feb 2001 20:17:51 MST." <200102160317.f1G3HqE26659@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 03:47:48 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > That's right. That's the problem. Actually, none of them are mucking > with the internals of libc. They just know that __sF[0] is stdin, > __sF[1] is stdout, etc. They know the size of FILE. That's bad. [.....] > Programs that play with the internals of stdio are few and far between > these days. Too many different ones :-) Programs use macros, but on a binary level they're still playing with the internals.... > The problems come up when we're trying to introduce new symbols. If > we do it smartly, and give users a transition time to rebuild (say 3-6 > months), then we'll be be able to make this transition mostly > seamless. Ok, that I understand. You're aiming for an intermediate period where you make binaries ``better able to cope with things being changed''. This is the idea behind using __stdxxx rather than sF[0-2]. > The solution to all this mess is to sit tight. I know people hate > doing that, but those people will have to cope for a while. > > Here's what I propose after my patches go into the tree: > 1) We introduce some assembler or other magic that will alias > __stdin to __sF[0], __stdout to __sF[1], etc being > careful to preserve the size of FILE, and the __sF array. > 2) We introduce this assembler to all ELF RELENG branches. > This is just RELENG_3 and RELENG_4 and current, so it isn't > as bad as it sounds. > 3) We wait a while. Ok, so we've now got a bunch of machines out there that have mostly got binaries that can survive into the future. > 4) We bump libc.so.5 to libc.so.5.20010501 or something like > that. At this stage, we make __std* ala peter's changes > and start generating binaries with __std* references. > These will work with the old and the new libc, since > the size of __sF isn't encoded into the binary. This means > that old binaries with slightly fixed old libc will > continue to work. Right, but binaries from before your first commit (1 above) are potentially dead in the water - (yep, you already know this, but this is my concern -- see below). > The reason we wait a while is to give people a chance to upgrade their > libc.so.3 and libc.so.4 libraries. If they do this, or if we have the > "fixed" libraries in compat, then the old binaries will just continue > to work. > > Why you ask? Well, new libraries will have __std* in them. What is > breaking things right now is that the old binaries were linking > against libc.so.OLD which doesn't have the __std* symbols. If we add > them to the old libraries as aliases, things will work as before. > Maybe even "better" because the new shared libraries won't have __sF > encoded into them. The old binaries will still have __sF encoded into > them, but that's OK because they will be using a library that matches. > > The only wrinkle in all of this is old libraries and fresh builds > after libc's version is bumped. They will break because they will > have __sF in them. We've had this sort of problem before, and can > tell people in those cases they will have to rebuild the libraries. > When they rebuild the libraries, they will be abled to be linked with > old and new libc and they won't even have to recompile their old > binaries, just the old libraries. Ah, ok, so you have thought of that :-) That was my concern - that there are libraries running around that use __sF and don't have a NEEDED libc.so.something in them (I'm not sure if this is a linker bug - I'm assuming it is). I don't get the bit about the old binaries not needing to be rebuilt. Surely they're still going to have references to __sF sizes *AND* are potentially going to use one or more of these horrible libraries without the NEEDED libc.so.something that have now been rebuilt and are doiking about with the new-improved FILE. When the old app gets ldd involved, we end up with the old binary, the old libc and the new other-library-without-the-NEEDED-bit, which is going to fail to all link together at run time :-( I must say, I've never understood why libraries end up with external references to other libraries, but no idea about the version numbers of those other libraries. This seems to be ``just wrong''. > Warner [__std* setup examples elided] -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 19:59:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3E8A737B503 for ; Thu, 15 Feb 2001 19:59:41 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1G3wrW56778; Thu, 15 Feb 2001 20:58:53 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102160358.f1G3wrW56778@harmony.village.org> To: Brian Somers Subject: Re: The whole libc thing. Cc: arch@freebsd.org In-reply-to: Your message of "Fri, 16 Feb 2001 03:47:48 GMT." <200102160347.f1G3lmw10596@hak.lan.Awfulhak.org> References: <200102160347.f1G3lmw10596@hak.lan.Awfulhak.org> Date: Thu, 15 Feb 2001 20:58:53 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102160347.f1G3lmw10596@hak.lan.Awfulhak.org> Brian Somers writes: : > That's right. That's the problem. Actually, none of them are mucking : > with the internals of libc. They just know that __sF[0] is stdin, : > __sF[1] is stdout, etc. They know the size of FILE. That's bad. : [.....] : > Programs that play with the internals of stdio are few and far between : > these days. Too many different ones :-) : : Programs use macros, but on a binary level they're still playing with : the internals.... Yes. I understand that. Which is why FILE is still in the same order and can only ever grow in size. Brian Feldman was smart to pick _up. : > The problems come up when we're trying to introduce new symbols. If : > we do it smartly, and give users a transition time to rebuild (say 3-6 : > months), then we'll be be able to make this transition mostly : > seamless. : : Ok, that I understand. You're aiming for an intermediate period : where you make binaries ``better able to cope with things being : changed''. This is the idea behind using __stdxxx rather than : sF[0-2]. Yes. That's right. : Ok, so we've now got a bunch of machines out there that have mostly : got binaries that can survive into the future. Yes. And if they don't, they can easily be upgraded with a simple cp or pkg_install. : > 4) We bump libc.so.5 to libc.so.5.20010501 or something like : > that. At this stage, we make __std* ala peter's changes : > and start generating binaries with __std* references. : > These will work with the old and the new libc, since : > the size of __sF isn't encoded into the binary. This means : > that old binaries with slightly fixed old libc will : > continue to work. : : Right, but binaries from before your first commit (1 above) are : potentially dead in the water - (yep, you already know this, but this : is my concern -- see below). I don't understand this, so I'll draw a timeline and see if you can tell me what you are talking about: libc.so.3 ----- libc.so.4 ---- libc.so.5 ---- Feb 10 --- Today --- tomorrow 1 2 3 4 5 6 The only area that I know that binaries programs will be busted is the 4 - 5 period. The rest should be good to go with this, assuming that their libc can be updated with the latest cool bits. : Ah, ok, so you have thought of that :-) That was my concern - that : there are libraries running around that use __sF and don't have a : NEEDED libc.so.something in them (I'm not sure if this is a linker : bug - I'm assuming it is). There's no library version info, iirc. Even if there is, FreeBSD has the Highlander rule: There Can BE only One. : I don't get the bit about the old binaries not needing to be rebuilt. : Surely they're still going to have references to __sF sizes *AND* : are potentially going to use one or more of these horrible libraries : without the NEEDED libc.so.something that have now been rebuilt and : are doiking about with the new-improved FILE. When the old app gets : ldd involved, we end up with the old binary, the old libc and the new : other-library-without-the-NEEDED-bit, which is going to fail to all : link together at run time :-( old binaries use old libc.so.[34] by definition. ELF doesn't let you have two different libc's brought in. : I must say, I've never understood why libraries end up with external : references to other libraries, but no idea about the version numbers : of those other libraries. This seems to be ``just wrong''. : It is ELF. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 21:18: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 6296E37B491; Thu, 15 Feb 2001 21:17:58 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1G5Hk294086; Thu, 15 Feb 2001 21:17:46 -0800 (PST) (envelope-from dillon) Date: Thu, 15 Feb 2001 21:17:46 -0800 (PST) From: Matt Dillon Message-Id: <200102160517.f1G5Hk294086@earth.backplane.com> To: Warner Losh Cc: freebsd-arch@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again References: <20010215135437.A3838@dragon.nuxi.com> <200102151834.f1FIXv941778@gratis.grondar.za> <200102152236.f1FMaHW11860@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :: ... :: > I'd like to turn each category into a port (ports/games/bsd-adventure :: > for example), with the exception of "utility"). Those, I'd like :: > to keep where they are. :: :: :: I fully support this idea. Anything else in the base system that was so :: old and little used, would have been pushed to ports a long time ago. : :Agreed. The make buildworld stuff is slowed down by a whole minute ::-) Seriously, except for fortune there's nothing in /usr/games that :gets used enough to warrant its inclusion in the base system, except :for sentimental reasons. : :Hey, what's this uucp stuff? : :Warner /var/spool/uucppublic has been an eyesore to me for over 5 years now. Someone, PLEASE put it out of its misery! Or turn it into a port. Or something... maybe just shoot it :-) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 21:18: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 6296E37B491; Thu, 15 Feb 2001 21:17:58 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1G5Hk294086; Thu, 15 Feb 2001 21:17:46 -0800 (PST) (envelope-from dillon) Date: Thu, 15 Feb 2001 21:17:46 -0800 (PST) From: Matt Dillon Message-Id: <200102160517.f1G5Hk294086@earth.backplane.com> To: Warner Losh Cc: freebsd-arch@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again References: <20010215135437.A3838@dragon.nuxi.com> <200102151834.f1FIXv941778@gratis.grondar.za> <200102152236.f1FMaHW11860@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :: ... :: > I'd like to turn each category into a port (ports/games/bsd-adventure :: > for example), with the exception of "utility"). Those, I'd like :: > to keep where they are. :: :: :: I fully support this idea. Anything else in the base system that was so :: old and little used, would have been pushed to ports a long time ago. : :Agreed. The make buildworld stuff is slowed down by a whole minute ::-) Seriously, except for fortune there's nothing in /usr/games that :gets used enough to warrant its inclusion in the base system, except :for sentimental reasons. : :Hey, what's this uucp stuff? : :Warner /var/spool/uucppublic has been an eyesore to me for over 5 years now. Someone, PLEASE put it out of its misery! Or turn it into a port. Or something... maybe just shoot it :-) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 21:19:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 97E3637B4EC for ; Thu, 15 Feb 2001 21:19:55 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id QAA17553; Fri, 16 Feb 2001 16:19:52 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01K06N61HJCGO2JK6T@cim.alcatel.com.au>; Fri, 16 Feb 2001 16:19:44 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f1G5JnQ71157; Fri, 16 Feb 2001 16:19:49 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Fri, 16 Feb 2001 16:19:48 +1100 From: Peter Jeremy Subject: Re: The whole libc thing. In-reply-to: <200102160317.f1G3HqE26659@billy-club.village.org>; from imp@village.org on Thu, Feb 15, 2001 at 08:17:51PM -0700 To: Warner Losh Cc: arch@FreeBSD.ORG Mail-followup-to: Warner Losh , arch@FreeBSD.ORG Message-id: <20010216161948.B70642@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2001-Feb-15 20:17:51 -0700, Warner Losh wrote: >P.S. I think that the following assembler would work for this on >i386. Alpha might be different and the only other port to worry >about. I might have an indirection error in here somewhere. I think the same approach would work on the Alpha, but the sizes are different - according to my calculations, FILE is 64 bytes larger on an Alpha - 10 pointers @ 4 bytes larger and 24 bytes of padding. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 21:26:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6963237B491 for ; Thu, 15 Feb 2001 21:26:41 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1G5QVW57212; Thu, 15 Feb 2001 22:26:31 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102160526.f1G5QVW57212@harmony.village.org> To: Peter Jeremy Subject: Re: The whole libc thing. Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Feb 2001 16:19:48 +1100." <20010216161948.B70642@gsmx07.alcatel.com.au> References: <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> Date: Thu, 15 Feb 2001 22:26:31 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010216161948.B70642@gsmx07.alcatel.com.au> Peter Jeremy writes: : On 2001-Feb-15 20:17:51 -0700, Warner Losh wrote: : >P.S. I think that the following assembler would work for this on : >i386. Alpha might be different and the only other port to worry : >about. I might have an indirection error in here somewhere. : : I think the same approach would work on the Alpha, but the sizes are : different - according to my calculations, FILE is 64 bytes larger : on an Alpha - 10 pointers @ 4 bytes larger and 24 bytes of padding. Yes. The numbers would need to be different for the alpha. Also, the assembler I posted is wrong. I don't need a pointer to it, I need a weak or strong reference. Peter Wemm, Brian Feldman and I are hashing things out on IRC #bsdcode, but so far are wishing for a +3 helm of understanding, or 10 minutes of jpd time :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 21:29:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 88CF637B6A1 for ; Thu, 15 Feb 2001 21:29:23 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1G5TGW57238; Thu, 15 Feb 2001 22:29:16 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102160529.f1G5TGW57238@harmony.village.org> To: Peter Jeremy Subject: Re: The whole libc thing. Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Feb 2001 16:19:48 +1100." <20010216161948.B70642@gsmx07.alcatel.com.au> References: <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> Date: Thu, 15 Feb 2001 22:29:15 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010216161948.B70642@gsmx07.alcatel.com.au> Peter Jeremy writes: : On 2001-Feb-15 20:17:51 -0700, Warner Losh wrote: : >P.S. I think that the following assembler would work for this on : >i386. Alpha might be different and the only other port to worry : >about. I might have an indirection error in here somewhere. : : I think the same approach would work on the Alpha, but the sizes are : different - according to my calculations, FILE is 64 bytes larger : on an Alpha - 10 pointers @ 4 bytes larger and 24 bytes of padding. Also, __weak_reference(__sF,__stdin) works well, but __weak_reference(__sF+88,_stdout) works only in intel :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 22: 8:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 5540E37B491 for ; Thu, 15 Feb 2001 22:08:13 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1G67k944464; Fri, 16 Feb 2001 08:07:48 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102160607.f1G67k944464@gratis.grondar.za> To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again References: <200102160517.f1G5Hk294086@earth.backplane.com> In-Reply-To: <200102160517.f1G5Hk294086@earth.backplane.com> ; from Matt Dillon "Thu, 15 Feb 2001 21:17:46 PST." Date: Fri, 16 Feb 2001 08:08:17 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Hey, what's this uucp stuff? > : > :Warner > > /var/spool/uucppublic has been an eyesore to me for over 5 years now. > Someone, PLEASE put it out of its misery! Or turn it into a port. > Or something... maybe just shoot it :-) Next on my list :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 23: 9:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id A0D2C37B491; Thu, 15 Feb 2001 23:09:29 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 14Tf1D-0000WE-00; Fri, 16 Feb 2001 09:09:27 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id JAA07201; Fri, 16 Feb 2001 09:09:25 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 7074; Fri Feb 16 09:08:44 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 14Tf0W-000CXF-00; Fri, 16 Feb 2001 09:08:44 +0200 To: Robert Watson Cc: Ruslan Ermilov , arch@freebsd.org Subject: Re: [Call for *quick* review] architecture-specific manpages In-reply-to: Your message of "Thu, 15 Feb 2001 16:23:15 EST." Date: Fri, 16 Feb 2001 09:08:44 +0200 Message-ID: <48188.982307324@axl.fw.uunet.co.za> From: Sheldon Hearn Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001 16:23:15 EST, Robert Watson wrote: > I'd personally feel a lot more comfortable with all this if we'd simply > remove the setuid/setgid man'ness of man, and either pre-generate cached > pages as appropriate, or simply eschew caching, given the speed of modern > machines. Have you tried going without caching on a typical workstation that's actually doing work? Personally, I can feel the difference and find it annoying. :-( Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 23: 9:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5212237B491; Thu, 15 Feb 2001 23:09:56 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA30379; Fri, 16 Feb 2001 18:09:53 +1100 Date: Fri, 16 Feb 2001 18:09:25 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "Brian F. Feldman" Cc: Warner Losh , arch@FreeBSD.org Subject: Re: The whole libc thing. In-Reply-To: <200102151558.f1FFwLA21464@green.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001, Brian F. Feldman wrote: > My proposition wouldn't break any binary compatibility because it would keep > the FILE structure size the same. This isn't sufficient. fileno() and getc() used to be macros and/or inline functions that knew about the internals of the struct. > The actual contents are _not_ allowed to > be known outside of libc, so anything that gets it wrong after this change > deserves to break in many horrible ways. We don't need a hash lookup > because there is already a _very_ seldom-used field, _up, which can be > absorbed for this purpose. I initially thought _cookie was better, but Your patch works because (hopefully) the field is so seldom used that it wasn't used by the old macros. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 23:11:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id DD0D737B503; Thu, 15 Feb 2001 23:11:19 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 14Tf2z-0000YS-00; Fri, 16 Feb 2001 09:11:17 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id JAA07756; Fri, 16 Feb 2001 09:11:16 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 7501; Fri Feb 16 09:10:42 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 14Tf2Q-000CYg-00; Fri, 16 Feb 2001 09:10:42 +0200 To: freebsd-arch@freebsd.org Cc: arch@freebsd.org Subject: Re: The /usr/bin/games bikeshed again In-reply-to: Your message of "Thu, 15 Feb 2001 13:54:37 PST." <20010215135437.A3838@dragon.nuxi.com> Date: Fri, 16 Feb 2001 09:10:42 +0200 Message-ID: <48277.982307442@axl.fw.uunet.co.za> From: Sheldon Hearn Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001 13:54:37 PST, "David O'Brien" wrote: > I fully support this idea. Anything else in the base system that was so > old and little used, would have been pushed to ports a long time ago. In fact, at least one of the games should just be shot dead. The nethack we have in the games directory shouldn't be shifted across to ports, because a maintained version exists in the ports tree already (nethack3-tty). Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 23:11:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id DD0D737B503; Thu, 15 Feb 2001 23:11:19 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 14Tf2z-0000YS-00; Fri, 16 Feb 2001 09:11:17 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id JAA07756; Fri, 16 Feb 2001 09:11:16 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 7501; Fri Feb 16 09:10:42 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 14Tf2Q-000CYg-00; Fri, 16 Feb 2001 09:10:42 +0200 To: freebsd-arch@freebsd.org Cc: arch@freebsd.org Subject: Re: The /usr/bin/games bikeshed again In-reply-to: Your message of "Thu, 15 Feb 2001 13:54:37 PST." <20010215135437.A3838@dragon.nuxi.com> Date: Fri, 16 Feb 2001 09:10:42 +0200 Message-ID: <48277.982307442@axl.fw.uunet.co.za> From: Sheldon Hearn Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Feb 2001 13:54:37 PST, "David O'Brien" wrote: > I fully support this idea. Anything else in the base system that was so > old and little used, would have been pushed to ports a long time ago. In fact, at least one of the games should just be shot dead. The nethack we have in the games directory shouldn't be shifted across to ports, because a maintained version exists in the ports tree already (nethack3-tty). Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 23:43:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id C6C7537B503; Thu, 15 Feb 2001 23:43:36 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f1G7h3303381; Fri, 16 Feb 2001 09:43:03 +0200 (EET) (envelope-from ru) Date: Fri, 16 Feb 2001 09:43:03 +0200 From: Ruslan Ermilov To: "Rodney W. Grimes" Cc: arch@FreeBSD.ORG, Andrey Chernov , Dag-Erling Smorgrav Subject: Re: Proposed change for ISO_8859-1 catpages Message-ID: <20010216094303.A2869@sunbay.com> Mail-Followup-To: "Rodney W. Grimes" , arch@FreeBSD.ORG, Andrey Chernov , Dag-Erling Smorgrav References: <20010215171519.A24192@sunbay.com> <200102151937.LAA63098@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102151937.LAA63098@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Thu, Feb 15, 2001 at 11:37:28AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 15, 2001 at 11:37:28AM -0800, Rodney W. Grimes wrote: > ... > > **************************** > > > > Now the problem. > > > > To make this patch actually do its job, and create symbolic links > > for /usr/share/man/man* in /usr/share/man/en.ISO_8859-1/, we need > > to drop the -d flag from mtree(8) call for BSD.usr.dist: > > > > Index: Makefile > ... > > > > So, are there any objections or goaheds? :-) > > README: > b) Only directories should be listed here. > Definitely, we would need to relax this :-) > Have you taken a look at what happens when you run > cd /usr/src; make hierarchy > > with your patch in place? > Sure I did, and I think you meant symlinks were not created for you. If that is the case, please upgrade your mtree(8) so that mtree/verify.c is at least of version 1.13 or later for HEAD, and 1.10.2.2 in RELENG_4. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 23:44:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 3BC6137B4EC; Thu, 15 Feb 2001 23:44:16 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f1G7i0N03417; Fri, 16 Feb 2001 09:44:00 +0200 (EET) (envelope-from ru) Date: Fri, 16 Feb 2001 09:44:00 +0200 From: Ruslan Ermilov To: "Andrey A. Chernov" Cc: arch@FreeBSD.ORG, Dag-Erling Smorgrav Subject: Re: Proposed change for ISO_8859-1 catpages Message-ID: <20010216094400.B2869@sunbay.com> Mail-Followup-To: "Andrey A. Chernov" , arch@FreeBSD.ORG, Dag-Erling Smorgrav References: <20010215171519.A24192@sunbay.com> <20010216000349.A91289@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010216000349.A91289@nagual.pp.ru>; from ache@nagual.pp.ru on Fri, Feb 16, 2001 at 12:03:49AM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 12:03:49AM +0300, Andrey A. Chernov wrote: > On Thu, Feb 15, 2001 at 17:15:19 +0200, Ruslan Ermilov wrote: > > Now the problem. > > > > To make this patch actually do its job, and create symbolic links > > for /usr/share/man/man* in /usr/share/man/en.ISO_8859-1/, we need > > to drop the -d flag from mtree(8) call for BSD.usr.dist: > > If adding links by mtree cause problems, they can be added like > locale.alias links (see etc/Makefile) > This does not cause problems to me, but I thought others may have objections which I can not personally see. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 15 23:57:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 2200437B503; Thu, 15 Feb 2001 23:57:27 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f1G7vJe04268; Fri, 16 Feb 2001 09:57:19 +0200 (EET) (envelope-from ru) Date: Fri, 16 Feb 2001 09:57:19 +0200 From: Ruslan Ermilov To: Maxim Sobolev Cc: mi@aldan.algebra.com, arch@FreeBSD.org Subject: Re: [Call for *quick* review] architecture-specific manpages Message-ID: <20010216095719.F2869@sunbay.com> Mail-Followup-To: Maxim Sobolev , mi@aldan.algebra.com, arch@FreeBSD.org References: <200102152119.f1FLJ6v10117@misha.privatelabs.com> <3A8C4C02.D8300939@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A8C4C02.D8300939@FreeBSD.org>; from sobomax@FreeBSD.org on Thu, Feb 15, 2001 at 11:37:06PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 15, 2001 at 11:37:06PM +0200, Maxim Sobolev wrote: > mi@aldan.algebra.com wrote: > > > On 15 Feb, Maxim Sobolev wrote: > > [...] > > = Why not to use HW_MACHINE mib to get current arch, so it would just work [tm] w/o the > > = need to define MACHINE env variable? > > > > Because I may be interested in the man page for one architecture while > > working on the other? There should be a command line option for that > > too, IMHO... > > Please read my message again. I have not implied that detection of > MACHINE env variable should be removed. I only noted that value > returned by the HW_MACHINE mib is to be used when no MACHINE env > variable is defined. > ``machine = MACHINE'' line in the patch will use the value defined in . This is faster than looking for hw.machine. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 0: 4:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B9DAF37B491; Fri, 16 Feb 2001 00:04:56 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1G84qW25651; Fri, 16 Feb 2001 01:04:52 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102160804.f1G84qW25651@harmony.village.org> To: Bruce Evans Subject: Re: The whole libc thing. Cc: "Brian F. Feldman" , arch@FreeBSD.org In-reply-to: Your message of "Fri, 16 Feb 2001 18:09:25 +1100." References: Date: Fri, 16 Feb 2001 01:04:51 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Bruce Evans writes: : On Thu, 15 Feb 2001, Brian F. Feldman wrote: : : > My proposition wouldn't break any binary compatibility because it would keep : > the FILE structure size the same. : : This isn't sufficient. fileno() and getc() used to be macros and/or : inline functions that knew about the internals of the struct. Right. That's why I didn't move things around at all in the end. : > The actual contents are _not_ allowed to : > be known outside of libc, so anything that gets it wrong after this change : > deserves to break in many horrible ways. We don't need a hash lookup : > because there is already a _very_ seldom-used field, _up, which can be : > absorbed for this purpose. I initially thought _cookie was better, but : : Your patch works because (hopefully) the field is so seldom used that it : wasn't used by the old macros. I don't think that _up is used in macros back to 3.2. Further back than that is not relevant since we start running out of the ELF world and 3.x wasn't stable until 3.2. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 0: 9: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 765D937B491; Fri, 16 Feb 2001 00:08:46 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f1G88Yx04908; Fri, 16 Feb 2001 10:08:34 +0200 (EET) (envelope-from ru) Date: Fri, 16 Feb 2001 10:08:34 +0200 From: Ruslan Ermilov To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: [Call for *quick* review] architecture-specific manpages Message-ID: <20010216100833.G2869@sunbay.com> Mail-Followup-To: Robert Watson , arch@FreeBSD.org References: <20010215211404.A44780@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Thu, Feb 15, 2001 at 04:23:15PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 15, 2001 at 04:23:15PM -0500, Robert Watson wrote: > On Thu, 15 Feb 2001, Ruslan Ermilov wrote: > > > The attached patch implements one nice feature of original BSD man(1), > > to look into the machine-specific subdirectory, specifically: > > > > : As some manual pages are intended only for specific architectures, > > : man searches any subdirectories, with the same name as the current > > : architecture, in every directory which it searches. Machine specific > > : areas are checked before general areas. The current machine type may > > : be overridden by setting the environment variable MACHINE to the name > > : of a specific architecture. > > > > This would eliminate the need to MLINK every arch-specific file to the > > parent directory, and would allow us to have both architecture-specific > > and generic manpages with the same name in the same section. > > It's a good idea to check the results of calls like snprintf or you can > get truncation bugs. I'd recommend you go pass these patches by -audit. > Any time you have programs running with privilege of some sort (and yes, > setuid man or setgid man counts as privilege), you have to be *really* > careful. These patches do not appear to be very careful at all, and they > seem to make heavy use of environmental variables in constructing strings. > Oh common, you can supply whatever you want in $MANPATH, and have man(1) look into whatever path you tell it to. The setgidness of man(1) is only to allow creation of catpages, and does not hurt everything else. Two days ago I fixed the bug in manpath that would allow a malicious user create empty catpages, and sent the notice to security-officer (which you are a member of). I got no replies so far, and I am a bit confused since (in my opinion) this definitely deserves the security advisory. > I'd personally feel a lot more comfortable with all this if we'd simply > remove the setuid/setgid man'ness of man, and either pre-generate cached > pages as appropriate, or simply eschew caching, given the speed of modern > machines. > Not everyone has the ability to buy the "modern" machine, so disabling catpages building would not work. Just delete cat* subdirectories, and man(1) will intelligently skip creating catpages for you. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 0:39:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id CF9B637B401; Fri, 16 Feb 2001 00:39:15 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA02715; Fri, 16 Feb 2001 19:39:04 +1100 Date: Fri, 16 Feb 2001 19:38:35 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Sheldon Hearn Cc: Robert Watson , Ruslan Ermilov , arch@FreeBSD.ORG Subject: Re: [Call for *quick* review] architecture-specific manpages In-Reply-To: <48188.982307324@axl.fw.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001, Sheldon Hearn wrote: > On Thu, 15 Feb 2001 16:23:15 EST, Robert Watson wrote: > > > I'd personally feel a lot more comfortable with all this if we'd simply > > remove the setuid/setgid man'ness of man, and either pre-generate cached > > pages as appropriate, or simply eschew caching, given the speed of modern > > machines. > > Have you tried going without caching on a typical workstation that's > actually doing work? Personally, I can feel the difference and find it > annoying. :-( I've always had it turned off, and never really noticed it, even in 1992 on a 486/33. You can get used to anything :-) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 1:24:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 0A1A837B401 for ; Fri, 16 Feb 2001 01:24:08 -0800 (PST) Received: from newsguy.com (p21-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.150]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id SAA03466; Fri, 16 Feb 2001 18:23:51 +0900 (JST) Message-ID: <3A8CF105.F0E4FFD1@newsguy.com> Date: Fri, 16 Feb 2001 18:21:09 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again References: <200102151834.f1FIXv941778@gratis.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > Utility > ------- > caesar U > factor U > fortune U > morse U > number U > primes U > random U Keep these on src/. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "That's evil, Sir," Layson said admiringly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 2:28:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30]) by hub.freebsd.org (Postfix) with ESMTP id CA14037B65D for ; Fri, 16 Feb 2001 02:28:16 -0800 (PST) Received: from dungeon.home (ppp9.dyn250.pacific.net.au [203.143.250.9]) by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id VAA27369; Fri, 16 Feb 2001 21:28:07 +1100 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.1/8.11.1) with ESMTP id f1GATar23483; Fri, 16 Feb 2001 20:29:36 +1000 (EST) (envelope-from mckay) Message-Id: <200102161029.f1GATar23483@dungeon.home> To: arch@freebsd.org Cc: mckay@thehub.com.au, Warner Losh , Bruce Evans Subject: Re: The whole libc thing. References: <200102160804.f1G84qW25651@harmony.village.org> In-Reply-To: <200102160804.f1G84qW25651@harmony.village.org> from Warner Losh at "Fri, 16 Feb 2001 08:04:51 +0000" Date: Fri, 16 Feb 2001 20:29:36 +1000 From: Stephen McKay Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm getting into this kinda late. It feels like people are rushing. There is every reason not to rush. Backward compatibility can be preserved and should be preserved, and if people rush, then it won't be preserved. Think back. This has all happened before, early in 1998 with errno. It was really only solved by switching from a.out to ELF and hence forcing the biggest major version bump in FreeBSD history. :-) For the few people who kept on with a.out, I added the ld.so hack which is still a controversial item even today. Hi David! The absolutely correct answer is to bump every version number of every library everywhere. You don't want to hear that, but it is the answer. Why? Because nearly all libraries know a few details about the internals of stdio, from getc() or putc() macros, because stdin and friends are in an array, or just from groveling around (dangerously) inside FILE structures. We don't track this internal knowledge with version numbers or anything. A given program demands a particular version of libc, and all other libraries just blindly assume that whatever version of stdio they were compiled with will be binary compatible with the libc that turned up in the dynamic link stage. Recent changes have broken that assumption. But given that people want to avoid bumping all versions, and hence want to keep stdio binary compatibility despite substantial changes, we turn our minds to hacks. On Friday, 16th February 2001, Warner Losh wrote: >In message Bruce Evans writes: >: On Thu, 15 Feb 2001, Brian F. Feldman wrote: >: >: > My proposition wouldn't break any binary compatibility because it would >: > keep the FILE structure size the same. >: >: This isn't sufficient. fileno() and getc() used to be macros and/or >: inline functions that knew about the internals of the struct. > >Right. That's why I didn't move things around at all in the end. Any field you change must be a field that was never manipulated by a macro, and to be super nice, was never a "cool" thing for an over-friendly user to manipulate. "_up" seems reasonable from this point of view. >: > The actual contents are _not_ allowed to >: > be known outside of libc, so anything that gets it wrong after this change > >: > deserves to break in many horrible ways. We don't need a hash lookup >: > because there is already a _very_ seldom-used field, _up, which can be >: > absorbed for this purpose. I initially thought _cookie was better, but >: >: Your patch works because (hopefully) the field is so seldom used that it >: wasn't used by the old macros. > >I don't think that _up is used in macros back to 3.2. Further back >than that is not relevant since we start running out of the ELF world >and 3.x wasn't stable until 3.2. We should be concerned about binaries back to 3.0 (and rev 1.20 of stdio.h) to pick up the earliest ELF binaries. I fully expect all my old binaries to run after whatever hack we make here. Rev 1.20 isn't much different from the latest release (4.2) anyway, so if we want to support any 4.2 users, it shouldn't be too hard to support all ELF users. In rev 1.20, getc and putc were macros, more complicated if threading was involved. Other than that, you have the the __sF array to deal with and the need to keep pretty much everything at the same offset. But this is still hackery. The real answer is to bump all revisions. At the same time, we could make FILE opaque, and deal with the few programs that break because they meddle with FILE internals. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 4:10:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 20FA137B503 for ; Fri, 16 Feb 2001 04:10:51 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1GCAD945461; Fri, 16 Feb 2001 14:10:18 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102161210.f1GCAD945461@gratis.grondar.za> To: "Daniel C. Sobral" Cc: arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again References: <3A8CF105.F0E4FFD1@newsguy.com> In-Reply-To: <3A8CF105.F0E4FFD1@newsguy.com> ; from "Daniel C. Sobral" "Fri, 16 Feb 2001 18:21:09 +0900." Date: Fri, 16 Feb 2001 14:10:48 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mark Murray wrote: > > > > Utility > > ------- > > caesar U > > factor U > > fortune U > > morse U > > number U > > primes U > > random U > > Keep these on src/. That's the plan! :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 6:32:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 0C90A37B401 for ; Fri, 16 Feb 2001 06:32:31 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id GAA01902; Fri, 16 Feb 2001 06:31:48 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda01900; Fri Feb 16 06:31:35 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GEVUq73111; Fri, 16 Feb 2001 06:31:30 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdR73109; Fri Feb 16 06:31:13 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GEVCX28090; Fri, 16 Feb 2001 06:31:12 -0800 (PST) Message-Id: <200102161431.f1GEVCX28090@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdi28086; Fri Feb 16 06:30:27 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Mark Murray Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Wish List (was: Re: The /usr/bin/games bikeshed again) In-reply-to: Your message of "Fri, 16 Feb 2001 08:08:17 +0200." <200102160607.f1G67k944464@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 06:30:27 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102160607.f1G67k944464@gratis.grondar.za>, Mark Murray writes: > > :Hey, what's this uucp stuff? > > : > > :Warner > > > > /var/spool/uucppublic has been an eyesore to me for over 5 years now. > > Someone, PLEASE put it out of its misery! Or turn it into a port. > > Or something... maybe just shoot it :-) > > Next on my list :-) Other candidates, Kerveros IV. Anyone is serious about using Kerberos would install the krb5 port. (I don't consider heimdal a serious condender, it's already a port and it should have stayed there). IMO, both Kerberos IV and heimdal are just a waste of disk space). Rdist was also discussed. Rdist5, rdist6, and rsync should share the same status. Some of us have vendor and FreeBSD systems, use rdist5. Others use Linux and FreeBSD system, use rdist6. Others, like myself, use rsync. Too bad this discussion just fizzled out with no decision. If we fulfil these wishes I'd be extremely grateful and make an otherwise bad year a little better. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 6:33:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id C2CC537B401 for ; Fri, 16 Feb 2001 06:33:10 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id GAA01907; Fri, 16 Feb 2001 06:32:48 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda01905; Fri Feb 16 06:32:36 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GEWVN73118; Fri, 16 Feb 2001 06:32:31 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdA73114; Fri Feb 16 06:32:12 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GEWBh28103; Fri, 16 Feb 2001 06:32:11 -0800 (PST) Message-Id: <200102161432.f1GEWBh28103@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdT28096; Fri Feb 16 06:31:33 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Mark Murray Cc: "Daniel C. Sobral" , arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again In-reply-to: Your message of "Fri, 16 Feb 2001 14:10:48 +0200." <200102161210.f1GCAD945461@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 06:31:33 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102161210.f1GCAD945461@gratis.grondar.za>, Mark Murray writes: > > Mark Murray wrote: > > > > > > Utility > > > ------- > > > caesar U > > > factor U > > > fortune U > > > morse U > > > number U > > > primes U > > > random U > > > > Keep these on src/. > > That's the plan! :-) Why? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 6:50:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4D5DD37B503 for ; Fri, 16 Feb 2001 06:50:24 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id PAA13325; Fri, 16 Feb 2001 15:49:29 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Cy Schubert - ITSD Open Systems Group Cc: Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) References: <200102161431.f1GEVCX28090@cwsys.cwsent.com> From: Dag-Erling Smorgrav Date: 16 Feb 2001 15:49:28 +0100 In-Reply-To: Cy Schubert - ITSD Open Systems Group's message of "Fri, 16 Feb 2001 06:30:27 -0800" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group writes: > Rdist was also discussed. Rdist5, rdist6, and rsync should share the > same status. Some of us have vendor and FreeBSD systems, use rdist5. > Others use Linux and FreeBSD system, use rdist6. Others, like myself, > use rsync. Too bad this discussion just fizzled out with no decision. I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) disappear either. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 7:10: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 2D15037B69B for ; Fri, 16 Feb 2001 07:10:04 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA02042; Fri, 16 Feb 2001 07:09:09 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda02040; Fri Feb 16 07:09:01 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GF8ul73463; Fri, 16 Feb 2001 07:08:56 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdl73443; Fri Feb 16 07:08:13 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GF8DR28339; Fri, 16 Feb 2001 07:08:13 -0800 (PST) Message-Id: <200102161508.f1GF8DR28339@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdC28335; Fri Feb 16 07:08:09 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Dag-Erling Smorgrav Cc: Cy Schubert - ITSD Open Systems Group , Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) In-reply-to: Your message of "16 Feb 2001 15:49:28 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 07:08:09 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: > Cy Schubert - ITSD Open Systems Group writes: > > Rdist was also discussed. Rdist5, rdist6, and rsync should share the > > same status. Some of us have vendor and FreeBSD systems, use rdist5. > > Others use Linux and FreeBSD system, use rdist6. Others, like myself, > > use rsync. Too bad this discussion just fizzled out with no decision. > > I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) > disappear either. Good idea. I've advocated removing all non-encrypting services and making them ports, like "r" commands, telnet, ftp, etc., because we have much better solutions like SSH and apache which are not only more secure but firewall friendly, however I won't go there, as it is yet another bikeshed that gets too many people upset. Someone should put together an plan, however that would get mired down in the bikeshed syndrome. (My apologies for the cynicism -- it's been a bad year). Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 7:57: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 37F8D37B4EC for ; Fri, 16 Feb 2001 07:57:01 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA13559; Fri, 16 Feb 2001 16:56:11 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Cy Schubert - ITSD Open Systems Group Cc: Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) References: <200102161508.f1GF8DR28339@cwsys.cwsent.com> From: Dag-Erling Smorgrav Date: 16 Feb 2001 16:56:10 +0100 In-Reply-To: Cy Schubert - ITSD Open Systems Group's message of "Fri, 16 Feb 2001 07:08:09 -0800" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group writes: > making them ports, like "r" commands, telnet, ftp, etc., Telnet and FTP still have their uses, even if they're not encrypted. FTP is obviously useful for anonymous FTP, and removing it would cause an uproar. Telnet is extremely useful as a debugging tool (remember, you can telnet to any TCP port, not just port 23...) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 8: 5:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from london.physics.purdue.edu (london.physics.purdue.edu [128.210.67.35]) by hub.freebsd.org (Postfix) with ESMTP id C4C5F37B67D for ; Fri, 16 Feb 2001 08:05:22 -0800 (PST) Received: (from will@localhost) by london.physics.purdue.edu (8.8.8/8.8.8) id LAA29992; Fri, 16 Feb 2001 11:04:20 -0500 (EST) X-Authentication-Warning: london.physics.purdue.edu: will set sender to will@physics.purdue.edu using -f Date: Fri, 16 Feb 2001 11:04:20 -0500 From: Will Andrews To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.org Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216110420.J22030@london.physics.purdue.edu> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , Cy Schubert - ITSD Open Systems Group , arch@FreeBSD.org References: <200102160607.f1G67k944464@gratis.grondar.za> <200102161431.f1GEVCX28090@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161431.f1GEVCX28090@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Feb 16, 2001 at 06:30:27AM -0800 X-Operating-System: SunOS 4.1.3_U1 sun4m Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 06:30:27AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > Other candidates, Kerveros IV. Anyone is serious about using Kerberos > would install the krb5 port. (I don't consider heimdal a serious > condender, it's already a port and it should have stayed there). IMO, > both Kerberos IV and heimdal are just a waste of disk space). Uh, just one problem. MIT Kerberos V is apparently still restricted from export. See http://web.mit.edu/network/kerberos-form.html. Or are the MIT people out of sync with crypto regulations? ;-) -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 8:26:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 05DB937B67D for ; Fri, 16 Feb 2001 08:26:21 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 6210619380; Fri, 16 Feb 2001 10:26:18 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GGQIA90272; Fri, 16 Feb 2001 10:26:18 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 10:26:18 -0600 From: "Jacques A. Vidrine" To: Cy Schubert - ITSD Open Systems Group Cc: Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216102618.A90210@hamlet.nectar.com> References: <200102160607.f1G67k944464@gratis.grondar.za> <200102161431.f1GEVCX28090@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161431.f1GEVCX28090@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Feb 16, 2001 at 06:30:27AM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 06:30:27AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > Other candidates, Kerveros IV. Anyone is serious about using Kerberos > would install the krb5 port. (I don't consider heimdal a serious > condender, it's already a port and it should have stayed there). IMO, > both Kerberos IV and heimdal are just a waste of disk space). Perhaps you'd like to elaborate on your comments about Heimdal. There is a lot to like about it over the MIT Kerberos implementation, not the least of which is the fact that the MIT Kerberos license still does not allow export from US. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 8:32:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id DA86637B503 for ; Fri, 16 Feb 2001 08:32:10 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA02825; Fri, 16 Feb 2001 08:31:38 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda02823; Fri Feb 16 08:31:29 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GGVOZ74003; Fri, 16 Feb 2001 08:31:24 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdf73985; Fri Feb 16 08:31:18 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GGVIs28888; Fri, 16 Feb 2001 08:31:18 -0800 (PST) Message-Id: <200102161631.f1GGVIs28888@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdo28884; Fri Feb 16 08:31:02 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Will Andrews Cc: Cy Schubert - ITSD Open Systems Group , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) In-reply-to: Your message of "Fri, 16 Feb 2001 11:04:20 EST." <20010216110420.J22030@london.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 08:31:02 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010216110420.J22030@london.physics.purdue.edu>, Will Andrews writ es: > On Fri, Feb 16, 2001 at 06:30:27AM -0800, Cy Schubert - ITSD Open Systems Gro > up wrote: > > Other candidates, Kerveros IV. Anyone is serious about using Kerberos > > would install the krb5 port. (I don't consider heimdal a serious > > condender, it's already a port and it should have stayed there). IMO, > > both Kerberos IV and heimdal are just a waste of disk space). > > Uh, just one problem. MIT Kerberos V is apparently still restricted from > export. See http://web.mit.edu/network/kerberos-form.html. Or are the > MIT people out of sync with crypto regulations? ;-) I think they are out of sync. I should have asked Paul Hill, MIT Kerberos Project Team Manager, this at the Kerberos Guru session when I was at LISA in December. As we in Canada can get MIT Kerberos, the question never crossed my mind, though other technical questions did. Sorry. :( The downside to Kerberos V is, I've yet to find a good Kerberos V client for Windows. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 8:38:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from london.physics.purdue.edu (london.physics.purdue.edu [128.210.67.35]) by hub.freebsd.org (Postfix) with ESMTP id 0ED5A37B4EC for ; Fri, 16 Feb 2001 08:38:39 -0800 (PST) Received: (from will@localhost) by london.physics.purdue.edu (8.8.8/8.8.8) id LAA02489; Fri, 16 Feb 2001 11:37:36 -0500 (EST) X-Authentication-Warning: london.physics.purdue.edu: will set sender to will@physics.purdue.edu using -f Date: Fri, 16 Feb 2001 11:37:35 -0500 From: Will Andrews To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.org Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216113734.K22030@london.physics.purdue.edu> Reply-To: arch@FreeBSD.org Mail-Followup-To: Will Andrews , Cy Schubert - ITSD Open Systems Group , arch@FreeBSD.org References: <20010216110420.J22030@london.physics.purdue.edu> <200102161631.f1GGVIs28888@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161631.f1GGVIs28888@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Feb 16, 2001 at 08:31:02AM -0800 X-Operating-System: SunOS 4.1.3_U1 sun4m Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 08:31:02AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > I think they are out of sync. I should have asked Paul Hill, MIT > Kerberos Project Team Manager, this at the Kerberos Guru session when I > was at LISA in December. As we in Canada can get MIT Kerberos, the > question never crossed my mind, though other technical questions did. So, until we get an answer to that, Heimdal is our best choice... :-) > The downside to Kerberos V is, I've yet to find a good Kerberos V > client for Windows. I hear Win2K can handle Kerberos V pretty well. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 8:44:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 6B73E37B401 for ; Fri, 16 Feb 2001 08:44:39 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA02877; Fri, 16 Feb 2001 08:44:39 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda02873; Fri Feb 16 08:44:36 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GGiVd74101; Fri, 16 Feb 2001 08:44:31 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdx74098; Fri Feb 16 08:44:18 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GGiIJ29006; Fri, 16 Feb 2001 08:44:18 -0800 (PST) Message-Id: <200102161644.f1GGiIJ29006@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdt28994; Fri Feb 16 08:43:59 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: arch@FreeBSD.ORG Cc: Cy Schubert - ITSD Open Systems Group Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) In-reply-to: Your message of "Fri, 16 Feb 2001 11:37:35 EST." <20010216113734.K22030@london.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 08:43:59 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010216113734.K22030@london.physics.purdue.edu>, Will Andrews writ es: > On Fri, Feb 16, 2001 at 08:31:02AM -0800, Cy Schubert - ITSD Open Systems Gro > up wrote: > > I think they are out of sync. I should have asked Paul Hill, MIT > > Kerberos Project Team Manager, this at the Kerberos Guru session when I > > was at LISA in December. As we in Canada can get MIT Kerberos, the > > question never crossed my mind, though other technical questions did. > > So, until we get an answer to that, Heimdal is our best choice... :-) > > > The downside to Kerberos V is, I've yet to find a good Kerberos V > > client for Windows. > > I hear Win2K can handle Kerberos V pretty well. The KDC needs to be a Win2K machine. That doesn't sit with me too well. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 8:45: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id A37E537B401 for ; Fri, 16 Feb 2001 08:45:03 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA02878; Fri, 16 Feb 2001 08:44:39 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda02874; Fri Feb 16 08:44:37 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GGiWp74105; Fri, 16 Feb 2001 08:44:32 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdN74099; Fri Feb 16 08:44:19 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GGiJR29010; Fri, 16 Feb 2001 08:44:19 -0800 (PST) Message-Id: <200102161644.f1GGiJR29010@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdE29002; Fri Feb 16 08:44:16 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: "Jacques A. Vidrine" Cc: Cy Schubert - ITSD Open Systems Group , Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) In-reply-to: Your message of "Fri, 16 Feb 2001 10:26:18 CST." <20010216102618.A90210@hamlet.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 08:44:15 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010216102618.A90210@hamlet.nectar.com>, "Jacques A. Vidrine" writ es: > On Fri, Feb 16, 2001 at 06:30:27AM -0800, Cy Schubert - ITSD Open Systems Gro > up wrote: > > Other candidates, Kerveros IV. Anyone is serious about using Kerberos > > would install the krb5 port. (I don't consider heimdal a serious > > condender, it's already a port and it should have stayed there). IMO, > > both Kerberos IV and heimdal are just a waste of disk space). > > Perhaps you'd like to elaborate on your comments about Heimdal. > There is a lot to like about it over the MIT Kerberos implementation, > not the least of which is the fact that the MIT Kerberos license still > does not allow export from US. I understand it to be not a full implementation of Kerberos V. There was some discussion about this on -stable or -security some time ago. As you're the maintainer of both in the FreeBSD ports/source trees you would know more about that than I do. Maybe I'm off base here. -- Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC "COBOL IS A WASTE OF CARDS." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 8:50:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A9E1037B4EC; Fri, 16 Feb 2001 08:50:46 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1GGokh58520; Fri, 16 Feb 2001 11:50:46 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Feb 2001 11:50:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ruslan Ermilov Cc: arch@FreeBSD.org Subject: Re: [Call for *quick* review] architecture-specific manpages In-Reply-To: <20010216100833.G2869@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001, Ruslan Ermilov wrote: > Two days ago I fixed the bug in manpath that would allow a malicious > user create empty catpages, and sent the notice to security-officer > (which you are a member of). I got no replies so far, and I am a bit > confused since (in my opinion) this definitely deserves the security > advisory. If the security-officer responds slowly to requests, it's because we keep having to put out fires because people keep committing security problems to the tree. Often times, we receive little or no assistance from code maintainers in correcting problems they've introduced, and usually end up fixing the problems ourselves rather than being able to rely on code maintainers to do the job right the first time, or fix it when a mistake is pointed out. We have little or no success at pursuading people who introduce security holes to offer us any assistance in helping them in their future commits, as we ask them to send mail to the -audit list for review, and more than likely they flat out refuse, saying we can go read the changes in the repository later and to stop wasting their time. Often, we're busy being flamed for security holes introduced by other people that we spend time fixing. The following two paragraphs refers not specifically to you, when saying "you", but rather the FreeBSD developer community as a whole, so please don't take it personally, as it's not clear that 3/4 of this applies to the man bug you're refering to. So if you have a problem with the security-officer timelag, there are a number of things you can do. For one, you can cooperate in making our lives easier by looking for review on the -audit mailing list, so we don't have to sit there and play CVS games to find and fix all the security holes. That way you can be involved in the testing and fixing of the problems, and not have us constantly looping on buildworld trying to fix problems before they are MFC'd or -CURRENT turns into -STABLE. You can avoid MFC'ing rapidly before we've had a chance to review code, especially if the code is sensitive to security (i.e., it runs with privilege (daemons, periodic code, ...), runs setuid or setgid to any user, binds network ports, uses /tmp without using mkstemp(), and so on). You can try to remember a few simple coding guidelines, such as always checking return values on string functions (or any function) and attempting to fail cleanly and "closed", and not reproducing security holes that have been fixed literally thousands of times before. You can remember that every time we have to release a security advisory, it costs a lot of people a lot of time and money. It takes us substantial time to evaluate/fix the problem, write the advisory, build patches for various branches and releases, and then provide support for all the people who can't figure it out. It costs everyone money who has to upgrade to deal with a security problem, and that adds up to a lot of money in administrator time. Security holes and fixes aren't "fire and forget", they waste everyone's time. And when the vulnerabilities result in active exploitation and compromise, then they result in people switching away from FreeBSD. Also, they make us look pretty rediculous. We've released more security advisories this year than Microsoft has (28 vs 12). If you exclude ports and re-releases (leaving aside the ipfw rerelease, which should not be ignored), we're doing better, but even so, that's far from good. Since the beginning of the year, we've averaged over an advisory a week on the base system, and yes, we have more in the queue. This year we've been particular prone to failure in the contrib code (BIND, OpenSSH), but last year was fraught with base system problems that were clearly not in the base code. Many of this year's advisories have been on problems introduced a fair distance in the past; many of last year's that was not true for (i.e., the problem was reported within 6 months of it being committed, and typically in a release branch). And, if you're interested, there are repeat offenders who seem to be responsible for the majority of the security holes we deal with. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 8:55:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6F77B37B491; Fri, 16 Feb 2001 08:55:06 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id RAA13816; Fri, 16 Feb 2001 17:55:05 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Robert Watson Cc: Ruslan Ermilov , arch@FreeBSD.ORG Subject: Re: [Call for *quick* review] architecture-specific manpages References: From: Dag-Erling Smorgrav Date: 16 Feb 2001 17:55:05 +0100 In-Reply-To: Robert Watson's message of "Fri, 16 Feb 2001 11:50:45 -0500 (EST)" Message-ID: Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson writes: > [...] And, if you're interested, > there are repeat offenders who seem to be responsible for the majority of > the security holes we deal with. IMHO, this should be grounds for suspension of committer privileges. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 9: 4:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 5357D37B401 for ; Fri, 16 Feb 2001 09:04:18 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id C0C0419380; Fri, 16 Feb 2001 11:04:17 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GH4Hr90354; Fri, 16 Feb 2001 11:04:17 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 11:04:17 -0600 From: "Jacques A. Vidrine" To: Cy Schubert - ITSD Open Systems Group Cc: Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216110417.B90297@hamlet.nectar.com> References: <20010216102618.A90210@hamlet.nectar.com> <200102161644.f1GGiJR29010@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161644.f1GGiJR29010@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Feb 16, 2001 at 08:44:15AM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 08:44:15AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > I understand it to be not a full implementation of Kerberos V. There > was some discussion about this on -stable or -security some time ago. > > As you're the maintainer of both in the FreeBSD ports/source trees you > would know more about that than I do. Maybe I'm off base here. Yes, you are off base :-) Heimdal is a complete implementation of Kerberos V, with KDC and client libraries and applications. (Speculating) The previous discussion you refer to may have been the fact that the integration into the base system was not complete. In many cases, it still is not integrated, but it is getting there. At least it is a recent version now (Thanks Assar!). -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 9:11:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 5BAAD37B503 for ; Fri, 16 Feb 2001 09:11:45 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id BBA9919380; Fri, 16 Feb 2001 11:11:44 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GHBi890375; Fri, 16 Feb 2001 11:11:44 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 11:11:44 -0600 From: "Jacques A. Vidrine" To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216111144.C90210@hamlet.nectar.com> References: <20010216113734.K22030@london.physics.purdue.edu> <200102161644.f1GGiIJ29006@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161644.f1GGiIJ29006@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Feb 16, 2001 at 08:43:59AM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 08:43:59AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > In message <20010216113734.K22030@london.physics.purdue.edu>, Will Andrews writes: > > I hear Win2K can handle Kerberos V pretty well. > > The KDC needs to be a Win2K machine. That doesn't sit with me too > well. I've authenticated a Windows 2000 machine against both an MIT KDC and a Heimdal KDC. I've also gotten them to talk to each other using a toy GSSAPI application. I did this just as proof-of-concept: no doubt there are caveats to a big rollout. However, there is lots of activity in this area on the various Kerberos lists. Microsoft even has documentation on their website regarding interoperability with MIT Kerberos V. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 9:15:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id E89F637B401 for ; Fri, 16 Feb 2001 09:15:39 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 462BF19380; Fri, 16 Feb 2001 11:15:39 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GHFdb90390; Fri, 16 Feb 2001 11:15:39 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 11:15:39 -0600 From: "Jacques A. Vidrine" To: Cy Schubert - ITSD Open Systems Group Cc: Will Andrews , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216111539.D90210@hamlet.nectar.com> References: <20010216110420.J22030@london.physics.purdue.edu> <200102161631.f1GGVIs28888@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161631.f1GGVIs28888@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Feb 16, 2001 at 08:31:02AM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 08:31:02AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > The downside to Kerberos V is, I've yet to find a good Kerberos V > client for Windows. Sadly, this is true. There is the MIT Kerberos for Windows, but this is pretty much restricted to the core credentials management. However, I read very recently that www.vandyke.com's SecureCRT can utilize an appropriate GSSAPI DLL to do Kerberos with TELNET/ssh. I believe the aforementioned MIT Kerberos for Windows contains such a DLL. I haven't yet had time to test this claim. Also, last year I corresponded with the Vandyke developers, and they said, ``We are looking at Kerberos for inclusion in a major upgrade of the software, generally in your time frame.'' My time frame was mid-2001. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 9:17:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 0B62D37B67D for ; Fri, 16 Feb 2001 09:17:23 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 7B50C19389; Fri, 16 Feb 2001 11:17:22 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GHHMk90397; Fri, 16 Feb 2001 11:17:22 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 11:17:22 -0600 From: "Jacques A. Vidrine" To: arch@FreeBSD.org Cc: will@physics.purdue.edu Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216111722.E90210@hamlet.nectar.com> References: <20010216110420.J22030@london.physics.purdue.edu> <200102161631.f1GGVIs28888@cwsys.cwsent.com> <20010216113734.K22030@london.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010216113734.K22030@london.physics.purdue.edu>; from will@physics.purdue.edu on Fri, Feb 16, 2001 at 11:37:35AM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 11:37:35AM -0500, Will Andrews wrote: > So, until we get an answer to that, Heimdal is our best choice... :-) Even if the license is fixed, I prefer the Heimdal code in general. It's cleaner. Granted, the MIT codebase is more mature, more widely used, and better documented. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 9:36:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id AB90A37B4EC for ; Fri, 16 Feb 2001 09:36:35 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1GHZR946693; Fri, 16 Feb 2001 19:35:27 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102161735.f1GHZR946693@gratis.grondar.za> To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again References: <200102161432.f1GEWBh28103@cwsys.cwsent.com> In-Reply-To: <200102161432.f1GEWBh28103@cwsys.cwsent.com> ; from Cy Schubert - ITSD Open Systems Group "Fri, 16 Feb 2001 06:31:33 PST." Date: Fri, 16 Feb 2001 19:36:04 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Keep these on src/. > > > > That's the plan! :-) There is no doubt about the others; everyone agrees that they need to move. There is argument about these - they default to the /status quo/. This doesn't mean that the SQ can't be revisited later. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 9:37:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 5CC9D37B401 for ; Fri, 16 Feb 2001 09:37:41 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1GHbQ946702; Fri, 16 Feb 2001 19:37:26 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102161737.f1GHbQ946702@gratis.grondar.za> To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) References: In-Reply-To: ; from Dag-Erling Smorgrav "16 Feb 2001 15:49:28 +0100." Date: Fri, 16 Feb 2001 19:38:02 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) > disappear either. I'd love to see those go, myself. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 9:41:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 532A337B503 for ; Fri, 16 Feb 2001 09:41:36 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id JAA03078; Fri, 16 Feb 2001 09:40:40 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda03076; Fri Feb 16 09:40:37 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GHeWO74591; Fri, 16 Feb 2001 09:40:32 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdd74585; Fri Feb 16 09:40:21 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GHeKO29359; Fri, 16 Feb 2001 09:40:20 -0800 (PST) Message-Id: <200102161740.f1GHeKO29359@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdz29352; Fri Feb 16 09:40:04 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Dag-Erling Smorgrav Cc: Cy Schubert - ITSD Open Systems Group , Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) In-reply-to: Your message of "16 Feb 2001 16:56:10 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 09:40:04 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: > Cy Schubert - ITSD Open Systems Group writes: > > making them ports, like "r" commands, telnet, ftp, etc., > > Telnet and FTP still have their uses, even if they're not encrypted. > FTP is obviously useful for anonymous FTP, and removing it would cause > an uproar. Telnet is extremely useful as a debugging tool (remember, > you can telnet to any TCP port, not just port 23...) I suppose Telnet, FTP, and "r" commands have their uses on a trusted private network behind a firewall or simply disconnected from the Internet. I use them at home on my private network but avoid their use at work and recommend to clients that they should be phased out. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 9:42:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 12A7C37B699 for ; Fri, 16 Feb 2001 09:41:53 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1GHf0A97803; Fri, 16 Feb 2001 09:41:00 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Feb 2001 09:41:00 -0800 (PST) From: Matt Dillon Message-Id: <200102161741.f1GHf0A97803@earth.backplane.com> To: Cy Schubert - ITSD Open Systems Group Cc: Dag-Erling Smorgrav , Cy Schubert - ITSD Open Systems Group , Mark Murray , arch@FreeBSD.ORG Subject: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) References: <200102161508.f1GF8DR28339@cwsys.cwsent.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In message , Dag-Erling Smorgrav :writes: :> Cy Schubert - ITSD Open Systems Group writes: :> > Rdist was also discussed. Rdist5, rdist6, and rsync should share the :> > same status. Some of us have vendor and FreeBSD systems, use rdist5. :> > Others use Linux and FreeBSD system, use rdist6. Others, like myself, :> > use rsync. Too bad this discussion just fizzled out with no decision. :> :> I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) :> disappear either. : :Good idea. I've advocated removing all non-encrypting services and :making them ports, like "r" commands, telnet, ftp, etc., because we :have much better solutions like SSH and apache which are not only more :secure but firewall friendly, however I won't go there, as it is yet :another bikeshed that gets too many people upset. : :Someone should put together an plan, however that would get mired down :in the bikeshed syndrome. (My apologies for the cynicism -- it's been :a bad year). : :Regards, Phone: (250)387-8437 :Cy Schubert Fax: (250)387-5766 Well, lets at least get rid of the ones that don't cause controversy (I'd like telnet to stay too.. I use it all the time for debugging things like sendmail). I agree completely in regards to Kerberos IV. Nobody in their right mind should be using it any more so it should definitely become a port. Lets see if we can put together a list of things can be moved to ports that is not too controversial: * All games except fortune * UUCP * Kerberos IV The more controversial ones: * rdist * rmt * rcp, rlogin, rsh Extremely controversial: * telnet (i.e. its too useful to have around for other purposes) The main issue with removing something like rcp or rsh is that, by default, our openssh is not compiled with the 'none' cipher, so it's impossible to use it when non-encrypted data content is desired. Sometimes speed is more important then encryption. (I dont use rcp or rsh myself, but while at BEST I had on ocassion needed to use 'ssh -c none' and that required recompiling ssh). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 9:49:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 5E19E37B401 for ; Fri, 16 Feb 2001 09:49:46 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id C8DDB19380 for ; Fri, 16 Feb 2001 11:49:41 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GHnfr90492 for arch@FreeBSD.ORG; Fri, 16 Feb 2001 11:49:41 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 11:49:41 -0600 From: "Jacques A. Vidrine" To: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports Message-ID: <20010216114941.F90210@hamlet.nectar.com> References: <200102161508.f1GF8DR28339@cwsys.cwsent.com> <200102161741.f1GHf0A97803@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161741.f1GHf0A97803@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Feb 16, 2001 at 09:41:00AM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cc: list mercifully killed] On Fri, Feb 16, 2001 at 09:41:00AM -0800, Matt Dillon wrote: > in regards to Kerberos IV. Nobody in their right mind should be > using it any more That's perhaps a bit harsh -- there are still some environments in which Kerberos IV is useful/required (e.g. AFS, DCE). > so it should definitely become a port. But I agree with this sentiment. > The more controversial ones: > > * rdist > * rmt > * rcp, rlogin, rsh As long as these can be used with encryption, they should stay. > Extremely controversial: > > * telnet (i.e. its too useful to have around for other purposes) Agreed. This is my primary means of remote access (well, with Kerberos). -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 10: 1:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4D0A837B503 for ; Fri, 16 Feb 2001 10:01:14 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1GI1Ew98317; Fri, 16 Feb 2001 10:01:14 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Feb 2001 10:01:14 -0800 (PST) From: Matt Dillon Message-Id: <200102161801.f1GI1Ew98317@earth.backplane.com> To: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) References: <200102161508.f1GF8DR28339@cwsys.cwsent.com> <200102161741.f1GHf0A97803@earth.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'll collect all the responses from the list together and put together a comprehensive list, then post it tonight. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 10: 2:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 41AE737B401 for ; Fri, 16 Feb 2001 10:02:17 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA14330; Fri, 16 Feb 2001 11:02:12 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA15283; Fri, 16 Feb 2001 11:02:10 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14989.27426.877852.291707@nomad.yogotech.com> Date: Fri, 16 Feb 2001 11:02:10 -0700 (MST) To: Mark Murray Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) In-Reply-To: <200102161737.f1GHbQ946702@gratis.grondar.za> References: <200102161737.f1GHbQ946702@gratis.grondar.za> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) > > disappear either. > > I'd love to see those go, myself. I'd be very angry to see them go. Not every FreeBSD machine is connected to the internet. R* utilities are very commonly used, and we're not gaining anything but removing them. Disabling them from /etc/inetd.conf is barely acceptable, IMO. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 10: 4:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3729337B4EC for ; Fri, 16 Feb 2001 10:04:24 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1GI2Rh59420; Fri, 16 Feb 2001 13:02:27 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Feb 2001 13:02:27 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matt Dillon Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-Reply-To: <200102161741.f1GHf0A97803@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001, Matt Dillon wrote: > Well, lets at least get rid of the ones that don't cause controversy > (I'd like telnet to stay too.. I use it all the time for debugging > things like sendmail). > > I agree completely in regards to Kerberos IV. Nobody in their right > mind should be using it any more so it should definitely become a port. The problem with Kerberos is that it requires substantial integration into base system code that is very security-sensitive. If you move KerberosIV to a port without some form of integrating it into the base system while using base system {telnetd,ftpd,...} then people who do run Kerberos will suffer a great deal. My hope would be that we'd keep supporting KerberosIV through the end of the 4.x branch, and make KerberosV be the supported Kerberos on 5.0-RELEASE, and have KerberosIV be a port. Unfortunately, PAM cannot provide the level of integration necessary at this point. > * All games except fortune > * UUCP Sadly, this one is still controversial. See below. > * Kerberos IV > > The more controversial ones: > > * rdist > * rmt > * rcp, rlogin, rsh > > Extremely controversial: > > * telnet (i.e. its too useful to have around for other purposes) > > The main issue with removing something like rcp or rsh is that, by > default, our openssh is not compiled with the 'none' cipher, so it's > impossible to use it when non-encrypted data content is desired. Sometimes > speed is more important then encryption. (I dont use rcp or rsh myself, > but while at BEST I had on ocassion needed to use 'ssh -c none' and that > required recompiling ssh). It seems to me that moving things off into ports is to some extent undesirable, as the ports collection is intended to adapt third-party code to the FreeBSD environment, and generate binary installs. It's not intended to allow more loose bundling of code that has a local maintainer. I think a logical next step on a number of these components is not to make them a port, but to make them not be part of the base "default" distribution. I.e., make UUCP a distribution of its own, and move from having a NO_UUCP to having a BUILD_UUCP flag in make.conf. There is also, I think, a strong argument towards avoiding making things be a port when they are substantially useful as part of the base system. One of the things that has characterized FreeBSD is a reasonable default install that looks like you'd expect UNIX to look. Regardless of the success of SSH, telnet is something that many administrators use daily to build TCP connections for testing mail, connecting to routers and boxes on local area networks, etc. Also, telnet contains SRA support, as well as Kerberos support, meaning that it is really not accurate to describe it purely as an insecure application. As much as I love SSH, it also has a lot of poor failure modes regarding key storage, configuration files, and probably needs more coordinated maintainership and a better review process for updates. One strong argument for disabling aspects of less well maintained code in the base system is whether they constitute a security risk by existing there unused. Generally speaking, this applies to services that are enabled but not used (we've addressed this a lot better in recent iterations on rc.conf and inetd.conf), and client code in the base system that makes use of privilege models in a way that introduces risk due to complexity and failure modes (UUCP and man both come to mind), which an attacker could attempt to exploit. We've already seen setuid perl move in this direction default disabling of the setuid bit. Part of the problem here also is that we still need packageNG or sysinstallNG or whatever. We don't have a consistent and coherent way to manage the installation of optional components that are part of the base system. Moving to a nicely modular install and partitioning scheme makes sense, but creating redundant code maintenance or reducing the support level for some services is not necessarily the right solution. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 10:37: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 1158E37B491 for ; Fri, 16 Feb 2001 10:36:57 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id KAA03213; Fri, 16 Feb 2001 10:36:02 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda03211; Fri Feb 16 10:36:00 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GIZsb74976; Fri, 16 Feb 2001 10:35:54 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdb74972; Fri Feb 16 10:35:26 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GIZOB29603; Fri, 16 Feb 2001 10:35:24 -0800 (PST) Message-Id: <200102161835.f1GIZOB29603@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdo29596; Fri Feb 16 10:34:38 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Matt Dillon Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-reply-to: Your message of "Fri, 16 Feb 2001 10:01:14 PST." <200102161801.f1GI1Ew98317@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 10:34:37 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102161801.f1GI1Ew98317@earth.backplane.com>, Matt Dillon writes: > I'll collect all the responses from the list together and put together > a comprehensive list, then post it tonight. Please move Sendmail to ports. People should have a choice of which MTA they want to use. Sendmail should not have any special status when compared to other MTA's in ports. Qmail and postfix are quite popular too and they are in ports. BIND: There is a growing groundswell in favour of djbdns. People should have a choice. Once again if they choose djbdns, BIND takes up space that could be used by other software on the disk. Economy. telnetd and ftpd. (I suppose the clients can stay in the base system, though fetch and a web browser can do the same). I no longer offer anonymous ftp services on most systems I manage, as a web browser can serve files just as well (assuming the client has approved of the changes), and the HTTP protocol is firewall friendly while FTP is not. For non-anonymous FTP, there is sftp. It's not the same protocol but the user interface is the same. Sftp, which uses SSH is much more secure and is firewall friendly, e.g. doesn't need any FTP proxy. Anyhow, I hope everyone can understand my rationale for moving away from FTP. All four of these have been very hot issues in the past. Judging from the responses in the past, I'd suggest taking a vote and deciding from there. Some of the above have flags defined in make.conf others don't. I suppose the place to start would be to define macros for each of the above that don't have macros defined in make.conf. Then after a while, like FreeBSD-6.0, default the above to "don't build". Finally, e.g. FreeBSD-7.0, people might be acclimatised to not having them, the can be moved to ports. For some, like ftpd and ftp, telnetd and telnet, we may have to phase in the solution over a much longer period of time -- call it a 3 or 5 year plan (virtually forever in this business but taking it slow should satisfy most if not all people). I realise these are sensitive issues, which is why I propose a long lead time. By then other open source projects and maybe even some vendors might have caught on to the idea as well. For those of use who have private networks with people you can trust on them, e.g. my network at home, I see no problem using these services and protocols. Having said that, this breaks one premise of good security (which I don't even follow as much as I preach), which is security through depth, so even then I can argue against using these protocols there. Hopefully I haven't ruffled too many feathers and have conveyed my message in a constructive manner. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 11: 6:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 134C537B503 for ; Fri, 16 Feb 2001 11:06:34 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1GJ5Yw01853; Fri, 16 Feb 2001 11:05:34 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Feb 2001 11:05:34 -0800 (PST) From: Matt Dillon Message-Id: <200102161905.f1GJ5Yw01853@earth.backplane.com> To: Cy Schubert - ITSD Open Systems Group Cc: Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) References: <200102161835.f1GIZOB29603@cwsys.cwsent.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I'll collect all the responses from the list together and put together :> a comprehensive list, then post it tonight. : :Please move Sendmail to ports. People should have a choice of which :MTA they want to use. Sendmail should not have any special status when :compared to other MTA's in ports. Qmail and postfix are quite popular :too and they are in ports. : :BIND: There is a growing groundswell in favour of djbdns. People :should have a choice. Once again if they choose djbdns, BIND takes up :space that could be used by other software on the disk. Economy. I have to disagree. Our base system must be operational without forcing people to install certain ports. We need a working bind and a working mail subsystem in the base system. We can let people turn it off, but we can't shift these to ports. In regards to djbdns... as much as I aplaud security-centric designs, the djbdns code is virtually unmaintainable -- unformatted, uncommented, and a mess. Despite his essentricities Paul Vixie and the code he produces is a whole lot easier to work with. I'd rather wait for Bind-9 to stabilize and then move the base system to that then to shift to djbdns. (I'll add these to the list under 'extremely controversial', which they are). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 11: 6:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id B874137B401 for ; Fri, 16 Feb 2001 11:06:41 -0800 (PST) Received: from localhost (scanner@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id OAA89000; Fri, 16 Feb 2001 14:00:22 -0500 (EST) Date: Fri, 16 Feb 2001 14:00:22 -0500 (EST) From: To: Cy Schubert - ITSD Open Systems Group Cc: Matt Dillon , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-Reply-To: <200102161835.f1GIZOB29603@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001, Cy Schubert - ITSD Open Systems Group wrote: > Please move Sendmail to ports. People should have a choice of which > MTA they want to use. Sendmail should not have any special status when > compared to other MTA's in ports. Qmail and postfix are quite popular > too and they are in ports. Cy, I and others feel the same about the MTA issue. However the last time I brought this up 2 valid points were raised that should not be over looked. 1. No one has written the code into sysinstall to allow for slecting an MTA. 2. We have an actuall maintainer of sendmail FROM the vendor. Greg from sendmail actually maintains our sendmail. If dan or wietse would do the same that would be one less argument people have for ripping out sendmail. However I know for a fact weitse does *not* have the time to do this. So both points are still valid. I love postfix and would love to see it as an option in sysinstall but until those 2 points above are checked off the list I don't see it happening. ============================================================================= -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: scanner@jurai.net | Open Systems Inc., Wellington, Kansas Home: scanner@deceptively.shady.org | http://open-systems.net ============================================================================= WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" ============================================================================= irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 11:19:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 6384937B401 for ; Fri, 16 Feb 2001 11:19:22 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id LAA03319; Fri, 16 Feb 2001 11:18:23 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda03317; Fri Feb 16 11:18:18 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GJID375334; Fri, 16 Feb 2001 11:18:13 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdk75330; Fri Feb 16 11:17:26 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GJHPl29820; Fri, 16 Feb 2001 11:17:25 -0800 (PST) Message-Id: <200102161917.f1GJHPl29820@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdN29815; Fri Feb 16 11:16:48 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Matt Dillon Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-reply-to: Your message of "Fri, 16 Feb 2001 11:05:34 PST." <200102161905.f1GJ5Yw01853@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 11:16:47 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102161905.f1GJ5Yw01853@earth.backplane.com>, Matt Dillon writes: > :> I'll collect all the responses from the list together and put together > :> a comprehensive list, then post it tonight. > : > :Please move Sendmail to ports. People should have a choice of which > :MTA they want to use. Sendmail should not have any special status when > :compared to other MTA's in ports. Qmail and postfix are quite popular > :too and they are in ports. > : > :BIND: There is a growing groundswell in favour of djbdns. People > :should have a choice. Once again if they choose djbdns, BIND takes up > :space that could be used by other software on the disk. Economy. > > I have to disagree. Our base system must be operational without forcing > people to install certain ports. We need a working bind and a working > mail subsystem in the base system. We can let people turn it off, but we > can't shift these to ports. > > In regards to djbdns... as much as I aplaud security-centric designs, > the djbdns code is virtually unmaintainable -- unformatted, uncommented, > and a mess. Despite his essentricities Paul Vixie and the code he produce > s > is a whole lot easier to work with. I'd rather wait for Bind-9 to > stabilize and then move the base system to that then to shift to djbdns. > > (I'll add these to the list under 'extremely controversial', which they > are). One could say the same about the "r" commands, telnet, and ftp. For telnet and ftp: Extremely controversial. For the "r" commands, I'd rate the issue as half way between controversial and extremely controversial. What do you think? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 11:30: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gatewaya.anheuser-busch.com (gatewaya.anheuser-busch.com [151.145.250.252]) by hub.freebsd.org (Postfix) with SMTP id 6A0A637B4EC for ; Fri, 16 Feb 2001 11:30:01 -0800 (PST) Received: by gatewaya.anheuser-busch.com; id NAA16282; Fri, 16 Feb 2001 13:29:56 -0600 Received: from stlexgvir004(10.33.24.97) by gatewaya.anheuser-busch.com via smap (V5.0) id xma016119; Fri, 16 Feb 01 13:28:52 -0600 Received: from SMTP (STLEXGGTW002.abc.corp.anheuser-busch.com [10.33.24.23]) by stlexgvir004.abc.corp.anheuser-busch.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 15QPPHS9; Fri, 16 Feb 2001 13:28:02 -0600 Received: from stlexgims004.anheuser-busch.com ([10.33.24.73]) by 10.33.24.23 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 16 Feb 2001 19:28:54 0000 (GMT) Received: by STLEXGIMS004 with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Feb 2001 13:28:51 -0600 Message-ID: From: "Young, Jason" To: "'Matt Dillon'" , Cy Schubert - ITSD Open Systems Group Cc: Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: RE: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Date: Fri, 16 Feb 2001 13:28:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark made a well-reasoned proposal to take some extremely ancient, rarely used games and get them out of the base system. I bet most people would agree that it's a good idea. But the discussion meandered over into the whole "we need to rip XXX out of the base system" thing, where XXX is a topic of religious significance (MTAs, DNS servers, editors, nonencrypting network utilities, etc). The other things have been discussed to death and they'll more than likely get discussed to death again now. Cy, I'm sure you mean well but I'm afraid you will destroy any chance for Mark to do this one useful non-controversial thing if you try to mix in the issue of sendmail and other controversial utilities. Is it possible to just set everything but the games aside for the moment? It's not like people won't discuss it in the future if it's set aside right now. Jason Young CNS - Network Design, Anheuser-Busch (314)577-4597 -----Original Message----- From: Matt Dillon [mailto:dillon@earth.backplane.com] Sent: Friday, February 16, 2001 1:06 PM To: Cy Schubert - ITSD Open Systems Group Cc: Dag-Erling Smorgrav; Mark Murray; arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) :> I'll collect all the responses from the list together and put together :> a comprehensive list, then post it tonight. : :Please move Sendmail to ports. People should have a choice of which :MTA they want to use. Sendmail should not have any special status when :compared to other MTA's in ports. Qmail and postfix are quite popular :too and they are in ports. : :BIND: There is a growing groundswell in favour of djbdns. People :should have a choice. Once again if they choose djbdns, BIND takes up :space that could be used by other software on the disk. Economy. I have to disagree. Our base system must be operational without forcing people to install certain ports. We need a working bind and a working mail subsystem in the base system. We can let people turn it off, but we can't shift these to ports. In regards to djbdns... as much as I aplaud security-centric designs, the djbdns code is virtually unmaintainable -- unformatted, uncommented, and a mess. Despite his essentricities Paul Vixie and the code he produces is a whole lot easier to work with. I'd rather wait for Bind-9 to stabilize and then move the base system to that then to shift to djbdns. (I'll add these to the list under 'extremely controversial', which they are). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 11:33:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9FA1337B401 for ; Fri, 16 Feb 2001 11:33:15 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1GJWN002324; Fri, 16 Feb 2001 11:32:23 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Feb 2001 11:32:23 -0800 (PST) From: Matt Dillon Message-Id: <200102161932.f1GJWN002324@earth.backplane.com> To: Cy Schubert - ITSD Open Systems Group Cc: Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) References: <200102161917.f1GJHPl29820@cwsys.cwsent.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :One could say the same about the "r" commands, telnet, and ftp. For :telnet and ftp: Extremely controversial. For the "r" commands, I'd :rate the issue as half way between controversial and extremely :controversial. What do you think? : :Regards, Phone: (250)387-8437 :Cy Schubert Fax: (250)387-5766 Yes, I agree. 'telnet' and 'ftp' would be extremely controversial (I'd like to keep them myself). The various 'r' commands rlogin, rsh, etc are in the middle. I'll separate the daemons from the clients. I think the daemons, e.g. 'telnetd', 'rshd', 'rexecd', 'rlogind' are in the middle, possibly even slightly less controversial then the client commands 'rlogin', 'rsh'. I think it may be possible to come to agreement to moving the daemons to ports. -- Scary moment of the day: At a meeting with a potential client I was standing in front of the white board an explained that we were using 'ssh' to create secure client-server links. I got blank stares. I paused, then asked to the room in general 'does *anyway* here know what 'ssh' is?'. More blank stares. This was a company doing secure VPNs. Very Scary. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 11:36:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9C46337B503 for ; Fri, 16 Feb 2001 11:36:13 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1GJZtO02394; Fri, 16 Feb 2001 11:35:55 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Feb 2001 11:35:55 -0800 (PST) From: Matt Dillon Message-Id: <200102161935.f1GJZtO02394@earth.backplane.com> To: "Young, Jason" Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: RE: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Is it possible to just set everything but the games aside for the moment? It's :not like people won't discuss it in the future if it's set aside right now. : :Jason Young I think it's worth putting together a comprehensive list of modules and assign a 'controversy level' to each one. Sure, one could argue over the assignments, but it will still be a good road map. It's important to keep the base system as modernized as possible. In many respects, we bear the responsibility to push our commercial and non-commercial users towards more reasonable configurations for today's interconnected world. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12: 7:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 32BA937B503 for ; Fri, 16 Feb 2001 12:07:49 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id NAA26938; Fri, 16 Feb 2001 13:04:46 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAfbaGL0; Fri Feb 16 13:04:39 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA07191; Fri, 16 Feb 2001 13:07:39 -0700 (MST) From: Terry Lambert Message-Id: <200102162007.NAA07191@usr05.primenet.com> Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) To: Cy.Schubert@uumail.gov.bc.ca Date: Fri, 16 Feb 2001 20:07:39 +0000 (GMT) Cc: will@physics.purdue.edu (Will Andrews), arch@FreeBSD.ORG In-Reply-To: <200102161631.f1GGVIs28888@cwsys.cwsent.com> from "Cy Schubert - ITSD Open Systems Group" at Feb 16, 2001 08:31:02 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The downside to Kerberos V is, I've yet to find a good Kerberos V > client for Windows. The Cyrus project has a Kerberos V DLL that it uses for IMAP4 client code. I think there are references to it on the Cyrus project page, as well as the University of Washington C-client page. I've always had too many people insisting that the realm not equal the delegated subdomain to be willing to deploy it on any network where I had a say, or was expected to provide authentication base synchronization code between one system and another (if delegation != realm, the problems in doing this become both obvious and 12 headed monsters). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:10:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id 0FF8E37B491; Fri, 16 Feb 2001 12:10:44 -0800 (PST) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.2/8.11.2) with ESMTP id f1GKAgq40421; Fri, 16 Feb 2001 13:10:42 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102162010.f1GKAgq40421@orthanc.ab.ca> To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-reply-to: Your message of "Fri, 16 Feb 2001 13:02:27 EST." Date: Fri, 16 Feb 2001 13:10:42 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Robert" == Robert Watson writes: Robert> do run Kerberos will suffer a great deal. My hope would Robert> be that we'd keep supporting KerberosIV through the end of Robert> the 4.x branch, and make KerberosV be the supported Robert> Kerberos on 5.0-RELEASE, and have KerberosIV be a port. If there is a move to K5 for 5.x I think it's imperative that the implementation fully support an existing deployed K4 infrastructure. E.g. we use K4 everywhere in our shop. One of the critical applications is kcvs. If the 5.x cvs cannot do kserver within our deployed K4 infrastucture, 5.x will not be running on our infrastructure machines, period. The same applies to a lesser extent with the kernerized r* utilities. (And yes, we're about to deploy a testbed to start looking at these interoperability issues.) K4 is going to be around for quite a while (at least on the client side), and can't be ignored. Robert> One strong argument for disabling aspects of less well Robert> maintained code in the base system is whether they Robert> constitute a security risk by existing there unused. The issue here is the definition of "unused." I'm sure there are things in the base that get used a _lot_ less than UUCP, and which aren't being considered for removal. With UUCP in particular, we have to be *very* careful not to let our first-world everyone-has-a-t1 view of the world blind us to the reality that large parts of the planet do not have ubiquitous and cheap IP connectivity. UUCP still provides a lot of connectivity. And I think the arguments against keeping UUCP are primarily FUD. I keep hearing about the security problems, but I've yet to see anyone document them. If the issue with UUCP _really_ _is_ security, let's audit the code. Just throwing it out doesn't serve any useful purpose. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:11:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id D3C8F37B4EC for ; Fri, 16 Feb 2001 12:11:43 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id NAA28313; Fri, 16 Feb 2001 13:08:38 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAqRaaq3; Fri Feb 16 13:08:31 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA07275; Fri, 16 Feb 2001 13:11:29 -0700 (MST) From: Terry Lambert Message-Id: <200102162011.NAA07275@usr05.primenet.com> Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) To: n@nectar.com (Jacques A. Vidrine) Date: Fri, 16 Feb 2001 20:11:29 +0000 (GMT) Cc: Cy.Schubert@uumail.gov.bc.ca (Cy Schubert - ITSD Open Systems Group), arch@FreeBSD.ORG In-Reply-To: <20010216111144.C90210@hamlet.nectar.com> from "Jacques A. Vidrine" at Feb 16, 2001 11:11:44 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I did this just as proof-of-concept: no doubt there are caveats to a > big rollout. However, there is lots of activity in this area on the > various Kerberos lists. Microsoft even has documentation on their > website regarding interoperability with MIT Kerberos V. Interoperability only as a client, or have they documented their illegal use of the reserved field, so that you can be a server? My personal opinion is that they should be snubbed, so long as they insis they be treated as the only valid server OS. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:12:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 66B5F37B4EC for ; Fri, 16 Feb 2001 12:12:18 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1GK9gh60976; Fri, 16 Feb 2001 15:09:43 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Feb 2001 15:09:42 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matt Dillon Cc: "Young, Jason" , Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: RE: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-Reply-To: <200102161935.f1GJZtO02394@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001, Matt Dillon wrote: > I think it's worth putting together a comprehensive list of modules > and assign a 'controversy level' to each one. Sure, one could argue > over > the assignments, but it will still be a good road map. It's > important > to keep the base system as modernized as possible. In many > respects, we > bear the responsibility to push our commercial and non-commercial > users > towards more reasonable configurations for today's interconnected > world. I'll reiterate the point just to make sure it didn't get lost in the previous e-mail: Some software relies on tight integration with the base operating system to work correctly. This includes any software tied into our authentication and login systems. This is in part due to our inability to provide clean abstractions for these services. Pushing this software out of the base system will result in far less security for those who use the software, and have negligible security benefit for those that do not use the software. Moving towards a fine-grained install and more careful build knob definition can give both of these sets of users warm fuzzies. Or let's put it this way: suppose we stop maintaing an FTP daemon on FreeBSD. Now all FreeBSD users who want to use an FTP daemon have to fall back on third party software. They might install the NetBSD or OpenBSD FTP daemon, or maybe wuftp or proftpd. Only it turns out that our FTP daemon has had far fewer security problems than any of those alternatives, because we did a pretty successful preemptive code audit on it. So we've gone from having a well-integrated piece of software that understands out login.conf class concepts, and meets some pretty riorous standards for software safety, to bumping users to third party tools with known deficiencies. We provide a fairly complete operating system, with well-integrated components and version control. There are some areas where there are particular well-maintained third party packages where doing the work ourselves makes little sense, and not much local adaptation is required (XFree86, Apache, etc), but there are a lot of pieces of software where we have substantial local adaptation and high levels of integration. This is a benefit. Let's not strip our system down to a bare minimum kernel and libc, and lose that level of integration. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:16:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 470F037B491 for ; Fri, 16 Feb 2001 12:16:09 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id MAA10234; Fri, 16 Feb 2001 12:57:27 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAARbaaIt; Fri Feb 16 12:57:00 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA07081; Fri, 16 Feb 2001 13:02:20 -0700 (MST) From: Terry Lambert Message-Id: <200102162002.NAA07081@usr05.primenet.com> Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) To: des@ofug.org (Dag-Erling Smorgrav) Date: Fri, 16 Feb 2001 20:02:20 +0000 (GMT) Cc: Cy.Schubert@uumail.gov.bc.ca (Cy Schubert - ITSD Open Systems Group), mark@grondar.za (Mark Murray), dillon@earth.backplane.com (Matt Dillon), arch@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Feb 16, 2001 03:49:28 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Rdist was also discussed. Rdist5, rdist6, and rsync should share the > > same status. Some of us have vendor and FreeBSD systems, use rdist5. > > Others use Linux and FreeBSD system, use rdist6. Others, like myself, > > use rsync. Too bad this discussion just fizzled out with no decision. > > I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) > disappear either. I would, I use them. Now if you wanted to shoot perl in the head, I'd be the first to jump on your bandwagon; I _don't_ generally use perl, and for things that need it, it could be a port. Having perl in the base system makes it a pain to run perl on multiple platforms at exactly the same version level, because perl's autodetect stuff in autoconf and CPAN are both too stupid to use the configured paths to get the perl you want from /usr/local (or wherever) instead of the system default. I had a lot of pain with keeping the same perl on FreeBSD and AIX over this, which was particularly bothersome because PERL is not strictly ANSI conformant (it's missing some volatile declarations that it should have), and so the most recent perl compiled with AIX xLC fails to pass the internal perl tests. Unfortunately, you can't mix gcc and xLC objects, since gcc has some gratuitous differences in symbol naming, and can't safely compile some of the OpenSSL and similar code that uses shared object modules. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:18:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 88E0F37B491; Fri, 16 Feb 2001 12:18:22 -0800 (PST) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id NAA63960; Fri, 16 Feb 2001 13:17:52 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdiYNkMa; Fri Feb 16 13:17:44 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA07491; Fri, 16 Feb 2001 13:18:09 -0700 (MST) From: Terry Lambert Message-Id: <200102162018.NAA07491@usr05.primenet.com> Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) To: rwatson@FreeBSD.ORG (Robert Watson) Date: Fri, 16 Feb 2001 20:18:09 +0000 (GMT) Cc: dillon@earth.backplane.com (Matt Dillon), Cy.Schubert@uumail.gov.bc.ca (Cy Schubert - ITSD Open Systems Group), des@ofug.org (Dag-Erling Smorgrav), mark@grondar.za (Mark Murray), arch@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Feb 16, 2001 01:02:27 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The problem with Kerberos is that it requires substantial integration into > base system code that is very security-sensitive. If you move KerberosIV > to a port without some form of integrating it into the base system while > using base system {telnetd,ftpd,...} then people who do run Kerberos will > suffer a great deal. In theory, PAM is supposed to permit programs to deal with this; many people don't use other than the authentication portion of PAM, but it seems that the API is there. It would be worthwhile to abstract this code to the point that you could plug in Kerberos (or Heimdal), or something else, into the programs that currently have non-modular Kerberos specific code. What you need is a gradual student... er. graduate student. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:25: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 95F0937B491 for ; Fri, 16 Feb 2001 12:25:03 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id MAA03704; Fri, 16 Feb 2001 12:24:24 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda03702; Fri Feb 16 12:24:22 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1GKOHD76219; Fri, 16 Feb 2001 12:24:17 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdF76215; Fri Feb 16 12:23:41 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1GKNeI30263; Fri, 16 Feb 2001 12:23:40 -0800 (PST) Message-Id: <200102162023.f1GKNeI30263@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdx30259; Fri Feb 16 12:22:59 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Terry Lambert Cc: Cy.Schubert@uumail.gov.bc.ca, will@physics.purdue.edu (Will Andrews), arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) In-reply-to: Your message of "Fri, 16 Feb 2001 20:07:39 GMT." <200102162007.NAA07191@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Feb 2001 12:22:59 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102162007.NAA07191@usr05.primenet.com>, Terry Lambert writes: > > The downside to Kerberos V is, I've yet to find a good Kerberos V > > client for Windows. > > The Cyrus project has a Kerberos V DLL that it uses for IMAP4 > client code. I think there are references to it on the Cyrus > project page, as well as the University of Washington C-client > page. Thanks. I'll take a look. > > I've always had too many people insisting that the realm not > equal the delegated subdomain to be willing to deploy it on > any network where I had a say, or was expected to provide > authentication base synchronization code between one system > and another (if delegation != realm, the problems in doing > this become both obvious and 12 headed monsters). I don't have experience with delegation != realm yet, though I will be embarking on this course shortly, not by my own doing. I'm not looking forward to this project. So far I think the only gotcha is that krb5.conf on every host will have to explicitly identify which hosts are in which realm. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:26:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 6D58837B491 for ; Fri, 16 Feb 2001 12:26:25 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id DDFF319380; Fri, 16 Feb 2001 14:26:23 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GKQNo91157; Fri, 16 Feb 2001 14:26:23 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 14:26:23 -0600 From: "Jacques A. Vidrine" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216142623.A91104@hamlet.nectar.com> References: <20010216111144.C90210@hamlet.nectar.com> <200102162011.NAA07275@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102162011.NAA07275@usr05.primenet.com>; from tlambert@primenet.com on Fri, Feb 16, 2001 at 08:11:29PM +0000 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 08:11:29PM +0000, Terry Lambert wrote: > > I did this just as proof-of-concept: no doubt there are caveats to a > > big rollout. However, there is lots of activity in this area on the > > various Kerberos lists. Microsoft even has documentation on their > > website regarding interoperability with MIT Kerberos V. > > Interoperability only as a client, or have they documented > their illegal use of the reserved field, so that you can be > a server? The Microsoft website is where I got enough information to configure a Windows 2000 machine as a client to MIT and Heimdal KDCs. It was primarily a matter of locating the right utilities for managing tickets. > My personal opinion is that they should be snubbed, so long > as they insis they be treated as the only valid server OS. Indeed. However, I am happy at the prospect that within the next couple of years there will be a majority of systems on the planet that can be Kerberos clients. It is funny to me how long it has taken ... it was at some panel at UniForum 1992 that I first heard Microsoft say they would integrate Kerberos as the security mechanism ``in the next release of Windows NT'' :-) Windows NT 3.1 was not yet shipping or had just shipped, I can't remember which. The same panel had IBM claiming that OS/2 would be ``the most compatible operating system in the world'' each time a question came up, but no details. Lots of snickering in the audience whenever this was repeated. Granted, this was Cannavino talking. Oh wait, sorry, I thought I was in -chat for a minute there :-) -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:28:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id 9865437B65D for ; Fri, 16 Feb 2001 12:28:44 -0800 (PST) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.2/8.11.2) with ESMTP id f1GKSaq40545; Fri, 16 Feb 2001 13:28:36 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102162028.f1GKSaq40545@orthanc.ab.ca> To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-reply-to: Your message of "Fri, 16 Feb 2001 20:18:09 GMT." <200102162018.NAA07491@usr05.primenet.com> Date: Fri, 16 Feb 2001 13:28:36 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Terry" == Terry Lambert writes: Terry> In theory, PAM is supposed to permit programs to deal with Terry> this; many people don't use other than the authentication Terry> portion of PAM, but it seems that the API is there. But to make K5 useful for applications we also need an integrated SASL library. Such a library would let us support GSSAPI for sendmail (and more importantly, submit) and ftpd out-of-the-box. And from a security standpoint I'd rather have things in ports link against our own SASL than have the ports import their own code (which inevitably use their own private credentials database instead of the OS facilities). --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:29:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 7A4F837B4EC for ; Fri, 16 Feb 2001 12:29:25 -0800 (PST) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id NAA15374; Fri, 16 Feb 2001 13:28:54 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdvZljUa; Fri Feb 16 13:28:47 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA07885; Fri, 16 Feb 2001 13:29:14 -0700 (MST) From: Terry Lambert Message-Id: <200102162029.NAA07885@usr05.primenet.com> Subject: Re: List of things to move from main tree to ports (was Re: To: Cy.Schubert@uumail.gov.bc.ca Date: Fri, 16 Feb 2001 20:29:14 +0000 (GMT) Cc: dillon@earth.backplane.com (Matt Dillon), des@ofug.org (Dag-Erling Smorgrav), mark@grondar.za (Mark Murray), arch@FreeBSD.ORG In-Reply-To: <200102161835.f1GIZOB29603@cwsys.cwsent.com> from "Cy Schubert - ITSD Open Systems Group" at Feb 16, 2001 10:34:37 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'll collect all the responses from the list together and put together > > a comprehensive list, then post it tonight. > > Please move Sendmail to ports. People should have a choice of which > MTA they want to use. Sendmail should not have any special status when > compared to other MTA's in ports. Qmail and postfix are quite popular > too and they are in ports. Please don't, until after you fix the rc code to allow it to be dropped in without manual editting being required. > BIND: There is a growing groundswell in favour of djbdns. People > should have a choice. Once again if they choose djbdns, BIND takes up > space that could be used by other software on the disk. Economy. Please don't. DJBDNS lacks significant and important functionality for all but trivial (one controller or single zone) uses. Also, if this goes in over that objection, please don't do it until after you have broken libresolv out of libc. > telnetd and ftpd. (I suppose the clients can stay in the base system, > though fetch and a web browser can do the same). I no longer offer > anonymous ftp services on most systems I manage, as a web browser can > serve files just as well (assuming the client has approved of the > changes), and the HTTP protocol is firewall friendly while FTP is not. For behind a firewall, telnetd and ftpd are useful. The ability to set up an ftpd for maintenance and support easily, and without a lot of work are important. Similarly, ftp and telnet clients are useful for more than talking to their respective servers locally; you can not debug SMTP or POP3 or IMAP4, etc., without telnet. For the daemons, please do not remove them, until you have addressed the ability of a port to manipulate the contents of the inetd.conf file, so that if they are selected as part of an installation (I suspect, people will want a "traditional" option to be default in sysinstall, with a totally seperate and non-default "anal" option). > For non-anonymous FTP, there is sftp. It's not the same protocol but > the user interface is the same. Sftp, which uses SSH is much more > secure and is firewall friendly, e.g. doesn't need any FTP proxy. > Anyhow, I hope everyone can understand my rationale for moving away > from FTP. You don't want us to be able to download files from Windows servers? > I realise these are sensitive issues, which is why I propose a long > lead time. By then other open source projects and maybe even some > vendors might have caught on to the idea as well. I suspect that whatever group wants to change the world will have to provide all the vendors with a fait accompli, for the change to be global. Volunteers gratefully accepted to work on the original code, ports to other OS's that can be integrated into vendor source trees without fear of the license, modification to the mozilla source to ad "sftp" handling, a plugin for Internet Expolorer on Windows, Macintosh, and Solaris, and an RFC to define the "sftp://" URI introducer. > For those of use who have private networks with people you can trust on > them, e.g. my network at home, I see no problem using these services > and protocols. Having said that, this breaks one premise of good > security (which I don't even follow as much as I preach), which is > security through depth, so even then I can argue against using these > protocols there. I suggest a port called "audit", which you can write to complain about, among other things, "lack of depth". > Hopefully I haven't ruffled too many feathers and have conveyed my > message in a constructive manner. We can agree to disagree, without having to worry about it coming to blows, I think. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:32:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 0728637B4EC for ; Fri, 16 Feb 2001 12:32:16 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id EF15D19380; Fri, 16 Feb 2001 14:32:14 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GKWEB91166; Fri, 16 Feb 2001 14:32:14 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 14:32:14 -0600 From: "Jacques A. Vidrine" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216143214.B91104@hamlet.nectar.com> References: <200102162002.NAA07081@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102162002.NAA07081@usr05.primenet.com>; from tlambert@primenet.com on Fri, Feb 16, 2001 at 08:02:20PM +0000 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 08:02:20PM +0000, Terry Lambert wrote: > Now if you wanted to shoot perl in the head, I'd be the first to > jump on your bandwagon; I _don't_ generally use perl, and for > things that need it, it could be a port. First, replace /bin/sh with ksh93. This will require minor twiddling with /etc/rc*. I think the `only' issue is use of the `local' in function definitions. But then again I haven't looked at it very closely. Then rewrite all the perl scripts. ksh93 programming is much advanced over ksh88 or other shells. Korn thinks that it is in the same category as Perl or Python. I don't agree with the latter from what I've seen, but "You've come a long way, baby," is appropriate. Then have flamewar here :-) -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:32:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id B068737B4EC for ; Fri, 16 Feb 2001 12:32:41 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA16773; Fri, 16 Feb 2001 13:30:44 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id NAA15890; Fri, 16 Feb 2001 13:30:43 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14989.36339.884430.66247@nomad.yogotech.com> Date: Fri, 16 Feb 2001 13:30:43 -0700 (MST) To: Matt Dillon Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-Reply-To: <200102161932.f1GJWN002324@earth.backplane.com> References: <200102161917.f1GJHPl29820@cwsys.cwsent.com> <200102161932.f1GJWN002324@earth.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :One could say the same about the "r" commands, telnet, and ftp. For > :telnet and ftp: Extremely controversial. For the "r" commands, I'd > :rate the issue as half way between controversial and extremely > :controversial. What do you think? > : > :Regards, Phone: (250)387-8437 > :Cy Schubert Fax: (250)387-5766 > > Yes, I agree. 'telnet' and 'ftp' would be extremely controversial > (I'd like to keep them myself). The various 'r' commands rlogin, rsh, > etc are in the middle. > > I'll separate the daemons from the clients. I think the daemons, > e.g. 'telnetd', 'rshd', 'rexecd', 'rlogind' are in the middle, possibly > even slightly less controversial then the client commands 'rlogin', 'rsh'. > > I think it may be possible to come to agreement to moving the daemons to > ports. Not if I have anything to say about it. Great examples of why r* is needed in a internal development environment. Remove CVS (from a Windows box) with decent 'CVS' security require R* access, since PSERVER doesn't work well. I could go on and on. However, I'm with Jason in that we should limit the initial stuff to games. One thing at a time. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:34:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 6272537B491 for ; Fri, 16 Feb 2001 12:34:36 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1GKYZe22417 for arch@FreeBSD.ORG; Fri, 16 Feb 2001 12:34:35 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Feb 2001 12:34:35 -0800 From: "David O'Brien" To: arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216123435.A22331@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <200102161431.f1GEVCX28090@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Fri, Feb 16, 2001 at 03:49:28PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 03:49:28PM +0100, Dag-Erling Smorgrav wrote: > I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) > disappear either. rsh/rlogin goes over my dead body[*], unless you fix the processing of ~/.telnetrc so I can stop if from processing certain control characters I need. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX [*] which I don't doubt some may like To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:36:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 46BAD37B65D for ; Fri, 16 Feb 2001 12:36:51 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 8E0BC19380; Fri, 16 Feb 2001 14:36:50 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GKaoi91175; Fri, 16 Feb 2001 14:36:50 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 14:36:50 -0600 From: "Jacques A. Vidrine" To: Cy Schubert - ITSD Open Systems Group Cc: Terry Lambert , Will Andrews , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216143650.C91104@hamlet.nectar.com> References: <200102162007.NAA07191@usr05.primenet.com> <200102162023.f1GKNeI30263@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102162023.f1GKNeI30263@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Feb 16, 2001 at 12:22:59PM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [This is off-topic, but I'm not sure where to take it.] On Fri, Feb 16, 2001 at 12:22:59PM -0800, Cy Schubert - ITSD Open Systems Group wrote: > I don't have experience with delegation != realm yet, though I will be > embarking on this course shortly, not by my own doing. I'm not looking > forward to this project. So far I think the only gotcha is that > krb5.conf on every host will have to explicitly identify which hosts > are in which realm. MIT Kerberos, Heimdal, and even Windows 2000 (IIRC) support looking up Kerberos configuration information in DNS. The host->realm mapping is pretty simple, e.g. _kerberos.sub.domain.com. IN TXT "MYREALM.COM" _kerberos.host.sub.domain.com. IN TXT "OTHERREALM.COM" Look for the expired draft-ietf-cat-krb-dns-locate Internet draft. A handy copy is in src/crypto/heimdal/doc/standardisation. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:37: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 0100D37B491 for ; Fri, 16 Feb 2001 12:36:59 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1GKapr22490; Fri, 16 Feb 2001 12:36:51 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Feb 2001 12:36:50 -0800 From: "David O'Brien" To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <20010216123650.C22331@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <200102161508.f1GF8DR28339@cwsys.cwsent.com> <200102161741.f1GHf0A97803@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161741.f1GHf0A97803@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Feb 16, 2001 at 09:41:00AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 09:41:00AM -0800, Matt Dillon wrote: > * rdist Uh... done already in -CURRENT... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:37:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 8091837B503 for ; Fri, 16 Feb 2001 12:37:37 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1GKZxZ22436; Fri, 16 Feb 2001 12:35:59 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Feb 2001 12:35:59 -0800 From: "David O'Brien" To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010216123559.B22331@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <200102161508.f1GF8DR28339@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161508.f1GF8DR28339@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Feb 16, 2001 at 07:08:09AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 07:08:09AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > Good idea. I've advocated removing all non-encrypting services and > making them ports, like "r" commands, telnet, ftp, etc., because we > have much better solutions like SSH SSH is NOT the best solution in many cases. We've already turned the daemons off by default. Leave the clients and *DROP THE DISCUSSION OF THEM* already. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:43:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 0AA3F37B4EC for ; Fri, 16 Feb 2001 12:43:11 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 16DC119380; Fri, 16 Feb 2001 14:43:10 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1GKhAX91185; Fri, 16 Feb 2001 14:43:10 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 16 Feb 2001 14:43:09 -0600 From: "Jacques A. Vidrine" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <20010216144309.D91104@hamlet.nectar.com> References: <200102162018.NAA07491@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102162018.NAA07491@usr05.primenet.com>; from tlambert@primenet.com on Fri, Feb 16, 2001 at 08:18:09PM +0000 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 08:18:09PM +0000, Terry Lambert wrote: > > The problem with Kerberos is that it requires substantial integration into > > base system code that is very security-sensitive. If you move KerberosIV > > to a port without some form of integrating it into the base system while > > using base system {telnetd,ftpd,...} then people who do run Kerberos will > > suffer a great deal. > > In theory, PAM is supposed to permit programs to deal with this; > many people don't use other than the authentication portion of > PAM, but it seems that the API is there. No, this is really only for interactive authentication. One must be able to get a password to a PAM-using process, and of course you don't normally want to do this over the network. > It would be worthwhile to abstract this code to the point that > you could plug in Kerberos (or Heimdal), or something else, into > the programs that currently have non-modular Kerberos specific > code. Well, there is already GSSAPI and SASL. In fact, the telnetd and ftpd in src/crypto/heimdal use GSSAPI. Now that we have a GSSAPI implementation in the base system (Heimdal), we can work on bringing telnetd/ftpd/et al up to speed. Unfortunately, sshd uses its own security negotiation protocol which is incompatible with GSSAPI. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:46:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 6949937B401 for ; Fri, 16 Feb 2001 12:46:39 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.2/8.11.1) id f1GKkbE22684; Fri, 16 Feb 2001 12:46:37 -0800 (PST) (envelope-from obrien) Date: Fri, 16 Feb 2001 12:46:37 -0800 From: "David O'Brien" To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <20010216124636.E22331@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <200102161917.f1GJHPl29820@cwsys.cwsent.com> <200102161932.f1GJWN002324@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161932.f1GJWN002324@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Feb 16, 2001 at 11:32:23AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 11:32:23AM -0800, Matt Dillon wrote: > I'll separate the daemons from the clients. I think the daemons, > e.g. 'telnetd', 'rshd', 'rexecd', 'rlogind' are in the middle, possibly > even slightly less controversial then the client commands 'rlogin', 'rsh'. > > I think it may be possible to come to agreement to moving the daemons to > ports. NO FSCKING WAY! They are already turned off by default. That is SUFFIENT ALREADY!! -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:52:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0EA2737B401 for ; Fri, 16 Feb 2001 12:52:00 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1GKpsh61404; Fri, 16 Feb 2001 15:51:55 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Feb 2001 15:51:54 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Lyndon Nerenberg Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-Reply-To: <200102162010.f1GKAgq40421@orthanc.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG robert@fledge.watson.org NAI Labs, Safeport Network Services On Fri, 16 Feb 2001, Lyndon Nerenberg wrote: > >>>>> "Robert" == Robert Watson writes: > > Robert> do run Kerberos will suffer a great deal. My hope would > Robert> be that we'd keep supporting KerberosIV through the end of > Robert> the 4.x branch, and make KerberosV be the supported > Robert> Kerberos on 5.0-RELEASE, and have KerberosIV be a port. > > If there is a move to K5 for 5.x I think it's imperative that the > implementation fully support an existing deployed K4 infrastructure. > E.g. we use K4 everywhere in our shop. One of the critical applications > is kcvs. If the 5.x cvs cannot do kserver within our deployed K4 > infrastucture, 5.x will not be running on our infrastructure machines, > period. The same applies to a lesser extent with the kernerized r* > utilities. (And yes, we're about to deploy a testbed to start looking at > these interoperability issues.) K4 is going to be around for quite a > while (at least on the client side), and can't be ignored. I work in a number of primarily K4-based environments, and am aware of the issues here, and would similarly like (read: expect) to see them addressed. > Robert> One strong argument for disabling aspects of less well > Robert> maintained code in the base system is whether they > Robert> constitute a security risk by existing there unused. > > The issue here is the definition of "unused." I'm sure there are things > in the base that get used a _lot_ less than UUCP, and which aren't being > considered for removal. With UUCP in particular, we have to be *very* > careful not to let our first-world everyone-has-a-t1 view of the world > blind us to the reality that large parts of the planet do not have > ubiquitous and cheap IP connectivity. UUCP still provides a lot of > connectivity. And I think the arguments against keeping UUCP are > primarily FUD. I keep hearing about the security problems, but I've yet > to see anyone document them. If the issue with UUCP _really_ _is_ > security, let's audit the code. Just throwing it out doesn't serve any > useful purpose. I wasn't recommending throwing it out. I'm of the opinion that it would make an excellent build toggle in make.conf, as with many other components of the system (which included, until recently, things like thread support, as well as crypto). The problem with UUCP is that it is a very complex system that does rely on setuid/setgid binaries that exist in the normal program path. The UUCP user and group appear to be tangled up in a number of components, including non-UUCP dialing functionality: crw-rw---- 1 uucp dialer - 28, 128 Feb 12 12:55 /dev/cuaa0 crw-rw---- 1 uucp dialer - 28, 129 Feb 12 12:55 /dev/cuaa1 crw-rw---- 1 uucp dialer - 28, 160 Feb 12 12:55 /dev/cuaia0 crw-rw---- 1 uucp dialer - 28, 161 Feb 12 12:55 /dev/cuaia1 crw-rw---- 1 uucp dialer - 28, 192 Feb 12 12:55 /dev/cuala0 crw-rw---- 1 uucp dialer - 28, 193 Feb 12 12:55 /dev/cuala1 -r-sr-sr-x 1 uucp dialer - 124400 Jan 31 20:21 /usr/bin/cu* -r-xr-xr-x 1 uucp dialer - 37980 Jan 31 20:27 /usr/bin/tip* -r-sr-xr-x 1 uucp wheel - 88652 Jan 31 20:21 /usr/bin/uucp* -r-sr-xr-x 1 uucp wheel - 37568 Jan 31 20:21 /usr/bin/uuname* -r-sr-sr-x 1 uucp dialer - 97048 Jan 31 20:21 /usr/bin/uustat* -r-sr-xr-x 1 uucp wheel - 89256 Jan 31 20:21 /usr/bin/uux* -r-sr-sr-x 1 uucp dialer - 221432 Jan 31 20:21 /usr/libexec/uucp/uucico* -r-sr-s--- 1 uucp uucp - 99996 Jan 31 20:21 /usr/libexec/uucp/uuxqt* Having setuid and setgid all over the place, and associated with devices makes the whole thing rather complicated. Really, /dev/cua* should be owner root, group dialer, for example, and not have UUCP "specialness". With the current model, the ability to compromise any of those setgid/setuid binaries yields access to the system serial ports, as well as the ability to modify programs in the default root and user paths. The daily periodic script, btw, appears to execute uustat each day, and as is seen above, the uustat binary is owned by the UUCP user. I thought all the uu* executions in the periodic stuff had been changed to use su, but either this one wasn't, or it was reverted. In any case, this means that a compromise of the UUCP account can result in a root compromise. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 12:54:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6943837B401 for ; Fri, 16 Feb 2001 12:54:37 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1GKsYh61425; Fri, 16 Feb 2001 15:54:34 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Feb 2001 15:54:34 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Lyndon Nerenberg Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just to clarify... On Fri, 16 Feb 2001, Robert Watson wrote: > I wasn't recommending throwing it out. I'm of the opinion that it would > make an excellent build toggle in make.conf, as with many other > components of the system (which included, until recently, things like > thread support, as well as crypto). The problem with UUCP is that it is > a very complex It's already a default-on toggle, I'd like to move it to default-off, and for it to be a seperate optional "UUCP" distribution in the base system install. We already do this for Kerberos. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 13: 8:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id CE19037B491; Fri, 16 Feb 2001 13:08:14 -0800 (PST) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.2/8.11.2) with ESMTP id f1GL8Dq40757; Fri, 16 Feb 2001 14:08:13 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102162108.f1GL8Dq40757@orthanc.ab.ca> To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-reply-to: Your message of "Fri, 16 Feb 2001 15:51:54 EST." Date: Fri, 16 Feb 2001 14:08:13 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Robert" == Robert Watson writes: Robert> Having setuid and setgid all over the place, and Robert> associated with devices makes the whole thing rather Robert> complicated. Really, /dev/cua* should be owner root, Robert> group dialer, for example, and not have UUCP Robert> "specialness". Yes, the 'dialer' interface is a bit of a mess. Several years ago there was an entry in the CSRG project wish list for a networked dialer daemon that would intermediate access to dialout tty devices. (I *think* it was Keith Bostic's idea.) This might solve part of the problem. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 13: 8:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 803B537B491 for ; Fri, 16 Feb 2001 13:08:19 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id NAA22594; Fri, 16 Feb 2001 13:36:15 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAATuayLR; Fri Feb 16 13:35:44 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA08079; Fri, 16 Feb 2001 13:40:49 -0700 (MST) From: Terry Lambert Message-Id: <200102162040.NAA08079@usr05.primenet.com> Subject: Re: List of things to move from main tree to ports (was Re: To: Cy.Schubert@uumail.gov.bc.ca Date: Fri, 16 Feb 2001 20:40:49 +0000 (GMT) Cc: dillon@earth.backplane.com (Matt Dillon), des@ofug.org (Dag-Erling Smorgrav), mark@grondar.za (Mark Murray), arch@FreeBSD.ORG In-Reply-To: <200102161917.f1GJHPl29820@cwsys.cwsent.com> from "Cy Schubert - ITSD Open Systems Group" at Feb 16, 2001 11:16:47 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > One could say the same about the "r" commands, telnet, and ftp. For > telnet and ftp: Extremely controversial. For the "r" commands, I'd > rate the issue as half way between controversial and extremely > controversial. What do you think? > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca > Open Systems Group, ITSD, ISTA > Province of BC Time for some philosophy? Sun is in a very different mind space. For one thing, it is very easy to compartmentalize daemon replacement, due to it's rc system being composed of component files, instead of being monolithic, as long as you ignore the inetd.conf issues. This also makes it boot slower, but you could always cache "compilations" of scripts to deal with that transparently except for the first boot following a reconfiguration, which would go away if there were a pre-recompile. Security is always a tradeoff between usability and safety. I think, philosophically, that FreeBSD has to be as easy as possible to get to what is generally accepted as "functional", and I'd even go so far as to say that "minimally functional" doesn't cut it. The barrier to entry for a free OS is always going to be how easy it is to install and deinstall without risking anything else on the machine. I think we're all confident that once people try it, if they are trying it for the things for which effort has been expended (i.e. desktop isn't there yet), then they'll come back. I think a number of these suggestions (not just yours) are the kind which increase the barrier to entry, and the FreeBSD market is not really mature enough to tolerate a lot of that at this stage (or FreeBSD would be taking the OpenBSD "it comes locked by default" approach). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 13: 8:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 34A5237B401 for ; Fri, 16 Feb 2001 13:08:27 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1GL7kO04369; Fri, 16 Feb 2001 13:07:46 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Feb 2001 13:07:46 -0800 (PST) From: Matt Dillon Message-Id: <200102162107.f1GL7kO04369@earth.backplane.com> To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) References: <200102161917.f1GJHPl29820@cwsys.cwsent.com> <200102161932.f1GJWN002324@earth.backplane.com> <20010216124636.E22331@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Fri, Feb 16, 2001 at 11:32:23AM -0800, Matt Dillon wrote: :> I'll separate the daemons from the clients. I think the daemons, :> e.g. 'telnetd', 'rshd', 'rexecd', 'rlogind' are in the middle, possibly :> even slightly less controversial then the client commands 'rlogin', 'rsh'. :> :> I think it may be possible to come to agreement to moving the daemons to :> ports. : :NO FSCKING WAY! They are already turned off by default. That is :SUFFIENT ALREADY!! : :-- :-- David (obrien@FreeBSD.org) So, I take it you want those in the 'wildly controversial' column. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 13:10:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id A79AC37B67D; Fri, 16 Feb 2001 13:10:51 -0800 (PST) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.2/8.11.2) with ESMTP id f1GLApq40789; Fri, 16 Feb 2001 14:10:51 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200102162110.f1GLApq40789@orthanc.ab.ca> To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-reply-to: Your message of "Fri, 16 Feb 2001 15:54:34 EST." Date: Fri, 16 Feb 2001 14:10:51 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Robert" == Robert Watson writes: Robert> It's already a default-on toggle, I'd like to move it to Robert> default-off, and for it to be a seperate optional "UUCP" Robert> distribution in the base system install. We already do Robert> this for Kerberos. I think a MAKE_UUCP option is a reasonable compromise. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 13:15:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C6FEF37B503 for ; Fri, 16 Feb 2001 13:15:20 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1GLDNh61731; Fri, 16 Feb 2001 16:13:23 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Feb 2001 16:13:23 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: Cy.Schubert@uumail.gov.bc.ca, Matt Dillon , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: In-Reply-To: <200102162040.NAA08079@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001, Terry Lambert wrote: > Security is always a tradeoff between usability and safety. I keep hearing this concept bandied about like it was pure truth, and frankly, I don't think it is. Some of aspects of the security problem reduce usability, but others don't. It improves security to correctly implement string handling in network daemons. But it also improves correctness, consistency and stability, and those are important components of having a usable system. So I think that the above statement is really a common misconception. I'd dig up some dead Greeks, but it seems like a lot of trouble simply to state: Security can cause reduced usability. Security can cause increased usability. The goal is to have enough of the former to satisfy your needs, and as much of the latter as possible. I.e., show me the last time the fact that your BIND8 server had a remote root compromise improved usability. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 14:22:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 6F60A37B401 for ; Fri, 16 Feb 2001 14:22:45 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1GMLrH98618; Fri, 16 Feb 2001 14:21:53 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Cy Schubert - ITSD Open Systems Group Cc: Matt Dillon , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Moving Things [was Re: List of things to move from main tree] In-Reply-To: Message from Cy Schubert - ITSD Open Systems Group of "Fri, 16 Feb 2001 10:34:37 PST." <200102161835.f1GIZOB29603@cwsys.cwsent.com> Date: Fri, 16 Feb 2001 14:21:53 -0800 Message-ID: <98614.982362113@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Guys guys guys, This whole thread (especially as pertaining to MTAs) comes up periodically and it always goes the same way. To use a rather western analogy, a bunch of torch-waving reformers ride into town calling for the death of a particularly useless and/or controversial utility and those townspeople who don't agree with this point of view start shooting at them from the second story windows. The reformers eventually get pissed-off at being shot at by the ungrateful people they're supposedly trying to save from their own folly and they ride out again in disgust. It always goes this way largely due to the fact that all sides are basically "right." A lot of folks want various interesting types of functionality in their OS which they also don't want to have to play hide-and-seek for as part of some grueling initiation rite - an OS should do what they want it to do. A lot of other folks want a more basic OS core which is easier to understand, easier to maintain and much easier to use in situations which require a fairly small OS footprint. Even more folks have Very Strong Opinions about what the right balance to strike between functionality and simplicity for FreeBSD in general is, even though few of them actually agree on the scale settings. The needs of all these various interest groups are not mutually exclusive. The problem is and always has been that instead of starting new jihads concerning specific components, nobody really sits down and says "Hmm, /usr/src as updated by cvsup is a good idea. /usr/ports is also a good idea. In here somewhere is an even better good idea which encompasses many of the best parts of both." Trust me folks, there are MUCH BETTER mechanisms than ports and a neatly organized /usr/src which would give us a more tree-structured FreeBSD, with "minbin" at the very root and things like MTAs several levels up, while also providing the nice free-standing taxonomy that /usr/src does. We've learned a tremendous amount about source code control and makefile wrappers over the last 9 years of this project, we simply haven't really applied that knowledge to our process in any truly significant ways. We just keep shoe-horning more shit into the same shaped box and complaining that we're running out of room while simultaneously defending the existing structures as somehow sacrosanct or, at worst, simply needing a fresh coat of paint and some minor remodeling. BAH! :) I'd even be willing to take the opium pipe out of my mouth and write down some of these grandiose claims in the form of a much clearer prototype, but before spending that kind of energy on it I'd first like to see some general sign that people aren't dead-set on arguing about individual leaves rather than thinking about the whole tree for a change. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 14:30:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id 712AA37B503 for ; Fri, 16 Feb 2001 14:30:40 -0800 (PST) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 14TtOg-0001BU-00; Fri, 16 Feb 2001 23:30:38 +0100 Received: (from daemon@localhost) by kemoauc.mips.inka.de (8.11.1/8.11.1) id f1GLawR16227 for freebsd-arch@freebsd.org; Fri, 16 Feb 2001 22:36:58 +0100 (CET) (envelope-from daemon) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: List of things to move from main tree to ports Date: Fri, 16 Feb 2001 21:36:57 +0000 (UTC) Message-ID: <96k6hp$eh2$2@kemoauc.mips.inka.de> References: <200102161508.f1GF8DR28339@cwsys.cwsent.com> <200102161741.f1GHf0A97803@earth.backplane.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > The more controversial ones: > > * rdist > * rmt > * rcp, rlogin, rsh rmt doesn't fit in there. rmt is *invoked* through rsh or an equivalent mechanism, which may just as well be ssh. It also doesn't suffer from incompatible implementations as rdist does. -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 15:27:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 8191A37B401 for ; Fri, 16 Feb 2001 15:27:11 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 14TuHH-0004Rn-00; Sat, 17 Feb 2001 01:27:03 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id BAA26075; Sat, 17 Feb 2001 01:26:59 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 25981; Sat Feb 17 01:26:20 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 14TuGa-000H9v-00; Sat, 17 Feb 2001 01:26:20 +0200 To: Cy Schubert - ITSD Open Systems Group Cc: Matt Dillon , Dag-Erling Smorgrav , Mark Murray , arch@freebsd.org Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-reply-to: Your message of "Fri, 16 Feb 2001 10:34:37 PST." <200102161835.f1GIZOB29603@cwsys.cwsent.com> Date: Sat, 17 Feb 2001 01:26:20 +0200 Message-ID: <65962.982365980@axl.fw.uunet.co.za> From: Sheldon Hearn Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001 10:34:37 PST, Cy Schubert - ITSD Open Systems Group wrote: > Please move Sendmail to ports. People should have a choice of which > MTA they want to use. Sendmail should not have any special status when > compared to other MTA's in ports. Qmail and postfix are quite popular > too and they are in ports. You can't move sendmail out of the base system (even if you get consensus) until someone does the work involved in ensuring that, unless the admin clearly doesn't want one, she'll get _some_ MTA with a default install. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 16:16:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from misty.eyesbeyond.com (c27-p101.senet.com.au [203.152.233.230]) by hub.freebsd.org (Postfix) with ESMTP id 0262637B491 for ; Fri, 16 Feb 2001 16:16:32 -0800 (PST) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.9.3/8.9.3) id KAA97146; Sat, 17 Feb 2001 10:46:17 +1030 (CST) (envelope-from glewis) Date: Sat, 17 Feb 2001 10:46:17 +1030 From: Greg Lewis To: Sheldon Hearn Cc: freebsd-arch@FreeBSD.ORG Subject: Re: The /usr/bin/games bikeshed again Message-ID: <20010217104617.A97041@misty.eyesbeyond.com> References: <20010215135437.A3838@dragon.nuxi.com> <48277.982307442@axl.fw.uunet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <48277.982307442@axl.fw.uunet.co.za>; from sheldonh@uunet.co.za on Fri, Feb 16, 2001 at 09:10:42AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 09:10:42AM +0200, Sheldon Hearn wrote: > In fact, at least one of the games should just be shot dead. The > nethack we have in the games directory shouldn't be shifted across to > ports, because a maintained version exists in the ports tree already > (nethack3-tty). What is in the base system (at least on my 4.1 box) is actually hack rather than nethack. IMO the current nethack is as different from hack as hack is from rogue. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Mobile: 0419 868 494 Information Technology Web : http://www.eyesbeyond.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 16:31:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 2992037B491; Fri, 16 Feb 2001 16:31:29 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id RAA27934; Fri, 16 Feb 2001 17:26:27 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAC0ayD2; Fri Feb 16 17:26:18 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA17052; Fri, 16 Feb 2001 17:31:11 -0700 (MST) From: Terry Lambert Message-Id: <200102170031.RAA17052@usr05.primenet.com> Subject: Re: List of things to move from main tree to ports (was Re: To: rwatson@FreeBSD.ORG (Robert Watson) Date: Sat, 17 Feb 2001 00:31:11 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), Cy.Schubert@uumail.gov.bc.ca, dillon@earth.backplane.com (Matt Dillon), des@ofug.org (Dag-Erling Smorgrav), mark@grondar.za (Mark Murray), arch@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Feb 16, 2001 04:13:23 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Security is always a tradeoff between usability and safety. > > I keep hearing this concept bandied about like it was pure truth, and > frankly, I don't think it is. Some of aspects of the security problem > reduce usability, but others don't. It improves security to correctly > implement string handling in network daemons. But it also improves > correctness, consistency and stability, and those are important components > of having a usable system. So I think that the above statement is really > a common misconception. I'd dig up some dead Greeks, but it seems like a > lot of trouble simply to state: > > Security can cause reduced usability. > Security can cause increased usability. For me, removing the R* commands, telnet, ftp, and UUCP reduce usability. UUCP over TCP is a wonderful way to exchange email with a dial on demand server without a static IP address, without having to implement SMTP AUTH and ATRN all over the place, and since there are no public ATRN implementations at this time, it is one of the few options that's easy to get right. Yeah, if you're a moron when it comes to configuring systems, then removing the r* commands by default will increase security, *if* you have one of your users already using the client versions of them on a system subject to compromise. If you don't, it won't matter, since it's just another way to get to a login prompt that's going to refuse you entry. If your problem with these things is string handling, then fix the string handling; there's a lot of code we could dike out as being "insecure", but which we leave lying around. Frankly, I can't see an initial install turning any box without a PC keyboard and VGA monitor attached to it, so you can later enable non-console access, into a useless inert lump, as being something positive for anyone by keyboard and monitor salesmen. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 21:37:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 381EE37B503 for ; Fri, 16 Feb 2001 21:37:42 -0800 (PST) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id NAA24980; Sat, 17 Feb 2001 13:37:35 +0800 Received: from elischer.org (i079-180.nv.iinet.net.au [203.59.79.180]) by muzak.iinet.net.au (8.8.5/8.8.5) with ESMTP id NAA31240; Sat, 17 Feb 2001 13:34:43 +0800 Message-ID: <3A8E0E01.F7D8A772@elischer.org> Date: Fri, 16 Feb 2001 21:37:05 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Matt Dillon Cc: "Young, Jason" , Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: WishList (was: Re: The /usr/bin/games bikeshed again)) References: <200102161935.f1GJZtO02394@earth.backplane.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > : > :Is it possible to just set everything but the games aside for the moment? It's > :not like people won't discuss it in the future if it's set aside right now. > : > :Jason Young > > I think it's worth putting together a comprehensive list of modules > and assign a 'controversy level' to each one. Sure, one could argue over > the assignments, but it will still be a good road map. It's important > to keep the base system as modernized as possible. In many respects, we > bear the responsibility to push our commercial and non-commercial users > towards more reasonable configurations for today's interconnected world. the fact that we DON'T keep these utilities separate is what is different between Linux and FreeBSD. I vote to leave thingsas they are! > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 21:39:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 5421D37B491 for ; Fri, 16 Feb 2001 21:36:58 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14TzvS-0000DZ-00; Fri, 16 Feb 2001 22:28:54 -0700 Message-ID: <3A8E0C16.CB2477C@softweyr.com> Date: Fri, 16 Feb 2001 22:28:54 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Cy Schubert - ITSD Open Systems Group , Matt Dillon , Dag-Erling Smorgrav , Mark Murray , arch@freebsd.org Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) References: <65962.982365980@axl.fw.uunet.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Fri, 16 Feb 2001 10:34:37 PST, Cy Schubert - ITSD Open Systems Group wrote: > > > Please move Sendmail to ports. People should have a choice of which > > MTA they want to use. Sendmail should not have any special status when > > compared to other MTA's in ports. Qmail and postfix are quite popular > > too and they are in ports. > > You can't move sendmail out of the base system (even if you get > consensus) until someone does the work involved in ensuring that, unless > the admin clearly doesn't want one, she'll get _some_ MTA with a default > install. Having SOME MTA selected in the default settings, with "None" as option, would probably suffice. I don't have strong feelings about what the default should be, as long as it's not encumbered. Sendmail or Postfix should suffice. It'd be great if it were configured to actually deliver mail, too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 22:39: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 7F2B737B401 for ; Fri, 16 Feb 2001 22:38:57 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1H6ckW84622; Fri, 16 Feb 2001 23:38:47 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102170638.f1H6ckW84622@harmony.village.org> To: Peter Jeremy Subject: Re: The whole libc thing. Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Feb 2001 16:19:48 +1100." <20010216161948.B70642@gsmx07.alcatel.com.au> References: <20010216161948.B70642@gsmx07.alcatel.com.au> <200102160225.f1G2PFw09227@hak.lan.Awfulhak.org> <200102160317.f1G3HqE26659@billy-club.village.org> Date: Fri, 16 Feb 2001 23:38:46 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010216161948.B70642@gsmx07.alcatel.com.au> Peter Jeremy writes: : I think the same approach would work on the Alpha, but the sizes are : different - according to my calculations, FILE is 64 bytes larger : on an Alpha - 10 pointers @ 4 bytes larger and 24 bytes of padding. Preliminary indications are that the following patch, when MFC'd to RELENG_3 and RELENG_4 (RELENG_2 isn't relevant since it is a.out). They hard code the size of FILE, but for legacy branches that is OK since the size will never change and I litterally find no other way that would work. Once these are in place and we can build compat libraries we can move forward with peter's patches and bump libc's major. We can also back out the gross hack that green and I put into bridge the gap. The enclosed patch doesn't do the backing out, just sets the groundwork for MFC so that we can be "retroactively" forward compatible. I also do just i386 and alpha, because those are the only platforms we need to worry about. This is the least gross thing I can think of to make it so we can move away from encoding sizes into binaries and libraries. I tried every thing else I could think of that didn't hardcode these sizes. They all failed. If you suggest something else, I want to see code that works, not just ideas, since I don't think there is any less gross way of doing this. If you have just ideas, I'll not even consider them without a working implementation to go along with the idea. Sorry to be so blunt, but the last few nights on IRC plus past discussions has gotten me to this point of having this high a level of requirement. First some definitions for the following discussion. First, a library is a shared library that's linked to a binary. A binary is what is actually run. Recall that in elf the binary effectively controlls which libc is used. "old" means prior to all of this. "new" means after we commit this. How will this work? First, it defines __stdin, et al as aliases to elements of __sF so they are in effect of type FILE. It places __std* in our legacy branches. This allows for old binaries that are dynamically linked with against libraries that have been rebuilt to work, which was the problem with Peter's patches. Let's look at a few examples to see what will work if we go down this path and what will fail. Example one. Simple old binary linked to libc.so.3. With an old libc.so.3 installed on the system, this binary works. It references __sF. With a new libc.so.3 (after my patches are MFC'd), it still works because __sF hasn't changed at all. s/3/4/g and you get the same answer. Example two. Old binary linked to libc.so.4 and libcam.so.2 on a current system. Before the change this works now. libcam.so.2 and the old binary have referneces to __sF, libc.so.4 satisifies them. After I MFC the enclosed patch and install the resulting binary on my -current system, things still work since libcam.so.2 still has references to __sF as does the binary. If I then reimport peter's __std* patches[*], bump libc's major and rebuild the world (this will also be the same thing as running it on 5.0 release, when it is golden, btw) things still work. The binary still references __sF, so that part of it works. libcam.so.2 now contains references to the new __std*. the updated libc.so.4 can now satisfy those references, so it works. [*] and back out the hacks that green and I put in, changing the size of FILE, but not its layout. Case 3. I've installed a port that installs libfred.so.3 from 4.2 release. It contains __sF references. I have a binary (say barney) that links libfred.so.3 and libc.so.4. Things work now. I rebuild the world. Things still work because neither of the above has changed. Now let's say I want to build wilma that depends on libfred. When wilma is built, it will fail to run because it links against libfred.so.3 and libc.so.5.20010220. This libc doesn't have __sF, so it will fail at link time or run time. This is easy to fix. Just rebuild the port tht produced libfred.so.3. A new libfred.so.3 is installed. wilma will now run (maybe after being rebuilt). barney will also still run because it gets all the symbols it needs (including the new libfred.so.3). Case 4. I install a new -current system, and build everything from scratch. This just works. Warner P.S. I'm still testing this out, so issues may come up. I think it will all just work. Index: stdio/findfp.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/findfp.c,v retrieving revision 1.15 diff -u -r1.15 findfp.c --- stdio/findfp.c 2001/02/16 21:09:49 1.15 +++ stdio/findfp.c 2001/02/17 06:34:05 @@ -77,6 +77,24 @@ std(__SWR|__SNBF, STDERR_FILENO) }; +/* + * The following kludge is done to ensure enough binary compatibility + * with future versions of libc. Or rather it allows us to work with + * libraries that have been built with a newer libc that defines these + * symbols and expects libc to provide them. + */ +#ifdef __i386__ +__weak_reference(__sF, __stdin); +__weak_reference(__sF+88, __stdout); +__weak_reference(__sF+176, __stderr); +#endif + +#ifdef __alpha__ +__weak_reference(__sF, __stdin); +__weak_reference(__sF+152, __stdout); +__weak_reference(__sF+304, __stderr); +#endif + struct glue __sglue = { &uglue, 3, __sF }; static struct glue *lastglue = &uglue; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 22:44:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 52F6337B65D for ; Fri, 16 Feb 2001 22:44:32 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1H6i6W84653; Fri, 16 Feb 2001 23:44:09 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102170644.f1H6i6W84653@harmony.village.org> To: nate@yogotech.com (Nate Williams) Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Cc: Mark Murray , Dag-Erling Smorgrav , arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Feb 2001 11:02:10 MST." <14989.27426.877852.291707@nomad.yogotech.com> References: <14989.27426.877852.291707@nomad.yogotech.com> <200102161737.f1GHbQ946702@gratis.grondar.za> Date: Fri, 16 Feb 2001 23:44:06 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14989.27426.877852.291707@nomad.yogotech.com> Nate Williams writes: : > > I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) : > > disappear either. : > : > I'd love to see those go, myself. : : I'd be very angry to see them go. Not every FreeBSD machine is : connected to the internet. R* utilities are very commonly used, and : we're not gaining anything but removing them. : : Disabling them from /etc/inetd.conf is barely acceptable, IMO. I'd hate to see them go as well. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 22:48:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 1B5EF37B401 for ; Fri, 16 Feb 2001 22:48:23 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 902506A90D; Sat, 17 Feb 2001 17:18:18 +1030 (CST) Date: Sat, 17 Feb 2001 17:18:18 +1030 From: Greg Lehey To: Warner Losh Cc: Nate Williams , Mark Murray , Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: Wish List (was: Re: The /usr/bin/games bikeshed again) Message-ID: <20010217171818.F21615@wantadilla.lemis.com> References: <14989.27426.877852.291707@nomad.yogotech.com> <200102161737.f1GHbQ946702@gratis.grondar.za> <14989.27426.877852.291707@nomad.yogotech.com> <200102170644.f1H6i6W84653@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102170644.f1H6i6W84653@harmony.village.org>; from imp@harmony.village.org on Fri, Feb 16, 2001 at 11:44:06PM -0700 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 16 February 2001 at 23:44:06 -0700, Warner Losh wrote: > In message <14989.27426.877852.291707@nomad.yogotech.com> Nate Williams writes: >>>> I wouldn't be sorry to see the r* utilities (rsh, rcp, rmt...) >>>> disappear either. >>> >>> I'd love to see those go, myself. >> >> I'd be very angry to see them go. Not every FreeBSD machine is >> connected to the internet. R* utilities are very commonly used, and >> we're not gaining anything but removing them. >> >> Disabling them from /etc/inetd.conf is barely acceptable, IMO. > > I'd hate to see them go as well. "Me too" Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 22:50: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CA07537B401 for ; Fri, 16 Feb 2001 22:50:04 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1H6njW84709; Fri, 16 Feb 2001 23:49:47 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102170649.f1H6njW84709@harmony.village.org> To: Matt Dillon Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Cc: "David O'Brien" , arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Feb 2001 13:07:46 PST." <200102162107.f1GL7kO04369@earth.backplane.com> References: <200102162107.f1GL7kO04369@earth.backplane.com> <200102161917.f1GJHPl29820@cwsys.cwsent.com> <200102161932.f1GJWN002324@earth.backplane.com> <20010216124636.E22331@dragon.nuxi.com> Date: Fri, 16 Feb 2001 23:49:45 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102162107.f1GL7kO04369@earth.backplane.com> Matt Dillon writes: : So, I take it you want those in the 'wildly controversial' column. Yes. Even though I'm a security wonk, rsh, et al have their place in some environments. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 23:22:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id C921B37B4EC for ; Fri, 16 Feb 2001 23:22:17 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1H7MHm20405; Fri, 16 Feb 2001 23:22:17 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Feb 2001 23:22:17 -0800 (PST) From: Matt Dillon Message-Id: <200102170722.f1H7MHm20405@earth.backplane.com> To: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Summary of List of things to move from main tree to ports Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, here's my summary. Yah yah, I inject my own opinions. Too bad. This will be my last posting on the topic. Least Controversial: games There does not seem to be much resistance to the idea of moving most /usr/src/games out of the main source tree and into ports. People seem to content to argue about other things. My opinion is that while the base games are still fun to play, there are so many games in ports that are as interesting or more interesting that the usefullness of having the original set in the base tree is marginal at best, even if you play 'hack' all the time. My only exception is 'fortune', which many third party apps (like xscreensaver) just assume exists on the system. rdist (apparently already removed from current) Medium Controversial: UUCP (uucp, uucpd) Robert Watson suggests, and others agree that the best way to handle UUCP is to change the NO_UUCP make.conf option into a BUILD_UUCP make.conf option. I would interject that, in addition to that, we should not create the uucp directory hierarchy unless uucp is selected in make.conf (i.e. not create /var/spool/uucppublic, a directory which defaults to modes 777, by default). Robert Watson also makes the point about the suid/sgid nature of many uucp binaries, and I and others will attest to the fact that UUCP is simply not maintained anymore. That is a dangerous combination to have installed in the system by default. There are fewer people screaming for UUCP to stay in the base tree then, say, people screaming for rlogind to stay in the base tree. Despite Terry's waxing poetic about UUCP's dialup capabilities, every soul I know (except maybe Terry) who has ever used UUCP in the past no longer does (and I should know: I wrote AmigaUUCP!). However, if those people are going to make a big deal about it, I suppose we can take the intermediate step of having a BUILD_UUCP make.conf (opt-in) option for the next few years. Kerberos IV Robert Watson argues (several times) about the complexity of integrating certain packages, namely KRB4, into the system. A counter argument is made that such integration is not necessarily a good thing. I would interject that KRB4 is so undesireably complex that integration is pretty much the only way you can support it, which is why we should throw it out and push KRB5 the last few yards it needs to be pushed to get it in as well as KRB4. KRB4 is a nightmare, integrated or not. Lyndon Nerenberg provides an example - his shop - which relies on the massive integration provided in our KRB4 implementation. He makes a reasoned argument for GSSAPI. But it can also be argued fairly easily that GSSAPI is actually preventing us from moving forward with its extremely limited scope. It may not be a good idea to force oneself to stay in the past because the future doesn't support your favorite API. Terry brings up a good point in regards to PAM. I feel that PAM is the most likely future, but it can't be use to justify moving 'older' pieces off the system until the newer pieces actually use it in the proper way. That is, at the moment GSSAPI is more proven then PAM, but PAM has the momentum and will likely be able to take over completely sometime in the next few years. When that occurs, anyone still using KRB4 is going to be faced with a very tough decision. So as far as KRB4 goes, I think we are going to have to keep it around until PAM catches up and KRB5 reaches the same level of integration. I am personally amazed at KRB4's staying power, but the writing is on the wall. Highly Controversial: telnetd, rshd, rlogind, rexecd rmt, rcp, rlogin, rsh A number of people favor removing the server side utils. Virtually nobody favors removing the client side utils. Terry argues that he still uses the daemons (not a very good argument in my opinion), others argue that the daemons are useful within firewalled networks (also a terrible argument in my opinion). There was a reasonable argument by Nate in regards to mixed windows <-> UNIX networks where the windows boxes used the above standard utilities to access the UNIX boxes. While I will point out that it is relatively easy to use ssh on a windows box, it is still no where near as easy as it is to use ssh on a UNIX box. David O'Brien probably made the best argument, if you remove the all-caps phrases from his posting. The daemons are turned off by default, keeping the binaries around does not present a serious burden on the system. Yes, it could be argued that this slows the adoption of protocols like ssh, but the daemons are still used enough that we cannot justify removing them from the system. And, despite being old, the daemons do support kerberos connections as an option (though I will add: Not very well. There are terrible bugs with regards to streaming and EOF handling with the kerberized telnet, for example. It's good enough for terminal sessions but I don't trust them for anything else). ftp, ftpd Mostly specious arguments. There are obvious uses for ftp and even ftpd in regards to anonymous downloading. Since ftpd is most often used for anonymous operations on publically available files, there is no real argument for removing it even though some idiots will probably use it with sensitive materials. Nobody seriously argued for the removal of ftp, but that didn't stop others from freaking out and screaming loudly that it should stay in the system. sendmail bind I think only Cy Schubert is the only one in favor of moving sendmail and bind to ports. Most everyone else is very loud in wanting to keep it. However, even Cy is partial to using make.conf options to select what to build and/or install and others tend to agree that that is a reasonable approach. Chris brings up a very good point about certain major packages (e.g. sendmail) being actively maintained by committers whereas other packages do not have the same level of commitment. My opinion is that, like bind, sendmail is a core piece of the system. If we were to provide alternatives, they would also have to be brought into the main tree (e.g. on a vendor branch) and maintained as such. Then you could choose via rc.conf and you could disable elements with make.conf (unlike UUCP, which should be opt-in, if we are given sendmail & bind equivalents to choose from in the base system they should probably be opt-out in regards to (not) compiling them, then selected with rc.conf). I can see postfix being brought into the vendor branch and being maintained as the same level that sendmail is maintained. I don't really see qmail being maintainable at the same level that postfix is maintainable, and three MTAs in the base tree is probably too many. As Chris says, someone needs to be willing to seriously maintain it. Someone brought djbdns up. Security alone is not a good enough reason to try to bring something into the base tree. To be in the base tree the program must be supported and I don't know a single person willing to maintain (long term) the unreadable, uncommented djbdns code. I feel that the most likely course of action is that bind8 will eventually become bind9. While Paul does not produce the most secure code in the world, he's a lot easier to work with and he acknowledges that bind8 has reached the end of its usefullness. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 23:33:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 4D2E137B503 for ; Fri, 16 Feb 2001 23:33:30 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1H7WS952157; Sat, 17 Feb 2001 09:32:50 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102170732.f1H7WS952157@gratis.grondar.za> To: Jordan Hubbard Cc: arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] References: <98614.982362113@winston.osd.bsdi.com> In-Reply-To: <98614.982362113@winston.osd.bsdi.com> ; from Jordan Hubbard "Fri, 16 Feb 2001 14:21:53 PST." Date: Sat, 17 Feb 2001 09:32:59 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The needs of all these various interest groups are not mutually > exclusive. The problem is and always has been that instead of > starting new jihads concerning specific components, nobody really sits > down and says "Hmm, /usr/src as updated by cvsup is a good idea. > /usr/ports is also a good idea. In here somewhere is an even better > good idea which encompasses many of the best parts of both." Nail on head with very large hammer. > Trust me folks, there are MUCH BETTER mechanisms than ports and a > neatly organized /usr/src which would give us a more tree-structured > FreeBSD, with "minbin" at the very root and things like MTAs several > levels up, while also providing the nice free-standing taxonomy that > /usr/src does. We've learned a tremendous amount about source code > control and makefile wrappers over the last 9 years of this project, > we simply haven't really applied that knowledge to our process in any > truly significant ways. We just keep shoe-horning more shit into the > same shaped box and complaining that we're running out of room while > simultaneously defending the existing structures as somehow sacrosanct > or, at worst, simply needing a fresh coat of paint and some minor > remodeling. BAH! :) Right! We currently split the OS into two classes; src and ports. For a long time now I have had an idea for more of a continuum, and less of a dividing line. Basically it is this: The src and ports remain, but get redefined in a rather extreme way: src) is comprised of the truly basic parts of the OS (sort of in GNU terms) the fileutils, the textutils and the kernel. ports) becomes those parts which it can be assumed are of interest to extremely small numbers of people - CAD programs, experimental languages and the like. (the word "ports" as used to describe this set could be changed to something like "optional". In between these two are various (large) collections of things that are very popular, and are thus deserving of special treatment. Such things could(would?) be "b-maked but separate", and are chosen for their (almost) inevitable choice by large numbers of the user base. Included in this set would be things like: devel) gcc, g77, gas, binutils, &c perl5) base perl5, CPAN maintenance stuff. kerberosIV/KerberosV) with fixes to properly integrate into the "base". Apache) all-singing, all-dancing works-burger collection. [x]emacs) all-singing, all-dancing works-burger collection with MULE as an option. Jade/SGML/XML) all-singing etc. sendmail/postfix/qmail/uucp/popserver) (separately maintained) The above are currently very ably maintained as "pure" ports, and there are many more in the same sort of class, but I think you get the idea that they could be made "semi-base" in a sort of b-make tradition, and looked after as sort of half-ports, but better integrated than current ports (and in some cases, optionally built in a make world, depending on the tightness of integration). > I'd even be willing to take the opium pipe out of my mouth and write > down some of these grandiose claims in the form of a much clearer > prototype, but before spending that kind of energy on it I'd first > like to see some general sign that people aren't dead-set on arguing > about individual leaves rather than thinking about the whole tree for > a change. How's my above sound as a first kick (with no religion attached)? (I'd love to work on this as a project, BTW) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 16 23:43: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id F1F1D37B491 for ; Fri, 16 Feb 2001 23:42:58 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1H7ggP20563; Fri, 16 Feb 2001 23:42:42 -0800 (PST) (envelope-from dillon) Date: Fri, 16 Feb 2001 23:42:42 -0800 (PST) From: Matt Dillon Message-Id: <200102170742.f1H7ggP20563@earth.backplane.com> To: Mark Murray Cc: Jordan Hubbard , arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] References: <98614.982362113@winston.osd.bsdi.com> <200102170732.f1H7WS952157@gratis.grondar.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Right! : :We currently split the OS into two classes; src and ports. For a long :time now I have had an idea for more of a continuum, and less of a :dividing line. : :Basically it is this: : :The src and ports remain, but get redefined in a rather extreme way: I don't think this is possible. One of the biggest differences between src and ports is that src is audited to a much higher degree then ports. Ports is virtually unaudited. There is no continuum to speak of and I see no continuum on the horizon. Shoot, and I said the last posting was my last word. Ok, THIS posting is my last word! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 0:22: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id EEED437B4EC for ; Sat, 17 Feb 2001 00:22:02 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1H8LV952295; Sat, 17 Feb 2001 10:21:37 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102170821.f1H8LV952295@gratis.grondar.za> To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports References: <200102170722.f1H7MHm20405@earth.backplane.com> In-Reply-To: <200102170722.f1H7MHm20405@earth.backplane.com> ; from Matt Dillon "Fri, 16 Feb 2001 23:22:17 PST." Date: Sat, 17 Feb 2001 10:22:09 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My opinion is that while the base games are still fun to play, > there are so many games in ports that are as interesting or more > interesting that the usefullness of having the original set in > the base tree is marginal at best, even if you play 'hack' all I'd really like to see the wall between "base" and "ports" broken down. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 1:33:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id A655C37B491 for ; Sat, 17 Feb 2001 01:33:36 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1H9WvH02632; Sat, 17 Feb 2001 01:32:57 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Mark Murray Cc: arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] In-Reply-To: Message from Mark Murray of "Sat, 17 Feb 2001 09:32:59 +0200." <200102170732.f1H7WS952157@gratis.grondar.za> Date: Sat, 17 Feb 2001 01:32:57 -0800 Message-ID: <2628.982402377@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > We currently split the OS into two classes; src and ports. For a long > time now I have had an idea for more of a continuum, and less of a > dividing line. > > Basically it is this: > > The src and ports remain, but get redefined in a rather extreme way: I think you're on the right general track, you're just not being radical enough to reach the real prize at the bottom of this cereal box. :-) [Note to self: Do countries other than the USA put prizes in boxes of breakfast cereal? Must research this]. First, let me ask everyone to stop thinking about this in terms of the traditional /usr/src and /usr/ports dichotomy and start thinking about software from more of a 20,000 foot [6080 meter] level. When we talk about software around here, we generally mean one of three things: 1. The aging binaries we got from some distribution medium in pre-packaged form. 2. The binaries we just made ourselves using an automated build mechanism which gave us very little clue as to what was actually involved (and we like it that way). 3. The binaries we just made after doing open-heart surgery on some collection of bits, hoping to see how successful the operation was. Whichever of these 3 categories the bits may reside in, they also have some common requirements: A sensible organizational structure (taxonomy), a packaging scheme which makes it flexible and easy to acquire the bits and a way of keeping those bits updated over the net or from other media. The only thing which changes significantly in each category is the amount of "source" you have around and I think that one fact also pretty much shouts out the model we should be looking at. But first, let's go back to that list of common requirements. To satisfy them, let's first assume that we have a really sensible taxonomy for everything: The very minimum binary representation of FreeBSD (/boot, /sbin, /bin, /etc), the text formatting tools, the system libraries, the documentation, the toolchain, everything which should be broken out into a sub-category or set of sub-categories is properly identified and organized according to function. Let's also assume that /usr/ports and /usr/src have been slammed together in our global taxonomy and everything from "minFreeBSD" to "KDE 2" is represented somewhere on the chart. Finally, let's assume that we have fairly sophisticated packaging tools which can package up everything from binaries to sources to "cvs operations", e.g. the package extract actually results in a real-time cvsup/anoncvs checkout operation rather than storing a snapshot of the bits. Our updating tools would also be similarly capable of walking through our tree of well-organized stuff and doing the right thing automatically with some supplied update policy information. That's all a bit more in the way of infrastructure than we have now, but nothing completely out of the realm of reason to imagine our being able to implement. Having to use sysinstall to install one set of bits, pkg_add for another set and cvsup for yet another is part of the problem here and a schism in desperate need of unification. Getting back to the three listed categories, it's clear that for category one, the binary package, the user will expect to simply "add" the package and be done with it, no source being involved for the trade-off of potentially getting an old set of bits (but maybe that's the idea). For category two, the automated build, "package add" could actually result in the ports collection sequence of "go fetch some sources, unpack them, build them, and install them." There's absolutely no reason why some part of what we now traditionally think of as "/usr/src" couldn't be a *transient* item if all you wanted sources for was building binaries. For category three, the developer actually interested in sources, "package add" might mean "go cause these bits to be checked out of a server somewhere or unpack them from the package itself as a source snapshot [which can then be optionally updated later]." There's no reason why a "source package" couldn't also be hacked on and then checked back by a developer with a commit bit, it's all a question of making the infrastructure support it. As long as the bits appear in the appropriate places and the layout both makes sense and is buildable, perhaps with other necessary components being checked out on demand, all the advantages of a "static tree" are also maintained. Tracking -current or tracking -stable also becomes largely a question of what property you had set when you did your initial "pkg_add src-devel" and that's all you need to know. This also deals with long-standing religious wars over MTAs since doing "pkg_add src-qmail" will result in the qmail sources being added to the appropriate subdirectory of your source tree just like they always belonged there, any subsequent change check-ins causing the right thing to happen for that particular package. Maybe it gets checked into a CVS sub-repository we maintain or maybe it simply gets bundled up and submitted to the maintainer of qmail, many won't even care which so long as the system works reasonably well. In a design like this, all distinction between src and ports goes away and it largely comes down to how much source the user wants to have lying around - anything from all to none. Developers adding new stuff to this system simply have to make sure that it's properly fitted into the global hierachy and that it will build and install correctly from its assigned spot, dependencies and all. Whether its principal developer(s) then decide that the master sources should live on primarily as a tarball or in a CVS repository somewhere shouldn't be the end-user's concern at all. Just so long as the components the user has declared transient on their system stay transient and the components declared fixed have sources sitting in the appropriate subdirectories of /foo/src whenever they look, everybody is happy. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 1:41: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id 8BFA237B401 for ; Sat, 17 Feb 2001 01:41:06 -0800 (PST) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id EAA03788; Sat, 17 Feb 2001 04:35:39 -0500 (EST) Date: Sat, 17 Feb 2001 04:35:39 -0500 (EST) From: "Matthew N. Dodd" To: Mark Murray Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports In-Reply-To: <200102170821.f1H8LV952295@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Feb 2001, Mark Murray wrote: > I'd really like to see the wall between "base" and "ports" broken down. base system layered software packages 3rd party software packages Humm... I seem to recall another OS that did this sort of thing -20- years ago. I think the real issue is that not everything maintained in the source tree should be installed by default. We've already got a fairly coarse system that does this via the various Sysinstall packages. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 1:44:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id B13DE37B491 for ; Sat, 17 Feb 2001 01:44:42 -0800 (PST) Received: from elischer.org (i003-089.nv.iinet.net.au [203.59.3.89]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id RAA04084; Sat, 17 Feb 2001 17:44:15 +0800 Message-ID: <3A8E47DC.FAF7F962@elischer.org> Date: Sat, 17 Feb 2001 01:43:56 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Matthew N. Dodd" Cc: Mark Murray , Matt Dillon , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Matthew N. Dodd" wrote: > > On Sat, 17 Feb 2001, Mark Murray wrote: > > I'd really like to see the wall between "base" and "ports" broken down. > > base system > layered software packages > 3rd party software packages > > Humm... I seem to recall another OS that did this sort of thing -20- years > ago. I remember how ill I felt the first time I encountered a Unix system with no C compiler... > > I think the real issue is that not everything maintained in the source > tree should be installed by default. We've already got a fairly coarse > system that does this via the various Sysinstall packages. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 1:52:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id D9EB537B401 for ; Sat, 17 Feb 2001 01:52:18 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id CAA05958; Sat, 17 Feb 2001 02:46:47 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAA8eayHl; Sat Feb 17 02:46:39 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id CAA28641; Sat, 17 Feb 2001 02:51:57 -0700 (MST) From: Terry Lambert Message-Id: <200102170951.CAA28641@usr05.primenet.com> Subject: Re: Summary of List of things to move from main tree to ports To: winter@jurai.net (Matthew N. Dodd) Date: Sat, 17 Feb 2001 09:51:52 +0000 (GMT) Cc: mark@grondar.za (Mark Murray), dillon@earth.backplane.com (Matt Dillon), arch@FreeBSD.ORG In-Reply-To: from "Matthew N. Dodd" at Feb 17, 2001 04:35:39 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'd really like to see the wall between "base" and "ports" broken down. > > base system > layered software packages > 3rd party software packages > > Humm... I seem to recall another OS that did this sort of thing -20- years > ago. SCO did this. The source code for their system is up on their site, and has been for almost two years now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 2:41:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id BB3B637B503 for ; Sat, 17 Feb 2001 02:41:39 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3A2FE67021; Sat, 17 Feb 2001 02:41:39 -0800 (PST) Date: Sat, 17 Feb 2001 02:41:39 -0800 From: Kris Kennaway To: Jordan Hubbard Cc: Mark Murray , arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] Message-ID: <20010217024139.A84171@mollari.cthul.hu> References: <2628.982402377@winston.osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2628.982402377@winston.osd.bsdi.com>; from jkh@winston.osd.bsdi.com on Sat, Feb 17, 2001 at 01:32:57AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 17, 2001 at 01:32:57AM -0800, Jordan Hubbard wrote: > I think you're on the right general track, you're just not being > radical enough to reach the real prize at the bottom of this cereal > box. :-) [Note to self: Do countries other than the USA put prizes in > boxes of breakfast cereal? Must research this]. >=20 > First, let me ask everyone to stop thinking about this in terms of the > traditional /usr/src and /usr/ports dichotomy and start thinking about > software from more of a 20,000 foot [6080 meter] level. When we talk > about software around here, we generally mean one of three things: I think a lot of good things will become easy once we finally get an installer which is capable of treating packages on the same footing as source code distributions. That is the root of our problems, and until it goes away I can't see much being fixed. Has there been any progress from BSDi about this? ISTR some of your guys were working on it. Kris --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6jlViWry0BWjoQKURApLHAKDO00GbuX+M2Mmjs+Zp3/lE5kL9GgCgqRph bEAgDO0C4qAw/FGFmyCMHbA= =Nrys -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 2:50:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 8D64637B4EC for ; Sat, 17 Feb 2001 02:50:53 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1HAoDH02900; Sat, 17 Feb 2001 02:50:13 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Kris Kennaway Cc: Mark Murray , arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] In-Reply-To: Message from Kris Kennaway of "Sat, 17 Feb 2001 02:41:39 PST." <20010217024139.A84171@mollari.cthul.hu> Date: Sat, 17 Feb 2001 02:50:13 -0800 Message-ID: <2896.982407013@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think a lot of good things will become easy once we finally get an > installer which is capable of treating packages on the same footing as > source code distributions. That is the root of our problems, and > until it goes away I can't see much being fixed. Well, I think that's true in some sense but also represents putting the cart before the horse if you take this point too literally. The problem really isn't in the installer since the list of choices it presents simply reflect the degree of "componentization" already in the system, and much of what sysinstall currently does by way of adding packages is just a front-end interface to the functionality provided by pkg_add. The installer is supposed to be little more than a fancy wrapper, not a major instrument of policy. To put it another way, if you create a clean organizational structure with the appropriate XML metadata describing it (vs our very simplistic INDEX type of information now) then the installer WILL treat the packages and source code/binary distributions exactly the same because the underlying framework it depends on will see no distinction itself. The actual UI work in building menus and list boxes out of the index information provided is pretty trivial by comparison. > Has there been any progress from BSDi about this? ISTR some of your > guys were working on it. They're actually working on the update mechanism, though by "they" I should also say "he" since I lost half the team when it went back to college. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 3:22: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 4E74737B491 for ; Sat, 17 Feb 2001 03:21:59 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BAD8B67021; Sat, 17 Feb 2001 03:21:58 -0800 (PST) Date: Sat, 17 Feb 2001 03:21:58 -0800 From: Kris Kennaway To: Jordan Hubbard Cc: Kris Kennaway , Mark Murray , arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] Message-ID: <20010217032158.A85153@mollari.cthul.hu> References: <2896.982407013@winston.osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2896.982407013@winston.osd.bsdi.com>; from jkh@winston.osd.bsdi.com on Sat, Feb 17, 2001 at 02:50:13AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 17, 2001 at 02:50:13AM -0800, Jordan Hubbard wrote: > Well, I think that's true in some sense but also represents putting > the cart before the horse if you take this point too literally. The > problem really isn't in the installer since the list of choices it > presents simply reflect the degree of "componentization" already in > the system, and much of what sysinstall currently does by way of > adding packages is just a front-end interface to the functionality > provided by pkg_add. The installer is supposed to be little more than > a fancy wrapper, not a major instrument of policy. Well, currently the installer does impose policy by virtue of the source components being in one menu and the ports in another, with all of the "src-like" bits like 44bsd-more, 44bsd-csh, etc, jumbled in amongst the crap like GNOME and four million versions of breakout. So under the current regime we have to work within the confines of source distributions being afforded greater status than ports. That's where the troubles come from, and I agree this needs to change. > To put it another way, if you create a clean organizational structure > with the appropriate XML metadata describing it (vs our very > simplistic INDEX type of information now) then the installer WILL > treat the packages and source code/binary distributions exactly the > same because the underlying framework it depends on will see no > distinction itself. The actual UI work in building menus and list > boxes out of the index information provided is pretty trivial by > comparison. That might be one way to go, but it's clear to me that any change needs to become manifest in sysinstall, being the interface to installing the various bits of software, and the rest will attend to itself. The most obvious way to handle this (not requiring any fancy XML ports tree rearchitecturing) would be to just rip out the sysinstall code which treats distributions separately and rewrite it to use packages. There is nothing preventing us from installing the base system as packages right now, except that sysinstall demands those bits to be distributions. > > Has there been any progress from BSDi about this? ISTR some of your > > guys were working on it. >=20 > They're actually working on the update mechanism, though by "they" I > should also say "he" since I lost half the team when it went back to > college. :) Good to hear there's continued progress in the related area. Kris --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6jl7VWry0BWjoQKURAqtQAJ4yxELMxU04kb7DUyjX52SdNCnW9gCdGntE vGS1OeemlpJJNMb//4HlOSk= =kUc+ -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 5:16:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 6AF4D37B401 for ; Sat, 17 Feb 2001 05:16:24 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.11.1/8.11.1) id f1HDDmH22011; Sat, 17 Feb 2001 08:13:48 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200102171313.f1HDDmH22011@hda.hda.com> Subject: Re: Summary of List of things to move from main tree to ports In-Reply-To: <200102170722.f1H7MHm20405@earth.backplane.com> from Matt Dillon at "Feb 16, 2001 11:22:17 pm" To: Matt Dillon Date: Sat, 17 Feb 2001 08:13:48 -0500 (EST) Cc: arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok, here's my summary. Yah yah, I inject my own opinions. Too bad. > This will be my last posting on the topic. > > > Least Controversial: > > games > ... > ... My only exception is 'fortune', which many third party > apps (like xscreensaver) just assume exists on the system. Does anyone else expect "factor"? It is the only thing I ever use in games and there is one place I'd have to start installing it. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 5:36:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4792837B4EC for ; Sat, 17 Feb 2001 05:36:55 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA19755; Sat, 17 Feb 2001 14:36:45 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Matt Dillon Cc: Cy Schubert - ITSD Open Systems Group , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) References: <200102161508.f1GF8DR28339@cwsys.cwsent.com> <200102161741.f1GHf0A97803@earth.backplane.com> From: Dag-Erling Smorgrav Date: 17 Feb 2001 14:36:45 +0100 In-Reply-To: Matt Dillon's message of "Fri, 16 Feb 2001 09:41:00 -0800 (PST)" Message-ID: Lines: 8 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon writes: > * All games except fortune Some of the games are actually utilities (rot13, primes etc.) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 6:16:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8291037B401 for ; Sat, 17 Feb 2001 06:16:28 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1HEE7h71993; Sat, 17 Feb 2001 09:14:09 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 17 Feb 2001 09:14:07 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: Cy.Schubert@uumail.gov.bc.ca, Matt Dillon , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: In-Reply-To: <200102170031.RAA17052@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Feb 2001, Terry Lambert wrote: > > > Security is always a tradeoff between usability and safety. > > > > I keep hearing this concept bandied about like it was pure truth, and > > frankly, I don't think it is. Some of aspects of the security problem > > reduce usability, but others don't. It improves security to correctly > > implement string handling in network daemons. But it also improves > > correctness, consistency and stability, and those are important components > > of having a usable system. So I think that the above statement is really > > a common misconception. I'd dig up some dead Greeks, but it seems like a > > lot of trouble simply to state: > > > > Security can cause reduced usability. > > Security can cause increased usability. > If your problem with these things is string handling, then fix the > string handling; there's a lot of code we could dike out as being > "insecure", but which we leave lying around. Funny, I've been arguing much the same thing, in two forms: 1) Keep it in the tree but improve installation and build modularity, because integrated software is more likely to be a part of the system security design 2) Keep it in the tree but fix it, and require higher standards for developers adding new code so that the code doesn't get "bad" in the first place So I think you might be arguing with the wrong person. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 6:19:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id C0D0737B4EC for ; Sat, 17 Feb 2001 06:19:02 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id GAA06763; Sat, 17 Feb 2001 06:18:32 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda06761; Sat Feb 17 06:18:23 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1HEIIL88450; Sat, 17 Feb 2001 06:18:18 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdw88444; Sat Feb 17 06:18:13 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1HEICF38480; Sat, 17 Feb 2001 06:18:12 -0800 (PST) Message-Id: <200102171418.f1HEICF38480@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdO38471; Sat Feb 17 06:17:38 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Mark Murray Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports In-reply-to: Your message of "Sat, 17 Feb 2001 10:22:09 +0200." <200102170821.f1H8LV952295@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Feb 2001 06:17:38 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102170821.f1H8LV952295@gratis.grondar.za>, Mark Murray writes: > > My opinion is that while the base games are still fun to play, > > there are so many games in ports that are as interesting or more > > interesting that the usefullness of having the original set in > > the base tree is marginal at best, even if you play 'hack' all > > I'd really like to see the wall between "base" and "ports" broken down. Count this as two votes. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC > > M > -- > Mark Murray > Warning: this .sig is umop ap!sdn > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 6:27:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0931C37B4EC for ; Sat, 17 Feb 2001 06:27:24 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1HEQvh72057; Sat, 17 Feb 2001 09:26:57 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 17 Feb 2001 09:26:57 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matt Dillon Cc: Mark Murray , Jordan Hubbard , arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] In-Reply-To: <200102170742.f1H7ggP20563@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001, Matt Dillon wrote: > :We currently split the OS into two classes; src and ports. For a long > :time now I have had an idea for more of a continuum, and less of a > :dividing line. > : > :Basically it is this: > : > :The src and ports remain, but get redefined in a rather extreme way: > > I don't think this is possible. One of the biggest differences between > src and ports is that src is audited to a much higher degree then > ports. Ports is virtually unaudited. There is no continuum to speak > of and I see no continuum on the horizon. > > Shoot, and I said the last posting was my last word. Ok, THIS posting > is my last word! Well, I think the problem is that everyone sees src and ports in a particular light, whereas there are a number of accesses to compare them on that are relevant. I'll list a few that I think are interesting, but part of this is a response to Jordan's comment and a suggestion that if the "src" and "ports" groupings of features are somewhat arbitrary and can always be moved around: o With src/, you get complete revision control of your modifications and the base code in question, including a fair amount of magic in the form of vendor branches for remerging local changes. o Complete source revision gives you a high level of reproduceability for a release, or for binary updates (a service that we'd like to be able to provide). o With src/ you get integration of the source in the tree allowing you to build the complete system based purely on CVS checkouts and updates, meaning that you don't rely on online source distribution during building, and are not vulnerable to the infamous checksum change o With src/, there's are coordinated attempts to address the source upgrade issue, and documentation of the upgrade issues, well as an attempt to provide documentation and tools for improving configuration updates o We expect that all src/ developers be in touch with the developer community and get approval for large changes in source code, and increasingly, auditing of that code. o We expect a higher level of security awareness in src/ code, and the security-officer is expected to provide a higher level of support for src/ o With the ports/ tree, it's easier to allow third parties to maintain their build compatibility changes without being tightly integrated into the FreeBSD developer community o With ports/, it's easier to allow users to customize the build options for software when they install it o With ports/, it's easier to make modular binary install chunks o With ports/, it's easier to represent build and install dependencies between arbitrary components o It's easier to imagine a *BSD communal ports/packages collection than a single *BSD src/ tree with ifdefs. An observation that Jordan and others have made is that you can distinguish source structure and install-time modularity issues, meaning that it's possible to imagine having the tight integration of sendmail and bind into the source tree, and related local patches and reproduceable source integration / auditing, while maintaing packages-like install-time choices and bundling. A lot of the reasons that people argue for removing code from the tree relate to the desire for high install-time modularity, and a lot of the reasons people argue for inclusion in the source tree are tight source integration, reproduceability, and configuration merging and management. We can have both you know. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 6:56:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id A739137B491 for ; Sat, 17 Feb 2001 06:56:23 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 92BFC18C97; Sat, 17 Feb 2001 08:56:22 -0600 (CST) Date: Sat, 17 Feb 2001 08:56:22 -0600 From: "Jacques A. Vidrine" To: Matt Dillon Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010217085622.A37238@spawn.nectar.com> References: <200102170722.f1H7MHm20405@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102170722.f1H7MHm20405@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Feb 16, 2001 at 11:22:17PM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 11:22:17PM -0800, Matt Dillon wrote: [snip] > Terry brings up a good point in regards to PAM. I feel that PAM > is the most likely future, but it can't be use to justify moving > 'older' pieces off the system until the newer pieces actually use > it in the proper way. That is, at the moment GSSAPI is more > proven then PAM, but PAM has the momentum and will likely be able > to take over completely sometime in the next few years. When > that occurs, anyone still using KRB4 is going to be faced with a > very tough decision. PAM does not and cannot provide the same functionality as the Kerberos API, GSS-API or SASL. PAM is targetted at interactive authentication -- give it a username and password, and return yes/no indicating authentication success or failure [1]. Once authentication is done, PAM is no longer involved (except for a possible clean-up when we log out -- though this is commonly not implemented). The other mechanisms (particularly Kerberos and GSS-API) do not concern themselves with initial authentication, but rather with handling the secure transfer of data between applications, including encryption and credential forwarding and such. So, to repeat: PAM and GSS-API are orthogonal. One is not going to ``take over completely'' at the expense of the other. Even SASL and GSS-API don't exactly compete -- to an extent, SASL is layered over GSS-API. > Highly Controversial: > > telnetd, rshd, rlogind, rexecd > rmt, rcp, rlogin, rsh > > A number of people favor removing the server side utils. Virtually > nobody favors removing the client side utils. [snip] > David O'Brien probably made the best argument, if you remove the > all-caps phrases from his posting. The all-caps should be retained. :-) Expect jihad if these are touched. Well, this _is_ the highly controversial section. > The daemons are turned off by default, keeping the binaries > around does not present a serious burden on the system. Yes, it > could be argued that this slows the adoption of protocols like > ssh, Some of us do not believe that ssh is the end-all and that slowing its adoption is a non-issue. > but the daemons are still used enough that we cannot justify > removing them from the system. And, despite being old, the > daemons do support kerberos connections as an option (though I > will add: Not very well. There are terrible bugs with regards > to streaming and EOF handling with the kerberized telnet, for > example. It's good enough for terminal sessions but I don't > trust them for anything else). If these problems exist, they are problems with the implementations in our base system and should be fixed like any other bug. I've used MIT's Kerberized versions of these utilities in the past with great success. I currently use the Heimdal versions, again with great success. Further, Kerberos is not the only way to get security and encryption with, say, TELNET. Other GSS-API implementations can be plugged in quite easily, such as X.509/SSL or DCE. (We have OpenSSL in the base now -- it probably makes sense to add this support to these daemons at some point.) Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org [1] This isn't strictly true -- one isn't limited to just username/password. Stuff like S/Key can also be supported. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 7: 4:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 9B8B137B503; Sat, 17 Feb 2001 07:04:54 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA06884; Sat, 17 Feb 2001 07:04:54 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda06882; Sat Feb 17 07:04:36 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1HF4Vt88641; Sat, 17 Feb 2001 07:04:31 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpds88639; Sat Feb 17 07:04:14 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1HF4DY38770; Sat, 17 Feb 2001 07:04:13 -0800 (PST) Message-Id: <200102171504.f1HF4DY38770@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdR38762; Sat Feb 17 07:03:21 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Robert Watson Cc: Matt Dillon , Mark Murray , Jordan Hubbard , arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] In-reply-to: Your message of "Sat, 17 Feb 2001 09:26:57 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Feb 2001 07:03:21 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Robe rt Watson writes: [many good comments removed] > An observation that Jordan and others have made is that you can > distinguish source structure and install-time modularity issues, meaning > that it's possible to imagine having the tight integration of sendmail and > bind into the source tree, and related local patches and reproduceable > source integration / auditing, while maintaing packages-like install-time > choices and bundling. A lot of the reasons that people argue for removing > code from the tree relate to the desire for high install-time modularity, > and a lot of the reasons people argue for inclusion in the source tree are > tight source integration, reproduceability, and configuration merging and > management. We can have both you know. :-) You've hit the nail right on the head. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 7: 8:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 1556037B491 for ; Sat, 17 Feb 2001 07:08:38 -0800 (PST) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id PAA05569; Sat, 17 Feb 2001 15:06:06 GMT (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id PAA86631; Sat, 17 Feb 2001 15:05:29 GMT (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <200102170722.f1H7MHm20405@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 17 Feb 2001 15:05:29 +0000 To: Matt Dillon From: Bob Bishop Subject: Re: Summary of List of things to move from main tree to ports Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, At 23:22 -0800 16/2/01, Matt Dillon wrote: >[...] >Medium Controversial: > > UUCP (uucp, uucpd) We've still got client sites with UUCP mail feeds because there isn't an economic alternative. I say move it to ports, at least that way we can install a binary package and we don't have to dick around building stuff. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 7:23:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id BEF3337B4EC for ; Sat, 17 Feb 2001 07:23:07 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1HFML953484; Sat, 17 Feb 2001 17:22:21 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102171522.f1HFML953484@gratis.grondar.za> To: "Matthew N. Dodd" Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports References: In-Reply-To: ; from "Matthew N. Dodd" "Sat, 17 Feb 2001 04:35:39 EST." Date: Sat, 17 Feb 2001 17:22:58 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, 17 Feb 2001, Mark Murray wrote: > > I'd really like to see the wall between "base" and "ports" broken down. > > base system > layered software packages > 3rd party software packages Yeah! Sorta! > Humm... I seem to recall another OS that did this sort of thing -20- years > ago. > > I think the real issue is that not everything maintained in the source > tree should be installed by default. We've already got a fairly coarse > system that does this via the various Sysinstall packages. The "base" should be pretty compulsory, the "layered" stuff is "maintained but optional", and '3rd party' is like what we have in ports now, but mostly only the smaller stuff. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 7:23:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B650D37B401 for ; Sat, 17 Feb 2001 07:23:38 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1HFMuh72494; Sat, 17 Feb 2001 10:22:57 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 17 Feb 2001 10:22:56 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Jacques A. Vidrine" Cc: Matt Dillon , Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports In-Reply-To: <20010217085622.A37238@spawn.nectar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Feb 2001, Jacques A. Vidrine wrote: > PAM does not and cannot provide the same functionality as the Kerberos > API, GSS-API or SASL. PAM is targetted at interactive authentication -- > give it a username and password, and return yes/no indicating > authentication success or failure [1]. Once authentication is done, PAM > is no longer involved (except for a possible clean-up when we log out -- > though this is commonly not implemented). Generally speaking, I agree with your statements on the relationships between GSS-API, SASL, PAM, et al, except with regards to your summary of PAM. There are actually additional things that PAM can be involved in, including the setup and tear-down of sessions, login authorization, management of local credentials, and accounting. That said, we don't do most of these with PAM {yet, right now}, but we should be moving in that direction. Especially given that our pam manpage claims that we do :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 7:32:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (pool240-tch-1.Sofia.0rbitel.net [212.95.170.240]) by hub.freebsd.org (Postfix) with SMTP id ACBD637B4EC for ; Sat, 17 Feb 2001 07:32:11 -0800 (PST) Received: (qmail 930 invoked by uid 1000); 17 Feb 2001 15:30:19 -0000 Date: Sat, 17 Feb 2001 17:30:19 +0200 From: Peter Pentchev To: Matt Dillon Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010217173019.A431@ringworld.oblivion.bg> Mail-Followup-To: Matt Dillon , Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG References: <200102170722.f1H7MHm20405@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102170722.f1H7MHm20405@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Feb 16, 2001 at 11:22:17PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 11:22:17PM -0800, Matt Dillon wrote: > Ok, here's my summary. Yah yah, I inject my own opinions. Too bad. > This will be my last posting on the topic. > > > Least Controversial: > > Medium Controversial: > > UUCP (uucp, uucpd) > [snip] > > There are fewer people screaming for UUCP to stay in the base tree > then, say, people screaming for rlogind to stay in the base tree. > Despite Terry's waxing poetic about UUCP's dialup capabilities, > every soul I know (except maybe Terry) who has ever used UUCP in the > past no longer does (and I should know: I wrote AmigaUUCP!). > However, if those people are going to make a big deal about it, > I suppose we can take the intermediate step of having a BUILD_UUCP > make.conf (opt-in) option for the next few years. Just a minor comment-with-a-question. What is UUCP used for - mainly mail? If so, then here's a datapoint - about two years ago I took part in converting an existing UUCP mail transfer config to one using fetchmail. Quite simple - invoke fetchmail -d from the PPP link-up script, kill it in the link-down script in such a way that it sends a QUIT to avoid message duplicates. There were a couple of other issues too, but in the end, it all started working, and it's been working flawlessly for the past two years. When I compared a five-line .fetchmailrc to the UUCP configuration (that I, admittedly, did not quite understand, since I had had no part in setting it up), I was, like.. well, you can imagine :) G'luck, Peter -- The rest of this sentence is written in Thailand, on To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 7:54:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 1B7D537B4EC; Sat, 17 Feb 2001 07:54:38 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 67F8118C97; Sat, 17 Feb 2001 09:54:34 -0600 (CST) Date: Sat, 17 Feb 2001 09:54:34 -0600 From: "Jacques A. Vidrine" To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010217095434.A37535@spawn.nectar.com> References: <20010217085622.A37238@spawn.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Sat, Feb 17, 2001 at 10:22:56AM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 17, 2001 at 10:22:56AM -0500, Robert Watson wrote: > On Sat, 17 Feb 2001, Jacques A. Vidrine wrote: > > > PAM does not and cannot provide the same functionality as the Kerberos > > API, GSS-API or SASL. PAM is targetted at interactive authentication -- > > give it a username and password, and return yes/no indicating > > authentication success or failure [1]. Once authentication is done, PAM > > is no longer involved (except for a possible clean-up when we log out -- > > though this is commonly not implemented). > > Generally speaking, I agree with your statements on the relationships > between GSS-API, SASL, PAM, et al, except with regards to your summary of > PAM. There are actually additional things that PAM can be involved in, > including the setup and tear-down of sessions, login authorization, > management of local credentials, and accounting. I think we are in violent agreement -- I elided the details in order to concentrate on the main point, which is a misconception that PAM could somehow provide GSS-API-like functionality: data integrity and privacy. This is outside the scope of PAM, just as much of what PAM does do is outside the scope of GSS-API and Kerberos. I'm repeating myself. :-) Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 9:14:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 784F237B401 for ; Sat, 17 Feb 2001 09:14:56 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA07990; Sat, 17 Feb 2001 10:14:18 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id KAA03926; Sat, 17 Feb 2001 10:14:15 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14990.45415.531767.116635@nomad.yogotech.com> Date: Sat, 17 Feb 2001 10:14:15 -0700 (MST) To: Terry Lambert Cc: winter@jurai.net (Matthew N. Dodd), mark@grondar.za (Mark Murray), dillon@earth.backplane.com (Matt Dillon), arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports In-Reply-To: <200102170951.CAA28641@usr05.primenet.com> References: <200102170951.CAA28641@usr05.primenet.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I'd really like to see the wall between "base" and "ports" broken down. > > > > base system > > layered software packages > > 3rd party software packages > > > > Humm... I seem to recall another OS that did this sort of thing -20- years > > ago. > > SCO did this. Sys III did this, ~20 years ago. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 10:59:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 14EF637B401 for ; Sat, 17 Feb 2001 10:59:40 -0800 (PST) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id f1HIw3I05937 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 17 Feb 2001 19:58:06 +0100 (MET) Received: from cicely5.cicely.de (cicely5.cicely.de [fec0:0:0:104::5]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id f1HIwVP20361 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sat, 17 Feb 2001 19:58:39 +0100 (CET) Received: (from ticso@localhost) by cicely5.cicely.de (8.11.1/8.11.1) id f1HIwLE37457; Sat, 17 Feb 2001 19:58:22 +0100 (CET) (envelope-from ticso) Date: Sat, 17 Feb 2001 19:58:20 +0100 From: Bernd Walter To: Peter Pentchev Cc: Matt Dillon , Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010217195820.A37125@cicely5.cicely.de> References: <200102170722.f1H7MHm20405@earth.backplane.com> <20010217173019.A431@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010217173019.A431@ringworld.oblivion.bg>; from roam@orbitel.bg on Sat, Feb 17, 2001 at 05:30:19PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 17, 2001 at 05:30:19PM +0200, Peter Pentchev wrote: > On Fri, Feb 16, 2001 at 11:22:17PM -0800, Matt Dillon wrote: > > Ok, here's my summary. Yah yah, I inject my own opinions. Too bad. > > This will be my last posting on the topic. > > > > > > Least Controversial: > > > > Medium Controversial: > > > > UUCP (uucp, uucpd) > > > [snip] > > > > There are fewer people screaming for UUCP to stay in the base tree > > then, say, people screaming for rlogind to stay in the base tree. > > Despite Terry's waxing poetic about UUCP's dialup capabilities, > > every soul I know (except maybe Terry) who has ever used UUCP in the > > past no longer does (and I should know: I wrote AmigaUUCP!). > > However, if those people are going to make a big deal about it, > > I suppose we can take the intermediate step of having a BUILD_UUCP > > make.conf (opt-in) option for the next few years. > > Just a minor comment-with-a-question. What is UUCP used for - mainly mail? > If so, then here's a datapoint - about two years ago I took part in > converting an existing UUCP mail transfer config to one using fetchmail. > Quite simple - invoke fetchmail -d from the PPP link-up script, kill it > in the link-down script in such a way that it sends a QUIT to avoid > message duplicates. There were a couple of other issues too, but in > the end, it all started working, and it's been working flawlessly for > the past two years. > > When I compared a five-line .fetchmailrc to the UUCP configuration > (that I, admittedly, did not quite understand, since I had had no part > in setting it up), I was, like.. well, you can imagine :) You have to use special additions so that fetchmail get get at the envelope recepient. UUCP is still a cool and fazcination thing. UUCP can handle remote command execution of offline systems independend of the existence of an IP configuration. We have customers fetching news and mail via direct UUCP (without IP). I can easily queue thing like pintjobs on an mobile system just to be automaticaly tranfered and executed once I have the ability. That said - UUCP is far away from beeing part of todays Unix philosophie and a globaly writeable directory is bad thing for several reasons. I want to be able to use it but it hasn't to be as part of the base system. It needs to be configured before any sensefull use of it and installing a package/port is not a big thing. My vote: Make a port out of uucp and keep r*-services. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 11:28:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 8A78637B401 for ; Sat, 17 Feb 2001 11:28:56 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id EA390EFE; Sat, 17 Feb 2001 11:28:51 -0800 (PST) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id LAA17551; Sat, 17 Feb 2001 11:28:50 -0800 (PST) Message-ID: <3A8ED0EF.23FF785C@cup.hp.com> Date: Sat, 17 Feb 2001 11:28:47 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jordan Hubbard Cc: arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] References: <2628.982402377@winston.osd.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan Hubbard wrote: > > box. :-) [Note to self: Do countries other than the USA put prizes in > boxes of breakfast cereal? Must research this]. I know that in The Netherlands these boxes contain breakfast cereal. I know it always made me happy :-) -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 11:47:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 7AF2737B4EC for ; Sat, 17 Feb 2001 11:47:21 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1HJkbH06909; Sat, 17 Feb 2001 11:46:37 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Kris Kennaway Cc: Mark Murray , arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] In-Reply-To: Message from Kris Kennaway of "Sat, 17 Feb 2001 03:21:58 PST." <20010217032158.A85153@mollari.cthul.hu> Date: Sat, 17 Feb 2001 11:46:37 -0800 Message-ID: <6905.982439197@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well, currently the installer does impose policy by virtue of the > source components being in one menu and the ports in another, with > all of the "src-like" bits like 44bsd-more, 44bsd-csh, etc, jumbled in > amongst the crap like GNOME and four million versions of breakout. So Again, this isn't the installer at work. Those components are *already* broken out into separate pieces and all the installer does is reflect the existing status quo. Sure, I could have tried to paper over the differences by having the installer invoke the appropriate installation magic behind the users back and create the illusion of a unified front, but we're talking about a lot of work to maintain an illusion which only collapses the minute the user starts thinking about updating those components anyway. > That might be one way to go, but it's clear to me that any change > needs to become manifest in sysinstall, being the interface to > installing the various bits of software, and the rest will attend to > itself. I really think you're conceptualizing this backwards. :) > The most obvious way to handle this (not requiring any fancy XML ports > tree rearchitecturing) would be to just rip out the sysinstall code > which treats distributions separately and rewrite it to use packages. Perhaps obvious, but not correct. The reason sysinstall hasn't used packages for the base system all along is due to the temporary space requirements of packages. The extraction technique used by pkg_add was always aimed at small stuff (a bad design I've already described and lambasted more than once in this forum) and there's just not enough room to have "base" transit through /tmp or even /usr/tmp first. Go UTSL for pkg_add if you don't believe me. :) > There is nothing preventing us from installing the base system as > packages right now, except that sysinstall demands those bits to be > distributions. I wish that were true. :( However, even that would only be a stop-gap measure since we're still looking for something which incorporates sources, binary packages and "distributions" into one unified design here. What you and Marc are proposing doesn't represent the true goal, it's just another step along the "hack it some more" path and I'd like to get off that one now. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 12:40: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 4358037B401 for ; Sat, 17 Feb 2001 12:40:01 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1HKdL954630; Sat, 17 Feb 2001 22:39:22 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102172039.f1HKdL954630@gratis.grondar.za> To: Bernd Walter Cc: arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports References: <20010217195820.A37125@cicely5.cicely.de> In-Reply-To: <20010217195820.A37125@cicely5.cicely.de> ; from Bernd Walter "Sat, 17 Feb 2001 19:58:20 +0100." Date: Sat, 17 Feb 2001 22:39:57 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My vote: Make a port out of uucp and keep r*-services. Please try quite hard to break with the binary "base-or-port" decision; the trend of the discussion is a much more fluid range of options. These options may not exist now, but it looks like there is enough sympaty to make them exist. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 15:20: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 89DE637B4EC for ; Sat, 17 Feb 2001 15:20:00 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id QAA13097; Sat, 17 Feb 2001 16:14:59 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAgVaqEz; Sat Feb 17 16:14:50 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA11294; Sat, 17 Feb 2001 16:19:46 -0700 (MST) From: Terry Lambert Message-Id: <200102172319.QAA11294@usr05.primenet.com> Subject: GSS-API and PAM (was list 'o things) To: n@nectar.com (Jacques A. Vidrine) Date: Sat, 17 Feb 2001 23:19:46 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <20010217085622.A37238@spawn.nectar.com> from "Jacques A. Vidrine" at Feb 17, 2001 08:56:22 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > PAM does not and cannot provide the same functionality as the Kerberos > API, GSS-API or SASL. PAM is targetted at interactive authentication -- > give it a username and password, and return yes/no indicating > authentication success or failure [1]. Once authentication is done, PAM > is no longer involved (except for a possible clean-up when we log out -- > though this is commonly not implemented). Please see either of: http://www.opengroup.org/onlinepubs/008329799/ http://www.kernel.org/pub/linux/libs/pam/pre/doc/xsso.ps.gz for the XSSO (X/Open Single Sign On service) PAM documentation. In particular, please look at the PAM API and SPI, and at the session management functions and session management module functions. > The other mechanisms (particularly Kerberos and GSS-API) do not concern > themselves with initial authentication, but rather with handling the > secure transfer of data between applications, including encryption and > credential forwarding and such. PAM concerns itself with five different types of service modules: Authentication (which is the one you were talking about), account management, session management, and mapping. It's true that Linux does not implement GSS-API and PAM integration, but it _is_ possible to put one under the other. > So, to repeat: PAM and GSS-API are orthogonal. One is not going to > ``take over completely'' at the expense of the other. Even SASL and > GSS-API don't exactly compete -- to an extent, SASL is layered over > GSS-API. It was my impression that XSSO had extended PAM to the point that it incorporates GSS-API functionality; yeah, I know it's not RFC 15xx compliant, but it doesn't really matter: it's a defacto standard. > Further, Kerberos is not the only way to get security and encryption > with, say, TELNET. Other GSS-API implementations can be plugged in > quite easily, such as X.509/SSL or DCE. (We have OpenSSL in the base > now -- it probably makes sense to add this support to these daemons at > some point.) Yes. RSA is specifically mentioned as a Kerberos option for GSS-API, in the original documents. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 15:32:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id C4FEE37B491 for ; Sat, 17 Feb 2001 15:32:23 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0CE8867046; Sat, 17 Feb 2001 15:32:23 -0800 (PST) Date: Sat, 17 Feb 2001 15:32:22 -0800 From: Kris Kennaway To: Jordan Hubbard Cc: Mark Murray , arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] Message-ID: <20010217153222.B8519@mollari.cthul.hu> References: <6905.982439197@winston.osd.bsdi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="uQr8t48UFsdbeI+V" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6905.982439197@winston.osd.bsdi.com>; from jkh@winston.osd.bsdi.com on Sat, Feb 17, 2001 at 11:46:37AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 17, 2001 at 11:46:37AM -0800, Jordan Hubbard wrote: > > There is nothing preventing us from installing the base system as > > packages right now, except that sysinstall demands those bits to be > > distributions. >=20 > I wish that were true. :( However, even that would only be a stop-gap > measure since we're still looking for something which incorporates > sources, binary packages and "distributions" into one unified design > here. What you and Marc are proposing doesn't represent the true > goal, it's just another step along the "hack it some more" path and > I'd like to get off that one now. So we're again off down that mythical PackageNG brick road again? Forgive me for being cynical that anything will come of it this iteration either :-( Kris --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6jwoGWry0BWjoQKURAicIAJ9WD8QK/Cb67DbPW5CMSKE3e+XETgCgmqGL /ik87esowg6fTGlFe8IHS0Y= =N4Q9 -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 15:50:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 76A8137B401 for ; Sat, 17 Feb 2001 15:50:12 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA21294; Sat, 17 Feb 2001 16:44:40 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAwlaaHP; Sat Feb 17 16:44:30 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA11724; Sat, 17 Feb 2001 16:49:58 -0700 (MST) From: Terry Lambert Message-Id: <200102172349.QAA11724@usr05.primenet.com> Subject: UUCP must stay; fetchmail sucks (was list 'o things) To: roam@orbitel.bg (Peter Pentchev) Date: Sat, 17 Feb 2001 23:49:58 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <20010217173019.A431@ringworld.oblivion.bg> from "Peter Pentchev" at Feb 17, 2001 05:30:19 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Just a minor comment-with-a-question. What is UUCP used for - mainly mail? > If so, then here's a datapoint - about two years ago I took part in > converting an existing UUCP mail transfer config to one using fetchmail. > Quite simple - invoke fetchmail -d from the PPP link-up script, kill it > in the link-down script in such a way that it sends a QUIT to avoid > message duplicates. There were a couple of other issues too, but in > the end, it all started working, and it's been working flawlessly for > the past two years. UCP belongs in the base system; you can skip the rest of this, if you are not interested in the gory details of UUCP vs. fetchmail. UUCP is the UNIX-UNIX Copy Program. It is used for copying files around. I formerly used it to copy TCP/IP and other packages to SVR4 boxes, since it was faster to do it over a null-modem cable than to use floppies. Primarily, it is used for email and usenet in areas of poor connectivity. The UUCP 'g' protocol is much more forgiving of noise than PPP or SL/IP over the same noisy connection. -- A tangential diatribe on the unsuitability of fetchmail ------- As to fetchmail: it is an abomination before God. If someone in the press ever paid for an audit of the source code, the result would refute the paper "The Cathedral and the Bazaar" to such an extent that it could damage the Open Source movement, which has pinned so much on the paper, in ill-considered haste. ESR has constantly maintained that fetchmail is "not an MTA", and he is right: it could be, but it's not. When mail is delivered to a POP3 maildrop, envelope information is destroyed. To combat this, you would need to tunnel the enveleope information in headers. Generally, sendmail does not support "X-Envelope-To:" because it exposes "Bcc:" recipients, since fetchmail-like programs generally _stupidly_ do not strip such headers before local re-injection of the email. Without this information, it can not recover the intended recipient of the email. The fetchmail program delivers this mail to "root". The program has another bug, even if you elect single message delivery (in order to ensure a "for " in the "Received:" timestamp line. The bug is that it assumes the machine from which the download is occurring is a valid MX for your domain. Many ISPs use one machine to do the virtual domain expansion, and another to do final deliver into ISP hosts POP3 maildrops. The net effect of this is that it attempts to use the "for " stamp, since it does not reverse-priority order "Received:" timestamp lines. Similarly, fetchmail fails to order headers in "confidence" order. This means that, given an email with a "valid" (MX matches in the "by " and a "for " exists) "Received:" timestamp line, a "To:", "Cc:", or "Bcc:" line, or an "X-Envelope-To:" line (which must be configured, and which is terrifically screwed up by qmail, requiring un-munging), fetchmail -- takes the first one it sees, not the most correct one. Using the "To:", "Cc:", or "Bcc:" lines ("data") to do the delivery buys a spammer the ability to relay mail, though the route it must take is rather circuitous. It also means that if the "Bcc:" was properly stripped before handing the RFC 822 message to an MTA, or if you are a list recipient, that data is useless for recovering envelope information. This means that root gets all mailing list mail from lists which do not do recipient rewriting (like the SVBUG list does), and root also gets all mail addressed to non-existant local users that was intended for particular local users (all SPAM and all mail that was requested but not sent specifically targetted to a particular user, via email header data). Unfortunately, ESR would not accept patches for the mistaken MX problem, nor for the preference order problem, nor for the tunneled envelope information stripping problem. He seemed to be too busy with speaking engagements, and has since declared fetchmail to be in "maintenance mode", in order to demonstrate a recognizable commercial software lifecycle for an Open Source project, to give business the warm fuzzies. -- End diatribe ------------------------------------------------ UUCP, comparatively, avoids this whole mess, by not destroying the envelope information, which normally exists only on on a mail transport (in SMTP, this is the "MAIL FROM:" and "RCPT TO:"; in UUCP, it's the control file contents). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 16:18:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 7303737B491 for ; Sat, 17 Feb 2001 16:18:36 -0800 (PST) Received: (qmail 56532 invoked by uid 1000); 18 Feb 2001 00:18:55 -0000 Date: Sat, 17 Feb 2001 16:18:33 -0800 From: Jos Backus To: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Message-ID: <20010217161833.D54688@lizzy.bugworks.com> Reply-To: Jos Backus References: <200102161835.f1GIZOB29603@cwsys.cwsent.com> <200102162029.NAA07885@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102162029.NAA07885@usr05.primenet.com>; from tlambert@primenet.com on Fri, Feb 16, 2001 at 08:28:52PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 08:28:52PM +0000, Terry Lambert wrote: > Please don't. DJBDNS lacks significant and important functionality > for all but trivial (one controller or single zone) uses. Maybe you should tell Dan what functionality you think is missing, and see what he says. There are very good reasons behind djbdns's current feature set. > For the daemons, please do not remove them, until you have > addressed the ability of a port to manipulate the contents of > the inetd.conf file, so that if they are selected as part of > an installation Running each service under its own network connection manager (say, tcpserver) mostly fixes this for TCP-based services. Maybe Dan could be persuaded to maintain djbdns in the FreeBSD source tree. -- Jos Backus _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 16:27: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 3202F37B401 for ; Sat, 17 Feb 2001 16:26:59 -0800 (PST) Received: (qmail 56566 invoked by uid 1000); 18 Feb 2001 00:27:18 -0000 Date: Sat, 17 Feb 2001 16:26:56 -0800 From: Jos Backus Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <20010217162656.E54688@lizzy.bugworks.com> Reply-To: Jos Backus References: <200102162108.f1GL8Dq40757@orthanc.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102162108.f1GL8Dq40757@orthanc.ab.ca>; from lyndon@orthanc.ab.ca on Fri, Feb 16, 2001 at 02:07:51PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 02:07:51PM -0700, Lyndon Nerenberg wrote: > Yes, the 'dialer' interface is a bit of a mess. Several years ago > there was an entry in the CSRG project wish list for a networked > dialer daemon that would intermediate access to dialout tty devices. > (I *think* it was Keith Bostic's idea.) This might solve part of > the problem. Maybe we could import BSD/OS' gettyd. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 17: 8: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 5720D37B491 for ; Sat, 17 Feb 2001 17:08:01 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 64C4F18C96; Sat, 17 Feb 2001 19:08:00 -0600 (CST) Date: Sat, 17 Feb 2001 19:08:00 -0600 From: "Jacques A. Vidrine" To: Terry Lambert Cc: arch@freebsd.org Subject: Re: GSS-API and PAM (was list 'o things) Message-ID: <20010217190800.A38833@spawn.nectar.com> References: <20010217085622.A37238@spawn.nectar.com> <200102172319.QAA11294@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102172319.QAA11294@usr05.primenet.com>; from tlambert@primenet.com on Sat, Feb 17, 2001 at 11:19:46PM +0000 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 17, 2001 at 11:19:46PM +0000, Terry Lambert wrote: > Please see either of: > > http://www.opengroup.org/onlinepubs/008329799/ > http://www.kernel.org/pub/linux/libs/pam/pre/doc/xsso.ps.gz > > for the XSSO (X/Open Single Sign On service) PAM documentation. > In particular, please look at the PAM API and SPI, and at the > session management functions and session management module > functions. Thanks for these references. I wasn't aware of them -- I've been going back to Sun for the PAM stuff. > PAM concerns itself with five different types of service modules: > Authentication (which is the one you were talking about), account management, > session management, and mapping. > > It's true that Linux does not implement GSS-API and PAM integration, > but it _is_ possible to put one under the other. It _is_ possible to stick authorization data into an authentication system, too, but that doesn't mean that one should (hello, Microsoft!). I assume you mean, `layer GSS-API under PAM'. I don't see how one could do the converse; there is no `place' in GSS-API to establish/create new credentials, for example, or to do account management. Layering GSS-API under PAM, such that the application uses only PAM and is not `aware' of GSS-API is possible only in the narrowest technical sense. In practice, PAM comes a bit too late in the game. In the popular network virtual terminal applications TELNET and SSH, for example, PAM is invoked once a security context has already been negotiated -- typically by /usr/bin/login (in concept with sshd, in reality with telnetd). Even if PAM were invoked very early so that an SPI could muck about with the protocol stream and did manage to negotiate a security context, you are then stuck with no way to do real way data integrity checking or data privacy, without resorting to something outside the PAM API. > It was my impression that XSSO had extended PAM to the point > that it incorporates GSS-API functionality; yeah, I know it's > not RFC 15xx compliant, but it doesn't really matter: it's a > defacto standard. I don't see how you can make this claim in the context of this discussion. Please show me even one PAM implementation that supports something approximating GSS-API or SASL. And then note that `one' hardly makes a de facto standard. All of this is not to knock PAM -- it is a godsend for many tasks. But it doesn't cover everything. > > Further, Kerberos is not the only way to get security and encryption > > with, say, TELNET. Other GSS-API implementations can be plugged in > > quite easily, such as X.509/SSL or DCE. (We have OpenSSL in the base > > now -- it probably makes sense to add this support to these daemons at > > some point.) > > Yes. RSA is specifically mentioned as a Kerberos option for GSS-API, > in the original documents. I didn't mean to narrow that to GSS-API either -- there is also TLS and SASL and such. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 19:32: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id C365437B401 for ; Sat, 17 Feb 2001 19:31:59 -0800 (PST) Received: from newsguy.com (p05-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.134]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id MAA19682; Sun, 18 Feb 2001 12:31:38 +0900 (JST) Message-ID: <3A8F4175.14A7E6CF@newsguy.com> Date: Sun, 18 Feb 2001 12:28:53 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Peter Dufault Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports References: <200102171313.f1HDDmH22011@hda.hda.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Dufault wrote: > > > games > > > ... > > ... My only exception is 'fortune', which many third party > > apps (like xscreensaver) just assume exists on the system. > > Does anyone else expect "factor"? It is the only thing I ever use > in games and there is one place I'd have to start installing it. I think all utilities markm spoke of have their place. At least for those of us who still prefer sh(1) over perl(1). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "That's evil, Sir," Layson said admiringly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 20:11:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CDD1137B503; Sat, 17 Feb 2001 20:11:47 -0800 (PST) Received: from localhost (u7lumd@localhost [127.0.0.1]) by green.dyndns.org (8.11.1/8.11.1) with ESMTP id f1I4BhA59592; Sat, 17 Feb 2001 23:11:45 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200102180411.f1I4BhA59592@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Peter Dufault Cc: arch@FreeBSD.org Subject: Re: Summary of List of things to move from main tree to ports In-Reply-To: Message from Peter Dufault of "Sat, 17 Feb 2001 08:13:48 EST." <200102171313.f1HDDmH22011@hda.hda.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Feb 2001 23:11:42 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Dufault wrote: > > Ok, here's my summary. Yah yah, I inject my own opinions. Too bad. > > This will be my last posting on the topic. > > > > > > Least Controversial: > > > > games > > > ... > > ... My only exception is 'fortune', which many third party > > apps (like xscreensaver) just assume exists on the system. > > Does anyone else expect "factor"? It is the only thing I ever use > in games and there is one place I'd have to start installing it. Since we install gmp, we may as well do something like is done in src/contrib/libgmp/demos/factorize.c and then kill the static size limitation for factor(6). That is, to make it even more useful if we do keep it. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 20:15:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-53.dsl.lsan03.pacbell.net [64.165.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 5484A37B491; Sat, 17 Feb 2001 20:15:11 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BCF8667021; Sat, 17 Feb 2001 20:15:10 -0800 (PST) Date: Sat, 17 Feb 2001 20:15:10 -0800 From: Kris Kennaway To: "Brian F. Feldman" Cc: Peter Dufault , arch@FreeBSD.org Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010217201510.A46093@mollari.cthul.hu> References: <200102180411.f1I4BhA59592@green.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102180411.f1I4BhA59592@green.dyndns.org>; from green@FreeBSD.org on Sat, Feb 17, 2001 at 11:11:42PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 17, 2001 at 11:11:42PM -0500, Brian F. Feldman wrote: > Peter Dufault wrote: > > > Ok, here's my summary. Yah yah, I inject my own opinions. Too b= ad. > > > This will be my last posting on the topic. > > >=20 > > >=20 > > > Least Controversial: > > >=20 > > > games > > >=20 > > ... > > > ... My only exception is 'fortune', which many third party > > > apps (like xscreensaver) just assume exists on the system. > >=20 > > Does anyone else expect "factor"? It is the only thing I ever use > > in games and there is one place I'd have to start installing it. >=20 > Since we install gmp, we may as well do something like is done in > src/contrib/libgmp/demos/factorize.c and then kill the static size=20 > limitation for factor(6). That is, to make it even more useful if we do= =20 > keep it. Actually, I'd like to go the other way. The only things which use libgmp in the tree are some crypto telnet stuff, and some NIS stuff. It shouldn't be much work to make them use libcrypto instead. I wrote patches for an upgrade to libgmp 3.0 a year ago but have held off committing them because I'd prefer to do that instead. Kris --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6j0xOWry0BWjoQKURApY0AJ4qgkBk2QG0Ql/gOw2rlNKjE9ypVgCg7mwA UxV1TPL66dyfcSZUC/wyAF0= =JZ4i -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 20:38:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id CC73937B503 for ; Sat, 17 Feb 2001 20:38:09 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.2/8.11.1) with ESMTP id f1I4bUH08448; Sat, 17 Feb 2001 20:37:31 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Kris Kennaway Cc: Mark Murray , arch@freebsd.org Subject: Re: Moving Things [was Re: List of things to move from main tree] In-Reply-To: Message from Kris Kennaway of "Sat, 17 Feb 2001 15:32:22 PST." <20010217153222.B8519@mollari.cthul.hu> Date: Sat, 17 Feb 2001 20:37:30 -0800 Message-ID: <8444.982471050@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So we're again off down that mythical PackageNG brick road again? No, this discussion is actually tangental to that one. We're talking about how to design the way we deal with sources in the future and, by direct result of that, how we deal with binary distributions of same. I might also add that things have changed since the last time we walked this path. How much they've changed I'll leave to everyone else to decide for themselves over the next 6 months or so, that being the period of time I'd predict to elapse for a halfway decent prototype. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 17 21:57:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id B229237B491 for ; Sat, 17 Feb 2001 21:57:07 -0800 (PST) Received: from newsguy.com (p05-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.134]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id OAA10994; Sun, 18 Feb 2001 14:56:49 +0900 (JST) Message-ID: <3A8F637B.45C18CFC@newsguy.com> Date: Sun, 18 Feb 2001 14:54:03 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Jordan Hubbard Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] References: <2628.982402377@winston.osd.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan Hubbard wrote: > [diet quote] > > In a design like this, all distinction between src and ports goes away > and it largely comes down to how much source the user wants to have > lying around - anything from all to none. > > Developers adding new stuff to this system simply have to make sure > that it's properly fitted into the global hierachy and that it will > build and install correctly from its assigned spot, dependencies and > all. Whether its principal developer(s) then decide that the master > sources should live on primarily as a tarball or in a CVS repository > somewhere shouldn't be the end-user's concern at all. Just so long as > the components the user has declared transient on their system stay > transient and the components declared fixed have sources sitting in > the appropriate subdirectories of /foo/src whenever they look, > everybody is happy. I disagree. One of FreeBSD strong points with many users is that we are not a "distribution", a bundle of assorted software thrown in together, but a whole OS, tightly integrated and balanced, to which the user may add extra software if he wants to. How could we possibly maintain this sense of integration, this sense of balance if there was no basic standard distribution around which we work? The mechanics you suggested seems fine, but only as long as we *do* keep a clear definition of what is FreeBSD and what is the rest. And that does mean saying "our MTA is sendmail, but you can chose to use another instead", instead of saying "you can use whatever MTA you want." All IMHO, of course. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "That's evil, Sir," Layson said admiringly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message