Slashdot Mirror
Red Hat 7.2 Released
Spirit writes "Red Hat has anounced the release of Version 7.2 distribution with Gnome 1.4 and Nautilus, default ext3 fliesystem and according to ZDnet migration from LILO to GRUB"
Updated by HeUnique:There are some issues to note before upgrading: The kernel that comes with the RH 7.2 is heavily patched 2.4.7 and has been tested quite heavily on fully loaded Linux boxes - so the recommendation is to use it
If you're upgrading from the previous Red Hat 7.1 and you're using Ximian GNOME, then you might want to erase all Ximian GNOME RPMS (use the command: rpm -e `rpm -qa | grep -i ximian` --nodeps to erase the RPMS). Red Hat's GNOME RPMS has been more tested then Ximian's one and there is a conflict between them. You cannot use Red-Carpet on Redhat 7.2 as it will fail with the RPM libraries.
These are the most critical notes about Redhat 7.2. You might want to read the README & the Release-notes which appears on the 1st ISO image.
Oh, and if you already installed it - then have some fun with the new un-official RPMS from Enigma's section of FreshRPMS
This has been at my local CompUSA (Fairfax, VA) for over a week. Anyone have any ideas as to why?
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
It has been my experience with RH that the .2 releases are the most stable and contains less bugs than the .0 or .1 releases. I've run servers with the 6.2 and the 7.0 release and the 6.2 always provides more stability than the 7.0
Of course I never jump on the bandwagon as soon as something is released. I always wait around for ppl to say something and hear complaints.
The only exception to this is Debian, apt-get upgrade using Sid and haven't had a problem yet ^__^
It's a pity they still use Bind instead of djbdns [cr.yp.to], which is a lot safer.
If you want us to ship djbdns, convince its author to put it under an Open Source license.
The current license is not acceptable.
I'm also surprised about KDE 2.2, since KDE 2.2.1 has been out for quite a while now
KDE is actually pseudo-2.2.1: We took 2.2, and merged all fixes from the stable CVS branch (and a couple of other patches).
Couldn't update to the official 2.2.1 because of the freeze - but the 2.2-* packages in 7.2 have all the fixes from 2.2.1 up to the day before it was released.
The same goes for the kernel version (2.4.7)
Which is actually 2.4.7 plus a lot of bugfixes from later versions, plus ext3, plus new drivers, and more.
Making sure the kernel is highly stable even under extreme load (and longer uptimes) takes time.
This message is provided under the terms outlined at http://www.bero.org/terms.html
Such as?
LILO has been replaced with GRUB. Why?
Because it has a load of advantages we consider more important than staying with what we've shipped forever.
Sometimes switching one working part with another for only minimal gains is NOT a good idea
You are right about this - and since lilo->grub is not minimal, it doesn't apply to this particular thing.
This message is provided under the terms outlined at http://www.bero.org/terms.html
I understand RedHat cannot integrate ipsec / FreeS/WAN into the Linux distribution because of US export restrictions.
Is there an "official" way to upgrade RH 7.2 to a kernel version with ipsec support (i.e. frees/wan) for European folks? The absence of this feature in RH becomes a more and more serious concern for my company.
Of course we know how to patch and compile a kernel. Maintenance must still be easy, though. Installing a custom kernel on several customer servers also means that we cannot use Redhat's update kernel RPMs but must maintain our own ones, so kernel (and possibly other packages) updates get complicated. It will not possible to respond on security issues as quickly as when using RH kernel RPMs.
It would be a great benefit for European customers if RedHat could at least draw the "official" procedure how to make this RH Linux version ipsec capable and then maintain this procedure as new kernel RPM packages or RedHat Linux versions appear.
Is any of this proprietary, or has RH managed to stay comeletely OS?
With the sole exception of Netscape (which will disappear later), it's 100% OS.
And Netscape will disappear with the next release - we're already including Konqueror, Mozilla and Galeon as free (and better) alternatives right now.
Also, what RH specific changes are in this gcc?
It's a stabilized fork of a CVS version. See http://www.bero.org/gcc296.html for a further explanation.
Why isn't gcc-3.01 being distributed? Does it have major issues?
It's included as a preview package, but it's not ready for a standard compiler.
It breaks binary compatibility with the compiler used in prior 7.x releases (which is something we don't do in minor releases), and its C++ part is quite broken ATM (try running a version of KDE that was compiled with gcc 3.0.1 and you'll see what I mean - it crashes at startup).
This message is provided under the terms outlined at http://www.bero.org/terms.html
Will Redhat 7.2 support reiserfs?
Support is compiled into the kernel and the required userland tools are included.
It's not supported by the installer (but existing reiserfs partitions will be mounted) because the kernel team says it's still not 100% ready.
It will be very hard to devfs and reiserfs to succeed if RH makes it difficult
There are currently a number of known security problems with devfs, so making that easy is not a good idea just yet.
This message is provided under the terms outlined at http://www.bero.org/terms.html
I bought Redhat's 'Garage Edition' of RH 7.1
This is a Europe-only product.
It'll be hard to find it in any other place.
This message is provided under the terms outlined at http://www.bero.org/terms.html
I did actually have a good idea (hard to tell from my posts, but I do have them - its a zero sum game...have some really stupid thoughts, youre bound to have some good ones to even you out...).
/etc/lilo.conf on the system. Someone like myself (this is what happened with xinetd) is going to sit down to admin one of these boxes one day, and assuming lilo.conf is there, type vi lilo.conf. As it stands now, when he/she does this on a GRUB only system, the response to discovering there is no lilo.conf might range from curious to semi-non-linear.
It goes like this. (I have no idea how GRUB works, so I'm guessing here). Let's say RH switches over to GRUB completely, and now there's no
But what if, instead of no file existing, a text file (/etc/lilo.conf) existed that explained why its not there, what has replaced it, and how to do everything with the replacement that could be done with its predecessor? This I think would actually be really cool, and it would still be there even if no help documentation was included during the initial install. You could even put some sort of shebang-style string at the beginning of every one of these "evolution" files, so that people who want to get rid of them can issue a simple grep or find command to search and destroy them.