2025-11-21 - BSD Versus Linux ============================= In 1999 i set up my first Linux server in a professional context. I used existing hardware and Debian 2.1 (Slink). It worked great except for a kernel OOPS that happened several times per month, requiring a reboot. I couldn't understand the garbledygook in the kernel messages, so i asked for help, probably on a Debian mailing list. Nobody replied. I tried NetBSD (1.4?) on the same hardware, and it was rock solid. The NetBSD bug tracking system and mailing lists were a much friendlier place for me, as a Unix newbie, compared to Debian. So i went with that. A year or so later, my supervisor figured out the root cause of the Debian server instability. Linux was enabling Ultra DMA 3 for faster disk access, which requires an 80-conductor ribbon cable. The server only had a 40-conductor ribbon cable. This resulted in cross-talk and data corruption, causing random, sporadic crashes. The solution was to replace it with an 80-conductor ribbon cable. UDMA I am no longer a newbie and i still don't understand why NetBSD worked better. Reviewing the source code, i see that NetBSD 1.4 supported Ultra DMA. It should have enabled whatever level of UDMA the disk claimed to support. wd(4) from NetBSD 1.4 For some reason NetBSD operated the disk at a lower speed, so it never crashed. The 40 conductor ribbon cable happened to be good enough. Perhaps NetBSD's cache flushing and filesystem defaults were simply more conservative and sane compared to Linux. It was a happy accident that it worked at all. In my experience this is true of much of technology. To pretend that the technology is pure or correct is a mistake. The important aspect is the social aspect, keeping in mind human creators and human users. Otherwise your dogma might get run over by your karma. This human centered approach is what made BSD superior to Linux in my book. I was willing to trade performance losses for better community, documentation, and organization. This is essentially the same point i made in another post: SystemD versus SYSV p.s. Today someone told me that i could have worked around this with the NODMA Linux kernel command line option. Debian 2.1 (Slink) used Linux kernel version 2.0. Debian Linux Kernel 2.0.33 Source Code (6 MB) Documentation/ide.txt says: > Bus-Master DMA support for Intel PCI Triton chipset IDE interfaces > for details, see comments at top of triton.c drivers/block/triton.c says: > The hdparm-2.4 (or later) utility can be used for manually > enabling/disabling DMA support, but must be (re-)compiled against > this kernel version or later. So if i had understood the garbledygook that the Linux kernel OOPS had printed on my console, i could have minimized my risk of crashes by editing my boot scripts and adding the following command to force Ultra DMA 2: hdparm -d1 -X18 /dev/hda Later, Linux got boot parameters to disable DMA: * Linux 2.4 -- ide=nodma * Linux 2.6 -- ide0=nodma * Later -- ide_core.nodma=0.0 * Even later -- libata.dma = 0 In contrast, NetBSD's option to disable DMA has remained the same: wd* at atabus? drive ? flags 0x0f00 Now if only i had a time machine to send this information to my befuddled self in 1999. tags: bencollver,retrocomputing,technical,unix Tags ==== bencollver retrocomputing technical unix