Anyone close to the development of FC would probably be the best to answer this..
I just had a look at the FC2 release schedule and it got me thinking..
Since the release interval between releases as so short (FC1 -> FC2 = 5Months) has any thought been given to maybe putting a structure in place that would allow initial installs to be performed by downloading the major release ISO's and then from there simply have a rolling upgrade meaning that as updates and upgrades happen the community can simply use YUM or a similar app to stay current.. I know that YUM can already perform and upgrade or update and most times it is sucessful but if the development community had this type of functionality in mind it would mean that the short release cycle would not be as much of a crisis for people using Fedora.. This is how "One Base Linux" appear to do it..
Of course this assumes that RedHat would not decline such a structure since one of their main selling points for RHEL is the 12-18month release cycle and if this was not an issue for useres of Fedora it could impact their sales of RHEL..
Anyway, anyone got any thoughts..
Later..
Em Seg, 2004-01-12 às 08:33, WipeOut escreveu:
Anyone close to the development of FC would probably be the best to answer this..
Fedora-devel list :-)
(...)
upgrade meaning that as updates and upgrades happen the community can simply use YUM or a similar app to stay current.. I know that YUM can
Its a simple change on sources.list if you use apt or yum.conf if you use it.
The matter is: not every single person wants to upgrade immediately. There are production server which can handle the upgrade of some packages but not a whole system, with kernel, gcc and almost everything else changing versions. So doing this by default is not a bad idea.
I've tried this once, with redhat8 to a preliminar version for 9. It screwed a litlle server, and made me be a little more cautious about this...
As you can see sometimes here, there are people which is still using redhat 7 - that's not uncommon. (in fact, a client of mine refuses to use anything newer than redhat 6.2 - there's special old hardware which doesn't have drivers for kernel 2.4...)
Alexandre Strube wrote:
Em Seg, 2004-01-12 às 08:33, WipeOut escreveu:
Anyone close to the development of FC would probably be the best to answer this..
Fedora-devel list :-)
(...)
upgrade meaning that as updates and upgrades happen the community can simply use YUM or a similar app to stay current.. I know that YUM can
Its a simple change on sources.list if you use apt or yum.conf if you use it.
The matter is: not every single person wants to upgrade immediately. There are production server which can handle the upgrade of some packages but not a whole system, with kernel, gcc and almost everything else changing versions. So doing this by default is not a bad idea.
If a server is running an app that requires a particular version of some package then I agree that the system would maybe not work fo that scenario, but those packages may be able to be excluded from the update list.. for everyone else, especially those running standard software I still think its a good idea.. :)
I've tried this once, with redhat8 to a preliminar version for 9. It screwed a litlle server, and made me be a little more cautious about this...
This is the point, if it was a standard practice then maybe it would not screw up the system..
As you can see sometimes here, there are people which is still using redhat 7 - that's not uncommon. (in fact, a client of mine refuses to use anything newer than redhat 6.2 - there's special old hardware which doesn't have drivers for kernel 2.4...)
I still run a RH7.2 as a webserver on one of my servers (although I am going to have to look at upgrading soon since there are no more security updates for 7.x) so I know what you are saying on this score.. :)
On Mon, 2004-01-12 at 05:33, WipeOut wrote:
Since the release interval between releases as so short (FC1 -> FC2 = 5Months) has any thought been given to maybe putting a structure in place that would allow initial installs to be performed by downloading the major release ISO's and then from there simply have a rolling upgrade meaning that as updates and upgrades happen the community can simply use YUM or a similar app to stay current.. I know that YUM can already perform and upgrade or update and most times it is sucessful but if the development community had this type of functionality in mind it would mean that the short release cycle would not be as much of a crisis for people using Fedora.. This is how "One Base Linux" appear to do it..
While this is one way of testing upgrading (via apt/yum/whatever), it's also not testing the new/newer/upgraded installer (anaconda) and how a new install or upgraded install works from the get go.
WipeOut said:
Since the release interval between releases as so short (FC1 -> FC2 = 5Months) has any thought been given to maybe putting a structure in place that would allow initial installs to be performed by downloading the major release ISO's and then from there simply have a rolling upgrade meaning that as updates and upgrades happen the community can simply use YUM or a similar app to stay current..
This idea falls apart pretty quickly depending on what is being upgraded. Looking at the devel list, for example, Python is going to be upgraded in FC2. Yum is based on Python, and Yum needed recompiled for the new version. Now with an Anaconda based install who cares. You aren't using the installed system for anything during the upgrade process. However, if you are trying to use the Python tools to upgrade the system you are going to see major headaches.
People have done this in the past with other updates (8 -> 9 or 9 -> FC1), but it has always been on the assumption of "if it breaks, you get to keep the pieces".
William Hooper wrote:
WipeOut said:
Since the release interval between releases as so short (FC1 -> FC2 = 5Months) has any thought been given to maybe putting a structure in place that would allow initial installs to be performed by downloading the major release ISO's and then from there simply have a rolling upgrade meaning that as updates and upgrades happen the community can simply use YUM or a similar app to stay current..
This idea falls apart pretty quickly depending on what is being upgraded. Looking at the devel list, for example, Python is going to be upgraded in FC2. Yum is based on Python, and Yum needed recompiled for the new version. Now with an Anaconda based install who cares. You aren't using the installed system for anything during the upgrade process. However, if you are trying to use the Python tools to upgrade the system you are going to see major headaches.
I agree that this scenario is possible but (and I may be wrong) aren't most scripting languages usually backwards compatible in that a script created for an older version of the scripting language would usually still run on the newer vertsion..
People have done this in the past with other updates (8 -> 9 or 9 -> FC1), but it has always been on the assumption of "if it breaks, you get to keep the pieces".
This is the point, to try and get to a point where the chances of ending up with pieces is far less likely since the people in the know have tried to avoid a situation that would cause the system to break from an inplace upgrade using YUM or similar..
Later..
WipeOut said:
I agree that this scenario is possible but (and I may be wrong) aren't most scripting languages usually backwards compatible in that a script created for an older version of the scripting language would usually still run on the newer vertsion..
As I said, an example. Looking at the Rawhide yum changelog:
- patch to work with python 2.3 from Seth
So maybe it was a yum issue, not a python issue. You still get the same result: a broken yum.
Another example would be any incompatable change with glibc because that would kill rpm.
This is the point, to try and get to a point where the chances of ending up with pieces is far less likely since the people in the know have tried to avoid a situation that would cause the system to break from an inplace upgrade using YUM or similar..
I don't disagree that the problem can be lessened, just that in some cases it may unavoidable.
On Mon, 12 Jan 2004, William Hooper wrote:
WipeOut said:
I agree that this scenario is possible but (and I may be wrong) aren't most scripting languages usually backwards compatible in that a script created for an older version of the scripting language would usually still run on the newer vertsion..
As I said, an example. Looking at the Rawhide yum changelog:
- patch to work with python 2.3 from Seth
So maybe it was a yum issue, not a python issue. You still get the same result: a broken yum.
Another example would be any incompatable change with glibc because that would kill rpm.
I think that's a pretty weak argument given that other distros have had no problem with similar things for quite some time. Given that fedora is without-warranty anyway, you don't have to worry about it causing complaints. Maybe don't make it the default, but I think for fedora to be acceptable to many people it will have to be able to do rolling upgrades sanely.
From: "William Hooper" whooperhsd3@earthlink.net
WipeOut said:
Since the release interval between releases as so short (FC1 -> FC2 = 5Months) has any thought been given to maybe putting a structure in place that would allow initial installs to be performed by downloading the major release ISO's and then from there simply have a rolling upgrade meaning that as updates and upgrades happen the community can simply use YUM or a similar app to stay current..
This idea falls apart pretty quickly depending on what is being upgraded. Looking at the devel list, for example, Python is going to be upgraded in FC2. Yum is based on Python, and Yum needed recompiled for the new version. Now with an Anaconda based install who cares. You aren't using the installed system for anything during the upgrade process. However, if you are trying to use the Python tools to upgrade the system you are going to see major headaches.
So, if I am reading you correctly, Fedora Core users are going to have one of four options from now on:
1) Re-install their servers from scratch, every 5-6 months.
2) Try to go it alone on an upgrade path that is not supported, and pray that they can keep their server somewhat stable in some arcane way.
3) Stick with their current FC1 and try to keep up to date on all of the security fixes themselves, since they won't be supported for but an additional 2 months or so.
4) Forget about it and allow the bad guys to hack into their system when the next big security hole is found.
Does that about sum it up?
As an addendum...is Redhat forcing Fedora Core into a too-rapid release cycle in order to force people to purchase their RHEL offerings? It sure feels that way to me...
Ben
Benjamin J. Weiss said:
This idea falls apart pretty quickly depending on what is being upgraded. Looking at the devel list, for example, Python is going to be upgraded in FC2. Yum is based on Python, and Yum needed recompiled for the new version. Now with an Anaconda based install who cares. You aren't
^^^^^^^^^^^^^^^^^^^^^^ [snip]
So, if I am reading you correctly, Fedora Core users are going to have one of four options from now on:
[snip]
Umm... how about:
5) Put the CD in and do an upgrade.
Maybe I didn't make clear enought that the problem is trying to upgrade tools/libraries that the upgrade program is trying to use. When doing and Anaconda based install (upgrade), the installer is using it's own environment, not the environment of the installed system.
On Mon, 12 Jan 2004, William Hooper wrote:
Benjamin J. Weiss said:
This idea falls apart pretty quickly depending on what is being upgraded. Looking at the devel list, for example, Python is going to be upgraded in FC2. Yum is based on Python, and Yum needed recompiled for the new version. Now with an Anaconda based install who cares. You aren't
^^^^^^^^^^^^^^^^^^^^^^[snip]
So, if I am reading you correctly, Fedora Core users are going to have one of four options from now on:
[snip]
Umm... how about:
- Put the CD in and do an upgrade.
Maybe I didn't make clear enought that the problem is trying to upgrade tools/libraries that the upgrade program is trying to use. When doing and Anaconda based install (upgrade), the installer is using it's own environment, not the environment of the installed system.
Given the track record with redhat of how often upgrades go wrong, and the fact that such an upgrade requires more downtime, I think a lot of people will worry about that.
Is fedora there to provide a good distro to users, or to exploit users to redhat's commercial benefit?
Given the track record with redhat of how often upgrades go wrong, and the fact that such an upgrade requires more downtime, I think a lot of people will worry about that.
Is fedora there to provide a good distro to users, or to exploit users to redhat's commercial benefit?
--
Sam Barnett-Cormack Software Developer | Student of Physics & Maths UK Mirror Service (http://www.mirror.ac.uk) | Lancaster University
Is it just me or do others get the sense that some people on this list feel that the fedora developers owe us a stable, easy to use, easy to upgrade, rock solid distro?
Fedora as a community distro is only as good as the community.
Have you tested the upgrade path? Have you donated money, or time in a meaningful way to make sure fedora has a clear and bug free upgrade path? If not then I wouldn't be complaining about the upgrade capabilities.
On Mon, 12 Jan 2004, Gene Delitzoy wrote:
Given the track record with redhat of how often upgrades go wrong, and the fact that such an upgrade requires more downtime, I think a lot of people will worry about that.
Is fedora there to provide a good distro to users, or to exploit users to redhat's commercial benefit?
Is it just me or do others get the sense that some people on this list feel that the fedora developers owe us a stable, easy to use, easy to upgrade, rock solid distro?
Fedora as a community distro is only as good as the community.
Indeed, and it should also serve the community as well. This is the point I was attempting to make
Have you tested the upgrade path? Have you donated money, or time in a meaningful way to make sure fedora has a clear and bug free upgrade path? If not then I wouldn't be complaining about the upgrade capabilities.
I wasn't complaing about what is there now - that's not important, as fedora is just starting out. I was complaining about the proposed paths - people (and I don't know where they stand in the community) were saying "we can't do that, won't do that, shouldn't have to do that, what's the point?" - I was pointing out the point.
As it is, I'd love to contribute to development of the distro, but that'd mean I need a spare machine to do it on, and my financial situation is far from rosy.
Fedora as a community distro is only as good as the community.
Indeed, and it should also serve the community as well.
To what extent and for how long? At some point you as an individual will be rolling your own packages or relying on a third party if the core needs to move on for others. Fedora is set up to accommodate this.
As many distros have shown you can't be all things to all people. You can only stretch Fedora so far before it becomes something else, and starts to suffer in other ways.
Should Red Hat be willing continue to devote resources longer than you are on a joint project? If this is a community project, relying on community contribution at some point is going to happen.
--jeremy
Em Seg, 2004-01-12 às 14:50, Sam Barnett-Cormack escreveu: (...)
As it is, I'd love to contribute to development of the distro, but that'd mean I need a spare machine to do it on, and my financial situation is far from rosy.
It's not easy for anyone. If its difficult in UK, think about it in the so-called third world, were salaries are a fraction of yours.
Anyway, I took the saturday afternoon to contribute, and everyday I contribute to brazilian openoffice... And I'm preety sure that the 600 dollars monthly that my bosses pays me is way less than yours.
On Mon, 12 Jan 2004, Alexandre Strube wrote:
Em Seg, 2004-01-12 às 14:50, Sam Barnett-Cormack escreveu: (...)
As it is, I'd love to contribute to development of the distro, but that'd mean I need a spare machine to do it on, and my financial situation is far from rosy.
It's not easy for anyone. If its difficult in UK, think about it in the so-called third world, were salaries are a fraction of yours.
Anyway, I took the saturday afternoon to contribute, and everyday I contribute to brazilian openoffice... And I'm preety sure that the 600 dollars monthly that my bosses pays me is way less than yours.
The time isn't a problem, it's the physical resources. I have 1 computer capable of running a modern distro, and that's my workstation. I can't risk that by experimenting with a development version, which would be necessary to contribute.
Oh, and I earn UKP256 in a good month.
as per the Red Hat wish list for Fedora, they mean to make it a "General Purpose" OS for everyones need. But will it really be ? They and Fedora Project has clearly mentioned that the releases will be on bleeding edge release of packages. Doesn't it seem to be a all time Beta OS ( Or I should say Red Hat Beta Release). It doesn't have a structure like Debian of having stable, testing and unstable which IMHO should be.
ritesh
On 12 Jan 2004, Gene Delitzoy wrote:
Given the track record with redhat of how often upgrades go wrong, and the fact that such an upgrade requires more downtime, I think a lot of people will worry about that.
Is fedora there to provide a good distro to users, or to exploit users to redhat's commercial benefit?
--
Sam Barnett-Cormack Software Developer | Student of Physics & Maths UK Mirror Service (http://www.mirror.ac.uk) | Lancaster University
Is it just me or do others get the sense that some people on this list feel that the fedora developers owe us a stable, easy to use, easy to upgrade, rock solid distro?
Fedora as a community distro is only as good as the community.
Have you tested the upgrade path? Have you donated money, or time in a meaningful way to make sure fedora has a clear and bug free upgrade path? If not then I wouldn't be complaining about the upgrade capabilities.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
rrs_rhlist@softhome.net said:
They and Fedora Project has clearly mentioned that the releases will be on bleeding edge release of packages.
"leading edge" is not the same as "bleeding edge".
Doesn't it seem to be a all time Beta OS ( Or I should say Red Hat Beta Release).
"Yeah, I'm mean it's been so horrible when they released three betas before a release. It felt like I was beta testing all the time..."
Please. The OS has had one, for the vast majority of the people, stable release. If you choose to upgrade to packages in development then you expect to loose stability. So far the release cycle doesn't seem to be much faster than Red Hat Linux used to have.
On Mon, 12 Jan 2004 rrs_rhlist@softhome.net wrote:
as per the Red Hat wish list for Fedora, they mean to make it a "General Purpose" OS for everyones need. But will it really be ? They and Fedora Project has clearly mentioned that the releases will be on bleeding edge release of packages. Doesn't it seem to be a all time Beta OS ( Or I should say Red Hat Beta Release). It doesn't have a structure like Debian of having stable, testing and unstable which IMHO should be.
OBTopPostComment: Please don't.
But I echo your thoughts... The dizzying rate of updates that I've been subjected to is really quite too much. What was it, 4 kernal updates within a spam of 7 or 10 days?
Xine is broken on one of my two machines because of these updates, and that seems par for the course.
I'd switch to Debian now, but I'm not quite enough of a geek to figure out the install stage *and* get everything working correctly. (It doesn't have a nice install interface... Manually entering your monitors synch rates? C'mon... Sure, it gives you extra flexability, but for someone who doesn't know quite which way is up, you get lost and bungle the install. So you end up with an incorrectly compiled kernal. (Which happened to me...)) I have a feeling I'd have the same problems with Gentoo, otherwise I'd go that route.
If a Fedora Stable release were made, I'd jump on it in a heartbeat. But I don't see that in the works. In the meantime, I'll keep poking around and searching. Hopefully I'll find something soon that works.
(Mandrake has issues with an optical wheel mouse. If it can't get that much done, why should I trust it enough to buy a new mouse to work with the package? Besides, with the troubles in Mandrake's future, I don't know that that's a route I want to go.) SuSE was a nightmare to compile anything, but you've seen those rants...)
You get the idea.
Fedora Stable would be a *really* good idea. I know other users who've left to other distros for this very reason....
Krikket
Krikket said:
But I echo your thoughts... The dizzying rate of updates that I've been subjected to is really quite too much. What was it, 4 kernal updates within a spam of 7 or 10 days?
Two within 2 days, actually.
https://www.redhat.com/archives/fedora-announce-list/2004-January/thread.htm...
Xine is broken on one of my two machines because of these updates, and that seems par for the course.
Bugzilla ID?
On Mon, 12 Jan 2004, William Hooper wrote:
Krikket said:
But I echo your thoughts... The dizzying rate of updates that I've been subjected to is really quite too much. What was it, 4 kernal updates within a spam of 7 or 10 days?
Two within 2 days, actually.
https://www.redhat.com/archives/fedora-announce-list/2004-January/thread.htm...
Xine is broken on one of my two machines because of these updates, and that seems par for the course.
Bugzilla ID?
I know bugzilla is a bug tracking system, but if I don't know what part of the updagte cycle broke it, how can I reliably report it?
Real life happens outside of Bugzilla, ya know...
Krikket
Krikket said:
Xine is broken on one of my two machines because of these updates, and that seems par for the course.
Bugzilla ID?
I know bugzilla is a bug tracking system, but if I don't know what part of the updagte cycle broke it, how can I reliably report it?
Did you post for help to track it down? I mean, if it broke two machines it was either repeatable or user error.
Real life happens outside of Bugzilla, ya know...
"If it's not in bugzilla, it doesn't exist."
Don't expect unreported bugs to magically get fixed.
On Tue, 13 Jan 2004, William Hooper wrote:
Krikket said:
Xine is broken on one of my two machines because of these updates, and that seems par for the course.
Bugzilla ID?
I know bugzilla is a bug tracking system, but if I don't know what part of the updagte cycle broke it, how can I reliably report it?
Did you post for help to track it down? I mean, if it broke two machines it was either repeatable or user error.
Real life happens outside of Bugzilla, ya know...
"If it's not in bugzilla, it doesn't exist."
Don't expect unreported bugs to magically get fixed.
Well, it exposes it to a wider area of users, and lets me know if the problem is widespread or not. So information was gained, even if it's only by a lack of data.
I also note, you didn't answer my question -- If I don't know what broke it, how can it be reliably reported? Doesn't it become more of a crank at that point, rather than a confirmed bug?
Krikket
Krikket said:
I know bugzilla is a bug tracking system, but if I don't know what
part of
the updagte cycle broke it, how can I reliably report it?
Did you post for help to track it down? I mean, if it broke two machines it was either repeatable or user error.
[snip]
I also note, you didn't answer my question -- If I don't know what broke it, how can it be reliably reported? Doesn't it become more of a crank at that point, rather than a confirmed bug?
I repeat:
Did you post for help to track it down? I mean, if it broke two machines it was either repeatable or user error.
The only thread I see where you mention xine is when you were talking about the livna.org Xine (not the FC Xine) and you complain about a newer version of it not working (no mention of FC updates that I see).
Sam Barnett-Cormack said:
Given the track record with redhat of how often upgrades go wrong,
The upgrade on my laptop from RHL9 to FC1 went completely without problems.
and the fact that such an upgrade requires more downtime, I think a lot of people will worry about that.
I would prefer more planned downtime than the downtime that comes from breaking something. All upgrades will require downtime, some more than others. As I said in a previous post, trying to get a distro to upgrade through yum, etc. isn't a bad thing, just as long as people understand that it may not be possible in some cases (like FC1 -> FC2 IMHO). APIs, config files, library versions change, and trying to change these while you are using them can cause Bad Things (tm).
Is fedora there to provide a good distro to users, or to exploit users to redhat's commercial benefit?
You'll have to pardon me for not looking over my shoulder for the black heliocopters...
Fedora IS the community. So the community is there to provide a good distro to the community. You would probably do well to get over the "I'm a user, Fedora owes me..." mentality.
-- William Hooper
On Mon, 12 Jan 2004, William Hooper wrote:
Sam Barnett-Cormack said:
Given the track record with redhat of how often upgrades go wrong,
The upgrade on my laptop from RHL9 to FC1 went completely without problems.
and the fact that such an upgrade requires more downtime, I think a lot of people will worry about that.
I would prefer more planned downtime than the downtime that comes from breaking something. All upgrades will require downtime, some more than others. As I said in a previous post, trying to get a distro to upgrade through yum, etc. isn't a bad thing, just as long as people understand that it may not be possible in some cases (like FC1 -> FC2 IMHO). APIs, config files, library versions change, and trying to change these while you are using them can cause Bad Things (tm).
Your points are well made and valid - I suppose some things are a matter of taste, although those points you make seem to not affect other distros already using the rolling model.
Is fedora there to provide a good distro to users, or to exploit users to redhat's commercial benefit?
You'll have to pardon me for not looking over my shoulder for the black heliocopters...
Fedora IS the community. So the community is there to provide a good distro to the community. You would probably do well to get over the "I'm a user, Fedora owes me..." mentality.
I far from think that, I apologise for any offence I may have caused the developers.
However, I stand by my point that the part of the community doing the development does need to listen to the wishes of the users.
Sam Barnett-Cormack said:
Your points are well made and valid - I suppose some things are a matter of taste, although those points you make seem to not affect other distros already using the rolling model.
Without seeing the docs for those "other distros" it is hard to say. Looking at Debian's FAQ they seem to have some special instructions for at least one case (upgrading libc5 -> libc6) which tell you the order to install some updates and a warning that the rest must be installed all at once. If someone were to take the time to right similar instructions for any issues that arise from a FC1 -> FC2 yum upgrade I'm sure there wouldn't be any objections.
However, I stand by my point that the part of the community doing the development does need to listen to the wishes of the users.
A quick bugzilla search doesn't turn up an RFE, so when you enter one please post the ID to the list so interested parties can add themselves to the CC: list.
"If it's not in bugzilla, it doesn't exist."
Sam Barnett-Cormack wrote:
On Mon, 12 Jan 2004, William Hooper wrote:
Sam Barnett-Cormack said:
Given the track record with redhat of how often upgrades go wrong,
The upgrade on my laptop from RHL9 to FC1 went completely without problems.
and the fact that such an upgrade requires more downtime, I think a lot of people will worry about that.
I would prefer more planned downtime than the downtime that comes from breaking something. All upgrades will require downtime, some more than others. As I said in a previous post, trying to get a distro to upgrade through yum, etc. isn't a bad thing, just as long as people understand that it may not be possible in some cases (like FC1 -> FC2 IMHO). APIs, config files, library versions change, and trying to change these while you are using them can cause Bad Things (tm).
Your points are well made and valid - I suppose some things are a matter of taste, although those points you make seem to not affect other distros already using the rolling model.
Is fedora there to provide a good distro to users, or to exploit users to redhat's commercial benefit?
You'll have to pardon me for not looking over my shoulder for the black heliocopters...
Fedora IS the community. So the community is there to provide a good distro to the community. You would probably do well to get over the "I'm a user, Fedora owes me..." mentality.
I far from think that, I apologise for any offence I may have caused the developers.
However, I stand by my point that the part of the community doing the development does need to listen to the wishes of the users.
(poking my hideous great hooter into this)... As the manager of over 600 servers (and fully half being Linux), I find that the risks of upgrading a "live" machine far outweigh the downtime of doing it offline. While the hiccups we've experienced have been fairly benign, several took longer to sort out than any downtime we may have saved by doing a live update.
Do what you will. I think one is playing with a loaded gun when one upgrades a busy machine. At the very minimum, it should be at single user mode with as many daemons shut down as possible. It should be taken off the network if possible, upgraded, CHECKED (iptables, etc.), and only then put back up and online.
However, as Dennis Miller says, "That's just my opinion. I could be wrong." ---------------------------------------------------------------------- - Rick Stevens, Senior Systems Engineer rstevens@vitalstream.com - - VitalStream, Inc. http://www.vitalstream.com - - - - BASIC is the Computer Science version of `Scientific Creationism' - ----------------------------------------------------------------------
Benjamin J. Weiss wrote:
So, if I am reading you correctly, Fedora Core users are going to have one of four options from now on:
Re-install their servers from scratch, every 5-6 months.
Try to go it alone on an upgrade path that is not supported, and pray
that they can keep their server somewhat stable in some arcane way.
- Stick with their current FC1 and try to keep up to date on all of the
security fixes themselves, since they won't be supported for but an additional 2 months or so.
- Forget about it and allow the bad guys to hack into their system when the
next big security hole is found.
Does that about sum it up?
As an addendum...is Redhat forcing Fedora Core into a too-rapid release cycle in order to force people to purchase their RHEL offerings? It sure feels that way to me...
Thats what I put on the end of my original mail, that the ability to easily migrate from one release to the next may be blocked by RH since its one of their major selling points for RHEL..
I am sure a structure could be put in place where seemless migration from one relase to the next could be achived.. even do awat with releases all together and simply use snapshots to install new systems and then just keep the system current from then on with no need to "upgrade" the whole system ever..
later..
Hey on your Listing your forgot one major option:
5) Switch to another distribution ;)
Patrick
Am Mon, 2004-01-12 um 15.49 schrieb WipeOut:
Benjamin J. Weiss wrote:
So, if I am reading you correctly, Fedora Core users are going to have one of four options from now on:
Re-install their servers from scratch, every 5-6 months.
Try to go it alone on an upgrade path that is not supported, and pray
that they can keep their server somewhat stable in some arcane way.
- Stick with their current FC1 and try to keep up to date on all of the
security fixes themselves, since they won't be supported for but an additional 2 months or so.
- Forget about it and allow the bad guys to hack into their system when the
next big security hole is found.
Does that about sum it up?
As an addendum...is Redhat forcing Fedora Core into a too-rapid release cycle in order to force people to purchase their RHEL offerings? It sure feels that way to me...
Thats what I put on the end of my original mail, that the ability to easily migrate from one release to the next may be blocked by RH since its one of their major selling points for RHEL..
I am sure a structure could be put in place where seemless migration from one relase to the next could be achived.. even do awat with releases all together and simply use snapshots to install new systems and then just keep the system current from then on with no need to "upgrade" the whole system ever..
later..
Patrick W. Fraley wrote:
Hey on your Listing your forgot one major option:
- Switch to another distribution ;)
This is also a problem..
Suse don't distribute ISO's which is frikken irritating when testing and breaking, the enterprise versions are more expensive than RHEL.. In fact its almost cheaper to buy MS products for web servers and the like bacasue it would probably be cheaper then RHEL or Suse enterprise.. Although out of pricipal I will not use any MS products but many would..
Mandrake is just not cutting it IMO.. especially as a server..
Debian is outdated and a nightmare to install..
Slackware and Gentoo are to difficult to effectively maintain for most of us since they are based on source packages..
Which really just leaves the smaller distros the best of which looks to be Trustix, which I am currently playing with for my new system..
Later..
WipeOut wrote:
Patrick W. Fraley wrote:
Hey on your Listing your forgot one major option:
- Switch to another distribution ;)
This is also a problem..
Suse don't distribute ISO's which is frikken irritating when testing and breaking, the enterprise versions are more expensive than RHEL.. In fact its almost cheaper to buy MS products for web servers and the like bacasue it would probably be cheaper then RHEL or Suse enterprise.. Although out of pricipal I will not use any MS products but many would..
Mandrake is just not cutting it IMO.. especially as a server..
Debian is outdated and a nightmare to install..
Slackware and Gentoo are to difficult to effectively maintain for most of us since they are based on source packages..
Which really just leaves the smaller distros the best of which looks to be Trustix, which I am currently playing with for my new system..
Later..
I sat through a presentation with Novell and IBM back in November where I tabled the issue of SuSE not having ISOs available. They said that they would be making ISOs available in the future but wouldn't say when. I guess we have to wait for the Novell acquisition of SuSE to complete before I ask them again.
Can someone tell me what the difference is between SuSE Linux Professional 9.0 and SuSE or Red Hat Enterprise versions? I built a server with FC1 when it was released but changed to SuSE because of initial problems with FC1. SuSE Pro 9 cost $ 90 at the local Best Buy and included 5 CDs and a dual sided DVD.
So, if I am reading you correctly, Fedora Core users are going to have one of four options from now on:
- Re-install their servers from scratch, every 5-6 months.
Upgrades should work fine.
- Try to go it alone on an upgrade path that is not supported, and pray
that they can keep their server somewhat stable in some arcane way.
If you are speaking of production use, folks are already going it alone on a platform that is not supported. The way the Fedora project is set-up, though, allows for projects like Fedora Legacy to emerge and focus on issuing errata for legacy releases.
As an addendum...is Redhat forcing Fedora Core into a too-rapid release cycle in order to force people to purchase their RHEL offerings? It sure feels that way to me...
So far releases haven't happened (or get scheduled to happen) any faster than RHL, though they are now free to happen when deemed necessary. But how fast the core releases is not the same as determining how long the core is maintained by Red Hat, which is not the same as how long it may be maintained by 3rd party projects and individual contributors.
Product and technical support for Fedora is up to the Fedora community to provide as well as use. You will always get out of it what you put in.
--jeremy
Ben
-
Alexandre Strube -
Benjamin J. Weiss -
Gene Delitzoy -
Jeremy Hogan -
Krikket -
Mike Chambers -
Patrick W. Fraley -
Rick Stevens -
rowan -
rrs_rhlist＠softhome.net -
Sam Barnett-Cormack -
William Hooper -
WipeOut