How long do you think (proper) QA takes? We didn't want to release "yet another buggy.0."
Then, pressing the CDs takes some time, getting them packaged takes some time...
We've gone gold a while before bind 9 has been released, and even if we hadn't, there's no chance anything this different from prior versions could have got in that late in the cycle.
On a different note, I've built 9.0 in the 7.1 tree the day it was released.
While it does its core functionality perfectly, there are still a couple of problems left that wouldn't be tolerated in a Red Hat Linux release.
Especially when running on 2.2 kernels, bind 9 isn't 100% ready yet.
There is still no prediction of when 2.4.0 will be released, and probably we'll have to wait at least for 2.4.2 to get a kernel that is as stable as 2.2.18.
We can't delay the 7.0 release forever (see the KDE thread).
Red Hat Linux 7 is ready for Kernel 2.4 though - just install the kernel and everything will work (we're even including a prerelease rpm).
I'm running Red Hat Linux 7 with 2.4.0 kernels on a couple of machines - no problems so far [on pretty much standard low-end hardware].
Actually, we think KDE 2.0 is very important.
The reason why we've ever had problems with KDE was the non-free nature of the Qt 1.x license - with Qt 2.0 (which is used by KDE 2.0 and can't be used with KDE 1.x), these problems are gone.
Qt 2.2.0 is even GPL (we'd still prefer LGPL, but given Trolltech's business model, it's perfectly clear that it won't happen, and that's ok).
If you've checked the beta, you've probably noticed we had a CVS snapshot of KDE 2 in there - both because of the great features of KDE 2 and because we'd like to get rid of Qt 1.x's license problems.
Unfortunately, it wasn't stable enough for prime time when we had to go gold, so we had to go back to KDE_1_1_BRANCH CVS - and packaged up the current beta for the preview directory.
Moving release dates (especially without knowing for sure when the stuff will finally be ready) would have been a big pain for the business side (I'm not part of that, so I can't give you the exact details, but the basics are obvious).
It'll be in 7.1 (which is already being heavily worked on) unless the planned KDE 2.0 release date is moved by months. (Actually the internal 7.1 build already has a CVS snapshot of KDE 2).
We don't do that sort of stuff. Releasing 2 different 7.0s would be impossible to support.
If anything turns out to be horribly broken (unlikely, aside from a couple of relatively minor bugs, we haven't had any problems with 7.0 yet), we'll make updates for the affected packages available.
It is safe to update from older versions to 7.
We recommend you make a backup of important files as well as your configuration, but I didn't need the backups on any of the boxes I've tried.
The beta was there to fix bugs, not to be perfect.
The KDE issues are most definitely fixed.
I didn't try gnome on an update installation, but if you reported it, I'm quite sure it was fixed.
We've tested this a number of times on a number of very different machines. It works without problems, and preserves your configuration. It even upgrades your inetd.conf to xinetd.
We're using a new glibc (2.2), a new and binary incompatible libstdc++ (gcc 2.96; some ABI changes were required to support more C++ features) as well as a new package format (rpm v4).
If you want to use rawhide packages on older versions of Red Hat Linux or other distributions using rpm, get rpm 3.0.5 or higher (3.0.5 is the first 3.x version that supports rpm v4 packages), get the source rpm and use rpm --rebuild.
That should work in most cases.
Sure - I don't think that there's any distributor
that doesn't watch other distributions and other
similar OSes closely.
It's the nicety of open source - if they come up
with something nice, we can usually take it - and vice
versa.
Which graphics chipset? Which CPU? Did you report it?
We can't fix problems we aren't aware of, and this stuff definitely didn't happen on any of our test machines.
Too bad it will still use KDE 1.
7.1 won't - at the time we had to go gold, KDE 2 simply wasn't ready.
We're including a KDE 2.0 beta on the 2nd CD for people who want to play, though.
Is Redhat even *attempting* to create a nice KDE setup?
I wonder if the redhat kernel will compile with gcc or is this new compiler going to be used by redhat to lock out competitors.
The new compiler actually is gcc, just a newer version of it.
And of course, the kernel will keep on compiling with older compilers.
Actually we're using egcs 1.1.2 to compile the default (2.2.x) kernel because it contains a lot of code that isn't ready for ISO C99 compatible compilers. 2.4.0 is ok, and works perfectly with gcc 2.96 (which we're shipping in Red Hat Linux 7).
TUX is included in the preview directory on the 2nd CD.
It's not ready for prime time yet (and requires kernel 2.4), so it's not part of the default installs.
With Red Hat getting bigger and bigger, you can't put the workload of being CEO and chairman at the same time and holding a lot of speeches about open source on any single person.
What is the deal with this new web server Red Hat is working on?
It'll be released in a while (7.0 actually has a preview).
It's a kernel-based acceleration for serving static pages; the primary benefits are speed and scalability (an 8 CPU system makes a large difference as opposed to a 4 CPU system. It doesn't on some competiting products).
Caldera 2.4 [...] has a lot of what RH 7 has, plus KDE2
What makes you think we don't have KDE2?
We're still using KDE 1.1.2 by default (because it's more stable), but a KDE 2.0 preview is included on the second CD (in the "preview" directory).
7.0 was quite a difficult release to finish since a lot of the basic stuff (compilers, glibc) was still under heavy development.
That's where a number of problems in the beta (not the final, no known bugs yet) are coming from.
Please do report these bugs at Bugzilla - we can't fix problems we aren't aware of, and we won't notice hardware specific problems unless one of us happens to have the same hardware.
Your article was probably rejected because it wasn't news.
We've had a copy of SuSE 7.0 in the Red Hat office for a couple of weeks, and we're usually not the first ones to get them.;)
You're wrong - the story was not a press release, at least not one from Red Hat.
We aren't in the habit of announcing releases before they're done, and it's "Red Hat Linux 7"
as opposed to "Red Hat 7.0". We don't issue press-releases that get the product names wrong.
Here's the other parts they got wrong:
XFree86 4.0 is set to default
This depends entirely on the chipset. XFree86 4.0 is used by default on certain chipsets only.
There are a couple of chipsets where XFree86 4.0 is far less stable than 3.3.6. For those (and those generally not supported by 4.0 [4.0.1 actually]), we're defaulting to 3.3.6.
The article also doesn't mention the two additional versions (special editions of the Deluxe and Professional versions for Europe) which will be out soon(tm).
Nowadays almost anyone can become certified by spending enough money, without even once touching the system that they are certified in
Not everywhere.
Take a look at the RHCE exams - they're 66% practical.
Debugging non-working systems, installing a system that provides certain services, hardening security on that box...
There's no way you can manage it without having used Linux.
Slashdot Mirror
How long do you think (proper) QA takes? We didn't want to release "yet another buggy .0."
Then, pressing the CDs takes some time, getting them packaged takes some time...
We've gone gold a while before bind 9 has been released, and even if we hadn't, there's no chance anything this different from prior versions could have got in that late in the cycle.
On a different note, I've built 9.0 in the 7.1 tree the day it was released.
While it does its core functionality perfectly, there are still a couple of problems left that wouldn't be tolerated in a Red Hat Linux release.
Especially when running on 2.2 kernels, bind 9 isn't 100% ready yet.
Rawhide is by definition a snapshot of our build tree for the next release, so everything that was in rawhide a couple of weeks ago is in there.
;) ) than the stuff in rawhide.
Some stuff in 7.0 is more current (and more fixed
There is still no prediction of when 2.4.0 will be released, and probably we'll have to wait at least for 2.4.2 to get a kernel that is as stable as 2.2.18.
We can't delay the 7.0 release forever (see the KDE thread).
Red Hat Linux 7 is ready for Kernel 2.4 though - just install the kernel and everything will work (we're even including a prerelease rpm).
I'm running Red Hat Linux 7 with 2.4.0 kernels on a couple of machines - no problems so far [on pretty much standard low-end hardware].
Actually, we think KDE 2.0 is very important.
The reason why we've ever had problems with KDE was the non-free nature of the Qt 1.x license - with Qt 2.0 (which is used by KDE 2.0 and can't be used with KDE 1.x), these problems are gone.
Qt 2.2.0 is even GPL (we'd still prefer LGPL, but given Trolltech's business model, it's perfectly clear that it won't happen, and that's ok).
If you've checked the beta, you've probably noticed we had a CVS snapshot of KDE 2 in there - both because of the great features of KDE 2 and because we'd like to get rid of Qt 1.x's license problems.
Unfortunately, it wasn't stable enough for prime time when we had to go gold, so we had to go back to KDE_1_1_BRANCH CVS - and packaged up the current beta for the preview directory.
Moving release dates (especially without knowing for sure when the stuff will finally be ready) would have been a big pain for the business side (I'm not part of that, so I can't give you the exact details, but the basics are obvious).
It'll be in 7.1 (which is already being heavily worked on) unless the planned KDE 2.0 release date is moved by months. (Actually the internal 7.1 build already has a CVS snapshot of KDE 2).
We don't do that sort of stuff. Releasing 2 different 7.0s would be impossible to support.
If anything turns out to be horribly broken (unlikely, aside from a couple of relatively minor bugs, we haven't had any problems with 7.0 yet), we'll make updates for the affected packages available.
It is safe to update from older versions to 7.
We recommend you make a backup of important files as well as your configuration, but I didn't need the backups on any of the boxes I've tried.
The beta was there to fix bugs, not to be perfect.
The KDE issues are most definitely fixed.
I didn't try gnome on an update installation, but if you reported it, I'm quite sure it was fixed.
We've tested this a number of times on a number of very different machines. It works without problems, and preserves your configuration. It even upgrades your inetd.conf to xinetd.
[Red Hat] has been known to ALWAYS have some huge problem in .0 releases
:)
;)
;) Since X is the roman number 10, they must beat MacOS X. ;)
Not this time.
Well, actually we used to, but we found it and fixed it even before the beta.
does this mean slackware needs to make the next version 10?
11 actually.
We're using a new glibc (2.2), a new and binary incompatible libstdc++ (gcc 2.96; some ABI changes were required to support more C++ features) as well as a new package format (rpm v4).
If you want to use rawhide packages on older versions of Red Hat Linux or other distributions using rpm, get rpm 3.0.5 or higher (3.0.5 is the first 3.x version that supports rpm v4 packages), get the source rpm and use rpm --rebuild.
That should work in most cases.
Actually there was an article about it...6 239&mode=thread
http://slashdot.org/article.pl?sid=00/08/01/005
Sure - I don't think that there's any distributor
that doesn't watch other distributions and other
similar OSes closely.
It's the nicety of open source - if they come up
with something nice, we can usually take it - and vice
versa.
Try accessing that great warez server, ftp.redhat.com, some time after Monday. ;)
For some reason X itself took up 71M of memory.
Which graphics chipset? Which CPU? Did you report it?
We can't fix problems we aren't aware of, and this stuff definitely didn't happen on any of our test machines.
Too bad it will still use KDE 1.
7.1 won't - at the time we had to go gold, KDE 2 simply wasn't ready.
We're including a KDE 2.0 beta on the 2nd CD for people who want to play, though.
Is Redhat even *attempting* to create a nice KDE setup?
Sure. That's part of my job, actually.
I wonder if the redhat kernel will compile with gcc or is this new compiler going to be used by redhat to lock out competitors.
The new compiler actually is gcc, just a newer version of it.
And of course, the kernel will keep on compiling with older compilers.
Actually we're using egcs 1.1.2 to compile the default (2.2.x) kernel because it contains a lot of code that isn't ready for ISO C99 compatible compilers. 2.4.0 is ok, and works perfectly with gcc 2.96 (which we're shipping in Red Hat Linux 7).
Yes.
Right.
Red Hat is good news for everyone, them included.
If you reported it, it's fixed.
If it isn't, please take the time to report it.
TUX is included in the preview directory on the 2nd CD.
It's not ready for prime time yet (and requires kernel 2.4), so it's not part of the default installs.
With Red Hat getting bigger and bigger, you can't put the workload of being CEO and chairman at the same time and holding a lot of speeches about open source on any single person.
Bob remains chairman.
What is the deal with this new web server Red Hat is working on?
It'll be released in a while (7.0 actually has a preview).
It's a kernel-based acceleration for serving static pages; the primary benefits are speed and scalability (an 8 CPU system makes a large difference as opposed to a 4 CPU system. It doesn't on some competiting products).
Caldera 2.4 [...] has a lot of what RH 7 has, plus KDE2
What makes you think we don't have KDE2?
We're still using KDE 1.1.2 by default (because it's more stable), but a KDE 2.0 preview is included on the second CD (in the "preview" directory).
7.0 was quite a difficult release to finish since a lot of the basic stuff (compilers, glibc) was still under heavy development.
That's where a number of problems in the beta (not the final, no known bugs yet) are coming from.
Please do report these bugs at Bugzilla - we can't fix problems we aren't aware of, and we won't notice hardware specific problems unless one of us happens to have the same hardware.
Your article was probably rejected because it wasn't news. ;)
We've had a copy of SuSE 7.0 in the Red Hat office for a couple of weeks, and we're usually not the first ones to get them.
You're wrong - the story was not a press release, at least not one from Red Hat.
We aren't in the habit of announcing releases before they're done, and it's "Red Hat Linux 7"
as opposed to "Red Hat 7.0". We don't issue press-releases that get the product names wrong.
Here's the other parts they got wrong:
XFree86 4.0 is set to default
This depends entirely on the chipset. XFree86 4.0 is used by default on certain chipsets only.
There are a couple of chipsets where XFree86 4.0 is far less stable than 3.3.6. For those (and those generally not supported by 4.0 [4.0.1 actually]), we're defaulting to 3.3.6.
The article also doesn't mention the two additional versions (special editions of the Deluxe and Professional versions for Europe) which will be out soon(tm).
Don't underestimate the importance of easy upgrading to 2.4. This will be one of the killer features in 7.0
We're even including a patched 2.4.0test kernel on the second CD in the preview directory for people who need its features and/or want to play.
[root@bero]# uname -r
2.4.0-0.24
[root@bero]# uptime
7:08pm up 43 days, 24 min, 2 users, load average: 4.13, 4.17, 3.38
Nowadays almost anyone can become certified by spending enough money, without even once touching the system that they are certified in
Not everywhere.
Take a look at the RHCE exams - they're 66% practical.
Debugging non-working systems, installing a system that provides certain services, hardening security on that box...
There's no way you can manage it without having used Linux.