3 ms·

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 struc

by JdeBP 10y ago

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.

gravypod 10y ago
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?
- aseipp 10y ago
  > 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.

by JdeBP 10y ago

gravypod 10y ago

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?

aseipp 10y ago
> 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.