Date: Sat, 18 Jan 1997 23:09:04 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Terry Lambert <terry@lambert.org> Cc: dennis@etinc.com, hackers@freebsd.org Subject: Re: Commerical applications (was: Development and validation Message-ID: <7144.853657744@time.cdrom.com> In-Reply-To: Your message of "Sat, 18 Jan 1997 16:25:41 MST." <199701182325.QAA12760@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 None of these 4 items are much in dispute, and you are raising "lack of sufficient clued-in personnel to do the job" issues again, not much else. John Polstra (now a core team member) has been working on ELF for a few years now, and I haven't exactly seen a tremendous outpouring of interest in his work - he's probably dropped it back on his TODO list for lack of interest. An outright "move to ELF" is probably also something we've actually been *smart* to avoid up to now, and as much as I'd like to be able to say "we are ELF" for marketing reasons, I think that the amount of sheer upheavel it would have caused would have put a lot of other (more important to our users) projects to get back-burnered while everyone struggled with the migration issues. Sometimes engineers will out-clever themselves in their rush to the latest, shiny technology, and I think that a premature move to ELF would have been a good example of this. Let's fix some of our nastier bugs and give the users something to run before we decide to break the world. Post-2.2 might be a good time. The more-than-on-Intel issue was also a resource problem and, unlike yourself, few of us have had non-Intel systems to even play with. I know that I originally gravitated to the PC because it's the only machine I could *afford*, and I've not been blessed with work situations which netted me cheap/used workstation hardware as a side-effect so that was basically it on the cross-platform issues for me (and no, a pc532 port just wasn't *that* interesting :-) More recently, Walnut Creek CDROM has been generous enough to buy me an ALPHA machine so I could work on the build issues (and hopefully some of the development) for a FreeBSD/ALPHA port and now I'm just trying to locate additional kernel-development bodies to help work on it - the lack of additional ALPHA machines being another problem here, of course, and for which I now have to locate some funds if I want other people to be able to play too - it's just that simple. Anyone with a vested interest in ALPHA support should also contact me about donations - I can hire a certain someone from the NetBSD to do this work if I can raise a year's salary (~$50-60K) for the guy, and that would be a definite win for everyone concerned. He'd get to finish the work he started with NetBSD/ALPHA (which he was yanked off of by his employer) and we'd get someone who already knew the ropes to do our own port. > o Run states for init (not run *levels*, run *states*) for > support of commercial software I think if there were a reasonable set of diffs submitted which did this, they'd have a good chance of getting in. This issue has become less polarized with the passage of time. > o Kernel multithreading/reentrancy changes Work. Someone needs to do it. > > 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 This is a software engineering problem which you must *always* grapple with, no matter how big you are or how many engineers you have. We're in the middle of a growth period right now, and that means that we have to put greater emphasis on solving user problems (even if it sometimes requires an "expedient" type of solution) than we do on pie-in-the-sky "just virtualize the frammitz and ensure that the breemis doesn't cross interface boundries" types of proposals which may be architecturally superior, but will also probably never be implemented in time to save the user's neck. Do that about 10 times and your users desert you with well-justified claims of "those losers don't care about my problems, they just care about some weird hacker asthetic." It also doesn't require much imagination to consider that this might very well have have been what kicked NetBSD in the goolies, despite their cross-platform-and-in-in-some-ways-superior code base. Without some emphasis on the practical issues, it's just a pile of bits at the end of the day. > 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". Actually, I must disagree. We've been making it easier than ever for new people to join the project, as a quick glance at our recent additions to both the committers list and the core team will easily show, and you've managed to make something of a special case out of yourself (well, perhaps Richard W. shares some of that distinction with you) simply by being so gol-darned hard to work with. You will probably disagree in turn, citing yourself as the most model of model citizens, but all I can say is that every time I've asked about your FS contributions or other work within the core team, I get back "Terry's dog ate his homework again. *Smirk*" as a reply, indicating what seems to be a certain lack of faith in your ability to deliver tangible (post-LKM that is) goods from within the core team. I believe John Dyson even recently asked you, for probably the 10th time, if you could possibly submit your patches without 10,000 lines of gratuitous whitespace changes intermixed in, making the patches essentially unmanagable, and you have not to my knowledge replied (and my full apologies if you have replied to John's satisfaction and I just don't know about it yet). Poul-Henning still talks with great amusement about the day he finally received some patches from Terry, only to find out that they had nothing whatsoever to do with the filesystem or with the functionality claims in question. When he pushed back on this obvious mistake, you claimed that your disk had crashed or a Pan Am jet had fallen on your house or some such thing and that the patches were a mistake, but then he never heard another thing about it. Given all that, I can hardly see that your experience with the project could be much different. Change your MO and it's quite possible that many of these "barriers" which you've been perceiving for years will simply go away. This is NOT a social structure issue, this is simply a complete and total lack of trust in Terry Lambert at work, to be somewhat more blunt about it than I'd like to be. Feel maligned, argue back that we've totally failed to appreciate your true worth and if we don't trust you then it's our own dang, dirty suspicious natures at work and not your fault at all, but I'm just telling you how it is. > 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 I'm glad that you recognise that, not out of any ego boost it gives me but because if you recognise that fact then the chances are good that you will also realise that a structure such as ours also has certain inherant limitations (and there was more intent at work in our setting things up this way than I think you realize). The FreeBSD organism, as you put it, is driven primarily by volunteer labor. That means that you can't all just file into a meeting room once a week and have a manager yell at everyone about all the stuff that needs doing "Right Now, damnit!" and have everyone scurrying back to their desks, in fear for their paychecks and possibly a lost reference on their resume. You have *leverage* in a paywork situation which simply isn't there for a volunteer, and if you yell at a volunteer and he takes a walk as a consequence, well, all you've just proven that you aren't a very good manager of volunteers and better find a less heavy-handed approach if you want to keep your whole team. This has other secondary effects as well. Let's take a hypothetical situation: Say Joe Brilliant Hacker comes along, able to code up complex device drivers in his sleep and close, personal friends with both James Gosling and Bill Joy. Joe likes the FreeBSD project and wants to participate, but during the opening conversation it comes out that Joe has all the social graces of a wolverine. Joe is the kind of engineer who thinks that "you're WRONG, you blithering IDIOT!" constitutes "reasoned rebuttal" to any argument, and if people can't take direct, honest critique then it must be because they're bad engineers who can't accept criticism. Joe wants to be on the core team or, at the very least, given commit access when it's painfully obvious that Joe will become a tremendous pain in the backside to all the existing members of the team if we give him the keys to the car. Do we let Joe in? No. Despite all of Joe's talents, it is clear to even the most casual observer that Joe is a ticking time-bomb, likely to drive everyone else away and the project to its knees in no time flat, so we try and work out some OTHER way for Joe to participate, perhaps through one or more other team members as insulators. If it turns out that Joe doesn't want to play, well, sorry but we did our best to accomodate someone in a bad situation. And no, I don't equate you with Joe in this example since your social graces are not an issue, I simply try to make the point that someone who should be brought in for engineering reasons is also often exactly the wrong person to bring in for every other reason. This could be, I suppose, seen as a basic limitation of the FreeBSD structure, but it's one I'm willing to live with since it has, despite many obstacles, continued to function better than even the most optimistic individuals dared hope. It functions largely because the existing core team and project member list has been picked with as much care as we could exercise, those few members who were unable to function effectively in a group being weeded out long ago, and everyone in it gets along very well. We may not think alike on all issues, and occasionally we disagree violently on things, but we've evolved beyond the need for shouting about them and generally even know when to pick up the phone and call one another when things seem to be running too far off the rails. Contrasting this with some of the antics of our sister groups, I'd say we're doing pretty well and all of this would be in danger if we just threw the doors open and invited everyone into the core team who thought they ought to be there. It's an invitation-only process for a reason, and that reason is self-protection rather than simply protectionism as you often see it. > 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. I don't see any "pains" which aren't the obvious result of growing pains, those being rather difficult to avoid unless you also avoid growth, and if NetBSD and OpenBSD are having any trouble I think it's more due to a lack of attention to certain critical details. > 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 don't think that we steadfastly refused to discuss it so much as simply didn't see: 1. That you were perceiving the "problem" correctly at all, and hence interested in a discussion which we couldn't even see the point of, much less want to spend time arguing. 2. Even if your perception of our problems was correct, and I have worked from that scenario as a possibility when trying to read your stuff in the past (figuring that if I could put myself in your perspective, I'd at least see the proposals clearly), I don't think that any of your proposed solutions are actually credible. So, if in our perception if you're either completely wrong about the problem or completely wrong about the solution, either way there's not likely to be much interest in discussion. :-) > I attribute this to the insiders not being able to see the threshold, > since, as insiders, they aren't personally being impeded (although I'm able to extrapolate as well as the next guy, and I can *see* the degree of impediment that someone (like our ficticious Joe) might feel at getting their work accepted if circumstances are such that we don't feel the trade-off to be worth it, but that doesn't mean that we still didn't make the right decision about where that threshold is. You see crisis management as our only problem, but history will also show that embracing the wrong people in our quest for progress ultimately cost us far more in terms of lost time, aggrevation and general unhappiness when we found ourselves to be sudden bedmates with a rattlesnake and needed to drop everything and get him out of the tent before he bit somebody. We're not big enough yet that someone like "Joe" can work in a corner and not bother anyone else. Maybe when that day comes, we can look at reevaluating that threshold. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7144.853657744>