Date: Thu, 30 Jul 1998 04:54:04 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: scrappy@hub.org, nate@mt.sri.com, freebsd-chat@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: Conspiracy Theories (Was: Re: The future of the bt848 driver? (FW: cvs commit: CVSROOT avail) ) Message-ID: <199807300954.EAA07706@dyson.iquest.net> In-Reply-To: <671.901739120@critter.freebsd.dk> from Poul-Henning Kamp at "Jul 29, 98 09:05:20 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp said: > > John Dyson went out a tangent and lost all contact with the core > team, some will even say he went "balistic", in either case, he > attained escape velocity, and that is the end of that story. > Actually, PHK, that isn't quite true. Please do a reality check as to the situation. Also, people were looking over my shoulder during the implied confrontations, and agreed with my opinions about the situation. However, those people were indeed fully informed, unlike those who might have misjudged the situation. Since you brought it up: 1) The incessant releases of 2.2.X put alot of pressure on future and current development. 3.0 had to be released and stabilized earlier. The current monolithic kernel is not the right vehicle for SMP (from a quality and design standpoint.) FreeBSD needed to "just stabilize" 3.0, and I would have, if that was the plan. I warned JKH about the differences between -current and -stable being more than a nuisance over 6-9 mos ago. Tolerable quality SMP would have been in a 3.0 release 6mos ago, *IF* the initiative was started to produce it. 2) There was a disagreement, with parties involved, taking positions, without being informed. Those parties include the person that I am responding to. 3) I had asked -core for significant support for an investment that was necessary for the future. That investment included a kernel that would have been able to support things that the current monolithic kernel could not. The response from PHK, due to his errant assumption that I was loosing interest was to "show me the door." It was pretty obvious that he was encouraging me to walk away. 4) The *only* reason why my employer was using FreeBSD was my advocacy, and my ability to show that FreeBSD was technologically advanced. I could no longer make that claim, especially considering a >2yr timeframe. (I tend not to think in the terms of "right now", but in future terms, where current decisions have the most influence.) 5) Comments about my quality of work need to be carefully considered based upon the lack of support and initiative from other people directly involved in FreeBSD. The best support that I got, was from wonderful contributors from the outside. Those who theoretically should be in the best position to help, weren't doing so (and were relatively absent from development.) If there was any question about the work that I was doing, should consider the fact that I had a strategy, that those who could have been involved just decided to judge, rather than talk to me, or help and participate. I suspect that the above judgement was partially a cultural thing. However, that isn't an excuse. 6) FreeBSD-3.0 will be much nicer than 2.2.X, but is not the generic answer to enterprise (and controller) computing. FreeBSD's niche that it has carved out is okay for now, but the strategy has been myopic. Not every -core member can do every job all of the time, and it was becoming clearer that even though there has been some success with FreeBSD, the PR was severely lacking. Since Linux has been winning the PR game (and I knew about certain issues regarding Linux commercial products), it is pretty obvious that there is a breakdown somewhere. I did keep up with the competition, and the marketing of such, and KNOW that there are some impressive things going on. The good news for FreeBSD, is that some of the competitions' initiatives have been "duds" also. Negative competition by hoping for competitors downfall isn't good (IMO), so it seems that FreeBSD needed a new initiative. The only way to compete effectively with Linux now, is to leapfrog them from BOTH a technological and quality standpoint. In many ways, FreeBSD still has an edge in the quality arena but that has been slowly slipping, and expected to, given the current framework. Technologically, FreeBSD and Linux are very close cousins, with few significant structural differences. The key to staying in the game with them is to overwhelm their product with a vastly superior technology. The other way to stay in the game is by superior marketing (but that doesn't appear to be possible, or likely given current staffing.) Given that, and the FACT that the (ALL) current monlithic kernels have a structure that is stunted for too many current and future needs, and the total lack of support from significant FreeBSD-core members, I decided to solve the problem with another group of individuals. I now have significant support from work (>4 people cooperating, between 10% -> 50%+ time) and various people involved in other OS teams. The new work will be under a BSD-like license, and will easily support POSIX/*BSD semantics, with a combination of performance, scalability (both upwards and downwards), and compatibility that, in combination, is unheard of in the free software world. Work is progressing, and initial results of design work are very encouraging. Context switch times in most cases will be fantastic, and the amount of AS code is significantly less than current *BSD OSes. Since the effort involves people who are interested in portability, large distributed systems, and RT micro controllers, the design is a little more challenging than writing "yet another U**X kernel." The new kernel will accept BSD kernel subsystems to support things like networking, and will have specific features to support BSD kernel emulation. BSD kernel pieces will be added in for emulation and certain native capabilites, but the BSD structure as a whole is being pretty much ignored. I am not giving away much on the structure yet, but even the lowest level context switching methods and code are very very tricky (not really complex, but have to be carefully designed), when working from a clean slate. (Difficult, considering issues of performance, portability, and simplicity.) So, summing it up, the reason why I left FreeBSD-core, was the rash assumptions made by people who really didn't know what they talking about (in the sense of the larger scale of things), and the frustration that I built up trying to make up for marketing problems. Not all -core members are guilty of that behavior, but it only took a few to spoil it for me, due to the extreme amount of effort that I knew that I had to invest (and others would have to invest) to make this new initiative succeed. There would have been that negative "undercurrent" that PHK expressed when I asked the team for support, and such a negative undercurrent would not have been easy to deal with. I didn't see the vision in those core members who decided that I was wrong. I could have stayed, but it just wouldn't have been "worth it." I hereby sentence those who think that I am wrong, to make properly fine grained SMP run in FreeBSD in about 6mos-1yr, and support the mess forever. :-). IMO, the time when it is sufficient to be a BSD kernel technician, in the next few years is coming to an end. There is more that can be milked out of it, but it is critical to invest in the future also. Predominant FreeBSD-core members were obviously not interested in such an investment. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. 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?199807300954.EAA07706>