In Australia they're getting 21Mbps from HSPA+: http://www.fiercebroadbandwireless.com/story/australias-telstra-launches-hspa/2009-02-22

And they claim they'll double it by the end of the year (with multicarrier HSPA+?)

Typical government:

1100 1010 [CBh],

Can't even convert 0b1010 to the correct hex digit (A).

I'd consider my primary computer as the one that has zero displays. However, I run "screen" on it and reattach all the time. So I selected zero, assuming that "screen" means "display" rather than "virtual terminals running under the screen command"...

Actually, I'm surprised this isn't a more popular option. Doesn't everyone connect to an always-on machine and reattach?

Linux has plenty of critics. Developers are critical of their own code. Just look through the lkml or read the code, there are plenty of places where there is constructive criticism about how something is done.

Yes, you should get more bandwidth. Yes, you should shape traffic to favor real-time traffic over bulk traffic. You should be doing both.

Like I said, we were only interested in one application: our simulator. It was developed for gcc and suncc for sparc. icc produced a slower binary. ICC may be faster over a wide variety of benchmarks, and probably especially ones where vectorization, etc can be used. However, for our simulator, gcc produced better results.

Look, I would love nothing more than ARM to win. Because if ARM wins, it opens up the door for innovation in architecture. And that's good for everyone.

But they won't. Intel can make x86 chips that are low cost and low power consumption. And ARM is rapidly approaching implementation requirements that mean it's not as simple as you think it is. They overcrowded the opcode space, making decode hard. Thumb2 means serial decode problems, just like x86. And the whole anything-shifted-by-anything field on every instruction isn't so great for decent OoO pipelines. You end up having what amount to microcoded instructions with the move-multiples. So you end up doing basically the same things Intel would do -- breaking up instructions, speculative decode blocks, microcoded instructions, etc -- and Intel has been doing it longer and better.

Two operating modes, seven supervisor modes, various page table formats, thousands of instructions (when you consider addressing modes and condexec and ARM/THUMB and Neon and VFP and...)... do you really think that ARM is *really* all that much more simple than x86?

ARM ain't no Alpha. ARM ain't no MIPS.

So maybe ARM has a niche in ARM7 and ARM9 class tiny, licensable, synthesizeable 32-bit microcontrollers that run at speeds of up to 200Mhz, but I'm afraid ARM won't be able to compete with Intel when it comes to gigahertz-level processors.

Oh, and as for thinking like a "techy", in the end the only thing that matters is "Does it run my office suite" and "does it run my games". And the answer is likely "no" if you have an ARM. Because at the end of the day, nearly everyone runs Microsoft Office and nearly everyone ends up with some games compiled for x86.

Like I said, I hope I'm wrong. It's much, much, much better for my career and the future of computing if ARM starts doing great. But I don't think I'm wrong. Too bad, too.

Sigh.

The reason to go with x86 is because ARM is just as shitty of an architecture.

Seven supervisor modes now? Horrible page table format? Have you seen what they are planning for 64-bit addressing?

Even more importantly than the CPU architecture, the ARM busses are typically very low performance. And if most of the time is dealt with memory movement, having a better bus dwarfs what's going on with the CPU.

So, in the end, you have slow cores. Intel knows how to make x86 fast. And, as they are starting to show, they can make it low power also. ARM has yet to show a fast core. They don't use that much power, but if "netbooks" are low end laptops instead of high end cell phones, a few watts is fine.

Oh, and did I mention that x86 cores are x86 compatible? That makes the software barrier to entry a lot lower.

To compete with Intel, you have to be better. A lot better. For very low end, ARM is better, because all that matters is leakage power, and after that all that matters is power for very small processing. At a higher level of performance, ARM is different, but perhaps not better. Maybe the ARM architecture has some features which make it less complex to implement than x86. But at the end of the day if nobody is making ARM cores that spank x86 cores, x86 will win. Didn't you learn this from PowerPC? Don't you realize the same thing will probably happen to ARM except at the extremely low end? And even there, if Intel decides to start licensing 386 synthesizeable cores, how long do you think ARM7 and ARM9 will last?

We tried ICC on our simulator. The result: 8% slower than GCC. On intel chips. Specifying the correct archtiecture to ICC.

We were not impressed.

I'll second Innumeracy, and also add _A Mathematician's Apology_, by Hardy, which can be red in full (Evidentially) here. A quote from it:

The mathematician's patterns, like the painter's or the poet's must be beautiful; the ideas like the colours or the words, must fit together in a harmonious way. Beauty is the first test: there is no permanent place in the world for ugly mathematics.

Nobody is noticing that Google is shipping an easy-to-use, free, fast, pretty operating system?

Make sure you do your own regular backups, clearcase will eat your repository in a disastrous way, and you'll wait for IT to fix it for 2 weeks. At least, that was my experience with clearcase.