Date: Fri, 17 Nov 2000 13:02:21 -0700 (MST) From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert@primenet.com> Cc: nate@yogotech.com, chat@freebsd.org Subject: Re: Turning on debugging in GENERIC Message-ID: <14869.36557.693564.613415@nomad.yogotech.com> In-Reply-To: <200011171924.MAA28949@usr08.primenet.com> References: <200011170020.RAA17742@nomad.yogotech.com> <200011171924.MAA28949@usr08.primenet.com>
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. You can speculate all you want, but it didn't happen, and whether or not it would have happened is *pure* speculation. The folks who became core members were folks who were actively involved with the day-day operations of FreeBSD, and you had *never* been involved with the day-day operations of FreeBSD. (I haven't been involved with them for years, and I have no intention on that changing.) > 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. No more so than David, Rod, or Jordan's access to old source code, such as BSD 4.[123], and SysVR3 sources. > 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. Again, you can choose to believe that you staying at Novell made a difference, when in fact circumstantial evidence would show otherwise (NetBSD, plus a number of other folks involvement). > I believe that I was instrumental in the lawsuit finally getting > dropped, after personally lobbying Ray Noorda. Possibly, there's no way to know. > You, Rod Grimes, and Jordan are the people I handed the patchkit > off to; Well, you handed it to me. I handed it to Rod, and Rod handed it to Jordan. > I handed the FAQ off to David Burgess. *I* handed the FAQ off to Dave. I owned the FAQ *AND* the patchkit for about 6 months (I suspect the FAQ was the reason you handed the patchkit off to me), and then handed it off to Dave, where it mostly languished because it became irrelevant almost immediately. For what it's worth, I still have a copy of the 'Unofficial 386BSD FAQ' sitting on my box. I also had a patchkit as well, although my patchkit wasn't nearly as well organized as yours (it was wrapped up in the FAQ). However, you had patches I didn't, and vice-versa. My first steps in the the patchkit was to combine all of the outstanding patches and make a 'unified' patchkit, which I did as my first task upon receiving the tools from you. Yes, what you did was important. But, as they say in the industry, 'what have you done for me lately'? You can't live in the past. > 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. FreeBSD owes most of it's existance to the obnoxiousness of Lynn Jolitz, who is as annoying an individual as I've ever had the chance to deal with. If you wouldn't have done the patchkit, it would have been done differently, but it still would have (and was) been done, in a different format. So, having said that, I disagree with teh above statement, having been greatly involved in it. But, if it makes you feel any better, you can believe whatever you want. > > > 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? Daily. > I maintain that doing this six times in one day to catch the CVS tree > in a buildable state is not practical. You're the one arguing that it has to be done 6X/day. I do it once a day, and have found in the 8+ years that the tree has been completely 'broken' (in a manner than having CVS locks would fix) has happened less than two dozen times. The tree has been broken *MUCH* more than that, but that's mostly related to 'personal' issues, not technical issues. If someone checks in code that doesn't compile CVS can't fix it. If someone checks in code that compiles in their tree, but not in a 'virgin' tree, CVS can't check that either. Those kinds of breakage happens *ALL* the time in every project, and FreeBSD is no exception to that. > 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. Maybe a developer like yourself, but there are *thousands* of other developers throughout the entire world who have actively contributed real code to real problems on the project who would show otherwise. Yes, there are those that agree with you (Richard Wackerbath comes to mind), but IMNSHO, people like that won't be happy with *ANYTHING*, so trying to please them is nearly impossible. Even folks as difficult to work with as Matt Dillon someone get past all of the problems and have made *signficant* personal contributions to FreeBSD. If you don't want to do something, you can *always* find excuses not to do them, and you seem to have been doing this for well over 8 years. Since 1995, what visible contributions have you made to the project, short of lots of email? (Since 1997, I have made little, short of lots of email, so I'm willing to consider that I'm of little use to the project, for what it's worth.) > > >, 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. It's a decision that's made for *ALL* software. I'm not aware of *any* software that doesn't require clueful users for useful bug reports. Even netscape's 'automatic bug reporting' software requires that the user have a properly configured system (for sending email), and that the user be able to write coherent descriptions of what triggered the bug. XI-Graphics has the same sort of problems in their 'automatic' bug reporting that happens when it crashes. You've got to write explanations of what's going on when the crash occurs, else the bug report is sent to /dev/null. > 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. Now you're contradicting yourself. Adding kernel diagnostics means the users must have 'less clue', and you're complaining about it yet above you don't want users to have to have a clue? Would you make up 'yer mind already? > > >, 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. If you're not willing to bring the -current bits into your tree, then you're obviously not willing to test -current bits. How is this invalid? See above. You can't test something if you aren't willing to even bring them in... Also, you've also complained about not having the 'resources' to test them. However, people with *less* resources than you are testing the bits, therefore logically speaking your statement is false, and your logic flawed. Therefore, I conclude that it's not an issue of ability, but an issue of 'willingnes'. > I think the problem is better solved by ensuring repeatability > using identical code at all test locations. The cure is worse than the solution. An engineer spends his time optimizing for the 'standard path', and you want the project to spend all of it's time optimizing for a 'rare' path. This is not the best use of resources, and would only cause the project to become that much more engendered in politics and finger-pointing than it already is, and get that much less done. This is a 'political' solution that has no engineering basis, and as such will be thrown out today, just like it has been for the last 8+ years. People can't be forced to become 'clueful'. You know it as much as I do. > > >, 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. Same here. I've got a 400Mhz IBM, but it's not mine (it's Nokia's), and it's still running FreeBSD 2.2.8-stable. My only 'development' box is a 486/66, which still crunches along (albeit slowly), but it does the job. > 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. So you're still in better shape than me, with more hardware. (Your dual P90 should still be able to run -current, just not with both CPUs.) > 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. Whee, you've got a faster/wider 'bus' than me, which more than makes up for the little bit of CPU speed I have. > 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". So upgrade it. DSL is dirt cheap, and if you're really willing to help out, you can sacrifice a bit more $$ and get a faster connection. For a guy that makes as much as you do, an extra $50/month shouldn't kill you. If you can't stand the heat, stay out of the kitchen. If you aren't willing to upgrade it, then quit bitchin and live with it. It works for me, and it works for a *heck* of alot of European users who also have to pay for the amount of bytes they download, and you don't see them complaining about it. Nate 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?14869.36557.693564.613415>