Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Comment: Take advice from Tiemann?? (Score 1) 41

by Stax (#47607097) Attached to: Open Source Pioneer Michael Tiemann On Open Source Business Success

>"Tiemann offers an historical perspective on what makes open source businesses successful, and shares how he dealt with the open source movement's early skeptic"

Cygnus lasted only for 11 years and was not a huge success. We shouldn't take advice from small business owners that didn't do very well. Sure Cygnus survived, but eventually sold out to Red Hat.

Now if you're the guys who originally came up with Android (pre-Google acquisition, as Google didn't create it), I'm listening.

Cygnus developers gave Red Hat talent, insight and control over what was the most important part of the ecosystem for the burgeoning operating system company - the toolchain. GCC was critical in the ability to provide 10 years of API/ABI compatibility and support for enterprise legitimacy.

Without Cygnus, Red Hat Linux would have had a hard time remaking itself into Red Hat Enterprise Linux.

Comment: Security... (Score 1) 116

by Stax (#43285485) Attached to: Ask Slashdot: Do-It-Yourself Security Auditing Tools?

A lot of this conversation has been about remote security scans, but once you find a vulnerability, how do you remediate it? How do you maintain your security posture, and continue auditing your hosts on a regular bases? To what standard?

The National Institute of Standards & Technology provides a lot of help to those attempting to implement security standards.

First is the Security Content Automation Protocol (SCAP) - scap.nist.gov. This defines how you manage, measure and evaluate vulnerabilities.

Second would be SCAP content. You'll note on the NIST SCAP page the word "community" appears 5 times in the first paragraph. That's not on accident. SCAP content is generally community generated, and there are lots of great lists of people working on SCAP content for a variety of operating systems.

Red Hat maintains the gov-sec mailing list and fedora, for example has loads of content available for Red Hat Enterprise Linux based systems.

Our friends at NIST also publish what is called the US Gov't Configuration Baseline (USGCB for short). USGCB content is available in SCAP format for Windows & RHEL. These standards are certainly a good starting point.

If your standards come in the form of a STIG - that content is available as well from the Aqueduct project.

[Disclaimer - I work for Red Hat, I support the US Gov't, and I think making security easier is probably an important thing to do]

Comment: Re: Not a gas-hybrid (Score 1) 222

by Stax (#43139077) Attached to: Ferrari Unveils World's Fastest (and Most Expensive) Hybrid

re-read the parent post. It has nothing to do with actual fuel economy, and everything to do with how govt's define and evaluate average fuel economy. His point is that you need to compare like test results, not disparate standards.

Your personal experience, while representative of your actual gas mileage, represent yet another standard for comparison.

capiche?

Comment: Re:No one-time issue (Score 1) 666

by Stax (#37894044) Attached to: How Can I Justify Using Red Hat When CentOS Exists?

There is no such thing as a "one-time issue" with RHEL.

True.

You have to pay for a yearly minimum support contract, for the right to use software that has their trade marked brand name and logo's embedded.

False.
You are paying for support and updates, access to the KB, the Certifications (Common Criteria, FIPS, etc, etc), reference architectures, etc. NOT for the use of the trademarked brand name / logo's

 

Once that runs out, you should either renew, or remove the offending binaries, documentation and logos off your systems.

False.
Once your subscription runs out, your RHN account will be locked, and you will not be able to get updates, access the KB or enter support tickets.

You do get update binaries in this minimal contract, which is what you really want anyway. Waiting for CentOS to come up with those may be the difference in having your systems compromised or not. There's nothing wrong with CentOS, but it's always behind RHEL, because of the mere concept of it.

True

Only through hard work and perseverance can one truly suffer.

Working...