Slashdot Mirror


Byte: FreeBSD vs Linux Revisited

Beerwolff writes: "This time I have remembered the link to the Byte article that's a follow-up to two of Moshe Bar's previous articles comparing FreeBSD and Linux--This time with the new Linux VM. His Apache "results show that Linux is better at handling I/O cache than FreeBSD, and that FreeBSD is more efficient at building up and tearing down processes."" As usual, please take benchmarks with a grain of salt, caveat emptor, look before you leap, and so forth.

13 of 401 comments (clear)

  1. The best thing... by stox · · Score: 3, Insightful

    that ever happend to FreeBSD, was Linux. The best thing that ever happened to Linux, was FreeBSD. Instead of fighting in the mud with those other guys, both can compete on the higher ground of techinical merit. As long as both keep leap frogging each other, we are all better off.

    --
    "To those who are overly cautious, everything is impossible. "
  2. FreeBSD and Linux will always complement ... by SuperDuG · · Score: 4, Insightful
    FreeBSD and Linux are always going to complement each other completely. Even though they are based behind two different kernels they are both free as in beer.

    Personally I would use FreeBSD for a server for the sheer fact that I can never crash it. For desktop uses I would definantelly use linux.

    But both of them being free in the same world will always complement each other. The only thing holding FreeBSD back from the desktop is a pretty installer ... though this _might_ count as a desktop varient of FreeBSD ...

    The latest releases of mandrake and redhat are full of wonderful packages and resources that make linux more than a prime candidate for the desktop.

    But Linux and FreeBSD will ALWAYS complement each other ...

    SuperDuG

    --
    Ignore the "p2p is theft" trolls, they're just uninformed
  3. Workstation use? by CtrlPhreak · · Score: 3, Insightful

    As well as I like to see benchmarks, apache benchmarks none the less (seems kinda like the infamous Photoshop benchmarks for the average user), I'd like to see a comparison between *BSD and Linux on a desktop workstation. I've been happy using slackware for a while and would like to know the difference on a usability standpoint.

    There are questions that are never answered for the average (above average for using some other platform than windows) user because of all the flame wars. How is compatability with software made for linux? Gaming support? Driver support? How do installs go? How much of a difference is there for setting up/configuring devices and other system preferences? These are things that I am interested as a perspective user and I am not that interested for this case about the differences between the BSD license and other free licenses which are important for some people. Is there a reason for me as a home non server user to switch to *BSD?

    --
    WikiAfterDark.com It's a sex wiki, go now!
  4. here we go again by necrognome · · Score: 3, Insightful

    now, before we start, everyone remember that *BSD IS NOT DYING!

    carry on.

    --


    Let's get drunk and delete production data!
  5. Stupid Media Trash by ksw2 · · Score: 4, Insightful
    Media loves a good "(X) VERSUS (Y)!" fight. I say fuck them. It's going to depend on the application. Linux users don't use their OS's in the same way the BSD users use theirs.

    Tell one person using OpenBSD that they should use Linux instead because the I/O cache is faster, and they'll tell you to GFY. Likewise if you tell a desktop Redhat 7.2 user that FreeBSD is going to suit him better because of process creation statistics.

    It's just another stupid OS jihad that doesn't matter. People should take a lesson from Linus when people ask him what he thinks of the "competition".

  6. Try Slackware 8 by aussersterne · · Score: 2, Insightful

    Slackware has always had BSD-like cleanliness and simplicity. No shit to dig through in scripts and packages and etc. etc. etc., just a nice, efficient Unix-like feel. I started using Linux with Slackware and for years saw Linux as just another Unix, albeit a newer, flashier one. The first time I tried Red Hat (at 5.0) I was totally startled to find that most people were seeing Linux as a whole other operating system...

    And with Slackware, you'll get the extra drivers and hardware up-to-dateness that Linux offers -- the one place where *BSD really suffers, especially for desktop or small server applications. That's my FreeBSD horror story... trying to install it on modern (Athlon+AGP graphics) hardware and on my Thinkpad.

    --
    STOP . AMERICA . NOW
  7. Re:I made the switch by npietraniec · · Score: 3, Insightful

    ...who *ahem* just want to have their TV tuner working out of the box.

    Read:

    Those who want their operating system to work as it should when they install it.

    Yes, there are arguments against running Mandrake (stability maybe) But not using it because it works doesn't make sense.

    "Yea, I tried Mandrake, but it worked too good... I switched to [insert distro here] so that I could spend hours trying to get every piece of my hardware working correctly."

  8. Re:Linux Vs BSD by bogie · · Score: 2, Insightful

    I think your forgetting OS X which is BSD based. Like Apple says they will soon have the largest installed base for unix desktops.If OS X ran on X86 linux would probably fall off the face of the earth as far as nix destkops go.

    --
    If you wanna get rich, you know that payback is a bitch
  9. Agreed, its down to installers and tools. by Ars-Fartsica · · Score: 3, Insightful
    I can't get over all of these posts in here like "I'm running a {webserver/database/mail server} and I wonder which one is best?"

    For 99% of the people here, the low-capacity applications they are discussing are going to operate identically on both platforms. Unless you are running AOL, Yhaoo, or Hotmail, you are not a corner case. Use whatever you like, it is not going to make one lick of difference in performance or stability.

  10. Not a VM benchmark by velco · · Score: 5, Insightful

    Note that this is systems benchmark, not a VM one.
    There are a lot more different things in the two
    kernels, than the VM. And note, that the server was
    SMP, an area where FreeBSD folks admit "Linux is a
    year ahead". It may turn out in the end that
    actually the FreeBSD VM performs better, making
    able the Big Lock BSD kernel catch up with more
    fine graned Linux .
    -velco
    Lies, damned lies, statistics

  11. Re:Q: softupdates vs. ext3 by warlock · · Score: 4, Insightful

    Your argument makes no more sense than the following:

    If journalling is so good, why has BSD not used the same approach?

  12. Re:Q: softupdates vs. ext3 by ByTor-2112 · · Score: 3, Insightful

    I believe that benchmarks have shown softupdates to have just as much speed as a journalling FS. 5.0 currently has background fsck'ing, meaning that except for the root partition all the filesystems are checked AFTER the system is completely up. So softupdates+background FSCK gives you everything a journaling fs does, without the risk of a corrupt journal, is probably faster than journaling, and doesn't require a new untested FS (or new, untested extensions to an FS).

  13. Combine the best bits of both? by rice_burners_suck · · Score: 3, Insightful

    FreeBSD rocks!! (But Linux doesn't suck. I use both. In fact, I say use whatever is best for the job, as long as it isn't Windows, because Windows sucks. (Bear with me for a moment--this is not flamebait, just part of the overall presentation of my comment.) Yeah, Windows might be useful at serving a purpose sometimes, as long as whatever it is doesn't need to actually function properly most of the time. But then, I was talking about FreeBSD and Linux, not Windows. Because Windows sucks.)

    Building up and tearing down processes is indeed one of the strong points of FreeBSD. I vaguely recall reading about that somewhere in the documentation on the website or the CD or somewhere. I also recall reading about how some older version of FreeBSD had an obscure timing-based vulnerability in some section of the forking code because keeping it fast requires it to be complicated. (Actually, it's not that complicated. It's just in deciding which parts of the process are copied to the new process and which ones aren't. Under very specific circumstances, something that wasn't supposed to be copied was, or the other way around. I just don't remember. That's what happens when you try to comment on something you read a year (or more) ago. Of course, this vulnerability has long since been fixed. The point is, I don't claim that FreeBSD is perfect while Linux isn't--they both have their strong and weak points and like I said, use whichever one is best for whatever you're trying to accomplish. And above all, like any machine, a system running any kind of operating system needs to be well maintained, and that is a big part of security. While there may be bugs in whatever parts of whatever operating system, proper maintainence will nearly always ensure that the system is kept running and is not compromised. (Unless you're running Windows, which, like I said before, sucks, so even if you maintain it properly, I am required by blood oath to tell you that it will be compromised anyway, just to make Windows look bad, even if it isn't all that bad for home use by computer newbies who just want to check out some website or whatever.))

    In the Linux compatibility section of the FreeBSD manual, the author claims that FreeBSD executes some parts of Linux programs faster than Linux. (I'm sure it executes other parts more slowly. This is what happens when you run programs designed for other software--you can use some of your features (or just circumstances) to your advantage while other things just don't work out quite as fast as you'd like.) It would be interesting to analyse FreeBSD and Linux, figure out which parts are best in both in terms of efficiency at running, say, desktop software, and modify both systems for better efficiency. Oh well. I got too much work to do. Maybe tomorrow.