Date: Wed, 2 Apr 1997 11:40:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mallison@konnections.com (mike allison) Cc: terry@lambert.org, nate@mt.sri.com, proff@suburbia.net, chat@freebsd.org Subject: Re: Internal clock Message-ID: <199704021840.LAA14074@phaeton.artisoft.com> In-Reply-To: <3343F926.5BA1B96E@konnections.com> from "mike allison" at Apr 3, 97 11:38:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's not a matter of knowing how someone will use it, it's a matter > > of not closing off possible uses through poor design considerations. > > It's not so much a matter or reasonable use, but reasonable use within a > set of established parameters. If you run into soething that wasn't > planned for, but later think might be reasonable, AND won't work. You > must decide whether it's important enough to rebuild the whole system or > move on. I think we've seen that too often since MSDOS 1.0, System 7, > OS/2 and all the proprientary minicomputer systems. The implementation > team has to decide what's reasonable and what hooks to leave in. The > later programmers are charged with using those hooks and not building > something into their application which damages other apps through poor > or irresponsible programming. Yes. One historical problem DOS has always faced is an unwillingness to fix something because of historical compatability issues. Those compatability issues derive from the original design being NP incomplete and therefore people "routed around the damage". Effectively, their design is screwed now because it was screwed then. Luckily(?) FreeBSD has very little in the way of users who have routed around damage, and are therefore dependent on FreeBSD keeping historical crap for marketing rather than technical reasons. This is most likely attributable to FreeBSD being a protected mode OS, more than to any good planning on FreeBSD's part. Take luck where you find it, I say. > I think that's Terry's point in "design considerations". The Linux > folks have the problem of EVERYONE being part of the design team. It > win't be long before there are SERIOUS and INHERENT incompatabilities > between different distributions of the same LINUX release. > > That's why you have and must use the core team to set the parameters. > You're never going to be able to anticipate what's even reasonable. The > design team DICTATES what's reasonable on their system. Yes. By seperating the "requirements" from the "implementation", you get the widest possible range of uses, while limiting the number of people stirring the pot. As in cooking, taking everything you have which tastes good and putting it in one pot and baking it will not result in something which tastes good. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704021840.LAA14074>