Posted
by
Soulskill
on Wednesday October 17, 2012 @04:09PM
from the onward-and-upward dept.

New submitter Madwand sends this quote from the NetBSD Project's announcement that NetBSD 6.0 has been released:
"Changes from the previous release include scalability improvements on multi-core systems, many new and updated device drivers, Xen and MIPS port improvements, and brand new features such as a new packet filter. Some NetBSD 6.0 highlights are: support for thread-local storage (TLS), Logical Volume Manager (LVM) functionality, rewritten disk quota subsystem, new subsystems to handle flash devices and NAND controllers, an experimental CHFS file system designed for flash devices, support for Multiprotocol Label Switching (MPLS) protocol, and more. This release also introduces NPF — a new packet filter, designed with multi-core systems in mind, which can do TCP/IP traffic filtering, stateful inspection, and network address translation (NAT)."

you might well be a NetBSD user and not know it. might be in your printer, network router or switch, internet security or web cam, cell phone.....it's an extremely stable, well engineered and high quality operating system

Because you don't need to enable every feature that an OS has?
If you want to play around with something experimental, temporarily load it as a module, or use Rump or Puffs to isolate the filesystem code to a userland process and hack away.

STABLE is just the branch release. It means if you track the STABLE tree, you'll only get bugfixes. If you track CURRENT, you get stuff that'll go into the next version of NetBSD, but stuff will change on you (requiring you to update scripts and such). See the release map [netbsd.org] for a better explaination.

It has nothing to do with the stability of the OS itself. I can't comment on that, since I haven't used it much, but from what I hear it's pretty good.

I have only used stable, but (On Sparc64) I get 2 year up times (after which machines tend to get rebuilt). Only down time has been due to hardware issues (and a HD filling up to 110%) I have been using it since version 2.8 - and intermittently before that on Sparc and PC architecture. (Headless - historically, graphics dirvers were very limited)

This is a common way of getting advanced features out in 'beta' without slowing down a whole release -it allows users to experiment with the feature without expecting full support or without having to manually installthe new feature itself - if you don't want to risk stability, don't use it.

Similary - there are at least 2x similar 'experimental' technologies in RHEL6, which is used by many thousands of companieson mission critical systems:

NetBSD is used by Apple for a large portion of the user-space commands and tools in their Darwin project, and Darwin is the UNIX-based core used by Mac OS X. NetBSD source tends to pay attention to issues of portability and correctness, and is virtually all BSD licenced, which avoids commercial problems with the GNU General Public Licence. At least one of the Apple developers has access to the NetBSD source tree and has fed back some useful changes

Apple has utilities from both NetBSD and OpenBSD. But remember that Apple hired the primary developer from FreeBSD, and there's lots of FreeBSD code in OS X. One obvious example is the property lists API, which is a really odd feature from FreeBSD. (Sort of like importing some random dude's init parsing code as-if it were somehow unique or even useful as an operating system interface.)

Also, there's a BSD kernel in OS X, which is a process managed by Mach. Not sure if it was ripped from FreeBSD or NetBSD.

