Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!uunet!in2.uu.net!206.13.28.13!news.pbi.net!news5.crl.com!nexp.crl.com!usenet From: "Jordan K. Hubbard" <jkh@FreeBSD.org> Newsgroups: neosoft.users.freebsd,comp.unix.bsd.freebsd.misc Subject: Re: Free BSD trouble Date: Mon, 03 Feb 1997 13:58:50 -0800 Organization: Walnut Creek CDROM Lines: 36 Message-ID: <32F65F99.4487EB71@FreeBSD.org> References: <32EAF919.17A0@neosoft.com> <5cflae$gal@bonkers.taronga.com> <5cpfsk$fqk@uuneo.neosoft.com> <32F15A22.6221@onramp.net> <32F24842.1CFBAE39@FreeBSD.org> <cslo99z6yk.fsf@Starbase.NeoSoft.COM> <32F3D587.1ABF@onramp.net> NNTP-Posting-Host: time.cdrom.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 3.0-CURRENT i386) Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:34651 Dave Littell wrote: > However, my original comments were indeed based on the observations of > someone who has decidely "done their homework" on these types of issues, > recognized what was happening, and described it as "incomplete standards > compatibility testing during the mastering process". This, in > conjunction with Jordan's own statement that 2.1.6 was sorta rushed out Ugh. Well, just for the record then: 1. All CDROM images sent to mastering have been created with the same mkisofs mastering software I've been using since FreeBSD 2.0. The files on the filesystem are checksum verified with brik after a one-off has been burned and with the same Sony 74min gold media being used for some time now without trouble. 2. The mastering and replication was, to my best knowledge, done by the same pressing plant as the 2.1.5 CD and to the same quality control standards. 3. Nothing with 2.1.6's production was rushed - quite the opposite. It was plagued with innumerable delays and almost cancelled at least once when it looked like projected ship days were turning into weeks. There was never any pressure on the replication house to ship any faster than normal. So, given all that, I still fail to see what it might have been about "the mastering process" which could have caused Dave Littell's problems. A physically bad CD or actual bugs in the code are always possibilities, sure, but you don't flag them as something "someone clearly screwed up in the mastering" unless you've got a clear and obvious reason to think that. That was all I took offense to, and my engineer's mind rebells at conclusions without proper supporting evidence being presented in general as it is. -- - Jordan Hubbard President, FreeBSD Project