Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!portal!cup.portal.com!ts From: ts@cup.portal.com (Tim W Smith) Newsgroups: comp.arch Subject: Re: Intel bugs / bugged by Intel :-( Message-ID: <35702@cup.portal.com> Date: 7 Nov 90 19:35:07 GMT References: <15632@netcom.UUCP> <35325@cup.portal.com> <1990Oct30.210852.15087@mozart.amd.com> <8527@scolex.sco.COM> <75@anomaly.sbs.com> Organization: The Portal System (TM) Lines: 37 I wonder if reluctance to reveal bug lists is partly to encourage bug reports? I used to work for a company that sold a Unix machine. We bought our Unix port from a company that specialized in porting Unix for people. Their policy on bugs was that if you reported it, they would confirm it and fix it in the next release (~6 months). They would not tell other companies about the bug unless those companies found it themselves. For a company that had no in-house Unix experise, this sucked. However, for a company like ours, which had a lot of such experise, it wasn't that bad. We would find a lot of bugs and fix them ourselves. The result was that our release would work better than many of our competitors release, because we had fixed these bugs. The competitors would not get these fixes until the next release from the port vendor, so we had a better Unix release. If the port vendor had been free with the bug list, there would have been a definite temptation on our part to *NOT* report bugs, but to simply fix them ourselves. It would have been a hassle to keep integrating our fixes into each new release until the port vendor found and fixed the bugs, but it might have been worth the hassle to keep our kernel better than our competitors. On the other hand, such a policy encouraged in-house Unix expertise from the clients of this port vendor. When it became time to move to a demand paged VM form of System V (this was a long time ago), we did it ourselves rather than wait for the port vendor. This was probably not something that pleased them! This is not meant as a defense of secret bug lists. It is just meant as an example of where such secrecy might have a semi-rational basis. It probably does not apply to hardware, since once you build something with a chip, you usually don't update it, unlike software. Tim Smith