Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Comment Re:Update & security responsiveness (Score 4, Informative) 666

Before I came to Red Hat I had a similar opinion. When I worked in Silicon Valley I thought "Why would anyone want to pay for Red Hat, I can't afford it so that means it's expensive." However after being at Red Hat for over a year my opinion has changed, and that has been because of some things I have witnessed.

Support is one of the first things people think about, however there is a little more than meets the eye here. Let's start with the packages. Let's say there's a major exploit in SSHd, you will likely see a fix from Red Hat within a few days, which will then be available via RHN. The source to the rpm will also be available at ftp.redhat.com due to the GPL obligations. (More on the GPL and RH later.) At this point in time RH customers have the patch available, in this fictitious scenario let's say it took RH 3 days to release the patch from time of exploit publication. CentOS users still don't have the fix, plus CentOS operates somewhat as a "Black Box." You will get the fix when they get around to it, let's say that takes two weeks before it's released (Could be more could be less). That means your systems are vulnerable for about two weeks, in some shops that's an acceptable risk, in other places it's not.
* Support from people is the other thing that people think about. Have you ever had to call RH support? If yes have you ever talked with an idiot? In the many times I have called RH support I have not dealt with anyone who I felt was sub-standard. Most often the problem I have seen is when the clients I'm working with do not present RH support with the information required in a timely manner. When the answers come back they often link to other knowledge base articles and have clear steps to either solve the problem or to better understand some of the complexities. When a solution is found and there is not a KBase article I understand (I may have heard wrong here) that there is an obligation to write a KBase article. I know that tickets are reviewed after they are closed. One ticket I opened regarding Satellite for a customer is getting discussion amongst the Satellite developers about how to best handle the same scenario in the future.
* Support from Articles, this I feel is a real hidden Gem of RH. Nobody knows about it until you have a subscription, and then everyone is so used to using Google for their answers they forget to start here first. The KBase articles from RH are phenomenal! I had a customer ask me how to rebuild the RH ISO image to include their own KS script. I could Google and find 10 articles talking about much of what I'm looking for or search the KBase and find one article that has every step needed for modifying a RHEL disk to have the KS script on the disk.
* Training. Having been through a few RH training classes I can say they are all very good. Yes there are some areas where I have questioned the need to know some things, but that is normal, but I'm never left feeling like the class was a waste. I have always walked out having learned many things which I can use later.
* Consulting. Yes there are many open source consultants who can come onsite and help implement a solution or fix something, however how many of them have access to the people who wrote the Distro or maintain the upstream project? RH has an internal list just for technical questions, many of the engineers are on this list and very technical answers are delieverd. Often SAs (Solutions Architects) and Consultants will post questions their clients have asked. I have yet to see a response of "Why would you want to do that?" or "RTFM."
* Additional products. Red Hat takes upstream projects and repackages them to integrate tightly with RH. Satellite is one example, it comes from Spacewalk and is designed to help keep internal systems up to date and patched according to their channel assignment. Could you use Spacewalk to manage your CentOS machines, yes you can! However let's say you have a problem getting Spacewlak to work right, or there's a bug, what kind of support is available? Only the community, which means you are at the mercy of someone taking your issue and championing it so that it's fixed, or you take the time to learn the code and fix it.

CentOS *can* work. However when you need support or you find a major issue is when the luster of CentOS may fade. Also what happens when CentOS implodes again? Is your infrastructure worth that risk? For some environments that is acceptable, and only you know that answer for your environment. Also does your environment have to deal with compliance issues? Will CentOS meet those compliance issues in terms of auditing and support?

There's a lot more than meets the eye in the enterprise setting. If you haven't already, reach out to your SA. They are the technical people who are there to understand your needs and how RH can help fulfill those needs. In the end your CIO may feel that the above risks are acceptable, the only question then is would the stinky stuff flow downhill when that decision goes sideways and fall back on your head?

Comment Re:This is (Score 1) 167

>His job is to maximize shareholder value. If that means settling for a lower price than the cost of pursuing a court case, that is what he is going to do.

f I had the points I'd mod your post up. :-)

You actually understand what is going on better than most people responding to this thread. It comes down to simple economics. If you can pay someone to shut up (and perhaps get a license for Open Source in general) for a fraction of what it would cost to have your legal team peruse it then it makes more sense to pay them the hush money than waste your legal team's efforts. In addition if you loose on a small fry the potential ramifications are huge as they ripple through the rest of of the patent system, which in part is built upon previous cases. Rather it makes much more sense to be strategic in dealing with those who are trolling.

Comment Re:Folding + Wiki might get you closer (Score 1) 401

Does this folding tool allow for the reuse of common sub-steps? e.g. (using the example in the summary) many tasks might require the knowledge of how to find "valid traffic", but if the steps change, will every one of the super-tasks need to be updated to show this? This alone has kept me from providing embedded sub-task level documentation details many times.

Good question. As far as I know the plugin I'm thinking of you would have to update each page if the low level information changes. However if you use macro inclusions I believe that is possible.

Thinking further on that, you could create a wiki page for each subgroup, which then includes each sub information. There is the potential for a closed loop recursion happening which is a bad thing (tm).

Comment Folding + Wiki might get you closer (Score 5, Informative) 401

I was reading through some of the Trac hacks for the wiki component and they had a folding plugin. If you create a table of steps you could then create a "fold" with greater detail should someone want to open it up and see it. The nice thing is you are not taken to a new page and you can continue to work and read the page you are already on. You can also imbed folds which can also allow a user to drill down to as much or as little detail as is needed or available.

All that is left now is to write enough information for the lowest common denominator.

Software

Submission + - Company Sells Open-Source Software As Its Own (zabbix.com) 4

teknopurge writes: "After using the software for years I was shocked to find that one of my favorite open-source projects, Zabbix, had its code stolen, rebranded and sold for profit as Firescope. Touting thier product as "revolutionary", Firescope has apparently copied the Zabbix repository and themed the interface without adhering to the GPL that Zabbix is distributed with. Is this not the worst fear of every open source project?"

Slashdot Top Deals

Genetics explains why you look like your father, and if you don't, why you should.

Working...