> > "2.b. Almost no STIG environment is purely RHEL. If you create a mongo > tool that only works on RHEL you have no value to the customer who > also supports Solaris, HP/UX, and AIX."
It's RHT's responsibility to ensure availability of tools to support Solaris, HP/UX, and AIX? How? > > "2.c. This seems to be a RH problem as well. Upstart and systemd are > bad ideas for anyone that actually works in an Enterprise, just like > SMF is on Solaris. If you make an interface like chkconfig, awesome! > If you have to change how you do business because some vendor can't > work with a System V standard, well, maybe that vendor needs to be > re-evaulated." RHT is far from the only vendor adopting systemd. A quick search <http://en.wikipedia.org/wiki/Systemd#Adoption> shows several. On Fri, Sep 5, 2014 at 9:18 AM, leam hall <[email protected]> wrote: > Shawn, > > I'd like to respond to several points made in your e-mail. The first, > and most critical, is that one cannot watch "to (sic) much Star Trek". > You should be ashamed of yourself for implying such and I'm sure your > next performance report will reflect these sorts of failures. > > Since we haven't met I'll simply accept your apology and admit that > that part of your e-mail impressed me. Often the ones who can't > apologize are the ones most needing to do so. If your behavior follows > your apology then the world will be a better place. > > Parts of the world, however, are crap. It seems that not enough > decision-making Hatters "get" the "E" in RHEL, especially when it > comes to STIG environments. If that part was graded today it would go > down in flames. > > SSG seems to not get the Unix philosophy of "small tools that do one > thing well". When you had a scanning tool that could take criteria and > identify issues it was awesome. Now it seems to be growing into a > bloated mongo thing that only works with certain versions of certain > products from certain vendors and only ingests certain criteria that > are not related to the criteria actually used by the customer. > > If you want to be successful you need to take a big step back. > > 1. Do not put your idea of "best practices" into the core measurement > criteria. The last time I looked at this: > 1.a. The criteria was not a really good practice. > 1.b. The test flagged the issue as if it were equal to a STIG violation. > 1.c. The test actually wasn't testing what it was said it was. > > STIG environments are accredited by people that seldom have a deep > knowledge of all technical areas. The STIG is the measurement, not > what you think things should be like. Separate your opinions from > actual criteria. Test against documented criteria. > > 2. Include active OS versions in the tools. > 2.a. Few STIG environments are running nothing but RHEL 6 yet. If you > don't deal with RHEL 5 your product is useless to your paying > customers. > 2.b. Almost no STIG environment is purely RHEL. If you create a mongo > tool that only works on RHEL you have no value to the customer who > also supports Solaris, HP/UX, and AIX. > 2.c. This seems to be a RH problem as well. Upstart and systemd are > bad ideas for anyone that actually works in an Enterprise, just like > SMF is on Solaris. If you make an interface like chkconfig, awesome! > If you have to change how you do business because some vendor can't > work with a System V standard, well, maybe that vendor needs to be > re-evaulated. > > > I firmly believe RH has the intellects and capabilities to change the > Enterprise world for the better. The behavior I'm seeing says they > just don't have the desire to be any more than a new flavor of has > been ideas like forking, control by lock in, and exclusion. > > Leam > > -- > Mind on a Mission > -- > SCAP Security Guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/ > -- David Smith Sr. Information Security Engineer Secure Innovations, LLC
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
