Stability is indeed important to enterprise users and admins. Important to non enterprise users and admins too.
Because the requirements of LSB include SysV init scripts and RPM packaging, I always thought LSB should be renamed to RSB: Red Hat Standards Base. I'm not trying to be funny or cute, just straightforward.
LSB is an illusion. Something designed to get people to ask the wrong questions so nobody has to worry about the right answers. Simple sleight-of-hand to fool less knowledgeable people. Red Hat is first and foremost a business and the people working under that legal fiction are focused on business. That implies intensive marketing. Marketing, by nature in the modern world, involves deception and sleight-of-hand. People behind LSB are acting like peacocks to show the colors of their feathers during courtship.
Dietrich Schmitz's claim that Red Hat's adherence to the Linux Standards Base (LSB) guarantees stability and reduces costs in the enterprise is horrible logic. LSB provides no provisions for stability and reducing costs. No standard, real or illusionary, provides such provisions. Standards provide common mechanisms and methods.
That Red Hat Enterprise is stable is a testament to vigorous quality control and has nothing to do with LSB.
If a primary criterion of enterprise usage is LSB, then Red Hat will always satisfy those requirements. Yet if one realizes that LSB is a proverbial red herring, then that criterion disappears like the dew on a hot sunny morning.
I won't deny that Red Hat influences enterprise usage of free/libre software. I don't know whether that is "good" or "bad." Just is. Decisions made in the enterprise tend to influence other areas of usage. The trickle-down effect. The solution then is for people to become better informed not to be fooled by marketing sleight-of-hand.
Regarding Red Hat stability, I believe Caitlyn is correct. Ignoring the bleeding edge, half insane Fedora, I believe the standard Red Hat Enterprise release is indeed stable. Other than security patches I believe most software in the enterprise version is not changed willy-nilly every month or even every year. Eventually that means using software that is several years old, but the Debian folks have done well with a similar model. Bleeding edge is not the name of the game with Red Hat Enterprise (or Debian).
The allegation Caitlyn made against SUSE Enterprise does not hold against Slackware (and Caitlyn made no such connection or allegation against Slackware). The only changes made in an official Slackware release are security patches. If viewed only from that limited perspective, Slackware qualifies as stable.
Is stability important in Slackware? (Caitlyn and Dietrich never argued as much.) Pat indicated that stability is important based upon his public request for opinions about which kernel version to use for the next official release. The long standing practice of issuing only security patches and not sneaking in general package updates further testifies to a goal toward stability.
One thing I detest with the free/libre software model is updating software for the sake of updating. Yesterday I was smacked by this
madness with Firefox. This insane attitude is the equivalent of shooting oneself in the foot. In that respect, the term stability means a lot to all users. Design models should not change simply for the sake of change. (I'm still pissed about that change in Firefox, hence my long venting in this response.
)
Are various tools such as PAM, SELinux or AppArmor important? I don't know. I'm not an enterprise admin and I am not well versed in that area. Yet I've used computers for more than three decades. A simple question is why are those tools considered important? What value do they add that the foundational design of 'nix systems do not provide? What criteria are used to establish that perceived value?
Another question is how many layers of security are deemed necessary? Like many areas of life, security concerns must face a point of diminishing returns. How many locks do I install on my house doors before I realize they are useless against the simple act of breaking a window and climbing through?
Is Slackware LSB compliant? Does any informed user really care? Especially since informed users realize that LSB is designed to benefit Red Hat and nobody else?
Slackware is different. Most users prefer not to have package dependency resolution, prefer the simpler packaging method, prefer BSD style init scripts. As long as that continues, Slackware will always be an "outsider" with respect to LSB and Red Hat. Yet by the same definitions and presumptions used in LSB, Debian also will always be an outsider.
That pretty much has always been the story in Linux based systems. That is, there are only three foundational operating systems: Slackware, Debian, and Red Hat. Almost everything else is a derivative. As long as those three foundations continue to be different in fundamental design choices, there never will be any adoption of LSB as currently defined.
Is that "good" or "bad"? I don't know and I don't care. In an enterprise environment I understand and appreciate the desire for some standards. The critical point is which standards? Analogies always break at some point, but this is somewhat like metric versus other measurement systems. There is no "right" or "wrong" system. There is only the criterion of which system works for certain people in certain applications.
LSB works for Red Hat because LSB was written primarily by Red Hat people. Red Hat will always be LSB compliant, which from a marketing perspective tends to sound impressive when selling systems to less knowledgeable customers. Yet Slackware and Debian providers could use similar tactics.
Standards have a role in human life but only when those definitions satisfy the needs and wants of many people. LSB does not qualify as a standard because only Red Hat people find the definitions palatable. Remember that the people working under the legal fiction of Canonical, another free/libre software business, long ago pissed in the Red Hat garden and are doing quit well without the market-speak otherwise known as LSB.
Conversely, the Canonical people shoot themselves in the foot by playing the bleeding edge game and offering ridiculously short life cycles for releases. In that respect Caitlyn's observations are correct.
Caitlyn's comment that LSB packaging requirements go a long way to ensure application compatibility is a proverbial two-edged sword. Compatible for whom? For other Red Hat derivative systems? Yes, packaging in such a manner offers high compatibility. The other edge of the sword blade is a common packaging format will never guarantee full compatibility with non Red Hat systems because of underlying differences in system design. Red Hat folks have strived for several years to change the underlying file system hierarchy. Package compatibility is meaningless to anybody using a system that does not use the same file system hierarchy as Red Hat systems.
Should all enterprise distros follow standards? As LSB is an illusion, then which standards should be followed? Most distro maintainers follow the traditional 'nix file system hierarchy, but the Red Hat folks do not.
From my corner of the world I notice that in the past Red Hat people were content to be Red Hat. Now there are employees working for Red Hat who have embraced an attitude that they should rule the world. They might succeed to some degree but the anarchist nature (anarchy: without rulers) of free/libre software means they never will prevail to the degree they envision. They might dominate certain aspects of free/libre software but they never will rule all.
There is danger with that attitude: revolt. Should they continue their naive insistence of "enforcing" various features and tools, other distro leaders could and might well band together in a revolt that will not reflect well on Red Hat. The great thing about anarchy is bloody revolution is unnecessary. Folks just shrug, move on, and do their own thing. All peacefully. The folks at Red Hat pushing these agendas should learn from Voltaire's Candide: they should tend their own garden and leave others to do likewise.
At one time people were told they could choose any color they wanted for a car as long as they chose black. Those days are long gone. Likewise for operating systems. Hopefully one day the Red Hat people look in the mirror and pause for serious reflection.