I hope you understand how unique netbsd is, it is one of the only systems which can be compiled so easily with just a single script even from linux or other systems and its rump kernel etc. drivers from what I know are (modular?) so they could be used with other kernels as well if any kernel wants ie.
You never know where the innovation can be, I feel like that each kernel/operating system can bring a new idea, as an example, templeOS uses Holy C which basically is Just in time C (iirc) and that means that you can just edit files of templeOS and restart and those changes would occur
I know TempleOS is niche and a meme OS but I feel like that there are a lot of ideas and unique operating systems and I have heard that netbsd can be good in giving driver support to.
This is just one of many things, and I feel like the main point of NetBSD and the likes are fundamental hackability, they can run on things like routers as well although most run openbsd/freebsd but still. I don't see a reason not to unless you are speaking monetary (ie. it may take some extra funds developing/hosting but that is chump change) but I feel like NETBSD is a novel project with respectable goals and they aren't going to change just for this.
More Options are a good thing. if I can have a project run on Netbsd, then its very easy to port it over to any other vast array of hardware as well, and that hardware includes extremely embedded hardware as well I guess
So in my other comment I mentioned some specific(s) to (or rather, originated from) NetBSD, just as much as for example pledge() (fine-grained system call restriction), unveil() (filesystem visibility restriction), arc4random family[1] (ChaCha20-based CSPRNG), reallocarray() (integer overflow-safe realloc), OpenBGPD (BGP daemon), OpenOSPFD (OSPF daemon), httpd (web server), acme-client (Let's Encrypt client), signify (cryptographic signing tool), etc. are specific to OpenBSD.
DragonflyBSD has some goodies too while we are at it! For example varsym (Variable Symbol System - per-process environment-like variable substitution), nlookup (namecache-based path lookup replacing the vnode-based namei()), objcache (per-CPU object caching allocator), LWKT (Light Weight Kernel Threads - message-passing based threading), HAMMER2 (clustered COW filesystem with multi-master replication, successor to HAMMER), and so forth.
All popular BSDs have their own rich history. I know more about DragonflyBSD than NetBSD, so as an example: DragonflyBSD's core design philosophy centers on SMP scalability (cache-coherent token-based synchronization and LWKT message passing, avoiding fine-grained locking), OpenBSD's gist is security, and so forth.
[1] The ChaCha20-based CSPRNG (originally arc4random was RC4-based), which has been ported to other BSDs and some Linux systems.
(Sorry, I was really tempted to elaborate on these unique features and I felt like your comment was the perfect place for it!).
> I hope you understand how unique netbsd is, it is one of the only systems which can be compiled so easily with just a single script even from linux or other systems and its rump kernel etc. drivers from what I know are (modular?) so they could be used with other kernels as well if any kernel wants
Aren't competing kernels already shipping support for this hardware? Surely the project has to have more selling points than "can be compiled with a single script."
I meant in the sense that since NetBSD supports soooo many devices, it can also help innovation in other kernels if need be as well by being able to take driver support via its rumpkernel as well if need be
And to be honest, I feel like there is this sense of freedom knowing that you can have a system which is portable, if some script can run on my pc on netbsd, chances are if its not too specific, it could run on your pc or even your toaster lol!
Netbsd can run on any device possible and I really appreciate it.
>Surely the project has to have more selling points than "can be compiled with a single script."
Personally I have only heard good things about netbsd but I don't have much expertise in it (sorry), I can recommend you to take a look at smolbsd which looks really cool for uni-kernel purposes as well
> Netbsd can run on any device possible and I really appreciate it.
That's more of a meme than reality and I wish people would actually look into it before mindlessly repeating the trope. I did, when I wanted to run a new OS on a niche device, and the reality is very different. Nowadays Linux works on a lot more hardware than NetBSD does. Yes, NetBSD nominally supports a few more architectures than Linux (very few, especially that μClinux is now upstreamed), but the driver situation for the rest of the system means that it can't run on most devices from those architecture anyway.
This and 'runs' is a very relative term. What exactly works, what doesn't? What do you need? How power efficient or buggy is it? How is the performance? I remember running Linux on an SGI Indy. Not everything worked, as not every Indy was equal (I had six) but also compared to IRIX (especially 5.x series) the performance was dog slow. The Indy had some good hardware (like the soundcard or Indycam) but that wouldn't work (well) on Linux. My Octane 2 didn't have 3D accelerated graphics on Linux. The state of every port isn't equal. Same on OpenBSD. Furthermore, if you run Linux your distribution of choice may not be available or work well.
Note that for most of the more esoteric platforms NetBSD supports, “support” simply means they continue to cross-compile to target that platform. There’s been lots of cases where there’s some major regression that makes a port unusable (can’t boot, can’t interact with the system, etc) and nobody notices for years because there’s both nobody testing these ports and nobody actually using them. At that point, the value of the support is questionable.
> I hope you understand how unique netbsd is, it is one of the only systems which can be compiled so easily with just a single script even from linux or other systems and its rump kernel etc. drivers from what I know are (modular?) so they could be used with other kernels as well if any kernel wants ie.
Linus hast this with User Mode Linux (upstream) and Linux Kernel Library (out of tree).
> You never know where the innovation can be, I feel like that each kernel/operating system can bring a new idea, as an example, templeOS uses Holy C which basically is Just in time C (iirc) and that means that you can just edit files of templeOS and restart and those changes would occur
That's a while ago, but Fabrice Bellard did a demo with his tiny c compiler where it would would compile the Linux Kernel at boot time and then boot the compiled Kernel.
> This is just one of many things, and I feel like the main point of NetBSD and the likes are fundamental hackability, they can run on things like routers as well although most run openbsd/freebsd but still.
Most consumer grade routers run Linux out of the box.
> More Options are a good thing. if I can have a project run on Netbsd, then its very easy to port it over to any other vast array of hardware as well, and that hardware includes extremely embedded hardware as well I guess
uCLinux (upstream) doesn't even need a MMU. It can run on a Cortex-M4 with 8mb ram.
> That's a while ago, but Fabrice Bellard did a demo with his tiny c compiler where it would would compile the Linux Kernel at boot time and then boot the compiled Kernel.
That’s interesting. Do you have a link you can share? Or remember any more details?
