NetBSD 1.6 Released

BSD Forums writes "The NetBSD Project is pleased to announce that release 1.6 of the NetBSD operating system is now available. NetBSD is widely known as the most portable operating system in the world. It currently supports fifty two different system architectures, all from a single source tree, and is always being ported to more. The NetBSD 1.6 release contains complete binary releases for thirty nine different system architectures. The thirteen remaining are not fully supported at this time and are thus not part of the binary distribution." hubertf adds some important notes: "Many of the FTP Mirrors are now carrying the NetBSD 1.6 distribution. Please try to use the NetBSD FTP Mirror Site closest to you. ... Czech, German, French, Japanese, Polish, Portugese , Russian, Spanish and Swedish language translations of the NetBSD 1.6 release announcement are available." The NetBSD packages collection now includes over 3000 pieces of software, including KDE3, OpenOffice and many more of the usual suspects.

Comments

lost in the noise

[g4dget]

The *BSD kernels may be a little more reliable and simple, and the Linux kernel may support more drivers, but it seems to me the differences are pretty much lost in the noise.

I think Jobs had the right idea when he picked Mach as the basis for NeXTStep: he wanted a kernel that looked like UNIX from the outside but that was much more componentized than the UNIX kernels of the time, or BSD/Linux today. I don't know whether Mach/Darwin is the best choice for that, but in general, I think it's where open source needs to go.

After all, we don't recompile Bash or dynamically load libraries into Bash every time someone comes out with a new command line program. We shouldn't have to do that either for a new file system type, networking protocol, or driver. And expending much time on a BSD/Linux rivalry isn't going to address such issues.

Re:lost in the noise

[g4dget]

No, but you could, if you needed it to be a shell builtin for performance or other reasons.

Indeed. When I do need the performance, it would be nice to be able to load modules dynamically. But for something like IPsec, PPP, UFS, ISO9660, CMOS, etc., I don't need the performance; maybe you do on your big server, but I don't, on my little laptop. As for "other reasons", there shouldn't be any reason other than performance to load something dynamically.

You still have to write and compile something - why not a kernel module?

Because, empirically, kernel modules seem to end up being very dependent on kernel versions; if they weren't, distributions like Debian wouldn't ship with different collections of most kernel modules for each kernel, they would ship with one kernel module per package for each function/driver, without much of a notion of a "kernel version".

Another reason is that one bug in one kernel modules brings down the whole thing. That's unnecessary and makes driver development a huge pain.

Not that OS X is actually a microkernel OS!

I made no claims about what it is or even whether it is a good architecture. What I claimed was that Jobs correctly identified a problem and tried to address it as best as possible with the software available at the time.

And I think he actually succeeded much more than Linux did in this particular regard: kernel extensions on OS X work much better than on Linux.

(Jobs also correctly identified the problem with C/C++ GUI toolkits and his solution, Objective-C with DisplayPostscript, probably also was the best technical compromise at the time, but I think that choice hasn't turned out as well as his choice for kernel--OpenStep and Cocoa ended up with most of the same problems as other GUI toolkits.)