Slashdot Mirror
Red Hat 9 To Be Released March 31
Garfunkel writes "Looks like Red Hat is breaking tradition and skipping 8.1 and 8.2 and jumping directly to 9.0 RHN subscribers
get it a week ahead on March 31st. Available to the rest the world a week
later (April 7)." The website refers to the upcoming release simply as "9" -- which doesn't rule out future point releases, but could it be?
Phoebe (8.0.94) has 2.4.20 (too many versions!!!)... it includes the O(1) scheduler and some latency patches... the desktop is really quite snappy (X 4.3 will be included, Phoebe is working off a pre-4.3 snapshot). I hope 9 includes Nautilus 2.2.2 because the GNOME team added some speed increases there too.
Anyways, the nVidia drivers (the kernel module component) needs some changes to be able to run on the beta (they're available, but not from nvidia directly), but I suspect nVidia will have this released shortly after RH9. Additionally, some third-party stuff will have to be relinked, because of thread local storage stuff and the new NTPL -- Redhat backported a lot of stuff from the 2.5 series. Hence the 9.0 release (IMHO) since an 8.1 release would seem to imply that it's relatively backwards-compatible. It seems there are too many low-level interface changes to justify a point release.
Some drivers are already ready for the 2.5 kernel (as ready as you can get for software-in-progress), so you just need to hack the version numbers a little bit to get it to compile properly -- for example, the PowerVR drivers. Specifically, the VM API has changed quite a bit, so when RH backported these changes, they got the new API as well.
The beta looks really nice though, especially with GNOME 2.2. And CD burning is integrated in Nautilus (drag-and-drop, then click the burn icon, and it writes it to disc). Very nice stuff is on its way...
I submitted a story on this prior to this one, but the gyst is this: Due to this move, anyone who wants to use RHN still will have 3 options:
install RH9 on their systems, overwriting whatever OS was there. Problems: long downtime to install OS then re-set everything up, depending on a X.0 release for everything
"upgrade" current systems to RH9. In my experience, longer downtime than just doing a clean install - things break, get annoying, etc.
hack their systems to look, act, and talk like RH9 systems tothe RHN update software, so you can still update them through RHN
personally, I think I'll just let this year be the last year I'm subscribed to RHN, then either get my updates from someone else (redcarpet?) or I'll just mirror the ftp://updates.redhat.com server locally and run my own service. I don't see any of those 3 above options working for me. Has RedHat gone insane? Do they not realize people count on linux in an enterprise environment, where anything beyond a few minutes downtime is very bad??
Red Hat bases their version numbers on binary compatibility. That is, every point release in a given series is (in theory) binary compatible with all the other point releases in that series.
Red Hat increments the major number when binary compatibility changes. For example, 7.3, 7.2, 7.1, and 7.0 are all back-compatible, but 8.0 and 7.x are not (necessarily.) 8.0 shipped with gcc 3.2, which is what broke binary compatibility.
The problem (to my mind) is that Red Hat is releasing 9, when there was only an 8.0. And that's been, what, 9 - 10 months? As a result, the Red Hat 8.x "binary platform" will be extant for only 9 - 10 months; what's up with that? There are also a number of semi-minor obnoxious bugs and regressions in 8.0 that I expected to be fixed in an 8.1.
Apparently they broke binary compatibility when I wasn't looking. Guess I should have followed the betas more closely.
I suppose it's also possible that Red Hat has chosen to deviate from the binary-compatibilty benchmark they've been using.
I've been using the beta version of this for a month now. Phoebe is the name of the beta if anyone is interested in seeing what might be changed as of the last update.
My impressions as a person who uses this as a desktop at home and is normally a Mandrake kind of user:
It is a very easy to use and install and stable distro. I don't like that they include almost no configuration tools. To make it a good desktop distro I had to download a lot of extra rpms because the cd's with the distro are packed with server/workstation rpms. Also, though not RedHat's fault, NVidia's glx driver doesn't work properly with the new kernel and some weird dis-optimizations to the code have to be done in order for it to work (as of mid Feb; haven't checked lately). This is an issue with all 2.5 and 2.4.20 and above kernels, IIRC.
It is very similar to 8.0 (but they might have changed some things in the last month). The biggest gripe I have is that they use GRUB as the bootloader, but have no configuration utility for it. I'm a LILO person, but I thought I'd install GRUB to see if it was better. The man pages weren't very helpful and RedHat includes nothing to help, either. I went back to LILO, but since RH has no priority for it, there was no graphical options for LILO, just text.
It works for what it is supposed to work for: servers and workstations. As a desktop user that wants to have a simple and easy distro, I switched to Mandrake 9.1 rc1.
IANAL, but I play one on
yet somehow I was able to compile and run apache 1.3.27 and 2.0.44 on a RedHat 8.0 system..... /me yawns..
just more fud from the Anonymous Coward.. man.. that bastard posts alot..
You bring up an excellent point - and you're along the right track. If we examine the features of Red Hat Linux 8.0.9x (Phoebe beta), we notice that several things have been added to the OS that will set it apart from previous releases. You can find the changes (so far) to Red Hat Linux 9.0 in the release notes of Phoebe:
o s/ i386/RELEASE-NOTES
g i? id=86498o w_bug.cgi? id=86465o w_bug.cgi? id=86449
http://rpmfind.net/linux/redhat/beta/phoebe/en/
I think the two major updates that will definitely warrant a few "major" number upgrade will be the following:
1) glibc update from the 2.2 development branch to the 2.3 branch; the major feature would be the addition of the NPTL (Native POSIX Thread Library).
The release notes cite that legacy (LinuxThreads) applications will work with NPTL if and only if they conform to the POSIX standard.
2) The new and improved XFree86 4.3 (usability, eye-candy, performance, drivers, et al.).
3) Extended attributes (EA) and access control lists (ACL) finally come to Red Hat's distribution - giving per-file control par with NT and other OSes that have already had EA and ACL.
4) The inclusion of Gnome 2.2 fine tunes Gnome 2.0 to a better degree.
So far, the glibc update (which seems to branch off the glibc that is shipping with Red Hat Linux 9.0) that was given to Red Hat Linux 8.0 users seems to be wreaking havoc with regards to threads implementations; a few examples:
https://bugzilla.redhat.com/bugzilla/show_bug.c
https://bugzilla.redhat.com/bugzilla/sh
https://bugzilla.redhat.com/bugzilla/sh
It should be noted that Red Hat has been extraordinarly adept with the inclusion of compatibility packages to allow legacy applications to continue working with their newest offering.
Ayup
Not quite. An RHCE is good for two MAJOR releases. So your 7.2 cert is good for 8.* and 9.*. My 8.0 cert is good for 9.* and 10.*.
Still kinda sucks that the 8.* series ended so quickly though, certifcation-wise.
"The cost of freedom is eternal vigilance." -Thomas Jefferson
Subject: Red Hat Linux 9 | Get the latest Linux early
Dear Dirk:
You may know that Red Hat Network is the best way to keep your
systems running the latest errata and always up to date. What you
might not know is that Red Hat Network passed the one million users
mark earlier this year. We've listened to valuable feedback and have
added two items of interest to keep those users happy - early release
of Red Hat Linux 9 ISOs and improved technical support.
Beginning March 31, 2003, paid subscribers to Red Hat Network will
have access to Red Hat Linux 9 ISOs - a full week before retail store
and Red Hat FTP availability. Also, Red Hat Network subscribers will
receive dedicated Red Hat Network Technical Support.
Learn more about the benefits of being a Red Hat Network Subscriber:
http://redhat.chtah.com/
To purchase a Red Hat Network subscription:
http://redhat.chtah.com/
Thanks again for using Red Hat Linux. We appreciate all feedback
from our users and hope you enjoy Red Hat Linux 9.
Sincerely,
Red Hat
--
The above email is intended for people who have opted-in to receiving
email from Red Hat. If you think that you have received this email in
error, please accept our apologies. Simply click on the link in the
section below and we'll make sure you do not receive this kind of
email from Red Hat again.
http://redhat.chtah.com
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
Well, ... install Red Hat Linux 8.1beta3 and see it by yourself. More good GUI tools as usual. Many things have been improved.
n0dez
==
http://www.n0dez.com/
Well another nail in the coffin.
RH8 has an EOL of 12/31/03 and this new version will give me an EOL of 03/31/04. I got several clients running RH 7&8 that I was looking at moving off to other distros or I upgrade NOW to RH9 and delay the next "forced" upgrade for 3 months. This is not going to encourage me to stay with RH. We need longer EOL times.
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
Ximian Desktop for single-users probably isn't a big money maker.
These days, Ximian seems to be focusing on three main products:
- The mono project, which isn't exclusivly Ximian but could give Ximian a big advantage c#/.NET arena, and incorporating Ximian Desktop
- Their RedCarpet Enterprise manager
- Evolution and other projects for some of the bigger *nix's like HP-UX and Solaris.
Those bigger contracts are probably the only thing keeping Ximian alive at the moment.
"Can of worms? The can is open... the worms are everywhere."
RH upgrades have always gone very well for me.
/etc (at the very least, and maybe /home) before upgrading, just in case.
/etc that end in .rpmnew or .rpmsave, using something like "find /etc -name *.rpm*". .rpmnew files are newly-installed configuration files that conflict with your existing copy and have thus been renamed. .rpmsave files are a backup of your existing configuration file that has now been replaced.
.rpmnew should be created when your customized configuration file should still be compatible with the new release, and an .rpmsave is used when the new version of the software could have problems with the old configuration file, and you should manually migrate your changes.
Having said that, though, RPM isn't so hot at mixing your customized configuration with the defaults included in new packages, so you should always backup
After the upgrade, do a search for all the files in
I think the logic is that an
You can do something like "diff -u foo.conf.rpmsave foo.conf" to see what the new default configuration file changes compared you yours, or "diff -u foo.conf foo.conf.rpmnew" to see if there are any new configuration options that you might want to adopt.
They're supposedly adjusting the expiration policy, due to the fast major version change. I asked, and there isn't any official statement yet.
People are over-thinking it.
Knocking down pins is the way to win at bowling.
You wouldn't say "Knocking down pins are the way to win" would you?
Downloading is illegal.
Downloading 5 games is illegal.
Downloading a game is illegal.
Downloading a dvd is illegal.
Downloading 5 dvd's is illegal.
You get the idea; this grammar message sponsored by the RIAA and the BSA.
It gets simple if you just try the same sentence structure with a few different words.
BSD systems make great servers, but they make only so-so desktop systems. Most disgruntled RH users are better off trying Mandrake.
You can make your own RH8.0 DVD iso... There are good instructions listed here: http://www.rickertweb.com/~justin/linux/Make_RedHa t_DVD_From_CDROM.html
You may want to take a look at Gentoo (www.gentoo.org). Fully customized and has a freebsd-like ports system.
Please don't start comparing RedHat to Microsoft... There are some truths that can clear up a lot of these misconceptions...
1) RedHat releasing this as a major version number is consistent with their numbering schemes in the past and is likely not a marketing plot. RedHat does major number versioning when binary compatibility is broken between versions. The Native POSIX Thread Libraries used in the latest beta Phoebe broke binary compatibility with a lot of applications. Thus, a new major number is warranted.
2) RedHat has an interesting challenge in that it must balance the "release early, release often" philosophy to satisfy those of us who like having cutting edge distros with the need for corporations to have some longevity in their releases. RedHat has found a good balance here. These consumer releases are going to continue to be released every six months to satisfy those who want its raw power. They will continue to be free, and RHN update services will continue to be free (though recently they've asked for about ten seconds of your time to complete a five question marketing survey). These six-month releases will continue to have same QA process as always. RedHat is willing to continue to invest so much into these freely downloadable versions because the feedback they get from them helps them work on the slower release versions. Redhat has said this more than once during a recent thread on the phoebe list.
Please don't start villifying RedHat. They do a lot of good for the whole Linux community, pay many of the best developers of our favorite projects, and give Linux a wider acceptance in the RealWorld (tm) which helps all of us.
-jag
http://starboard.flowtheory.net/
The move to the new thread system has been found to break binary compatibility in some cases, hence the major version change.
Thats what the LSB is for really. If its an LSB compliant distribution the LSB compliant apps should work, whether its numbered 8, 9 or 5001.
Its also why United Linux and Red Hat both have business oriented distributions which change much more slowly.
Alan
The RHCE scheme will be adjusted to reflect the numbering change. If you want more details contact rhcecert@redhat.com.
This should probably have been announced at the same time but wasn't.
You may know about it, but if not, you should try out "apt" for RPM (http://apt.freshrpms.net). It's all of the convenience of Debian with the packages and desktop (which I like :) from RedHat.
;)
Upgarding to the next RedHat release then becomes as easy as:
apt-get update
apt-get dist-upgrade
done
(I updated today, and already began noticing that it was pulling in some new glibc updates and so on.)
The regular ISO's they will see as something nice to do for the community, and have it be the test bed for new features, and the "beta/gamma" release of the upcoming Enterprise series. Then the new enterprise releases will have lots of software that has been tested and released on all kinds of hardware and they will have a very good chance of making a very, very stable release for the enterprise lineup.
Because they have the stable release, I believe you'll see fewer, and fewer X.1 and X.2 releases, and you'll see a lot more .0 releases. Somewhat because it will be enticement to have people buy the Enterprise line, and somewhat to keep the "beta/gamma" testing on the bleeding edge. It's a pretty clever scheme all in all. If they can pull it off, and keep the bugs in the .0 releases down, and put out a .1 to solve big problems in .0, I'll happily use the standard ISO on my desk, and happily pay the money for the Enterprise lineup for my servers.
Kirby
If you want to know the rationalle for the new major version from the horses mouth (a RedHat employee) here is the mailing list post that explains it.
If you don't think they're overly significant changes, how the hell did you become a RHCE? The reasons behind a major version bump are mentioned ALL OVER THE PLACE. AND it's nothing they haven't said since before 5.0. It's binary compatability, pure and simple. It may not look different to *you* since you probably rely on software they ship anyway, but for anyone shipping binaries, it's an altogether different story.
Hint: whenever a release break compatibility with a prior release, it gets a x.0. 9.0 is going to break compat. so they make it 9.0