FOSS developers, on the other hand, generally want to use the program they're writing (and don't want its performance to suffer). Also, they're open to the possibility that their niche has a boundary past which they shouldn't grow. There is generally less financial pressure to add new features than there is general pressure to keep the program working.
Although let's be realisic here: performance is only going to suffer in any kind of remotely detectable way as the result of either (1) very large and architectural choices, such as how image caching is handled, or (2) really stupid implementation decisions, like using alway using null terminated strings instead of counted strings when processing huge amounts of text (which can easily result in N^2 algorithms). I don't like featuritis as much as the next guy, but most talk about "bloat" is so much hot air. It's not like adding a handful of new features to a pulldown menu all of a sudden makes a program run globally slower. You could even do dumb things like checking for 100 different option flags all over the place and it wouldn't be perceptible to the user. We're talking nanoseconds here.
1) It's much easier to write a C compiler than a Pascal compiler, therefore the (early) availability of the C language on new platforms became a near certainty.
Not true. Pascal is generally easier to write a compiler for than C. Now you might be focusing on the optimization side of things, and in that case you'd be right. A naive compiler typically generates much better code for C-style pointer math than for arrays, and in Pascal you use the latter.
I think the reason Delphi hasn't become mainstream is the same reason many other excellent products haven't. Microsoft cloned it with VB and kept just close enough behind that it was acceptable to choose the un-FUD'd development environment.
Incorrect. Visual Basic was first, originally released in 1991. Delphi came ~3 years later. Of course Delphi was based on Borland's earlier Pascal products, but the GUI-building part of it was new with Delphi (unless you are counting Borland's text-only TurboVision stuff).
I like and use Firefox. But to be perfectly honest, it isn't the huge leap over IE that people want it to be. The achievement has been in getting something to run as well as IE, which is monstrously difficult in itself (one of the very first times an open source group has equalled commercial software in terms of user experience).
The primary benefits of Firefox are:
1. Security. You don't get spyware and such. You can also get the same result if you disable ActiveX controls and other features in IE, but most people don't do this. If Microsoft changed the defaults--which they won't because many sites depend on them--then IE would be on part with FF.
2. Tabbed browsing. This is a fairly small interface feature, though a very useful one. If Microsoft added it to IE--and they undoubtedly will, because it's easy to do--then there goes the biggest visible difference.
I realize that FF has other nice features (and I fully agree with people who cite them, because, again, I like and use FF), but those are the biggies. And the big negative feature is simply this: Sites that rely on ActiveX controls don't work under FF. Yes, I know, security, blah, blah, blah, but most people only see the "not working" part.
Maybe you should tell software publishers (e.g. Electronic Arts with "The Sims 2") it would be a good idea to not require the user to be running as admin.
Note that this is also true of open source. For example, the popular vim text editor. It installs to "c:\program files\vim", and writes data to that directory. This only works under an admin account.
The point is a 1GHz P4 would be slower than a 1GHz Athlon or P3. Yes, MHz is normally a good way to test processors of the same family, but not much else
And since the majority of consumer PCs, especially notebooks and anything from Dell, are running P4s, then, yes, MHz is a good indicator of performance in that case.
True, but you've gotta admit that the 3.2 GHz P4 benchmarked better than the 3.0 GHz P4 which benchmarked better than the 2.8 GHz P4. In fact, the general rule has has held up, except for transitions between processor generations. So even though MHz != performance, there was every reason to believe that Intel's 4 GHz P4 was going to benchmark better than the 3.6 GHz model.
This isn't the realization that MHz != performance on Intel's part nearly so much as it being them unable to continue to pump up the clock rate in a free manner.
First major commercial product to go OSS?
on
Netscape Turns 10
·
· Score: 1
This isn't true, or at least it depends how you look at it. Netscape had already lost relevance when they decided to open source the browser. It was a last ditch move. So it isn't quite the same as a huge, very relevant application like Flash or Photoshop going open source. And with that in mind, realize that the source code to major commercial products had been made available prior to this point, though purists will argue that the licensing terms aren't as purse as true OSS.
The source code to the hugely popular Wolfenstein 3D was released earlier than Netscape, for example. Going back further, you could get a printed code listing of the Atari 8-bit computer operating system from Atari for about the price of a book. For the same computer you could also buy a $12 book containing the *annotated* source code to Atari DOS. Both the Atari OS and Atari DOS were major commercial products at the time.
Memory moves are more efficient in 64-bit mode. Memory bandwidth in the Opteron/Athlon64 is much better than with Intel. This is even without the new register banks that come with these processors.
All Pentium processors have had 64-bit buses from the get-go. No joke. Read the specs.
Mozilla's tabbed browsing has completely changed how I research on the internet.
Right, but that's not the original poster's point. His point is that tabbed browsing may be a big feature for the end user, but it's a pretty small feature from the developer's point of view. The IE team Microsoft could *easily* add tabbed browsing without breaking a sweat. And most likely they already have done so internally.
Personally, I think this is what's funny about the IE/Firefox fighting. Security aside (and that's a big issue, so don't think I'm downplaying it), FF's improvement over IE are fairly small things. Now it was a huge job for the FF/Mozilla team to write a browser from scratch, yes, but now we end up with FF and IE having 90% of the same functionality, and it's only 10% used for differentiation. That's not enough reason for Microsoft to lose the "war" (again, security aside).
2 words : Doom 3 more words : Doom , then quake made the public update. I have no doubt Doom 3 will also influence hardware obsolescence.
Doom 3 runs perfectly on a 3GHz PC with 512MB and a good video card. *Perfectly*. This is exactly the setup I've been using, and the game is smooth as silk. Please note that the "ultra" quality setting doesn't count, because it trades an impercptible increase in video quality for a *massive* increase in bandwidth (it doesn't use lossy compression on certain types of multi-pass textures, like normal maps, so they get *huge*). Personally, I can't tell the difference between the the top three quality settings when I'm playing the game. I can only tell if I walk around pausing the game, specifically looking for artifacts (and even then I have to really put some effort into it).
Also, 1GB is chump change even in the land of 32 bit computing. 4GB is the max, whether MS can support it or not. 64 bit processing is important for things other than maximum memory access. Photo/sound processing comes to mind, not to mention video editing. That's just for starters.
You realize, of course, that the x86 line of processors has *always* supported 64-bit floating point operations (in reality, all operations are 80-bits internally). This goes all the way back to the original 8087 coporocessors. And there's always been a 64-bit bus on Pentiums, even the very first model. So what 64-bit operations are you wanting? Pure 64-bit integer math?
The i86 architecture is dying and Intel could not release decent 64 bit proc at time
But in reality, only the smallest fraction of the market is looking for 64-bit processors. Consider that Dell still sells 256MB PCs, PCs with 1GB in them are still the vast minority, and PCs with more than 1GB are rare indeed. (I know, I know, certain people in certain fields will chime in and talk about how 2GB is a requirement, but they're still in the minority.)
Among a certain crowd, Linux is viewed at the savior of computing--a young, hip operating system for the new century. But at the same time, there have been definite twinges of bitterness from a more old-school crowd, including people like Brian Kernighan, Jaron Lanier, and possibly even you. This bitterness appears to stem from the horror of a 25 year old operating system returning to the forefront of computing (for anyone vehemently disagreeing, consider if clones of VMS or OS/360 were suddenly all the rage). Who is right? What's your take?
Most people graduating with computer science degrees are only familiar with Windows and a handful of UNIX-variants: Linux, BSD, OS X. Is it good that stable technology is becoming the standard, thus allowing developers to focus their attentions elsewhere, or was this tremendous reduction in variety premature?
The operative word being "my"; static type checking becomes important when developing large systems over a long time and/or with many developers.
And "my" includes keeping an eye on large projects written using dynamically typed languages. Consider Ericsson's massive systems written in Erlang, for example. And there are plenty of good examples of large systems written in Python and Lisp, though note that "large" isn't in the same category as Ericsson's work (where "large" means 1,000,000+ lines of code).
Languages like Python have other problems for the development of large systems, like the lack of static type checking.
This is a debatable point. On the one hand, yes, it is dynamically typed. On the other hand, having easy access to an interpreter and zero compilation times leads to interactive testing and a more incremental approach to building large applications. In my experience, the latter far outweighs the former (as long as raw performance isn't the issue).
Very little. Even things like compressing video aren't so bad any more, as long as you're not compressing giant movies. And you can write code in Python or Lisp or your language of choice and have it run light lightning.
What do you guys think will be the next revolution in the CPU (or GPU, for that matter) market?
Processors that are less general purpose. GPUs are getting amazing boosts by being very specialized. Even shaders have narrow instruction sets. But a desktop CPU is designed to "run C," which is a much broader task. People building custom FPGA-based chips have proven that they can outperform high-end processors while only running at a fraction of the clockspeed. I fully expect that we're going to start to see processors--possibly even from hobbyists--optimized for running Python or other high-level languages, processors with built-in support for type tag checks and garbage collection (hmmm...sounds a bit like a Lisp machine, doesn't it?).
I should also mention that there has been activity outside of the Intel and AMD world that most people are familiar with. Remember, there are other processor families out there. And for an extreme example, there are the crazy "minimal instruction set" Forth chips from Chuck Moore.
Linus Torvalds makes a convenient representational symbol for the Linux community (it's named after him, after all), but is he really an Agenda Setter?
And, truthfully, Linux is the architect of the Linux *kernel*, which is stable and reliable and all of that, but it's a very small part of the Linux user experience. Actually, it's an insignificant part of the Linux user experience. If the Linux kernel were replaced with, say, BSD, then what impact would that have on someone who spends all of his time in the KDE desktop? This is not to belittle Linus's achievement, but at some point who matters more: the guy who builds guitars or the people who use those guitars to make amazing music? It's not like people say "Oh, my favorite band XXX is so completely enabled by the man who invented the electric guitar."
A couple of big issues are being missed in the price point discussion.
First, there are essentially no games out there that tax a high end card. Even games like Doom 3 run light lightning with a 128MB Radeon 9800. The high and ultra quality settings scraping for improvements, like not compressing normal and specular maps, things that buy you almost nothing in exchange for massive bandwidth requirements. So all of these people clamoring for X800s and all that...there's no need, not yet.
Second, a minority of PC owners run 3D games or otherwise need 3D acceleration. Partially this is because of compatibility and driver issues--and how those issues don't exist on consoles (cue the guy who always brings up RTS games as a counterargument)--but it's also partially because it's hard for the average person to know which games will work. DirectX 9? Pixel Shader 2.0? Video memory? Most people don't know anything about this. They buy a game, it doesn't work, they can't return it, and then they buy an Xbox for less than the price of a video card.
Third, the fragmentation and wide variations in the PC market result in all but a handful of game developers shooting for the high-end. Heck, over half of all PCs sold are notebooks. Is the 15% of the *gamer* market that owns X800s a viable target? Wouldn't it be better to tone things down and run on a wider variety of cards? Sure, you can write a game to scale based on the hardware it is running on, but this is expensive and time consuming.
In a lot of ways, the whole PC video card market is thriving on a sizable group of people--though still a minority--who upgrade obsessively.
An architecture switch breaking x86 ISA compatibility (i.e. emulation is noticeably slower than the original item) would put it on a level playing field with other 64-bit workstation/server-class chips, yet they never seemed to offer either world-beating design improvements or substantial price benefits, or appear as though they would in the future.
Intel decided to break with the past and start fresh, in hopes that they could make a large leap forward. That's a good goal. But what actually happened was a couple of things:
1. Their experiment failed, in that they didn't get the monstrous across-the-board benefits they expected.
2. They started this back in the days of the Pentium, when it looked like the x86 CPU architecture and instruction set were the big problems. The Itanium design team didn't forsee the crazy lengths that would be taken--by both Intel and AMD--in order to speed up the crappy x86 architecture.
Honestly, you can't fault Intel for trying. Where did chips like the ARM and MIPS come from (two of the most popular non-desktop processors)? From designing a new architecture. That's the same kind of thinking that resulted in the amazing GPUs from ATI and nVidia.
As a footnote, it's somewhat sad to see radical advances in CPUs come to a halt. I'd love to see someone set the industry on its ear.
Do you actually budget your computer in that way? Dear god man, turn off that computer! It's using the same electricity as TWO LIGHTBULBS! We could light the whole BATHROOM with those two 60w bulbs you're wasting!
Now that's not completely true. You're powering a CPU, three to seven fans, a video card, and a lot of RAM. And there is a cumulative effect here: if 50 million PC owners are using 100 watts more power than they need...that adds up.
If you want to be an environmental weenie, there are better justifiactions:
* The decrease in reliability that has come with PCs running so hot. If a fan goes out or a heatsink comes loose, that might be it for your CPU or video card.
* Latest and greatest processors have much lower yields, resulting in inefficient manufacturing (and chip manufacturing uses lots of toxic chemicals).
* RAM is messy to manufacture, too. Messier than most people want to admit.
* Heat problems result in more hardware in a typical PC: heatsinks, heat pipes, fans, bigger cases...stuff that ends up in the landfill.
Ok, there's lots of old code around, but we're talking about "multibillion liquid assets" Microsoft here: Can't they at least give their cash cow an overhaul with a modern compiler as a first step and have a team rewrite it in a proper language for full effect?
And honestly, this is what Microsoft is doing with.net and C#. They're moving as much of the OS and related applications to so-called "managed code" (which really means "no raw pointer access") as possible.
That's pretty low man. I've coded plenty before and I've never encountered an instance where I can't check to see if a buffer overflow has occurred. I can't help but feel that all of these exploits are just sloppy programming.
It isn't sloppy programming as much as the rules having changed. It used to be that you'd write an image decoder (or *any* program that reads an external file format), and you'd either (a) assume that the file structure is correct (because if it isn't, then it had to be created by a bad encodder), or (b) do some rudimentary checking to catch basic problems (such as a missing file id tag in the first bytes). And the worst that could usually happen was that your decoder would crash or become unstable. Really, this is how things have been, how coders have worked. Remember, it applies to every single type of external data read into a program: serialized data saved by library classes in C++, Python, etc., bytecode files read by a virtual machine or other interpreter, help file indices, intermediate object files...everything.
Moreso, just because you don't have buffer overruns doesn't mean you're in the clear. You have to check for tremendous files, too. What if someone passes you an image file that's correct and compressed, but decompresses into a 100,000 by 100,000 32-bit image? Even if you had the memory to decode a large file, the resources it takes up makes it essentiallly a denial of service attack.
Slashdot Mirror
FOSS developers, on the other hand, generally want to use the program they're writing (and don't want its performance to suffer). Also, they're open to the possibility that their niche has a boundary past which they shouldn't grow. There is generally less financial pressure to add new features than there is general pressure to keep the program working.
Although let's be realisic here: performance is only going to suffer in any kind of remotely detectable way as the result of either (1) very large and architectural choices, such as how image caching is handled, or (2) really stupid implementation decisions, like using alway using null terminated strings instead of counted strings when processing huge amounts of text (which can easily result in N^2 algorithms). I don't like featuritis as much as the next guy, but most talk about "bloat" is so much hot air. It's not like adding a handful of new features to a pulldown menu all of a sudden makes a program run globally slower. You could even do dumb things like checking for 100 different option flags all over the place and it wouldn't be perceptible to the user. We're talking nanoseconds here.
1) It's much easier to write a C compiler than a Pascal compiler, therefore the (early) availability of the C language on new platforms became a near certainty.
Not true. Pascal is generally easier to write a compiler for than C. Now you might be focusing on the optimization side of things, and in that case you'd be right. A naive compiler typically generates much better code for C-style pointer math than for arrays, and in Pascal you use the latter.
I think the reason Delphi hasn't become mainstream is the same reason many other excellent products haven't. Microsoft cloned it with VB and kept just close enough behind that it was acceptable to choose the un-FUD'd development environment.
Incorrect. Visual Basic was first, originally released in 1991. Delphi came ~3 years later. Of course Delphi was based on Borland's earlier Pascal products, but the GUI-building part of it was new with Delphi (unless you are counting Borland's text-only TurboVision stuff).
I like and use Firefox. But to be perfectly honest, it isn't the huge leap over IE that people want it to be. The achievement has been in getting something to run as well as IE, which is monstrously difficult in itself (one of the very first times an open source group has equalled commercial software in terms of user experience).
The primary benefits of Firefox are:
1. Security. You don't get spyware and such. You can also get the same result if you disable ActiveX controls and other features in IE, but most people don't do this. If Microsoft changed the defaults--which they won't because many sites depend on them--then IE would be on part with FF.
2. Tabbed browsing. This is a fairly small interface feature, though a very useful one. If Microsoft added it to IE--and they undoubtedly will, because it's easy to do--then there goes the biggest visible difference.
I realize that FF has other nice features (and I fully agree with people who cite them, because, again, I like and use FF), but those are the biggies. And the big negative feature is simply this: Sites that rely on ActiveX controls don't work under FF. Yes, I know, security, blah, blah, blah, but most people only see the "not working" part.
Maybe you should tell software publishers (e.g. Electronic Arts with "The Sims 2") it would be a good idea to not require the user to be running as admin.
Note that this is also true of open source. For example, the popular vim text editor. It installs to "c:\program files\vim", and writes data to that directory. This only works under an admin account.
The point is a 1GHz P4 would be slower than a 1GHz Athlon or P3. Yes, MHz is normally a good way to test processors of the same family, but not much else
And since the majority of consumer PCs, especially notebooks and anything from Dell, are running P4s, then, yes, MHz is a good indicator of performance in that case.
Mhz do not always = performance!
True, but you've gotta admit that the 3.2 GHz P4 benchmarked better than the 3.0 GHz P4 which benchmarked better than the 2.8 GHz P4. In fact, the general rule has has held up, except for transitions between processor generations. So even though MHz != performance, there was every reason to believe that Intel's 4 GHz P4 was going to benchmark better than the 3.6 GHz model.
This isn't the realization that MHz != performance on Intel's part nearly so much as it being them unable to continue to pump up the clock rate in a free manner.
This isn't true, or at least it depends how you look at it. Netscape had already lost relevance when they decided to open source the browser. It was a last ditch move. So it isn't quite the same as a huge, very relevant application like Flash or Photoshop going open source. And with that in mind, realize that the source code to major commercial products had been made available prior to this point, though purists will argue that the licensing terms aren't as purse as true OSS.
The source code to the hugely popular Wolfenstein 3D was released earlier than Netscape, for example. Going back further, you could get a printed code listing of the Atari 8-bit computer operating system from Atari for about the price of a book. For the same computer you could also buy a $12 book containing the *annotated* source code to Atari DOS. Both the Atari OS and Atari DOS were major commercial products at the time.
I'm sure there are other examples.
First off, a hearty thank you! In The Beginning Was The Command Line was what initially got me to try Linux back in 1998 - I wanted a free tank! :o)
:)
But the article wasn't written until 1999
Memory moves are more efficient in 64-bit mode. Memory bandwidth in the Opteron/Athlon64 is much better than with Intel. This is even without the new register banks that come with these processors.
All Pentium processors have had 64-bit buses from the get-go. No joke. Read the specs.
Mozilla's tabbed browsing has completely changed how I research on the internet.
Right, but that's not the original poster's point. His point is that tabbed browsing may be a big feature for the end user, but it's a pretty small feature from the developer's point of view. The IE team Microsoft could *easily* add tabbed browsing without breaking a sweat. And most likely they already have done so internally.
Personally, I think this is what's funny about the IE/Firefox fighting. Security aside (and that's a big issue, so don't think I'm downplaying it), FF's improvement over IE are fairly small things. Now it was a huge job for the FF/Mozilla team to write a browser from scratch, yes, but now we end up with FF and IE having 90% of the same functionality, and it's only 10% used for differentiation. That's not enough reason for Microsoft to lose the "war" (again, security aside).
2 words : Doom 3
more words : Doom , then quake made the public update.
I have no doubt Doom 3 will also influence hardware obsolescence.
Doom 3 runs perfectly on a 3GHz PC with 512MB and a good video card. *Perfectly*. This is exactly the setup I've been using, and the game is smooth as silk. Please note that the "ultra" quality setting doesn't count, because it trades an impercptible increase in video quality for a *massive* increase in bandwidth (it doesn't use lossy compression on certain types of multi-pass textures, like normal maps, so they get *huge*). Personally, I can't tell the difference between the the top three quality settings when I'm playing the game. I can only tell if I walk around pausing the game, specifically looking for artifacts (and even then I have to really put some effort into it).
Also, 1GB is chump change even in the land of 32 bit computing. 4GB is the max, whether MS can support it or not. 64 bit processing is important for things other than maximum memory access. Photo/sound processing comes to mind, not to mention video editing. That's just for starters.
You realize, of course, that the x86 line of processors has *always* supported 64-bit floating point operations (in reality, all operations are 80-bits internally). This goes all the way back to the original 8087 coporocessors. And there's always been a 64-bit bus on Pentiums, even the very first model. So what 64-bit operations are you wanting? Pure 64-bit integer math?
The i86 architecture is dying and Intel could not release decent 64 bit proc at time
But in reality, only the smallest fraction of the market is looking for 64-bit processors. Consider that Dell still sells 256MB PCs, PCs with 1GB in them are still the vast minority, and PCs with more than 1GB are rare indeed. (I know, I know, certain people in certain fields will chime in and talk about how 2GB is a requirement, but they're still in the minority.)
Among a certain crowd, Linux is viewed at the savior of computing--a young, hip operating system for the new century. But at the same time, there have been definite twinges of bitterness from a more old-school crowd, including people like Brian Kernighan, Jaron Lanier, and possibly even you. This bitterness appears to stem from the horror of a 25 year old operating system returning to the forefront of computing (for anyone vehemently disagreeing, consider if clones of VMS or OS/360 were suddenly all the rage). Who is right? What's your take?
Most people graduating with computer science degrees are only familiar with Windows and a handful of UNIX-variants: Linux, BSD, OS X. Is it good that stable technology is becoming the standard, thus allowing developers to focus their attentions elsewhere, or was this tremendous reduction in variety premature?
The operative word being "my"; static type checking becomes important when developing large systems over a long time and/or with many developers.
And "my" includes keeping an eye on large projects written using dynamically typed languages. Consider Ericsson's massive systems written in Erlang, for example. And there are plenty of good examples of large systems written in Python and Lisp, though note that "large" isn't in the same category as Ericsson's work (where "large" means 1,000,000+ lines of code).
Languages like Python have other problems for the development of large systems, like the lack of static type checking.
This is a debatable point. On the one hand, yes, it is dynamically typed. On the other hand, having easy access to an interpreter and zero compilation times leads to interactive testing and a more incremental approach to building large applications. In my experience, the latter far outweighs the former (as long as raw performance isn't the issue).
What can't you do with a 2.4Ghz HT Intel CPU?
Very little. Even things like compressing video aren't so bad any more, as long as you're not compressing giant movies. And you can write code in Python or Lisp or your language of choice and have it run light lightning.
What do you guys think will be the next revolution in the CPU (or GPU, for that matter) market?
Processors that are less general purpose. GPUs are getting amazing boosts by being very specialized. Even shaders have narrow instruction sets. But a desktop CPU is designed to "run C," which is a much broader task. People building custom FPGA-based chips have proven that they can outperform high-end processors while only running at a fraction of the clockspeed. I fully expect that we're going to start to see processors--possibly even from hobbyists--optimized for running Python or other high-level languages, processors with built-in support for type tag checks and garbage collection (hmmm...sounds a bit like a Lisp machine, doesn't it?).
I should also mention that there has been activity outside of the Intel and AMD world that most people are familiar with. Remember, there are other processor families out there. And for an extreme example, there are the crazy "minimal instruction set" Forth chips from Chuck Moore.
Linus Torvalds makes a convenient representational symbol for the Linux community (it's named after him, after all), but is he really an Agenda Setter?
And, truthfully, Linux is the architect of the Linux *kernel*, which is stable and reliable and all of that, but it's a very small part of the Linux user experience. Actually, it's an insignificant part of the Linux user experience. If the Linux kernel were replaced with, say, BSD, then what impact would that have on someone who spends all of his time in the KDE desktop? This is not to belittle Linus's achievement, but at some point who matters more: the guy who builds guitars or the people who use those guitars to make amazing music? It's not like people say "Oh, my favorite band XXX is so completely enabled by the man who invented the electric guitar."
A couple of big issues are being missed in the price point discussion.
First, there are essentially no games out there that tax a high end card. Even games like Doom 3 run light lightning with a 128MB Radeon 9800. The high and ultra quality settings scraping for improvements, like not compressing normal and specular maps, things that buy you almost nothing in exchange for massive bandwidth requirements. So all of these people clamoring for X800s and all that...there's no need, not yet.
Second, a minority of PC owners run 3D games or otherwise need 3D acceleration. Partially this is because of compatibility and driver issues--and how those issues don't exist on consoles (cue the guy who always brings up RTS games as a counterargument)--but it's also partially because it's hard for the average person to know which games will work. DirectX 9? Pixel Shader 2.0? Video memory? Most people don't know anything about this. They buy a game, it doesn't work, they can't return it, and then they buy an Xbox for less than the price of a video card.
Third, the fragmentation and wide variations in the PC market result in all but a handful of game developers shooting for the high-end. Heck, over half of all PCs sold are notebooks. Is the 15% of the *gamer* market that owns X800s a viable target? Wouldn't it be better to tone things down and run on a wider variety of cards? Sure, you can write a game to scale based on the hardware it is running on, but this is expensive and time consuming.
In a lot of ways, the whole PC video card market is thriving on a sizable group of people--though still a minority--who upgrade obsessively.
What was Intel thinking?
An architecture switch breaking x86 ISA compatibility (i.e. emulation is noticeably slower than the original item) would put it on a level playing field with other 64-bit workstation/server-class chips, yet they never seemed to offer either world-beating design improvements or substantial price benefits, or appear as though they would in the future.
Intel decided to break with the past and start fresh, in hopes that they could make a large leap forward. That's a good goal. But what actually happened was a couple of things:
1. Their experiment failed, in that they didn't get the monstrous across-the-board benefits they expected.
2. They started this back in the days of the Pentium, when it looked like the x86 CPU architecture and instruction set were the big problems. The Itanium design team didn't forsee the crazy lengths that would be taken--by both Intel and AMD--in order to speed up the crappy x86 architecture.
Honestly, you can't fault Intel for trying. Where did chips like the ARM and MIPS come from (two of the most popular non-desktop processors)? From designing a new architecture. That's the same kind of thinking that resulted in the amazing GPUs from ATI and nVidia.
As a footnote, it's somewhat sad to see radical advances in CPUs come to a halt. I'd love to see someone set the industry on its ear.
Do you actually budget your computer in that way? Dear god man, turn off that computer! It's using the same electricity as TWO LIGHTBULBS! We could light the whole BATHROOM with those two 60w bulbs you're wasting!
Now that's not completely true. You're powering a CPU, three to seven fans, a video card, and a lot of RAM. And there is a cumulative effect here: if 50 million PC owners are using 100 watts more power than they need...that adds up.
If you want to be an environmental weenie, there are better justifiactions:
* The decrease in reliability that has come with PCs running so hot. If a fan goes out or a heatsink comes loose, that might be it for your CPU or video card.
* Latest and greatest processors have much lower yields, resulting in inefficient manufacturing (and chip manufacturing uses lots of toxic chemicals).
* RAM is messy to manufacture, too. Messier than most people want to admit.
* Heat problems result in more hardware in a typical PC: heatsinks, heat pipes, fans, bigger cases...stuff that ends up in the landfill.
Ok, there's lots of old code around, but we're talking about "multibillion liquid assets" Microsoft here: Can't they at least give their cash cow an overhaul with a modern compiler as a first step and have a team rewrite it in a proper language for full effect?
.net and C#. They're moving as much of the OS and related applications to so-called "managed code" (which really means "no raw pointer access") as possible.
And honestly, this is what Microsoft is doing with
That's pretty low man. I've coded plenty before and I've never encountered an instance where I can't check to see if a buffer overflow has occurred. I can't help but feel that all of these exploits are just sloppy programming.
It isn't sloppy programming as much as the rules having changed. It used to be that you'd write an image decoder (or *any* program that reads an external file format), and you'd either (a) assume that the file structure is correct (because if it isn't, then it had to be created by a bad encodder), or (b) do some rudimentary checking to catch basic problems (such as a missing file id tag in the first bytes). And the worst that could usually happen was that your decoder would crash or become unstable. Really, this is how things have been, how coders have worked. Remember, it applies to every single type of external data read into a program: serialized data saved by library classes in C++, Python, etc., bytecode files read by a virtual machine or other interpreter, help file indices, intermediate object files...everything.
Moreso, just because you don't have buffer overruns doesn't mean you're in the clear. You have to check for tremendous files, too. What if someone passes you an image file that's correct and compressed, but decompresses into a 100,000 by 100,000 32-bit image? Even if you had the memory to decode a large file, the resources it takes up makes it essentiallly a denial of service attack.
These are tough issues.