I've often heard that, even when considering any Linux distribution, the only advantage to using Linux over BSD is a superior filesystem. While, on the other hand, for nearly anything else, BSD has the edge on Linux.
I feel I don't know enough about Linux, and especially not enough about BSD, to make a good comparison. If anyone can think of advantages and drawbacks to using Linux (choose your favourite distribution) over (Free)BSD, please post them here. Thanks :).
I like BSD's filesystem. UFS2 is really nice and I haven't had a problem with it.
I personally like how the BSD's are meant to be distributed as an OS, whereas Linux is just the kernel and the distributions of them are focued on programs and the like.
It depends on what you want. I use both Linux and FreeBSD and must say my experience in BSD has been a much more professional, clean feel, but Linux for me seems much more comfortable for some odd reason.
Elaborate on what you want to do.
Quote from: Newby on July 13, 2006, 11:08:55 PM
I personally like how the BSD's are meant to be distributed as an OS, whereas Linux is just the kernel and the distributions of them are focued on programs and the like.
That's my least favourite part about BSD. What's the point ? I find it just creates more confusion. tcpdump, ssh, BIND are all parts of the BSD base system. But they're not real copies of tcpdump, ssh, or BIND. They're actually BSD tcpdump, BSD ssh, and BSD BIND all of which were modified (by Makefiles, probably) to operate on BSD, whereas on Linux you're using the real tcpdump, real ssh, real BIND, etc as distributed by the vendor.
Also, to make matters worse, BSD base systems vary from distribution to distribution. OBSD and NBSD include X in their base system (because of console driver integration), whereas FBSD does _not_. That's just bloody confusing. What's BSD base system now ? KDE ? xterm ? Mozilla ? Any of them ? If one is, is it on both distributions ?? But none of them are base on FBSD...
Compare that with Linux... X, KDE, xterm, Mozilla, none of them are base system/need to be cross-compiled for your system. You could go on any Linux verison and know wether or not xterm is part of your base system (it's obviously not, as there is no Linux 'base system') and compile it right out of the box. That being said, having a 'base system' just doesn't seem to simplify matters at all.
Disclaimer: I'm speaking purely as a desktop OS. This does NOT apply to servers.
I like Linux better because of compatibility. I could not get video card drivers for BSD. I had issues getting wireless drivers for BSD. And I could never get my desktop to feel just right. Of course, if compatibility was the only key, I'd be using Windows.
I ran BSD on my laptop for a couple months. I got used to it, and it's pretty good, but I'm still more comfortable in Linux.
Realistically, if given a choice, I wouldn't care.
It seems Linux has a userbase several times as big, giving it a program base several times as big. Plus APT, but according to iago "APT is lazy". :)
Quote from: Joex86] link=topic=6662.msg81108#msg81108 date=1152887680]
It seems Linux has a userbase several times as big, giving it a program base several times as big. Plus APT, but according to iago "APT is lazy". :)
Linux doesn't have APT, but some distros do.
BSD has something similar, Ports, but Ports are all built from source (similar to Gentoo).
Quote from: iago on July 14, 2006, 08:13:06 AM
I like Linux better because of compatibility.
:o
From what I've heard from BSD advocates there's a jillion drivers for BSD.
Quote from: MyndFyrex86] link=topic=6662.msg81134#msg81134 date=1152895968]
Quote from: iago on July 14, 2006, 08:13:06 AM
I like Linux better because of compatibility.
:o
From what I've heard from BSD advocates there's a jillion drivers for BSD.
This goes back to a problem we recently discussed -- they only have drivers for which the specs have been given or have been reverse engineered. In the cases where the specs are unavailable (like many video cards), you don't get support. Same as Linux, but at least companies like ATI release drivers for Linux.
I prefere linux, but for low resources, BSD works better. Linux is just so darn *shiny* for some reason.
Lately, I've been toying around with LFS and building my own base system, and I must say I've learned a lot in what goes into a base system. I also feel more comfortable compiling a kernel and feel I have more control over what goes into my system.
It also takes ~10-15 seconds to boot once grub boots the kernel. Whereas on any Slackware/ FreeBSD installations I've done, it'll take easily longer than Windows to get to a login prompt.
Sure, a Slackware installation takes ~30 minutes compared to an LFS installation which took me 8 hours to get the base system up and running (800 mhz, 256mb ram laptop, testing and compiling/recompiling/recompiling binutils/glibc/gcc easily took half of that 8 hours by itself) but it feels so much cleaner in the end.
Honestly, BSD seems to be more centralized to their webpage/ports/etc, whereas Linux your distribution is either centralized to the vendor or you're on your own. That's the one thing I like about Linux: freedom of choice. Don't like the current vendors? Build your own system. Odds are you'll find a distribution of Linux that suits you, but if you don't, it's not hard to build your own.
Sure, you could do that with a BSD, but in the end your system will be modeled off one of the BSD's, since the central systems are unique (read what tmp said) and not the same.
My Slackware installs typically boot in less than 15 seconds. It really depends on what you install.
Quote from: iago on July 15, 2006, 06:09:35 PM
My Slackware installs typically boot in less than 15 seconds. It really depends on what you install.
And what you decide you want to start up... hotplug takes the longest on mine.
Quote from: Newby on July 13, 2006, 11:08:55 PM
I like BSD's filesystem. UFS2 is really nice and I haven't had a problem with it.
Old, but still revelant so long as BSD uses UFS.
Quote from: nslay
Some points against UFS:
- Using write caching with softupdates can be dangerous. This may have made sense two decades ago, but now with 40MB+ caches, the harddrive tends to write things out of order.
- On BSD, write caching can be turned off by adding hw.ata.wc=0 to /boot/loader.conf, but this seems to greatly reduce performance.
- Even with write caching off, the FS is not as reliable because there is no meta data journal. Since UFS relies on meta data order writes (for consistency), upon crashing the system must do fsck (instead of unwinding meta data transactions in the journal). With a large HD size, fsck takes quite awhile to complete.
Quote from: Rule on August 04, 2006, 12:33:49 PM
Quote from: nslay
Some points against UFS:
- Softupdates use write caching which may have made sense two decades ago, but now with 40MB+ caches, the harddrive tends to write things out of order.
I've never seen a consumer hard drive with a 40mb+ cache. The largest I've ever seen on any hard drive I've considered buying is 16mb. So, unless you're talking about a sizeable investment, this is fairly irrelevant.
Quote from: Rule on August 04, 2006, 12:33:49 PMQuote
- On BSD, write caching can be turned off by adding hw.ata.wc=0 to /boot/loader.conf, but this seems to greatly reduce performance.
Right, write caching is generally a good thing. If you're not using that 40mb+ cache hard drive, though, is it really so important?
Quote from: Rule on August 04, 2006, 12:33:49 PM
Quote
- Even with write caching off, the FS is not as reliable because there is no meta data journal. Since UFS relies on meta data order writes (for consistency), upon crashing the system must do fsck (instead of unwinding meta data transactions in the journal). With a large HD size, fsck takes quite awhile to complete.
That *is* the nice thing about journaling file systems, isn't it? :) That's probably the only thing valid to a typical home or small business user from your list. It's like running Autochk on a FAT drive vs. an NTFS drive. Validating an NTFS drive, unless you're doing the super-long-verify-indices process, is super-fast compared to FAT.
About the only thing I agree with on that list is a lack of journaling. I powered off my laptop hard once, and it fsck'd for over half an hour. Worst part was it did it in the background, so I killed it twice shutting down. Finally I ps'd and found out it was fscking my drive.
I don't have a 40mb cache. Hell, I'd be surprised if this thing had an 8mb cache.
Earlier this week, I discovered my Slackware server was using ext2... >_>
Mine uses ext3 all around.
Okay 40MB cache is an exaggeration, but thats besides the point. UFS (which is really FFS) relies on ordered meta data writes for consistency. This was very much the right way to do things ... uhh ... 20 years ago. Modern harddrives have write caches, the write cache usually reorders writes for efficiency. Well, for FFS, this is
dangerous, especially under heavy I/O. Upon a reboot from a crash, the system will invoke fsck to check the FS. The fsck utility makes assumptions that are no longer necessarily true. Remember, FFS and softupdates rely on ordered meta data writes for consistency, but with write caching on, the writes could have happened in any order. Another problem with FFS is that since it has no journal, the OS can't simply just "unwind" transactions to fix the FS, it has to run fsck ... this can take quite a
long while on large harddrives.
As further proof for the matter, the FreeBSD handbook
briefly mentions this:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html
Quote
11.12.1.5 hw.ata.wc
FreeBSD 4.3 flirted with turning off IDE write caching. This reduced write bandwidth to IDE disks but was considered necessary due to serious data consistency issues introduced by hard drive vendors. The problem is that IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives not only write data to disk out of order, but will sometimes delay writing some blocks indefinitely when under heavy disk loads. A crash or power failure may cause serious file system corruption. FreeBSD's default was changed to be safe. Unfortunately, the result was such a huge performance loss that we changed write caching back to on by default after the release. You should check the default on your system by observing the hw.ata.wc sysctl variable. If IDE write caching is turned off, you can turn it back on by setting the kernel variable back to 1. This must be done from the boot loader at boot time. Attempting to do it after the kernel boots will have no effect.
For more information, please see ata(4).
Please note that, while all harddrives behave this way. The BSD developers still blame the harddrive industry instead of fixing the problem. Thats another problem with the BSD community ... their attitude. I've seen messages and emails on mailing lists where users are arguing with developers on whether a problem is a "bug." I've seen developers call complaining users trolls for making comparisons to Linux about very real problems. BSD also has a bad attitude towards corporation, probably because of the legal battle with AT&T in the 80s and USL/Novell in the 90s. This is partly why they are not popular with business.
NetBSD has a Google Summer of Code project to add journaling to FFS. Although, like ext2, I think the file system ought to be designed from ground up for journaling. I also think that the FreeBSD foundation should purchase ReiserFS with BSDL and integrate it into the system ... or perhaps implement OpenSolaris's ZFS.
http://netbsd-soc.sourceforge.net/projects/jffs/
Please note, these are the sour points of BSD. There are plenty of good things about BSD systems so don't dismiss BSD based on the above.
Quote from: nslay on August 04, 2006, 08:48:54 PM
Please note that, while all harddrives behave this way. The BSD developers still blame the harddrive industry instead of fixing the problem. Thats another problem with the BSD community ... their attitude. I've seen messages and emails on mailing lists where users are arguing with developers on whether a problem is a "bug." I've seen developers call complaining users trolls for making comparisons to Linux about very real problems. BSD also has a bad attitude towards corporation, probably because of the legal battle with AT&T in the 80s and USL/Novell in the 90s. This is partly why they are not popular with business.
Wow..... Sounds familiar.... almost like... Linux vs. Windows.
Quote from: MyndFyrex86] link=topic=6662.msg85636#msg85636 date=1154769118]
Quote from: nslay on August 04, 2006, 08:48:54 PM
Please note that, while all harddrives behave this way. The BSD developers still blame the harddrive industry instead of fixing the problem. Thats another problem with the BSD community ... their attitude. I've seen messages and emails on mailing lists where users are arguing with developers on whether a problem is a "bug." I've seen developers call complaining users trolls for making comparisons to Linux about very real problems. BSD also has a bad attitude towards corporation, probably because of the legal battle with AT&T in the 80s and USL/Novell in the 90s. This is partly why they are not popular with business.
Wow..... Sounds familiar.... almost like... Linux vs. Windows.
To emphasize the point...
from Is Linux for Losers? (http://www.forbes.com/intelligentinfrastructure/2005/06/16/linux-bsd-unix-cz_dl_0616theo.html)
Quote from: Theo de RaadtThere's also a difference in motivation. "Linux people do what they do because they hate Microsoft. We do what we do because we love Unix," De Raadt says. The irony, however, is that while noisy Linux fanatics make a great deal out of their hatred for Microsoft, De Raadt says their beloved program is starting to look a lot like what Microsoft puts out. "They have the same rapid development cycle, which leads to crap," he says.
It's true. I downloaded 2.6.17.5 the day it came out, and literally by the end of the day 2.6.17.6 came out. Both were the stable releases on www.kernel.org. :/
The 2.4 series is NOT as rapidly developed as the 2.6 series, and not as bloated with crap features and options, which is why I currently use it. I don't feel like switching to 2.6 any time soon. It's changing drastically in the 2.6 series, 2.6.12 to 2.6.15 was an absolute ton of differences for such minor version # changes. :/