Slashdot Mirror
NetBSD Quarterly Status Report
An anonymous reader writes "NetBSD's Jan Schaumann announced today that, in order to provide a summary of the most
important changes over the last few months, the NetBSD Foundation has decided
to follow the example of other projects of releasing official status reports
on a regular basis. The first quarterly status report, covering the
activities within the NetBSD Project during the first three months of 2004 is
now available online."
The new port Xen virtual machine monitor for i386 sure looks interesting. The guest OS has to be ported to the Xen architecture, though.
When I first saw your post, I thought you where just another Slashdot troll, and did not reply. If it was not a troll, then I must say that your reasons and methology is superficial. I would not trust your jugdement based upon this, nor should your managers.
First, you don't counter ANY of the points raised; instead, you compare FreeBSD with Fedora. If you'd read the post properly, you'd see that the author also dismisses Fedora. He/she talks about Debian, so your point is completely moot.
No, actually I did read the post. Debian is easy to take care of (when all goes smoothly) but does not provide the support that the enterprise expects, which Fedora does.
Second, you say that a good FreeBSD admin will beat a bad Linux admin. Well, duh. A good Windows admin will beat a bad FreeBSD admin too.
Read it again, fuckwit. Talk about, "If you'd read the post properly"! I said, "I'll take FreeBSD with a good admin, over Fedora with a good admin, any day".
Amazing. The BSD zealots STILL can't refute the strenghts of Linux, instead opting to hand-wave their way out of the argument. Sheesh!
You need to improve your comprehension skills. I do not refute the strengths of Linux, in fact I have deployed more Debian Linux than BSD. My point is, that ANY Unix system that requires daily admin, also requires a good admin, since the "support" you get from ANY Unix is not enough to cover the weaknesses of a lesser admin. Where a good admin is on the job, a consistent platform shines. FreeBSD is consistent and Debian is too for that matter. I happen to prefer FreeBSD for systems that I use every day and Debian for systems which I only attend every now and then.
OK, so here are the points and my stance on them (it might shock you to know that I might not actually disagree with all of them):
Performance
Single CPU server: FreeBSD just edged ahead of Linux on this one.
A pretty generic statement. Hardly detailed.
Multi CPU server: With kernel 2.6, Linux performed considerably better than both FreeBSD 4.9 and 5.2.1. The updated SMP code and revised scheduler have worked wonders here, so 1 for Linux.
True. For now.
Desktop: Linux 2.6 is much faster than either FreeBSD, particularly when the system is heavily loaded. Application start times are slightly better, while responsiveness is remarkably superior to FreeBSD. Another 1 for Linux.
There have been times, when I've been compiling a BSD kernel in the background and completely forgot. I noticed no difference in responsiveness while the CPU is regularly near 100% occupancy and only slight delays with IDE disks when they are thrashing.
Stability
Linux distributions vary greatly in terms of stability, with Mandrake Linux and Fedora Core aiming for bleeding-edge desktop features, while Slackware and Debian put great emphasis on stability. FreeBSD is indeed a reliable OS, but the smaller development and testing community puts it behind Linux
FreeBSD behind Linux on stability? Garbage. They are both very close, assuming we're talking about the Linux kernel at it's best and not gcc optimized to hell by some distro that gives up stability for marginal performance gains.
I see FreeBSD as being slightly more stable than Linux, but this is only my subjective opinion.
additionally, there are more full-time Linux developers working with commercial companies on hardware support and core component testing.
Yes and I have done my fair share in the past. I've since moved over to the very clean BSD's and I'm no longer under NDA.
Commercial hardware companies fall into a few major categories. 1. Full documentation of hardware or driver source. 2. NDA documentation of hardware, resulting in binary only drivers or a mixture of some binary and source. 3. No support at all, reverse engineering required.
I don't really want to buy anything from 3 or 2. At least 2 can sometimes give the BSD developers a head start and some leads with some Linux code. With 1, BSD developers can either write their own driver from documentation or port from Linux driver source.
So, that point is moot.
Our Debian and Sla
I've been 'spoiled' by the clean well-focused tightness of NetBSD going way back to 1.3.2, when I first installed it, over NFS, on my Toshiba 486 laptop. The laptop has only a floppy drive and PCMCIA slots, so an ethernet install was the only reasonable way I could see. At that time, in the Linux 1.2 kernel era, PCMCIA support in Linux was a 'hang a bag on the side' set of kernel extensions that one had to fool with to get working. With NetBSD, PCMCIA ethernet support was integrated into the kernel core and 'just worked' in the single boot floppy needed for the install.
/etc/ directory is common to all architectures.
The 'minimal, clean' philosophy extends all the way through NetBSD. A basic install for most architectures is an 80-100 MB set of gzipped tarballs you can easily download. This gets you a working system, with all the basic functionality, a C compiler, X11 with the basic Tab Window Manager (TWM), networking, etc. The installer lets you 'pare' this down even further if, say, you don't need X11 or dev tools. When you want to extend your system beyond this base, you turn to the packages collection, which is really a massive build script, with 'configuration-wrapper' scripts and patches that are applied over the standard source tarballs from whomever the package actually comes from. You can also applie the packages as binaries using the pkg_add command and a large repository of prebuilt packages available from the NetBSD ftp sites.
Because the base system is small and fully integrated, you can also compile the whole base userland from a set of integrated gzipped tarballs (*.tgz files). It's as simple as unpacking the source tarballs and issuing a top-level make command. The whole kernel and base userland can also be upgraded with CVS live over the network and rebuilt.
Once you learn how to admin and run with NetBSD on one architecture, you know most of what you'll need to for running it on different architectures. All the ports of NetBSD, for Mac68k, MacPPC, i386, Sparc, Sparc64, VAX, MIPs, etc. built from the same core source files. The structure of the
And NetBSD has adopted a philosophy of doing things right, one time, and keeping things that way. Most of the info you need to set up and admin a NetBSD system you can learn from the classic UNIX books and documentation. The O'Reilly X Window System documentation (the big 8 book set) tells you almost anything you need to know, for instance.
There isn't a cadre of people out there trying to make NetBSD 'easy to use.' Thus, there aren't a bunch of people muddying things up and producing all kinds of croft and layers of GUI stuff to do basic tasks. There isn't a perceived goal of 'win over OS foo' which eggs the developers on to misdirected goals of competitiveness. The excellence of NetBSD stands on it's own and is based in what it is, not how it 'compares' to other OS projects and products.
Anyway, I think NetBSD is cool, it gives the users who are interested in 'getting under the hood' the opportunity to explore along well-followed paths of classic UNIX, and also lets the computer enthusiast run a Common OS on his whole collection of machines. I've run NetBSD on a Macintosh SE/30, a Quadra 650, on various PC compatibles going from a 386sx laptop to a Quad PentiumPro server, on all the classic Sun Sparc machines (IPC, IPX, LX, Classic, SS2, SS5, SS10, Ultra1), and on an RS/6000 box with the PowerPC chip.
resigned