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.