This morning's lead article in CNET News.com entitled "Red Hat overhauls flagship Linux" had references to Fedora which I found to be be disappointing. They quoted from users in an email list that I believe may have been confused about Fedora. Perhaps some folks on this list can clarify a couple of points.
First, there were concerns noted that Fedora will be a fast-changing distro, not conducive to a stable working environment. Granted, wholesale upgrades from one release to another might break things and could consume resources to accomplish the task. However, I am unclear as to whether the commenter's were concerned about ongoing upgrades within a release or were concerned about the need to upgrade all servers and desktops perhaps three times a year.
What should a user's expectation be with respect to planned upgrades and releases?
Second, one comment described Fedora as "possibly full of breakage." I think the poster may be theorizing about potential future upgrades. I certainly hope that the comment was not made on the basis of the stability of test releases!
Third, (unrelated to the news article) concerns access to patches and updates. Is it expected that mirror sites will be able to provide good repositories for apt or yum once FC1 is officially released? Or will we continue to point Fedora's up2date to the redhat.com repository?
On Wed, Oct 22, 2003 at 10:21:04AM -0500, Don Maxwell wrote:
Second, one comment described Fedora as "possibly full of breakage." I think the poster may be theorizing about potential future upgrades. I certainly hope that the comment was not made on the basis of the stability of test releases!
I think a lot of that is overblown. One of the more amusing bits of "social engineering" in the last month or so is how Red Hat has convinced a huge number of people to run "Rawhide" by calling it Fedora Core Test, and issuing updates through RHN. My guess is that this is the most widely tested release of "RHL" ever. :-)
And know what? Precious little has been utterly and truly broken. In a few instances I've had to back out an update. I've had far fewer problems in updating my laptop daily than the guys in my office have had with Windows security updates. [Not to say that besting Windows is any great achievement.]
So while there will be bugs and incompatibilities in any release, I'm feeling pretty confident that FC1 will be better than any previous ".0" release.
Just one user's opinion ...
Regards,
Bill Rugolsky
On Wednesday 22 October 2003 08:42, Bill Rugolsky Jr. wrote:
And know what? Precious little has been utterly and truly broken. In a few instances I've had to back out an update. I've had far fewer problems in updating my laptop daily than the guys in my office have had with Windows security updates. [Not to say that besting Windows is any great achievement.]
You make some great points, Bill. But as a small business man I can't take the time update or to back out updates daily. Or even weekly, or monthly, or quarterly, or annually. I need a server platform I can leave (with only security updates) for at least four years.
Perhaps Linux won't fill my needs. But I'd like it to.
So while there will be bugs and incompatibilities in any release, I'm feeling pretty confident that FC1 will be better than any previous ".0" release.
I hope so as well. But I can't help remember how the mozilla project went, and I can't afford to wait through as long as that took.
Just one user's opinion ...
And another's <smile>.
Jeff
On Wed, Oct 22, 2003 at 10:17:29AM -0700, Jeff Lasman wrote:
You make some great points, Bill. But as a small business man I can't take the time update or to back out updates daily. Or even weekly, or monthly, or quarterly, or annually. I need a server platform I can leave (with only security updates) for at least four years.
I never meant to suggest that production machines should be upgraded willy-nilly. Of course not. Rather, I was countering the idea that FC1 Test was somehow wildly unstable.
As to security updates for four years, I understand your reluctance to use RHEL because of price sensitivity. But Red Hat suffers from price sensitivity too -- they need to pay people to backport and QA patches. That involves personnel, equipment, and cycles. Hardware compatibility evolves, and so it is necessary to keep around hardware that was in the HCL for that release. (E.g., 440GX mobos, sold in large quantities by VA Linux and others, have broken APIC behavior.) It may be that others can provide this service for less money. This issue has been rehashed repeatedly on this list.
I'd suggest that if $100K/yr to hire someone to do maintenance on your systems, including patching and backporting, is too high, then hosting providers like yourself need to pool your resources to hire folks to do the work or divide it amongst yourselves. The Fedora Project is a natural rendezvous point, and one would assume that with a bit of coordination, the task of keeping the major server applications secure could be divided among a relatively small group, with individuals with expertise in a particular app, say Apache or MySQL, taking on maintenance of that package.
Patching is occasionally difficult, but the vast majority of security fixes are simple backports. The greatest difficulties are when (1) the upstream app is no longer vulnerable, due to extensive changes, hence there is nothing to backport, and (2) kernel patching, due to the heavily patched kernels in common use. One of the goals of Fedora core is to keep the kernel closer to mainline, and that may help.
Security-related backported patches also tend to show up in Debian stable, so it is often possible to patch an app about which one has little clue.
If you (or your customers) want *guarantees* regarding security updates, it is going to cost you money; there is no simple way around that.
Regards,
Bill Rugolsky
On Wednesday 22 October 2003 10:47, Bill Rugolsky Jr. wrote:
I never meant to suggest that production machines should be upgraded willy-nilly. Of course not. Rather, I was countering the idea that FC1 Test was somehow wildly unstable.
Thanks for your response, and your insight.
As to security updates for four years, I understand your reluctance to use RHEL because of price sensitivity. But Red Hat suffers from price sensitivity too -- they need to pay people to backport and QA patches. That involves personnel, equipment, and cycles.
I understand this. The part I don't like is the Fear, Uncertainty and Doubt that Red Hat is currently distributing. I called a salesrep a few days ago for information on whether the RHEL packages could be used after the first year (without renewing) or whether they could be used on additional systems.
The answer I got was that Enterprise Linux is almost all open source and that I could use the open source parts of it on multiple systems but the license prohibited me from using it on more than one machine so I'd have to compile everything from source. I was also told that I could use updates only on one machine, but not on any other machine.
But he had no idea which portions of the product were open source and which weren't, which to me is an attempt to instill FUD.
Either a given package is or isn't open source. And if Red Hat won't tell us which pieces of their packages are and which aren't, then as far as I'm concerned, they've infected the whole package.
Since they have more money than I do, I'm certainly not going to test them on this, but I believe it.
Hardware compatibility evolves, and so it is necessary to keep around hardware that was in the HCL for that release. (E.g., 440GX mobos, sold in large quantities by VA Linux and others, have broken APIC behavior.) It may be that others can provide this service for less money. This issue has been rehashed repeatedly on this list.
Yes, but so far no one has come up and offered the service. I won't; it's not our business model. And it doesn't appear to be anyone else's either.
I'd suggest that if $100K/yr to hire someone to do maintenance on your systems, including patching and backporting, is too high, then hosting providers like yourself need to pool your resources to hire folks to do the work or divide it amongst yourselves.
Or find other resources.
The Fedora Project is a natural rendezvous point, and one would assume that with a bit of coordination, the task of keeping the major server applications secure could be divided among a relatively small group, with individuals with expertise in a particular app, say Apache or MySQL, taking on maintenance of that package.
It may very well be. So far no one has stepped up to the plate, but I'm hopeful that will happen.
Patching is occasionally difficult, but the vast majority of security fixes are simple backports. The greatest difficulties are when (1) the upstream app is no longer vulnerable, due to extensive changes, hence there is nothing to backport, and (2) kernel patching, due to the heavily patched kernels in common use. One of the goals of Fedora core is to keep the kernel closer to mainline, and that may help.
I never said I faulted what Fedora is doing, and I don't. I just don't see it as filling my needs, or my cleints' needs. And that was the basis of my original response and my followups.
If you (or your customers) want *guarantees* regarding security updates, it is going to cost you money; there is no simple way around that.
We know that. I was willing (and I still am willing) to pay the $60 annual per system fee for RHN; it was Red Hat who decided to eliminate that model.
Interestingly, there is an option. I don't want to take it, but it's there, it's supported, and I may have to take it. It's called FreeBSD.
No, I'm not trying to start a war. I'm NOT trying to badmouth Linux or Red Hat, or the Fedora project. I'm merely disappointed that the promise of Linux has so deteriorated as companies who've made millions of dollars on open source software are now attempting to license it at as high a price as M$, and using as an excuse that they became a public corporation so now have to put their profits first.
That's my opinion.
No flames accepted onlist; if anyone needs to flame me please do it offlist.
Thanks.
Jeff
On Wed, 2003-10-22 at 13:04, Jeff Lasman wrote:
Either a given package is or isn't open source. And if Red Hat won't tell us which pieces of their packages are and which aren't, then as far as I'm concerned, they've infected the whole package.
As I understand it, everything is open source except the Sun/IBM java runtime. Someone please correct me if I'm wrong.
Steve Bergman wrote:
As I understand it, everything is open source except the Sun/IBM java runtime. Someone please correct me if I'm wrong.
Look yourself what is open source:
http://ftp.redhat.com/pub/redhat/linux/enterprise/
Jeff Lasman said: [snip]
We know that. I was willing (and I still am willing) to pay the $60 annual per system fee for RHN; it was Red Hat who decided to eliminate that model.
Interestingly, there is an option. I don't want to take it, but it's there, it's supported, and I may have to take it. It's called FreeBSD.
I'm not sure I see the difference in the EOL model for FreeBSD:
http://www.freebsd.org/security/security.html#adv
"Each branch is supported by the Security Officer for a limited time only, typically through 12 months after the release. The estimated lifetimes of the currently supported branches are given below. The Estimated EoL (end-of-life) column gives the earliest date on which that branch is likely to be dropped. Please note that these dates may be extended into the future, but only extenuating circumstances would lead to a branch's support being dropped earlier than the date listed."
On Wednesday 22 October 2003 11:59, William Hooper wrote:
I'm not sure I see the difference in the EOL model for FreeBSD:
In writing, I agree with you. But 4.8 is the current "stable" release; it's going to be around for a long time. And supported.
It's possible there'll be a stable 4.9, but it's unlikely, since most of the development work is now on 5.x.
In the past we ran BSDi-OS (a commercial version). Lots of people moved from that to FreeBSD when BSDI (the company) was sold. So there's a lot of support for the 4.x branches and it looks like there will be into the future.
Jeff
On Wed, 22 Oct 2003, Jeff Lasman wrote:
In writing, I agree with you. But 4.8 is the current "stable" release; it's going to be around for a long time. And supported.
It's possible there'll be a stable 4.9, but it's unlikely, since most of the development work is now on 5.x.
Um, FreeBSD 4.9 RC 3 is out now, and 4.9 proper should follow shortly
<ftp.FreeBSD.org/pub/FreeBSD/releases/i386/4.9-RC3>
later, chris
Jeff Lasman wrote:
In writing, I agree with you. But 4.8 is the current "stable" release; it's going to be around for a long time. And supported.
In the past we ran BSDi-OS (a commercial version). Lots of people moved from that to FreeBSD when BSDI (the company) was sold. So there's a lot of support for the 4.x branches and it looks like there will be into the future.
Did you see http://www.freebsd.org/releng/index.html ?
Looks like 'official' lifetime is *one* year.
Jeff Lasman said:
On Wednesday 22 October 2003 11:59, William Hooper wrote:
I'm not sure I see the difference in the EOL model for FreeBSD:
In writing, I agree with you. But 4.8 is the current "stable" release; it's going to be around for a long time. And supported.
March 31, 2004 to be exact (see the above web page).
RHL 9 is supported until April 30, 2004.
Jeff Lasman (blists@nobaloney.net) said:
But he had no idea which portions of the product were open source and which weren't, which to me is an attempt to instill FUD.
For Red Hat Enterprise Linux 3, the non-open-source stuff is on the 'Extras' CD/image, and some of the things in the additional products (JDK/JRE, etc.). There's also the usual trademark restrictions on anaconda-images and redhat-logos, of course.
Bill
On Wed, Oct 22, 2003 at 03:05:12PM -0400, Bill Nottingham wrote:
For Red Hat Enterprise Linux 3, the non-open-source stuff is on the 'Extras' CD/image, and some of the things in the additional products (JDK/JRE, etc.). There's also the usual trademark restrictions on anaconda-images and redhat-logos, of course.
I'd like to offer public accolades to Red Hat for being explicit with trademark and license issues, and cleanly delineating the parts that are not open source and freely redistributable. Red Hat is not required to do this, and historically some other vendors (SCO/Caldera OpenLinux, and others) have made it a point to entwine the pieces so as to frustrate attempts to reuse their work.
Given the pressures and responsibilties on a publicly-traded company, this is all the more admirable.
Bill Rugolsky
Bill Rugolsky Jr. wrote:
I'd like to offer public accolades to Red Hat for being explicit with trademark and license issues, and cleanly delineating the parts that are not open source and freely redistributable. Red Hat is not required to do this, and historically some other vendors (SCO/Caldera OpenLinux, and others) have made it a point to entwine the pieces so as to frustrate attempts to reuse their work.
Given the pressures and responsibilties on a publicly-traded company, this is all the more admirable.
Deja vu.
Already discussed on http://www.redhat.com/mailman/listinfo/fedora-list
more info: http://www.redhat.com/licenses/rhel_us_3.html http://www.linuxmafia.com/~rick/linux-info/rhas-isos http://www.redhat.com/about/corporate/trademark/ http://www.gnu.org/licenses/gpl-faq.html http://www.gnu.org/licenses/gpl.html
Jeff Lasman wrote:
You make some great points, Bill. But as a small business man I can't take the time update or to back out updates daily. Or even weekly, or monthly, or quarterly, or annually. I need a server platform I can leave (with only security updates) for at least four years.
Perhaps Linux won't fill my needs. But I'd like it to.
Jeff,
I read some of your other posts, and I understand where you are coming from. I am a manager in a company that run's mission critical UNIX systems for financial institutions. Any downtime could cost thousands of dollars a minute.
Anyway, we have been VERY happy with RHEL. Uptime is measured in hundreds of days. The OS has a three year release cycle, and patches are "back-ported" whenever possible, so compatability over time is not a problem. The quality of RHEL is very fine.
We buy official RHN subscriptions for boxes where we are running Netcool or Oracle or Remedy or Hideal. I mean heck, if you are spending tens of thousands of dollars for a commercial software license and the software is "certified" for support on an OS that costs less than $1K/year to get that stamp of "official" support why not?
However, I wanted to have a "standard" in my data center, one flavor to centralize on. Even for boxes that are just "devel" or intranet print servers and such. For these other systems I have created a "custom" distro. I use the word "Custom" loosely, because it was very simple and easy for me to do. This custom distro is /almost/ exactly the same thing as RHEL (but not quite).
I set up a cronjob to mirror the Source RPMS for RHEL. (it fetches updates every few hours) I rebuild the RPM's on one of the genuine RHEL Licensed boxes we have and put all the RPM's in a directory. I set up a CURRENT server (kind of like a replacement for RHN, but free and open source).
The only packages I don't copy are the IBM-java related ones.
I spent some time comparing 7.2 to RHEL, out of about 1200 RPM's that constitute the distribution, almost all of them were identical (name of RPM and md5sum) to 7.2 anyway. Only a handfull were any different. The few that weren't were licensed in such a way that they are freely distributable also. (GPL'd, BSD, Apache, X .... licenses)
I searched for some reason that it wouldn't be acceptable to do this, I couldn't find anything other than the issue about the RedHat logo's and trademarks in the packages. (IANAL), but I read the RedHat trademark use policy and found that as long as you are using the trademarks and logos that are in the packages in order to work with the software that RedHat is distributing, it seems to be acceptable.
The thing that would be WRONG is to call my hacked setup "RedHat" because that would violate the trademark's, it would also be WRONG to distribute my hacked version to someone else with those logos and trademarks in there. But since I am only using it internally for my own use, and my systems don't utilize ANYTHING from RHN at all, I don't use their logo's or trademarks for any other purpose than package compatability (dependencies) I *think* I am within my rights.
Look on this web-page and search for "GPL License" http://www.redhat.com/advice/ask_shadowman_may02.html
BTW, for the systems where it is financially justifiable (for the support needed on 7x24 systems) from Dell/HP/Compaq/IBM/Oracle/BEA... I think RedHat Enterprise is a great product.
The only thing I wish is that RedHat would sell me a "graduated" price model so that the more servers I deployed the less expensive it was per server. If they would do that I would definitely buy many more RHN-ES subscriptions.
-Ben.
On Wednesday 22 October 2003 20:25, Ben Russo wrote:
I read some of your other posts, and I understand where you are coming from. I am a manager in a company that run's mission critical UNIX systems for financial institutions. Any downtime could cost thousands of dollars a minute.
...<balance snipped>...
Thanks for your good points, Ben. I'm making an exception to my decision to not post on this thread anymore; your post is as close to ontopic as any I've seen on this list about the future of Red Hat Linux.
If my control panels were available for, and supported under, RHEL, I'd probably find myself doing just what you're doing, especially we have local support for creating complete RH-compatible operating systems.
(A friend of mine, who may even be on this list, does the Red-Hat-alike distribution for one of the mail-order distribution houses; I'm sure he'd let me pay him to do the same for him <smile>.)
But the fact is that I can't get the support for the Control Panels for RHEL.
It was never my intent to rant on this list, and though a few people have written both on and off-list to let me know I brought up some good points, I'm not happy with what the thread has turned into. I merely responded to someone who asked a question, and look where it's gotten me <wry grin>.
Jeff
Jeff Lasman said: [snip]
If my control panels were available for, and supported under, RHEL, I'd probably find myself doing just what you're doing, especially we have local support for creating complete RH-compatible operating systems.
[snip]
It sounds like your main problem is your control panel vendors, not RHEL.
On Thursday 23 October 2003 15:17, William Hooper wrote:
It sounds like your main problem is your control panel vendors, not RHEL.
Yes, and I never meant for my post to be taken as a rant; I was merely responding to the original poster's question. I'm quite sorry for all the time and space it's taken.
Jeff
Jeff Lasman said:
On Thursday 23 October 2003 15:17, William Hooper wrote:
It sounds like your main problem is your control panel vendors, not RHEL.
Yes, and I never meant for my post to be taken as a rant; I was merely responding to the original poster's question. I'm quite sorry for all the time and space it's taken.
It just brings up a good point that for some reason needs repeating. In following the mailing lists when RH announced it's EOL changes (before Fedora) there were a lot of posts saying "I'll just switch to foo" or "I'll be forced to go to bar". Most of these posters didn't bother looking at the support policies of foo or bar.
The situation has been changed a bit with Fedora, since it is aimed at the enthusiast market, does have a shorter errata time than most, but not by much. RHEL on the other hand has a very good errata policy in comparison to it's competition.
-- William Hooper
On Wednesday 22 October 2003 01:17 pm, Jeff Lasman wrote:
You make some great points, Bill. But as a small business man I can't take the time update or to back out updates daily. Or even weekly, or monthly, or quarterly, or annually. I need a server platform I can leave (with only security updates) for at least four years.
Please see if Redhat Professional Workstation fits your need. The price is well below RHEL, but it seems to have all the thing you need for webserver. I'd still like to find out how long is the life cycle and support for it though. http://www.redhat.com/software/workstation/
RDB
The link you provided has a link on it also and it points to RHEL. They are referring the RHEL WS. There are 3 different RHEL packages and each has up to 2 different prices per package. Fedora was possibly partly created because they would be supporting as many or more products than Microsoft. Which Microsoft keeps planning to drop support for more products all the time also. I support UNIX/ Linux/ Windows/DOS systems at my location.
----- Original Message ----- From: "Reuben D. Budiardja" techlist@voyager.phys.utk.edu To: fedora-list@redhat.com Sent: Thursday, October 23, 2003 8:25 AM Subject: Re: CNET News Article
On Wednesday 22 October 2003 01:17 pm, Jeff Lasman wrote:
You make some great points, Bill. But as a small business man I can't take the time update or to back out updates daily. Or even weekly, or monthly, or quarterly, or annually. I need a server platform I can leave (with only security updates) for at least four years.
Please see if Redhat Professional Workstation fits your need. The price is well below RHEL, but it seems to have all the thing you need for
webserver.
I'd still like to find out how long is the life cycle and support for it though. http://www.redhat.com/software/workstation/
RDB
Reuben D. Budiardja Department of Physics and Astronomy The University of Tennessee, Knoxville, TN
"To be a nemesis, you have to actively try to destroy something, don't you? Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." - Linus Torvalds -
-- fedora-list mailing list fedora-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-list
I'd still like to find out how long is the life cycle and support for it though. http://www.redhat.com/software/workstation/
RDB
Reuben D. Budiardja
My understanding is that the new Red Hat Enterprise offerings have a 5 year life. The point of WS is that it is the same code base as ES and AS so you don't have to worry about developers compiling something on thier desktop and it not running on the server.
ciao!
leam
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 23 Oct 2003 16:19:26 -0400, leam wrote:
I'd still like to find out how long is the life cycle and support for it though.
My understanding is that the new Red Hat Enterprise offerings have a 5 year life. The point of WS is that it is the same code base as ES and AS so you don't have to worry about developers compiling something on thier desktop and it not running on the server.
Though, Red Hat Professional Workstation is a different product than Red Hat Enterprise Linux WS, albeit based on the Red Hat Enterprise Linux code. My understanding is that the initial product life cycle is at least 12 months, after which you would upgrade to the successor (just as with the Red Hat Linux 8.0/9 model). I think the future of the product and its life cycle depend much on how popular it becomes without making Enterprise WS less attractive.
- --
On Wed, 22 Oct 2003, Bill Rugolsky Jr. wrote:
Second, one comment described Fedora as "possibly full of breakage." I think the poster may be theorizing about potential future upgrades. I certainly hope that the comment was not made on the basis of the stability of test releases!
I think a lot of that is overblown. One of the more amusing bits of "social engineering" in the last month or so is how Red Hat has convinced a huge number of people to run "Rawhide" by calling it Fedora Core Test, and issuing updates through RHN. My guess is that this is the most widely tested release of "RHL" ever. :-)
Huh? How is this ANY different from ANY previous release of Red Hat Linux in any way? Red Hat Linux beta releases have ALWAYS been created from a snapshot of Rawhide. That is by definition, what a Beta is in the first place.
Rawhide is the ongoing developmental head of Red Hat Linux (now Fedora Core) development, and betas (now called tests) are snapshots in time of Rawhide.
Absolutely nothing has changed in this respect whatsoever, other than that hundreds and hundreds of people have for years now requested that rawhide be also available via RHN, and now we've made it also available via RHN.
And know what? Precious little has been utterly and truly broken. In a few instances I've had to back out an update. I've had far fewer problems in updating my laptop daily than the guys in my office have had with Windows security updates. [Not to say that besting Windows is any great achievement.]
So while there will be bugs and incompatibilities in any release, I'm feeling pretty confident that FC1 will be better than any previous ".0" release.
Well, it should be just as stable or moreso than any previous Red Hat Linux release, because we have the same engineers working on it, and we've followed the same procedures we've used for previous releases, done the same types of debugging, troubleshooting and bug fixing.
"Fedora Core" to date has only been a test release (previously called betas), so to compare that with an official release such as Red Hat Linux 9 is comparing apples to oranges. The Fedora Core 1 release is what people should be reviewing once it is available, and knowing the resources and manpower that went into the development of this release, and having been a part of that, I have no reason to believe that our new OS release will be as stable, reliable, etc. or better than any previous Red Hat Linux release.
However, no software is 100% perfect, and people who use any given release may not encounter any problems at all, while other users may encounter a few or even many depending on their setups and usage patterns. Like any previous release, there will be people who love it and think it's great, and there will be people who hate it and think it sucks. Any major development such as a Linux distribution knows these things from the get go, and accepts them. The age old cliche rings true:
"You can please some of the people all of the time, and you can please all of the people some of the time, but you can't please all of the people all of the time."
We do however do our best to try, and I think we do so very successfully even when a minority of people aren't happy with the end results, as there will always be people who fit that category. ;o)
Of course I think Mike meant to say
"I have EVERY reason to believe that our new OS release will be as stable, reliable" :)
otherwise, he's definitely confirming the original posters opinion :)
sorry, could resist!
Tom
On Wed, 22 Oct 2003, Mike A. Harris wrote:
"Fedora Core" to date has only been a test release (previously called betas), so to compare that with an official release such as Red Hat Linux 9 is comparing apples to oranges. The Fedora Core 1 release is what people should be reviewing once it is available, and knowing the resources and manpower that went into the development of this release, and having been a part of that, I have no reason to believe that our new OS release will be as stable, reliable, etc. or better than any previous Red Hat Linux release.
However, no software is 100% perfect, and people who use any given release may not encounter any problems at all, while other users may encounter a few or even many depending on their setups and usage patterns. Like any previous release, there will be people who love it and think it's great, and there will be people who hate it and think it sucks. Any major development such as a Linux distribution knows these things from the get go, and accepts them. The age old cliche rings true:
"You can please some of the people all of the time, and you can please all of the people some of the time, but you can't please all of the people all of the time."
We do however do our best to try, and I think we do so very successfully even when a minority of people aren't happy with the end results, as there will always be people who fit that category. ;o)
On Wed, 22 Oct 2003, Tom Ryan wrote:
Date: Wed, 22 Oct 2003 15:09:32 -0400 (EDT) From: Tom Ryan tomryan@camlaw.rutgers.edu To: fedora-list@redhat.com Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: For users of Red Hat Linux releases <fedora-list.redhat.com> Subject: Re: CNET News Article
Of course I think Mike meant to say
"I have EVERY reason to believe that our new OS release will be as stable, reliable" :)
otherwise, he's definitely confirming the original posters opinion :)
sorry, could resist!
Oops! I meant to say:
I have no reason to believe that our new OS release *WONT* be as stable, reliable, etc. or better than any previous Red Hat Linux release.
What a horrible typo! Thanks for pointing it out!
On Wed, Oct 22, 2003 at 03:02:45PM -0400, Mike A. Harris wrote:
Huh? How is this ANY different from ANY previous release of Red Hat Linux in any way? Red Hat Linux beta releases have ALWAYS been created from a snapshot of Rawhide. That is by definition, what a Beta is in the first place.
I know. (Been using RH since 4.2.) I think that you mistook my praise for criticism.
Absolutely nothing has changed in this respect whatsoever, other than that hundreds and hundreds of people have for years now requested that rawhide be also available via RHN, and now we've made it also available via RHN.
And that was my point. In previous betas, we'd duly install from the isos, selectively updating packages that were of special interest to us, or especially broken, by grabbing the latest from Rawhide (and endure the dependency horrors that that sometimes entailed).
This time around, with yum repositories, and now up2date, keeping up with rawhide was trivial, and as a consequence, I'm guessing that many more people did so. My point was that running the most bleeding-edge configuration available was remarkably stable throughout the beta series.
So I think we are in vigorous agreement: kudos to Red Hat engineering!
We do however do our best to try, and I think we do so very successfully even when a minority of people aren't happy with the end results, as there will always be people who fit that category. ;o)
Amen.
Bill Rugolsky
On Wed, 22 Oct 2003, Bill Rugolsky Jr. wrote:
Huh? How is this ANY different from ANY previous release of Red Hat Linux in any way? Red Hat Linux beta releases have ALWAYS been created from a snapshot of Rawhide. That is by definition, what a Beta is in the first place.
I know. (Been using RH since 4.2.) I think that you mistook my praise for criticism.
Sorry, I understood you ok, I was more commenting on what the article was saying... it just appeared directed at you, but was directed to the not-present-person who you were paraphrasing. ;o)
Absolutely nothing has changed in this respect whatsoever, other than that hundreds and hundreds of people have for years now requested that rawhide be also available via RHN, and now we've made it also available via RHN.
And that was my point. In previous betas, we'd duly install from the isos, selectively updating packages that were of special interest to us, or especially broken, by grabbing the latest from Rawhide (and endure the dependency horrors that that sometimes entailed).
This time around, with yum repositories, and now up2date, keeping up with rawhide was trivial, and as a consequence, I'm guessing that many more people did so. My point was that running the most bleeding-edge configuration available was remarkably stable throughout the beta series.
I agree, I was more preaching to the choir, of whom you are part of, rather than disagreeing with you. ;o) It just didn't come out that way perhaps.
So I think we are in vigorous agreement: kudos to Red Hat engineering!
Thanks, agreed. ;o)
On Wednesday 22 October 2003 08:21, Don Maxwell wrote:
This morning's lead article in CNET News.com entitled "Red Hat overhauls flagship Linux" had references to Fedora which I found to be be disappointing. They quoted from users in an email list that I believe may have been confused about Fedora. Perhaps some folks on this list can clarify a couple of points.
I have no idea as to which list the CNET article author is referring. But I share some of those feelings, so I hope you don't mind me chiming in here to explain why I feel the way I do.
First, there were concerns noted that Fedora will be a fast-changing distro, not conducive to a stable working environment.
So far, from reading this list, I believe that's true. Will it change once there's a final release? I hope so. But until then, as a small business owner, I can't depend on it, as I could RHL7.3 and later RHL9 out of the box.
Granted, wholesale upgrades from one release to another might break things and could consume resources to accomplish the task.
What we do is host webservers and domains. It's not important that we upgrade to new versions. In fact it's important that we don't.
What we need is continued vulnerability-patching for core releases for a long time. While that might seem to make us primary candidates for the RHEL versions, with cabinets with 50 servers apiece and annual subscription charges that model will never work for us.
So far I've seen nothing on continued vulnerability-patching for RHL 7.3, or for RH9. If there is any, it appears to be well-hidden, and if you know of any, please tell me.
However, I am unclear as to whether the commenter's were concerned about ongoing upgrades within a release or were concerned about the need to upgrade all servers and desktops perhaps three times a year.
What I recall is that we'll need to update servers and desktops once a year. While that might work for us on desktops, we need to be assured of continued server support for at least four years.
What should a user's expectation be with respect to planned upgrades and releases?
As I wrote above, we need our servers to work without major operating system upgrades for four years. Your mileage may vary.
Second, one comment described Fedora as "possibly full of breakage." I think the poster may be theorizing about potential future upgrades. I certainly hope that the comment was not made on the basis of the stability of test releases!
I would make the comment based on what I've read on this list during the short time I've been a member.
Don't get me wrong, this list is a great resource and on one level I'm enjoying the same "thrill" (if that's the word) I had when I was much younger and first starting out with TRS-DOS, with MS-DOS, with M$-Windows, with Xenix, Unix, and Linux (which I've used since kernel release 0.9). But on another level, as a business man with servers to support I must have a stable release.
Since we use hosting control panels, both for ourselves and to support our clients, we must stick with releases the hosting control panel developers support. So for the moment' I'm just an interested bystander here.
But we're already running testbeds for FreeBSD (no flames, please) which the control panels already support. We'll run testbeds for Fedora if and when the control panel manufacturers offer support for it. We'll also look at other Linux platforms if an when the control panels offer support for it.
And we're still looking for sources of continued security updates for RHL 6.2, 7.3, and 9, as we know the moves will neither be quick nor easy.
Jeff
On Wed, 2003-10-22 at 12:15, Jeff Lasman wrote:
What we need is continued vulnerability-patching for core releases for a long time. While that might seem to make us primary candidates for the RHEL versions, with cabinets with 50 servers apiece and annual subscription charges that model will never work for us.
So far I've seen nothing on continued vulnerability-patching for RHL 7.3, or for RH9. If there is any, it appears to be well-hidden, and if you know of any, please tell me.
See:
On Wednesday 22 October 2003 10:30, Steve Bergman wrote:
Thanks. I don't use irc, but I've joined the mailing list.
Jeff
I have to say that where they have made a serious mistake is that they're judging a beta.
If I expected everything to work 100% I'd still be using RH9 and apt-get/freshrpms. ( and still do for one machine )
As with any OS if you want decent stability wait at least 2 months after release.
Personally I suspect RH9 is going to be one of those 'classic' stable releases like RH 7.3 ended up.
________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk
Jeff Lasman said: [snip]
What we need is continued vulnerability-patching for core releases for a long time.
Then you need either a) a team of coders to backport security fixes to the versions of the software you want to use or b) buy RHEL and rent Red Hat's team of coders to backport security fixes.
While that might seem to make us primary candidates for the RHEL versions, with cabinets with 50 servers apiece and annual subscription charges that model will never work for us.
Have you bothered to talk to RH sales at all? IIRC there was someone that posted about a quote for their .edu that ended up being ~$50/seat for 100 seats. That is less than the subscription to RHN.
So far I've seen nothing on continued vulnerability-patching for RHL 7.3, or for RH9. If there is any, it appears to be well-hidden, and if you know of any, please tell me.
Redhat's EOL for their releases have been posted for a while: http://www.redhat.com/apps/support/errata/
Fedora Core will come with no SLA at all. As others have pointed out there is a "Fedora-Legacy" movement out to do some back porting of fixes and such after RH's EOL. If you go with option a) above then you have the resources to contribute to this if you wish.
On Wednesday 22 October 2003 11:29, William Hooper wrote:
Then you need either a) a team of coders to backport security fixes to the versions of the software you want to use or b) buy RHEL and rent Red Hat's team of coders to backport security fixes.
No, what I need is an operating system from a vendor who understands that server life needs to be more than a year.
Have you bothered to talk to RH sales at all? IIRC there was someone that posted about a quote for their .edu that ended up being ~$50/seat for 100 seats. That is less than the subscription to RHN.
Yes. I talked to RH sales. An .edu gets a completely different price scale.
And servers don't get "per seat" licenses.
Redhat's EOL for their releases have been posted for a while: http://www.redhat.com/apps/support/errata/
That was my point. You can make it yours, though, if you wish <smile>.
As others have pointed out there is a "Fedora-Legacy" movement out to do some back porting of fixes and such after RH's EOL. If you go with option a) above then you have the resources to contribute to this if you wish.
I just joined that list, and I'm looking forward to seeing something besides a webpage.
I think it's time for me to bow out of this thread. I believe I've made it clear I love RHL and I love linux, and I'm frustrated by RH's direction. I answered the original post and I don't control this thread, but I'm going to bow out.
Jeff
Jeff Lasman said:
On Wednesday 22 October 2003 11:29, William Hooper wrote:
Then you need either a) a team of coders to backport security fixes to the versions of the software you want to use or b) buy RHEL and rent Red Hat's team of coders to backport security fixes.
No, what I need is an operating system from a vendor who understands that server life needs to be more than a year.
Which is why RHEL was created.
Have you bothered to talk to RH sales at all? IIRC there was someone that posted about a quote for their .edu that ended up being ~$50/seat for 100 seats. That is less than the subscription to RHN.
Yes. I talked to RH sales. An .edu gets a completely different price scale.
So you are telling me that you would get absolutely no discount on volume purchases?
And servers don't get "per seat" licenses.
Microsoft has corrupted the phrase. Replace "per seat" with "per machine". Another point to bring up is what RHEL you would need. You do know that RHWS includes Apache, right?
On Oct 22, 2003, "William Hooper" whooperhsd3@earthlink.net wrote:
And servers don't get "per seat" licenses.
Microsoft has corrupted the phrase. Replace "per seat" with "per machine".
Heh. ``But we don't have any chairs in this server room, why are you charging us for 128 seats?'' :-)
And servers don't get "per seat" licenses.
Microsoft has corrupted the phrase. Replace "per seat" with "per machine".
Heh. ``But we don't have any chairs in this server room, why are you charging us for 128 seats?'' :-)
Well, never one to be a microsoft apologist, I think they were referring to "users" of the software when they use the term "seat", not servers.
-Chuck
On Wednesday 22 October 2003 18:53, Chuck Wolber wrote:
Well, never one to be a microsoft apologist, I think they were referring to "users" of the software when they use the term "seat", not servers.
We currently have one M$ webserver license. M$ doesn't even allow you to use "seat" licenses to serve the net as a webserver; their license for webhosting sells for thou$ands of dollars, or can be "rented" for $10/processor/month for their W2003 Web Server edition.
If it weren't completely offtopic I'd find and post the URL to the website that explains the whole mess.
Jeff
TRS-DOS? Now, there's a name I haven't heard in a long time!
How about NewDOS, LDOS, or DoubleDOS?
BTW, this thread has been a refreshing discussion on some important topics!
On Wed, 2003-10-22 at 12:15, Jeff Lasman wrote:
Don't get me wrong, this list is a great resource and on one level I'm enjoying the same "thrill" (if that's the word) I had when I was much younger and first starting out with TRS-DOS, with MS-DOS, with M$-Windows, with Xenix, Unix, and Linux (which I've used since kernel release 0.9). But on another level, as a business man with servers to support I must have a stable release.
On Wed, Oct 22, 2003 at 10:15:05AM -0700, Jeff Lasman wrote:
What we need is continued vulnerability-patching for core releases for a long time. While that might seem to make us primary candidates for the RHEL versions, with cabinets with 50 servers apiece and annual subscription charges that model will never work for us.
Do you seriously believe that you're going to pay fill price for the Entreprise line if you call Red Hat, tell them you have n servers (where n is a whole lot) and ask for a discount?
Emmanuel
On Wednesday 22 October 2003 12:06, Emmanuel Seyman wrote:
Do you seriously believe that you're going to pay fill price for the Entreprise line if you call Red Hat, tell them you have n servers (where n is a whole lot) and ask for a discount?
I'm presuming you mean "NOT ask for a discount?".
I might do that (and ask for a discount) if and when the control panel vendors support RH EL. So far they're not.
Jeff
On Wed, 2003-10-22 at 15:06, Emmanuel Seyman wrote:
On Wed, Oct 22, 2003 at 10:15:05AM -0700, Jeff Lasman wrote:
What we need is continued vulnerability-patching for core releases for a long time. While that might seem to make us primary candidates for the RHEL versions, with cabinets with 50 servers apiece and annual subscription charges that model will never work for us.
Do you seriously believe that you're going to pay fill price for the Entreprise line if you call Red Hat, tell them you have n servers (where n is a whole lot) and ask for a discount?
Ding! Nobody publishes volume discounting unless they want folks not having the requisite volume to still lobby for the rock bottom deal.
--jeremy
On Fri, Oct 24, 2003 at 08:44:24PM -0400, Jeremy Hogan wrote:
Ding! Nobody publishes volume discounting unless they want folks not having the requisite volume to still lobby for the rock bottom deal.
Which leaves the poor "hobbyist" with an AMD64 or PPC64 box feeling like a chump for paying $792/yr for RHEL.
It is an absolute coup for Intel that RHEL cost the same on a US$2K AMD64 box as it does on a US$7-10K over-priced and under-performing IA-64 box. Development and support-wise, I can see why they should have cost parity. But I can also see SuSE and Mandrake sales rising rapidly ...
Fortunately, said "hobbyist" will soon be running 64-bit FC1. :-)
Bill Rugolsky
On Fri, 24 Oct 2003, Bill Rugolsky Jr. wrote:
Ding! Nobody publishes volume discounting unless they want folks not having the requisite volume to still lobby for the rock bottom deal.
Which leaves the poor "hobbyist" with an AMD64 or PPC64 box feeling like a chump for paying $792/yr for RHEL.
It is an absolute coup for Intel that RHEL cost the same on a US$2K AMD64 box as it does on a US$7-10K over-priced and under-performing IA-64 box. Development and support-wise, I can see why they should have cost parity. But I can also see SuSE and Mandrake sales rising rapidly ...
Fortunately, said "hobbyist" will soon be running 64-bit FC1. :-)
Shall I add your name to the "possible Fedora Core/AMD64 volunteers" list? Also, while I'm at it...
Who all out there is interested in spending their own personal time volunteering to work on an AMD64 version of Fedora Core? The main goal would be to have it an officially released Fedora Core 'branded' release, but even if we can't gather enough volunteers to make it an official release, there is most likely enough people interested to make an unofficial release something like what Tom Callaway has done with his Sparc port of RHL located at http://www.auroralinux.org
The simple stuff is rebuilding packages and fixing minor bugs, I don't think we need many people for that as most stuff builds and runs perfectly fine now as is. The areas needing help would be in kernel development/debugging, probably glibc and gcc, and other toolchain issues (although I know of no issues currently). Also needed more than developers are QA testers, and people itching to beta test the results on real AMD64 hardware and file bug reports.
I don't know how official we can make this in the short term, or how long it will take to get things off the ground, but I don't believe it is that much work personally, as one person outside of Red Hat has already gotten rawhide AMD64 packages rolled into installable ISO images using a recompiled RHEL3 kernel src.rpm, so it's more a matter of organizing the effort, determining where it will be officially compiled/built, and by whom, and where the community can pick up the results.
This could be a fantastic way to kickstart some of the community aspect of Fedora to the next level, and is IMHO a wonderful opportunity for everyone to work more closely with each other.
I'll spend as much personal time as I can on this, if there is enough community interest. AMD64 is IMHO going to be very widespread in a short period of time, due to it being consumer mass marketed. Wether or not the masses really need 64bit computing doesn't matter IMHO, as they'll have 64bit computers anyway. Can we all work towards getting them a kick arse 64bit cutting edge OS to run on it as well? I hope so! ;o)
Shall I set up a special development mailing list for this subproject, or does everyone think fedora-devel is sufficient?
On Sun, Oct 26, 2003 at 05:02:59AM -0500, Mike A. Harris wrote:
The simple stuff is rebuilding packages and fixing minor bugs, I don't think we need many people for that as most stuff builds and runs perfectly fine now as is. The areas needing help would be in kernel development/debugging, probably glibc and gcc, and other toolchain issues (although I know of no issues currently).
I think glibc and gcc are in a good shape on AMD64 in FC1. Main work is certainly kernel plus maybe installer.
Jakub
Jeremy Hogan wrote:
Ding! Nobody publishes volume discounting unless they want folks not having the requisite volume to still lobby for the rock bottom deal.
My boss (a VP in my company) called our RedHat Sales Person, we had 26 enterprised RHN licenses, we had a network with HUNDREDS of old SCO boxes on it that we were considering changing to RHEL. RedHat didn't want to talk about volume licensing.
Sorry...
-Ben.
From: "Don Maxwell" don.maxwell@usa.net
This morning's lead article in CNET News.com entitled "Red Hat overhauls flagship Linux" had references to Fedora which I found to be be disappointing. They quoted from users in an email list that I believe may have been confused about Fedora. Perhaps some folks on this list can clarify a couple of points.
First, there were concerns noted that Fedora will be a fast-changing distro, not conducive to a stable working environment. Granted, wholesale upgrades from one release to another might break things and could consume resources to accomplish the task. However, I am unclear as to whether the commenter's were concerned about ongoing upgrades within a release or were concerned about the need to upgrade all servers and desktops perhaps three times a year.
What should a user's expectation be with respect to planned upgrades and releases?
With the level of difficulty for providing a really bug free collection of software for something such as a Red Hat distribution (or a Windows distribution, which is actually smaller, for that matter) is pretty much "not going to happen" even for one specific CPU and stepping and one specific motherboard and collection of cards. Then when you consider the myriad of hardware problems in the hardware this software is expected to run on the only sure thing is that "bugs happem"
Given that bugs happen figure that a percentage of these bugs, perhaps a high percentage, will represent security holes. (BSD distributions that are built for security first still experience security problems from the critically needed add on tools such as browsers, servers, and user applications. It may be that the basic BSD structure minimizes this. But it does not eliminate it.) Security patches can keep up with the holes for awhile. However, as Microsoft has found out many security patches themselves cause system instability and further holes. At some time the probability of introducing problems becomes too close to the probability of eliminating them. At that time the distribution needs to face a clean and humane death. (Sadly Microsoft distributions seem to come off the production line in that state for many system uses. But that is an extreme example. Even Linux gets there eventually.)
Linux gets there because it gets boring to maintain the same code day in and day out. So the maintainers redesign it. (2.0, 2.2, 2.5, and now 2.6 kernels enter the picture. New incompatible compilers and libraries appear, and so forth.) At sometime the new hardware people wish to use is too incompatible with the kernel to run it for anything "user-ish" and probably even for server uses in extreme cases. So the whole smush needs to be updated again with a whole new distribution and we restart the bug cycle with a new range of bugs as well as many more that were there in the old code but just not found yet. Sometimes new technology for security is developed that requires a whole new means of compiling the application code as well as system code. Whatever, eventually old software is not going to be maintained. I rather expect that the life of a Microsoft OS with patches may exceed the life of a Linux distribution due to human factors. At Microsoft the people are getting paid to work on the old stuff. Money talks, people listen, and those people whore around in old code for the income it means. Linux offers little or no income to most of the developers for the various tools and programs that are delivered with a distribution. Linux offers little or no income for most kernel developers who might be moved to maintain proper backwards hardware compatibility. So it does not get done. Linux pays most developers in 'ego points'. The best ego points come from developing for the neat new stuff. And even there money talks. MS can manage to get some of the niftiest newest "stuff" so they can maintain compatibility with hardware as it comes out or even well before it comes out. Linux provides a disencentive for companies like Nvidia to develop Linux drivers. They have, they feel, proprietary money earning technology they have no intent to make available to their competitors. So they must release in binary. And the result is made a pariah in the Linux world. It's somewhat amazing they even bother. Linux is definately low on their priority lists. So Linux keeps up with new hardware as it comes out and developers can get their hands on the cards and documentation for the cards. It will lag. And when that server needs upgrade old kernels and software libraries may not handle the new machine. So you must ungrade. Three years seems to be close to the sustainable maximum life for any serious distribution mostly on a human factors level for Linux.
I wonder how this affects the <choke> "Total Cost of Ownership". I do note that successful hacks are a major often neglected item in the TCO equation. It is also a very positive side of Linux as compared to the results of the paid (and pained) minions of the Gates fortune.
Second, one comment described Fedora as "possibly full of breakage." I think the poster may be theorizing about potential future upgrades. I certainly hope that the comment was not made on the basis of the stability of test releases!
See the above discussion. And note that "full breakage" may simply mean a recompile of the old code in most cases. {^_-} Journalists tend to be alarmist by profession. It's their ego boost item. It also pads their bottom lines.
{^_^}
-
Alexandre Oliva -
Ben Russo -
Bill Nottingham -
Bill Rugolsky Jr. -
Chris Ricker -
Chuck Wolber -
Don R Maxwell -
Duncan Morison -
Emmanuel Seyman -
Jakub Jelinek -
jdow -
Jeff Lasman -
Jeremy Hogan -
Leam Hall -
Michael Schwendt -
Mike A. Harris -
Mike Peterson -
Reuben D. Budiardja -
Steve Bergman -
Tom Ryan -
William Hooper -
Xose Vazquez Perez