4 ms·

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, st

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 11y ago
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 11y ago
  "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 11y ago
    So is NetBSD[0]... exciting times in *BSD-land... [0] http://www.netbsd.org/~rmind/npf/ http://www.netbsd.org/~rmind/npf/
    - feld 11y ago
      npf is not pf, if that's what you're implying (can't tell?)
      - bch 11y ago
        ah no -- I was only talking about multiprocessor-ifying packet management. edit: s/package management/packet management/
        feld 11y ago
        oh, ok, yes -- this is getting traction in almost every project. It's nice to see this won't be a bottleneck.
- slasaus 11y ago
  And see this recent patch [1] from an Oracle developer to make PF SMP proof. It's under review. [1] http://marc.info/?t=143526332700004&r=1&w=2 http://marc.info/?t=143526332700004&r=1&w=2

candl 11y ago

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 11y ago
"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 11y ago
  So is NetBSD[0]... exciting times in *BSD-land... [0] http://www.netbsd.org/~rmind/npf/ http://www.netbsd.org/~rmind/npf/
  - feld 11y ago
    npf is not pf, if that's what you're implying (can't tell?)
    - bch 11y ago
      ah no -- I was only talking about multiprocessor-ifying packet management. edit: s/package management/packet management/
      - feld 11y ago
        oh, ok, yes -- this is getting traction in almost every project. It's nice to see this won't be a bottleneck.
slasaus 11y ago
And see this recent patch [1] from an Oracle developer to make PF SMP proof. It's under review. [1] http://marc.info/?t=143526332700004&r=1&w=2 http://marc.info/?t=143526332700004&r=1&w=2