Ubuntu is unlicensed, eh? And everything that's included in it, eh?
Sure. I've used an unlicensed copy of Ubuntu many times. It says right there in the GPL: If you don't want to accept the license, you don't have to in order to use the software. So I didn't.:-P
So I guess I can change some #IFDEF s, release a "new" operating system, and get rich, eh?
You could if you agreed to the GPL. If you didn't, then I imagine that the various Linux authors would take issue with your attempt to ignore copyright law.
Free software is not "public domain," which is what unlicensed/uncopywritten means.
No, unlicensed means unlicensed and public domain means public domain. Just because public domain software is unlicensed doesn't make all unlicensed software public domain. (i.e. A car stays in a garage. Is everything in a garage a car?) Unlicensed means exactly that: You didn't agree to a license to obtain the software. I don't agree to a license to obtain a book, either, but copyright law is still in full effect.
The SPARTAN 3 is a hobbyist FPGA. A Virtex 4 would've been nicer
I'm actually impressed! Back when they started this project, I made a suggestion here on Slashdot that it would be more accessible if they used a Spartan 3. A member of the project told me they couldn't use anything smaller than the latest Virtex because they needed the size and performance. Their reasons were good at the time, so I'm really impressed that they made the effort to fit it in such a small FPGA. Great work, guys! =)
A company spokesperson is also promising fixes for the multitude of problems in "Star Wars Galaxies" that have plagued the MMORPG for the last five years.
"This time we have based it on REAL battles that ACTUALLY HAPPENED in a long time ago in a galaxy far, far, away." said the spokeman. He then went on to show us some of the realistic features like:
- Real time weapon change - Giant space crabs - The ability to "hit the weak point" for what the spokesperson termed: "Massive Damage"
When Sony's executive staff was queried on the supposed realism of these changes, Kaz Harai went on record as asking, "Have you seen Ridge Racer yet? "RIIIIIIIDDDDGGGGEEEE RACERRRRRRRRR!!!"
"Reprove not a scorner, lest he hate thee: rebuke a wise man, and he will love thee." -Proverbs 9:8
My aim is to find myself in the latter category, not the former.:-)
And I'm not worried about you being AC. Truth is truth, even from an anonymous individual. (And trust me, I've done enough experiments where I posted ONLY as AC for a period, just to prove that my high scores were coming from the content of my posts and not the username I carry.)
Actually, that is a completely fair point. I tend to get easily frustrated when it seems like responders are failing to pay attention to the context of what is being discussed. My apologies if I got a little hot under the collar. And thanks for keeping me honest.:-)
watt hours are a measure of total energy use, not power use. It's obtained my multiplying watts by time.
"Power use" is obviously the colloquial term for "using" the "power" that the power company supplies you. While not intentional on my part, I slipped into using the term because it matches the use of kWh. (Which is really only used in consumer "power usage".)
It's very simple maths and it's the same damned way the power company bills you. A kWh is just a measure of total energy in Joules consumed.
That's kinda why I'm getting annoyed. A kilowatt/hour is about as standard of a measurement as you can get. I mean, it's taught in grade school fer' crying out loud! I generally expect people (especially those visiting a geek site;-)) to be familiar with the term.
Of course, I computed Joules and then converted into kWh to arrive at the final value. So maybe next time I'll just list the figures in MJ of Energy and let the slow ones be damned.:-P
45W isn't correct. (Or if it is, your Wii will be melting soon!) The Wii never crosses 20 Watts in power usage. The primary reason for this is that the chips are basically updated GameCube chips, but made with a 90nm process rather than the previous 180nm process. This makes the previously ~39 watt hardware a clean and cool ~17 watt architecture.
The Wii probably doesn't use more power in standby mode than in gameplay mode.
It doesn't. The Wii uses 17.8 watts in gameplay and 9.6 watts in standby. However, it stays in 17.8 watt mode for 1040 hours out of the year and standby mode for a whopping 7696 hours out of the year. Ergo, the Wii uses 18.51 kilowatt/hours to play games in a year and 73.88 kilowatt/hours to standby in a year.
The reason why the standby figure is larger is because the Wii is in Standby mode longer than in gameplay mode. Of course, you'd know that if you read the last two posts I made.
Now if I have to explain this again, someone is going to get called a rather nasty name.:-P
Check again yourself. The smaller number is based on 20 hours/week of gameplay for 52 weeks. That's 1040 hours. The larger number is based on the remaining standby time for a year. That's 7696 hours.
The difference between the two numbers on a per-hour basis is about 6 watts. To cop a line from the Atari Jaguar, "DO THE MATH!":-P
That's true but then they go and spoil it by requiring the Wii to be left on standby if you want the mail & Mii moving features to work.
Let's run a few figures here.
* Assume 20 hours a week of gameplay * Assume that all consoles remain plugged into the wall for a year * Assume that WiiConnect24 is active on the Wii * Assume that the 360 and PS3 are powered down when not playing games. (A stretch due to their secondary functions, but we'll go with it.) * I will compute using the average figures given in this article: http://www.hardcoreware.net/reviews/review-356-1.htm * (20 * 52) = 1040 hours of playtime per year * (52 * 7 * 24) - 1040 = 7696 hours of standby time per year
Nintendo didn't do anything wrong. This is the same bullshit that Greenpeace pulled with Apple. Because Apple didn't have a "environmental policy" listed on their website (Greenpeace didn't even ask!), Greenpeace automatically dinged them as the worst.
As it turned out, Apple was the best of the bunch. They were already using the safest materials, used the lowest power, and generally were superior to the competition in the area of environmental consciousness. But since they didn't shout it from the mountaintops, Greenpeace decided to get some free press out of them. Assholes.
According to TFA, they are now doing the same thing to Nintendo:
Nintendo came in for the harshest criticism, Greenpeace stating the firm "doesn't have any environmental policies."
Oh noes! No policy! I'll bet they even went as far as to check Nintendo's website!
(shock! horror! awe!)
Nevermind that Nintendo just produced the most energy efficient game console in the history of game consoles. Only handhelds use less power than the Wii.
As far as I'm concerned, Greenpeace has lost all credibility. They can take their little crusade and shove it for all I care. Progress may be slow when you're doing it on the level, but at least you keep the trust of the public. These publicity stunts only result in lower trust, which translates to lower credibility, which impacts their ability to be a force for change.
Not to mention all the folks who will no longer donate toward ANY of their efforts. (Hint)
I can believe that x86 compatibility would be a pretty big benefit for something like the eee pc - in that if you want to install OpenOffice, it's more user-friendly if you can just apt-get (or whatever) a binary package, compared to compiling from source.
Ever hear of Transmeta? They already tried that and failed. And in any case, Intel already provides 5.5 watt Core Solo chips to the market. How much more power efficient do you want? Taking the performance hit of ATOM just to lose a watt and a half doesn't seem like a very good trade-off. Even for a small PC like the Asus Eee.
Newer processes have always yielded faster, smaller, and cooler chips. Not anymore. 60nm didn't make chips use less power and 45nm doesn't help either.
60nm and 45nm DID yield smaller and cooler chips. (On the smaller side, take a look at the Core Duo silicon sometime. It's amazing how much smaller it is than the PIV chip!) There's just one catch with that: When you shrink the processes and make the chip smaller and cooler, you also have the option of using those gains for new features. e.g. If my power usage and silicon footprint cut in half, then I have the opportunity to add another core for the same power usage AND still get twice the yield from a silicon wafer as I got before! (Half-sized silicon chip == 1 quarter the space)
That's effectively what we've been seeing with microprocessors since they were invented. The moment that improvements in lithography shrink the die size, chip designers immediately start thinking about what they can do with all that extra space. So they start cramming in rather spacey features like FPUs, microcode engines, out of order engines, superscalar execution, SIMD cores, ever-larger L2 caches, 64bit support, so on and so forth. You'd be amazed how much chip designers cram into these processors. In some cases, the number of pins on the chip is actually becoming more of a limitation than the silicon area! (Each pin that's wired into the package significantly increases the cost to manufacture. It's bloody HARD to match a silicon wire of 45nm to a trace on the chip packaging.)
Um the charger only has to have higher voltage than the battery.
The voltage is the only concern when we're talking about a battery not in use. If the battery isn't being used, a few milliamps will happily charge the battery if the voltage is high enough. If the battery is in use (as it usually is when I plug my phone in) there had better well be more watts pouring in than out!
Nope. Just read the label on the charger. Output is 5V at 550 milliamps. 5V * 550mA = 2.75 watts. (I rounded up.) My old Nokia candybar phone had a 5V/300mA charger. Ergo, 1.5 watts.
On that note, I'm rather concerned by your statement. I'd hate to think about what 2.8 AMPS would do to my phone...
1) This CPU runs on **4 watts!** I'm not sure my cell phone can run on 4 watts in standby.
My Nokia charger was rated for 1.5 watts. My current Motorola Razr comes with a charger that's rated for ~2.8 watts. Obviously, the wattage of a charger has to be higher than the battery output in order to charge the phone.
Weird. Half the responders disagreed with him and you didn't notice?
RISC design was really, really attractive from an architectural standpoint. It simplified the hardware to such a great degree that it was completely worth the pain and suffering it put compiler writers through. With microcode, even stupid CISC architectures like x86 were able to run on a RISC CPU.
But here's the rub: It is always slower to use multiple instructions to complete a task that could be completed in a single instruction with dedicated silicon.
With that simple fact in mind, it didn't take long for CISC-style instructions to start reappearing in the silicon designs. Especially once the fab technologies improved enough to negate the speed advantages in early RISC chips. (e.g. Alpha seriously kicked ass back in the day.) Chip designers like Intel took note of what instructions were slowing things down and began adding them back into the silicon.
Thus the bar moved. Rather than trying to keep the silicon clean, the next arms race began over who could put fancier vector instructions into their CPUs. Thus began the war over SIMD instructions. (Which, honestly, not that many people cared about. They are cool instructions, though, and can be blazingly fast when used appropriately.)
An interesting trend you'll notice is that instructions take more or fewer instructions to execute between revisions of processors. (Especially with x86.) Part of this is definitely changes in the microcode and CPU design. But part of it is a re-evaluation of silicon usage. Some instructions which used to be fast thus become slow when they move to microcode, and some instructions that were slow become fast when they move to silicon.
RISC vs. CISC? What is this, the early 90's? There are no RISC chips anymore, except as product lines that were originally developed with the RISC methodology in mind. Similarly, true CISC doesn't exist either. Microcode has done wonders in turning complex instructions into a series of simpler instructions like one would find on a RISC processor.
The author's real point appears to be: x86 vs. Other Embedded Architectures. Without even looking at the article (which I did do), it's not hard to answer that one: There is no need for x86 code in a mobile platform. The hardware is going to be different than a PC, the interface is going to be different than a PC, and the usage of the device is going to be different than a PC. Providing x86 compatibility thus offers few, if any, real advantages over an ARM or other mobile chip.
If Intel's ATOM takes off, it will be on the merits of the processor and not on its x86 compatibility. Besides, x86 was a terrible architecture from the get-go. There's something mildly hilarious about the fact that it became the dominant instruction set in Desktop PCs across the world.
The problem with the MPC standard was that it wasn't very well executed. It was a success in that every magazine in existence talked about "if you have a multimedia PC you can do X!" CDROM Magazine was especially good at playing up the term.
The problem that came in was that consumers didn't understand the term very well due to the poor execution of the brand. Rather than recognizing that there were different levels of MPC, the assumption of the time was that MPC == CDROM+Sound Card+SVGA. Which wasn't too far from the truth as that's what MPC was created to promote. The problem was that they didn't future-proof the standard and thus it fell into disuse once all PCs had those features as standard.
I think this will be very cool for average joe who don't understand difference between 8400GS and 8800GT graphic cards.
I disagree. I didn't even finish reading the summary before I realized this wasn't going to work. TFA just confirmed my suspicion.
A few problems:
1. AMD will only certify AMD/ATI hardware. Which kind of makes this useless if you're an Intel/NVidia user.
2. Game Systems gain their stability due to LOOOOONG (4-5 years) release cycles. In PC terms, 4-5 years is an eternity.
3. AMD is going to butt heads with the PC Gaming Alliance they just helped form.
4. Given that PC Hardware is a moving target, how will AMD certify future machines? Will AMD GAME and GAME ULTRA also be moving targets? If so, will that not confuse Joe Gameplayer when AMD GAME system from 2008 fails to smoothly run AMD GAME software from 2010?
5. Epic and Id are the primary drivers behind the PC game market. Their engines are the keystone that holds the whole thing together. Thus it is their engines that make the market. Maybe I missed it, but I don't see AMD having their cooperation on setting future standards.
A much better system would be a versioned hardware spec that is maintained across the industry. e.g. PC-Spec 1 would certify GeFore 8400/Radeon HD 2400 and PC-Spec 2 would certify GeForce 8800/Radeon HD 2900. A new revision of the spec would be created for each sliding window. Each spec would consist of a certain performance plateau combined with a given feature set. (e.g. Support for GL Programmable Shaders.) The latest 3D engines from companies like Id and Epic would target the latest, upcoming spec. (A spec which those companies would have helped define when they were in early development.)
From a consumer perspective, this makes my life easier. Because instead of looking if RAM, Graphics Card, and CPU match, I can simply look for the spec number. If my computer supports a higher spec number than what's on the box (e.g. I have a PC-Spec 5 computer and this game requires PC-Spec 4) then I know I can play the game.
It's not quite as simple as consoles, but such is the way the PC world works.
Oh, and I forgot a particularly nasty option: Compressing or encrypting the code. e.g. A piece of code can use OS services to compress data on disk. This would make it look like any other program with compressed segments. Another option is a variation of One Time Pad based on system information like hostname or MAC address. Again, it's hard to identify the stub as a definite virus header.
Even worse is that most viruses today are part of a Botnet that has Command and Control capabilities. So the hiding ability of the virus can be updated on a regular basis. Version 1 selected between compression and OTP? No problem! Version 2 will add reordering of code segments!
Self modifying code is self modifying code. If it changes its signature into a different permutation that contains the same logic (e.g. changing the registers loaded, moving memory locations, inserting no-ops that don't look like no-ops, allocating different stack size, using a different location on disk, etc.) then it becomes nearly invisible to automated tools. I'm sure the next revision of anti-viral software will aim for complex heuristics that attempt to negate this sort of hiding. Which will become the next major arms race between virus writers and anti-virus writers. (Just like spam vs. anti-spam.)
Of course, arms races are usually a bad thing. They waste resources yet deliver very little. We need to start thinking about building a new infrastructure that is not susceptible to such simplistic attacks. e.g. Managed languages, jailed environments, trust relationships for email servers, and other such steps to data security. Unfortunately, there is so much time and money invested in our current infrastructure that there's no chance the market would make such a change unless absolutely forced to do so. Thus we come full circle back to the GPP's point.
1. Take the hard drives out and stick them in a USB Shell. Voila, instant backup/portable storage solution!
2. Take the memory chips and sell them on ebay as upgrades.
3. Rip the screens out and use them to create a Head Mounted Display in your home Virtual Reality project. (Yay for 90's thinking!;-))
4. Unsolder the parts and use them for home hardware projects.
5. I'm running out of ideas. Maybe use the shell to stuff something geeky inside? Like a Commodore 64 Laptop?
6. Last but not least, cobble the best and/or compatible parts together to create one or two functional laptops. Load an OS in development (e.g. JNode) and use it for portable Operating System development. Alternatively, use it for an educational experience by building Linux from Scratch.
Slashdot Mirror
Sure. I've used an unlicensed copy of Ubuntu many times. It says right there in the GPL: If you don't want to accept the license, you don't have to in order to use the software. So I didn't.
You could if you agreed to the GPL. If you didn't, then I imagine that the various Linux authors would take issue with your attempt to ignore copyright law.
No, unlicensed means unlicensed and public domain means public domain. Just because public domain software is unlicensed doesn't make all unlicensed software public domain. (i.e. A car stays in a garage. Is everything in a garage a car?) Unlicensed means exactly that: You didn't agree to a license to obtain the software. I don't agree to a license to obtain a book, either, but copyright law is still in full effect.
"This time we have based it on REAL battles that ACTUALLY HAPPENED in a long time ago in a galaxy far, far, away." said the spokeman. He then went on to show us some of the realistic features like:
- Real time weapon change
- Giant space crabs
- The ability to "hit the weak point" for what the spokesperson termed: "Massive Damage"
When Sony's executive staff was queried on the supposed realism of these changes, Kaz Harai went on record as asking, "Have you seen Ridge Racer yet? "RIIIIIIIDDDDGGGGEEEE RACERRRRRRRRR!!!"
(Sorry, couldn't resist!
"Reprove not a scorner, lest he hate thee: rebuke a wise man, and he will love thee." -Proverbs 9:8
:-)
My aim is to find myself in the latter category, not the former.
And I'm not worried about you being AC. Truth is truth, even from an anonymous individual. (And trust me, I've done enough experiments where I posted ONLY as AC for a period, just to prove that my high scores were coming from the content of my posts and not the username I carry.)
Actually, that is a completely fair point. I tend to get easily frustrated when it seems like responders are failing to pay attention to the context of what is being discussed. My apologies if I got a little hot under the collar. And thanks for keeping me honest. :-)
Of course, I computed Joules and then converted into kWh to arrive at the final value. So maybe next time I'll just list the figures in MJ of Energy and let the slow ones be damned.
45W isn't correct. (Or if it is, your Wii will be melting soon!) The Wii never crosses 20 Watts in power usage. The primary reason for this is that the chips are basically updated GameCube chips, but made with a 90nm process rather than the previous 180nm process. This makes the previously ~39 watt hardware a clean and cool ~17 watt architecture.
:-)
More info here: http://www.hardcoreware.net/reviews/review-356-1.htm
It doesn't. The Wii uses 17.8 watts in gameplay and 9.6 watts in standby. However, it stays in 17.8 watt mode for 1040 hours out of the year and standby mode for a whopping 7696 hours out of the year. Ergo, the Wii uses 18.51 kilowatt/hours to play games in a year and 73.88 kilowatt/hours to standby in a year.
The reason why the standby figure is larger is because the Wii is in Standby mode longer than in gameplay mode. Of course, you'd know that if you read the last two posts I made.
Now if I have to explain this again, someone is going to get called a rather nasty name.
Check again yourself. The smaller number is based on 20 hours/week of gameplay for 52 weeks. That's 1040 hours. The larger number is based on the remaining standby time for a year. That's 7696 hours.
The difference between the two numbers on a per-hour basis is about 6 watts. To cop a line from the Atari Jaguar, "DO THE MATH!"
* Assume 20 hours a week of gameplay
* Assume that all consoles remain plugged into the wall for a year
* Assume that WiiConnect24 is active on the Wii
* Assume that the 360 and PS3 are powered down when not playing games. (A stretch due to their secondary functions, but we'll go with it.)
* I will compute using the average figures given in this article: http://www.hardcoreware.net/reviews/review-356-1.htm
* (20 * 52) = 1040 hours of playtime per year
* (52 * 7 * 24) - 1040 = 7696 hours of standby time per year
Gameplay Power Usage
Wii: 18.51 kWh
360: 192.5 kWh
PS3: 201.3 kWh
Standby Power Usage
Wii: 73.88 kWh
360: 19.24 kWh
PS3: 14.62 kWh
Total Power Usage
Wii: 92.39 kWh
360: 211.74 kWh
PS3: 215.92 kWh
Even with WiiConnect24 operating all the time, the Wii will still use less than half the power used by the 360 and PS3.
Q.E.D.
As it turned out, Apple was the best of the bunch. They were already using the safest materials, used the lowest power, and generally were superior to the competition in the area of environmental consciousness. But since they didn't shout it from the mountaintops, Greenpeace decided to get some free press out of them. Assholes.
According to TFA, they are now doing the same thing to Nintendo:Oh noes! No policy! I'll bet they even went as far as to check Nintendo's website!
(shock! horror! awe!)
Nevermind that Nintendo just produced the most energy efficient game console in the history of game consoles. Only handhelds use less power than the Wii.
As far as I'm concerned, Greenpeace has lost all credibility. They can take their little crusade and shove it for all I care. Progress may be slow when you're doing it on the level, but at least you keep the trust of the public. These publicity stunts only result in lower trust, which translates to lower credibility, which impacts their ability to be a force for change.
Not to mention all the folks who will no longer donate toward ANY of their efforts. (Hint)
Ever hear of Transmeta? They already tried that and failed. And in any case, Intel already provides 5.5 watt Core Solo chips to the market. How much more power efficient do you want? Taking the performance hit of ATOM just to lose a watt and a half doesn't seem like a very good trade-off. Even for a small PC like the Asus Eee.
That's effectively what we've been seeing with microprocessors since they were invented. The moment that improvements in lithography shrink the die size, chip designers immediately start thinking about what they can do with all that extra space. So they start cramming in rather spacey features like FPUs, microcode engines, out of order engines, superscalar execution, SIMD cores, ever-larger L2 caches, 64bit support, so on and so forth. You'd be amazed how much chip designers cram into these processors. In some cases, the number of pins on the chip is actually becoming more of a limitation than the silicon area! (Each pin that's wired into the package significantly increases the cost to manufacture. It's bloody HARD to match a silicon wire of 45nm to a trace on the chip packaging.)
You might find these images to be of interest:
A simple "map" of the Core Duo
X-Ray of the Core 2 Duo chip
Can you spot all four cores?
Nehalm, Intel's next architecture to replace the Core Duo line (This chip is designed with 32nm processes in mind.)
An abstract look at Nehalm design
Detailed map of Via's Isiah processor
Photos that really show off the incredibly small size of these chips.
The voltage is the only concern when we're talking about a battery not in use. If the battery isn't being used, a few milliamps will happily charge the battery if the voltage is high enough. If the battery is in use (as it usually is when I plug my phone in) there had better well be more watts pouring in than out!
Nope. Just read the label on the charger. Output is 5V at 550 milliamps. 5V * 550mA = 2.75 watts. (I rounded up.) My old Nokia candybar phone had a 5V/300mA charger. Ergo, 1.5 watts.
On that note, I'm rather concerned by your statement. I'd hate to think about what 2.8 AMPS would do to my phone...
My Nokia charger was rated for 1.5 watts. My current Motorola Razr comes with a charger that's rated for ~2.8 watts. Obviously, the wattage of a charger has to be higher than the battery output in order to charge the phone.
Make of it what you will.
Weird. Half the responders disagreed with him and you didn't notice?
:-)
RISC design was really, really attractive from an architectural standpoint. It simplified the hardware to such a great degree that it was completely worth the pain and suffering it put compiler writers through. With microcode, even stupid CISC architectures like x86 were able to run on a RISC CPU.
But here's the rub: It is always slower to use multiple instructions to complete a task that could be completed in a single instruction with dedicated silicon.
With that simple fact in mind, it didn't take long for CISC-style instructions to start reappearing in the silicon designs. Especially once the fab technologies improved enough to negate the speed advantages in early RISC chips. (e.g. Alpha seriously kicked ass back in the day.) Chip designers like Intel took note of what instructions were slowing things down and began adding them back into the silicon.
Thus the bar moved. Rather than trying to keep the silicon clean, the next arms race began over who could put fancier vector instructions into their CPUs. Thus began the war over SIMD instructions. (Which, honestly, not that many people cared about. They are cool instructions, though, and can be blazingly fast when used appropriately.)
An interesting trend you'll notice is that instructions take more or fewer instructions to execute between revisions of processors. (Especially with x86.) Part of this is definitely changes in the microcode and CPU design. But part of it is a re-evaluation of silicon usage. Some instructions which used to be fast thus become slow when they move to microcode, and some instructions that were slow become fast when they move to silicon.
Rather interesting to watch in action.
RISC vs. CISC? What is this, the early 90's? There are no RISC chips anymore, except as product lines that were originally developed with the RISC methodology in mind. Similarly, true CISC doesn't exist either. Microcode has done wonders in turning complex instructions into a series of simpler instructions like one would find on a RISC processor.
The author's real point appears to be: x86 vs. Other Embedded Architectures. Without even looking at the article (which I did do), it's not hard to answer that one: There is no need for x86 code in a mobile platform. The hardware is going to be different than a PC, the interface is going to be different than a PC, and the usage of the device is going to be different than a PC. Providing x86 compatibility thus offers few, if any, real advantages over an ARM or other mobile chip.
If Intel's ATOM takes off, it will be on the merits of the processor and not on its x86 compatibility. Besides, x86 was a terrible architecture from the get-go. There's something mildly hilarious about the fact that it became the dominant instruction set in Desktop PCs across the world.
The problem with the MPC standard was that it wasn't very well executed. It was a success in that every magazine in existence talked about "if you have a multimedia PC you can do X!" CDROM Magazine was especially good at playing up the term.
The problem that came in was that consumers didn't understand the term very well due to the poor execution of the brand. Rather than recognizing that there were different levels of MPC, the assumption of the time was that MPC == CDROM+Sound Card+SVGA. Which wasn't too far from the truth as that's what MPC was created to promote. The problem was that they didn't future-proof the standard and thus it fell into disuse once all PCs had those features as standard.
I disagree. I didn't even finish reading the summary before I realized this wasn't going to work. TFA just confirmed my suspicion.
A few problems:
1. AMD will only certify AMD/ATI hardware. Which kind of makes this useless if you're an Intel/NVidia user.
2. Game Systems gain their stability due to LOOOOONG (4-5 years) release cycles. In PC terms, 4-5 years is an eternity.
3. AMD is going to butt heads with the PC Gaming Alliance they just helped form.
4. Given that PC Hardware is a moving target, how will AMD certify future machines? Will AMD GAME and GAME ULTRA also be moving targets? If so, will that not confuse Joe Gameplayer when AMD GAME system from 2008 fails to smoothly run AMD GAME software from 2010?
5. Epic and Id are the primary drivers behind the PC game market. Their engines are the keystone that holds the whole thing together. Thus it is their engines that make the market. Maybe I missed it, but I don't see AMD having their cooperation on setting future standards.
A much better system would be a versioned hardware spec that is maintained across the industry. e.g. PC-Spec 1 would certify GeFore 8400/Radeon HD 2400 and PC-Spec 2 would certify GeForce 8800/Radeon HD 2900. A new revision of the spec would be created for each sliding window. Each spec would consist of a certain performance plateau combined with a given feature set. (e.g. Support for GL Programmable Shaders.) The latest 3D engines from companies like Id and Epic would target the latest, upcoming spec. (A spec which those companies would have helped define when they were in early development.)
From a consumer perspective, this makes my life easier. Because instead of looking if RAM, Graphics Card, and CPU match, I can simply look for the spec number. If my computer supports a higher spec number than what's on the box (e.g. I have a PC-Spec 5 computer and this game requires PC-Spec 4) then I know I can play the game.
It's not quite as simple as consoles, but such is the way the PC world works.
You know the great thing about bleeding robots? Put enough holes in them and they die just as easily as humans.
We (the human resistance) will remember your allegiances when we send in the full S.W.A.T. team with heavy weaponry and body armor.
Oh, and I forgot a particularly nasty option: Compressing or encrypting the code. e.g. A piece of code can use OS services to compress data on disk. This would make it look like any other program with compressed segments. Another option is a variation of One Time Pad based on system information like hostname or MAC address. Again, it's hard to identify the stub as a definite virus header.
Even worse is that most viruses today are part of a Botnet that has Command and Control capabilities. So the hiding ability of the virus can be updated on a regular basis. Version 1 selected between compression and OTP? No problem! Version 2 will add reordering of code segments!
Quite nasty, these bugs.
Self modifying code is self modifying code. If it changes its signature into a different permutation that contains the same logic (e.g. changing the registers loaded, moving memory locations, inserting no-ops that don't look like no-ops, allocating different stack size, using a different location on disk, etc.) then it becomes nearly invisible to automated tools. I'm sure the next revision of anti-viral software will aim for complex heuristics that attempt to negate this sort of hiding. Which will become the next major arms race between virus writers and anti-virus writers. (Just like spam vs. anti-spam.)
Of course, arms races are usually a bad thing. They waste resources yet deliver very little. We need to start thinking about building a new infrastructure that is not susceptible to such simplistic attacks. e.g. Managed languages, jailed environments, trust relationships for email servers, and other such steps to data security. Unfortunately, there is so much time and money invested in our current infrastructure that there's no chance the market would make such a change unless absolutely forced to do so. Thus we come full circle back to the GPP's point.
1. Take the hard drives out and stick them in a USB Shell. Voila, instant backup/portable storage solution!
;-))
2. Take the memory chips and sell them on ebay as upgrades.
3. Rip the screens out and use them to create a Head Mounted Display in your home Virtual Reality project. (Yay for 90's thinking!
4. Unsolder the parts and use them for home hardware projects.
5. I'm running out of ideas. Maybe use the shell to stuff something geeky inside? Like a Commodore 64 Laptop?
6. Last but not least, cobble the best and/or compatible parts together to create one or two functional laptops. Load an OS in development (e.g. JNode) and use it for portable Operating System development. Alternatively, use it for an educational experience by building Linux from Scratch.