> You shouldn't need to retcon an entire stack just because the implementation behind some things weren't optimal. Apparently, you should. This is what the des

> You shouldn't need to retcon an entire stack just because the implementation behind some things weren't optimal. Apparently, you should. This is what the designers of iptables considered, and did -- because, you know, they also implemented nftables. I'm sure you are capable of lecturing them on the right way to do it, however. > Why could this not have been done under IPTables while maintaining compatibility with the old, already known, command/rule set? You should re-read the article. Almost every change adds up to a completely different UI in the aggregate. E.g. nftables supports concepts like maps and sets, things like rule deletion becomes simpler for users, you can have multiple actions in rules, the kernel/userland interface is different (which fundamentally will change how applications use it), and you have features like rule monitoring. Why would you go through the effort of retrofitting this stuff onto iptables UI? If anything it just adds tons of complexity to the iptables userland implementation, which really isn't necessary at all. There's a fairly reasonable argument to both not rock the iptables boat too much (it's stable and well tested), and that abandoning its interface for something more powerful and coherent, a clean slate, is the right way forward. Furthermore, why would you do this retrofit nonsense when iptables still exists? They're different stacks. If you don't want to use nftables, iptables will still exist for a long time. It isn't going anywhere, and its deficiencies are well known and understood. That's its own advantage, in its own right.