As someone who isn't very familiar with NetBSD aside from the "It runs on a toaster!" meme, what does NetBSD bring to the table compared to something like FreeBSD if you want to run it on a common architecture like x86?
This sounds like something which, were it done by Microsoft, would be taken as evidence of terminal senility on the part of the technical leads. What is NetBSD's reasoning for doing it?
The difference being that in this case, it's a doohickey in NetBSD that you can turn on if you're feeling bored or deranged. Microsoft would make it the new paradigm for development and then deprecate it four years later when the next new paradigm came out.
- For its excellent backward compatibility: NetBSD 6.1 is still able to run a.out binaries built for NetBSD 1.0
- For its system-independant build system. Building NetBSD needs a POSIX system with a C compiler, which does not need to be NetBSD. It first builds the tools for the host, including the compiler itself, and then the target NetBSD system, which may be for another CPU.
- For its machine-independant drivers. Have a fancy platform with an odd CPU? If NetBSD has a driver for a chip, it will work as is, no need to port it
For me the biggest advantage to running NetBSD on x86 is that it includes many of the features of other BSDs (simplicity, documentation, PF, CARP, etc..) and it runs great as a Xen Dom0/DomU.
Because NetBSD runs so well as a domU I'm really surprised it's not much more popular at many of the larger Xen-based cloud hosting platforms. I've heard it also works well with KVM & virtio but never tired it myself.
I just tried it on RHEVH the other week, and it -runs- well (easy to setup, just works, virtio works as expected), but on shutdown, would jump to kernel debugger.
I didn't get shutdown issue sorted, or benchmark performance, but it's really easy to setup and start playing with.
I haven't looked at in in years, but their code tends to strive for more simplicity, to ease portability. Which usually means that they can't make the same sacrifices as FreeBSD does, especially regarding SMP and multi-care systems. But I've heard that this got a lot better in recent years and by postponing that skipped a few errors that FreeBSD made.
Also their package system (pkgsrc) is a bit different from FreeBSDs ports, and those tend to be highly subjective, regarding ease of use and the amount of software packages covered.
My info might be a bit outdated, but I think NetBSD provides the best Xen support.
I think that simplicity is the big difference between {net,open}bsd and other operating systems. It is amazing how small some of the standard programs are compared to GNU.
If you ever want to read some excellent C code just go and look at the source for some userland utilities in OpenBSD.
The current FreeBSD installer is quite bad, I was unable to install a system with a NTFS partition left untouched. I wasn't able to create the partitions manually because it complains about "invalid arguments".
Also, when leaving out the bootcode partition, it happily installs and leaves you with a non-bootable system.
In addition, the pkgin tool is a really handy tool to install binary packages. I'm running in a VM with not too much memory and compiling would take ages or fail because of the amount of memory that compiling requires.
Comments
As someone who isn't very familiar with NetBSD aside from the "It runs on a toaster!" meme, what does NetBSD bring to the table compared to something like FreeBSD if you want to run it on a common architecture like x86?
Congratulations on the release, by the way. :)
I run FreeBSD on my home server (because of ZFS). But I use NetBSD every now and then.
Things I like about NetBSD:
- It has support for both Dom0 and DomU Xen domains.
- It is very clean and portable code, you can build it on any *nix machine and get install media, just do ./build.sh release; ./build.sh iso-image
- There are fun experiments being done. Like rump kernels and Lua in kernel space
- It's dominated by hobbyists.
I run FreeBSD on my home server (because of ZFS).
How is it better than the alternatives (linux and other bsds)?
> Lua in kernel space
This sounds like something which, were it done by Microsoft, would be taken as evidence of terminal senility on the part of the technical leads. What is NetBSD's reasoning for doing it?
Rapid prototyping of drivers is one reason.
A recent project adds Lua to Linux for dtrace style functionality https://github.com/ktap/ktap
The difference being that in this case, it's a doohickey in NetBSD that you can turn on if you're feeling bored or deranged. Microsoft would make it the new paradigm for development and then deprecate it four years later when the next new paradigm came out.
Why NetBSD?
- For its excellent backward compatibility: NetBSD 6.1 is still able to run a.out binaries built for NetBSD 1.0
- For its system-independant build system. Building NetBSD needs a POSIX system with a C compiler, which does not need to be NetBSD. It first builds the tools for the host, including the compiler itself, and then the target NetBSD system, which may be for another CPU.
- For its machine-independant drivers. Have a fancy platform with an odd CPU? If NetBSD has a driver for a chip, it will work as is, no need to port it
[From http://bsd.slashdot.org/comments.pl?sid=3764147&cid=4376...]
For me the biggest advantage to running NetBSD on x86 is that it includes many of the features of other BSDs (simplicity, documentation, PF, CARP, etc..) and it runs great as a Xen Dom0/DomU.
Because NetBSD runs so well as a domU I'm really surprised it's not much more popular at many of the larger Xen-based cloud hosting platforms. I've heard it also works well with KVM & virtio but never tired it myself.
I just tried it on RHEVH the other week, and it -runs- well (easy to setup, just works, virtio works as expected), but on shutdown, would jump to kernel debugger.
I didn't get shutdown issue sorted, or benchmark performance, but it's really easy to setup and start playing with.
I haven't looked at in in years, but their code tends to strive for more simplicity, to ease portability. Which usually means that they can't make the same sacrifices as FreeBSD does, especially regarding SMP and multi-care systems. But I've heard that this got a lot better in recent years and by postponing that skipped a few errors that FreeBSD made.
Also their package system (pkgsrc) is a bit different from FreeBSDs ports, and those tend to be highly subjective, regarding ease of use and the amount of software packages covered.
My info might be a bit outdated, but I think NetBSD provides the best Xen support.
I think that simplicity is the big difference between {net,open}bsd and other operating systems. It is amazing how small some of the standard programs are compared to GNU.
If you ever want to read some excellent C code just go and look at the source for some userland utilities in OpenBSD.
The current FreeBSD installer is quite bad, I was unable to install a system with a NTFS partition left untouched. I wasn't able to create the partitions manually because it complains about "invalid arguments".
Also, when leaving out the bootcode partition, it happily installs and leaves you with a non-bootable system.
In addition, the pkgin tool is a really handy tool to install binary packages. I'm running in a VM with not too much memory and compiling would take ages or fail because of the amount of memory that compiling requires.
I also kinda like the firewall but YMMV.