Yes, that's pretty much it. When I first saw grub, it sort of reminded me of the FreeBSD loader with an additional easy interface added to it for the newbies.
issue and issue.net get clobbered by a file called redhat-release at start-up
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/etc/rc.d/init.d/rc.local.
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?
We don't break binary compatibility between minor releases
It's still the most stable compiler out there - 3.0.1 miscompiles KDE and other C++ code
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/etc
There is no standard whatsoever that asks for putting them straight in/etc.
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/. as much as you're doing today, 7.2 had better be bug-free.
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/., but...).
Yes. It's easy, but it has security implications. Procmail has not exactly been safe from buffer overruns in the past, and I still don't trust it.
But it's probably better than running an SMTP server as root...
Re:Is RH including proprietary sw these days?
on
Red Hat 7.2 Released
·
· Score: 2
Most banks in Europe still use Java stuff for online banking - that's the #1 reason to keep Netscape 4.x in at this time.
I know Mozilla and Konqueror can do Java - but only if a JDK is installed, and right now, the JDKs are under even weirder licenses than Netscape 4.x, so we're staying with the lesser evil.
No, because it's actually a reproducable bug that has even been acknowledged as a bug by the gcc developers. gcc 3.0.x has a problem with multiple inheritance; and I'm sure it'll be fixed in 3.0.2 or 3.0.3.
This has nothing whatsoever to do with the ABI changes, or kdeinit being a hack.
2.96-RH broke some code too, but you certainly weren't blaming it on your compiler then
There's a difference between outputting a broken binary from valid code and refusing to compile bad code.
The initial version of 2.96 was somewhat broken, and so is 3.0.1, unless you don't use C++.
We haven't seen anything like this in the (pretty long) beta phase, so I assume it's been fixed.
I've had some problems with grub 0.1something as well (it would simply show a black screen),
but the current version has been running on the same machine
without problems.
It's actually broken. The bug has been present and known since gcc 3.0, and
hasn't been fixed in 3.0.1 or post-3.0.1 stable-branch CVS (at least as of 3 weeks ago).
gcc 3.0.1 miscompiles C++ applications/libraries that use multiple inheritance,
which KDE does in a couple of places.
Chances are we'll fix this and go 3.x for 8.0 (or whatever
the next major release will be called).
If you're using lilo, simply change message=/boot/message
to something else.
If you're using grub, remove the splashimage line.
Re:to forestall the inevitable -- why not reiserfs
on
Red Hat 7.2 Released
·
· Score: 2
I'm using it on one of my partitions, and haven't seen any problems (neither with 2.4.7-whatever nor 2.4.9-7).
Our kernel team thinks using 2.4.10 is a pretty bad idea because of some problems with the VM changes. (This may or may not be fixed in 2.4.12 and later, haven't had the time to look into it), so if you plan to update to 2.4.10pre or later, update with caution.
Such as giving newbies a chance to figure out what options they have without having to RTFM?
Re:to forestall the inevitable -- why not reiserfs
on
Red Hat 7.2 Released
·
· Score: 2
Since the test shows ext3 with writeback being slower than normal ext3 in some of the tests, I suspect something in the test went wrong.
Also, it wasn't using the current version of ext3.
That said, there are cases where ext3 is slower (obviously, since it has to take care of the journal data), but due to the better data ordering, it's faster in other cases.
Re:to forestall the inevitable -- why not reiserfs
on
Red Hat 7.2 Released
·
· Score: 3, Informative
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.
It breaks binary compatibility, which we can't do in a minor release
It produces broken code when C++ is used. Try compiling KDE 2.x (or 3.x) with it; every application will crash because of a miscompilation in kdelibs
Re:ipsec, freeS/WAN and RedHat
on
Red Hat 7.2 Released
·
· Score: 4, Informative
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.
Re:ext3, ok but what about reiserfs?
on
Red Hat 7.2 Released
·
· Score: 3, Interesting
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.
One of the features of grub is that you don't need to reinstall it every time you update the config file - therefore, kernel updates can now safely add an entry to the config file.
Also, if you compiled a test kernel yourself and don't want to clutter the boot menu, you can just tell grub to boot it anyway - it comes with a shell (nothing you need to work with unless you want to).
Re:Is RH including proprietary sw these days?
on
Red Hat 7.2 Released
·
· Score: 3, Interesting
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.
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).
Re:Red Hat is not synonymous with Linux.
on
Red Hat 7.2 Released
·
· Score: 5, Interesting
oddball decisions like the ones we're seeing in 7.2
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.
grub knows your filesystem. This means you can boot kernels you haven't listed in its config file (great for recovery, for example).
You don't need to reinstall grub every time you've modified its config file. Among other things, that means kernel updates can now add themselves to the boot loader. One of the big problems support was faced with in earlier (LILO based) releases was the number of people updating their kernel and forgetting to adapt/etc/lilo.conf and/or run/sbin/lilo.
It looks nicer (no more blocky 320x200 graphic at bootup)
It has better support for booting other OSes
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.
I am a bit concerned about this GRUB thing, does it replace LILO ?
In the long run, yes.
In 7.2, you have the choice between lilo and grub.
Try grub though, it has many useful features.
I've only just got the hang of lilo after all these years. I hope all my enrgy has not gone to waste.
One of the good things of 7.2/grub is that you don't need to know how to edit its config files - kernels install themselves to the boot menu automatically.
Re:to forestall the inevitable -- why not reiserfs
on
Red Hat 7.2 Released
·
· Score: 3, Informative
Please provide a testcase. Our tests have shown that (unless you compile in full debugging), ext3 is actually faster than ext2.
Slashdot Mirror
Yes, that's pretty much it. When I first saw grub, it sort of reminded me of the FreeBSD loader with an additional easy interface added to it for the newbies.
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
Yes. It's easy, but it has security implications. Procmail has not exactly been safe from buffer overruns in the past, and I still don't trust it.
But it's probably better than running an SMTP server as root...
Most banks in Europe still use Java stuff for online banking - that's the #1 reason to keep Netscape 4.x in at this time.
I know Mozilla and Konqueror can do Java - but only if a JDK is installed, and right now, the JDKs are under even weirder licenses than Netscape 4.x, so we're staying with the lesser evil.
gcj/gij may take care of this in the future.
No, because it's actually a reproducable bug that has even been acknowledged as a bug by the gcc developers. gcc 3.0.x has a problem with multiple inheritance; and I'm sure it'll be fixed in 3.0.2 or 3.0.3.
This has nothing whatsoever to do with the ABI changes, or kdeinit being a hack.
2.96-RH broke some code too, but you certainly weren't blaming it on your compiler then
There's a difference between outputting a broken binary from valid code and refusing to compile bad code.
The initial version of 2.96 was somewhat broken, and so is 3.0.1, unless you don't use C++.
We haven't seen anything like this in the (pretty long) beta phase, so I assume it's been fixed.
I've had some problems with grub 0.1something as well (it would simply show a black screen),
but the current version has been running on the same machine
without problems.
If this problem persists, please let me know.
It's actually broken. The bug has been present and known since gcc 3.0, and
hasn't been fixed in 3.0.1 or post-3.0.1 stable-branch CVS (at least as of 3 weeks ago).
gcc 3.0.1 miscompiles C++ applications/libraries that use multiple inheritance,
which KDE does in a couple of places.
Chances are we'll fix this and go 3.x for 8.0 (or whatever
the next major release will be called).
That will work, unless you've done odd stuff like
building your own gcc3 rpm that obsoletes the
normal gcc 2.96-RH libstdc++.
That shouldn't cause problems.
/usr/share/config/kdm is a symlink, you can go ahead. If it's a directory, uninstall kdebase and install the new version before doing anything else.
Depending on when you grabbed kdebase, you might have to remove the package first.
If
Not officially supported though.
But what happens if we take the roswell pakages for KDE, available from kde.org ?
That will work - they've actually been built on enigma.
Is there any update for 2.2.1 planned (i guess there is..) and when will it be out ?
No. There's no point in releasing an update that doesn't do much beyond changing the version number.
I'm planning to release an update to 2.2.2 once it's released though (shortly after November 12).
If you're using lilo, simply change message=/boot/message
to something else.
If you're using grub, remove the splashimage line.
I'm using it on one of my partitions, and haven't seen any problems (neither with 2.4.7-whatever nor 2.4.9-7).
Our kernel team thinks using 2.4.10 is a pretty bad idea because of some problems with the VM changes. (This may or may not be fixed in 2.4.12 and later, haven't had the time to look into it), so if you plan to update to 2.4.10pre or later, update with caution.
Such as giving newbies a chance to figure out what options they have without having to RTFM?
Since the test shows ext3 with writeback being slower than normal ext3 in some of the tests, I suspect something in the test went wrong.
Also, it wasn't using the current version of ext3.
That said, there are cases where ext3 is slower (obviously, since it has to take care of the journal data), but due to the better data ordering, it's faster in other cases.
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.
Just as long as it's not "Red Hat Linux XP". I'm moving to another distro if you go with "Red Hat Linux XP".
;)
Ok, I'll ask RMS to convince management to call it Red Hat GNU/Linux XP instead.
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.
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.
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.
One of the features of grub is that you don't need to reinstall it every time you update the config file - therefore, kernel updates can now safely add an entry to the config file.
Also, if you compiled a test kernel yourself and don't want to clutter the boot menu, you can just tell grub to boot it anyway - it comes with a shell (nothing you need to work with unless you want to).
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).
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.
I am a bit concerned about this GRUB thing, does it replace LILO ?
In the long run, yes.
In 7.2, you have the choice between lilo and grub.
Try grub though, it has many useful features.
I've only just got the hang of lilo after all these years. I hope all my enrgy has not gone to waste.
One of the good things of 7.2/grub is that you don't need to know how to edit its config files - kernels install themselves to the boot menu automatically.
Please provide a testcase. Our tests have shown that (unless you compile in full debugging), ext3 is actually faster than ext2.