Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!uwm.edu!math.ohio-state.edu!howland.erols.net!surfnet.nl!news.nic.surfnet.nl!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.32a1813c@mail.fwi.uva.nl> Date: 1 Dec 1996 13:59:41 +0100 Organization: Sun Microsystems, Netherlands Lines: 151 Distribution: inet Message-ID: <casper.32a1813c@mail.fwi.uva.nl> References: <32986299.AC7@mail.esrin.esa.it> <casper.329ae8f2@mail.fwi.uva.nl> <57fipg$q7j@panix2.panix.com> <casper.329c06bc@mail.fwi.uva.nl> <57res5$j7k@panix2.panix.com> NNTP-Posting-Host: mail.fwi.uva.nl Xref: euryale.cc.adfa.oz.au comp.unix.solaris:91014 comp.unix.bsd.misc:1638 comp.unix.internals:11382 tls@panix.com (Thor Lancelot Simon) writes: >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. Yes, there's going to be a 64 bit Solaris and a 32 bit Solaris (for as long as we support 32 bit hardware which will be quite some time) 64 bit Solaris will give you the ability to compile programs in a 64 bit address space, obviusly it won't be possible to mix 32 bit and 64 bit objects as all pointers have different sizes. The 64bit Solaris will be able to run (and create) 32 bit executables. Are you saying that *BSD will be able to move to a 64 bit OS without any changes in ABIs? Neat trick. >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. Like they had a large installed base and many 3rd party products. It's really a different game altogether. In th beginning BSDI only sold to BSD enthousiasts. To paraprhase Rob K: "then we found that nobody wanted to buy an OS, so we quit the OS business and started selling internet servers". There's a big difference between selling changing this for an OS with small installed base and *no* 3rd party products and a few 100,000s wotrth of customers running 1000s of different 3rd party applications each of which may or may not ship with objects which would require a new release for 2.6 if we'd adopt a "you need to recompile all folks" BTW, I fail to see the principal the difference between having open/open64 in libc and having them in the syscall table only. Did BSDI have shared libraries? >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. Oh really? You *can* link SunOS 3.x a.out files and combine them with SunOS 4.x files., I didn't work at Sun abck then, but I'm 100% sure I relinked 3.x .o files on 4.x. Unless, of course, you're talking SPARC vs m68k which I guess makes sense as hardly no SPARCs where supported in 3.x (there was SPARC-3.2 which only supported the early 4/1xxx and 4/2xx, I I recall). No chanegs occured bwteen 3.x and 4.x which required you to recompile 3.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*. I'm not altering my argument, I';m adding to it. And you apparently feel that shipping a handful of net-2 based BSDI copies gives the same requirements for maintaining binary compatibility as does shipping 100,000s of copies of an OS with many 3rd party products. That simply isn't so. I'm right, but you conveniently ignore my most important argument: .o files must be usable from different sources with the OS .o files. Your solution would have been much easier for Sun, but *much*, *much* more difficult for Sun's cutsomers and ISVs. >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? Only if: a 32bit aware program opens a large file and hands it off to a non-32 bit aware program Fds are inherited frequently, of course, but I've never seen a DB program having a separately compiled frontend or shell open its database files. >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. You conveniently ignore my arguments. You have demonstrated *no* solution for binary compatibility which would work for Sun nor have you argued why our constraints are invalid. Let me repeat: - .o/.a/.so files from 3rd part vendors should still be linkable with system libraries and other 3rd part/locally installed libraries. - you shouldn't have to do "make clean" or alter makefiles after upgrade. - you shouldn't need to synchronise 3rd party library upgrades [like a graphics frontend & a database backend lib from diff. parties] - you should be able to ship such 3rd party products for Solaris 2.[456] withouth having to worry much about it. >The hassle was minor, and nobody in particular has complained -- the benefit >clearly outweighs the loss. I don't argue that the *BSD solution wasn't best for them; it's different market, there are different numbers. I really wish it was that easy; there are so many ABIs which really need changing/extending. If we'd could every body to recompile all there stuff, that'd be great. But that isn;'t the real world. >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. Oh, how's that? You don't see it. It's *hidden* from view. It's as visible as the new system call numbers in *BSD. You don't need to recode. >"Customer" != "moron", you know. A great many of us care about the elegance >of solutions. I believe that only a fraction of the customers in the class "customers" != "moron" care about this sort of thing. Most people care about whether something works and care infinitely more that they can upgrade their OS and get better performance, yes the latest hardware, etc, without having to worry whether they have to buy upgrades to all their 3rd party products. (Of course, the ultimate counter argument would have been "MS windows" but you're probably one of those people thinking that MS windows users are morons by definition and you'd probably figure you'd won the discussion by comparing Solaris to MS Windows, whereas I just compared MS Windwos uers to Unix users) 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.