Here is the other part. For the BSD's, it's not as simple as, "someone implement them, then we include them." You can package it in the ports trees, but they won't be apart of the base system. Because BSD and Linux are similar in a lot of ways, they differ in a lot. The BSDs are designed with the idea that each BSD makes a completed "base system". The same team writing kernel code is the same team writing user land. So each BSD's core utils is developed and maintained by their respective development team. It is not like Linux, which is really more like smashing different projects from different teams together. At least for what is considered the "base" system.
Then mentioned elsewhere, but this isn't as big of a problem on OpenBSD, but would be fore NetBSD. The Rust tools don't support all the supported architectures. This is where BSD philosophy diverges. With NetBSD, if you got a PDP-11 or a toaster with a chip, they are more than happy to make NetBSD run on it, and the NetBSD team also don't necessarily have a requirement for physical hardware, if there is an esoteric chip with QEMU support, they will happily try to support it. OpenBSD will maintain support for an architecture so long as someone is willing to maintain it and owns the physical hardware (which is why it supports less than NetBSD).
This is also why NetBSD is sort of "stuck on
" gcc. I believe they would like to move to clang, but can't due to architecture support.
Some more addition to the first paragraph: OpenBSD to a degree takes this to a whole other level than the other BSDs. OpenBSD maintains their own fork of X11 called xenocara and window manager, cwm. In theory, you can have a pretty basic and functional system from boot code to window manager with all of that code being code maintained by the same team, the OpenBSD developers. They even have their own version control system called got.
Thanks for this indepth response. It's made me realise that I'm very much in the linux "smashing together different projects" camp. Probably much more so than other linux users seeing as I prefer to use super minimalist distros like Alpine + my favourite utils, rather thant he standard GNU/Linux.
No problem. Like I said, its easy to think that since they are both unixy-systems and a lot of things "rhyme" that a solution that works for one, works for the other. But that they in fact have different design and development philosophies. And this is even true amongst the BSDs themselves. NetBSD, from boot code to the top of the stack is developed independently from FreeBSD, OpenBSD, Dragonfly, and vice-verse. Now, they will take ideas and re-implement them into their own stack, but they don't necessarily share code directly.
Then mentioned elsewhere, but this isn't as big of a problem on OpenBSD, but would be fore NetBSD. The Rust tools don't support all the supported architectures. This is where BSD philosophy diverges. With NetBSD, if you got a PDP-11 or a toaster with a chip, they are more than happy to make NetBSD run on it, and the NetBSD team also don't necessarily have a requirement for physical hardware, if there is an esoteric chip with QEMU support, they will happily try to support it. OpenBSD will maintain support for an architecture so long as someone is willing to maintain it and owns the physical hardware (which is why it supports less than NetBSD).
This is also why NetBSD is sort of "stuck on " gcc. I believe they would like to move to clang, but can't due to architecture support.
Some more addition to the first paragraph: OpenBSD to a degree takes this to a whole other level than the other BSDs. OpenBSD maintains their own fork of X11 called xenocara and window manager, cwm. In theory, you can have a pretty basic and functional system from boot code to window manager with all of that code being code maintained by the same team, the OpenBSD developers. They even have their own version control system called got.