Date: Mon, 1 Jun 1998 18:30:39 -0500 (CDT) From: Richard Wackerbarth <rkw@dataplex.net> To: Terry Lambert <tlambert@primenet.com> Cc: current@FreeBSD.ORG Subject: Re: Fix for undefined "__error" and discussion of shared object Message-ID: <l03130308b19893b523d4@[208.2.87.10]> In-Reply-To: <199806011904.MAA04619@usr01.primenet.com> References: <l03130301b1977e68fd4e@[208.2.87.10]> from "Richard Wackerbarth" at May 31, 98 09:57:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:04 PM -0000 6/1/98, Terry Lambert wrote: >You conceded first by stating that what you were talking about was a hack. Unfortunately, the code that we consider "a hack" is someone else's prize code. :-) He won't be happy that you have dropped support for it. >> >Well, I am (I hope) well known as an advocate of "revolution instead of >> >evolution"; technology moves too damn slow for me as it is >> >> If you are successful, FreeBSD will not reach 235.x. It will have gotten >> another name long before. > >I doubt that. BSD can absorb technology and remain BSD. The 2.x systems >didn't support NFS, for example; is BSD any less BSD now that it does >support NFS, yet has dropped support for the old "berknet" serial >networking? I think that the "marketing types" will tell you that there is a middle ground in numbering. Only the foolhardy adopt the 1.0 version of anything. (It still needs "shaking out".) Similarly, when the number gets too big, most people think "legacy warts". (They want something fresher.) The solution is easy, just change the name and start numbering again. :-) This is especially true if you have a "relvolution" rather than incremental change. >ELF is one very good example. IMO, -current users should all >be running ELF systems now; -current is not -release, and the sooner >-current moves to ELF, the faster things can be tested. The fact >that you have to drop slash-screen support, etc. to get a dual boot >is irrelevent. We should take the hack, with the expectation of >getting rid of the a.out boot code to resolve the size issue at >some future date. Here, I agree. IMHO, we have gone too long, and have too many projects "almost" there. We need to do whatever is necessary to get some of them firmly "in" and move on. >> Aren't we really just emulating an "XANDF" machine with an XANDF->whatever >> micro-code expanded inline? Where is my XANDF native machine? > >No. There is a fundamental difference here. XANDF is not JAVA; it's >not a bytecode format, it's a distribution formant. But it still has a set of acceptable constructs. I argue that these are the "instruction set" of this virtual machine. > The code still needs architecture specific peephole optimzations, etc.. Does it "need" them (as in REQUIRE)? The optimizations could equally be viewed as a part of an efficient emulation. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130308b19893b523d4>