If anyone could summarize what makes DragonFly's stack different I'd be obliged.
I understand FreeBSD's networking stack has been well-regarded since the 90s[1] and has shipped in many environments and consumer devices. Now that it's 2017, it's interesting to see what else is out there.
Literally the entire section 2 of the linked to file discusses exactly what you're interested to know. It details the evolution of the DragonFlyBSD's network stack, which started as the FreeBSD network stack.
I'm more interested in the higher level takeaway. Why should developers use Dragonfly?
Don't get me wrong, I appreciate the ability to peruse the kernel implementation narrative in the first place.
As I'm not a kernel developer I'm left wondering what it means.
3. The parts of the DragonFlyBSD’s net-work stack that can really enjoy help hands.
...
- The IPv6 stack; though I am making progress, the progress is slow.
Ouch. I'm guessing this means IPv6 is just slow and not that it doesn't work at all, but it seems like something that's going to be a problem in a couple of years.
He's saying it is in a poor state and development is slow. My supposition is that this means there are missing features and a lack of performance optimization. Presumably the DFlyBSD network stack is now different enough that they can't just pull in the FreeBSD IPv6 stack and drop it in.
I was a diehard FreeBSD user around the time of the fork. Everything is just so well documented, the layout of things is sane, there was just so much order for a newbie like me. Eventually I moved to Linux but am still fond of *BSDs.
To gain experience on the platform for potential jobs. Honestly though I'm not sure. I guess I toyed with fedora and liked it well enough. I might move back and give trueOS a try.
I understand FreeBSD's networking stack has been well-regarded since the 90s[1] and has shipped in many environments and consumer devices. Now that it's 2017, it's interesting to see what else is out there.
[1] https://people.freebsd.org/~andre/tcpoptimization.html