Why do you run it? Why not $OtherBSD? What’s the point?
They don’t actually try to offer any answers to these questions though, and, having played around with different operating systems a fair amount in my life, it is… you know, kinda an important question. You need a pitch you can make, maybe even with some data to back it up. Even among BSD’s, why is NetBSD interesting instead of FreeBSD, OpenBSD, or DragonflyBSD? Apart from “portable to lots of systems that don’t exist anymore”, which is the only actual pitch I’ve heard anyone make for it.
People question partly out of insecurity for their own choices, but partly out of curiosity.
Why do you get that brand? is opening the questioner to change their mind about a brand. This question is a confused questioner asking “Ok, so when I need a new box with an OS… why might I choose NetBSD?”
But how am I supposed to judge them on the internet if I do that? /s
More helpfully, every technical design is a set of tradeoffs. Those tradeoffs need to be guided by goals. What goals does NetBSD have that guides its design tradeoffs? I question people’s choices because I’m interested in the topic and want to know the answers!
I maintain several small sites for friends (OJS, Drupal etc.) and IME NetBSD runs much better on low-spec VMs than Debian. I’d often run into MySQL crashes due to low memory which went away after switching to NetBSD. Have a bunch of ARM SBCs and NetBSD runs quite well unlike Debian which is a hit or miss and often one has to pull kernels from random GitHub repos.
TBH, FreeBSD is more complete and is arguably the best Linux alternative nowadays but NetBSD is not bad, especially for small servers. pkgsrc has a good selection of packages, updated quarterly. ZFS is stable (not OpenZFS 2 yet, I think). DTrace works (only a subset of providers). Xen is fairly stable (lags Linux), NVMM is the homegrown hypervisor that seems to have found a new home in DragonflyBSD. RUMP and ATF are unique to NetBSD (ok, FreeBSD has ATF ported). Even though many of the features are incomplete there is enough to make it an interesting system to study and work on.
Being much smaller, NetBSD is a good base for learning and experimenting. The build system is a key enabler. You just need to checkout the source tree and run build.sh. It takes care of building the cross-compilation toolchain, base system, kernel, and generating a bootable image which can then be run on the hypervisor for testing. See [0] for an example setup.
Jan Schaumann teaches a couple of courses that use NetBSD [1, 2]. The “Advanced Programming” course is highly recommended and can be seen as an updated version of Stevens’s classic APUE. However, for kernel development, documentation is not much beyond the man pages and mailing list posts (the kernel internals parts of the handbook are woefully incomplete).
Looking forward to 10.0 which is shaping up to be a great release!
The other problem is: How much do I gain versus what things I have to work around with. I’m probably one of the bigger Linux-on-the-desktop fans in the circles I frequent and still… some things are just better on Windows or OSX. So far, 90% of the time the same things have been even worse on the BSDs. I admit this is probably an end-user point of view and not a developer’s, but still.
Slightly tangential, but I want to say that I always try to setup and run periodically development/debug env for backend services on netbsd, openbsd, freebsd,omniOS (ilumos distro).
Using different OS as dev environment sharpens our dev tool chain reflexes, removes unforeseen os-depedencies where they are not necessary, and forces me to select dev tools and libraries that work across the board.
There are challenges.
Netbsd for, probably, 2years or so could not address an issue where gradle, a pretty major JVM toolchain – was not working (and this is not just for me, other users reported the same).
I tried to debug this but it was getting gigabyte kernel dumps/log statements… This probably required skills from compiler, to JVM, to native library debugging – and it was just too much to bear.
It seems, according to some reports this started working again in NetBSD release 10 beta. I do not think anybody troubleshooted this, it’s just probably upgrading the NetBSD compile toolchain fixed something deep in JVM, and now gradle apparently works again.
Flow (FB Type system for JB) does not even distribute BSD binaries, so flow typechecking does not work in vscode or emacs using Flow. That’s one of many reasons, why I would like to switch to typescript this year to optimize the JS tooling away from Flow.
Also, since android development toolchain does not work on any of the BSDs – that’s basically prohibits development of that subsystem on the BSDs.
–
Finally, it would be great if NetBSD would become one of the donatable projects from amazon smile (FreeBSD is there :-) ).
Finally, it would be great if NetBSD would become one of the donatable projects from amazon smile (FreeBSD is there :-) ).
Not really a NetBSD user (have used it way back in my teenage times though). But they have a foundation, so maybe you should contact someone there on this topic?
Regarding what you mention about JVM. You wrote that NetBSD had an out of date compiler toolchain. That sounds like a NetBSD issue indeed, but more generally speaking portability is a two-way project. I really dislike how it’s only about Windows/Linux/macOS and usually amd64 these days. That doesn’t make your project “very portable”, as the claim often is. I think a lot of this has to do with commercial CI offerings. Jenkins, buildbot, etc. don’t have that issue so much.
The reason I bring this up is that it reminds me of another thing than using NetBSD from my teenage time. Perl has that CPAN Testers project. And ParrotVM had something similar where you could do something along the lines of make test to upload the test results. It always felt a bit odd to me that this strategy is not more common place. Being a teenager with much free time, I tried to run their stuff on very obscure systems (NetBSD on amd64 wouldn’t count as obscure here) and it was pretty interesting since bugs were found in libraries, OSs and even in third party libraries and project. I think if such a very open testing strategy would be used more we’d have more stable software and systems.
I also want to point out tools like Buildbot there. Unlike some of the other CI systems it makes it relatively easy to make strangers set up clients (server address and login information if I remember correctly) so if a volunteer has an OS/architecture/etc. that you/the commercial CI doesn’t have you can easily have it tested there. I think there is a lot of software out there that could be trivially made to run on more systems where the author simply isn’t aware, even if they do care about portability, sometimes indirectly. For example it might bring you really good contributors. Most people using more rarely used systems have really good skills and if your software is one of few options available on a platform you will attract people from that pool. And I think most people that ever contributed to open source software know how much some individuals are capable of contributing.
One of the things that often gets overlooked in these is not ‘why should you run X?’, but rather ‘why should you contribute to X and why should you ensure that your stuff is compatible with X?’ For NetBSD, I think the main reason is the Rump Kernel work. The set of people that use a project and the set of people that use code from a project are often very different sized sets. The GPL and the rapid refactoring with no regard for stable interfaces mean that very few projects copy code from Linux. NetBSD has both a license and a code structure that are amenable to copying bits of code. Most new unikernels copy at least some code from NetBSD (for example, the VirtIO drivers). A lot of userspace networking stack projects (including DPDK) copy code from FreeBSD.
The thing that a lot of companies miss when they start talking about Linux when they mean ‘the open source ecosystem’ is that the ecosystem is far more a source of disruptive technologies than it is a source of mature products. The projects that most resemble completed products are the ones that are least likely to be the sources of disruption. If you want to ensure that the next disruptive technology works well on your products, ensure that you have good support for *BSD: if nothing else, it will ensure that you aren’t relying on Linuxisms that make it hard for a new kernel to support, but very often you’ll find that the new thing can easily grab *BSD code to add a compat layer for whatever you need.
They don’t actually try to offer any answers to these questions though, and, having played around with different operating systems a fair amount in my life, it is… you know, kinda an important question. You need a pitch you can make, maybe even with some data to back it up. Even among BSD’s, why is NetBSD interesting instead of FreeBSD, OpenBSD, or DragonflyBSD? Apart from “portable to lots of systems that don’t exist anymore”, which is the only actual pitch I’ve heard anyone make for it.
Well here are some thoughts of NetBSD users why they use it : https://www.unitedbsd.com/d/90-netbsd-users-why-do-you-use-it-over-freebsd-and-openbsd
Or maybe people could just not question other people’s choices?
People question partly out of insecurity for their own choices, but partly out of curiosity.
Why do you get that brand? is opening the questioner to change their mind about a brand. This question is a confused questioner asking “Ok, so when I need a new box with an OS… why might I choose NetBSD?”
But how am I supposed to judge them on the internet if I do that? /s
More helpfully, every technical design is a set of tradeoffs. Those tradeoffs need to be guided by goals. What goals does NetBSD have that guides its design tradeoffs? I question people’s choices because I’m interested in the topic and want to know the answers!
heh :-)
As for the design goals, NetBSD is somewhat known for looking for good abstractions. From that, ideas like rump kernel follow naturally.
I maintain several small sites for friends (OJS, Drupal etc.) and IME NetBSD runs much better on low-spec VMs than Debian. I’d often run into MySQL crashes due to low memory which went away after switching to NetBSD. Have a bunch of ARM SBCs and NetBSD runs quite well unlike Debian which is a hit or miss and often one has to pull kernels from random GitHub repos.
TBH, FreeBSD is more complete and is arguably the best Linux alternative nowadays but NetBSD is not bad, especially for small servers. pkgsrc has a good selection of packages, updated quarterly. ZFS is stable (not OpenZFS 2 yet, I think). DTrace works (only a subset of providers). Xen is fairly stable (lags Linux), NVMM is the homegrown hypervisor that seems to have found a new home in DragonflyBSD. RUMP and ATF are unique to NetBSD (ok, FreeBSD has ATF ported). Even though many of the features are incomplete there is enough to make it an interesting system to study and work on.
Being much smaller, NetBSD is a good base for learning and experimenting. The build system is a key enabler. You just need to checkout the source tree and run build.sh. It takes care of building the cross-compilation toolchain, base system, kernel, and generating a bootable image which can then be run on the hypervisor for testing. See [0] for an example setup.
Jan Schaumann teaches a couple of courses that use NetBSD [1, 2]. The “Advanced Programming” course is highly recommended and can be seen as an updated version of Stevens’s classic APUE. However, for kernel development, documentation is not much beyond the man pages and mailing list posts (the kernel internals parts of the handbook are woefully incomplete).
Looking forward to 10.0 which is shaping up to be a great release!
[0] - https://t.pagef.lt/working-with-the-netbsd-kernel/ [1] - https://stevens.netmeister.org/615/ [2] - https://stevens.netmeister.org/631/
The other problem is: How much do I gain versus what things I have to work around with. I’m probably one of the bigger Linux-on-the-desktop fans in the circles I frequent and still… some things are just better on Windows or OSX. So far, 90% of the time the same things have been even worse on the BSDs. I admit this is probably an end-user point of view and not a developer’s, but still.
Slightly tangential, but I want to say that I always try to setup and run periodically development/debug env for backend services on netbsd, openbsd, freebsd,omniOS (ilumos distro).
Using different OS as dev environment sharpens our dev tool chain reflexes, removes unforeseen os-depedencies where they are not necessary, and forces me to select dev tools and libraries that work across the board.
There are challenges.
Netbsd for, probably, 2years or so could not address an issue where gradle, a pretty major JVM toolchain – was not working (and this is not just for me, other users reported the same). I tried to debug this but it was getting gigabyte kernel dumps/log statements… This probably required skills from compiler, to JVM, to native library debugging – and it was just too much to bear.
It seems, according to some reports this started working again in NetBSD release 10 beta. I do not think anybody troubleshooted this, it’s just probably upgrading the NetBSD compile toolchain fixed something deep in JVM, and now gradle apparently works again.
Flow (FB Type system for JB) does not even distribute BSD binaries, so flow typechecking does not work in vscode or emacs using Flow. That’s one of many reasons, why I would like to switch to typescript this year to optimize the JS tooling away from Flow.
Also, since android development toolchain does not work on any of the BSDs – that’s basically prohibits development of that subsystem on the BSDs.
–
Finally, it would be great if NetBSD would become one of the donatable projects from amazon smile (FreeBSD is there :-) ).
Not really a NetBSD user (have used it way back in my teenage times though). But they have a foundation, so maybe you should contact someone there on this topic?
http://netbsd.org/foundation/
Regarding what you mention about JVM. You wrote that NetBSD had an out of date compiler toolchain. That sounds like a NetBSD issue indeed, but more generally speaking portability is a two-way project. I really dislike how it’s only about Windows/Linux/macOS and usually amd64 these days. That doesn’t make your project “very portable”, as the claim often is. I think a lot of this has to do with commercial CI offerings. Jenkins, buildbot, etc. don’t have that issue so much.
The reason I bring this up is that it reminds me of another thing than using NetBSD from my teenage time. Perl has that CPAN Testers project. And ParrotVM had something similar where you could do something along the lines of
make testto upload the test results. It always felt a bit odd to me that this strategy is not more common place. Being a teenager with much free time, I tried to run their stuff on very obscure systems (NetBSD on amd64 wouldn’t count as obscure here) and it was pretty interesting since bugs were found in libraries, OSs and even in third party libraries and project. I think if such a very open testing strategy would be used more we’d have more stable software and systems.I also want to point out tools like Buildbot there. Unlike some of the other CI systems it makes it relatively easy to make strangers set up clients (server address and login information if I remember correctly) so if a volunteer has an OS/architecture/etc. that you/the commercial CI doesn’t have you can easily have it tested there. I think there is a lot of software out there that could be trivially made to run on more systems where the author simply isn’t aware, even if they do care about portability, sometimes indirectly. For example it might bring you really good contributors. Most people using more rarely used systems have really good skills and if your software is one of few options available on a platform you will attract people from that pool. And I think most people that ever contributed to open source software know how much some individuals are capable of contributing.
One of the things that often gets overlooked in these is not ‘why should you run X?’, but rather ‘why should you contribute to X and why should you ensure that your stuff is compatible with X?’ For NetBSD, I think the main reason is the Rump Kernel work. The set of people that use a project and the set of people that use code from a project are often very different sized sets. The GPL and the rapid refactoring with no regard for stable interfaces mean that very few projects copy code from Linux. NetBSD has both a license and a code structure that are amenable to copying bits of code. Most new unikernels copy at least some code from NetBSD (for example, the VirtIO drivers). A lot of userspace networking stack projects (including DPDK) copy code from FreeBSD.
The thing that a lot of companies miss when they start talking about Linux when they mean ‘the open source ecosystem’ is that the ecosystem is far more a source of disruptive technologies than it is a source of mature products. The projects that most resemble completed products are the ones that are least likely to be the sources of disruption. If you want to ensure that the next disruptive technology works well on your products, ensure that you have good support for *BSD: if nothing else, it will ensure that you aren’t relying on Linuxisms that make it hard for a new kernel to support, but very often you’ll find that the new thing can easily grab *BSD code to add a compat layer for whatever you need.