Slashdot Mirror
NetBSD Goodies: 2.0 RC1 Tagged, New pkgsrc Branch
jschauma writes "The NetBSD Releng Team has announced that the first Release Candidate for NetBSD 2.0 (ie NetBSD-2.0_RC1) has been tagged. This is a major milestone in the much anticipated release of NetBSD 2.0: from now on, any pullups must address some form of show-stopping issue to even be considered. The NetBSD Project encourages all users to test the binary snapshots that will soon be available on the release engineering ftp server. If no pullups are necessary, then the 2.0 release should
occur around the middle of October. Any fixes resulting in pullups will cause a second RC cycle to begin and add approximately 1-2 weeks more to the timeline."
Further, "The NetBSD Packages team announced that a new
pkgsrc-2004Q3 branch was created, and the freeze on committing to the pkgsrc trunk is now over. This branch, which includes a total of 4959
actively-maintained and supported packages, deprecates the last stable pkgsrc
branch (pkgsrc-2004Q2); all maintenance will take place on this new pkgsrc-2004Q3 branch. Please see our online documentation of the NetBSD Packages Collection for details."
From http://www.kernel.org/:
:-P), check, check, never heard of it.
1 .6.2.html:
"These days it also runs on (at least) the Compaq Alpha AXP, Sun SPARC and UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 and CRIS architectures."
Check, check, check, check, check, dunno, check, in progress, in progress, check, check, nope (who needs Itanium?
From http://www.netbsd.org/Releases/formal-1.6/NetBSD-
"The NetBSD operating system is a full-featured, open source, UNIX-like operating system descended from the Berkeley Networking Release 2 (Net/2), 4.4BSD-Lite, and 4.4BSD-Lite2. NetBSD runs on 52 different system architectures featuring 17 machine architectures across 11 distinct CPU families, and is being ported to more. The NetBSD 1.6.2 release contains complete binary releases for 40 different machine types."
There are certainly some that Linux supports that NetBSD doesn't, but not many. And as far as sheer number, NetBSD wins hands down.
Besides. At a certain point, you get past the serious marker, because you've exhausted all the common platforms. At that point, only one thing matters: Can I run *Nix on my Atari?
Pffth. The "system architectures" number that NetBSD likes to tout is not impressive. A system architecture typically needs a bit of specific bootup and maybe chipset specific setup code, perhaps a few constants changed, a system specific driver or two. Not to say that NetBSD supports more than Linux, but just that Linux probably has lost count and nobody cares anyway.
i a64p arc
s parc64
A CPU ISA, now that is the important metric...
Linux supports:
alpha
arm
arm26
cris
h8300
i386
m32r
m68k (with and without an mmu)
mips
parisc
ppc
ppc64
s390
sh
sh64
s
sparc64
v850
x86-64
NetBSD supports:
alpha
arm
arm26
i386
m68k (with standard and a sun mmu)
mips
ns32k
parisc
ppc
sh
sh64
sparc
vax
x86-64
So the places you can run NetBSD but not Linux are on an old m68k from Sun, some old "ns32k" thing, and the old old vax. I'm sorry, but these are "who cares" systems *far* more than even ia64.
The CPUs that you can run Linux on that NetBSD doesn't support are cris h8300 ia64 m32r ppc64 s390 v850. In other words, modern CPUs from embedded to "big iron" to G5 desktops.
So the actual things that matter are: Can I run *Nix on my G5? My 512 CPU IA64 supercomputer? My POWER5 server? Or my handful of modern embedded CPU architectures? I really don't give a rat's ass about my Atari (although no doubt you can run Linux on that as well).
I like how you list CPU architectures, not platforms. Like there is absolutely no difference between an old 68K amiga and the Sun 3/260 I have downstairs?
;-) ). We run RedHat at work on our servers, and besides the damn date problem (tell me again why exaclty uptime can't count over 250-some-odd days?), I've had more random crashes and poor VM behaviour on RedHat than I've ever had with NetBSD.
Adding support for a new CPU type in NetBSD is fairly easy... the code is clean and portable. I'm sure most of those processors could be easily supportable if there was sufficient desire, but personally, I don't even know what the "cris" processor is, and what machine runs the h8300 processor? Its more likely a matter of nobody having the hardware, or the time, to spend porting to a machine nobody has.
With all the garbage I've had installed with "out of the box" linux installs, randomly changing the whole VM system in the middle of a "release" OS, and the like, I far prefer the stability of a release version of NetBSD. If it wasn't for having to power off my NetBSD server here at home to replace a failed 120GB drive a few weeks back, I'd have almost 2 years of uptime (the UPS helps
2.0 has been a long time in coming, but I far prefer the NetBSD philosophy of "do it right, before you release it" rather than the seeming linux philosphy of "relese it, and we can always fix it later".
The problem for the other architectures compared to NetBSD concerning scheduler activations is the fact that NetBSD has a smaller and cleaner core.
This is the same reason NetBSD is so simple to port; as a *BSD programmer I can tell you that NetBSD code is so clean you can eat it.
I'm not using NetBSD, I only code for it, but with the release of 2.0 I will move away some of our production machines from FreeBSD. I love FreeBSD, it's what I use, but the code is no where near as clean.
I don't really want to mention Linux, because it's butt ugly dirty code in about 95% of the code you look at, it's an achivement that it works at all; it's a complete wonder that it works so well as it does, probably the huge amount of involuntary(unknowing) testers that does the trick.
NetBSD and DragonflyBSD is probably the perfect mix for the future, as far as I'm concerned. But I dubt that it will happen at the level I want it to.