Darwin has code from FreeBSD, NetBSD, and OpenBSD, as well as code from Apple both in kernel space and userland (including the system library - the memory allocator [apple.com], for example, isn't from any *BSD).

...and there's lots of FreeBSD code in OS X. One obvious example is the property lists API, which is a really odd feature from FreeBSD

No, it's from NeXTStEP, not FreeBSD.

Also, there's a BSD kernel in OS X, which is a process managed by Mach.

Mach manages tasks and threads; UN*X processes are built atop Mach tasks, and pthreads are built atop Mach threads. The "BSD kernel" part of XNU (under the bsd subdirectory) is what implements the "UN*X processes" stuff (among other things, such as the file system and networking mechanisms), and that code runs in both the "kernel task" (the UN*X process for which is pid 0) and in other tasks; it doesn't run in "a" process/task in the sense of "it runs in a single process/task".

Not sure if it was ripped from FreeBSD or NetBSD.

The from-BSD parts of the "BSD kernel" are mostly taken from FreeBSD, but have changed significantly, and the "BSD kernel" has a fair bit of Apple code in it, as well as, for example, Sun (Open Solaris) code (as in "DTrace").

I think Android uses NetBSD-derived userland stuff also? I've had the impression that they wanted BSD stuff for licensing reasons but I wonder if there's something specific to NetBSD that makes everybody particularly like their userland utilities!

The Darwin kernel (which is called XNU) is a bit weird - I spent some time looking into it when it was still a relatively new thing (2003-4 kind of era). XNU is Mach + FreeBSD + DeviceKit/Apple-y bits, all sharing the same protection domain. The latter point is interesting, since despite the fact Mach is considered a microkernel they've actually shoved all of the other kernel-level services in with it, rather than separating them into different processes. This makes the whole kernel basically monolithic (i.e. like the modern Windows and Linux kernels), which is kind of unexpected!

The Apple-y bits in the kernel that I mentioned definitely includes DeviceKit, their driver interface. Maybe some other stuff as well. The drivers are not normal FreeBSD-like device drivers - I think they're even C++, unlike FreeBSD itself.

I found it all a bit unexpected really, things didn't fit together as I'd imagined.

The latter point is interesting, since despite the fact Mach is considered a microkernel they've actually shoved all of the other kernel-level services in with it, rather than separating them into different processes. This makes the whole kernel basically monolithic (i.e. like the modern Windows and Linux kernels), which is kind of unexpected!

I.e., it's as much a "microkernel" as Windows NT is.:-)

The Apple-y bits in the kernel that I mentioned definitely includes DeviceKit, their driver interface. Maybe some other stuff as well. The drivers are not normal FreeBSD-like device drivers - I think they're even C++, unlike FreeBSD itself.

Yes, DeviceKit drivers are written in (a subset of) C++. Drivers that just plug into the standard UN*Xy cdevsw are likely to be just Boring Old C.

The VFS (file system) and network protocol layers should look somewhat familiar to people used to the *BSDs. Other than sitting atop Mach tasks, the process layer should also look familiar to them.

This makes the whole kernel basically monolithic (i.e. like the modern Windows and Linux kernels), which is kind of unexpected!

Well, we knew that was the case before OSX even shipped, but OK. It's not a microkernel-based operating system because the microkernel isn't doing process management, or much of anything at all. It's just playing HAL.

This makes the whole kernel basically monolithic (i.e. like the modern Windows and Linux kernels), which is kind of unexpected!

It's not unexpected for anyone who has been paying even remotely attention to operating system development. Let me quote Linus from a G+ post on Greg Kroah-Hartmans feed:

yes, it's based on Mach, but it's based on the older Mach 2 architecture which really wasn't a microkernel. It's parts of FreeBSD bolted on top of a research kernel that was meant to become a microkernel, but never really did.

And the result really is nasty. Page fault and VM latencies are horrible (why do I know? We hit huge performance problems while doing the MacOS port of git), the filesystem choices they've done show a level of incompetence that is stunning, yadda yadda.

But hey, it's pretty on top. If the Apple engineers actually knew what they were doing, they could use a known superior open-source kernel and put their pretty on top of that instead. Then they wouldn't have to do kernel programming, and could leave it to the people who actually like doing it and know what they are doing.

Of course, at least Apple can come up with a stable ABI and driver model. Linus is too interested in playing around with little fiddly bits to worry about important stuff, like making sure software written a few months ago still works.

NetBSD is the "runs on any/everything" variant. It's absurdly portable. If you've heard stories / jokes about "BSD on a toaster", it was probably NetBSD.

It's not necessarily a great desktop system; "runs on everything" doesn't mean all internal or peripheral software support is going to be great (desktop-oriented BSD distros are usually FreeBSD based). However, it's a great choice if you have a very old or obscure computer that you want to run it on. I know a guy who runs NetBSD on one of the later-model VAXes.

NetBSD used to be known as an easily portable UNIX like operating system. Quite often whenever you heard of a new hardware architecture it was usually the first operating system ported to it. For example when X86-64 came out it was the first. AFAIK their device drivers are written in a way to be easier to port across machine architectures so that eases porting efforts. I heard the FreeBSD folks were integrating something similar to the NetBSD driver model but that is about it.

Oh, I know that OpenBSD forked from NetBSD, but it has far outgrown it. NetBSD's only selling point was being most ported - at least amongst the BSDs, but even there, FreeBSD has a version for ia64, but NetBSD doesn't. Which is why I was wondering.

Currently, amongst the OSs still active for Itanium, aside from HP/UX, on the Linux side, only Debian remains, and on the BSD side, only FreeBSD. Any inputs on which of these is a better choice for this platform?

I was thinking just amongst the BSDs - FBSD is available on ia64, whereas NBSD is not. Also, honestly, had never heard of blackfin, cris, frv, h8300, hexagon, m32r, m64k, microblaze, mn10300, score, tile, unicore and xtensa. And as for the present, Alpha & PARISC are dead architectures - anybody having an Alpha might as well sell them to anybody still running OVMS.

Apparently, I'll never understand Slashdot. The latest junk from Facebook, Microsoft, Amazon, Apple, Oracle, et al. make the front page, but one of the highest quality open source releases gets buried. (It's almost like people self-medicate their marketing these days, but separate issue.)

