Howdy, It's been said that this question get's asked at least once a day. Well, here's the daily question, but with the reason's I'm asking it.
When is the web page going to be updated? From the sounds of the standard reply, it sounds like it isn't going to be updated for at least 3 more weeks.
You know what, that's not good enough. I don't even care if the web page is updated saying it isn't going to be updated for 3 weeks, there has to be something.
Why? Because the ending of the errata for the RedHat 7.3 release is comming closer, really close actually. My management wants to know what we're going to do about it. Buying the Enterprise stuff is not an option. We were just starting work on alternatives when the RHL web page went up. All our work stopped and we started shifting over to maybe working with the RedHat community. But ... well as everyone knows, that got pulled out. A mailling list is not a community. My management is not going to accept my answer that 'I read it from some redhat guy on the mailling list' they want to see it on a web page. A policy isn't a policy if it's only on some mailling list. (I know that isn't entirely true, but think of it from managements perspective) So, we have basically turned and are looking for different alternatives again. That includes different distributions. That's not a threat, it's just something we have to look at because RedHat is no longer (at least in appearance) giving us what we need.
So ... I've aired my grievance ... I feel a bit better, but I would still like the question answered because I keep getting asked the same question over and over.
Thanks Troy Dawson
On Tue, 2003-08-26 at 10:44, Troy Dawson wrote:
Because the ending of the errata for the RedHat 7.3 release is comming closer, really close actually. My management wants to know what we're going to do about it. Buying the Enterprise stuff is not an option.
Out of curiousity, why is the Enterprise stuff not an option for Fermilab?
~spot
Tom "spot" Callaway wrote:
Out of curiousity, why is the Enterprise stuff not an option for Fermilab?
Based on their stats, (http://www-oss.fnal.gov/projects/fermilinux/common/stats/index.html) it looks like they would end up with a pretty hefty bill with 2435 installs out there. I'm guessing that isn't counting the compute cluster stations too, but I could be wrong.
Peace.
john
On Tue, 2003-08-26 at 12:48, John Beimler wrote:
Based on their stats, (http://www-oss.fnal.gov/projects/fermilinux/common/stats/index.html) it looks like they would end up with a pretty hefty bill with 2435 installs out there. I'm guessing that isn't counting the compute cluster stations too, but I could be wrong.
Yes, but if they're assuming that they wouldn't get a nice bit of volume discount for 2435 instances of RHEL, then they're wrong. :)
~spot
Le mar 26/08/2003 à 20:05, Tom "spot" Callaway a écrit :
On Tue, 2003-08-26 at 12:48, John Beimler wrote:
Based on their stats, (http://www-oss.fnal.gov/projects/fermilinux/common/stats/index.html) it looks like they would end up with a pretty hefty bill with 2435 installs out there. I'm guessing that isn't counting the compute cluster stations too, but I could be wrong.
Yes, but if they're assuming that they wouldn't get a nice bit of volume discount for 2435 instances of RHEL, then they're wrong. :)
No RHLP website, very poor communication (when come beta2 ? Oct 18?), you are now promoting RHLE.... If i believe i RHLP, am i wrong ?
More seriously, pay more attention about recurrent claims.
~spot
On Tuesday, August 26, 2003, at 02:05 PM, Tom "spot" Callaway wrote:
Yes, but if they're assuming that they wouldn't get a nice bit of volume discount for 2435 instances of RHEL, then they're wrong. :)
Even if it were $100 per box, that is $243,500. Not a small chunk of change. They could save a quarter million by going with a Free Beer distro.
The point he raised was dodged, though. And it was a good one. RHAT made announcements and such that are, to date, coming up short in the action department. A lot of people are in a holding pattern right now trying to decide whether to contribute to the RHL project or to spend their time elsewhere.
--
C. Magnus Hedemark http://trilug.org/~chrish "The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not." - Mark Twain
While it's true they have fallen down a bit on this, and it certainly doesn't look good, I'll defend RedHat a bit, here.
If I understand correctly, RHAS 2.1 is made of of completely open source software, with the exception of the Sun (and IBM?) Java runtime. RHAS 3.0, as I understand it, is not shipping with a Java VM and I have not heard of any new proprietary stuff being included. i.e. I think the RHEL 3.0 line will be 100% Open Source.
This tells me two things:
1. RedHat is one hell of a great Open Source company and truly believes in Open Source.
2. RHLP is vitally important to the future of the RHEL line.
I understand, and even share, the concerns that people have expressed. And RedHat does need to act soon. But I still have (almost) complete confidence that things will come together.
They probably should have waited until just after the release of RH10 to make the announcement. Announcing the RHLP right at the same time as they are coming out with a beta1 was, to say the least, an awkward move.
It may well be that someone at RedHat was *too* excited about the RHLP.
On Tue, 2003-08-26 at 14:28, Magnus wrote:
The point he raised was dodged, though. And it was a good one. RHAT made announcements and such that are, to date, coming up short in the action department. A lot of people are in a holding pattern right now trying to decide whether to contribute to the RHL project or to spend their time elsewhere.
On Tuesday, August 26, 2003, at 04:40 PM, Steve Bergman wrote:
This tells me two things:
- RedHat is one hell of a great Open Source company and truly believes
in Open Source.
I believe this is true as well. With the caveat that the licensing of RHEL is ambiguous (I mean, is it GPL, or isn't it? Will I get sued for putting RHEL 2.1 ISO's on my web site? Handing them out to people?) But their commitment to GPL'ing all of their work is admirable and sets them apart in my mind from competitors like SuSE.
- RHLP is vitally important to the future of the RHEL line.
Yes. Which is why the concerns expressed here need to be repeated daily until someone from RH takes them seriously.
It may well be that someone at RedHat was *too* excited about the RHLP.
I think perhaps that more preparation should have gone into the announcement. Much of the web content or at least the framework should have been in place at the time of the announcement. But the time for that is behind us. The best thing that can be done now is to address those concerns expediently.
--
C. Magnus Hedemark http://trilug.org/~chrish "The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not." - Mark Twain
On Tue, 2003-08-26 at 22:02, Magnus wrote:
On Tuesday, August 26, 2003, at 04:40 PM, Steve Bergman wrote:
This tells me two things:
- RedHat is one hell of a great Open Source company and truly believes
in Open Source.
I believe this is true as well. With the caveat that the licensing of RHEL is ambiguous (I mean, is it GPL, or isn't it? Will I get sued for putting RHEL 2.1 ISO's on my web site? Handing them out to people?)
If by RHEL you mean RHAS (which I believe you do): RHEL contains NON-REDHAT-SOFTWARE that you must have a license for. RH makes the SRPMS for RHAS w/o that software. Not all things in RH are GPL, but are still OSS.
The other part of RHEL is the support contract. So from what I see, yes what you are proposing above would get you in trouble. If you pull out the above mentioned software you are essentially left with a different version of RHL. Follow the noted trademark rules, and you should be just fine. However, making an ISO of a binary RHAS distribution and then distributing to others is wrong, due to the trademark[1] and additional software included.
IMO, but I do believe it is quite correct.
Bill
[1] Yes, I know that non-profit and LUGs have greater permissions here, but that wasn't exactly specified
On Tue, 2003-08-26 at 10:44, Troy Dawson wrote:
Buying the Enterprise stuff is not an option.
I guess this is as good a place as any to ask this question.
RHEL comes, necessarily, with a support agreement. The support agreement is good for 1 machine. That much is clear.
But what if you buy, say, 1 copy for every 10 machines and designate ahead of time which machines get the support contracts, and which are unsupported. Is this legit?
Also, is it then legit to download security patches from RHN and install them on all the machines?
I have always been a bit unclear on these points.
Thanks, Steve
On Tue, Aug 26, 2003 at 03:49:58PM -0500, Steve Bergman wrote:
On Tue, 2003-08-26 at 10:44, Troy Dawson wrote:
Buying the Enterprise stuff is not an option.
I guess this is as good a place as any to ask this question.
RHEL comes, necessarily, with a support agreement. The support agreement is good for 1 machine. That much is clear.
But what if you buy, say, 1 copy for every 10 machines and designate ahead of time which machines get the support contracts, and which are unsupported. Is this legit?
The licensing for the next release of RHEL isn't set in stone yet, so I'll answer respective to the RHEL 2.1 license. Under that license, you would need a license for every machine that you have RHEL installed on. So, no, you wouldn't be able to purchase one copy ofr every 10 machines.
Also, is it then legit to download security patches from RHN and install them on all the machines?
Here's one I can answer a lot better. All of the code which makes up the core of RHEL is licensed under the GPL (and other similar licenses.) Therefore, you can indeed download the security errata from RHN, then push it out to any machines that you would like.
- jkt
So, the restriction is possible because we are talking about the binary distribution. There is nothing to keep someone from creating RPM's from the SRPM's on a single RHEL box, and making a set of install ISO's. Except that the result:
1. Would not necessarily be exactly the well tested product that RedHat offers, since different compilers and compiler options may have been used for particular packages.
2. Would not have a support contract associated with it.
Consequently, all of the added value that RedHat provides would be lost, and the RHLP distro would still be the one with all the "cool" new stuff.
Except for the long term availability of errata... And this is a sore point with me. Why can't I purchase extended errata availability for the non-RHEL RedHat distro? I did ask, once, on the support or sales line, I can't remember which, and was told that it could be bought for *about* 35,000 USD a year, "because we would be doing it just for you". To be honest, it may have been 3,500 USD, but it was a sum that would have had my small clients clamoring for a Windows(tm) "solution".
It seems like there should be a market for errata, which is a service, after all, at a reasonable price, for more than a year.
Let me be clear on this. I think that RedHat has done so many things "right" that it really boggles the mind. What am I missing?
On Tue, 2003-08-26 at 16:59, Jay Turner wrote:
On Tue, Aug 26, 2003 at 03:49:58PM -0500, Steve Bergman wrote:
On Tue, 2003-08-26 at 10:44, Troy Dawson wrote:
Buying the Enterprise stuff is not an option.
I guess this is as good a place as any to ask this question.
RHEL comes, necessarily, with a support agreement. The support agreement is good for 1 machine. That much is clear.
But what if you buy, say, 1 copy for every 10 machines and designate ahead of time which machines get the support contracts, and which are unsupported. Is this legit?
The licensing for the next release of RHEL isn't set in stone yet, so I'll answer respective to the RHEL 2.1 license. Under that license, you would need a license for every machine that you have RHEL installed on. So, no, you wouldn't be able to purchase one copy ofr every 10 machines.
Also, is it then legit to download security patches from RHN and install them on all the machines?
Here's one I can answer a lot better. All of the code which makes up the core of RHEL is licensed under the GPL (and other similar licenses.) Therefore, you can indeed download the security errata from RHN, then push it out to any machines that you would like.
- jkt
Steve Bergman said: [snip]
Except for the long term availability of errata... And this is a sore point with me. Why can't I purchase extended errata availability for the non-RHEL RedHat distro? I did ask, once, on the support or sales line, I can't remember which, and was told that it could be bought for *about* 35,000 USD a year, "because we would be doing it just for you". To be honest, it may have been 3,500 USD, but it was a sum that would have had my small clients clamoring for a Windows(tm) "solution".
It seems like there should be a market for errata, which is a service, after all, at a reasonable price, for more than a year.
There probably is. All the software is Open Source, anyone could provide this support. For example you can a year's support from KRUD linux (Redhat based) for 7.3 at $195 a year (see http://lists.tummy.com/pipermail/krudusers/2002-October/000321.html).
Backporting patches to old versions isn't just plug and play. The point of the Enterprise line is that the versions will change as little as possible, so when Oracle certifies the distro to run their software, it will still run it in two years. Red Hat has made the business decision to not try to keep three or four different trees going so they they can provide Errata for the older RHLP distros. Makes sense to me.
On Tue, Aug 26, 2003 at 06:08:29PM -0500, Steve Bergman wrote:
So, the restriction is possible because we are talking about the binary distribution. There is nothing to keep someone from creating RPM's from the SRPM's on a single RHEL box, and making a set of install ISO's. Except that the result:
- Would not necessarily be exactly the well tested product that RedHat
offers, since different compilers and compiler options may have been used for particular packages.
Actually, it's highly unlikely that the compiler _options_ would be different, since package-specific compiler options are always included in the SRPMs. As far as I know. In that sense there are no "secret ingredients" left out of Red Hat source packages.
On Tue, Aug 26, 2003 at 05:59:59PM -0400, Jay Turner wrote:
Also, is it then legit to download security patches from RHN and install them on all the machines?
Here's one I can answer a lot better. All of the code which makes up the core of RHEL is licensed under the GPL (and other similar licenses.) Therefore, you can indeed download the security errata from RHN, then push it out to any machines that you would like.
Actually, following up on my own post, I need to clarify something. The license for RHEL 2.1 states that if you have support (which includes RHN) for one install, then you will have it for all installations. So, in that case, if you are in compliance, then all of your installations would have RHN support and there would be no need to download the errata from RHN then push it out to other machines. Sorry for the confusion.
- jkt
On Tuesday, August 26, 2003, at 07:17 PM, Jay Turner wrote:
Actually, following up on my own post, I need to clarify something. The license for RHEL 2.1 states that if you have support (which includes RHN) for one install, then you will have it for all installations. So, in that case, if you are in compliance, then all of your installations would have RHN support and there would be no need to download the errata from RHN then push it out to other machines. Sorry for the confusion.
Well, there *is* a need actually.
Let's say Joe has 50 RHEL servers, all pretty much identical, and properly licensed. There is a flurry of security activity one week and it takes about 50MB of new packages to patch one system. That's not much of a reach. Each of the 50 servers downloads 50MB of packages through https (i.e. not cached anywhere) over Joe's single business class DSL connection. 2500MB of downloads, split up across 50 clients, all hitting a DSL connection at once (not to mention the RHN servers). This is lunacy.
Most other distros permit larger installations to have their own local package repositories, and this is what would make the most sense. I understand that Red Hat has a product that will do this, but the cost is far above the means of someone like Joe.
The centralization of RHN is part of the driving force, IMHO, behind projects like Current and Yum. It would be far grander, I think, to have the slick RHN interface on the front end and the local repository on the back end.
So getting back to your example, yes, there is a need for RHEL customers to download one copy of a package and push it out to other machines.
--
C. Magnus Hedemark http://trilug.org/~chrish "The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not." - Mark Twain
On Wed, Aug 27, 2003 at 12:10:21AM -0400, Magnus wrote:
Let's say Joe has 50 RHEL servers, all pretty much identical, and properly licensed. There is a flurry of security activity one week and it takes about 50MB of new packages to patch one system. That's not much of a reach. Each of the 50 servers downloads 50MB of packages through https (i.e. not cached anywhere) over Joe's single business class DSL connection. 2500MB of downloads, split up across 50 clients, all hitting a DSL connection at once (not to mention the RHN servers). This is lunacy.
Edit /etc/sysconfig/rhn/up2date , change
storageDir[comment]=Where to store packages and other data when they are retrieved storageDir=/your_NFS_storage/var/spool/up2date
and
keepAfterInstall[comment]=Keep packages on disk after installation keepAfterInstall=1
There is a risk associated in the sense that there is no synchronization of the downloads, and I don't know what would happen if machine A and machine B try to download the same RPM at the same time, but the worse which can happen is a corrupted package which will be detected by the MD5 checksum check of rpm, will be reported and manual intervention can then clean it up.
Daniel
Daniel Veillard said:
Edit /etc/sysconfig/rhn/up2date , change
storageDir[comment]=Where to store packages and other data when they are retrieved storageDir=/your_NFS_storage/var/spool/up2date
and
keepAfterInstall[comment]=Keep packages on disk after installation keepAfterInstall=1
There is a risk associated in the sense that there is no synchronization of the downloads, and I don't know what would happen if machine A and machine B try to download the same RPM at the same time, but the worse which can happen is a corrupted package which will be detected by the MD5 checksum check of rpm, will be reported and manual intervention can then clean it up.
Daniel
Another option would be to just wget a mirror then use the "-k" option to have up2date copy the files from your mirror. That way if you don't have the file each machine can download it from RH without causing issues.
On Wed, 27 Aug 2003, Magnus wrote:
Let's say Joe has 50 RHEL servers, all pretty much identical, and properly licensed. There is a flurry of security activity one week and it takes about 50MB of new packages to patch one system. That's not much of a reach. Each of the 50 servers downloads 50MB of packages through https (i.e. not cached anywhere) over Joe's single business class DSL connection. 2500MB of downloads, split up across 50 clients, all hitting a DSL connection at once (not to mention the RHN servers). This is lunacy.
This is what the RHN Proxy product was created for.
-- Elliot For peace of mind, resign as general manager of the universe.
On Wednesday, August 27, 2003, at 07:06 AM, Elliot Lee wrote:
This is what the RHN Proxy product was created for.
As I mentioned previously, the cost for this product is unreasonable and the need for it is based on breakage in the design of RHN.
--
C. Magnus Hedemark http://trilug.org/~chrish "The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not." - Mark Twain
Magnus said:
Most other distros permit larger installations to have their own local package repositories, and this is what would make the most sense. I understand that Red Hat has a product that will do this, but the cost is far above the means of someone like Joe.
In addition to the two ways already mentioned, you have both the "Current" project, and "nrh-up2date" which act as up2date servers. There are a number of other scripts to download and apply updates from a local mirror of RPMs (search Freshmeat).
For the RHLP, yum is in Rawhide...
On Wednesday, August 27, 2003, at 08:30 AM, William Hooper wrote:
In addition to the two ways already mentioned, you have both the "Current" project, and "nrh-up2date" which act as up2date servers. There are a number of other scripts to download and apply updates from a local mirror of RPMs (search Freshmeat).
Call me crazy but I want to have my cake and eat it, too.
Ideally one should be able to use the RHN front end interface to tell 50 machines to all grab the same package. Then that package should be fetched from a local repository.
From what I've seen of yum & current so far, it seems like you lose the nice front end interface in order to gain a local repository.
--
C. Magnus Hedemark http://trilug.org/~chrish "The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not." - Mark Twain
On Wed, 27 Aug 2003 13:16:17 -0400, you wrote:
Ideally one should be able to use the RHN front end interface to tell 50 machines to all grab the same package. Then that package should be fetched from a local repository.
From what I've seen of yum & current so far, it seems like you lose the nice front end interface in order to gain a local repository.
the up2date available in rawhide and as an upgrade to severn now supports apt and yum downloads.
Steve Bergman said:
On Tue, 2003-08-26 at 10:44, Troy Dawson wrote:
Buying the Enterprise stuff is not an option.
I guess this is as good a place as any to ask this question.
RHEL comes, necessarily, with a support agreement. The support agreement is good for 1 machine. That much is clear.
But what if you buy, say, 1 copy for every 10 machines and designate ahead of time which machines get the support contracts, and which are unsupported. Is this legit?
You do realize that the license agreement is available to read, right? http://www.redhat.com/licenses/
I think it makes it pretty clear, "If Customer wishes to increase the number of Installed System, then Customer will purchase from Red Hat additional Services for each additional Installed System."
If you are violating the license, you don't get support. If you don't get support one has to wonder why you aren't using RHLP...
On Wed, 2003-08-27 at 05:27, William Hooper wrote:
If you are violating the license, you don't get support. If you don't get support one has to wonder why you aren't using RHLP...
Well, for similar reasons that ISVs like RHEL: less volatility. A stable platform is a boon for sysadmin support, too.
Big enterprises are on the verge (or slightly over the verge) of deploying Linux on the desktop in a big way. The reasons for this are complex, but they simplify down to the fact that the cost savings of doing so are starting to outweigh the costs of the conversion. Part of the calculation is the relative cost of licenses vs Windows. Another part is the cost of support of thousands of Linux desktops vs Windows. With Red Hat's Enterprise strategy, the no-cost license is coupled with the most volatile and least supported alternative. While this is understandable from Red Hat's perspective, it makes it impossible to hit the sweet spot on large scale Linux desktop deployments.
I have one Fortune 1000 client who is wrestling with this issue. They are rolling their own Red Hat based distro, and paying the price of chasing the consumer OS, while looking over their shoulder at the end-of-life dates for 7.x, 8 and 9. They have 1400 desktops rolled out, in a potential market of 16,000.
I think Red Hat should drop license fees for their WS product. The window of opportunity is open for Linux on the desktop, due to the maturation of the technology, Microsoft's gouging on licenses, and the lack of compelling new technology upon which they can piggyback new proprietary lock-in strategies. This window will close as soon as something truly new shows up. Microsoft will implement it stuffed full of barbed hooks. If they still have 95% desktop share at that point, the game will be over, for this round at least.
On 27 Aug 2003, Howard Owen wrote:
On Wed, 2003-08-27 at 05:27, William Hooper wrote:
I think Red Hat should drop license fees for their WS product. The window of opportunity is open for Linux on the desktop, due to the maturation of the technology, Microsoft's gouging on licenses, and the lack of compelling new technology upon which they can piggyback new
Sure and Red Hat can go belly up in 2 years because no-one is paying them for all the work they do.
On Wed, 27 Aug 2003, Stephen Smoogen wrote:
On 27 Aug 2003, Howard Owen wrote:
On Wed, 2003-08-27 at 05:27, William Hooper wrote:
I think Red Hat should drop license fees for their WS product. The window of opportunity is open for Linux on the desktop, due to the maturation of the technology, Microsoft's gouging on licenses, and the lack of compelling new technology upon which they can piggyback new
Sure and Red Hat can go belly up in 2 years because no-one is paying them for all the work they do.
I think people are saying they'd like a third option in between RHLP and RHEL WS, something where the desktop is long-lived (say, three years maintenance) but doesn't have bundled support. Right now, the closest there is to that option is to buy 1 SuSE Professional 8.2 box and deploy it on all desktops (which is actually only guaranteed 2 years maintenance AFAIK, and which sucks in lots of other ways ;-).
Maybe shifting the licensing / "Red Hat getting paid" stuff server-side by selling those customers 100-client proxy servers (or some similar product) would make them happy and still get RHAT revenue.... Or maybe RHAT just can't afford right now to make a product suitable for all customers....
later, chris
On Wed, 27 Aug 2003, Chris Ricker wrote:
On Wed, 27 Aug 2003, Stephen Smoogen wrote:
On 27 Aug 2003, Howard Owen wrote:
On Wed, 2003-08-27 at 05:27, William Hooper wrote:
I think Red Hat should drop license fees for their WS product. The window of opportunity is open for Linux on the desktop, due to the maturation of the technology, Microsoft's gouging on licenses, and the lack of compelling new technology upon which they can piggyback new
Sure and Red Hat can go belly up in 2 years because no-one is paying them for all the work they do.
I think people are saying they'd like a third option in between RHLP and RHEL WS, something where the desktop is long-lived (say, three years maintenance) but doesn't have bundled support. Right now, the closest there
I think that is the $179 version of the WS. It is 179/year... and could probably go down in large orders. So a complete cost would be $537 for 3 years support. Having done a lots of internal maintenance for older servers here... the cost per server seemed pretty good.
Chris Ricker said:
On Wed, 27 Aug 2003, Stephen Smoogen wrote:
On 27 Aug 2003, Howard Owen wrote:
On Wed, 2003-08-27 at 05:27, William Hooper wrote:
First off, please watch quoting. I most certainly didn't say the following lines.
I think Red Hat should drop license fees for their WS product. The window of opportunity is open for Linux on the desktop, due to the maturation of the technology, Microsoft's gouging on licenses, and the lack of compelling new technology upon which they can piggyback new
Sure and Red Hat can go belly up in 2 years because no-one is paying them for all the work they do.
I think people are saying they'd like a third option in between RHLP and RHEL WS, something where the desktop is long-lived (say, three years maintenance) but doesn't have bundled support.
It is my understanding that keeping multiple Errata trees for a long period is the problem that making RHLP a short life cycle product is meant to solve. I imagine that many more dollars go into backporting patches than into answering phones.
On Wed, 2003-08-27 at 18:47, William Hooper wrote:
It is my understanding that keeping multiple Errata trees for a long period is the problem that making RHLP a short life cycle product is meant to solve. I imagine that many more dollars go into backporting patches than into answering phones.
However the costs break out, there's no doubt that Red Hat adds enormous value and deserves to make a nice profit. I also have huge respect for them as the company that has done the most for Free Software, and that includes the company I'm presently employed by, who has been no slouch. My point might be better stated thus: "If you can possibly afford to do it, Red Hat, you might consider offering WS for zero dollars, and without support, just now. The strategic situation is such that a stable, low cost desktop platform upon which large support organizations can build very large scale deployments would do two things. First, it would accelerate adoption of Linux on the corporate desktop, a trend that is real and growing. Second, it would ensure that _your_ platform is the most widely adopted Linux desktop OS. This would of course give you enormous opportunities later, and you wouldn't even have to act like Microsoft to realize them."
And there's the point about the window (heh) of opportunity closing as soon as Microsoft gets around to implementing some new feature that hard-nosed bean counters will grudgingly (after much argument) admit is worth the cost of upgrading to Microsoft's latest trojan horse, er, desktop OS. They are reading the same research reports up there in Redmond. If you think they won't answer the threat to their desktop franchise with the most vicious, focused and effective counter-attack they've ever mounted, well, the world must look nice through those rose tinted glasses.
(That last was a general statement, Mr. Hooper. I have no idea what color your lenses are, or if you have any 8)
There are some flaws in your reasoning.
Howard Owen said: [snip]
My point might be better stated thus: "If you can possibly afford to do it, Red Hat, you might consider offering WS for zero dollars, and without support, just now. The strategic situation is such that a stable, low cost desktop platform upon which large support organizations can build very large scale deployments would do two things.
Most corporations (right or wrong) view no cost as a disadvantage. When asking companies for bids for a contract, it is common practice to throw out the highest and lowest, because the high one is trying to make to much money and the low one is either cutting corners or not understanding the job at hand.
First, it would accelerate adoption of Linux on the corporate desktop, a trend that is real and growing.
Having no support at home isn't that big of a deal. Having no support in a business, with my job on the line if something goes wrong is. There is no way in Hell *I* would do a large scale roll out of an OS without support.
Second, it would ensure that _your_ platform is the most widely adopted Linux desktop OS. This would of course give you enormous opportunities later, and you wouldn't even have to act like Microsoft to realize them."
As above, low cost doesn't mean widely adopted. You will find out in the Linux space, the distro that gets highest regards is the one the person administrating it is familiar with. This can be changed if third party requirements exist (i.e. Oracle certs for the Enterprise line).
On Thu, 2003-08-28 at 15:35, William Hooper wrote:
There are some flaws in your reasoning.
...as well as in yours (and mine)...
Howard Owen said: [snip]
My point might be better stated thus: "If you can possibly afford to do it, Red Hat, you might consider offering WS for zero dollars, and without support, just now. The strategic situation is such that a stable, low cost desktop platform upon which large support organizations can build very large scale deployments would do two things.
Most corporations (right or wrong) view no cost as a disadvantage. When asking companies for bids for a contract, it is common practice to throw out the highest and lowest, because the high one is trying to make to much money and the low one is either cutting corners or not understanding the job at hand.
A bid for contract will include multiple items, including some combination of materials, support, time, and so forth. There may be no material deliverables, but most companies like to get something tangible. This could be a turn-key web/file/fill-in-the-blak server/workstation or a box of software or whatever. In any event, no bid is free, though it may have some items thrown in at no cost or lumped together in one price bucket.
Pointedly, I have never seen a COO or CTO throw out a low bid based on price alone. Competent managers generally include metrics in the RFP/RFO/RFQ that can be used to qualify bids, and these metrics may even be slanted so that the COO's preferred bidder has the best shot all the while appearing and possibly even being reasonably objective. This tactic effectively transfers the burden of success (i.e., selection) to the bidders. This is just business and has no special bearing on software that it doesn't have on any other aspect of the business.
First, it would accelerate adoption of Linux on the corporate desktop, a trend that is real and growing.
Having no support at home isn't that big of a deal. Having no support in a business, with my job on the line if something goes wrong is. There is no way in Hell *I* would do a large scale roll out of an OS without support.
In many companies the IS/IT/DP department _is_ the support. These companies typically pay for a certain amount of training and expect their technical staff to fill in the blanks. Other companies don't have in-house expertise and elect to pay somebody local for "normal" support. Still others use a combination of the two. After all, there will always be somebody smarter, more experienced, luckier, happier, better golf player, etc., and that's where paid outside support comes in: it's simply an avenue for escalating support knowledge.
In other words, everybody pays for support. The question is, "who gets what percentage of the pay?" If in-house technical staff is not capable of accomplishing a large OS rollout on its own, it needs to outsource this support to the software vendor or local tech service. This is what the market generally sorts out on a macroscopic level, for better or worse. Everybody likes choice. You may choose to pay the vendor; others, the local person(s).
Many successful vendors get successful by appearing to offer multiple choices, each of which leads back to the vendor. Microsoft sells TechNet and MSDN and certifications, all good choices which fill the M$ coffers. Red Hat has its own excellent training programs, which further its long-term success.
Second, it would ensure that _your_ platform is the most widely adopted Linux desktop OS. This would of course give you enormous opportunities later, and you wouldn't even have to act like Microsoft to realize them."
As above, low cost doesn't mean widely adopted.
Yet low cost is a significant factor in widespread adoption. Risk usually translates in the minds of decision-makers (where a decision-maker is the person whose management bonus depends on the perceived "right" decision) into high cost, so the two go hand-in-hand. Low cost means that more risk is acceptable to the business side of the company (I'm sorry, I meant "to the manager's bonus prospects").
You will find out in the Linux space, the distro that gets highest regards is the one the person administrating it is familiar with. This can be changed if third party requirements exist (i.e. Oracle certs for the Enterprise line).
A more correct statement might be that distro's are regarded based on the company they keep. A distro that is certified by Oracle, as you point out, is much more acceptable to a company that needs Oracle. A company using DB2 will look more favorably on a distro that is favored by IBM (meaning that the IBM sales partner can make money, too). If a distro appears in the Wall Street Journal, it gains (or loses depending on the article) respect instantly. Likewise, if a friend of the CTO/COO mentions a particular distro in idle conversation, the same effect takes place. This is somewhat more significant than anything the sysadmin says.
William Hooper wrote:
There are some flaws in your reasoning.
Howard Owen said: [snip]
My point might be better stated thus: "If you can possibly afford to do it, Red Hat, you might consider offering WS for zero dollars, and without support, just now. The strategic situation is such that a stable, low cost desktop platform upon which large support organizations can build very large scale deployments would do two things.
Most corporations (right or wrong) view no cost as a disadvantage. When asking companies for bids for a contract, it is common practice to throw out the highest and lowest, because the high one is trying to make to much money and the low one is either cutting corners or not understanding the job at hand.
Well, where I'm working now, they have rolled out their own desktop Linux to 1400 customers. The total desktop pool is 16,000.They are currently based on RHL 7.3. The systems they are replacing are Sparc workstations, and the cost of hardware and software is the definitive reason. They pay nothing for the bits that come from Red Hat, but they put quite a bit of time into doing their own engineering on top of that. They also hire my employer to help them out with the tougher problems.
So the cost of the bits is not the biggest concern to them, but it is a factor. They have considered and rejected rolling out WS because of the cost. They are worried about how errata will work after 7.3, and 8 and 9+ are no longer supported. They will surely have to pay more to continue supporting their desktop Linux. How this will balance out with a switch to WS, I don't know. But they have rejected the alternative thus far, as I said.
The point is, the additional cost WILL affect the rate at which Linux is adopted here.
First, it would accelerate adoption of Linux on the corporate desktop, a trend that is real and growing.
Having no support at home isn't that big of a deal. Having no support in a business, with my job on the line if something goes wrong is. There is no way in Hell *I* would do a large scale roll out of an OS without support.
Second, it would ensure that _your_ platform is the most widely adopted Linux desktop OS. This would of course give you enormous opportunities later, and you wouldn't even have to act like Microsoft to realize them."
As above, low cost doesn't mean widely adopted. You will find out in the Linux space, the distro that gets highest regards is the one the person administrating it is familiar with. This can be changed if third party requirements exist (i.e. Oracle certs for the Enterprise line).
The switch to Linux on the desktop in corporations is absolutely about cost relative to Microsoft. To the extent that the cost of bits affects the overall cost, it will be a factor.
The real money is in the support. I predict that sales of WS will not amount to much. Give it away and win a few big support contracts with the penetration that gives you.
Howard Owen said:
Well, where I'm working now, they have rolled out their own desktop Linux to 1400 customers. The total desktop pool is 16,000.
I would guess that 16,000 seats would get you a pretty good volume discount.
They are currently based on RHL 7.3. The systems they are replacing are Sparc workstations, and the cost of hardware and software is the definitive reason. They pay nothing for the bits that come from Red Hat, but they put quite a bit of time into doing their own engineering on top of that. They also hire my employer to help them out with the tougher problems.
So the cost of the bits is not the biggest concern to them, but it is a factor. They have considered and rejected rolling out WS because of the cost. They are worried about how errata will work after 7.3, and 8 and 9+ are no longer supported. They will surely have to pay more to continue supporting their desktop Linux. How this will balance out with a switch to WS, I don't know. But they have rejected the alternative thus far, as I said.
So they understand that keeping up with Errata on a distro is time consuming and costly. It doesn't make sense for them to do this on their own, but they think it makes sense for Red Hat to do it and give it to them for free?
The switch to Linux on the desktop in corporations is absolutely about cost relative to Microsoft.
And retraining for existing support staff, re-implementation of in-house apps, finding replacement apps, etc. At the point you make a decision to change OSes, the cost of the OS is not a large percentage of the cost.
To the extent that the cost of bits affects the overall cost, it will be a factor.
Exactly. That factor isn't generally that much.
The real money is in the support.
I think you underestimate the development costs of backporting and verifying security patches.
I predict that sales of WS will not amount to much. Give it away and win a few big support contracts with the penetration that gives you.
WS *is* support. If you didn't care about support, buy one copy of WS, rip out any non-distributable bits (for example Red Hat trademarks), recompile the SRPM errata's available from http://ftp.redhat.com/pub/redhat/linux/enterprise/ every time a new one is released. When something breaks you get to keep all the pieces.
I have Red Hat 9 Does any one know why I can´t use dot (colon) in user names. In Red Hat 8 it works ok. Can I change it. It happend when I try to add a user adduser username.lastname.
On Thu, Aug 28, 2003 at 07:13:03PM -0400, Felix wrote:
I have Red Hat 9 Does any one know why I can´t use dot (colon) in user names. In Red Hat 8 it works ok. Can I change it. It happend when I try to add a user adduser username.lastname.
chown uses . and : to delimit users from groups, so it would be confusing to allow . and : in usernames.
On Thu, 2003-08-28 at 18:09, William Hooper wrote:
Howard Owen said:
So they understand that keeping up with Errata on a distro is time consuming and costly. It doesn't make sense for them to do this on their own, but they think it makes sense for Red Hat to do it and give it to them for free?
It obviously made sense to RedHat when RedHat was a company of ~100 employees. But it does not make sense now that RedHat is a larger company of over 600 employees.
QED
Steve Bergman said:
On Thu, 2003-08-28 at 18:09, William Hooper wrote:
Howard Owen said:
So they understand that keeping up with Errata on a distro is time consuming and costly. It doesn't make sense for them to do this on their own, but they think it makes sense for Red Hat to do it and give it to them for free?
It obviously made sense to RedHat when RedHat was a company of ~100 employees. But it does not make sense now that RedHat is a larger company of over 600 employees.
A lot of things that made sense during the dot-com bubble don't make sense now...
Looks like this is turning into a flame war. I'm not part of Red Hat's decision making process, so I can't help you with what motivates them to do what they do. I was just giving an alternative view to "Red Hat needs to give us no cost software supported forever..."
No, you're right. I shouldn't have said that. I plead a bad hair day and apologize. ;-)
Perhaps RHLP or a related project could pick up for a second year of errata. I suppose testing is harder than the actual back-porting/patching. As has been said, it really is going to take a free (as in beer) desktop alternative with more than 12 months of support to take on Windows on the corporate desktop most effectively.
-Steve
On Thu, 2003-08-28 at 19:43, William Hooper wrote:
Steve Bergman said:
It obviously made sense to RedHat when RedHat was a company of ~100 employees. But it does not make sense now that RedHat is a larger company of over 600 employees.
A lot of things that made sense during the dot-com bubble don't make sense now...
Looks like this is turning into a flame war. I'm not part of Red Hat's decision making process, so I can't help you with what motivates them to do what they do. I was just giving an alternative view to "Red Hat needs to give us no cost software supported forever..."
On Fri, 29 Aug 2003, Steve Bergman wrote:
No, you're right. I shouldn't have said that. I plead a bad hair day and apologize. ;-)
Perhaps RHLP or a related project could pick up for a second year of errata. I suppose testing is harder than the actual back-porting/patching. As has been said, it really is going to take a
Backporting+patching+testing is about a 1 QA+ 1 engineer WEEK per platform per release. Ask the security people who do Debian about how long they would like to support a release before killing it (I think the poll was 2 weeks but they realized it had to be longer.)
On Thu, 2003-08-28 at 17:44, Steve Bergman wrote:
On Thu, 2003-08-28 at 18:09, William Hooper wrote:
Howard Owen said:
So they understand that keeping up with Errata on a distro is time consuming and costly. It doesn't make sense for them to do this on their own, but they think it makes sense for Red Hat to do it and give it to them for free?
It obviously made sense to RedHat when RedHat was a company of ~100 employees. But it does not make sense now that RedHat is a larger company of over 600 employees.
!QED
It made sense when development was slower, the number of packages was smaller, the number of RH distributions was smaller, and the number of users was a LOT smaller. With GNOME, KDE, a rapid moving set of additional packages, a MUCH larger packages set, a MUCH larger userbase wanting a lot more (such as Corporate Support agreements with SLAs, and people thinking RH should make backports to stuff that is a few years old for free), and years and years of RH distributions, it is a different animal.
If it is so easy, feel free to go do it yourself and start rakind in the cash, man. Once you have, then you can say QED!
Cheers, Bill
William Hooper wrote:
... Having no support at home isn't that big of a deal. Having no support in a business, with my job on the line if something goes wrong is. There is no way in Hell *I* would do a large scale roll out of an OS without support.
People do this with Windows all the time! :-) I don't think i've worked at any organisation that actually had a support contract with Microsoft, despite it being their standard desktop.
Paul Gear said:
William Hooper wrote:
... Having no support at home isn't that big of a deal. Having no support in a business, with my job on the line if something goes wrong is. There is no way in Hell *I* would do a large scale roll out of an OS without support.
People do this with Windows all the time! :-) I don't think i've worked at any organisation that actually had a support contract with Microsoft, despite it being their standard desktop.
But pay per incident support is available. The original suggestion was to provide WS for free with *no* support.
On Wednesday, August 27, 2003, at 12:13 PM, Stephen Smoogen wrote:
Sure and Red Hat can go belly up in 2 years because no-one is paying them for all the work they do.
I didn't read that to imply that the WS product should be free, but that the license fee should be reduced to something more reasonable. In effect, this suggests that RHAT should profit from volume sales rather than margin (since they can't do both simultaneously like MS).
--
C. Magnus Hedemark http://trilug.org/~chrish "The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not." - Mark Twain
Actually, I DID mean drop the license to zero dollars.
I think the up front cost of the desktop version means it will not be deployed in volume. Large enterprises will deploy free alternatives instead, because that will help make ROI on the whole project reasonable.If this is a correct assumption, then Red Hat will not make much money from licensing WS. If they make it free. then they can compete for support dollars with everyone else, and win some. Their value proposition on servers is more compelling, so the AS offering can help drive WS adoption, which in turn can help drive support sales.
No one will be able to garner the sort of revenue stream Microsoft gets from its desktop monopoly. The only way to break their grip, even just a little, is to offer a much lower cost alternative that does the important things businesses look for in a desktop solution just as well. Linux is *this* close to being able to achieve that. If the leading Linux vendor adds license fees up front, it will slow adoption, perhaps long enough to allow Microsoft to leverage its current monopoly into dominating the next wave of client technology, whatever that turns out to be.
On Wed, 2003-08-27 at 10:20, Magnus wrote:
On Wednesday, August 27, 2003, at 12:13 PM, Stephen Smoogen wrote:
Sure and Red Hat can go belly up in 2 years because no-one is paying them for all the work they do.
I didn't read that to imply that the WS product should be free, but that the license fee should be reduced to something more reasonable. In effect, this suggests that RHAT should profit from volume sales rather than margin (since they can't do both simultaneously like MS).
--
C. Magnus Hedemark http://trilug.org/~chrish "The only way to keep your health is to eat what you don't want, drink what you don't like, and do what you'd rather not." - Mark Twain
Howard Owen wrote:
I have one Fortune 1000 client who is wrestling with this issue. They are rolling their own Red Hat based distro, and paying the price of chasing the consumer OS, while looking over their shoulder at the end-of-life dates for 7.x, 8 and 9. They have 1400 desktops rolled out, in a potential market of 16,000.
I think Red Hat should drop license fees for their WS product.
It is highly unrealistic for Red Hat to go uncompensated for their efforts. As people in charge of networks and the technology that runs on them it behooves us to make sure they are sufficiently financially compensated so that they can continue to push Linux where we need it to go (i.e. usable by the average corporate employee).
That being said, in my experience, corporate IT groups will only contact the vendor's support group after trying to solve the problem on their own. Also they will usually only call about a particular issue once or twice then they will be familiar with the fix and implement it without assistance.
Besides this there are different levels of urgency involved. If there were something along the lines of a less expensive, email only, with up to 72 hr response time contract option that was cheaper, this might be a comfortable fit for some customers. If things got truly ugly they could purchase an occasional per incident support call.
There must be a sweet spot for the number of installed clients vs. actual support incidents which would allow Red Hat to offer cheaper licensing to those that will purchase many licenses but have relatively few support calls.
So Red Hat could have three support options: 1- Full phone support with full RHN access 2- Email only up to 72hr response time with full RHN access 3- Only full RHN access.
This would allow customers to customize their support to their needs and protects Red Hat from people feeling pigeon-holed.
Of course this suggestion is only valid if the main cost component of an RHEL license is the support.
For reference: http://www.redhat.com/software/rhel/purchase/
Charles Bronson said:
So Red Hat could have three support options: 1- Full phone support with full RHN access
"Premium Editions" Web 24/7 for 1 year Phone 24/7 for 1 year Web SLA 1 Business Day Phone SLA 1 Hour
2- Email only up to 72hr response time with full RHN access
"Standard Editions" Web 24/7 for 1 year Phone 9a-9p ET M-F for 1 year Web SLA 2 business days Phone SLA 4 Hours
3- Only full RHN access.
"Basic Editions" Web 24/7 for 90 days Phone 9-5 ET M-F for 90 days No SLA
Looks like Red Hat is a step ahead of you.
William Hooper wrote:
For reference: http://www.redhat.com/software/rhel/purchase/
Charles Bronson said:
So Red Hat could have three support options:
------- SNIP ------
Looks like Red Hat is a step ahead of you.
Holy cow!!! I'm a damn genious... just a little behind the curve at it ;-)
OK, I know I've looked at those price lists and options(at the above link) before. I guess in all the other stuff I've been working on it slipped out of my brain. In light of so much of the broohaha(sp?) about WS licensing cost that has gone one here recently I have only one comment... $299 for a seat license and year of phone/web support! QUIT BITCHING ABOUT LICENSING COSTS!!! One per incident call to Microsoft will damn near equal that and I have invoices to prove it. Furthermore that price isn't even a volume discount.
Sorry I went a little over the edge there. But licensing costs are a near and dear subject for me right now as we are fighting to replace our *very* dated Microsoft products with Linux.
From: "Charles Bronson" packetgeek@chuckiechanboys.com
Looks like Red Hat is a step ahead of you.
Holy cow!!! I'm a damn genious... just a little behind the curve at it ;-)
No danger of that, Charles. A real genius would not spell it "genious."
--->>>>> Ack! Plblpltp! {O,o} Exiting fast!
jdow wrote:
From: "Charles Bronson" packetgeek@chuckiechanboys.com
Looks like Red Hat is a step ahead of you.
Holy cow!!! I'm a damn genious... just a little behind the curve at it ;-)
No danger of that, Charles. A real genius would not spell it "genious."
Charles Bronson... Super Genious has a nice ring to it. heh heh heh
On Tuesday, Aug 26, 2003, at 18:44 Asia/Jerusalem, Troy Dawson wrote:
I need to defend RH here and refute a few of the weaker points of your argument.
Buying the Enterprise stuff is not an option.
This is o.k. You don't need the enterprise stuff if you don't want it. I'll concede this one to you. Although you will get a huge discount, I'm sure, on a bulk order.
We were just starting work on alternatives when the RHL web page went up. All our work stopped and we started shifting over to maybe working with the RedHat community. But ... well as everyone knows, that got pulled out. A mailling list is not a community
Why not? You have direct contact with the developers. They will give back to you as much as you give to them and help the project.
My management is not going to accept my answer that 'I read it from some redhat guy on the mailling list' they want to see it on a web page. A policy isn't a policy if it's only on some mailling list. (I know that isn't entirely true, but think of it from managements perspective)
Another valid point. PHB's like to see things in "official writing."
So, we have basically turned and are looking for different alternatives again. That includes different distributions. That's not a threat, it's just something we have to look at because RedHat is no longer (at least in appearance) giving us what we need.
Red Hat will give you as much as you want out of it. I say that instead of complaining, try and have fermilab pay for you to get an rhce and take some of the rh developer courses. This way you can use, extend and flex the rhl distro any way you like. Basically the more you put in to it at this point; the more you help, the more help and time developers will put into helping you. I'd hate to see you use another platform, since I've been a developer on a few other distros, just for kicks, and nothing gets as good as rh. RH is a great distro, and it's not floating on air, it has corporate backing and wont have crazy developers forking the project every other week, because their patches are criticized. Stick with RH and RH will stick with you. There's a lot more to be said here, but I'll leave it to the developers to address.
--Jack
On Tue, Aug 26, 2003 at 10:44:12AM -0500, Troy Dawson wrote:
When is the web page going to be updated? From the sounds of the standard reply, it sounds like it isn't going to be updated for at least 3 more weeks.
The extended form of the standard reply is that we don't want to give an answer ahead of time, even if we have expectations for a date, because we'd rather underpromise and overdeliver than vice versa. I know it is frustrating, and I can only say that to frustrate is not our goal.
My management is not going to accept my answer that 'I read it from some redhat guy on the mailling list' they want to see it on a web page. A policy isn't a policy if it's only on some mailling list. (I know that isn't entirely true, but think of it from managements perspective)
It would be even worse if we pulled it, put it back, and then changed it a few times after that. I sympathize with your management; in their position, I'd want the same thing. Messages posted by employees should not be construed as statements of company policy.
What it says on the web site is really true, we're addressing questions that have come up, and the answers aren't trivial (if they were, we would have made a few quick changes and been back on line immediately). I do want to say that the discussion on these lists has been very important and has provided some of the questions that we believe it is critical to answer before we put the web site back up. We can't do this piecemeal; the issues are linked together too closely for that to work.
I'd love to give you a date, but failing that, I just want to make it clear that we're reading and thinking about every single post that has been made to these lists (and when we can, we are responding). We absolutely won't make everyone happy, and I certainly can't promise ahead of time that you will see exactly what you want, but you can expect it to be much clearer.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
-
Bill Anderson -
Charles Bronson -
Chris Ricker -
Daniel Veillard -
Elliot Lee -
Felix Cudello Hernandez -
Féliciano Matias -
Gerald Henriksen -
Howard Owen -
Jack Aboutboul -
Jay Turner -
jdow -
John Beimler -
Magnus Hedemark -
Michael K. Johnson -
Paul Gear -
Paul Morgan -
Robin Green -
Stephen Smoogen -
Steve Bergman -
Tom Callaway -
Troy Dawson -
William Hooper