The patent only covers one method/system for doing the translation, there are others. Also, Amikai had an IRC-style chat client that translated the entire conversation into your preferred language back in 2000.
> Yeah, and the way to do this is by checking the MAC address so the offendor can't just switch ports.
It depends on what environment the computer is in. In a residence, the student has only one port available to him, so he'd have to pick up his computer and move to a friend's room to switch ports (and unless he's malicious, he won't do that). Faking a MAC address is much easier though - it's a simple software setting (how simple depends on your operating system).
The school I go to has an effective policy: firstly, they routinely scan the entire campus network for vulnerable machines using nessus.
If they find vulnerable machines, or if they detect that a machine has been compromised, they notify the owner, and if the problem is not corrected in an appropriate amount of time, turn off the connection at the switch. If that happens, the owner has to prove that the machine is fixed before they will turn it back on.
Admittedly, this is a little draconian, but the other residents appreciate that the network isn't constantly congested with dos attacks from compromised machines in their dorm.
While that's technically possible, and I've heard many people propose schemes like that (or with seti@home-like clients on each machine in the company), I think it will become less useful as technology improves, not more useful.
The argument is typically that each desktop machine is now increadibly overpowered, so it has plenty of spare CPU (or storage or whetever) to spare that the company can use. However, the reason each secretary in the company has an overpowered PC is that compute powere is really cheap, so it's also really cheap to duplicate that power in a central server room (I'm not talking high-reliabilty server CPUs, I'm thinking more comodity components like Google uses. If the task can be accomplished with each secretary's PC, it can be accomplished with low-reliability servers).
So, while any duplication wastes money, I think a server farm in a central location would be vastly cheaper to maintain, and the savings in people costs would offset the (small) additional hardware costs.
The article title is a bit misleading - this isn't a new, more powerful chip, it's a new, less-powerful chip designed for consumer markets. The PowerPC has been 64-bit for a while now, but the chips have been aimed at high-end machines (especially the Power4). It seems that this is a low-end Power4 that's more suitable for desktops.
You're oversimplifying things a little too much when you say that if a PowerPC chip were made with the same process that Intel uses for it's new P4s, it would have the same clock rate.
Modern CPUs are all pipelined, so they divide each instruction into several pieces - say Instruction Fectch, Instruction Decode, Execute, Load/Store, Write Back for example. Then, they interleave the execution of the different stages, so while one instruction is being decode, the next is already being fetched.
At a very rough approximation (it's much more complicated than this), the clock rate has to be low enough that the largest of the pipeline stages can execute in one clock tick, so if tou divide up the execution into more, smaller stages, you can raise the clock rate higher. However, there's a lot of complex machinery to avoid "hazards" where instructions depend on each other, so they have to stall some of the instructions, and this gets more complicated and slower with a longer pipeline. (This would be a gross simplification 10 years ago, and today's CPUs are much more complicated, but it gets the main point across).
The designers of the current PowerPC implementations chose fairly short pipelines (I'm not sure of the number of stages, but I think it's around 5), while Intel uses 20 stages for the P4. That means that the P4 can run at a higher clock rate, but get less done per cycle because more of the instructions are stalled.
So, my point is, at least IBM has CPU processes at the same level as Intel's, if not better - it's due to the fundamental design of the chip that the GHz number is lower, which makes the GHz a very uninteresting measure - hence the "MHz Myth".
Also, PowerPC is an instruction set, like IA32 or IA64, it's not a chip architecture. IBM and Motorola currently make chips that implement the PowerPC instruction set (and IBM's chip, the Power4, is currently the fastest chip available, BTW).
Just to add to the list of totally unfounded predictions, here's mine:
IBM released the Power4 a few months ago, as the fastest chip on the market. They want to use it for every server platform they make (AIX boxes, mainframes and AS/400 boxes). It's designed for servers, and that shows - you need something like 1 ton of force to attach it to the motherboard, and a pretty impressive cooling system as well. This makes it unsuitable for small desktop machines like the imac, and for laptops. Also, it doesn't support Altivec. I figure, they'll work out some licensing agreement so they can make a special, slightly slower version for Apple that does support Altivec.
The merits of this: they could use basically the same CPU design and processes (which are very, very good), and now software changes.
I don't think Apple can change to Intel chips because that would require new versions of all the software. They've just asked all their customers to replace old OS9 software with OS X software. If they came back in 2 years and said everyone should replace all their software again, their customers would start to get rather irritated by it...
That's just not correct. The.NET Compact Framework is the exact functional equivalent of J2ME - it will run on Windows CE / PocketPC devices at least (and possibly others). Admittedly, it is still in beta, but the.NET SDK was only released a few months ago, so that's not surprising. On a similar note, the.NET Framework APIs are maturing in future versions, so it won't be long until they are functionally equivalent to the Java APIs (they are already pretty close, at release 1.0).
Slashdot Mirror
The patent only covers one method/system for doing the translation, there are others. Also, Amikai had an IRC-style chat client that translated the entire conversation into your preferred language back in 2000.
> Yeah, and the way to do this is by checking the MAC address so the offendor can't just switch ports.
It depends on what environment the computer is in. In a residence, the student has only one port available to him, so he'd have to pick up his computer and move to a friend's room to switch ports (and unless he's malicious, he won't do that). Faking a MAC address is much easier though - it's a simple software setting (how simple depends on your operating system).
The school I go to has an effective policy: firstly, they routinely scan the entire campus network for vulnerable machines using nessus.
If they find vulnerable machines, or if they detect that a machine has been compromised, they notify the owner, and if the problem is not corrected in an appropriate amount of time, turn off the connection at the switch. If that happens, the owner has to prove that the machine is fixed before they will turn it back on.
Admittedly, this is a little draconian, but the other residents appreciate that the network isn't constantly congested with dos attacks from compromised machines in their dorm.
While that's technically possible, and I've heard many people propose schemes like that (or with seti@home-like clients on each machine in the company), I think it will become less useful as technology improves, not more useful.
The argument is typically that each desktop machine is now increadibly overpowered, so it has plenty of spare CPU (or storage or whetever) to spare that the company can use. However, the reason each secretary in the company has an overpowered PC is that compute powere is really cheap, so it's also really cheap to duplicate that power in a central server room (I'm not talking high-reliabilty server CPUs, I'm thinking more comodity components like Google uses. If the task can be accomplished with each secretary's PC, it can be accomplished with low-reliability servers).
So, while any duplication wastes money, I think a server farm in a central location would be vastly cheaper to maintain, and the savings in people costs would offset the (small) additional hardware costs.
The article title is a bit misleading - this isn't a new, more powerful chip, it's a new, less-powerful chip designed for consumer markets. The PowerPC has been 64-bit for a while now, but the chips have been aimed at high-end machines (especially the Power4). It seems that this is a low-end Power4 that's more suitable for desktops.
You're oversimplifying things a little too much when you say that if a PowerPC chip were made with the same process that Intel uses for it's new P4s, it would have the same clock rate.
Modern CPUs are all pipelined, so they divide each instruction into several pieces - say Instruction Fectch, Instruction Decode, Execute, Load/Store, Write Back for example. Then, they interleave the execution of the different stages, so while one instruction is being decode, the next is already being fetched.
At a very rough approximation (it's much more complicated than this), the clock rate has to be low enough that the largest of the pipeline stages can execute in one clock tick, so if tou divide up the execution into more, smaller stages, you can raise the clock rate higher. However, there's a lot of complex machinery to avoid "hazards" where instructions depend on each other, so they have to stall some of the instructions, and this gets more complicated and slower with a longer pipeline. (This would be a gross simplification 10 years ago, and today's CPUs are much more complicated, but it gets the main point across).
The designers of the current PowerPC implementations chose fairly short pipelines (I'm not sure of the number of stages, but I think it's around 5), while Intel uses 20 stages for the P4. That means that the P4 can run at a higher clock rate, but get less done per cycle because more of the instructions are stalled.
So, my point is, at least IBM has CPU processes at the same level as Intel's, if not better - it's due to the fundamental design of the chip that the GHz number is lower, which makes the GHz a very uninteresting measure - hence the "MHz Myth".
Also, PowerPC is an instruction set, like IA32 or IA64, it's not a chip architecture. IBM and Motorola currently make chips that implement the PowerPC instruction set (and IBM's chip, the Power4, is currently the fastest chip available, BTW).
Just to add to the list of totally unfounded predictions, here's mine:
IBM released the Power4 a few months ago, as the fastest chip on the market. They want to use it for every server platform they make (AIX boxes, mainframes and AS/400 boxes). It's designed for servers, and that shows - you need something like 1 ton of force to attach it to the motherboard, and a pretty impressive cooling system as well. This makes it unsuitable for small desktop machines like the imac, and for laptops. Also, it doesn't support Altivec. I figure, they'll work out some licensing agreement so they can make a special, slightly slower version for Apple that does support Altivec.
The merits of this: they could use basically the same CPU design and processes (which are very, very good), and now software changes.
I don't think Apple can change to Intel chips because that would require new versions of all the software. They've just asked all their customers to replace old OS9 software with OS X software. If they came back in 2 years and said everyone should replace all their software again, their customers would start to get rather irritated by it...
That's just not correct. The .NET Compact Framework is the exact functional equivalent of J2ME - it will run on Windows CE / PocketPC devices at least (and possibly others). Admittedly, it is still in beta, but the .NET SDK was only released a few months ago, so that's not surprising. On a similar note, the .NET Framework APIs are maturing in future versions, so it won't be long until they are functionally equivalent to the Java APIs (they are already pretty close, at release 1.0).