Your list is bogus, as quite a few of our kernel hackers don't use their redhat.com addresses their or haver their old addresses in the kernel. Examples are Alan Cox, Al Viro, Doug Ledford, Ben LaHaise, Arjan Van de Ven and Tim Waugh. In fact, the only three of the above who actually work on the kernel are johnsonm, davem and sct.
As for ReiserFS, it had multiple data corruption issues the last two months and it is extremely sensitive to hardware failure - lose a few blocks, and your btree dies. For ext2, you'll typically
only loose the files on these blocks.
Wrt. to gcc as shipped in Red Hat Linux 7, there's no doubt this is the best compiler out there currently. The issues are wrt. to binary compatibility with C++ and not sufficient labeling as a release made by Red Hat, not by the gcc steering committee. And even so, this is not data corruption - a bug or two in a app is regrettable, corrupted data unacceptable. And corrupted data is what you get with the 2.4 kernel SuSE ships.
The installation of Red Hat Linux is IMNSHO way ahead of anything else out there - the SuSE one is really bad (and has a non-free license), and I'm not to keen on the Mandrake one either.
Note that the updates will break some builds - e.g. newer glibc cleaned up some name space polllution ( vs ), this broke compiling for a lot of packages. Both the pollution and the apps depending on it were fixed for Red Hat Linux 7., but this not released for RHL 7 as it didn't affect functionality.
We do mass rebuilds on a regular basis, so
the packages should build - if you experience bugs with this, report it in bugzilla
Take a look at all the core components, and see whose work it is - it isn't Mandrake. The people who make the it possible work here - no other distribution has a kernel team even remotely comparable to the one we got, and we also have the prime glibc, gcc, gdb, gtk etc. developers working here. FTR, if you look at their beta release, they're even copying our compiler.
As for updates, security in general, etc. you'll notice that RHL is ahead there too. Online updates (up2date) has been around for years. 3D support was added when it was integrated into XFree, and stabilitywise Mandrake is shipping known broken components in the kernel (ReiserFS, supermount etc).
No, our kernel people don't think it's safe - ReiserFS had quite a few bugs fixed the last month or so. And for filesystems, data integrity is an absolute requirement - this is the first distribution with a 2.4 kernel not known to destroy
filesystems under load.
It is enabled in the kernel, but not during install.
up2date also has functionality not found in apt-get, such as server/client authentication and verification of the origins of the update (the latter may be solved in the rpm version of apt, but standard Debian can't do it - get trojaned packages onto a mirror, and watch people use it)
The i686 glibc supports the 2.4 feature "floating stacks" - variable stack size for threads. Existing JDKs have a hardcoded assumption of 2 MB, and this limit in strange, weird and unsupported ways.
There are two work arounds for these buggy JDKs:
Install the i386 glibc, not the i686 glibc. It doesn't require a 2.4 kernel and doesn't have floating stacks.
Run your JDK with 'LD_ASSUME_KERNEL=2.2.5'.
Either one should work. We also expect fixed JDKs to become available in the not too distant future.
But why would you want to? The version we ship produces better code, has more bugfixes and less known problems and is binary compatible with the rest of the distrubution.
Using gcc 2.95.3 is setting you up for a world of PM.
There aren't known stability issues with Red Hat Linux 7 - of course, as with any distribution you should apply the updates for it but few of these are Red Hat specific. With those, it's a great platform with good performance.
There are no iso files for Alpha, as we haven't announced a product for Alpha yet.
As for SPARC, we're not doing distributions of it - just development snapshots. It's just not worth the development, QA and manufacturing effort right now.
SDL was developed by Loki to simplify their own job - porting standard commercial games from Windows to Linux. Thus, it's already being used for "professional" project with cutting-edge, commercial games and is proven technology - at least on the Linux platform.
The part you're quoting is the part which guarantees the user the source to the binary - so you can't say that the program is $50 and the source $5000.
The GPL has no restrictions whatsoever on price of the binary - you can charge whatever you like.
Another issue many don't understand: You have to own the binary to have a claim to the source.
The GPL does not say that you have a right to get anything for free: It just says that you have a right to the source if you get the program, that changes are GPL as well if you distrbute them and that you can redistribute the program freely with the same license.
So if someone sold a high priced 3D package and GPLed it, you couldn't demand that they give it to you or put it on the web - you could ask another one who already bought it to give to you, but if you don't have the program, you have no claim.
One of the reasons for the high price of the Ultras is the high price for components: It uses very fast (and expensive) memory chips, and this is the main reason for the performance increase. If memory serves, the memory on the GeForce Ultra is faster than on the GeForce3 - the latter uses new technology to make better use of available bandwidth instead of increasing it.
So until the prices on this kind of memory decreases quite a bit, I don't see the Ultras coming down
The architecture can run at higher speeds - that is one of the big benefits of the new architecture. The old one can't go any further, as demonstrated by Intels's attempt at 1.13 GHz
It has different speed characteristics - it's plenty fast enough for the standard applications, but is much more powerful where the current bottlenecks are: It has a much higher memory bandwith and very good performance for streams of data.
That aside, everything isn't perfect with the P4: It really needs a silicon shrink, and going with RAMBUS hurts it badly. It's by rambus, it's expensive and you could get as much performance by using DDR SDRAM and/or multiple memory interfaces. It's also rather expensive - I just bought myself an Athlon, and is happy with that.
its the principal behind it. there was no reason for RH to make a stupid move like that at all.
Of course there are reasons:
egcs was too old for another cycle, and has its share of bugs
2.95 is very buggy, and can't even compile glibc 2.2 on non-x86
The compiler we ship has better performance, IA32 and others
The compiler we ship has plenty of bugfixes
over the older releases.
The compiler we ship has much better C++ standard compliance
It supports platforms we find important, like IA64. This way, there is only one compiler across all platform.
On the minus side: C++ isn't binary compatible with other versions of gcc. As we went with glibc 2.2, this wouldn't have been compatible with anything anyway (a combination of gcc and glibc is binary incompatible with any other combination). There has never been C++ binary compatiblity on Linux, and there won't be until gcc 3.0 is released and used.
As you can see above, there is no doubt that on technical merits, this was the choice to do. And we did it. Unfortunately, we could have handled the political situation better. As for the end-user experience, that's irrelevant.
When gcc 3.0 comes out, we intend to switch to that at one point - "when" is dependent on when gcc 3.0 is actually released and how it fits into our cycles, as it will be a binary incompatible change.
We don't ship 2.95.3 - we ship a snapshotted, qaed and fixed brach from the gcc tree and call it "2.96RH". Mandrake, OTOH, ships 2.95.3 (no such thing) - but noone cares.
Slashdot Mirror
As for netscape, we're on the way of getting rid of it as mozilla improves.
Your list is bogus, as quite a few of our kernel hackers don't use their redhat.com addresses their or haver their old addresses in the kernel. Examples are Alan Cox, Al Viro, Doug Ledford, Ben LaHaise, Arjan Van de Ven and Tim Waugh. In fact, the only three of the above who actually work on the kernel are johnsonm, davem and sct.
As for ReiserFS, it had multiple data corruption issues the last two months and it is extremely sensitive to hardware failure - lose a few blocks, and your btree dies. For ext2, you'll typically only loose the files on these blocks.
Wrt. to gcc as shipped in Red Hat Linux 7, there's no doubt this is the best compiler out there currently. The issues are wrt. to binary compatibility with C++ and not sufficient labeling as a release made by Red Hat, not by the gcc steering committee. And even so, this is not data corruption - a bug or two in a app is regrettable, corrupted data unacceptable. And corrupted data is what you get with the 2.4 kernel SuSE ships.
The installation of Red Hat Linux is IMNSHO way ahead of anything else out there - the SuSE one is really bad (and has a non-free license), and I'm not to keen on the Mandrake one either.
Note that the updates will break some builds - e.g. newer glibc cleaned up some name space polllution ( vs ), this broke compiling for a lot of packages. Both the pollution and the apps depending on it were fixed for Red Hat Linux 7., but this not released for RHL 7 as it didn't affect functionality.
We do mass rebuilds on a regular basis, so the packages should build - if you experience bugs with this, report it in bugzilla
As for updates, security in general, etc. you'll notice that RHL is ahead there too. Online updates (up2date) has been around for years. 3D support was added when it was integrated into XFree, and stabilitywise Mandrake is shipping known broken components in the kernel (ReiserFS, supermount etc).
No, our kernel people don't think it's safe - ReiserFS had quite a few bugs fixed the last month or so. And for filesystems, data integrity is an absolute requirement - this is the first distribution with a 2.4 kernel not known to destroy filesystems under load.
It is enabled in the kernel, but not during install.
up2date also has functionality not found in apt-get, such as server/client authentication and verification of the origins of the update (the latter may be solved in the rpm version of apt, but standard Debian can't do it - get trojaned packages onto a mirror, and watch people use it)
Which brings me to another question: wtf haven't you people jumped into wine?
It's included in Red Hat Powertools 7.1
That said, I will be happy if gcc-2.95.x is in there.
Of course not:
The next compiler change will occur at Red Hat Linux 8, and we expect it to include gcc 3. Regressing isn't a good thing
AFAIR, you get free usage of one system ("trial") but need to pay if you want to add more systems.
The i686 glibc supports the 2.4 feature "floating stacks" - variable stack size for threads. Existing JDKs have a hardcoded assumption of 2 MB, and this limit in strange, weird and unsupported ways.
There are two work arounds for these buggy JDKs:
- Install the i386 glibc, not the i686 glibc. It doesn't require a 2.4 kernel and doesn't have floating stacks.
- Run your JDK with 'LD_ASSUME_KERNEL=2.2.5'.
Either one should work. We also expect fixed JDKs to become available in the not too distant future.But why would you want to? The version we ship produces better code, has more bugfixes and less known problems and is binary compatible with the rest of the distrubution.
Using gcc 2.95.3 is setting you up for a world of PM.
There aren't known stability issues with Red Hat Linux 7 - of course, as with any distribution you should apply the updates for it but few of these are Red Hat specific. With those, it's a great platform with good performance.
Tux isn't khttpd.
There are no iso files for Alpha, as we haven't announced a product for Alpha yet.
As for SPARC, we're not doing distributions of it - just development snapshots. It's just not worth the development, QA and manufacturing effort right now.
Does anyone know which version of the 2.4 kernel they are including?
An early 2.4.2ac with _lots_ of bugfixes - the kernel team fixed a couple of file corruption bugs a day for weeks.
There's no point running the overhead of Apache for serving static files and that's about all that Tux is good for.
Tux handles dynamic content just fine - in fact, it's a large part of the specweb benchmarks.
SDL was developed by Loki to simplify their own job - porting standard commercial games from Windows to Linux. Thus, it's already being used for "professional" project with cutting-edge, commercial games and is proven technology - at least on the Linux platform.
Yes, but they have the right to modify and redistribute it with the same (GPL) license - you can control who gets it, but not what they do with it.
The part you're quoting is the part which guarantees the user the source to the binary - so you can't say that the program is $50 and the source $5000.
The GPL has no restrictions whatsoever on price of the binary - you can charge whatever you like.
Another issue many don't understand: You have to own the binary to have a claim to the source.
The GPL does not say that you have a right to get anything for free: It just says that you have a right to the source if you get the program, that changes are GPL as well if you distrbute them and that you can redistribute the program freely with the same license.
So if someone sold a high priced 3D package and GPLed it, you couldn't demand that they give it to you or put it on the web - you could ask another one who already bought it to give to you, but if you don't have the program, you have no claim.
One of the reasons for the high price of the Ultras is the high price for components: It uses very fast (and expensive) memory chips, and this is the main reason for the performance increase. If memory serves, the memory on the GeForce Ultra is faster than on the GeForce3 - the latter uses new technology to make better use of available bandwidth instead of increasing it.
So until the prices on this kind of memory decreases quite a bit, I don't see the Ultras coming down
Oracle doesn't work with Red Hat Linux 7, as it does wacky things glibc 2.2 doesn't like - they're relying on undefined behaviour.
Saying it's "slower" isn't that accurate:
That aside, everything isn't perfect with the P4: It really needs a silicon shrink, and going with RAMBUS hurts it badly. It's by rambus, it's expensive and you could get as much performance by using DDR SDRAM and/or multiple memory interfaces. It's also rather expensive - I just bought myself an Athlon, and is happy with that.
We won't switch while in a major series, but after that we'll just ship compatibility libs and the new compiler.
In Red Hat Linux, all versions in a series (like 6.0, 6.1, 6.2) are binary compatible.
When we break backwards binary compatibility (like when we introduce new major versions of libc), we increase the major number.
its the principal behind it. there was no reason for RH to make a stupid move like that at all.
Of course there are reasons:
On the minus side: C++ isn't binary compatible with other versions of gcc. As we went with glibc 2.2, this wouldn't have been compatible with anything anyway (a combination of gcc and glibc is binary incompatible with any other combination). There has never been C++ binary compatiblity on Linux, and there won't be until gcc 3.0 is released and used.
As you can see above, there is no doubt that on technical merits, this was the choice to do. And we did it. Unfortunately, we could have handled the political situation better. As for the end-user experience, that's irrelevant.
When gcc 3.0 comes out, we intend to switch to that at one point - "when" is dependent on when gcc 3.0 is actually released and how it fits into our cycles, as it will be a binary incompatible change.
PS: Mandrake uses it too.
We don't ship 2.95.3 - we ship a snapshotted, qaed and fixed brach from the gcc tree and call it "2.96RH". Mandrake, OTOH, ships 2.95.3 (no such thing) - but noone cares.