Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!yarrina.connect.com.au!harbinger.cc.monash.edu.au!msuinfo!uwm.edu!news.moneng.mei.com!howland.reston.ans.net!gatech!prism!prism!not-for-mail From: gt8134b@prism.gatech.edu (Robert Sanders) Newsgroups: comp.os.386bsd.questions Subject: Re: Linux or FreeBSD? Date: 28 May 1994 23:47:09 -0400 Organization: Georgia Institute of Technology Lines: 185 Sender: gt8134b@prism.gatech.edu Message-ID: <2s937t$7sp@acmex.gatech.edu> References: <CqH2z7.29E@dit.upm.es> <2s618a$34t@pdq.coe.montana.edu> <2s86fj$cn4@acmex.gatech.edu> <hastyCqJBED.9yz@netcom.com> <2s8mbn$e1o@acmex.gatech.edu> <JKH.94May29030102@whisker.hubbard.ie> NNTP-Posting-Host: acmex.gatech.edu jkh@whisker.hubbard.ie (Jordan K. Hubbard) writes: >In article <2s8mbn$e1o@acmex.gatech.edu> gt8134b@prism.gatech.edu (Robert Sanders) writes: >Ok, everyone generally knows that I'm always careful to stay neutral >on the classing FreeBSD vs Linux issue, and I have always felt that But this isn't one of those issues! Sure, that's the subject, but the whole point of my two (now three) posts was to simply explain why some people who had used both Linux and FreeBSD came away with the subjective feeling that Linux was much faster. I don't give a damn about feature comparisons from other people: my roommate and I went out and *tried* it. In the same vein, I don't try to offer authoritative feature comparisons; I merely summarize my expereinces. If anything, I was trying to cut this flamewar off at the pass by explaining that much of the apparent speed difference wasn't as significant as it seems. >it's most important when discussing the two to BE HONEST about the >relative strengths and weaknesses of each one. You don't win >credibility for your OS of choice by saying things like "Our OS never >ever crashes and is totally and absolutely good in every respect and >anything you say to the contrary is BS, so there!" With that in mind, >I'd like to clear up a few points. You're fighting straw men, Jordan. I never said that. I'm not trying to win credibility for anyone, but if I were, it would be for FreeBSD. Two separate messages on this group expressed dismay at the relative speed of FreeBSD; one even said that out of Linux, Windows, etc., FreeBSD was the slowest OS he'd had on the machine. I was trying to explain that it isn't that slow, that it's just tuned less for interactive response than Linux was. > were a bad thing. For your information, I've lost filesystems twice, both > times due to bad disks; Linux's ext2fs has proven very reliable for me. >I'm sure that ext2fs has improved immeasurably since it first came >out, but just to note that some of its well-deserved suspicions have >come from early instability and the fact that one little f**kup could >generally cost you major chunks of your filesystem! If it's since >come along to the point where its stability ranks up there with FFS, >that's great, but also acknowledge that some people who've known it >for awhile have every right to be suspicious until it's really earned >its stripes. Well, this caveat could apply to all of Linux; none if it was very stable until fairly recently (in UNIX time). I'm talking about the here and now, and ext2fs in versions 1.0 and later is a *very* stable filesystem. I've been using ext2fs since the very first ALPHA release. I know how unstable it used to be, but believe me, it's fine now. > If you want to impress me with filesystem stability, show me BSD 4.4's > log-structured filesystem running under FreeBSD. >If that's what it will take, then all I can say is wait about, say, >8-10 weeks or so for the first ALPHA snapshot of FreeBSD 2.0 :-) I can't wait. I'd like some of the BSD4.4 magic to filter over into Linux. We should all benefit from the CSRG's dying breath. > I'm very well aware of the advantages of both implementations, thank you. > FreeBSD's implementation is inherently slower, but the tradeoff is a "cleaner" > system. What do you mean by "Dynamic Shared Libraries"? Linux has shared > libraries, and symbols in the executable can override those in the shared > library. But is the linking done at runtime? No. It's done at compile-time. > And we save a lot of CPU and page-dirtying for it. >This is another area where I think comparing the two quickly becomes >an exercise in thin justifications for Linux's approach (and shouldn't >even be raised as a point of argument when Linux has so many other >clear strengths that it could raise in its favor!). Here you misinterpret my purpose. I'm not trying to justify Linux's approach or promote Linux at all. I'm merely stating the facts. Yes, I admit that Linux's approach is tougher for the developer. But it's like compilation swicthes: gcc takes a hell of a lot longer with -O2, but you run the damn thing much more than you compile it. Where should you pay? >Sure, Linux's >approach is faster, but it's a F**KING NIGHTMARE from the application >developers point of view! I've talked about this quite a bit with >Warner Losh from ParcPlace (the OI people) and he often goes into >convulsions at the mere mention of how much time and agony he had to >put in to get OI's shared libs to work with Linux. Warner wasn't bitten by the shared library approach by itself; he was also bitten by major changes in gcc name mangling and an ill-advised reorganization of the Linux shared libraries without a corresponding major version change. I feel for him, but nobody's had as hard a time as Warner has. >By comparison, >building a shared lib under *BSD is generally no harder than it is on >a Sun (which is to say quite easy). Sometimes the advantages of a >`cleaner' implementation over the long run far outweigh some of the >more minimal run-time overhead issues (which can be made up in other >ways as you have time to add optimization), and I think that Linux's >approach will come to haunt its proponents more and more as the >popularity of it increases, eventually resulting in their being almost >_forced_ to go down the same road! I'm no proponent; I can't wait for Linux to use ELF-style executables and shared libraries. We can already *use* them, in fact, we just can't generate them because of deficiencies in the binutils. My kernel can load a version of gzip compiled on SVR4 and link it against a version of the Linux shared library compiled to be a Solaris-style (ELF) shared library. And then it can run it :-) But if you want to air dirty laundry, pull it all out. There's a greater cost for purity of shared library implementations than just longer load times and page dirtying. If you don't assign shared libraries fixed addresses, you must compile the libs with position independent code. On the i386, this has a much greater cost than on RISC processors with more registers to spare. Eric Youngdale long ago measured a 10-15% slowdown for library code (don't hold him to these numbers; he'd probably kill me for quoting him). I don't know if the Kranenberg/FreeBSD shlib implementation uses fixed addresses; I doubt it does. Has anyone benchmarked statically linked vs. dynamically linked executables on speed of *library* code? I'll bet it's not insignificant. Again, I know Linux's implementation isn't perfect, but there are good reasons to have it. Linux developers aren't idiots. >I think no more need be said here as history will inevitably prove me >right. Like I said, Linux has some great features and I'm always >ready to give it its proper due, but its shared library implementation >is not one of those features. I'm using them every day as a user with no problems. Now, as a developer, they're causing problems because there's no clean interface for dynamic loading of .o files prelinked against shared libraries into a running application. But I think that if you surveyed Linux users, an overwhelming majority wouldn't even be aware of any fault in the shared library mechanism. It works (unlike, from what I hear, SCO's). >You definately can't please everyone, with 2/3 of the >people screaming for *smaller* releases and another third yelling for >more "base programs", and the bottom line is that I think we did it >right by decoupling a lot of this stuff from the system. [...] >Did you try actually >adding any of the packages? I find it hard to see how anything could >be simpler.. Yes, it was simple. It was a minor nit to pick, but there it was. I'm not a very less-is-more person, and I didn't like the smallness of FreeBSD. All a matter of taste, and all easily remedied. I shouldn't have mentioned it. > >How odd, that Sun OS NFS seems to work with FreeBSD... > In which direction? And, if you wish to exchange childish snotty remarks, > how odd that SunOS's NFS worked with Linux (Linux->SunOS and SunOS->Linux). >I think he was referring to the fact that some Linux user had said >that Linux worked fine with all his other workstation hardware and >that FreeBSD didn't. You may be misquoting me; I said that Linux worked fine with all my other workstation hardware, but FreeBSD didn't work well with Linux. Big difference. And I was very careful not to lay blame; it's just something I mentioned because it was one of the reasons my roommate re- installed Linux over FreeBSD. >Sure, we could pick defaults that make it interoperate in a guaranteed >fashion for each and every FreeBSD box, but we'd end up severely >penalizing folks with faster 16 bit ethernet cards and speedy PC's >(with which most NFS servers are actually configured). Both our machines are 486dx33s with SMC Elite 16 cards. Not top-of-the- line, but plenty fast for NFS service. I imagine the NFS problem was some small vague corner of the NFS spec, but I didn't have the time to trace it. To sum it up: I wasn't contributing to the Linux-vs-FreeBSD thread itself, but merely trying to comment on the apparent speed difference. -- _g, '96 --->>>>>>>>>> gt8134b@prism.gatech.edu <<<<<<<<<--- CompSci ,g_ W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W W@@@@**~~~' ro|-<ert s/_\ nders | who am I??? ^ from Superman '~~~**@@@@W `*MV' hi,ocie! |-/ad! / \ss!! | ooga ooga!! | II (cool)! `VW*'