The article has not, then, done its job of conveying to you the important differences between the old and the new systems, such as

* the change from data structures and algorithms that are O(N) with respect to the number of individual rules to ones that are O(log N)

* elimination of a gross race condition where multiple concurrent ruleset updates by different subsystems (as can happen at, say, system bootstrap) can end up with updates simply getting silently lost

This is not user interface changes. This is actual difference in fundamental design and implementation.

It would be interesting to see a comparison of the nftables instruction set with other related instruction sets. It would be interesting to see how close it is to RISC, whether it includes things like branch registers or multiple width registers, if there is lowering to native machine code (and where that is), and what it does and does not take from real processor ISAs including VLIW ones.

You shouldn't need to retcon an entire stack just because the implementation behind some things weren't optimal. Why could this not have been done under IPTables while maintaining compatibility with the old, already known, command/rule set?

> 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.

I strongly dislike tools like ufw. Whenever I've had to troubleshoot a firewall generated by tools like it, the task is made more difficult by the extraneous rules created by them. I haven't actually used ufw, but reading the docs makes it seem more complicated than most such tools.

I would much rather the core management tools become better, rather than more ancillary scripts and generators get stacked up on top; nft seems to be solving it at the right level of abstraction. It is managing a very complex creature (the filtering capabilities of the Linux kernel), so it's representing very complex ideas, but building a basic firewall, or reading the rule set for a basic firewall, is not difficult (in this, or in iptables, though I can see how iptables can seem complicated, if you haven't used it a lot). But, this is definitely more readable for big rule sets than iptables.

So...I think this is focused on an easier user interface, in addition to solving a number of technical problems with iptables and paying off some of the technical debt of firewalls in Linux.