not so fast! if your canoe breaks on a lake in sweden, you'll get accused of lake rape

Most *nix systems since 1979's V7 at least try to defeat fork bombs by capping the number of processes allowed to be spawned by a user.

I think it's probably fine to store non-empty cells as objects, as long as you use something like the Flyweight pattern to avoid carrying too much baggage in each cell. It makes for a fine user interface, I'm sure.

To really get good recalc performance, though, you really need to drag the cell dependence graph out of the grid and treat it like an actual program. Once you do that, you could actually JIT the computation represented by all those cells. If you're really walking the object forest for every recalc, you'll never speed up.

I'd like to see you implement an AND gate with just XORs and NOTs. Use as many as you like... ;-)

In all seriousness, you can build all other gates from NANDs. Or from NORs. In fact, that's how the Cray 1 was built, apparently. Tons and tons of ECL NAND gates.

The 4th what? Surely you don't mean the 4th amendment? After all, that amendment protects against unreasonable searches, which is completely unrelated to the issue at hand.

The Fourth Amendment's protection of "papers" has never applied to the external surface of mail. The outside of mail must be read by the USPS for the service to function, so when you drop a letter in the mailbox, you're implicitly giving the USPS permission to read the visible surface. To my knowledge, there has never been a law preventing the USPS (or any other courier, for that matter) from reading anything visible from the outside. If the surface of mail is particularly confidential, it's not "unreasonable" to expect the mailer to put it in a plain outer envelope.

...Because it's not like your side of the story could possibly be corroborated by receipts, packing slips, or even the actual product.

Surveillance itself isn't inherently bad, but it's an all-or-nothing deal. Once the investigators know you've been receiving packages from $ENEMY, they need to also know that those packages were unrelated to $PLOT or $TARGET, so it's obvious you're just another mundane person.

How? Which piece of legislation forbids the USPS from logging what it handles?

Actually, that's exactly what Intel Custom Foundry does.

Intel supplies all of the CPUs used in Apple's desktop and laptop computers, yes.

Is that "Apple should take their cash and build their own foundries" or "Apple should take their cash and buy an existing foundry"? In either case, it's "Apple should continue to invest in foundries to update to new processes", and, in either case, I'm not sure how easy that would be.

Or is that "Apple should do their own chip designs"? Anandtech suspects they're already doing that.

If by "firmware component" you mean on-chip firmware, how is owning your own foundry, rather than having another foundry fab your design, a requirement for that? Or does this mean that "Apple should take their cash and build their own foundries" means "Apple should do their own chip designs" rather than "Apple should do their own chip fabrication"?

What sort of firmware customization are you talking about here?

I disagree. Copying a form factor is not really copying design. That's a bit like saying that every hatchback car today is a copy of the original Japanese hatchbacks or whoever first produced the design. While it is true at one level, it is too simplistic a statement to make.

Anyway - I think the biggest challenge for Intel is not its process technology (process shrinks are going to get a lot harder in every iteration, but that holds true for everyone - including Intel and probably more so for TSMC, Samsung, and others). It is actually not even an x86 vs ARM architecture thing - ARM architecture superiority has pretty much been debunked since Medfield's release.

The biggest challenge for Intel, IMHO, is that it is simply not used to (and not geared for) SOCs. Intel has always designed and manufactured discrete chips whereas the entire mobile industry prefers, nay wants, highly integrated SOCs. This is the one aspect where Qualcomm kicks everyone's butt. To put it another way, Intel's fight is not with ARM or TSMC or AMD. Intel's fight today is with Qualcomm. Intel *needs* to get the same level of integration in its SOCs as Qualcomm - otherwise no one will want a bunch of discrete chips from Intel even if Intel shouts itself hoarse about how much better its chips are. And this goes for Apple as well. If Intel can give Apple an SOC that integrates the CPU, GPU, modems and other chips (I'm actually not an expert here but I would say things like DAC, GPS, etc. - anything that is not MEMS), I have a feeling that Apple will find it very hard to say "no".

I don't mean to sound grand but I honestly feel that the future of semiconductors will be highly integrated one-chip SOC based solutions that are "cheap as chips".

I.e., code should be written in high-level descriptive languages, and the compiler should choose the algorithm, so that a tricky-to-understand but much-faster algorithm doesn't show up in the code as written, but shows up in the generated code?

Not all rewrites-for-performance involve low-level trickiness.

you don't think the guard, army (etc) won't shoot on fellow american citizens?

think again.