Date: Fri, 17 Nov 2000 19:24:08 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@yogotech.com Cc: tlambert@primenet.com (Terry Lambert), chat@freebsd.org Subject: Re: Turning on debugging in GENERIC Message-ID: <200011171924.MAA28949@usr08.primenet.com> In-Reply-To: <200011170020.RAA17742@nomad.yogotech.com> from "Nate Williams" at Nov 16, 2000 05:20:15 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > No. I ignored the majority of your post because it was wrong, > > No more than you complaining about how hard it is for you to help > because of trumped up complaints. That's incorrect; though it has nothing to do with the present discussion, it clearly speaks to your underlying motivations. You and others know very well that I would have been on the core team from the start, had I not sacrificed my position in order to protect the project from Mike DeFazio, VP of the UNIX systems group at Novell USG (the former USL), and the executive who did the initial sign-off on the BSDi, and later UCB lawsuits. Had I been on the core team, or even contributed anything in the post acquisition phase, while still a Novell employee, my access to the USL source code would have provided a ready claim to the contamination of all the FreeBSD code. I further stayed at Novell six months longer than I would have liked to, and had to forego other offers, in order to ensure the project got the same deal as BSDi, instead of having to live with the cease and desist order that Jordan and other received via certified mail. I believe that I was instrumental in the lawsuit finally getting dropped, after personally lobbying Ray Noorda. You, Rod Grimes, and Jordan are the people I handed the patchkit off to; I handed the FAQ off to David Burgess. These, more than any single thing, save the Net/2 release and William Jolitz's original 386BSD 0.1 release, formed the basis of FreeBSD 1.0. > > As a single point rebuttal, my home connection has been and > > remains ~28k > > That's more than adequate for the task. I ran with a 28.8K link until > recently, and at times I'm using a 33.6K connection for syncing the CVS > tree. (I got a new modem when lightning blew out my 28.8K USR.) How often do you perform this process? I maintain that doing this six times in one day to catch the CVS tree in a buildable state is not practical. I further maintain that, even if you were to do this, the repeatability of your experience is low, and the first thing any "works for me here" developer is going to do is blame the unknown-to-them version of the bits you are running, until you waste another day repeating the process. > >, and my premise was predicated on both the fact > > that I have insufficient disk space on my scratch machines > > for a full tree > > You don't need a full tree to test, especially if you're a clueful user. Insisting on bug reports _only_ from clueful users is a mistake, and one I hope the project is not ready to make. To me, the addition of a lot of kernel diagnostic messages seems clearly intended as a crutch: it is to substitute information volume for clue, recognizing that an insistance on clue has not been a valid success strategy so far. > >, do not _want_ -current bits pulled into my > > main tree > > Then quit yer bitchin about current. If you aren't willing to test the > bits, then you've got *NOTHING* to complain about. You are presuming a premise for me; do not do that: it is an invalid tautology. Do not put words in my mouth. I am not "bitchin about current". I am suggesting the perhaps putting a huge number of diagnostics in the kernel as a substitute for clueful users is perhaps not the best approach for resolving the problem that the diagnostic messages (or the clueful users) are being presumed would resolve. I think the problem is better solved by ensuring repeatability using identical code at all test locations. My stated assumption here is that the real problem that people are trying to solve is to get more people providing more useful bug reports against -current, to ensure that instabilities introduced are reported and resolved quickly. > >, and can afford neither the bandwidth nor the CPU > > cycles for what is frequently an iterative process of cvsup > > and build world. > > You have both (you've probably got better hardware than me), but you > wouldn't admit to them. I'm still using the *ORIGINAL* FreeBSD > development box (before it was called FreeBSD), a 486/66 with 16MB of > memory. > > All I see is someone making up excuses to to anything..... I have faster hardware on which I do real work, but which I can not risk, since I am using the OS as a platform, not an ends in itself. My non-scratch boxes are a laptop (the fastest machine I own; it is frequently booted into Windows these days) and a Dual P90 machine I bought from Rod Grimes in 1996, which can't run -current. I have other machines, but FreeBSD doesn't run on any of their architectures, except a 166MHz Multia. My scratch box is a 486/50 EISA box with an AHC1742 and 2G of disk. You have me beat by 8MHz on bus speed and 16MHz on processor speed. My connection speed as I type this (fighting with an FTP session at the same time) is 26.4k; yours is faster by 7.2k, and you state that you only use that speed "at times". 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-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011171924.MAA28949>