I have always wanted a distro in-between long term support and cutting edge.
Say one that uses the kernel/command line part of a long term distro and the gui and gui apps of a cutting edge distro (maybe 1 back from the cutting edge).
An kernel upgrade cycle of say 3 years, but a GUI that stays current within it's release.
-Ross
----- Original Message ----- From: centos-bounces@centos.org centos-bounces@centos.org To: CentOS mailing list centos@centos.org Sent: Wed Jul 30 18:22:36 2008 Subject: Re: [CentOS] Will CentOS 6's upstream be based on Fedora 10?
On Wed, 30 Jul 2008, Kanwar Ranbir Sandhu wrote:
The subject says it all. I'm asking because I've found Fedora 9 to be buggy as hell - it is one of the worst Fedora releases I've ever used (and I've been using it since Fedora Core 1). I'm putting up with it for my work laptop, but it's not fun. :(
My main home machine is still on Fedora Core 6 and will stay there until CentOS 6 comes out. I don't want to use CentOS 5 because it's upstream is based on Fedora Core 6, and I want something new! When CentOS 6 hits, I will be using it for my work laptop.
I might just keep Fedora for home my machine. I haven't decided yet if I want to move up to Fedora 10 or CentOS 6.
If you want something new, why do you think when CentOS 6 comes out it will be new ? And for how long ?
Either you stick with Fedora/Ubuntu and have something new, or you just want to _use_ your computer and go with something less new like CentOS/Ubuntu LTS. There is no middle path.
on 7-30-2008 3:39 PM Ross S. W. Walker spake the following:
I have always wanted a distro in-between long term support and cutting edge.
Say one that uses the kernel/command line part of a long term distro and the gui and gui apps of a cutting edge distro (maybe 1 back from the cutting edge).
An kernel upgrade cycle of say 3 years, but a GUI that stays current within it's release.
Current within the Distro's release, or current to the GUI's release? Cutting edge is sort of the middle. On both sides you have bleeding edge and Enterprise stable. Then on the bottom you have stale and locked
I think the API's and ABI's change radically in the two mainstream GUI's (Gnome and KDE). It would be a juggling act to balance their upgrades and the re-compile and re-download of all the binaries that hook into them. I think Gentoo is much closer to this then anything else, but if you leave a system too long, they can get so out of sync that they won't upgrade through portage anymore. But Gentoo upgrades the kernel along with everything else.
Scott Silva wrote:
I have always wanted a distro in-between long term support and cutting edge.
Say one that uses the kernel/command line part of a long term distro and the gui and gui apps of a cutting edge distro (maybe 1 back from the cutting edge).
An kernel upgrade cycle of say 3 years, but a GUI that stays current within it's release.
Current within the Distro's release, or current to the GUI's release? Cutting edge is sort of the middle. On both sides you have bleeding edge and Enterprise stable. Then on the bottom you have stale and locked
At least with Centos getting a fairly current firefox and OOo in the 5.2 update things aren't quite as stale on the desktop as usual.
I think the API's and ABI's change radically in the two mainstream GUI's (Gnome and KDE). It would be a juggling act to balance their upgrades and the re-compile and re-download of all the binaries that hook into them. I think Gentoo is much closer to this then anything else, but if you leave a system too long, they can get so out of sync that they won't upgrade through portage anymore. But Gentoo upgrades the kernel along with everything else.
Couldn't it be mostly-automated to build a just slightly outdated fedora desktop (everything that depends on the KDE or GNOME libs) on top of an otherwise stock Centos?
Les Mikesell wrote:
Couldn't it be mostly-automated to build a just slightly outdated fedora desktop (everything that depends on the KDE or GNOME libs) on top of an otherwise stock Centos?
I think you may be vastly underestimating the number of packages that would touch, and the amount of integration work involved..
Especially as time goes on, the amount of packages would likely increase as dependencies of the newer things continue to evolve(newer versions etc).
nate
on 7-30-2008 4:29 PM Les Mikesell spake the following:
Scott Silva wrote:
I have always wanted a distro in-between long term support and cutting edge.
Say one that uses the kernel/command line part of a long term distro and the gui and gui apps of a cutting edge distro (maybe 1 back from the cutting edge).
An kernel upgrade cycle of say 3 years, but a GUI that stays current within it's release.
Current within the Distro's release, or current to the GUI's release? Cutting edge is sort of the middle. On both sides you have bleeding edge and Enterprise stable. Then on the bottom you have stale and locked
At least with Centos getting a fairly current firefox and OOo in the 5.2 update things aren't quite as stale on the desktop as usual.
I think the API's and ABI's change radically in the two mainstream GUI's (Gnome and KDE). It would be a juggling act to balance their upgrades and the re-compile and re-download of all the binaries that hook into them. I think Gentoo is much closer to this then anything else, but if you leave a system too long, they can get so out of sync that they won't upgrade through portage anymore. But Gentoo upgrades the kernel along with everything else.
Couldn't it be mostly-automated to build a just slightly outdated fedora desktop (everything that depends on the KDE or GNOME libs) on top of an otherwise stock Centos?
You can get a fairly current KDE from their repo, but it will change base a lot. There are surprisingly a lot of packages in RHEL and CentOS that are linked to libraries that Gnome and KDE change with new versions. So you would either need a bunch of compat-xxx rpms or new binaries of all that. It could be automated, but you better have a good buildserver and someone to test what comes out. And as always, you would get to keep any broken pieces. GTK libs, gnome libs, kde libs all change often. And newer versions are usually tested with newer versions of compilers and base libs, so you would need to update those too. I have seen bugs appear just with new versions of the GCC compiler, and they can be hard to track down.
It would be a project for more than one person, and it would be a busy one for all of them. I see how much work the CentOS team puts in, and they are starting from a fairly complete and tested base. Just imagine if they went in and "poked the bear with a stick" a lot.
If you have the time, give it a try. But be prepared for a lot of work and little help. Long nights and thankless users that whine at everything (it only takes 1 or 2 to get your blood boiling, I've seen it happen here). No free time and no money to pay for hosting bills. Angry wives and children that feel neglected. Bad breath... Warts... Flatulence... The list goes on and on ;-P
On Wed, 2008-07-30 at 16:09 -0700, Scott Silva wrote:
<snip>
Cutting edge is sort of the middle. On both sides you have bleeding edge and Enterprise stable. Then on the bottom you have stale and locked
And in the middle of the two cutting edges is raw meat. It's not the edges that are bleeding, it's the victim in between (or on) the cutting/bleeding edge(s).
One chooses to be a masochist or not.
<snip>
On Thu, Jul 31, 2008 at 3:22 AM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
On Wed, 2008-07-30 at 16:09 -0700, Scott Silva wrote:
Cutting edge is sort of the middle. On both sides you have bleeding edge and Enterprise stable. Then on the bottom you have stale and locked
And in the middle of the two cutting edges is raw meat. It's not the edges that are bleeding, it's the victim in between (or on) the cutting/bleeding edge(s).
One chooses to be a masochist or not.
Oh, wow!
I thought "bleeding edge" was, like, a British curse.
Thanks!
</fake_innocence>
;^)
mhr
Ross S. W. Walker wrote:
I have always wanted a distro in-between long term support and cutting edge
I think Debian's testing branch aims to be this sort of thing, I haven't had a need to run testing in years myself. Stable is good enough for me
http://www.debian.org/releases/testing/
[..]That means that things should not break as badly as in unstable or experimental distributions, because packages are allowed to enter this distribution only after a certain period of time has passed, and when they don't have any release-critical bugs filed against them.
Please note that security updates for testing distribution are not managed by the security team. Hence, testing does not get security updates in a timely manner.
-- If your not upgrading on a very frequent basis I don't think you'd have too many problems. Back when I did run testing for a brief time (about 2001-2002 time frame) I upgraded maybe once every month or two, and never had a problem.
If your system(s) operate in a fairly secure environment, security updates may not be as critical.
There is often a time of brief instability in the testing branch after a stable release comes out when they re-sync with some of the latest packages. During this time it's probably best to stick with the stable branch, and "switch" back to testing after a good 2-3 months for maximum stability. If your apt configuration is pointed at the distribution name(e.g. "lenny") instead of the state (e.g. "testing") you automatically get upgraded to the next stable release when it comes out(and stay on stable until you explicitly reconfigure apt to point to the next testing version).
nate (still working on upgrading RHEL 3 and older RHEL 4 to CentOS 4.6)
-
Les Mikesell -
MHR -
nate -
Ross S. W. Walker -
Scott Silva -
William L. Maltby