Date: Sat, 18 Jan 1997 16:25:41 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, dennis@etinc.com, hackers@freebsd.org Subject: Re: Commerical applications (was: Development and validation Message-ID: <199701182325.QAA12760@phaeton.artisoft.com> In-Reply-To: <5996.853624780@time.cdrom.com> from "Jordan K. Hubbard" at Jan 18, 97 01:59:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > And in some respects, FreeBSD has refused to learn this lesson, being > > too proud to be 2nd to market with Linux technology (or SVR4 technology) > > because "it's not BSD'ish enough"). > > "Such as?" > > If you raise issues like dos emulation I'll also throw things at you > because this, like many other Linux features, has not succeeded due to > lack of knowledgable bodies to do the work rather than some anti-SV4 > mindset at work. o Move to ELF o Kernel exported symbols stored in kernel address space for module linking to fix LKM dependency/unloadability problems o Module loader in kernel address space (automatic, assuming a cleanly architected ELF image loader, and LKM's as ELF objects) o A build system that can support more than just Intel platforms o Run states for init (not run *levels*, run *states*) for support of commercial software o Kernel multithreading/reentrancy changes o More and more subsystems having architecturally bereft patches applied to them for reasons of expediency (make the problem submerge instead of fixing it). Question: how many of the recent kernel changes have been made with a view to the overall goals of a subsystem? I'm betting Johns VM work and the SMP work are probably your sole examples o etc. I'd need a lot of time to assemble a full list, but in general, any place the ease of participation trade-off is not being made in favor of increasing the number of participants. Or, in reality, the "number of participants threshold". Naievely, some of that should be in making FreeBSD "sexy", by adopting new technology while it is still new, and good technology without regard to ethnic purity. And some of it should be in being more concerned for "FreeBSD the platform" instead of "FreeBSD the means of me realizing my individual research project"; the goals are not mutually exclusive, since there is such a thing as research based on a research platform, where the platform is not the object of the research. A simple way of stating it is: To allow others to stand on the shoulders of giants, there must first be giants. There are also a lot of us who would consider ourselves "knowledgable bodies" who feel impeded by the limited "core team" social structure. Defend its grace and beauty if you like; we will continue to *feel* impeded. This is a social issue. It's interesting to note that the FreeBSD "organism" is the second largest singlar society on the Internet (Linux is the first). No news groups can make readership claims on similar order, or if it can, can not make similar claims on cohesiveness. Even getting to be second in this new social implementation space is probably more historically significant than any impact FreeBSD will have on the direction of technology (it's stated goal of research notwithstanding). I find that idea to be disconcerting; it flies in the face of intent: clearly, there is a discrepancy in design vs. goal somewhere. In any case, there is adequate evidence of the rundown of the model used by FreeBSD (and NetBSD and OpenBSD) at a given population threshold -- the pains we see are the self-limitation of the social model. Linux has a social model which is one order of fractal complexity above that of FreeBSD/et al., and it seems to be reaching it's self-limitation threshold as well (evidence: someone has finally done modular console work, yet Linux is not integrating it -- there are three or four simiar examples, but that one is the most obvious self-limitation induced error). We've had this discussion before, and you and everyone else have steadfastly refused to discuss meta-issues of social reengineering of the organization to facilitate growth past the current self-limitation threshold. I attribute this to the insiders not being able to see the threshold, since, as insiders, they aren't personally being impeded (although David has admitted to being stuck fighting fires <::= crisis management> instead of being able to pursue the goals he wants to pursue: I'd call that impeded, even if he doesn't). Better I make the attribution of the insider responsibility there (ignorance) than elsewhere (malice). For what it's worth, OpenBSD isn't an answer (neither is J"org's "TerryBSD", unless I pick a different model), since it *must* be structurally predestined for the same cul-de-sac by the same inevitable mechanisms of social dynamism, if built on the same dynamic model. Systems engineering is systems engineering, and it doesn't really matter if the substrate for the implementation is an OS or a society or a fragment of silicon in a doping oven. An automaton built from a template and run on (homeomorphically) the same data set, will run down to the same steady state; this is a simple mathematical certainty. Since really no one is interested in this discussion (or at least "no one capable of doing anything about it by virtue of historically indentured membership in the existing power structure"), I'll just go back to being the observer. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701182325.QAA12760>