Ahem, Hi Fans! Hi Paolo :)
On 2/5/07, Paolo Alexis Falcone <[EMAIL PROTECTED]> wrote:
2. Many are attracted to the simplicity of administration of BSD's more-robust networking stack and stateful packet filter with a more natural language syntax, while others like the bare-metal faster Linux networking stack with the modular, connection-oriented approach that Linux's packet filter gives without resorting to userland tools. 3. In this age where multi-core machines are already becoming the norm, SMP and threading in Linux is still superior compared to the BSD's. But the BSD's are not sleeping at the gates as they're catching up (with ULE and KSE). Then again, you've got better chances with Solaris, or the mxn threading capabilities of HPUX.
IMHO, simplicity is beauty. IMHO, NetBSD in the way it handles TCP/IP and the TCP/IP stack is far more mature and better than any of your Linux. NetBSD is the result of twenty five years of open source development. As a consequence, it has a highly mature code base. For example, its networking code ensures better performance and insurance against denial-of-service attacks than Linux's. Linux's TCP/IP suite, while well regarded, is simply less of a known quantity than NetBSD's, which is the reference implementation for Unix. As another example, NetBSD had integrated IPv6 long before Linux. Bugs have had longer to appear, and have been removed for a longer period of time. Although in many applications newer equals better, when dealing with OS code, the more mature a code base is, the more stable and predictable it is likely to be. If we are going to examine the development models of both operating systems, NetBSD and Linux are developed according to very different models. NetBSD is developed in a unified way, with the Core Team of the NetBSD Project overseeing additions and modifications to the NetBSD source tree. Adhering to the principle that FIRST IS NOT ALWAYS BEST, the NetBSD Core Team tightly controls access to the source tree, and frequently rejects early code contributions in order to wait for better ones. This gatekeeping role is particularly important because NetBSD maintains a unified source tree for all architectures – allowing simultaneous builds on each release -- ensuring high code quality and the most consistent possible environment across platforms. Linux is, by design, a more 'anarchic' development community. There is no single Linux distribution, but rather, as is well known, a multiplicity of distributions with different featuresets. While the market has coalesced around a select few distributions (RedHat, SuSE, SCO) and developers around a few additional ones (Slackware, Debian), code still diverges among the different distributions. Moreover, since there is no unified source tree for all architectures, Linux for the i386 may be very different from Linux for the x86-64. Each release is built, tested, and distributed separately However both communities, naturally, defend their development models. The NetBSD community points to several inferior modules being integrated into Linux (or certain distributions of Linux) simply because they were developed faster than superior pieces of code. For example, Linux had at least two completely independent USB stacks before Linus Torvalds rejected them both and wrote a third one from scratch, after he found both existent Linux stacks unsatisfactory. (When pressed for an explanation as to why he selected the API he did, Torvalds stated: "because I wanted to.") The NetBSD community also claims that the multiplicity of Linux distributions is both confusing and dangerous, because improvements to one distribution may or may not be present in other distributions. Linux developers counter that the multiplicity of distributions makes a wider variety of features available to users, and that there is no single standard of 'best' such as that which the guardians of the NetBSD source tree pretend to impose. Leaders of the Linux community have, further, been able to centralize development around a cadre of their own friends and associates, replicating to some degree the function of NetBSD Core. The Linux community is almost certainly correct when it comes to popular and widely-supported architectures. There is sufficient intellectual capital in the Linux community to support multiple Linux distributions for i386 and similar platforms, and the market is large enough to ensure code quality. Where Linux falters, however, is in more specialized platforms without such wide market support. For these platforms – whether produced by SuperH, or MIPS licensees, or other vendors – the lack of a single source tree across all architectures, and of unified development, can be critically fatal, because users may be forced to do much of the debugging and other development themselves (or pay consultants to do it for them). For embedded applications requiring or preferring unusual hardware configurations, NetBSD is likely preferable. Finally, the NetBSD development model can often yield better code quality. For example, NetBSD has full integration of kernel and user space code in the source tree. This ensures code changes are debugged in the context of the entire system. With Linux, kernel and user-space code are not tested together until integrated by the distributor. In addition, in NetBSD, regression test-suites are integrated in source tree, which helps isolate unexpected effects when introducing changes. With Linux, no single testing standard exists, so QA depends on the distributor.
4. Linux has a cornucopia of filesystems supported. Linux, like proprietary Unix variants, have supported journaling filesystems for a very long time.
IMHO Linux have yet to have a stable filesystem.
6. Linux supports more hardware peripherals and more hardware architectures than the BSD's (even more than NetBSD!), although it's not like how architectures are supported in the BSD's, where all comes from the same code tree.
*cough* NetBSD has had maximum portability as its chief design focus for the last seven years of its open source development. NetBSD's most distinctive feature is its wide platform support: as of the date of this writing, it runs on a technology-leading fifty one ++ different hardware architectures. NetBSD's fast portability is due to its unique Modular Portability Layer (MPL). With the MPL, the driver is completely isolated from the hardware platform, I/O instructions or no I/O instructions, interlocking, retry error recovery, bounce buffers, memory type boundaries, scatter/gather maps in host bridges, even peripherals which use pseudo-dma to write a buffer RAM with host CPU copyin and copyout all -- are transparently handled beneath the driver layer. Moreover, several embedded systems using NetBSD have required no additional software development other than toolchain and target rehost. With Linux, however, device driver code must be reworked for every new architecture. As a consequence, in recent porting efforts by NetBSD and Linux developers, NetBSD has taken as little as 10% of the time to port to new hardware. Engineers ported NetBSD to the SuperH processor core in under six weeks; Linux took three months. NetBSD was ported to the AMD x86-64 in about a month; Linux took six months. As a result, NetBSD supports fifty one supported architectures. Aside from that with the wide array of developers pushing in new code in their own style/methodology of writing, regression etc , chances are that there will always be HALF-baked / hacked / reverse engineered device drivers would work for some, and wouldnt work for others. I had experienced this with Linux firsthand, and it sadly broke some of my hardware, and Im not the only one who had these woes. Since then, I wouldnt put this risk on a production system. my two cents :) if you reached this far, it means you might think of "alternatives" ;) *grin* _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
