But the real question is this: Why would someone do this? Certainly someone with a cool million lying around did something to make that money. What is to be gained by an individual donating that much money to a cause that has its roots in opposing the big corporation and "the man"? Likely, it isn't because it was just philosophically the "right thing to do".
No. Its because, as has been pointed out, there are corporate interested backing the other side. The real question is -- why throw the $1mil now? Because right *now* the telecom industry is waking up to the fact that they need to protect consumers freedom to use their technology otherwise it will weaken the demand for their technology.
We finally have an ally (hardly an ideal choice, but they are big and influential) -- it is the telecom industry.
Read the article more carefully. It says hardware players still need to pony up. That includes hardware players that use Java as their programming interface (something Sun is keen about.)
All the original poster said was that while it was no big deal to emulate the 68k on the vastly more powerful PPC, emulating a PPC on an x86 would be not so easy, as x86 and PPC are roughly equal.
Well that's fine, but this too is wrong. There is in fact no longer any benchmarks that show the Apple within a country mile of the Pentium 4.
That being said, it would indeed be extremely difficult to emulate PPC on the x86! This is simply because of the way the chips are designed.
Ok, now you are just completely off base. The complexity of the task of emulation has to do with the instruction set you are emulating, not the target platform. The target platform is just a recepticle for compiled fragments. You don't software emulate another processor by trying to map the instruction sets directly to each other! If you claim that the RISC PPC is a cleaner nicer architecture because its RISC, then in fact to emulate it will be even easier to do than the 68K (a CISC) emulation.
You post like you sound like you know something, when you obviously don't have the first clue.
This will become blatantly obvious if you consider that there are multiple, at least three, separately developed programs-- one of which is open source-- which emulate an x86 PC on a PPC Macintosh. There are, however, no extant PPC Macintosh emulators for the x86 PC.
Spoken like true uninformed macaholic idiot. The reason there is no PPC emulator on the PC is because nobody who has a PC wants anything that runs on the Mac. Nobody.
But for what else? MS Word still opens in a split-second.
OpenOffice 1.01 still opens pretty quickly.
IE, Netscape, and Opera still open in a split-second.
Sorry bub -- Word, Open Office, IE and Netscape all take more than a second to load for me (and that is unacceptable to me.) But the real pisser for me is Adobe Acrobat. My god that thing takes for ever to load.
Initial load time is not all processor though. Its hard disk, software and OS architecture.
So, I'm curious. I haven't tried NWN yet, so maybe that's the sort of high-powered cybercrank I need to get myself hooked on the slickmercury speeds of AXP 2000+ and Ti4600.
Well I have NWN. But I also have a GeForce Ti4600, so I can play with 2x AA and its absolutely fine.
Well there's a quick way to shut this guy up ....
on
Mr Anti-Google
·
· Score: -1, Flamebait
Ah yes, I vaguely recall Microsoft sold its interest in Corel some time back.
Re:Mosfet.org updated about why this is bad
on
KDE Gets The Hat
·
· Score: 1
Dude, check your posts with the preview button.
That said:
If users select to use the KDE desktop they should obviously get access to KDE applications as the default, not Gnome ones. Doing otherwise cripples the entire thing. Are you sure about that? I would have thought that users should obviously get access to the best applications as the default. Doing otherwise is a self-selving wank on behalf of the desktop. Sorry, Mozilla will work for more pages than Konq and therefore makes a good alternative to Konq, which is still there.
I am with Mosfet on this one. If a user wants KDE, s/he should get KDE. If you want the "BEST" apps, you need some other choice mechanism (besides some defined criteria for "best".)
You can forget about all the code sharing features of KDE Why?
You are just regurgitating the Intel corporate line, Mr. ObviousGuy.
Compilers *could* take advantage of P4's long pipeline to exclusion, or they could take advantage of AMD's *WIDE* pipeline. Microsoft (the leading compiler vendor for x86) has chosen to tagret *BOTH* platforms.
If you view AMD as solely a *value chip* company you obviously have had your head in the sand for the last 3 years. AMD has been in a neck and neck race, where it has been mostly ahead of Intel ever since the release of the Athlon.
No it wouldn't be better. Its better to use a compiler that is actually used in the applications that you run on that platform. In the case of x86, that's going to be Microsoft Visual C++. You could even argue Sun or Microsoft's Java compilers, Visual Basic, or Delphi could be added to the mix.
However, using Intel C++, is not credible since the vast majority of C++ applications running on x86 don't use that compiler.
BapCo's head quarters are on the Intel campus. Its been Intel biased from day 1 (back when AMD was making K5's and thinking about making K6's) and AMD has known this.
The fact is, prior to the release of the Athlon, nearly all benchmarks were biased towards Intel. AMD's strategy when they released that Athlon was to make a CPU so good, it could beat Intel's CPUs even on these benchmarks. Sysmark just happens to be the one benchmark where Intel exercises so much control that it could literally say whatever Intel wanted it to say.
What you are seeing is AMD just starting to switch strategies from "lets just beat them on every benchmark under the sun regardless of bias" to "lets expose the bias where it is as its worse so people can know the truth".
This is all just preparation for the K8 launch I think. If AMD can properly put Sysmark results into perspective, maybe everything that is left will show what a monster K8 is versus any Intel offering. It is indicative that the K8 may not be winning on Sysmark on internal testing, or may not be winning by a sufficient margin.
Actually Van has been saying this for some time now. While this last chapter in this saga was mostly accomplished through the leg work of AMD, Van deserves credit for calling this one correctly a long time ago.
Then you do not understand the point of WineX at all.
The point is not to just lure over Windows people who don't want to switch. Its for those that want to switch but don't feel they can.
There are many such people (I am one of them) and Wine helps move them all over to Linux, that grows the community, which provides a market to pay for solving the remaining problems in Linux.
Personally, I regard, WineX and the Transgaming effort in general along with Open Office as the most important things going on in the Linux community right now.
I'm pretty surprised Microsoft hasn't said or done anything about the Lindows name.
Uh hello? Moron? They are doing something about it -- they are suing over the name in a trademark infringment suit. Its groundless, but they are doing so anyway.
Seriously, it's obviously named that so it sounds like Windows (duh) and then people will think it's like Windows and as easy to use as Windows.
Oh what a criminal misrepresentation! Especially since its most likely going to be true!
It's like if Microsoft came out with a side project called Mapple and sold a computer called the iWac....
While I fully support the case -- the Dmitry Sklyarov incident has nothing to do with the history of Linux. Perhaps some mention of deCSS would be more appropriate (it *DOES* have something to do with Linux.)
In CPUs like the Athlon or Pentium, esoteric and rarely used previous generation features are microcoded and have little or no impact on critical path performance.
The ability to create a high performance processor while retaining backward compatibility is just a matter of design. The two ideas do not necessarily interfere with each other in terms of performance.
The x86 backward compatibility hierarchy is actually quite reasonable excepting for the lack of registers. "long mode" in x86-64 fixes precisely this problem.
With "fresh starts" we end up with garbage like "MIPS" (exposed branch delay slots, makes forward compatibility to deeper pipelined chips difficult if not impossible) or "Itanium" (so complicated, its hard to imagine how they will improve architectural performance over time) or "Crusoe" (an extremely "simple" architecture that cannot go toe to toe with its contemporary x86 brothers.)
In the end the better implementation wins. That is all.
As usual with the register, big on speculation, useless on analysis.
The reason why AMD is a good choice for the next generation X-Box, is because Intel's P4 CPU is too big and draws too much heat. The presentations AMD have made on Hammer so far indicate that it will be a much smaller CPU with better thermal characteristics (I.e., AMD learns from its past...)
Sony and Nintendo have integrated chips which gives them an untouchable cost advantage vs. MS. Intel and nVidia wont integrate because they hate each other and because the Intel CPUs are just too damn big. With Hammer, the situation is very different.
Microsoft's real excuse last time was that AMD did not have the manufacturing capacity to meet the XBox demand (it was probably the *real* reason MS did not choose Athlon, though MS cleverly tricked Intel and AMD into thinking it was a matter of price.) However, once their UMC joint fab goes online, the combination of that and Dresden, 300 mm, and smaller dies will give AMD a much larger effective capacity.
Slashdot Mirror
Since its optimization you are concerned with I have a few choices you will be interested in:
1. The Zen of Code Optimization by Michael Abrash.
2. Agner Fog's Assembly Resources
3. The Athlon Optimization Guide
4. Intel's IA32 Optimization Guide
5. The Aggregate Magic Algorithms
These sources will give you everything you need to know about code optimization for x86.
We finally have an ally (hardly an ideal choice, but they are big and influential) -- it is the telecom industry.
Read the article more carefully. It says hardware players still need to pony up. That includes hardware players that use Java as their programming interface (something Sun is keen about.)
So Sun's still got to get rid of it.
Ok, now you are just completely off base. The complexity of the task of emulation has to do with the instruction set you are emulating, not the target platform. The target platform is just a recepticle for compiled fragments. You don't software emulate another processor by trying to map the instruction sets directly to each other! If you claim that the RISC PPC is a cleaner nicer architecture because its RISC, then in fact to emulate it will be even easier to do than the 68K (a CISC) emulation.
You post like you sound like you know something, when you obviously don't have the first clue.
Spoken like true uninformed macaholic idiot. The reason there is no PPC emulator on the PC is because nobody who has a PC wants anything that runs on the Mac. Nobody.
Initial load time is not all processor though. Its hard disk, software and OS architecture.
Well I have NWN. But I also have a GeForce Ti4600, so I can play with 2x AA and its absolutely fine.
Just /. him. Great.
Ah yes, I vaguely recall Microsoft sold its interest in Corel some time back.
That said:
I am with Mosfet on this one. If a user wants KDE, s/he should get KDE. If you want the "BEST" apps, you need some other choice mechanism (besides some defined criteria for "best".)
Because Gnome apps don't know/care about KParts?
You are just regurgitating the Intel corporate line, Mr. ObviousGuy.
Compilers *could* take advantage of P4's long pipeline to exclusion, or they could take advantage of AMD's *WIDE* pipeline. Microsoft (the leading compiler vendor for x86) has chosen to tagret *BOTH* platforms.
If you view AMD as solely a *value chip* company you obviously have had your head in the sand for the last 3 years. AMD has been in a neck and neck race, where it has been mostly ahead of Intel ever since the release of the Athlon.
No it wouldn't be better. Its better to use a compiler that is actually used in the applications that you run on that platform. In the case of x86, that's going to be Microsoft Visual C++. You could even argue Sun or Microsoft's Java compilers, Visual Basic, or Delphi could be added to the mix.
However, using Intel C++, is not credible since the vast majority of C++ applications running on x86 don't use that compiler.
Perhaps you should keep browsing Van's page then. He has an idea about making an open source benchmark using a standard compiler
BapCo's head quarters are on the Intel campus. Its been Intel biased from day 1 (back when AMD was making K5's and thinking about making K6's) and AMD has known this.
The fact is, prior to the release of the Athlon, nearly all benchmarks were biased towards Intel. AMD's strategy when they released that Athlon was to make a CPU so good, it could beat Intel's CPUs even on these benchmarks. Sysmark just happens to be the one benchmark where Intel exercises so much control that it could literally say whatever Intel wanted it to say.
What you are seeing is AMD just starting to switch strategies from "lets just beat them on every benchmark under the sun regardless of bias" to "lets expose the bias where it is as its worse so people can know the truth".
This is all just preparation for the K8 launch I think. If AMD can properly put Sysmark results into perspective, maybe everything that is left will show what a monster K8 is versus any Intel offering. It is indicative that the K8 may not be winning on Sysmark on internal testing, or may not be winning by a sufficient margin.
Actually Van has been saying this for some time now. While this last chapter in this saga was mostly accomplished through the leg work of AMD, Van deserves credit for calling this one correctly a long time ago.
On an unpatched installtion of Windows, yes, it would.
This is the idiotic method that Windows Media Encoder decides whether or not SSE instructions might be supported.
Then you do not understand the point of WineX at all.
The point is not to just lure over Windows people who don't want to switch. Its for those that want to switch but don't feel they can.
There are many such people (I am one of them) and Wine helps move them all over to Linux, that grows the community, which provides a market to pay for solving the remaining problems in Linux.
Personally, I regard, WineX and the Transgaming effort in general along with Open Office as the most important things going on in the Linux community right now.
Uh hello? Moron? They are doing something about it -- they are suing over the name in a trademark infringment suit. Its groundless, but they are doing so anyway.
Oh what a criminal misrepresentation! Especially since its most likely going to be true!
Or "Palm Sized PC" perhaps?
Why do the fricking moderators miss things like this?? Why does this get a score of 1?!?! Why is this not like a 3 or 4 "Informative"?
While I fully support the case -- the Dmitry Sklyarov incident has nothing to do with the history of Linux. Perhaps some mention of deCSS would be more appropriate (it *DOES* have something to do with Linux.)
No its not better.
In CPUs like the Athlon or Pentium, esoteric and rarely used previous generation features are microcoded and have little or no impact on critical path performance.
The ability to create a high performance processor while retaining backward compatibility is just a matter of design. The two ideas do not necessarily interfere with each other in terms of performance.
The x86 backward compatibility hierarchy is actually quite reasonable excepting for the lack of registers. "long mode" in x86-64 fixes precisely this problem.
With "fresh starts" we end up with garbage like "MIPS" (exposed branch delay slots, makes forward compatibility to deeper pipelined chips difficult if not impossible) or "Itanium" (so complicated, its hard to imagine how they will improve architectural performance over time) or "Crusoe" (an extremely "simple" architecture that cannot go toe to toe with its contemporary x86 brothers.)
In the end the better implementation wins. That is all.
That's bad coding style (C-based comments don't nest properly). Instead use:
#if 0
SpyWareReport ("$user");
#endif
Oh that's easy, just drag it into an open spanish, or king's gambit. If it rips you to shreds in 10 moves, then its definately a computer.
As usual with the register, big on speculation, useless on analysis.
...)
The reason why AMD is a good choice for the next generation X-Box, is because Intel's P4 CPU is too big and draws too much heat. The presentations AMD have made on Hammer so far indicate that it will be a much smaller CPU with better thermal characteristics (I.e., AMD learns from its past
Sony and Nintendo have integrated chips which gives them an untouchable cost advantage vs. MS. Intel and nVidia wont integrate because they hate each other and because the Intel CPUs are just too damn big. With Hammer, the situation is very different.
Microsoft's real excuse last time was that AMD did not have the manufacturing capacity to meet the XBox demand (it was probably the *real* reason MS did not choose Athlon, though MS cleverly tricked Intel and AMD into thinking it was a matter of price.) However, once their UMC joint fab goes online, the combination of that and Dresden, 300 mm, and smaller dies will give AMD a much larger effective capacity.
Why hasn't the above post been moderated to +5 insightful?