Author Topic: Linux versus BSD  (Read 8730 times)

0 Members and 3 Guests are viewing this topic.

Offline Sidoh

  • x86
  • Hero Member
  • *****
  • Posts: 17634
  • MHNATY ~~~~~
    • View Profile
    • sidoh
Re: Linux versus BSD
« Reply #15 on: August 04, 2006, 03:26:02 pm »
Earlier this week, I discovered my Slackware server was using ext2... >_>

Offline Newby

  • x86
  • Hero Member
  • *****
  • Posts: 10877
  • Thrash!
    • View Profile
Re: Linux versus BSD
« Reply #16 on: August 04, 2006, 03:57:30 pm »
Mine uses ext3 all around.
- Newby
http://www.x86labs.org

Quote
[17:32:45] * xar sets mode: -oooooooooo algorithm ban chris cipher newby stdio TehUser tnarongi|away vursed warz
[17:32:54] * xar sets mode: +o newby
[17:32:58] <xar> new rule
[17:33:02] <xar> me and newby rule all

I'd bet that you're currently bloated like a water ballon on a hot summer's day.

That analogy doesn't even make sense.  Why would a water balloon be especially bloated on a hot summer's day? For your sake, I hope there wasn't too much logic testing on your LSAT. 

Offline nslay

  • Hero Member
  • *****
  • Posts: 786
  • Giraffe meat, mmm
    • View Profile
Re: Linux versus BSD
« Reply #17 on: August 04, 2006, 08:48:54 pm »
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.
« Last Edit: August 04, 2006, 09:00:46 pm by nslay »
An adorable giant isopod!

Offline MyndFyre

  • Boticulator Extraordinaire
  • x86
  • Hero Member
  • *****
  • Posts: 4540
  • The wait is over.
    • View Profile
    • JinxBot :: the evolution in boticulation
Re: Linux versus BSD
« Reply #18 on: August 05, 2006, 05:11:58 am »
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.
I have a programming folder, and I have nothing of value there

Running with Code has a new home!

Our species really annoys me.

Offline nslay

  • Hero Member
  • *****
  • Posts: 786
  • Giraffe meat, mmm
    • View Profile
Re: Linux versus BSD
« Reply #19 on: August 09, 2006, 07:38:13 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?

Quote from: Theo de Raadt
There'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.

An adorable giant isopod!

Offline Newby

  • x86
  • Hero Member
  • *****
  • Posts: 10877
  • Thrash!
    • View Profile
Re: Linux versus BSD
« Reply #20 on: August 09, 2006, 08:51:55 pm »
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. :/
- Newby
http://www.x86labs.org

Quote
[17:32:45] * xar sets mode: -oooooooooo algorithm ban chris cipher newby stdio TehUser tnarongi|away vursed warz
[17:32:54] * xar sets mode: +o newby
[17:32:58] <xar> new rule
[17:33:02] <xar> me and newby rule all

I'd bet that you're currently bloated like a water ballon on a hot summer's day.

That analogy doesn't even make sense.  Why would a water balloon be especially bloated on a hot summer's day? For your sake, I hope there wasn't too much logic testing on your LSAT.