Date: Sat, 28 Nov 1998 10:42:13 -0500 (EST) From: Louis Bertrand <louis@signalpath.on.ca> To: Terry Lambert <tlambert@primenet.com> Cc: advocacy@openbsd.org, netbsd-advocacy@NetBSD.ORG, FreeBSD-advocacy@FreeBSD.ORG Subject: Re: Merging Net/Free/Open-BSD together against Linux Message-ID: <Pine.BSF.4.03.9811281026340.2219-100000@tronix.signalpath.on.ca> In-Reply-To: <199811272232.PAA20989@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry nailed it down exactly: it's a tradeoff between innovation and adoption. All those standards made it possible to build the internet as we know it, but new ideas will have to co-exist with old implementations. Your libc example is one case where you see an obvious improvement, but then you'd have to rewrite the kernel, the utilities and patch anything you put in the ports tree. Your wealth has become baggage you must carry forward. I agree with Terry about the damage a bad standard can do, and a discussion of hardware vs. software standards-making is outside this topic. Ciao! --Louis Louis Bertrand, Bowmanville, ON, Canada <louis@signalpath.on.ca> vox +1.905.623.8925 fax +1.905.623.3852 OpenBSD: Security matters <www.OpenBSD.org> On Fri, 27 Nov 1998, Terry Lambert wrote: > > In my experience in the hardware domain, standards favour widespread > > adoption but stifle innovation. > > You mean like FTP, SMTP, HTTP, HTMP, and MIME "stifle innovation"? > > Or do you mean like ELF, DWARF, NROFF, and SGML "stifle innovation"? > > Or perhaps ANSI, POSIX, and XPG/4? > > I'd agree if you wanted to say "Bad standards, like ISA, stifle > innovation", though... > > I think that software standards tend to codify interfaces, and that > hardware standards tend to codify implementations. > > Very different spaces. > > Not that I would mind rewriting all of libc to get rid off all static > or per thread allocated buffers, and to make all functions return only > status codes, forcing data returns to be implemented by passing a > return area by reference, mind you. I would *love* to see: > > int > ftell( FILE *stream, off_t*result) > > typedef u_int64_t off_t; > > (one example whre return values are overloaded to return error > information, to the detriment of the long term utility of the > interfaces). > > I would also *love* to see a method whereby the argument sizes are > passed as part of the information so that system call interfaces > can be easily and safely versioned without proliferating entry > points. > > But of course, that would constitute a "calling _standard_". > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.03.9811281026340.2219-100000>