Who cares? It's the most cost-effective CPU arch out there, and one of the most energy-efficient (well at least the Pentium M, that is).
And besides nobody has ever said x86. Apple will most likely jump straight to EMT64 (aka Intel's compatible answer to AMD64). The later P4 model support it. It's a pretty cool arch, really, with a good number of registers and a few new nice things. And Apple won't need to support backwards-compatibility to x86, so no yucky x86 binaries.
That's interesting. They're saying Windows could run on those Macs, which implies they WILL be more or less PC-compatible since Windows is not flexible enough to run on a non-standard PC (just look at the XBox, nobody ever managed to have a stock version of Windows running natively).
That means a plain BIOS (no OpenFirmware, sadly), plain video cards, yadda yadda. The only thing that will lock in OSX is a few Mac chips.
Hey, didn't OS 9 have the capability to use a fake Apple ROM in a binary file so Apple could remove that chip from their boards? And since the OSX kernel is open source..... muhahahaha....
I don't understand all this "waaaah! my PPC mac is obsolete!" whining. Everything for the next few years will be in hybrid PPC/x86 fat-binary form (or as Jobs called them, "universal binaries") so existing PPC macs will run future programs just fine during and after the x86 switch. Apple will probably scrap PPC support only at the next major OS restructuring (just as OSX abandonned 68k support). And by then your PPC mac will be an old POS anyway.
"Development tools could easily support compilation to some sort of fat-binary"
Actually, OSX already supports that. Darwin's native binary format, Mach-O, can do fat-binaries. The Darwin CD distribution is composed almost entirely of PPC/x86 fat-binaries, which allows it to be perfectly dual-arch.
Have you ever done any game programming work? I guess not, because if you did you'd probably knew by then that games can't be magically multithreaded. Of course it's so easy to whine about lack of multithreading in a game when you're only playing it. But that's okay, I'll explain it to you.
First of all, multithreading a game more trouble than it's worth, because a video game depends on having everything synchronized together. The second you offload a given task to another thread, it becomes the jurisdiction of the operating system's thread scheduler to decide when that thread gets to work on whatever it needs to do. That's not good, because you end up having every thread wait on each other to finish its required work in a given timeframe before going on to the next processing timeframe. If the OS decides to give less time than necessary to a single one of those threads, you end up with a loss.
Also, add into the fact that multithreading is the univeral way of not only making harder to debug code and create nasty deadlocks (any programmer eventually comes to this) and it suddenly becomes even more unattractive. A widely used rule of thumb in software engineering is "use threads only if it's really necessary for your program flow". It is necessary for a server to process multiple queries at a time, and it is necessary for a GUI app to avoid locking up the interface while there is a processing task running in background, but in the case of a game everything must be live and synchronized. There is no immediate need for threads.
The only thing that makes sense putting on another thread is the sound processing, because it's essentially a strictly background task, that gets called on-demand everytime a sound or music needs to be played, and doesn't need strict synchronization with the gameplay. And yes, every modern mainstream engine already does this, including DOOM III.
So finally after all this trouble, what advantages do you get? Not much. Most multi-CPU systems are only dual, and we have 1) the main thread, 2) the sound thread, and 3) the operating system's kernel. That's at least three tasks on two processors. Granted the kernel and sound thread does not work as much as the main thread, but nevertheless you're already overloaded, and therefore those other threads you want to create will only add minor performance increases by using what's left of the sound/kernel processor.
So in short, multithreading a game only adds marginal performance increases at a way too significant development (and stability) cost.
Canadian regulations on cable TV and digital radio stations are very limited. If a given American station covers content that can have a Canadian equivalent, then the American station won't be allowed in by the CRTC. This is done to give exclusive content rights to Canadian stations.
And your point is...? NAT may not be a proper firewall but for most uses it's a good enough security measure. Which is why I'm saying we shouldn't discard it.
Personnally I don't run any firewalls in my behind-a-router home network. Sure it may allow trojans and viruses to "call home", but apart from that what possible attacks am I vulnerable to?
NAT is a "Good Thing"(tm) because most machines shouldn't have incoming access from outside their LAN. The inconvenience of manually mapping incoming packets forwarding far outweights the blatant lack of security. And god knows our networks are insecure enough already.
Slashdot Mirror
Of course Microsoft can. That's not my point. I was talking about hacking Windows into running on an unsupported machine.
You're talking about PORTS to OTHER ARCHITECTURES. I'm talking about x86 Windows not running on non-PC-compatible x86 hardware.
I guess that by the end of the day, Duke Nukem Forever will be out.
I know that. But it's still pretty damn good. The biggest shortcoming of x86 is the lack of general-purpose registers, and now it's fixed. There.
Sweet mother of fuck. Thanks to this story, Slashdot is slashdotting itself. I can hear the fabric of space-time breaking up.
"The x86 architecture is a disgrace."
Who cares? It's the most cost-effective CPU arch out there, and one of the most energy-efficient (well at least the Pentium M, that is).
And besides nobody has ever said x86. Apple will most likely jump straight to EMT64 (aka Intel's compatible answer to AMD64). The later P4 model support it. It's a pretty cool arch, really, with a good number of registers and a few new nice things. And Apple won't need to support backwards-compatibility to x86, so no yucky x86 binaries.
That's interesting. They're saying Windows could run on those Macs, which implies they WILL be more or less PC-compatible since Windows is not flexible enough to run on a non-standard PC (just look at the XBox, nobody ever managed to have a stock version of Windows running natively).
That means a plain BIOS (no OpenFirmware, sadly), plain video cards, yadda yadda. The only thing that will lock in OSX is a few Mac chips.
Hey, didn't OS 9 have the capability to use a fake Apple ROM in a binary file so Apple could remove that chip from their boards? And since the OSX kernel is open source..... muhahahaha....
I don't understand all this "waaaah! my PPC mac is obsolete!" whining. Everything for the next few years will be in hybrid PPC/x86 fat-binary form (or as Jobs called them, "universal binaries") so existing PPC macs will run future programs just fine during and after the x86 switch. Apple will probably scrap PPC support only at the next major OS restructuring (just as OSX abandonned 68k support). And by then your PPC mac will be an old POS anyway.
"Development tools could easily support compilation to some sort of fat-binary"
Actually, OSX already supports that. Darwin's native binary format, Mach-O, can do fat-binaries. The Darwin CD distribution is composed almost entirely of PPC/x86 fat-binaries, which allows it to be perfectly dual-arch.
My guess is that this is the work of a troll.
Glad to know I was wrong.
"I mean, even microsoft uses apple g5's for their hardware-intensive rendering and compiling and such"
Do you have any references to back up that claim?
700$ is commodity to you??
SUV sales are still rising.
OK then, it was bad wording of my part, replace "space" with "footprint". Do you understand now?
Granted the PS2 is larger than your average console, but the fact that you can have it stand on the side really does make it use less space.
Have you ever done any game programming work? I guess not, because if you did you'd probably knew by then that games can't be magically multithreaded. Of course it's so easy to whine about lack of multithreading in a game when you're only playing it. But that's okay, I'll explain it to you.
First of all, multithreading a game more trouble than it's worth, because a video game depends on having everything synchronized together. The second you offload a given task to another thread, it becomes the jurisdiction of the operating system's thread scheduler to decide when that thread gets to work on whatever it needs to do. That's not good, because you end up having every thread wait on each other to finish its required work in a given timeframe before going on to the next processing timeframe. If the OS decides to give less time than necessary to a single one of those threads, you end up with a loss.
Also, add into the fact that multithreading is the univeral way of not only making harder to debug code and create nasty deadlocks (any programmer eventually comes to this) and it suddenly becomes even more unattractive. A widely used rule of thumb in software engineering is "use threads only if it's really necessary for your program flow". It is necessary for a server to process multiple queries at a time, and it is necessary for a GUI app to avoid locking up the interface while there is a processing task running in background, but in the case of a game everything must be live and synchronized. There is no immediate need for threads.
The only thing that makes sense putting on another thread is the sound processing, because it's essentially a strictly background task, that gets called on-demand everytime a sound or music needs to be played, and doesn't need strict synchronization with the gameplay. And yes, every modern mainstream engine already does this, including DOOM III.
So finally after all this trouble, what advantages do you get? Not much. Most multi-CPU systems are only dual, and we have 1) the main thread, 2) the sound thread, and 3) the operating system's kernel. That's at least three tasks on two processors. Granted the kernel and sound thread does not work as much as the main thread, but nevertheless you're already overloaded, and therefore those other threads you want to create will only add minor performance increases by using what's left of the sound/kernel processor.
So in short, multithreading a game only adds marginal performance increases at a way too significant development (and stability) cost.
They are ruining our "Yeah, but can it run Linux?" jokes by going right ahead and using it in their first demos!
Canadian regulations on cable TV and digital radio stations are very limited. If a given American station covers content that can have a Canadian equivalent, then the American station won't be allowed in by the CRTC. This is done to give exclusive content rights to Canadian stations.
This is /. you know. Not a Matrix Online forum. Acting "in character" here only makes you look very stupid.
Lawrence Fishburne decided not to renew his voice acting contract, and the W brothers didn't want to continue with a fake.
Funny how you cited Obi Wan as a comparison, even though I he dies within the first half of the first movie of the original trilogy.
And your point is...? NAT may not be a proper firewall but for most uses it's a good enough security measure. Which is why I'm saying we shouldn't discard it.
Personnally I don't run any firewalls in my behind-a-router home network. Sure it may allow trojans and viruses to "call home", but apart from that what possible attacks am I vulnerable to?
You're underestimating the power of inertia in the US. Remember that this is a country that still doesn't recognize the metric system!
NAT is a "Good Thing"(tm) because most machines shouldn't have incoming access from outside their LAN. The inconvenience of manually mapping incoming packets forwarding far outweights the blatant lack of security. And god knows our networks are insecure enough already.