NetBSD 6.1.4 and 6.0.5 released(blog.netbsd.org)
blog.netbsd.org
NetBSD 6.1.4 and 6.0.5 released
https://blog.netbsd.org/tnf/entry/netbsd_6_1_4_and
22 comments
Anyone using NetBSD these days could share what's your use case? Is it just about exotic or legacy systems or are there any upsides compared to other BSDs?
It's my (laptop) desktop. Which is sort of funny, because it's got weak graphics support (e.g. accelerated gfx). Despite that here's why I keep it:
It's a model of development beauty. From a single codebase, it supports 58 tier one and two architectures.
It "feels" incredibly solid, by design and construction.
It's sort of a side project, but the defacto standard source-based package management (pkgsrc) is the nicest I've used. It's interesting, because one might think "what's to get excited about with package management?". Nothing, if things are going well. Minimal dependency-hell problems, no issues with base-system versus pkgsrc versus "hand-built" installations. No problems rolling your own packages to add to pkgsrc for your own custom packages. And all driven by simple Makefiles.
The kernel and userland are also built with Makefiles, and lend themselves to exploration. Especially some of the userland tools when you consider what they're tasked to do: run portably across multiple architectures. Bootstrap systems. Cross-building. It's interesting, and there's lots to learn and take advantage of.
Even though it's solid and there's lots of "tried and true" methods in there, there's lots of interesting new work going on. When the project was fiddling with SMP, it tried interesting things[0]. It's doing interesting things now with virtualization, with Xen (dom0 and domU), RUMP[1], which is interesting for running kernel components in userspace, but even moreso because it's not tied to NetBSD [1][2]...
I could go on and on. Couple more points though: it's mostly BSD licensed, which makes for corporate friendly code. Secondly, the features here come with a super-friendly knowledgeable community as a bonus.
Try it for 4 weeks. You'll like it.
[0]http://en.m.wikipedia.org/wiki/NetBSD#Features (see symmetric multiprocessing)
[1]http://wiki.netbsd.org/rumpkernel/
[2]http://en.m.wikipedia.org/wiki/Anykernel
It's a model of development beauty. From a single codebase, it supports 58 tier one and two architectures.
It "feels" incredibly solid, by design and construction.
It's sort of a side project, but the defacto standard source-based package management (pkgsrc) is the nicest I've used. It's interesting, because one might think "what's to get excited about with package management?". Nothing, if things are going well. Minimal dependency-hell problems, no issues with base-system versus pkgsrc versus "hand-built" installations. No problems rolling your own packages to add to pkgsrc for your own custom packages. And all driven by simple Makefiles.
The kernel and userland are also built with Makefiles, and lend themselves to exploration. Especially some of the userland tools when you consider what they're tasked to do: run portably across multiple architectures. Bootstrap systems. Cross-building. It's interesting, and there's lots to learn and take advantage of.
Even though it's solid and there's lots of "tried and true" methods in there, there's lots of interesting new work going on. When the project was fiddling with SMP, it tried interesting things[0]. It's doing interesting things now with virtualization, with Xen (dom0 and domU), RUMP[1], which is interesting for running kernel components in userspace, but even moreso because it's not tied to NetBSD [1][2]...
I could go on and on. Couple more points though: it's mostly BSD licensed, which makes for corporate friendly code. Secondly, the features here come with a super-friendly knowledgeable community as a bonus.
Try it for 4 weeks. You'll like it.
[0]http://en.m.wikipedia.org/wiki/NetBSD#Features (see symmetric multiprocessing)
[1]http://wiki.netbsd.org/rumpkernel/
[2]http://en.m.wikipedia.org/wiki/Anykernel
It's very easy to learn about doing some interesting things.
http://www.netbsd.org/docs/kernel/pseudo/
there are ec2 images ready and working, it works as a xen dom0, there's a new firewall (npf) in development that's interesting, etc.
For a time some kind of planetary alignment made it the fastest ruby platform according to a few benchmarks.
build.sh makes it very very easy to cross-compile for arm/mips if you're building an rpi appliance (for example).
http://www.netbsd.org/docs/kernel/pseudo/
there are ec2 images ready and working, it works as a xen dom0, there's a new firewall (npf) in development that's interesting, etc.
For a time some kind of planetary alignment made it the fastest ruby platform according to a few benchmarks.
build.sh makes it very very easy to cross-compile for arm/mips if you're building an rpi appliance (for example).
Link to the fastest ruby thing? :-)
UPDATE: found it here http://www.aydogan.net/ruby/mauthesis.com/ruby_bench/
UPDATE: found it here http://www.aydogan.net/ruby/mauthesis.com/ruby_bench/
Fastest ruby if we disregard Jruby or include it ?
It is much the easiest to get started in developing. It is a nice simple modern BSD.
The netbsd.org website at https://www.netbsd.org/gallery/ under "Products and services around NetBSD" section https://www.netbsd.org/gallery/#products gives links to a lot of users and uses.
Maybe education, but I haven't heard of that use. NetBSD tends to go for simplicity of code over everything else.
Maybe this is just a bad example, but I was digging through the timing wheel code of the kernels of all three main BSDs at one point. FreeBSD and NetBSD had nearly the same code. OpenBSD's was rather simpler and did not have a lot of the locking code that the other two had. My guess is that OpenBSD has either a giant lock or its kernel only runs on one core.
Most of the OpenBSD kernel is under a big lock but they are adding more fine grained locking. OpenBSD didn't add kernel threads until 2012. A bit late in comparison to freebsd and linux but it wasn't a priority to them. It also allowed them to benefit from the lessons everybody else learned the hard way.
NetBSD kernel code is not simpler compared to FreeBSD/OpenBSD kernel code. On average, it's probably the same. I can definitely think of some things for which it is more complex.
> I can definitely think of some things for which it is more complex.
It dumbed down the malloc() interface, for example (no tags).
The SDF Public Access Unix System[1] uses NetBSD exclusively. They had some bad[2] times[3] in the past with Linux[4], and they seem very happy with NetBSD now.
[1] http://en.wikipedia.org/wiki/SDF_Public_Access_Unix_System
[2] ftp://sdf.lonestar.org/pub/sdf/historical/fscked_up.txt
[3] ftp://sdf.lonestar.org/pub/sdf/historical/linux-beastie.txt
[4] ftp://sdf.lonestar.org/pub/sdf/historical/bye-bye-leenox.txt
[1] http://en.wikipedia.org/wiki/SDF_Public_Access_Unix_System
[2] ftp://sdf.lonestar.org/pub/sdf/historical/fscked_up.txt
[3] ftp://sdf.lonestar.org/pub/sdf/historical/linux-beastie.txt
[4] ftp://sdf.lonestar.org/pub/sdf/historical/bye-bye-leenox.txt
I run it on desktop, laptops and router. I have a few legacy systems too.
I switched to it from FreeBSD about 15 years ago as I was doing embedded development and wanted to run the same OS as development host and target.
I switched to it from FreeBSD about 15 years ago as I was doing embedded development and wanted to run the same OS as development host and target.
I believe Apple's AirPort and Time Capsule products run NetBSD, although it's a little difficult to find a source for that.
It is the least painful OS that still has good performance and scalability. I would use openbsd if it weren't for the fact that it is 50% slower and is basically useless on SMP systems (which is everything now). FreeBSD might as well be gnu/linux at this point it is so bloated and convoluted.
I use NetBSD in Amazon EC2 for personal projects. It's been a good partner for that. I like the "run anywhere" mantra.