
DragonFly BSD 4.2 released - ceratopisan
http://www.dragonflybsd.org/release42/
======
vezzy-fnord
Good to see progress on HAMMER2. The removal of SCTP is a very interesting
decision. reapctl(2) has since been renamed to procctl(2), I believe.

DragonFly BSD is an amazing OS that really pushes the limits of the Unix
paradigm. For instance, things like process checkpointing as a single syscall
with two flags of CKPT_FREEZE and CKPT_THAW, among many other things [1] [2].
Elegant simplicity and powerful functionality.

Any self-respecting Unix (particularly Linux) developer needs to check it out
and preferably steal a feature or two. DF is a middle ground between Unix
workstation and cluster OS. Anything you do on that ground is bound to be more
interesting than Docker.

I've always wondered if someone could add some polish and marketing to make
DragonFly a solid competitor to the likes of CoreOS and Mesosphere. It already
has similar features neatly integrated with a low cognitive usage overhead, so
it's mostly a matter of being a good salesperson.

[1]
[http://www.dragonflybsd.org/features/](http://www.dragonflybsd.org/features/)

[2]
[https://www.dragonflybsd.org/docs/developer/DragonFly_Techno...](https://www.dragonflybsd.org/docs/developer/DragonFly_Technologies/)

~~~
nocarrier
I'm in favor of Dragonfly removing SCTP. It was okay on paper but never saw
adoption and was basically doomed after most firewalls were configured to
block it--this is why people are building their own transports on top of UDP
these days. It would almost be impossible to launch a new IP magic protocol
number now.

I dig the other stuff that Dragonfly is doing too. I've been a longtime BSD
fan and I like that there is a strong-willed counterpoint to FreeBSD with a
different architectural philosophy. The pressure pushes FreeBSD forward faster
than if Dragonfly wasn't around.

~~~
muppetman
SCTP is very much alive and kicking. In fact I have just been debugging an
issue with it before reading this post. It's used between Mobile Network
Elements, especially in the 4G Space, as the transport that DIAMETER sit on
top of.

So I agree it's niche, but it's far from a failure.

~~~
nocarrier
It's cool to hear someone using it, but it's still doomed to be relegated to
use inside private networks versus being used as a general use internet
transport protocol, which was the point I was making.

~~~
muppetman
Ahh, yes. I agree, there's very little SCTP used in public networks.

~~~
quink
NAT being the big reason. Ironically now more than ever before is the time for
NAT to disappear as IPv6 is deployed.

------
arca_vorago
I've been keeping track of DFly BSD for a while now, and I really like where
it is headed. The network stack alone is polished enough that if I were to,
say, start a local ISP, I would probably be using it as the primary backend.

Dillon's decision to support only x86-x64 I think was a good choice because it
helped reduced the workload associated with his multiprocessing/threading
system, which is another awesome set of features that I have a feeling will
end up forcing Linux and Mach to re-evaluate how they do some things.

For me, I think it may be time to move it out of a VM and onto a semi-regular
use machine bare metal.

Once Hammer2 is prod ready I have a feeling I may like it better than ZFS or
BTRFS, but only time will tell I suppose.

~~~
candl
I've recently learnt they are rewriting IPFW
([https://www.dragonflybsd.org/docs/ipfw2/](https://www.dragonflybsd.org/docs/ipfw2/))
to fully take advantage of DFly's features. Eventhough I am not particularly
fond of IPFW's syntax and prefer PF it's nice to see that a good SMP friendly
firewall is in the works.

~~~
protomyth
"Eventhough I am not particularly fond of IPFW's syntax and prefer PF it's
nice to see that a good SMP friendly firewall is in the works."

OpenBSD is slowly working to make PF SMP friendly:
[http://quigon.bsws.de/papers/2015/asiabsdcon/mgp00033.html](http://quigon.bsws.de/papers/2015/asiabsdcon/mgp00033.html)

~~~
bch
So is NetBSD[0]... exciting times in *BSD-land...

[0] [http://www.netbsd.org/~rmind/npf/](http://www.netbsd.org/~rmind/npf/)

~~~
feld
npf is not pf, if that's what you're implying (can't tell?)

~~~
bch
ah no -- I was only talking about multiprocessor-ifying packet management.

edit: s/package management/packet management/

~~~
feld
oh, ok, yes -- this is getting traction in almost every project. It's nice to
see this won't be a bottleneck.

------
McElroy
>GCC 5

A bit surprising for a BSD project, seeing as 4.2.1 was the last
GPLv2-licensed release and most of the rest of the BSD communities seem, shall
we say, not too enthusiastic about GPLv3.

~~~
noselasd
NetBSD also isn't bothered much the GPLv3 change of gcc, NetBSD 7 will ship
with gcc 4.8

