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
To forestall the inevitable questions
-- why not reiserfs, xfs, jfs, etc.
First look at the total feature
list of ext3 and compare, in particular the
compatibility (forwards AND backwards) with ext2.
There may or may not be better candidates for
a fs, but there are certainly none better for
a default install.
Nothing to fear with GRUB. I've been using it for about a year. Configuring it is a little different than with LILO, but it works fine.
Redhat has dropped support for Postfix (a sendmail replacement), which used to be on the Powertools CD. I really don't know why
.2 version, RedHat is going to support it for a looong time
;)
It's because Powertools was dropped, and everything on Powertools that conflicts with something on a main CD (e.g. you can't install postfix and sendmail on the same system) had to go because at this time, the installer doesn't handle conflicting packages (breaking the "Everything" install isn't nice).
This is likely to get fixed in a future release (no promises though, it's not my decision [I'm all for postfix]).
Those who prefer it can grab the current official postfix package from rhcontrib. I'll open up the 7.2 section there later today.
Since it is a
<obligatory "we don't preannounce releases" rant>
What makes you think the next release will be 8.0?
</rant>
This message is provided under the terms outlined at http://www.bero.org/terms.html
Not me - I did a bit of benchmarking but that is my sole contribution to nautilus. Lots of other folks both inside and outside of RH did all the work.
FAT? Hardly! ext3 uses is built on extension hooks designed into ext2, allowing you to mount ext3 partitions with an ext2-only kernel (of course no journalling in that case). Also, it takes a few seconds to "convert" ext2 to ext3, can't get easier than that! :-)
Personally I find it impressive that the foresight in the ext2 design allowed for ext3 to evolve the way it did with the backwords compatibility
And hey, it just works. Performance is like ext2, except you never have to fsck anymore when the machine doesn't shut down properly. And your ext2 bootfloppies still work, you don't have to reformat your partitions first, and did I mention it just works? :-)
So why not? ReiserFS would be more suited for news spool and squid cache partitions, but if you just want your same old system except for the fsck's, ext3 is the way to go.
"Enigma" - wasn't it the name of this German machine that was used to encrypt secret messages during WWII ?
gcc 2.96-RH is all open , always has been. Gcc 3 is not quite compatible so wouldnt be appropriate for the base tools for a new release. It is on the CD though if you want it
The only nonfree stuff on the RH distro should be netscape, and we recommend mozilla 8)
GNU GRUB != GRUB. I don't know which version this is, but RMS will be annoyed if they've left off a GNU... :D
/sbin/grub, it supports Logical Block Address (LBA) mode that solves the 1024 cylinders problem, and TAB completes a filename when it's unique. Of course, many bug fixes are done as well, so it is recommended to use GNU GRUB.
From the GNU GRUB Faq:
1. How does GNU GRUB differ from Erich's original GRUB?
GNU GRUB is the successor of Erich's great GRUB. He couldn't work on GRUB because of some other tasks, so the current maintainer Gordon Matzigkeit took over the maintainership, and opened the development in order for everybody to participate it.
Technically speaking, GNU GRUB has many features that are not seen in the original GRUB. For example, GNU GRUB can be installed on UNIX-like operating system (i.e. GNU/Linux) via the grub shell
http://freshrpms.net/misc/enigma.html
Also, don't forget to go get all the "missing" goodies (xine, lame, nessus...) from http://enigma.freshrpms.net/
Happy download! :-)
Matthias
UK folks should findu ti ons/redhat/7.2
ftp://zeniiib.linux.theplanet.co.uk/pub/distrib
nice and fast (its the new linux.org.uk test box)
Alan
Maybe you should read the article, fuckwit. GRUB is filesystem-aware, editable on the fly, features a command prompt like a REAL boot loader, and features none of the limitations of LILO.
On this page, a redhat employee explained why they chose ext3.
It was also the topic of a previous slashdot post.
This extract sums it up :
Why do you want to migrate from ext2 to ext3? Four main reasons: availability, data integrity, speed, and easy transition.
[...]
Again, we don't claim that every one of these points are unique to ext3. Most of them are shared by at least one other filesystem. We merely claim that the set of all of them together is true only for ext3.
Men are born ignorant, not stupid; they are made stupid by education. Bertrand Russel
I don't know exactly what is on Disc 2, but I do know that you need both discs for a complete install, the second CD is not optional.
An official statement on why ext3 was chosen (ext2 compatibility is a major reason, but not the only one) can be found here.
This message is provided under the terms outlined at http://www.bero.org/terms.html
Not really, but gradually and constantly: There is a -current and a -stable CVS branch. You can follow the -stable CVS branch to stay completely uptodate all the time. Nothing ever breaks except on major announcements and big MFC's (merge from current) that are announced. At those times it may be necessary to revisit your config files in /etc (which can be automated with 'mergemaster').
/usr/local and don't spoil the main OS) and up to date.
/usr/src; make world from time to time).
Thus, you never have to download a new version, but you can always download incremental diffs (daily) that patch the complete source tree (cvsup). I have not reinstalled my FreeBSD system in 5 years time, yet it is 100% clean (all add-ons and optional parts to into
(cd
1. Go to the official ftp.redhat.com site and get the MD5SUM:
efab549656a1a85ab8fa39eb873eff0e enigma-SRPMS-disc1.iso
70703897af7703b40e41777a3aa186c3 enigma-SRPMS-disc2.iso
cf7bce0c1cdbfedfae29e60aef202f6f enigma-i386-disc1.iso
fd705b3e5d0e37a828db35d21195a9f6 enigma-i386-disc2.iso
2. Go to any available mirror that isn't slashdotted...I found:
ftp://linux.nssl.noaa.gov
a 100Mbps mirror in Czech Republic, Europe can be found at ftp.linux.cz.
-Yenya
--
While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
Please provide a testcase. Our tests have shown that (unless you compile in full debugging), ext3 is actually faster than ext2.
This message is provided under the terms outlined at http://www.bero.org/terms.html
I migrated my / filesystem (only the one Linux filesystem on my laptop - it dual-boots) from ext2 ro ext3. Totally seamless. No time lost with fsck.
I accidentally nobbled the ext3 module (by upgrading the kernel and omitting the initrd that normally loads the ext3 module from linuxrc). Red Hat seamlessly mounted as ext2 - no loss of data (but obviously no journalling). Puttng the initrd back brought me back into the ext3 fold, again seamlessly. It was completely painless -I was really impressed. This experience is with 7.1.93 - I have not yet tried 7.2
In fact, I might not ever try 7.2 because of the really annoying ppp-watcher in 7.1. I had an ISP problem where the chat script would fail to authenticate, and the ppp-watcher just dialled again and again and again... Really annoying, and hard to change. I'm sure I'd miss RH if I stopped using it because I've used it since RH 2.1. For the moment I'm running Red Hat 7.1.93 at home and Debian on my laptop.
Besides, RedHat lets you choose at installation, so you can <sarcasm>"leverage" the mountain of knowledge you have about LILO</sarcasm>. Like there's so much to know...
WWJD? JWRTFM!!!
I've had no problems compiling and using custom kernels under the 7.2 beta, aka "Roswell." You just need to patch the stable 2.4.12 tree for ext3 support, or use the -ac kernels, which already incorporate ext3 support. I've found 2.4.12-ac3 to be a very stable kernel with good memory and VM behavior. RedHat kernels are closer to -ac kernels right now, it would appear, than to Linus' main kernel tree.
---
Disk 2 contains a few less-used packages, most of the -devel.rpm's, and some server daemons.
All in all, unless you do a extrememe minimal instalation, you will _definatly_ need disk to.
The point i'm trying to make, it is not a 'PowerTools' or 'Addons' disk, it is an intergral part of the instalation!
They have merged the PowerTools into the main instalation set (leaving out not often used, or badly maintained, or conflicting tools). So currently there is no 'Addons' cd's.
.. Unless you get the $199 Redhat 7.2 Pro set, which has (if i remeber correctly) 6 cd's containing quite a few extra apps and daemons.
the reason for ext3 over resier is the ability to non-destructively upgrade an ext2 drive. with reiserfs, you have to format the drive, which means dataloss for those that can't just 'tar zcvf /dev/tape /'. i'm sure there are other reasons too, but for most people, that ability is important.
Why read the article when I can just make up a snap judgement?
I understand RedHat cannot integrate ipsec / FreeS/WAN into the Linux distribution because of US export restrictions.
I don't think the export restrictions you're referring to are still in place.
We're currently shipping cipe, which provides pretty much the same functionality.
There have been some reasons for choosing cipe over FreeS/WAN. I don't remember the details, but I think it was related to not supporting non-x86 arches.
This message is provided under the terms outlined at http://www.bero.org/terms.html
This message is provided under the terms outlined at http://www.bero.org/terms.html
I don't particularly see any need to upgrade to 7.0, 7.1 or 7.2 for that matter.
What's the big deal?
I've used every version of RedHat since 3.3, and several versions of Mandrake over the last 6 years. That's a lot of upgrading, particularly since I have several servers and workstations running Linux. My firewall/proxy/router is still running a heavily upgraded version of RH 6.1, and my mail server is running a butchered version of RH 6.0. My internal web server and all of the workstations are running RH 7.1, and I'll be upgrading some of those to RH 7.2 in the near future, as it stabilizes.
Here's a short list of my reasons to upgrade to RH 7.X:
Ultimately with Red Hat, they've done a good job of supporting older X.2 releases, but support doesn't mean adding new features. If you want the new features, you'll want to upgrade. If you don't want/need them, then stick with what works. At least Red Hat (and most Linux distros) give you that choice -- as opposed to certain eXtra Proprietary systems.
We call it art because we have names for the things we understand.
This has been patched. Nothing to see here folks move along.
Get a free ipod.
I want to know why ReiserFS debugging was turned on in 7.1
Because our tests have shown the version of ReiserFS in the 7.1 kernel to produce filesystem corruption under some circumstances.
Avoiding that (or at least giving us a chance to debug it) was more important than getting it to full speed.
We haven't seen fs corruption in the 7.2 kernel, so it's turned off now.
This message is provided under the terms outlined at http://www.bero.org/terms.html
e.g Compile a library with gcc3 , compile
an app using the library with gcc 2.X. -->
Will porbably(and probably is not good enough) not work, atleast not for C++ programs.
Redhat tries to maintain binary compability in
their major releases, Binary compability is a _very_ good thing
but often neglected in the opensource world
We now have RedHat 7.2 up and running in the Compaq Test Drive Program, so you can try it on our systems before you put it on yours. It's running on a couple of dual-processor x86 systems, and using the ext3 file system. Sign up for a free account and give it a try.
Go, GRUB, go!
Carousel is a lie!
kernel-headers-2.4.9-7.i386.rpm
kernel-2.4.9-7.i386.rpm
kernel-doc-2.4.9-7.i386.rpm
kernel-source-2.4.9-7.i386.rpm
kernel-BOOT-2.4.9-7.i386.rpm
nscd-2.2.4-19.i386.rpm
glibc-common-2.2.4-19.i386.rpm
glibc-devel-2.2.4-19.i386.rpm
glibc-profile-2.2.4-19.i386.rpm
glibc-2.2.4-19.i386.rpm
openssh-askpass-gnome-2.9p2-9.i386.rpm
openssh-2.9p2-9.i386.rpm
openssh-askpass-2.9p2-9.i386.rpm
openssh-clients-2.9p2-9.i386.rpm
openssh-server-2.9p2-9.i386.rpm
squid-2.4.STABLE1-6.i386.rpm
mew-1.94.2-12.i386.rpm
util-linux-2.11f-12.i386.rpm
-- You can be a geeklord too
Ximian GNOME for Red Hat Linux 7.2 has been released. Please don't follow the instructions in the article for removing Ximian GNOME, as that will break your rpm dependency tree pretty badly.
The recommended procedure for upgrading to Red Hat Linux 7.2 with Ximian GNOME is to perform the Red Hat upgrade, then immediately reinstall Ximian GNOME.
lynx -source http://go-gnome.com/ |sh
The mirrors will pick it up shortly.
Share and enjoy,
The Ximian release team
Just to re-emphasize, Hemos's instructions for 'cleaning' Ximian will seriously break your system- it'll remove glib (among other things) which will remove a large number of RH's system tools. So... don't.
Luis Villa [Ximian Bugmaster, who doesn't want to have to deal with 'Hemos broke my system' bugs all day]
IAAL,BIANLY
This is intentional to make sure people calling up support can tell them which kernel they're running.
The correct way to change it is to edit
WTF can't you just use inetd.conf?
inetd was dumped precisely because inetd.conf sucks.
One of big advantages of xinetd is that packages can add themselves to xinetd without having to do ugly sed or perl tricks on a file.
Now you've got this thing called GRUB. Do any of the other distros have it?
Sure. Mandrake does, Debian does. Don't know about the others.
What happens when I decide I want to upgrade to kernel 2.4.12 - does it automagically know how to install itself on this new, poorly named bootloader?
If you install the RPM, yes, GRUB will know about it. If you install from source, you have to edit grub.conf (but you don't need to reinstall GRUB afterwards).
Speaking of which, why is 2.96-RH STILL the default compiler?
But taking industry-standard files and replacing them with something silly
If a standard is broken, it needs to be fixed. (Any website still running on HTML 1.0?)
xinetd is pretty much a standard right now - almost every Linux distribution has it, and it's in FreeBSD's ports collection.
Much the same is happening/has already happened for GRUB.
RH, for some reason, can't be happy with keeping the samba files in
There is no standard whatsoever that asks for putting them straight in
I don't know why the change was made (I don't do samba and I've never used it), but I'd think it's in order to make it more obvious which users need to edit nmbd.conf and which users can simply ignore it (or better yet deinstall the package, but there are quite a number of everything installs out there because people can't figure out which packages they need).
What you RH people don't seem to understand is that some of us still like to edit config files
Most of us understand. I for one don't use GUI config tools (except for testing, or to get a base configuration up to tune by hand later on).
could you _please_ stop mangling the text files they parse in the first place?
One of the things that sets Red Hat Linux apart from some other distributions is, actually, that most of our config tools try to parse existing config files rather than simply dumping any changes made by the user.
if you guys have got the time to troll on
This is a cyclic thing - right now, we have much less work than shortly before the engineering freeze for 7.2. The development of the next version has already started quite some time ago, of course - but a lot of the changes require waiting for other projects to finish, so at this time, we have some spare time. (And besides, it's long after office hours around here, so don't think I'm wasting work time. Granted, since I don't have a life I'd probably be hacking if I weren't reading
This message is provided under the terms outlined at http://www.bero.org/terms.html
And now to rebut...
.doc don't seem to be working either.
...
ext3 is just as robust, and doesn't require a fsck at all after a power cycle.
The fsck on a softupdates volume is blazingly fast. To be sure, ext3 is a nice file system, but that doesn't mean all the other ones are crap.
OpenOffice for Linux doesn't run, and native AbiWord in 4.4-release doesn't start. Koffice import filters for
Use the native OpenOffice. I didn't have any problems with AbiWord. And KOffice filters are identical under Linux and FreeBSD.
up2date takes care of all that for in-distro packages.
Yeah, for the in-distro packages. But that ignores the major flaw of RPM: you have to use RPM for everything or you screw up your system. With FreeBSD you can use packages, ports, or compile by hand, and nothing gets out of sync.
Except maybe just doing a half-hour upgrade and getting back to work, rather than compiling all day
Ever heard of multitasking? Compile everything in the background while you work in the foreground. Plus, if you cvsup once a week, you're never so far behind that you need to compile "all day". Or better yet, if you're into precompiled packages, just upgrade the packages!
Nautilus, f.e., doesn't even start in 4.4's GNOME distribution.
I didnt have any problem at all with Nautilus (other than the fact that it's slower than molasses).
On the server side, you can't just install fbsd and use it as a NAT or enable quotas without recompiling the kernel.
Huh? A coworker of mine installed FreeBSD "out of the box" for his server and had it up and running in half an hour. He never had to recompile anything. I don't know much about NAT (except that my coworker got it running without recompiling), but quotas are already in the shipping kernel.
FreeBSD just takes more work.
It does require that you use more than two brain cells, and it does require you to make some sort of effort to get it installed and administered. But since when has that been a drawback in the Unix world?
A Government Is a Body of People, Usually Notably Ungoverned
That's why I said "most" config tools.
/etc/sendmail.cf in key=value or xml, by the way?) - but it's almost certainly not going to happen, at least not anytime soon.
I know there are some exceptions (mostly due to schedules that had to be kept - we can't always get all wanted features into the first version...).
The non bandaid solution is to standardize on a particular format for config files
This is true - but I don't think you can get every project to follow the same standard.
We actually talked about something like this internally (basically, "provide one standard library for every config stuff, then fork every app to make use of it and ask maintainers to apply the patch"), but dismissed the idea quite quickly because that would definitely be a nonstandard thing giving people legitimate reasons to complain about ("Oh, you're using the Red Hat version of my application? Then I can't help you, I don't know anything about it, and I don't like their config layout"), and more "Red Hat is just like Microsoft, now they're forcing everyone to use their crap rather than compiling from source!" type FUD.
In an ideal world, we'd all be using the same format for config files (how do you represent
Even OSes that try to enforce one config scheme on everything (e.g. M$ registry) end up with applications that create their own config files using something totally different.
This message is provided under the terms outlined at http://www.bero.org/terms.html
Huh? According to Redhat's site it's $990 for 10 machines for a year! And I suspect you can get even bigger discounts if you're going to register 50 machines.