From owner-freebsd-hackers Mon Nov 25 14:39:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15975 for hackers-outgoing; Mon, 25 Nov 1996 14:39:22 -0800 (PST) Received: from hil-img-2.compuserve.com (hil-img-2.compuserve.com [149.174.177.132]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA15943 for ; Mon, 25 Nov 1996 14:38:57 -0800 (PST) From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com Received: by hil-img-2.compuserve.com (8.6.10/5.950515) id RAA12669; Mon, 25 Nov 1996 17:38:21 -0500 Date: Mon, 25 Nov 1996 17:32:24 -0500 Subject: NON-DELIVERY of: hackers-digest V1 #1660 To: "INTERNET:hackers@freefall.freebsd.org" Message-ID: <199611251738_MC1-C3A-258E@compuserve.com> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sender: owner-hackers-digest@freefall.freebsd.org Received: from ns2.harborcom.net (ns2.harborcom.net [206.158.4.4]) by arl-img-2.compuserve.com (8.6.10/5.950515) id OAA07889; Wed, 20 Nov 1996 14:38:12 -0500 From: Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.18]) by ns2.harborcom.net (8.8.3/8.6.12) with ESMTP id OAA08184; Wed, 20 Nov 1996 14:35:47 -0500 (EST) Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA26240 for freebsd-hackers-digest-outgoing; Wed, 20 Nov 1996 10:40:42 -0800 (PST) Date: Wed, 20 Nov 1996 10:40:42 -0800 (PST) Message-Id: <199611201840.KAA26240@freefall.freebsd.org> To: freebsd-hackers-digest@FreeBSD.ORG Subject: hackers-digest V1 #1660 Reply-To: hackers@freefall.freebsd.org Errors-To: owner-hackers-digest@freefall.freebsd.org Precedence: bulk hackers-digest Wednesday, 20 November 1996 Volume 01 : Number 1660 In this issue: Re: Ipx to ip routing Re: Recuperating a DOS partition Re: Ipx to ip routing(translation) 640MB MO support source kit Re: Kernel calls - args in registers Re: Ipx to ip routing Re: Ipx to ip routing Re: Ipx to ip routing Disk Striping Re: RELENG_2_2 and CVS Integrating sendmail 8.8.3 into a 2.1.6 tree Re: Ipx to ip routing(translation) Re: Turbo FreeBSD CD Re: Ipx to ip routing Re: Ipx to ip routing Re: Ipx to ip routing(translation) Re: Disk Striping Re: Who needs Perl? We do! ---------------------------------------------------------------------- From: exidor@superior.net (Christopher Masto) Date: Wed, 20 Nov 1996 09:50:47 -0500 Subject: Re: Ipx to ip routing Joe Greco writes: > Ideally, in a school environment, each networked classroom or lab should > be on its own subnet, or perhaps several subnets. When the machines are [...] This falls apart when you have to deal with roaming. If your "school environment" isn't dealing with student laptops now, it will be within the next few years. The nicest solution I've seen is a large subnet (~13 bits) with smart IP switches. - -- Christopher Masto . . . . Superior Net Support: support@superior.net chris@masto.com . . . . . Masto Consulting: info@masto.com On Book Titles, Confidence-Building: "Correctly English in 100 Days" - title from an East ASian book for beginning English speakers ------------------------------ From: J Wunsch Date: Wed, 20 Nov 1996 15:46:54 +0100 (MET) Subject: Re: Recuperating a DOS partition As Jean-Pierre Morant wrote: > I've used fdisk to assign that partition to FreeBSD, > then edited the fstab so that /dev/wd1s1f (the next available partition > name) is seen as a swap partition. Are you confusing partitions and slices here? wd1s1f would be partition `f' on slice 1 on wd1. > The data for partition 0 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 0, size 244160 (119 Meg), flag 80 > beg: cyl 0/ sector 1/ head 0; > end: cyl 1023/ sector 1/ head 0 This is slice 1. > The data for partition 1 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 0, size 244160 (119 Meg), flag 0 > beg: cyl 0/ sector 0/ head 0; > end: cyl 447/ sector 1/ head 0 This is slice 2, i think that's what you're actually trying to use? If so, it's /dev/wd1s2 (eventually followed by a partition letter). I'm not sure whether swapping to partitions != `b' is supported now; it wasn't supported in historic versions. At least, it's the cleanest to stick with the traditional names, disklabel wd1s2, and assign the entire space there to the `b' partition. See also the (updated) section 2.15 of the FAQ for traditional partition naming conventions. - -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ------------------------------ From: dennis@etinc.com (dennis) Date: Wed, 20 Nov 1996 10:13:44 -0500 Subject: Re: Ipx to ip routing(translation) > > >On Tue, 19 Nov 1996, Hal Snyder wrote: > >> > My question is: Does Freebsd support ipx to ip routing. I know that BSDi >> > does. (And they want $6,000 for their system because of it.) > >oops, I really meant ipx to ip TRANSLATION. I want to only have one host >using a ip address and all the others using ipx (or somthing similar) to >talk to the internet. Each computer would be mapped to by the MAC address >on the ethernet card. All communications with the internet would go >through FBSD host. www.netcon.com Dennis ------------------------------ From: "barry (b.a.) scott" Date: 20 Nov 1996 09:57 EST Subject: 640MB MO support source kit Introduction ============ This kit contains changes to "FreeBSD 2.2-961006-SNAP" which implement support for disks with physical sector size of 512, 1024 and 2048 bytes. Authors: These changes are the joint effort of John Gumb (john@talisker.demon.co.uk) and Barry Scott (barry@scottb.demon.co.uk). Please contact us about these chanages. At this point only the od device has been changed. Changing the sd device would be straight forward; apply the changes from od.c to sd.c. We will submit a patch for sd.c later. This kit contains diffs that can be used with the 'patch' utility to update a virgin source tree. Location: via ftp at ftp.freebsd.org:/pub/FreeBSD/incoming/mo-2048kit.tar.gz 1. Source Changes necessary ======================== a) SBIN changes ------------ Patch file: sbin.MO.patch This file patches fdisk and newfs to support up to 2048 byte sectors. Files changed on system: /usr/src/sbin/newfs/newfs.c /usr/src/sbin/newfs/mkfs.c /usr/src/sbin/i386/fdisk/fdisk.c Corresponding files in this kit: mo-kit/sbin.MO.patch mo-kit/sbin/newfs/newfs.c mo-kit/sbin/newfs/mkfs.c mo-kit/sbin/i386/fdisk.c b) SYS chages ---------- Patch file sys.MO.patch This file patches the kernel to support up to 2048 byte sectors on the od device. Both ufs and msdosfs are supported on the od device. Files changed on system: /usr/src/sys/msdosfs/msdosfs_fat.c /usr/src/sys/msdosfs/msdosfs_vfsops.c /usr/src/sys/msdosfs/msdosfsmount.h /usr/src/sys/kern/subr_diskslice.c /usr/src/sys/ufs/ufs/ufs_disksubr.c /usr/src/sys/scsi/od.c Corresponding files in this kit: mo-kit/sys.MO.patch mo-kit/sys/msdosfs/msdosfs_fat.c mo-kit/sys/msdosfs/msdosfs_vfsops.c mo-kit/sys/msdosfs/msdosfsmount.h mo-kit/sys/kern/subr_diskslice.c mo-kit/sys/ufs/ufs/ufs_disksubr.c mo-kit/sys/scsi/od.c c) ETC changes ----------- The file disktab.MO contains the disktab entry for the Fujitsu M2513A MO drive with 2048 byte media. Files changed on system: /etc/disktab Corresponding file in this kit: mo-kit/disktab.MO 2. Testing performed ================= a) MSDOS ----- For MSDOS FS we created a FAT formated MO disk under Windows NT and placed files onto the disk from Windows NT. Under FreeBSD all the directories and files where confirmed to be readable. Under FreeBSD we created extra directories and wrote files on to the MO disk. FreeBSD could read these additional files. The disk was moved back to Windows NT and chkdsk was used to detect any file system corrupt. None found. Window NT was used to read the directories and files written under FreeBSB. b) UFS --- we use the following script to regression test disklabel and newfs: - ------------- #!/bin/bash set -x echo Initing disk... umount /dev/od0a umount /dev/od0s1 logger -p local1.notice "Initing disk..." dd bs=2048 count=1 if=od0-mbr.fdisk of=/dev/rod0 dd bs=2048 count=2 seek=1 if=/dev/zero of=/dev/rod0 echo read disklabel... logger -p local1.notice "read disklabel before write..." disklabel /dev/rod0c echo read disklabel... logger -p local1.notice "read disklabel -r before write..." disklabel -r /dev/rod0c echo write disklabel... logger -p local1.notice "write disklabel..." disklabel -r -w /dev/rod0c m2513a-640mb testing-mo-code echo read disklabel after write... logger -p local1.notice "read disklabel..." disklabel /dev/rod0c echo newfs od0a logger -p local1.notice "newfs..." newfs /dev/rod0a echo mount od0a logger -p local1.notice "mount od0a..." mount /mo - ------------- Note the file od0-mbr.fdisk contains a copy of the mbr written previously under FreeBSD by the new fdisk. The entire /usr/src/sys tree was written to the MO disk using cp -r. The disk was dismounted and then remounted. Then the entire /usr/src/sys tree was diffed against the MO disk copy. No differences found. The MO was dismounted and fsck was run. It detected no problems. 3. Misc. Information ================= a) FDISK ----- We have tended to create a single BSD slice using fdisk. Be aware that the slice should start at offset 1 and the file system size should be 310351 sectors; the first sector being reserved for the mbr/partition table information. The geometry we use is slightly different to the default (see our modified /etc/disktab) in order to utilise the full capacity of the media. The bios geometry we use is C/H/S 652/17/28 (652*17*28=310352). ------------------------------ From: "barry (b.a.) scott" Date: 20 Nov 1996 10:04 EST Subject: Re: Kernel calls - args in registers This problem was reseached inside DEC by the compiler group. They found that it was far better to pass parameters on the stack and thus leave the optimiser a full set of registers to work with within the body of the routine. As gcc's optimiser improves it becomes less and less likely that passing args in registers will give an advantage. BArry ------------------------------ From: Joe Greco Date: Wed, 20 Nov 1996 10:18:43 -0600 (CST) Subject: Re: Ipx to ip routing > Joe Greco writes: > > Ideally, in a school environment, each networked classroom or lab should > > be on its own subnet, or perhaps several subnets. When the machines are > [...] > > This falls apart when you have to deal with roaming. If your "school > environment" isn't dealing with student laptops now, it will be within > the next few years. > > The nicest solution I've seen is a large subnet (~13 bits) with smart > IP switches. What do you do about IP address collisions, then??????? Good lord. Hope you are great with an Ethernet sniffer, and your switches can trace on your behalf. We had this problem at MEI, trust me, it is virtually impossible to track down transient collisions on such a large network. I can just see the fireworks when Suzi Smith, the first year arts major, plugs in her workstation and mistakenly nails your gateway IP address in as her PC's IP address. Woo woo! There goes your Internet connectivity. I would think that in the sort of environment you are suggesting, one would think that DHCP is the ideal solution, and would allow for properly subnetted networks that do not suffer from the general problems of a network with 13 bits of space. That way you could even "roam" yourself to your home network, or your local ISP, or the other school across town where you decided to take one course for the hell of it. Incidentally: I am no big supporter of DHCP, I do not even like the concept, but for this kind of thing, it's really the right tool. ... JG ------------------------------ From: exidor@superior.net (Christopher Masto) Date: Wed, 20 Nov 1996 12:03:37 -0500 Subject: Re: Ipx to ip routing Joe Greco writes: > > Joe Greco writes: > > > Ideally, in a school environment, each networked classroom or lab should > > > be on its own subnet, or perhaps several subnets. When the machines are > > [...] > > > > This falls apart when you have to deal with roaming. If your "school > > environment" isn't dealing with student laptops now, it will be within > > the next few years. > > > > The nicest solution I've seen is a large subnet (~13 bits) with smart > > IP switches. > > What do you do about IP address collisions, then??????? Good lord. Hope > you are great with an Ethernet sniffer, and your switches can trace on > your behalf. We had this problem at MEI, trust me, it is virtually > impossible to track down transient collisions on such a large network. The switches don't allow IP address collisions. They associate a hardware address with an IP address and talk to each other to keep things in sync. This is what they did where I went to school (RPI). When you're in your room with a laptop, packets for your IP get forwarded to that physical wire.. if you unplug the laptop and reconnect it in a classroom, the switch sees your first packet and updates its knowledge of where you are, physically. If you try to use the wrong IP, you are only affecting the physical segment that you are on, because the switch knows it's not correct and probably even sends an SNMP trap to let the administrators know. - -- Christopher Masto . . . . Superior Net Support: support@superior.net chris@masto.com . . . . . Masto Consulting: info@masto.com On Machismo and Pestilence: In the early sixties, we were strong, we were virulent... - John Connally, Secretary of Treasury under Richard Nixon. ------------------------------ From: Joe Greco Date: Wed, 20 Nov 1996 11:16:31 -0600 (CST) Subject: Re: Ipx to ip routing > The switches don't allow IP address collisions. They associate a > hardware address with an IP address and talk to each other to keep > things in sync. This is what they did where I went to school (RPI). > When you're in your room with a laptop, packets for your IP get > forwarded to that physical wire.. if you unplug the laptop and > reconnect it in a classroom, the switch sees your first packet and > updates its knowledge of where you are, physically. If you try to use > the wrong IP, you are only affecting the physical segment that you are > on, because the switch knows it's not correct and probably even sends > an SNMP trap to let the administrators know. Ethernet switches are not supposed to do anything other than MAC level address routing. Switches by definition will certainly allow IP address collisions because they do not have a clue what the hell an IP address is. The other disadvantage of switches is the potentially large amount of ARP'ing that can go on to locate hosts in such a network. ... JG ------------------------------ From: "Darrin R. Woods" Date: Wed, 20 Nov 1996 11:14:31 -0600 Subject: Disk Striping I just got my news server up and running INN (thanks to everyone that helped), but now I'm looking for a better way of dealing with it. I've got 3 Fast/Wide 4gb disks to hold news. It would be a lot easier (and better performance) if I could stripe (or span) the /var partition accross the 3 disks instead of having to guess as to how to partition each drive and into what sizes. The question: Is there a way to stripe a partition across multiple drives in FreeBSD? If not, does anyone know of a FreeBSD like OS that will do it? Preferably NOT Linux. Thanks, Darrin R. Woods | dwoods@netgazer.com Director | Netgazer Solutions, Inc. | http://www.netgazer.net Dallas, Texas | My employer most whole-heartedly denies everything I say ------------------------------ From: John Polstra Date: Wed, 20 Nov 1996 09:19:44 -0800 Subject: Re: RELENG_2_2 and CVS In article Mike Hancock writes: > I discovered that my CVS tree was corrupt after trying the following: > > cd /jaz > cvs co -r RELENG_2_2 src # -r implies -P > > The checkout failed and later that night my cvsup cron job failed with the > error "Possible reference of NIL". *Blush*, how embarrassing. There are still a couple of cases involving badly spammed CVS repositories that can cause this sort of thing to happen. If you still have a backup of the bad repository, I'd greatly appreciate getting a copy of the offending subtree. My current unreleased working version of CVSup has fixes for the two problems I was aware of. But neither of them involved null pointer dereferences, so this one could be new to me. > > So I rm -rf /jaz/cvs; cvsup'ed the tree again; rm -rf /jaz/src; checked > out 2.2 release; built a new kernel and things look fine now for testing > 2.2. > > /jaz/src was current. Which brings me to a question, should I have done a > cvs release src? No, "cvs release" doesn't affect the repository at all. It might affect your logfiles, but that's all. There's nothing wrong with doing a simple "rm -rf" of your working directory when you're done with it. - -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth ------------------------------ From: Tom Samplonius Date: Wed, 20 Nov 1996 09:54:48 -0800 (PST) Subject: Integrating sendmail 8.8.3 into a 2.1.6 tree I've been trying to integrate sendmail 8.8.3 (taken from current) into a 2.1.6 tree. This looked very straightforward because the Makefiles and directory structure was nearly identical. However, when trying a "make all", make stops with a "don't know how to make /usr/src/usr.sbin/sendmail/src/sysexits.h". I find this strange. sysexits.h isn't included with sendmail, and isn't mentioned in the Makefile, so why does make think it needs to be built? Tom ------------------------------ From: Terry Lambert Date: Wed, 20 Nov 1996 10:37:51 -0700 (MST) Subject: Re: Ipx to ip routing(translation) > > You up for writing a winsock? If you were to write a winsock, and > > you made it use SOCKS to connect to a SOCKS IP Proxy Gateway, your > > name would be heralded from the tops of towers, in many circles, > > since it would mean the death of the hated "aliasing". > > Trumpet Winsock does this, last time I looked, or am I misunderstanding > what you are suggesting? I'll have to look; I wasn't aware of this... Thanks! Terry Lambert terry@lambert.org - --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ From: "Maestros Asociados" Date: Wed, 20 Nov 1996 11:58:48 -0600 Subject: Re: Turbo FreeBSD CD - ---------- : From: Chris Timmons : To: Wilko Bulte : Cc: FreeBSD hackers list : Subject: Re: Turbo FreeBSD CD : Date: martes 19 de noviembre de 1996 13:28 : : : Well the great thing about FreeBSD is that it's FREE... so anybody can put : it on a CD and sell it. : : My preference has always been to buy from Walnut Creek CDROM because they : support the project. I personally subscribe to both the -RELEASE and : -SNAP cd distributions and have had excellent experience dealing with the : Walnut Creek people on the phone. Since we rely heavily on FreeBSD at : work, I spec Walnut Creek as the CD-ROM of choice there as well. Thanks : WC!!! : : -Chris : : On Tue, 19 Nov 1996, Wilko Bulte wrote: : : > Hi there, : > : > I just today got a catalog in my PObox of Pacific HighTech CDROM. : > A bit to my surprise it has a 'Turbo FreeBSD' CDROM listed on it's : > cover. I contains 2.1.5R and a 2.2 SNAP (960801? it's very : > fine print). : > : > Comments? : > : > Wilko : > _ ____________________________________________________________________ : > | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands : > |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda : > - -------------------------------------------------------------------------- : > ------------------------------ From: Terry Lambert Date: Wed, 20 Nov 1996 10:53:00 -0700 (MST) Subject: Re: Ipx to ip routing > > My question is: Does Freebsd support ipx to ip routing. I know that BSDi > > does. (And they want $6,000 for their system because of it.) > > > > Do we have any plans for implementing it? > > You can't route between IP and IPX. They are incompatible. You can > can however tunnel IPX across an IP network. Sidebar: NetWare/IP uses encapsulated IPX on a native IP transport; it is impossible to get away from IPX if you are using NetWare. Terry Lambert terry@lambert.org - --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ From: Terry Lambert Date: Wed, 20 Nov 1996 11:02:02 -0700 (MST) Subject: Re: Ipx to ip routing > I would think that in the sort of environment you are suggesting, one > would think that DHCP is the ideal solution, and would allow for properly > subnetted networks that do not suffer from the general problems of a > network with 13 bits of space. I agree. And I'm not a big fan of DHCP, either. Are people actually implementing PAP yet? One big problem is that most RAS clients on MS boxes (Windows 95 without the "Plus! Pack" and Windows NT prior to 4.x) do not do auto connection on the basis of routing information... ie: demand dial PPP. An application has to be RAS aware, or a human has to establish the connection. Bleah. But they are much better at being DHCP clients than a BSD box can generally stumble through. 8-(. Terry Lambert terry@lambert.org - --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ From: Doug Ambrisko Date: Wed, 20 Nov 1996 10:16:47 -0800 (PST) Subject: Re: Ipx to ip routing(translation) Terry Lambert writes: | > > You up for writing a winsock? If you were to write a winsock, and | > > you made it use SOCKS to connect to a SOCKS IP Proxy Gateway, your | > > name would be heralded from the tops of towers, in many circles, | > > since it would mean the death of the hated "aliasing". | > | > Trumpet Winsock does this, last time I looked, or am I misunderstanding | > what you are suggesting? | | I'll have to look; I wasn't aware of this... Thanks! Not to mention Hummingbird has a Win95/NT wedge for free and I've used at home, as well as, the 16 bit & 32 bit shims for Windows avaliable from NEC also for the download. Doug A. ------------------------------ From: Joe Greco Date: Wed, 20 Nov 1996 12:22:05 -0600 (CST) Subject: Re: Disk Striping > I just got my news server up and running INN (thanks to everyone that > helped), but now I'm looking for a better way of dealing with it. I've got > 3 Fast/Wide 4gb disks to hold news. It would be a lot easier (and better > performance) if I could stripe (or span) the /var partition accross the 3 > disks instead of having to guess as to how to partition each drive and into > what sizes. (I am not convinced that that statement is true...) > The question: Is there a way to stripe a partition across multiple drives > in FreeBSD? If not, does anyone know of a FreeBSD like OS that will do it? > Preferably NOT Linux. I recommend you go search the mailing list archives for almost anything I have ever written on the subject of Usenet news and FreeBSD. ... JG ------------------------------ From: Terry Lambert Date: Wed, 20 Nov 1996 11:26:32 -0700 (MST) Subject: Re: Who needs Perl? We do! > > The problem is the dependencies for the existing code, and that fact > > that if the maintainers of the code haven't "upgraded", then we become > > promary support for the "upgraded" scripts. > > Most programs run fine with NO changes. As we gain more dependencies on PERL in the main line source tree, we will become more sensitive to PERL changes. Has PERL syntax reached the top end of the inverse expotential curve yet? If the last major rev is any indicator, the answer is "no". 8-(. When it starts to stagnate, then it will be safe. 8-). > > This would have been less of a problem in the 5.x changeover if the > > PERL distribution had a tool to upgrade scripts over the syntactic > > changes. > > Why don't C++ compliers supply the same thing? I've seen programmers > get bit by the same thing. Frank answer: because compiler writers are lazy. IMO, it is work 100 hours of compiler write time to save 1 hour of compiler user time is compiler users outnumber compiler writers 100 to 1. Since there are now in excess of 1.1 million professional programmers in the US alone, I kind of think the number is closer to 1000 to 1. One hour of compiler writer time for each 6 minutes of compiler user time. The whole MS "near/far" debacle could have been avoided if the compiler emitted pseduo-ops, which the linker resolved to near/far calls as necessary -- and as a result, totally hidden segments from the compiler user. Prototypes were the MS and Borland answer to the ANSI committee; they are useful in that they allow a migration path from C to C++, but the type-checking benefits result from not properly attributing object module contents in the first place... otherwise, the linker could catch the call return/argument mismatch by comparing attributes. Similarly, the "extern C" constructs are bogus name space selector mechanisms, only necessary because the object modules are once again, not attributed, and the linker is, once again, stupid. A lot of extra work for the compiler user because the compiler writer didn't want to have to spend the time. You can make similar arguments about applying "volatile" to variables instead of functions and memory ranges to make it innocuous (and in many cases, hide it with encapsulation -- ie: in __sighandler_t). A "volatile" function, by definition, is a crossing of a thread of control boundry. Stack scoping attribution could eliminate the need for volatile for everything by physical device memory references... any function crossing a thread of control (like a signal handler) would implicitly have non-local scope references treated as volatile. Etc., etc. Failure to provide "syntax upgrade" tools to post-process existing source code into the new syntax is just another instance of the same general problem. 8-(. And even if "syntax upgrade" tools were available, most of the PERL code in FreeBSD is "vendor branched"... which means convincing all the "vendors" to run the tools and rerelease their sources. There *will* be a latency in that process. > > The problem, again, is that the change cycle on PERL has historically > > been too short to base a FreeBSD release on a PERL release... PERL > > is moving faster than FreeBSD, in other words. > > HuH???!!!??? Include the latency in getting all vendors to the same revision level of the interpreter so that the new revision and all the dependent tools can be committed simultaneously. If FreeBSD has to run the conversion, then FreeBSD becomes the maintainer for each tool until the vendor himself runs the conversion. Regards, Terry Lambert terry@lambert.org - --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ End of hackers-digest V1 #1660 ******************************