No, he's saying the speculators that he stole the domain from (and unlike, say, copyright infringement, someone was deprived of their use of the intellectual property, therefore, it was theft,) are the victims, but that they're sleazy for being speculators.
You're playing a game on your ARM-based netbook away from home - remember, that's what we're talking about here. Not sure what you're playing, Tux Racer, maybe, because that's about all it could handle that runs on Linux. Oh, wait, maybe LBreakout. Anyway, something crashes and you need to SSH into it. Wait, you're on your netbook that you suggested someone buy for the purpose of SSHing into other computers. And you can't set up an ad hoc connection between your cell phone and your netbook because you'd have to SSH in to do that, and last I checked, phones didn't have ethernet or (lately, anyway - yes, I know, Palm OS stuff has them, but you're a Linux beardo that probably has a Freerunner, forget a G1 or a Pre) RS232 ports.
But this is purely a hypothetical that you wouldn't understand, because you'd have to actually venture out of your mom's basement to encounter such a situation.
But ARM knows that consumers want Windows, not Linux. Hence all this.
Yes, applications are the problem, but if ARM sticks with it, eventually apps will migrate. I'll note that the various ports of NT to other architectures (other than MIPS) weren't paid for by Microsoft.
DEC paid MS to do the Alpha port (which is why Windows 2000 wasn't released for Alpha - Compaq decided to chase Itanium, and stopped paying Microsoft to develop the Alpha port,) and I'm fairly sure someone in the AIM alliance paid MS to do the PowerPC port, and fairly sure HP/Intel paid MS to do the Itanium port.
So, ARM would just have to pay MS to keep the port maintained. Keep doing it, and my guess is, given proper developer support (for example, Visual Studio compiling both x86 and ARM binaries by default,) within two Windows version generations, you'll have decent application support for ARM.
Except Windows CE has nothing in common with the NT branch other than part of an API. The iPhone OS runs the Darwin kernel, and has subsystems very similar to those on desktop OS X.
And the entire reason that ARM is trying to make deals with MS is because they want ARM netbooks to be the next big thing, and x86 Linux netbooks quickly got replaced by x86 Windows netbooks, so they obviously see ARM Linux netbooks as weak against x86 Windows netbooks.
Oh, and I just noticed, you used an Atom 330. That's not a 2 watt CPU, that's 8 watts. If Intel made a low voltage (N-series) part, it'd be 5 W, and a ULV (Z-series) part would be 4 W.
This is a bit confusing, but ARM claims 250 mW. That may be for a 2000 DMIPS single core, or it might be for an 8000 DMIPS quad core. Either way, that's 1 W at most for a quad, or half of Atom's power consumption.
If you're counting the SoC power, then please count the Atom's north and southbridges.
ARM designs CPU cores and licenses the cores and architecture to other companies.
Right now, off of the top of my head, there's the following architectures commonplace today:
ARM7, an ARMv4T-based core that's not far removed from the original ARM1 (ARM2 = ARM1 with hardware multiply, ARM3 = ARM2 with cache and coprocessor support, ARM6 = ARM3 with 32-bit addressing and minor speed improvements, ARM7 = ARM6 with more cache, essentially.) ARM9, an ARMv4T-based core ARM11, an ARMv6-based core ARM Cortex-A8, an ARMv7-based core
All of those were designed by ARM.
XScale, an ARMv5T-compliant core designed by DEC (IIRC) and Intel, now marketed by Marvell Feroceon/Sheeva, an ARMv5T-compliant core designed by Marvell Snapdragon, an ARMv7-compliant core/SoC designed by Qualcomm
The thing is, ARM is trying to push netbooks based on ARM CPUs, now, with TI and Freescale Cortex-A8-based chips and Qualcomm Snapdragon chips. This is why they're trying to get MS to pay attention to ARM.
Because wireless communications is not a free market, and shouldn't be.
If we had free market wireless, the company that had the most powerful transmitters would be the only carrier in that area, and all competition would be crowded out, until someone decided to buy a more powerful transmitter.
So, wireless communications is (in theory) heavily restricted, to make sure that companies are behaving, and don't stomp on each other or on customers.
Wired communications is also not a free market, because if it were, you'd have a solid wall of copper on telephone poles. Oddly, it'd be a more free market if it were more regulated - companies should have equal access to the copper, rather than one company owning the copper and keeping it to themselves.
Those FCC profanity regulations refer to broadcast content. That is, content transmitted with the intent of the general public receiving it. Cellular traffic is not broadcast - it's only meant for a cell tower or for a specific phone to receive it.
Opera desktop, however, has different binaries for each architecture it runs on. As Opera's closed source, that means Opera Software gets to decide what their program runs on.
With managed code, the VM developer gets to decide what platforms the VM runs on, and the software developers just target the VM.
As an example... there's a VNC app out there written for.NET. Now, normally, you'd need one VNC app for your PC, one VNC app for an ARM-based Windows CE device, so on, so on.
With.NET, I can run the same binary on an x86 PC, an Itanium server, or two different variants of ARM-based Windows Mobile device. (Not that I'd want to, it's not as good as, say, UltraVNC on x86, but it's still an example of how it can work.)
Anyway, there is also Java as an option, and a few real, useful apps out there are written in Java - I use a couple every day. And, the ARMs have Jazelle support, which basically means a subset of Java bytecode instructions that can be accelerated by running them directly are run directly on the CPU, so Sun would just have to release a JVM for Win32/ARM that used Jazelle, and Java performance would be excellent on ARM. (I think Jazelle's there because of ARM being used on cell phones, which almost always have JVMs of some sort, often.)
Also, MS could always make their compilers slip in an ARM binary automatically. Call it.exea. And make ARM DLLs.dlla or something.
Then, have a stub at the very beginning of the.exe/.dll, in x86 code. This would be small, and it would basically detect an ARM, if ARM, replace image with the ARM image, drop out of x86 emulation, and continue execution natively. That would create an effective fat binary format, without actually needing to change the Windows executable format at all.
Slashdot Mirror
Well, for one thing, Apple didn't deprive Cisco of the use of the iPhone name.
This guy did deprive the legitimate owners of the use of their domain names.
No, he's saying the speculators that he stole the domain from (and unlike, say, copyright infringement, someone was deprived of their use of the intellectual property, therefore, it was theft,) are the victims, but that they're sleazy for being speculators.
Except Stallman is one of those whiny FOSSies, hence GPL v3.
But, this is GPL v2, so the rest of your post is valid.
You're playing a game on your ARM-based netbook away from home - remember, that's what we're talking about here. Not sure what you're playing, Tux Racer, maybe, because that's about all it could handle that runs on Linux. Oh, wait, maybe LBreakout. Anyway, something crashes and you need to SSH into it. Wait, you're on your netbook that you suggested someone buy for the purpose of SSHing into other computers. And you can't set up an ad hoc connection between your cell phone and your netbook because you'd have to SSH in to do that, and last I checked, phones didn't have ethernet or (lately, anyway - yes, I know, Palm OS stuff has them, but you're a Linux beardo that probably has a Freerunner, forget a G1 or a Pre) RS232 ports.
But this is purely a hypothetical that you wouldn't understand, because you'd have to actually venture out of your mom's basement to encounter such a situation.
But ARM knows that consumers want Windows, not Linux. Hence all this.
Yes, applications are the problem, but if ARM sticks with it, eventually apps will migrate. I'll note that the various ports of NT to other architectures (other than MIPS) weren't paid for by Microsoft.
DEC paid MS to do the Alpha port (which is why Windows 2000 wasn't released for Alpha - Compaq decided to chase Itanium, and stopped paying Microsoft to develop the Alpha port,) and I'm fairly sure someone in the AIM alliance paid MS to do the PowerPC port, and fairly sure HP/Intel paid MS to do the Itanium port.
So, ARM would just have to pay MS to keep the port maintained. Keep doing it, and my guess is, given proper developer support (for example, Visual Studio compiling both x86 and ARM binaries by default,) within two Windows version generations, you'll have decent application support for ARM.
That has two CPUs, one x86 and one ARM, and Windows runs on the x86.
This is about running Windows on an ARM.
Except Windows CE has nothing in common with the NT branch other than part of an API. The iPhone OS runs the Darwin kernel, and has subsystems very similar to those on desktop OS X.
And the entire reason that ARM is trying to make deals with MS is because they want ARM netbooks to be the next big thing, and x86 Linux netbooks quickly got replaced by x86 Windows netbooks, so they obviously see ARM Linux netbooks as weak against x86 Windows netbooks.
And the processors being targeted by a theoretical ARM netbook port use one of three (OK, four) cores.
ARM Cortex-A8 (TI or Freescale SoCs)
ARM Cortex-A9 (TI SoCs in the future)
ARM11 (nVidia Tegra)
Qualcomm Snapdragon
Oh, and I just noticed, you used an Atom 330. That's not a 2 watt CPU, that's 8 watts. If Intel made a low voltage (N-series) part, it'd be 5 W, and a ULV (Z-series) part would be 4 W.
This is a bit confusing, but ARM claims 250 mW. That may be for a 2000 DMIPS single core, or it might be for an 8000 DMIPS quad core. Either way, that's 1 W at most for a quad, or half of Atom's power consumption.
If you're counting the SoC power, then please count the Atom's north and southbridges.
He meant PowerPC, not Pocket PC.
ARM designs CPU cores and licenses the cores and architecture to other companies.
Right now, off of the top of my head, there's the following architectures commonplace today:
ARM7, an ARMv4T-based core that's not far removed from the original ARM1 (ARM2 = ARM1 with hardware multiply, ARM3 = ARM2 with cache and coprocessor support, ARM6 = ARM3 with 32-bit addressing and minor speed improvements, ARM7 = ARM6 with more cache, essentially.)
ARM9, an ARMv4T-based core
ARM11, an ARMv6-based core
ARM Cortex-A8, an ARMv7-based core
All of those were designed by ARM.
XScale, an ARMv5T-compliant core designed by DEC (IIRC) and Intel, now marketed by Marvell
Feroceon/Sheeva, an ARMv5T-compliant core designed by Marvell
Snapdragon, an ARMv7-compliant core/SoC designed by Qualcomm
The thing is, ARM is trying to push netbooks based on ARM CPUs, now, with TI and Freescale Cortex-A8-based chips and Qualcomm Snapdragon chips. This is why they're trying to get MS to pay attention to ARM.
Because wireless communications is not a free market, and shouldn't be.
If we had free market wireless, the company that had the most powerful transmitters would be the only carrier in that area, and all competition would be crowded out, until someone decided to buy a more powerful transmitter.
So, wireless communications is (in theory) heavily restricted, to make sure that companies are behaving, and don't stomp on each other or on customers.
Wired communications is also not a free market, because if it were, you'd have a solid wall of copper on telephone poles. Oddly, it'd be a more free market if it were more regulated - companies should have equal access to the copper, rather than one company owning the copper and keeping it to themselves.
VOIP on the cell network is billed as data, not voice minutes, though.
But, all VOIP discussion is moot, other than cheaper international service, because Google Voice doesn't use VOIP for the last mile, it uses POTS.
Those FCC profanity regulations refer to broadcast content. That is, content transmitted with the intent of the general public receiving it. Cellular traffic is not broadcast - it's only meant for a cell tower or for a specific phone to receive it.
Opera desktop, however, has different binaries for each architecture it runs on. As Opera's closed source, that means Opera Software gets to decide what their program runs on.
With managed code, the VM developer gets to decide what platforms the VM runs on, and the software developers just target the VM.
As an example... there's a VNC app out there written for .NET. Now, normally, you'd need one VNC app for your PC, one VNC app for an ARM-based Windows CE device, so on, so on.
With .NET, I can run the same binary on an x86 PC, an Itanium server, or two different variants of ARM-based Windows Mobile device. (Not that I'd want to, it's not as good as, say, UltraVNC on x86, but it's still an example of how it can work.)
Anyway, there is also Java as an option, and a few real, useful apps out there are written in Java - I use a couple every day. And, the ARMs have Jazelle support, which basically means a subset of Java bytecode instructions that can be accelerated by running them directly are run directly on the CPU, so Sun would just have to release a JVM for Win32/ARM that used Jazelle, and Java performance would be excellent on ARM. (I think Jazelle's there because of ARM being used on cell phones, which almost always have JVMs of some sort, often.)
However, an Atom SoC could get a DSP of its own, and be competitive still. The other points still stand, though.
The problem arises when you have an app that "needs RHEL," and you don't want to pay for RHEL. And there are lots of companies like that.
So, CentOS becomes the only option.
And try DCC SEND (any text afterwards) in an IRC channel.
Certain patch levels of VxWorks-based routers with SPI firewalls will instantly drop the connection.
Lower power consumption, smaller die size, smaller PCB area.
And, they're working on the performance.
This isn't ARM trying to get Windows on mobile phones, this is ARM trying to get into the netbook space.
Also, MS could always make their compilers slip in an ARM binary automatically. Call it .exea. And make ARM DLLs .dlla or something.
Then, have a stub at the very beginning of the .exe/.dll, in x86 code. This would be small, and it would basically detect an ARM, if ARM, replace image with the ARM image, drop out of x86 emulation, and continue execution natively. That would create an effective fat binary format, without actually needing to change the Windows executable format at all.
To be fair, MS has worked on optimizing .NET for ARM. But, only a limited subset of it, the .NET Compact Framework. It's used in WinMo.
Except PA Semi also does ARM cores, and the rumor mill says that that's what they're working on for Apple.
The strongARM pun is so beaten into the ground that DEC's implementation of ARM was even called StrongARM. ;)