Precisely my point. Compatibility modes often are incomplete, unfaithful, and unreliable. I am not singing the praises of any new fundamental change in a basic kernel utility/configuration entity that has been integrated into many application and configuration packages/environments/situations . However, if the change is forced upon the community, then developers either must maintain two (or more) fundamentally incompatible versions (e.g., native STL and the rest for an ANSI open systems environment and MFC for a proprietary monopoly environment), or select one and let those lacking the environment to find another solution (e.g., VirtualBox to run native MS Windows as a guest/application to run a monopoly only application or environment under a Linux host). Admittedly, the change coming to the linux kernel (unless the change is abandoned) is not as drastic as having to use the monopoly MFC, but it certainly could prove to be highly inconvenient.

My timeline question was less directed towards application end user environments such as KDE or Gnome, but more towards actual fundamental kernel or Xwindows internals and the APIs required to use these fundamentals. Does anyone have an average time interval from history when a major change was declared stable production in the fundamental internals and then actually appeared in RHEL production (as it appears RHEL is no longer taboo)? It is Red Hat that determines this timeline, not the clone distributions such as SL or CentOS.

Yasha Karant

On 10/21/2013 03:53 PM, Nico Kadel-Garcia wrote:
 > If one takes the time to read up on NFTables (e.g. the articles
previously linked), they would find that there is an iptables
compatibility layer under development alongside this new project.

I hear there's plans at NASA for a manned return to the moon, too. Don't
hold your breath.

"Under development" by the core authors of nftables itself does not mean
they know the iptables configuration tools well enough to write such a
layer to work across the broad variety of RPM based and configuration
tool managed oddities. Even the "system-config-security" tool is
seriously awkward and underpowered for any complex iptables
configurations. I'll be pleased, and surprised, if their nftables
compatibility toolkit tool can manage even the well documented
configurations and layout of system-config-security.

Reply via email to