Linux versus BSD

[Rule]

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 .

[Newby]

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.

[mynameistmp]

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.

[iago]

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. 

[Joe]

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".

[iago]

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). 

[MyndFyre]

I like Linux better because of compatibility.

From what I've heard from BSD advocates there's a jillion drivers for BSD.

[iago]

I like Linux better because of compatibility.

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. 

[chuck]

I prefere linux, but for low resources, BSD works better. Linux is just so darn *shiny* for some reason.

[Newby]

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.

[iago]

My Slackware installs typically boot in less than 15 seconds.  It really depends on what you install. 

[Ergot]

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.

[Rule]

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.

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.

[MyndFyre]

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.

- 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?

- 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.

[Newby]

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.