Did I miss a sarcasm flag somewhere?
>"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.
That may well be the point
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.
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]
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.
A television Tax.
OSX is Unix (TM).
iOS is a Unix derivative.
No, but really. OSX is Unix.
then what's this : http://books.slashdot.org/story/11/11/30/2216218/book-review-the-cert-oracle-secure-coding-standard-for-java
Reads like an article to me.
There is no such thing as a "one-time issue" with RHEL.
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.
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.
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.
Cray linux, which as I understand is a derivative of SuSE
Without Red Hat there would be no CentOS, and even with Red Hat doing the lions share of the work, the CentOS folks have a hell of a time getting updates, patches, security fixes out.
this is my first post