I got 6 years of uptime once off of NetBSD on sparc. This stuff is gold. It's platinum. It's so stable, you have to worry about making sure you get around to patching your apps because the OS just never dies... stick this on solid state storage with the new NAND support, and you don't even have to worry about spinning disk fails. As a network device OS, this will be an awesome high-uptime packet sensor or embedded packet router.

Indeed. NetBSD is exceedingly stable and more people need to take advantage of it. I'm very surprised Google didn't choose to use *BSD instead of Linux, because as servers go, nothing beats BSD. I once administered several BSD server and never once had a failure. Ever. Once they are up and running and configured correctly, they are there to stay short of hardware failure.

NetBSD makes a great embedded OS and I'm surprised there are not smartphones running BSD. Maybe soon...

It's far easier to get random drivers and niche optimizations into Linux mainline. That's why BSDs tend to be more stable---less code churn. (Other times, it means persistent problems that go unaddressed for years.) Code churn means more bugs. It's inevitable. And it's why it's so easy to root a Linux machine, even though on-the-whole the code quality is really good. Also, Google started using Linux 15 years ago, before NetBSD was actually tolerable.

> Evidence? This is Slashdot. OTOH, code churn is quantifiable, and I'd put money down to show that Linux changes faster, especially wrt to drivers, but I'm not about to waste my time doing that. People can take my assertion for what it's worth.

One man's "code churn" is another man's development. If you improve code, it churns. BSDs certainly don't have any claim to be perfect and not requiring any improvement. They are behind Linux in almost any objective metric you can come up with, which is why they r

Linux used to be like the BSDs. I forgot his name, but in the 1990s there was like one dude who wrote most of the ethernet NIC drivers. If you bought a card you made sure to buy one compatible with his drivers, because all the others were crap.

how exactly do you access a kernel from the network without going via an application?

Hrm, I'd guess you're probably twenty-five or younger, given that question. You missed some good times.

Back in the day the TCP/IP stacks had quite a few bugs in them. Just about everyone lifted code from BSD 4.x (yeah, the original BSD). Once exploits for those started coming out, it was a race to see who could fix them the fastest. Linux (and I assume the BSDs, although I didn't follow them then) usually had a fix out within hours - Microsoft usually didn't have a fix for months, which did a lot for th

Companies have largely moved to sourcing MIT/BSD-licensed code when we need open source components. The GPL is great but there's usually too many copyleft issues to enable commercial development unless the copyright holders agree to relicense the code (eg as they did with X264). The other huge problem with much of the GPL'd world is it can be very hard to find appropriate consultanvy expertise to adapt/fix/apply code. I've put out open offers of serious consultancy fees to foss development lists in one s

Facebook, Microsoft, Amazon, Apple and Oracle all have a whole lot more users than NetBSD. To most people, NetBSD brings absolutely nothing that Linux doesn't bring. NetBSD may run in some routers, but Linux probably runs in a *lot* more routers. Even FreeBSD may run in more routers than NetBSD (JunOS is FreeBSD based..).

I'm curious about the new packet filter. First, I'd like to see benchmarks on performance due to multi-core use (it certainly seems like a good idea).
And second, because I've hated every packet filter I ever used (tried to use) - ipfwadm, iptables, ipchains, ipfw, tc, lartc. Hate 'em.

the features list are things most kernels have had for a decade or two, but NetBSD acts like they are brand new features? Talking about these features that have been around forever as being the latest and greatest is absurd. The BSDs long ago lost relevance. Pretty much there is not a thing that they do better than Linux and there is a lot that they do not do that Linux can do. It is painfuil to install and the hardware support is worse than Windows. I cant see a a strength to it.

Support for VAX & toaster ovens. Also, lack of new code. Protip: New code = opportunity for instability / exploits. Linux is great for bleeding edge, but I run BSD on my NAS & Routers because stability is more important there.

Yeah, as long as you ignore the fact that that license supported the growth of its use. Yes, it may be counter-intuitive to some, but the GPL 2.0 license is a big part of WHY Linux has kicked *BSD's butt all over the marketplace.

It was not because of the legal issues. FreeBSD 4 was widely considered as the pinnacle of FreeBSD's technial advantage over Linux, for example.

I don't see how this disputes the simple fact that BSD Unix ran into major legal hurdles in the early days of its migration to the x86-based commodity software sphere, thus helping Linux gain an early lead.

BSDs were run on some of the busiest websites on the internet for years. Hotmail, Yahoo, cdrom.

What I quoted implies everything you just restated, and it still doesn't dispute the fact that "BSD Unix ran into major legal hurdles in the early days of its migration to the x86-based commodity software sphere, thus helping Linux gain an early lead." You seem to have no (willingness to acknowledge, or conception of) the importance of timing. I suppose you've never heard the phrase "fist to market", either.

I've never really used NetBSD (I've installed it a couple times, but never used it much), but I've used OpenBSD and FreeBSD quite a bit.

