Re:What's wrong with more powerful = more expensiv
on
nVidia nForce
·
· Score: 2
Why is that? I mean, if it's very powerful, the graphics should be more than average, right?
No, the graphics won't be more than average - the GeForce 2MX, which is what Nvidia has integrated onto this motherboard, has been their value graphics chip for some time now. It isn't nearly as fast as GeForce2, GeForce2 Pro or GeForce3, and the motherboards aren't even on the market yet.
What the post you replied to pointed out, is that this is a strange combination - while other features on the motherboard, like the built in sound and memory architecture are high end, the graphics aren't in the same class. So many (myself included) would like to have the same chipset, without the builtin graphics - no point in having that chip if you want to buy a top-of-the line graphics card anyway.
Just thinking back to the wars between distributions, Red Hat, who invented Linux
We didn't invent Linux, or even the concept of a Linux distribution. Red Hat Linux was the first
distribution with a decent package system, and overtook the previous leader, Slackware. And Slackware wasn't the first one either... it replaced SLS as the leader earlier.
and brought it to the marketplace, has their
own proprietary code contained within the source
That's not correct - our kernels don't contain proprietary code. The only proprietary code in Red Hat Linux is netscape 4.x, which we intend to replace with mozilla (already included, the question is when we can drop netscape 4.x without users complaining too much). Our kernels come with full source code - and if you look in the SRPM, you'll find all the patches nicely separated and categorized.
Why do you think that they give pre-compiled kernels?
So we can be sure that the kernels are working and tested, and compiled with a known good toolchain, to name two reasons.
Red Hat, Inc. is not profitable - we're break even. True, we are looking for profits in the not too distant future, but no announcements have been made.
Caldera has huge profits? They have no market share, a huge loss - $10 million. On revenue of $1 million. And I don't see the SCO purchase as a good move - SCO wasn't exactly a growing business. And if you want to move off SCO (as many do) and go to Linux, Caldera isn't exactly the place you'd look: It has no mind share. You'd go with the company who has the people to make your company be successful, and that is Red Hat.
It's used for more and more projects in Red Hat Linux - it's used in the installer (since RHL 6.1), it's used in up2date, it's used in our new batch of configuration tools. If there needs to be a GUI, glade and python are there from the start.
You mention Qt - and we fought the ideals we (well, they - I wasn't working there then) believed in and put resources into a free desktop: GNOME.
While QT may be free now, it (and thus KDE built on top of it) certainly wasn't free then - and we took the consequence of that, opening markets for people who cared less for principles and open source and more about giving a group of users the KDE they wanted.
Read the licenses of djbdns and qmail, and you'll see why we can't ship them: If a hole is discovered, we're not allowed to distribute a fixed version in binary form.
As for Netscape, there really wasn't an alternative when we added it - there now is. qmail and djbdns, OTOH, would have a hard time making it in anyway as there are other alternatives with better licenses. Qmail isn't a "must have", when we already have sendmail, postfix and exim
Speaking of the other old ones: Caldera was Red Hat Linux with proprietary add-ons at that time - they had Looking Glass, a weird desktop thing.
The oldtimers around here always wonder how Caldera, with so much money and many people at the time managed to become what they are (a company with revenue of about $1 million, spending $10 million to get there).
As for the packaging format: One of the main reasons for the LSB is to give a vendor/packager the possibility of creating one package and then have it run on "Linux". Specifying multiple package formats doesn't help to reach that goal... Note that being able to use it everywhere is important, so only a subset of RPM functionality can be used (so alien can convert to other package formats (well,.deb -.tgz isn't really sufficient) without loosing functionality required by the package). An example of excluded functionality is triggers.
I started using Red Hat Linux in '95, and it wasn't the first release of RHL - Debian wasn't out with 1.0 (actually 1.1) at the time, and was insignificant: The big distro at the time was Slackware. The other major distros have also been around for some time - some spinoffs are a bit newer (like Connectiva and Mandrake).
They all use it already - (except Debian (deb) w/recent derivatives (only Progeny is currently active, AFAIR - Corel has stopped, Stormix is broke) and Slackware (no real package system)).
Among the current users are Red Hat Linux, Mandrake, SuSE, Turbo, Caldera, Immunix, Trustix, Connectiva and all of the derivatives of Red Hat Linux.
Sorry, I meant for commercial and high-end support - for a normal user with a new user's needs, nothing beats participating in a LUG.
Now, if you increase the difficulty level a bit, LUGs become less resourceful and the commnunity of users using the same software become more important - but if you're a corporation and need your answers quickly, then the support we offer is a very valuable tool. E.g if your web servers are down or are having performance problems and it needs fixing now, our Stronghold and kernel teams are second to none.
Red Hat Linuxcare's biggest client? I doubt that - we have high-quality support up to 24/7 enterprise level and make money from it. Why would we waste money buying services when we have deeper knowledge of different aspects of Linux than Linuxcare, and good people to deal with it? We're the premier source for support on Linux.
We bundle business card size rescue CDs with some of the Red Hat Linux products in Europe - at least, we did so with Red Hat Linux 7 professional there, and I don't know that we've stopped.
Look for a BIOS update from your vendor - most mothersboards seem to have gotten one, except the ones from ASUS (unfortunately - I have one myself).. Also, if there is a choice in your BIOS, turn performance down from "Optimal" to "Normal". Using PIO instead of DMA would be beneficial - turn it off in the BIOS.
As for recompilation, remember to run "make mrproper" first - the tree we ship isn't clean (so people can compile modules without having to compile a kernel first).
What kernel to use varies... right now, 2.4.4 should be OK. 2.4.3 wasn't (we made fixes after 2.4.3 was released... but as we were working hard on stabilizing it, upgrading didn't make sense as it didn't solve the disk corruption problems we were seing on all hardware (and which we fixed)). The ac kernels are usually a little bit closer to what we ship (well, they have some patches we have and some we don't) - and you can also find newer kernels in rawhide.
Of course, it all depends on what you're previously running - if you're running a previous 2.4 kernel from Linus.
Many file system corruption bugs were found by us during development of Red Hat Linux 7.1. The 2.4.2-2 kernel in Red Hat Linux 7.1 should be safe, any kernel released prior to that (our release, not 2.4.2 in general - our kernels has lots of fixes, some made after the official release of 2.4.3)
Using the "-pipe" option for gcc gives you the same benefits for compilation:
-pipe Use pipes rather than temporary files for communication between the
various stages of compilation. This fails to work on some systems
where the assembler cannot read from a pipe; but the GNU assembler
has no trouble.
Hardly... 2.4.3 has severe disk corruption issues, unless you use the patches we put into the kernel for Red Hat Linux just before shipping or use 2.4.3ac(recent). Whether you grabbed our patches or not, I don't know.
As for JDK, they won't run with floating stacks (bug in JDK, not glibc) - read the release notes for Red Hat Linux for more information, where you can find out more about the problem. You probably have the workarounds from our glibc rpms already.
As for the SuSE installer, that's my personal impression: Nothing else. I don't like it. I've used Red Hat Linux since 2.0ish, and I like our installer very much (I don't miss 40 floppies of slackware:). The only two other installers I've been impressed about in those years are Caldera when they started tetris during install and Corel (apart from it's obvious shortcomings, but it redefines simple). SuSE's installer just seem unpolished and confusing to me.
As for 2.4 kernel, it's not FUD. During heavy load it corrupts your hard drive rather well. Take a look at the last changes for the 2.4 AC kernel, look for corruption and who fixed it and realize SuSEs kernel can destroy your system. No FUD necesarry. We discovered severe disk corruption during testing, and they are present in all vanilla 2.4.x kernels, the previous ac kernels
and the kernel SuSE shipped (we tested just for fun). However, SuSE knew their 2.4 kernel was experimental and use 2.2 as default. I'm guessing that because of this, they didn't test it very much.
Slashdot Mirror
Why is that? I mean, if it's very powerful, the graphics should be more than average, right?
No, the graphics won't be more than average - the GeForce 2MX, which is what Nvidia has integrated onto this motherboard, has been their value graphics chip for some time now. It isn't nearly as fast as GeForce2, GeForce2 Pro or GeForce3, and the motherboards aren't even on the market yet.
What the post you replied to pointed out, is that this is a strange combination - while other features on the motherboard, like the built in sound and memory architecture are high end, the graphics aren't in the same class. So many (myself included) would like to have the same chipset, without the builtin graphics - no point in having that chip if you want to buy a top-of-the line graphics card anyway.
There is a difference between good performance (standard use) and exceptional performance, like the one Tux gets.
Just thinking back to the wars between distributions, Red Hat, who invented Linux
We didn't invent Linux, or even the concept of a Linux distribution. Red Hat Linux was the first distribution with a decent package system, and overtook the previous leader, Slackware. And Slackware wasn't the first one either... it replaced SLS as the leader earlier.
and brought it to the marketplace, has their own proprietary code contained within the source
That's not correct - our kernels don't contain proprietary code. The only proprietary code in Red Hat Linux is netscape 4.x, which we intend to replace with mozilla (already included, the question is when we can drop netscape 4.x without users complaining too much). Our kernels come with full source code - and if you look in the SRPM, you'll find all the patches nicely separated and categorized.Why do you think that they give pre-compiled kernels?
So we can be sure that the kernels are working and tested, and compiled with a known good toolchain, to name two reasons.
How does any game that involves recompiling the kernel get a 10/10 for installation?
That isn't a property of the game install - the game will work right out of the box if you have a properly configured system(3Dwise).
The Vine people now work for Red Hat - our last release works out of the box with Japanese, if you want it to.
(I work for Red Hat as a developer)
It's used for more and more projects in Red Hat Linux - it's used in the installer (since RHL 6.1), it's used in up2date, it's used in our new batch of configuration tools. If there needs to be a GUI, glade and python are there from the start.
You mention Qt - and we fought the ideals we (well, they - I wasn't working there then) believed in and put resources into a free desktop: GNOME.
While QT may be free now, it (and thus KDE built on top of it) certainly wasn't free then - and we took the consequence of that, opening markets for people who cared less for principles and open source and more about giving a group of users the KDE they wanted.
Read the licenses of djbdns and qmail, and you'll see why we can't ship them: If a hole is discovered, we're not allowed to distribute a fixed version in binary form.
As for Netscape, there really wasn't an alternative when we added it - there now is. qmail and djbdns, OTOH, would have a hard time making it in anyway as there are other alternatives with better licenses. Qmail isn't a "must have", when we already have sendmail, postfix and exim
Netscape 4.x has LDAP support, but Netscape 6 hasn't .
Speaking of the other old ones: Caldera was Red Hat Linux with proprietary add-ons at that time - they had Looking Glass, a weird desktop thing. The oldtimers around here always wonder how Caldera, with so much money and many people at the time managed to become what they are (a company with revenue of about $1 million, spending $10 million to get there).
As for the packaging format: One of the main reasons for the LSB is to give a vendor/packager the possibility of creating one package and then have it run on "Linux". Specifying multiple package formats doesn't help to reach that goal... Note that being able to use it everywhere is important, so only a subset of RPM functionality can be used (so alien can convert to other package formats (well, .deb - .tgz isn't really sufficient) without loosing functionality required by the package). An example of excluded functionality is triggers.
I started using Red Hat Linux in '95, and it wasn't the first release of RHL - Debian wasn't out with 1.0 (actually 1.1) at the time, and was insignificant: The big distro at the time was Slackware. The other major distros have also been around for some time - some spinoffs are a bit newer (like Connectiva and Mandrake).
All of the above has been around for some time, and the userbase of Red Hat Linux, Mandrake and SuSE is much bigger than Debian.
They all use it already - (except Debian (deb) w/recent derivatives (only Progeny is currently active, AFAIR - Corel has stopped, Stormix is broke) and Slackware (no real package system)).
Among the current users are Red Hat Linux, Mandrake, SuSE, Turbo, Caldera, Immunix, Trustix, Connectiva and all of the derivatives of Red Hat Linux.
Sorry, I meant for commercial and high-end support - for a normal user with a new user's needs, nothing beats participating in a LUG.
Now, if you increase the difficulty level a bit, LUGs become less resourceful and the commnunity of users using the same software become more important - but if you're a corporation and need your answers quickly, then the support we offer is a very valuable tool. E.g if your web servers are down or are having performance problems and it needs fixing now, our Stronghold and kernel teams are second to none.
Red Hat Linuxcare's biggest client? I doubt that - we have high-quality support up to 24/7 enterprise level and make money from it. Why would we waste money buying services when we have deeper knowledge of different aspects of Linux than Linuxcare, and good people to deal with it? We're the premier source for support on Linux.
We bundle business card size rescue CDs with some of the Red Hat Linux products in Europe - at least, we did so with Red Hat Linux 7 professional there, and I don't know that we've stopped.
Look for a BIOS update from your vendor - most mothersboards seem to have gotten one, except the ones from ASUS (unfortunately - I have one myself).. Also, if there is a choice in your BIOS, turn performance down from "Optimal" to "Normal". Using PIO instead of DMA would be beneficial - turn it off in the BIOS.
As for recompilation, remember to run "make mrproper" first - the tree we ship isn't clean (so people can compile modules without having to compile a kernel first).
What kernel to use varies... right now, 2.4.4 should be OK. 2.4.3 wasn't (we made fixes after 2.4.3 was released... but as we were working hard on stabilizing it, upgrading didn't make sense as it didn't solve the disk corruption problems we were seing on all hardware (and which we fixed)). The ac kernels are usually a little bit closer to what we ship (well, they have some patches we have and some we don't) - and you can also find newer kernels in rawhide.
Of course, it all depends on what you're previously running - if you're running a previous 2.4 kernel from Linus.
Many file system corruption bugs were found by us during development of Red Hat Linux 7.1. The 2.4.2-2 kernel in Red Hat Linux 7.1 should be safe, any kernel released prior to that (our release, not 2.4.2 in general - our kernels has lots of fixes, some made after the official release of 2.4.3)
Using the "-pipe" option for gcc gives you the same benefits for compilation:
AFAIR, it's part of the kernel in Red Hat Linux 7.1, so it's gotten almost as much exposure as the rest of the 2.4 kernel.
Hardly... 2.4.3 has severe disk corruption issues, unless you use the patches we put into the kernel for Red Hat Linux just before shipping or use 2.4.3ac(recent). Whether you grabbed our patches or not, I don't know.
As for JDK, they won't run with floating stacks (bug in JDK, not glibc) - read the release notes for Red Hat Linux for more information, where you can find out more about the problem. You probably have the workarounds from our glibc rpms already.
Since when did debian packages support cryptographic authentication? I'm quite sure that would be a recent addition.
As for the SuSE installer, that's my personal impression: Nothing else. I don't like it. I've used Red Hat Linux since 2.0ish, and I like our installer very much (I don't miss 40 floppies of slackware:). The only two other installers I've been impressed about in those years are Caldera when they started tetris during install and Corel (apart from it's obvious shortcomings, but it redefines simple). SuSE's installer just seem unpolished and confusing to me.
As for 2.4 kernel, it's not FUD. During heavy load it corrupts your hard drive rather well. Take a look at the last changes for the 2.4 AC kernel, look for corruption and who fixed it and realize SuSEs kernel can destroy your system. No FUD necesarry. We discovered severe disk corruption during testing, and they are present in all vanilla 2.4.x kernels, the previous ac kernels and the kernel SuSE shipped (we tested just for fun). However, SuSE knew their 2.4 kernel was experimental and use 2.2 as default. I'm guessing that because of this, they didn't test it very much.
Having 64 GB of RAM won't help you with quake III. IA32 is still a 32-bit architecture, so one process can only see 4 GB at a time.