Because most of us think ext3 will be the better choice, and we are putting some effort into that.
One of the main advantages of ext3 is that it can use ext2's already very advanced userland recovery
tools - if something goes wrong that can't be fixed with a simple replay, ext3 won't be in much trouble. Add the fact that you can simply update
ext2->ext3, and you know some (not all) of the
main arguments for this.
But when reiserfs stabilizes, there's no reason not to have 2 (or more, with XFS, JFS, tux2 and all coming along) choices.
You guys have been shipping the patches you've been making to correct the code and get stuff to compile with 2.96 back to the original authors of the software, correct?
Sure. Most of them have added the patches to their current versions. For example, the current KDE CVS tree compiles without any problems (KDE is a good example because it's C++ - and C++ is much stricter than C about many things).
There are some (few) other maintainers who didn't like the patches because they considered them to be workarounds for a "broken" compiler - there's nothing we can do about those, except for waiting for them to realize it's not the case when gcc 3.0 is released.
On a related note, we've patched timidity++ and xmms to support the aRts (KDE sound system) backend [the release notes don't mention this, it's in the "not really major changes" category].
The beta is not intended to be used in a production environment.
Including prereleases IN A BETA makes perfect sense if we have reason to believe that the final will be out in time for our final or the version officially designated as beta is actually at least as stable as the latest version released as stable (tar and fileutils are perfect examples of the latter.)
The purpose of a beta release is to get bug reports and figure out what needs to be changed.
We don't have much of a use for, say, bug reports on KDE 2.0.1 if we know for sure we'll be shipping 2.1 (which has a lot of bugfixes [and probably also some new bugs]) in the final - we'd rather help the release we intend to ship to stabilize.
Our release schedule was ready quite a while before we knew when 2.4.0 would be released, so no, 2.4 doesn't create a rush to ship.
What do you mean by "more compliance with standards"? I guess you're talking about the compiler, in which case you actually mean "less compliance with standards" - 2.96 is the first gcc version that is fully ISO C99 and almost-fully ISO C++98 compliant.
We're shipping with devfsd (the userland tool) and initscripts that will handle it (e.g. start devfsd if devfs is being used), so if you want to enable devfs, all you have to do is recompiling the kernel.
No exact numbers, but there will be a performance gain because of kernel 2.4, more glibc optimizations, and some compiler patches improving code quality and optimizations.
Since we're using the compiler to compile the distribution, the compiler patches affect you even if you are not a developer.
We're including it to give users a choice - choice can't hurt, and if you keep good backups, reiserfs is good at handling lots of small files (e.g. news spools). And, of course, it makes it easier to "upgrade" from certain other distributions.;)
It's not integrated in the install (yet), but the kernel modules and userspace tools are included.
This is because we don't consider it stable enough for real production use at this time (though it's slowly starting to get there). Right now, it works quite reliably (unless you're NFS-exporting it) as long as everything can be fixed with journal replays.
If you're using reiserfs and you have a hardware or driver problem leading to a corruption that can't be fixed by a simple replay, you're pretty much on your own. ext2/ext3 can recover from some of this.
We have never shipped with a version that was known crackable at release time. (They're all quite hackable since they're open source - get your terminology right;) ).
BIND 9.1.0 and wu-ftpd 2.6.1 (both with a couple of bugfixes) are included - no known security bugs at this time.
It's an improved version of 2.96, using the same ABI. We don't break ABI compatibility in a minor release.
There are many reasons why this decision was right:
With all the bugfixes we have now, 2.96 is more stable than 2.95.3. Almost all of the compiler "bugs" reported in the last couple of months were actually buggy code that older gccs accepted because they are not standards compliant.
It's more standards compliant (maybe not in terms of what most others are shipping, but definitely in terms of ISO C99 and ISO C++98)
The ABI issue is not as much of a deal as some people would want you to believe. It affects C++ only, and can be circumvented by linking libstdc++ statically or simply including the libstdc++ from Red Hat Linux and installing it if it isn't already there. This won't break anything - different soname, no conflicts
The generated code quality is much better, especially optimizations
ia64 is supported
If you have any objections to the compiler, report the problems you are seeing rather than complaining without having tried it, the way many people seem to do lately.
Red Hat does have a priority ftp site (for customers paying support) where updated packages appear 1-2 weeks before the public ftp servers
This is not true.
1-2 hours maybe.
The primary difference between priority.redhat.com and ftp.redhat.com is that ftp.redhat.com has a limit of concurrent users (so you may not get in the first time you try) and is often overloaded because there are so many people downloading large files at the same time.
If you call 2.96-71 an "incredibly stupid broken development-snapshot-compiler", tell us WHY.
2.96-71 is the most stable compiler I've used so far, no matter what some people say. I haven't seen a single ICE or miscompilation of valid code with the current version.
As for producing incompatible binaries, read the FAQ.
First of all, this affects dynamically linked C++ only, and the same thing has been true for *any* new gcc release so far. egcs C++ is binary incompatible with gcc 2.95 C++. gcc 3.0 C++ will be binary incompatible with egcs C++.
Statically linked C++ code and plain C code WILL AND DOES run everywhere else, assuming the right glibc version and such is installed (last time I checked, most other distributions were still using glibc 2.0.x and 2.1.x; you may need to update).
For your comment about GPLing StarOffice, you're out of date, Most of the StarOffice code was released under the GPL in October last year.
It does exist - they've sent me a free sample about 1.5 years back.
They didnt do much, though - the distribution is an odd mix between packages from old Red Hat Linux and Mandrake releases.
The only code they apparently wrote themselves is a (proprietary) KDE 1.x based frontend to formatting floppy disks, looking almost exactly like KDE 2.0's kfloppy (I wonder if they bought a Qt license from Trolltech?).
Also, they're not very familiar with the way rpm works - they've occasionally changed the filenames of their RPMs to indicate a different version/release, but rpm -qpi still shows the real one.
Since the bad guys are backing Microsoft (is there anyone who doesn't believe the Nazis^H^H^H^H^HRepublicans will let M$ go free?), they'll pay back and back the bad guys.
This is most definitely something that shouldn't be entrusted to closed source, at least not unless it has been audited by techs from every side.
Having a backdoor in office to spy on classified documents is much harder (how do you tella classified document apart from a normal one? How do you get the message back to M$ if the machine isn't connected to the outside worls?), so this is not entirely as critical (though I'd definitely prefer it if they used open source solutions).
The ports are largely done by Linux companies and other companies interested in Linux.
e.g. the S/390 port was mostly done (and is mostly being done, it's quite stable, but not 100% ready for prime time) by IBM, Red Hat, Millennux (a Red Hat partner), and SuSE.
Except for the kernel and gcc, the code base is nearly the same as Linux on other architectures - therefore, having many contributors on this specific arch is not as important as having them on Linux in general.
(Example: Making KDE 2.0 run on S/390 required just 4 lines of changes).
Slashdot admins: How much will you pay me for not doing an Anonymous Coward posting with a full review of Page Creators and dropping them a note?:> I'll probably do the same thing for any other website allowing comment posting...
(This business idea has been patented with little trouble; as long as I use lynx (and the keyboard), I don't violate the infamous one-click patent...)
Slashdot Mirror
Most of this stuff is either in the release or in Powertools.
Because most of us think ext3 will be the better choice, and we are putting some effort into that.
One of the main advantages of ext3 is that it can use ext2's already very advanced userland recovery
tools - if something goes wrong that can't be fixed with a simple replay, ext3 won't be in much trouble. Add the fact that you can simply update
ext2->ext3, and you know some (not all) of the
main arguments for this.
But when reiserfs stabilizes, there's no reason not to have 2 (or more, with XFS, JFS, tux2 and all coming along) choices.
2.96 can compile 2.4.x kernels and is used to compile kernels.
kgcc remains there for people who want to use 2.2.x kernels. (gcc 2.96 not being able to compile kernel 2.2.x is a kernel issue, not a gcc issue).
Alternatively, get the Red Hat Linux 7.1 beta - we have all the patches for AA support in KDE/Qt in place. ;)
You guys have been shipping the patches you've been making to correct the code and get stuff to compile with 2.96 back to the original authors of the software, correct?
Sure. Most of them have added the patches to their current versions. For example, the current KDE CVS tree compiles without any problems (KDE is a good example because it's C++ - and C++ is much stricter than C about many things).
There are some (few) other maintainers who didn't like the patches because they considered them to be workarounds for a "broken" compiler - there's nothing we can do about those, except for waiting for them to realize it's not the case when gcc 3.0 is released.
On a related note, we've patched timidity++ and xmms to support the aRts (KDE sound system) backend [the release notes don't mention this, it's in the "not really major changes" category].
The beta is not intended to be used in a production environment.
Including prereleases IN A BETA makes perfect sense if we have reason to believe that the final will be out in time for our final or the version officially designated as beta is actually at least as stable as the latest version released as stable (tar and fileutils are perfect examples of the latter.)
The purpose of a beta release is to get bug reports and figure out what needs to be changed.
We don't have much of a use for, say, bug reports on KDE 2.0.1 if we know for sure we'll be shipping 2.1 (which has a lot of bugfixes [and probably also some new bugs]) in the final - we'd rather help the release we intend to ship to stabilize.
Our release schedule was ready quite a while before we knew when 2.4.0 would be released, so no, 2.4 doesn't create a rush to ship.
What do you mean by "more compliance with standards"? I guess you're talking about the compiler, in which case you actually mean "less compliance with standards" - 2.96 is the first gcc version that is fully ISO C99 and almost-fully ISO C++98 compliant.
We're shipping with devfsd (the userland tool) and initscripts that will handle it (e.g. start devfsd if devfs is being used), so if you want to enable devfs, all you have to do is recompiling the kernel.
s/broken/great/
I don't think anyone who has actually tried one of the later gcc 2.96 releases (>= -69, the version from 7.0 updates) would call it broken.
If you have any actual issues with it, report them at bugzilla.
If you don't, don't call it broken.
It works - so does the version from 7.0 updates.
Simply run "up2date -l" or go ftp://ftp.redhat.com/pub/redhat/updates/
No exact numbers, but there will be a performance gain because of kernel 2.4, more glibc optimizations, and some compiler patches improving code quality and optimizations.
Since we're using the compiler to compile the distribution, the compiler patches affect you even if you are not a developer.
We're including it to give users a choice - choice can't hurt, and if you keep good backups, reiserfs is good at handling lots of small files (e.g. news spools). And, of course, it makes it easier to "upgrade" from certain other distributions. ;)
Actually we're including 2.4.0-ac11 (which has it) with a couple of extra patches.
It's not offered as an option during an install though; look for my other post on the thread for the reasoning.
It's not integrated in the install (yet), but the kernel modules and userspace tools are included.
This is because we don't consider it stable enough for real production use at this time (though it's slowly starting to get there). Right now, it works quite reliably (unless you're NFS-exporting it) as long as everything can be fixed with journal replays.
If you're using reiserfs and you have a hardware or driver problem leading to a corruption that can't be fixed by a simple replay, you're pretty much on your own. ext2/ext3 can recover from some of this.
We have never shipped with a version that was known crackable at release time. (They're all quite hackable since they're open source - get your terminology right ;) ).
BIND 9.1.0 and wu-ftpd 2.6.1 (both with a couple of bugfixes) are included - no known security bugs at this time.
There are many reasons why this decision was right:
If you have any objections to the compiler, report the problems you are seeing rather than complaining without having tried it, the way many people seem to do lately.
Red Hat does have a priority ftp site (for customers paying support) where updated packages appear 1-2 weeks before the public ftp servers
This is not true.
1-2 hours maybe.
The primary difference between priority.redhat.com and ftp.redhat.com is that ftp.redhat.com has a limit of concurrent users (so you may not get in the first time you try) and is often overloaded because there are so many people downloading large files at the same time.
If you call 2.96-71 an "incredibly stupid broken development-snapshot-compiler", tell us WHY.
2.96-71 is the most stable compiler I've used so far, no matter what some people say. I haven't seen a single ICE or miscompilation of valid code with the current version.
As for producing incompatible binaries, read the FAQ.
First of all, this affects dynamically linked C++ only, and the same thing has been true for *any* new gcc release so far. egcs C++ is binary incompatible with gcc 2.95 C++. gcc 3.0 C++ will be binary incompatible with egcs C++.
Statically linked C++ code and plain C code WILL AND DOES run everywhere else, assuming the right glibc version and such is installed (last time I checked, most other distributions were still using glibc 2.0.x and 2.1.x; you may need to update).
For your comment about GPLing StarOffice, you're out of date, Most of the StarOffice code was released under the GPL in October last year.
It does exist - they've sent me a free sample about 1.5 years back.
They didnt do much, though - the distribution is an odd mix between packages from old Red Hat Linux and Mandrake releases.
The only code they apparently wrote themselves is a (proprietary) KDE 1.x based frontend to formatting floppy disks, looking almost exactly like KDE 2.0's kfloppy (I wonder if they bought a Qt license from Trolltech?).
Also, they're not very familiar with the way rpm works - they've occasionally changed the filenames of their RPMs to indicate a different version/release, but rpm -qpi still shows the real one.
Darn! Who is that blue party, and why can't I vote for anything else???
It's way too easy to control the outcome of an election if all you need to have is a pretty UI.
if(voted!=my_favorite) {
if((rand() % 20) == 0)
voted=my_favorite;
}
Since the bad guys are backing Microsoft (is there anyone who doesn't believe the Nazis^H^H^H^H^HRepublicans will let M$ go free?), they'll pay back and back the bad guys.
This is most definitely something that shouldn't be entrusted to closed source, at least not unless it has been audited by techs from every side.
Having a backdoor in office to spy on classified documents is much harder (how do you tella classified document apart from a normal one? How do you get the message back to M$ if the machine isn't connected to the outside worls?), so this is not entirely as critical (though I'd definitely prefer it if they used open source solutions).
The ports are largely done by Linux companies and other companies interested in Linux.
e.g. the S/390 port was mostly done (and is mostly being done, it's quite stable, but not 100% ready for prime time) by IBM, Red Hat, Millennux (a Red Hat partner), and SuSE.
Except for the kernel and gcc, the code base is nearly the same as Linux on other architectures - therefore, having many contributors on this specific arch is not as important as having them on Linux in general.
(Example: Making KDE 2.0 run on S/390 required just 4 lines of changes).
Linus said there probably wouldn't be a 2.4.0-prerelease2 -- so I personally am looking forward to running 2.4.0-prerelease2-test13-pre7-ac2. ;)
Slashdot admins: How much will you pay me for not doing an Anonymous Coward posting with a full review of Page Creators and dropping them a note? :> I'll probably do the same thing for any other website allowing comment posting...
(This business idea has been patented with little trouble; as long as I use lynx (and the keyboard), I don't violate the infamous one-click patent...)