It's probably not what you'd want for a desktop system. It will run all the server stuff you listed just fine. The system compiler is gcc, although it likely comes with BSD make, so you'll want to install GNU make for compiling some software (usually it doesn't make a difference, but some projects rely on GNU make).

Packaging is similar to Slackware's package system (or at least how it used to be - I haven't use Slack in years) - it's tarball based. There is the pkgsrc system where you can automatically download and compile software for the system (based off FreeBSD's port system, which I rather like). You can also download and recompile the entire OS if you want (the infamous "make world" on FreeBSD, although glancing at the docs it seems NetBSD doesn't use that exact term).

Binary updates are generally available for security or bugfixes. The system doesn't do this for you (unless you recompile the system from source regularly - see below), so you have to check the errata page often to see if you need to update something. If you do, it's generally as simple as downloading the new binary and installing it using the system install tool.

Source updates are done on CVS trees - you track one of the trees (STABLE or CURRENT) and you get updates. The BSDs differ a bit where this is concerned, so I can't really give any specifics, but on FreeBSD and OpenBSD it's relatively painless once you get it set up. There's a utility to help you update your configuration files in FreeBSD and OpenBSD, so I assume NetBSD has something similar.

It supports CARP if you want to do clustering. I'm not sure if that will cover your needs, but if not, OpenBSD or FreeBSD might. I can attest that netbooting OpenBSD is cake - my firewall runs diskless.

As far as my experiences, well, there's a bit of a learning curve. It's easier if you've worked with Slackware or some other source-heavy Linux distro. The BSDs have a very unified feel to them, probably because there's no separation of userland and kernel development - the base system is developed as one unit, not a bunch of different projects. Like with anything, you have to use it a while to get a feel for it.

I like it. It's not as stuffy as Solaris, but it has a more consistant feel than Linux. Documentation is usually excellent, and the man pages are the definitive resource and usually include examples and explainations. I use OpenBSD for my firewall and nameserver, and FreeBSD for my file/webserver (due to ZFS and better Java support). I would use FreeBSD as a professional workstation (as long as it didn't require heavy 3D work), but not for my home machine.

If you've got the time to put into learning it (which if you know your stuff from Linux, it won't take long), it's well worth it. Throw it on a server and use it for a bit, and see what you think.

Slackware might not be source-heavy now (I haven't used it in years), but it used to be, if you actually wanted to do anything with the system.

If you wanted to install something that's not in the package sets (most everything, since Pat wasn't superman), you had to download and compile the source code. I never touched a line of C before I started on Slackware, and it was a trip learning to coax code into working. This was back before GNU autoconf was popular. Also, this was back when compiling your own k

I have an Asus EEE PC (900A) with NetBSD 5 that runs the stock X.org and uses the kernel Intel DRI driver (i915drm) for accelerated 3D performance -- pretty good given the hardware. There are DRI drivers for Radeon that I've also used, haven't looked into Nouveau. So the 3D support foundation is there, but the hardware pickings are still kinda slim.

Besides basic 3D acceleration, the continual 'catchup game' with desktop BSD is the explicit coding for Linux on the part of the big open source desktop envi