From owner-freebsd-current Mon Nov 13 23:38:52 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05560 for current-outgoing; Mon, 13 Nov 1995 23:38:52 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05555 for ; Mon, 13 Nov 1995 23:38:49 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id XAA26338; Mon, 13 Nov 1995 23:38:01 -0800 To: Nate Williams cc: Charles Henrich , freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Mon, 13 Nov 1995 18:25:22 MST." <199511140125.SAA01060@rocky.sri.MT.net> Date: Mon, 13 Nov 1995 23:38:00 -0800 Message-ID: <26335.816334680@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Since the VM system is *very* sensitive to even minor modifications, I > suspect it would have taken a *very* long to review the patches, apply > them to the system, and then test them. Even very simple errors can > cause *massive* corruptions, and I'm sure both David and John would > rather avoid that for something as critical as the 2.1 release. There's another issue, which is that David and John have been the entire VM system development team for awhile, not to mention actively involved in many other areas. To put it succinctly: They need help. We (the project) need more kernel hackers willing to go into the labyrintian depths of the code and carefully follow all the little chains of cause and effect that make things happen the way they happen (or occasionally not happen, which is when serious debugging skills are required). This is not easy work, and I've sat on the phone with David a number of times while he's chased a bug, listening to some of the steps required. Writing dozens of little test programs, carefully engineered to cause one bug or another, loading a system to the gills and watching it very very carefully at a number of different "test points" to see just how it's working. For those who've done any serious hardware work on complex pieces of hardware, you'll know the picture well. You end up with the equivalent of frankenstein's lab - various multi-channel logic analysers plugged in at different points, an oscilloscope or two, jumpers running hither and yon. It's not something for the faint of heart, and being able to *read* all those signals and say "aha!" from the faintest twitch of line A522 on some obscure multi-channel oscilloscope trace, thus knowing the problem and fixing it, is not a skill that grows on trees. Maybe we should try to make the project an accredited university, then at least those who gained such skills here could earn some recognition for the fact in the marketplace. CS majors could "intern" with us for awhile. :-) Jordan