Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!spool.mu.edu!newspump.sol.net!howland.erols.net!portc02.blue.aol.com!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!EU.net!sun4nl!fwi.uva.nl!not-for-mail From: casper@fwi.uva.nl (Casper H.S. Dik) Newsgroups: comp.unix.solaris,comp.unix.bsd.misc,comp.unix.internals Subject: Re: Solaris 2.6 Supersedes: <cancel.casper.32a42353@mail.fwi.uva.nl> Date: 3 Dec 1996 13:55:48 +0100 Organization: Sun Microsystems, Netherlands Lines: 90 Distribution: inet Message-ID: <casper.32a42353@mail.fwi.uva.nl> References: <32986299.AC7@mail.esrin.esa.it> <casper.32a3e5ae@mail.fwi.uva.nl> <580sgh$kpi@panix2.panix.com> <casper.32a40b7b@mail.fwi.uva.nl> <58131t$min@panix2.panix.com> NNTP-Posting-Host: mail.fwi.uva.nl Xref: euryale.cc.adfa.oz.au comp.unix.solaris:91290 comp.unix.bsd.misc:1668 comp.unix.internals:11439 tls@panix.com (Thor Lancelot Simon) writes: >You put "oh, just recompile everything" in quotes, and yet neither I nor >anyone else in this discussion has, in fact, offered that suggestion. Why are >you implying that I did so? I do not -- in fact, I offered examples of >operating systems which have used an alternative solution, notably SCO -- but >I'm entirely sick of discussing it with you, because you keep making things >up and acting as if I'd said them, which is patently false. Think how you're >making Sun look by doing this; it's not like it isn't obvious to everyone else >reading, too! Your position that it is acceptable to have in essence two types of objects, one of which can no longer be used in the release after the current, pretty much boils down to "just recompile all libraries/ object files". That, atleast, is how I understand SCO's option works. I thought I made it clear that linking with different (old) headers and different (old) libraries was out of the question. If you have a solution that satisfies that particular constraint, pray tell. I'm not known for being , I typically don't resort to name calling, and I'm sorry I did. I'm getting rather frustrated about being the only one discussing things. After two or so iterations in this thread, any arguemtns I have against your solutions have been ignored, clipped from your follow ups, fallen to deaf ears. As for making Sun looking bad, I don't think I'd trust your judgement on that. >The "lesser important" file corruption argument? About ten posts ago you >claimed that avoiding file corruption was the "one constraint" by which Sun >chose its implementation. You keep changing your argument so that you can >claim that nobody's addressing your (latest) points! Perhaps you should see my posts as incremental, rather than believing that I switch from one argument to the other. I'm not sure what's really more important in general: file corruption or binary compatibility. In this particular case both apply, but binary compatibility is the one all customers will see. Only customers manipulating large files could face a file corruption problem. But , come to think of it, the file corruption issue is largely orthogonal to the discussion at hand. *BSD could have been as protective as the large file API summit was, without changing anything in the visible interfaceJust make 32bit off_t apps that use the old interfaces fail on large files. >Sigh... now I really do give up. I don't appreciate your snipping my text to >fit your argument, either, as usual with no indication that you've done so. I snip text, I'm not aware of snipping text to fit my argument. Oh, and here you snip yet another invitation to take the full binary compatibility issue serious. I've explained why SCO's option isn't one, three times already and twice more in this post. >Oh -- and by the way, I'm still waiting for you to prove _anything_ in this >discussion "beyond the shadow of a doubt". I know _I_ haven't, but then >again, I've never claimed to. Well, as long as you don't come with counter arguments, I cannot believe otherwise. Let me repeat: compiling with different includes & libraries is *not* an option. You must be able to use old and new object files together. I've explained a number of times why that is necessary, so I won't rehash *that* part of the argument. You've not suggested a method in this discussion that could satisfy that contraint. I'm sorry I brought "bigot" into this discussion, but I got a bit frustrated because I have the feeling I'm talking to deaf ears here. Let's be technical again and perhaps someone can address the point in my last few paragraphs. Casper -- Casper Dik - Sun Microsystems - via my guest account at the University of Amsterdam. My work e-mail address is: Casper.Dik@Holland.Sun.COM Statements on Sun products included here are not gospel and may be fiction rather than truth.