Date: Mon, 6 Dec 1999 16:56:59 -0600 From: Karl Denninger <karl@Denninger.Net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Dennis <dennis@etinc.com>, hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) Message-ID: <19991206165659.A25917@Denninger.Net> In-Reply-To: <199912062124.NAA72775@apollo.backplane.com>; from Matthew Dillon on Mon, Dec 06, 1999 at 01:24:36PM -0800 References: <19991205120428.E6F4514C3E@hub.freebsd.org> <199912061939.OAA22030@etinc.com> <199912062019.MAA72301@apollo.backplane.com> <19991206144330.B25513@Denninger.Net> <199912062124.NAA72775@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 06, 1999 at 01:24:36PM -0800, Matthew Dillon wrote: > :Well, I used to run -CURRENT in a commercial environment :-) > : > :And I got bashed here and elsewhere for doing it too. > : > :But, with the exception of some really egregious fuck-ups (on both my part > :and those of people who committed shit that didn't work AT ALL) it was, by > :far, the better option of those available. > : > :For quite some time there were special "hacks" that I had (primarily > :consisting of grabbing older versions of this module or that) to get > :around stupidities that were in the process of being resolved, and there > :were always things that I disabled or just didn't do because I knew they > :were broken. > > This was an unfortunate consequence which I take partial blame for > in my little corner of the system -- but only partial blame. It was > hard enough getting my stuff into -current with all the extra requirements > core forced onto me, I didn't want to have to go through the same hell > to get it MFC'd into -stable as well. At one point at the beginning, > before the shit began to fly, I was actually considering only doing it > for -current but as more and more bugs were found it became clear that > if the stuff didn't get MFC'd into -stable soon it wouldn't at all. > By that time the shit was already flying and I just didn't want to > double it. Maybe 80% of the bug fixes have been MFC'd -- the ones that > were easy to fix. The other 20% can't be MFC'd without the rest of > the infrastructure in 4.x to support them. > > I hope the same thing will not repeat for 4.x/5.x, even without an > enforced stabilizing period between 4.0 and 4.1 prior to branching > off. However, I think that an enforced stabilizing period where > *everyone* is concentrating on 4.1 for a couple of months would be > extremely good for the project. > > -Matt I don't think you were to blame at all Matt, at least not in my particular set of circumstances. I'm the first to admit that when I use an OS I typically have both high expectations and also tend to have unique requirements. I stress parts of the system that many people do not. I frequently make performance demands on parts of the system that are unique, and they are inherent to how I design systems and software - I don't believe in throwing iron at a problem, rather, I expect the iron that is available to work with the code that is in the OS - and do so properly. When things don't work that way, its trouble. The list of vendors I have pissed off over the years because they either (1) broke something that worked horribly - usually by destroying its performance to the point that areas of the system I counted on were no longer usable for the production load I expected out of them, or (2) they flatly didn't bother supporting certain things that *should* work, is legion in the business in general. In some cases (commercialware, where you can have such expectations) I've found cooking of so-called "published performance levels" to literally outrageous levels, at least one commercial vendor has eaten six-digits worth of equipment over these types of issues, and another (many, many years ago) was literally driven from the US marketplace. I tend to find these situations very rapidly under commercial use conditions, because I select components and subsystems *precisely* due to those performance claims. When they cannot be met, or something is changed that breaks those claims, well, then the fur flies. This shouldn't imply that I dislike FreeBSD. On the contrary. It's still what I run on my OWN hardware for my OWN projects - after trying pretty much literally everything else at least once, and even after getting into some pretty serious pissing matches over the years with various members of CORE. Where I'm from that's known as a ringing endorsement. -- -- Karl Denninger (karl@denninger.net) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991206165659.A25917>