Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.erols.net!panix!news.panix.com!not-for-mail From: tls@panix.com (Thor Lancelot Simon) Newsgroups: comp.unix.solaris,comp.unix.bsd.misc,comp.unix.internals Subject: Re: Solaris 2.6 Date: 1 Dec 1996 03:16:05 -0500 Organization: Panix Lines: 117 Distribution: inet Message-ID: <57res5$j7k@panix2.panix.com> References: <32986299.AC7@mail.esrin.esa.it> <casper.329ae8f2@mail.fwi.uva.nl> <57fipg$q7j@panix2.panix.com> <casper.329c06bc@mail.fwi.uva.nl> Reply-To: tls@rek.tjls.com NNTP-Posting-Host: panix2.panix.com Xref: euryale.cc.adfa.oz.au comp.unix.solaris:91000 comp.unix.bsd.misc:1637 comp.unix.internals:11381 In article <casper.329c06bc@mail.fwi.uva.nl>, Casper H.S. Dik <casper@fwi.uva.nl> wrote: >tls@panix.com (Thor Lancelot Simon) writes: [lots of good stuff snipped -- I fear I just don't have the time.] > >>Yes, objects with different ideas of the size of basic types should not be >>linked together. This is pretty elementary. However, this is a pretty >>small fraction of the total number of precompiled programs out there, and >>there _are_ methods of dealing with it; if you have to, you can ship a >>32-bit-offset toolchain _temporarily_ instead of gunking up interfaces and >>libraries _forever_. > >Well, forever is a bit harsh. There's still only a 32bit Solaris., this >will be rectified when you have get a 64 bit Solaris So what you're saying is that this is going to change _again_? That there's going to be a "64 bit Solaris" and a "32 bit Solaris" and never the twain shall meet? That's even more ridiculous than what we're arguing about in the first place. [snip] >>There are commercial operating systems based on 4.4BSD. In fact, the last >>time I looked, despite Sun's touting itself a bigtime player in the >>Internet/intranet server market, it was _losing_ market share there to >>4.4-based systems, although of course everyone loses market share to Linux, >>too. > >There was no installed 4.3 BSD base worth mention on hardware now supported >on 4.4 BSD. There never was a big transition requireing serious binary >compatibility. Wrong. The off_t change we're speaking of occurred between Net/2 and 4.4-Lite -- BSDI shipped systems based upon each, and had to change over. They don't seem to have had many problems. For another example, NetBSD on the HP9000/3XX has replaced MORE/BSD (essentially 4.3 plus Sun NFS) in many applications; for yet another example, NetBSD runs binaries from _many_ 4.3BSD systems, notably Ultrix on the VAX and DECstation, NetBSD 0.X/FreeBSD 1.X/BSDI 0.X/1.X on the i386, and SunOS on the 68k and SPARC. >>No, but guess what? In the timespan between 4.3BSD and 4.4BSD, Sun did that >>_twice_. Tell me, can you take SunOS 3 .o files and link them to a SunOS 5 >>program? Same span of years. Pot-kettle-black. > >Twice? Once. And do you think this experiience is something Sun or its >customers want to repeat? Wrong. Twice. Jeez, you work for Sun? You can't take SunOS 3.X .o files and link them together with SunOS 4.X .o files, and you can't take SunOS 4.X .o files and link them together with SunOS 5.X .o files. This is particularly ironic in that it represents you altering your argument yet again after being enlightened about how you'd misrepresented the attitudes and practices of the BSD projects. The text you quote above was in response to your claim that the Berkeley camp didn't care about binary compatibility because it's not possible to link 4.3 and 4.4 .o files together -- in the space of time between 4.3BSD and 4.4BSD, as I said, Sun did that *twice*. >>Well, yes and no. In the first place, if you do this the 4.4 way, there _is_ >>no such thing as a "large" fd. Now, obviously, a 32-bit program can't seek >>off the end of a long file; the old lseek() won't let it. The only problem >>you really have is with programs which explicitly do an ftruncate() without >>checking to see if they're at the EOF first. There aren't many of these. If >>you make sure you change all the system utilities, nobody's ever likely to >>get bit here -- almost nothing actually ever creates long files, and the >>applications which do do so, like databases, handle their files with their >>own tools, so when the database engine goes 64-bit its tools will, too. > >There are many programs doing seeks/reads and writes intermiexed. > >a 32 bit program can easily read past the 31 bit boundary fetch its >current location with lseek() (truncated to 32 bits) and store it to >later seek to the wrong, truncated address, and than write there and >corrupt the files. > >>Even exporting this difference to the libraries is a huge lose. And I can't >>use non-broken 32-bit programs with the new long files without explicitly >>performing some kind of conversion on the fd before handing it to them, right? > >You can; you must open it in large file aware process. So you're then admitting that if I do it your way I can *still* experience file corruption because of programs compiled for 32-bit off_t, aren't you? >The solution chosen in the large file summit had one consraint: >there shall be no file corruption when using 32 bit applications. > > >Your solution hasn't given us that (but then, there was no installed base >that could complain). And making objects incompatible, without >the ability to tell them apart or with (by changing the ELF version) >would have increased the hassle for system administrators and developers >a like. Wrong. There _was_ an installed base that could complain. There you go once again, blithely demonstrating that Sun -- and its employees -- really know very little indeed about anything that wasn't invented at Sun. The hassle was minor, and nobody in particular has complained -- the benefit clearly outweighs the loss. >The largefile solution chosen is painless for customers, though harder to >maintain. It's fundamentally broken, demolishes one of the great consistencies about Unix which has traditionally made it preferable to other operating systems, and is exemplary of the kind of shortsighted thinking exhibited by a commercial vendor which is rapidly losing its clue. "Customer" != "moron", you know. A great many of us care about the elegance of solutions. -- Thor Lancelot Simon tls@panix.COM There's nothing like rancid bear fat to keep you happy. -Perry Metzger