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