Oh my GOD! I can't spare the bandwidth to download TWO copies of Mesa! Oh whatever will I do!
Seriously though, the RPM-packagers logic is seriously flawed. If you've got a slow connection, then more likely than not, you will just download a bunch of stuff overnight. In that case, you don't care about the extra size, and it makes it more complex to download multiple packages (you've got to either FTP or use something like GetRight.) If you've got a fast connection, you really don't give a damn if the download is 10 megs larger. Usually the RPM-bloated packages don't make sense. If I'm downloading GNOME, chances are that I won't already have GTK, glib, fnlib, etc. Those that do, are in the minority. Even then, most will have to download the latest versions of the packages anyway. Slackware has the right idea. KDE2 is in two tar.gzs (the KDE2 tarball, and the Qt tarball.)
1) ISA has been officially dead for 3 years. It's not going anywhere soon. You really think people are going to ditch PS/2 and parallel just like that? It took 3 years after ISA was denounced until motherboards finally started appearing without ISA slots. ISA will be relevant for another 1 or 2 years at a minimum. So a total of 5 years from the time a technology is pronounced dead, to the time it actually dies. The same will go for PS/2 and parallel/serial (even if ISA is gone, they'll probably move PS/2 somewhere else). PC2000 or PC2001 will reccomend USB slots only, and around 2005-2006, USB-only motherboards will be the norm. The point is, that USB won't really be all that relevant for another 2 years minimum. Announcements or not, when I find a critical piece of hardware that is USB-only, then I'll consider it. Until then, 3D accelleration is a much bigger problem that USB.
No. Saying Linux will be as valid as Windows for the desktop is deluding yourself. I can (and have) listed numerous reasons why Linux isn't yet ready for the desktop, so ready my past posts before responding. Few examples:
Office Suites: If WordPerfect Office 2000 is better in Windows than in Linux, why use Linux?
Gadget Software: Where's that ultra-simple photo-grabber/correcter for my $50 scanner?
Games: Even QuakeIII get's boring eventually.
Being "as valid" for the desktop as Windows takes more than just technical quality. It takes creature comforts, asthetics, ease of use, integration.
1) There are very few creature comforts in Linux. Sure stuff like ActiveDesktop or Win98 Explorer (with the integrated preview) are not absolutely necessary, but they're nice to have.
2) Linux has no asthetics. Asthetics goes beyond pretty GUIs into the system itself. There is only so much KDE and GNOME do for you. Once you get into the system itself, its ugly. Initscripts are ugly (except in Slackware). Adding hardware is ugly. The config files are ugly. (My thinking is that the whole mess in/etc could be condensed into a dozen well planned files.)
3) Linux has a learning curve shaped like an L. Sure, if your doing basic stupid-user stuff, it's just as easy as Windows. However, the minute you need to do something a little more advanced (like install non-KDE software!) or have to configure hardware less than 10 years old, you've got a problem. Take ALSA for example. This is supposed to be the next-gen Linux sound architecture, but I need to tell it how many soundcards I have? WTF! Need to install NAT? Though luck, you have to figure out the mess in/etc/rc.d first. Setting up a telnet server? Figure out inet first. It doesn't have to be that way. Take a look at BeOS. Setting up telnet and ftp servers is literally just a checkbox and a password-field away. Look underneath, however, and you have those plain-text config files, giving power to both groups of users. For some odd reason, no enterprising distro maker thought of this? (And don't point me to some link on FreashMeat. If the user was advanced enough to do that, then they'd be able to figure out inet. Also, find a way to get that link to the thousands of people who are sitting without a personal telnet server (incredibly usefull if you've got DSL and a static IP) because they can't figure it out. Another this is recompiling important system software. One of the great potential benifits of Linux is allowing users to custom compile their software for speed. However, most system software is so ridiculously (comparativly) difficult to hand configure, that this feature goes unused. A GUI interface for making any source package? That's the right thing to do. If Linux were judged by the same standards Windows is judged by, reviewers would bitch constantly about this missed opportunity. The bottom line is that Linux is hard. For ultra-basic uses, it may be easy, but the minute you venture out of KDE or GNOME, you hit a mess of legacy configuration crap, ill-thought-out configuration methods, and a totally inconsistant system. In Linux there are no advanced or intermediate users. There are newbies, and there are UNIX-gurus.
4) Linux isn't an OS. It is a bunch of software randomally glued together by a distro maker. Case in point: Some software uses make config/make/make install. Others use straight make. Others use the BSD style edit the config file, run make. Others use xmkmf. The kernel uses its own method. That's the wrong way to do it. There is no standard format for config files. Good GUI interfaces for configuration aren't included in the OS, and aren't similar to each other. Sure it may be hard to get so many developers to agree, but consistancy is a good thing for an OS to have, and I could care less about the managerial problems on OS has to bring consistancy to me. If its an inherent problem with the development model, then too bad, Linux should be judged by the same ruler as a commercial OS.
Nifty configuration in the OS from Linux? Yea right.
As for USB being the most significant hardware lackage, I'd cite 3D acceleration, force feedback, 3D sound, and winmodems ahead of USB support. Namely because no real hardware is totally USB dependant.
Now before you "flamebait" this, think about a minute. How many messages have you seen on Windows message boards that say "I can't install the drivers correct?" You see, "the computer crashes when I update the drivers," and "I had to reinstall to update the drivers," but you rarely see problems of this nature. That is such a waste. Linux has these good qualities that stuff usually works. However, people who write Linux applications/systems, really have no clue how to package stuff for the user all friendly-like. Who cares if it's totally stable if you can't even INSTALL it? As long as people keep distributing important things (like Glide, or XFree86, or the NVIDIA drivers) with poor documentation and no installer, Linux will continue to suck for a large portion of the computing population, despite any technical merits it may have.
If you use entirely free software, you're an idiot. Stand up for something important. Save the environment, feed the poor. Software is software. Supporting it will just help people who have good jobs anway, whether or not they get paid for it. If you're going to give up so much more performance just for the sake of free software, than OSS is screwed. If OSS doesn't have to be held to the same standards of quality as everyone else, then OSS programs will suck. Use the best hardware in your price range and screw the open/closed-ness of the drivers. Look at it pragmatically, without religious frevor. Linux is an important platform for SGI/NVIDIA. They will support it for the forseeable future. Given that, the open-ness of the drivers shouldn't matter.
It's a terrible idea because it breaks OpenGL complience. Also, you don't put a windowing system into a graphics library, you do the reverse. The true solution is this. Dump X. Dump the hell out of it. Develop Berlin. You've got your rotating, spinning, OpenGL accelerated windows.
Don't delude yourself. If you're going to spend good money on a video workstation, use NT. Linux might eventually be great for video, but right now, the platform is just too immature and the programs aren't quite there yet. Your experience in NT will be a lot more stable, and you'll have a much more flexible environment (in terms of programs and all.) Any CPU in the 450MHz+ range ought to do it, memory should be 256MB at least, and you need a fast harddrive. (A fast Ultra66 drive like IBM or Maxtor will be fine.) You'll need a firewire card (maybe $150-$200 for a decent one) and around $700-800 on a good camera. (The Canon ZR10's are pretty good. If you can afford it, get a Sony. They're quirky (like 20minute minidiscs as storge and has an ethernet interface instead of firewire) and they're hideously expensive (2.5K) but has unbelievable image quality.
The GeForce2 will kicks the G400's ass all over the place in terms of performance. The G400 (don't buy the 450 if you can afford the G400MAX, the 450 is lower performance) has better image quality, but it really isn't noticible unless your running 1280x1024+. Also, unless you've got a really good monitor you won't notice it that much at all. However, if you're not going to use 3D, G400 is the way to go (unless your running Linux, then GForce2 seems to be faster/less flaky.) G400MAX also tends to have better color quality in both normal running and 3D rendering. However, if performance is at all important, then buy a GeForce2. You won't be dissapointed with rendering quality or image quality. It's not as good as Matrox's, but is easily a solid second, and the card offers a much better performance/quality ratio that the G400MAX.
I think the memory bandwidth problem is best solved by ATI and Matrox. ATI uses its HyperZ archtecture to greatly reduce the number of reads into the Zbuffer, which really helps memory bandwidth. The fact that it can beat a GForce2 in some tests (only one or two now that the Detonator 3 drivers are out. In the others it still loses significantly Check www.sharkyextreme.com for the latest benchmarks in the ATI 32MB Radeon review) even though its runs as a significantly lower clock and has a good deal less fill-rate is a good indication of this. Matrox seems to have the best idea with its DualBus. Put two 128bit DDR SDRAM interfaces on the board and watch the bandwidth problems magicall dissapear.
Maybe you should comfort yourself in the fact that we've got a government. And the government checks to make sure harmful things don't reach consumers. Hell, they'll take you to task for not putting "Caution: Hot things may be hot" on the side of your mugs, and you think they'll let microwaves get through?
Disclaimer: I love OpenGL. I program mainly in OpenGL. I have no love of Microsoft.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Friends, OpenGL is in grave danger. Already, OpenGL has become a stagnated API, with most new and intereseting features relegated to propriatory extensions. In a world where different types of graphics cards abound, and the standardness of an API is critical, important innovations should NOT be tied to extensions.
Extensions are propriatory to a particular vendo. They lead to games that don't use the hardware effectively (ie. You buy a graphics card that supports per-pixel shading, you buy a game that support per-pixel shading, but your game won't run accelerated on your graphics card, because your graphics card implements NVIDIA's version of the extension, why the game uses ATI's.) They lead to the standard become weak. They lead to headaches for developers. They lead to headaches for hardware makers. All this bites the consumer in the ass. They lead to broken hearts, anguish, and Lucifer himself! (Sorry, I just read The Crucible.) Of course, ARB extensions could save OpenGL. However, ARB extensions are few and long in coming. By the time a standard ARB-register-combiner (per pixel shading) extension comes out, hardware makers will already have introduced new features, and software makers will already have a stable of hardware-specific games. (Or, they won't use those features at all. Sucks for the guy who paid for that NSR unit that's not being used.) In short, extensions are the devils work and should be sent back to the hell-fire from whence they came.
MS is coming. OpenGL found solace in the fact that D3D was an utter piece of shit, beyond hope and repair. However, MS doesn't take lightly to people who diss their API. And the DirectX team at MS can actually CODE! The result is that in current incarnations, DirectX7 and DirectX8 are VERY competitive with OpenGL, both in terms of speed, and features. Best of all, new features are incoperated into the standard. Despite what people prefer to believe, DirectX isn't done in standard MS-empircal way. They consult hardware developers, they consult software developers, and they make a standard from that. New feautres get put in the API, hardware manufacturers accelerate those features, and developers code for those features. Everything works together, everybody is happy. This way of extending the API has another great benifit. D3D simply has more features than OpenGL. Sure a lot of those features may be in OpenGL extensions, but extensions are propriotary, and we all hate anything propriotary, don't we;)
Saying that OpenGL will always rule is deluding yourself. People thought SGI would always use UNIX too, before the NT-based workstations came out. Luckily, Linux came to SGI's rescue. A cheap, powerful solution to NT. OpenGL has no such rescuer in sight. Already, people are breaking ranks and realizing that D3D8 is not that same piece of junk everyone scorned. The creator of UT has already stated his distaste for OpenGL. When DirectX8 becomes the better API (which it undoubtedly will, if it already hasn't) then not even Carmack will be able to save OpenGL. Those who still doubt the pluasability of Direct3D, take note. Direct3D 8 is vastly superior to D3D 3. Each release keeps getting much better. Given the fact that D3D is improving faster than OpenGL, simple math will tell you that eventually it will overtake OpenGL (if it already hasn't, and a lot of people WILL tell you that D3D 8 is already there.)
Of course, there is one ridicoulously simple way to resolve this problem. I say that the ARB get's off it's collective ass and works on OpenGL. Dump extensions, (or at least speed up the pace of ARB extensions, which is probably the better short-term solution) improve the API, and market it. Right now, OpenGL still enjoys an air of superiority. Making it competitive with D3D (both in power and growth) will cement it as THE standard 3D API. The sucess of OpenGL has greater ramifications that just 3D. If OpenGL ever falls from favor, alternative platforms are doomed. Games stop being written for Linux and BeOS, and everyone goes back to using Windows. MS has the advantage at the moment. The success or failure of D3D isn't terribly critical to it's platform, because they support OpenGL too. However, alternative platforms have a problem. There is no huge installed base of OpenGL-only machines to keep people on the platform. If D3D becomes that much more feasible, then developers (aside from a few like Carmack) won't pay much of a second thought to developing for D3D and making their games Windows-only again. They'll only lose negligibe sales, and after the Linux hype is over (face it, that's the only reason games are ported at the moment, hype, not potential for profit) then not developing for Linux really won't be a big deal. If the ARB acts swiftly, all this can be prevented. OpenGL can soldifiy its place as the standard, Linux can continue its erosion of Windows's market share, and people like me can keep developing for OpenGL (on BeOS of course!) without getting the felling that we're using inferior technology.
Whoa, sombody is in to consipracy theories. It seems that you don't realize that online polls are extremely hackable. If you read over some of the BeOS NewLetters, they'll tell you a story of how they rigged the Yahoo OS poll. First, they scripted Netpositive to repeatedly go to the voting URL and vote for BeOS. Then, they realized that they could get votes just be reloadeding the after-vote page, so they did. Eventually, the had several Linux machines (because Lynx only runs on Linux) running Lynx and a script to repeatedly vote for BeOS. When the manager thought they should find a better use for their time, the resorted themselves to continually voting for N64. As I remember, it, due to their efforts (and the chain effect that it caused) N64 came away with 28% of the votes.
True. Sorry 'bout that. The magazine was Boot, Atiq Riza denied the 25% rumor. I must have remembered it backwards (the issue is two years old). However, the yeilds WERE very low at that time.
Problem: Why the f*ck is there a book about a PACKAGE MANAGEMENT SYSTEM! A package manager should be akin to a boot-loader in simplicity. There shouldn't be more than a page of documentation on the thing.
Oh, say the recall of the 1.13 GHz P3? It couldn't pass the Linux kernel compile test for all its worth.
It also required a special BIOS to load up special microcode that it needed to be even remotely
stable. Note that it was quickly recalled for a re-tape and re-mask.
>>>>>>>>
How about the fact that AMD's yeild during the K6 eras was around 25%? All chip companies occasionally have yeild problems. It's not necessaryily demonstrative of the quality of future chips. And unless you got burned by the 1.13GHz recall, then you've got no problems. I don't hear to many people complaining about the stability of the 900-1000MHz PIIIs.
MMX speed up 3D? I don't remember anyone marketing it as that, at best, it sped up multimedia,
such as audio and some video functions, and codecs that used floating point math weren't widely
used either. MMX was only integer when I checked the instruction set. IIRC, Floating point 3D
became used more widely when the Pentium came out, as well as the fact that the 486DX's had them
too, not.
>>>>>>>>>>
MMX was designed to speed up multimedia, but mainly to compete with the 3D cards that were coming out. If you look at MMX, it actually does help for the rendering part of the pipeline. That's exactly why it is useless, because 3D cards these days handle that part of the pipeline. And floating point 3D was not at all common until the PentiumMMX and the first wave of 3D cards. Quake, DukeNukem3D, Doom, Wolfenstien, they all used fixed-point math. If you read any of the game programming docs from the era, you'll notice that it wasn't until into the PII's release that they stopped teaching how to do fixed point math.
IIRC, Alpha didn't have SIMD instructions per se, but it did have most of the functions that MMX
had, right from the start, circa 1991, due to having extensive byte manipulation methods and having
64 bit registers. I don't recall seeing SIMD add, subtract or multiply functions in the instruction set
until MVI was introduced, I have never used it. That mostly only added add, subract and multiply,
min, max as well as a couple more byte shuffling instructions.
>>>>>>
However, MVI does exist, and it is designed to allow the Alpha to perform better in multimedia software. (According to Digital's press release.) The point is that MMX wasn't a dumb idea. Every other chip comany is implementing similar instructions.
IIRC, Intel also had a hard time meeting demands for nearly entire quarters - a reason that Gateway
and such lowered their resistance to AMD chips. AMD is definitely giving them a run for the money,
and I will admit that neither company is perfect, and different chips are usually better at different
things.
>>>>>
Which quarters? Remember, AMD had a hard time meeting demands for more than a year during K6 era.
Your chips are already 64 bits in all the places you need them. The bus is 64 bits, FP is 80 bits, and SSE is 128 bits. Almost no-one needs 64bit integer units, and unless you have more than 4GB of RAM, you don't need 64bit memory addressing either. Maybe your talking about getting a RISC-type machine as opposed to 64 bit one? Remeber, even the G4 is a 32bit machine.
So AMD's total screwup of the K5 and original K6, it's it's mess-ups with the 2/5 clocked cached on the previous Athlons didn't make you lose trust in THAT company? Seriously though, people who base their opinions of a company on one or two debacles are stupid. Wait for the P4 to come out. See how it reviews. Try one out. Ask your friends how they like theirs. Compare it with an Athlon. Buy whichever you like best.
Actually, it's a balance of three things. First, it's market share. Which chip has the most units shipped. MMX had this, 3DNow! didn't. Second, it's marketing power. Intel has this, AMD doesn't. Third, it's technical feasability. SSE had this, MMX didn't. If any one of the three things is severly lacking (for example, MMX had market share, and it had volume, but was bad technically) then the standard won't succeed.
Oh my GOD! I can't spare the bandwidth to download TWO copies of Mesa! Oh whatever will I do!
Seriously though, the RPM-packagers logic is seriously flawed. If you've got a slow connection, then more likely than not, you will just download a bunch of stuff overnight. In that case, you don't care about the extra size, and it makes it more complex to download multiple packages (you've got to either FTP or use something like GetRight.) If you've got a fast connection, you really don't give a damn if the download is 10 megs larger. Usually the RPM-bloated packages don't make sense. If I'm downloading GNOME, chances are that I won't already have GTK, glib, fnlib, etc. Those that do, are in the minority. Even then, most will have to download the latest versions of the packages anyway. Slackware has the right idea. KDE2 is in two tar.gzs (the KDE2 tarball, and the Qt tarball.)
1) ISA has been officially dead for 3 years. It's not going anywhere soon. You really think people are going to ditch PS/2 and parallel just like that? It took 3 years after ISA was denounced until motherboards finally started appearing without ISA slots. ISA will be relevant for another 1 or 2 years at a minimum. So a total of 5 years from the time a technology is pronounced dead, to the time it actually dies. The same will go for PS/2 and parallel/serial (even if ISA is gone, they'll probably move PS/2 somewhere else). PC2000 or PC2001 will reccomend USB slots only, and around 2005-2006, USB-only motherboards will be the norm. The point is, that USB won't really be all that relevant for another 2 years minimum. Announcements or not, when I find a critical piece of hardware that is USB-only, then I'll consider it. Until then, 3D accelleration is a much bigger problem that USB.
No. Saying Linux will be as valid as Windows for the desktop is deluding yourself. I can (and have) listed numerous reasons why Linux isn't yet ready for the desktop, so ready my past posts before responding. Few examples:
/etc could be condensed into a dozen well planned files.)
/etc/rc.d first. Setting up a telnet server? Figure out inet first. It doesn't have to be that way. Take a look at BeOS. Setting up telnet and ftp servers is literally just a checkbox and a password-field away. Look underneath, however, and you have those plain-text config files, giving power to both groups of users. For some odd reason, no enterprising distro maker thought of this? (And don't point me to some link on FreashMeat. If the user was advanced enough to do that, then they'd be able to figure out inet. Also, find a way to get that link to the thousands of people who are sitting without a personal telnet server (incredibly usefull if you've got DSL and a static IP) because they can't figure it out. Another this is recompiling important system software. One of the great potential benifits of Linux is allowing users to custom compile their software for speed. However, most system software is so ridiculously (comparativly) difficult to hand configure, that this feature goes unused. A GUI interface for making any source package? That's the right thing to do. If Linux were judged by the same standards Windows is judged by, reviewers would bitch constantly about this missed opportunity. The bottom line is that Linux is hard. For ultra-basic uses, it may be easy, but the minute you venture out of KDE or GNOME, you hit a mess of legacy configuration crap, ill-thought-out configuration methods, and a totally inconsistant system. In Linux there are no advanced or intermediate users. There are newbies, and there are UNIX-gurus.
Office Suites: If WordPerfect Office 2000 is better in Windows than in Linux, why use Linux?
Gadget Software: Where's that ultra-simple photo-grabber/correcter for my $50 scanner?
Games: Even QuakeIII get's boring eventually.
Being "as valid" for the desktop as Windows takes more than just technical quality. It takes creature comforts, asthetics, ease of use, integration.
1) There are very few creature comforts in Linux. Sure stuff like ActiveDesktop or Win98 Explorer (with the integrated preview) are not absolutely necessary, but they're nice to have.
2) Linux has no asthetics. Asthetics goes beyond pretty GUIs into the system itself. There is only so much KDE and GNOME do for you. Once you get into the system itself, its ugly. Initscripts are ugly (except in Slackware). Adding hardware is ugly. The config files are ugly. (My thinking is that the whole mess in
3) Linux has a learning curve shaped like an L. Sure, if your doing basic stupid-user stuff, it's just as easy as Windows. However, the minute you need to do something a little more advanced (like install non-KDE software!) or have to configure hardware less than 10 years old, you've got a problem. Take ALSA for example. This is supposed to be the next-gen Linux sound architecture, but I need to tell it how many soundcards I have? WTF! Need to install NAT? Though luck, you have to figure out the mess in
4) Linux isn't an OS. It is a bunch of software randomally glued together by a distro maker. Case in point: Some software uses make config/make/make install. Others use straight make. Others use the BSD style edit the config file, run make. Others use xmkmf. The kernel uses its own method. That's the wrong way to do it. There is no standard format for config files. Good GUI interfaces for configuration aren't included in the OS, and aren't similar to each other. Sure it may be hard to get so many developers to agree, but consistancy is a good thing for an OS to have, and I could care less about the managerial problems on OS has to bring consistancy to me. If its an inherent problem with the development model, then too bad, Linux should be judged by the same ruler as a commercial OS.
Nifty configuration in the OS from Linux? Yea right.
As for USB being the most significant hardware lackage, I'd cite 3D acceleration, force feedback, 3D sound, and winmodems ahead of USB support. Namely because no real hardware is totally USB dependant.
I wonder if Slashdot would react the same way "MS is the all-consuming Borg" if Redhat objected to its children companies using NT on their machines.
It would work... if you were running Windows.
Now before you "flamebait" this, think about a minute. How many messages have you seen on Windows message boards that say "I can't install the drivers correct?" You see, "the computer crashes when I update the drivers," and "I had to reinstall to update the drivers," but you rarely see problems of this nature. That is such a waste. Linux has these good qualities that stuff usually works. However, people who write Linux applications/systems, really have no clue how to package stuff for the user all friendly-like. Who cares if it's totally stable if you can't even INSTALL it? As long as people keep distributing important things (like Glide, or XFree86, or the NVIDIA drivers) with poor documentation and no installer, Linux will continue to suck for a large portion of the computing population, despite any technical merits it may have.
If you use entirely free software, you're an idiot. Stand up for something important. Save the environment, feed the poor. Software is software. Supporting it will just help people who have good jobs anway, whether or not they get paid for it. If you're going to give up so much more performance just for the sake of free software, than OSS is screwed. If OSS doesn't have to be held to the same standards of quality as everyone else, then OSS programs will suck. Use the best hardware in your price range and screw the open/closed-ness of the drivers. Look at it pragmatically, without religious frevor. Linux is an important platform for SGI/NVIDIA. They will support it for the forseeable future. Given that, the open-ness of the drivers shouldn't matter.
It's a terrible idea because it breaks OpenGL complience. Also, you don't put a windowing system into a graphics library, you do the reverse. The true solution is this. Dump X. Dump the hell out of it. Develop Berlin. You've got your rotating, spinning, OpenGL accelerated windows.
Don't delude yourself. If you're going to spend good money on a video workstation, use NT. Linux might eventually be great for video, but right now, the platform is just too immature and the programs aren't quite there yet. Your experience in NT will be a lot more stable, and you'll have a much more flexible environment (in terms of programs and all.) Any CPU in the 450MHz+ range ought to do it, memory should be 256MB at least, and you need a fast harddrive. (A fast Ultra66 drive like IBM or Maxtor will be fine.) You'll need a firewire card (maybe $150-$200 for a decent one) and around $700-800 on a good camera. (The Canon ZR10's are pretty good. If you can afford it, get a Sony. They're quirky (like 20minute minidiscs as storge and has an ethernet interface instead of firewire) and they're hideously expensive (2.5K) but has unbelievable image quality.
The GeForce2 will kicks the G400's ass all over the place in terms of performance. The G400 (don't buy the 450 if you can afford the G400MAX, the 450 is lower performance) has better image quality, but it really isn't noticible unless your running 1280x1024+. Also, unless you've got a really good monitor you won't notice it that much at all. However, if you're not going to use 3D, G400 is the way to go (unless your running Linux, then GForce2 seems to be faster/less flaky.) G400MAX also tends to have better color quality in both normal running and 3D rendering. However, if performance is at all important, then buy a GeForce2. You won't be dissapointed with rendering quality or image quality. It's not as good as Matrox's, but is easily a solid second, and the card offers a much better performance/quality ratio that the G400MAX.
I think the memory bandwidth problem is best solved by ATI and Matrox. ATI uses its HyperZ archtecture to greatly reduce the number of reads into the Zbuffer, which really helps memory bandwidth. The fact that it can beat a GForce2 in some tests (only one or two now that the Detonator 3 drivers are out. In the others it still loses significantly Check www.sharkyextreme.com for the latest benchmarks in the ATI 32MB Radeon review) even though its runs as a significantly lower clock and has a good deal less fill-rate is a good indication of this. Matrox seems to have the best idea with its DualBus. Put two 128bit DDR SDRAM interfaces on the board and watch the bandwidth problems magicall dissapear.
Maybe you should comfort yourself in the fact that we've got a government. And the government checks to make sure harmful things don't reach consumers. Hell, they'll take you to task for not putting "Caution: Hot things may be hot" on the side of your mugs, and you think they'll let microwaves get through?
Disclaimer: I love OpenGL. I program mainly in OpenGL. I have no love of Microsoft.
;)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Friends, OpenGL is in grave danger. Already, OpenGL has become a stagnated API, with most new and intereseting features relegated to propriatory extensions. In a world where different types of graphics cards abound, and the standardness of an API is critical, important innovations should NOT be tied to extensions.
Extensions are propriatory to a particular vendo. They lead to games that don't use the hardware effectively (ie. You buy a graphics card that supports per-pixel shading, you buy a game that support per-pixel shading, but your game won't run accelerated on your graphics card, because your graphics card implements NVIDIA's version of the extension, why the game uses ATI's.) They lead to the standard become weak. They lead to headaches for developers. They lead to headaches for hardware makers. All this bites the consumer in the ass. They lead to broken hearts, anguish, and Lucifer himself! (Sorry, I just read The Crucible.) Of course, ARB extensions could save OpenGL. However, ARB extensions are few and long in coming. By the time a standard ARB-register-combiner (per pixel shading) extension comes out, hardware makers will already have introduced new features, and software makers will already have a stable of hardware-specific games. (Or, they won't use those features at all. Sucks for the guy who paid for that NSR unit that's not being used.) In short, extensions are the devils work and should be sent back to the hell-fire from whence they came.
MS is coming. OpenGL found solace in the fact that D3D was an utter piece of shit, beyond hope and repair. However, MS doesn't take lightly to people who diss their API. And the DirectX team at MS can actually CODE! The result is that in current incarnations, DirectX7 and DirectX8 are VERY competitive with OpenGL, both in terms of speed, and features. Best of all, new features are incoperated into the standard. Despite what people prefer to believe, DirectX isn't done in standard MS-empircal way. They consult hardware developers, they consult software developers, and they make a standard from that. New feautres get put in the API, hardware manufacturers accelerate those features, and developers code for those features. Everything works together, everybody is happy. This way of extending the API has another great benifit. D3D simply has more features than OpenGL. Sure a lot of those features may be in OpenGL extensions, but extensions are propriotary, and we all hate anything propriotary, don't we
Saying that OpenGL will always rule is deluding yourself. People thought SGI would always use UNIX too, before the NT-based workstations came out. Luckily, Linux came to SGI's rescue. A cheap, powerful solution to NT. OpenGL has no such rescuer in sight. Already, people are breaking ranks and realizing that D3D8 is not that same piece of junk everyone scorned. The creator of UT has already stated his distaste for OpenGL. When DirectX8 becomes the better API (which it undoubtedly will, if it already hasn't) then not even Carmack will be able to save OpenGL. Those who still doubt the pluasability of Direct3D, take note. Direct3D 8 is vastly superior to D3D 3. Each release keeps getting much better. Given the fact that D3D is improving faster than OpenGL, simple math will tell you that eventually it will overtake OpenGL (if it already hasn't, and a lot of people WILL tell you that D3D 8 is already there.)
Of course, there is one ridicoulously simple way to resolve this problem. I say that the ARB get's off it's collective ass and works on OpenGL. Dump extensions, (or at least speed up the pace of ARB extensions, which is probably the better short-term solution) improve the API, and market it. Right now, OpenGL still enjoys an air of superiority. Making it competitive with D3D (both in power and growth) will cement it as THE standard 3D API. The sucess of OpenGL has greater ramifications that just 3D. If OpenGL ever falls from favor, alternative platforms are doomed. Games stop being written for Linux and BeOS, and everyone goes back to using Windows. MS has the advantage at the moment. The success or failure of D3D isn't terribly critical to it's platform, because they support OpenGL too. However, alternative platforms have a problem. There is no huge installed base of OpenGL-only machines to keep people on the platform. If D3D becomes that much more feasible, then developers (aside from a few like Carmack) won't pay much of a second thought to developing for D3D and making their games Windows-only again. They'll only lose negligibe sales, and after the Linux hype is over (face it, that's the only reason games are ported at the moment, hype, not potential for profit) then not developing for Linux really won't be a big deal. If the ARB acts swiftly, all this can be prevented. OpenGL can soldifiy its place as the standard, Linux can continue its erosion of Windows's market share, and people like me can keep developing for OpenGL (on BeOS of course!) without getting the felling that we're using inferior technology.
Whoa, sombody is in to consipracy theories. It seems that you don't realize that online polls are extremely hackable. If you read over some of the BeOS NewLetters, they'll tell you a story of how they rigged the Yahoo OS poll. First, they scripted Netpositive to repeatedly go to the voting URL and vote for BeOS. Then, they realized that they could get votes just be reloadeding the after-vote page, so they did. Eventually, the had several Linux machines (because Lynx only runs on Linux) running Lynx and a script to repeatedly vote for BeOS. When the manager thought they should find a better use for their time, the resorted themselves to continually voting for N64. As I remember, it, due to their efforts (and the chain effect that it caused) N64 came away with 28% of the votes.
True. Sorry 'bout that. The magazine was Boot, Atiq Riza denied the 25% rumor. I must have remembered it backwards (the issue is two years old). However, the yeilds WERE very low at that time.
www.freebsd.org/ports
Problem: Why the f*ck is there a book about a PACKAGE MANAGEMENT SYSTEM! A package manager should be akin to a boot-loader in simplicity. There shouldn't be more than a page of documentation on the thing.
What happens when you uninstall it?
However, Microsoft doesn't make the YOU reformat THEIR documentation. If it did, it would catch hell from the press.
Oh, say the recall of the 1.13 GHz P3? It couldn't pass the Linux kernel compile test for all its worth.
It also required a special BIOS to load up special microcode that it needed to be even remotely
stable. Note that it was quickly recalled for a re-tape and re-mask.
>>>>>>>>
How about the fact that AMD's yeild during the K6 eras was around 25%? All chip companies occasionally have yeild problems. It's not necessaryily demonstrative of the quality of future chips. And unless you got burned by the 1.13GHz recall, then you've got no problems. I don't hear to many people complaining about the stability of the 900-1000MHz PIIIs.
MMX speed up 3D? I don't remember anyone marketing it as that, at best, it sped up multimedia,
such as audio and some video functions, and codecs that used floating point math weren't widely
used either. MMX was only integer when I checked the instruction set. IIRC, Floating point 3D
became used more widely when the Pentium came out, as well as the fact that the 486DX's had them
too, not.
>>>>>>>>>>
MMX was designed to speed up multimedia, but mainly to compete with the 3D cards that were coming out. If you look at MMX, it actually does help for the rendering part of the pipeline. That's exactly why it is useless, because 3D cards these days handle that part of the pipeline. And floating point 3D was not at all common until the PentiumMMX and the first wave of 3D cards. Quake, DukeNukem3D, Doom, Wolfenstien, they all used fixed-point math. If you read any of the game programming docs from the era, you'll notice that it wasn't until into the PII's release that they stopped teaching how to do fixed point math.
IIRC, Alpha didn't have SIMD instructions per se, but it did have most of the functions that MMX
had, right from the start, circa 1991, due to having extensive byte manipulation methods and having
64 bit registers. I don't recall seeing SIMD add, subtract or multiply functions in the instruction set
until MVI was introduced, I have never used it. That mostly only added add, subract and multiply,
min, max as well as a couple more byte shuffling instructions.
>>>>>>
However, MVI does exist, and it is designed to allow the Alpha to perform better in multimedia software. (According to Digital's press release.) The point is that MMX wasn't a dumb idea. Every other chip comany is implementing similar instructions.
IIRC, Intel also had a hard time meeting demands for nearly entire quarters - a reason that Gateway
and such lowered their resistance to AMD chips. AMD is definitely giving them a run for the money,
and I will admit that neither company is perfect, and different chips are usually better at different
things.
>>>>>
Which quarters? Remember, AMD had a hard time meeting demands for more than a year during K6 era.
Your chips are already 64 bits in all the places you need them. The bus is 64 bits, FP is 80 bits, and SSE is 128 bits. Almost no-one needs 64bit integer units, and unless you have more than 4GB of RAM, you don't need 64bit memory addressing either. Maybe your talking about getting a RISC-type machine as opposed to 64 bit one? Remeber, even the G4 is a 32bit machine.
The fact that there was almost no performance increase from a 700MHz to 850MHz Athlon due to the slower cache is not wrong?
So AMD's total screwup of the K5 and original K6, it's it's mess-ups with the 2/5 clocked cached on the previous Athlons didn't make you lose trust in THAT company? Seriously though, people who base their opinions of a company on one or two debacles are stupid. Wait for the P4 to come out. See how it reviews. Try one out. Ask your friends how they like theirs. Compare it with an Athlon. Buy whichever you like best.
I'm running a 200watt lightbulb off my standard American socket. Seriously though, the only thing this is going to require is a 400watt power supply.
Actually, it's a balance of three things. First, it's market share. Which chip has the most units shipped. MMX had this, 3DNow! didn't. Second, it's marketing power. Intel has this, AMD doesn't. Third, it's technical feasability. SSE had this, MMX didn't. If any one of the three things is severly lacking (for example, MMX had market share, and it had volume, but was bad technically) then the standard won't succeed.