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.
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.
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.
I've recently learnt they are rewriting IPFW (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.
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.
[+] [-] vezzy-fnord|10 years ago|reply
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/
[2] https://www.dragonflybsd.org/docs/developer/DragonFly_Techno...
[+] [-] nocarrier|10 years ago|reply
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.
[+] [-] zkanda|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] arca_vorago|10 years ago|reply
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|10 years ago|reply
[+] [-] McElroy|10 years ago|reply
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|10 years ago|reply
[+] [-] protomyth|10 years ago|reply
[+] [-] lmm|10 years ago|reply